Welcome to
Reactiflux
@@ -91,7 +111,7 @@ const Index = ({ userCount }) => {
>
Join Reactiflux
-
+
Q&A Schedule
diff --git a/src/pages/jobs.js b/src/pages/jobs.js
index a1f9445..186a4db 100644
--- a/src/pages/jobs.js
+++ b/src/pages/jobs.js
@@ -14,7 +14,12 @@ const Jobs = () => {
return (
-
+
{(setSidebar) => (
<>
diff --git a/src/pages/podcasts/[slug].tsx b/src/pages/podcasts/[slug].tsx
index 72485f9..07bb5b5 100644
--- a/src/pages/podcasts/[slug].tsx
+++ b/src/pages/podcasts/[slug].tsx
@@ -2,6 +2,7 @@ import { useEffect, useRef, useState } from "react";
import { z } from "zod";
import { type RootTranscript } from "@utils/transcript-types";
import { useRouter } from "next/router";
+import Head from "next/head";
import { Layout } from "@components";
const getNestedProperty = (
@@ -46,7 +47,20 @@ export const getStaticProps = (t: { params: { slug: Slug } }) => {
};
};
+// An unfinished experiment with a hardcoded slug. noindex goes on every render
+// path, including the loading state that is all the prerendered HTML holds.
export default function PodPage({ slug }: { slug: Slug }) {
+ return (
+ <>
+
+
+
+ (null);
diff --git a/src/pages/transcripts.tsx b/src/pages/transcripts.tsx
index f1e84ab..093f0f2 100644
--- a/src/pages/transcripts.tsx
+++ b/src/pages/transcripts.tsx
@@ -2,23 +2,33 @@ import React from "react";
import { add, format, compareDesc, parseISO } from "date-fns";
import { FocusBoundary, Layout, Link } from "@components";
-import { loadAllMd, processMd, Transcript } from "@helpers/retrieveMdPages";
+import {
+ loadAllMd,
+ processMdPlaintext,
+ Transcript,
+} from "@helpers/retrieveMdPages";
+
+// Dates are stored as midnight UTC; a day's offset keeps them from rendering
+// as the previous day in US time zones, same as the transcript pages.
+const toDay = (date: string) => add(parseISO(date), { days: 1 });
+
+const truncate = (text: string, max: number) =>
+ text.length <= max ? text : `${text.slice(0, max - 1).trimEnd()}…`;
export default function Transcripts({
all,
- latest,
+ firstYear,
}: Awaited>["props"]) {
- const date = format(add(parseISO(latest.date), { days: 1 }), "EEEE PPP");
return (
{(setSidebar: any) => (
<>
- {latest.title}
+ Q&A transcripts
-
+
+
+ Since {firstYear}, Reactiflux has hosted Q&As with the people
+ who build React, React Native, and the libraries and tools around
+ them. Members bring the questions; these are the transcripts,
+ newest first.
+
- Transcript from {date}
+ Looking for This Month in React? Episodes, show notes and
+ transcripts are at{" "}
+
+ tmir.reactiflux.com
+
+ .
-
+
+ {all.map((transcript) => (
+ -
+ {transcript.title},{" "}
+ {transcript.month}
+ {transcript.blurb ? `: ${transcript.blurb}` : null}
+
+ ))}
+
)}
@@ -56,23 +82,26 @@ export async function getStaticProps() {
.sort((a, b) =>
a.date && b.date ? compareDesc(parseISO(a.date), parseISO(b.date)) : 1,
);
- const latest = all[0];
- if (!latest) {
+ if (all.length === 0) {
throw new Error("No transcripts found!");
}
+ const years = all
+ .filter((t) => t.date)
+ .map((t) => toDay(t.date).getFullYear());
return {
props: {
+ firstYear: Math.min(...years),
all: all.map((t) => ({
title: t.title,
- hasContent: Boolean(t.content),
path: `/transcripts/${t.slug}`,
+ month: t.date ? format(toDay(t.date), "MMMM yyyy") : "",
+ blurb: truncate(
+ processMdPlaintext(t.description ?? "")
+ .html.replace(/\s+/g, " ")
+ .trim(),
+ 160,
+ ),
})),
- latest: {
- title: latest.title,
- description: latest.description,
- date: latest.date,
- html: processMd(latest.content, { wrapFirstList: true }).html,
- },
},
};
}
diff --git a/src/pages/transcripts/[slug].tsx b/src/pages/transcripts/[slug].tsx
index 8cb665e..8c81cc4 100644
--- a/src/pages/transcripts/[slug].tsx
+++ b/src/pages/transcripts/[slug].tsx
@@ -17,16 +17,17 @@ export default function Transcript({
html,
}: Awaited>["props"]) {
// A ridiculous method to ignore timezones
- const formattedDate = format(add(parseISO(date), { days: 1 }), "EEEE PPP");
+ const day = add(parseISO(date), { days: 1 });
+ const formattedDate = format(day, "EEEE PPP");
return (
{(setSidebar: any) => (
<>
@@ -66,6 +67,15 @@ ${description}`}
);
}
+/** One line for search results: who, when, then as much of the blurb as fits. */
+function metaDescription(title: string, date: string, blurb: string) {
+ const lead = `Transcript of the Reactiflux Q&A with ${title}, ${date}.`;
+ const rest = blurb.replace(/\s+/g, " ").trim();
+ if (!rest) return lead;
+ const full = `${lead} ${rest}`;
+ return full.length <= 200 ? full : `${full.slice(0, 197).trimEnd()}…`;
+}
+
export const getStaticProps = async ({
params,
}: {
@@ -89,7 +99,7 @@ export const getStaticProps = async ({
all,
...pick(["title", "date"], doc),
html: processMd(doc.content, { wrapFirstList: true }).html,
- description: processMdPlaintext(doc.description).html,
+ description: processMdPlaintext(doc.description ?? "").html,
},
};
};
diff --git a/src/transcripts/tmir-2024-01.md b/src/transcripts/tmir-2024-01.md
deleted file mode 100644
index 25adac8..0000000
--- a/src/transcripts/tmir-2024-01.md
+++ /dev/null
@@ -1,549 +0,0 @@
----
-title: This Month in React (January 2024)
-date: 2024-01-31
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/episode/5vn2bvmAkFxK3hvNQfGcmx?si=LNR0KUNwRnmpt7x2jJMf0g)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/tmir-2024-01-the-year-ahead-why-are-people-so-miffed/id1661733526?i=1000644051585)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick hits
- - [[00:32](#reviewing-layoffs)]: [Layoffs.fyi](https://layoffs.fyi/)
- - [[03:06](#conferences)]: Conferences
- - [React Paris](https://react.paris/) March 22nd, Paris, FR
- - [Epic Web](https://www.epicweb.dev/conf) April 11th, Park City, UT
- - [React Miami](https://www.reactmiami.com/) April 19-20th, Miami, FL
- - [React Connection / RN Connection](https://reactconnection.io/) April 22nd, Paris, FR
- - [React Conf 2024](https://conf.react.dev) May 15-16 Henderson, NV
- - [[03:58](#library-releases)]: New releases
- - [React Aria generally available](https://react-spectrum.adobe.com/releases/2023-12-20.html)
- - [New shadcn/ui components](https://ui.shadcn.com/docs/changelog)
- - [Eslint v9 alpha 0](https://eslint.org/blog/2023/12/eslint-v9.0.0-alpha.0-released/)
- - [jQuery 4.0??](https://github.com/jquery/jquery/issues/5365)
- - [date-fns v3](https://blog.date-fns.org/v3-is-out/)
- - [ReScript v11](https://rescript-lang.org/blog/release-11-0-0)
-- [[08:08](#react-libraries-for-2024-by-robin-wieruch)]: [React Libraries for 2024](https://www.robinwieruch.de/react-libraries/)
-- [[09:54](#rising-stars-on-github)]: [Rising Stars for JS, React ecosystem](https://risingstars.js.org/2023/en#section-react)
-- [[10:56](#bytes.dev-2024-predictions)]: [2024 bytes.dev predictions](https://bytes.dev/archives/250)
-- [[12:29](#speculating-on-react-19)]: React 19 and upcoming features
- - Context Selectors! [Discussion](https://twitter.com/acdlite/status/1741188563926962190) and a [summary from](https://interbolt.org/blog/react-use-selector-optimization/) [Colin Campbell](https://twitter.com/interbolt_colin)
- - [Proper Web Component support planned for React 19](https://github.com/facebook/react/issues/11347#issuecomment-1899140345)
- - [Web Components 2024 feature updates](https://eisenbergeffect.medium.com/web-components-2024-winter-update-445f27e7613a)
- - [[19:01](#upcoming-client-features-in-react)]: [Rick Hanlon: some upcoming client features I'm excited about](https://twitter.com/rickhanlonii/status/1747333623152275685)
- - [New client-side hooks coming in React 19](https://marmelab.com/blog/2024/01/23/react-19-new-hooks.html)
- - [React Forget updates](https://twitter.com/dan_abramov2/status/1747640983980806466)
-- Framework updates
- - [[22:34](#remix-spa-mode)]: [Remix working on “SPA mode”](https://github.com/remix-run/remix/pull/8338)
- - [Likely stabilize as Vite plugin does](https://github.com/remix-run/remix/discussions/7638#discussioncomment-8286839)
- - [Remix also working on RSC support](https://twitter.com/ryanflorence/status/1752166725028872432), and will have [differences from Next’s approach](https://twitter.com/ryanflorence/status/1752711755384692854).
- - [[24:53](#next-14.1)]: [Next.js 14.1](https://nextjs.org/blog/next-14-1)
-- [[27:56](#annoyed-at-react-roundup)]: “Annoyed at React” roundup
- - [Kind of annoyed at React](https://blog.cassidoo.co/post/annoyed-at-react/)
- - [React, where are you going?](https://dev.to/matfrana/react-where-are-you-going-5284)
- - [Mark’s reply](https://dev.to/matfrana/react-where-are-you-going-5284#comment-2c8g3)
- - [Ryan Florence on Twitter](https://twitter.com/ryanflorence/status/1747699804598395215)
- - [Increasingly miffed about the state of React releases](https://macwright.com/2024/01/03/miffed-about-react)
- - [React is getting a bit of a kicking lately](https://piccalil.li/blog/react-is-getting-a-bit-of-a-kicking-recently/)
-- [[37:55](#rsc-updates)]: RSCs
- - [RSCs: The Good, the Bad, and the Ugly](https://www.mayank.co/blog/react-server-components/)
- - [Leerob reacts](https://www.youtube.com/watch?v=8DyzsSWNcDE)
- - [The Two Reacts](https://overreacted.io/the-two-reacts/)
- - [RSC is React Server + Component](https://bobaekang.com/blog/rsc-is-react-server-plus-component/)
- - [“RSC does not require a server”](https://twitter.com/dan_abramov2/status/1745795274977493317) – Dan
- - [React Server Components paradigm](https://www.telerik.com/blogs/react-server-components-paradigm)
-- ⚡ Lightning round ⚡
- - [[47:40](#ryan-carniato-js-frameworks-into-2024)]: [Ryan Carniatto, JS Frameworks heading into 2024](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2024-i3l)
- - [[48:15](#rspack)]: [RSBuild guide to migrating from CRA](https://rsbuild.dev/guide/migration/cra)
- - [[50:10](#benchmarking-react-native-styling)]: [React Native styling tool benchmarks](https://www.reddit.com/r/reactnative/comments/1adasz4/react_native_cssstylesheet_frameworks_benchmark/)
- - [[50:40](#weird-things-engineers-believe-about-web-development)]: [Weird things engineers believe about Web development](https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/)
- - [[51:59](#tea.xyz)]: [Homebrew creator launching Tea.xyz, an OSS funding project](https://twitter.com/mxcl/status/1749894737862025330?s=46&t=uXPe0cHZZfyFyGotvsr9IQ)
- - [[55:44](#everything-on-npm)]: [NPM registry prank leaves developers unable to unpublish packages](https://www.scmagazine.com/news/npm-registry-prank-leaves-developers-unable-to-unpublish-packages)
- - [[57:00](#codepen-top-10)]: [CodePen top 10](https://codepen.io/2023/popular/pens/10)
- - [[57:37](#v8-performance-improvements)]: [V8 performance improvements](https://v8.dev/blog/holiday-season-2023)
-
-[00:00] **Carl Vitullo:** Thanks everyone for joining us for January's this month in React. I'm Carl. I am a staff product developer and freelance community manager here at React Tofl, the Discord for React Professionals. And Mark, you wanna introduce yourself?
-
-[00:14] **Mark Erikson:** Hi, I'm Mark. My day job is at Replay io where we're building a time, traveling demographer JavaScript.
-
-[00:20] And in my copious amount of spare time, I maintain Redux.
-
-[00:23] **Carl Vitullo:** Seems like it's been a big month. I don't know if that's just January, but yeah, let's dive right into it. I'm going to start off with a couple of, like, quick hits of small news.
-
-## Reviewing layoffs
-
-[Layoffs.fyi](https://layoffs.fyi/)
-
-[00:32] **Carl Vitullo:** I've been keeping track of layoffs. fyi. The first month of 2024 is looking not great. January layoffs have picked up a decent amount compared to last month, but compared to last year, January 2023, they're down like 70%. So, seems like it's trending in a good direction on an annual basis, but my instinct is that the next year is going to still be pretty rough.
-
-[00:58] Getting more specific, in January, 2022, there were five layoffs with about half a thousand affected. 2022 had a pretty steady upward trend for the rest of the year, which spiked really sharply in November. And then again, in January of 2023. Uh, so 2023 in January, there were 277 layoffs with about 89,000 affected. Jumping ahead to this year. January, there were 118 layoffs with about 31,000 affected. So this January is significantly less bad than last January, but compared to two years ago, it is... not even close it is super super high, still.
-
-[01:38] But looking at this annually as part of a cycle, um, I attribute some of this, I'd attribute the spike in November to businesses wanting to avoid holiday layoffs and sort of front-loading those.
-
-[01:49] So instead of splitting that same number of layoffs across two months, just doing it all at once in November. Um, and then. In January with new financial fears, starting new budgets. Uh, Annual decisions being made. In this fearful atmosphere management is biasing towards reducing expenses and lengthening runways, which I think is why there was such a large spike in January.
-
-[02:17] I also want to note that the first time the us fed hiked interest rates was in March of 2022. So looking at how. Low layoffs were in the first months of 2022, and then seeing how they spiked, or rather how they grew over time through the rest of the year. I think that a large part of the thrashing, ensuring that we're seeing right now in layoffs and, um, poor job climate is due to really national and global scale economic conditions.
-
-[02:49] Uh, you know, there's no more zero interest rates, so no more zero interest rate phenomenons, and nobody quite knows what the. Important financial metrics to optimize for, and even what to target are in this new funding environment. So I think that's really important context to keep in mind when thinking about layoffs.
-
-## Conferences
-
-- [React Paris](https://react.paris/) March 22nd, Paris, FR
-- [Epic Web](https://www.epicweb.dev/conf) April 11th, Park City, UT
-- [React Miami](https://www.reactmiami.com/) April 19-20th, Miami, FL
-- [React Connection / RN Connection](https://reactconnection.io/) April 22nd, Paris, FR
-- [React Conf 2024](https://conf.react.dev) May 15-16 Henderson, NV
-
-[03:06] **Carl Vitullo:** Conferences coming up in the next two to three months. I'm just going to run through a couple.
-
-[03:11] We've got React Paris going on in March, towards the end of March 22nd, in fact.
-
-[03:17] Epic Web, which is hosted by Kent C. Dodds. That's going to be going on in April 11th in Park City, Utah.
-
-[03:24] React Miami, April 19th and 20th, in Miami, obviously.
-
-[03:29] Another Paris conference it looks like, or, I guess conference.
-
-[03:33] **Mark Erikson:** It's an actual conference, and in fact, I will be speaking at React Connection Paris.
-
-[03:37] **Carl Vitullo:** React Connection, React Native Connection, April 22nd in Paris. That's two Paris conferences exactly one month apart. So that's neat.
-
-[03:46] And React Conf, the React Conf, is happening for the first time in three or four years. So that's, we're going to talk more about that later, but definitely pretty excited to see what they've got to share.
-
-## Library releases
-
-- [React Aria generally available](https://react-spectrum.adobe.com/releases/2023-12-20.html)
-- [New shadcn/ui components](https://ui.shadcn.com/docs/changelog)
-- [Eslint v9 alpha 0](https://eslint.org/blog/2023/12/eslint-v9.0.0-alpha.0-released/)
-- [jQuery 4.0??](https://github.com/jquery/jquery/issues/5365)
-- [date-fns v3](https://blog.date-fns.org/v3-is-out/)
-- [ReScript v11](https://rescript-lang.org/blog/release-11-0-0)
-
-[03:58] **Carl Vitullo:** All right, continuing on. Some more quick hits before we dive into the real proper link discussion. A number of new releases, just like smaller libraries, that don't quite merit a full discussion round in the main segment. Just thought I'd run through them real quick.
-
-[04:13] React ARIA from Adobe, which I As far as I understand is a component library more specifically aimed like the value proposition of it being accessibility, an area I always think of as an accessibility thing. That is a huge advantage of using a component toolkit like that is getting the long tail of smaller benefits like accessibility. So definitely interested to see that.
-
-[04:36] **Mark Erikson:** The important bit to distinguish there is React Aria, the original form of it is actually a whole bunch of hooks that are kind of like the headless data type management. Here's a hook for managing slider data or something. And this specifically, I believe they've then built their own component library on top of that. You've always been able to use the hooks yourself in your own components, but they've now also built a set of components that make use of those hooks as well.
-
-[05:04] **Carl Vitullo:** Starting from the core primitives, ironing out the functionality there and then exposing it for, through a different means of accessing it. That sounds really cool. I'm really into it.
-
-[05:13] There are new ShadCN UI components. I don't have a list prepared to read off. Oh, yes I do. Carousel, drawer, pagination, resizable, a toast component called sonner, and a bunch of CLI updates. Yeah, love ShadCN UI. Love the concept. So, check it out.
-
-[05:30] ESLint has a new version 9 alpha 0. Don't have anything prepared to speak about there. It's not ready for production use just to get feedback right now, but it caught my eye that there's a new major version of ESLint coming.
-
-[05:44] Speaking of major versions, there is a major version of jQuery version 4 that is in the works. It's not released yet, but I caught discussion of the announcement blog post and upgrade guide, so cool! jQuery, blast from the past, love to see it.
-
-[05:59] Two more here for you. There's `date-fns` v3. `date-fns` is definitely a great library. Good replacement tool for Moment, if you're still using Moment. And yeah, I love it. It's great. Major version.
-
-[06:11] And last one. This is a little bit more of a stretch, but Rescript has Major Version 11 coming out. It's a compile to JavaScript typed language that I saw described as TypeScript the good parts. I haven't used it. I'm not super familiar with what its value proposition is, but yeah. New version. Seems cool. Love an experimental language.
-
-[06:32] **Mark Erikson:** There is some amount of buzz around what was originally known as, let's see, what was it before Rescript? Something else that started with RE, and I can't think of it right now. The language itself started as a fork of OCaml with more JavaScript like syntax.
-
-[06:49] Jordan Walke and Chung Lo and some other folks in the React community were really trying to push this around like 2017 or so. And it felt like there might be enough bleed over from the React community to make it a thing. And there was a whole series of forks around the tool and the language syntax that really killed any actual momentum it had.
-
-[07:12] And that combined with TypeScript really taking over as the definitive way to write types for JavaScript. I feel like it's moment passed around 2017, so there's, you know, apparently some, still some development work ongoing, and there's, there's always arguments of, use a better language, and it fixes some of the issues with TypeScript and JavaScript, but I think in practice TypeScript is good enough at this point, and, and the ecosystem momentum is there.
-
-[07:40] **Carl Vitullo:** Tile to JavaScript language is a pretty hard sell on starting. If you're going to start a new product that they're going to maintain for years, it's a big swing to try and use a brand new language. But I always appreciate seeing experimental languages. I think that's where a lot of the experimentation happens.
-
-[07:56] And then maybe some of the learnings from running a language like that will be brought back into JavaScript, the ECMAScript process, or into TypeScript itself. Love to see it.
-
-[08:07]
-
-## [React Libraries for 2024 by Robin Wieruch](https://www.robinwieruch.de/react-libraries/)
-
-[08:08] **Carl Vitullo:** We're going to start off talking about React libraries for 2024 from Robin Wieruch, which I hope I'm not butchering that too badly.
-
-[08:16] **Mark Erikson:** I don't know how to pronounce his last name either.
-
-[08:18] **Carl Vitullo:** Robin has been publishing very high quality blog posts and explanations and Just great content for years and years. I remember reading his stuff way back in 2015, 16, I want to say. And this is yet another in the same vein. It's a huge, very comprehensive list of recommended tools for all sorts of different aspects of building a real production website.
-
-[08:45] I mean, the table of contents, it's A full page on its own. Starting a new project, package manager, state management, data fetching, authentication, database, testing, rich text editor, drag and drop, mail. Just, it's a great list. Definitely worth reading, definitely worth checking out, especially if you're in a position of spinning up a new Greenfield project.
-
-[09:05] Something like that.
-
-[09:07] **Mark Erikson:** And, and actually on, on that note, uh, Robin also just put up a post, um, talking about how to actually create a new React project in 2024. His argument, not surprisingly, is start with Vite, especially if you're learning, it's, it's simpler, there's Fewer concepts to learn at once, and then here's when you would consider Vite, here's when you would consider Next, here's when you would consider Astro.
-
-[09:31] **Carl Vitullo:** What I have found myself reaching for personally when I'm starting out has been either just whatever Next or Remix. They both ship starter kits, but I've been using React for 10 years. I appreciate the concept of a novelty budget when working with a, uh, starting a new project. So, limiting the number of new concepts you're exposing yourself to is definitely smart advice.
-
-## [Rising Stars on GitHub](https://risingstars.js.org/2023/en#section-react)
-
-[09:54] **Carl Vitullo:** Very cool. Somewhat related, I came across a Rising Stars Annual award thing. It's a tracking open source projects that gained the most stars on GitHub over 2023. Pretty cool. Top 10, I think, for the React ecosystem were ShadCNUI, Excalidraw which I don't know, it's a, it's not a library. It's not really a React tool.
-
-[10:21] I know it was created by. Christopher Chedeau . Christopher Chedeau, thank you. So I think that's why it's in here. I love it, but it's not, I don't know if I would call it a React project. Anyway, it did beat out Next. JS though, that's number three. Zustand, number four, Refine, Docusaurus, love Docusaurus, CreateT3App, NextUI, Tremor, and Serverless stack.
-
-[10:42] So that's the top 10. There's a whole lot more, and they had a bunch of different ecosystems represented. It's a pretty cool list, pretty neat to see. Yeah, I've seen a comment in the chat, sad not to see UnoCSS. That's a new one to me. Wanted to check out though.
-
-## [Bytes.dev 2024 Predictions](https://bytes.dev/archives/250)
-
-[10:56] **Carl Vitullo:** Cool, yeah, another, keeping the thread of 2024, I don't know, analysis, predictions, Bytes, the Bytes. dev newsletter, which is one of the places that I pull links from to discuss, it put out a a list of predictions for 2024 and This is put out by Tyler McGinnis. He's been huge in the React ecosystem for years and years. I think bytes. dev is like one of the largest developer newsletters. Definitely a great source.
-
-[11:23] Some of his predictions though,
-
-[11:25] bun becomes the default runtime for the front end. That seems like a big swing. I don't know. Mark, what do you think about that?
-
-[11:30] **Mark Erikson:** So the caveat here is that the Bytes newsletter is written in a very intentional tongue in cheek humorous style.
-
-[11:38] There's real links and real thoughts, but Bytes is very much a sarcastic humor kind of newsletter rather than a strict straight to the point newsletter. So most of these predictions are very tongue in cheek.
-
-[11:51] **Carl Vitullo:** Second prediction was more than three of your favorite open source software slash dev tool startups will die.
-
-[11:57] **Mark Erikson:** I mean, that one's pretty much a given, right?
-
-[11:59] **Carl Vitullo:** Yeah, right. Fair. But you could make that about any startup class over an annual timescale, but fair enough. AI will replace no code, low code tools. Seems plausible. Maybe not this year. Netlify gets acquired by GoDaddy. Yeah. Well, I don't know. I won't go through every single one, but I, one, another one that I did was no one will figure out what local first actually means.
-
-[12:19] I have opinions there. I feel like local first is a good thing to strive for, but hopefully more people figure it out this year.(chuckles) Cool. Mark, you want to tell us about React 19?
-
-## Speculating on React 19
-
-- Context Selectors! [Discussion](https://twitter.com/acdlite/status/1741188563926962190) and a [summary from](https://interbolt.org/blog/react-use-selector-optimization/) [Colin Campbell](https://twitter.com/interbolt_colin)
-- [Proper Web Component support planned for React 19](https://github.com/facebook/react/issues/11347#issuecomment-1899140345)
-- [Web Components 2024 feature updates](https://eisenbergeffect.medium.com/web-components-2024-winter-update-445f27e7613a)
-- [Rick Hanlon: some upcoming client features I'm excited about](https://twitter.com/rickhanlonii/status/1747333623152275685)
-- [New client-side hooks coming in React 19](https://marmelab.com/blog/2024/01/23/react-19-new-hooks.html)
-- [React Forget updates](https://twitter.com/dan_abramov2/status/1747640983980806466)
-
-[12:29] **Mark Erikson:** Yes, so when we did this last month and we were doing some predictions for this year, saying that I expect React 19 to probably happen this year because we were seeing some initial discussions and mentions from the React team, and while we still don't actually have a timeline, there is a lot more activity going on.
-
-[12:50] On that front, item one, Satya, one of the React Forget team members, happened to drop by one of our discussion threads over in the Tech Reads and News channel and said that the general discussion of the React team seems to be that the next stable release of React will be React 19, there hasn't been any specific discussions or plans around a React 18. 3 minor version, and that generally matches just the other bits and pieces of discussion I've seen so far.
-
-[13:20] So we can probably expect that the next actual release will be React 19. One really big thing that came out In some Twitter threads is the idea that React might finally ship a form of context selectors.
-
-[13:36] This was a proposal that was first done back in 2019 by Josh Story, who at the time was just a community member. He now currently works for Vercel building server side React stuff. Andrew Clarke played with a prototype of building context selectors in like 2020 and then it's the concept sat around and hasn't gone anywhere, especially with all the focus on suspense and server components.
-
-[14:01] But in this discussion thread, the React team has said that their approach for implementing quote, context selectors And optimizing re renders when a component only needs one piece of data from a context will actually be to use the new named use, which is still horribly confusing. Like, you're going to be able to call the use hook inside of use memo, and that basically becomes like your selector function, in a sense.
-
-[14:34] And that will actually allow React to look at the contents of what you've returned, and maybe even call the memo callback itself, separately from rendering, determine that, look, nothing actually changed, and actually be able to skip out of potential re renders that way. I don't know if this will actually be in React 19 yet, I don't know if it's Something that they've proof of concepted already, but that's, that is a pretty big deal.
-
-[15:04] We've been waiting for that one for a while. Another one that we've been waiting for a very long time is proper web component support. React allows you to render web component elements. They're just, HTML string tags in that sense, but there's been lots of complexity around being able to accurately pass props into web components because of the differences between React passing around JavaScript values as props.
-
-[15:31] Versus web components having attributes that are strings versus properties that have to be set via JavaScript. And I don't understand all the nuances there, I have not used web components. But a, like an issue was filed back in like 2017, complaining that React did not have correct support for interacting with web components.
-
-[15:55] It took four years until someone from Meta finally went through all the arguments and proposals of what the exact semantics should be, and finally implemented An experimental feature that made them work right for React, but that feature has sat inexperimental for the last two plus years. And so they finally commented on that thread a couple weeks ago and said, this will be in React 19, finally.
-
-[16:24] **Carl Vitullo:** I've never really used Web Components either. In a lot of ways, they felt like they were trying to solve the same challenges, or a similar set of challenges that React did. But in many ways, React seems to take on a much larger scope. I mean, I think that's exemplified by the emphasis on React Server Components now, where you Like web components are trying to componentize web and that's cool, that's great.
-
-[16:50] But React has componentized UI across, I mean, it's used in mobile, it's used in web to make the UI for video games. It's crossing the server client boundary now in a very meaningful way. So I mean, that's why I've, that's why I have never used web components is because I have never felt a pain that they seem to solve that React was not already trying to solve on its own.
-
-[17:14] Yeah, so I don't know. Cool to see it coming in though. It'll be interesting to have, cool to have it as another option. But I'm skeptical that it's going to be that meaningful in the grand scheme of things just because, okay, It's kind, it's, it's the new render target in a way.
-
-[17:29] It's like not the normal DOM. You'd need a compatibility shim make it work with React Native. So I guess maybe that's a good analogy.
-
-[17:39] **Mark Erikson:** There's been lots and lots of arguments. I mean, like a lot of web component fans hate React, you know, because it's too, it's too big. It's too much JavaScript.
-
-[17:47] It tries to take over the, the browser, et cetera.
-
-[17:49] **Carl Vitullo:** It doesn't use the platform. Yeah.
-
-[17:51] **Mark Erikson:** Right, right. I think the best pitch for web components plus React that would benefit from this new support is maybe your company has. The Vue apps and Angular apps and React apps, you're trying to have a unified design system and you build that design system as web components, so you only have to implement it once.
-
-[18:14] And then you can now use those design components properly from within React.
-
-[18:20] **Carl Vitullo:** Intuitively makes sense to me. I strongly suspect that the technical realities of making that work are going to be pretty painful. But yeah, cool. It sounds like a large team. kind of challenge. I don't know. But yeah, I think it, I think to me the mental model that makes sense for it is it's a little bit like dropping down into native code on React Native, but on the web.
-
-[18:43] If you're using web components, you're, you're working at a lower level of abstraction than, than most components you would write in React.
-
-[18:51] **Mark Erikson:** Yep. I've been complaining about the React teams, you know, seemingly single focus on server components to the Somewhat detriment of new features for the client side.
-
-## [Upcoming client features in React](https://twitter.com/rickhanlonii/status/1747333623152275685)
-
-[19:01] **Mark Erikson:** Having said that, Rick Hanlon from the React team did recently put up a Twitter thread where he pointed out that there are a number of new features that work in the client and in some cases can be considered client side only. There's a, these are primarily a new series of built in hooks. poorly named UseHook, which can accept a promise and will be the new official trigger for suspense behavior.
-
-[19:26] You could, you will also be able to call the UseHook and pass in a context object to grab the context value, and apparently you can actually call that inside of loops and non rendering functions like callbacks, and so there will be some very interesting flexibility out of that. There's some improvements to StartTransition and FormActions, and then some new hooks for FormState, FormStatus, and OptimisticUpdates.
-
-[19:56] All those do exist in the latest Canaries, so if you're using Next. js, those are probably available, but they will hopefully actually become stable as part of React 19. So I do have a link under here where someone wrote a follow up article that actually gives some further details about some of those.
-
-[20:15] And then, while it's not specifically listed in there, some other things we can expect are they will finally be removing some deprecated features like the Legacy Context API. Given that it's been deprecated for multiple years, I expect that very few people listening have ever actually used it. People have asked the React team to clean up dead features for a long time, and they're finally going to be doing some of that.
-
-[20:38] And React 19 should also include the source maps work that I did.
-
-[20:44] **Carl Vitullo:** Yeah, I mean I guess that's the big advantage. That's what you do with a major version release, is you remove all the things you deprecated over the, since the last release. So, with, what, 5 years? Since 18?
-
-[20:56] **Mark Erikson:** No, 18, 18 came out in 21, sometime in 22, I think.
-
-[21:03] **Carl Vitullo:** Oh, was it that recently? Okay. Yeah. I guess I'm conflating with hooks, so cool. Yeah. And just to enumerate the upcoming client features that Rick was excited about, there's use in two contact or. Two settings. There's usePromise, which, like you said, is the, uh, how we're going to be interacting with suspense or, yeah, interacting with suspense from now on.
-
-[21:25] UseContext. I don't know, I don't, I appreciate this simplicity being added by this use hook, but calling it a use hook and then not having it follow the rules of hooks as has been established for many years. It just seems like it adds confusion to me. I don't know. We'll have to see how that shakes out.
-
-[21:45] **Mark Erikson:** That plus the literal naming and how carefully I had to word that sentence for it to make any sense.
-
-[21:52] **Carl Vitullo:** So, I don't know. We'll see. But yeah, async transitions in the start transition. Function, form actions for React server components, useFormState, useFormStatus, and useOptimistic. So there's our enumerated upcoming client features, so keep an eye out for those. I think those are currently available in a Canary release, so if you want to play with those.
-
-[22:13] And very cool to have your source maps PR ship out. Finally! Ha ha ha. Looking forward to seeing that. Hopefully, I just want to see, I'd like to see people react like, oh my god, you can do this now! Ah, debugging got so much easier! Yeah.
-
-[22:26] **Mark Erikson:** For the ten of us who actually try to debug into React.
-
-[22:30] **Carl Vitullo:** Well, hopefully it'll make the stack traces easier to read anyway.
-
-[22:33]
-
-## [Remix SPA mode](https://github.com/remix-run/remix/pull/8338)
-
-[22:34] **Carl Vitullo:** Let's move on to some framework updates. Remix is working on a single page application mode, which I think is interesting. I think this makes a lot of sense as a general framing for things like Intuitively, I think my mental model for, like, different forms of complex web applications, there's solutions like Gatsby that did full static generation.
-
-[22:57] Like, you can only, you do a build time and then you publish a bunch of HTML and JavaScript. Then the opposite of that would be like Next and Remix, which are full server client frameworks that help you figure out how to write code across that seam. So, Remix adding more flexibility to cover different areas in that spectrum, I think is really interesting.
-
-[23:20] It's like a single page application, fully static assets shipped from a CDN to the client's browser. That has real use cases. That is the simplest way to host an application. Lowest cost, lowest upkeep, lowest deployment complexity, all of that. That's still a real niche that has real reasons to reach for that.
-
-[23:39] Then, one step advanced from that is something that has a build time generation step. Then, up to the full server, able to respond to requests individually, that is sort of classic Remix or Next. So, I'm excited to see this. They mentioned that it's likely to stabilize as the Vite plugin that they, that we'd talked about, I think, last time, maybe November.
-
-[24:04] But yeah, so SPA mode likely to stabilize alongside the Vite plugin. They're also looking at server component support. It sounds like they're going to be having some different Approaches from how Next is doing it. Yeah, curious to see what they come up with. Ryan Florence has been a little bit on a tear with some good tweets lately.
-
-[24:24] Yeah, I don't know. It feels like something changed. It feels like he's been, uh, a little more visible, at least in my feed lately.
-
-[24:31] **Mark Erikson:** He'd actually take it. 6 months mostly off Twitter, and at least I might have actually deleted his account at one point.
-
-[24:37] **Carl Vitullo:** Yeah, that scans, because I had just felt like I didn't see anything from him for a long time, and I was wondering if that was, I don't know, my consumption habits changing, the algorithm giving me different things, but yeah. Good to see him back because a lot of this is top tier, really great info, really great news.
-
-## [Next 14.1](https://nextjs.org/blog/next-14-1)
-
-[24:53] **Carl Vitullo:** Yeah. Okay. Moving on to from Remix to Next. Next shipped 14. 1. Just going to run through some of the changes. I haven't played with this myself, so just going to, I'm basically summarizing the blog post here. But yeah, they talk about performance improvements, lots of faster local server startup.
-
-[25:12] Faster code updates, a lot faster, say up to 96. 3, very precise. Faster code updates with fast refresh. Faster initial route compiled without caching. And they mentioned that they're, it's not so okay. It looks like they've been adding a lot of caching to get rebuilds faster. They talk about. Adding, in the future, disk caching.
-
-[25:32] So right now you start up the server, and every time you rebuild, the cache is there. The cache is warm. But starting the server has a cold cache, so it's slower. So a disk cache would dump that memory cache to disk, so that when you restart the server, it Still has a warm calf, so it starts up faster. Major trade off there is that you introduce a whole new category of caching bugs.
-
-[25:55] I know when, many moons ago, when I was developing very actively on a Gatsby project, I remember one of my debugging steps. Once one A step less desperate than deleting node modules was deleting the cache. It will be cool to see if performance improvements come out of that. That is always something I'm aware of, just the increased complexity of additional layers of caching.
-
-[26:18] They talk about improved self hosting, new documentation. for some custom cache handling. And I'm going to bring in another tweet that I saw, I don't know if I'll be able to get the link quickly, but I did see, um, a tweet from Dan Abramov in the context of Next. He mentioned that he thought it would be very valuable if Next shipped like a simple mode that did not have any of the advanced features that require The host, to be aware of it.
-
-[26:47] So right now, a lot of things, a lot of features in Next only work exactly as advertised if you're also hosting on Vercel. And that's been a criticism, that's been a criticism especially in the context of Yes, thank you, Mark. Especially in the context of Next and Vercel having a lot of core team members for React, it being tightly coupled to a paid hosting provider rubs some people the wrong way.
-
-[27:15] So I, that makes sense. I think that would be really cool to see, just make it a little bit more portable, especially as like the bleeding edge of React development. It would be nice if that was not required to be hosted on a specific platform.
-
-[27:28] There's some other improvements, TurboPack improvements, developer experience improvements. One that I thought was minor but significant is push state and replace state support in AppRouter. I didn't realize this was missing or something you couldn't do, but yeah, sounds like now you can use the native browser history APIs while you're using the next AppRouter. Not specifically sure what that will enable, but Intuitively, it feels like it should open some new doors.
-
-## Annoyed at React roundup
-
-- [Kind of annoyed at React](https://blog.cassidoo.co/post/annoyed-at-react/)
-- [React, where are you going?](https://dev.to/matfrana/react-where-are-you-going-5284)
-- [Mark’s reply](https://dev.to/matfrana/react-where-are-you-going-5284#comment-2c8g3)
-- [Ryan Florence on Twitter](https://twitter.com/ryanflorence/status/1747699804598395215)
-- [Increasingly miffed about the state of React releases](https://macwright.com/2024/01/03/miffed-about-react)
-- [React is getting a bit of a kicking lately](https://piccalil.li/blog/react-is-getting-a-bit-of-a-kicking-recently/)
-
-[27:56] **Carl Vitullo:** Can we talk about all the people who are annoyed at React?
-
-[27:59] **Mark Erikson:** Yes, let's. One of the hazards of being part of a large tool community, and especially one that is in some ways as controversial as React is, is that there's inevitably waves of discontent that come out. And we've seen this pop up in different ways over the years.
-
-[28:18] I mean, 2017, 2018, there were a lot of people who were posting comments about how much they hated Redux and wanted to kill it. So this is not a new phenomenon, but there has been a very definite series of posts and sentiment from people over the last month or so expressing annoyance with React. And, I'll say this as a meta comment, the real problem at the moment is that there are 30 different overlapping semi related things that people are complaining about.
-
-[28:51] And the problem is, everyone is complaining about a slightly different subset of problems, and It's making it impossible for anyone to actually have a clear and specific discussion about what things this person is actually upset about versus what someone else is upset about. There's complaints about React being tied to Vercel.
-
-[29:14] There's complaints about React's versioning strategy. There's complaints about how the React team does marketing and DevRel or not. There's complaints about the fact that Next and Remix are highly listed in the React docs as tools to start projects. But Vite is relegated to an expandable details section that literally says, Well, I guess if you want to use this, we can't stop you.
-
-[29:43] There's complaints about server components not being sufficiently documented in the actual React docs. And a lot of these complaints are very vibe related. Like, a lot of this stuff isn't specific, technical concerns, and so it's really hard for anyone to meaningfully and coherently discuss a lot of these complaints.
-
-[30:09] So some of the current wave kicked off with Cassidy Williams. Very smart person, well known in the community, has been around for a while. Put up a post where she said she's kind of annoyed at React. It, it is a very, there's a lot of vibes in there. She's very real, she's very actually frustrated. At the same time, if you look at the list of things she says, it's several different pieces, and a lot of it isn't even technical.
-
-[30:34] And, and I'm not discounting her frustration, I'm noting that it's the kind of frustration that can't be solved with. Let's put out a new release. Or something. There was another post that came out a couple days later in response called React, where are you going? Very well written, and it was actually, I believe Published by someone who works on a tool called React Cosmos and some of his complaints came because they'd been trying to update the tool to work properly with the next app router and server components and they got it working but it was a very hard effort and they had to make changes to the API that actually made it less, harder to work with. This person put up a post that expressed a different set of grapes, and among other things, actually suggested that maybe what we need is a new React framework That is owned by the community, and it has like, a steering committee of prominent React community members as like a starting point before we even actually begin any development.
-
-[31:39] And the author actually tagged a whole bunch of people by name on both Twitter and the article, and I was one of the people tagged. So I went in and I wrote a pretty long comment where, you know, I was doing, trying to actually respond to some of the points in the article, but then also saying, look, there is a lot of confusion and miscommunication going on right now.
-
-[32:01] And to be like, to be entirely frank, this has been frustrating for me. I'm, I read discussion. I want people to have meaningful discussion. And, okay, look, fine, it's, it's Twitter, it's, you know, Reddit, it's comment threads, I know too many people talking in too many places for it to be real discussion, but it would be nice if we could at least agree on what we're discussing, and the meta problem right now is that no one is.
-
-[32:25] I have seriously considered writing a 5, 000 word blog post that is just, Here is the definitive list of the 30 different topics the React ecosystem is arguing about right now. Now that we have this list, please continue arguing, just know that you're, here are the specific things that we're discussing.
-
-[32:44] **Carl Vitullo:** At the beginning of the argument, please make sure to enumerate which of these you are arguing about (both laugh). Yeah, yeah, I think the vibes you were talking about, especially in Cassidy's post, is, I think that's very real, but also the vibes are so important and impossible to measure that it's, I don't know, I think she had a really, One of the things that she talks about was it's frustrating that diversity efforts visibly took a backseat with React leadership, and there's just not as many voices from a variety of different people anymore.
-
-[33:13] And, you know, like, how do you, like, what a vibe. That is such a vibe check kind of complaint, and Speaking of vibes, I picked up on a vibe that there were, there was a lot of frustration from within the core team about how the React documentation rewrite went, and yeah, that took a couple of years, and seemed like it really burned out quite a number of people on the core team.
-
-[33:35] And if you are burned out from Social, political aspects of this technical work, then you don't have as much energy to bring to that technical work. So it's like, if there's problems with the vibes, then I don't know what the solution there is, but it feels like it's gonna just have a, like, downstream detriment across the board.
-
-[33:53] **Mark Erikson:** There's a few other good articles and bits of discussion out there. Ryan Florence made a tweet saying he's still very much all in on React as the best way to build apps, but, you know, Remix is working on trying to Have an alternative vision for how do you build a full stack app other than Next?
-
-[34:11] Tom McWright put out a post where he measured the times between React stable releases and noted that the time from 18. 2 until now, is going on a year and a half, I think, and that's the longest we've ever gone between official stable releases of React, and meanwhile you've got Next using Canary builds And so there's definitely frustration over how the versioning strategy is going right now. Andy Bell just put up a post, uh, in the last day or so, saying that React's getting a bit of a kicking lately.
-
-[34:44] So a little bit of the meta commentary there. But it was actually a very well balanced post that said, Look, there's, there are different tools and different trade offs. Certainly the ecosystem, the web dev ecosystem has first swung hard in the direction of Client side rendering and now we're kind of back in a server side thing and where do web components fit in this?
-
-[35:04] But it was actually a pretty decent take some time and think about the trade offs for your situation. In practice, none of this actually necessarily affects you, the individual developer, working on an app for your day job. But there is some value in having a sense of what the big conversation is.
-
-[35:21] Because, honestly, my goal out of all this would be that the React DevRel team does a bunch of work to improve the React docs. I have repeatedly griped that there's a bunch of things that I think should be done in the React docs that I'm shocked that they haven't done yet. If there's anything that comes out of this discussion, I'd like to see a lot of docs improvements.
-
-[35:43] **Carl Vitullo:** All of this conversation, all of this kind of annoyed, where are you going? Increasingly miffed, a bit of a kicking. Last month I went off on a little bit of a rant. I would say in defense of the React core team, like, I think they are truly at the bleeding edge of the web ecosystem.
-
-[36:00] And I think that in a very real way, they have been setting the tone, setting the subject of discussion that everyone else then builds on. And in so many different dimensions, like, Hooks came out of nowhere and invented this new approach to designing an API for web frameworks. Like, nobody else, I can't think of another project and hooks came out that shipped an ESLint plugin as part of using it correctly.
-
-[36:34] Okay, this has enough weird little trade offs of how we've made it work that we need supporting tooling in order to help you. use it correctly, use it well. And now, that's very common. Like, now that's something that, like, Tailwind does. So I, to me, that was something that the core, the React core team introduced to the ecosystem that, as part of API design, you also think about it more holistically, not just, okay, I import this module, what's the function signature?
-
-[37:02] But, okay, I install this package, I import it, what does the error message look like? In my IDE, just a very user centered framing of how to do API design and thinking of what tools are they likely to already use, everything possible to give them the best experience we know how to do.
-
-[37:22] Ryan Florence's tweet, he says, React is still the best rendering library for the web and the people behind it are doing are just doing their best and actually doing a great job. And I think that's extremely true. They are doing a really great job, but what they're trying to do is so advanced and so new that it's just really hard to get every detail of it right. And I think that part of the reason that they are now subject to so much criticism is because of how much they've gotten right in the past, and they've elevated the bar repeatedly, and so now the bar is super high and people have very high expectations.
-
-## RSC updates
-
-- [RSCs: The Good, the Bad, and the Ugly](https://www.mayank.co/blog/react-server-components/)
- - [Leerob reacts](https://www.youtube.com/watch?v=8DyzsSWNcDE)
-- [The Two Reacts](https://overreacted.io/the-two-reacts/)
-- [RSC is React Server + Component](https://bobaekang.com/blog/rsc-is-react-server-plus-component/)
-- [“RSC does not require a server”](https://twitter.com/dan_abramov2/status/1745795274977493317) – Dan
-- [React Server Components paradigm](https://www.telerik.com/blogs/react-server-components-paradigm)
-
-[37:55] **Carl Vitullo:** Should we go on to RSCs? A lot of stuff there. What a month!
-
-[37:59] **Mark Erikson:** Similar to some of the complaints, there was a really good post a few weeks ago called RSCs, the good, the bad, and the ugly. And one thing I appreciated was this was largely focused on technical aspects.
-
-[38:09] Someone tried to use RSCs and gave a bunch of very specific feedback on here's what they're trying to do. Here are some of the pain points I ran into in terms of understanding, like, where do I put the use server versus use client markers? And then, I think there were some additional mentions at the bottom of bigger piece complaints about some of the direction of React and Next, but it was a good article overall, very well written, not Not flame bait, like this was a substantive technical discussion and criticism.
-
-[38:42] Worth reading through that to get a sense of some of the pain points with Next and server components specifically. Which is part of the picture, the issue right now. Is there still really only one real production way to use server components right now. So, Lee Rob, uh, Lee Robinson, who's the primary dev rel.
-
-[39:02] for Vercel and Next did put up a post responding to some of the points that were raised in the Good, Bad, and Ugly post. So, some back and forth there. You can get a, have a chance to compare the thoughts there. Dan Abramov has resumed blogging, and if you've been watching him on Twitter, he has been iterating in public, trying to figure out, like, what is, what are the best analogies and metaphors and tools.
-
-[39:29] To try to get people to wrap their head around server components and the mindset shift that's involved. And in some ways this is kind of frustrating because he is rapid tweeting lots of different ideas, lots of different catchphrases. Server components are like this. Well, server components are like that.
-
-[39:48] And he's been building on some of that and he's got a couple different blog posts up. And I think we probably linked one of them last time where he's building up a series of posts. lead you to think about server components, but he literally hasn't even mentioned the word server component yet. He's been trying to help you understand, where does code run?
-
-[40:10] Sometimes code runs on one computer, sometimes code runs on another computer. What if we had a way to control where that code runs? so he's working up to a metaphor to help people understand the mental model behind server components. And so I know he said that this is turning into an actual blog post series, he's got a few more posts he wants to write, and so this post, the two Reacts, is trying to work towards that train of thought.
-
-[40:41] There was another explainer post from someone else completely. called RSC is React Server Plus Component. One of the other debates on Twitter, and tying into the people are confused or annoyed, is that the term React Server Components is highly confusing, because they don't always have to run on a literal server.
-
-[41:05] Like, not on a web server as we think about it. Like, they can be used at build time and generate static output. They are not strictly a server side rendering concept, and Dan has been frantically trying to make the point that, depending on how you use the technology, like, you could even use it, like, inside of a web worker or something?
-
-[41:27] Like, what, server components really are, like, a pre rendering method that spits out Serialize, React, as JSON. It just so happens that most of the time, and especially with Next, that happens in response to an API request. This blog post is trying to make the argument that rather than saying React Server Components with the implication that it runs on a web server, it's think of your code as like a React Server, React Client split, and the code for React Server could run At anywhere, at any time, depending on the bundler and the system architecture.
-
-[42:09] I realize there's a lot of semantics and technical nuance there, but I thought this was actually one of the better posts. And then there's, again, like I said, Dan has been trying to make the point that they don't require a literal web server. And then there's been a number of other different articles and discussion about this as well.
-
-[42:25] So the mental model and how do you teach server components, I think, is. One of the biggest outstanding questions. And again, I would love to see more of this in the actual docs.
-
-[42:35] **Carl Vitullo:** But, okay, so hopefully this is the putting it out there, ideating phase that then gets brought back in the rough draft, first pass.
-
-[42:45] So hopefully this does get brought back into the documentation as well, but I don't know if that's been I don't know how consistently that's happened over the last year or two. Something about Dan's, the two Reacts posts that stood out to me, I think that he had something really good to say.
-
-[43:00] I mean, just like the opening line of it was, I suppose I want to display something on your screen. Whether I want to display a web page, an interactive web app, or a native app you might download, at least two devices must be involved. Your device and mine. I think that is such a great, useful framing for what they're doing here.
-
-[43:17] Why React server components? It's, there are always at least two machines, the developer's machine, whether that's a local computer that they're running a build on or a server or a serverless function being executed somewhere, and the client machine. There's always a client machine. There's always something else.
-
-[43:38] So because of that, there's always going to be. Communication between those two and so that's my mental model for React server components is they are iterating on what that communication bridge looks like and how to interact with it.
-
-[43:53] **Mark Erikson:** There's been lots of arguments about what would be a better name for server components.
-
-[43:57] People have suggested dozens of different options. My vote would be React serialized components. I think that is the best retrofit for the acronym RSC and I think it's the best explanation technically in terms of what it does rather than the literal word server. You are serializing a component's output.
-
-[44:19] What it does, what happens after that depends on the environment. Maybe you're going to turn it straight into HTML on the server. Maybe you're going to output a file to disk. But ultimately what's happening is there's a pass that serializes the element output and then does something with it.
-
-[44:36] **Carl Vitullo:** Yeah, that actually makes a lot of sense.
-
-[44:38] I don't know if I, I don't know if we want to coin a brand new Well, I don't know if this is coined, but anyway, that's interesting. That's a, that is a good framing for it. Serialized is a little bit more evocative of The benefits and constraints, then server. Of course there's a server. Yeah, okay. That's interesting, I like that.
-
-[44:56] Okay, we're down to our last link, which I guess we'll just go right on
-
-[45:00] **Mark Erikson:** ahead. Yes, so I have been happily highlighting the progress of the React Forget compiler over the last few months. So, there was a blog post in March of last year. Where they said, we're working on it. There were two different conference talks at React India and React Advanced where the React team actually said, we're working on it and here's some of our progress.
-
-[45:20] There was a bit of very interesting discussion on Twitter a couple weeks ago where they talked a bit about some of the technical implementation. So, it is currently implemented as a Babel plugin. Having said that, the Babel plugin is basically just acting as a front end for the actual compiler logic.
-
-[45:41] The compiler itself is currently written in TypeScript, I believe, and not strictly tied to Babel itself. So, there were some thoughts about, I mean, there was some discussion of, well, how fast is it to run? Can you use it for fast refresh? Could it be translated to Rust someday? And one of the other possibilities that came up, Meta has been working on something that they call Static Hermes.
-
-[46:07] Hermes is the JavaScript engine that's used for React Native. It's a completely separate JavaScript implementation. And they've got a research project where they use the Hermes engine to compile your JavaScript or TypeScript code to a native binary. And have seen some interesting early results from that.
-
-[46:29] One other possibility for maybe making the Forget compiler execute faster. Instead of translating it to Rust, maybe they compile the TypeScript code to native with Static Hermes. We'll still know ETA on when this comes out. I have my fingers crossed that we'll see you some more details about it at React Conf in May.
-
-[46:47] But it was interesting to hear a bit more of the technical details of what it's taking to actually build this.
-
-[46:54] **Carl Vitullo:** Yeah, definitely. I have not been following it super closely.
-
-[46:57] **Mark Erikson:** That's why I'm here.
-
-[46:58] **Carl Vitullo:** Yeah, right? Thank you. We can pay attention to slightly different things that overlap and have a great conversation (laughs).
-
-[47:05] Yeah, my general M. O. on a lot of these experimental features is keep an eye out, know what they're called, check in once in a while, and then when they're released, cool, I have a framework for understanding why it exists. Excited to see what comes out of it, but I know this is I don't know. I've seen skepticism that it will be released in a timely manner, though it's not yet.
-
-[47:26] I mean, I'm still catching up on server components, so I just don't have the mental bandwidth to also pay attention to a whole optimizing compiler as well. On to the lightning round. We've got a bunch of links here. I think we should just pick and choose rather than going fully down the list, but
-
-## [⚡ Ryan Carniato, JS Frameworks into 2024](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2024-i3l)
-
-[47:40] **Carl Vitullo:** Ryan Carniato had a solid write up on JavaScript frameworks as we head into 2024.
-
-[47:48] Mark, tell us what that giggle was about.
-
-[47:50] **Mark Erikson:** So he's the author of SolidJS.
-
-[47:52] **Carl Vitullo:** Okay. I did, I, okay. I did not recognize the name. I, sorry, but a lot of talk about signals. And so that makes a lot of sense.
-
-[48:01] **Mark Erikson:** Yeah. Ryan's articles are always excellent. He is so good at. Discussing both technical details and trade offs and nuances. So his posts about what's going on in the front end ecosystem are always worth reading.
-
-## [⚡ RSPack](https://rsbuild.dev/guide/migration/cra)
-
-[48:15] **Mark Erikson:** Next up, so, there's a tool called rsPack, and it is a of Webpack to Rust. Literally, they've implemented all of Webpack's public API in Rust. I think the engineers behind it work at ByteDance, a company that does TikTok.
-
-[48:34] There's a second layer called rsbuild, which is like basically more of an ES builds API, but using rspack as. The implementation layer underneath and I recently saw a tweet suggesting that talking about they've got documentation on how to migrate from create React app to using RS build and I actually had a like my presentation slide tool set.
-
-[49:02] I was using React App with Craco to override the webpack config. And I thought for several years, like, I should switch this over to Vite. But, one, I'm too lazy. Two, that's a rabbit hole. Three, I, my setup uses a webpack plugin in order to parse the markdown that I use to write my slides. And so, I was actually curious about this, and in about one hour, I was able to switch from my CRA setup to using RSBuild, and the compile time went from 30 seconds to one second.
-
-[49:38] I then made it harder on myself and spent and burned like two hours trying to upgrade the version of the MDX markdown syntax that I could use. But that was a separate problem from doing the actual switch. So I know there's a lot of people who are trying to switch from create React app to Vite, and that's absolutely a thing you can do, but you might also want to look at using rsbuild instead, because it's webpack compatible and you might actually have to do less work to switch over.
-
-[50:08] Yeah,
-
-[50:09] **Carl Vitullo:** very cool. Very nice.
-
-## [⚡ Benchmarking React Native styling](https://www.reddit.com/r/reactnative/comments/1adasz4/react_native_cssstylesheet_frameworks_benchmark/)
-
-[50:10] **Carl Vitullo:** I saw a cool post on Reddit. Somebody made a project benchmarking different CSS and stylesheet implementations. It's basically a microbenchmarks list. I don't really know how applicable these are. I don't really know exactly what this would mean from a broader performance.
-
-[50:27] perspective. But, you know, it looked like they put some real work into benchmarking a variety of different approaches in React Native for applying styles, and not sure how much more there is to say on that, though.
-
-## [⚡ Weird things engineers believe about Web development](https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/)
-
-[50:40] **Mark Erikson:** Uh, one article that I really liked, a, an engineer who used to work on the internals of Mozilla Firefox, developing the browser itself, put up a post talking about weird things engineers believe about web development, and it was actually kind of a, here's the stuff that browser engineers think people care about, and then there's the stuff that web developers actually care about, and these are not necessarily the same thing.
-
-[51:04] So, it was just an interesting check on the mindsets of the people using the browsers vs the people building the browsers. I think
-
-[51:14] **Carl Vitullo:** this is a super important read. I think these are, I don't know, there's just this, you get this feedback cycle in knowledge where somebody learned something, they write about it, and then other people learn that from the people who wrote about it. And so you get like a game of telephone going on.
-
-[51:31] So then several, multiple years later, everyone knows all of these things. But if you go back to the actual primary source, some of them are a little warped. Some of them are outright wrong. So this feels like that going back to the primary source. Somebody's up to date on what people claim they know, what the common knowledge is, but they have experience with the actual underlying technology that provides those constraints. So definitely, we recommend reading this.
-
-## [⚡ Tea.xyz](https://twitter.com/mxcl/status/1749894737862025330?s=46&t=uXPe0cHZZfyFyGotvsr9IQ)
-
-[51:59] **Carl Vitullo:** I came across a cool project by the guy who created Homebrew, which is like the de facto dependency manager for macOS. It's like apt for Unix. But, so he is launching an open source software funding project that is I think blockchain based and whatever, so all of the whatever skepticism you have for that is probably warranted, but I'm always interested in new approaches for improving the economic situation of open source maintenance.
-
-[52:32] It is notoriously a very thankless job kind of situation. Yeah, I don't know, Mark, I'm curious if you have any thoughts on this as the only open source maintainer between the two of us. But yeah, it's broadly interesting to me.
-
-[52:45] **Mark Erikson:** I saw this mentioned, I didn't glance at it, so I don't have a lot of thoughts on this tool itself. The flip side is there's another tool in the same sort of space called thanks.
-
-[52:57] dev. One of the complaints about How do we fund open source maintainers has always been the trickle effect. If I provide, if my project uses Jest, ESLint and Webpack and Babel, do I send funds just to those projects? What about all the dependencies those projects are built out of? And so there's been a couple of different attempts over the years to figure out like, how do you divvy this up?
-
-[53:24] And one that I'm actually getting a little bit of something out of is this thanks. dev thing. So, companies like Sentry are donating chunks of money to this intermediary and the intermediary is scanning all the package JSONs and using a particular algorithm to figure out, like, what, what percentage each of the dependencies and sub dependencies that you would actually get, and, you know, full transparency, I'm not getting much out of this, but, you know, like, 15, 20 bucks every now and then, it's okay, it's non zero, okay, cool, thank you.
-
-[53:58] **Carl Vitullo:** I get a similar amount of money from the Medium blogging I did five years ago. It's not nothing, it's not that much. Whether it's enough money to warrant the additional need to remember to add it as income when I file my taxes is debatable.
-
-[54:11] But, yeah, I don't know. It's a hard problem. It's as yet unsolved. I'm always interested in seeing a new approach, trying to solve it. Analyzing package. json and things like that is cool. I kicked around the thought of trying to do a business in this space a number of years ago. Hey, we're Reactiflux. We have so many people donating their time to answering questions.
-
-[54:32] Open source maintainers, but ultimately where I came down on it is it's just so hard to attribute relative value between different projects that like, okay, you can scan thousands, millions of package. json files to understand the dependencies and what depends a lot on this and but then there's also there's so many deep utility functions, deep utility modules that You look at the MP M and they're downloaded like billions of times and it's like that real, is that, should that get the most money outta this?
-
-[55:06] I don't know. When I, when I was doing my own thought exercises and this never left thought land, I never did anything with these thoughts, but when I was thinking about it, it's, I don't know if you can get to the socially understood value versus. Any of the metrics that are available from analyzing dependencies, it seemed like too big of a gulf between the two of them to be obviously valuable to me, but I'm very cool to see anyone who is taking hard problem of open source funding and trying, building code, doing marketing, taking revenue and distributing it back out.
-
-[55:41] Anyone doing that, I will support 100%.
-
-## [⚡ `everything` on npm](https://www.scmagazine.com/news/npm-registry-prank-leaves-developers-unable-to-unpublish-packages)
-
-[55:44] **Mark Erikson:** Yep, and then the last one I got is, there was a recent, I don't know, issue, problem, whatever, with the npm registry, where some folks were experimenting with, Is it possible to make a package that literally depends on every other package in the entire npm registry? And they actually ran into some problems doing this, because there's like a maximum size in your package, or maximum number of dependencies you can have for one package, and what they ended up doing was chunking it up, so the top level package depended on 15, 20 other sub packages, and each of those depended on 5 to 8 packages in all of the npm registry.
-
-[56:26] What this resulted in, though, was it made it impossible to unpublish anything. From the entire NPM registry. Yet another weakness in both how NPM works and how people use NPM. First we had LeftPad, where we found out that unpublishing something dependent on by thousands of other libraries breaks everything.
-
-[56:49] We've had a few other issues over the years, and now this one. It was dealt with, but people continue to find more ways to break NPM.
-
-[56:57] **Carl Vitullo:** Alright, I'm gonna run through a couple here at the very end.
-
-## [⚡ CodePen top 10](https://codepen.io/2023/popular/pens/10)
-
-[57:00] **Carl Vitullo:** I loved this, CodePen put out a Top 10 CodePens of 2023. Love creative coding, love people just making little fun visual things.
-
-[57:10] Just for the joy of it, just to explore a new concept or to make something pretty. Creative coding is not a, an aspect of software development that we have in Reactiflux, had a lot of, people do that in CodePen, people do that in Glitch, people do that in, there's other platforms that are very well suited to it, and we've just never gotten a lot of that energy in Reactiflux.
-
-[57:30] But yeah, really cool, I loved some of these projects, definitely check it out, especially if you're looking for inspiration on a project to work on yourself.
-
-## [⚡ V8 performance improvements](https://v8.dev/blog/holiday-season-2023)
-
-[57:37] **Carl Vitullo:** And last link from me, V8 Performance Improvements. This is, like, extremely nitty gritty, like, close to the metal kind of knowledge. It's probably not going to be very practical in, you know, you as a software developer.
-
-[57:52] But they're adding yet another new level of optimizer, which is interesting. I don't know, I thought it was a good read. It's nice to understand a little bit more about how your code is being executed. There are specific people who will need to know implementation details like that. I know that the, I'm sure that the React core team has done a lot of performance optimization to ensure that the way their code is being interpreted and optimized and the way it runs through these processes results in a as close to optimal performance as possible.
-
-[58:25] I have an affinity for this type of low level post about where our code runs. But yeah, I just thought it was interesting to go through a little bit of history. It's also been 16 years since V8 was released. 16 years since Chrome came out, which is wild. What an era. It's the new era of the web. Definitely check that out if you're interested in bare metal stuff.
-
-[58:48] Thank you so much everyone for joining us. We'll be back on the last Wednesday of February here in the live stage or back in your podcast feed just as soon as we can. If you see anything newsworthy, definitely let us know in the tech reads and news channel of Reactiflux, but yeah, we also check. Quite a range of newsletters and other sources.
-
-[59:08] Mark and I both moderate the React. js subreddit. I love bytes. dev, React Status, ThisWeekInReact. There's close to a dozen sources that I pull links from here. Thanks for joining us. See you next month.
diff --git a/src/transcripts/tmir-2024-02.md b/src/transcripts/tmir-2024-02.md
deleted file mode 100644
index d61aa18..0000000
--- a/src/transcripts/tmir-2024-02.md
+++ /dev/null
@@ -1,446 +0,0 @@
----
-title: "This Month in React, February 2024: React 19 (but more details), Apple tries to kill PWAs"
-date: 2024-02-28
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick hits
- - [[00:25](#layoffs-and-job-market)] [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io job trends](https://trueup.io/job-trend)
- - [[01:46](#new-releases)] New releases
- - [react-email v2](https://resend.com/blog/react-email-2)
- - [Tamagui 1.88](https://github.com/tamagui/tamagui)
- - [Expressive Code](https://expressive-code.com/)
- - [Relay 16.2](https://github.com/facebook/relay/releases/tag/v16.2.0)
- - Remix 2.7 (and 2.6!) discussing later
- - [Isograph 0.1.0](https://isograph.dev/blog/2024/02/15/isograph-0.1.0/)
- - [[03:24](#upcoming-conferences)] Upcoming conferences
- - [React Paris 2024](https://react.paris/) March 22, 2024. In-person in Paris, France + Remote (hybrid)
- - [Epic Web Conf 2024](https://www.epicweb.dev/conf) April 10 - 11, 2024. In-person in Park City, UT, USA
- - [React Miami 2024](https://reactmiami.com/) April 19 - 20, 2024. In-person in Miami, FL, USA
- - [React Connection 2024](https://reactconnection.io/) April 22, 2024. In-person in Paris, France
- - [React Native Connection 2024](https://reactnativeconnection.io/) April 23, 2024. In-person in Paris, France
-- [[05:06](#react-labs-react-19)] [React Labs](https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024)
- - Brad Westfall: [React Will Be Compiled](https://reacttraining.com/blog/react-19-will-be-compiled)
- - [you’ll likely never need these APIs again:](https://twitter.com/acdlite/status/1758229889595977824)
- - [Good writeup from React Training](https://reacttraining.com/blog/react-19-will-be-compiled)
-- [[15:47](#a-pr-for-server-components-support-in-parcel)] React 19: RSCs, Suspense, and Server Actions
- - [Initial PR for Parcel support in RSCs?](https://github.com/facebook/react/pull/28138)
- - [Instant Search Params with React Server Components](https://buildui.com/posts/instant-search-params-with-react-server-components)
- - [Is Suspense Worth the Squeeze?](https://andy-gallagher.com/blog/about-react-suspense/)
- - [Avoid Using React’s `useFormStatus`](https://allanlasser.com/posts/2024-01-26-avoid-using-reacts-useformstatus)
- - [[19:30](#react-strict-dom-package)] [react-strict-dom](https://github.com/facebook/react-strict-dom)
- - [Announcement thread from kelset](https://twitter.com/Kelset/status/1760367655423549480)
- - Builds on [“react dom for native” proposal](https://github.com/react-native-community/discussions-and-proposals/pull/496)
- - [“Spiritual successor to react-native-web but from the opposite direction”](https://twitter.com/dan_abramov2/status/1760245165703184516)
- - [Compatibility chart](https://github.com/facebook/react-strict-dom/blob/main/packages/react-strict-dom/COMPATIBILITY.md)
-- [[25:09](#apple-announce-no-more-pwas)] [No PWAs on iOS in EU](https://developer.apple.com/support/dma-and-apps-in-the-eu)
- - [Action link, if you have an app affected](https://open-web-advocacy.org/apple-attempts-killing-webapps/) (Update, partially rolled back)
- - [MDN PWA Manifest docs](https://developer.mozilla.org/en-US/docs/Web/Manifest)
- - Gary Bernhardt’s [Birth and Death of Javascript talk](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript)
-- [[32:24](#next-app-router-the-good-the-bad-and-the-ugly)] Next
- - [A Next.js App Router Migration: The Good, Bad, and Ugly](https://www.flightcontrol.dev/blog/nextjs-app-router-migration-the-good-bad-and-ugly)
- - [What We’ve Learned from the transition to Next 14 and Server Components](https://medusajs.com/blog/client-server-transition-learnings-nextjs-14-server-components/)
-- [[35:22](#remix-26-27)] Remix
- - [2.6, 2.7 changelog](https://github.com/remix-run/remix/blob/main/CHANGELOG.md)
- - [Open sourced remix.run](https://remix.run/blog/oss-remix-dot-run)
- - [Good first issues](https://github.com/remix-run/remix-website/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
-- [[38:44](#state-of-react-native)] React Native
- - [State of React Native](https://results.stateofreactnative.com/) by Software Mansion
- - [[40:41](#react-native-frameworks-rfc)] [“React Native Frameworks”](https://github.com/react-native-community/discussions-and-proposals/pull/759)
- - [RN on Apple Vision Pro](https://www.callstack.com/blog/announcing-react-native-for-apple-vision-pro)
-- ⚡ Lightning round ⚡
- - [[43:34](#bun-shell-support)] [Bun shell](https://bun.sh/blog/the-bun-shell)
- - [[45:46](#deno-2023-2024)] [Deno in 2023](https://deno.com/blog/deno-in-2023)
- - [Survey results and 2024 roadmap](https://deno.com/blog/2024-survey-results-and-roadmap)
- - [[46:35](#jsrio)] [JSR](https://jsr.io/)
- - [[47:59](#how-hot-module-replacement-works)] [Hot Module Replacement is Easy](https://bjornlu.com/blog/hot-module-replacement-is-easy) (he lies)
- - [[48:33](#pmdrs-webgl-uikit)] [pmdrs WebGL layout engine](https://twitter.com/0xca0a/status/1762069894932160943) UI for react-three-fiber, [full repo](https://github.com/pmndrs/uikit)
- - [[49:25](#updates-from-the-100th-tc39-meeting)] [100th TC39 meeting updates](https://dev.to/hemanth/updates-from-the-100th-tc39-meeting-4j2f)
-
-[00:00] **Carl Vitullo:** Thanks everyone for joining for February's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
-
-I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, the Discord for React professionals.
-
-[00:16] **Mark Erikson:** Hi, I'm Mark Erickson. My day job is working at Replay io, where we're building a true time traveling debugger for JavaScript. And in my free time I do redux stuff.
-
-## Layoffs and job market
-
-[00:25] **Carl Vitullo:** We're gonna start off again, as we have been the last couple times with just some quick hits, layoffs that FYI, it looks like it's peaked, hopefully.
-
-There were just about 15,000 layoffs in February this year, which compares to 34,000 from last month. So that's down a little bit more than half, which seems pretty good. Pattern holds from last year as well, in 2023, numbers for January and February followed about the same pattern of dropping by half. But those numbers were 90,000 and 40,000.
-
-So that's down substantially year, over year, uh, 90,000, January last year to 34,000 january of this year. So that's down like 60%. So that's pretty great. Not out of the woods yet. But definitely comparing to 2023, it's looking a lot less grim.
-
-Here, I found a new resource that looks pretty cool, trueup.io/job- trend. It shows a number of open jobs in tech over time. It's not super clear where these are coming from. So, uh, take it with a grain of salt for sure. Don't know if this includes sales or product roles or if it's just engineering, but it looks like it peaked at 475, 000 jobs in April 2022, uh, down to a low of 163, 000 one year later, April 2023. And back up to about 200, 000. So the creeping back up, seems pretty good.
-
-## New releases
-
-[01:46] **Carl Vitullo:** I'm just going to run through a couple of new releases real quick. We've got React Email v2. Cool. Always a little bit tricky sending email from React. Email is always a pain in the butt, so I love new tools coming out for that.
-
-Tamagui 1. 88, which is a cross platform UI toolkit. The big selling point seems to be that it's seeking parity between web and React Native, which we're going to talk about a lot more later. There's been some cool new developments there. Yeah, they're supporting Expo 50, better types, and they tease a upcoming reduction in generated CSS size. So, seems cool. I know that's a reasonably widely used library. So, cool. New release.
-
-I heard about a cool new project doing syntax highlighting. It looks really good, actually. It's called ExpressiveCode. Definitely check that out if you're doing any sort of project that needs to highlight syntax.
-
-Relay. This is a little bit late, but Relay released version 16. 2. I've never been a big Relay user, so I don't fully understand what changes they just shipped, but if you use Relay, cool. There it is, new version.
-
-And again, something we're going to be talking about later, but Remix released actually two versions, released 2.6 and 2.7. We'll go into a little more depth on that later, but wanted to give it a shout out.
-
-And another, a little bit related, Isograph, which is a new take on doing GraphQL. Just announced a early 0. 1 release. We actually had the maintainer of that, Robert Balicki, on for an Office Hours last week. I think he released this version like an hour before we started the Office Hours event, so that was cool.
-
-## Upcoming Conferences
-
-[03:24] **Carl Vitullo:** All right, moving on from releases, there are a bunch of conferences coming on in the next two months or so.
-
-We've got React Paris, which is going to be March 22nd. It's in person, Paris, France, with a remote option as well.
-
-There is also Epic Web Conf coming out, or that's going to be in April 10th and 11th in person in Park City, Utah. Kent C Dodd's conference. So he always does great stuff. I'm sure this conference is going to be pretty cool.
-
-React Miami coming up April 19th and 20th as well in person in Miami. I went last year. It was really lovely. Reactiflux with a bit of an affiliation in that it's. The React Miami conference is organized by G2I, uh, which is run by Gabe, one of our admins. So definitely check it out. It was really great last year.
-
-There's also another conference in France, React Connection. That's going to be April 22nd, so exactly one month after React Paris. So, you know, great reason to get out to France.
-
-And one more in the next two months is React Native Connection. I guess that's also Same people, next day, also in France. So yeah, man, a lot of stuff going on in Paris.
-
-[04:34] **Mark Erikson:** I will be attending React Miami and then I'm actually speaking at React Connection in Paris. So I'm actually going to be directly, if you look at the timing, React Miami is actually like Friday, Saturday, and then React Connection is the next Monday. So I'm going to be. Going to Miami and then flying directly over there.
-
-[04:53] **Carl Vitullo:** That is going to be fun. We'll see if I can make it to any of the conferences this year. Not sure which ones I'm going to be going to. Yeah, that's all the quick hits we got. So let's go into our main content. Mark, you want to start us off?
-
-## React Labs, React 19
-
-[05:06] **Mark Erikson:** We have some really big news from the actual official React team posted on the actual official React team blog.
-
-They've put up another one of their React labs, what we're working on posts. And it's been 11 months since the previous post in March of 2023. And the good news is that there is a lot of details on what they've been working on, and a lot of pretty big pieces of news.
-
-Most of this is stuff we've actually talked about in previous episode, it's not like most of this is hidden, but it's good to get official confirmation of what they've been up to and where things stand.
-
-[05:40] **Carl Vitullo:** Yeah, you heard it here first, hahaha.
-
-[05:42] **Mark Erikson:** Very true. So, the first and probably the biggest piece of news is that the React team has been working away for the last couple of years on what they previously codenamed as React Forget. And the idea is it's a compiler that will auto optimize the content of your React components.
-
-Now, they talked about it initially at React Conf Online two years ago. They went kind of quiet for a while. They did a couple of talks in React India and React Advanced last fall.
-
-And so the big updates now are that 1. The name has changed. It's no longer React Forget. It's now officially just called React Compiler. And then also that they consider it no longer an experiment, it's effectively production ready.
-
-They are still working to finalize it and get it ready for use and release to the public, but it's a real thing that they effectively consider good enough that it's not just a will this work kind of situation.
-
-[06:50] **Carl Vitullo:** Yeah, and it's good enough that they are using it on Instagram's website right now is what I hear.
-
-[06:56] **Mark Erikson:** Yeah, when they did the talk at React Advanced in October, I believe they said that they were trying it out in production on Instagram Web's profile page, and then some kind of a React Native product page somewhere in Meta's code base.
-
-They might have expanded it to other parts of Instagram since then. I'm not entirely clear if it's being used more broadly than just the one profile page. But it, it, certainly the numbers and the results that they talked about back in October were very good. And they've had another five or, five plus months to try to iterate on this.
-
-Very encouraging to hear that this is progressing forward. Along with that, the React team said that the next official version of React will indeed be React 19. There will not be like an 18. 3 or 18. 4 minor release. I've, I've seen a number of people say that there are bug fixes that they wish would go out in a minor version, just to get them out sooner.
-
-I think I've seen some of the Remix Community talk about some bits and pieces that are in canary builds that they wish were already in a stable build. But certainly what I've seen over the last couple of months had been that they were working towards what they considered to be a React 19 major version, and this blog post confirms that is what they are actually planning.
-
-I do want to talk about the, a couple more bits about the React compiler. The most obvious thing that people will think about is that I don't necessarily need to put in the dependency arrays for things like useMemo and useCallback and maybe even useEffect. Because, you know, as the React team has said since Hooks first came out, if we just have a sufficiently smart compiler, It can figure out what variables you're actually using and fill in the dependency arrays automatically at compile time.
-
-But, the bigger thing, and this is the point that I've tried to make in our last couple discussions, is React has always had some built in optimizations if you memoize the JSX elements that your component returns. And so, the biggest benefit of React Compiler is that it will auto memoize chunks. of the elements that your component returns.
-
-So if your component returns, like, I don't know, three separate divs, and they depend on some combination of four or five different variables, it would auto memoize each of those chunks, so that the element only gets recreated when the input values change. And at that point, React's render optimizations kick in.
-
-And it just skips re rendering those child components, unless they change. You know, React has always had the mental model that we're actually gonna, we're gonna pretend like your entire application just got recreated every time. In practice, what it does is, when a parent component renders, everything inside of that renders by default.
-
-So you can kind of think of React Compiler as flipping that on its head. So that it's not just re rendering all children by default, but only children where their data actually changed. So, in a sense, it's actually kind of taking a common misconception and making that the default behavior.
-
-[10:14] **Carl Vitullo:** Yeah. Always good to if people hold expectations about how something will work, uh, nice to match that.
-
-This is a very high effort way to match people's expectations, but cool that they are confident enough in it working that they're starting to use it themselves on production apps.
-
-[10:31] **Mark Erikson:** And so Brad Westfall from the React training team had, or company, had a good post called React will be compiled, where he goes over some of the implications for that.
-
-Along with that, the React team has always been very big on trying to keep backwards compatibility. You know, you can still even use, you know, the original legacy create class API just as an extended package. React 19 will drop a lot of pieces that have been deprecated for years. They're finally killing StringRefs, they're killing LegacyContext.
-
-And a couple other pieces. Along with that, there's some iteration on how you're intended to use some of the existing functionality. Andrew Clark had a tweet where he's like, You know, we've got a lot of things that have been built in, but with React 19 and the compiler changes, You're actually going to access some of this functionality in a different way.
-
-So, you know, you won't have to worry so much about trying to memoize things. The compiler will take care of it for you. You won't have to use React. forwardRef because now components can just get ref as a prop directly. Apparently you won't need to use React. lazy much anymore. You can just have a promise that represents the component and put the promise directly in your JSX output as a child.
-
-The useContext hook will get replaced by the new use hook that accepts a context directly as an argument. It also will be the replacement for the undocumented but everybody knows about it technique of throwing a promise for triggering suspense. And finally, context objects themselves will now be considered the provider components that you render.
-
-So you can just render angle brackets, myContext. Instead of angle brackets, my context dot provider. Most of those are not huge changes. It's not like it's adding necessarily new functionality, but it is making some existing functionality nicer to work with.
-
-[12:33] **Carl Vitullo:** It really reduces the, you know, surface area of React's APIs quite a lot.
-
-Like, no more UseMemo, UseCallback, or the, you know, React. memo. The number of APIs that React exports is now dropping by like, what, six or seven? It's a lot. That's a lot. That's a lot fewer. Pretty cool.
-
-[12:55] **Mark Erikson:** And then, finally, the blog post talks about a lot of the features that they've been working on, especially in relation to suspense, and server actions, and forms.
-
-And, part of the reason why they came up with this Canary version release concept is they had features that were mostly ready, or close to being ready, and in theory, they were ready enough that frameworks like Next, or Remix, or, you know, something else, could make use of them, but they didn't have all the pieces ready yet, so they couldn't go into a public, stable release.
-
-They've had some of these new, you know, pieces like server actions, or the use optimistic hook, or use form status, available in Canary builds for a while. The key line from this blog post is that they said, the current set of features in React Canary are complete and ready for release. So that's actually a pretty big deal.
-
-One thing that I thought was interesting, which I hadn't really seen talked about anywhere else, and I did not actually understand the first time I read the blog post, React DOM is now going to support rendering metadata tags Anywhere in the component tree. And this means that if you render a title tag or metadata or link, number one, it'll automatically insert those into the head of the document.
-
-And two, you can render those from anywhere, which. As they said, basically replaces the need for a library like React Helmet. I have not had much need to do that myself in my own career, but it's, that's actually a pretty big deal to build in that kind of functionality. And along with that, they're adding support for suspense for things like assets, like script tags and style tags.
-
-So, there's a lot of moving pieces here, and it looks like a lot of this stuff is about ready for release. So that's pretty big news. And my assumption is that React 19 will probably either go final, or at least be in beta plus like a release roadmap at React Conf in May.
-
-[14:59] **Carl Vitullo:** Yeah, that seems like a safe assumption.
-
-They tend to make pretty major announcements at their conferences, so the lack of conferences for the last, what, four or five years? Yeah, definitely seems like Enough pieces have come together that they're comfortable saying like, yes, this is, here we go.
-
-Yeah. And on the React Helmet stuff, that is something I have had to do quite a number of times in my career. And pretty much every time I set up React Helmet, get bit by some bug, some weird quirk in how it works. Look for an alternative, find nothing, and then, you know, begrudgingly make do with whatever weird things React Helmet is doing.
-
-So this seems like a really great small tweak to make the experience of developing a new project in React just that much easier. So pretty excited for that.
-
-## A PR for Server Components support in Parcel
-
-[15:47] **Carl Vitullo:** Cool. All right. Let's talk about React server components, suspense, and server actions. There's a, an initial PR for parcel support for React server components. It looks like React Server Components needs like an external package to do things that I don't really understand because I have not looked at how you implement it from scratch in a framework.
-
-But so it looks like Parcel is now getting that support. So I think that's going to be the second. You know, Bundler that officially supports React server components. So that's, you know, going from one to two, that's a pretty major improvement here. But that's, that's pretty much all I know about it.
-
-[16:25] **Mark Erikson:** Got to have the Bundler build framework integration to actually hook up the pieces and make them do something useful.
-
-[16:30] **Carl Vitullo:** Right, yeah, this crosses a lot of boundaries, and one of the, one of those boundaries is from your app into however that app is being bundled into a production asset. So, do you want to introduce this blog post it looks like?
-
-[16:43] **Mark Erikson:** Yeah, so Sam Selikoff has done some, a couple different blog posts and talks related to how to actually make use of server components in more realistic applications.
-
-I haven't had a chance to go through this post in detail, but I saw Dan retweet it. So it's a discussion of how you would actually use server components and implement logic for things like filtering and displaying pieces and components and pieces of data, primarily based on search parameters. And so it goes through and shows examples of using a lot of the new pieces like some of the form state hooks, server actions, actually being able to control the behavior using suspense.
-
-So it feels like it's a pretty good example of how all the different pieces actually play together in practice. Super cool, yeah.
-
-On the flip side, I also saw a couple articles that are maybe just a little bit skeptical of how to use a couple of these pieces. One was an article called, Is Suspense Worth the Squeeze? And the author basically says, you know, suspense is useful, but in the end, like, showing loading states isn't necessarily, like, The greatest thing in the world. And it feels like, you know, maybe the React team's focus could have been better spent on some other things.
-
-This was at least a little bit more of like a technical set of complaints than some of the articles we've seen recently, where it's just like, I have bad vibes about React. So it's, you know, not necessarily like, you know, a big argument one way or the other, but I thought it was at least a little more of a reasonably technical focused.
-
-Similarly, there was another post called, Avoid using React's new UseFormStatus hook, where the author points out that you can only make use of the hook inside of a form component, and he had some use cases where he wanted to be able to deal with form status outside of the form tag.
-
-I think I also saw some discussion with Dan about this on Twitter, I don't have a link to it. Right this minute, but Dan's reply was that it was something about being able to properly compose pieces of the forms together as to why that limitation exists. So it's good, you know, discussion of, you know, some of the trade offs and understanding the actual limitations of available APIs is important.
-
-[19:01] **Carl Vitullo:** That reminds me of some of the things we've discussed about, like, context dependent APIs that React has started relying on. It seems sort of adjacent to the, you know, use server, use client directives, where you sort of opt into different behaviors in different parts of the tree. So, yeah, definitely having different bits of functionality only available in certain contexts, where it's not always super intuitive what those contexts will be.
-
-Yeah, that's a little bit funky.
-
-## react-strict-dom package
-
-[19:30] **Mark Erikson:** Moving on to the next section. There was another fairly big announcement from Meta within the last month. A new project called React Strict DOM. And this is really about taking React Native and giving it compatibility with web APIs. So let's back up and give a little bit of context on this one.
-
-You know, React Native came out in like 2014. It's, I think it's, it's been a while. Part of the principle of React Native has been, you get to use all the same concepts of React, you know, the components and state and rendering, but because it's targeted to native, and, you know, native could be Android, iOS, or even other platforms like Mac or Windows.
-
-React Native has its own set of abstractions. It doesn't use divs and spans and, you know, lowercase b buttons. It has its own abstractions like a view. And, you know, a view maps to whatever the underlying operating system primitive is for I want to draw a rectangle on screen and do something with it. And so you get to reuse the same concepts that you know from React DOM on the web, but the types of components that you render are completely different.
-
-And so there's been various attempts to make it easier to reuse code across both web and native platforms over the years. And one of the biggest ones was called React Native Web by, created by Nicholas Gallagher, I believe while he was originally at Twitter, and then he eventually left and went to Meta.
-
-React Native Web tried to recreate the names and types of the React Native components, but they rendered to DOM elements. So you would import capital V View from React Native Web in your web app, and you would render it, and on the web it would actually output a div instead. And so the idea is that you would always render a view instead of a div.
-
-And that made your source code compatible with both React Native on native platforms and React on web platforms. And so this is useful, but also had its limits. And so I believe this new project, React Strict DOM, has actually been worked on by Nicholas Gallagher and a bunch of other folks. And it basically takes the opposite approach.
-
-So rather than trying to make, to write web apps Where you're using something that looks like React Native component types. Instead, the goal is to make React Native look and feel more like the web. So they've been working to fill in, you know, various missing pieces of web compatibility behavior. And React Strict DOM gives you tags like HTML. div, and at usage time, those actually turn into a React Native view under the hood. So the idea is, you would now write your React components as if they were web based on both platforms. On the web, of course it outputs an actual div, and on native, it would actually map to a React Native view under the hood.
-
-So the idea is now, let's just pretend we're writing web style code everywhere, and it's just that on React Native it turns into the underlying native view instead. So this is brand new, but it sounds like it is actually being used in production at Meta, and it's gotten to the point where they felt they could open source this.
-
-[23:08] **Carl Vitullo:** I saw a tweet from Dan describing it as a spiritual successor to React Native Web, and like you said, you know, from the opposite direction, which makes a lot of sense. I, it, I have worked on React Native exactly once professionally. I tried to do a couple of side projects that never really got off the ground.
-
-It always struck me as just a little bit weird that like the view to div, you know, they're functionally almost exactly the same. It's just that one doesn't work and, they don't work in each other's contexts. So, trying to unify that just a little bit, trying to get rid of some of those weird edge cases that prevent compatibility from working. Yeah, sounds really cool.
-
-I had been really excited about React Native Web, what, five years ago, six years ago when it was new, but it just never really, never quite fulfilled the promise, the, you know, the vision that it had set out to. So cool to see another take, taking what people already do and making it compatible in the native context seems a lot easier than trying to get everyone to change how they write code to fit better with how React Native is authored. So yeah, pretty excited to see.
-
-Yeah, there was a great announcement thread from Lorenzo Sciandra, Kelset. Who, I think he works on this stuff. He's a senior software engineer at Microsoft working on React Native. Really great thread. Definitely goes into a lot of details, links out to a lot of great resources and RFCs and GitHub issues. So definitely check that out for a lot of details.
-
-There was also a wonderful compatibility chart showing the progress that they're, they've made so far. Look, it's a, it's a little bit rough at the moment. There, there's no green, but a lot of yellow and not too much red. So I think where the red is mostly on the, you know, more fringe side of HTML, although it looks like inputs are not super well supported yet, but I guess inputs are going to be tricky on. Just a little bit more functionality going on there, a little bit more behaviors to replicate.
-
-## Apple announce no more PWAs
-
-[25:09] **Carl Vitullo:** Cool. All right. I guess I'll move us on. This is a bit of a news, I don't know, a broader ecosystem news, but Apple has announced that they are dropping support from, for progressive web apps in response to regulatory challenges in the EU markets. I am pretty disappointed to see this. I had always, I've always been.
-
-Excited about progressive web apps. I love the thought of being able to author web applications in ways that are more meaningfully competitive in terms of user experience in a native context, you know, going back for years, Apple has not meaningfully supported a lot of the deeper functionality that would make this, more meaningfully, you know, work like a native application.
-
-Look, I dug deep on refreshing my memory of how these were, what the original vision for progressive web apps were and how it was meant to unfold. And in like 2014, 15, the Chrome team from Google really put out a lot of effort on doing a cross platform standard for essentially an app store.
-
-If there, you know, if you look at the MDN docs for the progressive web app manifest. It references a lot of things like, you know, screenshots and, you know, install methods. Where does this live? How do you access it? So this ultimately, Apple dropping support for progressive web apps, really it comes out of a series of lawsuits that have, that they, that have been unfolding in Europe around anti competitive behavior in the app store.
-
-You know, it kind of goes back to their 30%, you know, the Apple tax on all purchases in the iOS ecosystem. So, you know, the slightly conspiracy theory minded take on this is that fully supporting progressive web apps would meaningfully cut into their app store dominance. And so they had a strong disincentive from supporting them.
-
-So just, disappointing to see, if you are working on a progressive web app, especially in a European context, there's an advocacy organization called the Open Web Advocacy that is doing a, you know, action. So, if you are based in Europe and maintaining a progressive web application and would be impacted by this, definitely check that out.
-
-Going a little bit more, sort of broadly, back it up into, like, what is a progressive web app, why would this be meaningful? I think there's a lot of overlap there with local first as well. Um, just sort of the general idea of building a website that functions in ways similar to how people expect native applications to work.
-
-So for, like, local first, I think a wonderful example of that is, like, your email client. You know, Gmail on my phone, I can go in airplane mode and I can use it exactly as if I was online. I can archive things, I can recategorize them, I can draft replies, I can send things, and then once I'm back on network, it all works as I expected it to.
-
-So, the original vision for progressive web apps was providing a series of tools and platform features that enable that sort of thing. So, you know, the manifest is a way for web applications to say, these are the files I support. These are the, you know, domains that should open in this app.
-
-Then there's supporting features as well, like service workers. That's how you can provide a programmatic CAF from the web browser context. If they like, okay, if there's no network, here's how to respond. Unfortunately, mostly, it seems like the service workers mostly got used to serve 404 pages that look pretty, which like, okay, yes, that is something you can do with them.
-
-But it would be much more interesting if it would do synchronization of data in the background and queue up updates that you make while you don't have network. So I'm disappointed to see this. I had always been really excited for the potential of progressive web apps. And if this decision by Apple to meaningfully reduce support doesn't get changed, then kind of seems like a, maybe not the final nail in a coffin, but definitely a pretty big nail in the progressive web app coffin.
-
-Very sorry to see.
-
-[29:22] **Mark Erikson:** I haven't read through this in detail, but it seems like some of the claims are about, like, well, if we're, if you're forcing us to support multiple browser engines, we can't guarantee 100 percent perfect security and all the safety guarantees that we want to enforce on our own platform, but frankly, it sounds like, uh, well, if you're not going to let us do what we want, we're going to take our ball and go home.
-
-Kind of a temper tantrum.
-
-[29:44] **Carl Vitullo:** I'd agree with that, generally.
-
-All right in between recording this and publishing it, Apple has announced that they are actually changing tack and will be allowing home-screen web apps as they refer to progressive web apps which honestly is probably a better name.
-
-They're still going to be requiring that progressive web apps be authored in WebKit. So they're not allowing for alternate browser engines to fully integrate progressive web apps on iOS. They're claiming that this is to align with the security and privacy model for native apps. Uh, which to me, I interpret that as they have complete control over how notifications and device access work in iOS, and they're not going to give up any bit of that control to a third party, namely their largest competitor, Google. Apple's also very much in a very real way, hamstrung the way progressive web app notifications function in iOS for years now. They have never really made a serious effort at allowing developers to fine tune the user experience of how notifications are delivered. Which again I take as a subtle indicator that they don't like the operating model of a progressive web app because it is in competition with their other business interests. We're veering out of news and into, you know, I don't know, history, but there was a really great, somewhat satirical talk from 2013, given by Gary Bernhardt, called The Birth and Death of JavaScript, where he takes, it's sort of like a sci fi retrospective of JavaScript.
-
-So, yeah. He, he, he takes the perspective of someone in like 2035 discussing the arc of JavaScript and how it took over the world. And it's actually, it's a really good talk and it really got me excited about the potential for JavaScript in the world. And a lot of that really hit, I think it's very, it was very prescient and I think it got a lot of things very right.
-
-It has a funny bit where he, through the entire talk, pronounces it, "yava" script, uh, which I always found entertaining, but I would recommend that, um, I. Even though it's now 11 years old, um, I think it's, it talks a lot about like WebAssembly and the Browser taking over as the default runtime from the operating system.
-
-Um, it just, it, it, it takes a very broad, interesting perspective on programming and where we write apps and how they run. Definitely really interesting. And yeah, it's from the same guy who did that very famous "wat" talk with. you know, making fun of JavaScript. So definitely, definitely check it out. He's, I think he's been a little bit less active over the last 10 years, but he had a, he was very influential early in my career. So if I can direct any attention his way.
-
-## Next App Router: The Good, the Bad, and the Ugly
-
-[32:24] **Carl Vitullo:** All right, Mark, you want to take us on to talk about Next?
-
-[32:27] **Mark Erikson:** Sure. There were a couple of good articles that came out that discussed different companies attempting to migrate to Next and the Pages router and server components. And it's interesting to kind of look at them and compare and contrast some of the opinions and responses.
-
-So, Flight Control, which is a startup that does a different AWS dashboard, basically, talked about migrating some of their apps over to the app router. They had a number of things they did like. Layout and loading states. And some of the data loading patterns that they were able to use. They also ran into a lot of problems.
-
-They felt that they had to kind of duplicate data fetching code in order to handle live updates on the server. They didn't like issues like lack of routing type safety or some error handling situations. They really struggled a lot with the performance of the development mode server. I saw Brandon Bayer, the founder.
-
-Complaining about this repeatedly on Twitter, and asking, like, what can we do to try to speed this up? And, I know at the time that they were on the Next 13, I think he later said they did switch to Next 14, and it didn't seem to get any better. So, whatever specific problems they were running into with the speed of the dev server and memory usage, They considered those to be really major pain points.
-
-One of the comments in the article was it was marketed as production ready way too early. And it's been, it's a year later and we're still running into all these sorts of issues. So their final conclusion was, we would actually choose Remix if we could have gone back and started over.
-
-There was another article from a company called Medusa where they switched over their own next starter template to use the app router and server components. Medusa is apparently an e commerce framework. Their response, their opinion seems to be fairly positive overall. They thought that, you know, data fetching and caching was pretty good. They liked being able to use server actions to update state on the server. Talked about some different cases like static pre rendering and managing server versus client components.
-
-So they said, you know, it does take some getting used to, but, you know, once you switch over to it, it actually feels pretty natural. So, you know, always good to see some real world examples of people actually train these out in practice.
-
-[34:48] **Carl Vitullo:** Yeah, super cool. I see that Medusa post also talks about moving state to the URL, which I have worked on a couple of apps that did that, where they meaningfully kept application state up to date in the URL as you click around and navigate.
-
-The first time I worked on an app that did that. It just, it blew my mind. It was like, oh my God, every app should do this because then you can share, you can, you know, get the app into a certain state and then send it to somebody and they can, you start using the app from exactly that state. Really interesting concept. So cool to see it discussed in the context of Next 14. Cool. Cool.
-
-## Remix 2.6, 2.7
-
-[35:22] **Carl Vitullo:** I'll move us on to Remix. Like I said earlier, they put out two minor versions. There's 2. 6, which looks like it's mostly a sort of bookkeeping release where they, they made a breaking change to the unstable Vite plugin. So I guess. There you go. There's a minor release necessary to do that.
-
-2.7, they shipped VEET support, so they are now calling their, you know, internal usage of VEET stable, which also unlocks their single page application mode, which is pretty cool. That seems like it makes it meaningfully compete with Well, I don't know.
-
-I don't know. It's interesting to see. I was going to say meaningfully compete with something like Astro or Gatsby, but you know, actually, no, it's not quite that. It's not static generation. It's a single page application. That's a new context. Single page application is still like, I know the enthusiasm for that mode of publishing has dropped off in the last, you know, two or three years, Jamstack and all that kind of stuff has kind of lost mindshare, but it's still the simplest way to ship a web application.
-
-You know, if you're going to be hosting something, putting up static assets and letting it, you know, render entirely in somebody's client browser is lowest cost, lowest number of moving parts way to ship a product. So definitely still has use cases, I think. So cool to see Remix adding support for that.
-
-There was also an interesting feature that I don't quite know if I fully understand, but they called it server bundles, which looks to be support for basically sharding out a backend into multiple servers. So it looks like you can, at build time, communicate to Remix that this part of the backend. needs to be isolated from this other part of the backend.
-
-I could be mis explaining that, so don't take my word as gospel on this. I have not played around with it extensively. They mention that if you make use of this feature, you need to have something in place in front of Remix to direct the traffic and make sure that the correct backend gets, or rather, that the correct bundle gets the requests it expects.
-
-So it seems like, you know, a very niche feature that, like, large teams, large products with a lot of engineers making changes, a lot of performance characteristics to fine tune will need to take advantage of. So that seems cool. You know, one way of, I don't know, dealing with growth.
-
-It also looks to support a React router feature for base names, which is basically just a pre pended route segment. So you can say, this entire web app lives under this part of the path, and then, you know, routing will still work. That is something I have done a couple times in my career, and it has been fiddly every time. So, nice. Good to see.
-
-They also open sourced Remix. run, the, you know, Marketing website for the whole project. So that's pretty cool. They discuss some of the trade offs of, you know, why wouldn't you open source a site like this? Why would you want to? And I guess, why would you want to is basically open source is good and making the website code available is great. Uh, and why wouldn't you want to is sort of vague security risks and, you know, risk of leaking information and things like that. Nice to see the code for the site getting released.
-
-They also put up some good first issues on their, on the GitHub. So if you are looking to bust an open source, there's. There's some options.
-
-## State of React Native
-
-[38:44] **Carl Vitullo:** Moving on to our next set of links. There's been some good stuff coming out for React Native. Software Mansion, who does, they're, they're a consultancy that does a lot of React Native work.
-
-They maintain quite a number of open source projects. I always see them coming up in discussions of new React Native projects. They put out a state of React Native survey, similar to the like state of JS, state of React, state of CSS. But not organized by the same people, just to be clear.
-
-They had like 2, 500 respondents, it looks like. Just going to run through some quick stats here. Like two thirds of those have a higher ed degree, which I was a little surprised by. I thought it would be, as someone without a bachelor's degree, I. Was just surprised to find myself in such a small minority. One sixth of their respondents have no degree at all.
-
-It looks like the median, you know, I, this is a bit of a guess, I didn't have access to the data, so I'm just kind of like looking at percentage respondents. It looks like about the median engineer who responded has two, between two and six years of experience with React Native. Between five and 11 years of experience professionally programming in total, and 95 percent of the respondents were male over half between 25 and 34 years old.
-
-Top three industries represented here, finance, education, entertainment, with below then was consulting, social media, and web three, and. Something I found interesting, the vast majority of respondents, like well over 50%, work on a team with less than five engineers. And one in four people who responded to this survey are solo developers.
-
-So pretty cool to see. Just, I found those, you know, demographic Breakdowns of who is using React Native and how are they using it to be pretty interesting, just macro level. What's going on? But yeah, state of React Native survey definitely has a lot of really cool details that I did not get into. Lots of stuff about usage and opinions and what supporting libraries are being used, what features are being taken advantage of, what aren't. So that was pretty cool.
-
-## React Native Frameworks RFC
-
-[40:41] **Carl Vitullo:** Also a bit on react Native Frameworks. It looks like there was, I was a little bit confused by this, it seems, as I was reading through it, I guess they're more sharply defining the boundary between React Native and Expo.
-
-I'm not sure that there's another Similar framework to Expo. As I was reading it, I was thinking like, Oh, would like React Native web fit into this, would, you know, the React Native Windows, React Native Mac, you know, the VR support and all that, but it looks like they don't. Those are not frameworks by this definition.
-
-So I believe the only framework this is, you know, connected to defining would be Expo. The rest of those are, all of the other runtimes are described as an out of tree platform where, you know, tree there references the Git repo. So React Native. It has first party support for iOS and Android and everything else is an out of tree platform.
-
-So, this is interesting, it just seems like they're being a little bit more thoughtful and proactively communicating about responsibilities, saying, we are responsible for this, and a framework like Expo is responsible for this category of things. So, it seemed like a minor, but significant shift. in how things are, I don't know, defined (chuckles). Seems cool.
-
-[41:59] **Mark Erikson:** That was basically my takeaway. I mean, I think with the general React emphasis on, you should be using React built into a framework and most of the framework's being web focused, I think the React native side of the house was trying to get ahead of the game a little bit and say, Okay, here's what that would look like on our side if anyone else tries to build an RN based framework.
-
-[42:19] **Carl Vitullo:** I'd agree with that. It does seem like a compliment to, like, how Remix and Next are shaping up, but we don't have a sharply defined criteria for what is a framework responsible for in React. So, hey, maybe this is a proof of concept. Maybe we'll see something like that in the web context too. Ha, we can dream.
-
-Cool. One more thing to share on React Native, there is semi official support for. The Vision OS, which is pretty cool. Always cool to see. I'm impressed at how quickly they got that out. I got to say, it looks like they started working on it in June, 2023. They got a group of concept working in like compatibility mode, but that was like super stripped down, like technically it worked, but you could not, you know, the, what it, what behaviors it supported were, the list of that was very short.
-
-So this is now a much more full featured way of writing apps on the Vision OS with React Native. They described it as essentially a fork of the React Native core, which, whoo, that's a lot of work, haha. And something I found pretty cool, pretty impressive, is they got it working without even having access to a hardware device.
-
-So this is all just on the Vision Pro Simulator. Like, wow, that's hard, haha. All right, that's all of the main news items we, we have so far. Mark, take us away with the first lightning round.
-
-## ⚡Bun shell support ⚡
-
-[43:34] **Mark Erikson:** All right. So the Bunn JavaScript runtime has announced that they now have built in shell support. You know, it's always been kind of hard to kick off.
-
-external programs from within a, like a node JavaScript application. Like you can do it, but you have to call, you know, functions that capture standard in, standard out. And it's, it's not really ergonomic or intuitive. So bun now has a built in dollar sign variable. And when you use it, you just pass in like a command that you would have run in a bash shell, like, you know, LS star dot JS, or, you know, the infamous RM dash RF.
-
-And it just automatically executes it and hands back the results as a nice neat async await. I've actually got a little bit of prior experience with something like this. I had used a Python package years ago that did something very similar. So you could write Python scripts that It felt very shell scripty in terms of executing other commands and getting the output back. So I can definitely see some nice advantage of this.
-
-Working with scripting in a language like JavaScript is a lot nicer than dealing with Bash. The issue here is that being able to use commands like ls or rm, assume that you're running inside of a Bash shell. Which normally means that you're running on Linux or Mac, because Windows doesn't have those by default.
-
-A lot of people, like myself, might be using a WSL Linux environment on Windows, or at least the Git Bash version ported to Windows. But they've apparently gone and polyfilled a lot of the common shell commands you would be using, as well. This is not the first attempt to do that. There's an existing library called Shell. js, which provides JavaScript only implementations of common bash commands. I believe the Yarn package manager has already done something similar as well, so that you could, I believe, I haven't looked at this in a while. But I believe if you're using scripts in your package. json, Yarn will automatically fill in some commands like rm or setting environment variables to be cross platform and work on Windows and not just on Linux or Mac.
-
-So there's some prior art here, but it's nice to see this built into Bun.
-
-[45:46] **Carl Vitullo:** Yeah, super cool.
-
-## ⚡Deno 2023, 2024 ⚡
-
-[45:46] **Carl Vitullo:** The Deno team had a pretty cool looking Summary of what they've been up to in 2023. And I'm just going to roll straight into, they also did a blog post about their, they did a survey and announced a bit of a roadmap for 2024.
-
-They're targeting a major release this year, which they say will offer, third party framework compatibility, the ability to use any npm module, and all while having the best in class developer experience.
-
-I love all the explosion of alternate runtimes that we've been getting. I remember watching the Deno talk a couple years ago and just thinking that it was a really interesting take on What did we get wrong in Node?
-
-Deno is from the originator of Node. So he, this is very much a take two on a JavaScript runtime on the server. So I, I've been following him pretty closely just to see what's going on there.
-
-## ⚡JSR.io ⚡
-
-[46:35] **Carl Vitullo:** I guess I'll roll straight into another one that I had queued up for later, but it's closely related.
-
-The Deno team is doing a new JavaScript registry called jsr. io. I just got access to it and it seems pretty neat, I gotta say. For one, it's ESM only, so there's There is no longer going to be a CommonJS option for publishing to this registry, which that alone has me interested. The CommonJS vs.
-
-ESM split has been an absolute nightmare and a huge blight on the JavaScript ecosystem. So, that alone seems like a pretty good reason to try a new registry. It does look like they are starting from scratch. Um, I have I poked around just a little bit, and I don't see any familiar modules published there, but I'm excited to see where it goes.
-
-It's waitlisted right now, so if you are, if that sounds interesting, hop in the waitlist. I got off of it in like two or three weeks, so I have no idea what that means. But yeah, Deno, a lot of stuff going on.
-
-[47:36] **Mark Erikson:** I know I saw an article or two somewhere that was talking about using it.
-
-I think one of the interesting changes is it looks like they actually want you to just publish your TypeScript source code and the registry takes care of doing the compilation, I think, was something I saw. That would be a very significant change.
-
-[47:57] **Carl Vitullo:** Yeah, oh that's super cool.
-
-## ⚡How Hot Module Replacement works⚡
-
-[47:59] **Mark Erikson:** Alright, next up, there was an article talking about how are the hot module replacement feature is actually implemented inside of the Vite bundler.
-
-This is long, it's detailed, frankly this is all information you will never need to know in order to use or build applications. But it's a really good article that actually digs into the technical details of what does it take to implement the, you know, you know, module graphs and swapping and all the specific APIs that actually make hot module reloading possible.
-
-[48:29] **Carl Vitullo:** Yeah, really good post. I love deep dives into obscure parts of the ecosystem.
-
-## ⚡pmdrs WebGL uikit⚡
-
-[48:33] **Carl Vitullo:** Cool. The, the Poimanders, never quite sure how to pronounce that. They shared a fully functional WebGL UI rendering engine. It seems pretty cool, it's basically a layout engine for React 3 Fiber, which is pretty neat. If you're trying to work in WebGL, like that's about as close to bare metal as you can get in the browser from a, you know, like rendering engine side of things, you know, set aside web assembly and whatever you, so, but just like.
-
-Any kind of layout, you don't get any support for. So, pretty interesting to see somebody taking advantage of work done on React Native, actually, because this relies on the Flexbox engine that was built in order to facilitate React Native, the Yoga layout engine. So, super cool, definitely check that out if you are experimenting with WebGL on a side project.
-
-Should make some of these things a little bit easier.
-
-## ⚡Updates from the 100th TC39 meeting⚡
-
-[49:25] **Mark Erikson:** Alright, and the last item on the list is some updates from TC39 as potential new JavaScript syntax features make their way through the pipeline. Not a lot of huge news here, a lot of items at stage 1. There's a proposal called Promise. try, which is basically like a, almost, like a try catch for running any kind of function, sync or async, and getting back a promise for the result.
-
-One other thing that I saw, let me go find the details on this. I believe I saw mentioned that they've actually added a new stage number to the TC39 process. So traditionally it's been like stage 0 is just, we have an idea, stage 1 is we've proposed the idea. Stage 2 is, we, we think this idea could work, but it needs to be fleshed out. Stage 3 is, this basically works, we've got it implemented in a couple browsers, it's just Nailing down the final details and then stage four is it's good to go.
-
-They've actually added a new stage, which is, and this appears to be a real official thing, Stage 2.7 because it's more than stage two, but less than stage three. And I think I actually saw a comment that stage 2.7 is a little bit like what stage three used to be and now stage three is slightly more involved. This actually appears to be a real Thing.
-
-[50:46] **Carl Vitullo:** I love that. It's more than halfway, but. Cool.
-
-Alright, that's all we got. Thank you so much for joining us. We'll be back on the last Wednesday of the month here in the live stage of Reactiflux or back in your podcast feed just as soon as we can.
-
-We gather sources from all sorts of newsletters like React Status, bytes.dev, Next JS Weekly, React Digest, This Week in React, love that one, as well as like the React JS subreddit, here in Reactiflux. We do check the #tech-reads-and-news channel. So definitely if you see any news coming out, let us know. Put it in that #tech-reads-and-news channel, or if you like, you can send it to hello@reactiflux.Com. But make sure to include TMIR in the subject line. It's an acronym for the show.
-
-And we are starting to professionalize. We're trying to grow and find some sponsors. So if this is a show that you get value from and want to support, best way to do so is by giving us a review or telling your friends about it.
-
-Thanks so much. Excited to see what happens in March. Bye all.
diff --git a/src/transcripts/tmir-2024-03.md b/src/transcripts/tmir-2024-03.md
deleted file mode 100644
index 57461a9..0000000
--- a/src/transcripts/tmir-2024-03.md
+++ /dev/null
@@ -1,495 +0,0 @@
----
-title: "This Month in React, March 2024: React canary is 19, New ShadCN bits, Astro looks like Wordpress. Wiz??"
-date: 2024-03-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick Hits
- - [[00:39](#layoffs-seems-better)] [Layoffs.fyi](https://layoffs.fyi/)
- - [[01:20](#new-releases)] New releases
- - [React Native 0.74.0?](https://github.com/facebook/react-native/releases) Soon
- - [New Architecture docs page](https://reactnative.dev/docs/the-new-architecture/landing-page)
- - [TS 5.4](https://devblogs.microsoft.com/typescript/announcing-typescript-5-4/)
- - [“This is how most dependency injection in React apps should be done”](https://twitter.com/sebmarkbage/status/1765828741500981475) says Sebastian Markbåge
- - [Remix 2.8](https://github.com/remix-run/remix/blob/main/CHANGELOG.md#v280)
- - [Mantine v7.7.0](https://mantine.dev/changelog/7-7-0/)
- - [Rsbuild 0.5](https://rsbuild.dev/community/releases/v0-5)
- - [Gleam version 1](https://gleam.run/news/gleam-version-1/)
- - [[05:58](#shadcn-march-2024-update)] [ShadCN March 2024 update](https://ui.shadcn.com/docs/changelog)
- - [[06:55](#astro-45-astrodb)] [Astro 4.5](https://astro.build/blog/astro-450/)
- - [Astro DB](https://astro.build/blog/astro-db/), [Astro DB Deep Dive](https://astro.build/blog/astro-db-deep-dive/)
-- [[09:58](#upcoming-conferences)] [Upcoming conferences](https://react.dev/community/conferences)
- - [Epic Web Conf 2024](https://www.epicweb.dev/conf) April 10 - 11; Park City, UT, USA
- - [React Miami 2024](https://reactmiami.com/) April 19 - 20; Miami, FL, USA
- - $50 off a ticket: `reactiflux4ever`
- - [React Connection 2024](https://reactconnection.io/) April 22; Paris, France
- - [React Native Connection 2024](https://reactnativeconnection.io/) April 23; Paris, France
- - [Post/Con 2024](https://www.postman.com/) April 30 - May 1; SF, CA, USA
- - [React Conf 2024](https://conf.react.dev/) May 15 - 16; Henderson, NV, USA
- - [App.js Conf 2024](https://appjs.co/) May 22 - 24; Kraków, Poland
- - [Local First Conf 2024](https://www.localfirstconf.com/) May 30; Berlin, Germany
-- [[10:58](#react-19-and-react-compiler)] React 19 and React Compiler
- - [Feature flags PR - “Canary now represents React 19”](https://github.com/facebook/react/pull/28647)
- - [React 19 won’t include Compiler](https://twitter.com/en_JS/status/1760433969118769654)
- - [React Compiler & React 19 - forget about memoization soon?](https://developerway.com/posts/react-compiler-soon)
- - [“Compiler Theory and Reactivity”](https://www.recompiled.dev/blog/ssa/) and [“Type System”](https://www.recompiled.dev/blog/type-system/)
- - [Its-fine](https://twitter.com/0xca0a/status/1766032105807483261)
- - [sebmck and drcmda GitHub exchange](https://github.com/facebook/react/pull/28524#issuecomment-1992607052)
-- [[20:02](#react-strict-dom-why-is-it-so-great?)] ["react-strict-dom", why it's so great?](https://szymonrybczak.dev/blog/react-strict-dom)
-- [[23:42](#server-components-updates)] RSCs
- - [Conceptual Model of React and RSC](https://ondrejvelisek.github.io/conceptual-model-of-react-and-rsc/) Ondrej Velisek
- - [Why React Server Components Are Breaking Builds to Win Tomorrow](https://www.builder.io/blog/why-react-server-components) Vishwas Gopinath
- - [Waku has released a “pages router”](https://waku.gg/blog/introducing-pages-router)
- - Lee Robinson’s [List of projects experimenting with RSCs](https://twitter.com/leeerob/status/1772651496544317804) , including Redwood ([which just released an RSC beta](https://redwoodjs.com/blog/rsc-now-in-redwoodjs))
- - [Embracing the Future and Moving Back Again: From Server Actions to tRPC](https://documenso.com/blog/removing-server-actions)
-- [[29:06](#apple-walks-back-on-pwas-neat-safari-features)] [Webkit features in Safari 17.4](https://webkit.org/blog/15063/webkit-features-in-safari-17-4/)
-- [[33:05](#mental-health-in-open-source)] [Mental Health in Open Source](https://antfu.me/posts/mental-health-oss)
-- [[37:20](#angular-meet-wiz)] [Angular codebase is being merged with Wiz](https://twitter.com/sarah_edo/status/1770478763253379488?t=zbCMEoxUsXuLGYtqt3ik8w&s=19)
- - [Announced at NGConf 2024](https://youtu.be/nIBseTi6RVk?t=1869)
- - [[38:49](#designing-very-large-javascript-applications)] [Designing Very Large Javascript Applications](https://www.industrialempathy.com/posts/designing-very-large-javascript-applications/)
- - [Malte Ube discussed in 2018](https://twitter.com/cramforce/status/958696304149868545?t=ETSaJnj2aX9Dnw_yPXgWBA&s=19)
-- ⚡Lightning round ⚡
- - [[43:56](#interaction-to-next-paint-new-core-web-vital)] [Interaction to Next Paint (INP) is a Core Web Vital](https://web.dev/blog/inp-cwv-launch)
- - [What is INP and why you should care](https://blog.sentry.io/what-is-inp/)
- - [[44:56](#rspack-charts-a-path-to-10)] [Rsbuild 1.0 release plan](https://github.com/web-infra-dev/rsbuild/discussions/1678)
- - [[45:42](#remix-might-merge-react-router-in)] [React Router and Remix to be merged?](https://twitter.com/ryanflorence/status/1767560366027129211)
- - [[46:08](#declarative-shadow-dom-in-all-major-browsers)] [Declarative Shadow DOM available in all major browsers](https://www.mayank.co/blog/declarative-shadow-dom-guide)
- - [[47:05](#react-native-community-map)] [React Native community map](https://github.com/kelset/react-native-community-map)
- - [[47:34](#nodejs-2023-year-in-review)] [Node.js 2023 Year in An Article](https://blog.rafaelgss.dev/nodejs-2023-year-in-review)
- - [[48:57](#tailwind-preview-of-40)] [Open-sourcing our progress on Tailwind CSS v4.0](https://tailwindcss.com/blog/tailwindcss-v4-alpha)
- - [[49:26](#vercel-adds-remix+vite-support)] [Vercel adds support for Remix+Vite](https://vercel.com/changelog/support-for-remix-with-vite)
- - [[50:05](#navigating-the-future-of-frontend)] [Navigating the future of frontend](https://frontendmastery.com/posts/navigating-the-future-of-frontend/)
-
-[00:00] **Carl Vitullo:** Thanks for joining us for March's This Month in React! Coming to you live from Reactiflux, the Discord for React professionals. I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux.
-
-[00:13] **Mark Erikson:** Hi, I'm Mark Erikson. My day job, I work at Replay. io, where we're building a time traveling debugger for JavaScript, and outside of that, I do Redux stuff.
-
-[00:22] **Carl Vitullo:** We got a lot of good stuff to discuss and digest here. Lot more details coming out for React 19. We got TypeScript 5. 4, and lots of interesting stuff kind of at the margins. Not really core tools or libraries within React necessarily, but a lot of things all over the place.
-
-## Layoffs (seems better!)
-
-[00:39] **Carl Vitullo:** I'm going to start off with some layoffs news. At time of recording, you know, it's the 27th, so we'll have to see if anything else happens, but layoffs.fyi is showing 33 companies with layoffs, which is the fewest layoffs by count in that way in close to two years, since April 2022. So nice to see that number go down.
-
-[00:58] This month has about 7, 200 laid off so far, which is on the lower end, it's not the lowest of the last year, but it's towards the lower end of the average range. Last March, so one year ago, there were 122 layoffs with about 38, 000 affected. So, 33 layoffs with about 7, 000 affected is a large decline, so that's nice. That's pretty good.
-
-## New releases
-
-[01:20] On to some new releases. We have a pretty big list this month.
-
-[01:23] **Carl Vitullo:** We've got some news from React Native. They are going to be putting out a 0. 74 release soon. They've had a really cool post up , or I guess like a docs page, talking about their new architecture. Not a ton of super concrete items coming out in there. But they did talk a lot about the general new architecture, re architecting how React Native works. We're going to talk a little bit about some of that, too, later on, talking about React Strict DOM, that package that they released last month.
-
-[01:53] Moving on a bit, TypeScript 5. 4, sounds like it's not a huge release, but One thing that I thought was super notable, worth taking note of, they are recommending against using the compiler options paths configuration flag in favor of package. json imports. Since you use the paths for import aliases, moving that out of a TypeScript specific configuration option and into a general module configuration option I think is absolutely phenomenal.
-
-[02:23] Getting that standardized I think is going to simplify a lot of things.
-
-[02:26] **Mark Erikson:** It's particularly interesting because I've seen other tools actually start to use TypeScript's own paths option as the source of truth. So, I guess, you know, switching over to a package. json setup is making it more tool agnostic, in a way, but the question as always is, how long will it take for other tools to also support that kind of configuration?
-
-[02:47] **Carl Vitullo:** I am just excited to see something go out from, I don't know, kind of move from TypeScript into standards, but yeah, generally seems like a quieter release.
-
-[02:56] NoInfer is one of the biggest things they called out and sounds like it's mostly useful in library contexts. Mark, you did point out something coming up in 5. 5 that looks really interesting though, you want to introduce that?
-
-[03:10] **Mark Erikson:** TypeScript has the idea of, I'm always a little hazy on the terminology, typeguards or predicates, which are functions that take some object and you assert at the type level that if the function returns true, then the type of the value must be this thing.
-
-[03:25] And so it's a way to mix together control flow and telling TypeScript what a thing looks like at compile time. And the problem is that when you do an operation like array filtering, that has not actually done the type narrowing that you might expect. So, you might be filtering to ensure that, you know, the returned array only contains real values and removes null or undefined, but TypeScript wouldn't actually pick up on that so far.
-
-[03:51] And so you might have to do, like, an extra cast or some other check to make sure that the output array has the correct type. Well, TypeScript 5. 5, which should be out in a few months, actually now has a PR merged that uses TypeScript's existing inference in new ways inside of filter functions so that you can do normal logic when filtering and TypeScript will try to narrow down the returned array type based on the logic in the filter callback.
-
-[04:18] It's not a huge deal, but it's gonna be a nice little quality of life thing. And then I also saw a tweet mentioning that the TypeScript team is continuing to do work on the publishing process to try to shrink the install size. I think as of, like, TS 4. 9. Installing TypeScript was around 50 megs. They did a lot of work with TS 5. 0 to change their internal setup, which dropped it to like 30. And it looks like as of 5. 5, it might be down to 20 ish or so. So, you know, hey, smaller install size, always a good thing.
-
-[04:50] **Carl Vitullo:** Much, much later, I'm going to talk a little bit about a Node. js 2023 year in review, and that has the opposite trend. It has a chart in there showing the binary size for the Linux binary for Node. js, and it is much, much larger than it used to be. So, good to see that TypeScript is going the other direction. Maybe they can cancel each other out a little bit.
-
-[05:09] I'm just going to run through a bunch of other releases pretty quick.
-
-[05:12] Remix released 2. 8. Looks like it's just a bunch of minor changes, configuration stuff.
-
-[05:17] Mantine has 7. 7 out. I didn't see any changes in there that really jumped out to me. It looks like a bunch of new components, a couple new hooks. useStateHistory looks neat, undo is always a challenge.
-
-[05:29] RSBuild released a version, 0. 5, which they say it's most of a 1. 0 release that will happen approximately in Q3 of this year, but it'll be much, much later this year.
-
-[05:40] I saw a cool fringe language inspired by Elm. Gleam, released a version 1. First stable release of a new experimental language. I always need to see how people play around with different languages. It says it's inspired by languages such as Elm, OCaml, and Rust. Experimental languages. Lots of stuff going on there.
-
-## ShadCN March 2024 update
-
-[05:58] **Carl Vitullo:** Okay, here's another big one. We've got some ShadCN new updates. They put out a March 2024 update, which is the first time they have done one of these update posts since I think December. So definitely worth calling out. It looks like the single biggest new thing that they have is blocks, they call it.
-
-[06:15] Which looks like it's basically template pages for very common and like very low differentiation application pages like a settings UI, or two factor, an authentication page, some other things like that, so it's basically just, copy these out, use it yourself. It looks neat. It looks exactly like every instance of those pages that I've done many times over my career.
-
-[06:36] So having a nice copy paste target for that is, seems super helpful. They also had one for an input one time password, like the classic, you know, paste in these six digits and it will appear in nice pretty blocks. Again, something I've implemented many times and there's never any variation, but for some reason you can never use the last one you did, so nice to see that.
-
-## Astro 4.5, AstroDB
-
-[06:55] **Carl Vitullo:** One more big one here that I'm just going to kind of blast through because I find it interesting. So Astro, the static site generator, I guess. I don't know if that's quite accurate, but.
-
-[07:05] **Mark Erikson:** Close enough for now.
-
-[07:07] **Carl Vitullo:** They released 4. 5, improved developer experience, a dev audit UI for site performance and accessibility issues, which is cool. They are announcing that they're offering a hosted database in conjunction with their site generation, the site building tool. They're calling it "the database platform for content driven websites" and also describe it as "Astro DB is a fully managed SQL database designed exclusively for Astro." it's got Drizzle built in and uses LibSQL.
-
-[07:37] Apparently Lib SQL is a fork of SQLite, which, they posted a deep dive that goes into a lot of the sort of the history and how this whole thing unfolded. And they talk about trying to make it work spring of last year with SQLite, but they ran into constraints with the fact that SQLite relies on compiled components within it, the C native code produced performance constraints that didn't really work very well within serverless environments. So they then tried again with this fork of SQLite that does not use those same native compiled, subcomponents within it. that's super cool, I think this is neat.
-
-[08:11] It sounds like they're very much positioning themselves as a WordPress competitor. So it's, you know, content driven websites with an included database. Like, that sounds like WordPress to me. So I think that's pretty cool. Astro's been doing a lot of things, this really does seem like a substantial change to the core offering.
-
-[08:29] **Mark Erikson:** And purely from a technical perspective, it is interesting to see that there's been a number of tools and services that are being built using SQLite as more than just like a local datastore as of late.
-
-[08:40] I think Cloudflare Durable Objects, are built on SQLite. You've got this AstroDB, I think I've seen a couple other tools as well. A lot of tools that are basing themselves around SQLite in some way.
-
-[08:52] **Carl Vitullo:** Yeah, definitely. I read a really good blog post talking about why SQLite makes sense in a lot more contexts than we've generally given it credit for.
-
-[09:01] And, yeah, it seems like people are really experimenting in real meaningful ways with different places to use it, which I think is awesome. I think it's a great project. You know, co locate your database with your executing code because it's small and fast, keep it a single binary.
-
-[09:15] Yeah, this is not quite directly related, but while we're talking about databases, I also heard about, PGLite, which is a Postgres implementation packaged as a WASM module, which, that's neat.
-
-[09:27] It's not quite SQLite, but if you need a database in your browser app, it seems like a cool new option.
-
-[09:34] **Mark Erikson:** There's probably also some kind of application for, I don't know, running end to end tests in the back end with that as like an in memory database or something like that?
-
-[09:43] **Carl Vitullo:** Yeah, that's actually, that blog post I mentioned about SQLite, that was one of the things that they've said that SQLite has been relegated to just being like the test database because it's, you know, super fast and, you know, super easy to spin up. So, yeah. Definitely makes sense in those sorts of contexts.
-
-## Upcoming conferences
-
-[09:58] **Carl Vitullo:** Blasting through conferences.
-
-[09:59] Epic Web is coming up April 10th and 11th in Park City, Utah.
-
-[10:03] React Miami, Mark and I will both be there, is April 19th. We actually have a discount code. So if you are interested in going to React Miami, make sure to, one, get your ticket soon, cause it's in like three weeks, and get your ticket with the code REACTIFLUX4EVER with number 4.
-
-[10:21] Very much looking forward to that though. There's React Connection and React Native Connection on April 22nd and 23rd in Paris.
-
-[10:27] **Mark Erikson:** And I will be speaking there going straight from Miami.
-
-[10:30] **Carl Vitullo:** Haa, wonderful, yeah, 20th to 22nd, that's a quick turn for an international flight across the Atlantic.
-
-[10:36] There's PostCon April 30th and May 1st. That's from Postman. So they're doing like an API conference, they're calling it.
-
-[10:42] And then the big one, React Conf, is happening May 15th and 16th in Henderson, Nevada, just outside Las Vegas. Cool.
-
-[10:50] Alright, whew, we finally made it to the main bulk of the content. Yeah, Mark, you want to take us off with our first set of discussions?
-
-## React 19 and React Compiler
-
-[10:58] **Mark Erikson:** Alright, so there's a number of pieces of news around React 19 and the React compiler tool that was announced a couple months ago. So first off, I saw a PR go up just a day or so ago. React's codebase has lots of feature flags because they build React for many different use cases. There's internal Facebook builds, public open source builds, React Native builds, experimental builds, canary builds, lots of different combinations.
-
-[11:23] And so the React team is constantly adding new feature flags, altering the feature flags, changing the default value. And so this PR makes it sound as though what's in Canary right now is what's expected to go into React 19. So that sounds like a, you know, fairly meaningful step towards a potential React 19 release.
-
-[11:43] Also, if you've just been keeping an eye on the list of pull requests in the repository, there have been a ton of internal cleanup PRs where they've been changing over a lot of the existing tests to actually use some of the more modern React APIs, like, uh, React on client slash render, instead of the old React render, et cetera.
-
-[12:01] One thing that wasn't entirely clear from the React labs blog post in February is that React 19 and React compiler are not directly tied together. They're both things that are in progress, but React compiler is a separate project. And it probably will come out sometime after React 19 is released. So, different projects, separate schedules, but still both very much in flight.
-
-[12:29] Speaking of React Compiler, there's been a couple good posts discussing how it works and what practical effects it'll have. Nadia Makarevich has done multiple great blog posts about React rendering somewhat similar to the post that I had written a while back. And she put up a post talking about React 19 and React Compiler and, you know, some of the practical benefits like not having to write code that does a lot of your own memoization logic because the compiler will do it for you and it will help with rendering performance.
-
-[12:59] And then, Satya, who is on the actual React compiler team, and has popped in and hung around Reactiflux a decent amount, put up a couple really good posts talking about the internal implementation details of the compiler itself. The compiler is currently exposed to the world as a Babel plugin, but that's more for ease of integration with the existing build tool ecosystem.
-
-[13:24] The way I understand it is that the Babel plugin basically acts as just kind of like an outer shell and then all the real logic is like a full blown compiler from scratch that the Babel plugin kind of forwards everything to.
-
-[13:38] So, you know, perhaps at first to make use of it. You would need to have Babel set up, but with the way they've got it designed, they would eventually be able to, you know, maybe expose it as, you know, an SWC plugin, or its own standalone tool, or something like that. Also, sort of tied to React 19, there was, I don't know, maybe controversy is a little strong, but kerfluffle? Annoyance? Frustration back and forth?
-
-[14:03] **Carl Vitullo:** A joke that didn't land.
-
-[14:04] **Mark Erikson:** Yeah. So, a little bit of background. The React Three Fiber ecosystem is pretty large. uh, DRCMDA, however you pronounce his username, uh, I think his name's Paul Henschel, and a bunch of other folks have done some amazing work over the last few years to create a React renderer that wraps the three.js 3D WebGL library so that you can write React components that render full blown 3D scenes and control them. And while I have not played with this myself, I've seen lots of examples and snippets and videos of some incredibly impressive demos and apps and tools that they've built over the last few years.
-
-[14:44] Now, one issue is that React three fiber is its own separate React renderer different from React DOM. Like, they both have their own copies of React's core logic embedded in them. And React has a limitation that different renderers in the same program don't actually know about each other. And so, if you think about a typical web app, you're probably using React DOM to render the outer page, and then you might be using React Three Fiber to render, you know, like a 3D animated scene or a game or something inside of the page.
-
-[15:22] And the problem is that if you try to render a context provider, In, like, React DOM, React Three Fiber will not see it, because they are effectively totally separate worlds that just happen to be nested in each other. And so, there was a PR, there was an issue request all the way back in 2019, where some folks like the React Three Fiber people were asking, " Can React add a way to try to share context?"
-
-[15:48] between renderers. And that PR has been open for a long time, er, issue, and nothing's happened with it. So, the React Three Fiber folks ended up writing a very intentionally hacky package called `its-fine`, which, you know, references that goofy little, like, dog in the fire meme. It very intentionally reaches into React's internals and accesses fields that you're not supposed to be able to grab context instances from.
-
-[16:15] And pass them across the renderer boundary so that you could have like your context provider with user data or something at the top of the whole application and both React DOM and React Three Fiber could read from it. Well, a few weeks ago, Sebastien Mårkbage from the React team put up a tweet where he linked to the dependents of the it's fine package and said, " yeah, this is a list of Packages and tools that will break in React 19," which is fair.
-
-[16:41] I mean, it's a package that intentionally reaches into React's internals. You have to expect that there's going to be breakage. So that's a very legitimate observation.
-
-[16:50] But then it kind of went off the rails a little bit. Another one of the React team members, Rick Hanlon, actually posted a PR in the React repo that he labeled, " it's not fine," and that PR literally just looks for the existence of the it's fine package in your project and throws an error if it's detected. Now, while he didn't explicitly say it in the initial version of the PR, it was obvious this was a joke and it was never going to be merged. But, I'll be honest, speaking personally, I found that joke to be in very bad taste.
-
-[17:23] To me, as a library maintainer, if people are writing code in a way that reaches into my own library's internals, that usually says to me that there's some use case that I haven't considered that I ought to at least think about trying to handle. and make a public API for. As an example, with React Redux, up through version 5, used the old style React context system.
-
-[17:50] And everybody knew that you could reach in and grab the Redux store by accessing `this.context.store`, but it was never part of our public API. And so when we switched over to the new context API in version 6, Number one, all those old usages broke. And number two, we actually publicly added a useStore hook, that, you know, just grabs the store off of new context and returns it. And so it's not something we recommend using, but it's a thing people sometimes had a reason to do. And so we provided an API to do it.
-
-[18:26] So my stance as a maintainer and a community person here is that, number one, the joke PR was a bad idea. The React team has had enough issues with marketing and PR and DevRel.
-
-[18:39] Mistakes in the last few years and this really did not help the situation. And number two, you know, making the original observation that, hey, these things are going to break is fine, but maybe instead of making a joke, Pierre saying, "haha, we're going to ban this package", maybe you should be trying to address the legitimate request for a way to use React that does not officially work right now.
-
-[19:02] **Carl Vitullo:** It looks like this did turn into that as well. In a reply on that, you know, joke PR, Sebastien Mårkbage did come in with some like real analysis on, you know, he said, I spent some time investigation or investigating. "The proper solution behaves like a portal should forward the value during a concurrent render into the child."
-
-[19:26] Yeah, it's, it basically, it sounds like what he was saying is, " it's tough, it would require some adjustment to these other guarantees that we make, will take a fair amount of time to evaluate whether this is going to be actually possible. It's not our top priority because of the bit of a fringe need."
-
-[19:42] Which, all very fair. So I'm glad this did come back and get some, like, real technical back and forth. it just felt like it felt a little bit like targeted and kind of mean spirited. So, you know, glad it came back and had some more meaningful discussion about the problem and what the right solution—
-
-[20:00] **Mark Erikson:** the technical feasibility aspect of it. Yeah.
-
-## React Strict DOM, Why is it so Great?
-
-[20:02] **Carl Vitullo:** Yeah, most definitely.
-
-[20:04] Next one, there was a really great post called, React Strict DOM, Why is it so great? From Syzmon Rybczak? I am so sorry if I'm murdering that, but, interestingly, he, he claims to be 17 and working at Callstack. So, wow, cool. This is a great post flat out. And this is a phenomenal post for a 17 year old developer. Like, wow, cool. Somebody to keep an eye on.
-
-[20:24] But, talking about, React Strict DOM, and, sort of the, Technical background of where it came from and contrasting it with React Native for web. Actually, as I was reading this, it reminded me of some of the discussion we've had, but this is a really great long form write up of, that hits a lot of the same notes that we discussed previously, but with added benefit of pretty great technical diagrams made with Excalidraw . Yeah, definitely good to check out.
-
-[20:52] It talks about how React Native Web is It's ultimately a shim that offers compatibility with the React Native API, which the big downside of that is because of the approach it took, it is necessarily a relatively large shim, and adding A large core package to a web app, just it, it inflates the bundle significantly, more significantly than not using it, which is just the extra friction, which makes it just that much harder to get adoption.
-
-[21:23] And since React Native Web didn't really get adoption. So the React strict DOM approach sort of comes at it backwards, where it takes web APIs to render components out and, because it is taking such a different approach to a similar problem, it is able to keep the size of this shim, this compatibility layer, much, much smaller.
-
-[21:44] So it looks like the core of it is coming from these two CSS and HTML exports from the ReactStrict DOM package, and those are how React Native would then understand how to handle these UI primitives.
-
-[21:59] **Mark Erikson:** Yeah, another way to put it is that the React Native web package gave you what looked like React Native components, so you would write your web code as if it were targeting React Native.
-
-[22:12] With React Script Dom, it's flipped, so that you're You write React Native code as if you were targeting the web, and so you write, you know, your components return a, quote, div on both platforms, but now with React Strict DOM, what you said was a div on native actually becomes a React Native view instead.
-
-[22:33] **Carl Vitullo:** Yes. Thank you for that. I guess I didn't realize that the React Strict DOM package is built on StyleX? Like it looks like that is very core to what is enabling this, I guess? I know you have explained StyleX to me at least once before and I just don't have a, it doesn't, it didn't stick in my brain.
-
-[22:50] **Mark Erikson:** As usual, I've only glanced at it myself.
-
-[22:52] It is yet another CSS in JS type tool. It was developed internally at Meta, like many of the other tools that they've put out there. As I understand it, some of the defining features are it's more of a compile time tool instead of runtime. And I believe it compiles down to more of an atomic CSS setup so that it.
-
-[23:14] Like over time, the amount of extra styles that get generated stay pretty limited because, you know, like everywhere you use like a certain margin size or something that only ultimately adds one rule to the code base.
-
-[23:28] **Carl Vitullo:** It's definitely similar ish to the like compiler for the Tailwind compiler works ish, but operating on a different set of, uh, underlying primitives.
-
-[23:37] Very interesting. Didn't realize that it was so connected to React strict DOM. So that's pretty cool.
-
-## Server Components updates
-
-[23:42] **Mark Erikson:** Moving right along, we have a few different articles and bits of information related to server components. There was A couple articles that discussed kind of like some of the philosophical or conceptual model of React and server components.
-
-[23:57] There was one article in particular that tried to go back to React's, early selling point of your UI is a function of state. And, when we say state, we normally think about state in components, or maybe state in, you know, You know, an external state library like Redux or Jotai or something. The article makes the point that there could actually be lots and lots of sources of state in your application.
-
-[24:22] You know, there's the URL, there's server files, there's the current time, operating system settings, environment variables, You know, lots of different potential sources of state. And so, you know, kind of walking back philosophically about, you know, how do these concepts tie together. And the author goes in a couple different directions.
-
-[24:40] On the one hand, extrapolating some of React's principles, you know, the React team has always been very focused on composability. And that's why we ended up with the custom hooks model that we did, because it enables arbitrary composition of hooks. On the other hand, the author also put up a follow up post saying that they think that Next actually kind of breaks some of these React fundamentals with the way that server components work and some of the way you have to actually structure your code base and your data flow.
-
-[25:10] I don't have a particularly strong opinion here, but it's always nice to see people actually kind of thinking through the concepts and the consequences involved.
-
-[25:18] **Carl Vitullo:** Yeah, and I really like the focus on. Discussing what state is. I feel like the, you know, the React ecosystem has been talking about state and state management for so long that, you know, there's always a game of telephone that happens in trying to communicate concepts out.
-
-[25:34] And I feel like where that has ended up over the years in the React ecosystem is people think state is a single blob of JSON. You know, that their app uses. But what this article is bringing back up is like, no, that's not the only type of state. State is something that your app needs to track in order to function correctly.
-
-[25:55] So yeah, I just wanted to call that out. I think that's a really useful clarification.
-
-[26:00] **Mark Erikson:** There was also a pretty good post over at Builder. io entitled, Why React Server Components are Breaking Builds to Win Tomorrow. I actually didn't quite catch the where in this it's talking about the breaking builds concept specifically, but it does a pretty good job of talking about the different concepts of rendering on the client, versus rendering on the server, versus streaming HTML, and how suspense and server components actually make some of these capabilities possible. So it's a pretty good kind of like technical architectural walkthrough.
-
-[26:31] Moving on a little further to the ecosystem. The Waku project from Daishikado, who's the author of Jotai and Valtio and Maintainer as Zustand, is making good progress. They've announced that they're working on a Pages router.
-
-[26:44] And I believe they're up to version 0. 20. Not sure what the roadmap is to 1. 0, but it's definitely a nice alternative approach to what we've seen with Next. And I believe they're pretty serious about trying to make it like a full blown, meaningful, usable framework based on server components. Similarly, Lee Robinson from Vercel actually just tweeted out a list of at least a half dozen different projects that are working on server component support in some fashion.
-
-[27:14] And so there's definitely work being done in the ecosystem. More specifically, the Redwood project. which originally went all in on GraphQL as the back end, just announced that they have finally managed to succeed in integrating server components. And I think they actually put up a post a few months ago saying that we are all in on server components as a concept.
-
-[27:36] So, server components have been out in Next for a while. We know that Remix is working on them, but there's other tools and frameworks that are trying to adopt them as well. And finally, I, one slight counterpoint, found an article just a little bit earlier where a company said, you know, we've tried server components and we like them, and we tried the new React server actions support.
-
-[27:57] But they ran into a few technical details, or technical issues. They didn't get a lot of details. It looked like something about some bundle problems, and then they felt that there was too much magic going on at the architectural level, and so they actually dropped server actions and went back to using tRPC instead.
-
-[28:13] **Carl Vitullo:** Interesting. Yeah. Too much magic is a very hand wavy type of complaint that can be used for all sorts of different, uh, underlying problems. So I'm curious what some more of those technical details would have been. But it's cool to see more experimentation and a wider range of experiments being done with server components generally.
-
-[28:33] When we first talked about WACU, I kind of expected it to be like just sort of an experiment, just sort of a like trial, because we'd seen a couple of those. We've seen, we had seen a couple of people just throwing together a project, doing it for learning, doing it to just explore. There's been. Pretty consistent development on Waku, so very interesting to see.
-
-[28:52] We'll have to see if it grows into a, like, serious competitor framework for, you know, okay, like, if it makes it to Remix or Next tier, then I would be very impressed. But, you know, they're definitely working on it in a much more meaningful way than I was anticipating originally.
-
-## Apple walks back on PWAs, neat Safari features
-
-[29:06] **Carl Vitullo:** A bit of a follow up to something we talked about last month of, uh, Apple's Attempted undoing of PWAs attempted.
-
-[29:15] I don't know how to frame that, but the last month. Apple announced they were going to drop support for progressive web applications for installing a web app to your home screen. They very quickly walked that back. And actually now, like I was just checking in on WebKit updates and they're adding more support for progressive web apps.
-
-[29:32] They are most specifically, they're going to be supporting the shortcuts manifest property, which allows you to add context items for the home icon. So, you know. On a Mac, if you add it to the dock, you can right click on it and it will show up a couple of options that take you to specific URLs within the app.
-
-[29:51] So, you know, it's a shortcut. It's a context item for your home screen icon that takes you to somewhere specifically within the app. Like, these are the kind of things that Like what progressive web apps have been a thing for like a decade now. Like there was never a technical reason why Apple could not support shortcuts in this.
-
-[30:08] So this feels like a shift of tack to more meaningfully support progressive web apps so that they can entrench themselves and say like, no, look, we are, we do support alternatives. We're not a monopoly while they're defending lawsuits against the iPhone and app store. So cool. You know, if that ends up bringing more meaningful support of progressive web apps. Uh, I'm pretty excited. You have to see how that shakes out though.
-
-[30:32] Another small, interesting thing coming from here, not related to progressive web apps, just Safari web kit features. They added a like progressive enhancement type option for checkbox. So they added a switch attribute to the input in Safari.
-
-[30:48] So if you say input type checkbox switch. It will render as a switch. It was one of those solutions that felt really obvious in hindsight, and I have implemented so many switches in my career, and they are a pain in the butt to get to work correctly. So having a native option, like, now I want Chrome and Firefox to roll it out, like, immediately, because it is Just a great improvement.
-
-[31:08] It's a very small, but very meaningful improvement. I love to see, it's not even like innovation in form inputs. It's just like fixing a problem, fixing something that's been missing for 15 years at this point.
-
-[31:21] **Mark Erikson:** Nicole, who had been heading up a lot of Chrome's work around interacting with frameworks, I know that she had spearheaded a lot of efforts to try to improve native form controls as a concept.
-
-[31:33] I also know there's a project called Open UI, which is somewhere between let's build another set of web components, but also let's kind of like prototype and experiment with what additional built in browser forms and features would look like. And what if there were a tabs or a carousel kind of control built into browsers natively?
-
-[31:56] And so they've been doing work to try to spec those out.
-
-[31:59] **Carl Vitullo:** Oh, very cool. In some ways, I feel like in trying to be agnostic and provide maximum flexibility to developers, I feel like we used to have, like, the operating systems, before everything moved into being web based, operating systems provided, like, a very limited toolkit of, like, here are your UI elements.
-
-[32:18] **Mark Erikson:** And bring back the styled win Windows XP Common Controls, Doug on it. .
-
-[32:23] **Carl Vitullo:** Right, right. Where's the, where's the Windows 95, you know, tab list? Like, okay. Sure. Uh, we've had a lot more experimentation in different types of UIs and different types of ex uh, different types of user experiences. But like, man, you know, it's, I feel like it's also gotten super fragmented.
-
-[32:38] And so maybe this is the pendulum. Maybe, you know, it went, it started by technical necessity on a super constrained set of core components that you just added. And then we went all the way, maximum flexibility. You can do anything you want, anything and everything. And now people are going like, uh, I'm tired of figuring out new unfamiliar UIs.
-
-[32:57] I'm tired of implementing things from scratch. So, uh, yeah, I, maybe we'll. Consolidate a little more back on a simpler set of UI primitives.
-
-## Mental Health in Open Source
-
-[33:05] **Mark Erikson:** All right, changing topics completely. There was an excellent article this week from Anthony Fu, who is a prolific maintainer and developer within the Vite and Vue ecosystems.
-
-[33:17] And, you know, strictly speaking, this has nothing to do with React, but it is an excellent article. And so he wrote about mental health in open source. And he talked about, you know, he got involved in open source kind of by accident. Thanks And he made a lot of great points that absolutely resonated with me.
-
-[33:34] Like, as a fellow open source maintainer, I 100 percent absolutely agree and endorse and stamp and repeat every single thing that he said in this post. So we talked about, you know, not being prepared, like, as a maintainer, you are a developer, and tech support, and marketing, and docs writer, and team leader, and project manager, and, you know, a whole bunch of other hats, and nobody teaches you how to do any of this stuff.
-
-[34:03] But there's also a really big problem with expectations, both internal and external. You know, users file bug reports, and they expect their bug to be fixed right away. But then, as a maintainer, you also put a lot of pressure on yourself to try to get stuff done. And I unfortunately am very guilty of this.
-
-[34:21] I routinely have put far too much expectations and self responsibility to get certain things done. And then I feel bad when I don't live up to my own expectations. As an example, I've said that this year I want to do a refresh pass on the Redux docs tutorials. And I've sat down like three different evenings and made some progress on it, but I've been otherwise focused on some different things and my brain is yelling at me because I quote, haven't made as much progress as I should have made by the end of March.
-
-[34:54] Nobody's watching me. Nobody is keeping track. Like, I've tweeted that I was gonna do this, but like, no one is watching me. It's my own head that is yelling at me because I don't feel like I've gotten enough done. And so Anthony has, you know, some similar points that he makes in his post. And then he also talks about, you know, in some ways your dream of working on this tool can become its own entire second job.
-
-[35:17] So there's not like a specific solution that he discusses, but everything he said on that post, like is absolutely my own experience and it's very much worth reading.
-
-[35:28] **Carl Vitullo:** Definitely worth reading. You have a lot of good things to say about like making your hobby, your job, that definitely resonates with me because that's kind of what I've been trying to do with the community stuff here in Reactiflux, part of why we are doing this podcast is because I thought, you know what, podcasts, that's the way to make money, not that it's worked yet, but you know, hey, sooner or later.
-
-[35:48] But yeah, this is, I definitely thought this was a really great and, I think it's a pretty vulnerable post. He's being very open about the difficulty of taking on this category of work. So yeah, also he talks, he says in the beginning, it's been about four years since I started doing open source and that's like, man, that puts him at.
-
-[36:07] 2019, 2020? 2020? That's four years ago? What? I don't know. This blew my mind a little bit. I have never been an open source maintainer, really. I did briefly take over a, you know, abandoned project and did a little bit of work on it. But, you know, it was so small that I don't feel like I can meaningfully claim the open source maintainer.
-
-[36:27] But, you Even just, even a very small library that was, ultimately was functionally replaced by a browser standard, it was a sticky, you know, Sticky banner library. Even just doing that for a couple of, I guess it was close to a year, just fielding issues and diagnosing and figuring out the, whether the answer to a question is yes, this is the bug that needs to be fixed or no, this is a
-
-[36:49] **Mark Erikson:** Intentional design limitation or something.
-
-[36:52] **Carl Vitullo:** There we go. Yes. This is an intentional constraint that. The trade offs are such that this is the correct decision. That's a lot of mental energy to expend. Like, you know, separate from, and I never did any blogging on it. I never, you know, spoke at any conferences. It was like a, an extremely small part of my, Attention.
-
-[37:09] And it still wore on me a little bit. So yeah, definitely a really good post to read. Really good projects alive that all of us use to do our jobs. Yeah, definitely recommend reading it.
-
-## Angular, meet Wiz
-
-[37:20] **Carl Vitullo:** I'll move us on. This is even farther afield from React, but, um, I saw Sarah Drasner tweeted that the Angular is going to be merging with a heretofore unopensourced internal Google framework called Wiz.
-
-[37:36] Wiz was brand new to me, I had never heard of it. So. Hearing that, you know, Angular, one of these huge projects, one of the projects in web is going to be internally combining with a never open source project. That's a pretty big statement. That's a pretty big plan.
-
-[37:51] It looks like this ultimately came from a exploration of using signals within, you know, signals and reactivity within Angular and drawing inspiration from this well understood internal framework called Wiz that I believe it is.
-
-[38:07] No. Okay. So the combination of Angular and Wiz is already rolled out to 100 percent of YouTube traffic. So like, this is not, you know, an abstract. Intent to, like, no, this is done. This is, you know, I took this as a similar in weight to when the React core team announced that server components were being used on the Instagram web property, you know?
-
-[38:29] So this is a meaningful investment. One of the big reasons that I think this is worth discussing on our React news show, Malte Ube, he is currently working at Vercel. He did a lot of work on Wiz. Back in the day at Google, he, and he had a really good post where he talked about like, why was that? Why was Wiz developed?
-
-## Designing Very Large Javascript Applications
-
-[38:49] **Carl Vitullo:** What problem was it trying to solve? And so he put up this blog post called Designing Very Large JavaScript Applications, which is ostensibly about Wiz and about, you know, these frameworks. But I found it to be a really clear and cogent articulation of a lot of the challenges that React. is trying to solve as well.
-
-[39:08] It's, you know, it talks about like the challenges of centralizing configuration and how, you know, things like a routes configuration file or the webpack configuration file, when you start maintaining a Enormous web application begins to be such a large constraint as to be like prohibitive. Like it just, it doesn't work.
-
-[39:29] You can't scale it. It ends up being append only. And so then you end up loading the bundle, like it becomes fragile because nobody wants to remove things. So then nobody wants to change, make certain categories of changes. Definitely a really good post discussing a lot of the finer points around bundling and architecture limits of current tooling and the most challenging.
-
-[39:49] Parts of large and complex applications. Uh, specifically he talks about Google search results and you know, now they serve up lots of little, uh, widgets as the first result. Like, you know, you search some math and it will spit out a calculator. You search a currency conversion and it puts up.
-
-[40:03] A calculator. Or all sorts of those things. Like each of those is basically its own tiny web app, and so if you just pull up Google, obviously they cannot serve up dozens and dozens of these tiny web apps that you're not using. So that's sort of the category, that's the backdrop and the framing for this architecture that's gotten.
-
-[40:21] Yeah, definitely really interesting. Definitely recommend giving it a read.
-
-[40:24] **Mark Erikson:** One other small tangent off that is, you know, we've heard the discussions and the arguments about front end development doesn't get the respect that it deserves for being its own very complicated domain. And I think that post is a very good example of, you know, real world apps have a lot of complexity and there are, they have their own unique sets of constraints and concerns and potential problems they have to work through.
-
-[40:47] Yeah,
-
-[40:48] **Carl Vitullo:** very true. And on that note, something that struck me reading it is that is an entirely different set of constraints than I personally have ever experienced in my career. So of all of the weird, quirky, you know, specific reasons why like this tool doesn't work for this product or whatever, That was a whole new category that I've never encountered, like, I, you know, I don't work on a Google type app where there might be one of a hundred and fifty different things served on the same page.
-
-[41:16] So I just thought that was really interesting. It was a glimpse into a different part of the web world. Just broadened my perspective just that little bit much more.
-
-[41:23] **Mark Erikson:** I mean, similarly, you were talking earlier about like, you know, I've implemented, you know, a half dozen input widgets or something in my career.
-
-[41:30] Like, I've never done anything like that. I mean, I've never worked on a project that really made meaningful use of a router. At all. Like everything I've worked on in my career has basically been the equivalent of a desktop app that runs in a browser that, you know, it's an app, not like pages or routing.
-
-[41:51] So like I've barely ever used routing in my own career because the products I've worked on just haven't required it.
-
-[41:58] **Carl Vitullo:** Yeah. I think that is so true and very underappreciated even within frontend. I think that so like you said, I've implemented a lot of checkboxes. That's because I've jumped around to a lot of different startups and I've worked on a lot of greenfield projects.
-
-[42:11] So I actually think that I have a relatively rare perspective on the industry of, you know, I didn't spend six years at, you know, Google. Four years at Facebook. In, in my, over my 10 year career, I worked at nine different companies. Like, you know, I've seen a lot of different types of products. I've worked in advertising tech, agriculture tech, cryptocurrencies, done brochure sales sites for credit card companies.
-
-[42:34] So like, I have worked in a bunch of different contexts. And what I've learned is that Well, something I experienced was that surprisingly little of what I used in one company was immediately relevant at the next company. Like, the architectures were just so different that the assumptions I couldn't bring any of my past assumptions.
-
-[42:53] I had to leave all those assumptions at the door and just rediscover a new problem space every time I joined a new company. And so here's Malte discussing an entirely new type of architectural constraint that I have never encountered, despite my wide range of encountered problems. Last thing I'll say on that, he gave a talk at JSConf Australia in 2018.
-
-[43:13] Speaking about Wiz and talking a little bit about his decision not to open source. He says at the time didn't want to compete with React. There were already so many options, adding another one seemed unnecessary. And like, yeah, I, 2018, I feel like that was about peak JavaScript fatigue era. Um, but now he describes that decision not to open source as a misread of the market demand.
-
-[43:36] So that's interesting. So just bringing it back to Angular meets Wiz. I think, yeah, I'm going to be paying attention to that to see how that shakes out a little bit more. It seems like it's, he regards it as a correction to a mistake made like five or six years ago.
-
-## Lightning round
-
-[43:51] **Carl Vitullo:** We're into the lightning round. We are over an hour.
-
-[43:53] **Mark Erikson:** Lightning the lightning round.
-
-[43:55] **Carl Vitullo:** Yeah, lightning the lightning round. Cool.
-
-## ⚡️ Interaction to Next Paint, new Core Web Vital ⚡️
-
-[43:56] **Carl Vitullo:** First off, there is a new Core Web Vital, which are the, like, lighthouse, Performance characteristics that are measured by Google. I believe the Core Web Vitals are one relatively significant input to search ranking for like search engine optimization.
-
-[44:12] Interaction to NextPaint, INP, is replacing first input delay as a Core Web Vital. So really quick overview, uh, first input delay was You open up a new website, how long until that code responds to the first input you give it? You know, a click, a scroll, a keystroke. That is no longer going to be a Core Web Vital, and instead it will be how long between an interaction and the next paint.
-
-[44:36] Notably, that's A change from measuring like startup responsiveness to ongoing responsiveness, which I think is very important. 'cause you know, it's much easier to do a, a one-time optimization of the app as it's loading versus a just optimizing the entire app so it's more responsive and just faster, better. So yeah, definitely seems like a much more meaningful metric.
-
-## ⚡️ RSPack charts a path to 1.0 ⚡️
-
-[44:56] **Mark Erikson:** Next up, there's been a plethora of rust based javaScript build tools as of late. One of those is called RS Pack, which is a rust based reimplementation of the entire web pack tool being built by ance. RS Build is a layer on top of that from the same team that makes the web pack layer easier to use.
-
-[45:20] So conceptually this is like a CRE React app equivalent, and they actually have how to migrate from CRA in their docs. They have announced plans for their roadmap to a 1.0 release. For what it's worth, I tried out RS build in one relatively small CRA project that I had, and it worked great. Like the build time dropped from like 30 seconds to one second.
-
-## ⚡️ Remix might merge React Router in?? ⚡️
-
-[45:42] **Mark Erikson:** Entirely other news, Ryan Florence has been talking about how the Remix team has been continually adding more features to React Router, things like loaders and such. And so he's now tossing out the idea that they might end up effectively merging the Remix and React Router projects in some way. Details TBD. But it's something that they're thinking about.
-
-## ⚡ Declarative Shadow DOM in all major browsers ⚡️
-
-[46:08] **Carl Vitullo:** I have another broad web update here. Declarative Shadow DOM is now available in all major browsers. This is related to web components. I know that one of the major criticisms in the past several years, many years, has been Of web components has been that it is not possible to use them without JavaScript.
-
-[46:27] How they get added to the page is through JavaScript. And so if you are trying to make, there are many categories of web products, web properties. Where that just doesn't work. You can't use JavaScript, you can't rely on it, many reasons it doesn't work. And so, this is a declarative version of Shadow DOM that is now supported in all major browsers.
-
-[46:46] And, theoretically, maybe this will unlock a new era of experimentation in web toolkits. Now that we can use Web components without JavaScript. I think that we might start seeing some more experimentation. This kind of feels like what web components have always been meant to be. So yeah, interesting.
-
-## ⚡️ React Native community map ⚡️
-
-[47:05] **Mark Erikson:** Okay, next up, there's a developer named Lorenzo Sciandra, who works at Microsoft, I believe, on Microsoft's maintenance of React Native for Windows and React Native for Mac, and he's put together a repository list that points to lots of community resources for React Native. Discords and servers and discussions. So if you're interested in React Native and other possible community resources, that's useful.
-
-[47:31] **Carl Vitullo:** Yep, we're on there. Woo! (chuckles)
-
-## ⚡️ Node.js 2023 Year in Review ⚡️
-
-[47:34] **Carl Vitullo:** As mentioned much earlier, there was a Node. js 2023 year in review post.
-
-[47:39] It's mostly just sort of talking about, like, Technical overview of how Node itself has changed over the years. So it's not so much like how you use it or, you know, performance. It's here is how usage of different versions have, has trended over time as different ones have gone end of life or been released.
-
-[47:58] It has a great chart of the binary size per version over time, which let me just call out. So version 10. 24. was about 40 megabytes or mebibytes. I'm just going to call it megabytes. Version 21. 6 was 98. So that's a long time. Version 10 versus version 21. I think that's Like close to 10 years, something like that.
-
-[48:22] But yeah, seeing it 2. 5X in size over that time is, yeah, I guess it's been kind of append only. So yeah, like we discussed earlier, TypeScript has been focusing on reducing its install size. It sounds like there might be growing appetite to do so in Node as well. But this is just sort of like a, it's a pretty deep in the weeds discussion of how Node has evolved, and specifically some of the changes in 2023. So I found it was a good read. Not immediately actionable in any kind of way, but just sort of broad context. Stay on top of what's going on.
-
-## ⚡️ Tailwind preview of 4.0 ⚡️
-
-[48:57] **Mark Erikson:** Next up, Tailwind is working on a new version and they've put up a post talking about some of the changes that they're making for version four. The biggest one is they've got a whole new CSS engine.
-
-[49:08] Apparently it's built on top of Lightning CSS, a Rust based CSS parser and translator from the author of Parcel, but they're working to make it the whole thing smaller, faster, built in. They're also making some potential changes to the configuration so it actually kind of looks and feels more like CSS in the process.
-
-## ⚡️ Vercel adds Remix+Vite support ⚡️
-
-[49:26] **Carl Vitullo:** So, Vercel has announced that they are now supporting Remix with Vite. Pretty cool. Just especially because they maintain Next. It seems nice that they would pretty quickly jump on adding support for some new features coming out of Remix. They say in this post, they collaborated with the Remix team to add server bundles to Remix, which we discussed really briefly last month as a kind of confusing, deep optimization.
-
-[49:52] So just to see that. Vercel is meaningfully working to support some kind of fringe, niche features within one of their major competitors. Cool. That seems really nice. Very glad to see that. Also adds support for Remix features like the streaming, server side rendering, API routes, more advanced caching, data mutations.
-
-[50:13] Yeah. Happy to see that.
-
-## ⚡️ Navigating the Future of Frontend ⚡️
-
-[50:15] **Mark Erikson:** And finally, there's an author named Rem, uh, I don't know any more details about them, that's just their handle, who has put up a series of very good posts at a site called Frontend Mastery, talking about various aspects of React and frontend development. And the latest one's called Navigating the Future of Frontend.
-
-[50:32] And it talks about some of the aspects of JavaScript frameworks, and their capabilities, and what are some of these tools even doing for you. And talks about some of the directions that they are going these days in terms of routing, and mingling backend and frontend, and dealing with caching, and components that can be used on the server or on the client, and in a mix of some way.
-
-[50:55] So it's not like a specifically actionable post, but it's a useful guide to, like, where have we been and where are we going.
-
-[51:02] **Carl Vitullo:** Yeah, definitely looks like a really interesting post. And I just realized, just now, that it's not on Frontend Masters, it's Frontend Mastery, which is not an educational platform hahaha.
-
-[51:12] **Mark Erikson:** It looks like it's basically this one person's blog.
-
-[51:15] **Carl Vitullo:** Interesting. Yeah, I, I saw the link and I had assumed that it was really the front end masters, which makes perfect sense because they've been doing web education for my entire career, insofar as I learned React by taking a front end masters class. But yeah, no, this is front end mastery.
-
-[51:29] It's just somebody's blog. Still, it's really good, really good post to echo everything Mark just said.
-
-[51:34] That's everything we got. We'll be back on the last Wednesday of next month in April on the live stage here in Reactiflux or back in your podcast feed just as soon as we can. We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, React Digest, the React. js subreddit, here in Reactiflux, and directly from people publishing articles on Twitter or whatever.
-
-[51:57] If you see anything newsworthy, definitely let us know in the Tech Reads News channel here in Reactiflux, or let me know by sending an email to hello at reactiflux. com with T M I R in the subject line. It's an acronym for the show.
-
-[52:11] I read literally every email that comes in, including spam and all sorts of other things. So yeah, if you send an email to hello at reactiflux. com, I will read it. And if this is a show you get value from and want to support, the best way to do so is submit a review or tell your friends and co workers about it.
-
-[52:26] Just drop it in Slack. And I know that I will personally thank you if I am ever made aware of you broadcasting us. Cool. Thank you so much. See you next month.
diff --git a/src/transcripts/tmir-2024-04.md b/src/transcripts/tmir-2024-04.md
deleted file mode 100644
index 4edf563..0000000
--- a/src/transcripts/tmir-2024-04.md
+++ /dev/null
@@ -1,535 +0,0 @@
----
-title: "This Month in React, April 2024: So many new releases, React 19 featureset"
-date: 2024-04-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick hits
- - [[00:46](#upcoming-conferences)] [Upcoming conferences](https://react.dev/community/conferences)
- - [React Conf 2024](https://conf.react.dev/) May 15 - 16, 2024. In-person in Henderson, NV, USA
- - [App.js Conf 2024](https://appjs.co/) May 22 - 24, 2024. In-person in Kraków, Poland
- - [Local First Conf 2024](https://www.localfirstconf.com/) May 30, 2024. In person in Berlin, Germany. Followup hackathon on the 31st
- - [Render ATL](https://renderatl.com/) June 12-14, 2024. Atlanta, GA, USA
- - [Future Frontend](https://futurefrontend.com/) June 13-14, 2024. Helsinki, Finland
- - [React Norway](https://reactnorway.com/) June 14, 2024. Larvik, Norway
- - [React Summit](https://reactsummit.com/) June 14 + 18, 2024. Amsterdam, Netherlands (+remote)
- - New releases
- - [[02:32](#react-183-19)] [React 18.3](https://github.com/facebook/react/pull/28843)
- - [React 19 beta](https://react.dev/blog/2024/04/25/react-19)
- - [[03:15](#nodejs-v22)] [Node.js v22](https://openjsf.org/blog/nodejs-22-available)
- - [[04:02](#expo-sdk-51-beta)] [Expo SDK 51 beta](https://expo.dev/changelog/2024/04-24-sdk-51-beta)
- - [React Native 0.74.0](https://reactnative.dev/blog/2024/04/22/release-0.74)
- - [React DevTools 5.1](https://github.com/facebook/react/pull/28840)
- - [Next v14.2](https://nextjs.org/blog/next-14-2)
- - Bun v1.1 (discussion later)
- - [Pnpm v9](https://github.com/pnpm/pnpm/releases/tag/v9.0.0)
- - [Biome 1.7](https://biomejs.dev/blog/biome-v1-7/)
- - [Supabase goes GA](https://supabase.com/ga-week) after 4 years in beta
- - [Docusaurus 3.2](https://docusaurus.io/blog/releases/3.2)
- - [Gulp v5](https://medium.com/gulpjs/announcing-gulp-v5-c67d077dbdb7)
- - [Pragmatic Drag and Drop](https://github.com/atlassian/pragmatic-drag-and-drop)
- - [RedwoodJS 7.3](https://github.com/redwoodjs/redwood/releases/tag/v7.3.0)
- - [React on Rails v14](https://github.com/shakacode/react_on_rails)
-
-# Main Content
-
-- [[12:43](#new-react-release-details)] New React development
- - [React Blog - React 19 Beta](https://react.dev/blog/2024/04/25/react-19)
- - [React Blog - React 19 Beta Upgrade Guide](https://react.dev/blog/2024/04/25/react-19-upgrade-guide)
- - [React 18.3 changelog](https://github.com/facebook/react/blob/4508873393058e86bed308b56e49ec883ece59d1/CHANGELOG.md) : dev-only warnings for string refs, `findDOMNode` , default props, legacy context, `test-utils`
- - Internal changes:
- - [Rename SECRET INTERNALS to \_\_CLIENT_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE](https://github.com/facebook/react/pull/28789)
- - [Fast JSX: Don't clone props object](https://github.com/facebook/react/pull/28768)
- - [Remove defaultProps support (except for classes)](https://github.com/facebook/react/pull/28733)
- - [Ship optimized-but-unminified prod bundles and drop sourcemaps](https://github.com/facebook/react/pull/28881) ([current package contents](https://unpkg.com/browse/react-dom@19.0.0-beta-4508873393-20240430/cjs/))
- - [Don’t patch `fetch` anymore](https://github.com/facebook/react/pull/28896)
- - Future: [patching Date object?](https://twitter.com/acdlite/status/1785691330988986587)
-- [[33:29](#react-native-0740)] React Native [0.74.0 release](https://reactnative.dev/blog/2024/04/22/release-0.74)
- - [React Native Navigation v7](https://reactnavigation.org/blog/2024/03/25/introducing-static-api/)
- - [VisionCamera v4.0](https://github.com/mrousavy/react-native-vision-camera)
-- [[38:17](#kotaken-rscs-with-just-bun)] [Kotekan](https://kotekan.dev/blog/introducing-kotekan)
-- [[39:02](#bun-11)] [Bun v1.1](https://bun.sh/blog/bun-v1.1)
-- [[39:37](#jsr-by-deno)] [JSR](https://deno.com/blog/jsr_open_beta)
- - [First Impressions](https://dbushell.com/2024/02/16/jsr-first-impression/), [Second Look](https://dbushell.com/2024/03/04/jsr-second-look/)
- - [First Things I Learned about JSR](https://mariusvatasoiu.com/first-things-i-learned-about-jsr)
-- ⚡️ Lightning round ⚡️
- - ⚡️ [[45:09](#-why-i-like-react-even-in-2024-)] [Why I like React (Even in 2024)](https://ejosh.co/de/2024/03/why-i-like-react-even-in-2024/) ⚡️️
- - ⚡️ [[45:46](#-netlify-updates-their-nextjs-runtime-)] Netlify: [Introducing the new Next.js Runtime](https://www.netlify.com/blog/introducing-the-new-next-js-runtime/) ⚡️️
- - ⚡️ [[47:18](#-design-principles-behind-the-nextjs-app-router-)] [Design Principles behind the Next.js App Router](https://twitter.com/feedthejim/status/1785243633328758978) ⚡️️
- - ⚡️ [[48:04](#-nodejs-website-redesign-)] [Diving into the Node.js Website Redesign](https://nodejs.org/en/blog/announcements/diving-into-the-nodejs-website-redesign) ⚡️️
- - ⚡️ [[48:44](#-dives-into-react-features-)] [How does `useOptimistic` work internally?](https://jser.dev/2024-03-20-how-does-useoptimisticwork-internally-in-react/) (and many other code dives) ⚡️️
- - ⚡️ [[49:27](#-honeypot-releases-nodejs-documentary-)] [Node.js: The Documentary](https://www.youtube.com/watch?v=LB8KwiiUGy0) ⚡️️
- - ⚡️ [[49:56](#-flow-ships-react-features-)] [New Flow Language Features for React](https://medium.com/flow-type/announcing-component-syntax-b6c5285660d0) ⚡️️
- - ⚡️ [[50:26](#-vercel-updates-pricing-)] [Vercel cuts prices a lil](https://vercel.com/blog/improved-infrastructure-pricing) ⚡️️
- - ⚡️ [[51:28](#-redwoodjs-compares-data-fetch-methods-)] [Redwood Blog: Techniques for Fetching Data: Comparing Next, Remix, and Redwood](https://redwoodjs.com/blog/techniques-for-fetching-data) ⚡️️
- - ⚡️ [[52:02](#-kuto-reverse-js-bundler-)] [Kuto, “reverse JS bundler”](https://samthor.au/2024/kuto/) ⚡️️
-
-[00:00] **Carl Vitullo:** Thanks people for joining for April's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
-
-[00:09] **Mark Erikson:** And boy, is it evolving right now.
-
-[00:11] **Carl Vitullo:** Boy, is it evolving. Oh my God. There's so many releases. It's so much to get through.
-
-[00:16] So I guess let's try and run through it quick. Coming to you live from Reactiflux, the place for professional React developers.
-
-[00:24] I'm Carl, a staff product developer and freelance community manager here at Reactiflux, running community events like these.
-
-[00:31] **Mark Erikson:** And I'm Mark Erikson, my day job, I'm a senior front end engineer at Replay where we're building a time traveling debugger for JavaScript with some amazing test analysis features coming your way in the near future.
-
-[00:42] And outside of that, I do Redux stuff.
-
-[00:45] **Carl Vitullo:** So much Redux stuff.
-
-## Upcoming Conferences
-
-[00:46] **Carl Vitullo:** There's so many conferences coming up in the next, like, two months.
-
-[00:49] We've got this month, why I'm in Vegas. So if you're coming to React Conf, hit me up. If you're local and not attending the conference, come on down and we can do a watch party. Otherwise, I'm probably going to try and organize a couple of pre conf Things, post conf, after parties, ReactConf, May 15th and 16th in Henderson, Nevada.
-
-[01:09] AppJSConf is May 22nd through 24th in Krakow, Poland. The local first conf, I love local first stuff.
-
-[01:18] I think it's just a really powerful way to develop applications that is Kind of complicated. So I love seeing a conference dedicated to it. That's going to be May 30th in Berlin, Germany with a follow up hackathon on the 31st.
-
-[01:31] There's Render Atlanta in June 12th through 14th in Atlanta, Georgia.
-
-[01:36] Future Frontend, June 13th and 14th in Helsinki, Finland.
-
-[01:40] React Norway, June 14th in Larvik, Norway.
-
-[01:45] And React Summit, June 14th and 18th it looks like in Amsterdam with a remote option there.
-
-[01:51] **Mark Erikson:** I'm still crossing my fingers that I might at least be able to attend ReactConf here in a couple weeks and then I will be speaking at React Summit in Amsterdam as well.
-
-[02:01] **Carl Vitullo:** Awesome. Very cool. I can't believe how many are crammed into the middle of June. It's, it's a lot of good looking conferences. I know FutureFrontend
-
-[02:09] **Mark Erikson:** Is he the one who has been involved in like writing a webpack book years ago?
-
-[02:14] **Carl Vitullo:** I think so. He was involved in Reactiflux pretty actively a number of years ago.
-
-[02:18] I just wanted to give him a shout out because he's been deep in the React community for a very long time and seems like a cool dude.
-
-## New releases
-
-[02:25] **Carl Vitullo:** We're going to move on to a bunch of new releases. This has been a crazy dense month for new releases.
-
-## React 18.3 + 19
-
-[02:32] **Carl Vitullo:** The big ones, obviously two new React versions have been announced at least. There's React 18. 3. Which I think it's just sort of a pro forma release, getting ready for React 19. No behavior changes, just some extra warnings, a bit of improvements to developer experience to facilitate upgrading to React 19.
-
-[02:54] React 19 beta. Ooh, new major. Definitely excited to see all of the stuff going on there. I don't know. We've talked a lot about all of the development going on into React 19 with stuff like Form Actions, useActionState, RSC is obviously going to be big. Lots of form helpers and stuff.
-
-[03:12] **Mark Erikson:** We'll cover that in detail in a few minutes.
-
-[03:14] **Carl Vitullo:** For sure.
-
-## Node.js v22
-
-[03:15] **Carl Vitullo:** Yeah, new Node. js major version.
-
-[03:18] **Mark Erikson:** And I'm not sure where the versioning ties in, but I know I saw an announcement that some version of Node, probably this one, now has support for importing ESM files via Require, which is gigantic. I don't know what it was they had to do to finally make that work, and why they couldn't have done that like eight years ago, but hey, better late than never.
-
-[03:42] **Carl Vitullo:** Better late than never. Yeah, that, oh man, the ESM versus CommonJS has been such a troubling split in the web ecosystem. So seeing Node finally supporting native ESM import through Require, hopefully will lessen a lot of that pain. Definitely very excited to see that.
-
-## Expo SDK 51 beta
-
-[04:02] **Carl Vitullo:** Okay. Blasting through. We've got Expo SDK 51 is out in beta.
-
-[04:06] That looks interesting. They are including the new React Native release, which we're going to talk about later too. And just lots of other improvements to like cameras and SQLite APIs, iOS privacy manifest, definitely looks like a pretty big one.
-
-## React Native 0.74.0
-
-[04:21] **Carl Vitullo:** React Native 0. 74, definitely pretty big release. We're going to talk about it.
-
-[04:26] A lot more in depth later. Uh, they've got a new version of the yoga layout engine and using yarn three in the default community CLI. But yeah, more details later on.
-
-## React DevTools 5.1
-
-[04:36] **Carl Vitullo:** New DevTools version as well. For React, the React DevTools put out version 5. 1. There's a bunch of changes there, but you know, I don't know. It's the DevTools.
-
-[04:47] **Mark Erikson:** Mostly related to support for the new features like use action state.
-
-[04:52] **Carl Vitullo:** Right, love some better DX there. The DevTools have always been pretty powerful and excited to see what the new experiences there look like.
-
-## Next 14.2
-
-[05:02] **Carl Vitullo:** Next, 14. 2. Gonna chat more on that later, of course.
-
-## Bun v1.1
-
-[05:07] **Carl Vitullo:** Same with Bun, version 1.1. New Bun minor. Again, gonna get deeper into it later on.
-
-## pnpm v9
-
-[05:12] **Carl Vitullo:** PMPM put out a new version 9, so a major version of a pretty significant package manager. I didn't quite realize that the P in PMPM stands for performant. The whole idea is there is that it just is MPM, but faster and better. I've heard from a number of people that it's their package manager of choice.
-
-[05:33] I've never substantially used it. I had used Yarn for a long time, but then I never upgraded from version 2. As I understand, the big improvement for PMPM is that it does sort of what Yarn 3 does similarly with not installing duplicate versions of packages when you have them already installed on disk somewhere.
-
-[05:52] So, That seems really cool. They're also adding like CorePack compatibility, which I understand to be a node standard for better supporting different types of different package managers. So, cool to see them supporting that standard. Always good to see behavior become more standardized, as well as improvements to the lockfile.
-
-## Biome 1.7
-
-[06:12] **Carl Vitullo:** We got Biome 1. 7. I have a soft spot in my heart for Biome. I was an early supporter of Rome and it was very sad to see that, I don't know, kind of go into vaporware mode. So I was excited to see that many of the maintainers of Rome forked the project and came out with Biome. They're advertising single command migration from ESLint as well as Prettier.
-
-[06:34] So I guess two commands, one for ESLint, one for Prettier. And looks like a bunch of smaller developer experience improvements for using it. Like, you know, checking staged files with a command flag. And good default linter configuration. Love the project getting a sort of a bundling. Well, how to disambiguate the term bundling.
-
-[06:55] It sort of bundles up a bunch of behaviors from other tools like linting and. Formatting and all those sorts of things. So I like that. I think it's a very interesting project. Definitely check that out.
-
-## Supabase leaves beta
-
-[07:06] **Carl Vitullo:** Okay. Supabase, which is a, I guess, Postgres as a service. I always have conceptualized it as an open source Firebase competitor.
-
-[07:14] I guess Supabase, yeah, Firebase. I didn't realize that they're still, they had been still in beta, but earlier this month they went general availability, so definitely check out the launch event. Week that they did. I have heard it as, you know, sort of an open source darling. I've seen it all over, you know, Twitter, used by many people who do lots of side projects and smaller greenfield work.
-
-[07:35] So if you're considering something like Firebase, if you're considering a back end as a service, definitely check out Superbase because it is generally available. No longer in beta.
-
-## Docusaurus 3.2
-
-[07:45] **Carl Vitullo:** Docusaurus put out version 3. 2, looks like it's mostly performance improvements, a better table of contents from partials, which I guess is, you know, if you stitch together a bunch of documents into a single page, they now have better support for generating a table of contents.
-
-[08:02] And this is a silly thing that I have always had on my mind, but one of the things they advertised was An accurate last mod time in the sitemap. I have found that tricky. I think that makes a reasonably big difference in SEO. You know, you're signaling to Google or whatever search engine that your content is fresh, is up to date.
-
-[08:21] And in the past, I have generally found sitemap generation tools they just seem to not care about that, like they just put together a list of all the URLs. So just seeing that taken seriously by Sebastien, by Docusaurus, I like it. They also mentioned in their release post that they have overtaken Gatsby in NPM downloads, which seems like a pretty significant milestone.
-
-[08:43] Changing of the guard a little bit.
-
-[08:45] **Mark Erikson:** That is interesting because we use DocuSource for the Redux documentation sites, and it's not like it's getting downloaded continuously in our case, we only do docs updates kind of intermittently. And so for it to actually be getting downloaded frequently suggests there's a lot of people using it for like a non library documentation site kind of use case.
-
-[09:06] You know, more of that static like website beyond just Docs.
-
-## Gulp v5
-
-[09:11] **Carl Vitullo:** This is a bit of a throwback, but Gulp, the now at this point quite long in the tooth build tool, script runner, just released version 5. Man, I haven't thought about Gulp in a number of years, so seeing it cross my path again was just like, oh, Gulp. Nice.
-
-[09:26] **Mark Erikson:** I'm genuinely surprised it's being actively maintained, much less putting out major versions. I mean.
-
-[09:32] **Carl Vitullo:** A little bit!
-
-[09:33] **Mark Erikson:** Admittedly, my own experience is biased. I've been in the React ecosystem where we, you know, webpack, blah, blah, blah, but very surprised to see that it's getting actively developed.
-
-[09:42] **Carl Vitullo:** Would generally agree.
-
-[09:43] They say in the release post, this release contains four years worth 60 projects. The team closed over 200 issues and pull requests. Cool. It's neat to see. Doing a major version seems like maybe a big ask for a project that is, I think, most likely to be used in a maintenance mode capacity. So, major version there seems like a little bit of a hard sell. Nice to see an old name resurface.
-
-## Pragmatic Drag and Drop
-
-[10:07] **Carl Vitullo:** I'm going to shout this out because it's related to a project that we had the maintainer on as a guest a number of months ago, but Pragmatic Drag and Drop from Atlassian. Drag and drop is brought. I've always found it to be kind of challenging to implement.
-
-[10:23] I remember when I spoke with the, the, the maintainer, Alex Reardon a couple of months ago, he had a lot of really interesting things to say about serving the different use cases in drag and drop. And I think he has been involved in maintaining like three different drag and drop open source libraries. So he's been just very deep in it for a very long time. And it sounded like he really pulled a lot of learning from those different types of uses into this project, made it more like pluggable and, only pull in what you need to get the behaviors you want and things like that.
-
-[10:54] So definitely check that out. If you're considering some drag and drop stuff.
-
-## Redwood v7.3
-
-[10:58] **Carl Vitullo:** Redwood JS released version 7. 3. It's the app framework for startups. I'm familiar with the name, but I've never really worked on it too much.
-
-[11:08] **Mark Erikson:** Their big sales pitch was that they did single file component setups where you export a GraphQL vary as a variable.
-
-[11:17] Like, conceptually, think of like a view single file thing, where both the component and other pieces were in a single file. By convention, you export a named variable with a GraphQL query, and all the rest of the pieces just hook together from there. However, they had announced about a year ago that they were going to, quote, go all in on server components.
-
-[11:36] I've seen a lot of chatter from their developers who have been actively working on trying to figure out the mysteries of making server components work for anyone not named Vercel. And so, like I said, I haven't even looked at the release notes here, but from what I've seen, they're getting pretty close on having that working.
-
-[11:53] **Carl Vitullo:** Yeah, that's right. I think I mostly remembered the name from hearing you talk about them as people who are investing pretty seriously in server components. So yeah, new version there. Looks maybe like it has a little bit of overlap with Superbase. Just a little bit closer to the front end half of the stack.
-
-[12:11] But full stack JavaScript application framework, batteries included, backend, React, all that stuff. Definitely interesting.
-
-## React on Rails v14
-
-[12:17] **Carl Vitullo:** And our last new release that we're going to shoot through, React on Rails version 14. This is not something that I've ever made significant use of. I think one of the companies I worked at was using it because they were deeply invested into Rails.
-
-[12:32] But yeah, I mean, you know, if you're using Rails, if you are trying to use React with your Rails app, this seems, as far as I understand, this is the way to do so. So I thought it was worth shouting out a new major version.
-
-## New React release details!
-
-[12:43] **Mark Erikson:** All right, let's roll into a couple of the bigger items from this week. And by far the biggest one is, hallelujah, after two years, we finally have new actual releases of React itself.
-
-[12:57] Literally, there was a guy who had put up a website that was like, what was the time breakdown between consecutive React releases? And, you know, some of these 16 or 17 releases had been like a few months apart, and it had been two years between 18. 2 coming out and today. So, the biggest news is that React 19 is finally in beta, and the React team has an extensive blog post that covers what's actually included.
-
-[13:25] And if you've been paying attention to, you know, the discussions of the canaries and what's been available in Next. js, most of this stuff should not be a surprise. But it's worth briefly summarizing what's there.
-
-[13:36] There's what they're calling actions, which admittedly as the Redux maintainer is a little bit frustrating for me because the word action now has like 15 different overloads. There's what Redux means by it, what MobX means by it, what server components now means by it, but oh, well, whatever.
-
-[13:51] There's a lot of stuff that has to do with forms and async behavior. So if I have a form and I want to send some data to the server and I want to track pending state related to that form submission, React 19 now has multiple new features around being able to provide a callback As the action prop on the form tag itself, there are hooks for tracking form status and trying to handle transitions related to that.
-
-[14:22] As, I unfortunately keep having to say, like, I've read about this stuff, I sort of have the picture in my head of what these things roughly do. I certainly have not had time to play with them, and honestly the kind of apps that I work on today don't even necessarily benefit from this myself. But it is very interesting to see the React team investing in, like, this, this kind of overlaps with a couple of things.
-
-[14:45] One is server components in general, because, you know, Dan's pitch is that server components extend React's one way data flow model to the server. So a server component fetches some data, passes it as props to a child component, which then renders, but if you want to go back to the server component and make it actually do something to force a re render and fetch new data, you have to have some way to reach back to the server.
-
-[15:12] And so my understanding is that server actions are the equivalent of a callback from the parent, except now it's crossing the network boundary And going back all the way to the server. So there's that aspect. There's a hook for optimistic updates and a whole bunch more pieces. It's also interesting because basically all of React's lifetime, we had certain conventions.
-
-[15:33] React was a primarily single page client side app tool, although you could always use it for what we now refer to as the islands architecture, little bits of React inside of an existing page. And you're supposed to use controlled inputs. You were supposed to have a state field for, you know, your first name, your last name, field, et cetera.
-
-[15:56] And you were supposed to keep that data in state and control the input because that matched reacts concept of the UI is always based on your state. And, that still exists, and React still has a ton of logic to make controlled inputs work, but it looks like with React 19, and the new emphasis on forms and actions, that conceptually the React team is now sort of going back to the, well, okay, fine, let's use the platform and have uncontrolled inputs as a default, and grab values from the form, using a form data object. Which is also basically what the Remix team has been telling us for the last two or three years.
-
-[16:40] I, I know that the new React docs now actually have an API reference page for the HTML form tag. Like, there isn't like a usage guide page that says here's how you're supposed to use forms in React, but I believe there is an API ref page that talks about what you can do with the form tag in React. Clearly forms and data inputs are a big emphasis as part of React 19 as a whole.
-
-[17:08] Another big piece is the new use hook, which I guess this means it's finally stable? Maybe? This is the replacement for the long known but always technically internal trigger suspense by throwing a promise.
-
-[17:24] So, instead, now you call the use hook, you pass in a promise, the promise needs to be cached so that you're passing in the same promise reference across renders of the component, but that is what will trigger the suspense boundary in some parent component and make this component wait until the promise is resolved for the data.
-
-[17:44] There's a lot of stuff around the actual. RSC functionality, and there's improvements with things like, with React 19, we now actually get ref as a prop, which means that forward ref can actually go away, finally. And this required a number of changes to React's JSX transform that actually had a lot of internal tweaks that had to be made, like we don't really think about compilation or behavior step of going from JSX tags to React element objects.
-
-[18:18] React originally had the CreateElement API, eventually that got replaced with a somewhat more sophisticated compiler based JSX transform, which still did roughly the same job. And for React 19, they've done a number of changes to the internals of that to make things like passing through ref directly possible.
-
-[18:36] On that note, there was also a PR to change some of the internals where they used to always have to clone. Whatever props object was getting passed into element creation. And that's a hot path because every render is calling this element creation logic thousands of times. And I'd seen some issues filed that complained, like this is a noticeable part of React's performance overhead.
-
-[19:01] So, they've done some optimization work there, and that means that React 19 should have lower overhead in the overall rendering process because it's having to do, less object copying as part of the actual rendering step.
-
-[19:16] A couple other things, you can no longer apply default props to function components. You're now supposed to just use ES6 destructuring defaults. Apparently that still exists for classes, because you can't destructure anything there. There's also been a couple interesting changes on the build tooling side. So, one that I have a personal vested interest in.
-
-[19:37] Early last year, I had done a lot of work to modify React's build pipeline to generate source maps, because React had never shipped with source maps. That meant that any time there was an error message in production, you got a totally unreadable stack trace. And, if you were in the hopefully rare situation of needing to debug and step out of React, like outside of a function component and into the React bundle, well, React's source code is hard enough to read.
-
-[20:09] In its original form, once it's been bundled and minified, it's literally completely unreadable. And for companies like Replay that care about source maps and debugging, that was a problem for us. So I'd done the work last year to add source maps to React's build pipeline. So, in an interesting twist, a week or two ago, Andrew Clark removed my changes from the build pipeline BECAUSE React is no longer going to ship pre minified bundles.
-
-[20:38] Now, to understand some of this, React has always used a very advanced minifier called the Google Closure Compiler. It's like Terser, but much, much more powerful. And it is like the best tool for optimizing and minifying JavaScript bundles, and they wanted to shrink it as much as possible and like really do a good job of inlining functions to make things fast.
-
-[21:01] So when I did the source map work last year, I was capturing a copy of the source code right before it went through closure. But, that didn't have some of the other optimizations that Closure does besides the final minification step. So, what they've done is they've dropped shipping source maps and they've stopped pre minifying the bundle, but they are still doing the optimization and inlining step with Closure. So, in the future, as a, or actually as of the latest beta, what's in the bundle is no longer react dom. production. min. js, which is what it's always been, but rather a react dom. production. js that's still like 500k, un minified, but it's got all the source code optimizations applied.
-
-[21:52] So, your application build step will now do the final minification process out of that. One other interesting side effect here is that if you look at this, strictly speaking, actually ReactDOM. production is now like a six kilobyte file. And this is unexpected. And in fact, if you look at BundlePhobia for ReactDOM 19 beta, it thinks that ReactDOM is now only six, like, like three and a half K minified.
-
-[22:19] Which is clearly not the case, and it's because the Reconciler logic is now in a separate file, React dom client . If you think about writing web apps now, ever since React 18, when we switched over to the new CreateRoot method, that comes from the react-dom/client entry point. So, they've re architected the bundles so that the bulk of the code is in that slash client file, and because of that bundle phobia, it doesn't actually trace through and connect the dots to see that both these files end up getting used in a real app.
-
-[22:55] Finally, a couple other bits that are stirring up some controversy. So a couple of years ago, the React team announced that they were patching the fetch method in order to allow caching in case, you know, multiple components are trying to make similar requests on the server side.
-
-[23:09] And many people got pretty justifiably angry about this because we learned back in the mid tens, patching global objects in JavaScript is a really bad idea. So the React team has finally given up on that and they've reverted those changes for the final release. And they've said. If you want to make sure you're deduplicating requests, wrap your request logic in the cache method.
-
-[23:32] Which makes it really ironic that Andrew Clark just tweeted today that they might actually end up patching the date object down the road in order to prevent hydration mismatches. I don't know. I understand why he says that. I am not sure this is a good idea. I don't have a better solution. So, we'll see how this one pans out.
-
-[23:53] **Carl Vitullo:** Yeah, I am empathetic to that. And he does talk about, as long as it's standards compliant, nobody has cared about patching internals, people haven't complained about polyfills, and dates are such a pain in the butt when you're doing hydration. Just, you know, it's so easy to have them accidentally rely on current time, which then causes a hydration warning and is just super annoying.
-
-[24:14] So I can understand the motivation for doing it, but yeah, agree, it's, you know, patching stuff is scary, it's risky.
-
-[24:19] **Mark Erikson:** So we've got a beta out, and I actually was not even expecting a beta this soon. I did not expect that we would see a beta for another couple weeks, and it would actually be announced at React Conf.
-
-[24:31] I do not expect a React 19 final at React Conf. I could be surprised, but the fact that it's only been in beta for a couple weeks, Plus, I'm still seeing lots and lots of PRs flying through in the React repo. I, I would not expect React 19 final for at least another three or four months, but I have no specific info on that either way.
-
-[24:54] **Carl Vitullo:** Yeah, I also want to call out a couple of other less conceptual changes, they seem a little bit more like pragmatic, use the platform kind of adjustments. React 19 adds support for document metadata directly in rendered React output. Previously, this is the sort of thing that you would use a tool like React Helmet to render.
-
-[25:14] You know, if you're putting document metadata, title, link, meta tags, stuff that normally lives in the head. Part of your HTML. Now React is adding support for rendering that pretty much anywhere. And then React will do the work to figure out that it needs to go in the head, and putting it there at all. That's pretty interesting. I have been routinely let down by React Helmet, which it just has a lot of bugs.
-
-[25:39] It was one of the first open source React libraries that I ever remember coming across like way back in 2013 14. And it was written by the NFL, which always struck me as like, what? The NFL? So it Great name, like the NFL putting out something that renders to the head and calling it helmet is just like, oh my God, that is the perfect name.
-
-[26:01] So I love that. But then I just, oh man, I ran into so many weird bugs and edge cases every single time I tried to use it, which often I ended up compromising on behaviors because it just didn't work and there was no viable alternative. So excited to see. First party support for that without having to use a janky out of date library from eight years ago.
-
-[26:21] So that's nice. Kind of related to that, so, you know, keeping the theme of dumping stuff in your rendered output, they're also adding better support for style sheets in rendered output. They call this out in the release page saying, Style sheets require careful positioning of the DOM due to style precedence rules.
-
-[26:38] And I guess this is going to be a little bit related to the patching platform things. They've got a precedence prop on these link tags. So you know, so not only can you now render link tags in your output instead of having to figure out how to put them in your head, then you can just put them in your rendered output anywhere, signal what level of precedence they should have, and React will do the work to figure out.
-
-[27:04] Where it should live. Interesting. Seems to unlock a lot of new ways of using CSS in your React projects. It strikes me that it may inspire a new wave of, like, maybe not CSS in JS libraries, but may inspire new ways of Making use of CSS from your React components, of scoping your styles to your logic.
-
-[27:29] Definitely find that interesting. And another slightly related feature is the port for async script tags they talk about. Previously it was considered kind of, actually I don't know that I ever saw enough discussion of this to say considered an anti pattern. Just didn't feel right to render a script tag from your React component like you're already in JavaScript.
-
-[27:48] Why would you then load more JavaScript from your rendered output of your component? It feels weird, but they're calling out support for async scripts normal. They say normal scripts and deferred scripts, load and document order, which makes rendering these kind of scripts deepen your component tree challenging, you know, that's kinda the problem I was articulating there in React 19.
-
-[28:05] We've included better support for async scripts by allowing you to render them anywhere in your component tree without having to manage relocating and duplicating script instances. So, that's, again, a little bit interesting. I can imagine, I have run into situations where using React is maybe not the best tool for a specific type of UI.
-
-[28:25] You know, like, things like A complex map, or a highly complex and interactive data visualization, or there's a lot of things that you might want to render to like a canvas, or to WebGL, or in an iframe, or things like that, where React either can't do it because of security limitations, or because, you know, you can't render A component in WebGL or Canvas.
-
-[28:50] So there are circumstances where I've either bailed out of using React and just said like, Nope, everything inside this component renders once, and then some other script takes over for it. So in circumstances like that, I could see this being a significant experience improvement. And again, building on that, they're also adding support for preloading resources.
-
-[29:09] So the React DOM package now exports a couple of new, I guess I'll call them helper functions, listing them here. PrefetchDNS, Preconnect, Preload, and Preinit, which are similar to like the link or meta tags. You give it a URL and. Sort of a configuration object, and it signals to React that you will want these assets, but not right now.
-
-[29:30] It's not like rendering out a style tag or a script tag, but it's saying, here's a resource. I want you to resolve the DNS, or connect to the resource, but don't start loading it yet, or start loading it, but don't start parsing it yet. So it looks like a lot finer grain control over external resources.
-
-[29:49] So combined with greater level of control over how resources get loaded, and then clearer, simpler semantics around taking those resources and rendering them from a component, It does seem like it unlocks a lot of really powerful behaviors. I think it's going to introduce some churn into the ecosystem, but I can at least see, I have run into a lot of problems where I can see this set of tools being a pretty big unlock.
-
-[30:17] So excited to see it.
-
-[30:18] **Mark Erikson:** And then one more item that's all the way down at the very bottom of the beta release notes is support for custom elements aka web components finally work properly inside of React. I've never used web components. I've tried to read the threads that have had hundreds of comments and complaints.
-
-[30:40] I have a vague partial sense of what the problem space is. In general, like with React, we pass props and we pass real JavaScript values, objects and numbers and whatever. But with web components, there's the issue that, you know, like there, there's something about the attributes versus properties distinction.
-
-[30:59] Like HTML is you're defining attributes that are strings. DOM objects have properties that can be mutated and these are not always the same thing. So like you, you can't just always directly pass real objects into a custom element, the same way we would pass a prop from a parent to a child in React.
-
-[31:21] And there's been like a whole bunch of other interop issues trying to render web components inside of a React component and pass data and handle events between these. And so the web components community has complained for years that, well, every other UI framework manages to make this cooperate. Why can't React do it?
-
-[31:43] it's a reasonably fair complaint, but there'd been an issue filed all the way back in like 2016, 2017 saying, so React, are you finally going to make this just work? And it took another four or five years before an engineer from Meta actually sat down and implemented it. Now, apparently part of the problem.
-
-[32:02] It was unclear what the exact behavior semantics should be. I guess there is no single specification for how Web Components define, like, what kind of event props they take. And a lot of questions about the exact mechanisms for passing Props from a React component to a web component. So like the React team's like, well, okay, there's like a half dozen ways we could do this, and these are kind of mutually exclusive.
-
-[32:27] We're not the experts here. How would the web component community like us to build this? And everybody had very different opinions. So that was part of the reason why this took multiple years to happen. But, eventually, there was some adequate kind of consensus reached, and so a meta engineer actually went in and did a ton of work, a couple massive PRs to implement the support, and it got merged, like, two years ago, but it was always in, you know, under a feature flag, just in the experimental branches.
-
-[32:56] So, React 19 now finally ships with, quote, proper support for web components, and all three people who care cheered.
-
-[33:06] **Carl Vitullo:** Well, one of them is in the chat here, definitely interesting, I don't know. Like you said, I've been loosely paying attention to it for years at this point, and generally loosely paying attention to web components for even longer than that, and Cool.
-
-[33:18] I don't know. Good to see. I will continue to loosely pay attention to see what kind of effects it has on the ecosystem, but I'm a little bit skeptical it's gonna make big waves.
-
-## React Native 0.74.0
-
-[33:29] **Carl Vitullo:** Cool. Okay, React Native. They have officially released their 0. 74 version, which is gonna be I actually talked to someone when I was at React Miami about some of the work they've been doing.
-
-[33:40] So the, the One of the things included in this is Yoga 3. 0. Yoga is the Flexbox layout engine re implementation that powers React Native. It's, it's one of the core technologies that facilitated React Native approximating web layout. And I had, I had spoken with someone at React Native who said that it took them a long time to sort of spin back up on development, you know, some internal priorities and, people moving, they lost some expertise on that. So they had to reinvest, re relearn how to develop it.
-
-[34:15] So cool to see that in here. It looks like it fixes a couple of layout bugs that were, you know, non standard. They were different from the semantics on web. It was something about. Like, you know, row reverse columns with like start and end edge was not behaving correctly previously, and now it is. So you may find some weird margins.
-
-[34:34] They're also removing a tool called Flipper by default. You can still add it back in. Inspecting React Native layouts, network requests. Uh, it sounds like it has a lot of overlap with the React Dev tools in, browsers. Uh, it was deprecated in 0. 73. Thank you, Cedric and chat. And is now being removed by default.
-
-[34:52] **Mark Erikson:** I'm very curious what the debugging story is. As usual, I have not worked on React Native. I don't know what the debugging process is overall.
-
-[35:00] But if they're removing Flipper, I'm curious what the intended workflow is for debugging tools. And I see someone says Chrome DevTools.
-
-[35:07] **Carl Vitullo:** Yeah. I think when I was using React Native, this is now close to three years out of date. I believe I was already using the Chrome DevTools at that point. So it sounds like this shouldn't be too impactful on too many people.
-
-[35:19] Yeah. Community CLI for React Native, I guess, to make an analogy, sort of the create React app for React Native is now. Using Yarn 3 for new projects by default. So that's a reasonably opinionated change. I know that Yarn 3 has very different semantics from Yarn 2.
-
-[35:38] **Mark Erikson:** My, I would assume that they're going with Yarn's node modules behavior by default rather than the attempt to do the plug and play, don't extract everything on disk approach that Yarn 2 tried and failed to get out there.
-
-[35:52] **Carl Vitullo:** Can confirm using node-linker/node-modules.
-
-[35:55] **Mark Erikson:** I actually got to meet the primary maintainer of Yarn, Emil Nusson in Paris.
-
-[36:00] We talked a bit about, you know, where Yarn stands. Like Yarn 4 is out, but apparently kind of, Came out a little past, you know, whatever preparation deadline the React Native team had for trying to figure out things on their end. I don't think there were too many big changes between Yarn 3 and Yarn 4, but it is interesting.
-
-[36:18] You know, we mentioned earlier that, you know, PNPM has gotten a lot of popularity. And so, like, a segment of the ecosystem is going to be pretty, you know, pretty much set on Yarn 3 for the foreseeable future.
-
-[36:30] **Carl Vitullo:** Whoa, I consider myself a Yarn user, and I didn't even know they had a version 4. 0. Looks like it was released in October of last year. Interesting. Cool.
-
-[36:38] React Native Navigation version 7 is out, which looks like some of the major improvements there are around the configuration of it. Previously, talked about how previously there were of difficulties with Types, and basically you needed to keep your types manually synced with your route configuration.
-
-[36:57] So it looks like they've made some general architecture improvements, such to where TypeScript types can now be inferred from the root navigator with a static param list type, and it'll be available anywhere UseNavigation hook. So that's cool. Needs a, like, one line script. Global namespace adjustment in TypeScript in order to enable.
-
-[37:16] But that seems like a really big improvement. Type support in your navigation is definitely a lot more safe. So that's really good. And last React Native thing I'll do is just a small shout out. There's a Vision Camera package that just released a 4. 0. Looks like it supports a lot of Powerful camera stuff, you know, like QR codes and like some other visual recognition stuff.
-
-[37:41] looks like a really cool project and definitely some big React Native relevance.
-
-[37:46] **Mark Erikson:** On the note of React Native, I was at a React Connection and React Native Connection conference in Paris last week.
-
-[37:53] And I've always been a web dev, but it was interesting to me just sitting through the React Native talks and half of the material was familiar, half of it was like a completely different ecosystem that I'd never heard of. It was very interesting to see how there's just this entire different branch of the React ecosystem that I basically didn't almost even know existed in terms of mindset and what they're dealing with.
-
-## Kotaken, RSCs with just Bun
-
-[38:17] **Mark Erikson:** So, rolling through a few items very quickly. A new experimental server component framework that I had never even heard of until I saw it pasted in the links like an hour ago called Kotaken. And the interesting sales pitch here is what would a React framework look like if Bun we re the only tool in the tool chain.
-
-[38:37] This sounds very interesting in a lot of ways. Certainly the tool setup makes it sound like it's a lot simpler. It sounds like it has some interesting variations in how they're trying to use server components. I assume based on the description that it's brand new and highly experimental, but you know, another example of playing with the baseline ideas of server components and seeing how a different framework makes different choices around it.
-
-## Bun 1.1
-
-[39:02] **Mark Erikson:** On that note, Bun 1. 1 is out and it actually has Windows support. And as the, you know, the 1 percent of web developers who is actually a Windows user, cool. Yay. I'm excited by this. I actually played with Bun briefly on a very small work project a couple of weeks ago.
-
-[39:19] I was trying to prototype some SQL changes and Bun has SQLite support built in. So rather than try and mess with Postgres adapters or whatever, I just used that and it ran, it worked. I don't have further experience to report on, but I'm very excited to see BUN support getting fleshed out.
-
-## JSR, by Deno
-
-[39:37] **Carl Vitullo:** I wanted to talk about JSR, the JavaScript registry being put out by the Deno team. New registry is pretty interesting to me. We've seen a lot of experimentation in package managers, but ultimately all of them still hit NPM.
-
-[39:52] And the Deno team was talking a little bit about how that's a bit of a shame. We've had so much experimentation happening, but so little of it happening At that level, where a lot of behaviors are ultimately driven from. A couple of notable changes that they've done, this is ESM only, which is definitely going to be a pretty big level up for React. The ecosystem as a whole, I think, just, you know, ESM versus CommonJS has been such a pain for so long. I think a clean break in a new package registry might be a bit of a kick in the pants, as it were, just to kind of force the issue and say like, nope, clean break, new stuff.
-
-[40:33] They do say that JSR is backwards compatible with NPM, so that should facilitate migration at least. Obviously moving to a whole new package registry is a bit of a tough sell. Maybe not as tough as something like switching from Angular to React. As it were, but I think it's, I think it's up there. You know, if you are trying to use a new registry, but like, oops, there's no express, like that's just pretty hard.
-
-[40:58] A lot of the assumptions that you have about what open source code is going to be available. It may not be available. So I think that's going to be a little bit tough. They also said some interesting stuff like TypeScript has emerged as not only a way to write JavaScript with compile time type checking, but as a test bed for the latest JavaScript language features coming out of TC39.
-
-[41:17] That rang really true to me. So seeing a team push the boundaries of something as, you know, maybe a little bit esoteric and like less thought of as a package registry is, I don't know, I appreciate that they are also following the cutting edge Broadly across the rest of the ecosystem as well. They talk about Node is no longer the only relevant JavaScript runtime outside the browser.
-
-[41:40] Some other really cool stuff. I think something I saw was package provenance through a tool called SIGstore, this is sort of like, Supply chain attacks, if you're familiar with that, where how do you know that the code you believe you're installing on NPM is actually what you expect?
-
-[41:58] So provenance is dealing with that sort of end to end guarantee that something is what it claims to be. There have been a couple of notable Vulnerabilities, actually not even vulnerabilities, just straight up attacks where an open source project solicits a new maintainer, has malicious intent and publishes some kind of script, some kind of backdoor.
-
-[42:19] You know, whether that is trying to attack the end application that is consuming the library, or I think more frequently they have been attacking developer machines to then try to gain access to other parts of the system. I know there was a notable example a couple of months ago. Maybe years at this point ago, where somebody installed a crypto miner into a install script.
-
-[42:42] So people's developer laptops started mining crypto for them. So all that to say, package provenance as a core part of the package registry, I think is a really important area to explore. And contrasting something like package provenance Verifying contents with the, I would say, kind of failed attempt NPM did of doing like NPM audit.
-
-[43:05] You know, that was so unsuccessful that like Dan Abramov put out a post talking about how it was broken by design, like just the fundamental assumptions it made about security and how you address security issues being so wrong as to be harmful.
-
-[43:18] I have a reasonably high degree of confidence in the Deno team generally. You know, it's a project started by Ryan Dahl, who created Node in the first place. So having him come back and say, I got some things wrong. I'm going to try again in a new context with Deno. And then now expanding that into, I think that The Node ecosystem got some things wrong with how packages work.
-
-[43:40] I'm going to try that again. I think that's very exciting. I am not going to immediately jump on it and start using it for everything, but I am going to be paying pretty close attention because I think this is a serious attempt at a very complex and large problem space. Let me just run through a couple of guarantees, expectations that the JSR team has put out.
-
-[44:02] As for what a package manager should do, they say it should embrace ESM as the web standard for JavaScript modules, should be designed for TypeScript from first principles, should be simple, fast, provide excellent developer experience, should be free and open source and work anywhere that JavaScript does, and should build on the success of NPM, not fork it.
-
-[44:20] Seems pretty good. There's a couple other really good posts that I'm just going to dump in chat here. Those will be in the show notes as well. Some other things that I think are important, every module must be scoped, which I think is a positive change. It's always a little bit funny, you know, on NPM modules that don't have a scope feel somehow more official in some way.
-
-[44:39] It's so just requiring that all packages are scoped kind of eliminates that funny little. Bifurcation in the ecosystem. Like, is it scoped or is it not scoped? It also has a concept of multiple scopes per account. I saw a mention of four scopes per account as a limit. So being able to manage different scopes without having to set up like a dummy account, which I believe is how that has to work on NPM.
-
-[45:02] It's been a while since I've had to deal with that myself, but that seems like a really good idea. Interesting, useful, evolution of the ecosystem.
-
-## ⚡️ Why I like React (Even in 2024) ⚡️
-
-[45:09] **Mark Erikson:** And then hitting a couple of the lightning items really fast. We've commented how there's been a whole series of articles and tweets and complaints about, you know, being, people being frustrated with. React as a technology, based on the slow pace of development, or, you know, poor communication from the React team, or, you know, React just doesn't feel as modern as other frameworks that are adopting things like signals, etc.
-
-[45:36] And so, I thought this post on why I like React in 2024 was well written, and just a decent alternative train of thought to some of the negative chatter.
-
-## ⚡️ Netlify updates their Next.js runtime ⚡️
-
-[45:46] **Carl Vitullo:** Netlify put out a blog post introducing a new Next. js runtime, which I was pretty surprised about.
-
-[45:52] I think of Netlify as a static site host. When I think Netlify, I generally think Buildstep. Static assets, essentially static HTML and JavaScript served by a CDN. So seeing them talk about a runtime for a framework that I consider to require a server, it's pretty interesting to me. That seems like a pretty large evolution in their product offering in a pretty interesting way.
-
-[46:18] And. You know, Vercel's level of influence on React and it's coupling to the cloud runtime environment has been a little controversial to say the least. So seeing some more competition there is definitely pretty interesting. I guess relevant to that, I also saw somebody wrote a blog post discussing how Cloudflare is the best alternative to React.
-
-[46:40] Vercel, which I'll share as well while we're talking Vercel competitors. Definitely interesting. I guess this is not a new thing from Netlify. They say this is Next. js runtime version 5, so definitely pretty cool. Supports the app router, fine grain caching, on demand and time based revalidation. Oh, maybe a big one.
-
-[46:59] This is a problem that I've run into on Netlify using Next. They now support the Next image component. By default, so being able to optimize your images automatically through the next image package is definitely a pretty big, like, performance and user experience win. So that seems pretty good.
-
-## ⚡️ Design Principles behind the Next.js App Router ⚡️
-
-[47:18] **Mark Erikson:** There was also a really good tweet from one of the Vercel devs, I think just like a day or two ago, talking about design principles behind the Next. js app router. And frankly, it was an extended length tweet that really was a miniature blog post, and it talked about some of the ideas that it's really about layouts. and being able to identify which pieces of the page need data and which can be pre cached. And the fact that they actually don't expose things like the request object directly so that they can better detect which pieces could be cached versus which pieces have to be fully re rendered on the server side.So, whether or not you like the approach, it's clear that they've put a lot of actual thought into it. .
-
-## ⚡️ Node.js website redesign ⚡️
-
-[48:04] **Carl Vitullo:** I saw a blog post from Node. js about their website redesign. I thought this was a fun, technical write up to white paper, relevant to a lot of, relevant to our jobs. You know, like we do lots of website redesigns. I thought it was pretty cool. Just to see, you know, they talk about a failed attempt at restarting it with a nodejs.
-
-[48:25] dev domain. In retrospect, this might have unintentionally doomed the project from the start. Yeah, it seemed like a really good breakdown of the technical challenges and organizational struggles of Doing a major website overhaul. So yeah, definitely check that out. They talk about reassembling the airplane while in flight. Always a fun metaphor.
-
-## ⚡️ Dives into React features ⚡️
-
-[48:44] **Mark Erikson:** There's a website I've run across that has been doing a whole series of dives into the actual React codebase and picking out specific features like the new Use Optimistic hook. And talking about how they actually are implemented in React.
-
-[48:59] And one of React's strong points has been that it is a black box and you don't need to know how it works internally to be able to use it. You need to understand the mental model of the data flow. But you don't have to dig into the code and worry about the actual implementation details. But, I frequently see people asking, how does such and such a feature in React work?
-
-[49:20] And so I appreciate that the person behind this site has been doing dives into the codebase to try to explain things.
-
-## ⚡️ Honeypot releases Node.js documentary ⚡️
-
-[49:27] **Carl Vitullo:** The people behind the React. js documentary, Honeypot. io, which I believe is a recruiting platform, put out a documentary on the origins of Node. js. I haven't been able to give it a watch yet, but their React. js documentary was. Very good. Got to watch that at, on the big screen at React Miami last year, and I got a chance to speak with the filmmaker who put it together, who did all the recording, and found her very impressive. She's very skilled. So definitely check that out.
-
-## ⚡️ Flow ships React features ⚡️
-
-[49:56] **Mark Erikson:** The flow type system, which was a competitor to TypeScript and then in a sense, basically died outside of Facebook like three or four years ago, because the flow team didn't ship often and they didn't really, frankly, care about the community, has still been working on things and they recently announced some new language level features for React components. I think we might've touched this briefly last time, but they've added some actual syntax for defining components and prop types in React, which is interesting
-
-## ⚡️ Vercel updates pricing ⚡️
-
-[50:26] **Carl Vitullo:** Another small update, Vercel is cutting prices a little bit, or they are updating their Infrastructure pricing, which they expect to reduce costs for most users. So, cool. Looks like it's not a major alteration. It's not going to be like an order of magnitude fix, but it's include some like finer granularity on bandwidth costs.
-
-[50:48] So instead of per hundred gigabytes of bandwidth, it's per gigabyte. Well, which should help a lot. I saw it discussed, you know, if you use 105 gigabytes of bandwidth, now you'll be billed for 105, not 200. So a couple of little things like that. I saw some chatter about a limited number of people who had costs shoot up quite a bit, but that seems to be relatively rare.
-
-[51:11] if you have a very particular performance characteristic on how you're using the Vercel platform, it may not be a big cost savings, but it just, you know, as I was reading these, as they're breaking down the price changes, it looks generally like I would expect it to reduce costs.
-
-## ⚡️ RedwoodJS compares data fetch methods ⚡️
-
-[51:28] **Mark Erikson:** And then finally, the last one I'll mention is the Redwood JS, which we mentioned earlier, you know, had originally been focused on using GraphQL to define data fetching needs for React components.
-
-[51:40] And over the last year, they've been doing work to adopt server components. And they just put up, they put up a blog post that. Showed some comparisons in data fetching between the next AppRouter, the next PageRouter, Remix, and Redwood. there are some variations in how the tools work and some of the trade offs. I always appreciate posts that actually try to cross compare things.
-
-## ⚡️ Kuto, reverse JS bundler ⚡️
-
-[52:02] **Carl Vitullo:** I saw a neat project called Kuto. They called it a reverse JavaScript bundler. And it's around reusing your code as you're shipping updates to your application. This is something I've thought about a number of times at different companies I've worked at, but never made any significant headway on actually addressing.
-
-[52:22] You do a production build, you produce your new set of bundles, you upload those to the, to your production server. And you know, like most of that code didn't actually change. Like presumably just made, A bunch of small alterations. Like, I can't imagine that any new production release affects more than like, what, like one to five percent of your overall code?
-
-[52:43] Maybe even less when you start including dependencies and, you know, vendored code. So it looks like this is trying to sort of do a diff, kind of ship a diff on production releases, which is super cool. Like, if you can Do a new production release and know that much of the code that didn't change is still going to remain cached by your existing users, then that seems super cool.
-
-[53:06] They say, you know, just really quick, like first line of the page, for a real world site with three megabytes of JavaScript, updating the React dependency resulted in a 71 percent smaller download and a 28 percent faster startup time on an old phone. So I don't know exactly what the process of using this tool looks like, but.
-
-[53:24] Seems like a pretty compelling performance improvement. Reverse JS bundler, new category of infrastructure maybe.
-
-[53:31] That's everything I got, thank you everyone for joining us. We'll be back at the end of this month because we're recording late. We record on the last Wednesday of every month here in the live stage of Reactiflux, and we'll try to get back in your pod feed as soon as we can after that.
-
-[53:45] We gather sources from This Week in React by Sebastian Lorber, from Bytes. dev, Reactstatus, React JS Weekly, react Digest, the React JS subreddit here in Reactiflux, and direct from people publishing articles. If you see anything newsworthy, definitely let us know in the #tech-reads-and-news channel in Reactiflux, or you can email me directly at hello@reactiflux.com. Send that with TMIR in the subject line just to help me find it. It's an acronym for the show.
-
-[54:13] I read literally every email that comes in, usually even the ones that are marked as spam, so if you send me an email, it'll go in my brain.
-
-[54:20] If this is a show that you get value from and want to support, best way to do so, share it, send it to your co workers, say, hey, this seems like a really useful way to stay on top of everything.
-
-[54:29] And if you could leave us a review on Spotify or whatever platform that you listen on, that would be super helpful as well. I'm also seeking sponsors for this. I'm trying to professionalize. I've got a new logo. Looks all nice and fancy. If you are interested in getting your product or company in front of a group of professional React engineers, definitely reach out.
-
-[54:50] Thanks so much. Talk to you next month.
diff --git a/src/transcripts/tmir-2024-05.md b/src/transcripts/tmir-2024-05.md
deleted file mode 100644
index ae67c12..0000000
--- a/src/transcripts/tmir-2024-05.md
+++ /dev/null
@@ -1,640 +0,0 @@
----
-title: "This Month in React, May 2024: Updates from React Conf"
-date: 2024-05-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- [9600 laid off from 36 companies](https://layoffs.fyi/)
-- New releases
- - [[02:07](#docusaurus-33)] [Docusaurus 3.3](https://docusaurus.io/blog/releases/3.3)
- - [[02:17](#mantine-790)] [Mantine 7.9.0](https://mantine.dev/changelog/7-9-0/)
- - [[02:30](#astro-48)] [Astro 4.8](https://astro.build/blog/astro-480/)
- - [[03:18](#redwood-75)] [Redwood 7.5](https://github.com/redwoodjs/redwood/releases/tag/v7.5.0)
-- [Upcoming conferences](https://react.dev/community/conferences)
- - [[03:32](#render-atlanta)] [Render ATL](https://renderatl.com/) June 12-14, 2024. Atlanta, GA, USA
- - [[03:53](#future-frontend)] [Future Frontend](https://futurefrontend.com/) June 13-14, 2024. Helsinki, Finland
- - [[04:49](#react-norway)] [React Norway](https://reactnorway.com/) June 14, 2024. Larvik, Norway
- - [[05:01](#react-summit)] [React Summit](https://reactsummit.com/) June 14 + 18, 2024. Amsterdam, Netherlands (+remote)
- - [[05:15](#react-nexus)] [React Nexus](https://reactnexus.com/) July 4-5, 2024. Bangalore, India
- - [[05:43](#chain-react)] [Chain React 2024](https://chainreactconf.com/) July 17-19, 2024. In person in Portland, OR, USA
- - [[06:12](#the-geek-conf)] [The Geek Conf](https://thegeekconf.com/) July 25, 2024. Berlin, Germany
-- [[06:53](#react-conf-recap)] [React Conf recap](https://react.dev/blog/2024/05/22/react-conf-2024-recap)
- - [Livestream recording](https://www.youtube.com/watch?v=T8TZQ6k4SLE) (165k views 🤯)
- - [Seth Webster's mentioned thread](https://twitter.com/sethwebster/status/1792739000366809363)
- - [[08:21](#react-19-rc)] [React 19 RC](https://react.dev/blog/2024/04/25/react-19)
- - Talks:
- - [What’s new in React 19](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=8880s) by [Lydia Hallie](https://twitter.com/lydiahallie)
- - [React Unpacked: A Roadmap to React 19](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=10112s) by [Sam Selikoff](https://twitter.com/samselikoff)
- - [[09:44](#server-components-on-expo)] [React Server Components Demo on Expo](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=20765s) by Expo Team
- - [[12:12](#react-for-two-computers)] [React for Two Computers](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=18825s) by [Dan Abramov](https://twitter.com/dan_abramov2)
- - [[15:46](#qas-with-react-and-react-native-core-team)] [React Q&A](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=27518s) hosted by [Michael Chan](https://twitter.com/chantastic)
- - [React Native Q&A](https://www.youtube.com/watch?v=0ckOUBiuxVY&t=27935s) hosted by [Jamon Holmgren](https://twitter.com/jamonholmgren)
- - [[16:33](#react-compiler)] [React Compiler](https://react.dev/learn/react-compiler)
- - [Compiler playground](https://playground.react.dev/)
- - Lauren Tan’s [walkthrough of using the compiler and seeing the output](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=18825s), and Sathya + Mofei’s [deep dive into how the compiler works](https://www.youtube.com/live/0ckOUBiuxVY?si=yK4-4Ph_tm91zO8V&t=9303)
- - [Jack Herrington’s compiler walkthrough](https://www.youtube.com/watch?v=PYHBHK37xlE)
- - [Recommended for library authors to ship compiled artifacts](https://twitter.com/_gsathya/status/1792968851212169441)
- - [A talk from Lauren Tan in 2016](https://speakerdeck.com/poteto/embercamp-2016-i-can-write-my-app-with-no-handlebars-declarative-templating-in-ember) that’s spiritually related to React Compiler
- - [[23:39](#remix-is-merging-back-into-react-router)] [Merging Remix and React Router](https://remix.run/blog/merging-remix-and-react-router)
-- [[28:08](#effect-js)] [Effect](https://effect.website/blog/effect-3.0)
- - [Great 10 min intro](https://www.youtube.com/watch?v=SloZE4i4Zfk)
- - [Production-Grade Typescript talk](https://www.youtube.com/watch?v=PxIBWjiv3og) at an event they hosted
-- [[34:23](#forensics-of-react-server-components)] [The Forensics Of React Server Components](https://www.smashingmagazine.com/2024/05/forensics-react-server-components/)
-- [[35:39](#nextjs-v15-rc)] [Next 15 RC](https://nextjs.org/blog/next-15-rc) ([tweet](https://twitter.com/nextjs/status/1793670209443680382))
- - Unrelated: [Vercel raised $250m](https://www.reuters.com/technology/vercel-completes-250-mln-series-e-round-325-bln-valuation-2024-05-16/)
- - [[37:05](#its-not-just-you,-nextjs-is-getting-harder-to-use)] [It’s not just you, Next.js is getting harder to use](https://www.propelauth.com/post/nextjs-challenges)
-- React Native:
- - [[39:21](#react-native-new-architecture-beta)] [“New Architecture” is now in beta](https://github.com/reactwg/react-native-new-architecture/discussions/189)
- - [[40:25](#expo-is-now-the-recommended-framework)] [“useFrameworks”](https://reactnative.dev/docs/environment-setup) - Meta announcing that you should use Expo by default.
- - [[41:17](#react-native-skia-on-webgpu)] [React Native Skia](https://www.youtube.com/live/s0wn7qpBoB8?si=HDsihzf803fTLlIc&t=2802) updates
- - [[43:39](#react-native-ide)] [React Native IDE](https://ide.swmansion.com/):
- - [[45:03](#react-native-on-tvs)] [Amazon doing a keynote talk on using React Native for TV](https://conf.react.dev/talks/14) and other devices.
-- [[48:04](#lightning-round)] ⚡️ Lightning round ⚡️
- - [[48:07](#speculation-rules-api-in-chrome)] [Speculation Rules API](https://developer.chrome.com/blog/speculation-rules-improvements) in Chrome
- - [[48:33](#josh-comeaus-post-on-usedeferredvalue)] [Snappy UI Optimization with useDeferredValue](https://www.joshwcomeau.com/react/use-deferred-value/)
- - [[49:24](#bluesky-engineering-culture)] [BlueSky Engineering Culture](https://newsletter.pragmaticengineer.com/p/bluesky-engineering-culture), from The Pragmatic Engineer
- - [[50:16](#why-patching-globals-is-harmful)] [Why Patching Globals is Harmful](https://kettanaito.com/blog/why-patching-globals-is-harmful)
- - [[50:54](#new-webkit-features-in-safari-175)] [Webkit features in Safari 17.5](https://webkit.org/blog/15383/webkit-features-in-safari-17-5/)
- - [[53:56](#why-react-query)] [Why React Query?](https://ui.dev/why-react-query) (and upcoming React Query course)
- - [[54:45](#we-can-have-a-different-web)] [We can have a different web](https://www.citationneeded.news/we-can-have-a-different-web/)
- - [Athena Crisis is now open source](https://cpojer.net/posts/athena-crisis-open-source)
- - [Security Risks of Postman](https://www.leeholmes.com/security-risks-of-postman/)
- - [Angular v18 is now available!](https://blog.angular.dev/angular-v18-is-now-available-e79d5ac0affe)
-
-**Carl Vitullo:** Hello everyone. Thank you for joining us for May's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. We have so much news this month because there was ReactConf and so many of the things that we had been discussing over the last three or four months actually like dropped and landed. [00:23]
-
-And are available and there are eight hours of talks discussing all of the things that we have been like punditing and talking heads about direct from the source. So I am excited about that. We're going to dig into it. [00:34]
-
-But first, I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux, where I run community programs like these and build tools to help keep the community running. [00:44]
-
-Before I hand it off to Mark I'm gonna hand it off first to our new guest host for the month where it's a bit of a trial. [00:50]
-
-**Mark Erikson:** I think he's gonna do fine! [00:51]
-
-**Carl Vitullo:** Mark, thank you for introducing me to our new guest host! Do you want to introduce yourself? [00:56]
-
-**Mo Khazali:** Nice to be here with you all. So my name is Mo. I head the mobile team at Theodo and I've been sort of an active part of the React and React Native ecosystem for a few years now. And I help organize some meetup groups like the React Native London meetup and have here and there dabbled in some open source contributions within the ecosystem with libraries like Expo and Tamagui. [01:16]
-
-Very happy to be here with you all and looking forward to chatting all things React Native. [01:20]
-
-**Carl Vitullo:** Awesome. Thanks for joining us. [01:21]
-
-**Mark Erikson:** And I'm Mark Erikson, my day job is working at Replay. io, where we're building a time traveling debugger for JavaScript. And outside of Replay, I do Redux stuff. [01:30]
-
-**Carl Vitullo:** Some quick hits before we get into the main news. [01:33]
-
-## Layoffs news
-
-**Carl Vitullo:** Quick layoffs overview from layoffs. fyi. This month, over May, there were 9, 600 laid off. from 36 companies, which is down quite a bit actually from April. last month in April, there were 22, 000 laid off from 57 companies. So that's improving a little bit. So far, this year has been substantially better than last year, but that's not saying very much because last year was like, the worst year in the last 20 years. So improving steadily is still not great. [02:02]
-
-## New Releases
-
-**Carl Vitullo:** Some new releases. It looks like there's been a couple of new releases in sort of the fallout of React 18. [02:07]
-
-## Docusaurus 3.3
-
-**Carl Vitullo:** 3 coming out, there's a Docusaurus just doing a minor release on 3. 3. Nothing too new there, it's basically just like fixing some new warnings that popped up. [02:17]
-
-## Mantine 7.9.0
-
-**Carl Vitullo:** Mantine has also put out a 7. 9. 0 release. Mantine seems pretty cool, I haven't played with it too much myself, I don't play with very many UI toolkits, but this is high on my list of ones to look at. [02:30]
-
-## Astro 4.8
-
-**Carl Vitullo:** There's also Astro 4. 8, which just came out. They're coming out with a couple of new things that look pretty interesting. You know, also like classic performance improvements and bug fixes. They have an experimental Astro Actions, which, you know, okay. We have one more thing in the ecosystem called Actions, which is unfortunate, they pitch it as, "actions make it easy to define and call backend functions with full type safety from your client code." And full type safety on a backend request is wonderful. Happy to see that. That's pretty great. [03:00]
-
-They also have an experimental request rewriting feature. Request rewriting is pretty important on a large production application. It's where you receive a request on one URL and handle it internally as if it was a different URL. So you can do stuff like aliases or rewrites or silent redirects and things like that. [03:18]
-
-## Redwood 7.5
-
-**Carl Vitullo:** There's also Redwood 7. 5. I recently spoke with the Redwood folks at ReactConf and it got, it actually got me a lot more excited about the project. [03:26]
-
-## Upcoming conferences
-
-**Carl Vitullo:** All right, switching into some upcoming conferences. Me and Mo are going to bounce off each other here a little bit. [03:32]
-
-## Render Atlanta
-
-**Carl Vitullo:** In two weeks, I am sad that I will not be able to make it to this one, but Render Atlanta is happening June 12th through 14th in Atlanta, Georgia. [03:41]
-
-Looks like a really great conference. I have heard nothing but phenomenal things from past years, and it looks like a great crew is heading out there this year. So yeah, definitely check it out if you are looking for a conference this month. [03:52]
-
-Yeah, Mo? [03:53]
-
-## Future Frontend
-
-**Mo Khazali:** And just around the same time, so June 13th to 14th, Future Frontend is happening in Helsinki. [03:58]
-
-So that's up north in Finland. And I can personally attest to how good this conference is. It's one of those conferences that has a real community feel to it. You know, 100, 150, 200 people coming. And everyone is super passionate about building front end apps, not just in the React world, but across boundaries. And that means you get some really cool wacky ideas coming up. [04:15]
-
-Last year, someone demoed a talking hamster that was built in JavaScript, which was one of the most wacky and coolest conference talks I've ever seen in my life, and I really enjoyed it. So would definitely give it a shot if you're kind of in Europe and around at that time. [04:27]
-
-**Carl Vitullo:** And I, I believe one of the organizers is, uh, Juho Vepsäläinen. He has been active in Reactiflux from very early on, he used to have a channel himself for his project, SurviveJS. [04:37]
-
-So I, he's been on my radar for my entire career. He seems like a wonderful person. I've never met him in person though. So I'm sad that I also won't be able to fly out to, you know, I can't make the Georgia, so Finland is a bit of a tough sell. [04:49]
-
-## React Norway
-
-**Carl Vitullo:** But that week is a heavy conference month because React Norway is also happening June 14th in Larvik, Norway. I don't know anything about the organizers there. So, can't comment. [05:01]
-
-## React Summit
-
-**Carl Vitullo:** There's also React Summit, June 14th and 18th in Amsterdam in the Netherlands with a remote option as well. React Summit definitely, uh, I've spoken with the organizers in the past and they seem quite great. I have not attended it myself though. [05:15]
-
-## React Nexus
-
-**Mo Khazali:** At the very beginning of July, 4th to 5th of July, in Bangalore, in India, there's React Nexus. Now, last year I had the pleasure of attending React Nexus, and it was such a great community. [05:24]
-
-I gave a talk then and really just an amazing level of energy there. I think it was about four or five, 600 developers all there. And I really felt like there was something unique about it. There was a lot of passion and a lot of drive there and people were just genuinely interested in learning. So really would recommend it if you're kind of near the South, South Asia area to definitely give React Nexus a try. [05:43]
-
-## Chain React
-
-**Mo Khazali:** Around a couple of weeks after that, there's Chain React. So that's July 17th to 19th. That's in Portland, Oregon. Now, I haven't had the opportunity to visit Chain React, but I'm very close with some of the organizers of it, the folks from Infinite Red. I've met them here and there at different conferences, most recently last week, actually, and they are a lovely crew, are a lot of fun, genuinely so much energy and fun, and I've heard nothing but great things about Chain React. So if you're US based and can make it out to Portland, definitely would recommend going to Chain React. [06:12]
-
-## The Geek Conf
-
-**Mo Khazali:** And then a week after that on July 25th, there is the Geek Conf. I happen to know these organizers because they're a key part of the React Native community, the folks from GeekyAnts, and they are hosting a conference in Berlin. So it's the first year that they're doing this and I'll be doing a talk there. So a shameless plug that you should definitely come around and we should hang out. [06:31]
-
-But the Geek Conf is really kind of intersecting web and React Native, which I think is the direction that the ecosystem is going towards. They have some really great lineup of speakers coming around. Folks like Tejas Kumar and Bruno Polino and many others, not including myself there, which I don't consider myself to be a great speaker. So you should come for those folks, and maybe we can hang out in the process as well. [06:50]
-
-**Carl Vitullo:** Let's jump into the main content then. [06:53]
-
-## React Conf Recap
-
-**Carl Vitullo:** Obviously the main subject this month is going to be React Conf. They put up a post on the blog with a React Conf 2024 recap, which is phenomenal. [07:03]
-
-Something I appreciate, they link to the section in the live stream where each of the talks happened. So appreciate that. I feel like so many conferences take weeks to get their conference recordings up. So just leaving the live stream up and linking to the talks. What a solution, it's so good. Something else I found impressive. The livestream recording already has 165, 000 watches. Nope, sorry, since I watched it last night, it's now up to 167,000, which is wild. [07:29]
-
-They open with a recorded bit from the CTO of Meta and then go to Seth Webster, manager of the React team. And he just shouted out on Twitter after the fact, because he was getting some questions about his voice, he apparently had COVID and has had some enduring health effects as a result of complications from that. So I just thought it was really like powerful of him to take center stage, introducing the concept, knowing that that's his experience right now. So, I just wanted to shout that out. He put up a really good, a little explanation of it after the fact. And, I just thought it was really powerful. Wanted to give that a little bit of a signal boost. [08:04]
-
-**Mark Erikson:** Nice to touch on the fact that there are real people with real human concerns involved in building the tools that we actually use. [08:12]
-
-**Carl Vitullo:** Yes, the human aspect of React. But yeah. Let's also dig into some of the technical aspect of React as well. Mark, you want to lead us in here? [08:21]
-
-## React 19 RC
-
-**Mark Erikson:** Happily. Pointing to a couple of the big announcements from the conference. The first one was that React 19 itself has actually gone straight all the way from beta to release candidate. [08:31]
-
-I wasn't sure that they would even get to this step by the conference, but clearly they feel pretty good about the overall stability of, you know, what they've been trying to work on. I'm not going to try to go through all the various features and everything. If you've been listening to the podcast for the last few months, you've heard us discuss most of them at some point. [08:49]
-
-And the blog post itself does actually touch on all the major things that are in there. Things like, you know, hooks for dealing with for the new HTML streaming capabilities for things like assets. A lot of different stuff in there and whether these are going to have direct relevance for your own application will always vary, but there's been a lot of time and effort put into all these different pieces and how they tie together, even strictly on the client side, beyond things like server components as well. [09:21]
-
-Definitely worth taking a look at the RC blog posts, a great summary of what all is there in React 19. Related to that specifically, of course, there were talks at the conference that then went deeper into some of these aspects. Lydia Howley and Sam Selkoff both had talks that kind of gave overviews of the pieces there, especially some of the server component stuff. Worth watching those if you get a chance. [09:44]
-
-## Server Components on Expo
-
-**Mark Erikson:** Along with that, there was also a talk from the Expo team and Evan Bacon talking about how server components might actually fit into the React Native side of things. Mo, you have any thoughts on that one? [09:55]
-
-**Mo Khazali:** Yeah, so, this is something that the Expo team's been kind of silently working in the background for a little while, there was an interesting tweet that Evan had at one point. I think it was in a tweet exchange where he was like, if you look through my Git commits and my sort of hobby repos, you'll see the direction that Expo's going, because it's a very direct sign into my psyche. And you can see that he started working on this several months ago, and it's finally come to fruition. [10:15]
-
-But they've kind of been trying to work out what server components mean in a React Native ecosystem, which was, it was a big question mark, I think, for everyone in the community, because traditionally mobile apps are client side, and what does it mean to have the server rendering native layer components and elements? [10:31]
-
-I think they delivered on a phenomenal demo. There's still a long way to go before it reaches production and something that we can use, but really the core is that as long as there's sort of native layer supports for the right components, you can stream any JS that you want across the wire that's sort of serialized in the RSC way. [10:48]
-
-And then that can render native layer components on the device, which is quite cool. And what that means is you can basically stream JS that can orchestrate certain native behaviors, like maybe showing a native share card or showing a contact card on someone's phone. Those are sort of native elements, but they can still be orchestrated and sent across the wire with JS. [11:05]
-
-I'd really recommend going through and watching the demo that they had, because the majority of the talk is actually the demo, and you'll get a real good sense of what that means and what it would look like in practice. And interestingly, in the aftermath of it, it fueled a massive debate across the entire React Native ecosystem on the place where debates always get fueled, which is Twitter or X these days. It was a question of, because you can just basically send any JavaScript across the wire that will change how the app behaves, what does that really mean for Apple's terms of service? [11:32]
-
-And there was a bunch of people who were like, this absolutely violates Apple's terms of service. Your app will get rejected. Why is Expo doing this to the community? Why are they putting them down a rabbit hole? [11:40]
-
-And then other people saying, no, absolutely not. You can basically replace the entire JavaScript bundle today in React Native. So why should this change it? So interesting debates came out of it, but nonetheless, there's some exciting stuff going on. And I think we're just at the very tip of the iceberg so far. [11:55]
-
-**Carl Vitullo:** Yeah, a couple months ago, I had presumed that server components were just not going to be a thing on React Native, and was very surprised that they had full plans to integrate and make them work, pretty much the same as how it does on web. [12:09]
-
-So yeah, definitely worth checking out the demo to see how they get that going. [12:12]
-
-## React for Two Computers
-
-**Mo Khazali:** On top of that, afterwards, there was a talk by Dan Abramov, where he went over the paradigm of React for two computers, kind of sticking with the server component mode and model. And it was a really primitive explanation. I really love explanations like this, where someone kind of breaks things down into the very, very basic primitives. [12:30]
-
-Like you've got a web server. Here's how you can render HTML on the web and send it across to the client. Okay, what happens if we start to extract certain parts of this, separate them out and see how you can kind of construct React server components from scratch. I think Dan did a post on, it was something on GitHub that he posted, which kind of walked through the thinking for this talk, but really articulating it in a talk, put it into a nice story. [12:51]
-
-It was quite fascinating. And I think it was a really good explanation for anyone who wants to really understand server components. I don't know if you had any thoughts on it, Mark, yourself, but I quite enjoyed that. [13:00]
-
-**Mark Erikson:** A couple bits. He actually did put up a post earlier this year on his blog called The Two Reacts, which I think directly is, the exact same line of thought that led into this talk. [13:10]
-
-If you've watched Dan over the last year and a half, he's been throwing a lot of ideas against the wall to see what sticks in terms of teaching people server components and the mental model that, and like, we're trying to figure out what mental model makes sense to both explain it and make use of it properly. [13:29]
-
-The thought process here of, you know, it's expanding React to the server, but also it's still one React tree just split across two computers is something worth trying to wrap your mind around. [13:42]
-
-**Carl Vitullo:** Yeah, I was just thinking of whether I wanted to share this under the React compiler notes, and I think I'll get deeper into it. [13:47]
-
-But, I do think that this is a continuation of a pretty stable vision that the core team has had for React. From the outset, server rendering was something that was, you know, ostensibly possible to do with React. And there were many years and people were just kind of like wild westing it and doing it themselves and, you know, render to string and, Oh, cool. Now we can render a, you know, like a streamable HTML. [14:12]
-
-This is not new, it's just a new attempt at solving the same problem in a way that does it better than previously. So it's just a, you know, it's one more incremental step forward. [14:23]
-
-**Mark Erikson:** Yeah, I actually had a chance to talk with Ricky Hanlon while I was there in Vegas, actually, ironically, like five feet from where Carl's sitting right now, and he was talking a bit about, we didn't exactly know what the end state looked like, but we had a lot of intuitions about what it would feel like when we got there, and There, there was like partially a master plan, but also partially not. [14:48]
-
-It was just, we think these are the big problems we need to solve along the way. And that's how we ended up in things like hooks and whatnot. Eventually those have led to the point where now the grand vision is kind of coming together. [15:02]
-
-**Mo Khazali:** And I guess just to go in from the React Native perspective as well, me and Evan were having a chat about this at App.Js and a few other people as well were kind of echoing the same sentiment, which is it's been the same in the React Native ecosystem. [15:14]
-
-Larger scale organizations have been using server driven UI, where you kind of describe your layout in the form of a JSON object and ship that through an API endpoint or from your CMS directly to define how your page is layouted. [15:27]
-
-And server components on React Native as well are just kind of a continuation of that same paradigm of starting to move some of the layouting and some of the business logic of your front end app over to the server to kind of optimize it and also allow for more flexibility and better performance in many cases. [15:43]
-
-Like you say, it's just a natural continuation, whether you're on web or on mobile. [15:46]
-
-## Q&As with React and React Native Core team
-
-**Mark Erikson:** So, wrapping up a couple of the talk links here, there were also Q& As with both the React core team and React native core teams. I admittedly did not have a chance to watch these, but there's, I'm going to assume that there is material worth watching in both those sets of discussions. [16:04]
-
-**Carl Vitullo:** Sadly, I missed it as well. There was just too many interesting people to have great conversations with. I did hear that, I saw like a kind of snarky, sarcastic tweet from someone on the, I can't remember who now, someone on the React Native team, saying something to the effect of, like, we dropped so many bombs in this React Native Q& A and you're talking about this? Just as sort of a meta commentary on the Twitter discourse. It sounds like the core team thought that they got very deep in the weeds talking about some of the, talking about the technical details. [16:33]
-
-## React Compiler
-
-**Mark Erikson:** All right, moving along to another fairly sizable announcement from the conference and something I've been very eagerly waiting for it at the point that I almost stood up and did actually cheer when it happened. [16:43]
-
-The long awaited React compiler is now actually both open source and usable. Finally! The React team had been promising that it's real, trust us, it works. And they'd said at a couple talks last year that, you know, we're trialing it in production in a couple real Facebook sites. [17:03]
-
-It is now open source. You can now actually use it. And they've dropped a lot of information about how it actually works as well. So it's now actually officially listed in the docs. And there's instructions for setting up and using it. It's worth noting that in its current form, the way to use it is as a Babel plugin, which means that ironically we've been doing all this work to switch our build tooling over to Rust, and suddenly we might actually need to re add Babel, just to get the compiler to work. [17:31]
-
-Having said that, the compiler itself is like 90 percent it s own code, and it's really just using the Babel plugin layer as a way to manage the parsing of the code. But they've even played around with an eventual rewrite of some of the compiler logic in Rust. Um, there will likely be other alternative ways to load it into your build system down the road. [17:55]
-
-So, it's not like it's Strictly built out of Babel. One really neat piece is that they actually have a live playground. If you ever went to the Babel website, Babel has a playground that shows you, if you write some JavaScript code and have certain compilation settings activated, here's what the output looks like. [18:14]
-
-They've got a playground for the compiler as well. And I think this is really valuable on multiple levels. One, is that it literally shows you what the output will look like, so you can get a sense of the transpiled code without having to do an actual build step. It also actually has a set of vertical sidebars which show you what the actual compiler internals are outputting at each step of the transformation process. [18:43]
-
-The compiler itself is awesome. A real, no kidding, deep compiler, like, with all the, you know, real world compiler optimizations. And so getting a sense of both what kinds of passes they're doing and what the results look like, I think is really cool. There were a couple of really good talks at the conference about it. [19:01]
-
-Lauren Tan did a kind of a usage walkthrough, you know, let's add it to a project. Let's use it. The React DevTools will now show you if certain components have been optimized. She even had written her own little proof of concept VS Code plugin that would show in your editor if certain components were being optimized. That's not actually available yet that I know of. They may end up releasing like an official version of that VS Code plugin at some point. [19:29]
-
-Meanwhile, Sathya and Mofei, also on the compiler team, did more of a deep dive into how it works. And Mofei in particular did a live coding demo where she showed like, let's actually write a little Babel plugin that makes use of some of the compiler internal, and see how the output of it changes as they add each piece of the compiler logic to it. [19:50]
-
-One more good explainer, Jack Harrington had a chance to do, I think, both a video and a blog post where he walked through using the compiler and talked about some of the usage changes and the mental model aspects. I think one of the big pieces for people to understand is that this does several different things. [20:10]
-
-One is it adds like the dependency array aspects to useEffect, useMemo that we've always kind of wanted so we don't have to do it ourselves. [20:18]
-
-Another is that it overall optimizes the rendering performance of components. But on top of that, it kind of flips the mental model of React rendering on its head. [20:29]
-
-One of the big things you've always needed to know is that React renders recursively by default, and now the compiler flips it, so that finally, only components whose data actually changed will re render. So this is a big deal. [20:42]
-
-**Carl Vitullo:** Yeah, I also saw on Twitter, just sort of an open question that I thought was a good one to ask. [20:48]
-
-Jamie Kyle asked if library authors were going to be expected to ship components and hooks pre compiled. And Sathya responded that like, yep, they're just like all of the other transpiling, compiling in the ecosystem. You know, if you're authoring in TypeScript or Flow or, I can't think of any other compiled things off the top of my head, then yeah, so you published the compiled artifacts to npm, so I thought that was worth calling out for anyone here who might maintain a library. [21:17]
-
-**Mark Erikson:** It's worth noting that the compiler output does expect to use a new hook that is, strictly speaking, only available in React 19. Having said that, there is a very simple polyfill. [21:31]
-
-It's really just a useMemo that allocates an array. That polyfill ought to make the compiler's output work if your app is still on React 17 or 18. So, in theory, you could drop this into an existing React 17 or 18 application and still get the same performance benefits. Which is nice because, you know, basically nobody's on React 19 yet. [21:54]
-
-**Mo Khazali:** I guess in terms of another small detail as well, to keep in mind if you're trying to add this in, is the React compiler, as far as I'm aware, expects for you to list it as the first Babel plugin in your config, and the idea with there is they want to have the state of your code base before any other plugins mess around with it and transform it. [22:12]
-
-So, it's, that's just a little gotcha in case you are trying to integrate it. Just now into your app, hearing about this. [22:18]
-
-**Mark Erikson:** And again, with Carl, with what you said earlier, it's, this is a vision that the React team has had for a while. You know, they, they'd said early on that they designed the hooks APIs, you know, specifically the dependency arrays under the assumption that someday a future magical compiler could do that for you. [22:36]
-
-They honestly weren't sure if, and when they would ever get around to it. And it was pointed out that they didn't have compiler expertise on the team. At the time that they were making that assumption, but that was a thing that they assumed would eventually happen. You know, they played around with a proof of concept compiler called prepack years ago. [22:54]
-
-That attempt didn't work out. And even this current compiler took a couple of different attempts to really figure out what they, what it was supposed to do and how they were going to do it. But the thought process of we could use a compiler has been around for a while. A couple other quick notes to wrap this up. [23:12]
-
-Lauren Tan did a talk all the way back in 2016 that has kind of a couple indirect precursors to the thought process of the compiler and using it. They apparently used it in the official React Conf app. And the BlueSky Twitter alternative is already using it in production, partly because Dan works on BlueSky now. [23:32]
-
-And also the React core team added it to BlueSky to help prove that it would work in a separate real world application. [23:39]
-
-## Remix is merging (back?) into React Router
-
-**Mark Erikson:** I'll toss out one other announcement that came out of the conference. So Ryan Florence did a talk where he announced that Remix and React Router are merging, sort of, conceptually. [23:51]
-
-The way he put it is that Remix itself, at this point, is basically just the latest version of React Router plus a Vite plugin that adds the actual build steps. And so, rather than continuing to put more things into the Remix packages specifically, they're just gonna move a couple more things over into the React Router packages, label that React Router v7, and it has an optional Vite plugin if you want to do server usage. [24:21]
-
-Um, this of course was met with much confusion and complaining on Twitter. Personally, it makes sense to me. And it's worth watching Ryan's talk to get a sense of why they're going this way. [24:32]
-
-**Carl Vitullo:** Yeah, and this was surprising. I won't say that it wasn't surprising. I just thought that, like, Remix, I mean, they're a venture backed business. They got acquired by Shopify. I am surprised to see them say that Remix is just not going to be a thing anymore. For that, for those branding reasons, branding and funding and,[24:49]
-
-**Mark Erikson:** The caveat there is Ryan said in both the talk and the later blog post that they put up, like, we have more plans for Remix as both a brand and a set of tools that we want to circle back to in a few months. [25:05]
-
-Like, we have some idea of something new we want to do with it, but for now the focus is like, let's just roll all this stuff into the next version of React Router and then you can pick and choose whether it's just doing client side stuff or server side stuff too. [25:19]
-
-**Mo Khazali:** And I guess on the Shopify piece, Carl, I'd love to get your thoughts, but I feel like Shopify kind of achieved what they were trying to achieve with Remix, which was ultimately they took it and made it the backbone of Hydrogen, which was their own sort of, I guess, framework, so to speak. [25:33]
-
-And it's great if you've ever used it to make a Shopify app. I don't know if that, maybe they're looking to get more out of it or not, but I feel like it probably achieved at least some of the purpose of why they, they, backed it as a framework and invested in it. [25:44]
-
-**Carl Vitullo:** That's true. Yeah. And I guess, actually, I don't know this, but I think it was an acqui-hire, they started working at Shopify? Yeah. So that, that certainly makes sense, Shopify got their value out of business transaction for sure. But, so I guess, as surprising as it was to me for them to announce that they're now moving back to React Router as their primary brand for the work they're doing right now, they also have a long history of doing things like this. [26:09]
-
-The React Router folks put out React Router and then they've done at least one, I think, departure that sort of builds on because they had done Reach router for a while because they had some new concepts that they wanted to explore. And I think that is a phenomenally responsible way to approach public experimentation in an open source setting. [26:30]
-
-They have a large enough audience that if they announce a new project, people will give it a shot. And I think it is so smart, in terms of, like, branding and messaging and, managing expectations, I think they are tremendously smart and thoughtful about how they use brands, because, you know, you can do, like, a major version, you can do a beta or an RC, or, you know, do, like, an experimental phase in a project, but I think it is really great and honestly kind of them to the community to say like no This is different enough that we are giving it a new brand and we're gonna experiment and then now twice now They've said "cool, we learned a bunch of stuff and we're just gonna bring it back, now it's just React Router again." [27:12]
-
-So because React Router specifically React Router is such a like foundational part of the Ecosystem. Like, you know, the React team has never blessed a routing tool to use with React. So it's, they've always just been the de facto one to use. And I think it is really marvelous that they have taken that position with such seriousness and done this kind of thoughtful experimentation with it. [27:38]
-
-**Mark Erikson:** I can vouch that naming and branding and getting people to migrate is a really hard problem. [27:45]
-
-**Carl Vitullo:** I want to call that out, I think it's really clever and smart and, just having been in the ecosystem since 2015 and watching a lot of thrashing and watching a lot of arguing on Twitter about like this and that and the other, I think they've been really consistently great about, once all the dust settles, at the time it was kind of confusing, but so I guess I want to be the voice that's like," it's going to be okay." [28:08]
-
-## Effect JS
-
-**Carl Vitullo:** Okay, moving on to the next subject, I guess. This was a subject that I almost brought in on the last episode and held off because it seemed a little bit too out there. But I dug into it a little bit over the last month. [28:19]
-
-Effect, they have released 3. 0 and they are now calling it production ready. It, it had crossed my radar in April with some people asking folks like Kent C. Dodds and other prominent educators, what they thought about it. So, and the consensus I saw then was like, looks neat, but it's real big. That's a lot to learn. I'm not, I'm not dipping my toes in yet. [28:41]
-
-And basically what I understand it to be is a, it's almost a standard library for TypeScript, but it's also. Like a functional programming kind of paradigm, like it introduces new concepts for all the way down to console. log. So there's a fetch replacement. There's a console. log replacement. There's a promise replacement. It's an enormous surface area for the API. So in a very real way, it's like learning a new language, which is why I held off on this, because it's a Big swing. [29:15]
-
-It is an enormous swing. One of the reasons I decided to bring it in is that I learned while digging into it that Johannes Schickling is one of the people backing this, one of the creators of the project. And he's been, I can't remember what his first project was. I've been following him for, it feels like forever. He was the founder of Prisma, which was a very influential ORM, schema declaration model. [29:40]
-
-**Mark Erikson:** He's done some GraphQL stuff, and I actually had a chance to meet him in person back in December, and one of the ideas he's been playing around with is like a local first application where every single bit of the code from fetch data to literal client side state is held in an in memory SQLite database. [29:59]
-
-So, like, rather than a bunch of used state hooks, he's got, like, reactive hooks that tie into SQLite running as WASM in the browser, and literally every bit of data in that example. is coming straight out of that SQLite database. Which sounds odd, but when you see it in practice, it's like, oh, I can see the intent behind why he's playing with this idea. [30:22]
-
-**Mo Khazali:** I don't know if you folks recall Project Lightspeed, that Meta did a few years ago, I think it was like 2019, 2020. With the messenger app that they did, it was a very similar approach, which was everything on the client side is backed by SQLite database, the data fetching, the layouting, the local state. So I don't think it's an, it's that odd of a paradigm. [30:40]
-
-It sounds like a, it could be a good scalable way to handle things. So interesting to hear that somebody else is like digging into that vision, Mark. [30:47]
-
-**Mark Erikson:** So with the effect thing, like I echo what you're saying, Carl, is like, just trying to describe what the project is. And a couple bullet points is hard. If I could attempt to restate what you were saying a minute ago, it's multiple different pieces. [31:01]
-
-One is that there's some similarity to the Redux Saga package, where instead of using Async await syntax, and actually kicking off things like async requests right now, I think your code uses generators and generally returns descriptions of like what kind of side effectful behavior you want the code to execute. [31:26]
-
-But nothing actually happens until you return those descriptions to some kind of runner that actually goes off and does the work. Another aspect is that instead of relying on throwing errors just from any piece of the code, you actually end up specifying at the type level that this function could return a number and could throw a, like, could not parse integer error, or something like that. [31:54]
-
-And so you, like, it's a very, like I said, functional programming way of modeling code. Returned values versus possible thrown errors, and they have an entire JavaScript standard library built up because as we all know, one of the weaknesses of the JS ecosystem is we don't have much of a standard library built into the language itself. [32:17]
-
-And there's a whole bunch of primitives around async concurrency. So things like retries and, you know, iteration, backoffs, and that sort of thing. So, like, that, as usual, I've not played with it, I've only tried to skim over the docs, and, yeah, like, my own reaction is like, Wow, that's a lot, I can't even wrap my head around this, but I think that's the best description I can come up with, and I think I see where they're trying to go with this. [32:45]
-
-**Carl Vitullo:** I did dig around a little bit more than trying to read the documentation. I was directed to, a wonderful 10 minute introduction about it. That was what really sold me, and I'm like, yep, okay, we're gonna talk about this. So I definitely recommend checking that out. Um, from Ethan Niser, yeah, just, it's a great 10 minute introduction. [33:02]
-
-And going back to Johannes Schickling, he gave a, an hour long talk titled Production Grade TypeScript at, they put on a conference, they put on a conference already, Effect Days 2024. It was also great. It was much deeper in the weeds. At one point he said, like, "I'm sure that a lot of people watching this talk on YouTube are going to be angry I'm not explaining what effect is." And I was like, dang it, that's me. I wanted to know what effect is (laughter). But it was a great talk besides that, uh, it just didn't quite answer the question I was hoping for. [33:32]
-
-If he's got bona fides in, like, querying, schema, GraphQL, as well as local first, like, to me, those both extensively deal with the hardest parts of asynchronous behavior, with, like, retries and backoffs, like you were mentioning. So that is A lot of very deep experience with some very hard problems. [33:53]
-
-And I do love local first. I think it is an absolutely wonderful paradigm and it is very challenging right now. So if we end up getting a relatively widely used and supported standard library that makes things like exponential backoff and retries and responding to different kinds of errors in different ways. Then. All of the myriad things that make asynchronous behavior difficult, then that sounds pretty cool. [34:19]
-
-I'm pretty excited about it. So, I don't know, that's, that's all I will say on effect. [34:23]
-
-## Forensics of React Server Components
-
-**Mark Erikson:** All right, moving along. We've discussed and linked to a lot of articles over the last few months that attempt to dig in and explain various aspects of React server components. [34:34]
-
-What are they? Why would you care about them? How do you use them? How would you even go about building your own server components based framework? [34:42]
-
-And we want to point to one article along those lines this month, the forensics of React server components. This one does a really good job of laying out a lot of the different pieces and how they fit together. [34:54]
-
-It talks about, you know, client side rendering and kind of illustrates some of the data fetching and rendering workflow, server side rendering, and how data gets fetched on the server and rendered and loaded into the client. Hydration and servers and some of the issues with that, and then goes and digs into server components and kind of walks through a lot of what the data flow and mental model of where data and where server components fit into the life cycle, how the data fetching behaves, the interactions between server components and client components, and even shows some examples of the serialized output that server components return. So, it's a pretty good one stop shop for kind of wrapping your head around some of the actual usage and mental model of server components. [35:39]
-
-## Next.js v15 RC
-
-**Carl Vitullo:** Okay, uh, Next15 has an RC coming out, or that is now out. [35:44]
-
-Not entirely related, but I did see that Vercel has now raised 250 million dollars. So they are capitalized for a good minute longer. They're not going to go out of business anytime soon. [35:54]
-
-But yeah, Next 15 supports React 19 and the compiler, they have changed their caching behavior pretty extensively, which I had understood to be one of the bigger pain points of using the app router. They have an experimental API called Next After, which solves a problem where you can schedule work to be processed after the response from the server has finished streaming. It solves the problem of needing to figure out, needing to guess when the response has come in. I think that's pretty neat. [36:22]
-
-They also have a neat feature, they call it partial pre rendering, it is neat looking to me. They say, you can wrap any dynamic UI in a suspense boundary, when a new request comes in, Next will immediately serve a static HTML shell, then render and stream in the dynamic parts with the same HTTP request. That sounds a lot like out of order streaming that I had heard some stuff about in the past. [36:43]
-
-I mean, that's always been the dream of server side rendering is you make a request, you immediately respond with something, so it's not just a blank screen and then fill in the rest of the bits. So it seems like a clear improvement to me to be able to do that in a single HTTP request without having to open a new connection and do all the TCP handshaking. So that, that should be a pretty good performance improvement. [37:05]
-
-## It's not just you, Next.js is getting harder to use
-
-**Carl Vitullo:** I just wanted to call out an article that I saw entitled, It's Not Just You, Next. js is Getting Harder to Use. It just kind of calls out the increasing complexity of the framework. It's a little pessimistic, it's a little down note, but I think it's reasonably fair. [37:20]
-
-Just to call out a couple of sections that seemed worth it to me. You need to understand a lot about the internals to do seemingly basic tasks. There are many ways to shoot yourself in the foot that are opt out instead of opt in. This is just a funny bit talking about like, you know, you go to a GitHub issue and you see an explanation of why that thing that you want to do isn't possible and go like, "oh, that does make sense." But they say, you probably read this and left with five more things to Google before realizing that you probably have to restructure your code, which is Brutally familiar. [37:49]
-
-So, and on the app router, if you started a Next project, Next will default you into it, which implies that it's production ready. It implies that if you're starting something new that you're going to ship to production, you should use the app router. [38:02]
-
-But this article calls out, "the official React docs don't share that same sentiment. They currently recommend the Pages router and describes the app router as a bleeding edge React framework." So, it seemed like a really good, really fair. Non complementary discussion of Next. [38:17]
-
-**Mark Erikson:** I've seen a number of folks complain that the app router works great for the layouty stuff, but some of the integrations have been both buggy and somewhat hard to use. [38:28]
-
-One comment I saw was the effect that, ironically enough, the app router Works better for static pages and the pages router works better for applications in terms of data fetching. So the names almost seem a little bit backwards, ironically. [38:43]
-
-**Mo Khazali:** I don't know about you folks, but when the App router came out and you know, I've gotten more and more used to it as time passes, but I just found that the pages router, even just things like being explicit with, you know, whether you're doing get server side props or you're doing get static props, just found that I love the fact that it's explicit, so at least you as the developer have to explicitly define how you want sort of that page to be rendered, rather than sort of the automated, magical nature of the app router. [39:08]
-
-I do miss that sometimes, but there's also a lot of benefits to having the app router, so I guess it's, as with all things, there's trade offs with it. [39:15]
-
-**Mark Erikson:** All right, Mo, you have a lot more expertise on React Native than either the two of us. Want to hit some of those highlights? [39:21]
-
-## React Native New Architecture beta
-
-**Mo Khazali:** Let's jump into it. So let's start off with Meta news. Firstly, we've been hearing about the new architecture for years now, if you've been in the ecosystem, uh, but they have officially put it into beta, which is a big deal if you've been here for a hot minute and the word on the street unofficially is that we might finally see it going into production or going into default and out of beta sometime this year. We'll see if that happens, but it'd be very exciting. [39:46]
-
-The good news with all of this is there's more and more, uh, Third party libraries or open source libraries that are coming with new architecture support. And I think that's the real bottleneck right now is one having a good interop layer, which the folks shipped last year from the meta team. [40:00]
-
-So that helps kind of ensure some level of backwards compatibility, whether it's with the layouting engine or with the rendering engine, but I think it's a really good step that they're going into beta and soon more and more libraries are going to support new architecture. [40:12]
-
-There was this massive Google Sheet that just had all of the libraries that currently support new architecture that are commonly used in, in, in the community and some of the ones that don't yet. So it's, it's going in that direction. I think everyone's trying to push and get, get it finally over the line. [40:25]
-
-## Expo is now the recommended framework
-
-**Mo Khazali:** Uh, in other news, Meta, both in React Conf and also at AppJS did kind of similar talks about how you should use a framework. So if you've been in the React space with Next, you will be familiar with this. Very much, but the idea here is that they've officially came out and endorsed that you should use Expo by default. [40:43]
-
-And this isn't anything new. If you had been frequenting the React Native docs for the last couple years, they give a nod to Expo here and there, they use Expo Snacks for the coding examples, and they kind of make points to say you should go and check out Expo if you're starting out a new app. [40:59]
-
-Um, but now they've explicitly said, you know, you should use a framework for the same reasons that you see in the React ecosystem. Routing, um, tooling, and having the right ecosystem in place, which I think is a great step because it really, using something like Expo really saves developers a lot of, uh, hassle and a lot of difficulty that you oftentimes face if you're just on a bare React Native project. [41:17]
-
-## React Native Skia on WebGPU
-
-**Mo Khazali:** Now, going into community news, these things are fresh off of the press, predominantly out of App. js that happened last week. So, the first thing that I think was incredibly exciting was that we got some updates on React Native Skia. React Native Skia has been a 2D rendering sort of canvas that you can use in React Native to draw graphics, nice animated graphics, sometimes interactible graphics if you want to integrate it with things like Reanimated or GestureHandler. [41:43]
-
-The announcement for this was in some ways the most amazing and also the most sort of cheeky announcement possible because it was sort of Apple esque intros with sort of rainbow colors going to form a hello and really just showing that they're very much great graphists at heart that are working behind this. And Skia is backed by Shopify as well. So it's got massive backing. It's a great project. So you should definitely check it out. [42:05]
-
-Previously Skia was mainly used for 2D graphics. So it gave you a canvas. You could draw things on it. And people had I've been using it to kind of extend the boundaries to create what they call 2. 5D, which is 2D graphics that kind of resemble 3D, and through the illusions of looking at it, they kind of look like they're 3D, but they're still just rendered on a 2D graphic, uh, and this has a few limitations, it runs on the CPU, it's not really truly 3D. If you want to do anything like interactivity with it, you're quite limited by sieve there in terms of your performance. [42:35]
-
-And hence, the talk that they had at Appjs was called Hello GPU. So first they started off saying, ah, there's video support now, so you can do a whole bunch of shaders on videos, which was quite cool, but really the key thing that was exciting was that they actually brought WebGPU into the React Native world. [42:50]
-
-So you can use WebGPU to obviously target web, uh, with React Native Skia, if you're using React Native on the web, but you can also use it for iOS and for Android and having those sort of cross platform 3D visualizations and rendering, I think is going to be really cool for the community and not something that we've actually been able to do very effectively on the GPU layer. [43:09]
-
-And they've integrated all the way down into the native layer APIs, so, Metal on iOS as an example. Especially with something like React Native running on Vision OS, where you really want to have these 3D objects that you kind of put in your vicinity in the spatial navigation paradigm. [43:24]
-
-It will be so cool to be able to actually use that as well for VR and not just on Vision OS, but also maybe on some of the Quest runtimes and so on and so forth. So I think it's, it's a really cool step and it stops us from having to drop into the native layer as we've often had to do with this type of thing. [43:39]
-
-## React Native IDE
-
-**Mo Khazali:** Next up on the announcements from AppJS, we saw the React Native IDE. So this has been kind of teased by the folks at Software Mansion for a long time. We've had a lot of sort of disparate tools in the React Native ecosystem. You know, when you're usually developing with React Native, you have to have your terminal running your Metro bundler and then maybe have Some Chrome DevTools running connected to the React Native DevTools to kind of, uh, your network requests coming in and analyze your source code. [44:04]
-
-And then if you want to dig in and look at what elements are being rendered, where it's all really just sort of a bunch of different parts to the dev experience. And it's not been amazing. There's obviously been a lot of improvement. And if you come from the native world, sometimes those things can be a lot more integrated with Android Studio and Xcode. [44:20]
-
-And so the lovely folks at Software Mansion have developed an IDE and it does some really cool stuff. I won't go into too much details. It does everything you would expect from an IDE. And I think it brings first class DevEx into the React Native world. It's going into beta or went into beta last week. [44:34]
-
-And the coolest thing out of all of the demo was debuggers across the native boundaries, so when you put in a debugger, it not only could handle debugging on the JS code that you write, but you could also place debuggers inside of your node modules on the iOS Swift code, or maybe your Android code that you have written in Kotlin, which I think is really cool, because one of the challenges is you're kind of fiddling between Xcode and Android Studio and also Visual Studio Code, And this brings it all into one place, which is really quite exciting. [45:03]
-
-## React Native on TVs
-
-**Mo Khazali:** And then the last thing that happened around React Conf, and they nodded at it again at AppJS, was around Amazon doing a keynote talk about using React Native beyond web and mobile. And so Amazon has started becoming a big proponent of React Native in general, but also React Native on TV specifically. [45:20]
-
-And they have actually been using React Native for years now. They kind of hit it very cleverly where you couldn't really see it on first glance in the app binaries, but they came out with a big bang announcement last year saying we have actually been using React Native for a very long time, and it's been most of our apps. Huh. Gotcha. [45:35]
-
-And so it was quite a nice announcement in that, well, there's more people using React Native and that's always a good show of faith in the technology for the community. But it was quite funny that they hid it for so long. [45:45]
-
-Amazon obviously does a lot with Firesticks and TV devices, and their OS is based off of Android. So you can build TV apps for it with React Native. And I think they're very keen on people using React Native just because of its cross platform nature. They talked about many different things, challenges of performance and spatial navigation on TV. One thing, if anyone is interested in React Native for TV, a bit of a shameless plug here, so I apologize to you both, Carl and Mark. [46:12]
-
-**Mark Erikson:** Shameless plugs! Gasp! [46:15]
-
-**Carl Vitullo:** Who does those?? [46:16]
-
-**Mo Khazali:** Questionable on my, on my character there, I'm so sorry, folks. But, as part of like some of the community stuff that, I've been doing with some of the folks from Amazon. We actually started an RNTV.dev blog, and it's kind of meant to be a centralized resource for everything about React Native on TV, because that doesn't exist. We thought, why not make it so that we can help people onboard into it more and more. [46:36]
-
-The other last thing that they kind of dangled was they said, we want to support open source projects, especially ones on React Native for TV. So if you're interested and you've got a project that's extensively used on React Native for TV, Sign up for this form and we're gonna be, start starting to sponsor more and more projects on the React and React native ecosystem. [46:53]
-
-So if you're a community maintainer, wink wink, you might wanna check that out and see if there's something that you can, uh, get some support from them for. [47:01]
-
-And that is all of the React native stuff. Sorry folks for going into that rabbit hole. [47:05]
-
-**Carl Vitullo:** No, thank you. That's, we have a dearth of React native expertise on our end, so I'm very glad you can speak to it. [47:11]
-
-It's cool to hear more about the React Native TV stuff. Cause a couple of months ago, Oh God, probably a year ago now. I spoke to Kaleb McKelvey, I want to say it is, about React Native on TV. [47:24]
-
-In that setting. And it was a fun, interesting talk. It's an interesting input paradigm. You know, a remote control is very different from a keyboard or a touchscreen. [47:33]
-
-**Mo Khazali:** Yeah, it's really quite tough, Carl. Like, you know, we're used to touch displays or, you know, cursors on the web or the pointers or whatever it is. And then you're really suddenly limited to up, right, left, down, and a select key. And you're like, Oh, wow, how do I, how do I, what happens when I press down and I'm at the end of a carousel? Like, it's just so much, like, undefined behavior that isn't standardized. So, it's definitely a cool engineering challenge to delve into if you want something new. [48:01]
-
-**Carl Vitullo:** For sure. It's a funny, stateful mode of input. [48:04]
-
-**Mo Khazali:** Yeah 100%. [48:04]
-
-## ⚡️ Lightning round ⚡️
-
-**Carl Vitullo:** Okay, cool. On to the lightning round. [48:07]
-
-## Speculation Rules API in Chrome
-
-**Carl Vitullo:** I'll take the lead with some new Speculation Rules API in Chrome. This was a new term to me, Speculation Rules, but so this is apparently finer grained control over how Chrome will prefetch pages. [48:22]
-
-So this lets you more clearly signal to the Chrome browser whether and how it should try to prefetch something as a user, like hovers or begins to click, things like that. [48:33]
-
-## Josh Comeau's post on useDeferredValue
-
-**Mark Erikson:** Josh Comeau put out a, yet another one of his incredible blog posts. I mean, basically every blog post or article that Josh Comeau ever writes is amazing. [48:42]
-
-And this one was on snappy UI optimization with the relatively new React use deferred value hook. Now this came out in React 18, so it's actually been out for a couple of years, but frankly, almost nobody knows how to use this, including myself. And he pointed out that it's almost like a built in debounce for re rendering with a lower priority state update. [49:06]
-
-And so he gave some examples of a feature on his own blog or site that really benefited from moving some expensive calculations and rendering. In debouncing them via used, used deferred value and it really improved the smooth smoothness and snappiness of the ui. [49:24]
-
-## BlueSky engineering culture
-
-**Carl Vitullo:** Cool. I saw a pretty solid looking article from the pragmatic engineer about BlueSky engineering culture. I am all about BlueSky. I would love it if they are successful. And I always love a deep dive into engineering culture and, uh, you know, a white paper, as it were, of how an engineering team operates. So I thought it was pretty neat. For instance, they have two to three person teams with a directly responsible individual and lots of long form writing. [49:53]
-
-So it's like little things like that, I think are really cool to, you know, it's the, in our careers, we get so little, opportunity to experience different types of workplace cultures. So I think articles like these are super valuable for understanding whether there is something better for you out there. [50:11]
-
-So yeah, go check it out. Also, Dan Abramov works there, so you can learn about how Dan Abramov works. [50:16]
-
-## Why Patching Globals is Harmful
-
-**Mark Erikson:** Let's see, Artem Zakharchenko, uh, his handle is kettanito, he's the creator of the mux service worker tool. Put up a post called, Why patching globals is harmful. And, you know, sort of in response to, you know, some of the, the React and Next teams a couple other teams as well, suggesting that, like, we should patch globals automatically in various situations. [50:38]
-
-And his whole sales pitch is that, especially today, like MockServiceWorker just uses standardized JavaScript interfaces for doing this behavior, and we've collectively learned that patching globals is a really bad thing. So, you know, some useful food for thought there. [50:54]
-
-## New Webkit features in Safari 17.5
-
-**Carl Vitullo:** There was a great post from New WebKit Features in Safari 17. 5. [50:59]
-
-This caught my eye just because in so many cases, Safari is the last browser to implement something. So seeing oh, Safari implemented something, just caught my attention as like, Maybe we can use this now. It looks like Firefox is still a bit of a laggard on some of these features, but, there's a light dark function, light dark as a CSS function, which is a bit of a simplified developer experience for doing dark mode. [51:25]
-
-So it previously there had been a media query for, I believe it was prefers dark mode. That doesn't sound right, but there was a media query where you could apply different styles if the user had a setting for preferring dark mode. This is now a function that does effectively the same thing. So, This is a solid improvement because with the media query, you pretty much have to like copy an entire style block. [51:50]
-
-Whereas this you can just do inline, like if somebody wants a dark mode, you get this color. If somebody wants a light mode, you get this color. Just boom, nice little either or that you can do right in line. So I thought that was great. [52:01]
-
-This is, I cannot believe that we are only just now getting this in 2024, but we now have text wrap balanced, where you can tell CSS that you want, for instance, a title of a document to stay balanced instead of like, this goes deep into design and typography. It's a classic problem of designers saying like, well, hey, on certain screen sizes, we have a dangling word here. Can we just fix that? And the answer for so long has been, "no, that's really hard." So now we have a CSS rule that lets us give better control over how text wraps. So that's wonderful. [52:38]
-
-**Mo Khazali:** And I think there was a React library that was dedicated to this exact thing for the longest time. So it's cool. [52:44]
-
-**Carl Vitullo:** That's why — cuz it's so hard. You needed JavaScript. You needed to like measure the characters and like know what font you're using. [52:52]
-
-**Mark Erikson:** This is, this is a place I will legitimately happily use the platform. [52:56]
-
-**Carl Vitullo:** Right? It's such a core part of designing a web page, like how does the text wrap? It's just so outrageous to me that it's 2024 and we are just now getting some mode of control of it that doesn't require JavaScript. And it didn't even work well in the past because you like, measuring fonts was not easy on its own, so that was weird. [53:15]
-
-**Mo Khazali:** I'm going to rabbit hole again. You should have seen the, uh, Next. js implementation of that, because how do you consolidate the server rendering of the balanced text from the, it was, it had a whole, I went into the cores of that library, uh, massive rabbit hole. It was so funny to see how much work had to go into just getting that working on Next and on React client side. [53:33]
-
-**Mark Erikson:** Part of me wants to go look and the rest of me doesn't want to. [53:36]
-
-**Mo Khazali:** I will send you the link. Yeah,[53:37]
-
-**Carl Vitullo:** we'll put it in the show notes too. Haha. Cool. [53:40]
-
-And they also, there's also an app starting style rule for things like entry transitions, which is great because we now have a lot more options for entry transitions because stuff like popovers and modals are now entering the platform as well. [53:53]
-
-Cool. Love it. Here for it. That's all I got. [53:56]
-
-## Why React Query
-
-**Mark Erikson:** The folks from the UI. dev educational material site have put up a post that talks about why React query. I always love historical posts or posts that explain like, here's an abstraction, why does this extraction even exist? Like what work is it doing for us in the first place? [54:15]
-
-And so they kind of walk through like, okay, if you were to actually just fetch data inside a component, here's all the work you have to do it correctly. And, oh look, React Query actually does all that work for you. Same thing for RTK Query and Apollo and SWR, in principle. They put up this in support of their new upcoming React Query course, which I believe has been written by the current maintainer of React Query, Dominic Dorfmeister. Knowing that and knowing the folks behind UI. dev, highly endorsed, even though I haven't actually looked at it. [54:45]
-
-## We can have a different web
-
-**Carl Vitullo:** I saw a wonderful post from Molly White, who I am most familiar with her writing on looking at Web3 through a skeptical lens. [54:54]
-
-**Mark Erikson:** Web3 is going great. [54:56]
-
-**Carl Vitullo:** Yes, right. Her blog, Web3 is going great. She is a wonderful writer. She just gives great incisive commentary on Web3. She has put out this post titled, we can have a different web, it caught my eye. Because Web 3 took that moniker as trying to, kind of trying to ape the, like, Web 2. [55:13]
-
-0. They're like, well, Web 2. 0 is dead. We are now Web 3. And what a shame that only refers to kind of scammy cryptocurrency projects. I guess now I'd love to see like a Web 4. I know Block, briefly, Tried to do web five as a branding thing. [55:27]
-
-**Mark Erikson:** Let's do the Winamp thing. It's like version two, version three, version five. [55:32]
-
-**Carl Vitullo:** Yeah, right. If we could have Chrome just shout at you, it really whips the llama's ass, that would be great. [55:38]
-
-But yeah, so, okay. This is, Molly White put out this great post. We can have a different web. Just talking about the local Maxima that we've found ourselves in. as users of the internet, you know, sort of bemoaning how if you search something on Google, you used to be able to find it. [55:54]
-
-I think one of the points she makes that is important and nice is that all of those things that people loved about like the good old days of the internet, they're still there. It's just a little bit harder to find them. So sort of her claim is like, we can still have that. We just, you know, there's, needs to be a little bit more. [56:09]
-
-I just definitely recommend checking it out. It tickled my brain a little bit because obviously I've been thinking a lot about community and communities of developers. And so we can have a different web, what is just a very exciting subject to contemplate for me. So definitely recommend checking that out. [56:23]
-
-**Mo Khazali:** It just briefly also reminded me of the work that the folks at ARC are doing with the browser company with the new browser that they've released, ARC, that's based on Chromium. But, you know, I think they're also trying to kind of re envision what it means to search for something on the web where. And integrating some level of generative AI to pull everything and kind of give you a summary and signpost you to the right links so it's less overwhelming than searching on Google these days. [56:46]
-
-It's definitely an interesting take. I think other people are also struggling with that same problem and trying to tackle it. Or we could go for a fully decentralized internet on everyone's phones. A certain TV show might have tried to spin that idea. [56:58]
-
-**Mark Erikson:** A Black Mirror reference? [56:59]
-
-**Mo Khazali:** No, I was, I was referring to Silicon Valley with Pied Piper. [57:02]
-
-**Carl Vitullo:** Ah. No, Pied Piper. Okay. Yep. I also thought Black Mirror. So that says something. [57:08]
-
-**Mark Erikson:** So Christoph Nakazawa, who some folks might know as one of the long, I guess, previous maintainers of Jest while he was working at Facebook, has gone off and created a 2D strategy game sold on Steam called Athena Crisis. [57:23]
-
-I think it has some influences from, like, Advance Wars and that sort of genre. He built the entire game using React and CSS. And even though the game itself is, like, genuinely being sold on Steam, he's gone and open sourced the vast majority of the codebase. I had a chance to hear him talk about it a little bit while I was at React Conf, and he's even done things like putting up bounties for people to, like, improve the AI, or add new features to the map editor. [57:52]
-
-Someone added, like, a tile mirroring feature so you can, you know, create maps that have, like, equal challenges for all the players. And so, his explicit goal was that, like, look, you know, maybe there's people out there who want to get into some kind of game related programming. And while this isn't like a 60 frames per second shooter style of game, there's still aspects of building a game that people might be interested in learning about, and they might be coming from the React community. [58:19]
-
-And so by open sourcing this code base, folks can actually, you know, dig inside and learn and play around with it. So, you know, like kudos to him for taking that approach. [58:29]
-
-**Carl Vitullo:** I also want to shout out that if you played Advance Wars back in the day, this will scratch an itch for you, I think. I've played it a fair amount. [58:37]
-
-It's pretty good. I enjoy it. It's a good game. Having it also be fully open source and come with that ethos is just lovely. I love it. [58:44]
-
-Cool. I'm going to share this. Lee Holmes put out a blog post. Actually, this is not new, but it just crossed my radar. I don't remember where. I think it was in one of the newsletters that I read. [58:54]
-
-But it was titled, Security Risks of Postman. This is not new. This is, I think, even, maybe even reasonably well known. But like, Postman thinks data. They have a cloud service. It is meant to make it easier for you to, you know, keep your different development computers synchronized with each other. But, also You're probably using Postman to, you know, make requests to a development environment. [59:15]
-
-And it might include things like authorization tokens, API keys, like all kinds of really sensitive information that You probably don't want other people to get access to. So that's just generally the topic of this blog post of like, Postman is a security threat. And yeah, can't argue with that. That's you, you should not be putting your API keys into something that feeds them into a third party. [59:38]
-
-So yeah, definitely something to consider. I have always been confused about Postman. Their development path. I loved it for a long time and then they got really complicated with request collections and cloud features and whatever. So this didn't seem like something that needed to be a venture backed business, which is what it is, I believe. [59:58]
-
-**Mark Erikson:** And last item out of our lightning round, while it's not React related, Angular 18 is out. And of course, not being an Angular dev, I only have the vaguest clue of what's going on over there, but looking at the changelist, they're in the process of dropping something that they used called zone. [01:00:15]
-
-js, which monkey patched, like, every possible source of asynchronicity in the browser. In order to detect when data mutations happened so that the UI could then do the diffing and know if it needed to re render. They've also, I believe, been integrating things like signals and trying to move away from RxJS a little bit. [01:00:36]
-
-So, you know, there's various aspects that are there for interop between RxJS and signals. But they're kind of shifting some of that mindset and data flow approach. [01:00:46]
-
-**Carl Vitullo:** Yeah, man. Speaking of, funny to also talk about how patching globals is harmful and wow, I did not realize that Angular was patching globals quite that extensively. That is not great. [01:00:56]
-
-**Mark Erikson:** Angular 1 had some kind of a loop that would just keep checking the controller values to see if they'd been mutated and Angular 2 plus, so going on like the last seven or eight years. Has all relied on this tool called Zone. js to, like, monkey patch every source of asynchronicity in the browser. [01:01:15]
-
-**Carl Vitullo:** Yeah, that's a little bit wild. [01:01:17]
-
-**Mark Erikson:** Alright, I think we're out of things to talk about for now. [01:01:20]
-
-**Carl Vitullo:** 22 minutes over our planned time. Lot to get to this month. [01:01:23]
-
-Alright. Thank you so much everyone for joining us. We'll be back on the last Wednesday of the month here in the live stage in Reactiflux or back in your podcast feed just as soon as we can after that. [01:01:33]
-
-We gather sources from This Week in React, Bytes.Dev, React Status, Next JS, Weekly React Digest, the React JS subreddit, here in Reactiflux from the #tech-reads-and-news channel, and direct from those publishing articles, usually on Twitter or BlueSky. I'm not on threads, but maybe people post there. [01:01:51]
-
-If you see anything newsworthy, definitely let us know. You can do so in the #tech-reads-and-news channel here in Reactiflux, or you could send us an email to hello@reactiflux.com with T M I R in the subject line. It's an acronym for the show. I read literally every email that comes in, even ones marked as spam. So if you send me something to that address, I will read it. I may not reply, but I will read it for sure. [01:02:13]
-
-If this is a show that you get value from and want to support, the best way you can do so is by submitting a review, wherever you listen, and definitely tell your friends and coworkers about it. My thesis for the show is that there are a large number of people who are overwhelmed by trying to consume the fire hose. And so I'm trying to consume the fire hose for you and your coworkers. Yeah. [01:02:33]
-
-Thank you so much. Catch us next month. [01:02:35]
-
-**Mark Erikson:** Bye. [01:02:35]
-
-**Mo Khazali:** Bye everyone.
diff --git a/src/transcripts/tmir-2024-06.md b/src/transcripts/tmir-2024-06.md
deleted file mode 100644
index 54a471c..0000000
--- a/src/transcripts/tmir-2024-06.md
+++ /dev/null
@@ -1,703 +0,0 @@
----
-title: "This Month in React, June 2024: React 19 delayed (drama-ish), why no JS Laravel, TS 5.5 and more"
-date: 2024-06-26
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- Quick hits
- - [[00:51](#layoffs-updates)] [Layoffs.fyi](https://layoffs.fyi/)
- - [[01:35](#the-riseand-fallof-the-software-developer)] [Software jobs down 20% vs 2018? From ADP](https://www.adpri.org/the-rise-and-fall-of-the-software-developer/)
- - [[02:12](#new-releases)] New releases
- - [Turborepo 2.0](https://turbo.build/blog/turbo-2-0)
- - [React Admin v5](https://marmelab.com/blog/2024/06/20/react-admin-v5.html)
- - [Rsbuild 0.7](https://rsbuild.dev/community/releases/v0-7)
- - [Biome 1.8](https://x.com/biomejs/status/1797963672004043040)
- - [Astro 4.1](https://astro.build/blog/astro-4100/)
- - [Valibot 0.31.0](https://valibot.dev/blog/valibot-v0.31.0-is-finally-available/)
- - [[06:51](#upcoming-conferences)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [React Nexus](https://reactnexus.com/) July 4-5, 2024. Bangalore, India
- - [Chain React 2024](https://chainreactconf.com/) July 17-19, 2024. In person in Portland, OR, USA
- - [The Geek Conf](https://thegeekconf.com/) July 25, 2024. Berlin, Germany
- - [WeAreDevelopers World Congress](https://www.wearedevelopers.com/world-congress) Berlin, Germany & Online July 17-19
- - [CityJS Singapore](https://singapore.cityjsconf.org/) Singapore, Singapore July 24-26
- - ~~We Love JS~~ Unfortunately this appears to be a [fake event](https://twitter.com/_jessicasachs/status/1811394314112565301)
- - [React Rally](https://www.reactrally.com/) August 12-13, 2024. Salt Lake City, UT, USA
-- Main Content
- - [[09:43](#suspensegate)] [React 19 delayed](https://github.com/facebook/react/pull/26380)
- - [[09:55](#this-is-the-exact-build-well-release-as-190)] Previously, per Andrew: [React 19 _was_ ready to release](https://x.com/acdlite/status/1797668537349328923)
- - TKDodo: [React 19 and Suspense - A Drama in 3 Acts](https://tkdodo.eu/blog/react-19-and-suspense-a-drama-in-3-acts) , and also [How React 19 (Almost) Made the Internet Slower](https://blog.codeminer42.com/how-react-19-almost-made-the-internet-slower/)
- - [[19:03](#joe-savona-some-thoughts-on-the-suspense-changes-from-19-rc)] [Joe Savona “We'll hold the 19 release”](https://x.com/en_JS/status/1803480672327311425)
- - What does the React team _want_ for data fetching?
- - Seb: [“We never released official Suspense on the client, we did RSCs instead”](https://x.com/sebmarkbage/status/1801258093327593717) and [“Some people got the render-as-you-fetch memo. Some people chose to ignore it.”](https://x.com/sebmarkbage/status/1801294251965198578)
- - Andrew: [“the community shouldn’t think ‘we bullied React into changing fetching strategies”](https://x.com/acdlite/status/1803551296974168171).
- - Related: how do we communicate with the React team?
- - [[21:33](#tanner-linsley-react-needs-a-permanent-working-group)] [Tanner Linsley: “I feel there needs to be a permanent React + community working group”](https://twitter.com/tannerlinsley/status/1802798385810018769)
- - [Joe Savona: “we’re working on ideas to get feedback earlier and more users trying canaries”](https://x.com/en_JS/status/1803480684331483644)
- - [[23:42](#tc39-proposal-advances)] [TC39 proposals advanced](https://x.com/robpalmer2/status/1801239842908438694)
- - [[26:05](#react-partners-with-codemod)] [Codemod partners with React](https://codemod.com/blog/react-announcement)
- - [[27:52](#react-compiler)] React Compiler
- - [[28:03](#i-tried-react-compiler-today,-and-guess-what-)] [I tried React Compiler today, and guess what... 😉](https://www.developerway.com/posts/i-tried-react-compiler)
- - [[29:32](#understanding-react-compiler)] [Understanding React Compiler](https://tonyalicea.dev/blog/understanding-react-compiler/)
- - [[29:50](#why-dont-we-have-a-laravel-for-javascript-yet)] [Why We Don't Have a Laravel For JavaScript... Yet](https://wasp-lang.dev/blog/2024/05/29/why-we-dont-have-laravel-for-javascript-yet)
- - [Why Don't We Have A Laravel For JavaScript?](https://www.youtube.com/watch?v=yaodD79Q4iE)
- - [[35:45](#vercel-ship-2024)] [Vercel Ship 2024](https://vercel.com/blog/vercel-ship-2024)
- - [[37:35](#ts-55)] [TS 5.5 released](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5/?ck_subscriber_id=1888282043)
- - [Matt Pocock breaks it down](https://www.youtube.com/watch?v=sciBO_IaxTw)
- - [[40:41](#mind-the-gap-talk)] [Mind the Gap by Ryan Florence](https://www.youtube.com/watch?v=1g5ruM-16_Y&t=7595s) at Big Sky Dev Con
- - React Native Stuff:
- - [[41:36](#lorenzo-sciandra-exiting-react-native)] [Lorenzo leaving RN world 😭](https://x.com/Kelset/status/1800158749811966280)
- - [[43:47](#expo-atlas)] [Expo Atlas available](https://expo.dev/blog/introducing-expo-atlas)
- - [[46:40](#expo-adds-compiler-support)] [Expo adding React Compiler support](https://github.com/expo/expo/pull/29168)
- - [[46:52](#starlinks-react-native-app)] [Starlink’s RN story](https://www.notjust.dev/blog/react-native-starlink)
- - [[47:14](#expo-router-35)] [Expo Router 3.5](https://twitter.com/Baconbrix/status/1788235769812795559)
- - [[48:16](#sf-symbols-beta-support-in-expo)] [SF Symbols Beta Support in Expo](https://docs.expo.dev/versions/latest/sdk/symbols/)
-- ⚡Lightning round ⚡
- - [[50:03](#react-internals-explorer)] [React Internals Explorer](https://jser.dev/2024-05-11-introducing-rie/)
- - [[50:44](#whats-new-in-javascript-frameworks-for-may-2024)] [What's new in JavaScript Frameworks (May 2024)](https://developer.chrome.com/blog/frameworks-may-2024)
- -[[51:24](#memory-leaks)] Memory leaks:
- - [Memory Leaks from LocalAsyncStorage?](https://lucumr.pocoo.org/2024/6/5/node-timeout/)
- - [Sneaky React Memory Leaks: How useCallback and closures can bite you](https://schiener.io/2024-03-03/react-closures)
- - Follow-up: [Sneaky React Memory Leaks II: Closures vs React Query](https://schiener.io/2024-05-29/react-query-leaks)
- - [[52:21](#data-fetching-patterns-in-single-page-applications)] [Data Fetching Patterns in Single-Page Applications](https://martinfowler.com/articles/data-fetch-spa.html) from the Martin Fowler blog
- - [[57:19](#migrating-to-the-next-app-router-with-zero-downtime)] [Modularizing React Applications with Established UI Patterns](https://www.icodeit.com.au/posts/modularizing-react-apps)
- - [[58:12](#deno-standard-library-nearing-10)] [10 modern Node.js runtime features to start using in 2024](https://snyk.io/blog/10-modern-node-js-runtime-features/)
- - [Migrating to the Next.js App Router with Zero Downtime](https://workos.com/blog/migrating-to-next-js-app-router-with-zero-downtime)
- - [Deno announces the standard library is nearing 1.0](https://deno.com/blog/stabilize-std)
- - [[59:11](#why-dont-we-do-acid-tests-anymore)] [Why don’t we have things like the Acid3 test anymore?](https://twitter.com/vcarl_/status/1805627502036983995)
- - [[01:03:09](htmx-simplicity-in-an-age-of-complicated-solutions)] [htmx: Simplicity in an Age of Complicated Solutions](https://www.erikheemskerk.nl/htmx-simplicity/)
-
-[00:00] **Carl Vitullo:** Hello, thanks for joining us. This is June's edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers.
-
-[00:13] I'm Carl, I'm a staff product developer and freelance community manager here at Reactiflux, where I run community programs like these events and build tools that help keep the community going.
-
-[00:24] **Mark Erikson:** Hi, I'm Mark Erikson. My day job is working at Replay. io where we're building a time traveling debugger for JavaScript. And outside of that, I do Redux stuff.
-
-[00:33] **Mo Khazali:** Hi everyone. I'm Mo. I head the mobile team at Theodo. I'm quite active in the React Native community and I organized the React Native London meetup and here and there dabble in open source with a couple of libraries in the React Native ecosystem. Very happy to be here.
-
-[00:47] **Carl Vitullo:** Uh, I'm just going to start off with some quick hits of new releases and conferences.,
-
-## Layoffs updates
-
-[00:51] **Carl Vitullo:** Starting off immediately, because the market, the job market is so bad, I've been reading off stuff from layoffs.fyi.
-
-[00:59] We're not quite at the end of June, it's a couple of days left at time of recording, but most of the way through June, we're at about 9. 2, 000 laid off from 40 companies, which is down, I mean compared to six months ago we're down substantially, but compared to two years ago we are up substantially, so it's still not great. I've seen some other broader metrics trickling out from other places, like I saw a link from ADP that I unfortunately don't have handy suggesting that the overall like, tech market is at about 80 percent of it was, I believe, compared to 2018.
-
-### [The rise—and fall—of the software developer](https://www.adpri.org/the-rise-and-fall-of-the-software-developer/)
-
-[01:35] **Carl Vitullo:** Yeah, I, I found that really interesting because between hearing headlines about like record hiring during the pandemic and record layoffs in the two years, after that, it was like, Where do we end up? So that's the first data point I've seen, uh, addressing that question of, like, what's the net gain loss, and it suggests net loss of, like, 20%, which seems massive, but yeah, it's also, it's ADP, I don't know how much to trust that, I would assume that they got a very large sample size, but I'm not sure how they defined, like, tech, so, I don't really know how to interpret that in, through a lens of like software development.
-
-## New Releases
-
-[02:12] **Carl Vitullo:** But yeah, moving on to some new releases.
-
-### [Turborepo 2.0](https://turbo.build/blog/turbo-2-0)
-
-[02:14] **Carl Vitullo:** There is TurboRepo 2. 0. That's probably especially relevant if you're doing stuff with Next. It looks like it's mostly like a fancier UI. They're doing like a pretty high effort in terminal UI. Like it's, you know, reactive and interactive. And you can now break down your logs on a per task basis rather than it just being, you know, a constant scroll back the way terminals usually are.
-
-[02:38] So that seems neat. Oh, they had some new docs, and it looks like they included some, like, fundamental information about Monorepos, which seems cool.
-
-## React Admin v5
-
-[02:47] **Carl Vitullo:** React Admin released version five. We actually had Francois Zaniotto, hope I'm not mispronouncing that, on as a guest a couple of weeks ago, and I think he's super cool.
-
-[02:57] I love his ethos for the company that he's building, which maintains React Admin and does agency work. So I just wanted to shout that out.
-
-### [Rsbuild 0.7](https://rsbuild.dev/community/releases/v0-7)
-
-[03:04] **Carl Vitullo:** RS build released version 0. 7, which they say is going to be the last release before 1. 0. Mark, you had some thoughts?
-
-[03:14] **Mark Erikson:** ByteDance, the folks behind TikTok, have a massive web tooling infrastructure team. They've actually rebuilt Webpack in Rust, and I know that, you know, rewrite it in Rust is its own meme at this point, but it seems like they've, they've truly built a Webpack compatible version in Rust called RSPack. On top of that, they have a higher level abstraction layer called RSBuild, which has an easier configuration format, a little bit like ESBuild does. if you actually look in their docs, they have a migration guide for switching from Create React app to RSBuild. I did that on a little side project a few months ago.
-
-[03:55] It was really easy to switch and the compile time dropped from like 30 seconds to less than a second. it feels like a, an actually viable competitor tool.
-
-[04:06] **Carl Vitullo:** Nice. Super cool.
-
-### [Biome 1.8](https://x.com/biomejs/status/1797963672004043040)
-
-[04:08] **Carl Vitullo:** We've also got biome 1. 8. Yeah. I have a soft spot for biome. I was an early supporter of Rome. I have been eager to see what comes out of that.
-
-[04:17] So yeah, it looks like they've got like new support for CSS. They have better support for language servers in workspaces, so if you've got like a big monorepo, it should work a little bit better. New reporters, migration, some more linting options, but yeah, Biome is like kind of an all in one. They try to do like formatting and linting and, yeah, it's a bundle play.
-
-[04:38] They're taking in a bunch of tools that, were separate and doing it all as one package.
-
-[04:42] **Mark Erikson:** And written in Rust.
-
-[04:44] **Carl Vitullo:** Written in Rust. Sure. So super fast, blazing fast. Is blazing fast still cool?
-
-### [Astro 4.10](https://astro.build/blog/astro-4100/)
-
-[04:51] **Carl Vitullo:** There's also Astro 4. 10. I am hoping to play around with Astro this month. So maybe I'll be able to actually, you know, say some more intelligent things about what the experience is.
-
-[05:01] But I, I know lots of people who love the tool. It looks like some small improvements, nothing too major.
-
-### [Valibot 0.31](https://valibot.dev/blog/valibot-v0.31.0-is-finally-available/)
-
-[05:06] **Carl Vitullo:** This is a new library to me, Valibot released 0.31.
-
-[05:10] It's a competitor to Zod, which does like schema validation or, you know, data validation through a schema with like type generation and all that kind of stuff.
-
-[05:19] This looks like a pretty solid competitor. They talk about, tree shaking and stuff, which I'm broadly skeptical of tree shaking as a general promise. It's very difficult to verify.
-
-[05:30] **Mark Erikson:** My understanding is that Zod, when you import it, you're basically importing a giant object that has all the possible validation types built in, and I think Valobot's sales pitch is that it's a bunch of individual functions, and so you would only import the actual bits that you need.
-
-[05:47] And therefore, you're not getting a giant blob of runtime code.
-
-[05:51] **Carl Vitullo:** Yeah, I think they said it was like, could be up to like 95 percent smaller than Zod, while also like significantly simplifying the mental model of the schema and the type validation.
-
-[06:02] If I can think about it less and have it affect the size of my code less, like both of those sound like things that I would want.
-
-[06:10] **Mo Khazali:** I guess the thing is, it's a question of how much you want to really optimize your bundle size and at what stage you're at. If I'm recalling correctly, Zod minified and gzipped was about 60kb, something around that size.
-
-[06:22] So it is quite a chunky library to add into your dependencies. So, I guess if this actually delivers on that promise and it's closer to 90 percent less than that, which is I guess 6kb, it wouldn't be too bad of a shave to do, I'd say. But, remains to be seen if it's in practice going to be that good.
-
-[06:40] **Carl Vitullo:** Yeah, I just pulled up Bundlephobia for Zod, and it's, yep, 61kb minified, 14kb minified and zipped. Which is Hefty. Yeah, that's enormous. That would give me a lot of pause.
-
-## Upcoming Conferences
-
-[06:51] **Carl Vitullo:** Onto some conferences. Mo, I think you had a few.
-
-[06:53] **Mo Khazali:** Yeah, I'll jump right in.
-
-### [React Nexus](https://reactnexus.com/)
-
-[06:54] **Mo Khazali:** So, firstly, at the very beginning of July, 4th to 5th of July, React Nexus is happening in India.
-
-[07:00] One of the great conferences that I attended last year, I really enjoyed. The crowd there was quite a, quite a large crowd as well. I think there's about 500, 600 people. So a massive conference, but people are so friendly and I got to meet a lot of lovely people. So would highly recommend if you're sort of in the South Asia region to, to definitely give it a shot, if you can make it to Bangalore.
-
-### [Chain React](https://chainreactconf.com/)
-
-[07:19] **Mo Khazali:** Mid July, we have Chain React and this is hosted by the folks at Infinite Red. Another one of those great conferences. I've not been to Chain React myself, but I'm, So involved in the React Native community that I get told every year, why are you not at Chain React? And you're missing out on one of the best conferences ever.
-
-[07:34] So the FOMO hits real hard every time around Chain React. The folks at Infinite Red are absolutely amazing, and they organized an incredible conference from all accounts that I've heard of. Everyone really loves Chain React, so if you are in the U. S. and you're in the React Native scene, you really do not want to be missing Chain React. If I was in the U. S., I would definitely be at Chain React this month, so I cannot give it more praise than that.
-
-### [GeekConf](https://thegeekconf.com/)
-
-[07:58] **Mo Khazali:** And then, lastly, towards the end of July, we have GeekConf, so GeekConf is another sort of React Native conference with a little bit of a blend of web as well added into it. So that's happening on the 25th of July in Berlin. There's also a day that's dedicated to remote track, but 25th of July is the key date that's going to be happening in person, and I'll be speaking at that conference as well, and hopefully if any of you folks are there, please do come around and say hi, would be lovely to meet some of you in person.
-
-[08:24] **Carl Vitullo:** Heck yeah.
-
-### [WeAreDevelopers World Congress](https://www.wearedevelopers.com/world-congress)
-
-[08:25] **Carl Vitullo:** Leaving the list of conferences that us as hosts have personal experience with, there's a We Are Developers World Congress in Berlin, July 17th through 19th.
-
-### [CityJS Singapore](https://singapore.cityjsconf.org/)
-
-[08:35] **Carl Vitullo:** There's a CityJS in Singapore. That's going to be July 24th through 26th.
-
-### [We Love JS Amsterdam](https://welovejs.vercel.app/)
-
-[08:42] **Carl Vitullo:** We love JS in Amsterdam in the Netherlands, August 9th and 10th.
-
-### [React Rally](https://www.reactrally.com/)
-
-[08:46] **Carl Vitullo:** And then the last conference that we're highlighting in the next two months is React Rally, which is going to be August 12th through 13th in Salt Lake City. Actually, I have been to that one in the past and it was pretty quality.
-
-[08:58] **Mark Erikson:** Yeah, I, I would also. Emphasize like React Rally has been fantastic. the organizers are great.
-
-[09:04] they do a really good job of giving it a good community feel. I was there last year and attendance was unfortunately just a little down because of trying to revive it after COVID. So if, if you can all make it to React Rally in August, please go. It's, it's totally worth, worth it.
-
-[09:19] **Carl Vitullo:** Yeah, and it's the home neighborhood for a lot of really big people in the React and web ecosystem.
-
-[09:25] there are quite a number of people who live generally in Utah and in Salt Lake City. I think Kent C. Dodds is out there.
-
-[09:32] **Mark Erikson:** Kent, Tanner, Ryan.
-
-[09:33] **Carl Vitullo:** Yeah, it's their home neighborhood. I assume they'll be at the conference. Yeah, anyway, cool. All right, moving on to some of our main content here. Mark, you want to start us off?
-
-## "SuspenseGate"
-
-[09:43] **Mark Erikson:** Boy, oh boy, oh boy. Okay, welcome to SuspenseGate. So, for the for those of you who may not have been following all the drama on Twitter, we're here for you.
-
-### ["This is the exact build we'll release as 19.0"](https://x.com/acdlite/status/1797668537349328923)
-
-[09:55] **Mark Erikson:** About a month ish ago, a month and a half ish ago, Andrew Clark actually tweeted that, We've, we've updated to a new React 19 release candidate, and we think that this release candidate is going to be the final one, like, these are the actual bytes we plan to release as React 19, unless there's any other major changes.
-
-[10:17] Well, there is now cause for major changes. And in fact, React 19 has been delayed semi indefinitely. The React team is going to be doing some updates, and we don't know how long that's going to take. Why are they doing these updates?
-
-[10:32] In November of last year, Andrew Clark put up a PR that changed the behavior of the suspense component and how it manages loading children that are suspending to fetch data.
-
-[10:44] Previously, if you had multiple children inside of suspense, And they all wanted to fetch some data. The suspense component would give each of these components a chance to start rendering and start the data fetching. And then actually pause and wait for all of the components to finish fetching their data.
-
-[11:04] Doing it all in parallel, kind of like a promise. all combination. And with this PR, the React team changed it. So that React really only gives the first child that suspends a chance to fetch, and then it waits for that child to finish loading its data, tries to re render, and then keeps going until the next child component tries to fetch data.
-
-[11:28] Basically doing all of that in serial instead. Now, they, if you look at the PR, Andrew listed some potential reasons for this. One is that this actually made Facebook. com load a little faster. But also, it has to do with how the React team thinks. that people should be doing data fetching on the client side.
-
-[11:51] And basically their argument is, you, you shouldn't be doing data fetching nested deep in the component tree. Instead, you should hoist it up to the top at like the route level or the page level instead. And so their argument is like, well, we don't think people should be doing this pattern much anyway.
-
-[12:11] So it's okay for us to change it. Now, this was done as part of React 19's development, and React 19 is a major version. So you can totally, you know, make changes. It's, it's legal under the terms of semantic versioning. And this was available in the React 19 Canaries, but as we all know, nobody actually tries out pre release versions, everyone waits until it's actually released, and then tries it, and then reports bugs.
-
-[12:38] So, this basically went unnoticed by the community for months. And about a month ago, someone mentioned it on Twitter, very briefly, and TK Dodo, the maintainer of React Query, Saw that comment and said, oh, that doesn't look great, and then didn't think about it. And then just a couple weeks later, there was another discussion thread, and suddenly TK Dodo and a bunch of other people began to realize, wait a minute, this is actually a very significant change in how suspense works.
-
-[13:08] And in particular, the React 3 Fiber developers, which is the React for 3D game engines, Realized we depend on suspense heavily because we need to be able to load a lot of different things async like game assets. So it's not just about data fetching, it's about lots of other async behavior. And they, and they started showing demos where, everything went from loading in parallel to loading as a waterfall in serial.
-
-[13:38] And now example apps were way, way slower as a result. There was a massive firestorm on Twitter. A day or so later, Sophie Alpert from the React team said, We talked about this in a React team meeting today. We didn't realize how many people would be affected by this. But also, this was a very major change to React's internals. We did this, like, seven months ago. We've continued making lots more changes to the internal since then. We can't just roll back this change. We know what we would need to do in order to re enable the old behavior, but it's going to take another fairly significant set of internal changes to do that.
-
-[14:19] So, we don't know when we're going to get around to it. Stepping back for a second, at that point in time, the community conclusions were, they already said React 19 is release candidate and ready to ship, and we don't, like, we know this would take major changes. Therefore, the conclusion was React 19 is about to ship with this behavior and we're all going to be stuck with it for the duration of React 19 as a major release.
-
-[14:45] **Carl Vitullo:** Yeah, I don't know, some of the like firestorm framing for this, it makes me a little bit like, I don't know, it's, okay, this was a, this was a confusing behavior, and something that they overlooked, but I am glad that this conversation did happen.
-
-[14:59] And ultimately, the React team had this pointed out to them and did respond ultimately, I think, appropriately. So, like, it's, I don't know, how do you, How do you do open source development with millions of people, very few of whom actually try out pre releases?
-
-[15:15] **Mark Erikson:** Yeah, that actually even ties into the events this week of Jordan Harband and some of the package updates going on. Mo, you had a thought?
-
-[15:24] **Mo Khazali:** Well, I was just thinking, well, firstly, ironically, I remember when we did the last, last month's episode, we were talking about how this might be like the quickest release cycle for React, or, well, you know, it'll be a quick transition into Release Candidate and then released, and then this came up. So I find that quite funny that sometimes these things will come up and we can't predict it.
-
-[15:41] But I think it's, you know, around the whole expecting people to test canaries and, and release candidates, I almost wonder if there's a different way that that needs to be done and if there's some level of automation that can be done to ensure that not just, you know, apps that are using RSCs and are, you know, the most up to date and exactly architected in a way where Meta wants them to be architected, are tested, but rather, there's a whole wide range of apps, ones that are built over a long period of time, there might be SPAs or other things like that, all of those get tested. I don't know if there's a nicer way to handle that, but I feel like just expecting people to test Canaries and test RCs will not catch stuff like this .
-
-[16:20] **Mark Erikson:** That's the thing, I believe the Vue ecosystem has like a full fledged, I don't know the right term for it, they have a massive automation setup that tests all kinds of libraries across the ecosystem against the latest versions of like Vue and Vuex and Pinia and Vue Router and all these other tools. And similarly TypeScript, every time you push a PR to TypeScript, it does checks against almost all of DefinitelyTyped, or at least like a, the most widely used libraries on, on DefinitelyTyped and across the ecosystem, to try to catch a lot of these issues ahead of time.
-
-[16:56] But even then, there's a distinction between, do the library's tests fail, and how are people using that library. I think in this case, React Query had one test that did parallel fetching in a suspense, but it was like two components running locally. And so the effects of it would not have been meaningfully visible in terms of timing.
-
-[17:18] **Carl Vitullo:** Right. Right. And ultimately this is a like timing and parallelism issue. And I don't know, I'm not sure that that's something that would work. have been proactively tested? Like, I'm not sure that it's something that An automated test suite could like reasonably easily evaluate. And I'm not sure that someone would have said, Oh, this is a large enough risk that we need to invest, you know, several days of engineering time in order to make sure that we have test coverage that will flag this if it breaks.
-
-[17:48] So I don't know, I, to me, this is just like such a. Niche interaction between, you know, it's, it's such a corner case between the assumptions of the React core team and the, you know, evaluation work that they do against the Facebook project and the, you know, broader needs. So like, I don't know, I saw various negative takes, like, oh, I don't know, I saw lots of various negative takes, I'm not even gonna try and imagine, try and make up one.
-
-[18:16] **Mark Erikson:** the React Summit organizers for the last couple years Have done an event that they call the React ecosystem contributors summit, where they get like 25 to 30 maintainers and contributors to various tools and libraries together in a room. And they just give us a chance to vote on whatever topics we think would be worth discussing and then give us three hours to, talk about it in whatever way we think would be useful.
-
-[18:44] So, I was there. There were two topics that were discussed. Two thirds of the room was discussing the technical aspects of the suspense change, two thirds of the group was discussing the technical behaviors. One third of us were discussing, how can we have better communication and interactions with the React team.
-
-### [Joe Savona: Some thoughts on the suspense changes from 19 RC](https://x.com/en_JS/status/1803480672327311425)
-
-[19:03] **Mark Erikson:** A couple of days later, Joe Savona from the React team put up a long Twitter thread, which is very, very good and very worth reading. And he said, number one, we're going to hold off on the React 19 release. We agree that this is a major behavior change. And frankly, we underestimated how many people would be affected by this pattern change.
-
-[19:24] So they're going to step back and they're going to do something to do it. My, my, my assumption is trying to do the actual work to re implement some of the older behavior in the, in the reconciler internals. So that's good. Like the community complained, we communicated, they listened, they changed plans.
-
-[19:43] These are all actually very, very good things, but that ties into the communications question. Like a semi official way to communicate to the React team is by filing an issue, and the React issues are basically useless in that sense. One thing, they've been full of spam, both in terms of like really, really old issues and literal, literal spam issues, but also like the React team doesn't pay tons of attention to their issues list.
-
-[20:10] And so just filing an issue is not necessarily going to get like a quick response. There's Twitter, and a lot of the, you know, React team members are very active on Twitter, and that's great, but it's also not like a formal communications channel. So, what we concluded in our little set of people talking during this Contributors Summit, is that we really need to bring back this idea of a working group.
-
-[20:36] For React 18, the React team put together a React 18 working group where they specifically invited 50 to 75 people from across the ecosystem and continued adding to it over time. And there was a public GitHub repo where the React team and the invited contributors could write comments. Anybody could read it, so the discussions were public, but the idea was have a high signal ratio of meaningful discussions and questions about React 18, how things worked, how people could actually use some of the features and what the practical results would be.
-
-[21:12] And I think that was a great success. Like, there was a lot of really good information in that repo. So our conclusion, as the little group of people talking amongst ourselves, was we should somehow have a permanent version of the working group. And actually, Tanner Linsley independently tweeted the same thing a few days later, as well.
-
-### [Tanner Linsley: React needs a permanent working group](https://twitter.com/tannerlinsley/status/1802798385810018769)
-
-[21:33] **Mark Erikson:** So along with that, Joe Savona also said in his tweet thread that we are actively looking at how can we get more feedback on pre release versions and how we can actually Have better communication with the community. So, I don't know exactly what will happen, but I'm hopeful that something like this working group model would be an option going forward.
-
-[21:55] **Mo Khazali:** That's not, you know, too far away from how the React Native team does it, you know, for, for the past couple of years, I'd say, since, you know, Nicola Corti and Riccardo have come into the React Native team, they've been pushing this sort of release cycle where they'll have two, three different people from the community owning the release process for each version of React Native that comes out, and that Inherently add some level of community involvement to the releases.
-
-[22:17] Obviously a working group with more and more and more people, you know, about 60, 70 people sounds like there's going to be even more exposure, which is great. But I think it's, it's something that could take a page out of the React native core teams book as well, because they've done it successfully there.
-
-[22:29] **Mark Erikson:** Overall, takeaways are, nobody tries pre release versions, we really need a formal communications channel between the React team and the community that they will pay attention to, and that we can collectively offer feedback that they will see.
-
-[22:44] **Carl Vitullo:** Yeah, I, I, I chimed in on that because I don't know, Reactiflux, we're a thriving subset of the community.
-
-[22:50] Maybe we could be a neutral space for that type of communication to happen where they don't need to own the moderation side of things that has not turned into a conversation. So, hey, maybe it will eventually, but yeah. Twitter is definitely, I'm not sure how effective it was ever as like a DevRel, you know, source of truth, but now, like, if you don't have an account, they don't even let you view tweets, so, I think it is past time, well past time for DevRel from the React team to go somewhere else. Like it is, it's been over a month since the last blog post. And other than that, I don't know where any communications from the React team out to the broader community come from. It's basically the blog and the Twitter and the blog is not active. So. Yeah, I hope that that working group concept turns into something a little more effective.
-
-### [TC39 proposal advances](https://x.com/robpalmer2/status/1801239842908438694)
-
-[23:42] **Carl Vitullo:** But yeah, okay, cool. Next subject, TC39 proposals. A bunch just came out. I'm just going to kind of run through this on the high level. Yeah, promise. try, it looks like it's pretty much just like a quick wrapper on, , you know, new promise, and then you immediately resolve with a value.
-
-[23:58] I've done that a number of times, so I guess there's a use case for this, but in the abstract I'm not really coming up with a great example of why you would want to just Take a synchronous value and make it a promise.
-
-[24:09] Deferred import evaluation seems useful. it's a way, it's a way of delaying execution of some parts of the import process when you're getting a module in.
-
-[24:20] You can, you know, mark it as deferred so that it will not actually evaluate the module. It'll still like parse it and do some other interpretation steps that I'm blanking out at the moment. But it will not actually evaluate the code until later on.
-
-[24:33] **Mark Erikson:** Basically this, this allows. Speeding up, like the initialization process by not running all the code in the application right away on startup, even though you know, you'll need some of that code later.
-
-[24:48] **Carl Vitullo:** Yeah. Okay. There we go. Another one was joint iteration. I thought this was pretty cool because I've needed this a number of times. It's a way of iterating over more than one. iterable at the same time. That's on stage 2. 7, which means it's still pretty far from getting shipped.
-
-[25:03] Error. isError seems very useful for, for types. I guess lots of new stuff is moving down the pipe, I don't know how many of these are super important to call out in great detail, but yeah, Mark, Mo, anything that caught your eye is particularly important?
-
-[25:18] **Mo Khazali:** I, I really think Error.isError is the one that I'm most interested in. Obviously quite a while away before it gets to adoption. It's still on the process step two, it's stage two, but hopefully very soon. Well, I don't know how long this process is going to take for them.
-
-[25:31] It was interesting. The TC39 meeting that they had was happening in Helsinki, uh, near Future Frontend, which was a conference that we gave a shout out to last month.
-
-[25:39] And I happened to be there. That was quite cool to see some of these folks gather together and how they chatted about some of these standards. Just being privy to those conversations was fascinating. So they have a, they have an incredible process that I've, I've not seen anything like before in any other sort of working group.
-
-### [Panel discussion at Future Frontend](https://youtu.be/29wHaG7eVPM?t=17422)
-
-[25:53] **Mo Khazali:** So quite interesting, would recommend. There's a, if you go onto the Future Frontend streams, they actually have a big panel discussion for, from the second day of Future Frontend, and they actually discuss some of these proposals in detail, which is quite cool.
-
-### [React partners with Codemod](https://codemod.com/blog/react-announcement)
-
-[26:05] **Carl Vitullo:** All right, let's move on to the next one.
-
-[26:08] This is, I'm, CodeMod they announced they are partnering with the React team to help migrate to React 19.
-
-[26:16] I know, I feel like the React team initially popularized the idea of CodeMods. So this is like not a surprise at all to me. I guess I wasn't really familiar, wasn't really aware of Codemod as like its own separate team. I see, you know, this is posted by the founder of CEO of Codemod, I guess.
-
-[26:34] So that's kind of news to me. But yeah, so there's gonna be more Codemods, I guess, to help your codebase stay up to date with React 19.
-
-[26:42] **Mark Erikson:** I am very familiar with code not code mods as a technical concept I had no idea there was an entire company devoted to building tools for code mods as like a corporate thing.
-
-[26:53] **Carl Vitullo:** Right, right as a technical thing Very familiar. I don't really understand what the business case for that would be. I don't know, I guess maybe consulting. Maybe it's a services business.
-
-[27:03] **Mo Khazali:** Apparently the way that they also make it more effective is that they apparently pair it with some AI. It might be a pivot, I don't know, but apparently they pair it with some AI and some nice CLI tools to make your code mods more effective. That's not an endorsement, I don't know if it works well, but that's seemingly their model.
-
-[27:20] **Carl Vitullo:** Makes me a little skeptical, but yeah, I don't know. Codemods generally are great.
-
-[27:24] Any migrations and like major refactorings like that are definitely substantially helped by having automated tools that do, you know, even if it's like 60 to 80%, that's still pretty great, but yeah, cool. So there's an official partnership there. So I guess there's a business that is writing these codemods and the React team is in collaboration with them to make sure that they work well.
-
-[27:45] That's cool. That's great. Love that it's not just the core team trying to do everything on their own. Yeah, Mark, you want to take us on to React Compiler?
-
-## React Compiler
-
-[27:52] **Mark Erikson:** Sure. So, React Compiler came out in beta at ReactConf, and so we're starting to get, you know, various examples of people trying it out hands on in the real world.
-
-### [I tried React Compiler today, and guess what… 😉](https://www.developerway.com/posts/i-tried-react-compiler)
-
-[28:03] **Mark Erikson:** There was a very good post from Nadia Makarevich, I believe is the name, who has written a number of excellent articles about React rendering in the past. And she tried it out on both some toy applications and some larger, real world codebases that she had. And she found that the results were mixed. She expected the compiler to optimize fairly large percentages of the components in those codebases.
-
-[28:29] And it only seemed to optimize like 20 or 30 percent. Now, , apparently the compiler tool does have a health check command that will tell you which components it would bail out of because those are breaking the rules of React. And I believe that the updated React lint rules can also give you an indication of which components might not get optimized.
-
-[28:51] But her takeaway, I believe her takeaway was You know what? Well, okay, like this, this seems promising, but if real world code bases aren't going to get, or are we going to have like 20 to 30 percent of the components improved, that's not quite what we were pitched. Now, I will note that, uh, Satya from the React, React compiler team, I believe commented here in Reactiflux that, hey, this article is great.
-
-[29:14] Like, we got to See these example apps that she posted about, and we've been doing a bunch of additional changes to make sure we're handling those cases. So, I mean, just because it didn't work perfectly in her case, doesn't mean that the compiler's bust. It just means that it's still a work in progress. So having that real world feedback is actually very good.
-
-### [Understanding React Compiler](https://tonyalicea.dev/blog/understanding-react-compiler/)
-
-[29:32] **Mark Erikson:** And then Tony Alicea, wrote an Excellent article that actually breaks down what the compiler does and what the output looks like and how it works in practice. So, very worth reading if you want to understand what the compiler actually does for you.
-
-[29:47] **Carl Vitullo:** Heck yeah. Cool. Yeah, I guess I'll move us on.
-
-### [Why don't we have a Laravel for JavaScript... Yet](https://wasp-lang.dev/blog/2024/05/29/why-we-dont-have-laravel-for-javascript-yet)
-
-[29:50] **Carl Vitullo:** I wanted to call out this There's been a lot of, conversation that I've seen around, like, Laravel, specifically, specifically Laravel, Theo put out a video that then somebody wrote a blog post replying to of, " why don't we have a Laravel for JavaScript?"
-
-[30:06] And this actually crossed my radar from somebody who's not in the React world at all, they were talking about scoping a project, adding authentication to some app. And they said, "this developer estimated two weeks to add authentication to the product and I thought that was ridiculous. We have that out of the box in Laravel."
-
-[30:24] I, I, I chimed in because it's like, you know, I've done auth a couple of times in my life, in my career and like, yeah, you know, okay, sure. A login form, that's not hard to do in a day, but when you get like a settings page and you know, you got to be able to change your email address and reset your password and do two factor authentication and, you know, social login, It's like, you know, I mean, two weeks doesn't sound that wrong to me.
-
-[30:48] And he replied like, All of this is, all of that, everything you just described comes out of the box in Laravel. And it's like, alright, you know what, okay, maybe we do complicate things a little bit. Maybe not overcomplicate, but I guess, it, it, we do have so much flexibility and modularity and ability to Write things from scratch in React and, you know, in the React ecosystem more broadly, maybe that we have, you know, as far as the pendulum swings, maybe we have stayed in maximum modularity mode for a little bit longer than might be optimal.
-
-[31:21] I don't know. I, I'm curious what you guys think of that. where's the trade off? Where's the optimal line between modularity and out of the box functionality? I
-
-[31:29] **Mark Erikson:** mean, I think a lot of it also is the, you know, the whole back end, front end split. I mean, Laravel, you know, PHP, Rails, Ruby, they are back end languages, and the use case is You know, like, you know, the back end is doing basically all the work for you, and then, you know, there, there might be some additional stuff on the front end.
-
-[31:53] And so I think the frameworks there, they've, they've been around longer, and also they evolved to have, we, we need to have everything the back end needs to do all the work. Whereas, JS has always had the front end, back end split, and it's not that we couldn't build something that was, you know, absolutely out of the box like that.
-
-[32:13] I mean, there are, you know, some examples of that in the JS ecosystem, but I think it's typically been much more of a, like, I just need a basic HTTP server like Express. to serve up my client side code and then go from there. So, I think the modularity is a big aspect, but then also the differences in, like, the ecosystem historically as well.
-
-[32:34] **Mo Khazali:** I do think, you know, I've spent a bit of time working in the Django world a little bit, and I can definitely see the appeal to having something like Laravel, where so much comes out of the box. Done for you. And that interconnectedness means that it is a lot smoother to do things like you mentioned, like settings on a profile to modify those things.
-
-[32:51] They're all like one centralized model in Django. And it's significantly easier to create those sort of CRUD operations for users on like a settings page. It doesn't take you weeks. It takes you a day. And I know a lot of people who've been developing a while, like they spent time in the PHP world or in the Python world with Laravel or Django, and then they, you know, started doing React in our company and they were all like, this sucks, really don't like doing this.
-
-[33:12] It was so easy with Django, but I guess it's the pendulum swings and we probably land on some sort of midpoint, you know, I wouldn't be surprised if people start building things on top of Next, which allows it to be a more full fledged opinionated server that also can render and template React code.
-
-[33:26] **Mark Erikson:** That's what Blitz was. Blitz started off as the whole suite of things to go with Next, and then they tried to fork Next, and then they gave up on that idea.
-
-[33:35] **Carl Vitullo:** Yeah, and I mean, I guess this is, over the last ten years, React has slowly, I feel like it's grown in scope of, like, where people want to use it.
-
-[33:43] Like, when I first started it, There was a lot of, put it in, like, this spot, this little rectangle on the website, like, that's where React goes, and several years ago, that moved into, most people are using React to build their entire app, like it owns the entire client side, and now we're moving Up the chain into React owns more of the server side as well.
-
-[34:05] So maybe that's just kind of like the, this projects like Laravel already owned the data model in the server. And they had to come from there into owning more of the client side to provide a better experience there. And they certainly don't compete with React there in any meaningful way. Like nobody would, I don't think anyone would seriously suggest that projects like Laravel are able to provide. An exact, or a highly comparable, interactive client side experience.
-
-[34:35] You know, as I'm saying that, nobody would argue that. I think DHH has seriously argued that.
-
-[34:39] **Mo Khazali:** I was gonna say DHH hasn't argued that yet.
-
-[34:42] **Carl Vitullo:** So, okay, people do People do argue that, but let me add the caveat of offline capable. I don't think anyone would seriously argue they provide an offline capable client side experience comparable to React.
-
-[34:54] And so, yeah, I guess, you know, now with, as server components expand in utility and capabilities, like, yeah, maybe we will start seeing more of a Laravel. Or Ruby on Rails type of full ownership of the experience, which would make it more easy. Because that's really the problem here is React isn't even aware of the data model in most applications.
-
-[35:18] So that makes it very hard to do CRUD interactions, if you don't have the data, if you don't have direct access to the data. I just thought that was a really interesting framing for this. Like I have all, I've, I've lived in React for many, many years. And so then seeing people talk about how quickly you can do common tasks in a Laravel, it's like, Oh, Shit. Interesting. That's, that is a big difference.
-
-[35:39] Cool. Let's move on to Vercel Ship, their conference roundup. Moe, do you want to take us on that?
-
-### [Vercel Ship 2024](https://vercel.com/blog/vercel-ship-2024)
-
-[35:45] **Mo Khazali:** Sure. just the general and quickly running through this, Vercel is obviously moving across and, and taking up more of the, more than just becoming a hosting platform, so.
-
-[35:54] There's pieces on how you can collaborate and people in different teams can collaborate and, you know, preview different sort of webpages. And we've seen some stuff like that and more focus on observability. So they've added things like metrics and feature flags. And so there was someone who actually commented on Twitter about how beautiful their toolbar was as well, which I thought was quite cool. But no, there's, there's like a lot of direction around like product collaboration and a push in that, in, in that direction. So that's quite interesting.
-
-[36:18] Just on the observability piece, I actually found it quite interesting that hosting providers are going in that space. So Cloudflare a few months ago acquired Baseline, which is also an observability tool, and I think they're trying to integrate it into their workers slash Cloudflare pages space, which is a competitor to Vercel's, you know, hosting platform plus their, their serverless functions that they've got.
-
-[36:37] So, or the edge functions that they've got. So I think it's interesting that a lot of them are moving. Past just hosting into that observability space as well. And I think there's going to be a pretty big competition in that space in the next couple of years.
-
-[36:48] **Carl Vitullo:** Okay. That makes sense. Yeah. I haven't yet played with this at all, but I think I've heard people discussing the Vercel, metrics and feature flagging and that, yeah, I think that the, tacking those onto the, to a hosting provider does make a lot of sense to me because I feel like you get, you start getting a lot more things for free if those are all bundled together into one thing, like, I don't know, just having used LaunchDarkly and other feature flagging tools like that.
-
-[37:14] It feels like if they knew when a release was happening, if those feature flagging tools knew when a release was happening, I can imagine various optimizations or improvements to the, like, developer experience, the experience of putting out a new release that could be enabled by that. So yeah, that's something I'm paying attention to.
-
-[37:34] We'll see how that goes.
-
-### [TS 5.5](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5/)
-
-[37:35] **Mark Erikson:** All right, next up, TypeScript 5. 5 is out. And the, the single biggest thing that is interesting about this release is what they're calling inferred Type predicates. So as a little bit of background, one of the nifty things about TypeScript is you can write code that does runtime checks, and TypeScript uses that to narrow down TypeScript type of a particular variable is.
-
-[38:00] And part of that is not just having like an if statement, but actually having separate functions that, for example, accept any value, and then they do some runtime checks and you tell TypeScript, if this function returns true, then the actual TS type of the value must be some more specific type. And so you can use that to tie together runtime checks and type and compile time behavior.
-
-[38:27] But the issue was that things like filter callbacks for arrays, which return a boolean, didn't do any of that narrowing. And so you might have, like, an array that could be, like, item or null, and you could do a check. In the filter callback and say, if thing is not null, you know, return true, which ought to tell you that by the time we're done, we only have actual items and no nulls.
-
-[38:53] But TypeScript wouldn't automatically narrow down the TS types based on callback functions like that. So with TypeScript 5. 5, they've improved the type inference. So that if you have a function that accepts some value and does some checks and returns a boolean, TypeScript will automatically try to narrow down the TS types of the output to be stricter.
-
-[39:18] And so, this is going to be a nice little quality of life improvement for a lot of different TypeScript use cases. One other interesting thing that I saw in there, is that apparently they're doing some syntax checking on regular expressions. Mostly just catching things like, you know, like you have too many parentheses in there.
-
-[39:36] But that one's actually pretty cool too.
-
-[39:38] **Carl Vitullo:** Yeah, definitely super cool. I, on my list of things that I, that would make me excited, like typescript checking regexes was not on there, so I, Very unexpected for them to even start moving in that direction. But like, heck yeah, please help me make my regexes a little more robust.
-
-[39:54] **Mark Erikson:** One other thing towards the bottom that's under the hood. So they've done some changes on their internal variable definitions. So that they get more optimized by the JavaScript runtime, basically making sure that the same fields always exist. And you don't like occasionally add an extra field to the object dynamically.
-
-[40:15] And so because of that, the runtimes are able to optimize the behavior. And they found that it actually improved compile times by like 5 to 10 percent just by making the fields more consistent.
-
-### [TypeScript 5.5 is a BANGER](https://www.youtube.com/watch?v=sciBO_IaxTw)
-
-[40:26] **Carl Vitullo:** Yeah, I also want to share, Matt Pocock did a really great, just like quick 10 minute video breaking down what's new in TypeScript 5.
-
-[40:35] 5. So definitely worth, he's just such a great TypeScript expert. Just wanted to call that out. Great resource.
-
-### [Mind The Gap talk](https://www.youtube.com/watch?v=1g5ruM-16_Y&t=7595s)
-
-[40:41] **Carl Vitullo:** Cool. I wanted to shout out a conference talk by Ryan Florence that came out of Big Sky DevCon. I saw quite a number of people referring to it as like the best talk I've seen in years. I don't know if I would go that far personally. It's a great, it is a great talk.
-
-[40:57] It's, it's kind of just, I think I would describe it as like an oral history of the Problem space that React Server Components is trying to address. It just sort of talks about like the difference between, you know, the server and the client and the network being in the middle and plots out a couple of different tools and where they live in that, You know, taxonomy.
-
-[41:19] Definitely worth checking out. I mean, Ryan Florence has been around for so, so long. So hearing him just do kind of a dump of history of a problem, I thought was really interesting. It was definitely worth listening to.
-
-[41:32] **Mo Khazali:** I'll jump in with some React Native stuff quickly.
-
-### [Lorenzo Sciandra exiting React Native](https://x.com/Kelset/status/1800158749811966280)
-
-[41:36] **Mo Khazali:** So first, and I'd say most significant news in this space is unfortunately that Lorenzo Sciandra from the Microsoft team is leaving the React Native world and also leaving Microsoft, which is, I would say personally, a pretty big blow to this, to this community.
-
-[41:51] He's been such an instrumental part of. Getting more and more community involvement inside of React Native. He's been doing React Native for more than six years and, you know, being based in the UK. I've known him personally for a couple of years now and such a lovely guy. And I think he's moving on to focus something around making sure that the tech space is A little bit healthier and a little bit more humane, as he likes to put it.
-
-### [debug:mind by Lorenzo 'kelset' Sciandra](https://www.youtube.com/playlist?list=PLiD6R_aXkpLiMfS2YrhSgtSj09JJCaP2y)
-
-[42:13] **Mo Khazali:** And he's been focusing on mental health struggles within the tech ecosystem and within, within a career of tech. So you should definitely check out his podcast called Debug Mind. But really just want to, from the bottom of my heart, say a big thank you to Lorenzo for everything that he's done over the last six plus years.
-
-[42:27] An absolute shame that he's leaving us, but I am very excited for everything that he's going to be doing afterwards.
-
-[42:33] **Carl Vitullo:** Yeah, I have repeatedly come across his name when I've looked for React Native resources. He's done so many great lists of like, I can't even remember the various types of lists he's done, but just like major projects in the React Native space and educational resources on React Native.
-
-[42:51] Yeah, definitely a big blow to have him exit the ecosystem.
-
-[42:55] **Mo Khazali:** And, you know, more than that, you know, I think Lorenzo has been sort of the person who's been trying to bring the meta team closer and closer to the community. So, you know, Lorenzo, for the first time that I went to Meta's offices, Lorenzo invited me and, Organize that with a lot of the Meta folks to, to bring me over and, you know, for me to be able to chat and bring some of my concerns over to some of the folks at Meta and, you know, that became more of a recurring thing, all thanks to Lorenzo.
-
-[43:17] So he's been very instrumental and he's one of those sort of open source maintainer that maintainers that really cares about the community. So yeah, definitely a big blow.
-
-[43:24] **Carl Vitullo:** Yeah, and earlier, Mark was talking about how the React Native team has been a little bit better than the React core team at interfacing, doing like working groups and things like that, and including the community and the development.
-
-[43:36] I wonder, I wonder what role he played in making that happen.
-
-[43:40] **Mo Khazali:** A major one, definitely. So, yeah, but. Best of luck to him. I'm sure he's got some amazing stuff lined up that he's going to be exploring next. And yeah.
-
-### [Expo Atlas](https://expo.dev/blog/introducing-expo-atlas)
-
-[43:47] **Mo Khazali:** Next up, one thing that I'm personally super excited about is Expo Atlas. So Expo Atlas is almost like a sort of bundle size visualizer, but taken to a little bit of a higher level.
-
-[43:57] And this is something that's been missing from the React Native ecosystem for a long time. So just a little bit of context. Bundle size has never been a concern for the React Native ecosystem, unfortunately. For, for, for better or for worse, because it's all sort of sent once in the bundle of an application, when you download it from the app store, people don't seem to really care that much about how much JavaScript you ship, so long as it's downloaded once it's done.
-
-[44:19] And, you know, things like app startup time and actually, you know, having a lot of JavaScript and runtime don't affect React Native apps as much because of. Things like Hermes existing, where you have an engine that will have some sort of like bytecode representation and not have to load the entire JavaScript bundle into, into its runtime.
-
-[44:35] So that's been a challenge when you're trying to take React Native and put it on the web and deal with this whole universal story. And so, you know, one of the things that I spent a lot of time around React Summit, speaking to Evan and Cedric from the Expo team about was, you know, how do we make sure that some of the third party libraries that have.
-
-[44:52] I've been creating over a long period of time in the React Native ecosystem, actually have small bundle sizes when you try to take them to the web. And Expo Atlas is kind of the take that the Expo team has at doing that, which is, well, a lot of these libraries are all CJS based, so if we just introduce tree shaking into the bundler for React Native, It's not going to necessarily solve that problem by itself because most of the libraries won't be tree shakable.
-
-[45:13] So then what's the way to do it? Well, let's just visualize the problem, see what libraries are bundling in a lot of crap, and then see if we can slowly start to, as a community, shave some of that off and improve the performance for React Native web apps. This is a slow burn. It's not going to. Change over the next year, two years, maybe even three years, because there's a lot of legacy there.
-
-[45:31] But I think it's the right step. It's showing and visualizing the problem. So great tool that's out there. We'd definitely check it out. It shows you in a different way to how like the bundle visualizers that you might be used to, it actually shows you which import of a library you have in your code that is actually causing this library that might be bloating your bundle to be loaded.
-
-[45:50] So, you know, it might, it goes down the tree for transitive dependencies as well, which is quite cool.
-
-[45:54] **Mark Erikson:** Oh, that's wonderful.
-
-[45:56] **Mo Khazali:** Really great tool.
-
-[45:57] **Carl Vitullo:** Yeah. I'm looking at this, the visualization of the blog post with the, you know, recursive squares showing the, the bundle size and, oh man, I remember almost a visually, almost identical tool, much less polished.
-
-[46:10] Clearly this has someone who did a design pass, but there was a very similar tool that came out for Webpack in like, I don't know, 2014.
-
-[46:19] **Mark Erikson:** There's been a number of them, Webpack Bundle Analyzer, Source Map Explorer, and a couple others.
-
-[46:25] **Carl Vitullo:** I, I like practically made a career out of like fixing performance issues just because I learned that tool and it actually enabled me to do things.
-
-[46:33] So yeah, cool. Love to see it. Love to see it in the React Native context. Definitely looks valuable.
-
-[46:38] **Mo Khazali:** Cool. So then a few sort of quick things.
-
-### [Expo adds Compiler support](https://github.com/expo/expo/pull/29168)
-
-[46:40] **Mo Khazali:** Firstly, Expo's now added React compiler support. We saw this in the React Conf app. It was already using the React compiler. So just, you know, if you want to try it out experimentally, you can use the React compiler and see how it works for your app.
-
-### [Starlink's React Native app](https://www.notjust.dev/blog/react-native-starlink)
-
-[46:52] **Mo Khazali:** Next up is Starlink's React Native story. So this was interesting because it came out during AppJS, which happened last month. So the Starlink app is, is obviously built with React Native and it uses a lot of the expo libraries and things like React 3 Fiber. And it's really cool to see how some of these tools that we all have available to us are used in practice in some pretty serious production apps.
-
-### [Expo Router 3.5](https://twitter.com/Baconbrix/status/1788235769812795559)
-
-[47:14] **Mo Khazali:** And then another quick fire one, minor changes to Expo Router in Expo Router version 3. 5. So, just some stuff like, you know, supporting the, the sort of the hash parameters. There's some stuff around native, native intents with deep linking that you'll need for having a more seamless handoff between different Devices, and also for allowing for certain links to, to come with more details to, to really augment the native functionality.
-
-[47:38] Another small thing that I think is quite important, that's not actually one of the top headlines with this, is that previously Expo router was using an, a non standard version of the request and response. And with this version, they've, they've standardized it a bit more, which is great because that should definitely be standardized.
-
-[47:55] And then a few. Other minor things that I'm just going to run through. One is React Native Vision OS won the Git Nation Open Source Award, which was quite cool. It's a really cool project. Definitely give it a shot. And the folks from Callstack were there at a bunch of these different conferences with Apple Vision pros, trying to get people to try out React Native with Vision OS, which was quite a fun thing to try out.
-
-### [SF Symbols beta support in Expo](https://docs.expo.dev/versions/latest/sdk/symbols/)
-
-[48:16] **Mo Khazali:** Next up there is sf symbols. So sf symbols is sort of an icon pack that comes default with iOS. It oftentimes feels very Apple esque and having that inside of your app means that the icons are uniform with the OS and they look and feel like it's an iOS application and Expo's added beta support for it.
-
-[48:36] This is an interesting one because React Native is obviously cross platform. The main targets that you'll have is an iOS and an Android app, so specifically supporting icon sets and an icon set that's available for iOS means that you may need to have some divergence in your code base if you want to really use those SF symbols, and you'll need to create or choose equivalent Android icons, so a little bit of an odd take, but I'll see you A lot of people seem to really want to use SF Symbols, even with React Native apps.
-
-[49:03] So I'm sure that there was a level of feature requests and community involvement in trying to get that working. So that's definitely there. And then lastly, React Native Screens. This is actually a library that you will rarely ever have to use directly inside of your application code, but it's actually being used under the hood by React Navigation, which is by far the most common navigation library within React Native.
-
-[49:25] And they've just added some extra minor improvements. One that's quite cool is transparent header support. Obviously on the native layer, there's functionalities on iOS and Android to be able to add a transparent heading that's got a little bit of a blur, and it comes up with some cool effects. You can do that in React Native with the, with the default navigation libraries.
-
-[49:43] So React Native Screens has been updated to support that on both iOS and Android now, which is just cool minor changes. And that's just about everything that's been happening in the React Native ecosystem in the last month.
-
-[49:53] **Carl Vitullo:** Nice. Excellent. Thank you for catching us up.
-
-[49:56] Okay, shall we move on to our lightning round, see how many links we can get through there?
-
-[50:00] **Mark Erikson:** Yes, because we're already an hour in, so moving right along.
-
-### [React Internals Explorer](https://jser.dev/2024-05-11-introducing-rie/)
-
-[50:03] **Mark Erikson:** I saw a really, really cool tool called React Internals Explorer. It looks like you write some React code in a sandbox editor. And then it actually digs into the React fiber tree and shows you the structures of that.
-
-[50:17] I haven't even had time to play with this, but just like glancing at it and seeing a screenshot. I'm actually really, really excited about this because I love digging inside React's internals. I know most other people don't need to, but this looks really helpful. And the author has already written a whole series of blog posts where they actually go straight into the React source code and explain how specific features of React are implemented under the hood.
-
-[50:41] So if you want to know how React works inside, very worth reading.
-
-### [What's new in JavaScript Frameworks for May 2024](https://developer.chrome.com/blog/frameworks-may-2024)
-
-[50:44] **Carl Vitullo:** Yeah. I wanted to call out a blog post from the Chrome team where they just, they do a recap. What's new in JavaScript frameworks for May, 2024. So this is, I guess this is old. It's undated. So I guess it must have come out last month, but they are just, they just quickly round up a bunch of.
-
-[51:02] they go through like Angular, Astro, React, Remix, Next, Vue, NUC, Solidsfelt, and a couple of others. Yeah. This is Adi Osmani is. One of the, you know, it looked like they did a video and wrote a blog post with it. I thought it was curious, or I thought it was interesting to see what the Chrome team thinks about JavaScript frameworks.
-
-### [Memory leaks](https://lucumr.pocoo.org/2024/6/5/node-timeout/)
-
-[51:24] **Mark Erikson:** There were a few different blog posts that touched on the theme of memory leaks. There was one that talked about memory leaks inside of Node, potentially if you're using the relatively new local async storage feature. the example there was with setTimeout.
-
-[51:42] Apparently, Node can be keeping track of async call stacks attached to the context storage, and so you could actually end up leaking a whole bunch of memory if you're using it in certain ways.
-
-### [Sneaky Memory Leaks](https://schiener.io/2024-03-03/react-closures)
-
-[51:53] **Mark Erikson:** Uh, similarly, there are also a couple of very good blog posts talking about potential ways you might end up with memory leaks in a React application.
-
-[52:00] In cases where you're using like use callback or use memo or with React query where you're writing functions that are doing data fetching or something like that, and they're closing over variables that are in scope and they might not even be getting used. But the closure keeps those variables alive longer than you would have expected.
-
-### [Data Fetching Patterns in Single Page Applications](https://martinfowler.com/articles/data-fetch-spa.html)
-
-[52:21] **Mo Khazali:** Cool. So next up is an article that's actually on Martin Fowler's blog. So Martin Fowler being the big thought leader and evangelist of, of all things, application development, period.
-
-[52:33] **Mark Erikson:** Enterprise architecture patterns.
-
-[52:35] **Mo Khazali:** You see, divisive at the best of times, Martin Fowler is, but there's, there's been more and more React articles popping on, and they're not actually written by Martin Fowler, but they're written by someone who works at, whose name is Juntao, or actually, I don't think he works at ThoughtWorks, but he's very close with Martin Fowler, so he writes on Martin Fowler's blogs.
-
-[52:53] And he's been doing some really cool work on writing articles that start from the basic principles and expand out and create more and more complex applications that explain a bunch of concepts. So his latest article is about data fetching patterns in single page applications, and it starts with basic React concepts, builds up around, you know, asynchronous states being handled on the client side, parallel data fetching, how do you handle fallbacks, and then things like pre fetching, and then kind of It takes you through this journey and tells you when you should use which one.
-
-[53:21] Would recommend it. It's a very, very long read, probably one of the largest blog articles I've seen in a very long while, but it's definitely worthwhile if you want to get a more holistic viewpoint. And he's written a lot of articles like this. Another great one that he's written just to give a shout out is called modularizing React applications with established UI patterns.
-
-[53:38] And this is one that Mark is not going to be very happy about, but this one is one of those, which is like, how do you enterprise ify React code, but it's actually a very interesting article that has some thoughts about how you should architect React apps. And some of those patterns, not all of them, are actually very good to make it easier for you to do things like testing and so on and so forth.
-
-[53:55] **Carl Vitullo:** Cheers. Yeah. Oh man, I remember reading Martin Fowler's blog like 15 years ago when I was like starting my career. So just for it to still be relevant is like a little bit mind boggling to me.
-
-[54:07] **Mo Khazali:** The website still looks like it's from 15 years ago as well.
-
-[54:10] **Carl Vitullo:** Yeah. It's unchanged from when I started reading it.
-
-[54:13] Yeah. Not a single change that I can identify.
-
-[54:16] Cool. Yeah. I wanted to bring up a blog from Snyk, a security. Firm, I don't know, security product service, 10 modern Node. js runtime features to start using in 2024. It's, I have always found it really tricky to stay on top of every level of development over time.
-
-[54:35] So I appreciate a little roundup post like this that just sort of calls out a number of new features that I may not have caught the release of. It's sometimes it's hard to see, see the each individual release. So the 10 that they call out are a test runner. Native mocking, native test coverage, watch mode, core pack, the env loader, some import meta fields for the **dirname and **file fields, native timers and promises, permissions module and a policy module.
-
-[55:08] Those last two are not super clear to me, but like the test runner and native mocking and test coverage. Super great to not have to pull in a third party tool for that. As well as, yeah, I mean, watch mode. The number of times I've installed NodeMon. If I can stop relying on a third party package for that, I'll be pretty happy.
-
-[55:26] I haven't checked that out yet, though. CorePack is actually, I feel like the name of it makes you compare it to Webpack, or it makes me compare it to Webpack, at least. But actually, it's, the main use for it is being able to specify a package manager at a specific version, which is so useful. Um, I appreciate that they have made it, I guess it's a, I guess it's a combination of being able to pin a specific version of your package manager, but it's also, I think, some underlying tools to make cross compatibility possible between package managers.
-
-[55:59] **Mark Erikson:** The primary issue is that NPM has always come pre installed with Node. But if you want to use Yarn or PNPM, or, Bun, I guess, you have to first use NPM to install those tools globally. And that's kind of a one off per system thing. And then you have to remind everybody that they're supposed to be using this package manager, the project.
-
-[56:22] And so I think the idea of CorePack is that if you specify in your package JSON, that, Hey, we're actually using Yarn 4. 1 or PMPM 9. 2. It will automatically do the work to make sure that the right package manager is available and being used in that project.
-
-[56:40] **Carl Vitullo:** Right. It fills the gap where, like, PackageLock or Yarn.
-
-[56:44] Lock will let you pin your dependencies, left the, you know, the gap of what about the version, you know, for the package manager because the different versions interpret that lock file slightly differently sometimes. Or, you know, I've had a more recent version of Yarn blow away my Yarn or, you know, start adding things like a, a digest half to the, to the lock file.
-
-[57:06] So being able to pin a version, super great. Yeah. As well as like having a env loader, so we don't need to use env anymore. But yeah, so I appreciated this as a quick summary of a number of new built ins for Node.
-
-[57:18]
-
-### [Migrating to the Next App Router With Zero Downtime](https://workos.com/blog/migrating-to-next-js-app-router-with-zero-downtime)
-
-[57:19] **Mark Erikson:** There was a very good post on migrating to the next app router with zero downtime. One of the pain points with server components is that you have to have the entire application set up with server components as the outer layer of the application in order to use them at all.
-
-[57:36] There's no straightforward, simple, like migrate, just a little piece of my component tree. And while you can use the app router with everything still on the client, as a client component, it's still a key step in order to even be able to think about using server components with Next. And so, this article was a good example of how a team with an existing Next app that used the Pages router was able to mimic the routing setup in the app router and carefully, step by step, make sure that things worked the same both ways.
-
-[58:05] Switch over and then be able to start using some server components piece within the existing structure.
-
-### [Deno Standard Library nearing 1.0](https://deno.com/blog/stabilize-std)
-
-[58:12] **Carl Vitullo:** All right, Deno announces that the standard library is nearing 1. 0. That sounds great to me. The standard library is now a collection of 38 packages, they say. I appreciated this. Rather than doing it all in one big bang 1.
-
-[58:26] 0 release for the standard library, they're actually going to repeat a process for bringing each of those 38 packages up to stable relief. So they're gonna do it through like a release candidate and then gather feedback with like a a one month timeline for each of those packages to gather feedback.
-
-[58:45] So yeah, that's A lot of effort, a lot of energy being invested into creating a standard library and oh man, here's a standard library for a JS runtime.
-
-[58:55] **Mark Erikson:** I'm confused. Are we allowed to have that?
-
-[58:57] **Carl Vitullo:** Right? It's, it, the classic criticism of JavaScript is the lack of a standard runtime.
-
-[59:02] So, oh my goodness, we have a standard runtime hitting stable. I feel like that's going to affect the ecosystem in some way, but we'll have to see what happens there. Cool.
-
-### [Why don't we do Acid tests anymore?](https://twitter.com/vcarl_/status/1805627502036983995)
-
-[59:11] **Carl Vitullo:** I'm going to call this one out. This was, I put, I put up one of my tweets. I don't know. I think it's a good question. I'm going to do it.
-
-[59:16] I proposed the question out, why did we stop making checks like the ACID3 test? Why isn't there an ACID3 test for, for example, progressive web apps? I remember the ACID test series of, projects was
-
-[59:30] **Mark Erikson:** Browser rendering behaviors.
-
-[59:32] **Carl Vitullo:** Browser rendering behaviors. It was, is the browser you're viewing the web page in standards compliant? Here is something. It should look like this. And I remember checking that in, you know, 2008 or whatever, when I was a wee baby nerd. And, my browser didn't render it correctly, and then a couple years later it did.
-
-[59:50] I was considering, like, what factors may have moved us away from things like that, and I feel like it used to be so hard to ship new things, new standards. That it took big coordinated pushes like that, or maybe the ecosystem was also just smaller and the number of players involved were, you know, it could fit in a room, but I feel like we've lost something a little bit in there.
-
-[01:00:12] Like the acid three test was CSS three was ratified as a standard. They put out an associated test for this rendering behavior so that. Users could check if their browser was working in compliance with the standards. And I guess I, I put up the comparison to progressive web apps because like, They are not fully rolled out, like Chrome put out, the Chrome team put out a lot of support for progressive web apps, very much as a attempt, I think, to make web pages viable as competitors to native apps, and it just kind of never really happened, I think in large part because we never got cross compatibility With all the browsers for those capabilities.
-
-[01:00:54] And I don't even know that we, as an ecosystem, as web developers, have a shared understanding of what makes a progressive web app, you know, what defines a progressive web app? How do you distinguish that what you've made meets all the criteria? So, I don't know. I just, it was lamenting our lack of those sort of litmus tests for, I guess, bringing a Technical definition to some of the terms that we throw around frequently.
-
-[01:01:21] **Mark Erikson:** It's, it's not quite what you're asking for here, but I can point to a couple ways that there's been more efforts to do interoperability efforts. One is I think the latest version of the speedometer benchmark for JS engines was specifically built to include a bunch of different things.
-
-[01:01:38] Reasonable, plausible example applications using various JavaScript frameworks. Like I know that there's like a React, Redux, Todo application as part of the benchmark sequence. So that's been an attempt to semi standardize things and make things a little more plausible. Also, I believe the last three or four years, all the major browser Vendors have done, I don't remember the exact term but like an interoperability effort where they identify like the top five or six pain points of places we know where browser behavior is differing and we're all going to make a push this year to make sure we all work the same way for these things.
-
-[01:02:15] So it's, it's not quite the same as having like the ACID3 test or, you know, a named version of CSS that we're all trying to implement, but it is, it is kind of along those lines.
-
-[01:02:27] **Carl Vitullo:** Right. Yeah. I don't know. I guess I, I, I think the branding that used to be baked in to those sort of releases served, I think to me, it served a valuable function in developer education. And I think that we've lost something through not having it.
-
-### [Web Platform Tests dashboard](https://wpt.fyi/)
-
-[01:02:41] **Carl Vitullo:** Like there was a web platform tests dashboard that like, yes, here is a single place that compares all of the features, accessibility, all of the compatibility across browsers, but it's not actually, you know, as a developer, it doesn't tell me what features are grouped together? What features go well together? What capabilities are unlocked by supporting this thing? We're going well beyond the scope of a lightning round link right now.
-
-### [HTMX: Simplicity in an Age of Complicated Solutions](https://www.erikheemskerk.nl/htmx-simplicity/)
-
-[01:03:09] **Mark Erikson:** all right, and last one we got on the list. HTMX is a library for basically adding attributes to HTML tags that do things like data fetching and automatically inserting the results into the page without having to explicitly write JavaScript yourself, and they put up a blog post entitled Simplicity in an Age of Complicated Solutions, where they have some examples of handling inputs and data fetching with VanillaJS or with React code.
-
-[01:03:37] And they point out and say, look at how complicated this is. Whereas if we just slap HTML into the page and we add a couple attributes, look at how simple this is. And there's, there's some valid trains of thought to this. Certainly you're writing less code as an application developer. I questioned a little bit some of their arguments on general principle, but it is worth reading for an alternate viewpoint on how application behavior should be implemented.
-
-[01:04:00] **Carl Vitullo:** Yeah, definitely interesting from a perspective of just considering expansion of complexity too. I thought that was, I thought it was cool to read from that lens too.
-
-[01:04:08] Cool. All right. That is all of the, all the links we have. Thanks everyone for joining us. We'll be back on the last Wednesday of the month in here in the live stage of Reactiflux or in your podcast feed as soon as we can after that.
-
-[01:04:20] **Mark Erikson:** Thank you for listening. Plug, please check out Replay. io for debugging your tests and trying to fix flakes. And also, I'm almost done with a very large revamp of the primary Redux tutorial to make it TypeScript first and explain more things. Carl just pasted a link to the draft PR in there. I would appreciate feedback.
-
-### [Revamp "Redux Essentials" tutorial](https://github.com/reduxjs/redux/pull/4706)
-
-[01:04:43] **Mark Erikson:** I'm hoping to have this done within the next couple weeks. Like, I'm almost done with the first draft, and then hopefully there's not too much more work to do. So, feedback, please?
-
-[01:04:52] **Carl Vitullo:** For sure. Awesome. Yeah. Mo, anything you want to add?
-
-[01:04:55] **Mo Khazali:** Nothing. Just thank you again for having me and always a lovely time chatting with you all and going over everything that's been happening.
-
-[01:05:02] And yeah, looking forward to the next one.
-
-[01:05:03] **Carl Vitullo:** Most definitely. Yeah. Always good talking to you guys. Cool.
-
-[01:05:07] we, we gather links from, um, a bunch of different sources, including thisweekinreact, bytes. dev, reactstatus, nextjsweekly, the reactjs subreddit. Right here in Reactiflux from the Tech Reads and News channel, um, and directly from people publishing articles, usually on like Twitter or Blue Sky.
-
-[01:05:26] If you see anything that you think that we should be paying attention to, definitely feel free to email us at hello at reactiflux. com with T M I R in the subject line. That's acronym for the show. I read every email that comes in, even the ones marked as spam. If this is the show you get value from and want to support, the best way to do so is to send it to someone.
-
-[01:05:45] Send it to your co workers, help them learn how you know so much about React. Otherwise, you know, submit a review, do stuff like that. But yeah, thank you so much for joining us. Appreciate it. See you next month.
diff --git a/src/transcripts/tmir-2024-07.md b/src/transcripts/tmir-2024-07.md
deleted file mode 100644
index 09fe1d9..0000000
--- a/src/transcripts/tmir-2024-07.md
+++ /dev/null
@@ -1,642 +0,0 @@
----
-title: "This Month in React, July 2024: State of React, State of JS, React, HTML"
-date: 2024-07-31
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- Quick hits
- - [[02:14](#job-market)] Job market
- - [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE)
- - [Layoffs.fyi](https://layoffs.fyi/)
- - New releases
- - [[03:48](#vitest-20)] [Vitest 2.0](https://github.com/vitest-dev/vitest/releases/tag/v2.0.0)
- - [Future plans](https://github.com/vitest-dev/vitest/discussions/5828)
- - [[04:06](#remix-210-fog-of-war)] [Remix 2.10](https://remix.run/docs/en/main/start/changelog)
- - [[04:24](#jotai-29)] [Jotai 2.9](https://github.com/pmndrs/jotai/releases/tag/v2.9.0)
- - [[04:34](#storybook-82)] [Storybook 8.2](https://github.com/storybookjs/storybook/releases/tag/v8.2.0)
- - [[04:52](#react-native-reanimated-314)] [RN Reanimated at 3.14](https://github.com/software-mansion/react-native-reanimated/releases/tag/3.14.0)
- - [[04:59](#htmx-20)] [HTMX 2.0](https://htmx.org/posts/2024-06-17-htmx-2-0-0-is-released/)
- - [[05:03](#mako-released)] [Mako is Now Open Source](https://makojs.dev/blog/mako-open-sourced)
- - [[06:01](#conferences)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[06:01](#react-rally)] [React Rally](https://www.reactrally.com/) Salt Lake City, UT, USA August 12-13
- - [[06:25](#react-universe)] [React Universe 2024](https://www.reactuniverseconf.com/) Wrocław, Poland September 5-6
- - [[07:23](#jsconf-chile)] [JSConf Chile](https://www.jsconf.cl/) Santiago, Chile September 5-7
- - [[07:32](#utahjs-conf)] [UtahJS Conf](https://utahjs.com/conference) Salt Lake City, UT, U.S.A. September 13
- - [[07:44](#react-alicante)] [React Alicante](https://reactalicante.es/) September 19-21
- - [[08:00](#jsconf-ireland)] [JSConf Ireland](https://www.jsconf.ie/) Dublin, Ireland September 25-26
-- Main Content
- - Survey results:
- - [[10:21](#state-of-html)] [State of HTML 2023](https://2023.stateofhtml.com/)
- - [[14:39](#state-of-react)] [State of React 2023](https://2023.stateofreact.com/en-US)
- - [[17:43](#state-of-js)] [State of JS 2023](https://2023.stateofjs.com/en-US)
- - [2023 State of JavaScript Survey Highlights: Vite Dominates, TypeScript Adoption Soars](https://socket.dev/blog/2023-state-of-javascript-survey-highlights)
- - [Dark Matter Developers: The Unseen 99%](https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99)
-- ⚡Lightning round ⚡
- - Company migrations:
- - [[37:54](#nyt-and-slack-update-to-react-18-enzyme-to-blame)] [NYT just updated to React 18](https://open.nytimes.com/enhancing-the-new-york-times-web-performance-with-react-18-d6f91a7c5af8)
- - [Slack converted from Enzyme to RTL with some AI assistance](https://slack.engineering/balancing-old-tricks-with-new-feats-ai-powered-conversion-from-enzyme-to-react-testing-library-at-slack/)
- - RN news
- - [[39:05](#rise-tools-launched)] [Rise Tools Launched](https://rise.tools/)
- - [[39:48](#mos-talk-about)] [Mo Khazali – Server-Driven Mobile Apps With React Native](https://youtu.be/vjTVnSUZVEk?si=KIURXZGKMz-gtRFB)
- - [[40:15](#nativewind-ui-launching)] [NativeWindUI launched](https://nativewindui.com/)
- - [[40:51](#gluestack-too)] [Gluestack is going in a similar direction with v2](https://gluestack.io/)
- - [[41:30](#swift-package-manager-support-moving-away-from-cocoapods)] [Swift Package Manager Support for React Native](https://github.com/facebook/react-native/pull/44627)
- - [[43:24](#react-native-filament)] [Using React Native MacOS with Expo](https://github.com/expo/expo/pull/30660)
- - [React Native Filament](https://twitter.com/mrousavy/status/1811354708235239680)
- - [[44:31](#react-native-for-web-devs)] [Guide to React Native for Web React devs](https://expo.dev/blog/from-web-to-native-with-react)
- - [[45:09](#build-windows-apps-from-a-mac)] [How to build Windows apps for React Native with a Mac](https://devblogs.microsoft.com/react-native/2024-07-18-running-rnw-from-a-mac-md/)
- - [[46:06](#ecosystem-performance-group-e18e)] [e18e (Ecosystem Performance) - A new community initiative | e18e](https://e18e.dev/blog/e18e)
- - [[48:10](#es2024-released)] [ES2024](https://tc39.es/ecma262/2024/)
- - [Tweet from Rob Palmer](https://x.com/robpalmer2/status/1806064466510897240)
- - [[49:00](#memory-leaks-compiler-wont-save-you)] [Sneaky React Memory Leaks: How the React compiler won’t save you](https://schiener.io/2024-07-07/react-closures-compiler)
- - [Garbage collection and closures](https://jakearchibald.com/2024/garbage-collection-and-closures/)
- - [How to publish a JavaScript package in 2024](https://www.youtube.com/watch?v=nl4B1asyMdI)
- - [[50:33](#react-native-flutter)] [React Native + Flutter](https://x.com/mdj_dev/status/1811317534936719562)
- - [[51:01](#bun-q3-roadmap)] [Bun’s Q3 roadmap (not exhaustive)](https://x.com/jarredsumner/status/1807731197046653438)
- - [[51:57](#learn-suspense-by-building-a-suspenseenabled-library)] [Learn Suspense by Building a Suspense-Enabled Library](https://www.bbss.dev/posts/react-learn-suspense/)
- - [[52:39](#marks-talk-why-use-redux-today-at-react-summit)] [Why Use Redux Today?](https://blog.isquaredsoftware.com/2024/07/presentations-why-use-redux/)
- - [[53:24](#chrome-collects-extra-data-for-google-websites)] [Chrome gives Google properties privileged information about your system resources](https://x.com/lcasdev/status/1810696257137959018?t=r9eYl5mMXDWVzZ9suZugjQ&s=19)
- - [[53:48](#component-composition-colocation)] [Component, colocation, composition: A note on the state of React | bobae kang](https://bobaekang.com/blog/component-colocation-composition/)
- - [[54:15](#secret-knowledge-to-selfhost-nextjs)] [Secret Knowledge to Self-Host Next.js](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)
- - Node news:
- - [[54:37](#node-can-strip-ts-types-soon)] [TS stripping](https://github.com/nodejs/node/pull/53725)
- - [[55:01](#native-sqlite-drive-in-node)] [SQLite support](https://nodejs.org/docs/latest/api/sqlite.html)
- - [[56:00](#node-moving-away-from-corepack)] [Removing experimental `corepack` tool for version managers?](https://github.com/nodejs/TSC/pull/1527#issuecomment-2258868015)
-
-[00:00] **Carl Vitullo:** Hello. Thanks for joining us for the July edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We are coming to you live from Reactiflux, the place for React developers.
-
-[00:13] And we actually have a sponsor this month. Woo! First time we're supported by Infinite Red, a consultancy that works exclusively in React Native. They've been around since 2015, have employees on the core team of React Native, and are super great.
-
-[00:26] I'm going to do a little more on them after we do introductions, but I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs and otherwise build tools to keep the community running.
-
-[00:39] **Mark Erikson:** I'm Mark, most of you know me as the guy who does Redux stuff, and as far as day job things go, I am actually looking for a new position, which is a bit of an interesting personal development, so if folks have suggestions for places I should be getting in touch with or that might be interested in me, please ping me and let me know.
-
-[00:59] **Mo Khazali:** And I am Mo. I head the mobile team at Theodo, and I'm an active community member within the React Native ecosystem. I organize the React Native London meetup and soon to be conference, and just contribute here and there, dabble a little bit into open source. Nowhere near as much as Mark does, but I do try.
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-[01:18] **Carl Vitullo:** Yeah, and a little more on our sponsor. Infinite Red is a expert React Native consultancy. I'm actually uniquely excited to get them specifically, Infinite Red, as a sponsor. They have been around, I've been seeing their name for the entirety of my career since I started in about 2014 with React. And they organize conferences, they host the largest React Native podcast, and generally have just shown up in very real ways to support the ecosystem and the community.
-
-[01:46] So I got a chance to connect with one of their founders, Jamon Holmgren at React Conf down in Las Vegas, and we just really vibed. They seem like really great people, they talk about how they are a team of 30 with mostly developers, mostly with more than 10 years of experience, and they work with your team to coach you on how to best use React Native.
-
-[02:07] So if your company is looking to build up some React Native expertise, definitely check them out. And thank you, Infinite Red, for sponsoring us.
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE) + [layoffs.fyi](https://layoffs.fyi)
-
-[02:14] **Carl Vitullo:** Cool. All right. On to some quick hits. Job market updates.
-
-[02:18] So there's a new source of data that I'm following, which is amusingly called FRED, an economic data set based out of the St. Louis Fed. So apparently the job site indeed does some like data analytics stuff that now the Federal reserve is relying on for like labor information. And this is a chart of software development job postings that have been posted to Indeed. And it is, indexed off the beginning of 2020. So it's more than doubles at about the start of 2022 and is down to about like 68 percent of that 2020 baseline and it's been pretty flat.
-
-[02:57] I really like this because I've been looking at layoffs. fyi for, you know, a year now and it just doesn't quite do it. It is, there's, there's enough, there's a lot of variability. It's only the source of Layoff. So this is kind of the other side. What does hiring look like? And unfortunately, hiring is flat to down, which is not great. But at least people aren't getting laid off as quickly anymore.
-
-[03:20] Yeah, speaking of layoffs, layoffs. fyi. This is the first time in, like, the A year and a half that we haven't had a, like, a pop of layoffs at the start of a new quarter. So that's a small positive sign. It's down versus last month in June and only the second time this year that we've had less than 10, 000 developers laid off. So, seems good. Hiring is not ticking up though.
-
-## New Releases
-
-[03:44] **Carl Vitullo:** Mark, you want to take us through some new releases?
-
-[03:46] **Mark Erikson:** Sure, a couple of the most interesting ones.
-
-### [Vitest 2.0](https://github.com/vitest-dev/vitest/releases/tag/v2.0.0)
-
-[03:48] **Mark Erikson:** Vitest 2. 0 is out. A bunch of small changes, but it's interesting to note that they're working towards a browser mode. Because we've had browser based testing for a while, but trying to focus on running unit tests in the browser. So, this has some very interesting potential there.
-
-### [Remix 2.10, fog of war](https://remix.run/docs/en/main/start/)
-
-[04:06] **Mark Erikson:** Remix put out a new release that has a fog of war feature, which looks like it's about trying to optimize downloads of route information. Looks like rather than bundling all the route information ahead of time, they will actually download chunks of it as you go, which should improve loading speed.
-
-### [Jotai 2.9](https://github.com/pmndrs/jotai/releases/tag/v2.9.0)
-
-[04:24] **Mark Erikson:** Uh, Jotai 2. 9 is out. And it looks like the public behavior is basically the same, but they've reworked the internals.
-
-### [Storybook 8.2](https://github.com/storybookjs/storybook/releases/tag/)
-
-[04:34] **Mark Erikson:** Storybook 8. 2 has, trying to look at the release notes, a few small changes, probably not a whole lot of big stuff.
-
-[04:42] **Carl Vitullo:** I've never quite understood the niche, the purpose that Storybook really serves. But, you know, hey, minor release, so it seemed worth calling out. I know it's pretty widely used.
-
-[04:52]
-
-### [React Native Reanimated 3.14](https://github.com/software-mansion/)
-
-[04:52] **Mark Erikson:** React Native Reanimated has 3. 14. So I guess there's your, there's your Pi release.
-
-### [htmx 2.0](https://htmx.org/posts/2024-06-17-htmx-2-0-0-is-released/)
-
-[04:59] **Mark Erikson:** Totally outside of React. HTMX just hit 2. 0.
-
-### [Mako released](https://makojs.dev/blog/mako-open-sourced)
-
-[05:03] **Mark Erikson:** And there is yet another Rust based JavaScript build tool that came out. This one's called Mako. I saw it. I'll be honest. I have no idea how this is any different than the other seemingly like 15 other Rust based build tools at this point.
-
-[05:20] **Carl Vitullo:** Mako has come out of the Ant design. That's what caught my eye as being notable.
-
-[05:24] So this is a Rust based developer being built by the team that put together one of the reasonably popular component toolkits. It seems notable for that reason to me. But yeah, yet another Rust based build tool. One more thing on Mako. They put up a bunch of benchmarks that show it being like 10 times faster than Webpack and noticeably faster than RSBuild 0. 6, which is pretty impressive. They also talked about like not being able to get it to work, getting their benchmark to work with the latest release of RSBuild, which is 0. 7. So who's to say if those benchmarks will really hold up, but yeah, cool.
-
-## Conferences
-
-### [React Rally](https://www.reactrally.com/)
-
-[06:01] **Carl Vitullo:** Some conferences coming up. We've got React Rally in Salt Lake City, August 12th and 13th. I've been to React Rally a couple of times Over the years and definitely a great one. I also noticed it's pretty much the only conference in August. I think because everyone's on vacation.
-
-[06:16] **Mark Erikson:** React Rally is wonderful. They've done a great job of really having a good community vibe over the years. I should be there. So folks want to come by and say hi, please do.
-
-[06:24]
-
-### [React Universe](https://www.reactuniverseconf.com/)
-
-[06:25] **Mo Khazali:** Next up. We've got React Universe Conf in Wroclaw in Poland on September 5th and 6th. I actually am seeing this conference. So if you like listening to me talk about weird stuff and ramble, it's the place to be, I guess, but no, it's a great conference.
-
-[06:41] It used to be the former React Native EU, and now it's expanding to cover all things React based. And we've got some really good speakers there. So obviously you've got the, the popular React Native speakers that are the lineup of every single React Native community conference that you know, but we've also got folks like Dan Abramov, who's been I can't see Dodds and some others, and I would highly recommend coming to it.
-
-[07:03] The organizers really know how to organize conferences. They've done it for many, many years and you're guaranteed pretty much to have a great time.
-
-[07:10] **Carl Vitullo:** Yeah. And on them knowing how to organize a conference, they organized React Conf. They were one of the organizer partners for that. So yeah, they certainly do. They have organized yet another conference. Definitely would love to get up to Poland if I can. Cool.
-
-### [JSConf Chile](https://www.jsconf.cl/)
-
-[07:23] **Carl Vitullo:** A, an overlapping conference. There's also a JSConf Chile in Santiago. That's September 5th through 7th.
-
-### [UtahJS Conf](https://utahjs.com/conference)
-
-[07:32] **Carl Vitullo:** There's a Utah JSConf again in Salt Lake City on September 13th. I guess this is. JavaScript versus React for React Rally. But yeah, so we have two conferences in Salt Lake City a month apart.
-
-### [React Alicante](https://reactalicante.es/)
-
-[07:44] **Carl Vitullo:** There's React Alicante, which is going to, it looks like it's going to be an online conference.
-
-[07:49] **Mark Erikson:** It's in person in Spain and I'm speaking there.
-
-[07:53] **Carl Vitullo:** Cool. Oh, awesome. Wonderful. Go see Mark speak in Spain. That is September 19th through 21st.
-
-### [JSConf Ireland](https://www.jsconf.ie/)
-
-[08:00] **Carl Vitullo:** There's also JSConf Ireland in Dublin with also streaming September 25th and 26th.
-
-[08:07] And that is all of the conferences we have this month. Uh, I will shout out, last month I mentioned a conference that I will not name again because it came to light that they were using fake speakers on their website and had various people listed as speaking at the conference who were not. So, uh, I updated the transcript, but I wanted to shut that out. I did try to check. I do look at the conference websites and try and vet them, but I got it wrong last month. Sorry.
-
-## State of the web surveys
-
-[08:32] **Carl Vitullo:** All right. Onto our main content. We are slightly behind the times by a month or two on State of surveys. There have been a bunch of state of React, state of JavaScript, state of HTML, all kinds of states that have come out over the last two months or so, which is later than I expected.
-
-[08:50] Usually these have, in years past, the state of JS surveys have done a pretty good job of coming out. Pretty promptly, they've been running for, it seems like, most of my career. So, just surprised. Seemed like there were some, hitches this year.
-
-[09:04] **Mark Erikson:** Yeah, like, I'm not sure if it was that they, they just took a really long time to analyze the data, or they were working on, I know they did a lot of work on, like, new data visualizations as part of the survey results.
-
-[09:14] So, it might just have been that it took them a long time to get the new sites put together.
-
-[09:19] **Carl Vitullo:** I did notice that they had some really cool data interactivity bits on it, like you can, for a lot of, at least on the State of JS site, the State of React one got, looked like a little bit less attention, which is fair, it's a much smaller survey, it's like a third of the size. But, they had some interesting stuff where you could filter or correlate responses. So it's like, Oh, you can see years of experience as it pertains to salary. So there was a lot of really cool data exploration stuff there.
-
-[09:48] I did also see a little bit of chatter online or on Twitter about how the survey was promoted and what that means for its sample size and audience. demographics mainly, like the survey responses were like 92 percent male and that's not great. I've seen other spaces get up to like 80 percent male, so, you know, 15 to 20 percent female, which seems to be about the high watermark, unfortunately, for online based tech communities. But yeah, so just, just wanted to shout out that I have heard a little bit of that.
-
-## [State of HTML](https://2023.stateofhtml.com/)
-
-[10:21] **Carl Vitullo:** I'll start with the two smaller surveys.
-
-[10:23] So state of HTML was actually really interesting to me. I don't super duper know how to stay on top of, like, HTML and CSS changes, so I feel like every couple of years I, like, see a talk from someone who's a genuine cutting edge expert in CSS and, you know, use the platform kind of stuff and go like, "oh, holy shit, I don't know how to use HTML anymore," because just reading the state of HTML, I found a bunch of little things, a bunch of new features that I was not aware of. I unfortunately didn't take a bunch of notes on them, but just scroll through, see what catches your eye, see what you haven't stayed up to date with.
-
-## "Use the platform"
-
-[10:58] **Mark Erikson:** I know we've had, you know, there's, there's kind of the running meme of, you know, the, the folks who insist on use the platform and the, and the React community is a little bit like, "but the platform doesn't support all the things we want to do," but browsers are continuing to implement, new features, the HTML and JavaScript specs keep advancing.
-
-[11:17] And it's a fair critique that folks who tend to focus on, the React type front ends probably don't know as much about the nuances of what's available in HTML and CSS as folks who are more focused on that. So, like, there's sort of fair critiques on both sides, and it's worth keeping an eye on, the new advances there.
-
-[11:39] **Carl Vitullo:** Yeah, something that I have thought of many times over my professional career is like, there's use the platform, you know, there's a lot of things you can do without writing JavaScript code. If you can do it with a native feature, it's going to be less development time. It's going to be, it's probably going to be faster, more performant for the user.
-
-[11:56] But that use the platform nature is in tension with the flip side of React trying to allow people to write code that runs in more environments. So it's sort of, there's sort of that dichotomy. There's the pressure of writing a tool tip library, writing a modal library that works in React Native as well as natively on the web.
-
-[12:16] And if you rely on the platform features, then you can't do the React Native side of things. So There's been a big tension there for many, many years, but I have been very interested in what it would look like if there was a component toolkit that just said like, nope, fuck the other platforms, we're just going to go all in on web, we're going to do it in as few lines of code to get the best user experience and the best developer experience possible.
-
-[12:38] I don't know of one that's really working in that way, but I think it would be really cool.
-
-[12:42] **Mo Khazali:** So two points on that, which I think was a really interesting point that you raised, Carl. One is part of the reason why a lot of these libraries don't really work well for React Native is the lack of web API support in the React Native ecosystem.
-
-[12:54] And it is actually something that's being worked on. So Microsoft opened an RFC last year and they said, well, you know, we, we, whether we like it or not, as native developers, the web APIs have won. They're becoming standardized. Things are. Relatively stable. So why not try to at least use those as the interfaces, even if the native implementations are different under the hood, so that when you do use your trusty old React library, it does just kind of work out of the box in the React native ecosystem.
-
-[13:18] So there is a move towards that and you've got React strict DOM and whatnot. But the example, the counterside to that is the example of tooltips that you mentioned. Like tooltips are not a mobile. Friendly UI element. So there's no easy answer to this unless you create really high level primitives that are UI agnostic.
-
-[13:35] But functionality wise, they kind of behave similarly. So, you know, from a way that it looks, it's totally different on iOS, Android, and web, but at least the APIs for the developers are the same. So opens a tool tip on the, the, the web with a hover, but you know, maybe opens up a modal. A bottom sheet modal on native.
-
-[13:52] So it's a big point of contention for us React Native developers that we're trying to figure out. I don't think we have the answer, and I don't think anyone's figured out the sweet spot. But we'll get there. We will get there.
-
-[14:02] **Carl Vitullo:** Yeah, I feel like it crosses my mind every couple of months, but just hearing you talk about like, the web platform just makes me think yet again of a 2013 talk called the birth and death of JavaScript.
-
-## [Birth and Death of Javascript](https://www.destroyallsoftware.com/)
-
-[14:13] **Carl Vitullo:** And yes, JavaScript is intentional. But yeah, if you are not familiar with JavaScript. That birth and death of JavaScript talk, watch it because like, oh my God, it's the most, it has remained the most like prescient talk I've ever watched. It is exactly discussing how JavaScript takes over the world and we're just living it, we're just living that 10 years later, 11 years later. Anyway, that's a, that's all kind of long diversion for state of HTML, but.
-
-## [State of React](https://2023.stateofreact.com/en-US)
-
-[14:39] **Carl Vitullo:** There was also a state of React survey. It was pretty good. I kind of got more interesting signal I felt out of the state of JavaScript survey. There was a lot of survey time dedicated to like, what React features do you use? And that's just not really a question that I have, you know, I don't really care if you use, you know, use context. You probably do. If you don't, you probably should. That section, what features do you use, is interesting in terms of like, what are people aware of, but I don't know that it really changes that much.
-
-## Component Libraries
-
-[15:07] **Carl Vitullo:** It did have a lot of good data about component libraries and ecosystem that I thought was, just, we, we spend so much time in here bantering about like, what the vibes are and how does it feel What tools does it feel like people are using more and talking about more?
-
-[15:23] So this is a good data based check in on how accurate the, the vibes, our read of the vibes are and pretty accurate. I'm pretty happy. We'll get more into it with the state of JS, just that did have a lot more of the vibes, but some things I thought were notable component libraries, generally not popular.
-
-[15:40] Some of them are reasonably widely used, but like not loved. Radix were the most loved with Headless UI, also pretty high up there. Radix and Headless UI are not ones that live large in my mind, so it was cool to see those surfaced. Definitely, like, you know, obviously we talk about ShadCN pretty frequently, but Redux and Headless UI, good ones to check out.
-
-[16:03] Headless UI looks cool because it's unstyled, so it's just behavior, and then you make it look the way you want. Which, here for it, love it.
-
-[16:11] **Mo Khazali:** I think that's kind of the direction that they're all going with as well. Like, you know, R a bit more opinionated, but still flexible in a lot of ways compared to, let's say, your run of the mill material UI.
-
-[16:21] I think that's the general direction where these things are going. And Headless is great for that. I guess that's the appeal with Shad for me as well, right? Like I know a lot of people love ShadCN. The appeal is, well, if you don't like the rounded corners specifically, it's just a tailwind prop to change and you're kind of done.
-
-[16:36] So you have a lot of flexibility there.
-
-[16:38] **Carl Vitullo:** Yeah, definitely makes sense. It's been curious to see how slowly that has evolved over the years. I, I bailed out pretty quick on component toolkits cause I just, I don't want it to look like a bootstrap site.
-
-## StyledComponents still big
-
-[16:48] **Carl Vitullo:** So there was also something that I found interesting just because it seemed like a, you know, narrative violation is styled components are still pretty dominant in terms of actual usage, like enormously widely used, you know, everyone talks aboutTailwind and whatever, but. Style of components, they're here to stay, they're sticking around.
-
-[17:05] Some other interesting data, 23 percent of respondents are still on either React 16 or 17. So this is like, how many years after 18 was released? And 6 percent of survey respondents don't know what version they use, which is interesting to me.
-
-[17:21] So, yeah. If you're using React 18, congrats, you are on the cutting edge. The only 68%, less than 70 percent of survey respondents are on React 18. Talking about nobody uses beta versions. Nobody uses advanced versions. I think it was like less than 1 percent have tried a canary. So rounding error. All right.
-
-## [State of JS](https://2023.stateofjs.com/en-US)
-
-[17:43] **Carl Vitullo:** State of JS, the big one. Mo, you want to, you want to kick us off with your thoughts? Break up my monologue.
-
-## A Note on Survey Sample
-
-[17:48] **Mo Khazali:** Sure. Good to start off with what you kind of start off generically about the survey results, which is you got to look at the sample size.
-
-[17:53] It's like the most important thing to do when you start with this, because it makes the data seem a lot more contextualized as a result. So a colleague of mine, she was talking about this and I kind of took notes and then looked through it and I was like, yeah, wow, that's very accurate. She was giving me her thoughts.
-
-[18:09] But the first thing is, location is heavily US based. So if you look at the respondents, 16 17 percent are from the US. If you combine Germany, France, and the UK, Those become close to the US respondents. They're about the same as the US respondents, a little bit more. So all of this data is heavily skewed by the US market.
-
-[18:25] Things like, let's say like the Indian developer community is very, very underrepresented. There was only about 500 respondents where that's about two, 3%. Whereas, you know, they should be a lot more because proportionately they'll have a larger developer community than that, which is represented.
-
-[18:41] **Carl Vitullo:** I think the total number of respondents was like 20 or 30, 000.
-
-[18:44] So hearing only 500 from India is like a little bit shocking. Yeah,
-
-[18:47] **Mo Khazali:** it's, it's quite poorly represented. Or the Netherlands, as an example, has got about 500 as well. The Netherlands is a big tech hub in Europe. A lot of big tech conferences happen, JavaScript conferences happen in the Netherlands because there's already a big community there.
-
-[19:00] So it's very interesting, I think it's probably more to do with marketing and how they got the word out, and which communities it goes to. And so when you have location being heavily based in the US, then it skews salaries quite significantly. US salaries for developers are much higher. than European salaries And so all of the salary data is being taken on sort of an average, and so that moves the whole scale, basically.
-
-[19:20] The other thing which kind of you hinted on, Carl, was it's almost exclusively male. So 94 percent men, which isn't great. It's really heavily, disproportionately male. Men who have responded to this. And then the worst view that you can see, and this should, if anyone has any doubts about this, just look at this view and hopefully your doubts will be completely gone but when you combine the gender and the yearly income views, you can see that men have a higher average salary.
-
-[19:47] Shocker. So the gender pay gap is very much there, and it's something to the degree of 20, 000 on average between men and women. Shocking, right? And unfortunately as well, again, racial demographic, it's mostly white respondents, 70 plus percent as well.
-
-[20:02] So there's, there's, the sample size isn't very representative, I'd say. Still interesting findings, but just those caveats are very interesting to contextualize everything.
-
-[20:10] **Carl Vitullo:** Definitely. Yeah. It's funny. The salary to gender is one of the only things I did to play with the data. So it's funny that we both went straight for that. Yeah. Also on salary on, you know, US based salary, skewing it, you know, higher, I actually was, looking at that chart, looking at the, you know, the, the quartiles and seeing that my last job, like two years ago, my last full time software tech job was like, On the very high end of that.
-
-[20:36] So it's like, Oh, apparently I kind of maxed out the scale, which is interesting because I definitely have not, I was not at the top of the scale. I, my last salary is 171, 000. Like it was good. I was very happy with it, but. I know plenty of people who are making like double that. So I was surprised as much as US salaries will skew it higher, I was a little surprised to see the absolute high end of the scale, not really represented. Do you know, just knowing people who are making that.
-
-[21:04] **Mo Khazali:** So. Fascinating. You know, you say that because again, it's relative because if you, let's say like, look at the UK, 170, 000 per year, and your yearly salary is basically the top, top, top end, like maybe top two, 3 percent of developers. in the UK. So it's, it's all relative.
-
-[21:18] Like, like you say, yes, even in the U. S. you can go much higher and then it starts to become really skewed. So yeah, very interesting, but the data is never going to be accurate.
-
-[21:26] **Carl Vitullo:** Right, right, right. Yeah, I think top of market, I don't know, Netflix intentionally tries to pay top of market. I think they're in like 350 range.
-
-[21:33] I've heard rumors, consider this a rumor, but I've heard of like super top developers at OpenAI making upwards of like seven, eight, nine hundred k, a million dollars a year salary. So yeah, high end of the scale is crazy in the US, but we can, we can bail out of demographics for a minute.
-
-[21:52] I'm going to just rapid fire some of these, some of the breakdowns, some of the analysis that I was looking at.
-
-## Vue Tops Angular for usage
-
-[21:57] **Carl Vitullo:** Vue has surpassed Angular by usage according to this survey, which caveats about sample aside is interesting. Angular definitely not loved. It had a like net unfavorable view of it. I think majority of respondents had a negative view of it. it's still in competition with Vue and React by usage, but it is substantially more negative than either of those, than either React or Vue.
-
-[22:22] Everyone still loves Svelte. It was number one by like a long shot on interest and favorability rating, but not very top by actual usage. It has been consistently, growing in usage over the years. So React is still generally positive. It's still the most positive by rank. You know, in this list, it was number one most positive, but that's been declining over the last two or three years and is very tight with Svelte right now.
-
-[22:49] The dots were like practically overlapping, like definitely within margin of error for which one was more positive. Astro topped out the list of other options, It did not make the cut to be in the main list, but one of the shout out, Astro is in contention. it was funny.
-
-## Developer Happiness
-
-[23:05] **Carl Vitullo:** The, they had a chart of happiness and generally all of the libraries people were happiest in 2018, which I just thought was funny because I tend to think of 2018 as like peak tech for, in a lot of different ways.
-
-[23:18] Like when I think of Reactiflux and its activity and its growth and its vibes. 2018 was definitely a banner year. So that seems to just generally be true across the industry. Everyone was happy in 2018 and people are less happy now.
-
-[23:31] Next usage has been growing pretty consistently for like the last four or five years by this survey. Remix has been pretty flat, which I put them in the same usage bucket. I put them in the same popularity bucket in my mind. So that was a little surprising to me. There's also, Remix had a much more negative perception than I expected. It's about even for, you know, positive and negative responses.
-
-[23:52] I love it. I thought it was great. So I'm just surprised to see that. Over the last, like, three years, testing, usage of test tools. has grown pretty significantly, whether it's Jest, or VTest, or Playwright, or Cypress. All of them saw usage go way up in the last two to three years, which is very funny because that, that tracks very well with my experience of three to four years ago, nobody was writing tests.
-
-[24:17] Just, people actually started writing tests in the last couple of years, which is funny. Yeah, Playwright versus Cypress. The vibes are supported by the data. People love Playwright. It's got really great retention. It's got really great net favorability rating. Cypress, a little bit less so. It's still very widely used, but the retention chart was much more negative.
-
-[24:39] And it's just not as well loved, which generally tracks with the sentiment that I've seen.
-
-[24:44] **Mark Erikson:** Yeah, I think I saw that Playwright Downloads had recently surpassed Cyprus's. I know I've seen a lot of mentions of companies migrating from Cyprus to Playwright. So, yeah, matches my experience.
-
-[24:55] **Mo Khazali:** We literally, this week, migrated one of our clients from Cyprus to Playwright.
-
-[25:01] So, another anecdote of how the general vibes are going in the community.
-
-[25:05] **Carl Vitullo:** Yeah, Roboto just asked in the chat, what are people's problems with Cypress? I've run into a bunch of weirdness on flaky tests and just general quirks, like the edges have been rough. I haven't really done enough with Playwright to say what's better about it, but it seems like it's based on a more stable foundation.
-
-[25:24] **Mark Erikson:** I can briefly speak to this. Cypress runs your entire test in the browser. It basically kind of like hijacks everything about the browser behavior and sort of re implements a lot of that itself. Whereas Playwright, the test is running externally. And it's sending, like, DevTools protocol commands to the browser.
-
-[25:42] CypressR also has a really weird not actually async model. The way I understand it is it actually runs through the entire test code ahead of time and collects a queued list of commands, and then it executes those later. So you can't even use, like, real async await in your test syntax, whereas with PlayWrite you can.
-
-[26:03] **Carl Vitullo:** Interesting. Yeah, because I think Cypress came out before, like, headless Chrome was a thing, because I remember they, all of the browser automation stuff from, you know, years gone by are very hacky. Like, they're scripting the browser in a just really janky way, and the browsers produced a headless variant that is more intentionally able to be scripted.
-
-[26:26] And so I'm pretty sure that Cypress predates that change, and so they had to do the hacky weird stuff, and Playwright came about after that change, and they do less hacky weird stuff.
-
-[26:36] **Mo Khazali:** There's one more thing with the Cypress, I guess, model that pushed people away in the last couple of years, which was that they basically, they, I believe they're VC backed.
-
-[26:46] They needed to find a path towards monetization. So they released a paid model where you had a dashboard on their sort of like hosted platform. And then there was free alternatives. And they were scanning your node modules. There was this thing that came up where they were scanning node modules and sort of sabotaging if you were trying to use an open source alternative to their paid platform, which people really did not like.
-
-[27:09] And there was a lot of backlash. So I think a lot of people lost a lot of trust with Cypress as well after that.
-
-[27:13] **Carl Vitullo:** That tracks. Okay. That's not great. Yep. Also in testing, the generically branded testing library is also losing ground, which I'm surprised by. I loved it. I thought it hit a really great niche between like unit tests and full end to end tests.
-
-[27:28] But I guess my thought is maybe. Playwright is now stable enough to cover that use case with less setup process. Cause it did take quite a bit of work and influenced how I developed features when I had testing library tests in place. So maybe it's a similar benefit for less work using Playwright instead of testing library.
-
-[27:49] **Mark Erikson:** It is worth noting that Playwright actually added testing library inspired APIs like get by test.
-
-[27:56] **Mo Khazali:** And I have another hypothesis to this, which is again anecdotal, but it's from working with many different sort of clients. I think it might also be market led, and the reason I say that is because end to end tests are much easier to sell to your business stakeholders.
-
-[28:10] Oh, we're running and executing the full end to end lifecycle as if it was a user, and it helps prevent bugs because you can see when a flow, a major flow is broken. Whereas Component tests, whether they're with React testing library or any other solution or unit tests, are much smaller pieces of the segment.
-
-[28:26] And I think when you're crunched for budget, but you still want to have some level of testing and confidence as a business stakeholder, you'll push your developers to do more end to end tests because they understand it more. That's my hypothesis. I've seen it more in conversations with some of the leaders and the companies that we've been working with.
-
-[28:40] **Carl Vitullo:** Yeah, that makes sense. I personally find that a benefit because it'll, testing library lets me sidestep the whole, a whole set of questions. Like how do I log in? So weird stuff like that gets easier if you strip away the, you know, the stuff surrounding the feature you want to test. And once you've just run through the interactions there, but it definitely would be easier to sell.
-
-[29:01] We're going to test the whole thing. All right. Many diversions later. So testing, State of JS. Vitest usage has really skyrocketed. It's been very impressive. Jest is still surprisingly well loved to me. Generally testing across the board, way up. Everyone is writing more tests. Moving out of tests into native.
-
-[29:20] There's generally, it looks like a lot more people are building native code. This is probably a reflection of how much work the React Native and Expo teams have done to make that feasible for people who are use, who are coming at it from web development. Like in the, you know, different runtime section of this, they had, are you using, Electron, Expo, Cordova, React Native, all sorts of things, including native mobile.
-
-[29:48] You know, just, are you building a native app? All of those are, well, all the modern popular options are way up. You know, Cordova is, you know, Declining, luckily, but React Native, Native Mobile, all of that is trending pretty way up.
-
-[30:02] One option that was brand new to me in this survey is Tauri. Looked like an option that people love for doing native stuff and wanted to shout it out.
-
-[30:11] **Mark Erikson:** Yeah, and for those who aren't familiar with it, Tauri is basically a competitor to Electron. You know, the idea is you're writing a web app that runs it runs within the desktop as a native like application.
-
-[30:22] The distinction being that with Electron, you're having to ship an entire separate standalone copy of Chrome to run your web app, whereas Tauri wraps whatever the native web view is for that platform. So, you're only shipping, say, like, A five meg set of assets instead of, you know, 150 megs of Chrome to run your couple of megs of JavaScript.
-
-[30:45] **Mo Khazali:** And just from a native app developer's purist perspective, I would, from a React natives perspective would say that's not really your native, but it's a good hybrid option, but that is just a personal thing because you're not rendering native views at the end of the day. You're rendering a web app with some connections onto the native layer APIs.
-
-[31:02] But that's generally the challenge with anything like Electron, Ionic, Capacitor, or Tauri.
-
-[31:08] **Carl Vitullo:** Yep. Into like bundling and those tools, Webpack declining sharply. Really bad compared to others, like favorability and retention and all of that. Unfortunately, the way the questions are asked is, What have you used?
-
-[31:23] So there, it doesn't have a way of capturing What people currently use versus what they have used and have switched off. So it's hard to say whether people are actually not using Webpack anymore or, and whether they've added new tools to their toolkit or whether they've replaced it, that is not a question that we can answer with this dataset.
-
-[31:42] My, my intuition, my guess here would be that a lot of people are still using Webpack professionally, still working on a project that was spun up, you know, over the last two to five years. And, you know, switching bundlers is a really challenging project with not a lot of business value. So, yeah, I, I, it would not surprise me if a lot of people are still using Webpack at work, but have stopped relying on it for projects they make on their own or for, you know, open source work.
-
-[32:10] **Mark Erikson:** Also worth noting on that, on that front, that, Create React app. There's still plenty of CRA apps out there, even though it's no longer officially maintained or recommended, and that has always used Webpack internally. And Next is still a Webpack wrapper. They've been working on TurboPack, which I think now fully supports dev mode, but I don't think it supports production builds yet.
-
-[32:33] So, Next is still wrapping around Webpack for the foreseeable future.
-
-[32:38] **Carl Vitullo:** Yeah, generally, like, ESBuild and Vite have been the big winners here as Webpack is losing usage. Rollup is going up as well a little bit, but as far as I know, that's largely used by library maintainers, not app developers. Yeah, monorepo awareness is also growing a lot.
-
-[32:55] You know, the classics from, like, Several years ago where Yarn Workspaces and Lerna, those are declining. They are not the popular options anymore, but NX and PMPM are currently the leaders there, although I'm not sure if people would answer, I'm, I'm, I'm wondering if people might've said, Oh yeah, I use PMPM when they didn't mean they use it for monorepos, that's not the primary use of PMPM as far as I know.
-
-[33:18] And TurboRepo from. Vercel is also growing, but for other runtimes, Bun is slightly more popular than Deno. Interesting to check in on.
-
-[33:27] **Mark Erikson:** Now, is that, is that in sentiment or like actual usage amounts that we know of?
-
-[33:33] **Carl Vitullo:** That was claimed usage. So people saying, yes, I have used this. More people said that for Bun.
-
-[33:39] But, who's to say if it was personal, who's to say if it was professional, playing with something is very different from introducing it in a work setting, and my intuition says that Deno is currently better positioned than Bunn to be used at work, which is a much stickier usage. Yeah, another fun stat that I caught and wanted to shout out.
-
-[33:57] 18 percent of respondents have not used any AI tools. You know, whether that's Copilot or ChatGPT or Claude. Yeah, 1 in 5 of tech people who are aware enough of the online Zeitgeist to respond to a survey have not used it at all.
-
-[34:14] **Mo Khazali:** Just another interesting fun one. Apparently, 50 percent of respondents are still using Lodash actively, which I found was interesting, but more interesting than that is the 33 percent that still use Moment, despite some of those APIs basically being available in the, in the browser APIs.
-
-[34:29] So, takes a long time to get rid of some third party libraries, it seems.
-
-[34:32] **Carl Vitullo:** Yeah, yeah, it really does. Yeah, and I wanted to shout out the 20 percent of people who responded that are still hoping for, a pipe operator and pattern matching. My heart goes out to you as one of you.
-
-[34:44] I, that's something, those are two features that I got really excited about and like. 2015 16 that we are still waiting for. So I think I'm, I think I've given up at this point. Yeah. And Mo, about, uh, on library usage, I was really surprised to see that RxJS had a lot of usage. I think of it as a niche library, but, but by survey responses, a surprisingly large number of people are making use of it.
-
-[35:09] **Mo Khazali:** That's quite interesting. I mean, the, the, the one that everyone makes jokes about is jQuery as well, which is 22 percent still, but you know, yeah, it's, it's, RxJS has always been more niche and I'm, I think it was mainly used predominantly by the Angular community, if I'm not mistaken, right? Someone from the, uh, from the comments is saying that it's still a first class tool in Angular, so that, that might check out as to why it's got such a high usage.
-
-[35:31] **Carl Vitullo:** Okay, that, that would scan. Sure, sure.
-
-[35:33] Okay. Maybe this is my React bias showing then.
-
-[35:37] **Mark Erikson:** Yeah, I mean, they've, Angular has been introducing signals within the last couple major versions as they're, they are trying to put some emphasis on that, but RxJS is still very integrated into the Angular ecosystem.
-
-[35:49] **Carl Vitullo:** Gotcha. Okay. Looking at survey respondents generally, you know, the number of people who answered like the demographic questions at the beginning versus number of people who answered, who gave any answer for what content do you consume, like 80 to 90 percent do not consume content.
-
-[36:05] Like they did not give any answer for what content do you consume, which I just think is really. I think it's an important thing to keep in mind when you're, you know, as people are saying like, Oh, you know, Oh, everyone is, everyone's talking about this. Everyone's thinking about this. So and so made a video on this.
-
-[36:19] Like, you know what? Most people didn't see it. Most people are not thinking about that. Most people aren't even aware of that. I just think that, I just think that is a great, Demonstration of like the participation inequality that happens in so many software communities, or that happens in communities generally, where like 90 percent of the people are not participating in the same way as the most active 10%.
-
-## [Dark Matter Developers](https://www.hanselman.com/blog/)
-
-[36:43] **Mark Erikson:** And I have a very specific link for that, which is Scott Hanselman's classic post on dark matter developers, people who are just going to work and doing their thing and going home, and they don't know about the Twitter discussions or what's popular or the trends. They're just doing their thing quietly.
-
-[37:01] And we don't hear about them because they're not involved in the discussions. But the
-
-[37:06] **Carl Vitullo:** That is actually specifically the target that I'm kind of going for, for this podcast. I want to be the once a month, one hour long summary of that fire hose. Like, you don't care enough to drink the entire fire hose, stick your face in front of the blast of water, but want to get the signal.
-
-[37:23] that's what I view our role here as. We pull that signal out so that you can spend one hour consuming it instead of More than that, If you, instead of it being a part time job, staying on top of the latest news, I want this podcast to be an effective way to do so.
-
-[37:37] So yeah. Hello, Dark Matter developers. All right. That is half an hour of content on State of JS, which is good because there was not a ton of, React news otherwise. So yeah, Mark, you want to take us into our lightning round links?
-
-[37:49] **Mark Erikson:** Yep. So having said that we do have a bunch of lightning round stuff to go through.
-
-## [NYT](https://open.nytimes.com/enhancing-the-new-york-times-web-performance-with-react-18-d6f91a7c5af8) and [Slack](https://slack.engineering/balancing-old-tricks-with-new-feats-ai-powered-conversion-from-enzyme-to-react-testing-library-at-slack/) update to React 18 (Enzyme to blame)
-
-[37:54] **Mark Erikson:** First off, a couple of interesting company migration blog posts. We were talking earlier about, you know, like only two thirds of respondents being on React 18 and the New York Times put up a pretty big post about how they just updated React. to React 18. Some good details on the work they had to do and some of the challenges they ran into, especially with some of their embedded interactive setups, and some information on some of the performance improvements that they saw.
-
-[38:21] One interesting note is that A lot of their work had to do with migrating from enzyme tests to React testing library. And so, on a very similar note, Slack put up a post where they said, you know, we have tons and tons of enzyme tests and we, we tried to migrate those to React testing library. And, it was so hard, we actually ended up trying to automate a lot of the conversion using a combination of AI language models and some various additional tools.
-
-[38:52] So, this goes back to the test, and to the whole test discussion. Like, tests provide value, but they're code. And code becomes legacy. And you have to update it and modernize it. And that in itself can be a real drag on trying to change things.
-
-## [Rise Tools launched](https://rise.tools/)
-
-[39:05] **Mo Khazali:** So I'll jump in with a few things. First is that Rise Tools has been launched.
-
-[39:11] So Rise Tools is created by Mike Grabowski. So Mike is the former founder of Callstack and he's been very involved in the React Native ecosystem. It's basically, it's not tied to React Native, but it's basically targeting React Native for now. It's a way to build server driven apps. It's a server driven UI app where the server controls how the UI is layouted.
-
-[39:32] And it kind of comes with all things battery included, from the server, all the way up to the React primitives, and even some more opinionated UI design systems like Tamagui if you want to use it. It's kind of evolving in a way where it ends up being a bit of a meta framework on top of a meta framework.
-
-## Mo's talk about server-driven mobile UI
-
-[39:48] **Mo Khazali:** So a meta meta framework, we're getting into that age of front end development. Um, but it's really cool. It's server driven UI is very difficult. And I talk about how difficult it is in mobile development, many places. And I did a talk recently at a meetup in Poland. So shameless plug. If you're interested to see why this is an actual challenge in the React native world, just take a look at that YouTube video and hopefully you'll get a bit of a primer.
-
-[40:11] **Mark Erikson:** Gasp! A shameless plug on this podcast. What?
-
-## [NativeWind UI launching](https://nativewindui.com/)
-
-[40:15] **Mo Khazali:** Next up, Native Wind UI is launching. So this goes very much along the same train of thought as we were having a conversation about with the state of React, where a lot of these component libraries are not popular anymore, but people want these sort of copy pastable code components that have 90 percent of the stuff there and they can modify and change it as much as they want.
-
-[40:35] It doesn't come with any behavioral APIs. It's just. UI wise, how do things look like and what do the components look like? So this is basically like Tailwind UI. It's going to be a paid UI kit, UI copy and pasteable components and templates. But I think it's interesting that the React Native community is going in this space.
-
-## [GlueStack too](https://gluestack.io/)
-
-[40:51] **Mo Khazali:** Similarly, the GlueStack team. So GlueStack is, made by the former creators of NativeBase, which was another popular UI library and. GlueStack is basically the successor to that and they initially had a more batteries included opinionated API component library that is now going seemingly in a very similar direction to native WinDUI and Tailwind UI, which is, we have these copy pastable components.
-
-[41:16] So think of it as ShadCN as well, but in the React Native ecosystem. And the lovely thing about both of these libraries is, they work universally with React Native. So if you're targeting React Native on the web, these libraries will automatically work on both web and mobile, which is really cool, and a step in the right direction.
-
-## [Swift Package manager support, moving away from CocoaPods](https://)
-
-[41:30] **Mo Khazali:** More in the React Native ecosystem, so, If you've been in this ecosystem, you'll know that typically what we use on the iOS and MacOS front is we will use CocoaPods as a dependency and package manager. Now, CocoaPods is good, it works, it's one that's been around for a while. The iOS native community is moving towards Swift Package Manager that Apple created themselves.
-
-[41:53] And so now this PR got merged, but we will have Swift package manager support for React Native. So if you want to use Swift package manager, you now have the option to do so, which is going to be great for brownfield apps. So apps that are, some parts of it are in React Native, other parts are just purely native.
-
-[42:07] This will make it much easier to adopt if you've already been using Swift package manager for your native apps.
-
-[42:11] Now, one of the things that has been a challenge with the React Native ecosystem is around out of tree platform support and how easy it is to integrate them with tools like Expo. So out of tree platforms, for everyone who's not aware, are platforms that are not iOS and Android.
-
-[42:26] So, web, macOS, Windows, AR, VR, headsets like Vision Pro, and so on and so forth. So those are all platforms that are not officially managed and maintained by Meta, but they have sort of community partners that are maintaining them. And so macOS is maintained by, uh, Microsoft. And one of the challenges there was how do you get Expo to work with it?
-
-[42:45] Because previously you would need to do it in a bare React Native app, which means you have to do a lot of the typing and the wiring and all of the infrastructure underneath it. There's this concept of config plugins in Expo, and now there's support for React native Mac OS, and people are seemingly getting ready to be able to develop desktop apps with Expo, which is really exciting.
-
-[43:03] **Carl Vitullo:** Sorry, wait, did you say that this is maintained by Microsoft?
-
-[43:06] **Mark Erikson:** Yes. Microsoft maintains the React native implementations for Windows and for Mac.
-
-[43:13] **Carl Vitullo:** Okay. Just needed to check that. Cool.
-
-[43:15] **Mo Khazali:** Yes. Yeah. this is one of the things with React Native where there's so many people involved now. It's not just Meta, it's Meta, Microsoft, Amazon, Shopify, and name a bunch of other companies.
-
-## [React Native Filament](https://twitter.com/mrousavy/status/)
-
-[43:24] **Mo Khazali:** Next up, we have React Native Filament. So, it's a hot time in the 3D rendering space of React Native. there's a lot of stuff that's happening in the last few months. React 3 Fibers suddenly got a big boost in the React Native ecosystem. More and more people are talking about it. I've seen a lot of talks in 2024 about it.
-
-[43:41] The Skia team, the React Native Skia team have also been talking about GPU and 3d rendering. So they did that at their talk in AppJS. We covered it in the podcast back in May. And so now the team at Margello have released React Native Filament. So it's a base 3d rendering engine built for React Native. The nice thing about it being C is that it works kind of out of the box for most of these native platforms.
-
-[44:02] It is seemingly, again, this is how it's marketed, is that it's basically with less than 50 lines of code for you to load a 3d model and basically have things like pan gestures, zooming, and all of that, which is really hard to get.
-
-[44:15] And you need to actually manually code a lot of that yourself. So this is really cool. We'll see how it, how it materializes and how it evolves. There's a lot of 3d libraries that are coming to fruition and you've got to choose and see which ecosystem grows. So you're basically placing bets on horses and seeing which one kicks off.
-
-## [React Native for web devs](https://expo.dev/blog/)
-
-[44:31] **Mo Khazali:** On the trend of what we talked with the state of JS and, you know, how, uh, native usage is growing, Kati Kraman from the Expo team, she's written an article, a guide to React Native for web React devs. So people that haven't been in the native space kind of understand what are the things that you need to learn sort of like a TLDR before you can start creating React Native apps.
-
-[44:51] This is amazing because frankly, this is one of the things that I always rave about and rant about, if you don't tell people about the gotchas, they'll come and burn themselves in the React Native ecosystem, and then they will hate React Native for the rest of their lives. So, I love education and good education like this, which is specifically targeted for web React devs.
-
-## [Build Windows apps from a Mac](https://devblogs.microsoft.com/)
-
-[45:09] **Mo Khazali:** And last in this React Native train, at least in this one, is that one of the things, again, with out of tree platforms, again, with the Microsoft team, is that they maintain React Native Windows. But you need to have a Windows machine to develop for React Native with Windows, which many of us don't, myself included.
-
-[45:25] I have renounced the Windows days since many, many years ago. And so it makes it really hard to build Windows apps. And I've always wanted to do it. I've got an Xbox. You can build Xbox apps with React Native using the Windows implementation, but you need a Windows machine to be able to test your apps, which kind of sucks.
-
-[45:40] So they've written an article on how you can build Windows apps, with React Native. On a Mac. The spoiler alert is that it's not straightforward, unfortunately, you have to boot up a parallel Windows machine and then sort of port forward stuff and then use it on a VM to test it out, which is not the best DevEx, but at least there is an escape hatch if you really are inclined to do so.
-
-[46:00] So hopefully that opens the doors to React Native Windows for more and more people who are using Macs as their development drivers.
-
-## [Ecosystem Performance group, e18e](https://e18e.dev/blog/e18e)
-
-[46:06] **Mark Erikson:** Changing gears entirely, we all know the jokes about how, you know, Node modules is the heaviest object in the known universe. you know, you install one package and you get 1, 500 dependencies installed as a result.
-
-[46:20] And there's a lot of factors that go into it. It's how the Node ecosystem has evolved. There's also cases where, you know, certain maintainers are obsessed with Maintaining infinite backwards compatibility instead of allowing the ecosystem to move forward with modern tooling. I've been complaining for years that surely there has to be a way that we collectively as a community could go in and start You know, removing unnecessary dependencies from popular packages and end up improving, you know, download speeds and number of dependencies for everybody.
-
-[46:52] And there's now an actual community effort to do this. It's in a group called the Ecosystem Performance Effort. And it's just a community group. They've got a Discord for discussing things and a repo for pointing things out. But it's things like, could we look at, say, the isnumber package? And find the most common parent packages that depend on it, and replace those.
-
-[47:16] And end up saving, you know, like, cutting down on dependency trees, and saving download bandwidth for everybody. I'm very, very excited to see a lot of people actually spending time and effort on this. This is the kind of grassroots, you know, like, effort that actually benefits everybody.
-
-[47:32] **Carl Vitullo:** I saw a PR specifically about inlining `isNumber`, and it did, I don't know if I quite 100 percent buy this math, but the math they did was, by inlining this package instead of installing it as a dependency, we save this many kilobytes. This module is downloaded this many times per week. You multiply those together and ergo, we are saving 440 gigabytes of bandwidth every week. I am, I wonder if that is how that shakes out in practice with like caching and stuff. But if by inlining is number, we can have 440 gigabytes less data flowing through the air. Uh, that's, that's fascinating.
-
-## [ES2024 released](https://x.com/robpalmer2/status/1806064466510897240)
-
-[48:10] **Carl Vitullo:** We have also, ES2024 has been ratified by the, by TC39. We've got the spec, which is very dense and hard to read. Fun. Rob Palmer, who's part of the team involved in that also announced it on Twitter. A lot of these are like pretty esoteric to me, like well formed Unicode strings.
-
-[48:30] I didn't know they were not well formed. Promise. withResolvers, I guess. I don't, I don't know what that is either. ResizableArrayBuffers, ArrayBufferTransfer. Two that are a little bit more salient for me is Array. GroupBy and Object. GroupBy. What a great thing to have added to the standard library. So that's nice.
-
-[48:50] There's a regex v flag for creating regular expressions with more advanced features for working with sets of strings. Yeah. Lots of stuff. We've got a new spec, nothing too exciting though.
-
-## [Memory leaks: Compiler won't save you](https://schiener.io/)
-
-[49:00] **Mark Erikson:** We've mentioned one or two different articles that looked at ways you can end up with memory leaks in React applications due to closures and how JavaScript engines actually behave, and there's, there's some discussion of what happens when React Compiler comes into play, and so the author of those posts did some more research and concluded that no, you can, you can still end up with memory leaks, even with React Compiler.
-
-[49:25] It sort of ends up in the same situation where. Capturing variables in scope, and due to the way JavaScript engines work, you can still end up with some memory leaks if you're not careful. Similarly, Jake Archibald, who's done a lot of articles and research over the years around JS behavior, also just put up a very, very similar post talking about memory leaks and garbage collection with closures.
-
-[49:46] So, this is stuff that I only sort of half understand myself. And so seeing people go into these deep technical dives to research the actual behavior is very helpful. We've also, I believe we've mentioned the new JSR package registry a couple times, created by the Deno team. And there was a video talk from, I believe, Luca, who's part of the Deno team, going into some details on You know, a lot of the stuff that I've run into publishing the Redux packages over the last couple of years.
-
-[50:15] You know, issues trying to do the publishing, various problems with npm, goes into some details on how JSR is different, how it's supposed to work, and give some examples of actually doing the publishing. I don't know how much actual usage JSR is getting, but it's nice to see people actually rethinking this.
-
-## [React Native + Flutter](https://x.com/mdj_dev/status/)
-
-[50:33] **Mo Khazali:** The next thing is just a little bit of memes. More than anything, someone has decided to post a demo of React Native and Flutter running in a single app, which is quite funny. Believe it or not, I actually have tried this about a year ago. And the reason was we had someone who wanted to migrate away from Flutter.
-
-[50:50] So out of these memes, good conversations have actually started around how you can migrate and integrate Flutter and React Native together. In the case where someone wants to move away from Flutter. And you use React Native instead, so pretty fun times.
-
-## [Bun Q3 roadmap](https://x.com/jarredsumner/status/1807731197046653438)
-
-[51:01] **Carl Vitullo:** Earlier this month, Jared Sumner posted about the Q3 roadmap for BUN.
-
-[51:06] He says it's not exhaustive. And in the replies, adds more like, Oh, maybe we'll get to this too. But new stuff they're looking, they, they want to add a full stack bundler. I'm not exactly sure what that means, but I guess it's going to have overlap with like RSPack and probably server components too. I don't know.
-
-[51:22] A text lock file. So I guess another lock file format. I don't know why we need another package dependency tool. A CSS parser? on this roadmap seem confusing to me as a JavaScript runtime. He also talks about adding V8 C API compatibility, which sure, that makes sense, I can, I can see that, and getting better snapshots and timers for the bun test and mentions that he would like to ship a Postgres client sometime this quarter, but it's not in the main roadmap post that he made.
-
-## [Learn Suspense by building a Suspense-enabled library](https://www.)
-
-[51:57] **Mark Erikson:** So, we've been talking about suspense for, what, like six plus years now, but, there's been all the confusion over, how can you use suspense? Suspense only works with, React server components, or can you use it on the client? Are you supposed to use it on the client? There was a really good post that came out recently, Learn suspense by building a suspense enabled library that goes through some of the actual mechanics of trying to build a client side lib that uses suspense.
-
-[52:24] I'll be honest, I bookmarked this one because people have been begging for suspense support for RTKQuery. I looked at the issue actually, the issue is at least three years old. So I will probably be referring to this post when we hopefully get around to doing it, maybe later this year?
-
-## Mark's talk, "Why Use Redux Today" at React Summit
-
-[52:39] **Mark Erikson:** And the obligatory self plug, so I gave a talk at React Summit last month on why use Redux today, because this is a question that gets asked all the time.
-
-[52:50] TLDR, there's a lot of reasons why people adopted Redux in the first place. Some of those reasons no longer make sense, like avoiding the legacy context API, but the architectural reasons to consider using Redux are still valid. Being able to have a centralized store, being able to see that the state changes in the dev tools, having a well documented pattern for keeping state outside the component tree, So, it's not a lot of a sales pitch, it's like half of a history lesson, and then, discussions of trade offs, because I still find myself unable to give an unambiguous sales pitch.
-
-## [Chrome collects extra data for Google websites](https://x.com/)
-
-[53:24] **Carl Vitullo:** Cool. This is sort of general tech news a little bit, but Chrome apparently gives Google properties privileged information about your system resources, which is sketchy as heck. Why does Google need to know how much CPU my computer is currently using? Anti competitive behavior. Chrome taking advantage of vertical integration to suck up more data to use for reasons. Not great. Not exciting.
-
-## [Component, composition, colocation](https://bobaekang.com/blog/)
-
-[53:48] **Mark Erikson:** There was a really good post talking about trade offs and various architectural patterns between different ways to fetch data. Do you fetch data in hooks as components render? Do you do suspense based data fetching that starts nested down in your component tree versus do you try to kick it off, higher in the component tree, say like with a route or a page loader? Some very good actual thoughts of trade offs between these different patterns.
-
-## [Secret knowledge to self-host Next.js](https://www.flightcontrol.dev/)
-
-[54:15] **Mark Erikson:** And then, there was a good article from the folks at Flight Control, where they talked about challenges in trying to self host Next. js anywhere other than Vercel. It's feasible, but you definitely have to do some extra work.
-
-[54:29] Hosting Next on Vercel is obviously the happy path, and there's some challenges to try to fill in some of the pieces that Vercel would provide for you.
-
-## [Node can strip TS types soon?](https://github.com/nodejs/node/pull/)
-
-[54:37] **Mark Erikson:** Last but not, not entirely least, a few bits of news from the Node ecosystem. Node has merged a prototype PR to strip types and allow being able to just run TypeScript files directly.
-
-[54:50] Obviously, they're not actually checking the types, but similar to like TS Node, at least stripping off the types so it can just execute the code. Very perfect concept, but they're interested in iterating on it.
-
-## [Native SQLite drive in Node](https://nodejs.org/docs/latest/api/)
-
-[55:01] **Carl Vitullo:** Yeah, there's also, there's now a native SQLite driver in Node. Like if you're, if you have Node, you can now use SQLite. Wild! Apparently this came out of As Node was adding support for more browser stuff, like, apparently, I actually didn't really know this, you can also use local storage, quote unquote, from within Node, and that is backed by SQLite, and so then they did the work, after they got local storage in there, they added on a native SQLite driver.
-
-[55:30] I have been interested in Sqlite and the opportunities that it brings for like development patterns for a while, I'm actually making use of it in a bot that we use here in Reactiflux. I have a Kubernetes cluster set up with a Sqlite database just to keep everything co located and local. So I just have to back up a file instead of having to keep a running database server somewhere.
-
-[55:52] So yeah, just seeing more motion on Sqlite and seeing it get closer to the, uh, the actual runtime is, Very cool. I think that's awesome.
-
-## [Node moving away from CorePack?](https://github.com/nodejs/TSC/pull/)
-
-[56:00] **Mark Erikson:** Then, last item. So, Node ships with the npm package manager. And you've always had to use npm to then install other package managers like yarn and pnpm globally. There's been a long running effort to give Node a way to more directly install and use other package managers automatically.
-
-[56:21] If a project actually specifies it, and that's involved Node shipping a tool called CorePack. And it's been considered experimental this whole time, and it now seems as if there's discussions about removing CorePack. from Node. Folks like the Yarn maintainer are not happy about this, and I've seen a bunch of arguing about it, even within the last 24 hours.
-
-[56:43] So, who knows where this is going to land. You know, it's not like it prevents you from using Yarn or PMP in either way, it's about ease of usability. But clearly there's a lot of both technical debate and opinionated feelings involved.
-
-[56:56] **Carl Vitullo:** Yeah, I'm surprised to see a move towards getting removed.
-
-[56:59] It seems like a very valuable thing to have. It seemed very in line with the general direction of trying to decouple NPM from Node. js. But like you said, it's, this seems to be still very early.
-
-[57:12] **Mo Khazali:** I'm also quite surprised we've started using Corepack, and I think it's actually in the interest of other package manager maintainers, but I'm surprised they have backlash, interested to definitely read more about it.
-
-[57:21] **Carl Vitullo:** All right. That is the last link that we have. Thank you everyone for joining us. We'll be back on the last Wednesday of the month here in the live stage or back in your podcast feed just as soon as we can, which will hopefully be before Monday.
-
-[57:33] **Mo Khazali:** Thank you everyone for having me. Thank you for listening on to my rambling as always.
-
-[57:37] Always a pleasure and see you all next month.
-
-[57:39] **Mark Erikson:** Likewise, my two things, I will hopefully be publishing a very, very updated version of the Redux Docs Essentials tutorial within, like, the next few days, I've been working on it all year, and I will be glad to have that done. And as I mentioned at the start, I'm looking for a new position.
-
-[57:54] So, if you have suggestions, let me know. Please contact me.
-
-[57:57] **Carl Vitullo:** We gather sources from This Week in React, Bytes. dev, React status, Next. js Weekly, the React. js subreddit, and here in Reactiflux from the Tech Reads and News channel, as well as just following a million people on Twitter and looking for articles that way.
-
-[58:11] If you see anything that it seems like we missed, definitely send us a message. An email at hello at reactiflux. com with T M I R in the subject line. That's an acronym for the show. I read every email that comes in, including spam. So I will read it, even if I don't respond to it. We actually got a tip about the RISE tools for React Native.
-
-[58:30] Thank you for sending in a tip. That's our first one. Shout out. Thank you. If this is a show that you get value from and want to support, the best way to do so is, like, subscribe. Give it a review, help us show up in discovery charts for other people, or send it to your co workers, even if that gives away the secret of how you know so much about React.
-
-[58:46] Thank you so much, see you next month.
diff --git a/src/transcripts/tmir-2024-08.md b/src/transcripts/tmir-2024-08.md
deleted file mode 100644
index d848fd9..0000000
--- a/src/transcripts/tmir-2024-08.md
+++ /dev/null
@@ -1,646 +0,0 @@
----
-title: "This Month in React, August 2024: Matt Pocock taught us to make modules, RN is faster, iterator helpers are cool, JSR/Deno going sour"
-date: 2024-08-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-### Main Content
-
-- [[00:56](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
-- [[01:53](#react-19-progress)] React 19 progress:
- - [Initial “Suspense sibling pre-rendering” implementation work](https://github.com/facebook/react/pull/30800)
- - [DevTools support for Server Components](https://github.com/facebook/react/pull/30684) and [Viewing Source of Server Components](https://github.com/facebook/react/pull/30798)
-- [[05:23](#react-native-075)] [React Native 0.75 released](https://reactnative.dev/blog/2024/08/12/release-0.75)
-- [[07:30](#how-to-create-an-npm-package)] [How To Create An NPM Package | Total TypeScript](https://www.totaltypescript.com/how-to-create-an-npm-package)
- - [[08:13](#httpsblogisquaredsoftwarecom202308esm-modernization-lessons)] [Blogged Answers: My Experience Modernizing Packages to ESM](https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/)
-- [[10:36](#implementing-react-from-scratch)] [Implementing React from scratch](https://www.rob.directory/blog/react-from-scratch)
- - [Didact - build your own React](https://pomb.us/build-your-own-react/)
- - [Getting Closure on React Hooks](https://www.swyx.io/hooks)
-- [[12:04](#vercel-adds-retention-periods)] [Configure retention periods for deployments – Vercel](https://vercel.com/changelog/configure-retention-periods-for-deployments)
-- [[13:03](#waku-021-adds-server-actions-support)] [Waku 0.21 includes React Server Actions support](https://waku.gg/blog/server-actions-are-here)
- - [React Beyond the Render](https://playfulprogramming.com/collections/react-beyond-the-render)
-- [[14:35](#redux-essentials-tutorial-updated)] [Redux Essentials tutorial updated](https://redux.js.org/tutorials/essentials/part-1-overview-concepts)
-- [[17:46](#ts-56-rc)] [Announcing TypeScript 5.6 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-rc/)
- - [[18:31](#httpsgithubcomtc39proposal-iterator-helpers)] [Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers)
-- [[19:17](#expo-dom-released-)] [Using React DOM in Expo native apps](https://docs.expo.dev/guides/dom-components/)
-- [[24:51](#nitro-modules)] [NitroModules](https://x.com/mrousavy/status/1821165226546323930)
- - [Comparing to ObjC Turbomodules, it is significantly faster](https://x.com/mrousavy/status/1821651719945953309)
-- [[29:53](#jsr-and-deno-final-review--)] [JSR and Deno: Final Review 🚮 – David Bushell](https://dbushell.com/2024/08/09/jsr-and-deno-final-review/)
- - [What Deno Got Wrong About HTTP Imports](https://deno.com/blog/http-imports)
- - [The Deno Package Paradox – David Bushell](https://dbushell.com/2024/08/05/the-deno-package-paradox/)
-- [[35:45](#2024-stack-overflow-developer-survey)] [2024 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2024/)
-
-### ⚡ Lightning round ⚡
-
-- [[39:53](#cocoapods-going-into-maintenance-mode)] [Cocoapods going into maintenance mode](https://blog.cocoapods.org/CocoaPods-Support-Plans/)
-- [[34:30](#web-infra-devrslib-the-library-build-tool-powered-by-rsbuildmove-this-httpsgithubcomweb-infra-devrslib)] [web-infra-dev/rslib: The library build tool powered by Rsbuild.](https://github.com/web-infra-dev/rslib)
-- [[41:07](#accident-forgiveness--the-fly-blog)] [Accident Forgiveness · The Fly Blog](https://fly.io/blog/accident-forgiveness/)
-- [[42:17](#spatial-compute)] [spatial compute](https://sunilpai.dev/posts/spatial-compute/)
-- [[43:25](#how-airbnb-smoothly-upgrades-react)] [How Airbnb Smoothly Upgrades React](https://medium.com/airbnb-engineering/how-airbnb-smoothly-upgrades-react-b1d772a565fd)
-- [[44:34](#use-useid-instead-of-hand-making-ids)] [Use useId() Instead Of Hand-Making IDs](https://reacttraining.com/blog/use-useid-instead-of-hand-making-ids)
-- [[45:42](#common-sense-refactoring-of-a-messy-react-component)] [Common Sense Refactoring of a Messy React Component](https://alexkondov.com/refactoring-a-messy-react-component/)
-- [[46:20](#introducing-structured-outputs-in-the-api)] [Introducing Structured Outputs in the API | OpenAI](https://openai.com/index/introducing-structured-outputs-in-the-api/)
-- [[47:42](#httpsblogsentryiosentry-is-now-fair-source-sentry-is-now-fair-source)] [Sentry is now Fair Source](https://blog.sentry.io/sentry-is-now-fair-source/)
- - [Fair Source Definition](https://fair.io/definition)
-
-### Quick hits
-
-- [[50:51](#job-market)] Job market
- - [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE)
- - [Layoffs.fyi](https://layoffs.fyi/)
-- [[52:06](#new-releases)] New releases
- - [Material UI v6 is out now 🎉 - MUI](https://mui.com/blog/material-ui-v6-is-out/)
- - [Tauri 2.0 Release Candidate](https://v2.tauri.app/blog/tauri-2-0-0-release-candidate/)
- - [Nx 19.5 is here! Stackblitz, Bun, Incremental Builds for Vite, Gradle Test Atomizer](https://nx.dev/blog/nx-19-5-adds-stackblitz-new-features-and-more)
-- [[54:20](#upcoming-conferences)] Conferences
- - [React Universe 2024](https://www.reactuniverseconf.com/) Wrocław, Poland Sept 5-6
- - [JSConf Chile](https://www.jsconf.cl/) Santiago, Chile Sept 5-7
- - [UtahJS Conf](https://utahjs.com/conference) Salt Lake City, UT, U.S.A. Sept 13
- - [React Alicante](https://reactalicante.es/) September 19-21
- - [JSConf Ireland](https://www.jsconf.ie/) Dublin, Ireland & Online Sept 25-26
- - [SquiggleConf](https://2024.squiggleconf.com) Boston, MA USA Oct 3-4
- - [RenderCon](https://www.rendercon.org) Nairobi, Kenya Oct 4-5
- - [React India](https://www.reactindia.io/) Goa, India Oct 17-19, 2024
- - [React Brussels](https://www.react.brussels/) Brussels, Belgium Oct 18
- - [React Advanced London](https://reactadvanced.com/) London, UK Oct 25, 28
-- [[57:09](#outro)] Outro
-
-**Carl Vitullo:** Hello folks, welcome, thanks for joining us. This is the August edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. We're supported by Infinite Red, a consultancy that exclusively works in React Native. but more on them later. [00:22]
-
-Hello, I'm Carl. Uh, I'm a staff product developer and freelance community manager, here at Reactiflux mostly, where I run community programs like these events and the star helpers, and build tools to help keep the community operating. [00:34]
-
-**Mark Erikson:** I'm Mark. most people know me as the Redux maintainer or that guy with the Simpsons avatar, and I am currently an engineer at Replay. [00:42]
-
-**Mo Khazali:** And I am Mo. I head the mobile team at Theodo, which is another React Native and just generically tech consultancy. I'm also the organizer of the React Native London community and super excited to be here as always. [00:56]
-
-## Sponsored by Infinite Red
-
-**Carl Vitullo:** We are brought to you by Infinite Red, our main sponsor right now. They are an expert React Native consultancy that I am quite pleased to be a partner with because they are like authentically showing up to support the React Native and React ecosystems in like really meaningful ways. [01:12]
-
-They organize conferences, they host the largest React Native podcast, they publish the largest React Native focused newsletter, and they're Just really excited to work with them. Other than being great people who do great things in the community, they also, well, more precisely, they're a team of about 30 people, mostly developers with mostly greater than 10 years of experience. [01:33]
-
-So they actually work with your team to help you develop an expertise in building React Native. So if you are. Building something with React Native and need a little help hitting the ground running on that, definitely reach out to them because they are great people who will help you do good work. Cool. [01:51]
-
-All right. Mark, you want to start us off? [01:53]
-
-## React 19 progress
-
-**Mark Erikson:** So, last couple sessions, we talked about how React 19 had been delayed due to what has been known as Suspense Gate, where the React team had made a change last fall to pre rendering behavior for multiple nested suspense components. [02:07]
-
-So that instead of doing them in parallel, it effectively does them in serial. And people complained and said, we rely on these existing behavior, you're going to make a number of people's apps slower. And there was an outcry, and the React team had been ready to release React 19, and instead they backed off and said, "okay, yes, we see this is a big deal, we are going to figure out how to change the behavior." [02:30]
-
-But, the original PR that got merged was pretty complex, they've continued iterating on the internals. So it's not nearly as simple as revert the PR, it's we need to iterate further on the internals and figure out how to re implement some of the older behavior on top of the newer code changes. [02:48]
-
-### https://github.com/facebook/react/pull/30800
-
-**Mark Erikson:** There's been a thread where people have been trying to ask for updates, and the last comment in that thread a few weeks ago was, well Stay tuned to this thread for updates, but no indication of actual work. And so finally, within the last week and a half, I've seen a couple PRs where there is actual evidence of work being done on this. [03:07]
-
-Uh, Andrew Clark filed one PR that's added a feature flag that would later be added to gate this upcoming work. And then he just put up a PR a couple days ago with what looks like the initial implementation work for this Suspense sibling pre rendering behavior. I'm not sure if it's basically just this one PR, if he's working to split it into further PRs, or what the actual status is, but there is an actual PR with actual progress, and no idea how long it'll be before that gets merged, how long things will stay in beta or RC, but there is public evidence that they are actually pushing forward on this, and if you look at the code, you can see some of the complexity of the implementation work, like it's not just You know, one flag that gets turned on and off. It's a bunch of additional logic internally to make the older behavior possible. [03:57]
-
-### https://github.com/facebook/react/pull/30684
-
-And meanwhile, I've been very interested in this part. Sebastien Mårkbage had been spending, you know, really most of his last couple of years working on the server side aspects of React. Server components and a lot of the HTML, you know, related pre rendering work, but he's actually turned his attention to the React DevTools in the last month and a half. [04:17]
-
-And he's just been putting up a whole series of PRs, refactoring the guts of the React DevTools and making a whole bunch of improvements. And so two of them in particular, he's actually implemented what looks like React DevTools support for showing server components as part of the tree in the React DevTools. [04:37]
-
-### https://github.com/facebook/react/pull/30798
-
-**Mark Erikson:** And along with that, what looks like a feature for being able to view the source of server components from React DevTools on the client side. This is something that I had always wondered, like, when are they going to get around to doing this? Like, we've supposedly shipped this production ready feature, and yet there's no way to really debug or view server components. [04:56]
-
-So to me this is a pretty big deal. [04:58]
-
-**Carl Vitullo:** Yeah, definitely. Dev tool support has always been so good in React that calling it, you know, production ready when there isn't that dev tool support seems a little surprising. So yeah, cool to see that coming. I'm a little surprised to see that they are actually able to get like the source of server components into the client seems cool. [05:16]
-
-That PR is only a hundred lines added, 35 lines removed, so that seems very easy if they had a lot of support. [05:23]
-
-## [React Native 0.75](https://reactnative.dev/blog/2024/08/12/release-0.75)
-
-**Mo Khazali:** So, next up, React Native version 0. 75 has been released. Now, this has been one of the most sort of subtle and quiet releases of React Native I've seen in a very long time. There's a lot of sort of minor improvements under the hood that's happened. [05:37]
-
-The first thing is that we have a new version of Yoga. So, Yoga is the layouting engine in React Native that basically handles Your JavaScript code being translated to native layer drawing on the canvas. And so it's now got support for, so, so recently a couple of versions ago, we got support for gap when you're dealing with flex like layouting, and now there's also percentage value support for for GAP as well. So it's getting closer and closer to what you can do on the web. Another sort of update within this version is that you've got new architecture support that's getting more and more mature, and so you see that some of the libraries that previously didn't have new architecture support are getting more and more. [06:12]
-
-Positive support within the new architecture paradigm. And also, um, what you see is that tools where you can see the list of dependencies that you have now also mark whether or not new architecture is supported within it. It seems like we're kind of gearing towards finally having the new architecture as a default with the next release of React Native, which would be a pretty big deal. [06:31]
-
-But again, we've been saying that for a little while, so I'm not holding my breath, but I'm very, very cautiously optimistic about that. And then the last big thing within this version is that a couple of versions ago, again, they announced that you should use a framework and they suggested Expo as kind of the only option really that's, that's available currently. [06:46]
-
-And so we see a few movements that are coming out of that announcement. One of which is that the CLI tool React Native init is now being sunsetted in some capacity and moved to a community CLI. So. By the end of the year, so December 31st onwards, when you run the commands react native init, they just will no longer work, um, and you'll be guided either to use expo or to use the community fork of the CLI that will be maintained by the community. [07:11]
-
-But this is kind of a, let's just move it to the side. And wait for it to reach its demise type of thing. Which is, that's fine. That's kind of the direction that it's going towards. But it's just something to keep in mind though. [07:21]
-
-**Carl Vitullo:** Yeah, sure. Shades of create react app sunsetting. Commonly used tool that's just gonna slowly fade away. [07:28]
-
-**Mo Khazali:** Yes, exactly. Very much so. [07:30]
-
-## [How to Create an NPM Package](https://www.totaltypescript.com/how-to-create-an-npm-package)
-
-**Mark Erikson:** Alright, Matt Pocock, who's probably best known for a lot of his articles and courses on how to use TypeScript properly, has actually put together something adjacent and published a very long, detailed article on how to properly create and publish a package on NPM. This is an extremely detailed and very step by step guide that goes all the way from, you know, literally create a new Git repo to creating a package. json file, some of the fields you would want to define in there, setting up tools like TypeScript and Prettier, and one of the more complicated pieces, how to actually define the JavaScript files that are used in terms of the package exports. [08:13]
-
-### https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/
-
-**Mark Erikson:** Now, I spent a very large portion of 2023 trying to figure out a lot of this stuff for myself, because in today's JavaScript ecosystem, figuring out how to publish packages that properly support things like both ES modules and common JS modules is an absolute nightmare. [08:32]
-
-And there's all kinds of different permutations and different runtimes and environments and other things that you're going to run into. This guide isn't going to cover every different use case you'll run into, but it is a very, very good detailed look at a lot of the common things you would want to do to set up a reasonably standard package setup in today's environment. [08:52]
-
-So definitely worth looking at. [08:53]
-
-**Carl Vitullo:** Yeah, definitely. I have needed something like this many times. I've always kept track of generally each change in the ecosystem, but then when I, you know, actually sitting down and needing to write a new package and remembering which changes happened, what the current state of the best practice for setting up a new package are is always Very difficult. [09:12]
-
-So I'm really excited to have this. It's, I think your post from 2023 was like the first time I had seen somebody try to articulate what best practices for publishing a, you know, like professional quality NPM module looked like, and it's so weird. It's gotten so strange. [09:29]
-
-**Mark Erikson:** It is so painful and so bizarre. [09:31]
-
-Now I will, I will say I will say like a lot of the pain comes from Node, not allowed to import CommonJS into ESM, I can never remember which way it is. Um, like, you could do A into B, but not B into A. I just don't remember which way the limitation was. But the last couple versions of Node 22, I believe they've finally started to implement valid support for going both ways without any errors. [09:59]
-
-I can't remember if it's behind a flag, but at some point that version is going to become widely used enough that we can maybe, in five years, start to go past this. [10:10]
-
-**Carl Vitullo:** Hopefully. Yeah, I had actually just seen a tweet somebody put out complaining about a similar thing where, I think they called it a cardinal sin of CommonJS, but it was conditional exports. [10:20]
-
-You could put what you exported behind a flag. [10:23]
-
-**Mark Erikson:** Yeah, I think that was probably Ketanaito, the author of MSW. [10:27]
-
-**Carl Vitullo:** Correct. Arya in the chat saying, can't import ESM from CommonJS, but can import CommonJS from ESM. [10:35]
-
-**Mark Erikson:** Yep, that sounds right. Yep. [10:36]
-
-## [Implementing React from Scratch](https://www.rob.directory/blog/react-from-scratch)
-
-**Mark Erikson:** So I've always been a very big fan of articles that try to build a miniature version of a real library from scratch and kind of walk you through, here's the kind of functionality, here's what it actually looks like internally. Here's some of the pieces that you might consider. These are really, really good for both understanding the mental model and you know, kind of peeling away the black box and like understanding what's actually going on inside of these libraries. So I've seen a few different good articles along that line for both, you know, React and Redux and, and, you know, bundlers and other tools over the years. [11:11]
-
-So someone named Robbie Prusin just put out a really, really good new example of this implementing React from scratch that walks all the way through the process of creating elements um, modifying the DOM, putting, and putting all the pieces together. Really, really good post. Definitely recommended. And so, along that line, two other earlier posts that I'd recommend. The one I've pointed people to for me, for years, was from Rodrigo Pombo back in 2019, Build Your Own React. And then swyx has a classic post on how React hooks work by building your own version of hooks in 30 minutes. [11:45]
-
-**Carl Vitullo:** Yeah, also a huge fan of this kind of, like, first principles, understand how it works by making your own miniature version of it. Reminds me of, like, in the physical world, building a model. You're not going to use it for something for real, necessarily, but this gives you a really clear mental model of what's going on under the hood. [12:04]
-
-## [Vercel adds retention periods](https://vercel.com/changelog/configure-retention-periods-for-deployments)
-
-**Carl Vitullo:** I'm going to throw this in. This is maybe a lightning round tier post, but I'll show you right now. Vercel announced that they are going to allow you to configure retention periods for your deployments. I saw Guillermo Rauch post on Twitter about this and saying it was something that people have been requesting since he released, now, the precursor to Vercel. [12:25]
-
-So this is a feature that goes back nearly 10 years of people requesting it. And just like generally, retention periods, I feel like they're underrated. I feel like they're super powerful and just really good for a lot of things. Being able to configure how long data sticks around, I think, is a bit of a superpower. [12:42]
-
-It's one of the things that, like, once you figure out how to make use of it, it just lets you do a lot of really good, powerful things. I have an affinity for them because my first full time job was doing tech support for a backup server, and so learning retention periods and how the retention policies were structured was a big part of my early tech career. I think it's cool. It seems good. [13:03]
-
-## [Waku 0.21 adds Server Actions support](https://waku.gg/blog/server-actions-are-here)
-
-**Mark Erikson:** All right. So we're continuing to see folks try to work on building out React server component support in various frameworks. Uh, you know, Redwood's done some work. The remix folks are trying to work on things and one framework that's been plugging away kind of quietly is Waku, which is the brainchild of Daishi Kato, the author of Jotai and Valtio and maintainer of the Zustand library. [13:27]
-
-They have just released version 0. 21, which now includes support for server actions. We're still at a point where Next is really the only, like, full, you know, quote unquote, production ready implementation of React server components and server actions. But it's good to see that other frameworks in the ecosystem are getting closer. [13:47]
-
-While I don't know the overall status of WACU, like, it feels like it's starting to get a lot of the pieces fleshed out. And, you know, worth at least looking at. I mean, probably not ready to use in production yet. But it's an alternative approach to server components that'd be worth investigating. [14:02]
-
-**Mo Khazali:** Quite interesting that on their website, when you scroll down at the very bottom, it has a big sponsored by Vercel. Which seems quite funny, given that it's somewhat a competitor to Next in some capacity. [14:13]
-
-**Mark Erikson:** I was talking with Tanner Linsley and he said that like, Vercel has actually been doing a lot of work to both, like they, they sponsored, React Rally, the conference at the last minute, and they're even sponsoring some of the work on TenStack Start, I believe. [14:24]
-
-**Carl Vitullo:** Yeah, they are definitely all over the place sponsoring all sorts of stuff. So I guess they're just generally investing in the React ecosystem. Here for it. Let's distribute VC money. [14:34]
-
-**Mark Erikson:** Yeah, very much so. [14:35]
-
-## [Redux Essentials tutorial updated](https://redux.js.org/tutorials/essentials/part-1-overview-concepts)
-
-**Mark Erikson:** Okay. Next up is an item that is very near and dear to my heart because this has taken me like the entire calendar year in one form or another. [14:44]
-
-In fact, I think I actually published this, might've even been like the day after our last recording in July, but you know, hey. So Redux Toolkit came out in the fall of 2019. In the first half of 2020, I wrote a brand new tutorial for the Redux docs that I dubbed the Redux Essentials Tutorial. [15:02]
-
-And it was about 25, 000 words, and it covered how to use Redux Toolkit to build a plausibly realistic example app. And it taught Redux Toolkit for the first time as the default way to use and build Redux applications. And so that has been the primary Redux tutorial for the last four plus years. [15:23]
-
-But it was starting to get a little bit outdated in a couple ways. While I still think that the original version of the tutorial was, frankly, a really good piece of work and something I'm very proud of. I saw in retrospect that I could have done a better job explaining various, you know, Redux concepts. So, at the start of this year, I set out to do a pretty thorough modernization and update pass on that tutorial. [15:46]
-
-I did the work to convert the existing example application to TypeScript. Start to finish every single commit. And then I added some additional features and examples to demonstrate newer Redux Toolkit features that did not exist in 2020. From there, I went through and did a very thorough update on all the content. [16:06]
-
-Improved a lot of the explanations, moved pieces around. Ended up adding about 9, 000, close to 10, 000 words of overall content, not counting the content that got changed and shifted and moved around. So, a month ago, I published the finished update to this Redux Essentials tutorial. So, it is now TypeScript start to finish. [16:27]
-
-Which is something I spent a lot of time, I had spent time debating it out in the past. You know, I've always been concerned that adding TypeScript into the mix this early is going to add more learning overhead. [16:38]
-
-And that's still the case. But ultimately TypeScript adds so much benefit, and it's how we want people to learn. to use Redux, that I decided it was worth it to just do the whole tutorial in TypeScript all the way through and try to explain the pieces as I went. So, it's live, uh, it's now up to like 50, 000 words, it is incredibly comprehensive, covers effectively all the APIs in Redux Toolkit and explains Enough about how things work that you can follow through and use it and understand most of the why. [17:11]
-
-It doesn't go into how things work internally. For that, we still have kind of the lower level Redux fundamentals tutorial that explains, you know, like, how does a Redux store work, or how do some of the pieces connect together. But this is the way we want people to use Redux, and, you know, I'm pretty I'm biased, but I think it's the best way for people to learn Redux. [17:32]
-
-So I am very excited to have that out. It took me multiple months of effort to try to put that together. [17:38]
-
-**Carl Vitullo:** Nice. Cool. 50, 000 words. You could sell that as a book. [17:42]
-
-**Mark Erikson:** Pretty much. [17:43]
-
-**Carl Vitullo:** all right. I will pull us onto our next one. [17:46]
-
-## [TS 5.6 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-rc/)
-
-**Carl Vitullo:** TypeScript 5. 6 has a release candidate. Seems cool. Just going to call out a couple of cool things. [17:52]
-
-Something that caught my eye was the disallowed nullish and truthy checks. It's practically a linting rule, really. It just helps catch stuff that are pretty obviously bugs. Like, a good example they called out was if you accidentally switch the equals and the greater than in the, you know, trying to do a greater than equal comparison. [18:10]
-
-Oops, that's an arrow function, which is always going to be truthy. And so now TypeScript will give you an error for that. This expression is always truthy, you probably didn't mean to put that in an `if`. That just seems pretty useful. They talk a bit about other situations where they do allow, you know, constant expressions, but truthy expressions will now warn, which seems really great. [18:31]
-
-### https://github.com/tc39/proposal-iterator-helpers
-
-**Carl Vitullo:** I also liked the iterator helpers. It looks like they're pulling in a stage three proposal for, you know, ECMAScript, JavaScript, which I'm a little surprised by. You know, I, I thought that they generally wait for things to ship. [18:43]
-
-**Mark Erikson:** Stage three has usually been their target. [18:45]
-
-**Carl Vitullo:** Yeah, okay, cool. Good to know. But yeah, iterator helpers, it looks like that feature generally looks to be a recognition that people want to use iterables as if they were arrays, and so it adds a lot of array type, you know, functions to iterables. [19:01]
-
-So you can do things like map and filter and things like that on them. So that's super great. I'd love to see TypeScript adding support for that because that looks really great. I have tried to do that a number of times and been really annoyed that I had to spread it into an array first before using map. [19:16]
-
-So that's, I'd love to see it. [19:17]
-
-## [`expo-dom` released ](https://docs.expo.dev/guides/dom-components/)
-
-**Mo Khazali:** So, let's switch gears a little bit into some React Native news. So, a couple of cool things. First off, Expo DOM has been announced. So, now you've got a whole bunch of different ways to do code interoperability between web and mobile, uh, and all things in between. So, you now have React Strict DOM, there's React DOM, there's Expo DOM. [19:36]
-
-It's getting very confusing very quickly. But, really, the gist of all of this is, Expo's been really pushing this narrative of you want to be able to use a single code base to target web and mobile at the same time. Part of the challenge that will come up with a lot of people will be, well, I already have my web code base and I already have my React Native code base and combining these two together is going to be a bit of a tough egg to crack when you're dealing with a massive length in migration. [19:58]
-
-This is one of the things that they want to target with this, which basically is that they want to allow you to use DOM Primitives directly within, your React Native applications. So you put a use DOM directive at the very top of your file, and then that basically means you can start using DOM in there, and what it does under the hood is it basically constructs a web view and renders those DOM elements instead of real native elements. [20:17]
-
-Now this is quite powerful because it kind of means you can mishmash a little bit of DOM in places where you already have some code that's using React DOM inside of a React Native code base. And in theory, if your code is responsive and behaves well on mobile web, then it'll kind of work as you expected within your React Native app. [20:33]
-
-There is a lot of disclaimers within this in terms of how your data flow works and all of the different things that come with that, you can't, you know, render children within it. It's very primitive rendering at the moment. But, it's a path towards migrations, if you so need it, desperately. It's not a long term thing, I think it's a very short term, temporary, here's how we just get a fully functioning app out in the meantime while we slowly add native views into our application. [20:56]
-
-**Carl Vitullo:** Ah, interesting, okay. This is a stopgap they're not necessarily looking to have people build full React Native applications using web primitives. [21:06]
-
-**Mo Khazali:** Thanks. It's more of a migration thing. So, you know, I've worked on a number of apps. In fact, I'm working on one right now where it's a hybrid app. [21:13]
-
-A lot of companies will have hybrid apps where they have some of it in React native, that's native views. Some of it are web views and you have to use a web view inside of the native app to render some of the screens because, you know, they didn't have the time to build that out in a native fashion. So this is kind of just streamlining that process a little bit. [21:28]
-
-I think it's just to try to entice people to come over to the dark side of the native world, and then hold them hostage afterwards. Jokes aside with all of this though, I think it's a, it is a migration path. It is very experimental, it's nowhere near production ready, it's just being brewed as we speak this month, um, and they've released a bunch of demos and it's now officially on their docs, but it's very much with all of the disclaimers of you shouldn't use this yet. [21:49]
-
-And it comes with a whole bunch of limitations. [21:50]
-
-**Carl Vitullo:** Reminds me of Cordova and things like that. I'm a little surprised to see Expo doing something along those lines. I thought we had generally agreed that just like flapping a web view in a native app was not great, but okay, cool. [22:01]
-
-**Mark Erikson:** So just to make sure I follow the technical train here. [22:03]
-
-So roughly speaking, you write a line or two of code that looks like it's just rendering. Another React component, but under the hood, it's actually creating a whole web view, attaching it to the native layout, injecting the JavaScript code into the web view, and then actually rendering a web component, a React DOM component inside of that, right? [22:24]
-
-**Mo Khazali:** Exactly. That is exactly what it's doing, yeah. Layers of abstractions on top of layers of abstraction. So I think this will be around as a migration path. I think this is a small side project that they're just whipping up to make it easier for people to adopt the universal app paradigm, which is, you know, I want to have a single code base for all of my platforms. [22:40]
-
-I think you really want to focus on React strict DOM if you're thinking about the long term of your app, if you want to go down the route of having a universal app. This is just a temporary stopgap if you happen to have code in the web world that you want to easily use and migrate over to the native world. [22:56]
-
-**Carl Vitullo:** Sure. Yeah, right. I guess I still had the strict DOM in my head as you started talking about this and it threw me off. Definitely a, uh, a subtle but significant boundary between those things. Okay. Interesting. [23:08]
-
-**Mark Erikson:** And to recap for people who might not have listened to the last couple, last few episodes, React strict DOM, on the other hand, is adding more web like API capabilities to the React Native platform. [23:19]
-
-So you write more code that looks like React DOM for the web, and it makes your React Native code basically read as if it were web code. [23:27]
-
-**Mo Khazali:** Because the, the current status, and I guess maybe going a little bit further back into the context of this, we've had React Native Web for a long time, which allows you to basically take React Native code and run it through almost like a translation layer, uh, with almost like an interoperability layer that lets you render those native views and native texts on the web. [23:44]
-
-So this is, this has been around for years. It's like pretty much been there since the launch of React Native a few months after they kind of, somebody launched this project who now works at Meta. But that was a very big bloated piece of, of a dependency that you would add to your web app. So then React Strict on was like, can we, can we kind of find a way that's in the middle that uses the web based APIs, also makes it easier for web developers to come into the React Native world, translates them down to native views. [24:06]
-
-But also has a minimal overhead to use that same code on the web. And so, this is pretty much the exact opposite of that, but it's sort of a temporary stopgap. [24:15]
-
-**Carl Vitullo:** Yeah, interesting. Okay, so if, like, React Native Web from, you know, ye olde days was asking web developers to write code like React Native developers And React strict DOM is allowing web people to write what looks like web code, [24:31]
-
-**Mark Erikson:** Native code that looks like web code. And then this is this, eh, let's just shove a web view in the middle of our, all of our native views. [24:38]
-
-**Carl Vitullo:** They're covering all their bases. They're trying everything and seeing what works best. Cool. All right. [24:43]
-
-**Mo Khazali:** Where there's a will, there's a way. [24:45]
-
-**Carl Vitullo:** We've got a lot of wills going on. [24:48]
-
-**Mo Khazali:** There's many wills going on here. [24:50]
-
-**Carl Vitullo:** Neat. Very neat. [24:51]
-
-## [Nitro Modules](https://x.com/mrousavy/status/1821165226546323930)
-
-**Mo Khazali:** Let's move on to Nitro modules because this has been a big thing in the React Native ecosystem in the last month. Again, a little bit of context because I think this will help everyone kind of understand and set the scene. So, a few years ago with the old architecture, when you wanted to access native layer code, you would need to use a native module. That used something called the bridge and the bridge would basically serialize some JSON or some, some sort of JavaScript objects, send it across a bridge as we like to call it. And that data could be used by the native layer to be interacted and run some native operations. And that's how sort of the JavaScript layer and the native layer used to communicate with each other. [25:23]
-
-That bridge caused a lot of issues because you had sort of this one pathway to communicate between the native layer and the JavaScript layer and it caused slow apps and many issues and a lot of library maintainers were incredibly frustrated because it meant that if you use their library in a certain way, it would completely bog down people's apps and they were getting a bunch of issues around how their library is slow or React Native in general as being slow. [25:43]
-
-So then the new architecture tried to create a better way to interact between the JavaScript layer and the native layer. And so that's where TurboModules came into place. So the idea with TurboModules was you would create a TypeScript interface to define the type of functions and values that you want to communicate between the JavaScript layer and the native layer. Then it would run through some C code gen to generate the connection layer between the native layer and the JavaScript layer. And then you could write native layer code and use that with what they call turbo modules, which was the name for it. [26:13]
-
-That was a much more neat and streamlined way to communicate between the JavaScript layer and the native layer. That's a massive step up from the old architecture, and now Mark Roosevee, who is one of the sort of like people in the React Native ecosystem who's known to create some really cool native layer libraries that work really well, has now been playing around with this idea of creating an even faster way to communicate between JavaScript and the native layers and to write native layer code as, as a React native developer. [26:39]
-
-And he's calling it Nitro Modules and he's created a lot of fun puns out of them. For example, if you wanted to generate a Nitro Module, you run Nitrogen, which is, uh, quite fun. Um, [26:49]
-
-**Carl Vitullo:** Oh, my god. [26:50]
-
-**Mo Khazali:** It's great. [26:51]
-
-There's, this isn't really public at this, it's not very clear a lot of the stuff that works under the hood. I think it's getting released and drip fed as we kind of speak this month, but just some comparisons that he's run with Objective C based turbo modules compared to Nitro modules is that it's apparently like 10x faster, so 220 milliseconds in a benchmark that he ran versus 20 milliseconds. There's also another way that the Expo team have created Expo modules. [27:16]
-
-We're going, we're seeing a trend here, right? Like the React Native Ecosystem likes to invent and reinvent different ways of doing the exact same thing, whether it's with the strict DOM stuff or with this, but anyway. So then you've got Expo modules, which is slower to Turbo modules. And then now there's Nitro modules, which is apparently the fastest of them all. [27:31]
-
-So we'll see how this plays out. It's yet another approach of trying to handle this native to JavaScript communication. We'll see if it, if it actually pans out and how it, how it goes on, but promising signs at the beginning, and a lot of people seem very excited about it. [27:43]
-
-**Carl Vitullo:** Yeah, super neat. Throwing a bunch of shit at the wall and seeing what sticks, trying a bunch of different approaches. [27:49]
-
-I feel like that naturally flows out of where React Native sits in the world because it has iOS, Android, web, macOS, Windows, well, you know, it gets touched by so many different developers. And so I feel like where web and React can get a little bit like monoculture a little bit just because it's, you know, there's the one true way of doing it, but I feel like that sort of variety of approaches maybe flows a little bit more naturally out of React Native as a kind of a, I don't know, kind of a natural melting pot of developers. I appreciate that. [28:21]
-
-**Mark Erikson:** Polyglot development. [28:22]
-
-**Carl Vitullo:** Yeah, sure. [28:23]
-
-**Mo Khazali:** It feels like React in the early days, rather than what React is today. [28:26]
-
-Like, I've been in between the web and the mobile ecosystem. And, you know, I feel like the React ecosystem has reached a point of maturity, and there's less experimentation going on, it feels. Whereas with the React Native ecosystem, there's a bunch of people working on 3D rendering at the same time, and then there's a bunch of people working on web support at the same time, and then there's a bunch of other people working on native to, you know, JavaScript interfacing all together. I think it brews, a healthy amount of competition to try to get the best solution out of there. [28:52]
-
-**Carl Vitullo:** Yeah, thriving ecosystem in the biological sense. It's uh, evolution, survival of the fittest, many, many competing strategies and competition with each other. It's cool to see work on the bridge happening, because, I haven't done a ton of serious development with React Native, but that has always been a huge bottleneck. [29:10]
-
-I mean, you know, anytime you have a lot of data flowing through one thing, like, it's gonna be a challenge, it's gonna be a limiting factor if it's not fast. Interesting to see this come out of CodeGen from using TypeScript as a schema, it sounds like. It sounds familiar to my extremely vague understanding of things like protobuffers, where, like yeah, if you're just sending JSON, There's only so much you can optimize it because JSON as a data structure is just slower to parse. [29:37]
-
-You know, you don't have a schema, you don't know what it looks like, so you have to figure out what it looks like as you go. So starting from a schema, starting from a specification of what the data contains, and then using that to generate like ultra fast native code makes a lot of sense to me. That's, that's pretty cool. [29:53]
-
-## [JSR and Deno: Final Review 🚮 ](https://dbushell.com/2024/08/09/jsr-and-deno-final-review/)
-
-**Carl Vitullo:** All right. I will bring us on. Just a couple thoughts on JSR and Deno. I think Mark brought these up and had them cross my radar, but David Bushell, who is a WordPress developer mostly, wrote a couple of blog posts that I think are pretty It's a pretty rough indictment of the JSR, you know, module ecosystem and generally the path that Deno has taken through module, you know, managing modules, package dependency. [30:20]
-
-One of the criticisms that he brings up about Deno in general is as a, you know, okay, it's a venture backed company. We've talked a little bit on this show before about venture backed open source projects. One of the criticisms that David Bushel puts out is that it doesn't really feel like, it feels corporate, like the communication feels corporate. [30:38]
-
-It feels like corporate PR, not, you know, somebody talking about what they're working on. And that was actually, that resonated with me because that's something I've noticed. Like, for instance, I set up an ecosystem news channel here in Reactiflux, and Deno stuff is some of the only things that come through it, and it feels like somebody set up a corporate process and there's somebody whose job it is to make sure that all of the communications channels get populated, you know, in a way that it doesn't feel that way for other projects like Expo or React or things like that. [31:07]
-
-So, I don't know, just like as a vibe. That was an interesting call out that I had noticed on my own as well. They talk about the meandering path that Deno has taken through trying to get package dependencies going, you know, cause, um, Ryan Dahl had a, you know, what node got wrong about Imports, I'm misquoting that, but he complained about errors he had made in creating Node and talked about how he was going to do it differently this time with Deno. [31:34]
-
-And then they, you know, they did like a deno. land package registry for a while and then like, oop, nope, we're replacing that with JSR. But now it's all a little confused. Like it's, JSR applies certain restrictions on what you can publish. Like you have to annotate the return types. of any published module. [31:53]
-
-So you can't just let it infer the return type, which seems like a kind of strange restriction to put on it. I guess it's maybe to enforce SemVer through types, you know, use those return types as a schema and assert like, oh, nope, you got to break it. You change the types. I don't know. It's interesting. [32:08]
-
-It's curious. The single most, like, disruptive point that David Bushell made was pointing out that Dnode doesn't resolve sub dependencies like Node does. Like, the way that the JSR registry works does not permit sub dependencies in the same way, in the way that we've grown accustomed to with Node. Which, like, I have called that out before. [32:28]
-
-That, subdependencies, dependencies of dependencies, is one of the best parts of the JavaScript ecosystem. The fact that I can install a package and I don't need to, you know, to an extent, I don't need to Manually make sure that I have given it everything that it needs. You know, there's some exceptions, like if you're using, you know, there's peer dependencies where that is still the case, but in general for if I install a library, that library brings in what it needs on its own. [32:56]
-
-There's downsides to that of course, as well, but I generally consider that to be one of the major differentiators between JavaScript and, you know, PHP or Python. So seeing that go backwards is, seems like a bad thing to me. So that seems, yeah, I don't know. It's just a, a lot of pretty negative takes on Deno and JSR. It's given me a lot of pause on it. [33:15]
-
-**Mark Erikson:** I mean, it's not just one hard problem, it's dozens o f hard problems simultaneously. I mean, you know, think, think back to, you know, trying to work with C where there is no such thing as a package manager. Java is sort of its own different world. C sharp is its own different world. [33:31]
-
-Rust has the cargo tool and a centralized registry. Python is an utter mess. There was an XKCD years ago about how bad Python package management is, and I've continued to kind of just keep a general eye on developments in the Python world. And it's more confusing over time. So there's a lot of very, very justified complaints about how bad package management is on multiple levels in, we, we say the JS ecosystem, and by that we usually mean the Node plus NPM. [34:02]
-
-But all things considered at the same time. Most of that ecosystem generally works, and so it's been interesting to see Deno take a slightly different path and actually have to sort of backtrack a bit and say, Well, yeah, actually it turns out maybe a couple of those ideas weren't so bad after all. [34:19]
-
-**Carl Vitullo:** Right, they went pretty hard in copying Go style dependency management. [34:23]
-
-And I always thought Go style dependency management sounded like an absolute nightmare. And so, yep, alright, they're walking some of that back. [34:30]
-
-## [web-infra-dev/rslib: The library build tool powered by Rsbuild](https://github.com/web-infra-dev/rslib)
-
-**Mark Erikson:** There's yet another new build tool out called RSLib to work through the chain of pieces on this one. [34:37]
-
-So, the folks at ByteDance have an incredibly prolific infrastructure team, and so the way I understand this is they built a full blown Rust re implementation of Webpack that they call RSPack. In fact, they've actually made a couple comments about it would be nice if this could just be turned into Webpack version 6, in theory. So RS Pack is web pack five, but entirely rebuilt and rust, effectively. [35:02]
-
-RS build is a layer on top of RS Pack that makes it a lot easier to configure, or the, the configuration syntax is closer to like Es builds configuration level roughly than web pack's configuration level, where you're having to create a whole bunch of plugins. [35:19]
-
-And so, rsbuild is meant more for applications, and I guess they've made a third layer on top of that where rslib is a wrapper or specialization of rsbuild that is more meant for building libraries with a proper configuration output. So, I'm not sure what's leading to all this proliferation of build tools from them, but they are very happily cranking away on a whole series of things. [35:45]
-
-## [2024 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2024/)
-
-**Carl Vitullo:** All right. I'll pull us onto our next one. We spent a lot of time last month talking about state of JS, state of React, state of HTML, we have another survey, the Stack Overflow Developer Survey, the results came out this month. I'm not going to do too deep a dive, I think, although Mo, yeah, we had talked about, you know, demographics and selection biases of the state of JS, definitely more to talk about here. Yeah, some, some points that I took away from this that were interesting to me. I mostly looked at the professional developer respondents, just that's who I am. That's who I am viewing as the target audience for this show. [36:20]
-
-Something that surprised me a little bit, they said that more than 75 percent of professional developers have at least a bachelor's degree. I think it was like 45 percent have a bachelor's, like 26 have a master's, and like another 5 percent have some kind of specialized professional degree, like a JD or, you know, something like that, legal, medical, whatever. [36:40]
-
-For years of experience, front end developers were absolute bottom of the list, except for student, which was interesting, but also not surprising. You know, Boot camps, they probably teach you front end, like, makes sense. It's probably the most accessible part of the software field. So not super surprising there, but yeah, uh, also less than 6 percent of respondents to this survey self identified as a front end developer. [37:03]
-
-That's lower than I think it was in previous years. It feels like front end has kind of. I don't know, it feels like it's diminished over the last couple years. I was looking at the country demographics. I was curious about this because I know from our statistics who uses Reactiflux, I know that we have a huge Indian population within the server. Having my own read, my own perspective on what those metrics look like by actual like usage and participation. I was curious to see how they'd be reflected. And the answer is not great. Top five countries as responded to the Stack Overflow survey were the U. S. with like 19 percent, Germany with a bit over eight, India with a little over seven, UK with five and a half, Ukraine four and a half. [37:45]
-
-I was curious to see how, what data I could find to back that up on, you know, what those stats look like. I couldn't find a direct comparison between the US and India, partly because the only English sources I could find for tech jobs in India just said all of IT, all of software in one. [38:02]
-
-### https://www.meity.gov.in/content/software-and-services-sector
-
-### https://www.bls.gov/oes/current/oes151252.htm#nat
-
-**Carl Vitullo:** But yeah, they said five and a half million IT and software workers in India, when I summed those same jobs up for Bureau of Labor Statistics in the U. S., that was like four and a half million. So just to say, there's definitely a huge English speaking bias in these surveys, which is unfortunate because the programming world is much larger than the English speaking world. some other Things, JavaScript was the number one most used technology here, and 25 percent of people learning to code self reported using Google Cloud. [38:32]
-
-I think that was like one of the top. That was the number one. That was the like most reported. Vercel was number three in people learning to code. Uh, for professional developers, top three, obviously, AWS, Google, and uh, Microsoft, but Google and Microsoft combined were about equal to AWS's numbers. On that list, Vercel was seventh. [38:51]
-
-Just about a percent lower than DigitalOcean, which was behind Cloudflare, which was behind Firebase. React and Node, together, both topped the web frameworks list of, technologies used with jQuery in number three. But yeah, 18 points behind React and Node, so definitely a different tier. But yeah, jQuery, what staying power it's had. I actually saw that this was, I believe the 18th birthday? It's old enough to vote. [39:15]
-
-**Mo Khazali:** The one thing that's interesting to me is just the 25 percent of folks learning to code use Google Cloud. I have a suspicion that might be to do with the fact that I know that there are GCP is quite involved in student fairs and a whole bunch of stuff giving free credits to people for hackathons and whatnot. [39:31]
-
-I wonder if there's some sort of correlation there where a lot of people seem to use it for their student experimenting and hacking, but maybe not so much when they get into the professional world. Just an observation. [39:42]
-
-**Carl Vitullo:** Yeah, that actually makes a lot of sense. I have seen them sponsor a lot of hackathons and things like that. [39:46]
-
-Yeah, I hadn't considered that, but scans. Cool. That was our last main content piece, uh, I guess into the lightning round. [39:53]
-
-## [Cocoapods going into maintenance mode](https://blog.cocoapods.org/CocoaPods-Support-Plans/)
-
-**Mo Khazali:** I'll just jump in with an update from the React Native ecosystem, or more, more broadly speaking, the mobile ecosystem. So, in terms of package managers, CocoaPods used to be the be all and end all when you wanted to build an iOS app, in terms of managing your packages, and we've come a long way where CocoaPods is now going into maintenance mode. [40:10]
-
-Now, CocoaPods is actually used by most of the cross platform technologies as the package manager of choice. So React Native uses it, but I think Flutter also uses it, and apparently Unity also uses it for some of their stuff as well. So there's a whole lot of this ecosystem that's being built in CocoaPods. [40:25]
-
-But what's happened here is that Apple's actually released their own package manager called the Swift Package Manager, or SPM for short. What the CocoaPods team called it was that they got Sherlocked, which is a reference to old school OS X, where they Basically got rid of an app called Watson, which was what Spotlight is now. [40:41]
-
-They created Sherlock at that point, which basically did all of the functionality that Watson used to do that was already integrated into the OS itself. So they're basically citing that saying we've been Sherlocked and we're now going to go into maintenance mode as a result, because there's no competing with Apple. [40:55]
-
-So a sad day for everyone who loved and used CocoaPods for years, but obviously we're going forward into the SPM era and React Native is already kind of on that route to adopt SPM support. [41:07]
-
-## [Accident Forgiveness · The Fly Blog](https://fly.io/blog/accident-forgiveness/)
-
-**Carl Vitullo:** I saw a cool policy change for Fly. io, which is a, sort of a competitor to Vercel, it's a cloud compute platform. [41:14]
-
-They are doing an explicit accident forgiveness policy, which is just kind of great. It's generally socially understood that platforms like AWS or Vercel or, you know, whatever if you have some weird billing situation that arises, like I think one that happened was like somebody got in an infinite loop during their CI build and that caused a huge number of function invocations and because you could build per function invocation, they had, you know, like a 200, 000 bill when they're used to paying like 2, 000. [41:45]
-
-It's socially understood that most of the time, if it's not a repeat occurrence and it's not malicious, then they will forgive the bill. But it's socially understood. It's not in policy anywhere. It's just you put it on Twitter, you complain, it becomes a PR issue, and the company refunds you. [42:00]
-
-So now fly. io has put up an actual policy saying we forgive accidents and has given more clarity around there. I appreciate that. It's always nice to see social norms turn into policies, especially when they deal with six figures in billing. [42:17]
-
-## [spatial compute](https://sunilpai.dev/posts/spatial-compute/)
-
-**Carl Vitullo:** I saw a wonderful blog post from Sunil Pai, who I'm just a big fan of. We've collaborated a little bit in the past, but he has done PartyKit. He worked on Wrangler at CloudFlare. He's now working at CloudFlare again. He wrote about spatial compute, which is letting the network decide where in the world to run your code. So this is sort of an incremental step forward for serverless paradigm. [42:40]
-
-Instead of starting up a server that runs your code, you just say, this is the code that I want to run. Please start it when this request is made. But you still generally tell it, what region of the world that code is going to be hosted in. So this is just a blog post talking about not doing that. Letting the server decide, letting the network decide where in the world to run your code. [42:59]
-
-I just think that's a really interesting idea. It seems good. Seems kind of inevitable. Uh, and this is the first time I've ever seen anyone mention it. So calling it out. [43:06]
-
-**Mo Khazali:** Interestingly, he's called it spatial compute. And I think he's put a disclaimer at the top saying, sorry, Apple, but that I wish he chose another term for that. [43:13]
-
-That's already been used. [43:15]
-
-**Carl Vitullo:** Oh, that's true. That is what Apple called their Vision. [43:17]
-
-**Mo Khazali:** Yeah. Vision Pro Computing. Yeah. It's, it's, I wish there was another term he could use for this. [43:22]
-
-**Carl Vitullo:** I like that he called it out and still did it anyway. [43:25]
-
-**Mo Khazali:** Yeah, exactly. [43:25]
-
-## [How Airbnb Smoothly Upgrades React](https://medium.com/airbnb-engineering/how-airbnb-smoothly-upgrades-react-b1d772a565fd)
-
-**Carl Vitullo:** Womp womp. Yep. Airbnb, we talked about Airbnb last episode as well. Uh, they put out a blog post about how Airbnb smoothly upgrades React. [43:34]
-
-Last month, we talked about how they had just upgraded to React 18. So this is now two months later. them talking a little bit more about the process by which they did so. It was a pretty good read. It talks a lot about, like, feature flagging, you know, blue green deployments, and just sort of the trials and tribulations of what it means to update a core dependency of a widely used app that is in many, many phones with a huge variety of, you know, Performance and, you know, network and all those sorts of things. [44:01]
-
-So I appreciated that, just right at the beginning of the They show like, you know, here's the ideal, like a stair step function of what version we're using. And then here's the reality of what version we've used over time. And it's got lots of like false starts where it's, they ship it and it's like, Oh, nope. [44:14]
-
-Okay. There's a bug. We got to roll it back. Let's try again. Nope. Still bugs. Roll it back. This is, Relatable to my career. There's just, you can't do a big overhaul without missing some kind of edge case that you didn't anticipate. So, um, just always appreciate seeing people pull back the curtain and show what those pains look like, especially at big companies that have huge distributions. [44:34]
-
-## [Use useId() Instead Of Hand-Making IDs](https://reacttraining.com/blog/use-useid-instead-of-hand-making-ids)
-
-**Carl Vitullo:** all right, great blog post from React Training, which I'm actually not sure who's running this anymore, but it was started by Michael Jackson and Ryan Florence of React Router and Remix. They've been on my radar for a very long time. Looks like this was written by Brad Westfall. Use ID instead of hand making IDs. [44:50]
-
-This was one of the clearer articulations of what use ID is meant to be used for that I've read. This just really kind of made it click for me. It talks about using. an ID attribute on the DOM, and why you shouldn't handwrite them. And it was just very clear and simple. The gist of it is, if you handwrite an ID, then you can only use that component once in order to not violate the guarantees that an ID has with the browser. [45:17]
-
-You know, in a browser, an ID is supposed to be unique. If you select an ID, you get one element exactly. And so if you hand write an ID, your component can't be reused without violating that contract. What a simple idea. That makes sense. I now intuitively understand why use id is a valuable API to have. Um, yeah, just appreciated that. I love when something I didn't understand just clicks and becomes intuitive. I like it. [45:42]
-
-## [Common Sense Refactoring of a Messy React Component](https://alexkondov.com/refactoring-a-messy-react-component/)
-
-**Carl Vitullo:** Calling out this great blog post from Alex Kondov, he wrote, Common Sense Refactoring of a Messy React Component. Refactoring messy components, breaking them down into, from one mega component that does way too much into a smaller number of components that each have a smaller, you know, a single responsibility, has been a recurring theme in my career. [46:01]
-
-This looked like a really great write up. I appreciate that it just does, like, A two paragraph preamble and then dumps 300 lines of kind of gross code on you. It's like, yeah, you know, that is, that's the experience of entering a new code base most of the time. I appreciated this breakdown of here's what the process of refactoring a messy component looks like. [46:20]
-
-## [Introducing Structured Outputs in the API](https://openai.com/index/introducing-structured-outputs-in-the-api/)
-
-**Carl Vitullo:** All right, small news from OpenAI. I had actually noticed this. We use OpenAI to do a resume review AI feature here, and I just did a revision to it, and it's much better. It's a little bit sassy. It's very terse. I like it. But yeah, OpenAI now has structured outputs in the API, so you can tell it what shape of JSON you want it to give you back, and it will give you that structure. [46:43]
-
-I know in the past that has been a pain point. I remember people complaining about like just getting OpenAI to give you pure JSON without like, okay, here's the JSON you asked for, JSON. Uh, you know, just purely unhelpful. Just caught this bit of news. If you're curious about writing a little open AI side project, I think this is maybe going to make it a bit easier. [47:03]
-
-**Mo Khazali:** It's also quite interesting for the mobile world, because you see a lot of a bigger shift towards server driven UI now, where, you know, you render things or you compile a JSON object that defines how the UI should look like in the mobile space, because, you know, that really works in mobile because, you You don't have to go through App Store updates, so you can basically have a dynamic page that uses JSON to decide how to layout itself. [47:24]
-
-And so maybe pairing that with something like this could be very interesting because you can give it the right confines and restrictions and then say generate me dynamic UI and then it'll kind of be a smart AI native based app. [47:35]
-
-**Carl Vitullo:** Wild. Kind of V0 vibes. V0 from Vercel. [47:40]
-
-All right. Here's my last little news item. [47:42]
-
-## [Sentry is now Fair Source](https://blog.sentry.io/sentry-is-now-fair-source/)
-
-**Carl Vitullo:** This actually crossed my radar very late. I would like to be more prepared to talk about this because it's at the intersection of, you know, open source and licenses and legal stuff, which I am personally fascinated with. But Fentry has announced that they are FairSource. FairSource is a new concept to me. [48:00]
-
-It's a new project. So they say, today we're launching FairSource, a new approach to software sharing that is safe for companies to adopt and developers to use. Seems pretty neat. They talk about, they give a list of projects that are working with it, and they define it as like publicly available to read, allows use, modification, redistribution with minimal restrictions, and I guess notably it says that it undergoes delayed open source publication, which they give as a four letter acronym, D O S P, very enterprise. [48:29]
-
-It's not quite a license, it's sort of a social contract surrounding a license, I guess. They talk about a new functional source license, but it also recognizes a fair core license. And the business source license. It's interesting. I'm definitely gonna have to dig into this a lot more because this is just referencing a bunch of licenses that I haven't heard of in a like social contract for how source gets released that I haven't seen codified. [48:56]
-
-I've seen companies do things similar to this before, but there hasn't been a name for it. It hasn't been saying like, yes, we are. This, we are FairSource, so definitely interesting. It's not quite free and open source, but it is adjacent free and, you know, FOSS, FOSS has been difficult for many companies to actually execute on and live up to. [49:17]
-
-So this looks like a more friendly. type of license, mode of releasing source code into the world. So maybe it'll give engineers at more companies greater ability to make a compelling case for open sourcing internal code, which would be lovely. I would love to see more proprietary code get open sourced. [49:35]
-
-Too many things happen in secret. [49:37]
-
-**Mo Khazali:** The delayed open source publication is quite interesting because it's having a separate Closed source version of a code base that gets synced with an open source version is not, you know, unheard of. The React Native code base, as an example, is like this. So, it's not the most bizarre thing to have, and it's been happening. [49:52]
-
-It's just maybe not been codified like you mentioned, and maybe this is the way to do it. [49:56]
-
-**Carl Vitullo:** Right, exactly. That's the classic problem in a lot of businesses that would like to open source, is there's some part of it that is, like, truly proprietary, where if they release that, then, like, you know, they're giving away the secret recipe. [50:07]
-
-Or Contractual agreements they have with their customers where like they wrote some custom integration code and like that can't get open sourced. So like there are very real business constraints that make it difficult in some cases to open source code. Like you said, some companies have done that through things like synchronizing source code, but that's been done kind of ad hoc. [50:29]
-
-It's, you know, Each company has figured out its own way to work, to make that work. So seeing this as a template, a framework for people evaluating that decision, to push it over the finish line, to make it actually happen. Uh, that seems really valuable. This seems like one of those like quiet things that will have an outsized impact on the open source world. Pretty neat. [50:51]
-
-## [Job Market](https://layoffs.fyi/)
-
-**Carl Vitullo:** All right, some information about the job market. It was not great this month, but most of that was because of layoffs at Intel, just not great. So 15, 000 layoffs from Intel alone, overall like 25, 000 layoffs in tech. Which is not great, but since most of that came from one company, that's still pretty on track from where it was last month. [51:11]
-
-Intel screwing up doesn't really reflect too much on the broader, you know, tech and software ecosystem, I don't think. [51:18]
-
-### https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
-
-**Carl Vitullo:** I've been using this Fred data source of. Job postings on Indeed. And that is still trending down, which I'm a little surprised about. It's just been a consistent downward trend. It's down to 68 percent of the baseline of like the start of 2020. So, you know, pre pandemic, which I'm surprised. That's wild. I thought it was getting better. [51:38]
-
-**Mo Khazali:** Just on that, I guess like Intel and Cisco both together are 21, 000 out of the 25, 000 layoffs. So if you take those two out, it's, it's actually like three, four thousand. [51:49]
-
-**Carl Vitullo:** Okay. That's actually quite a bit smaller. [51:50]
-
-That's nice. So yeah, last month I commented that it was the first time in a while we haven't had a pretty big pop of layoffs at the start of a new quarter. So yeah, cool. I guess that's generally holding true except for two megacorps running into problems. [52:04]
-
-A couple of new releases. [52:06]
-
-## [Material UI v6](https://mui.com/blog/material-ui-v6-is-out/)
-
-**Carl Vitullo:** material UI put out version 6. They commented that they took two and a half megabytes out of the bundle size they'd installed on your disk, not the published size of your bundle, which made me look at that and go, wow, this is a 12 megabyte Install size, which is wild. That's larger than I realized. But yeah, Material UI, if you're using it, there's a new version out, new major. [52:28]
-
-**Mark Erikson:** Although on that note, the TypeScript team has done some fantastic work shrinking the size of the installation on disk. Like it, it was up to like 50 megs, I think, as of like 9. And they did a lot of work in 5. 0 to convert some of the internals over to ES modules. And then, and then. Working on deduplicating some of the bundled files that they had and other internal optimizations. [52:55]
-
-I think at this point it's down to like 20 or 25 megs, which is still sizable, but I mean on the other hand, you know, 50 percent net win is a net win. [53:04]
-
-**Carl Vitullo:** Adhering that size, you know, 25 megs for all of TypeScript versus, you know, I don't know if it's exactly 12, I don't have the number in front of me right now, but half of TypeScript for material UI seems like a pretty big lift. [53:16]
-
-## [Tauri v2 RC ](https://v2.tauri.app/blog/tauri-2-0-0-release-candidate/)
-
-**Carl Vitullo:** There's also Tauri v2 has a release candidate out. I don't know a ton about that, but we talked about it briefly in the past. [53:24]
-
-**Mark Erikson:** It's an Electron competitor allows you to build apps that run on the desktop But the UI is built with web technologies The difference is that Electron you're shipping an entire copy of Chrome as the rendering engine Whereas Tauri uses whatever OS's native web views instead So the overall shipped size is a lot smaller. [53:43]
-
-**Carl Vitullo:** Heck yes, seems cool. So they've got a new version 2 coming out, which should be big. [53:47]
-
-## [NX v19.5](https://nx.dev/blog/nx-19-5-adds-stackblitz-new-features-and-more)
-
-**Carl Vitullo:** There's also NX version 19. 5. I don't know a ton about NX. [53:53]
-
-**Mark Erikson:** It's primarily a monorepo management tool. So managing lots of individual packages for both, you know, multiple libraries, multiple applications in one repo, which each of which could be, you know, being built with different tools. Like you might have, you know, a common TypeScript library and maybe, you know, a Vite app and an Angular app all in the same repo. And so NX does work to deduplicate the builds as well as manage creating and updating a lot of those packages. [54:20]
-
-## Upcoming conferences
-
-**Carl Vitullo:** On to some conferences that are coming up. [54:22]
-
-### https://www.reactuniverseconf.com/
-
-**Mo Khazali:** Next week, if I'm not mistaken, and time is not escaping me, is React Universe Conf. React Universe Conf happens every year in Wroclaw in Poland. So it's happening on the 5th and 6th of September. Uh, it used to be called React Native EU, but it's now evolved since React and React Native are getting closer and closer together by the day. So I will be emceeing the conference. Hence why I'm giving this shout out. [54:44]
-
-So come along. Hopefully it'll be a good time. There's a lot of great speakers headlining there. [54:48]
-
-**Mark Erikson:** Was it September, almost September already? [54:50]
-
-**Mo Khazali:** That's why I have to take a double glance at the calendar. [54:53]
-
-### https://www.jsconf.cl/
-
-**Carl Vitullo:** Cool. There's also JSConf in Santiago in Chile. Overlapping with React Universe. So that's going to be September 5th through 7th. [55:01]
-
-### https://utahjs.com/conference
-
-**Carl Vitullo:** I feel like we've been talking about Utah conferences a lot, I guess. But yeah, Utah JS is doing a conference. Seems like there's been a lot of stuff going on in Salt Lake City. Yeah. [55:10]
-
-### https://reactalicante.es/
-
-**Carl Vitullo:** There's also React Alicante in Spain, September 19th through 21st. [55:15]
-
-**Mark Erikson:** I'm speaking, looking forward to it. [55:17]
-
-**Carl Vitullo:** Woo! [55:18]
-
-### https://www.jsconf.ie/
-
-**Carl Vitullo:** And JSConf Ireland in Dublin, September 25th and 26th. [55:23]
-
-### https://2024.squiggleconf.com
-
-**Carl Vitullo:** Yeah, SquiggleConf in Boston is October 3rd and 4th. This is organized by a conference buddy of mine, Josh Goldberg. He is author of a book on TypeScript and just a wonderful, friendly, lovely person. I'm actually going to be volunteering there, so I'll be helping out with making sure the conference goes off. [55:41]
-
-**Mo Khazali:** Yeah. So Josh, I was going to similarly give a big shout out to Josh for being an amazing person. But beyond that, me and him have been bonding. So we spent a bit of time in Amsterdam and we bonded over being first time conference organizers this year. So him and I have been trying to be each other's support group here and they're sending each other some tips and advice. [55:57]
-
-But Josh is, is incredibly well known in the community and he's going to hopefully put together a really, really cool event. So definitely go there if you're in the U. S. [56:05]
-
-**Mark Erikson:** The other organizer, Dimitri, is less well known, but also a wonderful person. [56:10]
-
-**Carl Vitullo:** Yep, I just got to meet Dimitri the other day, uh, talking about volunteering. Seems really cool, seems really lovely. I'm going to brag, I was at the table at React Miami where Josh Ideated the name SquiggleConf, so I was there for the origin. So, very happy to volunteer. [56:26]
-
-### https://www.rendercon.org
-
-**Carl Vitullo:** Overlapping with that, there's RenderCon in Nairobi, Kenya, October 4th and 5th. [56:32]
-
-### https://www.reactindia.io/
-
-**Carl Vitullo:** Then, React India in Goa, India, October 17th through 19th. [56:37]
-
-### https://www.react.brussels/
-
-**Carl Vitullo:** There's React Brussels in Brussels, Belgium, October 18th. I went to that not last year, but the year before. It seemed really great. I got to hang out with the organizer at React Conf in Las Vegas, and just really great dude. Would recommend React Brussels for sure. [56:53]
-
-### https://reactadvanced.com/
-
-**Mo Khazali:** Cool, next up we've got React Advanced London, so this happens around October time every single year in London, so I've been going for a few years now, and the Great React Conference is probably the biggest React Conference that there is in the UK, so definitely head there, I will be there again this year, so if you're around, pop me a message and we'll say hi. [57:09]
-
-## Outro
-
-**Carl Vitullo:** All right, cool. That is everything we've got for today. Thank you everyone for joining us. We will be back on the last Wednesday, even though today is Thursday, uh, last Wednesday of the month to hear on the live stage of Reactiflux or back in your podcast feed just as soon as we can. [57:23]
-
-**Mo Khazali:** Thank you all for joining and listening to us ramble on and chat all things React and React Native. [57:28]
-
-It is always a pleasure and see you all next month. [57:31]
-
-**Carl Vitullo:** We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, the React. js subreddit, and here in Reactiflux. If you see anything that seems newsworthy, uh, that you think we should discuss, just put it in the tech reads and news channel here in Reactiflux. [57:49]
-
-Or, if you like, You can send it to me in an email at hello at reactiflux with T M I R in the subject line, which is a, it's an acronym for the show. I read every email that comes in, including spam because I'm a crazy person. So I will read it even if we don't end up covering it. If this is the show you get value from and want to support, the best way you can do so is by giving a review on Spotify or whatever platform that you actually listen to. [58:15]
-
-Tell your friends, tell your coworkers, we're cool and smart and we can help you sound cool and smart too. You're pretty cool and smart too. See you guys next month. Bye.
diff --git a/src/transcripts/tmir-2024-09.md b/src/transcripts/tmir-2024-09.md
deleted file mode 100644
index 3ac2e84..0000000
--- a/src/transcripts/tmir-2024-09.md
+++ /dev/null
@@ -1,517 +0,0 @@
----
-title: "This Month in React, September 2024: Async Components??, a React 19 cheatsheet, static Hermes, and trademarks drama"
-date: 2024-09-25
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-### New releases
-
-- [[00:57](#node-v2280)] [Node v22.8.0](https://nodejs.org/en/blog/release/v22.8.0)
-- [[01:06](#deno-v2-rc)] [Deno 2.0 Release Candidate](https://deno.com/blog/v2.0-release-candidate)
-- [[01:47](#relay-v18)] [Relay v18](https://github.com/facebook/relay/releases/tag/v18.0.0)
-- [[02:28](#redwood-v8)] [Redwood v8.0.0](https://redwoodjs.com/upgrade/v8)
-- [[04:09](#epic-react-v2)] [EpicReact v2](https://x.com/kentcdodds/status/1838263679025844378)
-- [[04:55](#rspack-v1)] [RsPack 1.0](https://rspack.dev/blog/announcing-1-0) and [Rsbuild 1.0](https://rsbuild.dev/community/releases/v1-0)
-- [[06:20](#metro-08011)] [Metro 0.80.11](https://x.com/MetroBundler/status/1831709057670861260)
-- [[07:52](#effect-38)] [Effect 3.8](https://effect.website/blog/effect-3.8)
-- [[08:43](#astro-415)] [Astro 4.15](https://astro.build/blog/astro-4150/)
-- [[09:45](#react-email-v3)] [React Email 3.0](https://resend.com/blog/react-email-3)
-- [[10:26](#react-native-076-rc2)] [React Native 0.76 RC2](https://github.com/facebook/react-native/releases/tag/v0.76.0-rc.2)
-
-### Main Content
-
-- [[15:08](#bulletproof-react-updated-to-include-nextjs)] [Bulletproof React updated for NextJS](https://github.com/alan2207/bulletproof-react)
-- [[15:52](#new-react-native-debugger)] [New React Native Debugger](https://www.youtube.com/watch?v=b48Lax2-jOQ&t=4350s)
-- [[18:05](#hermes-new-runtime-bytecode-translation)] [Hermes new Runtime Bytecode Translation](https://www.youtube.com/watch?v=pfeTPSai6vc&t=8702s)
-- React 19
- - [[22:14](#react-19-cheat-sheet)] [React 19 Cheat Sheet](https://www.epicreact.dev/react-19-cheatsheet)
- - [[24:10](#whats-new-in-react-19)] [What’s new in React 19](https://vercel.com/blog/whats-new-in-react-19) (moreso a discussion of the evolution of the rendering model)
- - [Build-time Components](https://codehike.org/blog/build-time-components)
- - [You can use async functions for components in React 19??](https://x.com/kentcdodds/status/1831331752343716003)
- - [Core team forgot to put it in release notes??](https://x.com/sebsilbermann/status/1831405742257271202?t=RkXE1h91Ckher4kWUrzWuQ&s=19)
-- [[26:22](#a-milestone-for-typescript-performance-in-tanstack-router)] [A milestone for TypeScript Performance in TanStack Router](https://tanstack.com/blog/tanstack-router-typescript-performance)
-- [[27:46](#weve-decided-to-make-a-few-changes-to-ease-the-adoption-of-next-15)] ["we’ve decided to make a few changes to ease the adoption of Next 15"](https://x.com/feedthejim/status/1829569083777437745)
-- [[30:07](#trademark-disputes)] Trademarks drama
- - From Deno: [JavaScript™](https://javascript.tm/)
- - [[31:46](#wp-engine-v-automattic)] [WordPress](https://x.com/photomatt/status/1838738735795703976) v [WPEngine](https://x.com/justinferriman/status/1838356417482514842)
- - [[33:10](#trademark-diff-seems-targeted)] [Trademark page diff seems targeted](https://www.diffchecker.com/tJ29tGIn/)
-- [[33:49](#youre-writing-a-vite-based-spa-you-need-to-add-a-few-api-routes-ie-for-authentication-what-do-you-do?)] ["You're writing a vite-based SPA. You need to add a few API routes (i.e., for authentication). What do you do?"](https://x.com/aboodman/status/1836470815862460506)
- -[[36:43](#mos-talk-at-future-frontend-2024)] Mo at Future Frontend: [Dynamic UI at the Edge](https://youtu.be/BRce-DHEoNc?si=AsVqdVrxbiO9nyW9)
-
-### ⚡ Lightning round ⚡
-
-- [[39:03](#nitromodules-released-to-the-public)] [Nitromodules released to public](https://mrousavy.github.io/nitro/)
-- [[39:31](#nodejs-adds-an-experimental-permission-model)] [NodeJS adds an experimental permission model](https://twitter.com/liran_tal/status/1830621784770555915)
-- [[40:54](#typescript-with-react-styleguide)] [TypeScript Styleguide](https://mkosir.github.io/typescript-style-guide/#appendix---react)
-- [[43:05](#inside-ecmascript-javascript-standard-gets-an-extra-stage)] [Inside ECMAScript: JavaScript Standard Gets an Extra Stage](https://thenewstack.io/inside-ecmascript-javascript-standard-gets-an-extra-stage/)
-- [[44:34](#remix-the-web-from-mjackson)] [The Neverending Story](https://garrettdimon.com/journal/posts/the-neverending-story)
-- [[44:34](#remix-the-web-from-mjackson)] [Remix The Web from mjackson](https://github.com/mjackson/remix-the-web/)
-- [[46:42](#replacing-react-code-with-css-has-selector)] [Replacing React code with CSS :has selector](https://www.developerway.com/posts/replacing-react-with-css)
-- [[48:19](#performance-optimization-strategies-for-large-scale-react-applications)] [Performance Optimization Strategies for Large-Scale React Applications](https://old.reddit.com/r/reactjs/comments/1f6abzy/performance_optimization_strategies_for/)
-
-### Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-- [SquiggleConf](https://2024.squiggleconf.com) Boston, MA USA Oct 3-4
-- [RenderCon](https://www.rendercon.org) Nairobi, Kenya Oct 4-5
-- [React India](https://www.reactindia.io/) Goa, India Oct 17-19, 2024
-- [React Brussels](https://www.react.brussels/) Brussels, Belgium Oct 18
-- [Next.js Conf](https://nextjs.org/conf) SF, USA Oct 24
-- [React Advanced London](https://reactadvanced.com/) London, UK Oct 25, 28
-- [HalfStack London](https://halfstackconf.com/london/spon) London, UK Nov 13
-- [React Native London](https://www.reactnativelondon.co.uk/) London, UK Nov 15
-
-**Carl:** Hello, everyone. Thank you again for joining us for the September edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live in Reactiflux, the place for professional React developers, and we're supported by Infinite Red, a little bit more on them. I'm going to do something different this month. I'm going to do the ad read after our You know, quick hits at the start. [00:21]
-
-Hello, I'm Carl. I'm a staff product developer and a freelance community manager here at Reactiflux, uh, where I run community programs like these events and help keep the community operating. [00:31]
-
-This month we don't have Mark, sadly. He's in Turkey, um, I think. Not sure if he did a conference, but he just couldn't swing it this month. [00:37]
-
-**Mo:** And I am Mo. I head the mobile team at Theodom. I'm quite active in the React Native ecosystem. Get very involved in a bunch of different conferences and some open source here and there. [00:47]
-
-I organize the React Native London, community. And basically oversee a team of different developers who are specialized in React Native. So, happy to be here to chat, as always. [00:56]
-
-**Carl:** All right, straight into some new releases. [00:57]
-
-## [Node v22.8.0](https://nodejs.org/en/blog/release/v22.8.0)
-
-**Carl:** We've got Node version 22. 8. I didn't see anything super big that caught my eye in this change. New Node, minor version released. [01:06]
-
-## [Deno v2 RC](https://deno.com/blog/v2.0-release-candidate)
-
-**Carl:** We've got Deno v2 release candidate coming out. It looks like this is coming out in Continuing the trend over the last couple months that we've discussed of Deno kind of walking back some of its opinions, they have gone pretty hard on Go style dependency management and a couple of other Go and other highly opinionated back end languages. [01:25]
-
-They're kind of walking those back. Stuff like, they had been Encouraging people to use window instead of process. They are changing that in order to be more compatible with existing NPM modules. Just generally be more compatible across the ecosystem. Yeah, a couple of other things like that too, like making it easier to use with NPM. [01:41]
-
-Generally making it more compatible, which I think is why they're walking back some of their highly opinionated opinions. [01:47]
-
-## [Relay v18](https://github.com/facebook/relay/releases/tag/v18.0.0)
-
-**Carl:** We've also got Relay version 18. Are people still using Relay? I don't really have a good sense for its, I don't know, usage. I know, obviously, Facebook still uses, Meta still uses it, but, yeah, not sure how much community uptake it's had over the last three or so years. [02:01]
-
-**Mo:** Not much on our side. [02:03]
-
-**Carl:** But a change that should make it a little bit easier for people to start using, they have added IntelliSense for the Relay config file. Just getting started, I've tried to get started with Relay two or three times over my career, and just never got over that initial hump of figuring out how to get it working. [02:17]
-
-So, uh, maybe some stuff like that will help. Make it a little easier to use. Not having used it, I can't really speak to the other changes they have, but you know, improve validation of argument types, an alias, catch, throw on field error. Cool. [02:28]
-
-## [Redwood v8](https://redwoodjs.com/upgrade/v8)
-
-**Carl:** There's also Redwood with a major release, version 8. Redwood is sort of trying to be the Laravel of the React ecosystem, sort of an all in one framework that does all the things that you need. Instead of making you find all the packages yourself to glue the bits together, which seems pretty cool. Yeah, this major release upgrades a lot of dependencies, adds Docker support, which I was a little surprised to see. I, I think of Docker support as not something a framework needs to, like, explicitly add, but cool. [02:53]
-
-I guess maybe they're making it a little bit easier to just get running in that environment, which since Docker is such a widely used primitive, that makes a lot of sense. Seems cool. They talk about an experimental SSR and RSC setup, so if you're doing server side rendering, or if you're interested in server side rendering and server components, might be, should be easier. [03:12]
-
-As well as adding support for background jobs, which is definitely something that an all in one framework, I think, I would expect to provide. So that's cool. [03:20]
-
-**Mo:** The Docker support is really interesting because It's almost in direct, I want to say, almost opposing to how Next does it, which it seems to me like Docker is like, hey, you have a Docker image and you can basically use it to deploy your full stack web app into, into whatever cloud platform you want to use. [03:38]
-
-Super easy, primitive, that's agnostic to whatever cloud provider you want, you self host it, you scale it up yourself, however you want, and our batteries included framework will just work. Whereas Next is notoriously difficult to be able to, uh, self host. So I just find that interesting. Maybe it's directly done as sort of a distinguishing factor compared to Next. [03:55]
-
-I don't know, but I find it quite interesting. [03:57]
-
-**Carl:** Yeah, makes sense. I have preferred to host anything I do in Docker for most of the last 10 years, so it's, that will make it easier. I'm interested in trying out Redwood, so having it better support my preferred environment will definitely help with that. [04:09]
-
-## [Epic React v2](https://x.com/kentcdodds/status/1838263679025844378)
-
-**Carl:** There's a new release of Kent C. Dodd's Epic React, version 2. The overview of the course, it's going to teach you React fundamentals, hooks, advanced APIs, suspense, advanced patterns, performance, and server components. I was a little surprised I couldn't easily find like a diff of what is being covered and what they're focusing more on, uh, between the old version and the new version, which I had been hoping to see. [04:33]
-
-I have not bought it. I consider myself an epic React dev already, so I don't feel like the target audience. But yeah, they're doing a 40 percent off promo right now, so if you have an educational budget at work, definitely consider spending some of it on this. it's about 420 right now. Nice. [04:48]
-
-Full price is 700, and I think it's jumping up there in about two weeks from time of recording, which is on the 25th. [04:55]
-
-## [RsPack v1](https://rspack.dev/blog/announcing-1-0)
-
-## [RsBuild v1](https://rsbuild.dev/community/releases/v1-0)
-
-**Carl:** Some kind of big news. RS Pack and RS Build both released 1. 0 in the last month, about two weeks apart. RS Build is like a Rust based build tool, if you have not paid attention to previous episodes where we've discussed it. [05:10]
-
-A decent amount. And RSPack builds on top of that to provide a Webpack compatible bundler. I feel like this was all the way back to like 2014 15 when Webpack was new. I mean, Webpack really replaced tools like Gulp. I think I went straight from Gulp to Webpack, and it was a massive just step change improvement. [05:28]
-
-It was clearly better in just doing everything. Uh, but It was really complicated to configure, uh, not the fastest tool. So like, almost immediately people were talking about ways to make it faster, ways to make it do the great things that it did in a better manner. I feel like, uh, especially in the web ecosystem, we love our tools to be fast and snappy. [05:50]
-
-so a counterpoint to that, people have been interested in having a faster, better solution than Webpack, but the flip side is that Webpack does so much that it's just really hard to actually make a replacement. So I feel like this is a culmination of like a decade long process. [06:05]
-
-project to produce something like that. So to get a Rust based natively compiled language build tool that provides drop in compatibility with an existing massively complex, massively used tool. Awesome. Seems really cool. [06:20]
-
-## [Metro 0.80.11](https://x.com/MetroBundler/status/1831709057670861260)
-
-**Mo:** So, speaking of bundlers and staying on the same thread, as you will know, React Native has its own bundler that, uh, is purpose built. [06:28]
-
-or the use of React Native apps. Um, and it's called Metro. So, Metro just released a more of a patch than a minor although React Native's versioning is a little bit confusing because everything is a minor because they want to be able to do as many breaking changes as possible, but they released a patch and there was some insane performance benefits here, so They took the resolver step, which was a bit slow within Metro, and they made it around 15 percent, sorry, 15 times faster, and that made a massive difference. [06:56]
-
-So when they ran it on the, uh, Expensify app, which is notoriously a large scale, open source React Native app, the total build time, was brought down from around 13 seconds down to about 3. and that's about 4 times faster for the whole build process, right? So resolving is just one step of it, they've made that significantly faster, but that makes a big impact on the overall build time. [07:16]
-
-And so this is really cool, but one of the added benefits of this is because it's, it's, it's a, it's a patch here, it's actually not a breaking change at all. So you can use it 3 versions back, 3 major React Native versions back, and it kind of works. So all you need to do is just bump your dependencies and you'll get the faster resolving times, which is really cool. [07:34]
-
-So big shout out to the Metro team, specifically, uh, Rob Hogan's been working on this. They did a really good job, and hopefully it just makes our dev tools a little bit faster, which we all love. [07:42]
-
-**Carl:** Yep, yeah, right. Like I just said, we love our fast dev tools in the web ecosystem. Cool. 15 times faster in a patch release. That is rare. Very cool. [07:52]
-
-## [Effect 3.8](https://effect.website/blog/effect-3.8)
-
-**Carl:** Wish I could say more about this, but Effect has released version 3. 8. Cool. Effect seems really cool, but it's also got a really steep learning curve because it's basically an entire new, like, standard library and programming paradigm all at once. It seems really cool. What I've seen in it, it seems to take a lot of inspiration from functional programming tools like languages and environments like Elixir. [08:15]
-
-Just encouraging you to build more like composable APIs? Yeah, we, again, we've talked about this a little bit in the past, so it, I, I won't fully rehash everything, but it's a huge, massive, steep learning curve that seems really cool and possibly worth it. So it's, you know, it's, I feel like I say this so many times every episode, but this is something that I'm really curious about, learning more about and using more and yeah. [08:39]
-
-if you like functional programming in web, definitely. Consider looking at effect. [08:43]
-
-## [Astro 4.15](https://astro.build/blog/astro-4150/)
-
-**Carl:** We've got Astro 4. 15. Big change, they say that Astro actions are stabilized. Um, and it looks like they've swapped out how those actions are configured so that it's a little bit more concise. [08:54]
-
-Uh, you describe the shape of the data that it receives and what to do with that data when you get it. Rather than treating it like a whole request where you then, like, do the validation and the error handling yourself. That's adding some opinions to it, but doing a validation schema and then providing a handler that receives valid data that conforms to the schema that you provided. [09:16]
-
-Seems like a pretty solid abstraction point there. There's also some other things like, the astro islands pattern. you could previously configure it to load those islands asynchronously, idly, when the, when the tab is idle. Uh, and they've now added a timeout so you can set a maximum time that it will wait for your page to go idle. [09:36]
-
-Uh, which seems like a nice, you know, 99th percentile performance improvement. If, if, if you're on a slow device that never goes idle, that's going to cause problems if you're only loading when idle. [09:45]
-
-## [React Email v3](https://resend.com/blog/react-email-3)
-
-**Carl:** So we've also got a new major version of React Email, uh, version 3. 0. Looks like this is another, you know, release getting ahead of React 19. [09:54]
-
-They have swapped out their rendering. So it's now async by default. as well as adding a new component library, improving performance. They added a superbase integration so that you don't have to manually, like, render and then copy the output into superbase, which seems nice. I'm a little surprised to see a new component library here, but I guess in an email environment there are just so many ridiculous constraints that, uh, I guess it makes sense that you need a specialized component library for that environment. [10:20]
-
-But yeah, uh, React Email, if you're doing anything with emails, that seems like a pretty solid tool to use. [10:26]
-
-## [React Native 0.76 RC2](https://github.com/facebook/reactv0.76.0-rc.2)
-
-**Mo:** So, I've kind of stuck the next one in. It's not really a release, but it's a release candidate, so it's kind of a blurred line, but we'll just go with it. The second release candidate of React Native 76 is out. [10:38]
-
-So, when I say, for those who aren't in the React Native ecosystem, when I say 76, I mean 0. 76. It's just, it's so far up that we've just We just get rid of the zero because it's easier to say. But anyway, React Native, 0. 76, Release Candidate 2's out. Um, now, this will still take a few more weeks, at least, to, to land, but, this version of React Native is going to be, quite monumental because the new architecture will be the default. [11:02]
-
-Going forward from this version. Now this new architecture is nothing new. It's been around, it's been talked about for years now. Um, contrary to the name, uh, it was new a while ago. Um, but it was a, it was a massive undertaking because you're basically gutting the internals of React Native, replacing it with React. [11:18]
-
-Something that's totally different in terms of how the native layer is handled. And so you're needing a new rendering engine, you need a new way to interact with native code and the native APIs. And so what that's meant is that this, it's had this long tail of getting library maintainers, 3P libraries, and, and, All of these things ready so that app developers don't have that much of a pain with some of their libraries not working if they switch over to the new architecture. [11:43]
-
-And so hopefully it's going to result in a lot more stability, some performance gains. We're waiting to see, but this is going to be a big release and you can still use the old architecture, but new one is the default. And it will be going forward. So, very exciting times, very monumental times. It's probably going to come with some teething pains as it does when you do such a major rewrite, but we're keeping our fingers crossed. [12:02]
-
-They've put a lot of work into this. [12:04]
-
-**Carl:** For sure, yeah. And as we've discussed many times on here, especially Mark, nobody tries really as candidates. So if you're using React Native, just At least give it a shot. See if there's any, like, obvious failure points, because, uh, open source maintainers love hearing about those growing pains as you're trying to switch over. [12:20]
-
-This is a great opportunity to do it. We're RC2. We're running out of candidates. [12:24]
-
-## Sponsored by Infinite Red
-
-**Carl Vitullo:** We are brought to you by Infinite Red, our main sponsor right now. They are an expert React Native consultancy that I am quite pleased to be a partner with because they are like authentically showing up to support the React Native and React ecosystems in like really meaningful ways. [12:40]
-
-They organize conferences, they host the largest React Native podcast, they publish the largest React Native focused newsletter, and they're Just really excited to work with them. Other than being great people who do great things in the community, they also, well, more precisely, they're a team of about 30 people, mostly developers with mostly greater than 10 years of experience. [13:01]
-
-So they actually work with your team to help you develop an expertise in building React Native. So if you are. Building something with React Native and need a little help hitting the ground running on that, definitely reach out to them because they are great people who will help you do good work. [13:17]
-
-## Upcoming conferences
-
-**Carl:** Moving on to some upcoming conferences. There's a lot, so I'm gonna just do, like, half of these, because we're already 15 minutes in. Mark and I will both be at SquiggleConf in Boston, Massachusetts, October 3rd and 4th. it's organized by a conference buddy of mine, Josh Goldberg. [13:32]
-
-I'm looking forward to it. It should be, should be a great time. It's going to be at the Aquarium in Boston, which seems great. there's also going to be RenderCon in Nairobi, Kenya, October 4th and 5th. React India is in Goa, India, October 17th through 19th. And React Brussels in October, uh, 18th, Brussels, Belgium. [13:51]
-
-There's also Next. js Conf in San Francisco on the 24th of October. [13:55]
-
-**Mo:** And then, if you're in London, ReactiveLabs London is happening on the 25th of October for the in person day and the 28th of October for the remote day. I will be there. I'll be doing a talk about React Native there, so if you're around, come and say hi. [14:07]
-
-**Carl:** Uh, I think Mark will be there too. Sadly, I will not. I will be in Mexico City, having a great time. There's also Halfstack London in London on November 13th. [14:16]
-
-**Mo:** And then this is the announcement that I've been waiting a long time to make on this conference, but we have the two month rule, so we're trying to remain impartial. [14:23]
-
-We are doing the first ever React Native conference in London. So, RNLConf, React Native London conference, effectively, is happening on the 14th and 15th of November. in London, central London at the Brewery, which is this like old building from the 1800s, uh, where a bunch of the monarchs of the UK went and visited, and it was a big festive place. [14:42]
-
-Anyway, it is now an events venue that we have gotten, and we're gonna have a lot of core people from the React Native ecosystem there. Charlie Cheever, the founder of Expo, is gonna be there. we have a lot of different cool folks from Meta, from Amazon, and from a bunch of different places coming to share. [14:54]
-
-Ideas and talks with everyone. If you are interested in joining, we have also, I've just made a discount code for anyone who listens to the podcast, so it's TMIR. Feel free to just grab a ticket that way, and hopefully you'll save a little bit of cash as well. [15:05]
-
-**Carl:** All right, into our main content. [15:08]
-
-## [Bulletproof React updated to include Next.js](https:/bulletproof-react)
-
-**Carl:** Bulletproof React got updated for Next. js. This is a simple, scalable, and powerful architecture for building production ready React applications, it describes itself as. Um, so this, I guess it's a set of example apps, to help you get started. I wanted to call this out because it seems like a pretty good resource. You know, it's a question we get in, you know, Reactiflux all the time. [15:30]
-
-It's like, hey, where can I find a, production grade application to use as a reference? I want to learn. I want to learn more about how they do it. and yeah, this seems like a good resource. It's, it's a whole ass. They have an example app written in a couple of different frameworks, so they have updated it to use the app router, I believe, and yeah, seems like a great resource. [15:52]
-
-## [New React Native Debugger](https://www.youtube.comt=4350s)
-
-**Mo:** Cool. So, this month we had React Universe Conf happening in Wroclaw in Poland. I was there hosting the conference and there was a lot of React Native stuff that was announced. now they were kind of s I want to say soft announcements in some capacity because people kind of knew about them already. It wasn't anything like mind blowingly new, but it was really cool to see the output of a lot of hard work that people have been anticipating for a while. [16:14]
-
-So the first one was the new React Native debugger. just a little bit of context on some of this. Debugging in React Native has been a pain. Anyone who's built with React Native knows that, like, debugging has been a mess. Like, you could use a bunch of different tools in conjunction with one another. [16:29]
-
-Some of them worked for certain things, other ones worked for other things. there was a point where, you know, you used Flipper for a while, and Flipper wasn't great. everyone really did not like Flipper, and so it got deprecated because it was just not really usable. so it was a lot of different tools that you needed to have in your tool belt to be able to effectively debug. [16:45]
-
-the new, the team at Meta tried to kind of, go from a fresh blank slate and say, hey, how do we build a really good debugger that resembles some of the experiences that people are used to with other frameworks and other other languages? And so they built a completely new debugger that's fully built on the Chrome DevTools protocol. [17:00]
-
-And it looked like it was, from what we saw at the conference talk, it looked like it was a lot more reliable. It addressed a lot of the minor pain points that you felt when you were trying to debug. And I guess the big thing was that we finally have reliable breakpoints. Which was a real pain to get working within React Native. [17:16]
-
-So, really, really, exciting stuff to, to, to get. And it should be public soon. So we're excited to get, get our hands dirty with it and, uh, and try it out. [17:25]
-
-**Carl:** Getting into the Chrome debug protocol seems like such a massive improvement here. Instead of using some kind of like bespoke debugging system, I love that you can just actually tap into a widely used tool that a lot of people are familiar with. [17:38]
-
-**Mo:** And it makes sense in terms of the direction that, you know, React Native is going, which is they want to make it more friendly for the web devs to be able to come in and build native mobile apps, right? So you don't want to force React web devs to learn a totally new dev tool framework or a model. You just use the tools that people are familiar with. [17:55]
-
-And so I think it was a great choice, and it looks good. So we'll wait for it to come into the hands of all of us, and then we'll play around with it and make it better over time, and it'll be a great time. Oh, yeah. Cool. [18:05]
-
-## [Hermes new Runtime Bytecode Translation](https://wwwv=pfeTPSai6vc&t=8702s)
-
-**Mo:** So more stuff from React Universe Conf. Another announcement, almost like a thing that we saw into, was, Hermes, which is the JavaScript engine that's used with React Native on most apps, now has a new runtime sort of bytecode translation. [18:19]
-
-Now it's very complicated and complex, and the talk explains it far better than I do, because it's some really low level stuff, so you kind of need to wrap your head a little bit around assembly and some, some stuff like that. A little bit of context, just to contextualize this, I think helps. last year there was a talk by the Hermes team at React Native EU called, uh, talking about this, this new concept of Static Hermes, which was, could we take JavaScript code and, uh, Make it typed native code, and sort of compile that down so that you get near native, if not just native performance, using C Um, and so that was a really cool concept, and the benchmarks that they ran from their early tests was showing that it was massively faster to execute JavaScript code because you were basically executing native code there. [18:59]
-
-it was a really cool approach of, you know, How you bypass the restrictions of JavaScript's runtime. But there were some limitations in the sense of how people use React Native in practice. And, you know, people use a lot of different features like over the air updates, which means you can kind of replace your JavaScript bundle. [19:17]
-
-with a server and add new code to a mobile app without going through an app store. So that's like a big feature that a lot of people use in React Native. And so this wouldn't work with the current model of static Hermes. a lot of different build tools. when you, when you pass your code through something like Babel, it loses the type annotations. [19:32]
-
-So how does that then get compiled down to, you know, typed native machine code. It was hard to really wrap it into the ecosystem and how people are using and developing React native apps. So, Intermediately, the Hermes team's been working on sort of runtime bytecode translation, which means, Okay, well, if we can't do this at compilation time, could we? [19:52]
-
-Find ways to boost performance at runtime and compile things to native instructions without needing to necessarily rely on things that you might only have at compilation time, like your type annotations. whilst being able to still let people do things like over the air updates. And so that's this. [20:08]
-
-concept of the runtime bytecode translation. This isn't landed anywhere and it will take a long time. It will probably first go through Meta's internal process of testing and seeing how it works within their apps. And then if it's stable, it'll phase, in a phased approach, get drip fed to the rest of the community. [20:24]
-
-So it's going to take a little bit of time, but it's really interesting stuff and it can have massive performance gains when you're running really computationally heavy tasks that you would previously run in JavaScript, using this bytecode translation. [20:35]
-
-**Carl:** Interesting. Okay. So I remember Hermes. That's like, that was like a V8 competitor. It was a runtime for JavaScript optimized for React Native. So it sounds like this is going to be doing. Like, you know, all these JavaScript runtimes, they always have various levels of, JIT, just in time compilation happening. I remember, you know, V8 has like TurboFan, and I don't remember any of the other brand names. [21:00]
-
-But, okay, so this is sort of a new type of JIT sort of thing, where it, like, over time will create a I don't know, like codify the bytecode so that it doesn't need to do the JIT every single time? Is that, am I understanding that right? [21:14]
-
-**Mo:** That's what it seems like to me. Again, there's a blurred line between static release that happens at compilation and this, which is kind of JIT. [21:22]
-
-And this is a little bit, there is some level of caching that you can do, right, because those instructions don't change commonly. They're changing once every time you kind of do an over the air update. So, um, a lot is still unknown. it's just more, showing the possibility of if you have unannotated JavaScript code, how much could we, compile it down to bytecode and still get some of the performance gains that you can get out of something like Static Hermes. [21:46]
-
-Which would be a lot more aggressively, compiling things down and, and it has a lot more context because of having access to the source code and being able to run this at compilation. So it's a more practical step that they're trying to address with how the community uses React Native and how probably Meta uses React Native internally as well. [22:03]
-
-**Carl:** That makes sense. My mental model here is aggressive caching of JIT bytecode. Definitely will be curious to see how that shakes out as it starts to roll out. Exits idea stage and enters production stage. [22:14]
-
-## [React 19 Cheat Sheet](https://www.epicreact.dev/react-19-cheatsheet)
-
-**Carl:** All right. A bit of stuff on React 19. Man, I'm a little sad Mark isn't here today because there's a couple of new resources and some, some new info that I'd love to get his take on. [22:23]
-
-But yeah, so Kent C Dodds put out a React 19 cheat sheet and it looks pretty great. You know, even just kind of casually skimming this, I learned several new things that I hadn't realized. Even, even as someone who considers himself to put a decent amount of effort to stay on top of things as they happen. [22:40]
-
-I still learned about like four or five new things from this cheat sheet. Probably the single biggest one is that since when could we use async functions? Like we apparently in React 19 you can do if you know you're doing a function component like you do now you can just mark that as async and it will return a promise like async functions do and React just like knows how to handle that. [23:01]
-
-That makes a lot of sense. I am curious how that, I guess where I really wish I had Mark to talk about. This instead of me is, I don't really understand the difference between the suspense primitive of like throwing a promise versus now this where you can just return a promise. Yeah, this is a really great single page cheat sheet, you know, eight and a half by 11 with a bunch of great resources. [23:25]
-
-You know, it talks about like what the use hook is for, talks about the better error reporting, resource preloading APIs, so you can make sure that You know your fonts and your images are available. Loading style sheets with precedence. Uh, I, something I had known was that React 19 will let you render like scripts and style sheets just within your output and it will hoist them up to, you know, be Loaded as appropriately, something I didn't know is that you can signal their precedence, their relative precedence. So, you know, default precedents or high precedents. This is, this is a base level style sheet that needs to apply to everything versus this is a, you know, could override those base styles, things like that. Really great resource. Kent C. Dodds, of course, putting out lovely educational resources. [24:10]
-
-## [What’s new in React 19](https://vercel.com/blog/whats-new-in-react-19)
-
-**Carl:** There's also a great, What's New in React 19 blog post put out by Vercel. Mostly the bulk of the content talks about how the rendering model for React has evolved over the years. Uh, I thought this was just a really great breakdown of why. [24:25]
-
-We've gone from why React is pushing server components and like what the value proposition there is. It has a really great series of diagrams showing like, all right, this is how, this is how data fetch and resource loading happens in a single page application versus an SSR application versus now what React server components unlock. [24:47]
-
-And just showing like the data flow of like server to client. And it really does a good job of illustrating those waterfalls and how those waterfalls end up hap end up being imposed by the rendering model and how server components change that rendering model to enable fewer waterfalls to happen. another good resource talking about new things unlocked. In React 19, there was a good post talking about build time components, which is distinct from like server side rendering or server components, pretty related to like, you know, SSG, static site generation. Yeah, static site generation. [25:22]
-
-If you say that acronym SSG, the presumption is that that refers more to something like Gatsby, which is a one time, it doesn't have a server, it has static generation. so this, this discusses build time components, I think sort of as a complement to server rendering or server components, where as part of the build step, as part of, you know, your transpilation and compilation and whatever, you can statically generate. [25:47]
-
-Some of your, some of your resources, some of your pages, some of your components. I thought that was a good call out as new technical capability. Returning back to my earlier thought on the cheat sheet, I saw in real time Kent C Dodds learning that you can return a Promise from a component. So just like earlier this month, he put out on Twitter like, oh, you can, you can just do this. [26:08]
-
-You can just mark it as async. Amazing. So just to drop the link to a good thread in there, but really good. I'm not sure what the difference is between that. You know, classic suspense, throwing a based thing and just doing an async function. [26:22]
-
-## [A milestone for TypeScript Performance in TanStack Router](https://tanstack.com/blog/tanstack-router-typescript-performance)
-
-**Carl:** Moving on. TanStack had a really great post discussing a performance optimization they did for TanStack Router. [26:29]
-
-This is a very different type of performance optimization than most that we see discussed. This is not like runtime performance. This is not, you know, how the library works while you're using it. This is an optimization they did in your editor. So like, as your site grows larger, because their routing is type safe, it's actually doing a lot of, it's actually throwing a lot of work at the language server, at the TypeScript language server that your IDE is running. [26:56]
-
-In this blog post, they break down a pretty complicated site that has, I think they say, This example has 400 route definitions with validated search parameters, and I, you know, it takes like three seconds for the language server to get back to you. So, like, if you're writing code and you, like, open IntelliSense to see, like, oh wait, what, what query strings can this receive? [27:17]
-
-Like, sitting and waiting for three seconds as it parses that. Not great. but yeah, they talk about improvements they did for that. And just because, like, type safe routing is super cool and super difficult, and like, how often do you think about the performance of the TypeScript language server in your IDE? [27:34]
-
-For me, never. so just seeing this, like, Deep technical write up of how they've improved the performance of something that I have never thought about is pretty great, pretty interesting. [27:46]
-
-## ["we’ve decided to make a few changes to ease the adoption of Next 15"](https://x.com/feedthejim/status/1829569083777437745)
-
-**Carl:** Cool, an update on Next 15, which is not out yet. Yeah, they said, we've decided to make a few changes to ease the adoption of Next 15. [27:54]
-
-We'll relax the React 19 requirement for the Pages router so you can upgrade in your own time. I appreciated this because my read on the Next. Ecosystem right now is that there's a lot of attention being paid to the app router, but technically that's Bleeding Edge. That's the newest, still experimental grade, kind of. [28:14]
-
-So they encourage you to use it in the same way that open source maintainers encourage you to use release candidates. But strictly speaking, the Pages router is still where the business is. So seeing them talk about sending support for that into React 19 seems good. Bethany, for the app router, we decided not to block on the general release of React 19. [28:34]
-
-So I guess that they are looking to release. Finished non-experimental app router, before or, or they're decoupling released app router from the React 19 release. [28:45]
-
-**Mo:** Does that mean that they would ship the app router apps if you start a new app, router app with Next, that it would just be using like an RC of React 19, or would it just be using React 18 unless re 19 gets launched? [28:59]
-
-**Carl:** There was some confusion a while ago because they were using release candidates by default. Uh, I don't remember where that landed off the top of my head right now, but I think that's right, but I can't answer you definitely. I'm just looking at this thread again and I see someone ask a very similar question. [29:15]
-
-How do you relax the React 19 requirement when React is bundled into Next? Do you maintain a release for 18 and 19? Did not get a response, so not sure. This is kind of continuing the trend of version confusion with Next and React, like, it's not very clear. [29:33]
-
-**Mo:** I wouldn't personally feel comfortable using an RC with Next, if, Next 15, if they say, we've tested it, it's stable, but then at the same time, I wouldn't trust it to work well with React 18 either, because I would suspect they haven't tested that enough. [29:46]
-
-So, you're in this no man's land where you're like, do I just stay on Next14 until it's actually, you know, stable and React 19 is launched and out of our seat? Interesting questions. [29:57]
-
-**Carl:** Yeah. Confusing, but a similar, you know, vein of confusion as we've had for like most of 2024. That confusion has not been cleared up. Confusion remains. [30:07]
-
-## Trademark disputes!
-
-## [Oracle, it’s time to free JavaScript](https://javascript.tm/)
-
-**Carl:** There's been a couple of trademark dramas this month. Like, I don't know why all the trademark stuff is coming out of the woodwork right now, but um, the Deno team put out a, like an open letter requesting that Oracle release the trademark for JavaScript. and this is one of those like, Funny, weird like quirks of history that not that impactful, but it is still a thing. [30:27]
-
-Like Oracle owns the trademark for JavaScript. Like the reason that the TC39 standards body that determines what JavaScript is technically They are not building JavaScript. They're building ECMAScript, which ECMA is an international standards body. And the reason it's called that is because Oracle owns the trademark on JavaScript. [30:47]
-
-And they have done nothing with it. They have not enforced it, as far as I know, in a decade. They have not They haven't done anything with it. So, yeah, the Deno team is asking people to sign a letter. so, I would encourage you to do so. I have signed this letter. I think it's great. I would love for Oracle to be less in the web ecosystem. [31:04]
-
-Please. [31:05]
-
-**Mo:** I don't think I knew that Oracle had the trademark for JavaScript until I saw this. I don't know if you did, but it was, uh [31:11]
-
-**Carl:** I did know that. I mean, it's one of those stupid things. Like, it's called JavaScript because they were trying to, like I don't know. Ape on the popularity of Java back in the 90s, even though there's no relation. [31:23]
-
-So it's like, I think because I, I think it was something like in those early days, Oracle was like, no, no, no, no, hang on. You can't call it JavaScript. We own Java. And so I think that's how they ended up owning it, but then they didn't do anything in JavaScript or in the web because they're Oracle. And yeah, so it's just one of those like weird quirks of history. [31:40]
-
-So this feels like writing a wrong to me in a way that like, yes, please, let's resolve this tech debt, like get out of there. [31:46]
-
-## [WP Engine v Automattic](https://x.com/photomatt/status/1838738735795703976)
-
-## (https://x.com/justinferriman/status/1838356417482514842)
-
-**Carl:** And this is a little far afield from React, but there's been some WordPress drama. my, I don't do WordPress. I've never worked as a WordPress developer. So this is a little bit of me catching up on stuff. [31:59]
-
-But so my understanding of this is that there's. the WordPress maintainer is Automatic with two T's, and then there's a, another company called WP Engine that seems to, I think they're like a services business, I think, so I guess it's, it's a little bit like If there were two Vercels, like an official one that was actually maintaining Next, and then another one that, like, didn't actually do very much of the maintenance, but also provided all of the same, like, hosting, just with a different set of defaults. [32:26]
-
-And if that other actor that did not do all the maintenance work and the development work was making way more money than the people actually building on it. So, that's my understanding of the difference between Automatic and WP Engine. Is that WP Engine makes a lot more money and contributes less. so the CEO of Automatic has gone on a bit of a tear and it seems not great to me. [32:48]
-
-They are now accusing WP Engine of like infringing on the trademark of WordPress by way of introducing confusion. Like people think that WP Engine is, you know, WordPress engine and they think that they play a larger role in the ecosystem than they actually do. But they've done so, Automatic has done this by sending a cease and desist that doesn't, I don't know, it seems not great. [33:10]
-
-## [Trademark diff seems targeted](https://www.diffchecker.com/tJ29tGIn/)
-
-**Carl:** There's, um, the trademark page, I saw a diff, like, just in the last week, like, as they sent the cease and desist, Automatic updated the trademark information page from saying, you can do whatever you want with the abbreviation WP, to you can do anything you want That doesn't add confusion to the ecosystem, and also WP Engine is not great and we don't like them. [33:30]
-
-And so it's just like they specifically called out this organization that they are sending a cease and desist to in updating their trademark guidelines. It's just like, Oh, Oh, okay. I feel like if you wanted to make that argument and you needed to make it 10 years ago when they started. So it's drama, some big drama happening in WordPress right now. [33:49]
-
-## ["You're writing a vite-based SPA. You need to add a few API routes (i.e., for authentication). What do you do?"](https://x.com/aboodman/status/1836470815862460506)
-
-**Carl:** I saw a great. Twitter post from someone who is doing like a sync engines and lots of other like local first type development that I find very interesting. He posed the question, you're writing a Vite based SPA. You need to add a few API routes like for authentication. What do you do? And got a lot of engagement and I thought it was just a really good discussion. [34:11]
-
-I wanted to draw a little bit of attention to it just because a lot of great opinions coming out in there. I have recently been playing with. Cloudflare workers. And to me, they hit this really great niche that is perfect for this. Cloudflare workers are basically like serverless architecture. You, you know, set up a handler, and like, you don't do any of the infrastructure administration yourself. [34:31]
-
-It just, you know, starts up and stops. But they do it way better than anyone else that I've played with so far. Like, you know, I've used Lambdas and some other similar, you know, serverless architecture things, and all of them have, you know, Awful, terrible, brutally bad developer experience. Like, uh, this is a couple years out of date, so I think it's changed, but I don't think it's changed that much. [34:53]
-
-I, I just remember having to upload a zip file into AWS in order to test, in order to deploy changes to a, to a lambda function that I had written. And like, There's no environments, there's no way to say like, this is in test, this is in production, there's no way to test locally. So then like, this entire serverless framework spun up around that to try and make it better, but like, oops, it didn't actually work that way. [35:14]
-
-It didn't, it didn't match functionality, so it didn't serve the purpose. So yeah, I think for me this, the answer to what do you do if you need to add a few API routes is set up Wrangler, and then in locally and use Cloudflare Workers. [35:28]
-
-**Mo:** You stole the words from me, basically, which was I would use Cloudflare Workers for a few reasons, like AWS's serverless model means that you're still managing your infra to some degree, like what region do you place your serverless function? [35:41]
-
-How does it scale? How does it, you know, uh, how do you do API routing? Maybe you'll need to add another layer, with API gateway in front of it. It's not, like, Straightforward. And so Cloudflare Workers for me was like truly serverless because it's just a function that runs close to the users, somewhere on a CDN, and you get access to run some JavaScript somewhere on the edge, which is really quite cool. [36:03]
-
-there's some stuff around, you know, like I think that there's some trade offs, like you can't use Node packages, it's a custom runtime, and you know, if you want to use a specific router, like there is Hono as an example that you can use within Cloudflare Workers to do API routes. Auth is not as straightforward, I'd say. [36:19]
-
-So, like, for small tidbits And, you know, tasks that I just need something that runs without me worrying about it, definitely Cloudflare Workers. And so, shameless plug, I did a talk with, a very close friend of mine, Samuel McLeod, who now actually works at Cloudflare and is on the Wrangler team, so he works directly on Workers, and we were talking about how do you Move your front end code to live on the edge in Cloudflare Workers with minimal effort. [36:43]
-
-## [Mo's talk at Future Frontend 2024](https://youtsi=AsVqdVrxbiO9nyW9)
-
-**Mo:** So it's a, it's a, it's a talk that we did in Finland this year. Um, so, I'll share the link. but basically the gist of this was what if you could just take your use states that you have inside of your app and change it to use server state with a different import from a third party library and it would automatically just pop it inside of a durable object on the Cloudflare Worker environment. [37:02]
-
-And so there's a lot of cool magic and a lot of cool primitives that they've got that lets you build on top of, and I really like it. If I wanted to build a little bit more full fledged, you mentioned Auth as an example, maybe. I quite like Superbase these days. It's relatively simple. You know, you can run Deno functions within it. [37:18]
-
-It also has a database model, which, you know, is managed for you. It's kind of, for mobile devs, I think it's The better Firebase, which, you know, Firebase promised to be the way that you don't have to write back end code for a mobile dev, and then it really wasn't great. and I think Superbase is a little bit nicer, and it's also relational DBs, which I prefer personally, so. [37:38]
-
-It kind of just works. [37:39]
-
-**Carl:** Pretty much the major constraint of a serverless runtime is they pretty much have to be stateless because, you know, they start up and they spin it down. So if you want to persist state, you need to maintain some kind of other infrastructure to, you know, some kind of database or something like that, which like, as soon as you start running your own server for a database or something like that, like, well, why not just put the code on there too? [38:01]
-
-And Cloudflare workers give you both durable objects. Which are interesting and cool, and I haven't played with them very much, because they also have a key value store that is like this. Dead simple. It works basically like local storage with shared context between invocations of your workers, which just like, if I'm doing something small that I don't want to spend like a week setting up new infrastructure and then don't want to have to maintain that over time, like something that I can just forget about for two years and then come back to and go like, what, how, how the hell does this work? [38:33]
-
-Workers. Love it. I guess I should while hyping Cloudflare and workers so much, I should probably mention that they are like basically the only stocks that I individually own that isn't in an ETF, because I like Cloudflare. But yeah, that's, I don't know if I have a conflict of interest, but. [38:50]
-
-**Mo:** That is a vote of confidence, Carl. [38:51]
-
-**Carl:** I'm trying to put my money where my mouth is. Or, you know, now I'm putting my mouth where my money already was. ( both laugh) [38:57]
-
-**Mo:** is this some sort of, like, ramping up stock prices? I don't know. Yes, yes. [39:03]
-
-## [Nitromodules released to the public](https://mrousavy.github.io/nitro/)
-
-**Mo:** There's just a very quick update on NitroModules, which we talked about last month. And so, uh, NitroModules is this way to run faster native code from React Native. [39:12]
-
-And, uh, it's now been released to the public. And so a few people have been playing around with it. William Candillon, who builds React Native Skia and now React Native WebGPU, or WGPU, so to speak, is now using it on his project, and a few other people I know are experimenting with it. So we'll see some cool results, and I think it'll hopefully improve the performance of the React Native ecosystem as a whole. [39:31]
-
-## [NodeJS adds an experimental permission model](https://twitterstatus/1830621784770555915)
-
-**Carl:** Um, Node. js is taking a cue from Deno and they are adding a permissions model. I think this is super cool. I thought the permissions model is something that Deno got right. I think it's just very interesting to, rather than just allow all the permissions that your process has, being able to signal to the process, what this code is going to need to access. [39:56]
-
-Um, I think that's a, I think that's really good and interesting and useful, especially in alternate runtime environments like workers, like serverless environments and things like that. An example where this would be useful. I remember a couple of years ago, uh, someone in Reactiflux set up a little five project allowing anyone to execute code from within the chat. [40:15]
-
-Yeah. Um, so you could just, you know, like, use some chat command with a code block. They had set up a bot that would pull that code block in, execute it, and spit out the output. They were able to do that, I believe, because of Deno's permissions model. Because they could guarantee that the code only had access to this very tight sandbox. [40:32]
-
-You know, if you're running code from arbitrary people in a chat room, that's very dangerous. So you need an effective permissions model. So, um Now we have that. Now Node. js has that. Uh, maybe not relevant for most people, but especially if you are working on something that would allow, or that would benefit from allowing your users to run code, run arbitrary code, Node. js now supports that better, at least. [40:54]
-
-## [TypeScript with React styleguide ](https:/typescript-style-guide/#appendix---react)
-
-**Carl:** This isn't new. I don't think I, I have, no, it's undated. I don't know when it came out. but I just crossed my radar and I like it. It's a TypeScript style guide. they have a, they have a react appendix that I, I thought was pretty neat. And just, I love a good style guide. [41:09]
-
-Another common question in Reactiflux is like, what are the best practices? Well, there's a lot of practices. Some of them are worse than others. Some of them are good generally in all circumstances. Some of them only make sense in a very narrow range of circumstances. [41:23]
-
-So just like, what are the best practices is a very difficult question to answer. And I think this TypeScript style guide does a pretty good job of Outlining a decent range of them. You know, some of them are opinionated, like it talks about project structure and like how to organize your source code and like, okay, there's a lot of ways to do that acceptably. [41:40]
-
-but something in the, you know, the first thing it talks about in the React Appendix is like required versus optional props. And. It calls out props as a discriminated type, which is, it's so good. Instead of having a props object with a bunch of optional values, doing it as a group of different, you know, fully formed Types. Uh, so like, you know, the example they give is like a status indicator. Instead of saying like data, you know, error, status as like optional props, just saying like, no, no, the success status has a status value of success, data with this type, whatever. Then the loading status has, says this That's so much better. Like that is absolutely a best practice. So, um, Good resource, I enjoyed it. it had a couple of, maybe it's just because its opinions align with my own opinions, but I thought it was a really good resource. Definitely recommend it. And also, more generally, on the subject of style guides, I think a style guide is a wonderful resource to bring into your company. [42:44]
-
-Uh, the most effective teams I've been on have had a style guide document that was routinely updated. Just, uh, if. I think it's a really great anchor point for technical discussions. Like, if you have a technical argument with your team about, like, we should not be doing this, this is bad. Argument should have an output in the form of a PR to a style guide. I think that's really great. [43:05]
-
-## [Inside ECMAScript: JavaScript Standard Gets an Extra Stage](https://thenewstack.io/inside-ecmascript-javascript-standard-gets-an-extra-stage/)
-
-**Carl:** Not new news, but a good resource. We've talked briefly in previous months about the TC39 ECMAScript standardization process. You know, there's four stages, you can present an idea in stage one, then if you do X technical work, it gets to stage two. Stage three is like, basically standardized, but it's not shipped yet, and stage four is like, fully shipped. [43:27]
-
-There has been a problem over many years of a lot of things getting stuck at stage two. The transition between Stage 2 to Stage 3, and then like, oh, we found a new problem in Stage 3, so we gotta ship it back to Stage 2. Just like, the delta between Stage 2 and Stage 3 has turned out to be very, very large, in a way that has made it difficult to ship some of these proposals. [43:50]
-
-Just like, If it gets shipped back down to stage 2, that has some problems. So this article from The New Stack just did a really good job of explaining more of that history than the half assed summary that I just gave, and talks about the stage 2. 7, you know, sub stage that they added relatively recently. [44:09]
-
-It sounds like the gist of it is that if you've written tests for your thing, then getting bumped back all the way back down to stage two, like, calls into question the validity of those tests. And stage 2. 7 resolves that problem to make it a little bit clearer about what that means. If you're curious about, you know, if there's like, if there's a, proposal that you've been following and are curious about the standardization process. [44:30]
-
-Um, I just think this is a pretty solid resource explaining the history. [44:34]
-
-## [Remix The Web from mjackson](https://github.com/mjackson/remix-the-web/)
-
-**Carl:** cool. I came across a fun project from Michael Jackson, from the Remix team called Remix the Web. Michael Jackson, Ryan Florence have been so involved in the web React, in the React ecosystem for so long. I have always. I've respected them greatly as people who, like, they don't just try to solve a problem. [44:55]
-
-They try to solve a problem in a way that makes sense, given the primitives available on the web. So it's not just trying to do everything in JavaScript. Like a lot, a lot of Java, a lot of React libraries I've seen, they end up, re solving a lot of problems in JavaScript that you might not need to if you just leaned on the web platform a little bit harder. [45:14]
-
-And some of that is because of aspirational support for React Native. If you solve it in JavaScript, then it can work not on the web platform. So like, there's trade offs to doing that. The trade off is that If you write in JavaScript, like, it's probably going to be slower. It's probably going to be worse in some way than if you can use a native, you know, web platform feature. [45:34]
-
-That is the backstory for why I'm particularly interested in this. So, Michael Jackson is putting together a monorepo of modules that are narrowly scoped to do one thing and do that thing well. An example of this that I remember him talking about Years and years ago, in the context of React Router, is they built React Router on top of a primitive, on top of a wrapper they made around the history API. [45:59]
-
-So it's like, in trying to make a router, they found all of these weird, nasty edge cases around managing history, managing scrolls position, things like that, and found the platform feature to be highly deficient. as a, you know, mode of interacting with that. And so they made a wrapper abstraction around that to make it easier to deal with. [46:19]
-
-And so my understanding is that this Remix the web monorepo project is a bunch of those. So like in, if they find, A rough and grody, web platform feature, they write a wrapper around it, and into this repo it goes. So, uh, I'm interested, it seems curious, it seems pretty cool to me, I have certainly found a lot of platform features that don't do quite what I want, so, uh, I'm, yeah, I'm paying attention to it. [46:41]
-
-Seems cool. [46:42]
-
-## [Replacing React code with CSS :has selector](https:/posts/replacing-react-with-css)
-
-**Carl:** And somewhat related to the idea of solving things with JavaScript, I saw a good blog post titled, Replacing React code with CSS colon has selector. The gist of it is, I'll pull a quote. Until recently, we couldn't select objects in the opposite direction of the CSS cascade. You know, CSS is top down. [47:06]
-
-You can get, you can start from the top and it gets more specific. So you can say, in all of these elements that are under this type of parent, style it this way. But you can't, you couldn't say previously, in this parent, if it has this type of element within it, style it this way. It was a, it was sort of a, you know, unidirectional control flow in that way. You could style descendants based on their parents, but you couldn't style parents based on their descendants. And the CSS Has Selector enables you to do that, which I have run into so many situations where I wanted to do that, and you just can't. You just couldn't. So, uh, you end up having to solve it with JavaScript to like add a little bit of state to communicate whether some element is within it. [47:51]
-
-And yeah, so the CSS has selected something I've been wanting for a really long time, and I really appreciated that. I'm seeing it framed as, here's all the things you can stop doing with React because of this CSS feature. And yeah, it's written by Nadia Makarevic. I hope I'm not mispronouncing that. She also wrote a great book on React as well. Yeah, just really, I really enjoy her writing. She seems like a great writer and seems to pick good topics. I like it. [48:19]
-
-## [Performance Optimization Strategies for Large-Scale React Applications](https://old.reddit.com/r/reactjs/comments/1f6abzy/performance_optimization_strategies_for/)
-
-**Carl:** And last lightning round link, just going to call out a Reddit thread. I've started, I set up a thing to pull in top posts from Reddit into the tech reads and news channel, and it's served us some good stuff. [48:31]
-
-I like it. But yeah, somebody asked the question, somebody asked about. Performance optimization strategies for large scale React applications and it got a decent amount of response. So I just thought that was a good, I just wanted to call attention to a cool thread full of a lot of opinions. It seemed like a good thing. [48:47]
-
-I didn't really see anything that like massively caught my eye as like, this is the right thing to do. But it did get quite a few Lengthy explanations of how some person or another has done performance optimizations at work. Uh, and that was always a big part of my work. My career has always, I've put a lot of emphasis on performance optimizations. [49:08]
-
-Wanted to call that out. Go read it. It's good. [49:10]
-
-## Outro
-
-**Carl:** Cool. Alright, that's everything we got. thank you for joining us. We will be back on the last Wednesday of October here in the live stage or back in your podcast feed just as soon as we can, if that's how you listened. We gather sources from This Week in React, Bytes. [49:23]
-
-dev, React Status, Next. js Weekly. The React js subreddit here in Reactiflux and direct from those publishing articles. usually on Twitter, maybe on blue sky, maybe on RSS feed. Lots of things. If you see anything newsworthy, uh, definitely let us know in the tech News and reads channel of Reactiflux. [49:39]
-
-Or send it directly to me hello@reactiflux.com, uh, with TMIR in the subject line. It's an acronym for the show. I read literally every email that comes in, even the spam. So yeah, if you've got a hot tip, send it to me and I'll read it. if this is a show that you get value from and want to support, best way to do so is by submitting a review on Spotify, which helps us, Rank? [50:01]
-
-I'd say stay in the rankings, but like, we don't rank, so, you know. Or, you know, post it on Twitter, send it to your co workers, stuff like that. Appreciate it. Thanks for listening. [50:08]
-
-**Mo:** Always fun to do this every single month. Thanks, for having me, and hopefully I'll see you all at some point in person, somewhere, maybe at the, uh, RNLConf. [50:15]
-
-Till next month.
diff --git a/src/transcripts/tmir-2024-10.md b/src/transcripts/tmir-2024-10.md
deleted file mode 100644
index 5013bb5..0000000
--- a/src/transcripts/tmir-2024-10.md
+++ /dev/null
@@ -1,751 +0,0 @@
----
-title: "This Month in React, October 2024: React DevTools update, React Native 0.76 (new architecture dropped), Web Components are(n't) the future"
-date: 2024-10-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:56](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- [[01:40](#new-releases)] New releases
- - [[01:43](#react-native-076-proper)] [React Native 0.76 proper](https://reactnative.dev/blog/2024/10/23/release-0.76-new-architecture)
- - [[01:54](#new-architecture-is-here)] [New Architecture is here](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here)
- - [[05:18](#bluesky-and-expensify)] [BlueSky](https://github.com/bluesky-social/social-app/releases/tag/1.92.0-na-rc.2) and [Expensify](https://blog.swmansion.com/sunrising-new-architecture-in-the-new-expensify-app-729d237a02f5)
- - [[06:22](#react-compiler-beta)] [React Compiler Beta](https://react.dev/blog/2024/10/21/react-compiler-beta-release)
- - [[07:23](#react-devtools-v6)] [React DevTools v6](https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#600)
- - [[07:50](#zustand-v5)] [Zustand v5](https://github.com/pmndrs/zustand/releases/tag/v5.0.0)
- - [[08:17](#eslintpluginreacthooks-v5)] [eslint-plugin-react-hooks v5](https://github.com/facebook/react/releases/tag/eslint-plugin-react-hooks%405.0.0)
- - [[08:45](#announcing-deno-2)] [Announcing Deno 2](https://deno.com/blog/v2.0)
- - [[08:45](#rbun-deno-2-vs-bun-what-are-your-thoughts-rdeno-deno-2-vs-bun-what-are-your-thoughts)] /r/bun: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/bun/comments/1fp9ndk/deno_2_vs_bun_what_are_your_thoughts/) [](https://www.reddit.com/r/Deno/comments/1fp9mom/deno_2_vs_bun_what_are_your_thoughts/)
- - /r/deno: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/Deno/comments/1fp9mom/deno_2_vs_bun_what_are_your_thoughts/)
- - [[10:14](#tauri-20)] [Tauri 2.0](https://v2.tauri.app/blog/tauri-20/)
- - [[11:40](#one-the-new-rn-framework)] [One - the new RN framework](https://onestack.dev/)
- - [[11:40](#creators-of-tamagui)] Creators of [Tamagui](https://tamagui.dev/)
- - [[11:40](#built-on-zerosync)] Built on [ZeroSync](https://zerosync.dev/)
- - [[16:15](#cloudflare-workers-updates)] [Cloudflare Workers updates](https://blog.cloudflare.com/builder-day-2024-announcements/?ck_subscriber_id=1888282043/)
- - [[22:05](#zeego-20)] [Zeego 2.0](https://github.com/nandorojo/zeego/releases/tag/v2.0.0)
-- [[22:33](#conferences)] Conferences
- - [[22:35](#halfstack-london-london-uk-nov-13)] [HalfStack London](https://halfstackconf.com/london/spon) London, UK Nov 13
- - [[22:40](#react-native-london-london-uk-nov-15)] [React Native London](https://guild.host/events/rnlconf-2024-y9arho/attend?discount=TMIR) London, UK Nov 15
- - Special Discount for podcast listeners with discount code TMIR
- - [[23:10](#react-summit-us-new-york-usa-nov-1821)] [React Summit US](https://reactsummit.us/) New York, USA Nov 18-21
- - [[23:14](#react-africa-casablanca-morocco-nov-29)] [React Africa](https://react-africa.com/) Casablanca, Morocco Nov 29
- - [[23:19](#react-day-berlin-berlin-de-dec-13-&-16)] [React Day Berlin](https://reactday.berlin/) Berlin, DE Dec 13 & 16
-- [[23:33](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red)
-- [[24:50](#some-react-19-progress-but-no-eta)] Some React 19 progress, but no ETA
- - [[24:50](#lazy-context-propagation)] [Lazy Context Propagation](https://x.com/sebastienlorber/status/1841042683122286641)
- - [[25:51](#“server-actions”-renamed-to-“server-functions”)] [“Server Actions” renamed to “Server Functions”](https://19.react.dev/reference/rsc/server-functions)
-- [[26:08](#react-native-bottom-tabs-library-using-native-bottom-tabs)] [React Native Bottom Tabs library using native bottom tabs](https://github.com/okwasniewski/react-native-bottom-tabs)
-- [[27:45](#meta-connect-showcasing-new-arvr-apps-built-with-rn)] [Meta Connect showcasing new AR/VR apps built with RN](https://engineering.fb.com/2024/10/02/android/react-at-meta-connect-2024/)
-- [[29:07](#static-hermes-updates)] [Static Hermes Updates](https://github.com/EvanBacon/expo-static-hermes-demo)
-- Reddit is revolting against Epic React
- - [[30:16](#anyone-else-feel-burnt-by-epic-react--rreactjs)] [Anyone else feel burnt by Epic React? : r/reactjs](https://old.reddit.com/r/reactjs/comments/1fwks6r/anyone_else_feel_burnt_by_epic_react/)
- - [[30:42](#epic-react-v1-=>-v2-upgrade-&-deception)] [Epic React V1 => V2 Upgrade & Deception.](https://old.reddit.com/r/reactjs/comments/1fut75h/epic_react_v1_v2_upgrade_deception/)
-- [[37:12](#web-components-are-not-the-future)] [Web Components Are Not the Future](https://dev.to/ryansolid/web-components-are-not-the-future-48bh)
- - [[37:12](#followup-to-this-from-march-2020-maybe-web-components-are-not-the-future)] Followup to this from March 2020: [Maybe Web Components are not the Future?](https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh)
- - [[37:34](#web-components-are-not-the-future--they’re-the-present)] [Web Components Are Not the Future — They’re the Present](https://www.abeautifulsite.net/posts/web-components-are-not-the-future-they-re-the-present/)
- - [[37:53](#liskovs-gun-the-parallel-evolution-of-react-and-web-components)] [Liskov's Gun: The parallel evolution of React and Web Components](https://www.baldurbjarnason.com/2024/liskovs-gun/)
-- [[44:10](#announcing-voidzero-next-generation-toolchain-for-javascript)] [Announcing VoidZero - Next Generation Toolchain for JavaScript](https://voidzero.dev/posts/announcing-voidzero-inc)
- - [[44:37](#oxc-transformer-alpha)] [OXC compiler](https://twitter.com/boshen_c/status/1840322879424258115)
- - [[44:37](#oxc-compiler)] [OXC Transformer Alpha](https://oxc.rs/blog/2024-09-29-transformer-alpha.html)
-- [[45:23](#updates-from-the-104th-tc39-meeting)] [Updates from the 104th TC39 meeting](https://dev.to/hemanth/updates-from-the-104th-tc39-meeting-14cp)
- - Stage 4 proposals
- - [[45:33](#promisetry)] [Promise.try](https://github.com/tc39/proposal-promise-try)
- - [[46:21](#sync-iterator-helpers)] [Sync Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers)
- - [[46:48](#import-attributes)] [Import Attributes](https://github.com/tc39/proposal-import-attributes)
- - [[46:58](#json-modules)] [JSON modules](https://github.com/tc39/proposal-json-modules)
- - [[47:05](#regexp-modifiers)] [RegExp Modifiers](https://github.com/tc39/proposal-regexp-modifiers)
-- [[47:11](#language-evolution-jssugar-proposal)] [Language Evolution](https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o/edit#slide=id.g30432c5cd9c_0_30) “JSSugar” proposal
- - [[47:11](#nullvoxpopuli-on-x)] [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389133810913338)
- - [[47:11](#nullvoxpopuli-on-x)] [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389157693227375)
- - [[47:11](#brendaneich-on-x)] [BrendanEich on X](https://x.com/BrendanEich/status/1842630141304025263)
- - [[47:11](#daniel-ehrenberg-thoughts)] [Daniel Ehrenberg thoughts](https://gist.github.com/littledan/a590784a72f2e1b8cc633ff5ff8a9dc2)
-- [[50:44](#⚡-lightning-round-⚡)] Lightning Round
- - [[50:44](#the-disappearance-of-an-internet-domain--io)] [The Disappearance of an Internet Domain](https://every.to/p/the-disappearance-of-an-internet-domain) – .io
- - [[51:51](#how-to-control-a-react-component-with-the-url)] [How to control a React component with the URL](https://buildui.com/posts/how-to-control-a-react-component-with-the-url)
- - [[53:16](#if-wordpress-is-to-survive-matt-mullenweg-must-be-removed)] [If WordPress is to survive, Matt Mullenweg must be removed](https://joshcollinsworth.com/blog/fire-matt)
- - [[55:09](#web-without-walls--dan-abramov)] [Web Without Walls — Dan Abramov](https://www.youtube.com/watch?v=F1sJW6nTP6E)
- - [[57:23](#preact-compat-discussion)] [Preact compat discussion](https://old.reddit.com/r/reactjs/comments/1fy2jjh/i_ran_into_preacts_false_promise_what_can_i_do/)
- - [[57:44](#content-visibility-in-css)] Content-visibility in CSS
- - [[57:44](#using-css-containment)] [Using CSS containment](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Using_CSS_containment)
- - [[58:00](#contain-caniuse)] [contain](https://developer.mozilla.org/en-US/docs/Web/CSS/contain) - [CanIUse](https://caniuse.com/mdn-css_properties_contain)
- - [[59:50](#contentvisibility-caniuse)] [content-visibility](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) - [CanIUse](https://caniuse.com/mdn-css_properties_content-visibility)
- - [[01:00:39](#how-i-built-my-blog-•-josh-w-comeau)] [How I Built My Blog • Josh W. Comeau](https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2/)
- - [[01:02:24](#types-of-react-components-2024)] [Types of React Components 2024](https://www.robinwieruch.de/react-component-types/)
-
-**Carl:** Hello everyone. Thank you for joining us for the October edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. [00:14]
-
-And we're supported by Infinite Red, a consultancy that exclusively works with React Native, but we'll do a little ad read for them later. [00:21]
-
-Hello, I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux where I run community programs like these events and the star helpers, and do other stuff to keep the community running smoothly. [00:33]
-
-**Mark:** Hi, I'm Mark. My day job is at replay. io, which we're going to have a slight tangent on the io part of this later on. And other than that, on Redux stuff. [00:43]
-
-**Mo:** The mobile team at Theodo which is a global consultancy and I'm active within the React Native ecosystem, organizing the React Native community and here and there dabbling in some open source. Happy to be here as always. [00:56]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Yeah. First up, some quick hits while people start filtering in. We did not do a job market update last month. It was actually pretty quiet. Not a lot of news. It seems kind of back to baseline. data for posts made to Indeed is still, like, two thirds of what it was at the beginning of 2020 before pandemic hit. [01:14]
-
-that might have been a high watermark for the industry, so it's, it's kind of hard to say. Layoffs at least have been, look very low for the last two months in a row. So that seems good, but yeah, the hiring has not really picked up. But not sure it's going to. [01:29]
-
-I wonder about that. Definitely the vibe I've been getting is that most of the roles being hired for are more on the seniors end of the scale, which is Not ideal, not great, but yeah, seems to be where it's at. [01:40]
-
-## New releases
-
-**Carl:** Yeah, into some new releases. [01:41]
-
-Moe, you want to tell us about React Native? [01:43]
-
-## [React Native 0.76 proper](https://reactnative.dev/blog/2024/10/23/release-0.76-new-architecture)
-
-**Mo:** Yes, indeed. I feel like this is years in the making, so I've got to really drum this up as much as possible. But, the new architecture is finally here, [01:54]
-
-## [New Architecture is here](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here)
-
-**Mark:** Woohoo! [01:55]
-
-**Mo:** So this is React Native version 0. 76. And if you go back into likethe history of React Native over the last five years, the first mention of the new architecture publicly was in 2019. [02:08]
-
-And really what the whole purpose of the new architecture was, was to make a more stable Baseline for React Native interacting with native platforms. How components are rendered. How does JavaScript code trigger native code and native modules? And how do we move different things around different threads and make sure that everything is optimized and consistent? [02:28]
-
-A lot of people think that the new architecture is like a performance oriented update. It doesn't really have that many major performance improvements. There's minor ones, but really what it's trying there for mainly is, I think, for library maintainers and for framework authors to be able to create a more consistent pattern of communicating between native and React Native. [02:47]
-
-So, for a little bit of context, React Native's old architecture used this thing called the bridge. So it was basically a messaging bridge where you could pass in serialized JSON from the JavaScript layer and from the native layer and it would kind of get communicated across this bridge. But the issue with a bridge is that it can have some traffic, right? [03:03]
-
-So you can bombard it with a lot of JSON and suddenly because it's asynchronous it has limits in terms of how much it can communicate if you were trying to update things frequently or send a lot of data through that bridge you would block that, and what we would call that is that the JS thread is blocked, and so your app would basically drop in its frame rate, the CPU usage would spike, and everyone would be unhappy, and your users would be like, Hmm, this is not quite native feeling to me. [03:30]
-
-But, as of now, there's been a lot of work that's been done. React Native has a bunch of different stuff that I'm not going to go into too much detail about. But the bridge has been replaced with what we call the JavaScript interface. And so what that means is JavaScript code can get a reference to a C object that communicates with a native layer, and it can directly invoke methods within that C layer that would live on the native layer. [03:51]
-
-So it removes the bridge and it's just direct communication via JavaScript interface to the native layer. So that makes things significantly more efficient. It's not just that, the new architecture is a lot of different parts. There's the new event loop, there's the new renderer and then there's the new native module system, and of course the JSI, which is kind of underpinning all of that. [04:11]
-
-the article that you shared in the chat has a lot of details and it's a good summary, so I would start from there if you've been kind of under the rocks. In the React Native ecosystem and not,really hearing much about the new architecture. I think it's a really good summary about why it matters, what you can achieve. [04:25]
-
-And ultimately, I think one of the biggest things is that it's giving you parody with React behaviors, because a lot of things that were in React before just didn't work in React Native properly and people were figuring that out on usage. Basically, it wasn't really documented very well anywhere. very exciting times. [04:40]
-
-it's finally happened. [04:42]
-
-**Carl:** Yeah, I feel like this is an update that's a little easy to be, you know, under a rock on. If it's been in progress for literally five years now, I could see how that might slip into the back of your mind as something like, There's a lot of things I waited five years for, and by about the third or fourth year, I started wondering if it was ever going to actually happen. [05:01]
-
-**Mo:** exactly, and you know, it's one of those things where yeah, it's been happening for five years, but you do get new architecture talks every conference that's a React Native conference or like React Native adjacent. So it's been the topic of conversation and everyone's like, Oh, that'll probably come at some point. [05:15]
-
-And it feels quite surreal to have it actually here. [05:18]
-
-## [BlueSky](https://github.com/bluesky-social/social-app/releases/tag/1.92.0-na-rc.2) and [Expensify](https://blog.swmansion.com/sunrising-new-architecture-in-the-new-expensify-app-729d237a02f5)
-
-**Carl:** Cool. I saw a post from Software Mansion, which is a React Native focused, consultancy as far as I know, talking about bringing the new architecture into the Expensify app, and I understand that the Blue Sky native app is doing a release candidate for it that's like, opt in, and they say it's, you know, it's a release candidate, it's unsupported, try it at your own risk, please report bugs. [05:41]
-
-But like, those are real apps, like Expensify is widely used enterprise app. So that's some real usage. That's pretty cool. [05:48]
-
-**Mo:** props to the meta team, they actually spent a lot of time with real apps that are large scale apps that, you know, were popularly React Native. They approached the developers of those apps and said, Hey, can you turn on the new architecture before we release and make sure that it's working and behaving and functioning in a way that doesn't really have regressions and is actually better than it was before. [06:06]
-
-So they've really tested this out and drawn it out. They've worked with library maintainers one on one to get them on to the new architecture boat. So, this is as good as it ever will get in terms of just biting the bullet and releasing. [06:19]
-
-**Carl:** Nice. Yeah. [06:22]
-
-## [React Compiler Beta](https://react.dev/blog/2024/10/21/react-compiler-beta-release)
-
-**Mark:** The first one is that the React compiler is now in beta. The first, you know, early adopter, I guess, releases came out at React Conf back in May. And it's now in beta you can actually meaningfully try it out, they've done a lot of work to try to improve the behavior against real world applications. [06:42]
-
-Along with that, there's a couple different ESLint plugins the Rules of React Hooks plugin has been updated, and it's got some additional checks for whether things are actually components. Along with that, the compiler has its own associated plugin that tries to check for the rules of React behavior. [07:02]
-
-You know, basically, are you doing anything that is considered illegal, even if it technically runs inside of your React component? And so they're highly recommending that people start trying to use the rules of React plugin in your applications to find places where you're doing things that you're really not supposed to in React. [07:23]
-
-## [React DevTools v6](https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#600)
-
-**Mark:** Along with that, there's a new React DevTools extension release. They did a lot of shuffling around of the internals, but what is probably most relevant here is that the DevTools now actually have support for showing server components in the tree. And this is a big deal, because up until now there really hadn't been any way to atsee what server components were actually, being used when you were looking at the code on the client side. [07:47]
-
-So that's a pretty distinct improvement there. [07:50]
-
-## [Zustand v5](https://github.com/pmndrs/zustand/releases/tag/v5.0.0)
-
-**Mark:** Flipping away from that over into state management, Zustan just came out with version 5, and it doesn't have any new features, but it does drop some, legacy backwards compatibility changes, default exports, a couple other things, and it now requires React 18. [08:08]
-
-So if you're using Zustan, you may want to look at picking that up. [08:11]
-
-**Carl:** Yeah. Hang on. The Redux guy talking about another state management library. Hold up. [08:15]
-
-**Mark:** I'm allowed to. ( laughter) [08:17]
-
-**Carl:** For sure . [08:17]
-
-## [eslint-plugin-react-hooks v5](https://github.com/facebook/react/releases/tag/eslint-plugin-react-hooks%405.0.0)
-
-**Carl:** There's also a new major version of the ESLint plugin for React Hooks. Looks like it supports ESLint v9, and it doesn't look like there's a lot of changes, I think it's mostly just compatibility for latest versions. But, they did change how the rule works for component names. [08:33]
-
-So now, previously it used to require a non lowercase letter. So it'll let you do things like an underscore in front, and now it doesn't. Now it has to be an uppercase letter. they kind of flipped the bit on that. [08:44]
-
-**Mark:** Picky, picky. [08:45]
-
-**Carl:** Cool. [08:45]
-
-## [Announcing Deno 2](https://deno.com/blog/v2.0)
-
-## /r/bun: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/bun/comments/1fp9ndk/deno_2_vs_bun_what_are_your_thoughts/) /r/deno: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/Deno/comments/1fp9mom/deno_2_vs_bun_what_are_your_thoughts/)
-
-**Carl:** Deno released version 2 as well. We've covered Deno sporadically over the last couple of episodes, but the highlights here that they shout out are backwards compatibility with Node. [08:56]
-
-js and NPM, native support for the package. json and Node modules. I guess that's part of backwards compatibility. More package management, I know, you know, the original idea behind Deno dependencies was just like a little bit more URL based and kind of free for all like no registry just like install code very like go Inspired and I guess they're walking that back pretty hard. [09:21]
-
-**Mark:** they've walked [09:22]
-
-back a lot of things around NPM compatibility. [09:25]
-
-**Carl:** Yes, I feel like they started out heavily opinionated and are walking back a lot of those opinions, which okay I mean, I guess fair enough. They did also do a lot of work on the standard library and things So it could well be that some of those opinions were just like this is less work. [09:40]
-
-We're gonna launch it they've got a standard library Support for private NPM registries. Yeah, a lot of these things are just kind of like details on backwards compatibility with node and NPM they're doing LTS releases. They've got their own JSR, JavaScript, something registry. [09:57]
-
-And there were a couple of threads that I wanted to shout out of exact same title posted in the Bun and Dino subreddits, Dino2 vs Bun. What are your thoughts? I won't summarize them. It's just like a bunch of Reddit commenters, you can see, see the two, the two camps reacting to the news, [10:14]
-
-## [Tauri 2.0](https://v2.tauri.app/blog/tauri-20/)
-
-**Mark:** The Tari framework, which lets you build desktop apps using web technologies as an alternative to Electron just came out with version two. They have some improvements around HMAR and plugins and various other internal improvements. If you're building desktop apps, probably worth taking a look. [10:32]
-
-**Carl:** Yeah, I thought it was neat that they added a permissions model. I guess they used to have like an allow list of things that your app was allowed to do. And they talked a little bit about enhancing that with, you know, a permissions model, which seems like a good improvement. Yeah, they also mentioned mobile support, which was like, what? I feel like they buried the lead on that. It's like, I want to know a lot more about that. I feel like Rust based native app framework where you can use React on Android and iOS. Like, huh, I want to know a lot more about that, but they didn't say too much in the announcements. [11:04]
-
-**Mo:** Yeah, it's, as with all things with thisso it's not official yet with Taure. I think they're just kind of working on it, so I,suspect they're kind of saying, hey, we're working on it. The general gist with all of these Electron like frameworks it ultimately ends upbeing something like Cordova with Ionic. [11:22]
-
-it's a web view that triggers some native functionality. It won't be a truly native app, which is, I guess, one of the distinguishing factors of React Native. But it'd be very interesting to see how they play this out. And how it works in practice. It might be something a bit different, but they're being very cryptic about it so far. [11:38]
-
-So, remains to be seen. [11:40]
-
-## [One the new RN framework](https://onestack.dev/)
-
-## Creators of [Tamagui](https://tamagui.dev/)
-
-## Built on [ZeroSync](https://zerosync.dev/)
-
-**Mo:** Moving on. So, earlier this year the React Native Core team came up with this big announcement saying, Hey, we think you should use frameworks. And not build your own frameworks every time you initialize a new React Native app. And so at that point they introduced Expo as the only option to, as a pre built framework. [11:57]
-
-They said, you know, you're either using Expo, or you've built your own framework by building on top of the core of React Native. And so now we have finally gotten a second framework that's come in and said, Hey, I I'm a contender for that spot as well. the framework is called one. I'm not too sure why there's, that's the naming, but, there we are. [12:16]
-
-You have a theory. All right. [12:17]
-
-**Carl:** so it looks like they're built on a sync engine that's called Zero. ZeroSync. so I guess this is, you know, they're built on Zero so they are one. [12:26]
-
-**Mo:** Cool. So, this is an interesting development because the person who's behind this is behind the library called Tamagui. So Tamagui is a styling library within the React Native Ecosystem. the whole spiel with Tamagui is that it's an optimized view layer library that you can use not just for your React Native apps, but also in things like Next. [12:46]
-
-js. So you can kind of share your UI across the board between React Native and the web. it's used to build these universal apps. Tamagui is quite an interesting project. It's actually a very heavyweight library, because it comes with things like a styling solution, a compiler that, does view flattening. [13:05]
-
-Next. js optimizations out of the hood. it's a very heavy styling solution when you're using it just for React Native, and it's notoriously complicated as well. they've taken Tamagui, paired it with a whole bunch of other stuff, like a file system routing based solution, and the most interesting part, I'd say arguably, is the fact that this is beat based.previous to this, you couldn't use Vite for React Native because you'd have to use either Metro or in some cases you could use Webpack, but it was quite a pain to actually get that working. the creator of this, Nate, has been working on seeing if Vite can become a compiler for React Native. [13:42]
-
-React Native, and it seems like there's some good movement on this. So, it uses Veep by default to kind of standardize the bundler across web and mobile. So, it's a very interesting proposition and they have a lot of experience but it's still going to be interesting to see how this plays out. [13:58]
-
-It's very early days. So, I would Tread with caution until it's reached some point of stability and it's being used. But it's very interesting to see how it's forming. [14:09]
-
-**Carl:** Yeah, definitely early days, but like, I'm taking this reasonably seriously. It seems like a pretty clever and opinionated take on how to do a framework on React Native. I guess, you know, like, my rough mental model for this this feels to me like the React Native equivalent for Remix. [14:28]
-
-in large part because it's beat based, you know, okay. [14:31]
-
-**Mo:** but it has a lot of, like, very similar ideas, right? Like, they've kind of introduced this concept of loaders as well. it's very Remix esque. so I can see why you take that comparison. [14:42]
-
-**Carl:** another thing that I find fascinating here is they put local first and sync engine very heavy in their homepage marketing for this. they talk a lot about this being built on zero sync, which is built by a company that I've heard of and that the CEO follows me on Twitter. [14:57]
-
-I think that's cool. it's being built by a team that worked at a decentralized exchange that I had heard of. Six years ago. So they worked on decentralized tech that I took seriously as someone I also worked in decentralized tech six years ago. So I think it's really interesting that that's the Opinion they're bringing to this company that they named that they worked at Uniswap I viewed as one of the serious contenders in web 3 before it became overtaken by scams So it looks like they have now moved out of Web3, taken that decentralized technology experience, and are building a React Native framework that is based around local first, you know, data on your device, primarily synced to a backend. [15:40]
-
-And I think that's really cool. I am pretty bullish on local first generally, I'm very curious to see how this works. Early days, like you said, it's interesting to me. I am intrigued. [15:51]
-
-**Mo:** and Uniswap is built with Tamagui. So the web and the mobile app is built with Tamagui which kind of is a real implementation, real world production app that's using the universal app paradigm. they know how to do it. It's just a matter of how, easy to use it is for other developers who aren't that familiar with this sort of framework or this [16:10]
-
-**Carl:** it's Yeah, right. It's easy to say how powerful and useful something is when you are the person who made it. [16:15]
-
-## [Cloudflare Workers updates](https://blog.cloudflare.com/builder-day-2024-announcements/)
-
-**Carl:** Cloudflare Workers released a bunch of new updates, and a lot of them look really cool to me. So I'm using Cloudflare Workers a little bit in like, a side project or two. [16:24]
-
-I would like to use it more for ReactiFlux projects, but actually Discord does not allow the gateway to connect to like, the Cloudflare Workers durable objects. For some reason, I don't know why, that seems weird. than the fact that you just can't connect to the API, they seem like a really powerful way to interact with Discord. [16:43]
-
-So, I would love to use them for that. Sadly, I can't. ButI think Cloudflare released, yeah, 18 big updates to the workers platform is the headline here. Literally the title of release. Something that I found really interesting is they are advertising CICD with PR preview releases for workers. [17:01]
-
-I think that's not going to be quite as like turnkey, instantly useful as it is in like Netlify or you know, Vercel where, you know, like, you get a PR preview on your website, you just get a new domain, boom, done, everything kind of works. Assuming you didn't like actively screw something up and how you are doing, you know, base URLs. [17:22]
-
-I think for a backend service like this, it's just not going to be quite so simple and like zero effort to take advantage of PR previews. Like you, you need to have a staging environment where you can be notified of a new URL being available and then dynamically swap out the, like, base route for this. [17:39]
-
-And then like other stuff, like what about. Seeding test data and things like that. So I don't think this is quite so like Mind blowingly immediately useful as it is on a web deployment CICD, but that's still super cool Like that's you know, like for it for a discord bot, which is mostly where I've tried to use these like that's still pretty Accessible. [18:00]
-
-Yeah, so I think that's pretty pretty useful some other smaller stuff Logging on the dashboard for your workers. I have run into issues with like Observability was not easy before this, so I have actually already enabled logging on the dashboard in one of my projects because I needed it, and I was like, oh, cool, great, now I can just do it's not effort. [18:17]
-
-Better Node. js compatibility, they have, because it's a serverless runtime, they don't have stuff, like FS or HTTP or things like that. It was a little bit more Sandbox, like, Request Lifetime, they give you the entire environment in the request handler. So, when they say greater Node. [18:35]
-
-js compatibility, I'm not quite sure how to interpret that. The, they had like a compatibility chart, and it included like 100 percent on, you know, NodeFS. But like, I don't know what that means when you don't have a file system, you know. I don't think they are actually emulating a file system where you can read and write. [18:52]
-
-Maybe they are, I don't think they are. [18:54]
-
-**Mo:** [18:54]
-
-they're slowly going through the list of Node APIs, And I think they support like only 50 percent of them. So they still don't support like file system in any capacity, just because it doesn't make sense for the runtimes they have, because our workers kind of just run in a V8 isolate. [19:11]
-
-just running somewhere on their edge network [19:13]
-
-**Carl:** That's what confused me though, because the compatibility thing said 100 percent coverage for FS. And so it's like, I know you don't support this because of the environment, what does that mean? I don't know how to interpret this chart. [19:24]
-
-**Mo:** yeah, I think some of them are probably just weird polyfills or just like shimmed values. I'm [19:30]
-
-**Carl:** Yeah, I mean, I guess even like, doesn't immediately explode is an improvement, you [19:36]
-
-**Mo:** Is it an improvement yet? [19:38]
-
-**Carl:** Which is where it's been for me, like, oh my god, there were some weird things that happened when I was trying to develop that. Like, CommonJS imports and things, yeah, so, yeah, I have to play around with that a little bit more. [19:48]
-
-Yeah, they also have Next. js support. via open next, which they've open sourced. So like, cool, here's an open source runtime that they are using themselves in production to provide next support. And like, that's enormous. I think I saw when this was announced Vercel, some of the big Vercel DevRel folks who are active on Twitter seemed a little bit like they were nervous. [20:12]
-
-**Mo:** I've used Cloudflare Workers quite a lot recently, and they had some, like, Next. js support, limited. They've been increasing it for the past few years. They started off with just, like, you can static export Next sites. Great. You can do that with anywhere and host it anywhere. Right? Then it was like, we'll support some limited sub features of Next. [20:28]
-
-And I think they're now supporting it almost fully with the OpenNext runtime. And I can see why some of the Vercel folks would be a little bit on edge, because if you support Next to that degree, yes, Vercel has a lot of nice DevEx features, but when you look at the cost for a large scale site, and where Vercel would make a lot of their money you can get the majority of those functionalities, or like 80 percent of those functionalities on CloudFlare pages. [20:52]
-
-it kind of works similarly. You get those preview branches and all of that. So I can see why they'd be a little bit anxious about that, but I suspect they'll do what Vercel usually does, which is introduce a new, like, runtime dependency, and then it'll take everyone six months to basically get on the same compatibility. [21:11]
-
-So we'll see. [21:12]
-
-**Carl:** They'll just dig that moat a little bit deeper, maybe. Yeah, they also have per worker SQLite, which is neat. Previously, I guess it had only been, like key value store based, so it was kind of like having local storage available per worker, which is great, but, you know, you can't query it.you can't really do structured data in a situation like that. As well as blue green deployments, incremental rollouts. And queues, and a vector database, performance improvements, like, you know, one of the performance improvements is faster time to first token on their AI, platform. [21:41]
-
-like you were saying, Mo, about Vercel getting maybe a little nervous aboutCloudflare workers with real Next support for things like the dynamic images, some of their, longer tail of server based functionality with PR previews, incremental rollouts, and, a queuing system, like,that starts to sound a lot like the offerings that Vercel offers. [22:03]
-
-But yeah, [22:05]
-
-## [Zeego 2.0](https://github.com/nandorojo/zeego/releases/tag/v2.0.0)
-
-**Mo:** Cool. I'll quickly just give a shout out to version Zgo. So for those of you who aren't familiar, Zgo is a wrapper, it's almost like an abstraction, on top of context menus on both native and web. So again, going in that universal app trend you can use a single API in your code base to create context menus for your web with Radix, and then it'll hook into the native layer context menus on iOS and Android. [22:26]
-
-So it's a nice little library to use as a utility when you do want to have context on certain elements of your app. [22:32]
-
-**Carl:** Cool, seems useful. [22:33]
-
-## Conferences
-
-**Carl:** Alright I'm gonna fly through some conferences. [22:35]
-
-## [HalfStack London](https://halfstackconf.com/london/spon) London, UK Nov 13
-
-**Carl:** Halfstack London is happening in two weeks. November 13th. [22:40]
-
-## [React Native London](https://guild.host/events/rnlconf-2024-y9arho/attend?discount=TMIR) London, UK Nov 15
-
-**Mo:** Yes, and another shameless plug React Native London conference, this will be the last announcement before it actually happens in Just over two weeks now. So, this is happening in London, of course on the 14th and 15th of November. Tickets are gonna probably start closing soon, in the next week and a half, roughly, so grab your ticket if you're interested, and there's a discount code with TMIR for this month in React. [23:03]
-
-Where you can get 10 percent off. So come along, say hi to me if you're there, shoot me a message if you do plan on attending. We'd love to host you. [23:10]
-
-## [React Summit US](https://reactsummit.us/) New York, USA Nov 18-21
-
-**Carl:** There's also React Summit in New York November 18th through 21st. [23:14]
-
-## [React Africa](https://react-africa.com/) Casablanca, Morocco Nov 29
-
-**Carl:** React Africa in Casablanca, Morocco at the end of the month in November 29th. [23:19]
-
-## [React Day Berlin](https://reactday.berlin/) Berlin, DE Dec 13 & 16
-
-**Carl:** And React Day Berlin December 13th and 16th. [23:23]
-
-**Mark:** I will be speaking at React Summit. [23:25]
-
-**Carl:** Cool. Yeah, go to React Summit in New York and go meet Mark. I live in New York. [23:31]
-
-I will try and make it if I can. [23:34]
-
-## [Sponsored by Infinite Red](https://infinite.red)
-
-**Carl:** So we are exclusively brought to you by Infinite Red. That's very tongue in cheek, but yes, they are our only sponsor right now. Infinite Red is an expert React Native consultancy. They've been around since 2015 uh, and are owned by Jim and Holmgren. [23:47]
-
-Todd Wirth and Gant Laborde. They've been super active in the community for literally my entire career. I got my start like professionally with React around 2014 or so. So like, I have been aware of them for a really long time. And yeah, I connected with them in a conference and just great vibes. So good. [24:04]
-
-They only do React Native and have built over 75 apps for companies from startups to like huge enterprises. And just like, other than being good people who do a lot of good things for the React and React Native ecosystemsthey seem to be very good to their people because they, like their average tenure of employees at their company is more than seven years. [24:23]
-
-Which is wild to me. That's double the tenure I've ever spent at one company. So that seems great. They are not a like feature factory. They work alongside your developers at your company and help you develop your own expertise there. So if you are spinning up a new product with React Native and want some help hitting the ground running, definitely give them a ring. [24:41]
-
-And uh, you do let them know that you heard about them from us. Not that we get anything out of it. Just, you know, Maybe help us in the next contract negotiations. He he he. [24:48]
-
-## Main Content
-
-**Carl:** Into our main content though. [24:50]
-
-## Some React 19 progress, but no ETA
-
-## [Lazy Context Propagation](https://x.com/sebastienlorber/status/1841042683122286641)
-
-**Mark:** So we've been attempting to track the progress of React 19 and there were a couple of progress that I saw happening in the last month or so. The. Big thing is that we're still waiting for them to finish work on the changes related to the parallel suspense rendering behavior that caused an outcry earlier this year. [25:13]
-
-And I saw a couple PRs from Andrew get merged. I later saw one of them get reverted. And then, just in the last week or so, I think I saw one of them get unreverted or a feature flag get landed around that. So, there is work going on, I have no evidence to say how much more work is needed to be done. I also think I saw someone from the React team, possibly Sophie, mention that they're hoping to get it out by the end of the year, but, you know, nothing concrete either way. [25:46]
-
-So, stuff's happening, stand by, and wait. It's all we can do. [25:51]
-
-## [“Server Actions” renamed to “Server Functions”](https://19.react.dev/reference/rsc/server-functions)
-
-**Carl:** Hurry up and wait. Yeah. And I guess one concrete change that has happened is server actions have been renamed to server functions, which I don't know, I guess that seems good. There's a lot of things in the ecosystem that were called actions. So one less thing called action seems good. [26:07]
-
-**Mark:** Probably. [26:08]
-
-## [React Native Bottom Tabs library using native bottom tabs](https://github.com/okwasniewski/react-native-bottom-tabs)
-
-**Mo:** Cool. So, the next update is that there's this library called react native bottom tabs that's made by one of the developers at Callstack, Oskar Kwaszynewski. Who I've known for a little while. And This is quite an interesting development. Because The current library that you use for navigation within React Native Is called React Navigation. [26:28]
-
-And React Navigation has bottom tabs within it. But they're not fully native backed bottom tabs. And so it means when there's updates Or specific Styling applied to certain platforms Let's say onLet's say on iOS Where if you're on like tvOS, the tabs go on the top. And if you're on tablet, you can have them as like a sidebar. [26:47]
-
-But on mobile, they kind of just look like a normal tab bar. Those changes wouldn't be reflected because they were just basically JavaScript views that were customized. And so the whole purpose of React Native bottom tabs is to create native based navigationOn React Native apps using a JavaScript API. [27:05]
-
-So this will hook into the native layer and it'll look and be styled as a native layer bottom tab, which is quite cool. And a lot of work's being placed into it. One of the things that I've been thinking about with this is could this possibly be introduced and upstreamed into React Navigation because It's a really good alternative. [27:27]
-
-So in React Navigation, we've got native stack navigators, which is the stack navigator that you can use. And it uses the native functionality for the stacks. This could also be introduced as some sort of native tab navigator. So still to be seen, but quite interesting as an update. [27:45]
-
-## [Meta Connect showcasing new AR/VR apps built with RN](https://engineering.fb.com/2024/10/02/android/react-at-meta-connect-2024/)
-
-**Mo:** Cool. Next up, we have MetaConnect happening, and there was a whole bunch of AR VR showcases, which was cool. Obviously, Mark Zuckerberg went on stage and showed off the Orion headsets, which are not really going on sale, but they're kind of showing the future of where Meta wants to go, which I'm personally quite excited about, I really like AR, I hate massive VR goggles, but I really like the form factor of the uh, Google Glass. [28:09]
-
-And I was quite gutted that Google Glass was, was basically chopped. I think it was just a bit too early for its time. But, on the side of that demo there some sort of, like, engineering blogs that were released. And they showcased at the event the Instagram and Facebook apps for the new MetaQuest. [28:25]
-
-interestingly despite Instagram being a native application and despite you know, parts of the Facebook app also being backed by native the Instagram and Facebook apps for the MetaQuest have been rebuilt with React Native, which is quite a big step forward. win for the React Native ecosystem because it's being used on more and more platforms and powering more of Meta's apps that is part of the core business. [28:50]
-
-So this was quite cool to hear and they've built some incredible apps. Like if you, if you look at the demos, there's really swift animations there. Everything looks really buttery smooth and looks really nice. So, it's a really cool showcase of, what they've been able to achieve by rebuilding some of this stuff in React Native. [29:06]
-
-Cool. [29:07]
-
-## [Static Hermes Updates](https://github.com/EvanBacon/expo-static-hermes-demo)
-
-**Mo:** Just a quick update on Static Hermes. Not much is happening here. There's a lot of discussions around like how compatible it would be and you know, what challenges it would introduce with the existing ecosystem. Svetlan Mikhov, who's one of the people behind Static Hermes and who first introduced it last year at React Native EU actually talked about some of the limitations that they were facing trying to take Static Hermes to production with the wider ecosystem. [29:30]
-
-A few people have been playing around giving him some feedback. He's been going on long threads on Twitter explaining some of the details of the implementation, especially with assembly code. So he's been like pasting assembly code in Twitter threads which is quite interesting and he's been styling them like, he's been going through a lot of effort to try to really like explain to the community, which is props to him. [29:48]
-
-But Evan Bacon, as Evan Bacon does came up with a demo of using Static Hermes with Expo dev clients on iOS. So Software Mansion's been working on some stuff around trying to take Static Hermes to production, and Evan Bacon's been trying to see if he can find a way to make it work with a basic Expo app. [30:07]
-
-There's still some limitations it's not anywhere near production ready, but it's just, things are being done in that space, which is quite cool to see. [30:14]
-
-**Carl:** Yeah. Super cool. Nice. [30:16]
-
-## [Anyone else feel burnt by Epic React? : r/reactjs](https://old.reddit.com/r/reactjs/comments/1fwks6r/anyone_else_feel_burnt_by_epic_react/)
-
-**Carl:** This is maybe a little bit of a small note, but I think we've plugged it before. So I wanted include some follow up from the ecosystem. Folks on Reddit have been sharing about feeling burnt by Epic React, which is Kent C. Dodd's React course. I empathize. I get it. Their criticisms are pretty legit. [30:34]
-
-Some of them are legit. Some of them feel like, you know, reddit commenters having strong opinions about how the world works, which are not necessarily based in economic realities. [30:42]
-
-## [Epic React V1 => V2 Upgrade & Deception.](https://old.reddit.com/r/reactjs/comments/1fut75h/epic_react_v1_v2_upgrade_deception/)
-
-**Carl:** Butsome of the complaints that seemed a little more legit to me were, like, people who had bought the, version one, the old version a couple of years ago, were upset about having to pay almost full price to get the upgrade. [30:54]
-
-## Marker
-
-**Carl:** And on the one hand, like, if you bought a course and you learned the course, why do you need to buy it again? I can understand wanting it. And I guess I can understand, like, wanting to, I don't know, it feels a little bit like folks, Feels a little entitled. Feels a little bit like wanting stuff for free. [31:13]
-
-Like I don't know, he put in a lot of effort to update it. I think the previous version came out like four years ago and that's a long time. A lot of things have changed and been updated and the ecosystem has moved on a lot. So I don't know that it is a reasonable expectation to get a brand new course for free or for extremely cheap just because you paid for it a couple of years ago. [31:37]
-
-If you paid for a course that is intended to like help you kickstart a career using the technology, I don't know that you should necessarily need to buy another course targeting people who are trying to kickstart careers in the industry several years later. If you do, like, maybe you didn't take full advantage of the first course. [31:55]
-
-I don't know. So I empathize with that. People were also criticizing the cost of it as being very expensive. It is like, you know, it's several hundred dollars. Like, I think full price for it is like 700. [32:05]
-
-**Mark:** my train of thought on that one is that Kent is entitled, it's a free market, Kent is entitled to put whatever price on, you know, something he's selling, and you are free to ignore it if you don't feel like it's going to be useful or provide enough value. there were maybe some comments about, like, folks not liking his teaching style. [32:24]
-
-That's more of a valid concern, but if you don't want to pay that much money for his course, if you feel like a 20 Udemy course is better, then go pay 20 for that course and move on. [32:36]
-
-**Mo:** Yeah, I'm inclined to agree as well with Mark there. It's just, you do your research before you purchase something. I think he's abundantly popular where you can watch some videos online of Kent. See if you like his teaching style, if you don't like his teaching style, and then make an informed choice as to whether or not you want to spend several hundred dollars for it. [32:53]
-
-I think trying to argue after the fact to say, hey, this wasn't great, it wasn't worth the price, well, cool, but, you know, leave a review for it, I guess, and move on. It's, a free market with this type of thing. Yeah. [33:04]
-
-**Carl:** what? Like, I dropped out of college after a year. Each of those college credits was like 1, 500, 15 years ago. So I feel like I would have gotten much more value out of a course like this than I did out of any individual college course that I took. I don't know, I left that comment on Reddit and they did not find it compelling or I got a negative score. But that's my opinion on it. Like, education, in general, costs so much money. And the value to Cost for something like this to me seems pretty clearly at least worth trying I don't know if you're going for it Yeah, and in the comments to joshwcomo has a course out as well. [33:47]
-
-Also seems really great Also a pretty similar price point, like curated education material from an industry leading expert. You don't get that for free. It's a lot of effort. It's hard to be an industry leading expert. It's hard to design a course syllabus. It's hard to produce that content. [34:03]
-
-It's hard to distribute it. It's hard to, yeah. So I don't know. It's,they're doing it all on their own. These are independent educators in general. Like they are doing their own thing on their own time. Yeah. [34:15]
-
-**Mark:** And, I mean, just, just as a related point, so I did all that work in the first half of this year to update the Redux Essentials tutorial in the Redux docs, which I did all that work for free, and I'm not charging any money for it. And, for the first time I actually tried tracking my hours. And I put in 80 hours of actual focused time, which on the one hand feels like it's not much, you know, like my first instinct is, well, that's only two weeks of work. [34:44]
-
-On the other hand, let's face it, across a typical two week period, I don't actually put in 80 hours of focused effort in my day job. you're in your seat for eight hours, maybe, but you're getting maybe four or five hours of productivity tops. And like, that was, quote, just building off of an existing tutorial where I'd written the content and written the example app. [35:05]
-
-I wasn't coming up with that stuff from scratch. I was converting it to TypeScript, figuring out how to add a couple new features to teach a couple new ideas and then, you know, doing the work to get the right commit sequence, and then turning that into code. Updated content. So, I mean, it was effort, but like, I wasn't doing all this stuff from scratch and that still took me like multiple weeks worth of focused time that I did for free. [35:33]
-
-And so, I got a sense of the amount of work Kent was putting into version two of his course and like he was significantly revamping things. [35:42]
-
-**Mo:** there's a comment in the Reddit thread, which I actually agree with quite a lot and I think it's the right approach with this, which is The person says, well, it is expensive and you can go through YouTube and find each of those topics and find like a tutorial video on them for free on YouTube. [36:00]
-
-But if you have the money, what you're basically paying for is someone to curate that content for you. Summarize it, create a syllabus for you, and give it to you on a silver platter, right? instead of searching for that material, you're paying for that person's time to curate that material for you. [36:15]
-
-The information is there for free, but you are paying for Kent's time and organization to come in and create something valuable for you so that you don't have to spend the time searching. So if you got the money for it, great, go for it. There's someone else in the chat as well that mentioned, which I think is a good point to put it into perspectivea lot of companies will let you expense stuff like this on like a training budget or, an upscaling budget that they have. [36:36]
-
-So when someone like probably prices something at several hundred dollars, I don't think he's expecting indies to come in and all shell out several hundred dollars. I suspect the goal is to find like a midpoint price point where it's. Expensive for indies, but quite cheap for corporates to pay for a large number of licenses. [36:58]
-
-And he does have a option to select multiple licenses and buy for your team. So I think that's probably where the pricing is coming into place. [37:05]
-
-**Mark:** Yeah, sort of the training equivalent of targeting the enterprise market. [37:09]
-
-**Mo:** Exactly. [37:09]
-
-**Mark:** moving along touching on some drama. [37:12]
-
-## [Web Components Are Not the Future](https://dev.to/ryansolid/web-components-are-not-the-future-48bh)
-
-## Followup to this from March 2020: [Maybe Web Components are not the Future?](https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh)
-
-**Mark:** I think we might have mentioned some previous bits of the web components versus React thing that's been going on the last couple months. This started with a post from Ryan Carniato, the author of the Solid Framework. Where he said that Web Components aren't the future. [37:27]
-
-And that spawned a whole lot of discussion after that. A lot of folks from the Web Components community were upset. [37:34]
-
-## [Web Components Are Not the Future — They’re the Present](https://www.abeautifulsite.net/posts/web-components-are-not-the-future-they-re-the-present/)
-
-**Mark:** Someone wrote a post called, Web Components are not the future, they're the present. Which made a bunch of arguments, both technical and sociological, about how Web Components should be fitting in. [37:46]
-
-Lots of debate in Twitter threads, Mastodon threads. I'm not on Blue Sky, but I bet there was probably some debate over there, too. [37:53]
-
-## [Liskov's Gun: The parallel evolution of React and Web Components](https://www.baldurbjarnason.com/2024/liskovs-gun/)
-
-**Mark:** there was one other article that really stuck out to me called the Parallel Evolution of React and Web Components. It's stupidly long, even by my standards. [38:01]
-
-It's 11, 000 words. It's a very long read, and I had mixed thoughts on it. I thought the first third of this was a really good technical discussion about, Some of the web component's early specs came out even before React did. Both of them have evolved over time. The middle third devolves into the author kind of bashing on React for a while, and then it kind of finishes up with some more decent thoughts about technical aspects and how they fit into web application architectures. [38:31]
-
-I'm not gonna suggest that everyone should read it, but there was some interesting background material, and at least the author put in actual time Writing this post as opposed to just, you know, random bashing of things purely on Twitter if you want to see some of the web components discussion that stuff's out there [38:48]
-
-**Carl:** my understanding is that one of the biggest problems of web components, I've never used them, I understand them to be in, you know, Intended to be used as like leaf nodes, kind of like your, your design system. Like if you are going to build a design system in React, I think that web components advocates would say, no, no, no, don't build those components with React, build them with web components. [39:10]
-
-And then you can use them in many, many places and many frameworks and yada, yada. My understanding is that web components have many of the same problems as trying to build your own design systems, where the hardest part is things like versioning. And if you don't get it exactly right the first time, it's kind of difficult to ship new changes to them. [39:29]
-
-So it sounds like web components are still hit a lot of the same problems. They just kind of shift the context. And so you have to figure out like, when you're doing a design system in React, The problem is around versioning and like packaging. Like, do you do many sub libraries? Like, do you make your own like React modal component and your own tool tips and your own buttons and your own accordion tabs, whatever, or do you do one big bulk package? [39:54]
-
-But then it's like, you end up with these like, well, okay. If you ship a change to this. Low level component used within this design system, like, how do you migrate all of the clients that are using that design system without doing like a big bang rewrite across dozens of clients? [40:11]
-
-And like, that's hard. It's not trivial and it sounds like web components have that same problem But instead of versioning happening through semver in npm, it happens in this entirely bespoke Web component standard system and like that doesn't seem better to me. It's like you have to learn a whole new, Context, as well as dealing with the same problem. [40:32]
-
-So, like, I haven't seen that discussed at all in any of these, you know, discussions. These, you know, when people are talking about the technical merits of Web Components, I'm not seeing, like, and here's why it works better for this reason. I also just really, like, the Web Components are not the future, they're the present article. man, I did not like it. I thought it was good. So, this is not a compelling argument. Like, you know, a quote from it that I pulled was like, they're not solid components, they're not React components, they're not Svelte components, they're not Vue components, they're standards based web components that work in all of the above. [41:04]
-
-And that seems like a big assertion to make when the maintainers of solid, React, Svelte, and Vue are all saying, they don't work for us. So, I feel like you can't just say, they work in all of those, when the maintainers of those frameworks are saying, they don't work. And it doesn't really argue why they work, it just kind of asserts that they do. [41:21]
-
-**Mark:** it's a little bit like a lot of the React arguments that were happening earlier this year, where there's like 30 different partially overlapping topics. And people are arguing about a different subset of them. [41:33]
-
-So, in this case, the concerns are technological, some of them are ideological. Folks who prefer web components or advocate for web components tend to be the kind of people who like frameworks. They feel that frameworks are too heavy, they feel that frameworks have bad results on the industry, they prefer to, you know, kind of stay closer to the browser, you know, they use the platform mentality, and so they see large frameworks as sort of the enemy, and so anyone who is using a framework is kind of a bad person. a lot of the vocalness here is coming from these people who's like, it's a standard,therefore it's better.These frameworks aren't standards. I don't see a lot of people in the React ecosystem, like, actively advocating against web components. more of a, whatever, we don't care.So, worth noting that, you know, Ryan's article, came from his perspective more as a framework author, and similarly, Rich Harris, the author of Svelte had a number of complaint threads on Twitter recently, where he was talking about there's a bunch of really, really weird behaviors in browsers that only exist because the web component specs demand those, and that has caused problems for him as a framework author. [42:58]
-
-Things like, Cloning domnodes requiring you to pass in an additional flag, but that makes the cloning process 30 percent slower, [43:08]
-
-**Carl:** Right. And in contrast to that, the present article says, towards the back half of it, it says, I'm not a conspiracy theorist, but I find interesting the number of people who are and have been sponsored and or hired by for profit companies whose platform rely heavily on said frameworks. [43:25]
-
-So it's like, I feel like the web components aren't working for us. Framework authors are making arguments like that. I'm taking a 30 percent performance hit because of the spec requirements to support these. Like that's a very precise technical argument. Not, I'm not a conspiracy theorist, but [43:42]
-
-**Mo:** [43:42]
-
-that sounds like, here's my friend's opinion about these guys. They're awful people. Not my opinion. I'm just quoting what my friends, I'm not a conspiracy theorist. That sounds pretty conspiracy theorist to me. [43:52]
-
-**Carl:** Yeah. It's big, just asking questions energy. we should move on though. I think Mo, you said you have to duck out. [43:57]
-
-**Mo:** I do have to leave, so I guess I can just say goodbye hereand hopefully see you all next month. So it's been a pleasure in all things react and react native and I'll see you all in the next one. [44:08]
-
-**Mark:** we've got a bunch more stuff to get through, [44:10]
-
-## [Announcing VoidZero Next Generation Toolchain for JavaScript](https://voidzero.dev/posts/announcing-voidzero-inc)
-
-**Mark:** Evan Yu, the author of View and Veet and a number of other things, Has announced a venture backed company called VoidZero, which is quote working on the next generation of JavaScript tooling This might sound a little bit familiar. [44:24]
-
-That was sort of the pitch behind the Roam tool set So in this case some of the things that VoidZero is working on correlate a lot with Things that were already in progress with the VEET framework. [44:37]
-
-## [Oxc Transformer Alpha](https://oxc.rs/blog/2024-09-29-transformer-alpha.html)
-
-## [OXC compiler](https://twitter.com/boshen_c/status/1840322879424258115)
-
-**Mark:** There's a Rust based JavaScript compiler called OXC, which also includes a linter and reusable parsers and things like that. [44:46]
-
-So I believe that's now gonna be sponsored under Void0. There's a project called Rolldown, which is going to be a Rust based re implementation of the Rollup build toolset. So eventually the goal is to really make Vite a whole lot faster, ultimately. Vite currently uses a mixture of, I believe, ESBuild for local dev builds and Rollup for production builds. [45:12]
-
-And so they're also trying to make the behavior more standard, or more similar across dev and production as well. [45:18]
-
-**Carl:** Yeah, definitely seems interesting. Always down for stuff to core dev tools to be made faster. All right, cool. [45:23]
-
-## [Updates from the 104th TC39 meeting](https://dev.to/hemanth/updates-from-the-104th-tc39-meeting-14cp)
-
-**Carl:** I'll move us on some new TC39 news. They just had a meeting and blog post I saw said four new proposals advanced to stage four and the list had five items in it. [45:33]
-
-## [Promise.try](https://github.com/tc39/proposal-promise-try)
-
-**Carl:** so there's promise. try, which is now stage four. It seems neat. It looks like it's basically a likeconvenience so that if you don't know whether a function is going to return a promise or not, you can give it to promise. try and then you can handle any errors that it emits as though it were a promise. [45:53]
-
-And the advantage of that is that, you know, if you did something like promise. resolve. then and then execute that function, which would be a great way to achieve this behavior without a change to the language that would process it on the next tick. [46:06]
-
-So it doesn't execute synchronously as, you know, line by line. It gets thrown to the event loop and then event loop comes back and executes it. So, you know, that's. Not always what you want. If you are trying not to do that, now you have a new tool to do so, which is promise. try. [46:21]
-
-## [Sync Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers)
-
-**Carl:** I also liked the sync iterator helpers. [46:23]
-
-I think we mentioned this in a previous episode. Maybe not the last one, maybe the one before. But it's. Basically letting you do stuff like map, filter, reduce on iterable objects without Spreading it into an array first Which I think creates a copy. So like this seems great. You can now map over without the cost of Producing an array from it first. [46:47]
-
-I love it. Here for it. [46:48]
-
-## [Import Attributes](https://github.com/tc39/proposal-import-attributes)
-
-**Carl:** Some other ones that I didn't talk about Think about as hard there's import attributes which I think is like metadata for describing what you're importing, something like that. [46:58]
-
-## [JSON modules](https://github.com/tc39/proposal-json-modules)
-
-**Carl:** JSON modules. So you can import JSON files as modules without, you just kind of natively. It seems good. [47:05]
-
-## [RegExp Modifiers](https://github.com/tc39/proposal-regexp-modifiers)
-
-**Carl:** as well as regex modifiers. couple of new changes, five new things to the language. Seems good. [47:11]
-
-## [Language Evolution](https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o/edit#slide=id.g30432c5cd9c_0_30) “JSSugar” proposal
-
-## [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389133810913338)
-
-## [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389157693227375)
-
-## [BrendanEich on X](https://x.com/BrendanEich/status/1842630141304025263)
-
-## [Daniel Ehrenberg thoughts](https://gist.github.com/littledan/a590784a72f2e1b8cc633ff5ff8a9dc2)
-
-**Mark:** And one other thing that came up at that meeting there was a presentation I think co authored by a number of JavaScript engine implementers at Google and Mozilla and a couple other companies. That is very long and complicated, and it's worth reading through, but as a high level summary, we've had the TC39 process for, like, 15 some years now, and, you know, we had the big bang change to the language with ES2015, and then a steady stream of new language features since then. [47:45]
-
-And the expectation is that once TC39 finishes standardizing a given feature, Every JavaScript engine out there. Is going to end up fully implementing this. Now in practice, if it's basically V8 and spider monkey from, you know, from Mozilla, that's the majority of people as far as browsers are concerned, but there are other JS engines out there as well, and implementing all these new language level features takes time and effort, some of these engine implementers were actually saying, you know what, we actually. [48:19]
-
-are thinking that maybe we shouldn't be required to implement every feature that is added to the JS language spec. Sometimes these things have performance implications, sometimes these things have actually caused security related concerns, It's not like a full blown proposal, but it's kind of like a what if we considered this kind of a thing. [48:42]
-
-what if we sort of split the JavaScript language spec into things that are actually going to be implemented by runtime engines, versus things that are in the spec, and we agree it's part of the language, But would only ever be implemented by transpilers, like Babel or ESBuild or something like that. [49:05]
-
-So that, the JS engines don't have to literally implement every finished feature ever. a number of folks felt this was probably a bad idea. I can understand some of the concerns that are being raised by the engine folks. But, splitting the language feels problematic. You know, certainly the folks who are, you know, kind of in on that, like, I don't want to have to use build tools to write my JavaScript are, are not happy about this. [49:34]
-
-But, even knowing that, you know, some of these things won't make it into the engines and might not be able to take advantage of, you know, built in optimizations feels kind of sketchy. [49:43]
-
-**Carl:** Yeah, I can definitely understand that though, like so many things, I feel like, I mean there are so many lingering polyfills and transforms and whatever that Babel and all of them are like still implementing, even though they are now part of the language, just because how do you know when it's okay to remove stuff like that? [50:03]
-
-I can understand the motivation of saying like, look, this is the reality. We are still transforming this even though technically by the spec, we don't have to. I can definitely understand why they would see, just start saying like, this is a practical reality, pragmatically, this is what's happening. the standardization process should reflect that and acknowledge that some things will just live in the transformer. [50:25]
-
-I can definitely understand that argument. But yeah, I guess that's also weird. Like it introduces a new like point of abstraction in the standardization process and like, what is JavaScript? that's weird. [50:38]
-
-**Mark:** Alright, so, now we're in and we haven't started the lightning round. So, let's try to actually make this a [50:43]
-
-lightning round, shall we? [50:44]
-
-## ⚡ Lightning round ⚡
-
-## [The Disappearance of an Internet Domain](https://every.to/p/the-disappearance-of-an-internet-domain) – .io
-
-**Mark:** Moving along. So there was an article titled Disappearance of an Internet Domain. the TLDR here is that the io domain is associated with a set of islands in the Indian Ocean owned by Great Britain and Great Britain just signed a treaty to eventually hand those islands over to you. [51:05]
-
-I think the island of Mauritania. And so based on international law, there's a chance that once this 3D handover is complete, there is no longer a separate territory. And if there's no longer a separate territory, then there's no legal reason to have a io domain associated with that. And so the article says that, you know, if we, if we've, Assume that these laws and practices get followed strictly, then hypothetically, five years from now, the io top level domain might go away completely. So that's up for grabs, but it's a legitimate concern. [51:46]
-
-**Carl:** The intersection of geopolitics and tech debt seems bad. [51:51]
-
-flying through a little bit. [51:51]
-
-## [How to control a React component with the URL](https://buildui.com/posts/how-to-control-a-react-component-with-the-url)
-
-**Carl:** So I saw a great blog post by Sam Zelikoff called How to Control a React Component with the URL. blog post makes the argument that it's a very common feature request. [52:00]
-
-I think that it is not as common a feature request as it should be because it is the power of the web. URL addressability, deep linking, being able to open a URL and have it, represent the same page that somebody else is seeing. So I think that is a phenomenal goal to seek, and so more things should behave that way. [52:17]
-
-just a pull quote from it that I think summarizes What makes that hard is the fundamental reason why we're heading down a bad road, he says that we now have two sources of truth for the search text. And that's exactly it, like, when you are writing React, you tend to have your source of truth be something in React state. [52:35]
-
-But if it's in the URL state that it exists outside of React's Awareness, you know the universe that you've created for your app that is within react the URL state lives outside of that So it's very easy to accidentally duplicate state then you have a state synchronization problem and I also want to call out that problems like that are a Wonderful example of why dogmatic best practices can really easily lead you to broken apps [52:59]
-
-Then if you use a form library, it's going to keep track of its own state. Then you have to do state synchronization between the URL and the form. That's a really easy way to get a lot of bugs. So if you follow the rule of always use a form library, you're going to run into state synchronization bugs if you try to implement this feature. [53:16]
-
-## [If WordPress is to survive, Matt Mullenweg must be removed](https://joshcollinsworth.com/blog/fire-matt)
-
-**Mark:** one more drama related item, I'm really gonna TLDR this. The WordPress community is basically blowing up right now. WordPress founder and project company CEO Matt Mullenweg went on a seemingly unprovoked rampage. [53:35]
-
-He is basically upset that one of the biggest WordPress hosting companies, quote, isn't giving back enough to the project. And there's all kinds of issues where Matt is both simultaneously the CEO of Automatic, one of the other bigger hosting companies. And the leader of the open source project and the nonprofit foundation. [53:58]
-
-And it turns out that in some cases, he's the sole person who controls some of the key websites. There's been issues with him, basically hijacking a plugin that was developed by this other company blocking people from the Slack and all kinds of other Like, he's basically blowing up their community single handedly, and seemingly for no reason. [54:22]
-
-And a lot of folks who had been very involved with WordPress are like, I can't be involved with this anymore. So, a lot of WordPress folks are actively looking to stop using WordPress and find something else. There's an extremely long, very well written post that lays out a lot of the details linked in the chat, called, If WordPress is to survive, Matt Mullenweg must be removed. [54:45]
-
-It's long, it's complicated, but it's also a very thorough look at everything that's happened. [54:50]
-
-**Carl:** Yeah. Oh man, there's so much to get into. There's so much that could be said about this, but yeah, it's,oh, this has been, this has built its own cottage industry of podcasts and interviews and blog posts. Yeah. It's also not really React. WordPress developer is like an entirely separate thing from web developer. [55:06]
-
-So yeah, it's kind of not related to our main topic. [55:09]
-
-## [Web Without Walls — Dan Abramov](https://www.youtube.com/watch?v=F1sJW6nTP6E)
-
-**Carl:** we've had a couple of tangential references to Blue Sky. I love Blue Sky, I think it's really cool, I've been on it for like over a year because Twitter sucks and meh, I have opinions. [55:20]
-
-But so Dan Abramov, who I'm sure some of you may have heard of once or twice, gave a really great talk. he's currently working at BlueSky as an app developer which is, I'm actually interested to speak with him a little bit more about that kind of transition because he went from core team, building React to now React consumer and I think that is just such a relatively rare Transition to make and I'd be really curious to hear not just like what he thinks about that transition as someone who's made it But also what Dan Abramov thinks of that as a very clear thinker and clear speaker butwe gave a really great talk about the app protocol, which is the underlying technology that BlueSky is built on top of and it hits a lot of really cool things that I personally have been thinking about for a decade about the future of social media and data portability and federated access. [56:14]
-
-not just social graphs, but also to the actual data. I just think it's really cool. Like, I saw some people talking about, like, Oh, it doesn't matter if you have You know, you can always export the social graph because you have your contacts list. And like, that doesn't really matter. [56:28]
-
-It doesn't matter if you have the social graph, if you have the connections between the people. If the people are not producing content, you know, if they're not interacting with each other on that platform. And I would boil down this hour long talk that Dan gave that is really good. And I think you should watch if you're interested in social media and building apps on social platforms. [56:47]
-
-It really comes down to, like, it's not just an open source Twitter clone. It is an open network that people are publishing Twitter like data to, and no one can close your app off. You know, there is no way for something like the, Twitter X API Shut down, the Reddit API shut down. [57:10]
-
-You can't do that because it's built on a federated decentralized protocol. it's not just a proprietary API. So yeah, I think that's really cool. This is a really interesting thing. I think this is going to be a generational shift in how social media operates. So yeah. [57:23]
-
-## [Preact compat discussion](https://old.reddit.com/r/reactjs/comments/1fy2jjh/i_ran_into_preacts_false_promise_what_can_i_do/)
-
-**Mark:** There was a Reddit discussion thread going and was looking into the compatibility of Preact with, you know, actual React and debating some of the pros, cons, and trade offs. And since Preact has been traditionally pitched as a React compatible library, worth looking at. [57:43]
-
-**Carl:** Yeah. [57:44]
-
-## Content-visibility in CSS
-
-## [Using CSS containment](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Using_CSS_containment)
-
-**Carl:** There's some interesting stuff with CSS containment. It seems pretty, like, wonkish, deep in the weeds stuff to properly understand, but it looks really interesting as, like, a performance optimization for rendering. [58:00]
-
-## [contain](https://developer.mozilla.org/en-US/docs/Web/CSS/contain) [CanIUse](https://caniuse.com/mdn-css_properties_contain)
-
-**Carl:** The bulk of it, as I saw in researching it for, you know, an hour and a half, I haven't really used it yet, is there's a contain and a contain visibility, you know, a CSS attribute now, that let you signal more precisely to the browser renderer, how much effort to dedicate to rendering a particular part of the page. [58:19]
-
-So, you know, like, how I'm making sense of this is in React, if you're trying to choose whether or not to render something, for a long time the decision has been kind of like, conditional rendering, like, is the DOM in the page at all, or, like, display none. [58:34]
-
-And you know, there's a lot of other, like, subtle variations around that, like, should it live in the accessibility tree as well, like, You know, there's a lot of subtle nuances to that. So this adds a lot more subtle nuances. Very exciting. But yeah, so it looks really interesting. It lets you constrain So that's kind of part of it, but it's also a little bit on like sandboxing. Like, I guess the contain element is maybe a little bit more on sandboxing. It's like, if you were to like render an ad into your page, you might be able to do it using this instead of an iframe. [59:07]
-
-So, and still maintain the same kind of strong guarantees about how it behaves on the page, how it looks on the page. [59:16]
-
-**Mark:** someone in the chat just said it's like, it's kind of like Shadowroot, and I think that's a little bit, like, along the right lines. Like, you're telling the browser that elements inside here aren't going to have layout interactions with the rest of the page. [59:28]
-
-So, like, whereas, a normal element, depending on your CSS, might, interact or overlap or something with other parts of the page, might cause the browser to do, a bunch of additional checks against other DOM nodes to see if they in some way. And so contain tells it, nope, anything under here is scope, you don't have to waste time and effort checking locations versus the rest of the page. [59:50]
-
-## [content-visibility](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) [CanIUse](https://caniuse.com/mdn-css_properties_content-visibility)
-
-**Carl:** Yeah, and something else they shout out in the docs about it is, like, really long pages using it to optimize, you know, rendering performance. If you've got a massive, massive amount of HTML, then just saying, like, nope, this is off screen, like, don't render it. If that makes sense they were saying that that would help you maintain performance on a huge page. [01:00:07]
-
-But it also talks about like reducing layout shift. So I wonder if that is actually going to be like practical and useful, or if it just would just be like too weird to have to, I've, I've had to do that kind of performance optimization and. Cracking the size of the content being rendered so that you don't have it, like, you scroll down, something goes out of view and then like gets, stops being rendered and then everything on the page shifts. [01:00:31]
-
-So you have to keep like scroll because what you were looking at just changed. I, I don't know. I don't know if that advertised benefit will actually be real. I don't trust it. [01:00:39]
-
-## [How I Built My Blog • Josh W. Comeau](https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2/)
-
-**Carl:** We mentioned Josh W Comeau earlier. He has put out a great blog post. How I built my blog. Looks pretty interesting. [01:00:45]
-
-I, I just always appreciate little technical write ups of things like this. [01:00:49]
-
-**Mark:** and like, it's more than just the blog. I mean, I think he goes into some details about the developer, the education platform and whatnot. But Josh always puts such care and effort into everything he builds. [01:01:03]
-
-**Carl:** Yes, a consummate crafts person. So yeah, it's a good write up. He's very thoughtful about how he builds and how he writes. So this is really great. I have also built a large documentation site for a previous employer. And as I was reading this, I just saw so many problems that I remember dealing with in that. [01:01:19]
-
-Like he talks about, you know, authoring content in MDX and the kind of weird errors you get when doing that. He talked about like doing syntax highlighting with Prism and how it can really explode complexity of, you know, just the amount of HTML on a site, which is a problem I had I built this whole thing, put all of this documentation on a single like API reference massively tall site and oops, it's 12 megabytes of just HTML. [01:01:45]
-
-So I ended up having to like totally re architect how the syntax highlighting was happening because just it totally exploded the amount of HTML on the page. so he talked about using, like updating to the latest version of MDX and using Sheeky which is like a server side, Syntax highlighting tool that seemed pretty interesting and definitely sounded like it would have solved some problems. [01:02:04]
-
-I had a couple years ago And he also referenced he's got a like interactive rainbow on the home page And You can edit how it behaves and that behavior gets synchronized across all viewers of the site simultaneously through PartyKit, which is near and dear to my heart. I helped set up their community a couple years ago. [01:02:23]
-
-cool. It's a good read, [01:02:24]
-
-**Mark:** All right. [01:02:24]
-
-## [Types of React Components [2024]](https://www.robinwieruch.de/react-component-types/)
-
-**Mark:** And the final item for today Robin Wierich is another prolific React educator and author of useful tutorial learning blog posts. Thanks. And he put up a post called Types of React Components in 2024. it's actually a bit of a history lesson. It goes back and looks at the old style create class and mixins, the still newer but by now out of date class components, the higher order components pattern, and then the relatively modern function components, server components, and async components. [01:02:58]
-
-So it's not something that's necessarily going to teach you to do things, but it's a useful look at and sort of like the evolution of React over the years. [01:03:06]
-
-**Carl:** And apparently this is part of a whole series that he's doing updating his most popular blog posts for 2024. generally, I saw a couple of other ones and I wanted to add them, but I, oh god, we already had so many links. So, yeah. Definitely go check those out. he's a great writer. I have been reading his blog for 10 years and he just keeps putting out bangers. [01:03:29]
-
-So yeah, definitely check it out. [01:03:31]
-
-**Mark:** right. I think we're actually at the end. [01:03:33]
-
-**Carl:** We are at the end. We've made it. Oh my God. You guys, you're still here with us. Thank you for sticking around for 80 minutes. Thank you so much for joining us. We'll be back on the last Wednesday of next month here at the live stage in Reactiflux or back in your podcast feed just as soon as we can. [01:03:48]
-
-Lennart, [01:03:49]
-
-**Mark:** Yeah. I got nothing this week other than I am diving into working on some RTK query features, specifically infinite queries, which is a complex thing that I didn't know about and I'm thankful that we're basing it off of how React query works. So My side project for a while. [01:04:08]
-
-**Carl:** That was fun. Cool. We gather sources from ThisWeekInReact, Bytes. dev, React Status, Next. js Weekly, React. js, Subreddit and here in Reactiflux, mostly from the tech reads and news, If you see anything that you feel like we should talk about feel free to send it to us via email to hello at reactiflux dot com T M I R in the subject line. [01:04:28]
-
-Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/) Help them know how smart you are. Alright, see you later.
diff --git a/src/transcripts/tmir-2024-11.md b/src/transcripts/tmir-2024-11.md
deleted file mode 100644
index 3196344..0000000
--- a/src/transcripts/tmir-2024-11.md
+++ /dev/null
@@ -1,723 +0,0 @@
----
-title: "TMiR 2024-11: React 19 is unblocked, Next 15 is 'stable', Expo launch week. The cool kids are on BlueSky"
-date: 2024-11-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:35](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- New releases
- - [[01:51](#vscode-195)] [VSCode 1.95](https://code.visualstudio.com/updates/v1_95)
- - [[02:20](#node-v23)] [Node v23](https://openjsf.org/blog/announcing-node.js-23-key-features-and-enhancement?ck_subscriber_id=1888282043)
- - [[04:12](#docusaurus-36)] [Docusaurus 3.6](https://docusaurus.io/blog/releases/3.6)
- - [[04:40](#react-navigation-70)] [React Navigation 7.0](https://reactnavigation.org/blog/2024/11/06/react-navigation-7.0/)
- - [[04:46](#better-auth-v10)] [better-auth v1.0](https://www.better-auth.com/v1)
- - [[05:06](#mantine-v7140)] [Mantine v7.14.0](https://mantine.dev/changelog/7-14-0/)
- - [[05:14](#storybook-84)] [Storybook 8.4](https://storybook.js.org/blog/storybook-8-4/)
- - [[05:22](#gatsby-v514)] [Gatsby v5.14](https://github.com/gatsbyjs/gatsby/releases/tag/gatsby%405.14.0)
- - [[05:34](#rspack-11)] [Rspack 1.1](https://rspack.dev/blog/announcing-1-1)
- - [[05:39](#angular-beat-react-to-v19)] [Angular beat React to v19](https://blog.angular.dev/meet-angular-v19-7b29dfd05b84)
-- [[05:57](#conferences)] Conferences
- - [[06:06](#react-day-berlin)] [React Day Berlin](https://reactday.berlin/) Berlin, DE Dec 13 & 16
-- [[07:39](#main-content)] Main Content
- - [[07:39](#react-19-rc1)] React 19 RC1
- - [[08:17](#tech-writeup-of-a-solution-to-the-sibling-rendering-issue-that-delayed-react-19s-release)] [Tech writeup of a solution to the sibling rendering issue](https://github.com/facebook/react/issues/29898#issuecomment-2477449973) that delayed React 19’s release
- - [[11:27](#nextjs-15)] [Next.js 15](https://nextjs.org/blog/next-15)
- - [[15:25](#ts-57)] [TS 5.7](https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/)
- - [[19:48](#react-router-v7--remix)] [React Router v7 | Remix](https://remix.run/blog/react-router-v7)
- - [[24:28](#vite-v6)] [Vite v6](https://vite.dev/blog/announcing-vite6.html)
- - [[24:50](#environment-api)] [Environment API](https://github.com/vitejs/vite/discussions/16358)
- - [[27:52](#expo-launch-party)] [Expo Launch Party](https://expo.dev/launch-party)
- - [[28:19](#the-magic-of-expo-dom-components)] [The magic of Expo DOM Components](https://expo.dev/blog/the-magic-of-expo-dom-components)
- - [[32:24](#introducing-workflows-cicd-built-for-your-app)] [Introducing Workflows: CICD built for your app](https://expo.dev/blog/expo-workflows-automate-your-release-process)
- - [[33:33](#environment-variables-in-eas-new-changes-to-simplify-setup)] [Environment variables in EAS: new changes to simplify setup](https://expo.dev/blog/environment-variables)
- - [[36:59](#expo-sdk-52)] [Expo SDK 52](https://expo.dev/changelog/2024/11-12-sdk-52)
- - [[40:10](#new-css)] New CSS
- - [[40:14](#a-friendly-introduction-to-container-queries)] [A Friendly Introduction to Container Queries](https://www.joshwcomeau.com/css/container-queries-introduction/)
- - [[41:05](#a-framework-for-evaluating-browser-support)] [A Framework for Evaluating Browser Support](https://www.joshwcomeau.com/css/browser-support/)
- - [[43:48](#state-of-css-2024)] [State of CSS 2024](https://2024.stateofcss.com/)
- - [[47:02](#framework-betas:)] Framework betas:
- - [[47:08](#rsc-in-expo-router-is-now-in-beta!)] [RSC in Expo Router is now in Beta!](https://expo.dev/blog/universal-react-server-components-developer-preview)
- - [[47:29](#tanstack-start-beta)] [TanStack Start beta](https://tanstack.com/router/latest/docs/framework/react/start/overview)
- - [[49:14](#react-native-077-rc0)] [React Native 0.77 RC0](https://github.com/facebook/react-native/releases/tag/v0.77.0-rc.0)
- - [[50:02](#new-list-dropped-in-react-native)] [New List dropped in React Native](https://x.com/jmeistrich/status/1855663310386958840)
- - [[51:45](#twitter---bluesky-migration)] Twitter -> Bluesky migration
- - [[54:54](#starter-packs-ericclemmonsawesome-starter-packs-stevendborrellibluesky-tech-starter-packs-bluesky-directory-a-complete-guide-to-bluesky-)] [ericclemmons/awesome-starter-packs](https://github.com/ericclemmons/awesome-starter-packs), [stevendborrelli/bluesky-tech-starter-packs](https://github.com/stevendborrelli/bluesky-tech-starter-packs), [A complete guide to Bluesky 🦋](https://mackuba.eu/2024/02/21/bluesky-guide/)
- - [[55:13](#technical-debate-over-how-decentralized-bluesky-actually-is)] [Technical debate](https://dustycloud.org/blog/how-decentralized-is-bluesky/) over [how “decentralized”](https://whtwnd.com/bnewbold.net/3lbvbtqrg5t2t) Bluesky actually is.
- - [[55:57](#web-without-walls--react-universe-conf-2024)] [Web Without Walls | React Universe Conf 2024](https://www.youtube.com/watch?v=F1sJW6nTP6E)
-- [[59:03](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[59:06](#deno-v-oracle-canceling-the-javascript-trademark)] [Deno v. Oracle: Canceling the JavaScript Trademark](https://deno.com/blog/deno-v-oracle)
- - [[59:27](#two-ways-to-the-two-reacts)] [Two ways to the two Reacts](https://bobaekang.com/blog/two-ways-to-the-two-reacts)
- - [[59:52](#thats-not-an-abstraction-thats-just-a-layer-of-indirection)] [That's not an abstraction, that's just a layer of indirection](https://fhur.me/posts/2024/thats-not-an-abstraction)
- - [[01:00:04](#react-anti-pattern-stop-passing-setters-down-the-components-tree)] [React Anti-Pattern: Stop Passing Setters Down the Components Tree](https://matanbobi.dev/posts/stop-passing-setter-functions-to-components)
- - [[01:00:31](#what-is-http3)] [What is HTTP/3?](https://www.cloudflare.com/learning/performance/what-is-http3/)
- - [[01:01:03](#leaked-vercel-v0-system-prompts)] [Leaked Vercel v0 system prompts](https://old.reddit.com/r/LocalLLaMA/comments/1gwwyia/leaked_system_prompts_from_v0_vercels_ai/)
- - [[01:01:59](#react-scan-to-highlight-component-renders-by-the-author-of-millionjs-which-he-used-to-point-out-githubs-code-view-re-rendering-on-every-scroll)] [React Scan to highlight component renders](https://react-scan.million.dev/) (by the author of Million.js), which he used to point out [Github’s code view re-rendering on every scroll](https://x.com/aidenybai/status/1859267710498263073)
- - [[01:02:56](#whats-next-for-the-react-compiler)] [What’s Next for the React Compiler?](https://www.youtube.com/watch?v=qd5yk2gxbtg)
- - [[01:03:14](#framer-motion-spinning-out-as-an-oss-tool-motion-and-conversely-gsap-is-joining-webflow)] [Framer Motion spinning out as an OSS tool (Motion)](https://motion.dev/blog/framer-motion-is-now-independent-introducing-motion), and conversely [GSAP is joining WebFlow](https://gsap.com/blog/webflow-GSAP/)
-
-**Carl:** Hello everyone. Thank you for joining us for October's This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem come and do live out of Reactiflux, the place for professional React developers and supported by Infinite Red a React Native consultancy, but more about them later. [00:18]
-
-I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like events like this. And build some tools to help keep the community operating smoothly. [00:31]
-
-**Mark:** I'm Mark. My day job is working at Replay, which is a time traveling debugger for JavaScript, and outside of that I do way too much Redux stuff. [00:38]
-
-**Mo:** And I am Mo. I head the mobile team at Theodo. I am an active, semi active part of the React Native community. And I organize the React Native London conference and the meetups and sometimes dabble in open source with libraries like Expo and Tamagui. [00:54]
-
-**Mark:** If you're only semi active, what qualifies as active? [00:57]
-
-**Mo:** I don't know. I, I feel like I'm less active than I was a few months ago. Maybe I just need to take a little bit of a break and become reactive. [01:05]
-
-**Mark:** You just ran a conference! [01:07]
-
-**Mo:** Yeah, maybe that's taking most of my energy out of my sails. [01:10]
-
-**Carl:** Yeah, right. I think organizing a conference gives you a little bit of a pass on other contributions. That's a lot. That was a [01:16]
-
-**Mo:** Yeah, it was it was a fun time. Intense, but fun time. [01:19]
-
-**Carl:** All right. Jumping into some quick hits. I'm gonna change up the format a little bit. The last couple months we've had so many new releases that new releases are just mostly part of the content now. But I'm gonna run through some quick new releases with like, no discussion. Just like, this is out, go check it out if you want. If it's relevant to your life. [01:35]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** But job market stuff looks pretty steady state compared to last month. Like, layoffs. 23andMe has laid off a couple of folks. But, generally seems to be pretty stable again. not much to say there. Okay. [01:50]
-
-New releases, lightning mode. [01:51]
-
-## [VSCode 1.95](https://code.visualstudio.com/updates/v1_95)
-
-**Carl:** VS Code they released like every, I don't know, six weeks, something like that. They've got VS Code 1. 95, which mostly looks like it brings out co pilot things. thing that caught my eye the most was you can add multiple files to like a working set, they call it, in the co pilot AI assistant stuff. [02:10]
-
-So that seems kind of neat. I haven't used the copilot very much, but being able to say, here are the files that are relevant. Please do this for me. That seems neat. That seems cool. [02:20]
-
-## [Node v23](https://openjsf.org/blog/announcing-node.js-23-key-features-and-enhancement?ck_subscriber_id=1888282043)
-
-**Carl:** There is a new version of Node, Node 23 Which means Node 22 is now LTS Two things caught my eye that seemed neat Biggest one is they now have native support for loading ES modules using Require. [02:37]
-
-this seems like a huge compatibility bridge between common JS and ESM, which has been a pain point for like five years, literally since the ES modules were released. So that's cool. It's been experimental for a long time and is now no longer experimental. It's just stable. So that's cool. [02:54]
-
-They also added a native, flag to node, the node executable to run your package. JSON scripts. So no longer do you have to do NPM run. Now you can do node dash dash run. Which is just kind of cool. that was like a weird coupling between NPM and node. So like moving that into the runtime just kind of makes sense to me. So cool. Just especially while we have more variation in like runtimes and, Package management [03:19]
-
-**Carl:** tools and whatever. [03:20]
-
-**Mark:** I agree that Node having support for being able to use require to pull ESM modules into CommonJS a huge thing. I think you could do it the other way around where you could import CJS files, apparently. I'm still hazy on that one. But in general, the interop panes between ESM and CommonJS in Node have been the big barrier and reason why package maintainers like myself have had to go through shenanigans trying to get our packages defined and published properly with multiple different artifacts inside. [03:58]
-
-As always, the fact that a new version of Node. js has support for this doesn't mean we'll be able to drop that immediately because, you know, the long tail but at least it's a step in the right direction. [04:12]
-
-## [Docusaurus 3.6](https://docusaurus.io/blog/releases/3.6)
-
-**Carl:** DocuSource put out 3. 6. It's faster apparently. Seems good. [04:16]
-
-**Mark:** Apparently that's because they did switch from using Webpack to using RSPack, which is, it's effectively Webpack. But rebuilt in Rust, so it's like public API compatible. So, an example of a migration path to get faster build tools without having to sort of switch which build tool ecosystem you're in. [04:40]
-
-## [React Navigation 7.0](https://reactnavigation.org/blog/2024/11/06/react-navigation-7.0/)
-
-**Carl:** React Navigation put out version 7 if you're in React Native World. [04:46]
-
-## [better-auth v1.0](https://www.better-auth.com/v1)
-
-**Carl:** A project I've mentioned at least once on this show for authentication, BetterAuth, is at 1. 0. They've been doing a really fast, rapid release cycle, I've noticed. like, last month they were on version, 0. 6 and then they did, like, 0. 0. 9, and now 1. 0. So, cool. Seems good. Love authentication. And it seems like a good project for it. [05:06]
-
-## [Mantine v7.14.0](https://mantine.dev/changelog/7-14-0/)
-
-**Carl:** Mantine put out version 7. 14. Seems like a decent UI toolkit. [05:14]
-
-## [Storybook 8.4](https://storybook.js.org/blog/storybook-8-4/)
-
-**Carl:** Storybook has 8. 4. I have opinions about Storybook. I don't use it. But hey, if you do, they are talking more about like testing and stuff. [05:22]
-
-## [Gatsby v5.14](https://github.com/gatsbyjs/gatsby/releases/tag/gatsby%405.14.0)
-
-**Carl:** Throwback Gatsby released version 5. 14. It's out. [05:28]
-
-**Mark:** genuinely surprised anyone's still working on it. [05:30]
-
-**Carl:** Gatsby is still here. It still exists. Me too, a little bit, [05:34]
-
-## [Rspack 1.1](https://rspack.dev/blog/announcing-1-1)
-
-**Carl:** RSPack put out 1. 1. We talked about version 1 release Recently. [05:39]
-
-## [Angular beat React to v19](https://blog.angular.dev/meet-angular-v19-7b29dfd05b84)
-
-**Carl:** And amusingly, Angular has released version 19, beating React to the punch. Nothing that means anything, but yeah, well, Angular's got a new major version out. [05:50]
-
-I saw they're looking to revise their style guide, which is apparently 52 pages long currently. So that's ridiculous. [05:57]
-
-## Conferences
-
-**Carl:** Yeah, conferences. Mo, you wanna talk? [06:00]
-
-**Mo:** Yeah, sure. So, we're reaching the end of the year, which means conferences are going into hibernation mode as expected. [06:06]
-
-## [React Day Berlin](https://reactday.berlin/)
-
-**Mo:** But we've got one more left for you all this year, React Day Berlin. And React Day Berlin happens in December every year. It's a really cool gathering of people. I was there last year and I'll be doing a talk this year with a friend of mine from Amazon, Anisha Malde, about universal React, so it's a, it's a great of React people. [06:25]
-
-They have a really cool venue called Cosmos It's a really historical city. If you're in Europe, I'd recommend you come around. It's, it's a good time. [06:32]
-
-**Carl:** And it's on my birthday, so I'm not going. [06:34]
-
-**Mo:** Happy birthday, Carl. Early birthday. Very early birthday. [06:38]
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl:** All right, sponsor time. We are sponsored currently exclusively by Infinite Red. They're an expert React Native consultancy that's been around since 2015. Coming up on 10 years, wild. They're our only sponsor in part because very few companies do as much as they do for the React Native ecosystem. [06:55]
-
-And so just really happy to be a part of it. Have a earnest collaborator in that kind of way. Yeah, I've seen their name around for as long as I've heard about React Native being used professionally. They only do React Native and have built over 75 apps for companies from startups to like the biggest fortune, whatever companies in the world. [07:13]
-
-than being great people who I'm happy to collaborate with, be sponsored by they're a team of about 30, mostly developers, mostly with more than 10 years of experience. And they work alongside your team to help you develop expertise in React Native. So if you are working for a company, spinning up a new product with React Native, and want to hit the ground running, definitely give them a ring. [07:36]
-
-Infinite. red is the website. Cool, all right, [07:39]
-
-## Main content React 19 RC1
-
-**Mark:** so we actually have a very, very big Big development if you've been paying attention the last few months, we've been tracking that the React 19 release has got delayed because of concerns over changes to suspense behavior when multiple sibling components all want to suspend you know, the change had been made last fall, the community pointed out problems with it, Back in the spring, and the React team said okay, fine, we'll hold on React 19 until we can come up with a solution for this issue. Well, the good news is, that fix is actually done and out as a new React 19 RC. [08:17]
-
-## [Tech writeup of a solution to the sibling rendering issue](https://github.com/facebook/react/issues/29898#issuecomment-2477449973) that delayed React 19’s release
-
-**Mark:** And the React team put together a very good visual and technical explanation of what they changed and how the behavior works. They're in the GitHub issue link, so I highly recommend taking a look at that. Big picture is that the original behavior as of 18, if you had multiple sibling components that all wanted to suspend, was it kind of acted like a promise. [08:40]
-
-all, Where, in one render pass, it would kick off all of them, wait for them all to complete, and then actually show the content. The change that effectively broke things was it would render the first child that's suspended, see it, and say, oh, wait, let's wait for that one to complete, then pick up with the siblings, making it more like a serial for loop. [09:05]
-
-And the new behavior is when that first child suspends, It will go ahead and show the fallback, but it will kick off kind of a pre warming step in the background. So like, not like a complete render, but I guess kind of like a partial render, enough to kick off the requests. So that at least the other requests are in flight right away. [09:29]
-
-And so the overall behavior should be at least as good as it originally was, if not maybe actually kind of better. In, in some certain ways. So the two key takeaways here are that the, you know, the suspense behavior that people were concerned about has been addressed. It did take them a few months, but they, they did it in a comprehensive way, not just slapping in a bug fix. [09:52]
-
-And also that hopefully React 19 final is very, very close. There's still no specific timeline, but they did make the comment that we hope to publish 19 stable. Boy, [10:03]
-
-**Carl:** Yeah, and just maybe to restate what you were saying in different words, so my understanding of like the problem that they introduced and why they introduced it is Like you said previously, it was just sort of rendering all of the siblings before it handled the suspense. [10:18]
-
-And that was undesirable because it introduced latency before the fallback would be rendered. It did a bunch of work before showing the fallback. So they wanted to change it so that the fallback would be shown quicker, but caused requests to behave as a waterfall rather than kicking off in parallel. [10:36]
-
-It would kind of waterfall shape of your component tree. If you had requests being kicked off by like child components and sibling components and stuff and so now they managed to find like a happy balance where they don't do all of the work of rendering, you know doing the I'm fuzzy on the terminology around like commits and rendering and all that so I can't speak to precisely there [11:00]
-
-**Mark:** someone had a blog post that explained these things. [11:03]
-
-**Carl:** I read that but many moons ago, yeah, so it's a nice Midpoint between what it used to do and what they wanted it to do and now it works correctly. [11:13]
-
-So yeah, They delayed it back in June and they now have a fix So, you know, only a couple of months delayed. It's only all year that we've been talking about React 19. So maybe it'll be released soon. moving on. [11:27]
-
-## [Next.js 15](https://nextjs.org/blog/next-15)
-
-**Carl:** Next. js has version 15, out and stable. You know, they call it out and stable, but I don't know, it's stable version is like using of the big changes is using like React 19. RC in the apps router, the app router. And so that still feels to me like the proving ground for React 19. [11:50]
-
-So calling Next. js 15 stable when it's recommending that you use an unstable version of React feels funky to me. Feels like a, like a workaround to the problem of people don't test, you know, release candidates, so they're just going to call it stable. [12:06]
-
-But yeah, I'm not sure that I personally would base a production system off of the app router in Next 15 because it just, because of that, it feels like a beta, beta is maybe too strong, but it feels like they're still exploring. claim it's stable, I don't know what sort of underlying technical issues might cause things to have to be changed. [12:27]
-
-**Mark:** This touches on multiple different aspects that we've talked, at least I think we've talked about previously. One is that, you know, especially with all the server component stuff, the React team used to be able to, pre alpha test all their ideas internally at Facebook, but they can't do that with server components because it relies on having a separate server, and Facebook has all their own server, which is one of the reasons they ended up collaborating with Vercel. [12:55]
-
-To be like, they convinced Vercell to go with their vision, but also it conveniently aligned with, we need someone who doesn't have Facebook server infra to let us build out server components and prove that it works. Along with that the app router has always used a pre release version of react. [13:14]
-
-Like this. Like, even before they came up with the Canary system, it was using, assorted, experimental, unstable builds. And so, haven't been keeping track of which version specifically, but, I would assume that over the last year, versions of Next 14 have been using, you know, React 19 Canaries, betas, RCs. [13:36]
-
-So, if anything, it's, More stable now than it was a year ago. But part of the point was that, the App Writer needs all this new functionality in 19 in order to work. And the whole point of the Canary system was that, well, even if it's not fully 100 percent stable stable as a standalone release, frameworks like Next are able to paper over the rough edges so that from their point of view and from the consumer's point of view, It's stable. [14:05]
-
-So, I agree that the versioning system is funky, but it's also not a new thing. [14:10]
-
-**Carl:** Right. Definitely not new for sure. But yeah, if you're doing a little side project, probably fun to play with. If you're a founding engineer at a new company, I'm not sure I would start a new thing on it. It's not sure I would start a new revenue generating entity on it. [14:25]
-
-So, yeah, one new thing that they introduced is an instrumentation. js file, hook, I don't know. It's a place where you can plug in to the core, like, network level of the system. Next. js for things like observability and monitoring. [14:43]
-
-So that seems pretty cool. I think that is one of those like quiet underrated things that every app needs and that is not always super easy to figure out how to fit it in. In the past, I have done a fetch wrapper that introduced things like performance metrics and observability and stuff. So just having that as like a a framework feature in Next. Makes a lot of sense to me. Glad to see it. [15:07]
-
-They also put out a, a form component, which seems like it overlaps with like the native behavior that the native form enhancements that React 19 is introducing, so I'm a little bit fuzzy on like what that abstraction is super duper for, but yeah, it's there. [15:22]
-
-Cool. On to TypeScript. [15:25]
-
-## [TS 5.7](https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/)
-
-**Mark:** So, the TypeScript release chain also keeps chugging along. I think they do releases every two or three months. And so we're now up to TypeScript 5. 7. There are a couple nice to haves, like checking for variables that never got initialized, like borderline winter. Related stuff, but at the types level. The, the interesting thing from an ecosystem perspective the story around, you know, how TypeScript interacts with module output and file paths has always been very complicated, because it's always been very complicated at the JavaScript level. [16:00]
-
-And one of the things that had been kind of a pain point, weird point, frustration thing was that even when you were writing, like, Writing TypeScript files in order for some ES module, you know, import behavior to work properly, your imports still had to say you were importing from a js file in the import path. [16:25]
-
-And that always felt really weird. It's like, yes, I realized that's what is actually executing at runtime and that the build output is a bunch of js files, but the file name I'm, but with the file that I'm writing this in is a ts file. Like this, this doesn't make sense. This is weird. I don't want to have to do this. [16:45]
-
-And the TS team had resisted trying to make changes here because after the first couple of years of doing TypeScript features that required actual separate output, like enums, they're now very much on board with like, we are a superset of the JavaScript language and the compiler doesn't do anything to have to rewrite the actual behavior of your code. [17:11]
-
-But they appear to have actually added a mode that will change import path names. So when you have an import that says import from something. ts If this flag is enabled, it will rewrite that to say import something from a js. It only does this in certain conditions where it's a relative path and not, and not a, like a globally scoped path. [17:41]
-
-I, I don't pretend to understand the rationales behind it. I'm mostly just going off the release notes here. So, it seems like a rather grudging Decision to tweak things in favor of better ecosystem interop. [17:54]
-
-**Carl:** this feels very much like stuck between a rock and a hard place in that, like, Now there are more and more ways to run your TypeScript code without doing a full compilation pass, sending it fully through the TypeScript compiler, TSC, It's an intersection of like, there are more ways to run your code without fully compiling it and executing the built output. And there are more ways to, or rather, imports are getting stricter about file extensions and just like, Ooh, oh no, what do you do with that? Those are like incompatible assumptions. [18:29]
-
-this seems, I agree, this seems like a grudging, I don't know if I want to call it a hack fix or a band aid or something, but like, just even as they're talking about it in the release notes, it's, I feel like I can sense their trepidation and like angst over, like, you know, like a quote from it is like, you might need to use conditional exports with scoped custom conditions to make this work for like absolute paths, like if you're using, you know, your TS config to, you know, import, you know, structure and not use relative paths and it's just like, Oh no, that's [18:59]
-
-**Mark:** so thrilling, [19:01]
-
-**Carl:** Right! [19:01]
-
-It's like, oh god, that's, this sounds like a whole new problem. they're trying to fix a problem. They may introduce more problems. I think this is going to be painful for a long time. [19:11]
-
-**Mark:** but it's there. If you feel you need this. [19:14]
-
-**Carl:** maybe you do. Yeah, I don't know. Anyway, seems, seems rough. V8 introduced compile caching, which allows runtimes to reuse some of the like JIT compilation steps. So TypeScript is taking advantage of that new V8 feature to improve its startup time. They talked about, you know, if you do like TSC dash dash version, it now prints faster. [19:38]
-
-So like, that's cool. That's nice. Startup time is definitely a pain point for Node generally, JavaScript generally. And that's nice. Less latency. [19:48]
-
-## [React Router v7 | Remix](https://remix.run/blog/react-router-v7)
-
-**Carl:** Cool, okay, moving on. React Router v7 slash, you know, the one with Remix. headline, big pull quote, " We encourage all Remix v2 users to upgrade to React Router v7." This seems really neat. I want to play more with this, but I think really playing with it is going to take a lot. I have an app in mind that I want to try and move over. [20:12]
-
-It's currently using Remix 1, so I can upgrade to 2 and then upgrade to React Router 7. Woo! Multistage upgrades. Yeah, the big highlight here, I guess, is that Essentially, I think my mental model for understanding this change, you know, Remix to React Router is what was Remix is now Framework Mode in React Router. [20:34]
-
-So you can still use React Router as you always have, as just like a library. Or you can use it in Framework Mode, which has a Vite plugin to get more control over, you know, the build step, the compilation, which is what used to be Remix. So it feels like they explored a lot of like API surface area. [20:55]
-
-Like, how do we fix this? How do we make this work correctly as we want it to with Remix? And then it feels like they got it, they got it where they want, they refined it to where it was just kind of an abstraction over existing build tools. Like that was the big push to not have like, you don't interact with Remix, you interact with Vite and there's a plugin that is Remix. [21:15]
-
-And so now this feels like the next logical step there where like it is truly just an agglomeration of existing tools that you can choose how to use in the way you want. I think that's pretty neat. That seems pretty cool. I definitely want to play with this a lot more. [21:27]
-
-**Mark:** as I roughly understand the sequencing, so Remix itself was originally based on ESBuild, and there was no way to really mess with that configuration. Then they managed to come up with a Vite plugin, which did the same thing. And then the Vite plugin, I guess, became the default way to use Remix. [21:44]
-
-And now that it's like, well, at this point, there actually isn't much left that's specific to Remix the framework. It's all in the plugin. And so that enabled them to help take some of this, and take basically all this functionality, back into React Router, the library. And so as you said, there's the client side piece, which has always been there, and then it's like, well, all this stuff that used to be server related, and used to be specific to the Remix framework, is now encapsulated in the Vite plugin, so it's just there if you want to use it. [22:14]
-
-**Mo:** I mean, it's quite interesting because I feel like this idea of, frameworks being almost add ons or plugins to the bundler, whether it's Vite, I guess I've seen this with Vite only, is quite an interesting premise and I think it's picking up a little bit, maybe almost as a response to how Next. js is such like a, tightly It's not proprietary, but proprietary like piece of software where you're like really buying into Next rather than buying into the tools that are, you know, underlying Next. [22:43]
-
-And I see that with the new React Native Framework One as well, where it's really kind of, it's a Vite plugin. Everything's on Vite and we're building on top of Vite and we have some extra functionalities that comes out if you want to use it as kind of a framework. So it's interesting to see how this shift from the Remix team has had, I think, probably reverberations across to other, parts of the ecosystem. [23:04]
-
-I guess the question that I still have is, why have they done this from a branding perspective? Like, it seems like a lot of brand capital that they probably had in Remix Is, kind of disappearing by going into React Router. Now you could argue whether or not that's good brand capital or not, because Remix has had its fair share of controversies. [23:22]
-
-it's an interesting move for me. [23:24]
-
-**Carl:** I would raise, as a counterpoint, That they already captured the brand value because they sold Remix to Shopify, [23:31]
-
-**Mo:** It's a monetary brand value rather than anything else. Like a monetary for acquisition brand value. [23:36]
-
-**Carl:** I think there's a decent argument to be made there. but also like react router has been Around for like 12 years 11 years Literally, like, the original way of doing routing in React. So it kind of makes sense to me to say like, Look, we solved this problem. [23:54]
-
-I have been watching them try to figure out where the boundaries are between routing and, like, server and, they've been trying to figure out how to do data loading and, bundle splitting at the router level. For that entire time. So it feels to me like they spun up a new brand to do more experimentation and now got there and then folded it back into the original tool that they've been trying to solve this in forever. [24:20]
-
-**Mo:** the process got acquired, which is a nice payout as well. [24:24]
-
-**Carl:** great bonus. Yeah. [24:25]
-
-**Mo:** Yeah, makes sense. [24:27]
-
-**Carl:** Speaking of Vite. [24:28]
-
-## [Vite v6](https://vite.dev/blog/announcing-vite6.html)
-
-**Mark:** So associated with that Vite version six just came out. And it's interesting because they've tagged it as the most significant release since Vite 2. And yet I was looking through the announcement and the migration guide, and it looks like there isn't a lot that really feels user facing in terms of features and changes. [24:50]
-
-## [Environment API](https://github.com/vitejs/vite/discussions/16358)
-
-**Mark:** Best as I can tell, a lot of this one is on the inside, and it looks like they did a lot of major refactoring internally to enable what they're calling the Environment API. And as I understand it, the idea is that because JavaScript these days is used in so many different ways, it's used in the browser, it's used in Node, in Deno, in Bun, in worker runtimes, that may have differing constraints. [25:18]
-
-It seems that the environment API is going to allow you to generate build output targeted for different environments based on certain definitions. I'm still kind of hazy on that part myself. I have seen a number of mentions that things like some of the other, Framework level Vite wrappers are going to benefit from having the environment API available. [25:45]
-
-So, seen some mentions here, I don't quite know how all the pieces connect. general takeaway is like, it seems like, a fairly easy upgrade. saw a couple people on Reddit say like, yeah, I just like bumped the version and it just worked. So it might not have an immediate benefit for an application in terms of speed or build output per se, but it does seem like it's fairly foundational for a lot of the framework level stuff that's going on in the ecosystem. [26:12]
-
-**Carl:** Yeah, we definitely agree with that. I've encountered a little bit of that environment pain. Not using Vite, but just like trying to use Cloudflare workers. Trying to do, a worker serverless type of architecture. Definitely can tell that it is, Like bleeding edge of the ecosystem and a lot of the existing tooling is just like not well suited to support it precisely. [26:37]
-
-Yeah, just like having an existing, like daemon, existing process that is long lived. It's just a very different set of constraints from a short lived process that Handles a request and shuts down. So, Remember the era of the, of the acronym for rendering? SSG and SSR and ISR and S So, I feel like this environment API to me, it feels like a reaction to that, of like, look, we have all of these contexts in which web pages are being rendered and used. [27:08]
-
-And we don't even have a language to talk about it. I guess Vite has, spent most of the version five release iterating on what has then turned into this environment API. It sounds like they introduced it as. Something else the runtime API in 5. 1 and iterated on it, iterated on it, realized that what they landed on was different enough from that, that they just came up with a new name for it and put out a major release. So yeah, definitely looks interesting and valuable. [27:38]
-
-And yeah, given how Vite seems to be like the common building block that everyone else is starting to rely on, here for it. This seems like the kind of exploration that is super, super valuable, especially given that place in the ecosystem. [27:51]
-
-**Mark:** Definitely. [27:52]
-
-## [Expo Launch Party](https://expo.dev/launch-party)
-
-**Mo:** yeah, let's move on to some React Native land. And interestingly so, towards the end of November, we've had Expo's launch week. This is where Expo kind of bundle a bunch of the stuff that they've been working on and launch it in one go over a few days. it's been quite interesting to see some of the stuff that's been coming off. [28:10]
-
-Nothing is particularly a big surprise but it's interesting to see the culmination of some of the stuff being released out to the public. So, I'll go through some of this bit by bit, and we'll talk through it. [28:19]
-
-## [The magic of Expo DOM Components](https://expo.dev/blog/the-magic-of-expo-dom-components)
-
-**Mo:** So, the biggest thing that the Expo team has been talking about over the last few months, I'd say, is DOM components. [28:26]
-
-This idea of how uh, Can we make it super easy to run web based DOM elements inside of a native app without turning the entire app into a Cordova Ionic sort of web view based app? this is controversial at the best of times, I think, right now. A lot of people seem to really like it. [28:44]
-
-There's some people who feel like it's kind of a step I think the expo team is trying to take this pragmatic approach of, a lot of people have React web apps, how do we kind of get them to migrate incrementally and introduce them into the React native ecosystem. So, The article that we've linked has some interesting use cases. It kind of looks at the integration of, you know, you still, if you have a WebView based app, maybe there's some cases where you still want to introduce some native functionality. [29:11]
-
-So, you know, you press a button, maybe you still want to have a haptic on the native device. So how do you integrate those things together? And make it kind of feel native in some capacity. So it talks about some of that, some of the patterns that you want, and some use cases. So some of the things that have been really difficult to do in React Native is things like displaying markdown. [29:28]
-
-Markdown, you know, you have to create your own renderer with native components for it. And it's a lot of work to do that natively. Anyone who's done that will kind of attest to that. And Stuff like that gets really easy because it's a solved problem in the web world. So, they're kind of not saying you should use this for your entire app. [29:44]
-
-They're kind of being very, very, very clear about that. thinking of using that in places as an escape hatch more than anything. [29:51]
-
-**Mark:** More interop is always a good thing. [29:53]
-
-**Mo:** yeah, you know, it's good to have that. Now, this isn't something that necessarily is new. Like, you can always use WebViews in React Native. It's been around for probably since the very, very, very early days. [30:03]
-
-It's nothing new. There was always React Native WebView as a library. this is just an easier way and a nicer way to do it. And it uses the favorite directives that everyone has now in the React ecosystem, which is the use directive at the top of the file. And you just pop in a use DOM and it kind of works. [30:18]
-
-I think we're starting to overuse directives. We should probably stop as an ecosystem. It's just getting a bit out of hand, but that's a different conversation for another time. I see Carl passionately nodding at this. Mm [30:30]
-
-**Carl:** flashbacks to like, I guess it was like ES6 when the use strict directive was introduced. And I just remember the emphatic, you know, like people would say like, Ooh, what if we did this other directive? And I just remember the reaction being like an emphatic, like, No, this is the only directive we're ever going to do. Never again. This is terrible. We should not have had to do this, but we needed to. Never again. [30:53]
-
-And so now seeing like, we got like, what, four or five now in React? And they don't even have the same semantics. Like it used to be only at the top of the file and now it's like top of the source file, which is technically different. Not the, and like some of them are at the tops of functions. It's, it's complicated. It's too much complication. [31:13]
-
-**Mo:** I tend to agree with you. I quickly want to touch on some of the limitations to dissuade people from trying to use this for their entire app, so I'll just quickly quickfire those. The first thing is that performance is really going to suffer. Because, you know, when you're running a React Native app, it does have a JavaScript engine that uses Hermes under the hood. [31:30]
-
-But for this, you're basically instantiating a new JavaScript engine that will run web code, so that can be JSC on iOS and V8 on Android. And that basically slows down your load time quite significantly. And then if you do want to tackle that, you're probably going to have to have some hacky stuff to preload these components, hide them, and then display them. [31:48]
-
-It becomes a mess. So you really want to use this when you have no other options, or, you know, You have an escape path long term to basically get rid of these, these webviews. And then the other thing here is you have to be very, very clear as to how you handle your navigation. Because the worst thing for a user experience is having multiple layers of navigation. [32:06]
-
-So, you know, you have your stacks and your tabs inside of your native app, and then suddenly someone clicks a button inside of the webview, and it just adds a new screen onto your webview. And so you've got like two or three layers of navigation. It gets messy. Be careful, think about it deeply basically use at your own risk and think about the consequences of your actions. [32:24]
-
-## [Introducing Workflows: CICD built for your app](https://expo.dev/blog/expo-workflows-automate-your-release-process)
-
-**Mo:** In other things that the Expo team's been launching so Expo launched workflows. This was one of the more surprising things. They hadn't, they kind of kept this under wraps a little bit. But the whole concept with this is so far you know, Expo's got their cloud build tools, EAS build and EAS update. [32:38]
-
-So you can use builds to create your mobile native builds. They've got a submit tool. solution as well, which kind of pushes that thing to the App Store for you on Google Play and Apple App Stores. And they also had an update mechanism, which allowed you to issue over the air updates to your users. [32:52]
-
-Now, this, they never had a workflow or like a proper CICD tool. So you would have to basically almost run your CICD on another cloud or another sort of CICD tool and then call Expose. servers just to trigger the build or trigger the update. So they've kind of created some very basic workflow functionality. [33:11]
-
-It's YAML based. You know, you can run bash commands, you can run NPM commands in it. It has some very basic control flows as well. So if you kind of want to get away from, you know, using GitHub actions for your, for your mobile builds and mobile updates, it's a cool option if you don't want to add that as an extra piece that interacts with Expo. [33:30]
-
-It's something to see how they develop and extend over time. [33:33]
-
-## [Environment variables in EAS: new changes to simplify setup](https://expo.dev/blog/environment-variables)
-
-**Mo:** other unexpected, but this is incredibly welcome news they have revamped the way that you handle environment variable handling within Expo. Now this is something that has been a real pain. I think it's the place that the Expo team probably struggled the most to come up with a good and comprehensive solution. [33:52]
-
-Because you've got sort of different layers of environment variables when you're dealing with a mobile app. You have sort of secrets that are stored inside of the app's binary. Then you've got JavaScript based environment variables that anyone can inspect if they go into the JavaScript, so you don't really want to use any secrets or put any secrets within them. [34:10]
-
-Then you've got some stuff for your build processes. So there's sort of these like multiple layers of environment variables and they each had different sort of sensitivities or levels of secrecy that you needed to maintain. And so they've centralized all of this in one place. So EAS can kind of manage all of this for you. [34:26]
-
-And they've tried to centralize this because environment handle, variable handling in Expo was a nightmare. You had to kind of deal with three different environment variables, like working in a consultancy was one of those things that clients would come to us and be like, why is this so hard? And I would be like, I don't know, there's probably should be a solution. [34:43]
-
-One of our clients actually, prior to start a startup, like, like, thought very seriously about starting a startup to solve this problem, and I told them don't, please don't, Expo will probably solve it, and they have. So, it's good. I think it's still to be seen how it bodes in practice, but from first glance, it looks like you kind of define these centralized environments, and they have all of your environment variables in one place managed by Expo, which can make things significantly easier, and you can kind of define the visibility, visibilities as well. [35:08]
-
-So this is very welcome, because I think it's. It's kind of long overdue and it's one of those things that was a big pain point. [35:13]
-
-**Carl:** I love that. It sounds great. Sounds like a real problem that needs, you know, sounds like an improvement, but I have never worked anywhere that did not have some kind of pain with environment variables, including on my like solo projects, like currently the, you know, the main app that I write code for. As a stupid, terrible environment variable setup, because like, you know, it's CICD with GitHub Actions deploying to a Kubernetes cluster. [35:41]
-
-And so like, I have to take, I can't remember the, I think I put all of the secrets in GitHub. But then they get loaded into GitHub Actions alongside lots of context, build context, that the action provides on its own. And then I have to manually take all of the information that's relevant to the executing code and put that in a secret in Kubernetes and then load that. [36:03]
-
-So, like, I'm glad they're trying to improve it. I also just kind of think dealing with secret data is just a hard problem. So, I suspect this may not be the end of it. [36:13]
-
-**Mo:** I don't think it's the end of it. If they make it marginally better, especially, I think, I think it kind of ties hand in hand with their workflows functionality because they needed a, you know, solution to environment variables if they're creating almost a CICD. So, I think it's kind of hand in hand with that, but yeah, the exact same problem, right? [36:29]
-
-Like, even if you, before these workflows, what you had was you had the same environment variables, probably in GitHub, and then you had them replicated somewhere in EAS for your builds, and then somewhere else in your, for your updates. Maybe this removes some of that duplication, so at least your client side secrets. are sort of shared by Expo and managed by Expo. I hear your pain with the Kubernetes and backends, like infrastructure environment variables. I've done the exact same thing with GCP and Terraform and trying to manage those and it's not a, it's not a fun ride. [36:58]
-
-**Carl:** Nope. [36:59]
-
-## [Expo SDK 52](https://expo.dev/changelog/2024/11-12-sdk-52)
-
-**Mo:** Cool, and last but not least, obviously they also released Expo SDK 52. they say that this is their biggest release ever and I kind of believe it because the new architecture is out Cool. So that is a big, big revamp of everything in the internals of React Native, and they obviously manage a massive SDK with a bunch of different libraries. [37:16]
-
-So they've had to make sure all of it is compatible. So far we're hearing about some pains with Expo Go. Some people are having some troubles with Expo Go because it suddenly switched to the new architecture by default. So people are having some upgrades. Issues, but that's to be expected, to be honest, with such a big revamp of the internals and people will need to update their apps. [37:35]
-
-Some interesting highlights, just quickly running through these. Expo Video is a new library that's become stable now. So this is a revamp of the old Expo AV library that handled audio and video. They're splitting these out to Expo Video and Expo Audio. And it comes with a whole bunch of cool stuff. [37:50]
-
-Like, being able to generate thumbnails, being able to have picture in picture and a whole bunch of other stuff which is, is needed to, to kind of play video in a, in a high quality way in native apps. They've also released a beta of Expo Audio, which is, again, a rewrite, and this is great, and hopefully it just becomes a little bit nicer implementation. [38:09]
-
-And then they're releasing a whole bunch of stuff to their file system libraries, their cameras, and so on and so forth, Expo Images getting some updates. So there's a lot of good things. I'm not going to go through all of them because it is a massive changelog. But go and try it out. DOM Components as well, which we mentioned earlier on, is available with Expo SDK 52. [38:25]
-
-So if you want to play around with those DOM Components and figure out how you can integrate WebViews inside of your existing app with DOM Components, go for it. Expo SDK 52 is the place to try it out. [38:36]
-
-**Mark:** Sounds like a pretty big deal. [38:38]
-
-**Mo:** Yep. [38:39]
-
-**Carl:** Maybe one day I'll use Expo. [38:41]
-
-**Mo:** I'd love to hear your feedback on it, Carl, because it's quite a nice DevEx. I've had people who've, like, have you, you've built for React Native back in the day, right? [38:49]
-
-**Carl:** Yes. Short answer, yes. [38:51]
-
-**Mo:** it's usually people who have built with React Native or built native apps before, ages ago, and then they come in and try Expo, and they're like, holy crap, this is something. it has that, like, mind blowing effect, so I'd love for you to try it and then come with your feedback. [39:04]
-
-**Carl:** I briefly tried Expo like five years ago, [39:08]
-
-**Mo:** Not the same. yeah, they're totally different, totally different, totally different ecosystem. Yeah. [39:13]
-
-**Carl:** I remember it had a huge constraint of, it felt a little bit like a create react app in that it did a lot. But if you were building a production app, you were going to have to eject from it sooner or later. And the ejection story sounded pretty rough. [39:28]
-
-**Mo:** yeah, ejection was not a fun time. they had a lot of, I think that was the biggest, like Expo had almost a dip in reputation and it was because of ejecting. And so they, they completely got rid of ejecting. You don't eject anymore. You can add native dependencies as you wish. And it's a totally different mechanism. [39:42]
-
-So Expo in 2019, 2019. is a very different thing to Expo in 2024. And I'd say they've regained that reputation, which is great. [39:52]
-
-**Carl:** Cool. Sounds good. Yeah. I guess my, perception way back when was like, this feels like create react app, create react app feels like it's dying. This feels like it might die, but here we are five years later and it is totally transformed. Looks really great. This is definitely what I would, you know, were I to try a native app. I got a long list of other things to do. [40:10]
-
-## New CSS
-
-**Carl:** Cool. Okay moving on. This is slightly unstructured. [40:14]
-
-## [A Friendly Introduction to Container Queries](https://www.joshwcomeau.com/css/container-queries-introduction/)
-
-**Carl:** I'm going to frame this conversation around a Josh Kumo article about a friendly introduction to container queries. I don't think I had heard of container queries, but like, I was reading this was like, holy shit, there is so much new CSS stuff that I, that has just not crossed my radar. [40:31]
-
-So container queries are basically media queries, but for the containing element. So you can say all sorts of things. not super duper sure what the support story looks like for them. that's basically why I checked out of paying close attention to CSS news is because it was so much of it is like Chrome only, or, you know, not supported in Firefox or Safari. [40:54]
-
-And so like, stopped paying attention because so many of the things that looked really interesting and neat were not stable. And if a CSS feature is not stable, you can't polyfill it in the same way as JavaScript. Bye. [41:05]
-
-## [A Framework for Evaluating Browser Support](https://www.joshwcomeau.com/css/browser-support/)
-
-**Mark:** Conveniently on that note, Josh also just put out a post that discusses his approach for looking at browser support for various features, CSS or JavaScript, and sort of like his mental model of, how do I decide when a feature works? Might be good for me to actually use in practice. Of course, like it literally, it basically boils down to it depends, but he walks through kind of the process of how he gets to that and the article actually literally starts out according to can I use container queries are supported for almost 93 percent of users. [41:39]
-
-**Carl:** Right, and I see in the, thumbnail, in the, you know, preview image, is 93 percent good enough? And that was exactly my response to that. So, I don't know. it's a hard thing. [41:47]
-
-so, container queries just caught my eye as like a great Way to do a great enhancement over media queries because media, queries, you can adjust your styling based on, you know, the size of the screen, based on the capabilities of the device, but container queries, it looks like, I don't know the depth of the capabilities, but the most obvious one I'm seeing right here, you know, the first one it shows is, you know, mid width of the containing element and like, that's great. [42:18]
-
-I have had so many responsive. design bugs where, I try to reuse an element in a new context and it's narrower because I wanted to put more elements next to each other or something than I did in the previous one and it looks like with container queries I could Avoid those bugs by saying, if the space this is in is this size, render in this way. Which is a very different, much more powerful method of querying than just the device support. So, yeah, that seems really [42:53]
-
-**Mo:** I'm curious as to when, I think it's still probably in, experimental phase, but I'd love to see when this becomes available for something like Tailwind. [43:01]
-
-**Carl:** Right, and it might, I wonder if it would even be like a breaking change. Because they currently have, you know, SM, MD, different size constraints. Thanks. Thanks. And it feels like they might be able to just modify those to be based on the container. [43:16]
-
-**Mo:** they've done that exact pattern when they like introduced the group functionality. Like, they obviously had like hover, active, focus, or whatever for the different states, and then they just added a group colon active. So I wonder if this becomes like a container dash sm, container dash md, or something like that. [43:31]
-
-Like, that would be consistent in my mind, at least. [43:34]
-
-**Mark:** quick Google search says that they put out a first party plug in for container queries back in 2022. And there's something involving an at container wrapper on a parent. [43:48]
-
-## [State of CSS 2024](https://2024.stateofcss.com/)
-
-**Carl:** I said this is going to be kind of a loosely structured thing, related to this conversation, there was a state of CSS survey, you know, same as state of React, state of JS, whatever, Devographics, Sasha Greif and I was just looking at the list of CSS features and thinking like, wow, I have not used more than half of these. CSS is totally different. And you know, in the introduction to this State of CSS survey shouts out, "let me make a prediction. We'll look back at 2024 as the turning point between CSS classic and new CSS." And that's interesting. I feel I definitely learned and became expert in classic CSS. CSS Classic. [44:31]
-
-Describes as like, the build steps and all of that. I had to learn floats and positioning and box model and I feel like none of those things are super relevant anymore. Now it's grid and flex. And so it's just like a whole new set of Primitives that I have not had professional experience using like oh dang cool. Wow shifting landscape know what? I thought was stable land is now totally different just really [45:01]
-
-**Mo:** I the one that always, like, that winds me up that I learned about a little while back, that was just like, What? Why does this exist? But it's also very impressive that it exists. Is, like, the mathematical functions that you can use now in, like, CSS for calculating values. Like, power of, square root, logarithms. Like, how do I, what case do I have where I need to, like, calculate a size based off of a logarithm in CSS? Like Cool, I'm glad it exists, but I can never imagine needing to use that. [45:30]
-
-**Carl:** we do some funny layout logic and on the Reactiflux website. And yeah, you can do that. the font size is based on the viewport width, for instance. [45:41]
-
-**Mo:** but would you ever use a logarithm based off of that? [45:43]
-
-**Carl:** Hey, maybe if I wanted to, you know, nonlinear scaling, [45:46]
-
-**Mo:** Yeah, maybe. Anyway, it's quite cool. [45:48]
-
-**Carl:** I don't know. Wild. [45:49]
-
-**Mark:** big picture metaphor. I think what's come into my mind is that it feels like it's a little bit like the ES 2015 spec where you could do a lot of stuff in JavaScript prior to that. And a lot of stuff in ES2015 was effectively syntax sugar for stuff you could do before. But there were also a number of things in ES2015 that required support at the language runtime level, like proxies, that simply could not be done before and enabled virtualization. [46:17]
-
-A whole lot of new functionality from there. So, you know, I, I know that CSS is not like a strictly versioned spec the way that, you know, the JS language is at this point, but I think that's kind of the, the metaphor that we're going for here. [46:31]
-
-**Mo:** yeah. [46:32]
-
-interesting. Complete side note before we move on, but since we started with this, Josh Comeau his website is like one of the most beautifully designed tech websites I've seen. Like, I say this every time I look at it, I'm like, wow, this is beautiful. He's done a phenomenal job with this website. [46:47]
-
-**Mark:** Josh is amazingly talented, he is an amazing educator, his blog is wonderful, I can vouch for his courses without having looked at them because I see the care and effort he's put into his blog post. So, highly recommend all of Josh's stuff. [47:00]
-
-**Carl:** Very, very true. [47:02]
-
-## Framework betas:
-
-**Mark:** Okay, moving on a little more quickly, a couple different frameworks and pieces are in beta. [47:08]
-
-## [RSC in Expo Router is now in Beta!](https://expo.dev/blog/universal-react-server-components-developer-preview)
-
-**Mark:** One is that the Expo router now has support for server components. And Mo can probably talk a little bit more about the actual implementation nuances here, but big picture, it's a big deal because it's server components coming out in any framework other than Next, and more specifically within the React Native ecosystem. [47:29]
-
-## [TanStack Start beta](https://tanstack.com/router/latest/docs/framework/react/start/overview)
-
-**Mark:** And then as sort of an inverse of that, Tanner Linsley's 10 stack start framework is now in beta, and it's a deliberately non server component framework for now. Tanner has said he will look at adding some server component support down the road, but his argument, and he's made BlueSky within the last few days, is that he feels server components are actually of very limited use. [47:59]
-
-and really much less flexible compared to a server function concept architecture for managing data. So he did just do a talk about and kind of advertising some of the features at React Summit New York last week. I looked, if you check out the Git Nation website, the video is available for people who have, you know, paid up for the early access to the videos and it'll go public sometime in the next month. [48:27]
-
-**Mo:** Just to quickly touch on the exporouter RSC stuff, So it is very much an experimental at this point, it's beta. You can't even host it on a production server, you need to do it locally, so it just means you're basically testing it out in dev at this point. It was previously just on Evan Bacon's machine, and now it's on, you can have it on your machine, which is quite, quite cool. [48:47]
-
-But yeah, like the cool thing about RSCs and React Native is that you're rendering native components under the hood. So you almost render native views, native texts, native images, and you almost do a building block of components through an RSC that is then rendered natively, so it's not web views or anything like that. [49:03]
-
-So it's very different to the DOM component stuff that we talked earlier, which makes it very interesting. Still very early days, but we've seen really cool demos of this over the last year at React Conf and beyond. [49:14]
-
-## [React Native 0.77 RC0](https://github.com/facebook/react-native/releases/tag/v0.77.0-rc.0)
-
-**Mo:** Picking on the React Native terrain, very quickly, React Native version 0. 77 has had its release candidate, which is very quick after 0. 76. This is a very small release. Expectedly so, after the massive release that was the new architecture becoming default. So, just some quick things. Swift templates for iOS. [49:35]
-
-This is taken away from the Objective C base of code in the internals of React Native and making it more Swift based and more modern, which is great. They've done some improvements on tvOS integration, which is great because tvOS has kind of been one of those platforms that's been in the shadows and not well supported. [49:52]
-
-And there's some general better performance improvements specifically when dealing with animations. So there's some minor improvements, but nothing super major and not a whole lot of breaking changes. [50:02]
-
-## [New List dropped in React Native](https://x.com/jmeistrich/status/1855663310386958840)
-
-**Mo:** Now, speaking of the new architecture Last month we had the release of the new architecture with 0. 76, and we're already seeing some interesting stuff coming out of it. [50:12]
-
-So, Jay Meistrich, who I've known for a little while now, actually released a completely new list component for React Native called LegendList. So, Jay maintains a few libraries called, like, LegendState, another state management library, and I think LegendMotion, which is an animation library. And he recently Created a new list, and now he, he claims that I inspired him to do this at a talk that I did at React Advanced, which is very flattering, and I think he's giving me way too much credit and I definitely don't deserve that, but basically the, the whole concept is with the new event loop in React Native, you can kind of synchronously call on layout events. [50:50]
-
-Which you previously couldn't with React Native and so this is a JS only implementation as a list and it seemingly, on first glance, outperforms FlashList and the FlatList that comes default with React Native so it may be the quickest list in the React Native ecosystem right now. A lot of people are very, very excited by it. [51:08]
-
-Jay is quite good at performance stuff because he spent a lot of his time as a game developer back in the early 2000s basically. So, he was dealing with a lot of very, very, very low memory and low CPU devices. And I guess he kind of knows this stuff decently well. So it's going to be interesting. [51:25]
-
-He's released it to public, so you can go and try it out right now. But it's still to be seen. He's adding more and more APIs as we, as we speak. So it's quite interesting. [51:33]
-
-**Carl:** Super cool. Mo, I'm going to challenge you on that because if somebody tells you that you were an inspiration, I think you should [51:39]
-
-**Mark:** Take all the credit. [51:41]
-
-**Mo:** I just did a talk. It was nothing special. [51:44]
-
-**Carl:** Ah, that's pretty special. [51:45]
-
-## Twitter -> Bluesky migration
-
-**Mark:** All right, and our, our last big item for this episode is, is not directly tech related, but it is, because React is more than the tech, it's the people in the community, and, you know, we, we spend time talking about conferences, but, you know, we, we get a lot of our links and keep an eye on things from, you know, historically, from Twitter, and Twitter has been where, you know, most of the web dev community has chatted and interacted online for the last several years. [52:11]
-
-And without going into, you know, some of the, the political or, you know, aspects behind it Twitter has declined a lot in the last couple of years. And there's been various waves of people saying I'm done with Twitter and I'm leaving. And the main alternative that a lot of people had gone with was Mastodon. [52:27]
-
-But Mastodon's always had sort of that, like, I'm a Linux user and I know how to set up everything myself kind of a vibe to it. And there's been an alternative to Twitter called BlueSky, which had been invite only for a while. I believe they opened up to public signups maybe about a year ago. But it always felt very niche. [52:48]
-
-And really the main thing I knew about it over the last year was that Dan Abramov, after leaving Facebook had gone over there to actually work on their web and native apps as, as his day job. Well, there has been a massive migration of the greater web development tech community from Twitter over to BlueSky really within just the last month. [53:13]
-
-And I mean, there's, there's been lots of other. Twitter communities that have moved over there black Twitter, football, Twitter, basketball, Twitter, science, Twitter, etc. And feels like, to me, like one, in the earlier era of Twitter where it was people talking rather than just bots or big businesses. And two, the, you know, just the general atmosphere and sort of discussions that are, that are happening. [53:43]
-
-So, a lot of people from the React community have signed up and started being very active over there. A number of people have specifically deleted their old Twitter accounts. As an example, Seb Markbaga from the React team. I believe actually nuked all his old tweets, and moved over to Blue Sky. I think Dan Abramov's Twitter accounts are, are, are gone at this point. [54:09]
-
-So a number of people are doing the Scorched Earth thing, and like, wiping out all their old messages, which I'll be honest, as someone who has always depended a lot on, you know, archiving the web and, you know, linking to external discussions makes me sad because I hate to see historical discussions and tweets and artifacts go away. [54:33]
-
-Having said that, as far as the community goes, I personally am feeling Like Blue Sky is probably where I'm going to put my posting energy going forward. There is, there's a lot of people there. It feels like the community is self sustaining at this point. And it's where a lot of the discussion is happening now. [54:54]
-
-## Starter packs: [ericclemmons/awesome-starter-packs](https://github.com/ericclemmons/awesome-starter-packs), [stevendborrelli/bluesky-tech-starter-packs](https://github.com/stevendborrelli/bluesky-tech-starter-packs) [Bluesky Directory](https://blueskydirectory.com/) [A complete guide to Bluesky 🦋](https://mackuba.eu/2024/02/21/bluesky-guide/)
-
-**Mark:** One nice thing is that Blue Sky has these things called starter packs, where anyone can just make a list of people they recommend on a certain topic. And it makes it very easy to follow some or all of them. At once. There are directories of starter packs out there. there's a question about whether BlueSky is kind of related to crypto related things. [55:13]
-
-## [Technical debate](https://dustycloud.org/blog/how-decentralized-is-bluesky/) over [how “decentralized”](https://whtwnd.com/bnewbold.net/3lbvbtqrg5t2t) Bluesky actually is
-
-**Mark:** there were a couple good articles talking about some of the technical implementation differences at the server level between Mastodon and BlueSky and like how actually decentralized things are. Loosely put, BlueSky is semi centralized, but it's possible to run your own server and own your own data, somehow. [55:38]
-
-So, big picture, a lot of folks who are from the React community are no longer active on Twitter, and they are now active on BlueSky. [55:47]
-
-**Carl:** Yep, can confirm. Definitely saw a massive shift in the last, like, month. It's been notable. Yeah. Definitely a lot more people posting out there, yeah. [55:57]
-
-## [Web Without Walls | React Universe Conf 2024](https://www.youtube.com/watch?v=F1sJW6nTP6E)
-
-**Mo:** because of the crypto question, if you're interested in how the BlueSky backend and like the decentralized nature of BlueSky operates, Dan Abramov did a talk at React Universe Conf about this called Web Without Walls, so I've just shared that and that gives a pretty comprehensive, it is a 40 minute talk, but that gives a pretty long and comprehensive discussion about what the nature, the decentralized nature of BlueSky is. [56:22]
-
-Quickly to add on this, actually, BlueSky is a universal React Native app. So it uses ExpoRouter and it's basically using the same code base for web and mobile, which is quite cool. And you're seeing something in production that's being used by, as we speak, 17, 18 million users now, which is pretty [56:40]
-
-**Mark:** They reached over, like, 21 million a couple days ago. okay. So I'm clearly off of the uh, off of the numbers. [56:47]
-
-There was about a week and a half where they were adding about a million people a day. [56:51]
-
-**Mo:** React Native London Conf, we actually had the and Sam from the BlueSky team. Dan now works mostly on the AT protocol stuff, but Sam works on the mobile app and the web app. They are talking about it. This was while they were getting a million per day. So it was quite cool to see them there talking about some of the stuff that they're working on. [57:06]
-
-It's a really cool team, and it's a very small team that's building this, which makes it all the more impressive. And it's super cool that they can take on the likes of a certain someone who's multi multi multi billionaire who's trying to create his own community. So, you know, pretty cool. [57:20]
-
-**Carl:** Yep, it is super cool. I could probably talk a lot more about it. I have opinions on this. And I've been thinking about the need for data portability and the benefits, the potential benefits of decentralization in the context of social media for most of a decade. I'm actually considering if I want to try and do a business effort based on the underlying data that is BlueSky. [57:45]
-
-I think that there's a lot of opportunity to iterate on the UI layer of social media. And if you have a common public data set, that's a lot easier to do. [57:53]
-
-**Mo:** on that Carl, the current BlueSky app was not the original BlueSky app Which makes it all the more interesting. So Sam created his own BlueSky client It was better than the original BlueSky app because he could use it with the AT protocol And then they just hired him and made Sam So it kind of shows that like, with this decentralized nature, anyone can make a client and sometimes it'll be better. [58:14]
-
-Kind of like the, what was that Reddit client that was better on, on iOS back in the day, but then Reddit shut it down? I forget [58:20]
-
-the name. [58:21]
-
-**Carl:** of them. Apollo? [58:22]
-
-**Mo:** Well, [58:23]
-
-**Mark:** all, all of them, yeah. [58:24]
-
-**Mo:** all of them, but Apollo. So yeah, similar story, but the decentralized nature helps with that. [58:29]
-
-**Carl:** It does. And also the BlueSky client is both a universal React native app, and it's also open source. So I've seen a bunch of React and web people, like not just posting on BlueSky, but what they're posting is their experiments building, you know, iterate changing the UI of the client they're posting from like, Oh, wouldn't it be great if we had Markdown support in BlueSky? [58:51]
-
-Look at this proof of concept that just hacked [58:52]
-
-**Mark:** We're splitting [58:53]
-
-**Carl:** a PR. [58:53]
-
-**Mark:** the notifications tab into subtabs. [58:56]
-
-**Carl:** could talk a lot more about this. We're already 10 minutes over and. Still need to do the lightning round. But yeah, okay, Blue Sky's great. Follow me. [59:03]
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Alright, lightning round, go! [59:06]
-
-## [Deno v. Oracle: Canceling the JavaScript Trademark](https://deno.com/blog/deno-v-oracle)
-
-**Carl:** Deno vs. Oracle. We mentioned this a while ago. I think two months ago. Deno opened a petition to ask Oracle to release the JavaScript trademark, and this is a follow up to that. Seems neat. Seems cool. Love it. They are like formally asking Oracle now. It has moved on from just a petition. [59:27]
-
-## [Two ways to the two Reacts](https://bobaekang.com/blog/two-ways-to-the-two-reacts)
-
-**Mark:** Next up, an author named Bobae Kang has written some good articles talking about the mental mindset of React at a very conceptual, architectural level. And has a good post called, The Two Ways to the Two Reacts, which kind of contrasts Next, where everything is about the server first, versus something like a tan stack start, which is client first, and then optionally adding in the server. [59:52]
-
-## [That's not an abstraction, that's just a layer of indirection](https://fhur.me/posts/2024/thats-not-an-abstraction)
-
-**Carl:** Another one. Great post that I love, called, That's not an abstraction, that's just a layer of indirection. [59:59]
-
-**Mark:** True that [01:00:00]
-
-**Carl:** Just generally true, like, end of, end of comment. [01:00:04]
-
-## [React Anti-Pattern: Stop Passing Setters Down the Components Tree](https://matanbobi.dev/posts/stop-passing-setter-functions-to-components)
-
-**Carl:** Related, while I was looking for, you know, doing my final pass of resources to pull in I've seen this anti pattern kind of blog post called stop "passing setters down the components tree" and, agree. [01:00:17]
-
-That is a wonderful example of not an abstraction. If you're just passing the set state setter down as a prop, you should probably do it differently. [01:00:26]
-
-**Mark:** something something dispatching actions. [01:00:29]
-
-**Carl:** Aha. What Redux? [01:00:31]
-
-## [What is HTTP/3?](https://www.cloudflare.com/learning/performance/what-is-http3/)
-
-**Carl:** Yeah, I saw a neat post from Cloudflare called, What is HTTP 3? That made me go, whoa, I didn't know there was an HTTP 3. So yeah, that exists. It's something about QUIC. And I think it's related to, like, I don't know. It sounded like the promise benefits. They sounded very familiar from what I remember reading about HTTP 2, which as far as I know have not really been realized. So Seems like a new attempt to edit something something UDP, HTTP 3. [01:01:03]
-
-## [Leaked Vercel v0 system prompts](https://old.reddit.com/r/LocalLLaMA/comments/1gwwyia/leaked_system_prompts_from_v0_vercels_ai/)
-
-**Carl:** Someone posted on Reddit that they managed to exfiltrate the system prompts for Vercel's V0 AI UI generation tool. And that's cool, that's interesting. It looks like this was not, you know, any weird black hat stuff, like they just saw something leak. and managed to continue prompting the AI until they got the full system prompt. [01:01:25]
-
-So this is output from the AI, which means it might not be real, but it does seem approximately correct. You know, Must write valid JavaScript code that uses state of the art Node. js features and follows best practices. Does not use the components. You know, so it's like massive, massive prompt. [01:01:44]
-
-I think it's an interesting, you know, peek behind the curtain. This is what the wizard looks like kind of [01:01:50]
-
-**Mark:** And today's example of why I do not want to spend the rest of my career writing prompts. I want to write code. [01:01:57]
-
-**Carl:** What's the difference? [01:01:59]
-
-## [React Scan to highlight component renders](https://react-scan.million.dev/) (by the author of Million.js), which he used to point out [Github’s code view re-rendering on every scroll](https://x.com/aidenybai/status/1859267710498263073)
-
-**Mark:** Alright, a couple perf related items. Aiden Bai, the author of the Million. js React plugin for performance, I guess. Recently put out a new tool called React Scan, which can be used to identify, you know, components that are over rendering in your app. I glanced at the source code for 30 seconds and saw that it's messing around with some of the internals of React's Fibretree, and as someone who has spent a lot of time messing around with the React code, And React's internals in the React DevTools. [01:02:28]
-
-I have a sense of how this is probably working, and I approve. In fact, he actually used it to identify that GitHub's current source file display, which is based on React, was apparently re rendering all the lines every time you scrolled. And he even managed to identify, yeah, like, here's the component. [01:02:46]
-
-And here's like the prop that needs to be memoized in order to fix that. And a couple hours later, some GitHub engineer actually fixed it. So that's a step in the right direction. [01:02:56]
-
-## [What’s Next for the React Compiler?](https://www.youtube.com/watch?v=qd5yk2gxbtg)
-
-**Mark:** On a similar note, Satya from the React team just did a, just did a, an update talk called what's next for the React compiler talking about some of the upcoming features they're thinking of working on that would hopefully further improve performance. [01:03:10]
-
-**Carl:** Very smooth. Unrelated, non smooth transition [01:03:14]
-
-## [Framer Motion spinning out as an OSS tool (Motion)](https://motion.dev/blog/framer-motion-is-now-independent-introducing-motion), and conversely [GSAP is joining WebFlow](https://gsap.com/blog/webflow-GSAP/)
-
-**Carl:** Framer Motion which is a React animation tool. Uh, Is spinning out. It is no longer under the Framer brand and it is no longer React specific. Uh, It's just an open source tool called Motion, which seems cool. Framer Motion is definitely something I've heard about a lot for doing like complex, advanced animations and whatever. [01:03:37]
-
-So yeah, it seems cool. Love it. In the inverse direction GreenSock animation platform, GSAP, was acquired by Webflow. Love it. Love seeing open source tools get money. The maintainers do a lot of work and they deserve to be compensated for it. So yeah, super happy to see that. [01:03:54]
-
-**Mark:** This feels like that, you know, that classic line about there's two ways to make money. Bundling and unbundling. [01:04:00]
-
-**Carl:** Yes. 100%. [01:04:03]
-
-**Mark:** One library leaves, another library joins. [01:04:05]
-
-**Carl:** Right, every company is either a bundling or unbundling play and here we go. Here's two examples. Well, all right Thank you everyone for joining us and sticking with us all the way to the end. We will be back Well, actually we will not be back on the last Wednesday of the month because the last Wednesday of December is Christmas and we are Not recording on Christmas. I am so sorry. I'm not sorry [01:04:26]
-
-But yeah, we so we will be back recording at the end of December probably that Monday TBD Or back in your podcast feed as soon as we can. Yeah, thanks so much, Mark. Yeah. Always [01:04:37]
-
-**Mark:** nice too be here. I'm very much looking forward to a nice long Thanksgiving break where we'll probably mostly be hacking and Redux stuff. [01:04:43]
-
-**Mo:** yeah, it's always a pleasure to be here. Um, Lovely chatting with you all and loved getting into blue sky shenanigans this month, so we'll see what next month has in store for us. [01:04:52]
-
-**Mark:** Thank you for the behind the scenes bit on that. I did not know that they'd swapped clients. [01:04:56]
-
-**Mo:** I'll hopefully share the recording once we have it live and everyone can hear the story from the comforts of their home. [01:05:02]
-
-**Carl:** Cool. All right. We gather sources from this week in React, bytes. dev, react status, Next. js Weekly, the React. js subreddit, here in Reactaflux, and directly from people publishing articles, mostly on BlueSky. If you see anything newsworthy, definitely let us know by posting it in the Tech News and Reads channel here in Reactaflux, or send me an email. [01:05:24]
-
-I will read it if you send me an email to hello at reactiflux. com yeah, I read everything. I will read it. If this is a show you get value from and want to support, best way to do so is by submitting a review and by telling your friends and coworkers about it. Help them get as smart as you are about React. [01:05:41]
-
-See you next month.
diff --git a/src/transcripts/tmir-2024-12.md b/src/transcripts/tmir-2024-12.md
deleted file mode 100644
index eac2257..0000000
--- a/src/transcripts/tmir-2024-12.md
+++ /dev/null
@@ -1,592 +0,0 @@
----
-title: "TMiR 2024-12: React 19 is here 🎉 "
-date: 2024-12-23
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:45](#sponsored-by-infinite-red)] Sponsored by [Infinite Red](https://infinite.red/)
-- [[02:46](#new-releases)] New releases
- - [[02:48](#relay-v182)] [Relay v18.2](https://github.com/facebook/relay/releases/tag/v18.2.0)
- - [[03:07](#react-admin-v54)] [React-admin v5.4](https://github.com/marmelab/react-admin/releases/tag/v5.4.0)
- - [[03:16](#preact-v1025)] [Preact v10.25](https://github.com/preactjs/preact/releases/tag/10.25.0)
- - [[05:25](#playwright-v149)] [Playwright 1.49](https://playwright.dev/docs/release-notes)
- - [[05:33](#astro-v50)] [Astro 5.0](https://astro.build/blog/astro-5/)
- - [[06:00](#radon-ide)] [Radon IDE](https://ide.swmansion.com/)
- - [[07:57](#react-19-compatibility-in-react-redux-and-redux-toolkit)] React 19 compat for [react-redux](https://github.com/reduxjs/react-redux/releases/tag/v9.2.0) and [Redux Toolkit](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.5.0)
-- [[10:37](#main-content)] Main Content
- - [[10:39](#react-19-is-finally-out-blog-post)] [React 19 is actually out](https://github.com/facebook/react/releases/tag/v19.0.0) ([blog post](https://react.dev/blog/2024/12/05/react-19))
- - [[11:16](#upgrade-guide-from-april)] [Upgrade guide from April 2024](https://19.react.dev/blog/2024/04/25/react-19-upgrade-guide)
- - [[11:31](#removed-things)] Removed things
- - [[17:07](#new-things)] New things
- - [[28:42](#ref-callbacks-react-19-and-the-compiler)] TKDodo: [Ref Callbacks, React 19, and the Compiler](https://tkdodo.eu/blog/ref-callbacks-react-19-and-the-compiler)
- - [[34:07](#react-native-screens-400)] [Introducing React Native Screens 4.0.0](https://blog.swmansion.com/introducing-react-native-screens-4-0-0-1b833ff98a55)
- - [[37:00](#react-19-and-react-native-and-pr)] [React 19 support in React Native TBD](https://github.com/react-native-community/discussions-and-proposals/issues/842#issuecomment-2527591610) (0.77/78?)
- - [[38:58](#expo-experimental-support)] [Expo has experimental support](https://x.com/Baconbrix/status/1864785257297305833)
- - [[40:37](#next-151)] [Next 15.1](https://nextjs.org/blog/next-15-1)
- - [[39:52](#nextjs-experimental-css-inlining)] [experimental: css inlining](https://github.com/vercel/next.js/pull/72195)
- - [[41:33](#react-native-fast-io)] [React Native Fast IO now in prerelease](https://github.com/callstackincubator/react-native-fast-io)
- - [[43:27](#npx-create-target)] [Create Target Widgets in Expo](https://x.com/Baconbrix/status/1868672438898455023)
-- [[44:55](#lightning-round)] ⚡ Lightning round ⚡
- - [[45:02](#react-native-demo-for-android-xr)] [React Native demo for Android XR](https://x.com/o_kwasniewski/status/1868645896239690009)
- - [[45:43](#if-not-react-then-what)] [If Not React, Then What?](https://infrequently.org/2024/11/if-not-react-then-what/)
- - [[50:14](#vitest-vs-jest)] [Vitest vs. Jest](https://www.speakeasy.com/post/vitest-vs-jest)
- - [[52:29](#aiden-bai-render-shaming-sites-while-working-on-react-scan)] [Aiden Bai “render-shaming” sites](https://x.com/aidenybai/status/1862529226727121366) while [working on React Scan](https://react-scan.com/)
- - [[55:14](#lenzs-webers-testing-libraryreact-render-stream-testing-library)] [Lenz’s Weber’s testing-library/react-render-stream-testing-library](https://github.com/testing-library/react-render-stream-testing-library)
-- [[58:13](#outro)] Outro [00:00]
-
-**Carl Vitullo:** Hello people. Thank you for joining us for the December edition, the end of 2024. this is almost this year in React, this time around. [00:08]
-
-But yeah thanks for joining for December's This Month in React, wherewe recap and digest recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:22]
-
-I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like this. [00:29]
-
-**Mark Erikson:** Hi, I'm Mark. My day job is working at Replay building a time traveling debugger for JavaScript and outside of that I do ridiculous amounts of Redux stuff. [00:39]
-
-**Mo Khazali:** And I am Mo. I head the mobile team at Theodore. I'm quite active in the React Native ecosystem and I organized the React Native London meetup and conferences. [00:47]
-
-**Carl Vitullo:** Right into it. I don't really have a job market or conferences coming up this month. I had noted that over the last, six weeks or so, the list of upcoming conferences has dwindled down to zero. I've seen them start to pop back up again. [01:01]
-
-So we've rounded that corner of people getting prepared for next year, but we'll be back with some more conferences. to notify you of next month. [01:10]
-
-**Mark Erikson:** that is that I actually sat down and started trying to do preparation for applying to conferences for next year. Some of them apparently have already closed for next year. So it's, getting ahead of the timeline process. [01:24]
-
-**Carl Vitullo:** definitely getting ahead of it. Yeah small fun news for me, I am on staff for SquiggleConf next year, so, I'll have news for that, but it's not until September, so, no rush. Highly [01:36]
-
-**Mark Erikson:** recommendd folks going to SquiggleConf. It was great. [01:40]
-
-**Carl Vitullo:** But yeah, into it. Before we get all the way into the main content a note from our sponsor. [01:45]
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl Vitullo:** We are sponsored by Infinite Red, which is an expert React Native consultancy. They've been around since 2015, so like about to be 10 years, Give it another week or so and that'll be ten years. They're owned by Jermaine Holmgren, Todd Wirth, and Gant Laborde. They're our only sponsor in part because they do so much more than most consultancies and most of the companies in the ecosystem. [02:07]
-
-there's just not many other people who operate at the same level as they do. I've been seeing their name for as long as I've been active professionally. And they're still around. They're still doing great stuff. They only do React Native. They've built over 75 apps for companies and startups. [02:21]
-
-And other than great people who've done great things for the ecosystem they're a team of about 30, mostly devs, mostly 10 years of experience or more and they work alongside your team to develop expertise at that company. So if you are spinning up a new product with React Native, or just trying to develop in house expertise with React and React Native, they can definitely help you hit the ground running. [02:44]
-
-So give them a ring. https://infinite.red/. [02:46]
-
-## New Releases
-
-**Carl Vitullo:** cool. Into some new releases. [02:48]
-
-## [Relay v18.2](https://github.com/facebook/relay/releases/tag/v18.2.0)
-
-**Carl Vitullo:** First on the list, we got Relay18. 2. They've got an experimental hook for pagination with prefetching and a at catch directive, or the catch directive has been updated so it can be used on fragments and queries and mutations. [03:03]
-
-So just better error handling, looks like. Better pagination, better error handling. [03:07]
-
-## [React Admin v5.4](https://github.com/marmelab/react-admin/releases/tag/v5.4.0)
-
-**Carl Vitullo:** There's React. Admin, 5. 4 not a lot of notes here, but it's out, it's new, if you're using it, definitely check it out. [03:16]
-
-## [Preact v10.25](https://github.com/preactjs/preact/releases/tag/10.25.0)
-
-**Carl Vitullo:** Preact has a release, 10. 25 looks like stronger types. Support for object interface as a listener, , It looks like the last couple of releases have all been pretty small. So, you know, this is just sort of Preact doing its Preact thing. I'm not really sure if they're still abiding to the original idea of like drop in replacement for React. It's, I think, especially with React server components, they've diverged a little bit. But yeah, there's still use for it for sure. [03:45]
-
-**Mark Erikson:** Yeah, I've not sat down and tried to do a strict line by line feature comparison, but I think at this point generally support most of the original hooks. But I think beyond that, , they've stopped trying to match things feature for feature. So, if you're doing relatively straightforward things, then, you may have actual compatibility, especially if you like want to use any of the new, like React 19 features or anything with the Preact bundle, then obviously they wouldn't work. [04:14]
-
-**Carl Vitullo:** right. I guess my mental model for it is this is like, if you're working in a highly constrained environment where you would still like the niceties of React, React is great, but if you're not dealing with a highly constrained environment, then might not be necessary. [04:28]
-
-**Mo Khazali:** So an interesting one, I guess an interesting use case for Preact is that it's commonly used in TV development. If you're building web apps that are going to run on TVs, where there's a very, very small amount of resources. A lot of times I've seen people use Preact. So some big names in TV apps that you might've known, which I don't know if I should mention, but you know, some big TV apps will be using Preact because a lot of the apps that you have on TVs are web apps, but they need to be constrained in the resources that they use. Mm [04:57]
-
-**Mark Erikson:** is just ironic how Web app has become the default, way to distribute things everywhere. I [05:05]
-
-**Mo Khazali:** Yeah. I mean, web is like kind of a standard almost for TV, for TVs. Like if you're building for Samsung, if you're building for LG and a bunch of other TVs, you build it using a web app, so it's pretty cool that it's standardized around that. [05:18]
-
-**Carl Vitullo:** Yeah, I talked to someone about React Native on TV too, yeah. Neat. Funny. JavaScript eating the world. [05:25]
-
-## [Playwright v1.49](https://playwright.dev/docs/release-notes)
-
-**Carl Vitullo:** There's also Playwright 1. 49. Nothing too fancy there, but pretty widely used test tool, so if you're using that, there it is. [05:33]
-
-## [Astro v5.0](https://astro.build/blog/astro-5/)
-
-**Carl Vitullo:** Astro has a major release, version 5. 0. what they're calling content layer, a new flexible and pluggable way to manage content, providing a unified type safe API to define, load, and access your content, no matter where it comes from. Sounds a lot like Gatsby's [05:48]
-
-**Mark Erikson:** was about to say that, yeah. [05:50]
-
-**Carl Vitullo:** So fair enough, you know, like that's a real need, you know, loading content from many places. Very real need. Sounds like they're not using GraphQL for it. So, different take. Fair enough. [06:00]
-
-## [Radon IDE](https://ide.swmansion.com/)
-
-**Carl Vitullo:** Yeah, there was Radon IDE. Mo, you want to talk about that? [06:03]
-
-**Mo Khazali:** it used to be called the React Native IDE, and then they rebranded for obvious branding reasons to Radon IDE, fun little Easter egg. Radon on the element lists is RN. So, anyway React Native traditionally has not had an IDE. So, you know, you build in VS Code, but a lot of the functionalities that, if you were like a Swift or an Android developer, just wouldn't be there. [06:23]
-
-And so, the folks at Software Mansion have created Radon IDE as sort of a way to make your VS Code more of a Full fledged IDE for React Native development. So it comes with a bunch of cool stuff like integrating with like your simulator and then being able to inspect elements that are on the screen and find out where they are in code, which is really, really cool. [06:42]
-
-And it's sometimes a pain in React Native breakpoint support, understanding your navigation tree. They have debugging kind of nailed down, which has been a real pain in React Native, so that's quite cool. And then another thing that was a cool little gimmicky feature, I'd say, is instant replays. [06:57]
-
-So, you know, if something happens on your simulator and you're like, oh crap, that was a bug you can click back and get, like, the last 5, 10 seconds as a replay and then save that , to a file. So some cool little utilities, I'd say that you can use when you're building React Native apps. It is a paid IDE, so You know, it starts at, it's around 20 a month per seat. [07:17]
-
-But you know, so something to consider. So they're going for the paid model as almost a paid extension onto VS code. [07:23]
-
-**Carl Vitullo:** Interesting, huh? Definitely makes sense. I mean, times I've worked with React Native, the debugging experience was among the rougher sides of it, so it makes sense to have a stronger IDE integration for debuggability things. Cool. [07:37]
-
-and I believe Software Mansion is also Nope, never mind. I was gonna say behind React Admin, but no, they're not. [07:44]
-
-But then Software Mansion does lots of stuff in the ecosystem. They are Certainly, you know, I say not many companies do as much as Infinite Red and Software Mansion is definitely in the running there. A trusted name for sure. [07:57]
-
-## React 19 compatibility in [react-redux](https://github.com/reduxjs/react-redux/releases/tag/v9.2.0) and [Redux Toolkit](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.5.0)
-
-**Carl Vitullo:** Yeah, there's also React 19 compatibility release of Redux Toolkit. [08:02]
-
-Mark, anything you want to say there? [08:04]
-
-**Mark Erikson:** yeah number one, I actually had nothing to do with the work on these. One of the other maintainers, Arya, did all the actual grunt work. in React Redux, we now test against both 18 and 19. you'd think it would be as simple as just bumping the peer dependencies list and shipping, but, you know, you actually want to test against them, you have to check any, any types related issues. [08:27]
-
-in the Redux toolkit case, it's actually caused a ripple effect where we. I merged the PR to support React 19 at, you know, at the code level. And we accidentally ended up, semi accidentally ended up bumping React 19 for our DocuSource based docs website. And that ended up breaking client side interactivity because we were still on DocuSource version two. [08:52]
-
-Which didn't correctly support React 19 somehow. So the doc site built and you could view it, but it was the static, you know, HTML only and all the client side interactivity broke, search, copy code button, everything else. On the one hand, it's like, you know, conceptually, it's simple. On the other hand, there's actually a lot of work involved. And then there's always the, you know, the unexpected ripple effects afterwards. [09:19]
-
-One other ripple effect I've seen, which I don't think we have listed directly, but I've seen a lot of people report problems with Create React App because, you know, like, beginners are trying to I assume beginners are trying to create new CRA projects. They're using, you know, It uses NPM to do the installation by default, and the CRA templates still use an existing version of React testing library that wants React 18 as a peer dependency. [09:50]
-
-And so, what happens is, NPM tries to install the packages, Also tries to install React 19, because that's the latest. And then, NPM being its helpful self, throws an error because there's a peer dependency mismatch between the installed React 19 and React Testing Library 1. 18. So, I've seen a bunch of people report, Why can't I create a new React project? [10:16]
-
-With that kind of an error in the last couple weeks. And so basically CRE's borked at this point. I [10:22]
-
-**Carl Vitullo:** That is unfortunate, yeah. But also not too surprising. I guess it's a little bit of a matter of time for that. Too [10:28]
-
-**Mark Erikson:** in theory it could be fixed with, like, someone publishing updates to the templates, but I have no idea who, if anyone, would do that. [10:35]
-
-**Carl Vitullo:** Not sure how actively maintained that is anymore. [10:37]
-
-## Main Content
-
-**Carl Vitullo:** Alright, into our main content. [10:39]
-
-## [React 19](https://github.com/facebook/react/releases/tag/v19.0.0) is finally out ([blog post](https://react.dev/blog/2024/12/05/react-19))
-
-**Carl Vitullo:** The main, main, main, main, main content of React 19 is out. It is officially released and usable. [10:47]
-
-**Mark Erikson:** Yay! [10:48]
-
-**Carl Vitullo:** Yeah, so, we're gonna spend a minute, pretty much everything in these, you know, release notes and, , overview blog posts. , there's nothing brand new, , they've been messaging this, they've been talking about it, they've been, you know, trickling out bits. over the last year and a half. So pretty much everything in this episode that we're going to discuss, at least for React 19, we've already covered in some detail in the past, but we're going to bring it all together. this is the one where we talk about it all holistically. [11:16]
-
-## [Upgrade guide from April](https://19.react.dev/blog/2024/04/25/react-19-upgrade-guide)
-
-**Carl Vitullo:** Yeah, there's a great upgrade guide from back in April. I think that was before they found the issue with Sibling. [11:23]
-
-**Mark Erikson:** Yep, because that happened at the start of June. [11:26]
-
-**Carl Vitullo:** So that was when they thought it was going out pretty, pretty shortly. Here we are eight months later, and it's out! [11:31]
-
-## Removed things
-
-**Carl Vitullo:** I'm gonna start with what they took out, because I, it's a lot of things that I, Remember using, I remember fondly. [11:38]
-
-So they removed prop types. There's no more prop types it just silently gets ignored. know, they mentioned prop types were deprecated in April 2017. So here we are seven years later, and it's finally, a deprecated feature is finally being removed. Wow. Likewise, they removed default props for functions. For class components, those still have default props, but for a function component, just give it a default argument. It'll figure it out. [12:05]
-
-Finally removed legacy context. Also, just like prop types, deprecated in October 2018. Six years later, here we are. They removed string refs, the create factory helper, because that was if you can't use JSX, you can use this instead. So yeah, everyone uses JSX. Widely supported. [12:25]
-
-**Mark Erikson:** I've used a couple different little third party helper libraries for JSX environments, but this was one that was sort of built in. [12:34]
-
-**Carl Vitullo:** Yep [12:34]
-
-some testutils, removed some deprecated DOM helpers. Or, Render and Hydrate are now removed in favor of their concurrent equivalents, the CreateRoot and HydrateRoot, as well as UnmountComponentAtNode and FindDomNode. They also removed UMD builds, Universal Module Declaration definition. [12:58]
-
-**Mark Erikson:** Definition, yeah. [12:59]
-
-**Carl Vitullo:** Yeah, that's not really been super relevant for a very long time now, not sorry to see that go. What was the, what was the main tool that used UMD? [13:09]
-
-**Mark Erikson:** Well, okay, so, recap for people. So we had, you know, we, originally we had script tags and everything's a global, and then the AMD format, Asynchronous Module Definition, was a, community created module format for use in the browser. CommonJS, loosely put, was designed for use in Node because it requires reading a file off disk synchronously. [13:31]
-
-UMD was a, someone figured out the incantation to wrap the actual code that you cared about in a complex header that basically tried to figure out, am I being loaded as a script tag, a CommonJS file, or an AMD file, so that one bundle could serve as all three formats. Simultaneously. In practice, UMD files have basically been generated for use as script tags loading off of unpackage or something like that. [14:04]
-
-**Carl Vitullo:** sure, right. Yeah, I was thinking of RequireJS with the AMD module. but yeah, now with ESM and you know, dynamic import and all the bundling tools that we have now, that's, that hasn't really been relevant in six or eight years, something like that. Or it hasn't been cutting edge, at least. Hasn't been the recommended. [14:22]
-
-But yeah, so, cool. That's all the stuff they removed. A lot of old things that haven't really, that have been deprecated for long enough that, yeah, they can go away. [14:32]
-
-**Mark Erikson:** Yeah, a couple observations there. One, I made the same decision around removing the UMD bundles from the Redux packages when I shipped RTK 2. 0 last year. The difference there is that I replaced it with an ESM format file that had all the process node env references compiled out of it. [14:52]
-
-And the React packages still don't have, quote, proper ESM support. So this, in one sense, they did actually remove something without a direct replacement for it. I've seen a number of suggestions to you that if you need to use React, like, in essence, as a script tag, then the intended replacement is to use a site called ESM. SH, which I actually looked into that a little bit, and what it does is it apparently uses ESBuild to compile various third party libraries with some sort of an ESM wrapper around them. So, even though React itself is still only shipped in common JS format, this site, this service it'll re wrap various packages with ESM around them, even if they didn't ship with it. [15:46]
-
-And then serve that up as, you know, a script tag. [15:50]
-
-**Carl Vitullo:** Interesting. Yeah, I hadn't heard of esm. sh. Looks like it's maybe sponsored by Cloudflare? It says the CDN is powered by Cloudflare. So it looks like this might be a service, you know, for the ecosystem that they're running. [16:05]
-
-**Mark Erikson:** and then the other one is, if you look at the issue with people complaining that find DOM node was about to be removed, there's, there's still a number of people who are not terribly happy about that one. they've got cases where their component structure is, it's deep enough, nested enough that they, they needed to rely on find DOM node to Find the right things to interact with and, people are not happy that it's been taken away. [16:30]
-
-**Carl Vitullo:** That seems a little strange to me. I feel like if you're in that position, there are native browser features that would do you pretty well enough, but okay, sure. I've not been in that situation, so I don't know what the weird technical trade offs involved there might be. [16:44]
-
-**Mark Erikson:** And then our favorite hidden internal non documented API, `SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED`, has been renamed to `SECRET_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE` [17:00]
-
-**Carl Vitullo:** okay, that's a little more descriptive. It's a little more actionable. I don't know of anyone who's been fired for using those, so, a little more accurate. [17:07]
-
-## New things
-
-**Carl Vitullo:** Yeah, some, getting into some new things, what they're, you know, what they've added now looks like, to me, it looks like the big stuff is mostly around transitions. my mental model for this is a little bit like, for most of React 18, we used like useState and useEffect and like a couple things around there to do basically everything. [17:31]
-
-And I think the core team identified that there was a pretty consistent and tricky use case of what happens when you need to take actions and manage state as components are, mounting and unmounting. That was definitely a little bit painful. Getting the intricate dance of as things unmount and remount, or different things swap in to replace them has definitely been awkward and tricky, especially for little things like animations. [18:02]
-
-Like If you have an animation, you can't actually unmount until the animation is completed, which may, you know, if you have a state change that would remove the component, but you want an animation to finish, then you need to like add in this like extra ceremony to keep it technically mounted while not actually in use, not actually responding to new events and things like that. So that's my mental model for what these transitions are intended to support. [18:28]
-
-**Mark Erikson:** That feels a little different than my understanding. So I've not used transitions myself, probably because I haven't been writing as much React front end stuff lately. But, like we, you know, there used to be the discussion of, you know, React 18 is going to have a concurrent mode. [18:42]
-
-eventually said, okay, like, having an entire mode isn't what we need, we're going to have concurrent features instead. So my, my understanding is that transitions are, primarily part of that concurrent feature set where you're basically telling React, we're going to start a render, but this is going to be considered low priority. [19:02]
-
-This could be interrupted. It will do the, like, you know, render a tree for five milliseconds and then pause to see if the browser has any events. So, my understanding is that transitions are primarily telling React, do some work, but this is considered a low priority render versus all the normal use state type based rendering. [19:26]
-
-**Carl Vitullo:** Interesting. Okay, fair enough. [19:28]
-
-so this is where the, you know, confusing verbiage that React introduced around like actions and how now we have many, many, many Actions is a very overloaded term in the ecosystem. [19:40]
-
-**Mark Erikson:** for Redux, another thing for MobX, now another thing for React Forms. [19:44]
-
-**Carl Vitullo:** Right, and I remember Astro had an actions thing as well a while back. So, right, there's just many, there's a lot of actions being taken. Yeah, so functions pass to start transition are actions. There's some additional hooks that are also able to tap into those, into the Actions as being used by active transitions. [20:05]
-
-So there's used action state which is a new hook to order actions inside of a transition with access to the state of the action and the pending state. So it, accepts a reducer that can call actions. So this is this smells a little bit like redux, baked into an interaction. a little bit. [20:24]
-
-As well as useOptimistic, which ties into these transitions by letting you update state while the transition is in progress, and it returns the state as well as a set function to optimistically update the state within a transition to be the expected final value. So, you know, like if you're doing optimistic updates within your UI, firing it off to persist in the back end, but immediately updating the local UI as if that has already finished. [20:51]
-
-But then gracefully handling the actual outcome of the of whatever action you took. [20:57]
-
-**Mark Erikson:** one observation here, you know, less around the behavior and more around the description. When React 19 came out a few weeks ago, the post in the JavaScript subreddit, the main discussion was basically around that paragraph and how hard it is to read for someone who isn't intimately familiar with React already. [21:19]
-
-And You know, a couple of different thoughts around this, like, one is that, you know, React has added a lot of things over time. Another is that there's been some cases where the React team has tried to turn things into proper named nouns in a way. Like, it's not just like, the useEffect hook, there are capital E effects. [21:44]
-
-And so, and so now it's not just, you know, we're going to do a low priority render, it is a capital T transition. And I, I just glanced at the docs. Like I'm, I'm looking at the use transition docs page and it does intro with use transition as a react hook that lets you render a part of the UI in the background, but like it right away starts using capital T transitions without ever defining what that word means. And there isn't really like a conceptual explainer. [22:19]
-
-So, part of it, like I realized that release notes aren't the right place to, you know, to go out and define a bunch of things, but both reading this specific paragraph, as well as trying to figure out how some of these new features are integrated into the docs and the teaching workflow, it feels like they're like, we're kind of missing a bit of a, like a conceptual explainer for some of these terms and how they relate to each other. [22:46]
-
-it's fixable, but, you know, like that, that's just one of the things that stuck out to me. [22:50]
-
-**Carl Vitullo:** Yeah, makes sense. Yeah, that's fair. it feels like an Apple type of branding. You know, it's not a, it's not an mp3 player, it's the iPod. [22:59]
-
-**Mark Erikson:** not the, just iPod, iPad, iPhone, whatever. [23:03]
-
-**Carl Vitullo:** No articles. Sure. [23:04]
-
-Yeah. other than transitions, they got the use hook, which is a little bit old hat by now, accepts a promise or context for accessing resources within render. If you give it a promise it will suspend until the Promise is resolved. [23:19]
-
-**Mark Erikson:** the naming still feels awkward, like, I don't have a better suggestion, but, in today's world, naming things for Googleability is very relevant, and giving this thing the name use is like the most un Googleable thing ever. [23:37]
-
-**Carl Vitullo:** There, right, right. [23:38]
-
-And back to my pet peeve about some of the quirks of React 19. This is the use hook, and it says right in the release notes, use can only be used in render, but can be called conditionally. And like, come on, rules of hooks, like, drilled into us repeatedly. Anything called use Use whatever. Cannot be called conditionally. [24:04]
-
-**Mark Erikson:** With the exception that you could already get away with, you could apparently already get away with calling useContext conditionally. I've never actually done it myself, but apparently, technically that worked. [24:14]
-
-**Carl Vitullo:** Interesting. I have not either. I don't think I knew that, actually. So I guess, cool, this is consistent with use context. [24:20]
-
-So clearly, I guess, it has its lineage in there. It is the way to use context. it just seems a little strange to me to, like, this seems like it's going to be a very widely used hook, and so for it to break the rules of hooks, quote unquote, quote unquote. [24:34]
-
-Feels like it adds a lot of, I don't know, weirdness, ambiguity, confusion. [24:39]
-
-**Mark Erikson:** it does I mean, I know that there's plans to hopefully expand that down the line. My, my Redux co maintainer, Lens, who also works on Apollo, has been begging for the ability to pass an observable. to use for a while now. So it's possible that that may happen at some point. It also is kind of one of those things where like they, you know, they needed the rules to be strict originally. [25:03]
-
-And now that the rules are defined and the ecosystem understands them, they can start to tweak it. But as you know, that also leads to confusion as well. [25:11]
-
-**Carl Vitullo:** Right, right. it's all a game of telephone and this adds strangeness. It adds exceptions to the rules. lots of other convenience features coming out with React 19. You can render metadata tags in components wherever, and they'll automatically get hoisted into the head section, which is great. [25:28]
-
-I, I think I said it when this was first announced, but like, the, React Helmet was, as far as I know, the main way to really interact with head in React, and it was just like not very consistently maintained. I kept running into, like, I feel like every time I used it, every time I was spinning up a new project and trying to interact with the head, it's like, oh, React Helmet, cool. [25:48]
-
-Pull that in. Oh, this does not behave in the way I expect in these many different ways. And so then what I thought was just gonna be a trivial, it works. Was not, was not trivial, did not work. So love that. Love to see that. [26:03]
-
-But yeah, RIP React Helmet. That was, I remember, I remember when that was released. I remember that was announced and going like, what the hell? NFL is releasing an open source project at the bleeding edge and they called it React Helmet. This is perfect. Protects the [26:18]
-
-**Mark Erikson:** one, definitely one of the best project names ever. [26:21]
-
-**Carl Vitullo:** Yes, absolutely. So, RIP to NFL's React Helmet. another convenience feature, you can use async scripts. [26:30]
-
-You can render them anywhere in the component tree, and they will be, React will handle the ordering and deduplication of them, which is neat. Yeah, deduplicating async scripts sounds That makes me a little scared. But yeah, I guess it shouldn't be too bad as long as you're not doing any weird stuff with the file name. Yeah, likewise, more head stuff. React 19 will ensure style sheets are inserted into the head before revealing the content of a suspense boundary. So, you know, predictable, Easily anticipated ways of interacting with the head. Also some initial load optimizations. Initial load and transition, page transition optimizations around pre init, pre load, pre fetch DNS, pre connect. [27:14]
-
-These are all, like, kind of low level optimizations that used to be exposed at the level of, like, script tags, where you could say, you could communicate to browser what level of initial connection to try and get ahead of. You know, because it takes a little bit of time to look up the DNS, to connect to the server, to open, you know, begin streaming data. [27:34]
-
-So, it sometimes introduced extra latency that was undesirable. So you can now, in React 19, have a little bit more control over how external assets get loaded in that way. You know, just even like pre fetch DNS and pre connect. Will cut the latency a decent amount. I've used those things in the past. It's a pretty nitty gritty performance optimization, but yeah, definitely important that we can now do that. That's nice. [28:00]
-
-Yeah, a big one, a nice one. One less use case for Refs can now return cleanup functions, so that's definitely big. That's definitely good. I think it had definitely been a pattern to, like, do a useEffect, to do things like setting up event listeners, and that was a little bit weird. [28:19]
-
-I don't know, it's just a little funky, because they're, they're clearly tied to the DOM. It's associated with a DOM node so having to do it in useEffect introduced, it just, extended that distance between the code that was being run and what it relied on. You had to do extra weird deduplication stuff because it was an effect. [28:36]
-
-So now, because refs support cleanup functions, it's just a little bit closer, you can keep it a little more self contained. [28:42]
-
-## [Ref Callbacks, React 19, and the Compiler](https://tkdodo.eu/blog/ref-callbacks-react-19-and-the-compiler)
-
-**Mark Erikson:** Yeah, and there's a, there's a good post from Dominic Torfmeister, the, you know, maintainer of React Query, he had written about dealing with, dealing with refs a couple years ago. And so he kind of revisited that topic and showed that, you know, hey, there, here's, here's cases when, You know, now you can do things like setting up a resize observer in a ref, and you don't even have to have a useEffect plus a useRef to manage that. [29:10]
-
-**Carl Vitullo:** another very small convenience feature, you can now render just context instead of context. provider. That's nice, that's good. Very small, very petite. React 19 also has support for custom elements, i. e. web components. For the first time in React's history we discussed that at much greater length in previous episodes. I don't know if there's that much more to say, web components. If you're using web components, cool, great, now you can use React as well. [29:36]
-
-**Mark Erikson:** it's still really complicated You know, a lot of it boiled down to, like, React can, in theory, render any arbitrary HTML tag. React have a hard coded list of element types that it knows are part of HTML. But, React 18 and earlier had issues with properly passing complicated props into web components. [30:02]
-
-And that's because of the whole difference between HTML attributes versus JavaScript DOM node properties, which I still only partly understand myself. But think part of the issue was React wanted to pass in. properties, but a lot of these things expected attributes instead. [30:23]
-
-And so there, there was a mismatch in, in how things would get passed down as well as issues with setting up event listeners as well. And from what I've read, went into the, the mile long discussion threads, they're like the web component spec does not necessarily define how a given web component receives this. [30:42]
-
-it's It's implementation dependent on a per web component basis. So it's literally how it's almost as if every single web component author, as they write that component decides, how is this component going to get its data or trigger its events? And so, different libraries, different wrappers, different authors take different approaches. [31:09]
-
-And so, part of the issue with implementing this was trying to find a reasonable set of heuristics that would work most of the time, and also allow React to pass this web component in framework compat spec that had been put out there. And after React 19 came out, I saw a couple more people posting complaints that certain scenarios didn't work right. [31:34]
-
-Like, I guess if you define a function field on your web component class. And then you also try to pass in a prop with that name. React will happily overwrite the function because it just assigns the field name, but ultimately it seems like web component authoring is a very inconsistent and per component basis kind of a thing. [32:00]
-
-And there's a lot of edge cases with the interop and so they're never going to make everybody happy. [32:06]
-
-**Carl Vitullo:** Awesome. Sounds great. Yeah, the finer points of attributes versus properties is, my eyes began glazing over at that point. [32:13]
-
-**Mark Erikson:** Yep. [32:14]
-
-**Carl Vitullo:** Yeah okay. a convenience that got me a little excited in React 19. Hydration errors will now be collapsed into a single error, even if there are multiple mismatches. [32:23]
-
-Like, nice. [32:26]
-
-Just [32:26]
-
-Right, just having my console be blasted with, like, 30 stack traces because, like, obviously this hydration did not match is, yeah, very happy to have that just be didn't work, not here's every point at which hydration did not work. That's nice. [32:44]
-
-So kind of subtle, I don't quite, I don't understand the, the precise details here, but errors in render are not rethread. If they're not caught by an error boundary, they're reported to window report error, not logged with console error. There's also, they've introduced onUncaughtError and onCaughtError methods to the create root and hydrate root. APIs to customize how those errors get handled. So I guess they're kind of stepping back from like automatically handling every error and logging it to the console to saying, if you have a boundary, we'll log it. [33:18]
-
-If you don't have a boundary, you can configure how it gets handled on your own. [33:23]
-
-**Mark Erikson:** You know, that's interesting. This, this might be the kind of thing that libraries might end up caring about more, but I, I actually feel like I need to go back to those React 19 compat PRs that I did not write myself, but I did merge. Because I, I think we had some tests where we had, like, assertions that, like, if an error happens while doing, like, a React Redux render or something, that errors would either get thrown of rendering or get logged somewhere. [33:50]
-
-So now I'm actually curious how we, how those PRs ended up handling them. [33:54]
-
-**Carl Vitullo:** Sure. Right. You can never know what you don't know. obviously that's the majority of our, I think that's the majority of what we wanted to get to today. [34:01]
-
-But uh, yeah, Mo, tell us about React Native screens. Hang [34:07]
-
-## [React Native Screens 4.0.0](https://blog.swmansion.com/introducing-react-native-screens-4-0-0-1b833ff98a55)
-
-**Mo Khazali:** Major version of the React Native Screens library, version 4. 0, came out. So, you, as a React Native developer, probably don't interact directly with React Native Screens. If you use React Navigation or ExpoRouter, which uses React Navigation under the hood, you will be using React Native Screens. [34:23]
-
-React Native Screens is native layer implementation of screens on iOS and Android for your app so that you're not creating JavaScript views and not handling the view transitions on the JavaScript layer, rather you handle them on the native layer. And so a few updates here that will likely be picked up by the React Navigation libraries. [34:43]
-
-React Navigation and ExpoRouter libraries. One is that they're adding more support for the forum sheet presentation. So this is kind of the bottom sheet interaction that you'll be used to on phones. And previously it wasn't supported on Android. And now there's an Android support. It was supported on iOS but you had a limitation. [35:02]
-
-So if you ever played around with those bottom sheets, you can kind of pin them to certain points, and they'll kind of stick. They call these detents, I think. [35:10]
-
-**Carl Vitullo:** This is like the sort of mobile version of a modal, where it's like an overlay that you slide around. [35:16]
-
-**Mo Khazali:** Yeah, exactly, those ones. So the ones that come from the bottom, and, you know, you've got a little modal, and the screen behind it is still kind of visible, and you can adjust how big the modal is. they call them sheets, I guess, in mobile development. Modals, when you're talking about in a mobile navigation world, it's the ones that kind of fully cover the screen. [35:35]
-
-Not the ones that can partially cover the screen. So you've got some of these pop ups that fully cover the screen. Sometimes you'll see them on, like, login pages or something like that. And so, a lot of these sheets, you can kind of control where they are, so you can pin them to different locations. [35:47]
-
-So, with this new API, you are able to, on iOS, set as many points to kind of have these snap points. And on Android, I believe, there's three different snap points. That you can define. So this is kind of sticking true to the iOS and Android APIs on the native layer. They've also made some minor improvements on animations when it comes to iOS to make it a bit more smooth. [36:11]
-
-And one of the other things that they've done is that if you've got a screen that's now detached, from the main tree of your navigation, so it's no longer rendered. You can preload these screens, and so this will kind of happen through React Navigation so that if you know a user is going to go onto a specific screen, you preload it, render everything, create the native views, and so you won't have this delay in getting the screen loaded onto the app, which is quite a nice feature, and I think this is great. [36:39]
-
-Quite important for optimizing your app and making sure that everything is smooth, quick, and snappy. So those are kind of some of the things. You won't really be implementing any of these yourself. You'll probably use React Navigation, so keep an eye out on the React Navigation docs and the ExpoRouter docs, because some of this stuff will be landing. [36:56]
-
-Some of it's already been landed as well. [36:58]
-
-**Carl Vitullo:** Nice. Makes sense. Yeah. [37:00]
-
-## [React 19 and React Native](https://react.dev/blog/2024/12/05/react-19), and [PR](https://github.com/react-native-community/discussions-and-proposals/issues/842#issuecomment-2527591610)
-
-**Carl Vitullo:** Tell us about React 19 and React Native. [37:04]
-
-**Mo Khazali:** so taking a step back, React Native just released the new architecture. So that was the, big release that they've been kind of working on for many, many years. And so, I think they're going through a stabilization period right now. They are I think waiting to make sure that everything is smooth, stable with the last two versions of React Native that have been released. [37:26]
-
-I suspect this will be some point in early to mid 2025, sometime in the next two releases of React Native, where they'll actually support React 19. I know that there's been some issues with supporting React 19 anyway with React Native. I think there's been some internal testing, but they haven't conclusively made sure that everything is working as expected. [37:46]
-
-So, I think there's just going to be some delay on this. But I think it's not something that we haven't seen in the React Native ecosystem. There's sometimes a lag with these major version upgrades anyway. [37:55]
-
-**Carl Vitullo:** Yeah, that makes sense. And especially, I'm just, I'm kind of connecting dots of what you were just talking about with like React Native screens, adding support for like preloading. And that sounds adjacent to, like, some of the use optimistic or use transition hooks that have popped up now as, like, first class APIs. [38:15]
-
-So I wonder if that's maybe some of the tension there, is that now that it's a first class API, a feature of React 19, React Native needs to figure out how to implement it [38:28]
-
-**Mo Khazali:** Because it's not just JavaScript there's also an element of, you know, how do you map those to native functionalities, right? So if you're transitioning to allow a native component to be rendered, well, how do you handle that on the native layer? [38:41]
-
-So there's a lot more support that needs to happen, it's not just the browser. But you need to also make sure that at least iOS and Android support those features, not to even get into the whole out of tree platform shenanigans where you've got a bunch of other platforms that are maintained by the community and they also need to support it. [38:56]
-
-So yeah, it has a long tail. [38:58]
-
-## [Expo experimental support](https://x.com/Baconbrix/status/1864785257297305833)
-
-**Carl Vitullo:** But it looks like Expo has experimental support. [39:03]
-
-**Mo Khazali:** this is probably one of the musings of Evan Bacon over a weekend just hacking away, but yeah, there's a lot of these sort of, like, Expo kind of goes ahead of the curve with some of these things and tries to push the React Native ecosystem forward, which is great so, I'm not surprised that this is supported with some sort of flag in Expo. [39:21]
-
-So yeah, it's the experiments. reactCanary, setting that to true. In Expo SDK 52, it works. These are very much experimental. Don't try these for any production apps, but it's just kind of trying to see what the effects would be ahead of time. I mean, we've seen this pattern, like Expo supporting RSCs with the bundler, with some custom changes to the bundler ahead of time before it's even, you know, supported, in any capacity officially by Meta. [39:46]
-
-So, it's cool to see it, but it's still a long way to go for production apps. [39:51]
-
-**Carl Vitullo:** Sure, yeah. Makes sense. [39:52]
-
-## [Next.js experimental CSS inlining](https://github.com/vercel/next.js/pull/72195)
-
-**Carl Vitullo:** Well, I have a very, very small bit of React, er, a very small bit of Next. js news. They've added a experimental CSS inlining feature. And now, if you are generating, you know, if you're, you're, if you're pulling in CSS styles, instead of it being compiled into a CSS asset and Loaded with a link tag. You can configure next so that it will just inline those styles in a style tag Yeah, this takes advantage of the React 19 precedence in deduping You know, CSS features. [40:28]
-
-So I guess this is enabled by React 19 But yeah, definitely pretty small, relatively minor performance optimization. [40:37]
-
-## [Next 15.1](https://nextjs.org/blog/next-15-1)
-
-**Carl Vitullo:** guess a larger bit of news. Thank you, Mark. There's also Next 15. 1 that's out Yeah, last episode we talked about how Next 15 was stable and now they're up to 15. 1 [40:50]
-
-**Mark Erikson:** The biggest one here is that because React 19 is now actually out, they've switched to using React 19 everywhere. So actually, it's kind of funny because for now they're on React 19 stable, but there's a good chance that they will continue using those canary releases in future versions of Next down the road. [41:10]
-
-So this may actually be only a temporary problem. you know, period of time where they're, where the version of React they use actually exactly matches the stable version. [41:20]
-
-**Carl Vitullo:** Right. I didn't know they have, you know, One of the headers on the 15. 1 release notes is React 19, parentheses stable. So yeah, right. They've been on Canary for forever. [41:33]
-
-## [React Native Fast IO](https://github.com/callstackincubator/react-native-fast-io)
-
-**Mo Khazali:** Cool. So, next up we've got the pre release version of React Native Fast. io out. So this was sort of first showcased at React Native London Con in November. So this is made by Mike Grabowski, who is the co founder and CTO of Callstack. And so it's basically built on top of the Nitro modules package that we've seen and talked about in the past few months that's been made by Mark Roussevy. [41:59]
-
-And so it's a way to create native libraries that are super, super fast to execute. And so, Mike from Callstack has been working on trying to get some of the I. O. functionality in React Native implemented with Nitro modules so that they're as fast as possible. And hence, React Native Fast I. O. [42:18]
-
-So he started off with WebSockets but he eventually wants to target WebSockets, Fetch, FileSystem APIs, Blobs, and Streams. And so the whole idea is you can use the WebSockets or the Fetch that comes from React Native Fast. io and in theory it should beat all of the benchmarks for any other implementations of I. [42:36]
-
-O. related functionality in React Native. So this isn't anywhere near production. But it's something that you can give it a shot and play around with and just run some benchmarks on and eventually at some point it should land and it could be quite interesting to see what that means for the whole ecosystem because these are quite core functionalities, right? [42:54]
-
-**Carl Vitullo:** Yeah. I uh, definitely pretty low level. If that gets much faster, that enables a lot of other interesting experiments. [43:00]
-
-**Mo Khazali:** Exactly. And I think The, one of the things with this is that it's one of the, like, first implementations of an actual library with Nitro modules. So, so far Nitro modules have been very hypothetical in terms of what you can achieve. Mark's been using it on a few of his libraries, but nobody else, sort of, in the community has adopted it to this degree to build an actual package. [43:20]
-
-So, it can really start to push a lot of people towards Nitro modules when they're building native dependencies. [43:25]
-
-**Carl Vitullo:** Neat. Cool. [43:27]
-
-## [NPX Create Target](https://x.com/Baconbrix/status/1868672438898455023)
-
-**Mo Khazali:** In other news, and we talked about Expo's random demos that they release with some cool features and going ahead of the curve. Evan Bacon in a very truly Evan Bacon fashion has been working on a new CLI tool specifically for iOS called NPX Create Target. And so the whole idea with this is, is that there are certain parts of an iOS app that you can't build with React Native and you need to build in the native layer. [43:51]
-
-So what are those? Those are things like widgets, live activities. Lockscreen widgets, and there's a whole host of things that are not part of, like, the main app that you use, but are almost extensions on top of on top of your main app. And so, the whole idea with this is, is that it's been quite difficult to get these up and running with React Native so far, because you need to go into Xcode, add those, widgets and then kind of do the binding between your React Native app and the widgets that you create or those targets that you create. [44:19]
-
-And so the whole idea with this is is that it's a simple NPX command that you can run and you choose the type of target or widget that you want to use and then it kind of bootstraps all the code, links it to your React Native app, has a way for them to communicate between each other, and all you need to do is just write the Swift code to basically implement that on the native layer. [44:37]
-
-And so it's a much easier way to add these targets to your existing application to your existing Expo application. So it's a pretty cool thing. It's, it's it's nothing that you couldn't do before, but it obviously was a lot more work. And this just makes it significantly easier to get up and running with those features to make your app feel even more interconnected within the OS, within the person's phone. [44:55]
-
-I [44:55]
-
-## Lightning round
-
-**Carl Vitullo:** Alright, that's all of our main content. Let's jump into the lightning round. Moe, you're up again. [45:02]
-
-## [React Native demo for Android XR](https://x.com/o_kwasniewski/status/1868645896239690009)
-
-**Mo Khazali:** So, quick thing. Android released some new features. Cool mixed reality stuff Android XR. So there's a whole release on that. And of course someone had to create a demo of React Native running on it. So there's a quick tweet showing React Native running on Android XR. [45:17]
-
-We'll see how this expands, but it's always within days that someone creates a demo of React Native running on any new platform or any new APIs. [45:25]
-
-**Carl Vitullo:** Nice, cool. Okay, so this looks kind of like Android version of Apple Vision. [45:30]
-
-**Mo Khazali:** Yeah, it seems like it's a competitor to Vision OS, basically but Android's really trying to standardize the way that XR goggles are built with Android. [45:41]
-
-**Carl Vitullo:** right, cool. Good luck. [45:43]
-
-## [If Not React, Then What?](https://infrequently.org/2024/11/if-not-react-then-what/)
-
-**Mark Erikson:** Another post from Alex Russell was going around in the last few weeks. Alex generally is on a one man crusade against client side JavaScript and the React ecosystem in particular. This one was titled, If Not React, Then What? And most of it boils down to most sites shouldn't be single page applications. [46:04]
-
-Most sites shouldn't be using react. I guess there's other client side libraries that you can use, but generally they shouldn't be client side in the first place, which is frankly, like, like my own summary is actually a, like a reasonable stance to take. And if he phrased it that way, he would probably have more people listening to him. [46:23]
-
-But the vitriol and the vehement and the anger that he puts into these posts, even when he has valid points, makes it really hard for people to actually listen to what he's saying. [46:33]
-
-**Carl Vitullo:** Sure. I haven't read this in depth yet. I would like to but yeah, he like very strongly states that, let me pull a direct quote. " React is a legacy technology, but it continues to appear in Greenfield projects. In short, nobody should start a new project in the 2020s based on React. Full stop." That is uh, not something I'd agree with. Strongly stated. [46:57]
-
-**Mo Khazali:** reading the About Me page, and Alex Russell, I didn't know this, works at Microsoft. And he's a partner project manager on the Edge team. [47:05]
-
-**Mark Erikson:** he was previously at Google and he also basically invented like two thirds of what we now know as the web component spec as well. I. [47:11]
-
-**Mo Khazali:** Yeah, I wonder how Microsoft feels about these stances. all of these posts are, these are not my, you know, employer's opinions. These are endorsed by no one except me. [47:22]
-
-**Carl Vitullo:** I randomly, I was just trying to refresh my memory on who Alex Russell is. Cause I, I recognize his name, I know his Twitter handle is slightly late, and I have seen him for years, as like, somebody in the ecosystem. So I was just trying to refresh my memory more specifically, and I quickly found A random Hacker News comment that describes him as early member of the Chrome team, three time elected member to the W3C from 2013 to 2019, and representative of TC39 from 2006 to 2017. [47:52]
-
-this is from two years ago, and it says, Lately, he's been very critical of single page apps in React, going as far as to call the past ten years a lost decade. guess he's been on this for a minute, but has some, like, Drawing deep credentials to, on, you know, web technologies. So, interesting. [48:08]
-
-Curious. But if he's on, if he's coming at this from a web components perspective, that adds a lot of color to my understanding of the situation and his arguments. [48:19]
-
-**Mark Erikson:** my take on it is like, he, he absolutely has the technical credentials to back up most of his opinions as well as statistics on like how bad, I mean, like many website bundles actually are like, he's not wrong about that, but he then goes from that to say that anyone using react is doing it wrong. Basically any single page app is wrong and the people who push react have been doing so with malicious intent from day one. Which is way over the line. [48:49]
-
-**Carl Vitullo:** Yeah, I'm gonna, I would disagree strongly with that. I feel like in, I feel like I can understand his macro perspective there, cause like, I have used a lot of like news websites that are like clearly using React very badly. It has been, it has been put in a lot of contexts that I don't know that it was the best tool for the job, because it was a popular tool that was easy to hire for. So I guess I can empathize with the perspective a little bit, but, I don't know, the nuance there, I feel like there's more nuance [49:18]
-
-**Mark Erikson:** no nuance, and that's the issue. [49:20]
-
-**Mo Khazali:** Well, just to go a little bit more into this. I just read his Rebuttal to if someone says, well, what about React Native? And I'm just going to read this verbatim. "React Native is a good way to make slow apps that require constant hand tuning and an excellent way to make a terrible website. It has also been abandoned by its poster child, [referring to Airbnb]". And then he goes on to suggest that you should use Capacitor and Cordova instead. Cordova is The poster child of making awful applications. [49:47]
-
-**Carl Vitullo:** everything he just said applies way more to Cordova than to React Native. [49:51]
-
-**Mo Khazali:** yeah, his, he seems to be pushing you to make web apps and use those on mobile with responsiveness. So I've at least on the native side, I think his opinions are incredibly unvalidated. He's probably has more credentials on the web, but that is a bizarre take to then go and say Capacitor and Cordova are better options. [50:10]
-
-**Carl Vitullo:** Oh yeah, yeah, definitely agree with that one. [50:13]
-
-**Mark Erikson:** Moving right along. [50:14]
-
-## [Vitest vs. Jest](https://www.speakeasy.com/post/vitest-vs-jest)
-
-**Carl Vitullo:** Great post titled Vitest vs Jest. I think this is Very needed. I think this is a great post. Just it starts with like just like a raw feature comparison comparing what does Vitest support and what does Jest support. And just goes into a bit of like a oral history of like, why did Jest appear? Why did it succeed? always appreciate some oral histories. I think it's really useful to understand how things came about. [50:41]
-
-Like I remember when ultimately Jest succeeded because it got open sourced. Also by Meta right, like within six months after React came on the scene. So like people had started using React, people had started using all of the everything Facebook was putting out, Facebook at the time was putting out React and Flux and then like, Oh sure, Jest. [51:06]
-
-So it definitely got a huge, huge, huge boost by the timing of its open source release. I never really got a ton of professional experience using other tools like Mocha or Chai and all of those. I don't really know what the comparison is from my perspective like functionality wise they all seemed about the same and But I don't know I used Jest because I was early in my career and I didn't have opinions and it seemed popular So why not? [51:31]
-
-Yeah, over the years definitely it became It, it became not a preferred tool of mine because I found myself needing to maintain parallel bundle configurations for, a production build, and then for Jest, and then for like end to end testing, and then, and so it's just like, it just became like one more target that made upgrading instance, like, new webpack or new, I don't know, any new core technology, I found updating Jest was just a huge pain in the butt. [52:03]
-
-So it became not my preferred tool for that reason. And Vitest seems to be a little bit better about that, but But I have not had that same professional experience of, I'm on a team with 15 other engineers trying to update a core technology without breaking everything or stopping work. So that's really the litmus test for me on a tool like Vitest or Jest. [52:23]
-
-And I've had negative experiences with Jest and no experiences with Vitest. Ergo, Vitest is obviously better. But [52:29]
-
-## [Aiden Bai “render-shaming” sites](https://x.com/aidenybai/status/1862529226727121366) while [working on React Scan](https://react-scan.com/)
-
-**Mark Erikson:** there's a young engineer named Aiden Bai, who I, I think is, I could be wrong on this, might not even be 20 years old yet. But he's the creator of a tool called Million. js, which is kind of like a, almost like a proto version of React compiler where you could isolate parts of your component tree and it would optimize like the text updates in there. [52:50]
-
-And he's since gone on and been working on a bunch of other React related performance tools. Some of them have been branded with Million as well. I think there's a like a million lint and like a a million VS code extension that try to highlight some React performance issues. But he's working on a tool called React Scan, and it loosely put pretends to be the React DevTools in the browser in order to get access to React saying, I just got done rendering, here's the new component tree. [53:24]
-
-And he's been advertising this with a tweets that are kind of render shaming. Sites like he did one where he pointed out that like typing in a search input in Twitter Makes basically every component on the page Rerender and those naturally got a lot of circulation and stuff going around So he called out a number of sites that way And it's, it's both really, really clever marketing, as well as, you know, a bit of an example of ways that React does not necessarily lead to a pit of success kind of a thing you know, just because of, you know, React's default render behavior. [54:07]
-
-I've very briefly dug, you know, dug into the source code just enough to see that that's how it's hooking into React's updates. I've not tried to go through the code and see how the rest of the analysis is implemented. But this feels very similar in spirit to some of the work I've done at Replay over the last couple years. [54:24]
-
-So I, I always approve of people digging inside React's internals in ways they're not supposed to. [54:28]
-
-**Carl Vitullo:** Yeah, I small reaction. I saw one of the site, one of the render shaming tweets he put out was about GitHub. [54:35]
-
-**Mark Erikson:** The list view that is used to render source code was re rendering all the list items every time you scrolled. And so, scrolling performance was relatively bad. And he tweeted it, tagged someone at GitHub, and they did actually fix it like a day or so later. [54:53]
-
-**Carl Vitullo:** yeah, that's worse than I was thinking. I thought it was uh, something about typing, but scrolling, ooh, rendering every line of code on a diff while scrolling. Yeah. That's, that's, that's not going to do good things. [55:03]
-
-**Mark Erikson:** it's virtualized, so like it wasn't rendering like 50, 000 lines of code at once. But even just what was on screen could be, you know, relatively slow. [55:14]
-
-## Lenz’s Weber’s [testing-library/react-render-stream-testing-library](https://github.com/testing-library/react-render-stream-testing-library)
-
-**Mark Erikson:** And then the last one plug for a friend uh, Lenz Weber is co maintainer of Redux Toolkit and works on Apollo Client. And he'd been putting in a ton of work to try to write tests for Apollo in conjunction with React Suspense and ran into all kinds of problems. And this is one of those things that is, it's a library maintainer problem. [55:36]
-
-This is not an app developer. But, you know, like we've, we've had lots of tests in the React Redux code base over the years that say, okay, I'm going to render a component, do an update. And I expect React will have re rendered this many times in the process. And as React's internal behavior changed over time, we kept having to go in and tweak those assertions, you know, like when, when React 18 switched to batching by default, like the number of render counts changed in a lot of our tests. [56:07]
-
-And in fact, at one point we had to say, like, if it's 17, then we expect that this test will render four times. If it's 18, we expect it'll render three times, et cetera. So like, this is not the kind of thing that an application test would need to care about, but a lot of library tests needed to care about this thing. [56:26]
-
-And, you know, we always implemented it with basically. You know, having a, having a variable outside a component, the components defined inside the test and you count how many times it rendered. So in the process of working on the test for Apollo, Lens came up with a new approach, which he's called the React Render Stream Testing Library, and it actually got included in the testing library. [56:52]
-
-organization, part of the, like the RTL group that we all know and love. And this takes a different approach where it actually kind of buffers up all the renders that occurred. And then you can say, okay, give me almost like a wrapper for the contents of the next render in the sequence. [57:12]
-
-And then let me write assertions against the contents of the DOM as it happened in that render. So you're still doing the usual testing library approach of, like, let me look for a button, let me, you know, assert that certain text is on screen. But rather than kind of conceptually testing it against a, quote, live version of the DOM, You're asking for a series of snapshots of it, and this library does the work of kind of buffering those, and then you can just sort of take the next one, do some assertions, take the next one, do some assertions. [57:47]
-
-I actually tried making use of this in a test with Redux Toolkit the other day. And it required a bit of a mental model shift to try to use it that way, but it actually ended up being much more consistent, and like, I didn't have to write any waitfors, because it wasn't timing based anymore. So, again, if you're not writing libraries, you probably don't need this, but if you are writing libraries, this might be useful. [58:13]
-
-## Outro
-
-**Carl Vitullo:** All right. That's all the news we have for you this month, this year. Woo! Thanks for joining us. We will be back next month on the last Wednesday of January here in the live stage, or back in your podcast feed just as soon as we can. [58:28]
-
-**Mark Erikson:** And Mo was worried we wouldn't have enough to talk about. [58:31]
-
-**Carl Vitullo:** Haha, it's gonna be a short episode. [58:32]
-
-Well, [58:33]
-
-**Mark Erikson:** all. Yeah look forward to talking with you folks next month, and enjoy the break, everybody. [58:39]
-
-**Carl Vitullo:** yeah. Happy holidays. [58:40]
-
-**Mo Khazali:** Always a pleasure. Hope everyone has a lovely time off, and enjoys the festivities, and uh, looking forward to what next year's got in store for us. [58:48]
-
-**Carl Vitullo:** 2024 was good to you. Good to you all. It was good to me. It's been a, it's been a weird year for me, but a good one. Yeah, end of episode. Personal updates. this has been the first year of my life when I accepted for myself that I'm queer. I'm not straight. It's been a good year for me, I hope it's been a good year for you. [59:06]
-
-Thanks so much. We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, our React. js, the subreddit, here in Reactaflux, and direct from those publishing articles. If you see anything newsworthy, definitely let us know at hello at reactaflux. [59:21]
-
-com. Bye! I read every email that comes in, even the spam, so send me an email. I'll check it out. If this is a show you get value from and want to support, the best way you can do so is by submitting a review wherever you listen, and by telling your friends and co workers about it. Cheers. Thanks for listening.
diff --git a/src/transcripts/tmir-2025-01.md b/src/transcripts/tmir-2025-01.md
deleted file mode 100644
index 1cd2ba5..0000000
--- a/src/transcripts/tmir-2025-01.md
+++ /dev/null
@@ -1,542 +0,0 @@
----
-title: "TMiR 2025-01: Movement on CRA, Redwood.js dead?"
-date: 2025-01-29
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:29](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- [[03:09](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://docs.google.com/document/d/1V-wc6YRW7TeKSREPxREI70vfIyA0vVmVbYKr6sU2jZc/edit)
-- [[04:17](#new-releases)] New releases
- - [[04:26](#react-query-563)] [React query 5.63](https://bsky.app/profile/tkdodo.eu/post/3lfaeteulds2i)
- - [[04:45](#docusaurus-37)] [Docusaurus 3.7](https://docusaurus.io/blog/releases/3.7)
- - [[05:17](#react-native-audio-api)] [React Native Audio API](https://blog.swmansion.com/hello-react-native-audio-api-bb0f10347211)
-- [[07:30](#main-content)] Main Content
- - [[07:30](#cra-deprecation-react-team-against-recommending-vite)] [CRA deprecation, React team against recommending Vite](https://bsky.app/profile/acemarke.dev/post/3lggg6pk7g22o)
- - [[09:28](#dans-why-cra-exists-dont-use-it-possible-future-options-comment-from-2023)] [Dan’s “why CRA exists, don’t use it, possible future options” comment from 2023](https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741)
- - [Dan: “turn CRA into a launcher” still on the table, but stuck](https://bsky.app/profile/danabra.mov/post/3lggs4ql72k2w)
- - [“CRA is broken and not deprecated” umbrella issue](https://github.com/facebook/create-react-app/issues/17004)
- - [Ricky merged the PRs, working on legacy docs SEO redirects](https://github.com/facebook/create-react-app/issues/17004#issuecomment-2620263140)
- - [[37:46](#revealed-reacts-experimental-animations-api--motion-blog)] [Revealed: React's experimental animations API - Motion Blog](https://motion.dev/blog/reacts-experimental-view-transition-api)
- - [[37:59](#main-pr)] [Main PR](https://github.com/facebook/react/pull/31975)
- - [[40:17](#static-hermes-update)] [Static hermes update](https://x.com/tmikov/status/1869945330638442651)
- - [[42:38](#react-native-hosting-with-eas)] [React Native Hosting with EAS](https://expo.dev/blog/expo-announces-eas-hosting-service)
- - [[44:44](#everything-you-need-to-know-about-nodejs-type-stripping)] [Everything You Need to Know About Node.js Type Stripping](https://satanacchio.hashnode.dev/everything-you-need-to-know-about-nodejs-type-stripping)
- - [[47:57](#composable-caching-with-nextjs)] [Composable Caching with Next.js](https://nextjs.org/blog/composable-caching)
- - [[51:56](#thoughts-on-what-rsc-means-for-spas)] [Thoughts on What RSC Means for SPAs](https://blog.axlight.com/posts/thoughts-on-what-rsc-means-for-spas/)
- - [[52:44](#chromes-2024-recap-for-devs)] [Chrome's 2024 recap for devs](https://developer.chrome.com/blog/chrome-2024-recap)
- - [[53:39](#shoutout-webstatusdev)] Shoutout [webstatus.dev](https://webstatus.dev/)
-- [[54:26](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[54:26](#redwoodjs-shutting-down)] Redwood.js 😱
- - [[55:59](#a-checklist-for-your-tsconfigjson)] [A checklist for your `tsconfig.json`](https://2ality.com/2025/01/tsconfig-json.html)
- - [[56:30](#recoil-repo-archived)] [Recoil repo archived](https://x.com/dai_shi/status/1875910305802514649)
- - [[57:47](#bun-firstclass-support-for-s3)] [Bun: first-class support for s3](https://bsky.app/profile/bun.sh/post/3legdozw3nc2p)
- - [[58:48](#interpolate-auto-height-for-animations)] [Interpolate `auto` height for animations](https://bsky.app/profile/joshwcomeau.com/post/3lf5zwg2ths22)
- - [[59:47](#free-javascript-oracle-not-voluntarily-releasing)] [Free javascript; Oracle not voluntarily releasing](https://bsky.app/profile/deno.land/post/3lfapjn7gns2w)
- - [[01:00:31](#understanding-react-server-components--tony-alicea)] [Understanding React Server Components | Tony Alicea](https://tonyalicea.dev/blog/understanding-react-server-components/)
- - [[01:02:13](#follow-us-on-bluesky)] [Follow us on Bluesky!](https://bsky.app/profile/tmir.reactiflux.com/post/3lc6ziumnq22p)
-
-**Carl:** Hello! Thank you everyone for joining us for the January edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux. The place for professional React developers. We are supported by Infinite Red, a consultancy that exclusively works with React Native. [00:19]
-
-I am Carl, I am a staff product developer and freelance community manager here at Reactiflux, where I run community programs like this and Star Helpers and some other stuff, and just generally try to keep the community humming nice and smoothly. [00:32]
-
-**Mark:** Hi, I'm Mark. My day job is working at Replay, where we're building a time traveling debugger for JavaScript and other fancy uses of introspecting application behavior. Outside of that, I do Redux, and I apparently argue with people about the right way to use React. [00:48]
-
-**Mo:** And I am Mo. I head the mobile team at Theodo. And I am involved in the React Native ecosystem, where I frequently jet off to some of the different conferences, meeting some lovely folks in the community and help organize the London community with the React Native London Conference and the meetups that we run monthly. [01:04]
-
-Yeah, very excited to be here, as every month. [01:07]
-
-**Carl:** Yeah I feel like There has been some stuff, just not like a wide range of libraries and whatever, but yeah, I think we'll definitely find a lot to talk about. Uh, Actually this month, Mark is not only a pundit, but active participant in the ecosystem, [01:24]
-
-**Mark:** am making the news. [01:26]
-
-**Carl:** making the news and then reporting on it. Cool.
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Yeah, let's start off briefly, overview of the job market tech. Man, you know what? I thought it was like recovering a little bit, but I'm looking at the metrics and like, okay, the FRED data, some Federal Reserve data source, it only shows job postings to Indeed, so like that's a pretty narrow slice. [01:50]
-
-Who knows what other activity is happening, but like, presumably they're publishing it because they believe it's a reasonable proxy for the broader market. And it keeps going down! It just keeps going down. I don't know, hopefully that's just an indicative of Indeed, like, not being the place where people hire software engineers, which, you know It's probably, likely true? [02:09]
-
-I don't know. But yeah, it's just lower and lower every month it looks like. It's lower in January than it was in December, and December was lower than November. So, that's not great. Layoffs are also trending down. There's not as many people getting laid off anymore. But there was a bit of a spike in January this month. [02:26]
-
-Looks like 5, 200 people were laid off from 20 companies. Yeah, that's fewer companies than December, but like twice as many people, so that sucks. I think a lot of those are coming from a small number of companies. Yeah, Meta laid off 3, 600 employees two weeks ago. So yeah, job market is maybe not gonna be As improving as quickly as I hoped it might from some early indications towards the end of the year and in the first couple weeks of 2025. [03:00]
-
-But conferences still don't have a ton of queued up ones. I think people are still getting their ducks in a row with planning and scheduling for 2025.
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl:** like I said in the open, we are sponsored by Infinite Red. They are currently our only sponsor. But we don't communicate with them about, like, editorial or anything like that. They gave us some money, and I shot them out. Woo! They are an expert React Native consultancy that's been around since 2015. [03:22]
-
-And they're our only sponsor in part because so few companies do as much as they do for the ecosystem. They, put out a newsletter. They host the largest React Native podcast. They run, I think, the largest US based conference. Specifically on React Native and generally they are just like great people who do good work. [03:44]
-
-They have built over 75 apps for companies ranging from startups to the biggest in the world and they generally work with your team to help you develop expertise, not just build the app for you and get out of there. So yeah, if your company is looking at starting up a new React Native project, definitely consider reaching out to them. [04:02]
-
-They are infinite. red. [04:04]
-
-**Mark:** I've met Jamon a couple times and seen some of his discussions online. He's a good guy. [04:09]
-
-**Carl:** I mean, they're our sponsor because I met him at a conference and just sort of chatted idly about what we were doing. He was like, yeah, that sounds good. Let's talk more. great dude.
-
-## New Releases
-
-**Carl:** into some new releases. Not a ton this month, in part because I've been distracted with some other projects and have not paid quite as close an eye as I would have preferred.
-
-## [React query 5.63](https://bsky.app/profile/tkdodo.eu/post/3lfaeteulds2i)
-
-**Carl:** But React Query put out 5.63 looks like, you know, I mean, it's a 63 point release, like there's, it's gonna be some fine tune and revisions, but uh, looks like they added an ability to unsubscribe an observer from the cache which should help in React Native. So, yeah, PanStack, great, great resource.
-
-## [Docusaurus 3.7](https://docusaurus.io/blog/releases/3.7)
-
-**Carl:** Docusaurus also put out version 3.7, so if you're using that, consider upgrading. Great [04:52]
-
-**Mark:** actually updated the Redux Toolkit doc site from DocuSource 2 to DocuSource 3, and it's definitely some improvements. thing I think was in 3.6, previously they've always used Webpack as their build tool. And with 3.6, they introduced an experimental option to use the RS Pack, Webpack re implementation in Rust for faster builds, and it definitely did seem to speed things up,
-
-## [React Native Audio API](https://blog.swmansion.com/hello-react-native-audio-api-bb0f10347211)
-
-**Carl:** Yeah Mo, you want to talk about the React Native Audio API? [05:20]
-
-**Mo:** so this one is really, Interesting. Because for the longest time, obviously, like, the Web Audio API is incredibly mature. It gives you so much functionality, you can make some really cool stuff with it. So if you're trying to do anything with audio, like, I don't know get information about your audio sources, run it through effects Be able to generate audio graphs, you know, things like showing wave, waveforms and stuff like that. On the React Native side, it's a lot more difficult to achieve similar things because you're dealing with native level APIs, they're not standardized and you may end up having to just write some code yourself to be able to do that on the native layer per platform and to try to achieve similar things. [06:07]
-
-So, the example that is quite common is generating wavelengths. I've tried to generate wavelengths on the client for certain files. Not a very easy task to do, it turns out. So some functionalities like that are just so much easier to do on the web. [06:21]
-
-And so the folks at Software Mansion have recently started building out A React Native audio API, and so the whole idea is, let's try to bring over the Web Audio API, which is incredibly mature, very standardized, and high performance, into the React Native scene, so that you can have the same levels on control and playback as you do on the web, and standardize it. [06:46]
-
-It fits quite well into the sort of universal app story where you want to standardize around web APIs because they're mature and allow native developers to ingest the same ones but delegate the implementation and the runtime of those APIs onto the native layer. So this is quite cool. It's still early days. [07:06]
-
-And it's, it's not, you know, ready and it doesn't have all the bells and whistles that you have in the web, but it is a very, very good step in the right direction. And so I, I'm super excited to see how this evolves over the next few months and years, I guess. [07:21]
-
-## Main content
-
-**Carl:** Cool our main content. So this is our first episode of the year. I was thinking that we'd discuss a little bit about what we'd like to see, but,
-
-## [CRA deprecation, React team against recommending Vite](https://bsky.app/profile/acemarke.dev/post/3lggg6pk7g22o)
-
-**Carl:** Mark, you want to start us off talking about Create React App and we we can springboard from there [07:37]
-
-**Mark:** gladly. So, React 19 came out last month, in the culmination of, couple plus years worth of technical effort from the React team, and we've all been very excited about that huge jump forward for the ecosystem. Thanks But it also had some unexpected technical side effects, and the technical problems have then spiraled into drama. [07:57]
-
-And I actually happen to be squarely in the middle of that. So I'm going to be describing things, I am both a participant and an observer. And we'll go from there. So Create React App came out in late 2016, early 2017, and it was designed for a couple of purposes. The whole point was make it really easy to start a new React project with a good default build config out of the box with one command. [08:23]
-
-You know, previously you had to spend a lot of time configuring yourself. And so part of this was to make it easy for beginners to start a new project and be able to focus on trying and learning and using React. And it also, you know, had, you know, was perfectly fine for actual production projects as well. [08:42]
-
-And so Create React App succeeded wonderfully. It became the default standard, you know, set up for tutorials. Lots of companies used it for actual apps, but over the next few years, you know, other build tools came out, things that were faster than Webpack CRA was having trouble kind of keeping up with, you know, some of the maintenance demands. [09:03]
-
-They were very slow, you know, dealing with the, the Webpack upgrade. [09:07]
-
-**Carl:** Right [09:07]
-
-**Mark:** And by like 2022, Create React App was actually kind of basically unmaintained. Now, even though it was in the Facebook GitHub org the last people maintaining it were not even Facebook employees or, or part of the React team. And it basically like a ton of issues had piled up.
-
-## [Dan’s “why CRA exists, don’t use it, possible future options” comment from 2023](https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741)
-
-**Mark:** So in, I think it was early 23 Theo Brown put up an issue saying we should mark Create React App as deprecated and we should point people to use Vite instead. That's it. And, you know, he, the issue got, you know, went viral and it collected tons and tons of thumbs ups and eventually Dan Abramov responded and wrote a massive detailed reply saying, saying, here's why Create React App exists. [09:55]
-
-We see that the ecosystem has changed. We've also been changing some of our thinking about the right ways to use React. And here's five possible futures for the Create React app tool, ranging from kill it completely to, modernize it, to change the CLI tool to be a multi launcher that would end up pointing to, creating a next app or uh, remix app or something. And that's where things kind of left off. You know, lots of people read that comment. The community just sort of absorbed the knowledge that you're not supposed to use Create React App anymore and everyone asking questions about how should I start a project was told, use something else. But Create React App itself never formally got deprecated. [10:40]
-
-The CLI still ran, nothing changed in the docs, Dan's extensive comment was never turned into actual documentation. And so that brings us forward to, you know, this last month. React 19 came out and Create React App promptly started breaking. The Create React App CLI has always tried to install the latest version of React into whichever template package you specify. [11:06]
-
-And the templates have some dependencies, including tools for linting and testing. And it turns out that the React Testing Library version had a peer dependency on React 18, and suddenly CRA was trying to install React 19. And since NPM throws errors anytime there's a peer dependency mismatch, what happened was you try to run create react app my app, and it promptly throws errors saying I was told to look for React 18, but there's React 19, these don't match. And so over the last month, I've seen dozens of people file issues or You know, Reddit threads or comments saying, Hey, I'm trying to start a new React project, and it throws an error. And a lot of these people are beginners. And so I was seeing so many of these threads pop up that I began to make a couple comments on social media saying, Hey, like, no one owns Create React App at this point. [12:01]
-
-It's unmaintained. This is bad for the ecosystem. It's bad for beginners who don't know they're not supposed to be using it and are just trying to follow a tutorial. And that's actually part of the problem, is that a lot of older tutorials They'll reference create React app and no one's telling them you should be using something different. [12:21]
-
-And if it breaks, they don't know what their other options are. [12:24]
-
-**Carl:** the SEO for it is so strong. Like if you're just, if you don't know anything about the ecosystem and it's like, I want to make a new React app, like you search new React app or something like that in Google, [12:35]
-
-80 percent odd, you find Create React App. [12:38]
-
-**Mark:** I literally Googled that, and the, the top hit is the actual CRA docs. The third hit is the legacy React installation page. And like the second hit is the current React installation page. So I started griping about this on social media. And the second or third tweet that I put up about this actually is what really spawned the discussion and drama. [13:03]
-
-So that thread went viral and took off. And a couple members of the React team, Dan and Ricky, began to reply. And Overall, my main goal was, I felt that number one, somebody, aka the React team, that had the right project permissions, should fix the Create React App templates so that it doesn't error when you create a new project. [13:26]
-
-It's still a tool, it should work, it shouldn't break. But, both the CLI tool and the docs should be updated to say, Create React App is deprecated, don't use this anymore. Like, yeah, it'll work, but you shouldn't use this. Thanks. And that they should, you know, hopefully point to like some kind of a migration guide, like here's what you should use instead. that's where we also start to run into other problems. if we point people to the existing new React docs, start a new project page, that's the one that specifically says you should only use React with a framework like Next, Remix, Gatsby of all things, and Expo. And it actually specifically argues against trying to do things yourself. Now, the most direct equivalent to Create React App today is Vite. And Vite works great. And in fact, Vite is being used by millions of React projects. But the React docs don't actually list Vite as a real option. [14:30]
-
-They mention it a couple times. And it's buried down in, at the bottom of the React docs. Can I use React without a framework section where they sort of grudgingly say, well, if your project doesn't fit any of these constraints, I guess you can use something like Vite which I'll get, I'll touch on that a bit further later. So to me, the right thing to do to get people off Create React App is to have Vite listed prominently on the setup page because it's the direct equivalent and say, this is good for someone who's beginning or has, you know, just doesn't need all the bells and whistles that come with a framework. [15:10]
-
-So that turned into more arguments. The React team still insists that you should only ever use a framework and have generally refused to list Vite in that page. And a lot of other people besides myself find this to be a pretty ridiculous stance. So the good news is after, you know, a lot of debate online this weekend, the React team did say we will update Create React App so it doesn't break. [15:35]
-
-Mark it is deprecated, and we will do some work to change the SEO on the old docs and the CRA docs to try to point them to the current SEO. Setup page. And so I've, I've seen Ricky doing the work in the PRs on that in the last couple of days. So it's been a lot of frustration and debate. [15:53]
-
-The good news is the immediate problem appears to be getting solved. Doesn't touch on changing the docs to list Vite as a valid option. And then that ties into all kinds of other general complaints about how the React team runs things. So that's the general state of play. [16:12]
-
-**Carl:** It does seem like the, this stems a lot of the worst of the bleeding, like, you know, the SEO issue of if you're trying to enter the React ecosystem as a newbie, then those PRs will address the worst of that in that, like, I think they realized that there was like a real legacy issue, legacy docs issue in that like, The SEO for those links are so good that it ranks above the current docs in a lot of cases. [16:36]
-
-So I'm glad to see them looking at ways to manage that SEO, but like, I've also managed documentation sites before and done SEO for them, like it legitimately took six months for those SEO changes to like fully settle down. So it's just going to take a minute for these changes to fully be reflected in search results too. [16:57]
-
-**Mark:** You know, I don't blame them for you know, taking a few weeks for this, you know, Create React App breakage to bubble up. You know, like I said, no one had really been maintaining Create React App through 21 and 22. It's been widely considered deprecated and no one's owning it for the last couple years. [17:18]
-
-So, You know, no one's really looking over at the repo issues. I saw the issues being filed in the actual React repo and on Reddit and Reactaflux. But I can understand that, like, it wasn't bubbling up and, really catching their attention. So, I'm not upset that it, you know, it took me, you know, raising this issue and pushing it and, kind of stirring up the drama in order to get their attention. [17:43]
-
-I can also understand that, you know, with React 19 having just come out, like, they're still kind of trying to catch their breath from that. That said, like, obviously I'm overly invested in this because I was the one trying to make the point that it needed to be fixed, but I've spent so much of my time as a maintainer Trying to think about how beginners will, read my documentation or, Trying to make things easy to use or answering questions from beginners And so I, you know, I care deeply about, giving beginners a good, you know, Startup path. [18:12]
-
-And so it kind of bothers me that, they didn't jump on this as, Oh yeah, this is an obvious problem and we should do something about it right away. [18:20]
-
-**Carl:** yeah, Dan gave such a long and thoughtful reply, acknowledging the issues, but then, yeah, it's, it sat for two years. [18:27]
-
-**Mark:** There was kind of like, like I said, kind of the spinoff of the, you know, CRA is broken part is that the insistence on using a framework has become. Such a stubborn ideological stance, and I understand the reasons why the React team feels it's better for people to use a framework, it's coming with all the pieces out of the box, those pieces are pre assembled to, you know, be guaranteed to try to work the right way You know, the React team has kind of shifted gears to where they feel that, you know, server rendering is an important capability, routing is an important capability. [19:03]
-
-You know, obviously it ties into their vision for React server components, which can only work with a framework for technical reasons. for years I've felt that there is a pretty big disconnect between how the React team thinks that people are using React, And how people actually are using React in practice. [19:23]
-
-And there's, there's, there's a lot of reasons for this. I experienced it myself with Redux. Like I, I don't even use Redux to build apps anymore. And so I'm, as a maintainer, I'm having to just kind of like take cues from issues people file or, well, a lot of people have asked for this feature. [19:39]
-
-I think it's worth it. But it's, it's reactive and I'm sort of over in my corner doing things almost by guessing. So there is always that danger when you spend all your time building a library of not seeing and feeling the way it is to use something in the real world. And, you know, part of the issue is that the way Meta, Facebook uses React, is different from how everyone else does, just because Meta has all their own infrastructure for routing and serving and bundling and everything else. [20:08]
-
-They don't need lots of third party libraries for that. But, given how huge React is, It is at least the job of the maintainers to be aware that it's used in a lot of other ways. And even if you don't necessarily want to focus on all those use cases, you still need to be able to be aware and support that. [20:31]
-
-And a lot of the React team's decisions and statements over the last few years have been basically very focused on we sort of assume that everyone who's using React is using it to build a server rendered, data fetched, routed CRUD app. And we don't really seem to care about any of the other ways people use React. [20:53]
-
-**Carl:** Yeah, having been paying attention to React since it was like, since relatively shortly after it was open sourced, there has always been a pretty clear, I don't know, like they came at developing React with a philosophy for how to do web development. [21:09]
-
-And I think that like over the last 10 years of React, 12 years of React. I think that has borne out more often than it's, there's always been people saying like, What the, what the heck are you doing? Like, this doesn't make any sense, this isn't, how I want to use it, you should be doing this. [21:25]
-
-And I have seen many cases where the naysayers were wrong. I am sympathetic to the, You know what the vibes that are I'm getting from the core team of like, this is our lane. Like, we understand what we're doing here. Like, "you'll understand one day" kind of vibe. but I, I think there are a couple of, I don't know, I guess they, they've always had this ideological stance that they were sort of. [21:49]
-
-Putting out into the world like people talk about react brain and you have to like change the way you think in order to Really effectively develop with react and like coming out of react you have to sort of Drift back into a different way of thinking to use other tools again And I think that's real and I do think that it's One of the great things about React, but I don't know It's uh, we're definitely in a kind of weird spot here where I guess some of the specifics about it have gotten a little bit Divorced from the everyday usage. [22:20]
-
-Yeah [22:20]
-
-**Mark:** Yeah let me give three reasonably specific anecdotes that kind of tie into this. So, when the new React docs came out a couple years ago that's when they, they really made that shift from, you know, you, you can use create React app, the old React doc said, if you're learning or building a single page app, use CRA. [22:42]
-
-If you need server rendering, use Next. If it's a static site, use Gatsby. The new doc site, when it came out, said, use a framework. Next, Remix, Expo. And then it had the Can I use React without a framework section with five paragraphs of explaining why they think it's a bad idea. And the original screen at the end of it was, if you feel you need to do something else go ahead, we can't stop you. Now they've said they didn't mean that to be sarcastic, But everybody I've talked to have said, like, that is just like the most passive aggressive, insulting way to phrase it. And it took over a year for them to finally rewrite that paragraph to take out the passive aggressiveness. [23:27]
-
-And, like, that is not a good way to treat your user base. Especially when using React without a framework had been the default way to do it. And it's what you were recommending in your docs up until you flipped the switch on the new ones. Second example, so the suspense gate thing last year, you know, the React team had made a code change to alter how nested suspense components in as siblings would load from in, in parallel to in sequence. [23:58]
-
-and you know, they had a good reason to make a change. You know, they were trying to make facebook. com a little bit faster and I'm not expecting them to have gone out and like, you know, run hundreds of example apps just to see if this might alter anything. But it Later on, in some of the discussions, they were saying, Well, I mean, you really shouldn't even be doing this pattern anyway. [24:18]
-
-Like, if you want good perf, you should always be hoisting your data fetching up to a route or a page for best performance. Which, okay, like, it's a valid thing to do to improve perf, but it turns out that, like, React 3 Fiber people were using suspense to load 3D assets. And it's still a va and like, even ignoring that, nested suspense is a valid thing to do. [24:44]
-
-So, it's a, you know, second example of, well, we, we really assume that you're gonna be doing things this one way that we recommend, and Not really following through of, but are there other people doing things a different way? And as a last example I even just ran some quick searches on GitHub in the last couple days, just querying for package.json [25:05]
-
-files that reference either Next, the Vite React plugin, or the React scripts package from create react app. And it's, it's napkin math, I think it might have actually been, like, CRA was 1.9, Vite was 1.1, and Next was 1.5. And so, mathematically, that means that there's 3 million projects that are You know, a basic single page app, and only one and a half million projects that are on Next. So the single page apps actually outweigh Next by two to one. [25:38]
-
-And yet, the React docs don't even list Vite fairly compared to the other options. So it feels like they're cutting out an awful lot of the ecosystem compared to how people actually use it. [25:50]
-
-**Carl:** Right, right. And like the, the recommendations they make around like best practices for performance and like whatever around loading and how to use suspense. Like, those are great. That's true. I don't disagree with it, but I also like most of my projects are like solo things. Or, you know, I'm collaborating with like one or two other people. [26:10]
-
-And I'll skip a lot of that a lot of the time just because it introduces complexity. Like it's, it's an extra couple of days of like introducing scaffolding and, piping data around. And like then, especially when I'm just like iterating and exploring and I don't really know if I'm even following the right path yet. [26:28]
-
-Like, I don't, I don't want to do that yet. I'll do it later once I know it's good, and I do want to care about performance, but that to say that like, I think a lot of development ignores those best practices because it is, because ignoring it is the right trade off for that bit of work, you know, the available, you know, it If you end up not shipping because you tried to follow all the best practices and blew out your budget for time or money or, you know, motivation from your contributors, then like, that's not great either. [27:00]
-
-Yeah. [27:01]
-
-**Mark:** So, in general I've seen a lot of frustrations about how, you know, the communications has been handled, about the React team's resistance to, you know, just adding a couple paragraphs in a header to one docs page. And I have a lot of thoughts about it that I'm working on writing a blog post on that will hopefully come out in the near future. [27:19]
-
-But that's, that's been a pain point for myself, for a number of other prominent figures in the React community that I've talked to, and for a lot of other people that I've talked to as well. [27:31]
-
-**Carl:** Well, so maybe, maybe let's try and bring it back. what do you think good relations from the core team to the ecosystem might look like over the next year? Like, just blank slate, what is, what does a good, I don't know, comms program look like? [27:48]
-
-**Mark:** Yeah, so, I've actually, you know, mentioned this in a couple of my tweets, if I could magic wand things, we've fixed the CRA brokenness, that's great, we're marking as deprecated, great. You know, for CRA specifically, I would get the docs updated, so the CRA docs have migration guides, and they point to the setup page. [28:07]
-
-And the setup page lists Vite as both a learning tool and a, if you just want a simple project. Because that both handles the, I'm a beginner, I just want to start a new project so I can write some components and learn aspect. But it also recognizes the breadth of ways that React is actually used. [28:28]
-
-In practice, whether it's, I'm spinning up just a little sample project or, you know, an enterprise that has like a Python or Java backend and can't even run Node on their server. But just like, we're not even giving you details, we're just saying here's a valid way to do it and here's a pointer to where to go. [28:45]
-
-Another thing that the React team has struggled with is general public updates on where they're going. And there's a lot of reasons for this. The React team has historically not had, a real full time paid devrel person. Historically, Dan Abramov did a lot of that work in an unofficial sense. [29:04]
-
-Like, he was the public face of the React team, but it's just because he spent all his time answering questions on his, of his own volition. they've hired a couple devrels or announced that they had a devrel a couple times, and then those people always seem to just sort of and not really do anything within a couple months. I think Matt Carroll has been in that position for a while, but in all honesty, I couldn't tell you much of what he's done. I know I've seen some people say they've had conversations with him, [29:36]
-
-**Carl:** I do know he put a lot of energy into the, into React Conf last year. But obviously a conference is not a like complete developer relations strategy, I don't know. But yeah, just to say, I do know that was a big effort. [29:48]
-
-**Mark:** And especially since, you know, Dan shifted over and both left Twitter publicly and actually started working at Blue Sky. It generally feels like there's no one from the React team who is actively reaching out and looking to be involved in conversations. [30:06]
-
-flip side of this is that a lot of that has come from Vercel and Next. [30:12]
-
-You know, Lee Robinson has been incredibly active in terms of actually looking for discussion threads around Next. And popping in, but also the Vercel dev rels have written some really good content explaining things like how, you know, how does, you know, suspense or concurrent rendering work and, you know, how to use some of the new React 19 features. [30:35]
-
-And some of that is in the next documentation and it's not at all in the core React docs. Some of it's on the Vercel or Next blogs and it's not in the core docs. Thanks. And frankly, a lot of that information feels like it should be in the core docs. Like, you know, the core docs describe the use server and use client directives. [30:59]
-
-And they, they talk about some of where and, and when to use it, but they don't have any information on what are server components, how do they fit into the React architecture conceptually, when and why would I want to use server components in general? And so that, that feels like a documentation gap there. [31:21]
-
-**Carl:** Yeah. [31:24]
-
-**Mark:** docs are wonderful. Dan poured his heart and soul into this tutorial. It is excellently crafted, comprehensive. In page sandboxes, all kinds of other things, it's great, but if you were to follow the tutorial linearly, you get past the couple of, like, nah, never use useEffect pages, then it just sort of ends. [31:47]
-
-And there's no direction on how to take this sort of theoretical knowledge of I'm writing some components in these sandboxes, and How to actually apply that to starting a real project. So like at a minimum I'd like to see a page at the end that says, Okay, you've finished the tutorial, great. Here are some active next steps. [32:08]
-
-Here's how you can start a project. And by the way, if you're like using Next or Vite or Remix. Here's how you would write components in the file structure in those actually give people a pathway. And then the last thing I'm, I guess, one other thing I'd like to see is more active communication on the blog. [32:28]
-
-Historically, they've done announcement posts for big releases. And then they basically do like one. What we're working on post a year. That's about it. I realize that they, you know, they do a lot of prototyping. They're very reluctant to, you know, give early details on prototypes because everyone gets overexcited about them. [32:51]
-
-And, You know, also this goes back to the, you know, the lack of a formal devrel person to have the capacity to do the writing. But, you know, even, and just, you know, some more frequent updates on what direction we're headed, or the kinds of things we're experimenting with. Even if you have to plaster it with, with very loud, this is a proof of concept. [33:11]
-
-Labels you know, the idea of using the TC39 stages as descriptions of how far along things are has been kicked around a few times. But you just, some sense of like, what is the roadmap and where are we actually going would be nice. [33:28]
-
-**Carl:** Or like, heck, like you said, there's lots of great blog posts that people like Lee Robb or other, you know, Next and Vercel people are putting out. Like, just reposting those to the official blog would probably be pretty good. [33:41]
-
-**Mark:** another one that I saw was the uh, I think, Some of the, you know, the team folks did a lot of great work in fleshing out the API references in the docs. And the only indication that anything had changed was they made a post in the discussions section of a, of a working group repo. No one is reading that. [34:03]
-
-Put up a blog post saying, Hey, we added five new docs pages covering these topics. Like that is a thing worth announcing. [34:10]
-
-**Carl:** Absolutely, 100%. Yeah. Well, one other thing I want to chime in on. On the documentation side of things too, I just saw, I just caught some discussion from people looking to make their own frameworks, were expressing frustration, like, you know, they were reading the docs and it says like, this is best left to the framework authors, and they're like, that's me! [34:30]
-
-How do I do this? yeah, [34:32]
-
-**Mark:** or library authors. Yeah. [34:34]
-
-**Carl:** right, and you know, then I'm seeing people talk about like, oh yeah, I was, I, I spent a week, three weeks, months reverse engineering this and understanding it so that I could write something on top of it, and it's like, yeah, you know what, that's, that's a pretty big documentation gap if like a half dozen people are all reverse engineering stuff in order to do what is being advised, you know, they're trying to own it, [34:58]
-
-**Mark:** seen a couple framework author kind of behind the scenes discussion groups and there, there is chatter back and forth and asking questions, but I mean, again, like a lot of that stuff would have been nice to see covered in public documentation in the first place. [35:15]
-
-**Carl:** I guess maybe, maybe to close this discussion out, this is all like refinement. Like, I also want to highlight that as far as frameworks for building web applications, The React documentation is absolutely world class, and like, you compare it to its peers in the, you know, ecosystem, and like, both what it's trying to do and how well it communicates it to someone trying to learn is actually quite good. [35:45]
-
-in my opinion, like, I, I think that there are many things that it does really, really, really effectively, and As, you know, pundits opining, we're seeking out the rough edges to focus on. I do just want to bring that in. [35:59]
-
-**Mark:** I have huge respect for the React team. I have a very good understanding of the constraints that they deal with, both from having watched and talked to And then, you know, as a, as a maintainer of a widely used library myself, I, I totally understand, like, I just don't have time to sit down and document this. [36:15]
-
-it's both the, the success that they've had, And the work that they've put in that makes a lot of these gaps and pain points all the more frustrating. And so it's not that they're doing a bad job. It's that the pain points really stand out. [36:32]
-
-And a lot of them feel like self inflicted wounds that could have been addressed fairly simply. [36:37]
-
-**Carl:** And, perhaps, because it has had such a vibrant, thriving ecosystem for so long, and so many phenomenal, wonderful, generous, talented individuals who are filling some of these gaps, Like, now that the momentum, now that some of the heat has gone out, like, you know, there was a, there was probably a five year span where a lot of the hype in tech was focused on React and now, you know, then there was like a kind of like, ooh, should we focus on Web 3? [37:08]
-
-Like, ooh, is blockchain interesting? And there's like, no, no, no, actually, no. And now, like, that, that laser has Fully focused away from tech like React and more onto AI things. So I think that a lot of those individuals who were driven and talented and motivated and ended up filling those gaps are now doing other things. [37:27]
-
-makes sense and it's fair, but it means that those gaps are not getting filled anymore. [37:31]
-
-**Mark:** I have a lot more thoughts on this topic. I will not go through them here. However, I am planning to put up a very, very, very long blog post explaining a lot of this stuff hopefully within the next few days. [37:43]
-
-**Carl:** I've read half of it. It's good. Okay. Moving on.
-
-## [Revealed: React's experimental animations API - Motion Blog](https://motion.dev/blog/
-
-**Carl:** Somewhat small. We can maybe do this in lightning round, but too late. speaking of new developments in React, there is an experimental animations API taking advantage of the view transition, platform API On the web.
-
-## [Main PR](https://github.com/facebook/react/pull/31975)
-
-**Carl:** Uh, It's currently unstable. It looks like it's going to be a view transition component that also comes with a little bit of ceremony around how to set state in order to make the transition aware that a change happened. [38:12]
-
-But seems cool. I don't know if view transitions look great. And being able to easily tap into them when you're doing your react logic. Definitely here for that. Looks great. [38:23]
-
-**Mark:** I still don't even know exactly what view transitions even are. I've been too occupied to have a chance to read about or learn them. Having said that, this also does feel like kind of a big deal. People have been griping about the lack of real animation support in React itself for years. There's been lots of, you know, community packages, Motion and React Transition Group, and A whole bunch of other things. [38:48]
-
-and they've said that they wanted to get around to it eventually, but it really needed to be integrated into concurrent rendering behavior because you got to track multiple copies of the tree at once. So this does actually feel like a pretty big step forward. [39:01]
-
-**Carl:** Yeah, and I used like React Motion Cheng Lou's library from many, many years ago which was great. I found that really cool and really powerful. I did some really fun, exciting things with that. the single most fun thing I did with that, I did a spotlight. Like onboarding tour for an app I built, where I did a custom SVG to cut a hole out of a, like, transparent, translucent overlay. [39:26]
-
-And then I used React animation to, like, animate it, and so it would, like, do a, like, little springy animation around. And, like, it was performant. It was fast. It took me, like, three hours to do. So for me, user space implementations like that were like, cool, great, this is solved, I don't need to do this. [39:44]
-
-And I don't need React to be more aware of this because this works great for me. I think that's part of the reason why they haven't brought anything in before this. And I think now there has been more of a, I don't know, general understanding of how animation should work at a platform level. [40:01]
-
-And so They've been brought in as platform features to do like flip animations. First, last, interpolate, play. And so I think that's what view transitions are, but I'm in the same boat. I've read about them. I have not actually put them to practice in any real project yet.
-
-## [Static hermes update](https://x.com/tmikov/status/1869945330638442651)
-
-**Mo:** Let's jump into Static Hermes, because I think that one's quite interesting. So, we've talked about Static Hermes over the last few months a few times, but right before Christmas there was an update that went on by Tzvetan, who's basically really the person who's leading the efforts as far as I know, at Meta, and so people are kind of asking the question, like, when is Static Hermes actually going to come out? [40:38]
-
-Because we saw it like years ago. It was super exciting. When is it coming out? And I think we got the first glimpses of hope in there. In the sense that in 2025, so in 2024, they say, next year they want to start to make it an opt in branch and maybe towards the end of the year, later in the year, at some point, make it the default React Native Engine. [40:57]
-
-And one of the biggest hurdles that they face, which they seemingly have overcame now, is that There wasn't good support for un typed JavaScript and obviously there's gonna be a lot of un typed JavaScript in the world. Like the whole premise of static Hermes is that you use the types within TypeScript to be able to compile better typed code at a c plus plus level. And so this is a big step and it was one of the hardest sort of hurdles that they had and they've compared the performance. with different benchmarks and seemingly they are doing, you know, somewhere to the ranges of 20 to 60 percent better with a bunch of different benchmarks that they're trying. [41:36]
-
-So it's quite cool and we'll see how it evolves, but I guess it's a very exciting update, whether or not that stays in practice and it'll be, you know, available at some point in 2025, we'll see, but you know, first glimpses of a supposed Timeline of delivery. So we'll, we'll see how that plays out. [41:53]
-
-**Carl:** Yeah, definitely makes sense that untyped JavaScript is a major hurdle, like, yeah, it's a JIT compiled language. If you're trying to do a static compilation of it, that's gonna be tough. [42:03]
-
-**Mo:** And it's honestly like super impressive what this team has been trying to achieve in itself. It's it's I don't think I have the capabilities to be able to, to dissect such hard problems. So kudos to them. [42:14]
-
-**Carl:** And also, just to, like, carry in the tone from this, you know, Hermes update post, I love that it has this hero image of a, I'm gonna call [42:21]
-
-it a flag that says "we do this not because it is easy, but because we thought it would be easy." [42:27]
-
-**Mo:** I love that so much, yeah, that hero images. Tzvetan is a really funny guy, like a very like, specific sense of humor, I've met him a couple times at conferences, he's just, he's such a joy to be around.
-
-## [React Native Hosting with EAS](https://expo.dev/blog/expo-announces-eas-hosting-service)
-
-**Mo:** I also want to quickly touch on Expo hosting, so this was announced a few weeks ago, and so, in sort of that light of, you know, there's Resell, which is the way that you host React applications or so called Next. js applications, I guess, mainly and you know, it's the framework that you use with the Expo world, obviously they are also kind of going into that footing of, we are the framework to use, and we also can host it because Expo is obviously going in this universal direction of, you can also use Expo and React native on the web and build full stack sort of across the board multi platform application on web and mobile and so obviously as part of that you're going to have to think about hosting where do you host the web applications and so they've launched EAS hosting which is their sort of first attempt at creating a hosting platform that will host your, you know, Web applications, but also your API routes, because if you remember from last year, we talked about Next.js's [43:31]
-
-API routes that they had, and so very similar to Vercel's API routes, you've got Next. js's API routes now, I'm sorry, you've got Expo's API routes now. And so it's a very sort of basic hosting platform for now. It lets you keep a track of, you know, the requests coming in, your deployments, the crashes. [43:48]
-
-And just some basic logging into your requests and so on and so forth. But I think it's, it's a, it's an interesting start and it's, you know, it's one of the pieces that they've been missing a little bit when it came to this universal story. So, we'll see how that expands, we'll see how it grows and evolves, but it's just the first and the early days of, you know, of EAS hosting. [44:07]
-
-**Carl:** I wish I had more to say on Expo, because it does seem really cool, and I have really admired its development over the years, but man, I just, I don't, I don't need to make native apps. Maybe one day. [44:17]
-
-as I'm charting my year in January I have a couple projects booked for the next couple of months, but back half of the year I might actually try and do like a fork of the Blue Sky plant, and that's Expo, so hey, maybe I'll get some real first hand knowledge [44:32]
-
-**Mo:** very keen. I love the comment. Someone's saying, I wonder if Tanstack will launch their own hosting one day. [44:37]
-
-**Carl:** That makes, yeah, that actually would not surprise me. Yeah, Mark you want to tell us everything we need to know about Node. js type stripping?
-
-## [Everything You Need to Know About Node.js Type Stripping](https://satanacchio.hashnode.dev/everything-you-need-to-know-about-nodejs-type-stripping)
-
-**Mark:** Well, I won't, but I'll tell you about the post that does. So, like bun have TypeScript support built in, but it's basically been like, Okay, we read the TypeScript source code, don't bother type checking it, we just execute it. And so, you know, given TypeScript's popularity, Node has finally jumped on the bandwagon and some of the latest Node releases actually integrate some tools that will do the type stripping so that TypeScript syntax code can at least run directly in Node without needing an additional tool like the TS Node. And, the big thing about this is that because they're stripping the types, they're not doing type checking the output also needs to be, like, your TypeScript code needs to be just types. Now you might think, well, it's TypeScript. Of course, it's just types. The problem is that some early TypeScript features do also result in additional runtime code being generated. [45:43]
-
-For example, when you use the enum keyword in TypeScript, it results in an object lookup table being added. And so because Node is just stripping the type syntax, if you try to use an enum with this new Node feature, it'll actually break things. So, I believe one of the upcoming TypeScript versions will actually have a flag that will enforce that you're only using type strippable syntax, but Big picture what this means is that it'll be easier to take, like, a node script that is written as a ts file with ts syntax and just say, like, node myscript.ts [46:25]
-
-or whatever. I don't think you have to pass in any additional arguments. So overall, it's, it's basically like matching the feature set of other tools like Bunn and making it easier to use TypeScript code across the ecosystem. [46:38]
-
-**Carl:** yeah, I am trying to quickly refresh my memory here, but I believe that I am actually using the strip types. No, I played with it but I found a different way around it. Yeah, I did, I did it. This is a feature I got to play with. I have first hand experience with strip types. It was pretty good. But yeah, there's still some weirdness around, like, type extensions, I think, in imports. [47:02]
-
-**Mark:** That does not surprise me. [47:04]
-
-**Carl:** I know, in trying to play with it, I had to do a code mod in order to add extensions, you know, like js extensions everywhere, and yeah, I know, I think a couple of episodes ago, we ended up talking, we talked a little bit about TypeScript, Faking what extensions it would use in order to make that work for compatibility reasons. [47:25]
-
-And so yeah, I got some first hand experience and it's weird. It worked. I got it working, but it felt weird to have, you know, to be authoring a ts or tsx file and importing it as js. That's definitely unintuitive. [47:41]
-
-**Mark:** complicated but valid technical reasons why they made that stance. [47:45]
-
-All right, Mo, I know you need to drop off shortly. Any other points you want to cover before you head out? [47:49]
-
-**Mo:** no, I think it's been a relatively quiet React Native month and I've been completely off the grid.
-
-## [Composable Caching with Next.js](https://nextjs.org/blog/composable-caching)
-
-**Mo:** The only thing that I am quite keen to talk about actually is the caching with Next. js, our little composable caching. Because I've been dealing with Next.js caching for the last two weeks and oh boy, oh boy, [48:10]
-
-I have been trying to, after dealing with the Pages router for a very long time I've been now dealing with Next. js caching for a little bit, and this use cache is obviously something that's more in canary at the moment. It's not published in, in sort of the, the stable versions, whatever that means in Next world these days, in terms of a stable version. [48:32]
-
-But, Basically, the caching is a little bit complex with Next14, as we know, and currently, if you want to cache things like database responses in server components, or you want to cache fetching, you have to wrap it in an unstable cache function that takes in the function, a promise, some key, and then some revalidation time. [48:56]
-
-And so, there's this really weird syntax to do this, and then of course there's also another level of caching when you have static pages, which means those static pages get cached after they're published. Built in whatever capacity. And there's just so many layers of caching at this point. It's hard to wrap your head around how your application is functioning. [49:16]
-
-And to make matters more confusing now, there's this use cache directive that they're planning on introducing, which looks really cool, but I can just imagine this getting ever more and more complicated. And to me, a real symptom of this is the fact that they've 180'd on the defaults of caching with Next 15. [49:36]
-
-Like, you've set some definitions on what is cached by default, what's not cached, and it went so poorly that you had to flip it 180 degrees. That does not give any semblance of stability to me as a consumer of the technology. And so I just look back at the days of the Pages router and wish we could just go back to the simplicity of having and getServerSideProps and just live life in that naivety of how simple that was. [50:06]
-
-**Carl:** I was thinking in similar directions and I'm actually now in a position where I'm maintaining a React Router v7 project, which I upgraded all the way from Remix 1 to React Router v7 in one go, or in one go, sequentially all the way up. And the, the Reactiflux website is I think it's a Next 14 Pages router app, so that one I could probably play with a little bit more. [50:35]
-
-But it's like, oh, I'm now actually maintaining apps on several of the largest frameworks And you know what? I like Remix the best. It's just got, like, the, the mental model is most familiar to me. It seems most predictable. And, like, I hate magic. I am someone who completely avoided the entire RWBY ecosystem because it's too magical. [50:57]
-
-I'm just like, man, Remix hits right for me. not much there. Just yeah, it feels good. I don't know. I like it. [51:03]
-
-**Mo:** I've used Remix as well, and I must say, like, It takes a little bit of adjusting from when you've just dealt with Next. js for several, months and years, but is just simpler. Like it feels more native webby, the bits of magic are really just like the loaders, the actions that you have, but like everything else just feels sort of you're dealing either with React or you're dealing with the web. [51:24]
-
-And I quite like that as a concept. [51:27]
-
-**Carl:** Right. [51:28]
-[51:28]
-
-**Carl:** it lets me think in terms of like, HTML, HTTP, and like, cookies. And like, yes please, let me think about the platform and not the toolchain. Yeah. [51:39]
-
-**Mo:** And someone in the chat, one of our listeners, is actually pointing out that the app router is still defined as the bleeding edge of on the React install docs, basically, on start a new React project. [51:51]
-
-**Carl:** definitely some bleeding happening. [51:53]
-
-**Mo:** So yeah, that was my little, my rant. [51:55]
-
-**Carl:** Cool. Yeah,
-
-## [Thoughts on What RSC Means for SPAs](https://blog.axlight.com/posts/thoughts-on-what-rsc-means-for-spas/)
-
-**Carl:** Mark, next link up is like thoughts on what RSC means. did you read that? Can you talk about that? [52:02]
-
-**Mark:** Yeah, I, I skimmed it a bit. So it's a, it's a post from Daishi Kato who worked maintains Zustand, created Jotai and Valtio and has been working on the, the Waku RSC based framework. So it's a couple different points. One is, can R RSCs actually relate to single page apps? And the answer is sort of maybe yes. [52:25]
-
-Like, you know, for example, the RSC payload could be served statically. And not dynamically generated on a server. it's actually kind of a, kind of a short read, but you know, just like some, alternative thoughts from just like, RSCs are on the server and, you know, can only be used with Next, et cetera. [52:42]
-
-So it's short, but worth reading.
-
-## [Chrome's 2024 recap for devs](https://developer.chrome.com/blog/chrome-2024-recap)
-
-**Carl:** last main content article Chrome put out a 2024 recap. That was just pretty good. I don't know. Some of it, I'd call it like 30 to 40% marketing fluff. [52:55]
-
-They spent a lot of time talking about how they added AI to the chrome dev tools, which I actually have heard some positive things about, like interpreting errors. Like okay, yeah. Neat. But yeah, I noted that it called out view transitions, which just 'cause we talked about it earlier in the episode. [53:09]
-
-Like, hey, look at that. platform and react in unity in sync. I think we'd mentioned this before, but there's a CSS popover and like anchor positioning. So you can do popovers without JavaScript, which. I have implemented popovers in so many apps, and I hate it. I am so tired of it. Like, I do not use popovers anymore because I'm so tired of making them. [53:33]
-
-So, being able to do it without crazy layout logic in JavaScript sounds great. Maybe I will actually use them again.
-
-## Shoutout [webstatus.dev](https://webstatus.dev/)
-
-**Carl:** And I also learned about a new site recently through reading that, webstatus.dev, which has a, like, annualized baseline browser feature summary, which looks neat. Although I'll note that, you know, we're into 2025. [53:55]
-
-We're a month into 2025, and the 2024 baseline is not met. Like, yeah. Safari looks to be generally the worst offender, But, Firefox and Edge also, slipping behind a little bit. Well, no, maybe that's not fair, because Firefox is ahead in a couple of them, ahead of Chrome in a couple of them. So, anyway, this is neat. [54:14]
-
-I love these kind of like, broad based what features Are being implemented. this is how I have always kept an eye on what's coming down the pike. So, didn't know this existed. Cool. Useful.
-
-## Redwood.js shutting down?
-
-**Carl:** I don't have a link for this, but I've heard, through the grapevine, that there will be some impending announcements from Redwood.js generally the shape of what I've heard is that like an original found co founder of the project who had kind of left or like gone dormant came back and has decided that I I don't know what is going on I read some like Google translated slack messages from I believe Swedish and it sounds like a co founder has come back out of the woodwork and basically taken over and Just said like This is good SEO. [55:01]
-
-This, there is value to this domain, this brand. It's mine now. I'm going to do something entirely different with it. So yeah, keep an eye out. Redwood. [55:09]
-
-**Mark:** Another way to phrase it is it sounds like Redwood the framework is dead and the name and repo are going to be repurposed. [55:19]
-
-**Carl:** that's the shape of what I've heard. I think I heard that they will be doing an announcement in the next month. So like, ooh, breaking story, our first one, but, ah, it's just such a shame because I, I've met them at a conference or two, they seemed really good, and I liked the general, like, like, I understood them as trying to do Laravel for the React ecosystem, and I thought that was a pretty good niche, so, just a shame. [55:45]
-
-Shame to see it die to some drama like this. But yeah, there should be some more details, maybe we can talk about it maybe we will have some, you know, perspective to give [55:55]
-
-this month. [55:56]
-
-**Mark:** next month. [55:56]
-
-**Carl:** Actual details, not screenshots of Slack.
-
-## [A checklist for your `tsconfig.json`](https://2ality.com/2025/01/tsconfig-json.html)
-
-**Mark:** Axel Rauschmeyer has done a lot of articles over the years about like, what's new in this year's version of the, you know, the, the ES language spec. He's also been writing some articles recently about some TypeScript related things, like different ways to define a NUS or similar things. And he put up a post call a checklist for your TS config, JSON, which walks through and actually like, looks at a lot of the config options and what they do and when it makes sense to use a lot of them. [56:27]
-
-pretty sure that Matt Pocock has done a similar post somewhere.
-
-## [Recoil repo archived](https://x.com/dai_shi/status/1875910305802514649)
-
-**Mark:** completely different note We talked about Redwood maybe kind of going away. The recoil library repository has been officially archived. Now, it had been unmaintained for a while. I had read from people who had been involved that apparently both the people who had been maintaining it had gotten caught up in layoffs from meta. [56:52]
-
-So, But, honestly, it also seemed as though the project had stagnated for quite a while. The thing that gets me, really, is that when Recoil was first announced whenever that was, like 2017, 18 ish there were just so many people who looked at the announcement and took it as Oh look, this is an official React State Management Library. [57:19]
-
-When in reality it was just some other app team at Meta came up with their own solutions and decided to publish it. But, you know, the combination of Redux backlash, and like, It's from Facebook, it must be official! meant that a lot of people jumped on it, and then it sort of stalled, and then Jotai came out, and Recoil just sort of went away. [57:45]
-
-**Carl:** Sad to see stuff drop
-
-## [Bun: first-class support for s3](https://bsky.app/profile/bun.sh/post/3legdozw3nc2p)
-
-**Carl:** Alright Bun is shipping first class support for S3, which is interesting. So, first class support for S3 here means being able to use it as like a file system, I guess. standard library tool for implementing Or for interacting with file storage services that themselves implement the S3 API, which is pretty widely supported. [58:11]
-
-So this is actually pretty interesting because, like, I don't know, I hate dealing with, stuff like the AWS SDK. I've, like, partially avoided learning AWS because it's just so complicated and annoying. So seeing some little details like S3 interactions being brought into the runtime is actually pretty neat. [58:32]
-
-Yeah. I'm seeing in the chat, there's a lot in that 2 announcement. Sadly, I don't actually use bun in my day to day. So I am just kind of an observer here and I have not stayed super up to date. Just that caught my eye as like, Oh, interesting. What an opinionated stance.
-
-## [Interpolate `auto` height for animations](https://bsky.app/profile/joshwcomeau.com/post/3lf5zwg2ths22)
-
-**Carl:** There is now, I believe in the latest Chrome, there is an interpolate size CSS property you can set on like high up on your your page to allow interpolating allow animations to interpolate between Auto, like if you say height auto and height zero. Previously you couldn't animate between those two states. [59:11]
-
-And now, You can in latest Chrome. That's super cool. I have always thought it was super weird that that extra step of just letting your size, letting the size of an element be automatically determined meant that you couldn't use CSS transitions. That just never made sense to me. So it's, it also doesn't make sense to me why it took 10 years from me feeling, oh, that's weird, to this actually shipping, but super cool. [59:37]
-
-Neat. Love it. I believe it's currently Chrome only, but yeah, I mean, hopefully it'll, hopefully it'll filter out pretty quick. He says, after complaining about waiting 10 years.
-
-## [Free javascript; Oracle not voluntarily releasing](https://bsky.app/profile/deno.land/post/3lfapjn7gns2w)
-
-**Carl:** And a small, extremely small update to something we discussed previously, the Deno organization's campaign to get Oracle to free the JavaScript trademark. [01:00:00]
-
-Oracle has Declined to voluntarily withdraw the trademark. So Deno is doing legal things to advance the process. This is a legal drama. So this is probably going to be something we're still talking about in like 2026. And I would not surprise me if it's like 2030 before the trademark actually, like before this case settles, let's say. [01:00:23]
-
-But yeah, neat. Maybe I'll stop giving updates, but Oh God, it would be so nice if Oracle did not own JavaScript.
-
-## [Understanding React Server Components | Tony Alicea](https://tonyalicea.dev/blog/understanding-react-server-components/)
-
-**Mark:** All right, and last one Tony Alicea is an educator who has written some very, very good deep dive blog posts into some things like React rendering, which is a topic I care deeply about, so I appreciate that and he recently put up a post on understanding React server components. [01:00:48]
-
-Now we've, we've mentioned a lot of different dive into server components type posts over the last couple years. This one walks through a lot of how server components fit into the rendering process, looks at some of the actual JSX related data that is serialized and sent back and forth, and talks about how it then fits into things like streaming and bundlers and hydration. [01:01:12]
-
-So it's not something you would read to understand, like, how do I use a server component? But it's a really good explainer that, you know, how digs through a lot of the technical aspects and talks about why server components work the way they do. [01:01:26]
-
-**Carl:** Yeah. Oh man. Wouldn't it be cool if this was put out as like a guest post on the React blog? [01:01:32]
-
-Cool. Okay. That's all of the links we have for you this month. Thank you for our persistent listeners who stuck with us all the way to the end. Yeah, we'll be back on the last Wednesday of February next month or in this episode, we'll be back in your podcast feed just as soon as we can. Thanks so much for listening. [01:01:50]
-
-**Mo:** Lovely to be here with you all again every single month. it's always a pleasure. Thank you, Mark. Thank you, Carl Thank you to everyone who's listening in and see you all in February [01:01:59]
-
-**Mark:** Yep, thank you, appreciate it. And if you want to stay up on the current drama that I am involved in in the React ecosystem, please follow me on Bluesky or watch for my upcoming blog post within the next few days.
-
-## [Follow us on Bluesky!](https://bsky.app/profile/tmir.reactiflux.com)
-
-**Carl:** Oh yeah, we can follow, you can actually follow this podcast on BlueSky too. We are tmir.reactiflux.com and I'm going to put a link in here. Cause you know what? I should do that. [01:02:23]
-
-We gather sources from thismonthinreact, bytes.dev, reactstatus, nextjsweekly, the reactjs subreddit, here in Reactiflux from the techreadsandnews channel, and sometimes even directly from people publishing content. [01:02:38]
-
-If you see anything that would be useful for us to discuss or just that you want to share with the community. Definitely pop it in the Tech Reads the News channel, or if you like, you can send it to hello at reactiflux.com. I will read literally anything you send to that. So, yep, go ahead. If this is a show that you get value from and want to support, best way to do so is by submitting a review, wherever you listen, or tell people about it. [01:03:02]
-
-It's great. Help us grow. Woo!
diff --git a/src/transcripts/tmir-2025-02.md b/src/transcripts/tmir-2025-02.md
deleted file mode 100644
index 523c407..0000000
--- a/src/transcripts/tmir-2025-02.md
+++ /dev/null
@@ -1,494 +0,0 @@
----
-title: "TMiR 2025-02: Updated new project docs"
-date: 2025-02-24
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:11](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
- - [[02:35](#microsoft-performance-based-job-cuts-have-started)] [Microsoft Performance-Based Job Cuts Have Started](https://www.businessinsider.com/microsoft-performance-based-job-cuts-have-started-termination-letters-2025-1)
-- [[03:07](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[03:10](#react-paris-march-20-21-paris-france)] [React Paris](https://react.paris/) March 20-21 Paris, France
- - [[03:14](#react-native-connection-april-34-paris-france)] [React Native Connection](https://reactnativeconnection.io/) April 3–4 Paris, France
- - [[03:19](#react-miami-apr-17-18-miami-fl-usa)] [React Miami](https://reactmiami.com), Apr 17-18 Miami, FL, USA
- - [[03:25](#cityjs-london-april-23-25-london-uk)] [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
-- [[03:53](#sponsored-by-infinite-red)] Sponsored by [Infinite Red](https://infinite.red)
-- [[04:48](#new-releases)] New releases
- - [[04:50](#react-router-72)] [React Router 7.2](https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v720)
- - [[05:11](#ts-58)] [TS 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8-beta/)
- - [[09:01](#prettier-35)] [Prettier 3.5](https://prettier.io/blog/2025/02/09/3.5.0)
- - [[09:12](#rtk-query-v260)] [RTK Query v2.6.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.6.0)
- - [[10:04](#standard-schema)] [Standard Schema](https://standardschema.dev/)
- - [[10:34](#astro-52-also-astro-53)] [Astro 5.2](https://astro.build/blog/astro-520/) (also [Astro 5.3](https://astro.build/blog/astro-530/))
- - [[11:35](#turborepo-24)] [Turborepo 2.4](https://turbo.build/blog/turbo-2-4)
-- [[12:20](#main-content)] Main Content
- - [[12:23](#sunsetting-create-react-app)] [Sunsetting Create React App](https://react.dev/blog/2025/02/14/sunsetting-create-react-app)
- - [[16:59](#original-sunsetting-cra-post-vs-build-a-react-app-from-scratch)] Original “[Sunsetting CRA](https://github.com/reactjs/react.dev/pull/7495)” post vs [Build a React app from Scratch](https://react.dev/learn/build-a-react-app-from-scratch)
- - [[25:26](#backlash-and-confusion-over-initial-version)] [Backlash](https://x.com/youyuxi/status/1891721924197351497) and [confusion](https://x.com/youyuxi/status/1892000761778929931) over initial version
- - [[26:52](#mark-filed-a-pr-to-rewrite-the-docs-the-react-team-closed-that-but-based-a-new-one-off-it)] [Mark filed a PR](https://github.com/reactjs/react.dev/pull/7618) to rewrite the docs, the React team closed that but [based a new one off it](https://github.com/reactjs/react.dev/pull/7624)
- - [[38:09](#between-the-wires-an-interview-with-mootools-contributors)] [Between the Wires: An interview with MooTools contributors](https://www.freecodecamp.org/news/between-the-wires-an-interview-with-mootools-contributors-33d764957575/)
- - [[42:58](#how-to-start-a-react-project-2025)] [How to start a React Project [2025]](https://www.robinwieruch.de/react-starter/)
- - [[43:56](#jack-herrington-published-create-tsrouter-app-under-the-tanstack-umbrella)] [Jack Herrington published `create-tsrouter-app`](https://bsky.app/profile/tannerlinsley.com/post/3lif6fdpzkw2s) under the Tanstack umbrella
-- [[47:24](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[47:29](#vercel-acquires-tremor)] [Vercel acquires Tremor](https://vercel.com/blog/vercel-acquires-tremor)
- - [[48:29](#things-people-get-wrong-about-electron)] [Things people get wrong about Electron](https://felixrieseberg.com/things-people-get-wrong-about-electron/)
- - [[48:57](#initial-observables-support-in-chrome-135-observable-api)] [Initial Observables support in Chrome 135](https://x.com/BenLesh/status/1893053275995357608), [Observable API](https://chromestatus.com/feature/5154593776599040)
- - [[49:33](#why-i-rebuilt-prosemirrors-renderer-in-react)] [Why I rebuilt ProseMirror’s renderer in React](https://smoores.dev/post/why_i_rebuilt_prosemirror_view/)
- - [[49:52](#javascript-temporal-is-coming)] [JavaScript Temporal is coming](https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/)
- - [[50:44](#do-javascript-frameworks-still-need-portals)] [Do JavaScript frameworks still need portals?](https://fullystacked.net/portal/)
- - [[51:46](#what-do-we-do-with-you-old-react)] [What Do We Do with You, Old React?](https://www.manuelsanchezdev.com/blog/what-to-do-with-old-react-upgrading-to-modern-react)
- - [[52:18](#records-and-tuples-proposal-is-now-composites)] [“Records and Tuples” proposal is now “Composites”](https://bsky.app/profile/littledan.dev/post/3liwo57opl22b)
-
-**Carl:** All right. Hello, everyone. Thank you for joining us for the February edition of This Month in React, where we recap And digest the recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:00]
-
-But I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like these events and build tools to help keep the community operating. [00:16]
-
-**Mark:** And I'm Mark. My day job is working at Replay. Io. We're building a time traveling debugger for JavaScript and figuring out how to integrate that with AI DevTools. And in my copious amounts of spare time, I both work on Redux and spend entirely too much time complaining about the React ecosystem. [00:26]
-
-**Carl:** And also now writing documentation and long, enormous blog posts. I actually printed out your blog post that I offered to help you edit, and it was 50 pages long. 50 sheets of paper. [00:42]
-
-**Mark:** I apologize to the forests that suffered for that one. [00:53]
-
-**Carl:** It's entirely your fault. [00:56]
-
-Yeah, our third co host, Mo, is off this month. He is very busy with work and things, and just needed to take some time, not in the right space to have this conversation this month, so he'll be back next time. [00:58]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Some quick hits. Job market. I was hoping around December, January, it was looking like, I don't know, new quarter, new year, new budgets. I was cautiously optimistic from seeing activity in the job board, yada yada. But sadly that has not borne out. [01:11]
-
-## [Microsoft Performance-Based Job Cuts Have Started](https://www.businessinsider.com/microsoft-performance-based-job-cuts-have-started-termination-letters-2025-1)
-
-**Carl:** I guess, you know, maybe some small companies were hiring, but like, Meta is doing performance based layoffs. Microsoft is doing performance based layoffs. And talking to someone about the job market and the ecosystem, and they shared something that made me think differently about layoffs that are happening right now. [01:29]
-
-Like, when the company is signaling that it is performance based, That is a very different situation than when you just get laid off. Like, was pointed out to me that like, if you have on your resume that you worked at Meta and that you got laid off January 2025, that is no longer, like, the golden ticket. You know, like, for many, many years, if you worked at one of these big tech companies, that was, like, pretty much, not a free pass, but, like, it opened a lot of doors. But now a lot of people are getting let go when the public messaging is we're letting go of low performers. And that is a very different environment to lose your job in. [01:46]
-
-So that's, yeah, I hadn't really thought about that, but yeah, how the company messages, how they're letting people go definitely can have a huge impact. And I saw a quote from a Bloomberg article about the Microsoft layoffs. [02:23]
-
-## [Microsoft Performance-Based Job Cuts Have Started](https://www.businessinsider.com/microsoft-performance-based-job-cuts-have-started-termination-letters-2025-1)
-
-**Carl:** " Employees losing their job will see health care benefits end immediately. In three specific cases, employees were told that they weren't getting severance." [02:35]
-
-So like, not only is, are they publicly signaling that these are like performance based and therefore really doing harm to the like future employment prospects, like they're not, they're being pretty stingy about these severance deals. [02:43]
-
-Losing your health insurance with no notice. It's pretty brutal, like, that's, that's just rough. Especially, like, yeah, hopefully they weren't getting any active treatments. Ugh, anyway, that's all I'll say on that. [02:56]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** some upcoming conferences in March and April, [03:07]
-
-## [React Paris](https://react.paris/) March 20-21 Paris, France
-
-**Carl:** we've got React Paris. March 20th and 21st. [03:10]
-
-## [React Native Connection](https://reactnativeconnection.io/) April 3–4 Paris, France
-
-**Carl:** We've got React Native Connection, April 3rd and 4th, also in Paris. [03:14]
-
-## [React Miami](https://reactmiami.com), Apr 17-18 Miami, FL, USA
-
-**Carl:** we've got React Miami, coming up in April 17th And 18th. [03:19]
-
-## [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
-
-**Carl:** there's also CityJS London, April 23rd to 25th in London. [03:25]
-
-**Mark:** Then whole slew of things in late May and early June. Conference season kicking off. [03:30]
-
-**Carl:** Yeah, definitely. I need to actually book things. I don't have anything, I'm going to render Atlanta in June, but I don't have anything booked before then. Yeah, going to Brazil for 12 days is really kind of complicated by Soaked up a lot of my logistical planning. [03:35]
-
-, Um, yeah, our sponsor. We are sponsored. We have a sponsor. [03:49]
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl:** Infinite Red is an expert React Native consultancy. It's been around since 2015. So basically the entire time that React Native has been around. They are our only sponsor in part because very few companies do as much as they do for the ecosystem. [03:53]
-
-, and I just don't know Too many other companies that have done quite so much for quite so long. So very happy to be partnered with them in that way. They only do React Native and they've built over 75 apps for companies from startups to the biggest in the world. And other than being kind, great people who have done great things for the ecosystem, like hosting podcasts and organizing conferences, They are generally just a small team that focuses on like building for the long term. [04:07]
-
-So if you are working at a company that's spinning up a new React Native project and needs to get build some expertise, definitely give them a call because they will actually not just build it, but they will work with you to help develop expertise and hit the ground running. Cool. [04:34]
-
-## New releases
-
-**Carl:** onto some new releases. [04:48]
-
-## [React Router 7.2](https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v720)
-
-**Carl:** We've got React Router, putting out a minor release, 7.2. Looked pretty minor. The headline for me here is that they have a type safe HRF tool, which sounds pretty interesting if you can have type safety. That your links work like that's just neat. They have a new way of doing that how well it works remains to be seen, but it seems cool [04:50]
-
-## [TS 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8-beta/)
-
-**Carl:** We've also got TypeScript version 5. 8 with a bunch of stuff. Of course TypeScript new version [05:11]
-
-**Mark:** thing that I'm interested in here is the new erasable syntax only flag. And for background on that, so TypeScript has always been described as, you know, a types only layer on top of JavaScript. But there are a few TypeScript features that actually do have some runtime code. Enums, I think a couple of the, a couple of the old legacy, um, syntax features as well. [05:18]
-
-And so, there are a number of tools today which work to strip out TypeScript types. But if your code uses some of those features that do have some runtime code, they, they don't work right. And this actually matters a lot for things like Node's new TypeScript, Stripping support. [05:43]
-
-And so, to try to work better with those tools, TS has added this erasable syntax flag, which I believe actually throws an error if you are using any of the syntax that has runtime output. So it's basically like a, an extra enforcement check to make sure that you're not using any of those features. And that way you can ensure that your code is compatible with just stripping the types as opposed to like a transpilation. That's actually a really big deal. [06:01]
-
-**Carl:** Yeah, super helpful. And it's actually, that's like a reasonably large build time optimization if you can get away with it. Because if you're not actually analyzing the types while compiling the code, you're just doing the parsing and the output. Like that's a lot less work. And your, like, VS Code, our IDEs, our language servers are already surfacing most of those type errors. [06:29]
-
-So, like, I think it's really neat to, for one, I have used this just Because it's less effort to stand up a new project. You know, if I can just lean on the language server, then that's just less code, fewer moving parts, fewer things to go wrong, fewer things to break when I pick the project back up in four months. [06:52]
-
-but yeah, it's also like if you can move the actual type checking into like CI or something like that and just do it less frequently, that's, that can be a lot less work overall. Yeah, there was a relatively subtle thing, slightly smarter return types when generic arguments are used in conditional types. [07:08]
-
-It's really specific and only a partial solution, but I've run into some problems like this. And the overall like pattern that they were showing off for this was like not super familiar with to me and looked useful. So like, I that caught my eye as like a kind of subtle but useful thing. [07:27]
-
-They are adding support for using require to get ESM modules. Which is interesting, like this is, you know, a continuation of the long tail of complexity that the switch over to ES modules, standardized modules, is having. But like, cool, now we have one more way to run into fewer problems when In an ESM environment, but needing to depend on CommonJS code. [07:43]
-
-it still does not allow you to require an ESM file that contains a top level await. [08:10]
-
-**Mark:** Because `require()` is synchronous. [08:16]
-
-**Carl:** yes, facts. Also added a new flag that just caught my eyes, like a nice, I don't know, LTS feature. They have a `--module node18`. So you can tell TypeScript what module, like parsing, what determines what modules to use, how it evaluates what modules are being imported? You can tell it to use specifically the behavior for node 18. [08:18]
-
-I've done a lot of maintenance of legacy apps and weird edge cases like that, like, Oh, in the last five versions, they have changed in what order or in what manner modules are crawled. Stuff like that can cause so many weird, obnoxious, difficult to debug errors. [08:42]
-
-## [Prettier 3.5](https://prettier.io/blog/2025/02/09/3.5.0)
-
-[09:01]
-
-**Carl:** Cool, new version of Prettier. I saw they're adding an option, which they do not do very frequently, so that's cool. [09:01]
-
-**Mark:** Looks like they're trying to let you configure how it formats collapsing objects. [09:07]
-
-**Carl:** Useful. [09:12]
-
-## [RTK Query v2.6.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.6.0)
-
-**Mark:** I am very pleased to announce that yesterday I shipped Redux Toolkit 2. 6, which now has infinite query support for RTKQuery. This has been our single most requested feature since RTK Query came out, and I started working on this back in October, after another user had submitted a draft PR to get a first proof of concept going. [09:12]
-
-There was a lot of discussion, a lot of trying to figure out what the problem space is, and how to implement this properly. We ended up adopting the React Query public API design for this. And I had some discussions with Dominic Dorfmeister, the, you know, TK Dodo, the React Query Maintainer, who specifically gave us advice on why they ended up with this API design and how they implemented it. [09:34]
-
-So, worked on this intermittently when I had time over the last few months and very happy to get this out the door. [09:58]
-
-## [Standard Schema](https://standardschema.dev/)
-
-**Mark:** There's also a, project or a standard, I guess, called Standard Schema, which is an attempt to, you know, sort of unify or find a common denominator between a bunch of the different TypeScript validation tools out there, like Zod and Valobot and Archetype. So apparently you can now say that your project needs Just the standard schema definitions, and then the end users can then swap in their preferred validation library where and where they want to. [10:04]
-
-## [Astro 5.2](https://astro.build/blog/astro-520/) (also [Astro 5.3](https://astro.build/blog/astro-530/))
-
-**Carl:** there's also two Astro releases. There's 5. 2 and 5. 3. Looks like it's You know, relatively. Small iterative improvements. I was just reading a little bit more. Astro 5. 3 is talking about automatic session storage setup. And as someone who has opinions about off, And prefers, you know, session storage to jWTs for authentication, that caught my eye. [10:34]
-
-I don't know a ton about this, but definitely anything that makes sessions a little bit easier to like wrangle and manage, is definitely nice. I've been, as an exercise, I've been building my own. Authentication from scratch in session storage with React Router v7. So that's just fresh on my mind. [10:59]
-
-I would love to be able to tell you more about what the experience of using Astro is like, but I, I have tried and failed to start several projects because I just don't have time. I have too many different projects going on. But It always crosses my mind when I'm thinking about, like, a blog, or a static site, or things like that. Seems like a very good tool for those purposes. [11:18]
-
-## [Turborepo 2.4](https://turbo.build/blog/turbo-2-4)
-
-**Carl:** There's also TurboRepo 2. 4. TurboRepo is a great tool for managing monorepos. From the next team, and they've got a number of improvements to enhance your repository as they say Boundaries, watch mode caching, continuing the trend of Vercel dealing with caching issues and Versioned configuration validation from within your repository, interesting. And they've also got circular dependency recommendations for adopting Turbo repo in large repos more easily. That's interesting. I've run into so many circular dependency issues throughout my career that just very much catches my attention. Very neat. Cool. [11:35]
-
-**Mark:** I spent time trying to squash those as well. [12:16]
-
-**Carl:** Just the worst. So painful. [12:19]
-
-## Main Content
-
-**Carl:** Cool. Into our main content. Mark, you wanna start us [12:20]
-
-## [Sunsetting Create React App](https://react.dev/blog/2025/02/14/sunsetting-create-react-app)
-
-**Mark:** All right, yes, yes, I, I have thoughts and opinions on this topic. So, in our last episode, as a Relatively brief recap. When React 19 came out, it broke Create React App because of a peer dependency version mismatch, where the old templates wanted React 18, but CRA tried to install React 19. So I spent a chunk of January griping about this and trying to say, this is broken and it needs to be fixed. [12:23]
-
-That led to several heated discussions on Blue Sky with the React team about, and trying to convince them to fix it. And so, right before our last episode, I had filed an issue that recapped what was broken and why, and pointed to a couple of PRs that other people had filed to both fix the CRA templates and actually mark the Create React App repo and command line tool as deprecated, and the React team had actually taken action on that and merged the initial PRs And they hadn't actually put out a new release of Create React App that fixed the brokenness, but the changes were in there and they were trying to figure out the process for doing the releases. [12:53]
-
-Along with that, though, I had specifically said that I felt the React Docs setup page ought to recommend Vite as, you know, the equivalent replacement tool. So that people being told, CRA is dead, don't use it, would have a direct equivalent tool to try to use. So that's where we left off a month ago. [13:38]
-
-And the entire topic has continued significantly over the last few weeks. So, from my perspective, there were several additional debates going on, on, you know, BlueSky and Twitter and in the docs about, you know, what ought to be done as follow ups and, you know, what should be recommended as tools. [13:59]
-
-And on my side, I had actually started writing a rather lengthy blog post that tried to cover a bunch of topics from how has React been developed over the years to erecting some community confusion, like. You know, the ongoing claims that Vercel is driving React development just to make money on servers, which is wrong. [14:20]
-
-but also describing sort of my take on the history of interactions between the React team and the community and frustrations and miscommunications and docs problems and frameworks and all these different things. So I'd been working on that. In, you know, over the course of a couple of weeks and kind of like teasing my progress online. [14:42]
-
-And I'd also been having discussion with some other maintainers and without having given specific details publicly, the React team actually reached out to folks like Tanner Linsley and myself and specifically said, we can, like, we can tell you're frustrated. We would like to hear your feedback directly. [15:04]
-
-And so I know that, Joe from the React team had a call with Tanner Winsley, where Tanner expressed a lot of thoughts about, I think especially some of lack of new client functionality in React as well as where React was headed. And so, Joe and I had a call. In early February ish, where I summarized all my different concerns, and then there were a couple follow up calls, and, Carl and I actually were on one with, both Joe and Matt, where the React team talked about what they're trying to work on. [15:25]
-
-In response to a lot of these discussions and feedback. One of the things they said was we're, we're preparing a blog post and some docs updates in response to CRA being dead. As well as even things like they've been talking about trying to have a new community working group for a while, but they've kind of gotten bogged down in what the logistics should be. [15:59]
-
-So, based on that, I could see that the React team was very actively trying to listen to feedback and trying to take some actions in response. And so, I think it was later that week that the React team finished the draft of the blog post and the docs updates. They gave me a chance to review it and offer feedback and a bunch of other folks as well. [16:20]
-
-And so they published that blog post and they, I did actually see that they had applied some of the feedback that I'd suggested. They did not apply all of the feedback that I suggested. [16:45]
-
-## Original “[Sunsetting CRA](https://github.com/reactjs/react.dev/pull/7495)” post vs [Build a React app from Scratch](https://react.dev/learn/build-a-react-app-from-scratch)
-
-**Mark:** And this actually kind of got rather controversial again as I rather predicted that it would. They put up a blog post labeled Sunsetting Create React App, where they said, CRA is dead, here's all the things that it didn't include. [16:59]
-
-There's better tools, but also we really, really, really, really, really think that people should be using frameworks that have routing and data fetching and everything else built in. And the first version of this blog post really, really emphasized the framework part. And they did make changes to the setup docs, but they also put up a new blog post that was called Building a React Framework. [17:14]
-
-And so, you know, what, what everyone's been clamoring for is just recommend VEET in the setup page, please. And they didn't actually do that with this first update. They instead, what they said was, well, when you pick your own build tool and your own router. And your own data fetching library. What you're really doing is building your own framework badly. [17:39]
-
-And I can understand the mindset behind that, but frankly, this was not a helpful approach for anyone actually reading the framework. If you are a learner or a beginner, or want to try to choose some other tools, what would be helpful is instructions that say, you can use one of these two or three build tools, you can use one of these couple routers, and one of these data fetching libraries, and at least giving people a valid direction to go with it. [18:07]
-
-And instead, what we got was a pretty straightforward, page that said, if you don't want to use a framework, you can build your own framework. Step one, install Vite or Parcel. Step two, you're going to have to think about routing and data fetching and code splitting, and boy, these are complicated and you will never be able to do this by yourself. [18:35]
-
-Don't do this, please! Use a framework instead. And that really was not helpful for the audience that was going to be reading it. And so I had tried to offer feedback saying I don't think this page is good before the post went up, and that was one of the things they did not listen to me on. [18:57]
-
-**Carl:** Yeah, And it, it definitely feels like that the fe it seems like the feedback that you gave is in line with like community expectations. Just seeing the Reddit response to, you know, the comments on the Reddit post for this blog. I, you know, I saw like Rick Hanlin had replied to something and got down, voted to like, you know, minus 20, something like that. So, it does, just like for more data points coming, rolling in in real time around, the core team is out of step with expectations for the community. [19:16]
-
-**Mark:** Yeah, so, you know, I, I understand what the React team is trying to accomplish, and in fact, actually, one of the, one of the most interesting data points that came out of those couple conversations with the team. So, they've said, since they started this frameworks emphasis that, Part of the goal is that, you know, they, they don't want people to start off with a single page app and then have to do like a major tool migration in order to add SSR functionality. [19:48]
-
-What I didn't realize was a lot of their goal and mindset around this is actually around React app performance. And they are actually very sensitive and I've heard a lot of the criticism. From folks like Alex Russell that, you know, single page apps and the average React app are horribly performing tens of megabytes of JavaScript. [20:14]
-
-Like, they're actually very, very sensitive to that criticism, and I don't think I'd realized how sensitive it was. Turns out that part of their reason for emphasizing frameworks Is, they feel that if most apps start with a framework by default, then on average, more React apps will have somewhat better loading performance, data fetching, code splitting performance, etc. [20:38]
-
-That is actually one of the big drivers for why they recommend Framework so strongly, and I didn't realize how big a driver that was until they told me that themselves repeatedly. [21:05]
-
-**Carl:** Yeah, I can understand that, and like, I don't think that's wrong. Like I have worked on so many different apps and so many of them have been like badly broken in different ways. Like shout out to the company I worked at that had a 45 minute Docker build that produced 36 megabytes of webpack output. Had six different copies of the app because every, Each of their six pages was a different entry point, so you literally had to download six copies of the app as you clicked around. [21:16]
-
-So, like, I've lived that. I've seen that. That is true. Just facts. Also, I don't know, I guess it's maybe just like in this, I feel like it's an inherent tension to the goals of encouraging deep learning and, setting up default incentives that produce better outputs, better outcomes. [21:43]
-
-Like, I feel like they're going very hard at, um, We know that this will produce better outcomes in aggregate. And I don't think they're wrong. I think they're correct to say that. But I don't think it's The ideal path for many individual developers. So I feel like this is, this is a tension between micro and macro. [22:04]
-
-You know, they are taking the macro perspective of in aggregate, this will produce more good. And you and I maybe are looking at the micro of this is not filling the needs for these people specifically. Yeah, [22:23]
-
-**Mark:** Yeah, so like, you know, I, I understand the, you know, make, make sure that you use a tool that has all the features you will ever need. So you don't have to migrate and make sure you use a tool that has all the optimizations built in. So you're getting good default performance. What it leaves out and ignores, though, is that. [22:39]
-
-if you're a learner or a beginner, having fewer knobs and having fewer concepts to worry about is going to make it easier to learn. A lot of companies are in positions where they can't or don't want to use Node on the back end. They just want a very simple SPA. Um, there's a lot of people who, for good or bad reasons, don't like Node. [22:59]
-
-The React team's emphasis on frameworks. They're suspicious of, you know, the, the incentives in Vercel. And so the React ecosystem is very large and for better or for worse, a lot of people are very happy building React apps the way we have for years. And so my perspective is that the thing that the maintainers should do is Provide recommendations, but also recognize that it is a broad ecosystem and at least say The way you're using react is valid and we recognize you and support you Even if you've made choices that we don't think are the most optimal and the problem is the one line emphasis on frameworks And the tone of the statements in the docs has basically told half the ecosystem, We don't care about you, and we think you're doing it wrong. [23:23]
-
-Which is not very helpful. [24:17]
-
-**Carl:** Yeah. For sure. Right? Like, I wanna, I wanna bring in a strong opinion I have, which is that the world is held together with shoestrings and duct tape. Like, everything in the world barely works. If you look too closely at anything, like, it's a miracle that things are functional. And, My impression is that the core team is kind of railing against that a little bit. [24:18]
-
-Like, they wish things worked better. They wish that the world were a little bit more ordered. And they are meaningfully trying to shift, you know, they are exerting their influence on the world as the caretakers for a tool used by literally millions. So, yeah, I don't know. I guess, circling back a little bit, you had brought up, like, community working group and some chats. It's very early, but you and I and Jack Harrington and maybe some other folks are talking about what that might mean. What that might look like, what processes might be involved, and what outputs might be produced. [24:39]
-
-So yeah, I don't know, maybe ReactiFlex can play a larger role in that conversation, in that, I don't know, activity. [25:19]
-
-## [Backlash](https://x.com/youyuxi/status/1891721924197351497) and [confusion](https://x.com/youyuxi/status/1892000761778929931) over initial version
-
-**Mark:** Yep. So ultimately what happened was they put up the new docs PA and the new blog post and the docs page, and this spawned a bunch of controversy and outcry, lots of arguments on Reddit and Twitter and Blue Sky. And, you know, one ex, one example of this was, Evan You, you know, the Vite creator. Um, putting up a couple of tweets where he said that, you know, like, I, I just don't understand why the React team is refusing to reasonably recommend Veep. [25:26]
-
-And, like, I'm, I'm happy to work with them, I just don't understand where they're going with this and why. And that actually got kind of a positive response. Rather, strongly worded initial response from a couple of React team devs that later got retracted and there were a bunch of follow on discussions. [25:56]
-
-But, it's like, from my perspective, the React team has pretty explicitly stated what their goals are, and no one wants to take those statements at face value, which is Interesting. So last weekend, after like two days after the blog post and the docs updates had gone live, I was sitting around on a Sunday night and I'm like, I could try to offer more feedback and suggestions, but I did that once already and I knew what some of the responses would be and that's why I offered this feedback and they didn't take it and apply all of it. So what if I just take this into my own hands? [26:13]
-
-## [Mark filed a PR](https://github.com/reactjs/react.dev/pull/7618) to rewrite the docs, the React team closed that but [based a new one off it](https://github.com/reactjs/react.dev/pull/7624)
-
-**Mark:** And I actually try rewriting the docs page and the blog post myself to try to get across the same message but with a better tone and actually provide better guidance and instruction on using React without a framework. So, I actually filed a PR a week ago that rewrote the docs page. [26:52]
-
-And the next day the React team actually closed that PR, and I actually got a message on the side from Matt Carroll on the React team who said, you know, like, actually do thank you for doing the work on this, but it's not quite the direction we want to go with it. [27:14]
-
-However, they did then open up a new PR that was explicitly intended to address a lot of the feedback from over the weekend. They did copy and paste several of the sections that I had had in my PR, as well as tweaking some other sections. And this did actually get merged. So, it did not have some of the phrasing and the writing approaches that I felt should be in there, but it is legitimately an improvement. [27:30]
-
-And it does actually meet, I think, a minimum acceptable bar where it says, like, they changed the build a React framework page into build a React app from scratch, which is roughly the phrasing that I had used. And it does actually say, you know, you can use V or Parcel or RSPack and a data fetching library and a router. [27:59]
-
-And so it's giving actual instructions And that is linked prominently from the intro paragraph on the main setup page, and it's linked at the bottom. And the setup page actually explicitly uses the word VEET in a paragraph. And so it's not ideal, it's not the exact phrasing I would want, but they did make a second round of changes. [28:24]
-
-And they did listen to feedback, and I do think it meets a reasonable minimum bar of recognizing that you can use React without a framework, and here are steps to do so. So it's been painful, it's still not exactly what I'd like to see, but I think we've actually reached an acceptable state at this point. [28:47]
-
-**Carl:** Heck yeah. All right, nice that it's ended in that spot. We haven't talked about this, but where have you landed on your giant blog posts? Are you still sitting on those? [29:09]
-
-**Mark:** Yeah, I'm sitting on it, so Like I said, part one was a recap of the history of how the React project has been developed, the influences like Meta and Vercell, as well as, you know, dispelling conspiracy theories like Next is dr or Vercell is driving it just to make money. Part two was all the history of, you know, frustrations and good and bad interactions and everything else. [29:18]
-
-And, you know, part of my goal was to document things, and part of my goal was to drive change. And it's ended up helping with the change, but indirectly. I did show the draft to the React team after a couple of our conversations, they, you know, frankly, they asked me not to publish it. [29:43]
-
-they didn't tell me not to, they said I should consider not publishing, which is. But like, my goal with this was not to burn bridges. Instead, I wanted to push them to make changes to the docs, to make changes to the messaging. And, we talked, and they were listening, and they were in the process of making changes. [30:04]
-
-So I felt that at a minimum, I ought to at least give them a chance to publish the doc updates and see how things would work out, because they were in the middle of that. And so now that they've done some of that, I feel like publishing the post in its current form would be like slamming, hitting them with a sledgehammer after they did some of the thing that I already asked them to do. [30:25]
-
-And that doesn't feel good. So where I'm at right now, is I, I still think the first part the history and the conspiracy theories part is probably worth publishing stand alone, and I can probably just extract that. I feel like there's a lot of useful content in the second part, but I would, I would need to extract and restructure a lot of it, and I haven't had time to sit down and think about it, and frankly, after, I would actually like to think about something else for a while. [30:44]
-
-So, I expect to end up publishing some of that content at some point, but it's not top of my priority list right now. [31:08]
-
-**Carl:** That makes sense. Yeah, I actually did sit down with it and four highlighter pens and I feel like there's like four posts in there. I feel like there's your personal [31:17]
-
-experiences of trying to make changes. There's the, like, summary. Oh, man, just like the oral history you captured of like, here's how things have evolved over the last, like, nine years. [31:25]
-
-I feel like is really useful. But Yeah. So cool. Yeah, go sit on it. Don't think about it. I will come to you with thoughts that I have in a, in a number of weeks. [31:36]
-
-**Mark:** Yeah. So overall, it's been a couple months of, you know, a lot of kind of painful discussion and, and a lot of drama and arguing, but I think we've ended up in a fairly good place by the end of it. So Create React app's officially dead. The docs have been updated. The docs say both, you know, use a framework and those recommendations are updated. [31:47]
-
-But they also say you can build an app from scratch and here's concrete instructions on how to do so. The tone is a lot better. So we've, we've ended up in a fairly good point, but a lot of this has shown that there is a really big gap between, you know, the React team's vision of where they want to go with React versus how a lot of the ecosystem wants to use React and I, I don't think that's going to go away anytime soon. [32:07]
-
-Yeah. And I, [32:37]
-
-**Carl:** Yeah, would agree. That reminds me of, uh, Posts that I put on Blue Sky. Opinions. I feel like the current, like, conflict is a, an example of the different, perspectives, really. Like, in this post, I say it's a clash between the indie hackers, the corporate cogs, and the academics. [32:38]
-
-Where, like, by background, I'm a corporate cog, like, I have always had a large team supporting me. And so, like, I was usually the guy, like, playing around in this code base, trying to make it work better for my colleagues, who were then the ones actually shipping, like, individual features. That's a very different setting than if you are, you know, an indie hacker doing your own things and just trying to ship features and functionality. [32:59]
-
-Which is, again, a very different perspective from, the core team, who I'm considering the academics here. Like, I've said before in this podcast, like, I strongly feel that the React core team is managed more like a research project than anything else. And, you know, I, some signal in that, in that I got some, I think like two or three of the core team members responded to this. [33:24]
-
-It was just like a, like, I'm just going to brag that they saw it and engaged. But yeah, like they have, the core team has had a very stable vision for what React could be really since 2013. Like from the beginning, they've talked about stuff like algebraic effects and functional programming and, you know, encapsulation component models. [33:47]
-
-And if you're like, I've been paying close attention to that. So I feel like I have a reasonably clear understanding of what that vision is and has been. And so like, I can see that it's stable, but I think if you're not paying close attention to what they're doing, you're not watching this research team go. [34:08]
-
-You're off dealing with your own projects, shipping code, building features. You know, setting up processes for your team, then I think that. Vision is actually really hard to gather, like just from resources, from reading the documentation, from reading, from following their social media feeds. I think it's really hard to catch up on what the vision is. [34:27]
-
-So that's maybe a gap currently in like what's available. [34:48]
-
-**Mark:** And I think that ties a lot into something that the team mentioned to us in the couple calls I had with them. So, like, we just said that they have a vision, and that's, that's very accurate and valid. And yet, in a lot of ways, I've learned that the vision is almost like a vague, amorphous thing that they're figuring out as they go. [34:53]
-
-You know, it's not that they have, apparently it's not that, like, literally everyone is driving towards the one true vision all the time. It's that, in a lot of ways, are individuals going off and experimenting with things, and then it's almost every so often they get together and figure out, okay, we've played around with a lot of ideas. [35:13]
-
-do we have a consensus on where we're going? And like, one of the things they said was that, you know, like, I've complained that they put up very infrequent updates on the blog, on, in terms of like, roadmaps and where they're going. Like, they've put up three React Labs posts almost like a year apart. [35:32]
-
-And my assumption reading those was that, oh, well, like, clearly they already know what they're doing, and the blog posts are just documenting that plan. And Matt Carroll said it's actually the opposite. Like, they sort of look around at each other, it's like, we probably ought to put up an update post. What are we working on and do we have agreement on where we're going and so that the blog posts actually take them multiple months to write because it's almost like a forcing function to figure out like and actually nail down where they're headed. [35:51]
-
-So that was actually really really surprising for me to hear. [36:26]
-
-**Carl:** Yeah, and you know what it made me think of? The valve management structure, the flat Non hierarchical, anyone can work on whatever interests them, and if you want to get a project done, you have to pitch it to your colleagues. Which was famously, I don't know, Valve has its own vibe, and I don't know, it's like the vibe of Valve is not super far off from the vibe of React releases. [36:30]
-
-You know, the uh, indefinite delays and lack of communication. So, yeah. [36:51]
-
-**Mark:** So, you know, I, I think we're going to see them continue to push forward. I mean, even just in the last few weeks, seeing Sebastian working on implementing Vue transition support and some other pieces like that, they're going to keep building on these things and it's great to see the forward 19's out, but you know, there, there's a lot of people out there that are just very happy to keep using React essentially the way they have. [36:58]
-
-And there's going to continue to be a mismatch because what they're, well, what they're doing is absolutely valid and fine at a technical level. It's not the direction that the React team is trying to push. And so that leaves a lot of people feeling. You know, left out, unsupported, on the outside, and in the worst cases, concerned that somehow, like, client side React is going to stop functioning someday, just because it's not part of the server emphasis. [37:25]
-
-And I mean, anyone can look at, like, you want to be able to look at that and realize it'll never happen, but it shows you some of the, the vibes and the extrapolation happens that leave people concerned. Um, [37:57]
-
-## [Between the Wires: An interview with MooTools contributors](https://www.freecodecamp.org/news/between-the-wires-an-interview-with-mootools-contributors-33d764957575/)
-
-**Carl:** Yeah, I feel like I re share this every couple of months, but I want to share again this resource from FreeCodeCamp where they interviewed a bunch of the React core team through the lens of let's talk about your past work on MooTools. So, like, this is, a now 8 year old interview with, Sebastian Morkabug, whose name I'm sure I'm saying incorrectly, but it's as close as I can get, Tom, Tom Acino and Christoph Poyer, now, Christoph Nakazawa, I believe. Those are still Major players in the current React world, and they have been collaborating since 2009. So, like, they are coming up on 16 years of working together on foundational tools for the web. Like, I never personally used Mutools. But it was a, you know, meaningful minority use tool competing with jQuery. [38:09]
-
-And it remained relevant because I think in like 2014, 15, something like that, they wanted to do, wanted to release a new array tool, you know, an array primitive. And they couldn't because MooTools hadn't yet been released. But yeah, FlatMap, that was it. That was the one, FlatMap. SmooshGate. They couldn't release the standard because Mutools had monkey patched the Array object with its own FlatMap that was incompatible with the standard, and so releasing this would have broken the web. [39:09]
-
-So, like, this team, the core team, has, more than ten years ago, First hand experience with what it means to engage with standards and what it means to break the web. So, like, that's part of why I give them so much leeway and, like, kudos on their approach. Because, like, they know how bad it is to get it wrong. [39:40]
-
-They know that a decision you made 15 years ago can have lingering echoes. That prevent future work from happening. [40:04]
-
-And like, that's a really hard lesson to learn. It's a really hard lesson to apply. [40:13]
-
-**Mark:** The web is forever. [40:16]
-
-**Carl:** The web is forever. [40:18]
-
-**Mark:** So, it's, one of the other interesting points that came out of the discussions with Matt is that the React docs are very much aimed at beginners. And it's not just the tutorial, it's the setup guides. And I think that's, that's also some of the tension here is that people are not looking at the setup instructions page and saying, Oh, this list of tools is especially oriented for beginners. [40:19]
-
-I know what I'm doing. I can make, make my own choices. And that's fine. People have been looking at that page and saying, well, it doesn't explicitly list VEET. Therefore, the React team must have something against Vite. It's somehow bad to use Vite, et cetera. And in my, in my own draft PR, I had tried to rework some of their, their own paragraphs and phrases into a page on web app architectures to provide some guidance on like, what is a server, like a single page app versus multi page versus SSR versus SSG. [40:48]
-
-When might you want to use one versus the other? As a way of, like, applying some guidance to choosing a build tool. And they don't seem to want to go that direction yet, because it's not, in essence, it's not something a beginner should be worrying about immediately. And so I think that's another piece of the tension. [41:24]
-
-In what people want to see listed in the docs recommendations versus React team actually is willing to cover, which then ties back to the thing that Carl and I have been tossing around, which is, what if we had, A fully community written set of recommendations and docs and guidance for using React in the real world as a supplement to the beginner oriented, getting started level official React docs. [41:46]
-
-So we're still trying to figure out what that might look like and what the content might be. In fact, we're supposed to be talking about it literally right after this, [42:20]
-
-but that's sort of a pitch. Like if the React docs are going to explicitly focus on the beginner use case, then it's kind of up to the community to officially, to quote unquote, officially document what it's like to expand beyond that. [42:28]
-
-And how to use React properly in the real world. It's something that I, I had played around with trying to pitch this kind of a community doc site idea a few years ago. It didn't get off the ground and I'm, I'm hopeful that maybe this time around we can make something like that work. [42:43]
-
-## [How to start a React Project [2025]](https://www.robinwieruch.de/react-starter/)
-
-**Mark:** So as an example of this, Robin Weirich, who's a prolific React author and, tutor, Has put up a number of blog posts over the years with advice on, you know, common React libraries and tools. And so he's updated his post on how to start a React project for 2025 with a set of recommendations. And it's interesting to note how this is different than the actual React Docs setup page, because this one actually starts with prefer using Vite as the starting point. [42:58]
-
-, actually discusses some trade offs, both pros and cons, for all the different tools. Talks about using Next, talks about using Astro, which the React docs don't mention at all. And so it's the same problem space, but a very different approach to describing what your choices are than the actual setup page. [43:30]
-
-And on a similar note, So, with Create React app itself actually being officially deprecated. [43:50]
-
-## [Jack Herrington published `create-tsrouter-app`](https://bsky.app/profile/tannerlinsley.com/post/3lif6fdpzkw2s) under the Tanstack umbrella
-
-**Mark:** Jack Harrington actually put together a Vite based starter kit called Create TS Router App with the idea that it would be a, basically a drop in replacement. For the old create react app command that you get a basically like instead of running create react app, you run create TS router app, you get a Vite based project with TanStack router built in. [43:56]
-
-It has the same starting. Application component content and basically equivalent features, but you're starting with a modern set of functionality. You have routing built in, whereas CRA didn't come with a router. You can expand to file based routing if you want to. So, this has been moved into the TANstack organization, and it's now an official TANstack project, and it feels like a pretty useful tool. [44:23]
-
-**Carl:** Yeah, I actually had talked to Jack, just coincidentally, not about this, shortly before he released that tool. And he, just talking to him about, like, create react app and the legacy of it, I realized that, like, the original, promise of create react app was for it to be an abstraction over your build tool. [44:49]
-
-Over all of the build tools, and I hadn't really considered that that was really kind of, that promise never really realized, like, we, yeah, we had it for a while, but It took years for it to update from Webpack 4 to 5, for instance, and then it never released again. So it would, like, I remember at work arguing in support of using create react app instead of doing our own tooling, because, like, let's just never think about tooling again and just stay within the sandbox and get better. [45:09]
-
-What we need out of it. And that promise just never quite happened. So yeah, I don't know that just Hearing it, hearing this TS router, create TS router tool Build as like sort of a drop in replacement for it It is a drop in replacement for the functionality But it does not even attempt to provide that same kind of like social contract promise of future maintenance Just inaccurate, correct. [45:38]
-
-I mean, Create React app never lived up to that promise either, [46:03]
-
-**Mark:** I would actually have a slightly different opinion. I would say it mostly fulfilled that promise. I would, I would agree that it never, it didn't achieve the goal of eliminating the need to think about build tools. In the cases of like the Webpack upgrade or, you know, the fact that the, The blackboxing of the webpack config meant you needed third party tools to alter the config, etc. [46:05]
-
-So like, it didn't make those parts go away, but it did succeed in giving you a single command that would start a project without having to spend time on creating the build config yourself. Or using a boilerplate project or copy pasting it from your last working config. And that did enable tutorials to just say, run, create React app, and now let's start learning React, which was a big goal, as well as making it actually useful for real world, real world projects. [46:30]
-
-So it didn't eliminate those concerns entirely, but I think it sufficiently succeeded in the goals of not having to think about it just to get started. [47:01]
-
-**Carl:** I would agree with that. I understood it to be, to have a larger scope in mind of being an enduring abstraction that would evolve over time. And that didn't happen. Yeah. Anyway, Yeah. [47:10]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Oh man, we have so many lightning round links [47:24]
-
-**Mark:** Lightning Round! [47:25]
-
-**Carl:** Yeah, cool. All right, we're going to fly through this a little bit. [47:26]
-
-## [Vercel acquires Tremor](https://vercel.com/blog/vercel-acquires-tremor)
-
-**Carl:** Uh, Vercel bought an open source React, toolkit, which is interesting to me. Like, I hadn't heard about this in advance, but like, Tremor is apparently a open source React dashboard tool that was funded by Y Combinator in 2023, and now Vercel has bought them. So like, I don't really understand what it means for an open source library to be venture backed. [47:29]
-
-, but like I'm generally supportive of it. Like I would love it if open source maintainers could paid for the work that they do, which is meaningful and impactful and takes a lot of effort. It's a little bit unfortunate to me that the model by which you can get paid for that work seems to be rich dudes in tech decide that they're going to give you money and then other rich dudes in tech buy that work from you. [47:53]
-
-But yeah, that was just interesting. That seems like an outlier. I have not heard of very many open source tools either getting VC funding or getting acquired. Really, Remix is the only other example that comes to mind. [48:18]
-
-## [Things people get wrong about Electron](https://felixrieseberg.com/things-people-get-wrong-about-electron/)
-
-**Carl:** Yeah, I saw a fun post titled, Things People Get Wrong About Electron. And just sort of a fringe at, you know, a fringe post talking about tech kind of at the margins. [48:29]
-
-Like, I have written a re an Electron app in, like, 2015. Oh my god, 10 years ago. Ugh, I'm so old. But yeah, just, it's neat. It's fun to see such a different context for the web. Definitely recommend checking that out. Just as a, as a curiosity, really. [48:41]
-
-## [Initial Observables support in Chrome 135](https://x.com/BenLesh/status/1893053275995357608), [Observable API](https://chromestatus.com/feature/5154593776599040)
-
-**Mark:** So, there's been a decade long effort to try to get some form of observables baked into the browser. Ben Lesh of RxJS has been beating this drum for years, and it looks like they've finally succeeded in getting some of it. Some form of observables actually baked into the browser. It seems partially limited in scope, partially related to, event handlers, but I think it's at least a starting point for adding this kind of an API directly. [48:57]
-
-And so Ben's pretty excited about that. Also on, also on the note of just, you know, really good deep dive technical articles. [49:25]
-
-## [Why I rebuilt ProseMirror’s renderer in React](https://smoores.dev/post/why_i_rebuilt_prosemirror_view/)
-
-**Mark:** someone who used to work for the New York Times talked about taking the pros mirror rich text editing library, which is partially react related, but partially independent. [49:33]
-
-, and rebuilding the ProseMirrorRenderer directly in React on top of the data structures. Great article, very well written. [49:43]
-
-## [JavaScript Temporal is coming](https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/)
-
-[49:52]
-
-**Carl:** Mozilla had a post at the end of January, about Temporal. JavaScript Temporal is coming. Dates in JavaScript are garbage. They are awful. My favorite example of a specific way they're awful is that they have no concept of time zone. And so every date uses your local system time zone, Which is absolutely awful. [49:53]
-
-If you're trying to do anything involving time in two different locations, [50:13]
-
-**Mark:** is why we've had Moment and DateFunctions and Lexon and who knows how many other libraries. [50:18]
-
-**Carl:** All fine. So Temporal is a new, date standard tool, standard library for JavaScript doing dates and it's coming. I hope it's good. I haven't really played with it. I tend, I don't want to think about dates, so I don't want to think about them any more than I have to. And so I haven't really looked at this. [50:24]
-
-It's coming. It's soon. That was a good post. [50:41]
-
-## [Do JavaScript frameworks still need portals?](https://fullystacked.net/portal/)
-
-**Carl:** this was kind of neat. Do JavaScript frameworks still need portals? React has had portals for a long time for like, rendering stuff like modals or tooltips or popovers that exist like, outside of the hierarchy, quote unquote. Just sort of as a way of rendering something within the component tree, but not having the DOM output be in the same hierarchy. [50:44]
-
-And that comes with all sorts of quirks and weird bits. Like z index can get really weird. Think it's awkward and funky for like cross platform stuff. I don't know how well it works in React Native or, you know, other contexts to make use of these portals. So just like this was a kind of fringe topic, like how often do you think about using React portals? [51:07]
-
-And so just like reevaluating, like, are they still necessary? Do they still, is the problem that they were introduced to solve Still relevant in 2025. And I thought that was a good question to ask regardless of what the answer is. [51:33]
-
-## [What Do We Do with You, Old React?](https://www.manuelsanchezdev.com/blog/what-to-do-with-old-react-upgrading-to-modern-react)
-
-**Mark:** we've had years of migrating from other frameworks to React, and we've now had two or three different eras of different styles of React code. So, now you can migrate and modernize your old React code to modern React code. And so there was a good post called, what do we do with you old React that just gave some quick examples of migrating from things like class components to function components and old Redux to modern Redux and old testing approaches to React testing library. [51:46]
-
-, nothing fancy. A lot of this has been covered elsewhere, but it was a good, useful summary. [52:14]
-
-## [“Records and Tuples” proposal is now “Composites”](https://bsky.app/profile/littledan.dev/post/3liwo57opl22b)
-
-**Mark:** And finally, for the last couple, last few years, we've had a work in progress TC39 proposal called records and tuples, which was an attempt to build fully deeply equal objects and arrays directly into the runtime so that you don't have, so that you could just use like the triple equals operator and it would do like a deep equality comparison of all the fields rather cheaply, rather than having to use a library like immutable. [52:18]
-
-js. And this proposal has apparently just undergone a significant revision. It's, I guess it's no longer even called records and tuples, and instead they're calling the objects composites instead, and you would need to call a specific composite. Equals method to compare them. I saw the tweet, I skimmed through the readme of the summary of the changes, I have not had a chance to look through the slides yet, but it's interesting to see how this proposal keeps evolving. [52:48]
-
-**Carl:** Neat. Super cool. Oh yeah. That was all of our lightning round links in like less than 10 minutes. For sure. Proud of [53:19]
-
-**Mark:** us! [53:24]
-
-**Carl:** Cool. Thank you everyone for joining us. That's all we got this month. We'll be back on the last Wednesday of the month, for real this time, I think. [53:25]
-
-, uh, we'll be back at the end of the month in the live stage here in React to Flux or back in your podcast feed just as soon as we can after that. I try to get it by the first of the month, but not always. We gather sources from This Week in React, Bytes. Dev, React Status, Next. Js Weekly. The React. Js subreddit, here in Reactiflux, and directly from those publishing articles as well. If you see anything newsworthy, definitely let us know in the tech news and reads channel here in Reactiflux, or shoot us an email at hello at Reactiflux dot com, with TMIR in the subject line if you can. I read literally everything that comes in, even spam and whatever, so if you send it, I'll read it for sure. [53:32]
-
-And if this is a show that you get value from and want to support, the best way you can do so is by either submitting a review or telling your friends and coworkers about it. Like, if this was useful, just like, send it to one other person. That would actually do a lot for us. Cool! Thank you so much for joining us! [54:09]
-
-**Mark:** Thanks, appreciate it, and hopefully we'll have less drama to talk about next month. [54:24]
-
-**Carl:** Maybe. [54:28]
diff --git a/src/transcripts/tmir-2025-03.md b/src/transcripts/tmir-2025-03.md
deleted file mode 100644
index 881d8dd..0000000
--- a/src/transcripts/tmir-2025-03.md
+++ /dev/null
@@ -1,563 +0,0 @@
----
-title: "TMiR 2025-03: Next had an auth vulnerability, TypeScript is porting to Golang"
-date: 2025-03-26
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:45](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- [[01:28](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:29](#react-native-connection-april-3--4-2025-paris-france)] [React Native Connection](https://reactnativeconnection.io/) April 3 \+ 4, 2025 Paris, France
- - [[01:36](#react-miami-apr-17-18)] [React Miami](https://www.reactmiami.com/), Apr 17-18
- - [[01:49](#cityjs-london-april-23-25-london-uk)] [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
- - [[01:55](#appjs-conf-may-28-30-krakw-poland)] [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
- - [[02:06](#cityjs-athens-may-27-31-athens-greece)] [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
- - [[02:13](#squiggleconf-2025-cfp-closes-may-23)] [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
-- [[03:19](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
-- [[04:24](#new-releases)] New releases
- - [[04:26](#typescript-58)] [TypeScript 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/#the---erasablesyntaxonly-option)
- - [[05:00](#typescript-release-with-go)] [Typescript Release with Go](https://devblogs.microsoft.com/typescript/typescript-native-port)
- - [[06:26](#react-native-078---react-19-and-more)] [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
- - [[06:44](#next-152)] [Next 15.2](https://nextjs.org/blog/next-15-2)
- - [[07:07](#tanstack-form-10)] [Tanstack Form 1.0](https://tanstack.com/blog/announcing-tanstack-form-v1)
- - [[07:54](#zeego-v3)] [Zeego v3](https://github.com/nandorojo/zeego/releases/tag/v3.0.1)
- - [[09:04](#material-ui-v7)] [Material UI v7](https://mui.com/blog/material-ui-v7-is-here/)
- - [[09:04](#slot-pattern-for-overriding-internals)] ["Slot pattern" for overriding internals](https://mui.com/material-ui/customization/overriding-component-structure/)
- - [[10:45](#parcel-v214)] [Parcel v2.14](https://x.com/devongovett/status/1902022923764076808)
- - [[12:33](#xstate-store-v3)] [XState Store v3](https://stately.ai/blog/2025-02-26-xstate-store-v3)
- - [[13:11](#better-auth-v12)] [Better Auth v1.2](https://www.better-auth.com/changelogs/1-2)
-- [[14:31](#main-content)] Main Content
- - [[14:31](#lynx-released)] [Lynx released](https://lynxjs.org/)
- - [[14:33](#release-blog)] [Release blog](https://lynxjs.org/blog/lynx-unlock-native-for-more)
- - [[18:20](#security-vulneratibility-in-nextjs-cve-2025-29927001820-original-researcher-report)] [Security vulneratibility](https://nextjs.org/blog/cve-2025-29927) in Next.js: [CVE-2025-29927](https://github.com/advisories/GHSA-f82v-jwr5-mffw)[18:20] [Original researcher report](https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware)
- - [[20:36](#cves-and-the-nvd-process)] [CVEs and the NVD Process](https://nvd.nist.gov/general/cve-process)
- - [[25:03](#postmortem-on-nextjs-middleware-bypass)] [Postmortem on Next.js Middleware bypass](https://vercel.com/blog/postmortem-on-next-js-middleware-bypass)
- - [[27:00](#nextjs-and-coordinated-disclosure)] [Next.js and Coordinated Disclosure](https://sxlijin.github.io/2025-03-23-next-js-and-coordinated-disclosure)
- - [[30:17](#you-should-know-this-before-choosing-nextjs)] [You should know this before choosing Next.js](https://eduardoboucas.com/posts/2025-03-25-you-should-know-this-before-choosing-nextjs/)
- - [[31:37](#react-native-078---react-19-and-more)] [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
- - [[34:27](#react-native-core-contributor-summit-2024-recap)] [React Native Core Contributor Summit 2024 Recap](https://reactnative.dev/blog/2025/02/03/react-native-core-contributor-summit-2024)
- - [[36:42](#typescript-compiler-golang-rewrite)] [TypeScript compiler Golang rewrite??](https://devblogs.microsoft.com/typescript/typescript-native-port/)
- - [[41:23](#github-discussion-and-on-reddit-too)] [Github discussion](https://github.com/microsoft/typescript-go/discussions/411) and [on reddit too](https://www.reddit.com/r/javascript/comments/1j8s441/comment/mh7ms9n/)
-- [[44:50](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[44:52](#jsc-being-extracted-from-rn-core)] [JSC being extracted from RN Core](https://github.com/react-native-community/javascriptcore)
- - [[45:22](#node-modulesdev-v040)] [node-modules.dev v0.4.0](https://bsky.app/profile/antfu.me/post/3ljubvzvwec2w)
- - [[46:00](#fernando-rojo-joining-vercel-as-head-of-mobile)] [Fernando Rojo joining Vercel as Head of Mobile](https://x.com/rauchg/status/1896943726486032783)
- - [[46:41](#next-vs-tanstack-router-vite)] [Next vs TanStack (Router \+ Vite)](https://www.kylegill.com/essays/next-vs-tanstack/)
- - [[47:46](#expos-ai-strategy)] [Expo’s AI Strategy](https://expo.dev/ai/strategy)
- - [[48:39](#laravel-launched-starter-kits-including-react)] [Laravel launched “starter kits” including React](https://laravel.com/docs/12.x/starter-kits)
- - [[49:36](#react-native-enterprise-framework)] [React Native Enterprise Framework](https://enterprise-framework.callstack.com/)
- - [[50:36](#state-of-react-native-2024)] [State of React Native 2024](https://results.stateofreactnative.com/en-US/) [00:00]
-
-**Carl:** Thank you everyone for joining us for the March edition of this month in React, where we recap and digest the recent developments in the ever evolving react and web ecosystem. We are coming to you live here in Reactiflux, the place for professional react developers. [00:14]
-
-And we are supported by infinite red, but more on them later. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I run community programs like these events and build tools to help keep the community operating. [00:28]
-
-**Mark:** Hi, I'm Mark. My day job is working at Replay io, where we're building a time traveling debugger for JavaScript, and also trying to find ways to make AI developers smarter by giving them access to replay runtime data and in my copious amounts of spare time. Outside of that, I do redux stuff. [00:45]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Some early quick hits. My general temperature check on the job market is that it's not good. It seems bad. Layoffs for March are higher than they were in every month, except last month since September, 2024. So that's five months, yeah, that's not great. It seems like hiring is down. Oh yeah. Look at that. The Fred economic data is a continued decline, so that's not ideal. I guess that is software development, job posting, so I wonder if maybe there's like some kind of title shift leading to that decline as well. [01:20]
-
-But yeah, job market not good. So yeah, if you are on the market, I hope you are. I don't know. Good luck. Sorry. [01:28]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Upcoming conferences. [01:29]
-
-## [React Native Connection](https://reactnativeconnection.io/) April 3 \+ 4, 2025 Paris, France
-
-**Carl:** There is React Native Connection April 3rd and fourth in Paris. So if you're in France, definitely check that out. [01:36]
-
-## [React Miami](https://www.reactmiami.com/), Apr 17-18
-
-**Carl:** React Miami. A beloved conference that I have attended several times but will not be at this year. [01:41]
-
-Is April 17th and 18th in Miami, Florida. [01:45]
-
-**Mark:** I'll be hanging out there. [01:47]
-
-**Carl:** now go see Mark. He'll say, Hey . [01:49]
-
-## [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
-
-**Carl:** There's City Js London on April 23rd through 25th in London, the uk. [01:55]
-
-## [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
-
-**Carl:** We've also got App JS Conf May 28th through 30th in Cacao Poland. I've heard good things. I looked at going, but it's just can't swing it. Too big of a trip. [02:06]
-
-## [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
-
-**Carl:** CDJS Athens is also gonna be May 27th through 31st in Athens, Greece. [02:13]
-
-## [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
-
-**Carl:** And I'm helping organize squiggle conf, which is coming up much later this year. But their CFP is open, so if you are interested in speaking go ahead. Submit. It's gonna be open until May 23rd. [02:26]
-
-**Mark:** I, I got to attend Squiggle Con last year. I, I also know the organizers, Dmitri and Josh, they're wonderful people. They did a fantastic job for a first year conference last year. Squiggle Conf was great. You should totally try to go. It's in, it's in Boston. [02:40]
-
-**Carl:** It is in Boston. Yeah. Dmitri, his most recent accomplishment that made pretty big waves is he got doom running in TypeScript types, which is bananas, and took like a year and a half and he had to learn all sorts of like compiler and like processor stuff. Yeah. Unbelievable. [02:56]
-
-**Mark:** we should totally toss a link to that in here on general principal. [02:59]
-
-**Carl:** Yeah, we probably should. I don't have one handy. But yeah, super cool. Super impressive. Unbelievable maniacal in fact. But yeah. [03:06]
-
-Yeah, our sponsor you know, bear with us through all of our setup stuff before we get to the real news. We, there's so much news. We've got like a pretty major security vulnerability in next. [03:17]
-
-There's like a couple of new releases to talk about, but yeah. [03:19]
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-**Carl:** We are sponsored by Infinite Red. They are an expert react native consultancy that's been around since 2015. And I actually just saw a post that they put up on LinkedIn where in 2015 they hired 21 people and 14 of those 21 are still there, like 10 year tenure for two thirds of the organization. Like that's impressive. [03:38]
-
-I've been laid off and fired a lot and I appreciate a company that is willing to get let its people stick around. Yeah. They're currently our only sponsor, in part because so few companies do as much as they do for the ecosystem. They host the largest React native podcast. They host the largest US-based React Native conference. Yeah, lots, tons of React native stuff. They very meaningful ecosystem investment. [04:04]
-
-They only do React native and have built over 75 apps for companies from startups to the biggest in the world. And they will work with your team in order to help you develop expertise, not just get code running and dip out. [04:16]
-
-So, yeah. if your company is looking to start a new React native project, definitely check them out. They are at Infinite Red, [04:24]
-
-## New releases
-
-**Carl:** into some new releases. [04:26]
-
-## [TypeScript 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/#the---erasablesyntaxonly-option)
-
-**Mark:** last month we mentioned the TS 5.8 beta, and so now it's come out as final. The biggest thing here is probably the erasable syntax only flag, which ensures that you're only using TS types that can just be stripped away without having to go through with transation step useful for use with node, for example. [04:45]
-
-**Carl:** Yep, super great. I'm already using something like that in code that I run. It's just nice. I don't know it's nice to not do like a full compilation step. It just lets me cut an entire thing an an entire build tool out of my, outta my local development, which I like. [05:00]
-
-## [Typescript Release with Go](https://devblogs.microsoft.com/typescript/typescript-native-port)
-
-**Mark:** Although on that note, and we'll talk about this more later the TS team has announced that they have finally rewritten the TypeScript compiler itself in another language go instead of TypeScript still in an early preview stage, but they're seeing 10 x speed up and compilation time. And so the trend of converting JS build tools into other languages continues, and we'll, we'll talk about this more in depth later. [05:26]
-
-**Carl:** Probably, we'll talk about it later and we'll then probably continue talking about it later and later and later, because they have said that this is really gonna ship in like TypeScript seven, which by current release cadence [05:40]
-
-**Mark:** Is like two years from now. [05:42]
-
-**Carl:** Yeah. [05:42]
-
-two and a half, three years. So yeah, we, this is gonna be a topic for a very long time. [05:47]
-
-But yeah, they are continuing the trend of rewriting build tools in native and they are disrupting the trend of rewriting JavaScript build tools. rest. Yep. [05:55]
-
-But yeah apparently they chose Go not Rust because the like general ethos, you know, the, the way you write code in Go is more similar than Rust. So they can do like more similar patterns in the code they're offering. So it's more of a one-to-one rewrite rather than like different enough code that it would have different semantics and different, you know, challenges there. [06:19]
-
-**Mark:** And we have a mo. [06:20]
-
-**Carl:** Ammo welcome. That's okay. We're gonna throw you immediately into the hot seat with React Native 78. [06:26]
-
-## [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
-
-**Mo:** So React native 78 is out. Bunch of small things, but we're getting smaller releases and so this one is mainly focusing on React 19 support. So you can get all the React 19 features that you know and love on the web now working on Native World. And we finally get our logs back in Metro. [06:44]
-
-## [Next 15.2](https://nextjs.org/blog/next-15-2)
-
-**Carl:** Cool. Yeah, There's next. 15.2, which, you know, we're gonna talk a lot about next and more later. But um, this looks like not too crazy. A release they redesigned error ui, more streaming metadata, performance improvements, yada yada. Some experimental features as well. [07:02]
-
-And ooh, experimental node js middleware. A lot more on middleware later. [07:07]
-
-## [Tanstack Form 1.0](https://tanstack.com/blog/announcing-tanstack-form-v1)
-
-**Mark:** Tan Stack Form is a brand new form library in the vein of libraries like formic and React Hook form. This one I, I believe, was started by Tanner Winsley himself. The current maintainer is Corbin Crutchley who'd worked on a previous library, I think, called House Form, I believe. But like some of the big selling points are things like type safety, you know, being able to infer that, you know, like when you pass in the name of a field as an argument that all the other callbacks and everything else know exactly what the, you know, the proper value type for that field is. [07:41]
-
-Lotted, different validation options a lot. And working with SSR and other scenarios haven't used it, but it looks fairly comprehensive and worth taking a look at as a, you know, form solution for your apps. [07:54]
-
-## [Zeego v3](https://github.com/nandorojo/zeego/releases/tag/v3.0.1)
-
-**Mo:** Yeah, so Zeego is a library that I quite appreciate. So it's made by Fernando Roho, who very recently actually joined Vercel as their head of mobile, which is going to, which tells us a lot about the direction that Vercel is going in terms of some of their mobile offerings. But Zeego released a new sort of major release. [08:13]
-
-And so the, the big points with this is and just just for a little bit of context, we have talked about Zeego before in the podcast, but just for anyone who might have missed it, Zeego is a library that allows you to create context menus that are native to each platform and it's universal. So what that means is that it will let you create context menus on the web and it defers that to something like rad. [08:34]
-
-Then on native platforms like iOS and Android, you actually get the native context menus that you get on the platform. So those are native elements that are rendered. And it's, it's a really good example of using the same API but getting very different looks and feels that are native to each platform. [08:49]
-
-So it's, it's, it's a, it's a cool library. It's a very nice like utility library that you might need to use when you wanna get some native functionality inside of your mobile app. But the major things with this is just supporting the new architecture and React native and working with some of the new versions of Expo. [09:04]
-
-## [Material UI v7](https://mui.com/blog/material-ui-v7-is-here/)
-
-## ["Slot pattern" for overriding internals](https://mui.com/material-ui/customization/overriding-component-structure/)
-
-**Carl:** Yeah. Material UI has version seven out. Main thing that caught my eye here is they have a slot pattern for overriding the internals of their different, you know, components. Customizing component library components is like the number one reason why I have not extensively used component libraries in my career. [09:25]
-
-I just, like every company I've worked for, they have wanted a greater level of customization than is achievable just by doing things with the component library. I've been very interested in Chad CN for that reason, because it's just like, it's a co generator, not a library. [09:40]
-
-You use it to make components and then you customize those components to your needs. But this looks like a really interesting alternative pattern for it. Basically, it looks like they have a pair of props slots and slot props where a component will specify different slots that you can override. [09:59]
-
-So you can give it different components to put into places where, you know, like in, in a tab or a dropdown or whatever. That's really interesting. That seems good. Generally, it's nice that they are like trying to standardize it a little bit and like have a specification. I appreciate that and it's, yeah. [10:20]
-
-I've seen a lot of libraries do things like add in. Sort of slots. They don't call it that, but like they let you pass in a component that it will use in place of something else or whatever. But I've always seen that as very like ad hoc and like there's no standardization or structure around it. [10:37]
-
-So seeing this as a pattern is interesting to me. It's definitely, definitely interesting. Yeah. That's all I gotta say. [10:45]
-
-## [Parcel v2.14](https://x.com/devongovett/status/1902022923764076808)
-
-**Mark:** The Parcel Bundler released version two point 14, and this is kind of a big deal because it actually adds built-in React server component support. I was actually just looking at the download stats. So parcel has been around for several years. The primary author, Devin Govet, also works on React Aria and React Spectrum and a couple other component libraries. [11:05]
-
-He's put a ton of effort into building it, but it's, it's very much an also ran in terms of actual usage. Like last month, Webpac had 116 million downloads. V had 85 million downloads. Parcel only had 800,000, so non-zero, but obviously not like, you know, anywhere near the level of the other tools. [11:25]
-
-That said it is a, an actual tool in the space and so it is interesting to see what's more of a bundler rather than a framework. Adding React server component support and looking at the examples the usage pattern here looks to be a whole lot simpler than what Next has and, and has put together, you know, next is the, the defacto standard implementation of React Server components at this point. [11:52]
-
-And so I think a lot of us have tended to assume that the way server components work in NEXT is the way that they work, whereas it, it's really more like React exposes the primitives and it's up to the framework or bundler to decide how they get used. So in this case, apparently parcel actually supports using server components, like just within a, like a, like a basic express request handler, which actually looks a lot simpler conceptually. [12:20]
-
-So parcel may not have a lot of actual real world usage, but this looks like a, a, a nice example of what can be done with server component support. [12:32]
-
-**Carl:** That's cool. Oh, nice. [12:33]
-
-## [XState Store v3](https://stately.ai/blog/2025-02-26-xstate-store-v3)
-
-**Mark:** Meanwhile, the, the X State and people, AKA, mostly David Khourshid has released X State Store. Version three. X State Store is meant to be a, a much wider weight state management tool. Kind of more along the lines of a, of a zoo stand, but with a little bit more of a, a state machine twist on it. So there, there's some updates to make the usage and the developer experience a little nicer. [13:00]
-
-**Carl:** Yeah. Love X State. I don't know, I've just always had an affinity for it. They had a, they've always had a great state machine design tool and I found that useful even while not using the library. So I dunno, I just like them. [13:11]
-
-## [Better Auth v1.2](https://www.better-auth.com/changelogs/1-2)
-
-**Carl:** There's Better Auth version 1.2, which is interesting and cool. I have been following Better Off for a while. I haven't actually used it myself yet. But they've been, [13:21]
-
-**Mark:** Theme of this podcast? [13:23]
-
-**Carl:** yeah, a little bit. There's just so many things. It's hard to stay, it's hard to, staying on top of it is hard to know. Actually using all of it as well is uh, impossible. [13:31]
-
-Yeah, I, I, I like the general vibe of it. [13:34]
-
-I have been let down by literally every auth tool that I've ever used. I have written my own auth far too many times because I'm so irritated with trying to use all of the authentications libraries. And yeah, this seems good. I'm just gonna read what bytes.dev said, 'cause they summed it up very well. [13:51]
-
-"It's got Stripe subscriptions, recapture API, keys teams and sub orgs and a new init CLI, and they rewrote the core library to fix TypeScript editor lags. So like, it just seems really good. They've really been on a tear with shipping improvements. Like I, I subscribed to GitHub notifications for them and I slightly regret it because I swear to God I got like five a week with just like beta releases and new minor releases. [14:18]
-
-So it's, it's, I'm impressed at their pace of development. They seem to be doing a really good job of shipping pretty major upgrades as they go. So, if you're doing a greenfield project that needs authentication, consider it. [14:31]
-
-## Main Content
-
-**Carl:** Mo can you tell us about Lynx? [14:33]
-
-## [Lynx released](https://lynxjs.org/)
-
-## [Release blog](https://lynxjs.org/blog/lynx-unlock-native-for-more)
-
-**Mo:** SO this is, this is not specifically React native related, but it's React native adjacent and definitely react related. So, you may have heard that bite Dance, the team behind TikTok released links, and links is effectively sort of a competitor to React Native. They've created another way that to build native applications using JavaScript tooling and using React as the way that you define UIs, which is really cool. [15:01]
-
-And so, the, the real sort of reason why why this is exciting is because this is actually what's powering TikTok behind the scenes. So this is what they're using internally for TikTok. And you know, TikTok is as large scale of an application as comes. And so it's actually quite a. Quite a big deal to have something like this release and it brings healthy competition to the space of sort of cross-platform native applications where it's been traditionally just rack native and flutter. [15:27]
-
-So I think there's some really interesting stuff here. The TLDR is that they have a sort of multi-threaded a multi-threaded architecture in place. And that's one of the things that they really, really empathize, em, emphasize on. And so the whole idea is that this architecture and this multi-threaded runtime allows you to take priority on sort of synchronous UI tasks that are high priority so that the app feels snappy and responsive. [15:52]
-
-And things like event handlings are done sort of with a high priority. This is getting quite similar to the space of sort of what the React native team is trying to achieve with the new architecture, which was trying to. Targets similar benefits. And so they, they give a lot of examples on things like instant first frame rendering, which is one of the metrics that they're trying to target with this architecture to make sure that the first time you open up your app, you get as quick to instant as possible launches. [16:18]
-
-And sort of multi-threaded scripts for when there's a you know, important scrolling event or something that requires really good responsiveness. Having those sort of concepts embedded into the architecture, which is really, really quite cool. And one of the nice things about this is that their JavaScript layer functionality is not actually react specific. [16:36]
-
-So in theory, down the line, albeit React is really the only main way that you can define UIs right now down the line, they may create other versions of it. So currently there's links, which is the core, and then there's React links as well, which is the sort of the React library that you can use to define UIs for links currently. [16:54]
-
-There could be in the future initiatives where it can allow you to use other UI libraries to do this, which can be really quite cool. [16:59]
-
-**Mark:** I think I saw even at least a mention or like someone at least asking like, when can you use Vue with this? And it sounded like that was a thing that they were trying to work on. [17:07]
-
-**Carl:** Interesting. [17:08]
-
-**Mo:** but you know, that in itself is quite powerful because, you know, one of the, you know, there is nothing like rack native or there wasn't anything like rack native where you could use web-based UI libraries to define a mobile app. And so this actually opens up the door for people to use view to make actual native apps rather than sort of PWAs or hybrid web view based apps that are not gonna be good experiences. [17:31]
-
-So, quite exciting stuff. [17:33]
-
-**Carl:** That is really interesting. And it, it's, it's funny that I feel like over the last year we've talked about a couple of projects that we're exploring different ways of authoring react and getting some form of mobile app out of it. And I'm surprised that there's still like new approaches. This, we've seen so many with like, I don't know, react native web and I'm forgetting the names of all of them, but I swear to God [17:55]
-
-Four of React strict dom. [17:56]
-
-Yep. So, okay. Interesting. That sounds really cool. And I like that there's a way, I don't know, just like it, I love the web. I secretly wish that Web os from like 2012 had been a viable option. So it's just, I'm, I'm, I love seeing the web expand more meaningfully into the native arena. That's really cool. [18:17]
-
-Cool. Alright. Into the headline. [18:20]
-
-## [Security vulneratibility](https://nextjs.org/blog/cve-2025-29927) in Next.js: [CVE-2025-29927](https://github.com/advisories/GHSA-f82v-jwr5-mffw)[18:20] [Original researcher report](https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware)
-
-**Mark:** All right. The biggest news story of the month occurred just a few days ago, and that was that there was a major security vulnerability with next's middleware implementation that ultimately allowed any external attacker to send a fairly simple set of headers and force next to skip the middleware. [18:46]
-
-And if you, your app used the middleware to provide authentication to. You could actually just bypass the entire authentication process. So the assumption here is if you're using next to do middleware, and then there's some other caveats around where your app's actually hosted. But ultimately this was rated as an extremely high concern security vulnerability. [19:11]
-
-So Next has released actual, actual fixes across a couple different major versions to try to patch up the issue. There's been. You know, breakdowns of, you know, what the actual bug is and why this is a concern and how it works. And then there's been a lot of fallout from this issue in terms of how did Vercel handle communicating the vulnerability to the general public as well as other partners. [19:38]
-
-And follow on questions like, you know, how does Vercel and next actually kind of handle their development processes? associated pieces to go through with this. So let's, let's try and break some of this stuff down. [19:49]
-
-**Carl:** Let's see what we can do. Yeah. So you, you mentioned how many versions that they shipped. So they, in, in their, you know, blog post, it's very. I don't know, no details, no extra explaining what happened. They explaining the advisory, I guess they, they then put out a, like timeline of the thing and gave a lot more details. [20:09]
-
-But so they released patches for version 12, 13, 14, and 15, which means that this has been a vulnerability since at least 2021, which is wild [20:19]
-
-**Mark:** It sounds sounds like Al, almost exactly, almost since like the, the middleware feature probably came into existence. [20:26]
-
-**Carl:** Which I guess that makes sense. Like you add a new feature and it has vulnerabilities and until somebody notices it, you don't fix it. But wow, four years for an auth bypass based on a header. [20:36]
-
-## [CVEs and the NVD Process](https://nvd.nist.gov/general/cve-process)
-
-**Carl:** So I want to lead in a little bit breaking down like the CVE process, which I am not sure. I feel like everyone, I feel like a lot of people will have a general, I. [20:47]
-
-Awareness of what, of what A CVE is. I didn't quite realize that it was like an NIST national Institute of Standards and Technology Program. Like this is a government program established in 1999 to track, [21:02]
-
-**Mark:** known security bugs. [21:04]
-
-**Carl:** Right. So like, yeah, and it has a, there's a calculator that lets you figure out the severity of a vulnerability. [21:12]
-
-And it has criteria like the attack vector, the attack complexity, the requirements of the attack privileges required, user interaction are required, and then the impact of the vulnerability. It's confidentiality, integrity, availability. It's basically like how do you do the attack and if you execute the attack, what are the impact, what are the effects of it? [21:35]
-
-So this. You know, the scoring criteria for this vulnerability is it's a network attack vector, which means you don't need to be physically present which is bad if you can do it over the network that's like a high level of access. The attack complexity is low, the privileges required are none. [21:54]
-
-The user interaction required is none. And the impacts confidentiality are high, integrity is high but no impact on availability. So you can, you know, get into confidential spaces and, you know, violate the integrity of the data. [22:09]
-
-You so it, it's, it's basically an attack you can do from anywhere in the world that's very simple. That gets you a high level of access, which is why this is a, you know, critical severity bug. That's so bad. Oh my God. Just for a, a bug of that severity to exist for four years before anyone noticed is oof rough. [22:30]
-
-**Mark:** The general concept here is that, you know, middleware can be chained together. But there's, there's internal implementation details around like possibly needing to rerun middleware or possibly needing to skip middleware. [22:43]
-
-And so at some point Versel opted to implement skipping, running middleware by looking for a specific header that they could attach to the request. And the intent was that this would only be an internal thing, that the header would only ever get added by next itself in response to, some piece of code saying, Hey, we're, we're good. [23:09]
-
-We can just keep going. Or I guess maybe to, to, to get rid of loops in the middleware chain. And someone figured out that. You know, wait a minute, I could, I could attach this kind of a header as part of an external request. And the piece of information that next was looking for the, in the header is just a name of the middleware itself, which is pretty much always based on the file you would've added in your next project, which is apparently in some cases like just the literal word middleware. [23:44]
-
-And so you could end up like having a header value of middleware, colon, middleware, colon, middleware, colon or something like that. the end result is that someone could send a request to a next base server, add this header to their original external request, and end up convincing next, skip all the middleware and never run them. [24:07]
-
-And. And so if some of the were trained to do authentication, then the request would end up just skipping that entire process. I believe Vercel said that the way they have their systems architecture set up it was not really possible to have that be a problem on if your app was hosted on Vercel infrastructure. But then there was questions of, okay, well what if you're running on Netlify or CloudFlare or using one of the Open Next adapters? So the bug exists in next, and then there's the question of, well, how is next being hosted and what requests could actually get through? [24:46]
-
-**Carl:** Right, so. I think what I saw is that they're saying if you hosted on Vercel, you were never vulnerable to this because of how we set up our system, which is great. I guess this. Certainly fuel on the fire of like Vercel is privileging itself in the ecosystem. [25:03]
-
-## [Postmortem on Next.js Middleware bypass](https://vercel.com/blog/postmortem-on-next-js-middleware-bypass)
-
-**Carl:** And I guess building on that a bit, so they put out, you know, their postmortem breaking it down and breaking down the response. [25:11]
-
-**Mark:** Which, which came out about like, like two to three days after the actual announcements. [25:16]
-
-**Carl:** Right. And it looks like, you know, in the timeline they talk about like receiving emails and like multiple reports, which delayed the triaging. But like, you know, the core of the timeline, I. [25:27]
-
-**Mark:** A month or something. [25:28]
-
-**Carl:** it looks like somebody reported this at the end of February on the 27th, and then it didn't get triaged until two weeks later, which seems not good. [25:38]
-
-I don't know. I, I, I have done triaging of security vulnerabilities. I was the point person for that at my last job for like two years, a year and a half, something like that. And there's a lot of noise. There's a lot of garbage that comes in. There's a lot of, you know, quote unquote security researchers who are just like running automated tools like nmp. [25:58]
-
-You know, it's like, you know, you are an NPM audit and it's like 63 critical violations and like, none of them actually matter at all. So like, there is a lot of noise and I can understand how triaging might get delayed, but you know, like even just reading the headline, you know, if somebody submits like authorization bypass, like that would wake me up. [26:17]
-
-So, I don't know, just waiting for two week lag time on that is not ideal. [26:22]
-
-**Mark:** One, I mean, one, one bit of that is, it sounds like the initial submission just said, this looks like it's a problem in next, in, next next 12, which was out of date. And so like it sounded like someone may have glanced at it and said, oh, we don't even support next 12 anymore. It's not a big deal. [26:38]
-
-And then the researcher came back and said, actually, it's a problem in like every version of next. And that finally got someone to wake up. [26:46]
-
-**Carl:** for sure right? So, like, okay. Devil's in the details on this as always, but yeah, it's not a great situation. And what's more is that, it sounds like they did no coordinated disclosure. [27:00]
-
-## [Next.js and Coordinated Disclosure](https://sxlijin.github.io/2025-03-23-next-js-and-coordinated-disclosure)
-
-**Carl:** This person talks about some other CVE environments or disclosures that they've either, you know, been a part of seen and for instance, you know, like heart bleed, some of those other like large scale mass impact vulnerabilities, like this is not obviously of that scale, but it is large. [27:21]
-
-So the, the, those ones like heart bleed, they had like multiple months of coordinated disclosure where behind the scenes in secret. You know, once these vulnerabilities are known, the companies are coordinating with each other to say like, are you vulnerable? Yes. Here's how we fix that. Are you? Yes. Okay, let's fix that too. [27:40]
-
-And. What they're claiming is that Net or Vercel did nothing like that. They received a report, they validated it, they pushed their own fixes, and then they went public with it and basically caught other platforms like Netlify, cloud Flare, et cetera, with their pants down. And it was just like, oh shit. [28:02]
-
-You what? What? We're vulnerable. And so now everyone's scrambling. And it's been publicly, it is, it's been publicized. So like now many websites are vulnerable, it's public knowledge and the a patch isn't ready. So like, that's, that's just not nice. it's not collaborative at all for sure. [28:22]
-
-So it, it just means that like, it became a race to fix this before it got exploited in the wild. That's definitely not ideal that like that's, I guess I can understand how a company might say like, this is a problem with our product. We are fixing it. We have fixed it. It is time to go public. I guess I can understand that thought process, but man, as far as like being a participant in a broader ecosystem, that's a big blind spot. [28:49]
-
-**Mark:** yeah. The, that, that link about coordinated disclosure is really good. It, it breaks down what did happen at what times, and then talks about like what are, what are the proper practices for handling a security disclosure? What did, like, what actually happened instead? How did this, like, how did other people end up finding out about it? [29:09]
-
-And then like, what, what would have been a proper sequence of results? Instead, I. So like ultimately, you know, things have sort of been handled here, but really, really badly along the way. [29:24]
-
-**Carl:** Yeah, and I guess one more detail that I'll highlight as part of like, this response was not handled well and maybe went through the wrong channels, the wrong internal channels. when they announced the vulnerability, I. One of their claims as part of it, which is accurate as best I can tell, is that you as our customers of Vercel, were not vulnerable because you were protected by our firewall. [29:47]
-
-So it's like, it feels like it went through the marketing department rather than like, I don't know, engineering, security, whatever, where they were making an honest claim about a differentiating factor. But like part of the differentiating is that they were not collaborating with anyone else to help protect end users. [30:08]
-
-So it's like, yeah, sure that's true, but it's also kind of mean that you did that. So, I don't know. It's not ideal. Not great. [30:17]
-
-## [You should know this before choosing Next.js](https://eduardoboucas.com/posts/2025-03-25-you-should-know-this-before-choosing-nextjs/)
-
-**Mark:** And then one other good blog post related to this somebody who works at Netlify and has spent a lot of their engineering time trained to reverse engineer some of the somewhat more proprietary features of Next to make sure that they work on Netlify. Wrote a very long blog post that. Digs into both, you know, some of the, some of the vulnerability aspects, but then also just general concerns about the way next is developed and deployed and, you know, does not necessarily work with the ecosystem as well as it ought to. [30:54]
-
-Describing a lot, a lot of the concerns, you know, that there, that there aren't, official adapters to run on other platforms that it doesn't have serverless support, that there's certain code paths that really only work on versal. And then also kind of talking about, you know, some of the security aspects. [31:11]
-
-It's not like, it's not a, it's not a flat out indictment, but it's a, it's a very fairly written post from, you know, someone who acknowledges, you know, the own biases upfront, but like, it's a, it's a very valid set of concerns from someone who deals with next, from an external ecosystem perspective. [31:29]
-
-**Carl:** Sure. [31:30]
-
-Yeah. Not a great situation overall, but it's out, it's fixed. That's good. Onto the next [31:35]
-
-um, okay. [31:37]
-
-## [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
-
-**Mo:** We are back with another release of React Native. And so this one is is focused again, we're, we're going through faster releases now. So you might've noticed if you've been staying tuned for a little while that our release cadence within the React native ecosystem is becoming shorter and shorter, which is great news because it means we get updates quicker. [31:58]
-
-And that's largely due to the new architecture being out now. And so that allows us to basically the, the core of React native is a lot more stable. And so there is there's, there's more of a foundation to release a lot faster, which is great. Other highlights for this release is React 19 is now available on React Native, which is great. [32:17]
-
-So if you, you know, followed along with the previous React 18 implementation for React Native, you will have been aware that it took years to get it up to date with all of the React 18 features, largely because of the new architecture not being out fully. And so now you can see there's much of a smaller lead time to get React 19 support. [32:38]
-
-So all of the new sort of features of React, things like actions use, optimistic, the use hook, all of that stuff, and, you know, not needing to use forward ref anymore. All of that stuff is there now. On top of that the React compiler support is is now there. So you can actually install the compiler, configure it, and it should be able to work just as you would on the web, which is awesome. [32:59]
-
-The, probably the most, important feature for the community though is that they've brought back JavaScript logs in your metro bundler. So this was one of the things that the react native team did last release was they removed logs being shown in your JavaScript bundler. So they were trying to push people to use the react dev tools that they released, or the new dev tools that they released for the React native ecosystem only to face the most crazy amount of backlash from the community because their logs had moved. [33:27]
-
-And people were very unhappy about that. So, they rolled back that. you can pass on a flag now and basically get the logs showing in your bundler once again, like it was for the last. However many years React native has been out for. And so they have said that they will eventually remove this again. [33:43]
-
-But they're trying to give a little bit more time for people to adjust to using the new dev tools. So we'll see how that goes when that happens. Once again, there's some other minor changes, but those are really the big things that's worth mentioning. And I think we're gonna get a lot more React native releases happening a lot more regularly since the new architecture is up. [34:00]
-
-**Mark:** Sounds like a pretty substantial set of changes. [34:02]
-
-**Carl:** And it's cool that they are able to release more quickly, to keep better aligned with the, you know, main mainline react version. I hadn't really registered that as a benefit that would come out of the new architecture, but it makes sense, especially while they are effectively maintaining two versions, you know, new architecture, old architecture, suddenly only have to do the new architecture. [34:25]
-
-That makes a lot of sense. That's super cool. [34:27]
-
-## [React Native Core Contributor Summit 2024 Recap](https://reactnative.dev/blog/2025/02/03/react-native-core-contributor-summit-2024)
-
-**Mo:** So the, the next thing that I, I thought I'd just drop in here. it was technically published in February, but I think we missed it and I, I wasn't around in February is the React Native Core contributor Summit for 2024. The recap was finally released. So this is an article on the rec native dev blog. [34:43]
-
-I actually co-authored this. So last year in SLA in in Poland, I think it was around September we had the React Native Core Contributor Summit, which is a, a full day workshop. Talking about a bunch of different. Things that are strategic to React native in general. And one of the things we talked about was the release process. [35:02]
-
-We talked about, you know, what's the next big thing after the new architecture. So there was a bunch of different sessions and we split off. There was a session about how do we bring web APIs into, into to, to the React native world to standardize some of the APIs for interacting with the native layer. [35:15]
-
-So a lot of really interesting stuff. We talked about Nitro modules, which is sort of, we've talked about several times in the last few sort of podcast episodes outta tree platforms and react native on desktop. I held a session as well, so I led a session during this during this core contributor summit lean Core 2.0. [35:31]
-
-So just for a bit of context lean core, was an initiative in the React native ecosystem back in 2019. And so the goal of Lean Core was to bring down the surface area of React Native's, core APIs because there was just so much stuff in there. Like somebody needed access to something in IOS's specific APIs and they just create a component and pop it into React Native Core and that would just be a part of maintenance burden for the core React native team. [35:56]
-
-So there wasn't much strategic direction around what goes into core and what goes into sort of community packages. And so they went through this effort in 2019. But the goal of the session this time around was actually, I think we we're due for another cleanup. 'cause there's a lot of random stuff there that is either props in certain core components that are tying specifically to Android or iOS, or there's just some components that don't get used anymore because there's much better components in community libraries that you can use. [36:23]
-
-And most people end up using those. So it was a good conversation around what should be deprecated in the long run. And so that's one of the sessions that I think was quite fruitful. And I say that probably being quite biased because I was the person who hosted the session. But yeah, that's a, that's a summary about the uh, the React Native core contributor Summit from last year. [36:39]
-
-If you're interested please feel free to go and, and read the article. [36:42]
-
-## [TypeScript compiler Golang rewrite??](https://devblogs.microsoft.com/typescript/typescript-native-port/)
-
-**Mark:** Alright, so the other really big piece in and piece of news for not just the React ecosystem, but the web development ecosystem as a whole is the, the TypeScript team has officially announced that they have created a fort, not a rewrite of the TypeScript compiler, the current version of TypeScript itself is written in TypeScript, which means it's actually, you know, in the end it's the, it's just JavaScript executing and they have ported the compiler itself to be written in. [37:14]
-
-Go. And what they say in the announcement is that they're seeing like generally 10 x speedups in the actual TypeScript compilation stage of processing people's programs. I saw at least one post on Reddit where someone was complaining that people are gonna be confused. That this means that they think that this means their code runs faster. [37:34]
-
-It's like, no, this is just compiling the TypeScript types 10 times as fast. And this is a really big deal. this trend over the last five, six years of all these different JavaScript ecosystem build tools being rewritten in native languages, mostly rust, and getting a lot of speed ups that way. [37:53]
-
-So, you know, es e es build as in go you know, RS pack and roll down are both written in rust, et cetera. I mean, a lot of tools being rewritten in native languages to try to speed things up, but a lot of them have still, like the actual build pipelines still get bottlenecked on TypeScript compilation time because it doesn't matter how, how fast you can process all these different, you know, individual module files and bundle them together if you're still doing a full type script type check during that section of the build phase. [38:29]
-
-And so there's been a bunch of attempts to rewrite the TypeScript compiler. I. Into native languages from random people in the ecosystem. The author of SWC had tried to do a couple different attempts at porting. One in rust, one in go. I saw somebody who had done one with trying to, trying to create some kinda like a stack based virtual machine to process the types, and he'd gotten like a baby example working that seemed way faster, but it was only for, it only worked for very, very simple types. [39:01]
-
-So, I mean, there, there's been attempts from individuals, but none of these got anywhere past, like a modest proof of concept stage, like they proved they could work, but then it's a massive amount of effort just to catch up with where the TypeScript compiler is much less keep up with where it's going on a month to month basis. [39:21]
-
-And so, you know, a lot of people had said that, well, it feels like the only way this would actually happen is if the TypeScript team themselves actually decides to do it. Well, it turns out the TypeScript team decided to do it about a year ago, and they've been working on this in secret, and now they've gotten this far and proven it works and are actually intending to push this forward to become, you know, the actual TypeScript compiler down the road. [39:49]
-
-as Carl mentioned, so right now we're on TypeScript 5.8. They put out quarterly ish releases, I think. So basically four, four releases a year. They also follow a kind of a, a, a decimal based versioning system where it's not really SemVer, but they just roll over from 5.8, 5.9, 6.0, 6.1. So they've said that the plan is that the new native go compiler will probably officially become TypeScript 7.0. So that means we probably have about two to three years before that actually happens officially. [40:26]
-
-**Carl:** But they may also just release it like when it's ready. I, I don't believe that the version seven is a firm commitment. So it, maybe, it will, maybe validating it, maybe making sure that it won't break. Everything will happen faster than they expect, and it may be [40:42]
-
-**Mark:** I mean, they, they, they might like, they, they might end up going from like a six four to a 7.0 instead of having to get through 6, 4, 5, 6, 7, 8, 9. [40:52]
-
-**Carl:** Okay. I don't know. I thought they just did straight up incremental and when they got to nine they incremented, [40:57]
-
-**Mark:** right, right, Like, so my, my point is that if it's ready in say one year from now, we would be at TypeScript 6.2, and rather than officially waiting another two years and eight more releases to get to 7.0, they might just say, okay, yeah, this is the end of the line for the old compiler here. [41:15]
-
-**Carl:** yeah. Hard to say. Who knows? I do wanna, I wanna highlight a couple of, you know, comments from the people who worked on this. [41:23]
-
-## [Github discussion](https://github.com/microsoft/typescript-go/discussions/411) and [on reddit too](https://www.reddit.com/r/javascript/comments/1j8s441/comment/mh7ms9n/)
-
-**Carl:** Ryan Cavanaugh put out a great Reddit comment describing why they chose go, basically. And, you know, we kind of talked about it a little bit, but I, I wanted to enter his words into the cannon a little bit here. [41:36]
-
-**Mark:** I was shocked at how much pushback there was, especially from the C sharp folks. Oh my word. The C sharp community was up in arms about why the Microsoft engineers did not pick C Sharp as the language for the new compiler, [41:51]
-
-**Carl:** Yeah, sure. I, the amount of space in my brain that C sharp developers occupy rounds to zero. So anytime they come on, I am a little surprised. But yeah. So like, I wanna, I wanna try and pull out a good quote here. So, like, really their primary goal here was portability. They don't wanna rewrite anything. [42:09]
-
-They would like to adapt it into a new faster language. So they really say portability was always a key constraint here. As we thought about how to do this, we tried tons of approaches to get a representation that it would've made the port approach tractable and rust. But all of them either had unacceptable trade-offs or devolved into write your own garbage collector style strategies. [42:28]
-
-So right, like they, it looks like they really genuinely validated trying to use multiple languages here at least between Rust and go. And they say, [42:38]
-
-**Mark:** I think I saw mention they also tried in c as well, okay, in this post, but elsewhere. [42:42]
-
-**Carl:** yeah, sure. That makes sense. I saw a quote that I liked. " In our opinion, rust succeeds wildly at its design goals, but quote is straightforward to port to rust from this particular JavaScript. Code base is very rationally not one of its design goals. It's not one of goes either, but in our case, given the way we've written the code so far, it does turn out to be pretty good at it." [43:01]
-
-So like basically they chose to write code in a style that happens to align thematically with Go. And so when they chose to port it, it ended up working out pretty well. [43:11]
-
-**Mark:** one of the key points here is that like anyone who's actually worked with a lot of TypeScript types or has dared to peek inside the TypeScript compiler, I. Is aware that there, there are a lot of very complex and very subtle behaviors of TypeScript and you know, one of the complaints about TypeScript for years is that there is no official spec for the language itself and how everything should work. [43:36]
-
-It's pretty much just, well, the spec is what the compiler does for this release and that's it. So in other words, the, the spec is the tests that they have. It's not an official language design document. because of that, if you try to rewrite the compiler in another language and you kind of start from scratch, you run the risk of ha of like trying to do things the same way. [44:05]
-
-But the code ends up being kind of different. I. Then you end up getting literally different output from the rewrite of the compiler, which would be really bad for the entire ecosystem that is depending on the compiler to return consistent type results. And so one of their conclusions was go allows us to make an almost literal one for one line for wine port of the exact data structures and the exact logic that we already have written in TypeScript. [44:36]
-
-And so that guarantees that we should get exactly the same calculation results from the new compiler just faster. Faster. So that was a really, really big consideration here. [44:49]
-
-**Carl:** Definitely makes a lot of sense. [44:50]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Cool. Okay. Onto the lightning round. [44:52]
-
-## [JSC being extracted from RN Core](https://github.com/react-native-community/javascriptcore)
-
-**Mo:** first one JSC is being extracted from React Native Core. So, several years ago there was a custom JavaScript engine that was introduced into React Native called Hermes. [45:01]
-
-That's what everyone has been using for the last several years, or most people have been using for the last several years. There are some people who still use JSC for very specific niche use cases. And so it was inside of the reactive core package up until recently when it's been extracted out. [45:16]
-
-So if you want to use JSC instead of Hermes, it is now an external package and you're gonna need to install it separately. [45:22]
-
-## [node-modules.dev v0.4.0](https://bsky.app/profile/antfu.me/post/3ljubvzvwec2w)
-
-**Carl:** This is very small, but seems neat. I'm just going to call it out. Anthony Fu put out a node modules dev, which just seems kind of cool. It's like a way of analyzing the dependency tree for a specific node module. It seems cool. I have had to do various ways of visualizing dependency trees a number of times throughout my career, and it's always been a pain in the butt. [45:47]
-
-So just seeing a tool that's online, on the internet where you can just like plug it in and analyze it visually is very cool and interesting to me. Seems good. I like it. [46:00]
-
-## [Fernando Rojo joining Vercel as Head of Mobile](https://x.com/rauchg/status/1896943726486032783)
-
-**Mo:** next up on the lightning round is that, as we mentioned a little bit earlier on in the episode, a little bit of a, of a spoiler. Fernando Roho has joined Vercel as the head of mobile. [46:10]
-
-And so this is a very interesting development because Vercel traditionally was very web focused. Expo was traditionally mobile focused. So those were the two frameworks. And it seems like they're starting to bleed into each other's territory, which is gonna get really, really interesting. So that is that's gonna be quite an interesting one to see because maybe Vercel is working on a framework for React Native. [46:32]
-
-And we know that the Expo folks have been working on sort of web-based support as well, so we will see on how this develops. But it's just an interesting signal from the Vercel folks. [46:41]
-
-## [Next vs TanStack (Router \+ Vite)](https://www.kylegill.com/essays/next-vs-tanstack/)
-
-**Carl:** Kyle Gill put out a next JS versus Tan Stack article, which he at the very start says, was inspired by a 2019 post from Jared Palmer contrasting Gatsby with next js. [46:55]
-
-I highlight that because Jared Palmer currently works at Versal. Fun fact, I interviewed with him for a job in 2017. I did not get it. And 2019 when Jared Palmer wrote that Gatsby versus Next Post I feel like was about the turning point for Gatsby enthusiasm starting to die off. That's when mine started to die off for sure. [47:17]
-
-So that, it's, it's interesting seeing that he is calling back to that moment, in this moment in a pretty different direction. So we'll see, you know, who, who knows if that same trend will continue, but it's, it's, it looks like a great comparison of functionality between Next and Tan Stack. And Tan Stack is certainly getting a lot of interest in mind share. [47:42]
-
-So yeah, if you're thinking about it, definitely check that out 'cause it seems nice. [47:46]
-
-## [Expo’s AI Strategy](https://expo.dev/ai/strategy)
-
-**Mo:** Cool. Next up there's a blog post that the CTO of Expo did on their AI strategy. it's quite a short blog post so you can kind of skim through it. But really the point they're trying to make is that we're in an age that you can use AI to democratize building apps. And so they talk about how they're gonna take efforts to make sure that their docs and, you know, all of their material is well suitable for things like the model context protocol, the MCP that philanthropic released but also other sort of, protocols and interfaces that AI agents may use. And then they talk about how Expo is being used by tools like Repli by Bolt and other tools already to build apps from prompts so that, you know, non-technical people can sort of, as we say today, vibe code their apps. But I think they, they're really seeing this as a uh, as an opportunity to, to get people to build apps. [48:37]
-
-The everyday person who's not a developer to be able to build apps. [48:39]
-
-## [Laravel launched “starter kits” including React](https://laravel.com/docs/12.x/starter-kits)
-
-**Carl:** Laravel just released starter kits this month including some for React. So that's interesting. They're doing, like, I, it looked like it included server-side rendering. I'm not sure if that is owned by Laravel or React but just interesting. [48:54]
-
-I don't know. I, Laravel is maybe on my mind because I was seeing a number of months ago some conversation discussing what you get out of the box with tools like Laravel and the general lack of anything comparable in the React ecosystem. Specifically around auth. I saw people talking about what you need to, what you get for free with a tool like Laravel. [49:18]
-
-And I was a little bit surprised because you do not get that for free. In my experience when you're building an app with React, so that just gave Bit, gave me a bit of a respect for the, the, the tool. So it seems neat. It's a new major version, version 12. It's got starter kits. One of the starter kits uses React. [49:34]
-
-It claims server-side rendering support. [49:36]
-
-## [React Native Enterprise Framework](https://enterprise-framework.callstack.com/)
-
-**Mo:** So next up, call stack, the folks behind React Universe Conf and libraries like React Native Paper, have announced that they're creating a new React native framework that's specifically targeting enterprise. [49:49]
-
-Now, this is very early days. They're trying to target some of the pain points that enterprise clients with large, large number of you know, devs and with restrictions on where they can host their infrastructure are facing. And so they want to try to target that niche of React native apps which is quite interesting. [50:07]
-
-And so, this is still very much in sort of waiting list stage. So it's, it's early days. But their, that, their start focus is that you can have reusable cloud builds that run on anywhere. Potentially GitHub actions but potentially also other pipeline providers. And also a nice way to be able to integrate Brownfield into existing iOS and Android apps so that you have an incremental migration path. [50:30]
-
-So, very early days, we'll see. We'll see where we, where we, where this kind of develops and, and, and where this goes. [50:36]
-
-## [State of React Native 2024](https://results.stateofreactnative.com/en-US/)
-
-**Mo:** And last on our list is the State of React native 2024. So this is a survey that the folks at Software Mansion do every single year and they touch on a whole bunch of stuff like dev backgrounds, demographics, what libraries people are using, and what you use for state management and all of that. [50:52]
-
-And so, this year the main things that they're that they basically concluded, which is, is kind of no surprise whatsoever, is the um, expos becoming sort of the main way to build react native apps. And they see momentum with tools like Chrome, the, the, the Chrome dev tools, protocol based new React native dev tools that Meta's announced and tools like Expo Atlas. [51:14]
-
-But take a look into it if you're interested in. Analyzing the trends in the React native ecosystem. [51:19]
-
-**Carl:** Alright, thanks everyone. That's everything we got. We will be back on the last Wednesday of next month in April on the 30th. come join us on April 30th here in the live stage, or we will be back in your podcast feed just as soon as we can. [51:33]
-
-**Mo:** Yeah, well, always a pleasure guys, and looking forward to jumping on in April to see you all there. [51:40]
-
-**Mark:** Likewise. [51:41]
-
-**Carl:** Cool, see you then. We gather sources from this week in React bys.dev, react status next JS weekly, the React JS subreddit here in reactive flux, and sometimes even directly from those publishing articles. If you see anything newsworthy, definitely let us know in the Tech reads, tech News and Reads channel here in reactive Flux. [52:00]
-
-Or you can send me an email at hello@reactiflux.com. I read everything that comes in, even if it gets marked as spam, so don't worry. If this is a show that you get value from and would like to support, best way to do so is by telling people about it or by submitting a review on whatever platform that you listen to it.
-
-Thanks for listening. See you next month. [52:16]
diff --git a/src/transcripts/tmir-2025-04.md b/src/transcripts/tmir-2025-04.md
deleted file mode 100644
index 629d510..0000000
--- a/src/transcripts/tmir-2025-04.md
+++ /dev/null
@@ -1,504 +0,0 @@
----
-title: "TMiR 2025-04: React 19.1 helps debug owner stacks"
-date: 2025-04-23
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- Quick hits
- - [[00:52](#job-market-fred-data-layoffsfyi-trueupio)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
- - [[01:50](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:53](#appjs-conf-may-28-30-krakw-poland)] [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
- - [[01:59](#cityjs-athens-may-27-31-athens-greece)] [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
- - [[02:04](#react-summit-june-13-17-amsterdam-nl)] [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
- - [[02:09](#react-conf-is-back-oct-7-8)] [React Conf is back](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Oct 7-8
- - [[02:22](#squiggleconf-2025-cfp-closes-may-23)] [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
- - [[02:37](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
- - [[03:24](#new-releases)] New releases
- - [[03:27](#animejs-v4)] [Anime.js v4](https://animejs.com/)
- - [[04:03](#rn-v79)] [RN v79](https://reactnative.dev/blog/2025/04/08/react-native-0.79)
- - [[05:00](#nextjs-153)] [Next.js 15.3](https://nextjs.org/blog/next-15-3)
- - [[05:20](#rspack-joins-the-nextjs-ecosystem)] [Rspack joins the Next.js ecosystem](https://rspack.dev/blog/rspack-next-partner)
- - [[06:29](#react-aria-april-11th)] [React Aria April 11th](https://react-spectrum.adobe.com/releases/2025-04-11.html)
- - [[07:13](#redux-toolkit-27)] [Redux Toolkit 2.7](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.7.0)
- - [[07:44](#vitest-31)] [Vitest 3.1](https://github.com/vitest-dev/vitest/releases/tag/v3.1.0)
-- [[07:55](#main-content)] Main Content
- - [[07:57](#react-labs-view-transitions-activity-and-more)] [React Labs: View Transitions, Activity, and more](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more)
- - [[22:04](#react-191)] [React 19.1](https://github.com/facebook/react/releases/tag/v19.1.0)
- - [[22:53](#one-react-mistake-thats-slowing-you-down)] [One React mistake that's slowing you down](https://www.epicreact.dev/one-react-mistake-thats-slowing-you-down)
- - [[26:12](#advanced-react-component-patterns)] [Advanced React Component Patterns](https://kentcdodds.com/blog/advanced-react-component-patterns)
- - [[26:54](#improvements-in-expo-using-owner-stack)] [Improvements in Expo using owner stack](https://github.com/expo/expo/pull/35866)
- - [[27:48](#dan-abramov-is-writing-again)] Dan Abramov is writing again
- - [[29:09](#react-for-two-computers-complement-to-his-react-conf-talk)] [React for Two Computers](https://overreacted.io/react-for-two-computers/) (Complement to [his React Conf talk](https://www.youtube.com/watch?v=ozI4V_29fj4))
- - [[29:26](#jsx-over-the-wire)] [JSX Over The Wire](https://overreacted.io/jsx-over-the-wire/)
- - [[30:11](#impossible-components)] [Impossible Components](https://overreacted.io/impossible-components/)
- - [[35:28](#dont-ruin-his-process)] [don’t 👏 ruin 👏 his 👏 process](https://bsky.app/profile/danabra.mov/post/3lmi3gpiluk2m)
-- [[35:47](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[35:48](#nextjs-rfc-deployment-adapters-api)] [Next.js RFC: Deployment Adapters API](https://github.com/vercel/next.js/discussions/77740)
- - [[36:23](#flightcontroldev-from-last-year-secret-knowledge-to-self-host-nextjs)] flightcontrol.dev from last year: [Secret knowledge to self-host Next.js](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)
- - [[36:38](#styled-components-in-maintenance-mode)] [Styled-Components in maintenance mode](https://opencollective.com/styled-components/updates/thank-you)
- - [[37:15](#rip-styled-components-now-what)] [RIP Styled-Components. Now What?](https://fadamakis.com/rip-styled-components-now-what-a8717df86e86)
- - [[38:50](#redwood-announces-new-cloudflare-based-rsc-sdk-existing-framework-in-community-maintenance-mode)] [Redwood announces new Cloudflare-based RSC SDK](https://redwoodjs.com/), existing framework in community maintenance mode
- - [[40:18](#tc39-kills-records-and-tuples-proposal-possible-alternative-is-composites)] TC39 kills [Records and Tuples proposal](https://github.com/tc39/proposal-record-tuple/issues/394). Possible alternative is [“Composites”](https://github.com/tc39/proposal-composites)
- - [[41:36](#react-compiler-rc)] [React Compiler RC](https://react.dev/blog/2025/04/21/react-compiler-rc)
- - [[42:29](#just-use-vite-with-the-workers-runtime-vite-on-cloudflare)] ["Just use Vite”… with the Workers runtime](https://blog.cloudflare.com/introducing-the-cloudflare-vite-plugin/) (Vite on Cloudflare)
- - [[44:21](#silk-library---native-like-swipeables-for-the-web)] [Silk Library - native-like swipeables for the web](https://silkhq.co/)
- - [[45:22](#transitions-fstate)] [\{transitions\} = f(state)](https://jordaneldredge.com/blog/transitions-f-of-state/)
- - [[45:51](#tailwind-4-bun-and-old-macs-a-supermarket-bag-and-a-truckload-of-fomo)] Tailwind 4, Bun, and old Macs: [A Supermarket Bag And a Truckload Of FOMO](https://blog.julik.nl/2025/03/a-little-adventure-in-modern-frontend)
- - [[46:47](#introducing-firebase-studio)] [Introducing Firebase Studio](https://firebase.blog/posts/2025/04/introducing-firebase-studio/)
- - [[49:05](#gumroad-is-open-source)] [Gumroad is open source!](https://gumroad.gumroad.com/p/gumroad-is-now-open-source)
- - [[49:50](#automattic-laid-off-16-of-staff)] [Automattic laid off 16% of staff](https://automattic.com/2025/04/02/restructuring-announcement/)
-
-**Carl:** Thank you for joining us for the April edition of this month in React, where we recap and digest the recent developments in the ever-evolving reactive web ecosystem. [00:07]
-
-We are coming to you live from Reactiflux, the place for professional react developers, and we are supported by Infinite Red, a consultancy that works exclusively in React Native. I am Carl. I'm a staff product developer and freelance community manager here at Reactiflux, where I do community programs like these and build tools to help keep the community operating. And I might oversee a hackathon next month. So yeah, keep an eye out. [00:30]
-
-**Mark:** I'm Mark. My day job is working at Replay io and in my free time I spend entirely too much stuff and time working on Redux and griping about the React docs. [00:39]
-
-**Mo:** And I am Mo, I had the mobile team at Theodo. And I am an active member of the React Native ecosystem and organized the React Native London Meetup and the React Native London Conference. Happy to be here as always. [00:51]
-
-**Carl:** Heck yeah. [00:52]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
-
-**Carl:** Very quick overview of job market stuff. I found a new data source that I don't know how I hadn't heard of it before 'cause it is not super new. trueup.io has a job trend page that looks pretty good. similar but distinct from layoffs.fyi. [01:05]
-
-They are saying that there's been a little uptick of open tech jobs. But you know, there's also been a bunch of layoffs. Although this month most of the layoffs are coming from Intel, which yesterday had a bunch of reports filter out saying they're gonna lay off 20% of staff. [01:23]
-
-But like 20% of staff in Intel probably means a lot of manufacturing jobs, not like software tech. So I don't know what that means, but yeah. I don't know. Vibes are still bad. One thing I like about TrueUp is that they have a, like remote index where it estimates what percentage of available jobs are remote friendly And that has been trending down, sadly. [01:45]
-
-It's slightly sub 20% right now, which is, not great. Yeah. [01:50]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** So upcoming conferences in May! [01:53]
-
-## [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
-
-**Carl:** At the end of May, May 28th through 30th in Krakow Poland, we have App.Js conference [01:59]
-
-## [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
-
-**Carl:** . There's also City JS Athens around the same time. May 27th through 31st. [02:04]
-
-## [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
-
-**Carl:** Then in June we've got a React Summit in Amsterdam. [02:09]
-
-## [React Conf is back](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Oct 7-8
-
-**Carl:** This is very early, but the React core team has announced that React Conf will be back this year. last year. It was when I was in May. this time last year I was in Vegas for that, but yeah, they're doing it you know, mid-October. So that's cool. [02:22]
-
-## [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
-
-**Carl:** there's an open CFP that closes one month from now for squiggle conf, which I am on staff for. if you would like to maybe speak at a conference. It's a great conference. I love it. It's organized by a, you know, a good buddy of mine. Yeah, definitely check that out. [02:37]
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-**Carl:** And of our sponsor read, we are sponsored solely right now by Infinite Red, which is an expert React native consultancy that's been around since 2015. [02:46]
-
-They're our only sponsor, partly because very few companies do as much as they do for the whole React and React native ecosystem. They host podcasts. They run conferences, they sponsor all sorts of different organizations generally just seem like really great people. They're a team of about 30 people, mostly developers, mostly with more than 10 years of experience. [03:06]
-
-And they will work with your team to help you develop react native expertise rather than just doing contract engineering and then saying, here you go, this is your problem now. So if your company is looking to start working on a React Native app in the near future, definitely reach out to them and give them a shout. Yeah. Cheers. [03:24]
-
-## New releases
-
-**Carl:** Okay, running through some new releases. [03:27]
-
-## [Anime.js v4](https://animejs.com/)
-
-**Carl:** This is only tangentially react related, but anime js a animation library, or they describe it as an animation engine. Just had a V four release and the website is super slick. Definitely a phenomenal advertisement for what you can do with the tool. [03:46]
-
-Very impressive. And animations are always, I don't know, doing high level animations with like a bunch, you know, interactive and different layers, and it, it's always complicated. So this looks like a pretty great tool. So wanted to give it a shout out. Yeah. Mo, can you tell us a bit about the latest React native. [04:03]
-
-## [RN v79](https://reactnative.dev/blog/2025/04/08/react-native-0.79)
-
-**Mo:** react native version 0.79 has been released. There's. Sort of some small changes here. The big one is that the JavaScript engine, JSC that previously used to be the default is now actually being removed completely from react Native Core and being moved to a community package and is effectively really being deprecated. [04:21]
-
-The few other changes some improvements to performance with Android, but all in all, as we'll see, and as we've seen in the past few months with React native releases, they're getting slimmer and a lot more frequent. So this whole idea of sort of continuously releasing React Native rather than having a few Big Bang releases, so good to see that it's chugging along. [04:40]
-
-**Carl:** Yeah. Very cool. I saw this is their third release this year, whereas in the past , they've generally done like three releases in any given year, [04:48]
-
-**Mo:** I think the trend is going towards doing a release every two months or so. [04:52]
-
-**Mark:** That's a pretty solid cadence. [04:54]
-
-**Mo:** Yeah. I think they've really taken a lot of steps over the last two years to try to bring down that release time and it's starting to pay off. [05:00]
-
-## [Next.js 15.3](https://nextjs.org/blog/next-15-3)
-
-**Mark:** Next 15.3 is out. Biggest news for this one is they now have alpha level support for using the turbo pack bundler for production builds. Previously, it had only been available for dev mode. So it looks like there's alpha level version for that. they have it passing most of their tests, but it's apparently not ready yet. [05:20]
-
-## [Rspack joins the Next.js ecosystem](https://rspack.dev/blog/rspack-next-partner)
-
-**Mark:** Also 15.3 now has support for optional using the third party RS Pac Bundler. I. For builts RS Ppac is a rust based re-implementation of Webpac and basic compatible with web pack's configs. So given that the existing version of Next still uses Webpac under the hood, the next and web and RS Ppac teams were able to collaborate and figure out how to get a plugin that would essentially allow it to use RsPack instead of Webpack as one possible alternative way to try to speed things up. [05:55]
-
-**Carl:** Yeah, I did see that the performance improvement from using RsPack and Next is like not that great and like in some circumstances could actually be worse than Webpac, which seems confusing to me. [06:07]
-
-**Mark:** some of it was due to things like JS based plugins and, and some of the, the interrupt back and forth between. Uhland and JS land. [06:16]
-
-**Carl:** Right. I mean, hey, similar problem is how React Native had with the, parsing data back and forth. kind of goes to show you how even once you have a tool that is written in native, it's, you know, it's not a silver bullet. It doesn't fix all the problems. [06:29]
-
-## [React Aria April 11th](https://react-spectrum.adobe.com/releases/2025-04-11.html)
-
-**Carl:** Yeah, react Aria by Adobe had a release. [06:32]
-
-They don't, I guess they don't do versions, they do just date releases. So this is the April 11th release. One thing that caught my eye that I thought was pretty interesting, so they have a calendar tool and they now allow custom calendar support. So it lets you implement your own like calendar schedule in re rendering this calendar thing, which, you know, they, they shout it out, for instance, using a 4 5, 4 fiscal calendar, which I had to Google because I'd never heard of it. [07:01]
-
-So this seems like a very, like, deep in the weeds kind of feature edition for, I don't know that that goes to show how seriously they are exploring the problem space. And I, I take that as a pretty positive sign. [07:13]
-
-## [Redux Toolkit 2.7](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.7.0)
-
-**Mark:** Last week I shipped Redux Toolkit 2.7 as I was on my flight to React Miami. [07:18]
-
-the main feature outta this is that RTK query now supports use of standard schema definitions for both validating requests and responses and errors, as well as potentially inferring the TypeScript types for those errors so that you don't have to hand rate those when you're defining the endpoints. As well as a bunch of other, other bug fixes and improvements. [07:41]
-
-**Carl:** That's super cool. I love generated types. [07:44]
-
-## [Vitest 3.1](https://github.com/vitest-dev/vitest/releases/tag/v3.1.0)
-
-**Mark:** And then Vitest 3.1 is out. Doesn't look like there's a, a huge standout feature, but a, a bunch of, again, small fixes and performance improvements, obligatory. [07:55]
-
-## Main Content
-
-**Carl:** Yeah, into our main content. [07:57]
-
-## [React Labs: View Transitions, Activity, and more](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more)
-
-**Carl:** So conveniently, like 35 minutes ago, the core team put out a new blog post a new React Labs post. React Labs are posts where they write about projects in active research and development. So this is like, definitely, this is like, you know, leading edge. What is the core team working on? [08:14]
-
-They do like what, maybe two of these a year? [08:18]
-
-a solid year since the actual React Labs post. They did have like the, the React 19 release announcements in that since then, I. [08:24]
-
-**Carl:** dated React Labs, March, 2023, react Labs, February, 2024, and now April, 2025. [08:31]
-
-**Mark:** So the headline out of this one is that they have been working over the last few in couple months on official support for the browser view transitions. API now. Going backwards. A lot of folks have asked over the years for some kind of official animation support in React itself. I know that people have compared, versus something like Svelte, which has apparently has the ability to declare some animations directly in your templates. And they've pointed at React and said like, why can't I do the same thing? Or like, you know, animating elements in and out is, is really, really difficult. And there's been lots of, you know, different animation libraries for React over the years, react Transition Group, react Spring, et cetera. But this is the first time we've ever had anything related to animations baked into the React core itself. Now as usual, I'm not actively ready in a lot of React myself these days. And when I have, I've never done anything animation related, so I'll be honest. I still don't even fully know what a view transition actually is, but I see a lot of people really, really excited about it. My, my vague understanding is that it's taking elements that are within the page and being able to move them back and forth. [09:46]
-
-**Carl:** As far as I know, it's largely about like page transitions, like when you navigate it will let you emulate like the kind of a native style of like, oh, this new, you know, new pane slides in over top [09:57]
-
-**Mo:** I mean, there, there's a few different types of transitions. There's like a fade transition that's native sort of there. But there's also the, the one that you're referring to, I think Carl, is the shared element transition, which is you have one element that exists on the first page and then the second, that element kind of persists, changes shape. [10:13]
-
-So the best example of that is like Instagram when you open up a a post and it kind of expands to take up the whole screen. That's what we call shared element transition in the mobile world. [10:22]
-
-**Mark:** Yeah, that, that makes sense. And I can definitely see how something like that would be difficult to do in React, where, you know, normally you stop rendering A and you start rendering B. [10:32]
-
-So the React team has been working on an official actual view transition component which has a number of different. Pieces of functionality, being able to, to label the transitions animate navigations, do some customization of these behaviors. the blog post goes into some examples of what these different capabilities are and how you would actually try to use them in practice. So it is still experimental. You have to specifically switch over from a production stable build of react to using the latest experimental channel release. But it's gotten to the point where they think it's actually ready for folks to try out. [11:09]
-
-on a similar note the React team has been working on and off for the last three or four years on a component that they originally called off screen. And the idea for this is that, as we all know, when you unmount a React component, everything about that component goes away. The effects are cleaned up. [11:27]
-
-The state that was unique to that component instance goes away, and that's made some things like, you know, building tabbed UIs difficult because you either have to do some work to hide the other tab contents, you know, maybe using like display none in CSS. But, and or you actually have to unmount them. [11:49]
-
-But in that case, state that was there goes away. And so the intent of this offscreen component. Was that you could wrap it around a section of your UI and you could tell React to toggle the display, but it would keep those components around and preserve their state. And then when you make it visible again, everything's still there. So they have since renamed this to be called the activity component. And they've also, and so now that is all at a point where it's officially ready for trial in an experimental form as well. And I think this is actually gonna be kind of a big deal. , we've actually used the predecessor offscreen component in replays UI for a while, which is why we're stuck on an old experimental build of react. And it, it really does prove pretty useful. [12:37]
-
-**Carl:** this like scratch an itch in the back of my brain because it, I, remember talking about this previously, so I was just googling like the, you know, offscreen and oh my God, like they've, they've been talking about this in both of the last two labs posts that we just mentioned. [12:50]
-
-So like, you know, they've got a tab called offscreen Rendering in 2023. "Offscreen rendering is an upcoming capability and react for rendering screens in the background." Like, okay. Alright. So they've been looking at this for over two years, I guess. It does seem really useful. Like I have definitely used every trick in the book to make things, you know, deprioritized. But yeah, I'm a little surprised to see that this is still in progress [13:16]
-
-**Mark:** The other two interesting bits out of the blog post about this, and they were not things that I, I had thought about in relation to this component. Another use for this is that if you start off with the activity labeled as Hidden, React will pre-render that content even before it's been displayed at all. But using concurrent capabilities, it'll be done in the background. So this can be useful for, you know, maybe you have like a more expensive piece of the UI that you know will be shown eventually, but maybe it doesn't need to be part of the initial render. And then that also ties into SSR capabilities as well. [13:54]
-
-And based on the initial value, react might like, include it in the content and then hydrate it later, or, do it in the background. And they also mentioned the possibility of adding some additional modes to this. Right now, currently it's, it's an nu that is just hidden or visible and they may actually have some other alternative behaviors down the road as well, which is why it's not a bullion. [14:16]
-
-**Carl:** Yep. Love flags rather than Boolean. That's great. Yeah. Interesting. I guess. I guess I'll keep an eye on it, but like, man, I guess I've been keeping an eye on it for two and a half years now. [14:24]
-
-**Mark:** The post covers a few other things. There's some performance tracking stuff they're working on. They are talking about trying to have the compiler automatically insert dependencies into use effect dependency arrays. there was one phrase in there in the post that I thought was kind of understandable, but also slightly oddly phrased. They, they gave a classic example of like a, a chat room connection in a use effect. they had a sentence to the effect that " Some hooks can be hard to think of in function instead of life cycles, developers get confused," da da da. " We think one of the reasons for the confusion is that developers think of effects from the components perspective, like a life cycle instead of the effects point of view, what the effect does." [15:10]
-
-And it basically what that's trying to say is. You know, the, the entire Rack React community looked at the use effect hook when it came out and we said, ah, this is the replacement for component. Did Mount and Component did update from class components to the point that, you know, often people even even create their own abstractions with those names. [15:28]
-
-I. And the React team has been valiantly trained to get us to stop thinking in those terms for years. And so I think this paragraph is basically saying, we've been trying to convince people not to think this way and failed. But it also like, it's, phrased slightly, like they're almost surprised. [15:45]
-
-People still think of it that way. [15:47]
-
-**Carl:** Yeah. it feels like a documentation problem. I feel like so many people are learning, react from a mishmash of strange places that they're learning, not what the core team would like. And you fix that by writing really good docs. [16:00]
-
-**Mark:** So anyway, the ul ultimately they're trying to work towards making the compiler be able to insert all those dependencies for you, and then maybe someday we get to stop thinking about this entirely. [16:08]
-
-They are also working on an early version of a compiler ex or extension for IDs, which has the potential to act as maybe like a super winter or show you what the transformed component might look like or even like what dependencies it would insert into use effect array automatically. [16:29]
-
-A couple other tidbits. And then one, the last item is very short, but as a library maintainer, it caught my eye. We all know that React has component-based state and that this has the strength that it's isolated to that component and the portion of the component tree, it has the weakness that you can't easily share it across different portions of the component tree. And we also know that Reacts concurrent behavior really only works with state that React owns, which is why external libraries like Redux and Zustand rely on the used sync external store hook, which works, but also kind of forces react to give up on doing things like transitions in the most optimized way. [17:13]
-
-So they've talked on and off for years about what if we were to add some sort of like a reusable store primitive to react. there's discussions about this going back to like 2015 and the blog post hasn't mentioned that they are working on something called concurrent stores. And it gives sort of a one line example that you would pass this to the use hook, and it does say, our goal is to allow external state to be read during render without caring and to work seamlessly with all the concurrent features that React offers. There's no further details. It's something they're just starting to think about. But it sounds like maybe down the road, react-redux and Zustand could use this and still work the same way, but better without the limitations. I don't know. I'm interested. I. [18:05]
-
-**Carl:** Right. I've never used used sync external store, partly because of the warnings they gave of like, this is gonna break stuff. So yeah. That's interesting. That's cool. [18:12]
-
-I'll also shout out, they mentioned, two other things very tangentially, like, we are looking at this, or we intend to look at this. [18:21]
-
-I'm curious about fragment refs. So like, you know, if you want to get a reference to the underlying dom node and react, you can do that with a ref. And you can use fragments to group elements, as a single top level rendered item rather than like wrapping it in a diviv or something like that. [18:35]
-
-But you cannot grab a reference to that group of nodes. But now they're looking, they "intend to research" refs on node groups like that, which is definitely interesting. I could see that being valuable in something like rendering a table or a list of something else. [18:55]
-
-Like especially if you're trying to do drag and drop kind of things. I could understand why being able to access a reference to a list of rendered nodes might be useful. But yeah, so I, I'm, I'm curious about that, but also given how long we've waited for some of these other things that are being researched with maybe clearer use cases, I will not be holding my breath on that. [19:17]
-
-**Mark:** will say that I've, I've watched them put up and merge several prs that are input, are trying to implement fragment refs. So it's, it's definitely not just a theoretical research project. They're actively trained to work out the implementation deals and details. At the moment, [19:33]
-
-**Carl:** That makes sense. Yeah. [19:34]
-
-Likewise for gesture animations gestures are generally just like a pain in the butt. I have never found anything that worked super well for that. So they say we're researching ways to enhance new transitions to support gesture animations, such as swiping to open a menu or scroll through a photo carousel. [19:50]
-
-That's cool. I will be excited to see if they get something working there. Just 'cause gestures are always annoying and part of why they're annoying is because it's such a, I don't know, they're just very far from like the rendering model. The way you have to think about gestures is very far from the way that React asks you to think about rendering a tree of components with like, self-contained state. It's just like fundamentally outside of a component. It's at the level of the browser, the device. [20:17]
-
-So, figuring out a way to, I don't know, reduce the distance between those is definitely interesting and sounds valuable and useful. But they also say for now we're focused on shipping view transition and we'll revisit gestures afterwards. So this definitely sounds a little bit more like intent to explore than active exploration. [20:34]
-
-They say they, they also say, we believe we found an approach that works well and may introduce a new API. So cool. They've done some research, they've got an idea, but it's not their immediate focus right now. [20:44]
-
-**Mark:** the other sort of big picture thing that I took away from this post. So there's been a lot of. Complaints and concerns from the community over the last couple years that the React team kind of stopped caring about the client side. That, you know, all their effort was going into building server components and pushing people towards frameworks and all this other stuff, which I. There's definitely been a push. The React team has noted that part of it is just how much, how hard everyone went in on single page apps over the last several years, and so there, there has been a swing back towards server-side rendering and ess, but even like React 19 had a bunch of client-centric features for, for forms and whatnot. it is interesting that basically all the things that they've got in this blog post are client side pieces, you know, view transitions, activities compiler stuff. Sort of there is a real focus on stuff that works on the client and adding like fairly meaningful core level functionality to the library itself. And so I think this actually kinda counterbalances some of the concerns people had that, you know, they were focusing on the server too much as well as noting that, okay, like, okay, now that the big React 19 push is done, now they've got some room to actually pick up with some of the features that they were trying to work on. [22:04]
-
-## [React 19.1](https://github.com/facebook/react/releases/tag/v19.1.0)
-
-**Carl:** Let's move on to React 19.1. [22:07]
-
-literally the headline in the post itself is the owner stack. They're introducing development mode only stack trace to help identify what components are rendering, which. And this really brought the, the whole concept of the owner staff back to mind for me. [22:23]
-
-Like this was something that I remember learning about and thinking about, thinking in terms of a lot in the first several years that I worked with React. And I think it's been slightly deprioritized in people's minds, like it's lost mind share. But it is super valuable for a ton of different things. [22:41]
-
-So surfacing it better in the developer tools and such I think will be really powerful. I wanted to bring in a couple of like, old, old, old posts that I remember reading and remember being, you know, instructive for me. [22:53]
-
-## [One React mistake that's slowing you down](https://www.epicreact.dev/one-react-mistake-thats-slowing-you-down)
-
-**Carl:** Kent C Dodds, put out a, you know, one react mistake that's slowing you down blog post a while back and it talks about like component composition and like how you structure the tree and it doesn't name owner stack. [23:07]
-
-I So it doesn't name the owner stack, but like really that's what it's talking about. It talks about like, you know, context and like prop drilling and how you can avoid it and why it's painful. And really what they're talking about, what Kent is talking about in this post is mindfully managing your owner stack. [23:23]
-
-Because the reason you have to prop drill is because the owner stack is weird and you need to go through intermediate components between data source and data usage. But if you restructure that owner stack so that you're, instead of passing a prop through one component so that it gets rendered in another component rendered by that component, you can just render children and then you don't need to pass the prop through. You just render them all at the same level. [23:52]
-
-Or, you know, you maybe not all at the same level, but you can collapse that you can make the tree broader and shallower. And prop drilling is like a developer experience, you know, convenience. It's nice to not have to remember, you know, if you think about it as like the length of a pipe, it makes the pipe a lot shorter and you, you know, there's fewer places for things to go wrong and you have to think about fewer twists and turns. [24:13]
-
-So like, that's great. But also a flatter, broader owner stack is just naturally good for performance because when you have a deep tree, something at the top re rendering will cause like everything to re-render underneath it. Whereas when you have it flatter and broader, then just you can re-render in smaller batches, like smaller units of components will be forced to re-render when things [24:39]
-
-**Mark:** I will caveat that one. [24:40]
-
-So rendering does work at the direct parent child level. So like if I have parent component, I. Inside of its own JSX, it renders a child of A, and then it inserts B as children inside of A. So like both the tag A and the tag B are inside of parent. There is still a three component level parent-child relationship tree. So root is the parent of of A, A is the parent of B. But the root is the owner of both A and B. [25:19]
-
-There's still three levels of components that have to get rendered, but it does flatten , the logic needed to generate those. And that's kind of like , the distinction that a lot of people haven't quite seen as they're learning. [25:31]
-
-**Carl:** Right, right. I guess let, yeah, maybe I'll, I'll revise that a little bit. So it's at that root level, if the root level component is re rendering, sure. All of the children still need to re-render, but the deeper the tree, the more parents that're in the loop there are. So this has been like moving components so that it's, the owner tree is flatter, has been like the number one, general approach I've done when there are performance problems in a code base, , which generally comes from, like, you can think in smaller units. I don't know. feel like I'm going deep in the weeds and not stating anything clearly. [26:07]
-
-**Mark:** generally speaking Composition is a good thing that more developers would benefit from taking advantage of. [26:12]
-
-## [Advanced React Component Patterns](https://kentcdodds.com/blog/advanced-react-component-patterns)
-
-**Carl:** Yeah. Another, old, old old post that I'll just shout out. Uh, again had a phenomenal post from 2017 talking about advanced react component patterns and like, okay, some of these are no longer like super duper relevant anymore, like higher aortic components. [26:27]
-
-Like, hmm, probably just use a hook. But these types back in this era of blogging about React stuff like owner stack was a little bit more, closer to the surface, it was still not on the surface. People are not referencing the owner stack. But yeah, just like when. I feel like owner stack is secretly the other option when people are talking about like prop drilling versus context like, well also what if you just restructured it so it's simpler? [26:52]
-
-**Mark:** Yep. [26:52]
-
-**Carl:** Anyway, super cool to see it surfaced. [26:54]
-
-## [Improvements in Expo using owner stack](https://github.com/expo/expo/pull/35866)
-
-**Mo:** one of the things that this owner stack, change is actually powering is some updates to the expo CLI for when you run your app in dev mode because one of the challenges in the React native world is that you get these massive log, massive log spans. [27:10]
-
-The stack trace is not at all discernible because it's kind of interacting in between the native world and, and the react world. but with this, the expo team actually ran a p and I think it's been actually merged now into hopefully the next release of, of Expo where they're actually showing you where in the react tree, the, the, the specific component is being rendered. [27:31]
-
-So it makes discerning some of these error messages a lot simpler. So I think we'll start to see some, maybe some improvements on like the framework level as a result of this. [27:41]
-
-**Carl:** Okay. That's all we got for React 19.1. Really. I don't know. There's just, there's not that much in 19.1. [27:48]
-
-## Dan Abramov is writing again
-
-**Carl:** This is kind of small, this is maybe just like commenting on the ecosystem, but Dan Abramov is writing again, and That's nice. He was writing a lot. I don't know how many hours of text do you think he's written, mark? [28:00]
-
-**Mark:** Many, many hours. Like I, I read fairly fast and there, there is a lot of content there. [28:06]
-
-**Carl:** One of the newsletters I subscribed to that shared this out you know, does share estimated reading time. And it was, you know, one of the posts was estimated reading time of an hour. And like, that's just if you're scanning your eyes over the words, I think, not trying to digest and understand it, but like broadly what he's writing about is server components. [28:25]
-
-**Mark:** Dan is fascinated with server components at like a technical concept, architectural. Where did this come from? How did we get here? What does this, how is this similar to old approaches? How is this different? What does it enable that you couldn't do before, kind of a level. [28:47]
-
-And he's, not even officially on the React team anymore. Like, think of him as like a, private citizen expressing his own opinions at this point. But the different posts are going through different aspects of. Server components from like a, very conceptual level and trained to explain from first principles, how did we get here? [29:09]
-
-## [React for Two Computers](https://overreacted.io/react-for-two-computers/) (Complement to [his React Conf talk](https://www.youtube.com/watch?v=ozI4V_29fj4))
-
-**Mark:** So like react for two computers is taking some of the concepts of, well, we have code that runs on the client and code that runs the server. How do we sort of figure out how to intermingle those? How can we shift pieces of that code back and forth and still have all this work together? [29:26]
-
-## [JSX Over The Wire](https://overreacted.io/jsx-over-the-wire/)
-
-**Mark:** JSX over the wire, I believe looks at, you know, if we, like we started with rest APIs, but rest APIs often end up growing special cases to handle data that the UI needs. And there's precedent for server driven UIs where you specify, here's a list of components in a JSON format. And then you know, the. All your different UI layers, you know, mobile, web, whatever, can just, you know, figure out on the fly what components you're talking about and render those and that RSCs take that sort of idea form a backend for front end pattern, but it's one that has more flexibility. And being able to send the list of components to render over the wire in a rather dynamic way. [30:11]
-
-## [Impossible Components](https://overreacted.io/impossible-components/)
-
-**Mark:** I always skimmed the most recent one, impossible components, but it's, it's kind of expanding on some of this, like where can the logic live? What are some of the capabilities of things you could do, like having a server component read blog files off disk and estimate the reading time rather than like having to insert them into a database somewhere. So. The first couple were very, very abstract and you know, that was a complaint that a lot of people had. the last one was more concrete. He's also kind of trying to be careful to, I. Explain concepts without literally invoking the word react server component. So like think through the mindset without getting caught up in the trap of, well, this is like a thing I can only use with next, or whatever other complaints people have, [31:00]
-
-**Carl:** funny, I just saw a meme that was like, name something that you can describe and people will agree with until you call it what it is called, and I was like, server components. [31:08]
-
-**Mark:** Yeah. So. I've seen a number of reactions. You know, some folks are just saying like, look, Dan, your blog posts are too long. They need a table of content, or at least a, a summary upfront of what is the point I'm trying to make here? And Dan's like, that's not the way I write, and I'm sort of ready for myself at this point, which I totally get and good for him. I've, I've seen a number of comments where people have said like, well, I followed the train of thought and now I'm actually sort of getting. What the point of server components are, and I've seen a couple other folks say that like, you know, if, it's taking this much explanation to try to convince me of what server components do, maybe the React team really needs to like come up with like a 500 word summary, which are, which are all I think, are all very valid reactions. But it's , Dan loves explaining things from first principles. he's a very like, logical, think it through. Why does this exist kind of a person. On a personal level, I'm just very happy that he's gotten past his writer's block and feels good about writing the stuff he wants to say, the way he wants to say it. And also, there is some value in reading through these to try to understand like, what is the point of all this? [32:12]
-
-**Carl:** And like at the end of the day, this is not, I think the, I think " feature in a JavaScript tool" is the wrong mental model for thinking about server components. I really do think that they are exploring a new. Compute paradigm, like it's a blending of the client server modes and they're constrained by, you know, technical aspects, everything in JavaScript in the browser is based around like batch and requests, it's hardcore based around a client server model. And they're trying to blur those lines and they do not really have platform support for doing it. So they are, you know, that's where things like the "use client" / "use server" directives, I think like they're kind of a hack fix because they don't have better primitives in the language, in the runtime to work with. [33:02]
-
-to me, yes, it's taking a lot of words to explain this and to explore it and to try and make it digestible and comprehendible, but it was also really hard to convince people that like, like I, you know, I, I remember early in my career there were a lot of words written about like pets versus livestock servers because like, you should be able to like, kill and restart any server and it shouldn't cause a problem and that's a livestock server, rather than one that you like very gently take care of and, you know, evolve over, over time and love and dote on. [33:34]
-
-And similarly when serverless became more of a thing, like these are different models for thinking about how your code executes and they're complicated and they're hard and I feel like this is cutting edge in so many different ways and so many, I dunno, I, I appreciate Dan really occupying this space at the bleeding edge, especially now that he's not, you know, professionally obligated to as a member of the core team. [33:59]
-
-**Mark:** last thought real fast. when the new React Docs came out, there was nothing in there about server components, and for a while the only official docs about server components were over in the next framework documentation that Vercel's devrel team had written, I still thought there was absolutely nothing in the React docs all, about server components until about a week and a half ago. [34:21]
-
-When I made that statement, after searching to try to confirm that there were nothing, and I missed that, there had been a page added about server components to the docs about a year ago, and I flat out missed that it existed. Having said that I do feel that the React docs would really benefit from having a much more concrete set of pages that describe server components. Ideally I would like to see an intro page, an overview, and in fact, there was actually a Versel blog post about server components that I think should just be literally copy pasted into the official React docs as the intro. I'd like to see kinda like a modest technical explanation. Like what are they architecturally, where do they fit in? [35:02]
-
-What does running a server component output? Maybe some kind of an FAQ because there's an awful lot of questions people still have about them, including some pretty stupid ones. And then maybe even like some kind of like a adoption or migration page. Like I would like to start using them. [35:17]
-
-I feel like having those pages would, it wouldn't solve all people's complaints, but it, it would at least centralize and make some of the information more official to reference. [35:28]
-
-## [don’t 👏 ruin 👏 his 👏 process](https://bsky.app/profile/danabra.mov/post/3lmi3gpiluk2m)
-
-**Carl:** Last thing I'll say on the subject of Dan writing again about server components. he posted on blue sky. "I kind of wanna write a dozen more posts about react server components. But I also feel like it's inviting endless takes about Dan trying to explain RSC means RSC is bad and it kind of ruins some of the process for me." [35:44]
-
-So don't ruin the process. [35:45]
-
-**Mark:** Be nice Dan, please. [35:47]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Okay. Lightning round. [35:48]
-
-## [Next.js RFC: Deployment Adapters API](https://github.com/vercel/next.js/discussions/77740)
-
-**Carl:** There is an RFC from next to do deployment adapters which is pretty cool. Like one of the big endless complaints about next is how hard it is to run anywhere other than versal. So they are meaningfully exploring what it would take to make that easier. [36:09]
-
-Yeah, it was post put up three weeks ago. I, I haven't seen a ton of like movement yet on what exactly that means, but yeah, it's seems cool here for it. Interested. Very excited to see what comes out of that. [36:23]
-
-## flightcontrol.dev from last year: [Secret knowledge to self-host Next.js](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)
-
-**Carl:** And I also wanted to shout out a blog post from October of last year from Brandon Bayer of Flight Control, secret Knowledge to Self-Host Next js. [36:33]
-
-So that seems like a relevant read in, in conjunction with this new deployment adapters. [36:38]
-
-## [Styled-Components in maintenance mode](https://opencollective.com/styled-components/updates/thank-you)
-
-**Mark:** I don't think we mentioned this last month. the style components CSS and JS library has announced that it is officially going into maintenance mode. Part of this is the amount of work needed to do it, and part of it is the shifts in the ecosystem such as relying on context when server components don't support context on the client. So that's both A FYI. This library is going into maintenance mode and also like more evidence that CSS and JS is sort of both falling out of favor and kind of being discouraged by technical changes in React itself. [37:15]
-
-## [RIP Styled-Components. Now What?](https://fadamakis.com/rip-styled-components-now-what-a8717df86e86)
-
-**Mo:** One sort of interesting like experience from my side on this specific thing was we actually migrated on a project of mine that was on the web that was using Next js. They went into the app router and tried to embrace all things server components and part of that process was they had a styled component library, like a shared component library that they had internally, which was all in components and, immediately they hit a brick wall and they had like 80 plus components that were all styled components and they couldn't use any of that there. So to throw in a little bit of AI magic what we actually did was created a custom prompt in like two hours that took styled components and converted it into their choice SaaS modules. [37:54]
-
-Which is going back to basics, but you know, a good technology choice nonetheless, if you want zero js runtime styles. And it worked shockingly well. So if you give it a good set of rules and you define the problem and you give it a nice workflow to follow, as if it was a developer did a shockingly good job, it reduced like the time for each component from like two hours to 15 minutes, 10, 15 minutes with a review process, like manually looking through the code it would generate. [38:22]
-
-So if you're stuck in style components world and need a little bit of help, try to use gen AI and the reasoning models shockingly worked very well because. With CSS, things cascade and it needs to have an internal representation of how styles cascade down. So your four OS in chat, GPT wouldn't work very well, but your O ones and O threes would work quite well. bit of a weird guideline, but it was quite a fun experience and I think it's a good use case for it. Trying to play around with gen ai. [38:48]
-
-**Mark:** I would not have thought about that. [38:50]
-
-## [Redwood announces new Cloudflare-based RSC SDK](https://redwoodjs.com/), existing framework in community maintenance mode
-
-**Carl:** Redwood has announced that they are now doing a CloudFlare based react server components, SDK. So like they used to be more of a framework and now they're like, it's kind of a reduced scope. I don't know. This connects back to, part of the headline of our January episode was "RedwoodJS, dead?" [39:12]
-
-We caught word that like some other person who had been involved in the project early but hadn't been involved recently, came back out outta the woodwork and basically what Redwood JS has been for the last, I don't know, two years, it is not anymore and it is now something else. That's, strange. [39:31]
-
-the SDK looks neat. I haven't played with it yet. I had been pretty interested in Redwood js because I thought they were trying to be like a Laravel for JavaScript and React Universe, and I thought that was cool. Something that is more narrowly like about doing the rendering is a lot less interesting to me. [39:48]
-
-For me, the value of a framework like that is more like, when they were trying to be the Laravel of reactive, I was excited because I would love somebody to make things like authentication and toast messages and all those kinds of things. Easier to do, easier to build a product rather than, I dunno, a rendering model. So this is now kind of going back into rendering model. [40:13]
-
-So it, it seems like an interesting, worthwhile exploration, but it's not what got me excited about Redwood in the first place. [40:18]
-
-## TC39 kills [Records and Tuples proposal](https://github.com/tc39/proposal-record-tuple/issues/394). Possible alternative is [“Composites”](https://github.com/tc39/proposal-composites)
-
-**Mark:** Yep. Meanwhile in, not directly react, but very related news, the TC 39 JavaScript Specification Committee has officially killed the records and two polls proposal. This was intended to add. Deeply comparable immutable objects directly into the JavaScript language, both in terms of runtime and specific syntax for declaring them. The idea was this would sort of like replace all your.dot object spreads and be able to have two objects and deeply compare them with the triple equals sign. [40:53]
-
-And apparently there was pushback from JavaScript engine, you know, developers who were concerned about the impacts this would have on like internal performance. So that proposal's dead. There is a new proposal called composites, which is sort of lighter weight, like it looks like you would construct objects use, like using like a new composite class that could then have like a composite equals comparison, possibly. So sort of the same direction, but like less deeply embedded in the language itself. So I know a lot of folks had a lot of interest in records and tuples, and we're hoping that one would really come to pass and it didn't happen. [41:36]
-
-## [React Compiler RC](https://react.dev/blog/2025/04/21/react-compiler-rc)
-
-**Mark:** React Compiler just came out, it was in beta and they've now gone rc. so number one, they, you know, they think it's, it's pretty good. It's almost ready. Number two, they've rearranged some of the lint rules previously. The React. The React compiler lint rules were in their own package, and I believe they're moving them into the existing rules of Hooks package. then they, they also announced experimental support for integrating the compiler with the SWC build tool, which is, you know, conveniently what's actually used by next. the compiler is primarily exposed as a babble plugin, even though the, all the implementation is not babble specific. they've found a way to integrate it into SWC, even if it's maybe not the most optimized way and are continuing to work on, you know, different approaches for configuring it as well. [42:27]
-
-So it's getting fairly close. [42:29]
-
-## ["Just use Vite”… with the Workers runtime](https://blog.cloudflare.com/introducing-the-cloudflare-vite-plugin/) (Vite on Cloudflare)
-
-**Carl:** Nice. Yeah, CloudFlare has announced better support for Vite with the Workers' runtime while also throwing a little bit of shade, I think, at the React ecosystem by titling it quote, just use Vite dot dot dot, with the workers' runtime. I don't know. It just feels like they're throwing a little bit of shade out there. [42:47]
-
-it looks pretty neat. I would like to play with this a little bit more, like yeah, they say "we're announcing release of the CloudFlare v plugin as well as official support for the React Router v7." So that's cool. I am currently running a React router v7 app. [43:01]
-
-That would be interesting to connect to CloudFlare in that way. I guess like the big distinction here is that previously I. They say, "the V dev server would always run your server code in node js, even if you were deploying the CloudFlare workers." in local development. Previously if you were using workers it would just run in node and that's not the same. [43:21]
-
-There are node APIs that are not available in the workers' time. So now taking advantage of the environment, API that we talked about a couple of months ago they are able to run your local development workers in an identical environment to what they will have in production. So that's cool. [43:40]
-
-Definitely very neat. And I generally, I think workers are super cool and just like an interesting programming paradigm. Like talk about, you know, exploring new paradigms for executing code workers are the most exciting other than server components [43:54]
-
-**Mark:** Last month we announced one of the major pieces of news was a vulnerability in Next's middleware implementation that could potentially have author related concerns. And there was a, you know, a major CVE vulnerability announced around that. This month it was react routers turn something was announced to have to do with some of the the path parsing definitions. [44:12]
-
-There are fixes out for both React Rider and remix. Please upgrade appropriately. [44:17]
-
-**Carl:** Yeah, this one looks a lot less major than the next one, but yeah, they did get a CVE. [44:21]
-
-## [Silk Library - native-like swipeables for the web](https://silkhq.co/)
-
-**Mo:** So next up, I just a library that I saw floating about in the, blue Sky and Twitterverse. Silk is a pretty cool library that takes in sort of these like native swipeable sheets that you're used to in the native world and brings it to the web in a React library. [44:37]
-
-So, you know, native feeling sidebars or bottom sheets or sort of like a, a, expandable bottom sheet for things like media players and stuff like that. All of that is quite difficult to do in the web world but very easy to do in the native world. And so they've created a React library and it works delightfully, like, it's very hard to tell that it's not native, which is really, really cool. [44:58]
-
-The. I guess the, the caveat is that it's not open source for anything that's commercial. So any like hobby projects that you're using or open source projects that you're using, it's free. But you need to pay around 300 euros if you want to use it in any commercial projects [45:17]
-
-**Carl:** reminds me of like sublime text, sublime merge, like the, the shareware. Please, please pay us. [45:22]
-
-## [\{transitions\} = f(state)](https://jordaneldredge.com/blog/transitions-f-of-state/)
-
-**Mark:** Jordan Eldridge, who is possibly best known for having created the React reimplementation of the Winamp music player from the good old days. wrote a post a month or two ago about transitions, RA function of state. it's not talking about the new React transitions, API, but rather kinda that mindset of viewing the contents and the logic of your component as state machines. It's kinda short, but some good thoughts there that are useful to put into practice. [45:51]
-
-## Tailwind 4, Bun, and old Macs: [A Supermarket Bag And a Truckload Of FOMO](https://blog.julik.nl/2025/03/a-little-adventure-in-modern-frontend)
-
-**Mark:** And then tossing out one more There was a very interesting article from someone who is trying to switch from using Tailwind three to Tailwind four. [45:58]
-
-I. But they were doing it on an old Mac, and as usual, I haven't used Tailwind, tailwind much myself, but apparently the latest version of Tailwind now uses a customized version of the BUN runtime to do its build steps. BUN is distributed as a native binary, and apparently the bun binary requires some of the latest CPU instructions. So it wouldn't even run on this Mac, even though it was a perfectly valid functional laptop. And so this person kind of got stuck, like, how can I even use Tailwind on this laptop when the latest version of tailwind's, compiler won't run on the laptop? And so it's well written, but also it's, just interesting to see how upgrades can cause problems sometimes. [46:47]
-
-## [Introducing Firebase Studio](https://firebase.blog/posts/2025/04/introducing-firebase-studio/)
-
-**Mo:** if you are somewhat following the world of Gen AI and the whirlwind of different tools and stuff that comes up every day some of them good, some of them not so good. There's been these sort of app builders that have been appearing, right? So things like V zero is the, is the big one that you'll probably be familiar with because of Sha Cian and, you know, the Versal ecosystem. [47:08]
-
-But you know, there's other ones like Repli lovable Dev Bolt and, and many, many more I'm sure. It's a problem that a lot of people are trying to solve, which is, you know, how can we enable non-technical people to build out apps or maybe accelerate developers to actually build them out in some sort of agent tech model. [47:25]
-
-And so, Firebase. the classic sort of toolkit that was there for mobile and front-end devs to be able to create backends without being real backend developers and needing to worry about things like infrastructure and whatnot, has thrown its hat into the ring and created Firebase studio. [47:41]
-
-So the whole idea with Firebase Studio is that it's it's kind of giving you the full stack. So, you know, Firebase already existed to help you build backends without really building backends. And so they're thinking of building on top of that. They've released this using sort of the Gemini models that Google has to allow you to also build the front end so you know, in one sort of prompt or set of prompts. [48:02]
-
-So you can generate a screen and then that goes all the way back and creates the sort of the backend for you as well in, in Firebase world, which is an interesting approach because they already have sort of a backend as a service. That people love and use quite often. And I, I still see it being used on a lot of sort of passion projects and even on some production applications. [48:22]
-
-One of the reasons I thought it was interesting to mention here was because if you look at some of the examples that they've released they don't actually, they have a lot of react examples and not as many angular examples, albeit you can use it to generate angular apps as well. And that makes me think that they're sort of coming around to this fact that it's, you know, there's a lot more react and next js open source code on the internet, which means gen AI is probably better at generating it than something like Angular. [48:49]
-
-But that's just a, that's just a take that I have and it's not grounded on any reality. So take that with a grain of salt. But that's my thought process as to why they're, showing a lot of react examples. Of course, they're showing flutter and some angular as well. So it's not like it's just react, but it's definitely interesting. [49:05]
-
-## [Gumroad is open source!](https://gumroad.gumroad.com/p/gumroad-is-now-open-source)
-
-**Carl:** maybe further afield from React and such, but Gumroad, for their 14th anniversary of being a product in the world is going open source. So they are, I guess, open sourcing their entire product which is cool. I like that. I'm confused about why, because like, you know, like fundamentally, usually people guard their source code if they're a like, functioning business that like makes revenue, you know, having the source code is a decent moat. [49:34]
-
-But yeah, it's cool. I, I like that. I like to see it. I love seeing real production code bases made open source because like, that's such a, that's such a common request that I see people asking for is like, okay, cool, I'm learning all of this, but how do I know if it's good, if it's real? [49:50]
-
-## [Automattic laid off 16% of staff](https://automattic.com/2025/04/02/restructuring-announcement/)
-
-**Carl:** And my last link also a little further afield, kind of at the intersection of our first job market section and our lightning rounds. But checking in on some of the WordPress drama that we had covered a couple months back; Automattic. The company that maintains WordPress and led by Matt of much drama, the last six months is laying off 16% of its staff. It's a little bit, this like restructuring announcement from earlier this month is a little bit goofy to me to read because it, it's, you know, it's just like why we're making changes. We've reached an important crossroads. While revenue continues to grow, we operate in a highly competitive market. It's like, well, yeah, and you also alienated your entire, like, product base and like open source ecosystem and customer base. [50:37]
-
-so just like seeing them talk about laying off one, one out of every six people who works there without talking about how, like, this was a total self own where the CEO just like burned every bridge he could find is like, alright buddy, good luck. [50:51]
-
-**Mo:** It's kind of poetic in some. [50:53]
-
-**Carl:** it would feel more like poetic justice if Matt was the one losing his job. [50:56]
-
-Not people unrelated, but Yes. Ugh. [50:59]
-
-**Mo:** But you know, I, I, I hope that other tech executives think twice and it becomes a learning lesson before they try to take open source products and monetize it in their favor when they have control over an ecosystem. I hope that people uh, think twice after this. [51:15]
-
-**Carl:** Yeah, right. I feel like this is gonna be some kind of business case study somewhere. So that's, you know, hopefully [51:20]
-
-**Mo:** I hope he also loses any bonuses that he was banking on getting this year [51:24]
-
-**Carl:** anyway, That's all we got for you this month. Thank you so much for joining us. We will be back on the last Wednesday of the month, next month here in the live stage or back in your podcast feed just as soon as we can. [51:34]
-
-We gather sources from this we in React Bites, dev React status, next JS Weekly, the React JS subreddit here in Reactiflux, and those direct from those publishing articles. If you see anything newsworthy, definitely let us know in the Tech News and reads channel here in Reactiflux or shoot me an email at hello@reactiveflux.com. [51:52]
-
-I read everything that comes in, so definitely send me something. This is a show that you value and would like to support. Best way to do so is by submitting a review. It would be cool if it was, you know, five stars, but whatever, any feedback is appreciated and definitely tell your friends and coworkers about it if you like. [52:09]
-
-Cool. Thank you so much. See you next month. [52:11]
-
-**Mo:** See you all next month.
diff --git a/src/transcripts/tmir-2025-05.md b/src/transcripts/tmir-2025-05.md
deleted file mode 100644
index 7afb0b8..0000000
--- a/src/transcripts/tmir-2025-05.md
+++ /dev/null
@@ -1,526 +0,0 @@
----
-title: "TMiR 2025-05: Dan explains RSC. Remix v3? React core team WIP?"
-date: 2025-05-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:54](#quick-hits)] Quick hits
- - [[00:57](#job-market-fred-data-layoffsfyi-trueupio)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
- - [[01:19](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:20](#react-summit-june-13-17-amsterdam-nl)] [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
- - [[01:57](#render-atl-june-11-13-atlanta-ga-usa)] [Render ATL](https://www.renderatl.com/) June 11-13 Atlanta, GA, USA
-- [[02:12](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
-- [[02:59](#new-releases)] New releases
- - [[03:01](#tanstackdb)] [TanStack/db](https://github.com/TanStack/db)
- - [[05:28](#legend-list-10-released)] [Legend List 1.0 released](https://bsky.app/profile/jayz.us/post/3lni5ofbuvs2s)
- - [[06:48](#redux-toolkit-v280-and-bugfixes-after)] [Redux Toolkit v2.8.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.8.0) (and bugfixes after)
- - [[07:37](#mui-v71)] [MUI v7.1](https://github.com/mui/material-ui/releases/tag/v7.1.0)
- - [[08:30](#jest-has-a-v30-beta3-4-out-first-alpha-of-it-was-published-october-2023)] Jest has a v30 [beta.3](https://github.com/jestjs/jest/releases/tag/v30.0.0-beta.3) \+ 4 out. [First alpha](https://github.com/jestjs/jest/releases/tag/v30.0.0-alpha.1) of it was published October 2023
- - [[09:11](#zustand-505-jotai-2124-and-5)] [Zustand 5.0.5](https://github.com/pmndrs/zustand/releases), [Jotai 2.12.4 and .5](https://github.com/pmndrs/jotai/releases)
- - [[09:17](#devstore-deprecated)] [devstore deprecated](https://x.com/jotaijs/status/1919778234037878919)
- - [[09:28](#radix-has-new-primitives-onetimepasswordfield-and-passwordtogglefield)] [Radix](https://www.radix-ui.com/primitives/docs/overview/releases) has new primitives: [OneTimePasswordField](https://www.radix-ui.com/primitives/docs/components/one-time-password-field) and [PasswordToggleField](https://www.radix-ui.com/primitives/docs/components/password-toggle-field)
- - [[09:38](#ant-design-525)] [Ant Design 5.25](https://ant.design/changelog#5250)
- - [[10:02](#react-aria-may-19-2025-release)] [React Aria May 19, 2025 release](https://react-spectrum.adobe.com/releases/2025-05-19.html)
- - [[10:21](#relay-19-with-react-19-support)] [Relay 19](https://github.com/facebook/relay/releases/tag/v19.0.0) with React 19 support
- - [[10:29](#storybook-9)] [Storybook 9](https://github.com/storybookjs/storybook/releases/tag/v9.0.0)
-- [[10:38](#main-content)] Main Content
- - [[10:45](#expo-sdk-53-release)] [Expo SDK 53 release](https://expo.dev/changelog/sdk-53)
- - [[16:01](#packagejson-imports-support)] [Package.json imports support](https://x.com/satya164/status/1916095938604548366)
- - [[17:32](#react-router-rsc-preview-and-other-rsc-topics)] [React Router RSC preview](https://remix.run/blog/rsc-preview) and other RSC topics:
- - [[20:49](#vite-community-pr-to-add-rsc-support)] [Vite community PR to add RSC support](https://github.com/facebook/react/pull/33152)
- - [[21:33](#leerobs-list-of-other-rsc-explorations)] [Leerob’s list of other RSC explorations](https://bsky.app/profile/leerob.com/post/3lo4l2rmy7k2b)
- - [[21:44](#more-dan-posts-like-static-as-a-server-and-one-roundtrip-per-navigation)] More Dan posts, like [Static as a Server](https://overreacted.io/static-as-a-server/) and [One Roundtrip Per Navigation](https://overreacted.io/one-roundtrip-per-navigation/)
- - [[22:33](#redwoodsdks-your-react-framework-feels-broken)] RedwoodSDK’s [“Your React Framework Feels Broken”](https://rwsdk.com/blog/your-react-meta-framework-feels-broken)
- - [[23:20](#remix-v3-announcement)] [Remix v3 announcement](https://remix.run/blog/wake-up-remix)
- - [[26:04](#discussion-between-evan-you-and-michael-jackson-about-bundling-hmr-approach-and-tradeoffs)] [Discussion between Evan You and Michael Jackson about bundling / HMR approach and tradeoffs](https://x.com/mjackson/status/1928297364726632499)
- - [[29:56](#react-core-wip)] React Core WIP
- - [[30:08](#react-mcp-server)] [React MCP server](https://github.com/facebook/react/tree/main/compiler/packages/react-mcp-server/src)
- - [[34:08](#concurrent-store-skeleton-pr-a-concurrent-compatible-integration-for-external-libraries)] [“Concurrent store” skeleton PR](https://github.com/facebook/react/pull/33215) a concurrent-compatible integration for external libraries
- - [[35:49](#suspenselist-being-worked-on-again)] [\ being worked on again](https://github.com/search?q=repo%3Afacebook%2Freact%20SuspenseList&type=pullrequests&s=created&o=desc)
- - [[36:29](#compiler-integrations-with-swc-and-oxc)] Compiler integrations with [SWC](https://github.com/swc-project/swc/pull/10475) and [OXC](https://github.com/oxc-project/oxc/issues/10048)
- - [[37:19](#apple-app-store-epic-games-saga-30-apple-cut-ruled-unlawful-in-the-us)] Apple App Store Epic Games Saga 30% [Apple cut ruled unlawful in the US](https://www.macrumors.com/2025/05/19/epic-asks-judge-apple-approve-fortnite-app-store/)
- - [[40:59](#next-reducing-vercel-mentions-in-docs)] [Next reducing Vercel mentions in docs](https://github.com/vercel/next.js/pull/78557)
-- [[45:52](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[45:54](#shared-element-transitions-in-reanimated)] [Shared Element Transitions in Reanimated](https://github.com/software-mansion/react-native-reanimated/pull/7466)
- - [[46:56](#v8-explicit-compiler-hints)] [V8 explicit compiler hints](https://v8.dev/blog/explicit-compile-hints)
- - [[48:05](#ts-native-previews-usable-build-of-the-go-based-compiler)] [TS Native Previews](https://devblogs.microsoft.com/typescript/announcing-typescript-native-previews/?s=33) (usable build of the Go-based compiler)
- - [[48:26](#vite-rolldown-preview-build)] [Vite \+ Rolldown preview build](https://voidzero.dev/posts/announcing-rolldown-vite)
- - [[49:10](#seeded-pseudo-random-number-proposal-advances-to-stage-2)] [Seeded pseudo-random number proposal advances to Stage 2](https://bsky.app/profile/did:plc:w227epg3attqnssfdkx6ex6a/post/3lqcugizbls2g)
- - [[50:34](#3-layer-data-data-fetching-for-complex-react-apps-rscs-react-query-optimistic-ui)] [3-layer data data fetching for complex React apps](https://www.trevorlasn.com/blog/fetching-data-for-complex-next-and-react-apps) (RSCs, React Query, optimistic UI)
- - [[51:05](#johannes-schickling-announces-livestore-reactive-sqlite-sync-layer)] Johannes Schickling announces [LiveStore (reactive SQLite \+ sync layer)](https://bsky.app/profile/schickling.dev/post/3lq5gucxsj22a)
-- [[53:02](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the May edition of this month in React, where we recap and digest the ever evolving react and web ecosystem. We are coming to you live from Reactiflux, the place for professional react developers, and we are supported by infinite red uh, consultancy that exclusively works in React Native. [00:00]
-
-I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like this and build other tools to keep the community operating. [00:18]
-
-**Mark:** Hi, I'm Mark. My day job is with Replay io, where we're building a time traveling debugger and trying to find ways to make AI chat bots smarter with time travel. And also I spend a lot of time working on redux and ranting about the React teams communication. [00:28]
-
-**Mo:** my name is. I had the mobile team at Theodo and I'm an active member of the React Native community, a core contributor, and I organized the React Native London Meetup and conference. [00:42]
-
-## Quick hits
-
-**Carl:** Quick job market news new releases. [00:54]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
-
-**Carl:** Generally it looks like this Fred data source that looks at Indeed, I'm starting to doubt whether it's an accurate reflection of the current market. It's just been continuously trending down which I think may just indicate that people are hiring fewer software engineers on Indeed, since that's the only source of data for it. [00:57]
-
-Drew up dot iOS job trends shows a different direction. It's been a little bit better, but you know, it's not categorically different. [01:11]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** upcoming conferences. [01:19]
-
-## [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
-
-**Carl:** We've got React Summit in about two weeks, so if you are looking for something to do that's gonna be June 13th through 17th in Amsterdam. In Netherlands, [01:20]
-
-**Mark:** as usual, they're doing one day of an actual in-person conference, and then there's a remote only streaming set of talks. I think like the, the following Monday or something. I'll be speaking there in person. If you've heard me I said I've been doing routine. If you've heard me talking about things like, you know, the community misunderstanding reacts development or the React team having opinions about frameworks and stuff, I will be talking about that sort of thing, live on the main stage. [01:29]
-
-**Carl:** Very nice. Excellent. Well, I will be at a different conference. [01:54]
-
-## [Render ATL](https://www.renderatl.com/) June 11-13 Atlanta, GA, USA
-
-**Carl:** There's also gonna be render Atlanta June 11th through 13th. they seem to have really good vibes. It looks like it's pretty well attended in general. So this is my first time attending the event, but yeah, I'll, I'll be there June 11th through 13th. [01:57]
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-**Carl:** We are sponsored by Infinite Red. They are an expert react native consultancy that's been around since 2015. So very long running. They do a lot for the ecosystem, including hosting podcasts. The hosting, the largest React native podcast hosting, I believe the largest or organizing, I believe the largest React native specific conference in the us. [02:12]
-
-And they only do React native and have built over 75 apps for companies ranging from startups to the biggest in the world. And they generally will work with a team in order to develop expertise, you know, within that team rather than just being a airdrop in Build the Thing and leave kind of consultancy. [02:34]
-
-So if you are working at a company looking to develop some React native expertise, definitely reach out to them. they're good people. [02:52]
-
-## New releases
-
-**Carl:** Into some new releases. [02:59]
-
-## [TanStack/db](https://github.com/TanStack/db)
-
-**Carl:** a new TanStack sync engine that looks like it ties in pretty well with TanStack Query. I haven't played with this, but it looks pretty interesting. [03:01]
-
-**Mark:** Looks like Kyle Matthews is working on it. Kyle's probably best known as having created Gatsby, but he's currently working at Electric sql, which, which is a syn engine company, so probably making use of some of his expertise there. I. [03:10]
-
-**Carl:** Yeah. Very cool. Definitely nice to see that kind of expertise being brought a little more broadly into some other projects. I think local first and like syn engine kind of stuff seems like. A very powerful area of exploration right now. I don't think we really know what it's gonna shake out to. But yeah, I've seen a couple of apps developed in this way over the years and they always, it just strikes me as a really powerful way to do it. [03:23]
-
-I think a great example of Local First is actually Gmail. They've been very local first forever in a mobile app, you know, you can just functionally use it and then you come back online and it actually executes all the things you did. That's just generally how I think most apps should work. So seeing a lot more exploration and how to support that with different types of tools definitely looks really cool. [03:47]
-
-And then coupling that, tying it very closely in with the query engine as it appears that this Tan Stack DB does. Definitely makes a ton of sense. Definitely really interesting there. [04:08]
-
-**Mo:** It's quite interesting 'cause I was having a chat with a fellow mobile developer just a few days ago, and he was telling me how he uses TanStack Query as like really like the central data store. Of his application on a React native app. But then the challenge is that things working locally is always a real pain and things working offline is a real pain because taking that either means you have to just like store the entire cache inside of like adjacent blob living somewhere on the device disc. [04:19]
-
-It's quite messy and it, doesn't follow those like asset principles that you would want to make sure that the data's intact and there's no sort of conflicts when you do reconnect. This looks pretty cool. I know it's only for react at this point, as far as I can tell, and it doesn't necessarily seem to be targeting React native support, but I think a lot of people in the React native ecosystem would probably love to use something like this so that these things are just synced onto a SQL like DB somewhere on the phone, which is kind of a way to do local first stops in React native. [04:50]
-
-**Carl:** network is so much more unpredictable on a phone than it is on, on the web. So yeah, that, that makes sense. That's maybe a little underwhelming, but it's not targeting React native support. [05:18]
-
-## [Legend List 1.0 released](https://bsky.app/profile/jayz.us/post/3lni5ofbuvs2s)
-
-**Carl:** Mo you want to tell us about Legend List? [05:28]
-
-**Mo:** Yes. So this is super exciting because legend list, for those of you who've been following along with the podcast for the last few months has been something that we've been talking about on and off, but it's been sort of in that alpha beta phase. So Jay Meistrich, he used to be a game developer, so I say that because. [05:29]
-
-Game development is super, super hard and you optimize for performance as much as you can. So he has that background and worked on a bunch of sort of low level OS stuff for a while. And so he's been a active member of the React native community. Made a library that was the most performant, well by his metrics, one of the most performant state management tools called Legend State. And and so Legend List is sort of, taking that experience and putting it into React native lists, which is one of the most challenging parts of the React native sort of development workflows, making performance lists. [05:45]
-
-And it is by far on all accounts of different people testing it in the ecosystem. The fastest React native list implementation. And it is a hundred percent js. It is very stable. At this stage. I know a lot of actual production apps that have been using it before 1.0. And so I would highly recommend you, you'd give it a try. [06:14]
-
-It's pretty straightforward to replace any existing list that you have, whether that's flat list or flash list. [06:31]
-
-**Carl:** Very cool. Yeah. List performance while like rapidly scrolling is one of those really visible things in an app, so definitely, definitely really cool to see a great, low level primitive for use there. [06:36]
-
-## [Redux Toolkit v2.8.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.8.0) (and bugfixes after)
-
-**Mark:** If you've been listening for a while, you've also heard me ranting about the complexities of publishing JavaScript packages and ESM and CommonJS compatibility. We shipped Redux Toolkit 2.8, which was primarily intended to improve our compatibility with the Metro Bundler and React Native. It did that and then it promptly started breaking tests with just environment js dumb due to reasons. we shipped a fix for that and then a process we act, we found out that the release had also ended up messing up some of our bundling so that the different and things weren't getting shaken out properly. And oops, our nested imports were actually like three times as big as they were supposed to be, so we had to fix that. So RTK 2 8 2 is out, and if you're going to upgrade, please use that one. [06:48]
-
-**Carl:** For sure. Yeah, we've got a bunch of smaller releases or like beta stuff, so I'm just gonna kind of fly through some of these. [07:30]
-
-## [MUI v7.1](https://github.com/mui/material-ui/releases/tag/v7.1.0)
-
-**Carl:** Material UI has version 7.1 out. It looks like it's mostly bug fixes. We talked about the new like slot pattern that they introduced in 7.0 in the last episode. Interestingly, they also talk about Tailwind V four support, which is a little bit surprising for a component library of this complexity. [07:37]
-
-I don't know exactly what Tailwind support means in this context, but it does appear that you can use a styled engine provider with a, like CSS layer not quite clear on whether this is doing all of the compile time tailwind optimization kind of stuff, or. Right. The implementation details here are not totally clear to me from the release notes but definitely interesting. [07:55]
-
-Yeah. I know that Tailwind V four support has been kind of a sticking point for some projects, so it's interesting to see such a large and complex style library take advantage of. It [08:20]
-
-## Jest has a v30 [beta.3](https://github.com/jestjs/jest/releases/tag/v30.0.0-beta.3) \+ 4 out. [First alpha](https://github.com/jestjs/jest/releases/tag/v30.0.0-alpha.1) of it was published October 2023
-
-**Carl:** Jest has a new V 30 beta beta three. I was checking the release notes for it and alpha one of version 30 was first published in October of 2023. [08:30]
-
-So this has been a long time coming. It looks like beta three introduced a lot more new things than the re the other alphas or, you know, many more fixes and whatever. So yeah, I don't know exactly what to think about that, Jest has been generally a kind of finished project in my experience. But yeah, they've got a new version turning its way through. [08:43]
-
-Although with two years, a year and a half since the first Alpha, I'm not sure if this is gonna be released anytime soon. Mark, tell us about Zustand and Jotai. [09:03]
-
-## [Zustand 5.0.5](https://github.com/pmndrs/zustand/releases), [Jotai 2.12.4 and .5](https://github.com/pmndrs/jotai/releases)
-
-**Mark:** Just a couple minor bug fix releases. Probably not in much meaningful, but you know, always worth looking at updates. [09:11]
-
-## [devstore deprecated](https://x.com/jotaijs/status/1919778234037878919)
-
-**Mark:** Jotai is also switching from whatever previous standalone dev tool support they had to their own built-in dev tools. [09:17]
-
-**Carl:** Yeah. Deprecating whatever internal tooling they had for that. [09:25]
-
-## [Radix](https://www.radix-ui.com/primitives/docs/overview/releases) has new primitives: [OneTimePasswordField](https://www.radix-ui.com/primitives/docs/components/one-time-password-field) and [PasswordToggleField](https://www.radix-ui.com/primitives/docs/components/password-toggle-field)
-
-**Carl:** Radix has a new release that has a couple of new primitives if you're using that. It's got a generally password adjacent. There's a one time password field and a password toggle field, so neat. [09:28]
-
-## [Ant Design 5.25](https://ant.design/changelog#5250)
-
-**Carl:** Ant design also has a new release with a, a new. [09:38]
-
-Timer statistic component. I've never used ant design. It was interesting to me. Well, I was looking to read more of the, you know, release details on this, but an awful lot of the contribution is in Chinese and I do not read Chinese. I know that's, been a bit of a bifurcation in the React ecosystem is, you know, language barriers are challenging. [09:41]
-
-they got a new thing. It looks cool. [10:00]
-
-## [React Aria May 19, 2025 release](https://react-spectrum.adobe.com/releases/2025-05-19.html)
-
-**Carl:** React Aria has a new dated release, you know, they don't do versions, they do dates. So this is the May 19th release. It looks like it's pretty much just small bug fixes, although they do also say they have support for the React 19 ref cleanup call that was introduced. [10:02]
-
-So yeah. Neat. Cool. [10:19]
-
-## [Relay 19](https://github.com/facebook/relay/releases/tag/v19.0.0) with React 19 support
-
-**Mark:** relay GraphQL version 19 is out. It's got support for react 19 as well as they've been working on their documentation. [10:21]
-
-## [Storybook 9](https://github.com/storybookjs/storybook/releases/tag/v9.0.0)
-
-**Mark:** And then storybook version nine is out, and it looks like they've made a really big effort to try to shrink the bundle size of their own tooling. [10:29]
-
-**Carl:** Cool. Alright, so that's all the new releases. [10:36]
-
-## Main Content
-
-**Carl:** We got so many small ones this month into our main content. Mo let's start off with expo. [10:38]
-
-## [Expo SDK 53 release](https://expo.dev/changelog/sdk-53)
-
-**Mo:** Cool. So we have a major release of a new expos DK. So expos, DK 53 is out, and this has been under the, the, the works for a very. Very long time. So Expo usually historically would release a version of an SDK with every React native release that would come out. So, you know, react native dot 72 comes out. [10:45]
-
-And then SDK version 40. I can't remember the corresponding, but you get the point. Every single version is tied to a specific SDK version. But as the React native team has been releasing more frequently the expo team found that it was actually probably a good time to stop tying those things together and sort of bunch some of these SDK releases into larger releases so that they can make. changes to the actual SDKs rather than having to keep up with React native and the versions that are being released every few months. So SDK 53 is a big one primarily because now the new architecture is default everywhere. So if you were paying attention, the last release that they had, the new architecture was default for new projects. [11:05]
-
-What they've now done is they set the new architecture even for existing projects when you update test SDK 53. And this fits with sort of the larger push that the React Native Core team is doing to push people onto the new architecture. And so React native version 79, as an example, has the same thing where, you know, existing apps will also be in the new architecture by default, and you need to opt out. [11:45]
-
-And as of yesterday as well meta announced at app js that they're going to be freezing the old architecture. So they're not really gonna be doing and adding any new features into the new architecture either. So very much going down the deprecation path with eventual sort of removal from React Native Core, which is kind of as we would expect it. [12:06]
-
-Other things to mention. So. Android developers will know about a requirement that came in to the Android ecosystem a few years ago called Edge to Edge support, which meant that your app needs to cover the full sort of corners and notches of an app of an Android phone. And this was sort of opt in for the longest time, but as of the next Android version that's soon to be released, I believe it's Android 16, edge to Edge support will be required. [12:23]
-
-On all apps. So if you submit an app that doesn't have Edge, edge to Edge support, they will reject it. So a bunch of people in the community have been working on getting this up and running because it's not trivial, it's actually quite complicated. So Zoom Tech who's well known in the React native ecosystem's, been working on this. [12:47]
-
-So he's worked with the expo team to get that implemented by default in SDK 53. So once you update to SDK 53, your app will already have Edge to Edge support. This is not the case yet for React Native Core. So if you have a non expo app, that won't necessarily be the case and you're gonna need to add it in manually yourself. [13:02]
-
-The goal is that eventually this will be merged and upstreamed into React Native Core anyway, and will just be handled as a core part of, RNs functionality. [13:19]
-
-**Carl:** That makes sense. So I'm thinking of like instead of safe area, it's gotta be edge to edge. I. [13:27]
-
-**Mo:** It's adjacent to that, but not directly related. So safe area views in react native, typically, historically were more of an iOS thing because iOS introduced the notch and then they introduced the dynamic island. So that safe area view was for that more than anything. 'cause Android app devices typically were a little bit more uniform, albeit not the exact same. [13:31]
-
-And then. Android devices followed suit with that. Edge to edge is more sort of how the app interacts underneath the notch or like in the corners of your, of your, of your screen. So, you know, you have a bunch of things in the Android world, like curved screens, and you have screens that, you know, have a a rounding on the corners and so on and so forth. [13:51]
-
-And edge to edge support is to basically make sure that it covers the full sort of portions of that which wasn't there by default. it's, I'm not an Android developer, so it's not necessarily my specialty, but I do know that it is a requirement there, and I think it's certain Android screens can be a little wacky and edge stage support is necessary to make sure that things are behaving correctly on all Android devices. [14:12]
-
-I. A few other things to mention with Expo SDK 53. Background tasks. If anyone's been building rack native apps since the beginning, he'll know that doing background tasks is really, really hard and making sure that they actually execute and you have some level of confidence that things are gonna be run in the background when your app's not sort of front and center in the foreground of, of the user's phone. [14:33]
-
-It's challenging. So Expo actually like went through this. They had a background tasks module. They went through just re-architecting it all because it was fundamentally flawed in the way that it was trying to tackle the problem. So they're actually using they, they've released the expo background task module and it uses sort of the up-to-date latest APIs on both Android and iOS. [14:54]
-
-And so they recommend you use this for different things, like let's say if you need to download data in the background. Or if you need to run over the air updates, so you wanna check, see if there's over the updates, and then actually download it in the background. You can do that, or, you know, garbage cleanup and so on and so forth. [15:12]
-
-If you need to do that in the background of your app. So this is quite useful. It's one of those things that happens behind the scenes, but I think is incredibly important to make an app really perform and, and feel like a native app would. Another sort of minor thing is expo audio. [15:27]
-
-So there's an expo audio update within this release. And expo audio is generally the replacement of Expo av, but the audio portion of that library. So that library was quite complicated And so they've split it off into expo audio and expo video and expo video came first. [15:41]
-
-Whilst they were working on audio, and now audio is, being released at this point, which is quite cool. [15:57]
-
-## [Package.json imports support](https://x.com/satya164/status/1916095938604548366)
-
-**Mo:** Last point on SDK 53, that's kind of adjacent to SDK 53, more of a React native thing, but it's part of SDK 53 as well is package json import support, which is great because it's oftentimes quite a big in React native projects with. [16:01]
-
-Babel and TypeScript working together for these package imports. So now React native has this feature built in, so you just define imports within your package js. You update your ts config to just resolve package JS imports and that's it. Which is a really good standardization. So, if you're using the older way of doing sort of aliases for your imports go ahead and change that because I think it'll make your life a lot easier in the long run. [16:15]
-
-**Mark:** I do kind of object to the use of the word just in that sentence. [16:39]
-
-that's basically what we were trying to, trying to get compatibility for with, our RTK 2.8 release. [16:43]
-
-**Carl:** I'm glad to see this standardization rolling out. I remembered this coming through in node. I went and looked it up. It was originally released in node 14, which came out April, 2020. So this has been a pretty decent long time coming though, you know? a lot of ducks to get in a row to make it work. [16:48]
-
-But definitely really nice to have alias resolution happen just from package. Jason, instead of needing to, I just, I can just remember all of the various pain I've had with like, trying to keep the aliases between like web pack and Babel and jest and storybook in, you know, all of the different parallel configuration that each needed, its own different way of configuring aliases. [17:05]
-
-So I love that standardization around that is settling out. [17:29]
-
-## [React Router RSC preview](https://remix.run/blog/rsc-preview) and other RSC topics:
-
-**Mark:** we've got a bunch of different things happening related to server components this month. Probably the biggest one is that React Router has announced a server components preview. this is probably a big deal for multiple reasons. We've already had at least one other tool parcel put out what it considers like a, a fully production ready release of server component support. [17:32]
-
-So we, we are getting more tools other than just next supporting it. But in terms of usage, react router, you know, even if you're, and you're just looking at the client side functionality has always been one of the biggest packages in the ecosystem. And part of the point of the whole React router, remix, react router back and forth was to try to make more of those pieces available in React router itself so that you could just turn on the framework mode flag and start to get server side rendering bundling type support. [17:55]
-
-And so having RSC support there. Is really going to be, from my perspective, the first widely available usage outside of next. So that feels like a big deal. It's also a big deal because I think most of our understanding of how to use server components has been very heavily shaped by the fact that next was the only real implementation. And so there's sort of been this, well, the way that the next app router works must be the, the way that server components have to work. [18:26]
-
-And instead here we see that the React router team has made some very different implementation choices in how you use server components. So in particular, they've got the ability to actually return server components as individual fields from your loader functions. So you can return some, data. You can return some components, and then your actual component on the client side just receives the loader data and you receive the elements much like you would props dot children, and you just include that in the output. They've also got some more options for server components, routes, and intermixing them support for server functions and then still doing things on the client side. So this looks like a pretty big deal release if you want to try that out, sort of adjacent to that. one of the complexities for server components in general is that they require tight integration with a bundler. And so the React team had specifically most of their initial work was around implementing integration for Webpac because Webpac is so widely used across ecosystem. And they've repeatedly stated that Vite's internal architecture just did not support the proper module graph handling to make real server components support possible. [19:01]
-
-so the, the React team has tried to keep the packages for the Bundler integrations in the React repo so that they can more easily iterate on changes to the core functionality versus what's specific to the bundlers. Like there isn't really like, kinda like a, a publicly defined API for that sort of thing, easier to all have it in one repo. But that's also meant that they didn't have the expertise or knowledge to do the Vite integration properly. [20:24]
-
-## [Vite community PR to add RSC support](https://github.com/facebook/react/pull/33152)
-
-**Mark:** So there is now a PR from the community to try to add, quote, unquote, proper Vite and RSC integration. And there's been some back and forth on that. Don't know how long it'll take to get that landed, but that does seem like a fairly big step. [20:49]
-
-**Carl:** Yeah, it definitely does, right? The lack of public API and general documentation for this is definitely, we've talked a little bit about how that's a pretty big barrier for people looking to explore this. You really have to reverse engineer it yourself if you wanna look into it. Seriously. [21:04]
-
-**Mark:** so at this point, we've got Next has been out for a while. Parcel just released its own quote, production ready, RSC support. We've got React Router coming out with a preview. So it, the, the ecosystem is starting to flesh out. [21:19]
-
-## [Leerob’s list of other RSC explorations](https://bsky.app/profile/leerob.com/post/3lo4l2rmy7k2b)
-
-**Mark:** Lee Robinson from CEL has been collecting a list of some different frameworks that are experimenting with RSE support in various alpha and, and, you know, test preview approaches. [21:33]
-
-## More Dan posts, like [Static as a Server](https://overreacted.io/static-as-a-server/) and [One Roundtrip Per Navigation](https://overreacted.io/one-roundtrip-per-navigation/)
-
-**Mark:** meanwhile Dan Abramov has cranked out several more blog posts trying to. Pitch the mental model of es. A couple folks have said that, you know, he's kind of hitting the same theme from different ways he's basically trained to start from different mental models and work backwards to, "and here's how RSCs address all these different problems." I think he actually put out four different posts this month. Two in particular one talks about how RSCs allow you to do static site generation and don't even require a, like a running application server to do the work. As well as how rses help handle the need to fetch multiple different pieces of data in one round trip. So there's those couple posts plus a couple others. So, as usual, worth reading, [21:44]
-
-## RedwoodSDK’s [“Your React Framework Feels Broken”](https://rwsdk.com/blog/your-react-meta-framework-feels-broken)
-
-**Mark:** One other sort of related post. So we previously mentioned that Redwood pivoted from their previous, very GraphQL based framework and they, they deprecated or archived that framework entirely, and they've come out with a new tool called Redwood, SDK which is based on CloudFlare and RSCs. And they, they put out a post called your React Meta Framework Feels Broken, which is both a, a kind of a critique of other frameworks as well as a sales pitch for their particular approach to dealing with server components. So we really are seeing different parts of the ecosystem trying to figure out how to actually make use of server components and ship those as actual features. [22:33]
-
-## [Remix v3 announcement](https://remix.run/blog/wake-up-remix)
-
-**Carl:** Well, yeah, that leads us sort of into new remix. They have released, or they've announced a version three which is somewhat surprising to me because I had understood it as a deprecated brand that was being merged back into React Router. But actually I, you know, reached out to them to be like, huh. And, you know, reached out in the remix Discord just to express confusion. And I had my attention directed back to the blog post that was released around when they actually did that talk at React Con last year revealing that they would be merging remix back into React router. And they, they were very clear about this from the beginning. [23:20]
-
-I don't really remember it in the talk and I'm not sure that I went back and read the announcement blog post after hearing the talk. So that may have been why I missed this. But yeah, they do talk about how this is, you know, that was their plan. They were going to re remix was a, a Fork of React router, I guess. They did a big thing with V two and merged that back into React router V seven. And in that blog post they talk about how V three is gonna be something totally brand new, but it will be coming, it was in progress. So it's here and remix is not dead despite reports to the contrary. [24:03]
-
-**Mark:** Or at least it's, it's far enough long that they were actually, ready to announce it. I don't know if any of this is available or visible in any way yet, but at least they're saying we're, we're working on it. [24:35]
-
-**Carl:** Yeah, true. [24:45]
-
-**Mark:** So, yeah, this is. it's confusing. I've seen a lot of people pushing back on, you know, like there's already been lots of people complaining over the years about the various React Rider major versions and changes and, you know, Ryan and Michael can't seem to settle on a single API design. I, I will say that the bouncing back and forth is kind of confusing. And then having a version three of an existing package that seems to throw all the existing, previous pieces out the window, is also kind of confusing. You can sort of make the parallel between the angular one or angular JS one versus angular two changeover that happened like a decade ago. [24:46]
-
-The general sales pitch, looking at the announcement blog post and some of the comments by Ryan and Michael on Twitter. So. They're, taking inspiration from, you know, tools like Rails and Express and whatever. You know, , they're sort of trying to apply like best lessons learned from all the other tools out there. [25:29]
-
-They really seem to be, want, seem to, want to go for simplicity and a non bundling approach. Like they seem to want their tool to minimize the number of actual dependencies that it needs to run. And they want to avoid having a bundling step in both development and production. [25:44]
-
-## [Discussion between Evan You and Michael Jackson about bundling / HMR approach and tradeoffs](https://x.com/mjackson/status/1928297364726632499)
-
-**Mark:** In fact there was a, a conversation between Evan Yu from, you know, from V and View who is saying that, you know, modern apps really need HMR, they need bundling even in development. [26:04]
-
-That's why, you know, that's part of why VIT is redoing its internals. And Michael replied and said. Yeah, we are, we, we want to minimize the number of tools that are involved. We want to minimize the number of transformation steps. We want things to be able to run without needing to do a bunch of compilation. And we're actually not going to ship HMR, we are going to rely on page reloads in Dev, and we think we can make it fast and work. [26:15]
-
-So they clearly have a vision, it's definitely a bit of a zigzag from where the ecosystem has gone over the years. One of the other interesting points is that it's not even going to use React as the UI layer. It's going to use Preact and in fact, apparently it's going to use a fork of Preact so that they can do some additional customizations. I don't have any additional details on what those customizations will be, but that's the direction they're going. I think, check me in this Jason Miller, who originally created Preact also now works at Shopify, right? [26:40]
-
-**Carl:** That sounds right to me. [27:16]
-
-**Mark:** So both, you know, Ryan and Michael, you know, like Remix got bought by Shopify a couple years ago and Jason Miller is there. So that, that presumably makes it easier for them to potentially collaborate on some of that work. I. [27:17]
-
-**Carl:** Yes, his Twitter bio lists him as platform developer experience at Shopify. So, right, like that job title is exactly this kind of work, like making developer tools and frameworks easier to use. So interesting [27:31]
-
-**Mark:** One of the other bullet points was they, they want to have an emphasis on LLM model based development. Ryan has made some comments recently that he's using LLMs in his day-to-day work, and it's helping to make him more productive. And I think I saw him mention that like the first line of the draft new docs for this version three is "disregard all previous remix versions" as an instruction. [27:46]
-
-So I, I don't know what all they have in mind there other than, being able to organize the docs in such a way that it's LM friendly, but it's something that they have in mind. So no ETA on when any of this will be available. But given how influential React Rider and remix have been, this is certainly something to keep an eye on. [28:13]
-
-**Mo:** there's sort of two thoughts on the, like the LLM friendliness that stands out to me. The first one is, ironically, I think by naming this remix, they've actually shot themselves a little bit in the foot because it's gonna be a fun challenge trying to teach an LLM how to disregard a version two versus version three documentation or stack overflow question that has been trained on, [28:34]
-
-**Carl:** That's actually a really good point. [28:55]
-
-**Mo:** I do wonder if inherently by building on top of web APIs and like staying as close, which, which has kind of been the philosophy with remix, old remix slash react router anyway, by trying to stick to web APIs and standardized sort of W3C primitive, so to speak, that are so well defined in terms of documentation, more so than probably anything else on the web. [28:57]
-
-Plus them adding some good documentation that is LLM friendly in very, very loose air quotes. If that just makes it a little bit more predictable, because I feel like. Having gone through a lot of the W3C docs, it is so well structured and so logical. Obviously it's quite convoluted a lot of times for people who aren't used to it, but it's, it's very like organizationally structured and I wonder if that can help an LLM understand it better than anything else. [29:20]
-
-But that's just a, that's just a personal guess. Could be very wrong. [29:45]
-
-**Carl:** Yeah. Well, I was gonna say that kind of leads us into our next topic, which is react core work in progress. [29:49]
-
-## React Core WIP
-
-**Carl:** And one thing that they have checked into the repo that I, I don't think has been really discussed or publicized anywhere, is they have a MCP server work in progress. [29:56]
-
-## [React MCP server](https://github.com/facebook/react/tree/main/compiler/packages/react-mcp-server/src)
-
-**Carl:** And so MCP is model context protocol, I believe. It's basically a generally standardized way of authoring tools for LLMs to make use of. I think this react core MCP server is mostly around the compiler. So Lauren has done a lot of work on the compiler and is now doing, it looks like some work on this MCP server. I don't really have a great grasp of what MCP servers are good at, but as far as like tools that LLMs can take advantage of, like sure. Having your IDE be able, your, you know, the LLM and your IDE to query, react, to say, please run this through the compiler and tell, you know, check the performance optimization, see if it's better than it, you know, this other attempt that seems interesting and potentially useful in a, relatively limited capacity, but connecting it back to the remix v3 and LLM friendliness, I could imagine a world where like there's an MCP server that looks up documentation for your specific version that you have installed. [30:08]
-
-I don't know if that's, you know, a direction that they're going to explore, but that def, that sounds plausibly workable to me. I don't know. That's interesting. [31:13]
-
-**Mo:** specifically like an MCP server. Is is more for the LLM to be able to externally call tools rather than just generating text. So it gives it like a way to interact with the outside world. And I guess going through the code of this specific MCP server they've defined a few different tools to compile with the React compiler. [31:21]
-
-If you give it a set of code basically but also then run performance tests. And sort of go through this process of assessing what, the LCP is, I-N-P-C-L-S, and also the core web vitals. And so looking through the actual source code, it seems to me what they kind of want you to be able to do is to use the, use this MCP server to basically compile some of your code, open up a browser and run core web vital scores. [31:43]
-
-Run the react compiler, see if it improves it, and then sort of do that in a loop, almost in an age agentic fashion, so that you can optimize a react component until it's kind of at a state where things are performance, as performance as they get. So it's almost like write your react component. It's fine if it's crap, and then leave it to the model to go in and optimize. [32:09]
-
-Measure, optimize, measure, optimize until it's at a state where, things are working as expected and is as performing as it gets. [32:29]
-
-**Carl:** Yeah. There's also some mark, I think this is more of a you question, but they've got a skeleton PR for a concurrent store. I. [32:35]
-
-**Mark:** Yeah. So this is a topic that's been discussed for a while. So one of the big limitations that limitations thus far around suspense and concurrent rendering and transitions has been that React needs to own the state in order to be able to postpone or interrupt or reschedule work in progress state updates, which means that for external libraries, Redux, Zustand, Jotai, you know, X State, you know, take your pick here. We've had to rely on the use Sync external store hook as our integration with React so that when the external store updates, react gets notified and it can trigger or re-render. [32:42]
-
-But the limitation is that used syn external store can quote unquote det, which the React team has never done a great job of defining that term. But as best as I understand it, what it means is that if React was in the middle of a concurrent render and something happens with the external store, like say a Redux action gets dispatched while React was paused, rendering halfway down the tree, it ends up having to throw away the entire work in progress render and do a full synchronous render start to finish in order to ensure that the whole tree has access to the right data. And, you know, from their point of view, that's, that's a bad thing, which is understandable. [33:24]
-
-## [“Concurrent store” skeleton PR](https://github.com/facebook/react/pull/33215) a concurrent-compatible integration for external libraries
-
-**Mark:** So. They've put up a PR for what they're calling a concurrent store, and this appears to be a react built-in object that you can create and then you can pass it to the use hook to extract the value. And somehow the internals of this will be concurrent compatible. And it looks like that will allow external libraries to interact with that instead of use syn external store and potentially allow them to be concurrent transition compatible in a way that use syn external store is not. Now, thus far, what we have is a draft PR that just adds the skeleton of this to the code base feature flags and some tests, no implementation details, nothing we can run or try out. But based on some of the stated comments on social media and this draft PR and then the last React lapse blog post, it looks like that's the idea of what this could do. So at some point we may have to put out React Redux version 10, which which is over to this, it's good to see that they're iterating on this, on this concept. [34:08]
-
-**Carl:** well you, you certainly would know a lot better the context behind that than I would having maintained redux for so long. But it seemed like the, you know, use concurrent or, you know, concurrent store or whatever the various things they've tried, it seems like none of them have quite solved the problem they were hoping it would. So. [35:17]
-
-**Mark:** External store avoids the tearing problem. But at the cost of, if you happen to have that sequence of events occur, then you, it has to, you know, take the time to do a full render, which could be costly 'cause it can't interrupt itself. [35:32]
-
-**Carl:** Trade offs not ideal. [35:48]
-
-## [\ being worked on again](https://github.com/search?q=repo%3Afacebook%2Freact%20SuspenseList&type=pullrequests&s=created&o=desc)
-
-**Mark:** Along with that, Sebastian has done some more work on view transitions and they're working on resurrecting the suspense list component idea, which had been prototyped quite a while ago. And they're found Trying to bring it back. This is apparently meant to try to allow you to define intended order for multiple different, like adjacent or nested suspense components to reveal themselves. Say maybe like you have a, I guess like a list of items or something. Admittedly as usual, it's outside the scope of what I've actually ever tried to use, but it's a thing that had been sitting around for a while and it was unclear when they would get back to trying to work on it. [35:49]
-
-## Compiler integrations with [SWC](https://github.com/swc-project/swc/pull/10475) and [OXC](https://github.com/oxc-project/oxc/issues/10048)
-
-**Mark:** And, and then finally the React compiler is currently implemented as a Babel plugin. And given how the ecosystem has been shifting away from Babel, that was a bit of a pain point. The core of it does not rely on Babel. Like Babel was just sort of used as the way to get it into your build tool. And so they've been working on, in, they have a semi working integration with the SDC compiler, which is what next and other tools use. And they're also talking with the folks from OXC, which is what the New V implementation will use about the best ways to try to integrate. So still early days there, but it's good to see that we are, they're trying to find better ways to integrate with both, you know, with the latest generations of build tooling so that we hopefully don't have to have Babel in our build tool chains. [36:29]
-
-After all. [37:19]
-
-## Apple App Store Epic Games Saga 30% [Apple cut ruled unlawful in the US](https://www.macrumors.com/2025/05/19/epic-asks-judge-apple-approve-fortnite-app-store/)
-
-**Mo:** Next up a little bit of a segue. Not specifically React news, but I think reasonable enough to call out here because it does affect React native apps. So if you've been following the news, apple and Epic games have been locked in a feud for the last. Several, several years. Apple basically taxes any company on in-app purchases for digital goods of 30%, which is quite a significant revenue hit for any app developers that are out there. [37:19]
-
-There's some provisions for startups and so on and so forth to bring that down to a lower number. But once you hit a certain amount of revenue, I think it's around 1 million or 1.5 million a year on the app store, you have to pay 30%. And so. Epic games and Apple have been going to court over this for a very, very long time. [37:48]
-
-And Fortnite was off of the app store for a while several years ago now. So it's been going back and forth. If you use Netflix on your phone as an example, you'll notice that you can't actually purchase or change your subscriptions on the app. You need to go onto a website. And there's no sort of link from the app whatsoever to manage anything related to your subscriptions. [38:05]
-
-And that's kind of by design because they don't really wanna pay the 30% to Apple. So, in a sort of shocking turn of events a court came in and basically said that apple's 30% tax is actually unlawful in the us. Which is kind of a. nobody kind of expected this to come out especially because the EU didn't even go this far. [38:23]
-
-And so, the EU basically went in and said, Hey, you should be able to have a, you know, alternative app store rather than just the Apple app store available, but didn't say that, you know, 30% tax should be removed and it's unlawful. in the first sort of events that happened in May. Epic Games won and basically they, courts ruled that Apple should reduce the 30% tax or remove the 30% tax. [38:44]
-
-And how they do that is basically you can use in-app purchases. Basically use another external payment platform for it so you can use Stripe or whatever else you want to take payments for digital goods inside of your app. The next day, apple basically blocked Fortnite from the app store in a sort of weird turn of events saying, no, we don't, we don't accept this. [39:08]
-
-Only to then get overruled with a judge asking Apple to approve the app store submission for Fortnite. So now if you're in the US you might see some apps. Having a big warning on the app store from Apple saying, Hey, this app is unsafe in terms of transactions and you're not gonna be protected by the App store, so proceed at your own risk, which is quite funny. [39:29]
-
-So still doing anything that they can to stop people from doing this. But for React native developers, that basically means that you can now use Stripe only for the US market. So if this. If this is functionality that you have for any locale outside of the us, your app will still be rejected because this is on a US only ruling. [39:50]
-
-But you can use Stripe or any other payment provider for digital goods inside of your app, circumventing in-app purchases, and still have your app approved in the us which is a big, big deal for a lot of people in this ecosystem. And folks like Charlie Cheever have been speaking about this being a big day for, for mobile developers. [40:08]
-
-A bit of an aside, but it's relevant to react native developers to be in the loop about what's happening in the ecosystem. [40:27]
-
-**Carl:** that's like half of a seismic shift for native apps. the fact that it's only in the US locale is, you know, definitely dampens that quite a bit, but [40:32]
-
-for such a large market to now be required to accept. Different payment methods that don't have a 30%, you know, cut removed that is still quite large. [40:43]
-
-Still quite significant. [40:53]
-
-**Mo:** Hopefully this kind of reverberates to other markets as well and I can kind of see that happening. [40:54]
-
-**Carl:** All right. [40:59]
-
-## [Next reducing Vercel mentions in docs](https://github.com/vercel/next.js/pull/78557)
-
-**Carl:** Our last main, you know, topic here, kind of small, but sort of speaks to the general undercurrent, the vibes that people have felt around next and react. next has reduced how many mentions Vercel gets in the next documentation. Lee Rob in the PR for this says some of the mentions were egregious and unneeded. [40:59]
-
-Others were documenting specific behavior for how next runs on Vercel, which is better suited for Vercel documentation. That seems good. I would certainly agree that some of the mentions were egregious. Some of the behavior being documented was better suited to the platform documentation rather than the project. [41:20]
-
-The next project documentation, you know, it's just such a persistent topic of discussion that like next verse and react are all just like so tightly coordinating and whatever. This is definitely a small but positive change on that. I appreciate seeing it. I. [41:37]
-
-**Mark:** I think we even also put up a similar PR to tweak the phrasing that where next is listed in the React op docs set up an installation page. I think it used to have a phrase like, next or next is hosted by Vercel, or developed by Vercel or something. And they specifically tweaked that to remove some of that reference. And like it all, like, it also kind of goes along with, Vercel being intentional about reaching out to like the Open Next folks and trying to more standardize how next actually can be hosted. think people's complaints have been valid. Like this has been both a pain point technically as well as it has it, it's looked bad, but I think we ought to give credit to them for saying, okay, yeah, we, we agree, we kinda screwed up here and we're going to try to improve the documentation and the actual usage to make it more generic. [41:53]
-
-**Mo:** Looking at this a slightly different lens as well. I mean, props of them for this goes without saying, but I think Vercel is also starting to reach this realization that they can't just rely on being a next hosting platform to monetize. Because, you know, you see in the last you. Few months how their business model has kind of shifted into three spaces, which is, you know, hosting for next and, and other things. [42:49]
-
-But also observability has become a lot more of a mention on their sort of product listing pages. And more recently, I think they're really going hard on the AI space. So a few days ago, I think they announced that you can use Vercel. Sort of ISDK as a proxy to call 40 plus different LLMs without needing to set up different billing with each of these different platforms. [43:10]
-
-So I get a sense they're trying to go for a larger cloud play, which means that they're probably less reliant on next Js being sort of their guarded secret. And, you know, their tool that only runs on Vercel. And they can open it up a little bit more without worrying about it being sort of their only lever for business. [43:32]
-
-**Carl:** Yeah, that's interesting. I hadn't thought about how they were, they were super early on the ai SDK, they definitely have first mover advantage there, I'd say, and that is, that does position them well for like, if they are a point of entry for LLM based APIs, then that I could imagine a world where they then try and be like host their own models. [43:49]
-
-And then you are paying them for that hosting as well, which is adjacent to hosting your, your web app, but not quite the same maybe. Yeah. That's interesting. Yeah, they definitely own a pretty significant front door there and so where that door goes could certainly lead to stronger monetization for them in the future. [44:12]
-
-I also want to, you know, since in the last couple of episodes we've, one of the topics of discussion has been Vercel, and its. Collaboration or lack thereof with other adjacent hosting providers. noticed at the bottom of this PR it says Netlify has confirmed they're okay with a specific feature matrix link included, and I did my best to include the CloudFlare and Amplify versions based on their documentation, which I'm going to read into and say they do not have open lines of communication with CloudFlare and AWS which is maybe not ideal. I feel like they should have, you know, the, the head of dx, head of, I don't know. [44:30]
-
-I don't know exactly what Lee Robb's title is, but he is highly active, engaging with many individuals throughout the ecosystem. And for him to reveal that they do not have, you know, maybe not a red phone, but like any means of getting in touch with people within CloudFlare or AWS somewhat surprising. [45:06]
-
-I don't know. [45:24]
-
-**Mo:** CloudFlare, yes, I agree with you. Amplify. Oh boy. I've, used Amplify on and off to host various applications. I'm instinctually going to say that that might be more on the Amplify team, just by virtue of how they deal with their own users, let alone with other community leaders. But that's just a guess. [45:24]
-
-CloudFlare is probably a different, [45:45]
-
-**Carl:** I have very briefly used Amplify and that is approximately my read of things too. Fair enough. [45:47]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Alright Should we go to the lightning round? [45:52]
-
-## [Shared Element Transitions in Reanimated](https://github.com/software-mansion/react-native-reanimated/pull/7466)
-
-**Mo:** I'll kick it off with shared element Transitions, a very, very exciting prospect that we've been waiting on in the React native ecosystem So there's a draft PR going into React native reanimated for shared element transitions on the new architecture. I. Shared element transitions very quickly is basically what happens when you navigate from a screen to another screen in the React native or in a mobile app, and some element is taken, expanded, or animated onto the next screen. [45:54]
-
-So, you know, Instagram, you click on a post, it navigates you to that post, but it opens it up so you see a transition of that post expanding or something like that. There's been a lot of sort of POCs of this in the React native ecosystem, but nothing standardized that people can use easily and consistently in their apps. [46:22]
-
-So, Bart from Software Mansion has been working on this for a while and we've seen some really good promise of, of things actually working out for it to be available. So keep an eye out, keep an eye out on that. But it's still early stages, but I think that the new architecture can enable stuff like that, which is really, really exciting. [46:38]
-
-## [V8 explicit compiler hints](https://v8.dev/blog/explicit-compile-hints)
-
-**Carl:** This is extremely niche. But V8 now has, or is providing a new way of ge improving startup time by using comments to hint to the compiler what will be used and what should be compiled. So this is like very deep in the weeds of the runtime engine and like how it gets compiled and when it will compile things. [46:56]
-
-So this is certainly not something that I think most of us will need to use, if optimizing startup time is something that you care about, V eight is now giving you some new things, some new ways to play with that. I don't super duper understand all the, you know, twists and turns of this, but the gist of this blog post is saying that you can add a comment you know, slash slash. [47:18]
-
-Hash bang or no, not a hash bang, just a hash slash slash ash. All functions called on load. And that will signal to V eight that it should compile it differently than it would otherwise, which will improve startup time so that it, you know, because it doesn't have to guess so much at what is being compiled. [47:40]
-
-I always appreciate seeing some of these runtime optimizations. It's just like a little window into the black box. [47:58]
-
-## [TS Native Previews](https://devblogs.microsoft.com/typescript/announcing-typescript-native-previews/?s=33) (usable build of the Go-based compiler)
-
-**Mark:** All right. we're always talking about tools that are, and putting out, you know, faster releases, rewrites and native languages. And this month we've got a couple of previews. We've previously a announced that TypeScript is being rewritten in Go, and the TypeScript team has put out preview builds of the go based tooling. So you can try those out and see how fast it is. [48:05]
-
-## [Vite \+ Rolldown preview build](https://voidzero.dev/posts/announcing-rolldown-vite)
-
-**Mark:** Similarly, Vite just announced like right before we, we, we started recording this, that they've got a preview build of their roll down based. Bundle. So the idea right now, v uses a mixture of es build in development modes and roll up, which is a, which is written in JavaScript for their production builds. And so roll down is a rust based reimplementation of roll up, but they're going to use it for both dev and prod. And they're also going to look at, start doing bundling in dev rather than just shipping standalone ES modules to the browser. So it's preview, you can try it out. They've got some stats saying builds have gotten a lot faster as a result. [48:26]
-
-## [Seeded pseudo-random number proposal advances to Stage 2](https://bsky.app/profile/did:plc:w227epg3attqnssfdkx6ex6a/post/3lqcugizbls2g)
-
-**Carl:** Another deep in the weeds. update, but this is pretty early too, TC 39. But a seated pseudorandom number generator proposal has advanced to stage two. You know, math, that random is useful for many things, but cryptographically secure random generation is not really one of them. [49:10]
-
-Although actually this is sort of adjacent to that. This is one of the problems of math thought random is it doesn't let you provide a seed for the randomness, which has various drawbacks where sometimes you, you know, you want something that appears random, but is actually deterministic so that you can, you know. [49:29]
-
-Have other parallel computation that will produce the same output regardless of what the random is. some specific example tying in a CSS feature that I am not familiar enough with to speak at length to. But yeah, just like generally this is a huge expansion in the functionality, the randomness support in the web, in JavaScript. [49:46]
-
-I, I think it said it's like 17 new various random functions. So that's, that seems very nice. [50:10]
-
-**Mark:** a couple times where I needed to do some seated ran number generation, even if it was just for something like a, a, a tutorial example app and had had to rely on various third party libraries for that. So, I mean, definitely a useful thing to add to the platform. [50:17]
-
-Okay. And wrapping things up, a couple, couple bits around data fetching. [50:29]
-
-## [3-layer data data fetching for complex React apps](https://www.trevorlasn.com/blog/fetching-data-for-complex-next-and-react-apps) (RSCs, React Query, optimistic UI)
-
-**Mark:** I saw one article that gave and gave some suggestions around a way to manage your data fetching at a a three tiered approach where you can use server components on the server to do some initial fetching. Pass some of that as props into components and use it to seed react query on the client and then set up React Query to do some optimistic UI updates for faster behavior. Not necessarily new and groundbreaking, but it was nice to see a reasonably detailed article that suggested some ways to tie all three pieces of those together. [50:34]
-
-## Johannes Schickling announces [LiveStore (reactive SQLite \+ sync layer)](https://bsky.app/profile/schickling.dev/post/3lq5gucxsj22a)
-
-**Mark:** And finally Johannes Schickling, who I believe originally co-founded Prisma has been doing some work over the last few years around a local first sync engine called Live Store. He gave me a demo in person when I was, in a conference a couple years ago. And then he gave me and David corse a preview of his talk for local First conf a couple weeks ago. And this is really interesting. So he is running SQ Lite in the browser. He's got a reactive layer around SQ Lite. [51:05]
-
-So you would have like a, a, a data-fetching-like hook that you'd use in your components, except it's talking to sq l under the hood. But then the sq LI instance itself is being based on. A series of descriptive events. One might almost call them actions that describe a thing that happened that ultimately define how the data ends up in SQL eight in the first place. And so he actually very intentionally drew parallels to the, the redux mindset and architecture in his talk. So he, he just put that, I put that out and announced it at local first conf. it genuinely looks very interesting. Like, would all apps need it? No, but it looks like it would be extremely useful for things like a, like a local first setup needing to work offline. [51:35]
-
-**Carl:** I know Johannes Schickling is also very involved in effect, which is a interesting, like massive, huge API scope, like functional programming library. So like, man, he's doing a lot of stuff. He is really shooting his shot in a lot of different directions. Very cool. I somehow feel like he was involved in organizing the local first con. [52:24]
-
-Trying to confirm that. Yes. Okay, cool. He is in fact one of the organizers of Local First Comp, so that, that [52:47]
-
-**Mark:** Oh, that's cheating. Accepting your own talk. [52:52]
-
-**Carl:** Right. [52:55]
-
-it feels like he's very all in on building the future of local first. So Very cool. [52:55]
-
-## Outro
-
-**Carl:** Alright, that's all we got for you this month. Thank you so much for joining us. We will be back on. I'd say we'll be back on the last Wednesday of the month, but I think we haven't hit that for a minute, [53:02]
-
-**Mark:** I can already say that I, I'm still traveling. In fact, I will probably, I'm pretty sure I will be at a conference on the last Wednesday of next month. So we, we may need to bump it back a few days. [53:12]
-
-**Carl:** recording time, TBD usually the last week of the month. and we will be back in your podcast feed just as soon as we can after that. I hopefully will get it up on Monday. We gather sources from this week in React bites.dev react status next JS weekly, the React JS subreddit and herein Reactiflux from the Tech news and reads channel. [53:22]
-
-And also sometimes directly from people publishing, but that's a, that's an noisier signal. If this is a show that you get value from and would like to support, best way to do so is by submitting a review on whatever platform you listen to and by telling your friends and coworkers about it. Thanks so much for listening. See you next month. [53:41]
-
-**Mark:** Take care. [53:56]
diff --git a/src/transcripts/tmir-2025-06.md b/src/transcripts/tmir-2025-06.md
deleted file mode 100644
index ecb8cf6..0000000
--- a/src/transcripts/tmir-2025-06.md
+++ /dev/null
@@ -1,361 +0,0 @@
----
-title: "TMiR 2025-06: kinda quiet tbh. ES2025 finalized, new Safari"
-date: 2025-06-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-We had some problems with transcript generation this month, downstream of the audio recording issues. Sorry! Fixed for July.
-
-- Job market [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
-- New releases
- - Shadcn
- - updated Calendar component
- - Moving from \@radix-ui/... to radix-ui
- - [Recharts v3.0](https://github.com/recharts/recharts/releases/tag/v3.0.0)
- - [Vite 7.0 is out!](https://vite.dev/blog/announcing-vite7.html)
- - [Biome v2](https://biomejs.dev/blog/biome-v2/)
- - [Announcing Oxlint 1.0 \| VoidZero](https://oxc.rs/blog/2025-06-10-oxlint-stable)
- - [Prettier 3.6: Experimental fast CLI and new OXC and Hermes plugins!](https://prettier.io/blog/2025/06/23/3.6.0)
- - Experimental "fast CLI" support, first discussed [Nov 2023](https://prettier.io/blog/2023/11/30/cli-deep-dive) 👀
- - [Jest 30](https://jestjs.io/blog/2025/06/04/jest-30)
- - [React Native 0.80](https://reactnative.dev/blog/2025/06/12/react-native-0.80)
- - [Safari v26 beta](https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/)
- - [Apollo Client 4 RC1](https://github.com/apollographql/apollo-client/releases/tag/%40apollo%2Fclient%404.0.0-rc.1)
- - May actually ship pre-compiled with the React Compiler ([discussion with Lenz and Joe](https://bsky.app/profile/phry.dev/post/3lsl7w4ynjc2v))
-- [Sponsored by Infinite Red](https://infinite.red/)
-- Main Content
- - Mark's "[The State of React and the Community in 2025](https://blog.isquaredsoftware.com/2025/06/react-community-2025/)" ([slides](https://blog.isquaredsoftware.com/2025/06/presentations-react-community-2025/))
- - Remix direction?
- - "[Disillusioned with React Hooks](https://x.com/mjackson/status/1937979887815692465)"
- - "[I can break signals quickly, don't use them for real apps](https://x.com/mjackson/status/1938362165221523542)"
- - [React Router "Open Governance"](https://remix.run/blog/rr-governance) (and [governance doc](https://github.com/remix-run/react-router/blob/main/GOVERNANCE.md#steering-committee))
- - [Debate over Radix UI status](https://x.com/colmtuite/status/1935629877069172861)
- - [Shadcn has thoughts](https://x.com/shadcn/status/1936082723904565435) on switching component libraries
-- ⚡ Lightning round ⚡
- - [Towards React Server Components in Clojure, Part 3](https://romanliutikov.com/blog/towards-react-server-components-in-clojure-part-3)
- - Dan's latest posts:
- - [Progressive JSON](https://overreacted.io/progressive-json/)
- - [How Imports Work in RSC](https://overreacted.io/how-imports-work-in-rsc/)
- - ES2025 spec released. [What's New in ES2025?](https://2ality.com/2025/06/ecmascript-2025.html)
- - [The Future of React Native Graphics: WebGPU, Skia, and Beyond ](https://shopify.engineering/webgpu-skia-web-graphics)
- - [Open sourced identity](https://nodejs.org/en/blog/community/2025-pride)
-- Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [React Nexus](https://reactnexus.com/) July 3-5 Bangalore, India
- - [Big Sky Dev Con](https://bigskydevcon.com/) Aug 2 Bozeman, MT, USA
- - [Kansas City Developer Conference](https://www.kcdc.info/) Aug 13-14 Kansas City, KS, USA
- - [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025. Wrocław, Poland
- - [WaysConf](https://www.waysconf.com/) Sept 16-17
- - [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [SquiggleConf](https://squiggleconf.com/) Sept 17-18 Bostom, MA, USA
- - [React Conf is back](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Oct 7-8, Las Vegas, NV, USA
-
-# This Month in React: June, 2025
-
-[00:00] **1-vcarl:** Hi, Carl here. Just a quick note before we get into this episode. We had a little bit of an issue with the audio recording, so the quality is a little bit lower than I usually go for. Sorry about that. We'll do better next month.
-
-[00:11] Hello everyone. Thank you for joining us for the June edition of this month in React, where we recap and digest recent developments in the ever evolving react and web ecosystem. We are coming to you live here in Reactiflux, the place for professional React developers.
-
-[00:27] We're supported by infinite red. Consultancy that works in React Native.
-
-[00:31] I'm Carl, a staff product developer and freelance community leader here in React Plex, where I run community programs like these events and build tools to help keep the community operating.
-
-[00:41] **2-acemarke:** Hi, I'm Mark. I maintain Redux. I work at Replay.io io and I apparently spend too much time debating the React team's documentation and communication.
-
-[00:51] **1-vcarl:** Endlessly!
-
-## [00:52] job market
-
-[00:52] **1-vcarl:** Start off with a little bit of job market news. I don't know, maybe we should stop doing these. 'cause I feel like it's not really in crisis anymore and it's not really making any dramatic shifts and I feel like I just keep giving about the same update every month. But yeah, data from Indeed trended up for the first time in a while.
-
-[01:12] True up.io, which also. Attempts to answer about the same question in terms of like, are people hiring in tech shows a slightly more positive trend. So I think that might be like giant people are using Indeed and they are not hiring as aggressively in tech for tech roles and everyone else is using a random smattering of hiring tools and they are hiring. So I wonder if that's like a big tech versus little tech dichotomy. I don't know. That's not based off too much concrete in summation at all.
-
-[01:43] The layoff charts for June are the best that they've been in a year and a half. Fewest number of people laid off by a decent margin and fewest companies running layoffs again by a pretty decent margin, about half for each. Lowest five 50%. So that's good. That's nice. I'm not sure if anecdotally feels that much different, but yeah. I don't know if you disagree, lemme know.
-
-[02:08] We're gonna change up order a little bit. Previously we've done on job market, the conferences and the releases. I'm gonna throw conferences back at the end because I could tell in the data that people were skipping through it. So we're gonna move it.
-
-## [02:19] New Releases
-
-[02:19] **1-vcarl:** Yeah. New releases.
-
-## [02:21] ShadCN
-
-[02:21] **1-vcarl:** Shadcn pushed out an updated calendar components. In the release notes, they included like a, a code mod to move imports from at rad cy slash whatever to just rad, cy, like top level like barrel import kind of thing. I don't know what that's about. I didn't really see any new releases from RadixUI that mentioned that.
-
-[02:40] So like I don't really know why that shift is happening, but like, okay, cool. That seems fine.
-
-[02:44] **2-acemarke:** A couple other things about RadixUI UI later on in the discussion.
-
-[02:47] **1-vcarl:** Yeah. Oh yeah. We've got some main content chatter about them. Just like some Twitter threads, debating, usefulness and whatever. Yeah, more of them later.
-
-## [02:55] rechart
-
-[02:55] **1-vcarl:** Recharts has a major release for the first time in a long time. Their last major release was January 4th, 2023. So two and a half years. That's a while. Recharts is not a library that I'm often happy to use, but it is a library that I often use because it just makes charts pretty easy. Not always as powerfully and flexibility as I want, but, it's good enough. It's pretty great.
-
-[03:16] The big thing that caught my eye in these release notes was they're claiming it's now accessible by default, so you can tap into it in these arrow keys to navigate it. So that's nice. Accessible charts are hard.
-
-[03:27] Most people don't do them, so getting it in the default is lovely. That's, that should help a lot more charts be access, and then Mark feel like you'll have more to say on that.
-
-## [03:37] vite 7
-
-[03:37] **2-acemarke:** Maybe so, so Vite 7 just came out. I've actually been having a little bit of trouble just trying to keep track of some, some of the releases, it feels like they've, they've really sped up some of the development.
-
-[03:49] They've bumped their, their node version support. Part of that is because they want to make use of the relatively recent node support for requiring ESM packages. In other words, importing an ESM module from a CGS module. Which was always the, the sticking point for a lot of the ESM common JS compatibility.
-
-[04:10] So they're actually distributing e and Vite 7 as ESM only, which. It feels like a fairly big step in the progress of, you know, the ESM ecosystem. They're also changing the default browser target to use the baseline, widely available preset in terms of browser features. They also now have some better support for the environment.
-
-[04:35] API, I'm still a little hazy on what exactly that does. My understanding is it, it allows you to ultimately generate bundles for different target environments, I believe is the best way to put it. So Vite 7 feels like it's a fairly big release.
-
-[04:51] **1-vcarl:** We had talked about the environment a while ago. I also don't really understand it too well, but definitely like deep in the weeds for library authors or, I don't know, framework authors. I've heard some positive things, but yeah, it seems esoteric.
-
-## [05:06] biome
-
-[05:06] **2-acemarke:** Meanwhile, we also have a slew of new formatting and lint tool leases, all seemingly with an emphasis on making things go a whole lot faster. First off Biome, which is, you know, formerly known as Rome back in the day, just released a version two, which is a fairly big deal, partly because they're, they now actually have some type aware linting rules.
-
-[05:31] Part of the issue here is that I. Up until now, the only option for doing types based linting was to use the TypeScript ES lint package, and that involves using the TypeScript compiler actually compiling things. And so it's kind of slow, and I don't know exactly how they've managed to implement this, but Biome now has some form of lightweight type analysis that does not appear to rely on the TypeScript compiler.
-
-[05:58] And so they've used that. To implement things like the no Floating Promises Rule. Now, it does not appear to be anywhere near as comprehensive as what TypeScript ES lent supports, but it is an interesting step in that direction.
-
-## [06:11] Void Zero
-
-[06:11] **2-acemarke:** Meanwhile, Void Zero, which is the VC backed company behind now Vite and other related build tooling development has released Oxlint 1.0.
-
-[06:24] So we have another lint tool that is a competitor to ES lint. They're claiming they have 50 to 100 x speedups and built in support for over 500 ES lint rules. And they say it's being used in a number of major companies. So if Linting is a particularly slow portion of your build pipeline. You may wanna check that out.
-
-## [06:45] Prettier
-
-[06:45] **2-acemarke:** And meanwhile, prettier 3.6 is out and they've been working on an internal rewrite of their existing CLI to try to speed it up as well. It's not a, it's not a rewrite and rust, it's just finding more efficient ways to do the same work in JavaScript. So the general theme here is people want to do linting faster.
-
-## [07:07] jest
-
-[07:07] **1-vcarl:** Yeah, we've got a new release, new major release from Jest as well. I think we had teased this the other day because they had a beta out. But yeah, first major release in three years. Again, faster perf, faster module resolution with some better ESM support. I know that generally like crawling your modules is one of the slowest is like, you know, broadly one of the slower parts of all of these bundling linting testing, whatever tools.
-
-[07:34] I wish I knew a little bit more details about the internals of like how just versus Vitest do it differently. 'cause my sense is that J is like heavier weight. It like does more, is more, I don't know, doing more on your disk and like crawling the condenses and all of those kinds of things. Yeah. So like one more place where there's a focus on performance in our build environment.
-
-[07:56] **2-acemarke:** Faster build tools, always a good thing.
-
-## [07:57] rn 0.80
-
-[07:57] **2-acemarke:** Those who in the audience may have noticed that MO is not here this week. He had a prior commitment and wasn't able to make it. So I will have to do a poor job of filling in and describing some of the React native changes. React Native 0.80 is out and it looks like the two biggest things out of this are they have frozen support for the legacy architecture.
-
-[08:18] I believe one of the recent releases made the new architecture default. So they are, they're seizing work on the legacy architecture, and this also brings support for React 19.1 as well. Now along with that, I believe the current version of the Expo SDK, version 53, does not have support for this directly yet.
-
-[08:41] If you want to use React Native 80 with Expo, they do have a canary version of the SDK that you can try out at the moment. But full support, I believe is. Or is planned that Expo SDK 54 coming out later this year would have support for React Native 0.81. So good luck trying to juggle those.
-
-[09:03] **1-vcarl:** Yeah, I know Expo has visibly been like focusing on release cadence.
-
-[09:07] I feel like for the last year or so, it seems like they've just been releasing something, being constant. And I know that Mo has talked previously about React Native working to have a more frequent release cadence, which is also has been very apparent. Kudos to Expo for like still being able to address this. Even if it's only in a pre-lease version, we can still test it out.
-
-[09:28] And also just like, it seems like it speaks well to the cadence that they're able to hit that they are, Expo is just saying like, yeah, we'll catch the next one because that's how fast it's gonna come out. I do wish Mo was here 'cause I feel like I see references here that make me curious to have an expert explain a little more.
-
-[09:45] They have a good post referenced in these release notes, moving towards a stable JavaScript API. I would love to hear Mo talk about how they are getting rid of JavaScript deep imports, so that, you know, basically just like saying, here's the public API stop importing things from deep within the project, which makes sense that if you let people import whatever the heck they want from inside of your package, then yeah, you just don't have a public API and you have to support literally everything. Everything is a break and change. Seems really cool. We'll have to have Mo catch us up next month.
-
-## [10:15] webkit 26 beta
-
-[10:15] **1-vcarl:** Yeah, this is a big one that is, I wish I had slightly more context for, but WebKit Safari version 26 is in beta. They're jumping from version 18, I believe it was all the way up to 26. So that all of the different, you know, iOS, whatever technology things can all be in sync.
-
-[10:33] This was announced of a WW BC 25 keynote. Yeah, so like Mac, os, iOS, iPad os, vision os and Watch OS are all now version 26. And so is Safari because the browser is also an operating system. Vision's a pretty large update and it has like all sorts of things from like cutting edge. Now you can use a model.
-
-[10:54] HTML tag, if you're Envision OS to render a 3D model all the way. So like that's very cutting edge, like future looking high tech, whatever. All the way back to you can also use SBGs as your favicon. A feature that like many other B browsers have had for a decade. So they're like both pushing the envelope and playing catch up.
-
-[11:14] Yeah. Safari has the di very different release cadence from other browsers. It's much closer to like the old style release. Cadence as opposed to how Chrome and Firefox and Edge are all like Evergreen, constantly updating. So I guess it makes sense that we're gonna have such a huge, massive dump of features, but like definitely check it out because they've got all sorts of stuff.
-
-[11:34] HDR images, web GPU, lots of CSS changes, lots of, you know, new standardized APIs, standardized job J JavaScript, APIs, all sorts of stuff. Finally, Apollo client just shipped a release candidate for version four. The release notes for this version don't have like a consolidated list of everything that's changed, but if you scroll back some, and you look at some of the lists of the prior alphas, it's clear that the, the Apollo team has been very, very busy and I know that.
-
-[12:05] In some discussions with Lens, who is my fellow Redux maintainer, but also works on Apollo client as his day job. They've been doing a lot of work to try to improve some of, and some of the packaging setup that had been, that had stuck around for years. One interesting side point out of this is that there's a good chance that Apollo client for might actually ship pre-compiled with the React compiler to try to optimize some of the internal hooks and components in the library.
-
-[12:34] There was a really interesting discussion thread on Blue Sky between Lens from Apollo and Josepha from the React team where they were discussing like, should libraries go ahead and ship like React compiler pre-compiled bundles already? Does it make sense to wait until some of the compiler runtime pieces are more stable, so clear, like.
-
-[12:58] This is very new and new and unusual territory for all of us library maintainers, and so it's interesting to see Lynn's trying to figure out some of these things that for the rest of us, yeah. That question of whether libraries should be pre-compiled with the React compiler definitely seems like a big open one in the ecosystem.
-
-[13:18] Cool. Alright. We are sponsored by Infinite Red. We are an expert React native consultancy that's been around since 2015. I. They're our only sponsor right now, in part because very few companies do as much as they do for the ecosystem. Just they, I don't know of anyone else who's done it quite so much for quite so long.
-
-[13:34] I've been seeing the name Internet Red around for as long as I've been in React and around React. React Native, which goes back all the way back to like 20 14, 20 15, they host the largest React Native podcast. They organized the largest React native conference in the us. They only do React native and have built over 75 apps for companies from startups to the biggest in the world, other than being great people who've done the great things to the ecosystem.
-
-[14:00] It's a team of about 30, mostly developers, mostly with more than 10 years of experience, and something like half of them have been there since the company was created. So just, you know, dev shop with Longevity. A dev shop with loyalty to its employees. What wild, they aren't just a feature factory. They will work alongside your devs and help you develop your own expertise.
-
-[14:20] So if you're spinning up a new product, being React native and want some help in the ground running, definitely give them a ring intimate top red. Cool. Okay. Into our main content. Start us off with your posts and talk. Hi. Yes. This is the part where I go off on things for a while, so if you, if you've been listening to the podcast for a while, you know, following me on Blue Sky or something, I've been involved in a lot of discussions and had a lot of opinions about, I.
-
-[14:44] A number of the interactions between the React team and the community, as well as a lot of the common misconceptions that have been unfortunately running around in a lot of community threads for a while now. It seems like pretty much every time you open up a discussion, for example, about Next.JS, there's complaints that the React team has is, you know, too close to next.
-
-[15:06] Or that Elle invented server components just to, you know, just to make money. Or why is the React team doing all these server things? Does the React team even care about, you know, single page apps anymore? And. A lot of this stuff has been going on for a while, all the way back in January and February when some of the CRE React app deprecation stuff was going on.
-
-[15:28] I kind of got fed up for a while and I was writing an extremely long blog post that I never actually published. I did a lot of research. I wrote a lot of words. It was cathartic. In reviewing it, I concluded that publishing it probably would've burned some bridges, even if the content there was accurate.
-
-[15:46] But there was, there was some good historical information in there and a number of folks said that it would be worth, you know, trying to publish that. Anyway, so I had a chance to speak at React Summit in Amsterdam a couple weeks ago, and my talk there was actually directly based on some of the content in the post and.
-
-[16:07] I decided it was worth trying to revisit the draft that I never published and extract the info that was relevant to the talk and hopefully make some of the points that I'd originally tried to think of, but, you know, maybe in a slightly more tact, tactful and less inflammatory kind of way. So really the the post and the talk.
-
-[16:28] Are trying to push back on a lot of the myths and misconceptions and FUD that have floated around in the React community for the last few years, but also point out some places where I think the React team's communication has has kind of fallen down. So a lot of people get confused about. The relationship between the React team and the next team who actually invented server components, why they were invented.
-
-[16:55] So as usual, a good portion of the talk and the post are basically a history lesson. You know, I tried, I did my best to try to recap, as I understand it, the origin of server of server components, the timeline of when they were invented, basically that the React team invented them while they were still at Meta, before Versal ever got involved.
-
-[17:15] And that it was something the React team invented because they ultimately, they saw the infrastructure that Meta had for server side rendering and data fetching. That was always very specific to meta and it really couldn't be generalized. And so server components was an attempt to. Implement kinda like a generic version of what Meta had for its own infrastructure, but because Meta had that infrastructure, they really couldn't iterate and Alpha test the features the way that they had everything else.
-
-[17:47] They ended up reaching out to Versal and getting Versal to build out the React team's vision of what they wanted to do. So a lot of this was me attempting to push back on the Versal invented server components to make money narrative. But then I also ended up addressing some of my points of concern where the lack of documentation about server components.
-
-[18:11] Has been a point of confusion. People not understanding when do I use them, how much should I use them? Is the React telling me to use them or are they optional? As well as a lot of the, the back and forth about why are the docs pushing the concept of frameworks so hard. And so I went into some details on my understanding of the React team's rationales for actually trained to say frameworks should be the default way to use react.
-
-[18:39] I put a lot of effort into it. I hope it's been informative and the feedback to the post and the talk have been pretty good. Dan Abramov actually retweeted it and basically said that, you know, he, he had a couple nitpicks about the way I described some of the timelines and bits of info, and he actually passed me some corrections on the side, which I tried to, to fill in, but he seemed to think it was generally accurate, and also he said that he'd been kind of stuck.
-
-[19:06] Debating whether to write his own history post, and he might end up being able to write one. Now that I've done most of the heavy lifting on it, that at least tells me I was directionally accurate. I. Like I can't have been too far off if he wanted to correct me on. So I don't expect that my me writing a post and doing a conference talk is going to silence a lot of the confusion, but at least I've done my best to try to clarify things.
-
-[19:33] So hopefully we'll see. Yeah, I think it's really valuable is to just check in every couple of years I'm like, what is. True. What did happen? What, what were the facts here? Oral history is very, very valuable. Sometimes capture some of that local knowledge. You put it in the paper. Yeah. I would be very curious to see what kind of oral history Dan OV can write though.
-
-[19:52] That's, uh, you know, you and I have been paying attention for a long time, but we have not been. Operating anywhere near the same level as Dan has for as long as he has. I would say, I hope it doesn't feel unfair to make the same claim for you, but useful post. Interesting. I think it's interesting too, how I.
-
-[20:10] As big as reactors, you know, the millions of people using it and relying on it and affected by it. At its core, the people in control of it is still like very countable. You know, it's not like unaccountable machine of like hundreds of people turning knobs and dials and you know, like it is at the end of the day, very much a core group of a handful of people making a lot of these decisions and doing a lot of this work.
-
-[20:37] And I feel like that's maybe, I don't know, that feels relevant when we're discussing its evolution and such. There's a team page in the React Docs and that page Curie lists about 20 people. There's about 13 to 15 at Meta at the moment. There's about five people at Versal, and then there's two or three sort of independent slash emeritus people.
-
-[21:00] So for example, Dan Abramov is not directly on the team at this point, actually. I'm not even sure if he's still listed on the page. I would've to double check. Sophie Alpert, who was at Meta for a number of years is still listed on the team page. I don't think she does a lot of development at this point, but still involved in discussions.
-
-[21:19] So it's about 20 ish people that would be considered sort of the, the core team that's separate from, you know, whoever might be doing like React native or other pieces like that. Right. React native is its own court team, which I think is larger. Yeah, I can confirm. Dan Amont was still listed on the meet between page second, so very highly along with me giving my talk.
-
-[21:43] Earlier in the afternoon. Tanner Winsley did a talk about couple different things. Some of it was, you know, pitching the various 10 stack pieces. So router query the upcoming 10 Stack start framework as well. But part of his thesis was that. Single page apps are still by far the dominant way to build React, even if there's been more of an emphasis on server side pieces in the last few years.
-
-[22:10] He really likes single page apps and a lot of his goal is to build good tooling that would be used by single page apps. I don't think any of the talks from React Summit are are online yet. I think they said they would try to have 'em online within two to three weeks after the conference. I haven't seen a notification that any of 'em were up yet, but I would definitely recommend watching Tanner's talk once the video for that's available.
-
-[22:38] Yeah, maybe we can, oh wait. Oh wait, I see a playlist. No, there's only five videos on it. Yeah. Maybe we'll be able to share those out next month. Yeah, they, I believe they, they're generally put up directly on get nation.org or.com, I think, rather than being listed in the YouTube channel. But we'll have to see.
-
-[22:57] Okay. I do see a React Summit 2025 playlist that has a couple of videos with like children views, maybe a ways to watch. Yeah. Moving on. Remix React router, going back to last month. So we've had a lot of. Back and forth between what is Remix, what is React Router? First we had React Router, the client side, LI Library.
-
-[23:21] Then we had Remix the SSR framework, and then we had Brian Forres announcement at React Conf, I think two years ago that most of the features in Remix we're going to migrate back to React router. And so React router gained things like loaders and a framework mode, and they announced that Remix was going into some kind of hibernation.
-
-[23:46] What was Remix is now basically all in React router, version seven I. And so Remix had kind of stopped development at version two last month. We talked about the announcement post where they said that Remix V three is coming. It's going to be very different. It's not just like, you know, upgrade to the latest version of React Features or something like that, but instead that it would be.
-
-[24:12] A new framework, one that actually is gonna use a fork of the pre-ACT alternative library, and with various emphasis on things like LLM based development and no bundling. That's the context for where things stand with Remix and react Router as a whole. So from there, Ryan for and Michael Jackson are both pr, you know, still pretty active on Twitter and they've been making a lot of comments that are either teasing things in directions that they want to go with Remix, but also, I'm not entirely gonna call them like clickbait or flame bait posts.
-
-[24:55] But kind of close stating a number of opinions about React itself that frankly make me very, very, very confused about what it is. Remix V three is actually even gonna look like. An example of this would be that Michael Jackson recently tweeted that he's now very disillusioned with React Hooks. You might even remember that Ryan Florence did one of the original talks at React Con 2018 where he helped, you know, demo React hooks for the first time.
-
-[25:22] And you know, granted, this is Michael's comment, not Ryan's, but I think it kind of shows their shift in mindset over the last seven years. Yeah, definitely big moves. I don't know, there's. They've been such big figures throughout my career. Like when I was learning React, I learned React rather in parallel, in like literally 2014.
-
-[25:44] And it's a little bit funny to have like been there for the whole saga because I've just watched them go like back and forth and back and forth on like what should be the API do. We care about data fetch at the router level. Just like watching them explore this and like watching their opinions shift and evolve and like double back and unfold in slightly different directions.
-
-[26:06] It's, I don't know, it is a bit of a surprise. I, I don't know. It is and isn't surprising to see Michael Jackson here come out against hooks. Also, I'll just say I was trying to confirm whether Michael Jackson still worked at Remix post Shopify acquisition, but I, I had a funny interaction years ago, managed to get enough of the profile in the ecosystem where Michael Jackson was following me on Twitter and we had a interaction during COVD about like lockdown stuff, where he was skeptical of lockdown.
-
-[26:36] And I was like, it's keeping people safe. And he ended up unfollowing me. So I don't know, like that felt like, that felt like a moment, that was a moment for me. I dunno, big famous person in the ecosystem unfollows you on Twitter. Like it stuck in my head and I don't know, it's just like, to me that feels like that feels relevant here as like point of contrarian and like, I don't know.
-
-[26:56] It's seemed since then that there was kinda like a closing off since then of him being like, Nope, I believe what I believe and I'm very confident that it is right. And like, screw all you. So I don't know. This is interesting. On the one hand, like hell yeah. Know your principles live by them and put the work in and like he's doing that.
-
-[27:16] Heck yeah. It's interesting hearing him say like, I don't like hooks. They're not great. And also like I relate to that. I don't know, like I, I started like learning hooks and like rewriting a bunch of code and using them professionally for a number of years. It felt like there was a right way to solve the problem.
-
-[27:35] It felt like I was, it felt less like I was writing code and like doing a thing and more like I was figuring out a puzzle somebody else had made with a right answer. And if you didn't get just the right answer, like you kind of had to start over. You know, it felt video gamey in that way of like, you make a bunch of progress and then you realize that you're at a dead end and it's like, let me start over.
-
-[27:54] I think that, you know, that feels like what he's complaining about here. You know, everything about them just seems so unnecessarily complex. But then he is also like down on signals, which is what a lot of other people are very pro. I'm also skeptical having used, I don't know there, I hear there are differences from event emitters, but I'm skeptical that the differences are that significant.
-
-[28:16] I keep hearing similar trade offs about circular dependencies and like event storm type of stuff. So if he's rejected like pokes and signals, which are the two top of mind ways of dealing with reactivity in React. And he's also stated the intent to use a fork of a fork of react in Remix D three. Yeah, whatever that's gonna be called.
-
-[28:39] I don't know. It's interesting. Like it doesn't sound like it's react anymore. It sounds like it's, he's gonna try and explore. The same problem space that React has been exploring, but doing so while challenging some of the core assumptions. So I don't know, it's space to watch. Yeah. And, and to be clear, like I'm, I'm not sitting here and saying like, oh no, Michael Jackson hate hooks.
-
-[29:00] He's a bad person. And anyone who's actually. Excuse, react, understands that hooks have trade-offs. They are not perfect. They have a different set of trade-offs than class components did. There are a lot of pain points, depths, arrays, data flow, you know, reactivity, mental models, et cetera. I am certainly very well aware that.
-
-[29:21] Hooks have their own set of trade-offs and flaws. But yeah, like my point, looking at the thread and this discussion is basically what you were saying, like Remix was a react based framework in version one and version two, Remix V three is not a React based. Framework, but given that they don't seem to like hooks and they don't seem to like signals at this point, I just honestly have no idea what it is they're even trying to build or what the feature set is, what the.
-
-[29:56] Usage patterns are supposed to be. I, I am just, I, I, I don't have a good mental model for what it is they're trying to do at this point, just by reading the discussion and the tweets. I believe they said that, I think there's a, a Remix jam conference coming up later this year. I think possibly in Toronto, if I remember hearing correctly.
-
-[30:18] I don't have a date for that off the top of my head, but I think it's this fall, and I think I've seen them say that they will have some announcements to make. At Remix Jam, which is understandable. I don't know, like I'm curious to see what they've got, but it, it doesn't seem like we'll really have a decent understanding until they make an actual announcement and then there's good documentation to look at, and then we could critique that.
-
-[30:39] Yeah. Right. So, I don't know. I'm curious. If they have my attention, for sure. It feels like they're being coy about it too. I feel like they have a lot more of this banged out than they're talking about and you know, I feel like there's a private group chat or like a secret repo somewhere that it'd be very fascinating to get access to.
-
-[30:57] Another little bit about this, they have posted about the open governance. Technical committee, steering committee that reactor adder will now have, I hold some skepticism, some level of skepticism just based on like the contents of this governance stock that you know, this governance announcement blog post, like notably the only people on the steering committee at inception, our existing Remix and react to router contributors, the announcement and the governance model.
-
-[31:28] Both focus very heavily on technical goals while discussing governance and how this is going to be open and like, you know, participant participatory from the ecosystem and whatever. They set up a lot of fences pretty early and strongly of this is what we care about. This is the direction we're gonna be going.
-
-[31:46] So like saying, not including outside people in the initial steering committee. And very aggressively setting direction while discussing open governance to me says this is visible governance, but I don't know if it's gonna be open to that, open to outside participators. Yeah. This feels reminiscent of like some of the working groups in the React ecosystem where they, we were just, you know, a little bit, they had blinders on.
-
-[32:11] They were gonna do their thing and they did their thing and that's great, but it's, it's not that open, it's not really that participatory. So this is, this is one that I've only partly read, but it feels like there's some amount of relevance. So the RAD X UI is a headless UI library that is pretty popular, especially because it's been used by the Shad CN component library.
-
-[32:36] But RAD X UI has been borderline unmaintained for quite a while. I believe the library itself got bought out a while back by a company called Work Os. And there's now basically a, a halftime maintainer of the library. And I've actually spoken to that maintainer before at a conference and he is like, yeah, I'm, I'm pretty burned out.
-
-[32:59] And I would almost rather like not even do anything with redix at this point. I. So there was some chatter in the last few weeks about whether people really ought to even be using it at this point. And apparently one of the original co-creators of Readex is now working on a competing package called Base ui.
-
-[33:20] And so basically saying that, look, Readex is unmaintained. Try using base ui, try using Aria kit. So I, I don't necessarily have a lot more feedback and thought and no, I have not seen Theo's video on it, so I have no opinions there. I will say that just because something is not getting active maintenance does not mean that the code is dead or suddenly more broken.
-
-[33:46] But I can definitely understand people's reluctance to use something that isn't getting, you know, like still getting active fixes. Yeah, I do have some opinions. I think that to some extent, like I don't really expect that much active maintenance from a like mature and wide used component library because there's not really that much changing in how you would develop a component library.
-
-[34:12] Like there has been so many component libraries. All like, you know, building on each other and exploring different directions and like pulling different types of abstractions and different types of like interactivity or whatever, different developer experiences. Going back for like long enough that it's pretty well trot ground at this point, and for a very long time it reacts life.
-
-[34:37] The patterns and the abstractions and the ecosystem they existed in were churning very heavily, and so it, it was not that surprising to see new component libraries coming out like every, you know, six months because there were meaningful differences. Every six months, you know, like, you know, is, is this written with higher order components or render props or hooks or, right.
-
-[35:00] Oh, you know, like when I first started, I started writing things with mix-ins, and then I was like, wow, mix-ins are, and then someone was like, oh, here's a higher order component. I was like, oh, that's cool. Let me try that. And then someone was like, here's a render prop. Here's a hook. You know? Now node and MPM support different modes of like consuming libraries.
-
-[35:21] And so now as a component library maintainer, I need to go refactor everything to support tree shaking or to be ESM only. So like there's just been so many big seismic shifts that like, yeah, we got used to that, but it's not really, that hasn't really been strongly the case for a minute now, like I would say, I.
-
-[35:44] 2022. I feel like it was when we had a, started getting, you know, as an ecosystem, the wisdom of how to use hooks had really settled down pretty well. Like we, we explored a lot of patterns and figured out things that did or did not work. And Hooks came out in 2018. 2022 is like four years of like playing with them.
-
-[36:06] And then that was three years ago. So like we've been, we've had a stable set of primitive tools within React. For doing abstractions for seven years now, which is absolutely, you know, that's longer than pre hooks. We only have three years before hooks existed. Four years, maybe five. No, it was 2013 when it came out.
-
-[36:25] So like that's more time with hooks than we had without hooks. So I don't know, like. I see this thread started with hot tape using Chad CN slash radix. The liability at this point, and maybe this is also an echo of a point that I try to drive home periodically on this podcast of like there are many different audiences using React and if you're an indie hacker than your constraints are extremely different from someone four years into maintaining a legacy application that's making tens of millions dollars for its parent company.
-
-[36:56] So like. This hot take sounds to me like someone doing small team build it and set it down projects, not somebody maintaining a legacy application. So like, sure, if you are trying to use the latest, greatest, sharpest leading edge tools, I. Is maybe that, not that name water, but I don't think it's getting rusty that quickly.
-
-[37:16] So like if you are not building a new thing every three months, I think it's probably fine. I dunno. Seems okay. And like, and you know, oh there was a really great, oh shoot, did I lose the link? There's a really great, I. Response that I saw from the maintainer of chat already, just baed it in. Lovely. Yes, thank you.
-
-[37:33] You just did that. Yeah. And he says, he says a lot of things that resonate with me that I think I have hit on here. Like here's what I'd suggest already. There's a quote here, here's what I'd suggest already using redix and prod. Stick with it. Starting a new project. Consider ics React Aria or Aria Kid.
-
-[37:49] All great choices. So like, yeah, that's, I would agree with all of that. And he closes this, what I'd suggest section with Shae is built for this code. Your own code can approve, rewrite or replace and like, yeah, that's the whole like reason for Shae and being built in the way it was, is that like it's not a library if you're unhappy with it, it's your code, it's hidden, your repo, you committed it.
-
-[38:11] So change it, commit something else. So I don't know. It seems cool. This seems, not that I have a lot of opinions on this, but at the end of the day, my opinion is like chill out, care less. Do the thing that's right for you. I guess in a very broad level, the JS ecosystem is entirely too prone to saying Tool X is dead because tool Y exists.
-
-[38:34] Yeah, I could rant about that. The human trend towards X is dead long lives. The new X on with Y? Yeah. Okay. I think we've beaten that to death now. Okay. Into our lightning round. I don't have too much to say on this, but I like it. This is a blog post. Of somebody writing React components. Enclosure, this is part three of his series, and that just seems to be, I don't know.
-
-[39:01] I love seeing people play around with server components more and playing around in different languages, in different room times. Is extra interesting, so that's cool. Just a great like use case, write up. There's been a subset of the closure script, whatever community that's used, react in their own way for many years now.
-
-[39:21] So seeing, seeing someone attempt to bring server components over in that direction's kind of cool. Dan Abramov has continued to crank out blog posts and he put out a couple more since we did our, our last podcast. He wrote one on progressive JSON, where he talks about how server components will progressively send over pieces of JSON and insert placeholders via suspense.
-
-[39:44] And then he did another post on how imports work with server components. And the majority of this post actually doesn't have anything to do with. Server components per se. It's really describing how the JavaScript module ecosystem works and then brings in some bits about how server components allow you to connect the dots between the client side and the server side, as well as enforce that certain code only exists on one side or the other.
-
-[40:13] We've got new ES 2025 out, which seems pretty good. Man, I, it, it took me a little bit to catch up on. Order of operations and what came out when. So this is everything. This contains everything that went to stage four, more or less over the past year. The most recent stage four is going out in 2026. So this what's contained here is Sync Iterator Helpers Promise.
-
-[40:40] Try some new set methods. Methods on the set primitive. That is JSON modules for imports. Import attributes and then a couple of like Redex updates for escape and modifiers and main capture capture groups. Sync iterators. Sync Iterator helpers are definitely the most like, interesting thing on this list to me.
-
-[41:00] Just like they're the, the number of times that I've taken a set or, you know, some iterable and then spread it out into an array so that it can map over. It is like constantly. I, every time I use an Iterable, I'm doing stuff like that because I like using e. Map and four each more than I like doing four ofs, so that's cool.
-
-[41:19] I'm excited to see that. Just being able to natively map over Iterable is lovely and I love it. One thing that's probably worth noting is that apparently the iterator support is, might be a little better for perf in some cases because it doesn't have to create a separate array every time you do like a filter or a map, right?
-
-[41:37] That's the main thing I think about every time I do that. Oh man, I'm just iterating a new array for no reason. New RA for no reason and kind of related promise that try is sort of a similar type of performance optimization, you know, performance micro optimization. This, the last time I was reading about it, the advantage I saw is that it lets you, it lets you ignore whether something is or is not a promise without skipping a tick.
-
-[42:03] If it is a promise, you know, and you do a dot, then like, okay, it's gonna consume a tick. But if it's not a promise and you wanna just run something afterwards. All of the like poly fills for something like promise try that would let you exit. Whether or not it returns, a promise would consume a tick. So now that, that's the advantage here is if it, if you're looking for that, it just is a little bit faster.
-
-[42:27] It's a little bit less talking. Then the, the set methods are a very nice, convenient thing. Sets now have built-in methods for intersection union difference, and a couple other things, which is something that really should have been in there from the beginning. Yeah. Definitely, there's so many more details on Axel Meyer's blog, so like definitely the dive into that and yeah, little teaser of ES 2026 is they have already sh shipped.
-
-[42:57] Well, they've already landed. Error is error, like an identity function for errors. So you can actually get like type safety in catch blocks. More easily. That is stage four, but it did not make the cutoff for S 2025, so that'll be out in 2027. There was a post on the Shopify engineering blog about the future of React Native Graphics Web GPU, SKIA and beyond.
-
-[43:21] The land of low level 2D graphics toolkits is complex with. Wrappers and abstractions and cross compat and all kinds of other layers of complexity. And so the post goes into into details on the existing React Native ski, a package for 2D graphics, how they've been able to add web GPU support to React native so they can do things like running three JS inside and some of the other upcoming improvements to React Native Skia as well.
-
-[43:51] Yeah, I, I know I've heard Mo talk about Yeah. A couple of times. See it getting, I don't know, broader. It seems cool. It's neat to see it still going, still chugging along. Cool. This is a personal plug. I wrote a blog post for the node js blog. I. It's June, it's Pride month. I'm proud. I have not always, I have accepted within the last couple of years that I am queer and began understanding what the heck that actually means.
-
-[44:18] I was asked to write a blog post for Pride and I pulled together one discussing open source and it's parallels with queer identity and how you know, we all take the labels that exist. Learn from them, incorporate them into our understanding of ourselves and use those as a springboard to find new things.
-
-[44:38] So, I don't know. I'm proud of it. I like it. It's a good post if you're interested. Check it out. Yeah, I, I've been checking the Twitter replies on the announcement and yeah. Yep. Those people still exist. They don't like it. So anyway, it's all I'll say on that. Closing with conferences, we have a quite a number of conferences coming up, like basically next week, July 3rd through fifth.
-
-[45:00] Is React Nexus in Bangalore, India. There is Big Sky devcon out in Bozeman, Montana. Which seems cool. I don't know. I I appreciate that. It's called Big Sky. I know that there's a, I think there's a big Sky National Park and I, I used to do astrophotography, so big skies are like near and dear to my heart. So this one just looks sweet.
-
-[45:22] I don't know. I don't have any, there's not no other reason beyond that for me to have an affinity foot, but I like it. So if you can get up to Bozeman, Montana. There's Kansas City Developer Conference, August 13th through 14th of Kansas City, Kansas. KCBC. 2025, which made me assume from the label that Kent c Dodds might be affiliated, but he is not.
-
-[45:42] It is not. Kent c Dodds conference. It's Kansas City Developer Conference. There is React Universe, September 2nd through fourth in Poland. Then September 16th and 17th, Wacon also in Poland back to back pretty much after Wacon. There's Cascadia Js up in Seattle, Washington, September 18th and 19th. So I think Squiggle conf is happening in Boston the exact same time.
-
-[46:07] I. Yeah, you've got SW Con, September 18th, 19th, Boston, Massachusetts. They are great. I plan to be there. This is slightly further afield for further down the line, but React Cons will be back in LA in Las Vegas. I. October 7th and eighth. So yeah, I was there last year and it was a pretty great time.
-
-[46:26] Definitely check it out. Although tickets are expensive and lottery system, so good luck. That's everything we got for you this month. Thank you so much for joining us. We will be back next month. I hesitate to promise on Wednesday because we have not done that in a minute, but maybe next month on Wednesday here in the live stage, or we'll be back in your podcast feed just as soon as we can after that.
-
-[46:46] Scheduling is hard. Yo scheduling is so hard. We gather sources from this week in React Bites. Do Dev React status, Next.JS Weekly the React JS subreddit. And here in react to plugs from the Tech News Andres channel. If you have any news that you wanna share with us. Tech Reads and News is a great place to do so, or you can send it to us at hello@reactiveflex.com.
-
-[47:09] If this is a show that you get value from and would like to support, one of the best ways you can do so is give it a review on whatever platform you listen to, listen to it on, and just share it with friends, share it with coworkers. Go to a meetup and say, Hey, there's this great podcast. I like. Yeah, thanks so much for listening.
-
-[47:25] We'll see you next month. Take care.
diff --git a/src/transcripts/tmir-2025-07.md b/src/transcripts/tmir-2025-07.md
deleted file mode 100644
index 0bc5808..0000000
--- a/src/transcripts/tmir-2025-07.md
+++ /dev/null
@@ -1,669 +0,0 @@
----
-title: "TMiR 2025-07: Vercel shakeups, new React Compiler docs"
-date: 2025-07-28
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-# This Month in React: July, 2025
-
-- [[01:17](#new-releases)] New Releases
- - [[01:20](#rn-reanimated-v4)] [RN Reanimated v4](https://blog.swmansion.com/reanimated-4-stable-release-the-future-of-react-native-animations-ba68210c3713)
- - [[08:46](#rn-ignite-toolkit-v11)] [RN Ignite toolkit v11](https://shift.infinite.red/announcing-ignite-11-bison-f2802a85f94d)
-- [[10:18](#main-content)] Main Content
- - [[10:21](#compiler-docs-are-merged-live-docs-and-config-api)] [Compiler docs are merged!](https://github.com/reactjs/react.dev/pull/7868) ([live docs](https://react.dev/learn/react-compiler/introduction), and [config API](https://react.dev/reference/react-compiler/configuration))
- - [[11:42](#expo-docs-say-its-on-hold-but-evan-bacon-says-expo-54-may-enable-the-compiler-by-default)] [Expo docs](https://docs.expo.dev/guides/react-compiler/) say it’s “on hold”, but Evan Bacon says [Expo 54 may enable the Compiler by default](https://x.com/Baconbrix/status/1949714155482841094)
- - [[12:45](#oh-no-more-function-directives-use-memo-and-use-no-memo)] Oh no — [more function directives](https://react.dev/learn/react-compiler/incremental-adoption) , “use memo” and “use no memo”
- - [[12:51](#directives)] [DIRECTIVES](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
- - [[13:13](#good-thread-on-some-history)] [Good thread on some history](https://x.com/en_JS/status/1948502925468467369)
- - [[14:19](#some-tech-discussion-on-the-complexities-of-making-react-compiler-work-with-oxlint)] Some tech discussion on [the complexities of making React Compiler work with Oxlint](https://github.com/oxc-project/oxc/issues/10048)
- - [[15:41](#directive-prologues-and-javascript-dark-matter)] [Directive prologues and JavaScript dark matter](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
- - [[18:01](#node-api-support-for-react-native)] [Node API Support for React Native](https://www.callstack.com/blog/announcing-node-api-support-for-react-native)
- - [[21:49](#vercel-shaking-things-up)] Vercel shaking things up
- - [[22:02](#leerob-is-at-cursor-now-five-things-he-learned-at-vercel)] [Leerob is at Cursor now](https://x.com/leerob/status/1943446393819177342) — [Five Things \\[he\\] Learned at Vercel](https://leerob.com/vercel)
- - [[27:43](#swc-creator-leaves-focusing-on-swc-for-a-while)] [SWC creator leaves, focusing on SWC for a while](https://x.com/kdy1dev/status/1941129219293225273)
- - [[28:01](#sam-selikoff-just-joined-to-do-content-and-stuff)] [Sam Selikoff just joined to do content and stuff](https://x.com/samselikoff/status/1943325592260092298)
- - [[28:23](#nuxt-acquired)] [Nuxt acquired](https://x.com/nuxtlabs/status/1942575789645640071)
- - [[29:58](#netlify-staff-eng-philippe-serhal-replies-to-the-vercel-deployment-adapters-rfc-from-april)] [Netlify Staff Eng Philippe Serhal replies to the Vercel Deployment Adapters RFC from April](https://github.com/vercel/next.js/discussions/77740#discussioncomment-13893373)
- - [[30:48](#ryan-carniatos-react-and-signals)] [Ryan Carniato’s “react and signals”](https://www.youtube.com/watch?v=VgGl9i-OBBI)
- - [[33:09](#react-native-unistyles-30-released)] [React Native Unistyles 3.0 Released](https://www.reactnativecrossroads.com/posts/introducing-unistyles-3)
- - [[35:39](#react-router-and-rscs-the-path-forward)] [React Router and RSCs: The Path Forward](https://remix.run/blog/react-router-and-react-server-components)
- - [[36:57](#parcel-writeup-for-server-components)] [Parcel writeup for Server Components](https://devongovett.me/blog/parcel-rsc.html)
- - [[37:26](#wip-vite-rsc-plugin-support)] [WIP Vite RSC plugin support](https://github.com/vitejs/vite-plugin-react/issues/531)
-- [[38:15](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[38:35](#corbins-history-of-react-through-code-deep-dive)] Corbin’s [“History of React Through Code”](https://playfulprogramming.com/posts/react-history-through-code) deep dive
- - [[39:06](#tkdodos-thoughts-on-when-usecallback-is-useless)] [TkDodo’s thoughts on when `useCallback` is useless](https://tkdodo.eu/blog/the-useless-use-callback)
- - [[39:26](#eslint-config-prettier-compromised-as-part-of-an-npm-supply-chain-attack)] [`eslint-config-prettier` compromised](https://safedep.io/eslint-config-prettier-major-npm-supply-chain-hack/) as part of an [NPM supply chain attack](https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise)
- - [[40:48](#expo-router-demo-by-evan-bacon-ai-rscs-expo-router)] [Expo Router demo by Evan Bacon AI \+ RSCs \+ Expo Router](https://github.com/EvanBacon/app-that-builds-apps)
- - [[41:16](#some-tech-details-on-how-meta-serves-react-pages)] Some tech details on [how Meta serves React pages](https://www.reddit.com/r/reactjs/comments/1ltbw2e/how_does_facebook_serve_react_pages/)
- - [[41:40](#nitro-image-library-for-react-native)] [Nitro Image library for React Native](https://github.com/mrousavy/react-native-nitro-image)
- - [[42:08](#a-very-hacky-way-to-test-rsc-components)] [A very hacky way to test RSC components](https://www.nico.fyi/blog/how-to-test-react-server-component)
- - [[42:31](#a-good-technical-dive-into-improving-inp-in-a-next-app)] [A good technical dive into improving INP in a Next app](https://medium.com/preply-engineering/how-preply-improved-inp-on-a-next-js-application-without-react-server-components-and-app-router-491713149875)
- - [[42:51](#extra-css-properties-in-react-native)] [Extra CSS Properties in React Native](https://github.com/facebook/react-native/pull/52284)
- - [[43:16](#chrome-137-adds-if-support-in-css)] [Chrome 137 adds `if` support in CSS](https://developer.chrome.com/blog/new-in-chrome-137)
- - [[44:50](#react-devtools-for-firefox-may-not-get-updated-due-to-review-restrictions)] [React Devtools for Firefox may not get updated due to review restrictions](https://bsky.app/profile/ricky.fm/post/3ltkxpo5ewk2i)
- - [[46:29](#both-oxlint-and-biome-are-investigating-typed-lint-rule-support-biome-v2-tsgolint)] [Both `oxlint` and `biome` are investigating typed lint rule support](https://www.solberg.is/fast-type-aware-linting) ([Biome v2](https://biomejs.dev/blog/biome-v2/), [tsgolint](https://github.com/oxc-project/tsgolint))
- - [[47:49](#remix-v3-dev-branch-containing-support-packages)] [Remix v3 dev branch containing support packages](https://github.com/remix-run/remix/tree/v3)
- - [[48:40](#react-native-wallet)] [React Native Wallet](https://blog.swmansion.com/introducing-react-native-wallet-90c1ee103d3e)
- - [[50:07](#deno-v-oracle-update)] [Deno v Oracle update](https://deno.com/blog/deno-v-oracle4)
- - [[51:23](#content-independence-day-from-cloudflare-theyre-blocking-ai-crawlers)] [“Content independence day” from Cloudflare](https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/) (they’re blocking AI crawlers)
- - [[52:04](#some-updated-static-hermes-perf-numbers-release-available-soon-being-tested-internally-at-meta)] [Some updated Static Hermes perf numbers](https://x.com/tmikov/status/1945348222110859500) release available “soon”, being tested internally at Meta
- - [[52:47](#state-of-html-survey-is-open)] [State of HTML Survey is open](https://survey.devographics.com/en-US/survey/state-of-html/2025)
-- [[53:26](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[53:29](#big-sky-dev-con-aug-2-bozeman-mt-usa)] [Big Sky Dev Con](https://bigskydevcon.com/) Aug 2 Bozeman, MT, USA
- - [[53:36](#kansas-city-developer-conference-aug-13-14-kansas-city-ks-usa)] [Kansas City Developer Conference](https://www.kcdc.info/) Aug 13-14 Kansas City, KS, USA
- - [[53:47](#react-universe-conf-sept-2-4-2025-wrocaw-poland)] [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025. Wrocław, Poland
- - [[53:57](#waysconf-sept-16-17)] [WaysConf](https://www.waysconf.com/) Sept 16-17
- - [[54:06](#cascadiajs-sept-18-19-seattle-wa-usa)] [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [[54:10](#squiggle-conf-sept-17-18-boston-ma-usa)] [Squiggle Conf](https://squiggleconf.com/) Sept 17-18 Boston, MA, USA
- - [[54:17](#react-conf-is-back-oct-7-8)] [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l)
- - [[54:22](#remix-jam-oct-10-toronto-canada)] [Remix Jam](https://remix.run/jam/2025) Oct 10 Toronto, Canada
-- [[54:33](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the July edition of this month in React, where we recap and digest all of the latest news and developments in React. React Native, and across the web. We're coming to you live from Reactive Flux, the place for professional developers using React. [00:00]
-
-I am a staff product developer and freelance community leader here in React Flux where I do community programs like these events and build tools to help keep the community operating. May be making more progress on one of those. So maybe I'll do a product announcement in the next couple of weeks or months maybe. [00:16]
-
-**Mark:** Hi, I'm Mark. I maintain Redux. My day job is at Replay where we've built a time traveling debugger and are currently trying to get in on the AI app generating craze. And other than that, I may moderate things and read too many articles. [00:32]
-
-**Mo:** My name is Mo. I head the mobile team at Theo. I'm an active member of the React Native community and I organize the React Native London Meetup and the React Native London Conference. Excited to be here. [00:46]
-
-**Carl:** Excellent. Yeah. We missed you Last month there was react native things to discuss. [00:58]
-
-**Mark:** We had no idea what we were talking about. [01:01]
-
-**Carl:** Not even a little bit. We basically just punted on it. Great. Cool. [01:03]
-
-I'm gonna skip job market stuff. I don't think I'm gonna do that anymore. 'cause like who even knows what's going on? The jobs are wild and the indicators are. Too fuzzy to really be that useful, I think. [01:07]
-
-## New Releases
-
-**Carl:** Mo, tell us about some React native new releases. [01:17]
-
-## [RN Reanimated v4](https://blog.swmansion.com/reanimated-4-stable-release-the-future-of-react-native-animations-ba68210c3713)
-
-**Mo:** Cool. So we recently had React Native Reanimated version four being released. So for those of you who are sort of avid React native developers, you'll know that React Reanimated is sort of the defacto way. To be able to animate elements, layouts and whatever you have inside of your React native applications. [01:20]
-
-So the team's been hard at work. Animates has been around as a package for, for several years now, and they've been iterating on it and making it better and better over time. There's a general push that you'll sort of know from the previous episodes over the last year or so towards sort of unifying React native and react in the web as much as possible. [01:40]
-
-And so CSS transitions and animations are sort of becoming a key part of Reanimated as well, so that the APIs and the way that you can animate things in Native world are as similar as possible. Obviously there's some limitations that can't make it one-to-one, but as similar as possible between web and mobile. [01:59]
-
-And one of the other things is now that we're in this world where you could use React native on web and mobile, trying to find a way to have performance. Web-based animations and transitions is quite important as well. And Reanimated has been working on this under the hood so that when you do use reanimated in your React Native universal app, it actually has performant animations on the web as well, not just on native devices. [02:18]
-
-One of the challenges in the past has been that it's not quite great on the web because it would use JavaScript to orchestrate animations. Not really great, and really, really bogs down the performance of your app on the web. So some good work being done there. A few other things to mention is that Worklet is a part of Reanimated as well. [02:41]
-
-It's, it's a way to basically allow some level of multithreading in your apps. It kind of formed as a need of reanimated itself, but they've made it sort of an open public API that you can access for other multithreading needs that you may have. So they're trying to move that. Across into sort of a separate library and start to separate that up because it's not just useful for reanimated or animations. [02:59]
-
-It's useful for a whole bunch of other stuff like background fetching and, and you know, computationally heavy tasks that you need to run behind the scenes. Other things to mention is that Reanimated used to be this huge package and once you had, you know, imported one thing and Reanimated, everything was imported and so obviously that affects things like your app bundle size. [03:21]
-
-They've now took an approach to make it modular so that you can import. And Bobs of Reanimated rather than the whole thing. Obviously it's not just a JavaScript sort of tree shaking thing that matters here because we're in Native World. There's also sort of the native compiled code and you need to be able to modularize that as well. [03:38]
-
-So it, it's not necessarily a straightforward process for the team, and I appreciate that. It was probably quite complex to decouple a lot of this code and separate it up into different packages, both on the native layer and the JavaScript layer. [03:54]
-
-**Carl:** What does that affect on a native. Package, I guess like app, total package size, or does it affect like startup performance and things like that? [04:04]
-
-**Mo:** It, it can affect both. Mainly the app total size that you would need to download is, is a key thing. It can also affect, like you say, the startup time, albeit startup time is largely sort of. Handled by Hermes, the engine that's been created for React Native specifically because it, it sort of optimizes to, to avoid large startup times as a result of having a big app bundle. [04:11]
-
-But it's really mainly the, the, the bundle size. And again, when we're going into this sort of web and mobile world where you use the same packages across the board, modularizing as well on the web, even though you'll have tree shaking, is going to be good practice so that you're not importing a whole bunch of stuff that you don't need. [04:33]
-
-Lastly, and I, I think this is. Something that everyone is quite passionate about in the React native ecosystem and has been a challenge is shared element transitions. So shared element transitions is sort of the transitions that you might be familiar with in the native world where an element is is sort of present and is animated from one screen to another. [04:49]
-
-So when you navigate from one screen to another, there's this sort of shared element. So it might be like an image you click on and you navigate to a sort of detailed view of that image. You have a navigation that happens in the background. But you want to have these on separate screens, but you wanna kinda keep that seamless expanding of the image animation as an example or transition. [05:08]
-
-This is very difficult to do in React Native. You can kind of achieve it in some hacky ways, but it's sort of on the app developers to figure it out. There's not been like a unified API that you can use and it's usually quite hacky and doesn't work most of the times. They are working on this, [05:26]
-
-**Carl:** would that be stuff like flip animations, like first, last, interpolate, play? [05:38]
-
-**Mo:** No, I don't think it would be flip animations. The examples that I would give is, you know, like in Instagram as an example, if you're on the, the search page and you see a set of posts that are sort of laid out in a grid and you click on one of those posts, it expands out and takes over the whole screen. [05:43]
-
-Right. [05:57]
-
-**Carl:** I meant more like would the hacky interpret in the hacky implementation of. what should be a shared element transition? Would that be, is that the kind of thing somebody might use flip for? [05:58]
-
-**Mo:** I'm not sure, I haven't actually seen flip, but there are some approaches where people have been sort of tapping into the native layer to be able to do that manually, but it's not gonna be quite extensible putting some tags and then using the native layer to do those transitions. [06:08]
-
-So there's a few different approaches that I've seen people do some sort of like third party libraries that people have created as POCs more than anything is how I've seen it done. The, the, the gist of it is that there isn't really like a. Standardized well-defined and like well tested API to do this in React Native. [06:20]
-
-And so that's what the Reanimated team have been working on. It's not out yet, but they've said that they're gonna be releasing it as part of this major release cycle. So four dot something will have. Some support for shared element transition, still TBC, but keep your eyes open for that one. [06:37]
-
-**Mark:** Cool. [06:52]
-
-Honestly, that whole discussion reinforces how many things people are doing that I have no experience with whatsoever. [06:53]
-
-**Carl:** Love that. Yeah. I guess just to close the loop a little bit on like flip animations, like it reminds me a lot of shared element here. 'cause I guess like shared element means that it doesn't like vanish. [06:58]
-
-You know, it's one thing persists. From this state to that state. That's my general understanding of it. And how I had done that in 2017 was, so you've got the current state, you've just rendered, you have something up and then you re-render and you get the new state. Then you have some abstraction that cracks the old state after the new state shows up and says, okay, this element is tagged with this animation, you know, indicator. [07:09]
-
-And that indicator has now gone to this element in this new state. It used to be here. Now it's here. Let's measure it triple eight, you know, the old size versus the new size. And then do Aran smooth transition, you know, generate a CSS animation to make it look like it's the same element. [07:37]
-
-**Mo:** Yeah, it gets a little bit more complicated in the native world because these are different sort of screens that are different view nodes on the native layer, you'd need to have a little bit more control over how you do that on the native layer, the native layer might override it. [07:54]
-
-If you write that JavaScript logic as an example, it definitely needed some native components to be able to handle it. Under the hood, the algorithm and the native layer will do something very similar, which is first screen, screen A has this size for this element. Screen B has this size. Let's look at the positions and interpolate the values and the, the zoom of it to match the target size as we're migrate, as we're opening up the new screen as an example. [08:07]
-
-**Carl:** Right. Oh, interesting. Okay. Sure. On native, there are things already doing that for you, so you don't need to hack into the, into that. You just need to actually support it. Cool. Makes sense. Okay. [08:29]
-
-**Mark:** Probably just as well. We really didn't have all that many new items and new release items this month, given that we just sort of deep dived on that one. [08:40]
-
-## [RN Ignite toolkit v11](https://shift.infinite.red/announcing-ignite-11-bison-f2802a85f94d)
-
-**Mark:** So one other thing from the React Native world, the Infinite Red has a very long running boilerplate toolkit called Ignite, and they just put out version 11. The big news for this one is it. Only sports, the new architecture. It's been bumped to E Expo, SDK 53, some changes to the theme implementation and they've made it bring your own state management. [08:46]
-
-They used to default to MobX State Tree and now they've tweaked it. So you can pick and choose how you want your state to be handled within the new app. [09:06]
-
-**Mo:** There's a little bit of context here, which is that the maintainers of this library, infinite Red, have been very opinionated on Malbecs being the best sort of tool for React Native. [09:14]
-
-State management there. There's some some reasons behind that. Like Mob State Tree is quite good in terms of sort of heavy memorization and that can really affect performance if you don't have stuff like that and React native or you're not careful. So I think they were trying to set some practices that they were used to. [09:25]
-
-**Mark:** And also I believe Jamon from Infinite Red was the maintainer of MobX State Tree for a number of years, and he either still is or recently handed it off to somebody I think. [09:41]
-
-**Mo:** Might be that he was maintaining it to some degree. Yeah. [09:51]
-
-**Mark:** So I mean there was, there was a very understandable preference there. [09:54]
-
-**Mo:** So the main maintainer of MobX and MobX State Tree as far as I'm aware is Michelle West Streett. [09:56]
-
-From WHO, who works at Meta, [10:00]
-
-**Mark:** I think Michelle handed off MobX State Tree to into Jamon a number of years ago. Okay, cool. Didn't know about that really. That's fair enough. [10:02]
-
-**Carl:** Oh, interesting. I didn't know that [10:08]
-
-**Mark:** he spiked MobX State Tree. And then it's like, okay, I've, I've proven I can build this, but I don't have time to maintain it would someone else like to? [10:10]
-
-Cool. [10:17]
-
-## Main Content
-
-**Mark:** Onto the main content for today? [10:18]
-
-## [Compiler docs are merged!](https://github.com/reactjs/react.dev/pull/7868) ([live docs](https://react.dev/learn/react-compiler/introduction), and [config API](https://react.dev/reference/react-compiler/configuration))
-
-**Mark:** The big news this month is that the React team has written completely brand new docs for the React compiler. Not only did they put them up as a PR this month, that PR has been merged and the new docs are now live. Previously there was just a single page under the installation setup section of the React Docs that gave some amount of details, and now the React compiler has its own top level section with multiple pages under both the learn and reference sections of the React docs. [10:21]
-
-These sections cover a lot of things. What is the compiler? What does it do? How does it work? Should I try it out? What build tools do it? Does it work with? How do I install it? How can I incrementally adopt the compiler? As well as some reference section information, talking about configuring it and some of the concepts it includes. [10:54]
-
-And even like if I'm a library author, should I pre-compiled my library bundle to make use of the compiler? So it's very clear that they've been looking at some of the discussion threads where people have complained that, you know, it doesn't feel like it's ready for adoption yet. I don't know if it, you know, I don't know how to configure it. [11:16]
-
-And they've taken a lot of that to heart and put together some pretty good docs to try to actually address a lot of those points. [11:34]
-
-## [Expo docs](https://docs.expo.dev/guides/react-compiler/) say it’s “on hold”, but Evan Bacon says [Expo 54 may enable the Compiler by default](https://x.com/Baconbrix/status/1949714155482841094)
-
-**Mark:** We noted that the, if you look at the expo docs, there is currently a section that says that their integration with the React compiler is on hold, but that may be superseded because I saw a tweet from Evan Bacon just earlier today where he said that we are actually going to enable the React compiler by default in Expo version 54. [11:42]
-
-And along with that, the compiler docs themselves in the introduction section. Actually say like, should I try the compiler and is it safe to use? And they specifically say at this point, we encourage everyone to start using it. It's still optional, but it's in release candidate. It is safe to use. It's been tested in production and we really would like people to actually try it out. [12:05]
-
-Of course they do. [12:30]
-
-Oh yeah. But I mean it's, it's a pretty big vote of confidence that this is not just a whim. That it is something they're very serious about, that it is basically ready for release and that they would like to see the ecosystem start adopting it. [12:31]
-
-**Carl:** Yeah, makes sense. [12:43]
-
-## Oh no — [more function directives](https://react.dev/learn/react-compiler/incremental-adoption) , “use memo” and “use no memo”
-
-**Carl:** I am not super thrilled about seeing more function directives being introduced here. [12:45]
-
-## [DIRECTIVES](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
-
-**Carl:** Like I'm on record for like the past two years here, being frustrated with introducing more and more directives, and so seeing now basically a compiler flag for memorize or don't memorize this. As the, uh, incremental adoption method. I just don't like it. It's, it feels like magic. It feels gross. I don't like it. I don't like directives. They scare me. [12:51]
-
-## [Good thread on some history](https://x.com/en_JS/status/1948502925468467369)
-
-**Mark:** Couple other compiler bits of news. There was some discussion on Twitter, I believe, where Joseph from the React compiler team gave a little bit of background on who had worked on the compiler, some of the timelines and some of the influences, and then the compiler right now has a couple limitations in terms of tool support. [13:13]
-
-One is that while the 90% of the compiler code is its own independent true compiler, currently the only way to integrate with that and actually use it is via a babble plugin shell around it, which also means you have to have babble. In your build pipeline, and a lot of people are not happy about that. We got rid of babble. [13:33]
-
-We use, we use SWC, we use, you know, whatever other, you know, ES build something that's not babble anymore. And so there's been lots of questions about, you know, when will they get around to offering a non babble integration? No timeline on that yet. But as a related part of that, the lint rules that React offers are also ES lint based. [13:55]
-
-## Some tech discussion on [the complexities of making React Compiler work with Oxlint](https://github.com/oxc-project/oxc/issues/10048)
-
-**Mark:** And we now have other winters like biome and oxalate that are not ES lint and not esent compatible. So there was a pretty good thread between the React compiler team and the oxalate team talking about like what would it take to make React compiler and the React ES lint rules. Runnable inside oxalate, and there's a bunch of low level technical details about, you know, js rust interop and, and some of the complexities that might be needed there. [14:19]
-
-So the answer is probably not anytime soon, but there's discussions about what it might take to make that happen. [14:48]
-
-**Carl:** Yeah, and circling back to your, you know, good thread with like some timeline and influences and whatever frustration I have, this is like such a, this is exactly the same problem that React and I guess web and like development in general has had for a long time. [14:55]
-
-But like all of that happened on Twitter and like that's great knowledge and such good resource. But the guy who asked the question asked it on his private alt. So like, if you are not one of the, you know, 1100 approved people that he has granted access to see his thoughts, you can't see what was asked, just the response. [15:09]
-
-So at least you can see the response. That's nice. But I wish they'd put something like this in like, I don't know, an introspective blog post or whatever. So. I'm just gonna keep shouting at clouds throughout this episode, I think. Cool. Cool. Let's move on though, [15:28]
-
-**Mark:** even before we get there. [15:40]
-
-## [Directive prologues and JavaScript dark matter](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
-
-**Mark:** I found the article I was looking for, it was indeed in Tech reads the news a few weeks ago. [15:41]
-
-This was in linking a post on directives, prologues and JS Dark Matter, which was an archeological explanation of how things like JSX, pragmas and function directives and magic comments. Have all been used to indicate to build tools, Hey, do something different with this code than what you would expect. [15:45]
-
-Just reading it. [16:05]
-
-**Carl:** Love that. That is actually really good. And like basically this is all just communicating with different levels of abstraction between like runtime and source code. So it's like, I don't know, the linter or the formatter or the, I don't know. I guess you don't really do tests so much there, you just do it elsewhere. [16:06]
-
-But the compiler, or transpiler compiler is now a fuzzy, overloaded term, and I guess they all make sense for one reason or another, but something about directives and the way that they like persist through. I prefer a magic comment, like at least a magic comment is like very clearly something like not runtime. [16:24]
-
-I don't know, something about it feels wrong. The [16:41]
-
-**Mark:** fact that a directive is just a string hanging out there. [16:44]
-
-**Carl:** I dunno. It seems weird. And since it is just a string, like why not a magic comment? Ah, I don't know. Maybe there was some kind of weird esoteric, like the compiler, you know, the, all the various compilers and whatever, transpilers, and ASTs transformers are all like, maybe they muck with comments and whatever, but also like the compiler requires that you put it first in your Babel so it gets the untransformed code anyway, so that doesn't sound right to me. [16:47]
-
-I don't know. Weird doesn't seem necessary. I guess the root of my angst here is that like when they introduced the "use strict" directive, like when they introduced the concept of a directive, they said, we're never gonna do this again. Like, don't do this. This is bad. We should, we shouldn't have had to do this, but we did because weird legacy concerns don't do any more of these. [17:13]
-
-**Mark:** And then the community decided, okay, now we got a new mechanism to play with. [17:32]
-
-**Carl:** We got like, how many do we have for React now? Like. I can think of four off the top of my head. [17:36]
-
-**Mark:** Client server memo. No memo. [17:40]
-
-**Carl:** Yep. Okay. Maybe four, but like, come on. That's 400% increase from one. Come on. [17:43]
-
-**Mo:** Now you can have two at the top of one file, which is gonna look weird. [17:49]
-
-It's gonna take some time getting used to that one. Wait, [17:52]
-
-**Carl:** can those even, are the, is that even compatible? 'cause it's gotta be, the directive has to be the first line. I [17:54]
-
-**Mo:** don't know how that would even work. Moving right along. [17:58]
-
-## [Node API Support for React Native](https://www.callstack.com/blog/announcing-node-api-support-for-react-native)
-
-**Mo:** Alright, so back into React Native World. The folks at call Stack have been working on some other projects under the, under the smoke screens, and it's some cool stuff that they've released. [18:01]
-
-They've basically enabled Node API support at a very basic, primitive level. They're, they're working, still working on this. They've made some good headway with this. So they're bringing Node API support into React native. Now, not to be confused with node itself, node API is basically like a mechanism by node js that allows you to use C based languages to interact from JavaScript code to call native code. [18:12]
-
-And so you can write native add-ons in CC plus plus. Even rust or swift. And then they can be used and ingested by JavaScript applications. So there's a few reasons for doing this and it, it really goes more into the internals of React Native. And you know what this means for library maintainers, for built tool maintainers, and for really meta itself as well. [18:38]
-
-But the two key things here is faster build times. And closer convergence with native web libraries that may already exist and be using the node API mechanism. So at a first level build times, and I think this is the bit that will affect users more than anyone else is. Basically in the rate of world today, most native modules are actually distributed a source. [18:59]
-
-So every time you make a build, you actually have to compile it all and do the build step, which is quite long. Building a typical rec native app somewhere around 10 to, if you've got a massive scale app, it could takes several tens of minutes to actually do the full build of the app, right? But it's a long, long time now. [19:22]
-
-You don't need to do this for like your development workflow typically, or that often, because you wouldn't change native dependencies every day. You would just do this when there's a new native dependency that's been introduced, but it's still a significant amount of time. Right? And so the idea is if we can get some of these prebuilt. [19:41]
-
-Using a mechanism like the node APIs, then we can bring this time down quite significantly. And so one of the things that they ran as a test was for a basic sort of React Native core app that you know is just having the basics of React native within it. They think that they could bring down. The build time to close to seven seconds, which would be insanely fast in comparison to what it's today. [19:59]
-
-So this could be some really cool stuff that's down that's coming down the line. The other side is that there is already an ecosystem of node API compatible sort of applications and run times, and so, so many sort of libraries. Web API libraries like Web RTC or Web Audio Canvas. These are implemented with node API. [20:21]
-
-Now, they're not going to be direct one-to-one mappings for native, but there is already an initiative to try to, to try to align on the web API spec. And so this is sort of another part of that puzzle. And so if you bring these two together, suddenly we can use sort of web APIs and React native, and it could be a really, really cool future to look into. [20:42]
-
-None of this is. None of this is sort of like fully there, and there's gonna be, this is a long term effort, but it's something that they announced this month, and it's quite exciting. [21:02]
-
-**Carl:** I've had enough struggles with native binaries on desktop where they're, you know, like intended to be compiled for just like, like mostly across, like upgrading, upgrading a version of that, or node versions or whatever. [21:11]
-
-But I, I've had enough struggles and complications there to be wary. Of what the actual experience of using this will look like. But this is, this is really cool. This just even having made enough progress at this to announce it and like meaningfully talk about it as a thing they desire is pretty cool. [21:25]
-
-Very hard, really hard problem. I'm curious how they're implementing it. [21:43]
-
-**Mo:** It's definitely not trivial. [21:48]
-
-## Vercel shaking things up
-
-**Carl:** Cool. Alright, moving on a bit. So there's been a bunch of Vercel things this week, a fair number of departures. I'm sure people are coming and going all the time and we just, you know, we can't get a comprehensive list of that. [21:49]
-
-## [Leerob is at Cursor now](https://x.com/leerob/status/1943446393819177342) — [Five Things \\[he\\] Learned at Vercel](https://leerob.com/vercel)
-
-**Carl:** But they, they had a couple of relatively high profile departures in the last month, starting with the most notable Lee Robinson, who has been there for. Five years, a long time. Was he there before COVID? [22:02]
-
-**Mark:** Not sure on the timeline. Like it, it felt like he'd been there much longer than that, but apparently it has only been five years. [22:15]
-
-**Carl:** Yeah. Okay. No, you're right because he, he put out a blog post. Well, anyway, I'll, I'll stop speculating on the timeline, but to me, he is highly identified. With Versel, like, you know, if I think of Versel, I think of, uh, Guillermo, Roush, and Leero, just like by volume of activity and like prolificness in content and social media interaction and blog posts and example resources. [22:21]
-
-So just all of it. So he has now left Versel and is working at Cursor, which like. That seems great, at least in terms of like mind share and hype and you know, alignment, potential, alignment with future, whatever. Cursors is definitely a really hot company right now. I've had some private conversations of with like, can they keep doing that? [22:45]
-
-'cause at the end of the day they're a fork of VS code and like fork of a large project with 30 people working on it. Which I think is in the ballpark of how many employees Cursor has versus like Anthropic, which is, you know, a giant, huge beast with all of the money. So like it's cool. Great for him. [23:05]
-
-Definitely there's a lot more like oxygen in the room in terms of excitement and like potential at cursor. I think so. Cool. I'll be keeping an eye on that. I use cursor. It's nice, so he'll still remain in my, I don't know, professional spheres. But yeah, he had a really good blog post that he put up called, UH, five Things I Learned From Five Years At Versa. [23:24]
-
-I appreciated it. His number one was go hard at work, then go home, and he closes it with, when I'm offline, I'm offline. I'm a hundred percent focused on my wife and daughter. To be clear, I still get this wrong sometimes. It's a never ending pursuit of work, life, harmony, takeaway. You can work really hard and set clear boundaries. [23:46]
-
-I'll say That's hard. I struggle with that. I don't, I don't have a wife, I don't have kids. So like in that section he talks about like responding to tweets from the beach on his honeymoon and like, yes, I want to believe that you can work really hard and set clear boundaries to where you're not working on vacation doing, you know, social media comms work from the beach, but also like if you're not there. [24:03]
-
-Like, people aren't gonna wait three days for you to get back from vacation to, you know, get the authoritative answer. Like, if they ask a question, then like, the person who is Johnny on the spot answering it in their time of need, like they are gonna get the, I don't know, the kudos, the energy they're gonna, you know, people are gonna start gravitating towards them for future questions. [24:27]
-
-I'm like, that's. This going so hard is how Leero managed to get that level of status, like in my own brain. And so I wanna believe you can work really hard and set clear boundaries. I'm not always so sure about that. I, I dunno. I wrote, I actually wrote a little blog post kind of on that subject almost exactly a year ago. [24:47]
-
-I'll link it here. I probably won't put it in the transcript. Just kind of talking about that general thing and like I, I had a kind of similar experience to what he describes here of like, going really hard and like poor boundaries and like burnout and all of the, a lot of the benefits, a lot of the costs. [25:06]
-
-And what I kinda realized is that like, I don't know that I could have achieved the kind of success that I got without that level of burnout and I don't know, poor boundary setting because like, it's because I gave. All of my attention to maybe not just work, like some of, a lot of my attention, you know, the full-time work, but also investing in things like reactive flex or just learning new tools and staying on top of the cutting edge outside of work. [25:23]
-
-Like that was really poorly boundaried and like fully throughout my twenties, I ignored a lot of myself. I just really think that that is, I wanna believe that you can succeed and achieve big success without giving up that kind of, I don't know, intimacy with yourself. But I don't know that you can, I don't know, it seems really hard. [25:50]
-
-And it, it just notable to me that like the only people I see talking about that and like saying things like, you can work really hard and set clear boundaries are the people who had poor boundaries, achieved success, and are now reflecting on it. So, I don't know. [26:09]
-
-**Mark:** Yeah. It, it is tough, but I, I have a, I have a lot of respect for Lee Rob and that the work and effort that he's put in, when I just think of the word derel, he is the first that comes to mind. [26:22]
-
-He, he's always, you know, omnipresent in any kind of Reddit or Hacker News or Twitter thread that mentions Versel and Next. And, you know, even if you maybe, you know, at times disagreed with, you know, what he was saying or representing the company wine, he absolutely like did a great job of being there and answering questions and, and being involved in reaching out. [26:33]
-
-It's definitely a loss for Versel and when I wrote my React Community article, you know, recently, I had a line in there about Versal had a large Dere team that updated the next docs, and he corrected me. It's like, no, there were two of us at that point. I was like, oh, whoops. I got that wrong. It seemed like you had a large team because you were doing so much work. [26:55]
-
-**Carl:** Right? So, yeah, I don't know. From the comment, from the, from chat, from re Sam, bit of taking advice from lottery winners, vibe occasionally like, yeah, that's, that's what it is. It sounds like survivor bias, things like that. Anyway, this is, we're already like kind of far afield from where we started here. [27:21]
-
-This was talking about Versel and some of their updates. This was a good piece. Lee Rob, wish him the best at cursor. I'll be paying attention still. [27:35]
-
-## [SWC creator leaves, focusing on SWC for a while](https://x.com/kdy1dev/status/1941129219293225273)
-
-**Carl:** The, uh, creator of SWC also left Versal. He's taken some time to, to rest and focus back on, uh, SWC again, so that's great. I'm not as familiar with him as a, you know, individual human, but I am familiar with s wc. [27:43]
-
-So cool. Good luck to him. Love that. [27:59]
-
-## [Sam Selikoff just joined to do content and stuff](https://x.com/samselikoff/status/1943325592260092298)
-
-**Carl:** And another prolific react ecosystem speaker and like educator, Sam Selikoff joined Versal to do content and some other things. His Twitter feed is all like, all about ramping up and like, you know, spinning up on a new team. So that's, that's a fun, that's a fun moment in time. [28:01]
-
-Team transitions and gathering context in a new spot. [28:20]
-
-## [Nuxt acquired](https://x.com/nuxtlabs/status/1942575789645640071)
-
-**Mark:** And then overall, and not, not react, but adjacent. So next is the view ecosystem equivalent to next Js. And Versel had already picked up, you know, rich Harris who builds Svel, possibly one or two other non-reactive framework authors as well. And VL actually just acquired whatever group or company has been behind N and is hiring all of the developers, including Daniel Grow, who I think is the, the lead. [28:23]
-
-Developer maintainer for N So you know, Versal is not just about react like they, they are sort of putting their money where their mouth is and trying to back many different tools that, you know, build apps and of course can be run on versal. That's [28:55]
-
-**Carl:** got me curious about what kind of like corporate structure is behind Nuxt. [29:11]
-
-'cause like, you know, if it's individual developers then like. You can't acquire that, you just hire them. [29:16]
-
-**Mark:** I think next Labs may be an actual company, but I don't know how much of a like profit seeking company it is versus some kind of little holding thing. [29:21]
-
-**Carl:** Right. I'm now, I'm on the next website. I see next UI Pro, A hub for managing apps. [29:29]
-
-So I guess like deployment and then like a visual editor. And I see some reference to courses and stuff too, so like, yeah, that sounds like a business. That sounds like they're selling products. Kind of a mishmash of various different open source monetization techniques there. So. Cool. Nice. That's good to know. [29:36]
-
-I appreciate that. Love someone who's trying to take a project and turn it into a business Relat. Another smaller update. [29:50]
-
-## [Netlify Staff Eng Philippe Serhal replies to the Vercel Deployment Adapters RFC from April](https://github.com/vercel/next.js/discussions/77740#discussioncomment-13893373)
-
-**Carl:** This is like barely an update, but I've been tracking A an RFC, actually an RFC that Lee Robb started back in April on deployment adapters for next from Versal, basically making it. [29:58]
-
-More robust and reliable, I guess, to deploy next projects to infrastructure that isn't hosted on Versal. So the, a staff engineer from Netlify gave a response that's pretty lengthy, pretty serious, you know, it's got like, you list six gaps and 10 questions and four suggestions, mostly minor suggestions. [30:13]
-
-It's just cool to see that moving along slowly and I question the momentum now that Lee Robb is no longer there. It's just really hard to hand off major projects like that, major initiatives like that. But yeah, that's cool. Neat. Love to see it. [30:32]
-
-**Mark:** Okay. Somewhat smaller item, but definitely worth calling out. [30:45]
-
-## [Ryan Carniato’s “react and signals”](https://www.youtube.com/watch?v=VgGl9i-OBBI)
-
-**Mark:** So Ryan Carniato, the author of Solid, is, you know, pretty much the world's foremost expert on signals as a state management mechanism. And there was a lot of back and forth and chatter, and I think we even referred to some of it in our, in our last talk about like Ryan for and Michael Jackson from Remix were kind of questioning like, why does Signals exist? [30:48]
-
-Why do you know? Why do these different frameworks look sort of the same? And I think somewhat inspired by some of those questions and discussion. Ryan put together a 10 minute video on React and Signals what every React developer should know about signals. And Ryan like me is very big on history and context and explaining how we got from past tools and decisions to current tools and decisions. [31:09]
-
-He goes into some, some of the history of signals, you know, they originated with early JavaScript frameworks like Knockout, but the concepts and implementation of signals have evolved significantly in the last 15 years ago. And so he talks about some of the actual technical advantages of signals. And then he also does some, some myth busting. [31:36]
-
-You know, he pushes back and says they're not magic. They do scale. A lot of other frameworks like Angular and View rely on signals to make them faster. And he also talks about comparisons between like, what's the difference between three ACT compiler and signals or reacts virtual dumb in signals. And I think what a lot of that sums down to is that in react. [31:56]
-
-The component is the smallest unit of update granularity, like you set state, at least one component will re-render the whole component renders, and then maybe only a few bit bits of it need to be applied, but you had to run the whole component to see what needed to change. Whereas with signals, it's this one value changed and it's more directly attached to the output. [32:19]
-
-And so only the bits of the output that actually relied on that need to be calculated. And it's not an earth shaking discussion, but given that there's been a lot of hype and discussion and arguing back and forth, it's a good overview. Looking at some of like. Some of the pros, cons, concepts, and myths around signals. [32:42]
-
-**Carl:** Yeah, I missed that. I need to give that a watch because I hold a number of myths and misconceptions about signals, and I would like to understand them better. Yeah. [33:01]
-
-## [React Native Unistyles 3.0 Released](https://www.reactnativecrossroads.com/posts/introducing-unistyles-3)
-
-**Mo:** Nice. Next up, we have another release. So we've been talking about this for a few months. On and off because it's been sort of an RC mode, but React Native Uni Styles 3.0 has finally been released. [33:09]
-
-Now there's a few points to sort of hit here. Uni Styles came out as sort of like a very performant, lightweight styling option for React Native because there's a lot of styling libraries that are quite complex and have a lot of. Stuff included within it. But the challenge with a lot of those is that it also comes with a little bit of a performance hit because you've got a lot more being bundled into your application. [33:21]
-
-Uni styles is, is sort of since then being this sort of lightweight JavaScript only implementation has has dug into this sort of performance space a bit more. And this newest release is really digging into the new architecture with with Fabric, which is the new render and it uses native code and c plus plus. [33:45]
-
-To basically bypass the JavaScript layer when possible and keeps us track of the styling dependencies in c plus plus, and we'll only update affected styles and components on the native layer as much as possible. Again, this is like some things are possible on the native layer. Some things aren't. In terms of styling and, and the visuals of it, but as much as it can possibly do, it does that in the native layer and avoids re-render. [34:03]
-
-The maintainer kind likens this to CSS on the web in that it's not handled by JavaScript, but it's a different layer that that handles it. On top of that, added a bunch of extra functionality through a babble plug plugin to handle things like theming, break points, orientation, font scale, and maybe even right to left styling if you need that for your app. [34:29]
-
-And so the by and large, the biggest thing here is that there is a performance boost and they've done some measurements to, to show how much of a performance boost you can get because of these safe three renders that would've previously been happening because of styling changes. Other noteworthy things to mention are that there's some new features around sort of variance or scoped themes and so on and so forth. [34:48]
-
-You can go read through the blog post in more details to understand what are the sort of more granular new features that exist. But also given that this is sort of a universal library that works on web and native, there is a new web functionality as well. Some web only styles, some pseudo classes that they've introduced and some support for class names that would be targeting the web. [35:10]
-
-So there's some stuff around web support as well, which is quite interesting. But yeah, that's Uni Cells 3.0. Give it a give it, give it a quick look. Cool. Love that. [35:30]
-
-## [React Router and RSCs: The Path Forward](https://remix.run/blog/react-router-and-react-server-components)
-
-**Mark:** Finally, we have a couple different, uh, react server component updates. The React Router team has been iterating for a while on their work in progress server component implementation, and they've put together a blog post describing a path forward, so they go through some details talking about the, and ways you would handle things like streaming UI or in lighting data in existing React router framework mode versus how you might handle it with their server component implementation. [35:39]
-
-And so there the summary is that. apparently they're going to revamp the framework mode to be built on top of their server component support. [36:10]
-
-They are still labeling the server component support as unstable, but they do want people to try it out and give it a shot. So looking at some of these examples, it looks pretty significantly different usage wise than say like the next app router. It maybe looks even a little more similar to how Parcel had almost like a pick and choose your own server component usage approach. [36:19]
-
-So it is very cool to see additional frameworks providing support for server components. As well as that we're starting to finally see some variation in how they might get used and not just. The way next does it is the only way to do it. [36:42]
-
-## [Parcel writeup for Server Components](https://devongovett.me/blog/parcel-rsc.html)
-
-**Mark:** Along with that, Devin Govett from parcel put together a pretty good article where he was talking about how parcel bundles, server components, and he goes into some background detail about like, you know, what is a bundle even do in the first place? How does it. You know, follow the, the module graph. How does it handle dynamic loading? How do the pieces fit together? And then talks about, okay, and since React server components is really a bundler driven feature, here's how server components actually rely and make use of some of those bundler aspects. [36:57]
-
-## [WIP Vite RSC plugin support](https://github.com/vitejs/vite-plugin-react/issues/531)
-
-**Mark:** And along with that, I think we've previously mentioned that there's been an in progress. Attempt to build RSC support directly into Vite's React plugin. And there's one person who appears to be steadily cranking away on trying to make that support possible. And I'm seeing a number of the to-do list items in the roadmap being checked off. [37:26]
-
-So I don't know how far along that is. But it seems like a pretty serious effort to make that happen. So the server component ecosystem is slowly filling out. [37:50]
-
-**Carl:** Yeah. Interesting. I see one of the to-do list items in that is moving waku to VJS plugin, RSC. That's interesting. 'cause I, I had understood, I mean, Waku was like. [38:02]
-
-A proof of concept implementation of like how to do a framework on RSC. So it's interesting to see that move from like custom one-off implementation to relying on a, you know, kind of delegating RSC support back into, back into Ved. Love to see that. That's cool.
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Okay, moving on to the lightning round. [38:32]
-
-## Corbin’s [“History of React Through Code”](https://playfulprogramming.com/posts/react-history-through-code) deep dive
-
-**Mark:** Lightning round. Corbin Crutchley, author of the Framework Field Guide ebook, put together a very lengthy deep dive, which I highly approve of, called the History of React through Code, where he goes back and looks at a whole bunch of different react features that were added over time and kind of argues that you know what these, the, these actually have sort of a. [38:35]
-
-Intellectual cohesiveness a like a design cohesiveness to them and that they, they all, it makes sense when you look at the sequence of, of features and how they were added. [38:56]
-
-## [TkDodo’s thoughts on when `useCallback` is useless](https://tkdodo.eu/blog/the-useless-use-callback)
-
-**Mark:** Meanwhile, TK Dodo, Dominic Dorf, Meister maintainer of React query, just put up a post today where he has some thoughts on when use callback is actually useless. [39:06]
-
-And I think his argument is actually, it's useless in a, in a lot more cases and you probably don't actually need it all that often. [39:18]
-
-## [`eslint-config-prettier` compromised](https://safedep.io/eslint-config-prettier-major-npm-supply-chain-hack/) as part of an [NPM supply chain attack](https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise)
-
-**Carl:** Cool. There was a NPM supply chain attack that was pretty interesting. I believe. The issue was that a couple of relatively high profile maintainers got phished, and yes, there's a phishing campaign on a typo, squatted, URL, which is NPN js.com. [39:26]
-
-So it's a couple of major. Maintainers got successfully phished through that, which then, uh, stole their NPM credentials and published malicious versions of packages. Yeah, so, uh, malicious releases included lin config, prettier. That's big Lin plugin, prettier. Think kit packager, core and nappy post install. [39:45]
-
-So the, like, most of those not so big. I, I haven't really heard of, heard about 'em, but yeah. Esly config, prettier, that's big. And they got version, they got major versions. 8, 9, 10. Eight, nine, and 10. Okay, so make sure you're not using version 10.1, 9.1 0.1. Anyway, if you're using those, check it. If you're using ES link config, prettier or ES link plugin prettier. [40:06]
-
-Make sure it's not a vulnerable version. Check your lock files. Yeah, that's not great. [40:29]
-
-**Mark:** I know one of the other redix maintainers got the phishing email and avoided it. It's definitely semi widespread campaign. [40:34]
-
-**Carl:** Wild. They must have hit so many people to get a couple of major vulnerabilities in. Cool. [40:41]
-
-## [Expo Router demo by Evan Bacon AI \+ RSCs \+ Expo Router](https://github.com/EvanBacon/app-that-builds-apps)
-
-**Mo:** So next up, very quick one. [40:48]
-
-You might've remembered the old expo router demo from last year's react conf, where they showed RSCs in the world of expo router for building an AI app. Something very similar to that is now an open source project that you can clone and play around with. So Evan Bacon has released a demo of an AI app that can generate. [40:50]
-
-With AI native components and stream them in with RSCs. It's pretty cool. So clone the repo, play around with it. It's an interesting little demo. [41:08]
-
-## Some tech details on [how Meta serves React pages](https://www.reddit.com/r/reactjs/comments/1ltbw2e/how_does_facebook_serve_react_pages/)
-
-**Mark:** There was a Reddit thread that was asking how does Facebook slash meta actually build and serve their React applications? And some former meta engineers responded with a few technical details talking about how they do a bunch of dynamic bundling, and they also use, I believe Hermes or static Hermes on the back end to pre-build some of the server rendering pieces. [41:16]
-
-So, you know, a little peek behind the curtain. [41:38]
-
-## [Nitro Image library for React Native](https://github.com/mrousavy/react-native-nitro-image)
-
-**Mo:** Cool. And we talked a little bit about Nitro modules over the months, the past few months, there is a new library that the Margie folks folks have been working on called React Native Nitro Image. And so this is built on top of Nitro modules. I was actually talking with someone this morning about some of the challenges with images on the native layer when it comes to loading them in React Native. [41:40]
-
-So this is very much welcome as a change to hopefully improve performance across the board for React native. [42:02]
-
-## [A very hacky way to test RSC components](https://www.nico.fyi/blog/how-to-test-react-server-component)
-
-**Mark:** One of the weaknesses of React Server components has been that there hasn't been a good testing story for them yet, or at least not one that I've heard of. Someone put up an article with a way to test them. [42:08]
-
-However, it's incredibly hacky and relies on overriding some of reacts internals, so it's probably not a good way, but it is a way to try to test them if you like. [42:20]
-
-## [A good technical dive into improving INP in a Next app](https://medium.com/preply-engineering/how-preply-improved-inp-on-a-next-js-application-without-react-server-components-and-app-router-491713149875)
-
-**Mark:** And then there was a pretty good article that gave, it went into a bit of a technical dive and deep dive on how a company improved the interaction to Next Paint Web Vital Metric in their app, and gave a bunch of very practical examples of problems they found in their app and ways that they, they addressed those. [42:31]
-
-## [Extra CSS Properties in React Native](https://github.com/facebook/react-native/pull/52284)
-
-**Mo:** Cool. Next up, there are some new styling properties that are being proposed to be added to React Native. So this is being done by Nishan Bede, who has been doing a lot of work in trying to bring some CSS styling into React Native and better support. This time there's a pr up that adds support for background size, position, and reply and, and repeat. [42:51]
-
-So this will be quite interesting to see when and if it gets merged in. [43:13]
-
-## [Chrome 137 adds `if` support in CSS](https://developer.chrome.com/blog/new-in-chrome-137)
-
-**Carl:** Yeah. Speaking of, I don't know, new CSS things. Chrome 1 37 added an if to CSS. There's a conditional flow, or I don't know, there's a condition now in CCSS. I have not seen that before. So I guess it's a way of, you know, you can consult the various variables you've set up and evaluate what the associated styles are or associated values and conditionally. [43:16]
-
-Do one thing or another. Yeah. [43:43]
-
-**Mark:** Yeah. It, it, it looks like it's a built-in function. You pass in a very, like a, an existing variable or property value as the first, and then it's, if it matches, then it's a, if it doesn't match, then it's b like, almost like an Excel function, like kind of a thing. [43:44]
-
-**Mo:** Reminded me exactly of that. [44:01]
-
-Are we finally at the stage where CSS is turning complete? [44:03]
-
-**Carl:** I remember seeing a demo of turning complete CSS like 15 years ago if you include user input. So yeah, it was like a grid of check boxes and uh, I think the, the human had to interact with stuff, but it was turning complete, if you included that. [44:06]
-
-**Mo:** So I think we just need loops and it'll technically be turn complete. [44:20]
-
-**Carl:** Yeah. Wild. Anyway, that, that seems interesting and new. This document that I'm reading is using something else that I don't recognize. The, the example they have here is if style, you know, dash color, white, so I guess that's using a different function to read the styles of the current element. [44:23]
-
-Something. That's what it looks like to me, but that's also new to me. So like between conditionals and being able to read the current state of element are, uh, interesting. [44:41]
-
-## [React Devtools for Firefox may not get updated due to review restrictions](https://bsky.app/profile/ricky.fm/post/3ltkxpo5ewk2i)
-
-**Mark:** There was a discussion thread on Blue Sky where someone, where one of the React team members said that. They were, they had tried to submit an update to React Dev Tools extension in Mozilla's, Firefox, add-on store, and it was getting blocked because Mozilla has some very specific and strict rules around how code gets built into extensions, and suddenly, all of a sudden, someone on the Mozilla side is complaining that the way React builds their extension is hypothetically a security concern. [44:50]
-
-There were also some numbers thrown around about how many Firefox users of the dev tools extension actually exist. And it was only like, maybe like 120,000 or something. Whereas I think the, the last time I looked at the, the dev tools extension for Chrome, it's like 4 million. So the React team was actually saying, you know, maybe we, we won't even bother building the extension for Firefox anymore. [45:23]
-
-It's, it's not worth the effort. You can always add the, you know, the unbundled version yourself. I think they maybe managed to get the attention of someone from Mozilla to try to, you know, bypass the stuck review process. But clearly that's a pain point. And [45:47]
-
-**Carl:** I gotta say, just side load this extension that can read all of your input on every site is the dangerous thing to do at scale. [46:03]
-
-Like if you just tell millions of people side load this application, there's gonna be dozens of malicious actors who spin up their own. Side load version of the extension that does malicious things. So Oof. Don't like that. So yeah, hopefully they can fix this, you know, correctly. [46:12]
-
-## [Both `oxlint` and `biome` are investigating typed lint rule support](https://www.solberg.is/fast-type-aware-linting) ([Biome v2](https://biomejs.dev/blog/biome-v2/), [tsgolint](https://github.com/oxc-project/tsgolint))
-
-**Mark:** And so another item, so we've previously mentioned that, you know, biomes working on version two and they had included some typed some support for typed aware rules that normally would've required integration with the TypeScript DS went package and the TypeScript compiler ENT came out with 1.0. [46:29]
-
-There, there's a bit of additional information and updates on both of those. So there was, there was an article. Talking and comparing the different approaches that Biome and Oxalate are using to implement typed support. And then we got a couple links to some of the discussions where those linters are doing it. [46:49]
-
-Biome appears to be building in like their own, almost like a miniature version of. Typed processing, whereas Oxalate has taken the new TypeScript written in Go compiler and sort of hacked up an interop layer. Then they're relying on the new TypeScript go compiler to do the type checking work. And that approach appears to be working it. [47:09]
-
-They said they've implemented a number of the different type to wear rules, and it seems highly performant, so you know that in addition to being able to build our apps faster, we may be able to lint our apps faster as well. [47:35]
-
-## [Remix v3 dev branch containing support packages](https://github.com/remix-run/remix/tree/v3)
-
-**Mark:** Cool. We've been going on for a while about how the remix team has been dropping very, very vague hints about what remix version three is going to be, to the point that it's really getting very, very annoying for those of us reading their, their Twitter accounts, and I still haven't seen any actual code of what the framework itself. [47:49]
-
-Will be like, however, there they did put up a development branch that includes some of the support packages that they're going to be using as part of the implementation of version three. So like it's not the full framework, but there's a lot of individual sub packages for various like tar parsing and other sorts of things that they want to be usable standalone, but they're building them for the purpose of usage in version three. [48:07]
-
-So it's not a full look at what, what they're doing, but it's a little bit of a peek behind the curtain. [48:35]
-
-## [React Native Wallet](https://blog.swmansion.com/introducing-react-native-wallet-90c1ee103d3e)
-
-**Mo:** Cool. Next up, we've got another sort of honorable mention of releases that happened over the last month, and this is React native wallets. So there's a lot of sort of. Wallet style libraries that have come and go in the React native ecosystem, not one that's really been maintained extensively. [48:40]
-
-And so the folks at Expensify and Software Mansion have partnered together to create the React Native Wallet library. And so the idea is that. It's firstly a cross-platform way to add payment and credit cards to Apple and Google Wallet. Now, there's libraries that like handle passes and tickets. They're quite limited. [48:58]
-
-I've used a few of them in the past, but this is more specifically on payment cards. And so the idea is that you can maybe. Hopefully through this process avoid needing to integrate a whole bunch of different SDKs for different cards and different and different platforms, and you can kind of just use this library to handle a lot of that functionality for you. [49:19]
-
-Sounds quite complex because, you know, payments are usually quite difficult to get working, so I'm curious to see how well this works in practice, but I've not had the use case yet. Typically payments and, and cards and stuff like has so many different people that you need to communicate with. The card issuer, apple, and a whole bunch of other people in the process. [49:37]
-
-So curious to see how extensible and generic this is gonna be, but very cool. [49:56]
-
-**Carl:** Yeah. Interesting. Also, it's the first time I've seen a wallet library that was not Web3 in a long time, so additional wallets, right. [49:59]
-
-## [Deno v Oracle update](https://deno.com/blog/deno-v-oracle4)
-
-**Carl:** This is a very small update, but we've. I talked a bit in the past about Deno versus Oracle. [50:07]
-
-Deno has been suing Oracle for use of the JavaScript trademark because did you even know that Oracle owned it? Oracle owns the JavaScript word, the word JavaScript. So basically the only content update here is that in the past, at some point previously in the litigation, Deno filed a claim of fraud because. [50:13]
-
-Oracle filed supporting evidence of prior use of the trademarked term JavaScript by referencing the node JS project. Generally as something that they did and you know, who did not start or maintain node js is Oracle. So like basically they filed a just wildly inaccurate claim supporting that. They do in fact use JavaScripts. [50:36]
-
-So that unfortunately was dismissed. The fraud claim was dismissed, which seems strange to me because like if you say I made this and you didn't, seems wrong. But anyway, that's really the only major update here, but hopefully we will hear more. Hopefully this will go in a good direction. I am not super confident of that, but August and September have some major court dates, so maybe there will be more updates later this year. [51:00]
-
-## [“Content independence day” from Cloudflare](https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/) (they’re blocking AI crawlers)
-
-**Carl:** There's also an update from CloudFlare on AI crawlers. They have declared content independence stay. No AI crawl without compensation, which seems lovely, Cloudflare's in a pretty good position to meaningfully control traffic in that kind of a way. Lots of real services are using CloudFlare for that purpose. [51:23]
-
-So, yeah, seems good. I've heard a couple of anecdotes of people with smaller services getting absolutely slammed with traffic from, you know, poorly coded AI supporting crawlers, trying to gather information and doing it just greedily or excessively. So, seems good. Seems nice. [51:45]
-
-## [Some updated Static Hermes perf numbers](https://x.com/tmikov/status/1945348222110859500) release available “soon”, being tested internally at Meta
-
-**Mark:** All right, and last couple items. [52:04]
-
-The folks at Meta have been working way on static Hermes, which is an attempt to take the existing Hermes JavaScript engine for React Native and be able to pre-compiled entire JavaScript apps to a native binary. And they put up a tweet with some. Performance numbers comparing static hermes's output versus a couple of other JavaScript runtimes. [52:06]
-
-The numbers seem higher, which seems like a good thing. And they also mentioned that they think they will have a release available, quote unquote soon, and that they are using it internally at meta. So, you know, that seems like another potentially useful tool to have in the ecosystem. [52:29]
-
-## [State of HTML Survey is open](https://survey.devographics.com/en-US/survey/state-of-html/2025)
-
-**Mark:** Finally, the folks behind the various state of surveys have put out the state of HTML survey. [52:47]
-
-So that's open. You can fill it out, test out your knowledge, answer some questions about what various new H TM L features you may or may not be familiar with and what you think about them. [52:54]
-
-**Mo:** I did not know them. State of HTML. Very interesting. [53:04]
-
-**Carl:** Yeah, I think they started like two or three years ago. It's relatively newer. [53:07]
-
-I mean, the state of. X has really exploded in the last couple of years. It's great. I love that. But I do worry about like survey fatigue and a lot of these are trying to solicit answers from the same population of developers. So I don't know, maybe, maybe. We'll, we'll see how that plays out. Cool. [53:10]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Alright, before we close out, let's, uh, talk about some coming [53:26]
-
-## [Big Sky Dev Con](https://bigskydevcon.com/) Aug 2 Bozeman, MT, USA
-
-**Carl:** like four days, there's Big Sky devcon in Bozeman, Montana. [53:29]
-
-## [Kansas City Developer Conference](https://www.kcdc.info/) Aug 13-14 Kansas City, KS, USA
-
-**Carl:** Seems good. Kansas City Developer Conference, which is not KCD. It's KCDC, but it's not Ken C dos that's happening August 13th and 14th in Kansas City, Kansas. [53:36]
-
-## [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025. Wrocław, Poland
-
-**Carl:** We also have React Universe September 2nd through fourth in Wroclaw [53:47]
-
-**Mo:** I've been there enough times where I've been taught the pronunciation because butchered it several times, but it's, [53:52]
-
-## [WaysConf](https://www.waysconf.com/) Sept 16-17
-
-**Carl:** uh, we've also got Ways Conf coming up September 16th and 17th in Krakow. [53:57]
-
-I'm also probably butchering, but also in Poland. [54:04]
-
-## [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
-
-**Carl:** Cascadia js is September 18th, 19th in Seattle, Washington. [54:06]
-
-## [Squiggle Conf](https://squiggleconf.com/) Sept 17-18 Boston, MA, USA
-
-**Carl:** And we've got Squi Squiggle conf in Boston, September 17th and 18th, which should be great and I should be there, I believe. [54:10]
-
-## [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l)
-
-**Carl:** And of course, react Conf October 7th and 8th in Las Vegas, Nevada. [54:17]
-
-## [Remix Jam](https://remix.run/jam/2025) Oct 10 Toronto, Canada
-
-**Carl:** I also just heard about Remix Jam, happening October 10th in Toronto, Canada. Yeah, that's new. I don't know that they've done a conference like that before, so that's interesting. [54:22]
-
-## Outro
-
-**Carl:** But yeah, that's all we got for you this month. Thanks so much for joining us. We will be back probably on the last Wednesday of August, but we've been. Jumping around the last few months, but we'll be back in your podcast feed just as soon as we can. [54:33]
-
-**Mark:** Always fun. Way too much to keep track of, but hopefully this has been useful. Lovely to be with you all and see you all next month. [54:46]
-
-**Carl:** Great. We gather sources from this week in React Bites, dev Next JS Weekly, the React JS subreddit, and here in React to Flux from the E, the Tech Reads and News Channel. If you see something that you think we should talk about, definitely Sheridan. [54:53]
-
-Channel or send it to me at hello@reactiflux.com. If this is a show that you get value from and want to support, one of the best ways you can do so is by submitting a review on whatever platform you listen to it on, or tell your friends and coworkers about it. [55:07]
-
-Thanks so much for listening. Talk to you later. [55:19]
diff --git a/src/transcripts/tmir-2025-08.md b/src/transcripts/tmir-2025-08.md
deleted file mode 100644
index 15b5e9f..0000000
--- a/src/transcripts/tmir-2025-08.md
+++ /dev/null
@@ -1,498 +0,0 @@
----
-title: "TMiR 2025-08: Nx compromised; no more throwing promises; Remix-ing new component models"
-date: 2025-08-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:47](#new-releases)] New releases
- - [[00:51](#ts-59)] [TS 5.9](https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/)
- - [[02:50](#ts-60-may-enable-strict-by-default-and-change-other-defaults)] [TS 6.0 may enable \\\`strict\\\` by default](https://bsky.app/profile/robpalmer.bsky.social/post/3lxar2cp5rs2p) and [change other defaults](https://github.com/microsoft/TypeScript/issues?q=milestone%3A%22TypeScript%206.0.0%22)
- - [[03:46](#react-native-081)] [React Native 0.81](https://reactnative.dev/blog/2025/08/12/react-native-0.81)
- - [[05:40](#next-155)] [Next 15.5](https://nextjs.org/blog/next-15-5)
- - [[07:10](#preact-11-beta)] [Preact 11 beta](https://github.com/preactjs/preact/releases/tag/11.0.0-beta.0)
- - [[07:39](#hydration-20)] [Hydration 2.0](https://github.com/preactjs/preact/issues/4442)
- - [[07:52](#bun-1221)] [Bun 1.2.21](https://bun.com/blog/release-notes/bun-v1.2.21)
- - [[08:54](#native-yaml-support-definitely-not-going-to-cause-any-problems)] Native YAML support. Definitely not going to [cause any problems](https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell)
- - [[10:21](#tanstack-db-beta)] [Tanstack DB beta](https://tanstack.com/blog/tanstack-db-0.1-the-embedded-client-database-for-tanstack-query)
- - [[11:30](#ghost-v6)] [Ghost v6](https://ghost.org/changelog/6/)
-- [[13:09](#main-content)] Main Content
- - [[13:13](#react-api-changes-updates)] React API changes / updates
- - [[13:24](#react-deprecating-the-throw-a-promise-suspense-trigger-method)] [React deprecating the “throw a promise” Suspense trigger method](https://github.com/facebook/react/pull/34032)
- - [[16:20](#discussion-between-dan-dominik-and-ricky-about-how-to-support-multiple-react-versions-if-at-all)] Discussion between Dan, Dominik, and Ricky about [how to support multiple React versions (if at all)](https://bsky.app/profile/tkdodo.eu/post/3lv4rhr4mrs2i)
- - [[17:43](#github-discussion-with-joe-about-why-no-context-selectors-api-or-signals-research-into-data-modeling-and-why-concurrent-stores-are-the-current-focus-area)] Github discussion with Joe about [why no context selectors API or signals, research into data modeling, and why “concurrent stores” are the current focus area](https://github.com/reactjs/rfcs/pull/119#issuecomment-3214971470)
- - [[21:25](#pr-for-concurrent-stores-skeleton)] [PR for “concurrent stores” skeleton](https://github.com/facebook/react/pull/33215)
- - [[23:13](#third-party-react-concurrent-store-ponyfill-package)] [Third-party \\\`react-concurrent-store\\\` ponyfill package](https://github.com/thejustinwalsh/react-concurrent-store)
- - [[26:39](#lee-robinsonss-reflections-on-the-react-community-wrap-up-post)] Lee Robinsons’s [“Reflections on the React Community”](https://leerob.com/reflections) wrap-up post
- - [[31:18](#remix-doing-its-own-component-model)] [Remix doing its own component model??](https://x.com/mjackson/status/1954975322157486408)
- - [[36:46](#remix-3-and-the-end-of-react-centric-architectures)] [Remix 3 and the End of React-Centric Architectures](https://thenewstack.io/remix-3-and-the-end-of-react-centric-architectures/)
- - [[37:21](#popular-nx-packages-compromised-on-npm)] [Popular nx packages compromised on npm](https://www.aikido.dev/blog/popular-nx-packages-compromised-on-npm)
- - [[39:43](#last-month-eslint-plugin-prettier-maintainers-were-targeted-this-is-a-much-broader-attack)] Last month [eslint-plugin-prettier maintainers were targeted](https://snyk.io/blog/maintainers-of-eslint-prettier-plugin-attacked-via-npm-supply-chain-malware/), this is a much broader attack
-- [[41:31](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[41:33](#react-strict-dom-vs-react-native-for-web-in-2025)] [React Strict DOM vs React Native for Web in 2025](https://shift.infinite.red/react-strict-dom-vs-react-native-for-web-in-2025-bb91582ef261)
- - [[43:34](#faster-jsonstringify)] [Faster JSON.stringify()](https://v8.dev/blog/json-stringify)
- - [[44:56](#node-2218-unflags-ts-type-stripping-support)] [Node 22.18 unflags TS type-stripping support](https://nodejs.org/en/blog/release/v22.18.0)
- - [[46:23](#waku-switches-to-vites-wip-rsc-support)] [Waku switches to Vite’s WIP RSC support](https://waku.gg/blog/migration-to-vite-plugin-rsc)
- - [[47:00](#rari-a-fast-react-framework-with-rsc-support-built-with-rust)] [Rari, a fast React framework with RSC support built with Rust](https://ryanskinner.com/posts/how-i-built-a-full-stack-react-framework-4x-faster-than-nextjs-with-4x-more-throughput)
- - [[47:52](#selecting-values-from-query-results-as-well-as-the-useless-usecallback)] [Selecting values from query results](https://tkdodo.eu/blog/react-query-selectors-supercharged), as well as [The Useless useCallback](https://tkdodo.eu/blog/the-useless-use-callback)
- - [[48:26](#ts-postmortem-effect-ts-experimental-ts-fork)] [TS\+ postmortem (Effect-TS experimental TS fork)](https://effect.website/blog/ts-plus-postmortem/)
- - [[50:48](#react-usetransition-update-ordering-details)] [React useTransition update ordering details](https://jordaneldredge.com/notes/react-rebasing/)
- - [[51:13](#a-clock-that-doesnt-snap-techniques-for-fixing-hydration-of-values-like-dates)] [“A Clock that Doesn’t Snap”](https://ethanniser.dev/blog/a-clock-that-doesnt-snap/), Techniques for fixing hydration of values like dates
- - [[51:36](#react-cache-its-about-consistency)] [React Cache: It’s about consistency](https://twofoldframework.com/blog/react-cache-its-about-consistency)
- - [[52:26](#self-hosting-next-at-scale)] [Self-hosting Next at scale](https://dlhck.com/thoughts/the-complete-guide-to-self-hosting-nextjs-at-scale)
- - [[53:26](#server-and-client-component-composition-in-practice)] [Server and Client Component Composition in Practice](https://aurorascharff.no/posts/server-client-component-composition-in-practice/)
-- [[54:04](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[54:06](#react-universe-conf-sept-2-4-2025-wrocaw-poland)] [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025\\. Wrocław, Poland
- - [[54:14](#waysconf-sept-16-17)] [WaysConf](https://www.waysconf.com/) Sept 16-17
- - [[54:21](#cascadiajs-sept-18-19-seattle-wa-usa)] [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [[54:26](#cascadiajs-sept-18-19-seattle-wa-usa)] [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [[54:32](#react-alicante-oct-2-4)] [React Alicante](https://reactalicante.es/) Oct 2-4
- - [[54:51](#react-conf-is-back-oct-7-8-las-vegas-nv-usa)] [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
- - [[54:56](#remix-jam-oct-10-toronto-on-ca)] [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
-- [[55:10](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the August edition of this Month in React. As we recap what's going on with React, react native in the web we're coming to you live from Reactive Flux, the place for professional developers using React. I'm Carl. [00:00]
-
-I'm a staff product developer and freelance community leader here at Reactive Flux, where I do community programs like this event and write some code to help keep the community running. [00:13]
-
-**Mark:** Hi, I'm Mark. I maintain Redux. I try to find time to maintain Redux. Life is busy these days and my day job is working at Replay where we've built a time traveling debugger for JavaScript and are also attempting to get in on the AI app generating craze. [00:22]
-
-**Carl:** Mo is unfortunately out this month, he seems to have food poisoning or something similar. So he's gonna take a break and I'm gonna do my best on React Native news, which is only Okay. [00:37]
-
-## New releases
-
-**Carl:** But yeah, let's start off with some new releases. Mark, tell us about new TypeScript. [00:47]
-
-## [TS 5.9](https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/)
-
-**Mark:** The TypeScript release train keeps on rolling. They've just put out TypeScript 5.9. Few points of interest out of this one. They've updated some of the options for generating any new TypeScript project. They've simplified the initial TS config, JSON that gets generated. They also have support for the upcoming JavaScript import, defer syntax. This is a new thing. That is coming down the pipeline for JavaScript engines where you can use the defer keyword in an import statement and the JavaScript runtime will know that it needs to go read this file, but it won't try to actually load and execute that JavaScript right away. [00:51]
-
-Right now, when you do imports, everything's imported and executed synchronously. This can have a lot of effect on startup time, and so the import, defer keyword is meant to la effectively lazy load some pieces of the JS system without having to use the the separate import statement. So TypeScript now at least has support for that syntax, but in a sense it won't do anything until JavaScript engines fully support actually doing something with that. One thing that I personally am excited for is that TS 5.9 now has support for expandable hover previews. If you, if you ever work with TypeScript, you have big type definitions, you know that TypeScript often cuts down the amount of information it shows about a type in the hover preview or, you know, the types are deeply nested and you, you don't already know like what is inside this field. So ts 5.9 now has support for actually being able to drill down into hover previews. you do need to have an updated version of VS code to make use of that as well. But as someone who has spent too much time fiddling with those settings, I'm actually very excited about that one. [01:37]
-
-**Carl:** Yeah, that sounds great. [02:48]
-
-## [TS 6.0 may enable \\\`strict\\\` by default](https://bsky.app/profile/robpalmer.bsky.social/post/3lxar2cp5rs2p) and [change other defaults](https://github.com/microsoft/TypeScript/issues?q=milestone%3A%22TypeScript%206.0.0%22)
-
-**Mark:** And then along with that, there are a couple bits about the future of TypeScript. So right now we're on 5.9. The TypeScript team has said that the go port of the TypeScript compiler will become a TypeScript 7.0. They've put out some news and plans on the roadmap for TypeScript 6.0. There's an issue in some discussion about making the strict flag the default, or maybe not the entire strict flag, but maybe graduating some of the specific settings, like strict null checks to be turned on by default. As a maintainer, that makes me very, very happy. I'm tired of seeing people post issues against my library saying, your library doesn't work. Right. And the problem is they didn't have TypeScript in strict mode in the first place. So. still to be worked out, but it's good to see that they are trying to figure out the transition plan for all this. [02:50]
-
-**Carl:** Definitely super cool. [03:44]
-
-## [React Native 0.81](https://reactnative.dev/blog/2025/08/12/react-native-0.81)
-
-**Carl:** We've also got React native releasing version uh, O 81. Obviously I am not anywhere near as deeply versed in React native as Mo would be. So, uh, hopefully we'll have him around to catch us up again later on. But we've talked a little bit about what's coming on, what's in this release in previous months. [03:46]
-
-Nothing here struck me as super new. They're deprecating, the safe area view which they talked about as being originally an iOS specific. Component in order to support, you know, the safe area because of the notch. But now Android has notches too, and it doesn't work very well for that. So it's being deprecated and they're leaning on the, Safe Area Context. They recommend that you migrate to the React native safe Area context library for that. They are also defaulting to Android 16 now in React Native. They had an, a curious call out that seems strange to me. They say predictive back gesture is now enabled by default for apps targeting Android 16 and just , the phrase predictive back gesture. [04:07]
-
-Is, I don't know, it seems like a lot to me. I know gestures, you have to predict them and whatever, and I guess everything is now gestures, but I have my phone sent to use buttons still, so I don't know what they're talking about, but that sounds complicated. It also talks like, you know, if you have overridden your, the back behavior of your app, then you may need to migrate or change how your app works. [04:50]
-
-So man, if only you could reliably go back in Native apps isn't the web great. They also are introducing pre-compiled iOS builds, which they say cuts the compile time by up to You know, 10 x so like one 10th the compiled time. It used to be in projects where react native is a primary dependency. [05:11]
-
-And they've got better error rendering in the dev tools as well, which is great. it now shows the original message in Stack trace of uncut JavaScript errors. So how, how lovely to know where your errors come from, [05:29]
-
-## [Next 15.5](https://nextjs.org/blog/next-15-5)
-
-**Mark:** Next 15.5 came out. A couple things worth noting from this one. They now have turbo pack builds for production in beta. Turbo Pack had previously really only been used for local development, and so they've been cranking away on trying to get it to full compatibility for production builds. And it seems like that's getting close. They now have node support for middleware. They've got some TypeScript improvements, like actually having full typing for routes. So it'll catch things like mistyped link tags as well as trying to get rid of the old next lint command. [05:40]
-
-**Carl:** Yeah, the middleware support for no JS also seems like a pretty big step. You know, one of the main complaints, a large complaint about next is how difficult it is to run yourself not on Vercel. So supporting a more generic runtime for your middleware seems really great. [06:16]
-
-I haven't run into this with next specifically, but I have run into. Compatibility issues between edge runtimes and node JS code. it's such a constraint if you're trying to run on, edge runtime, which is, you know, okay, so next Vercel is they have their Edge Runtime, in title case. [06:33]
-
-But also, you know, CloudFlare workers are also a very similar kind of runtime that offer a similar set of constraints. And man, you just can't use a lot of the node ecosystem when you're in one of those constrained environments. So this, this should open up compatibility quite a lot it sounds like to me. [06:51]
-
-## [Preact 11 beta](https://github.com/preactjs/preact/releases/tag/11.0.0-beta.0)
-
-**Mark:** Meanwhile, the Preact library, the, the longstanding smaller replacement for React just put out a beta for version 11. Preact has always been dom slash web only, not native. And the calling cards have been that it's much smaller than full-blown react, but maintains most API compatibility up to a certain point. [07:10]
-
-I think they've stopped trying to, maintain compatibility for some of the newer React APIs in 18 and 19. [07:33]
-
-## [Hydration 2.0](https://github.com/preactjs/preact/issues/4442)
-
-**Mark:** A couple of the big points this one they finally dropped IE 11 support and they've improved hydration and a number of other small tweaks. So it's always good to see that them making progress as well. [07:39]
-
-## [Bun 1.2.21](https://bun.com/blog/release-notes/bun-v1.2.21)
-
-**Carl:** Every so often it's nice to check in on what BUN and Dino and everything are doing. BUN has a 1.2 point 21 release out. A couple things that caught my eye on it were the bun sql, you know, standard library tool now supports MySQL, MariaDB, SQL Light, and Postgres, all from like one dependency. [07:52]
-
-And that's pretty great. I don't know. Nice to have, nice to be able to swap those out. I wonder what the experience of actually trying to swap them out would be, because the different engines have slightly different constraints. I appreciate that. That's cool. I, I love, especially for like SQL light stuff, it just seems so simple as maybe overstating it, but it's really nice to be able to just spin up a database without installing dependencies. [08:12]
-
-So, uh, kudos to BUN for adding that. They've also added native YAML support which is great. You know, it's lovely to not for parsing confi common configuration file formats again, seems like something that should be in the standard library. However, I am generally aware of YAML as like a very challenging format to parse. [08:35]
-
-## Native YAML support. Definitely not going to [cause any problems](https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell)
-
-**Carl:** There's a, a blog post that lives in my brain about YAML from 2023 titled The YAML document from Hell Enumerates some of the complexities one of my favorites being sex decimal numbers. And so a, a, apparently a common older format quirk is that some, ranges of ports that you might try to map in, say a Docker file like Port 22, mapped to port 22 is not parsed as 22, colon 22. [08:54]
-
-It's parsed as a sexagesimal, IE base 60, number. So then instead of the string 22:22, you get 1,342. Which is not a valid port mapping. So like things like there are like 30 different ways to put Booleans to encode Boolean in a YAML file. And so like yes and no are one of the valid formats. And so if you're trying to do a list of countries using standard country codes, apparently Norway will be interpreted. [09:24]
-
-**Mark:** Is NO, [09:53]
-
-**Carl:** So like, just hearing about that, those kind of like foot guns that exist in the format and apparently like variations in parser behavior is an existing problem throughout the YAML ecosystem. So, great. I [09:56]
-
-**Mark:** let's add another parser. [10:09]
-
-**Carl:** Right what? Great. One more parser there. Wonderful. I can't wait to hear about what weird, terrible, hellish bugs emerge from this new parser. [10:09]
-
-Good luck to them. I hope it's good. [10:19]
-
-## [Tanstack DB beta](https://tanstack.com/blog/tanstack-db-0.1-the-embedded-client-database-for-tanstack-query)
-
-**Mark:** Next up the folks over in the Tan Stack Collective have just put out a beta of the new Tan Stack database library. it's a little interesting to describe. It's a layer that's supposed to sit on top of your tan stack query setup, and it kind of acts as like a local in client database and sync engine. [10:21]
-
-So you can still use 10 set query to do the fetching, but the database layer is supposed to provide a normalized view of the data, supposed to have very fast in client updates. I believe this has been worked on by Kyle Matthews, who you may know as the original creator of the Gatsby framework back in the day. He's been working on electric sql, which is itself a AYC engine layer, so he clearly now has some expertise over there. So, looks like a very potentially interesting tool for fast client side data management. [10:41]
-
-**Carl:** it seems like hand stack throwing their hat in the ring on like sync engines at a slightly different level of abstraction than like where React query sits. Further to the backend, further to here's your internal store being managed, not just request caching. [11:12]
-
-So that's cool. Yeah. Interesting. [11:28]
-
-## [Ghost v6](https://ghost.org/changelog/6/)
-
-**Carl:** A very small shout out, a little bit further away, but this is a tool that I evaluated for use in a professional setting on a React project. So I'm gonna shout out a new major version. Ghost version 6.0 has been released. Ghost is a, like CMS, an open I believe open source CMS. [11:30]
-
-And they generally seem nice. They seem great. I, you know, as contrasting things like Contentful or Ghost or Substack or Medium or what have [11:47]
-
-you, uh, Word, right? They sit in a good spot in the niche. They, so they're now, they're announcing as part of this version six that they have added distribution. [11:57]
-
-So now you can automatically publish your posts from Ghost across social platforms. So like they, they call out Blue Sky Flipboard Threads, MAs it on WordPress, interestingly and Ghost, they can, so, okay, so you can publish the ghost and it will be distributed elsewhere on, in Ghost, I don't know, I don't know what that means. [12:09]
-
-Or any other social web platform as well as like analytics. And they talk a lot about how much revenue they have passed along to publishers on their platform. So they show their earnings broken down into like. Hosting revenue and platform revenue, and it's like $38 million for their own company and like a hundred million dollars through, you know, distributed to people publishing on ghosts. [12:28]
-
-So like that, I don't know. That's great. They, they shout out 4 0 4 Media, which is a site that I'm familiar with and did not realize hosted on this platform. So, you know, love that. That's great. I love a, love a open source media platform that's doing good work right now. [12:56]
-
-## Main Content
-
-**Carl:** Cool. Uh, That's all the new releases we have for now, into the main content. [13:09]
-
-## React API changes / updates
-
-**Mark:** All right, so we have a roundup of a number of topics related to changes in reacts APIs. So get your technical hats on for these. [13:13]
-
-## [React deprecating the “throw a promise” Suspense trigger method](https://github.com/facebook/react/pull/34032)
-
-**Mark:** The first one is that Sebastian Markbåge put up a PR to officially deprecate the throw a promise technique for triggering suspense. So let's wind backwards and unpack a little bit, like what is that in the first place and why does it even exist? So. Currently up through React 17 and 18. The suspense component came out in I think like 16.6, but originally it was only used with React lazy for importing and deferring loading of components. There wasn't an official like react for data fetching method, but there was the unofficial experimental. [13:24]
-
-This is never documented, but the code exists and works. If you wanted to trigger suspense in terms of like, you know, managing some data fetching yourself, the super secret technique was that you would throw a promise from within your component. And the reason the React team picked this was because we. It like, to a certain extent, it enabled them to reuse the existing infrastructure from catching errors within a component where, you know, it kind of conceptually, you have a catch block around the actual component call and then react knows, here's where I'm rendering in the tree, and then it can sort of bubble up the behavior to some ancestor component that was supposed to catch it for errors. [14:07]
-
-It's a, you know, actual error handling with the component did catch. And for suspense it's, you know, where's the nearest suspense component in the tree? And so this was never officially documented, but, you know, library maintainers and people investigating the code saw that it was there. And so it's been known and used by the community and libraries for years. [14:57]
-
-And so pretty much anything, any library that had suspense support built in was internally just throwing a promise. So with React 19, we now have the use hook built in, and that is the officially documented publicly, you know, described way to actually trigger suspense. If you look at the use hook, I think internally it does actually still end up throwing a promise last time I checked, but it's now an implementation detail. And it does some other things in there as well. So if you read a pr, they are officially going to get rid of the throwing a suspense, throwing a promise technique for a number of reasons. Some of it has to do with internal implementation details and optimizations. Some of it has to do with, well, we can have the lit rules look for uses of the use hook and flag any, any time you try to put that in a place that it's not legal to do so. [15:19]
-
-## Discussion between Dan, Dominik, and Ricky about [how to support multiple React versions (if at all)](https://bsky.app/profile/tkdodo.eu/post/3lv4rhr4mrs2i)
-
-**Mark:** This did then lead to some discussion on Blue Sky amongst a couple of the maintainers like Dominic Dorf, Meister of React Query asking, well, if this comes out in like, you know, 19 3, 19 4, something like that, how are we supposed to manage having our own libraries work with both like React 18 and 19.1 and 19.4 at the same time when there's now three different variations of what is a legal way to trigger suspense. there was a bit of a back and forth on that. One partial answer was, your library can check if the use hook is exported from React and prefer that if it exists and fall back the promise if it doesn't. One of the React team members, Ricky said, well, you probably should just focus on supporting the latest version of React. I'll admit, I feel like that kind of hand waves the problem a little bit. [16:20]
-
-**Carl:** How great if everyone could just rely on that. Yeah. [17:17]
-
-**Mark:** yeah, because I mean that, that probably also means putting out new major versions of our own libraries, which is then an effort and also has a ripple effect on the ecosystem. I mean, I don't really want to publish a new version, a new major version of, you know, some of the Redux libraries just to support that. But it's good to see that there, that we are actually making headway on that now that 19 is out. [17:20]
-
-## Github discussion with Joe about [why no context selectors API or signals, research into data modeling, and why “concurrent stores” are the current focus area](https://github.com/reactjs/rfcs/pull/119#issuecomment-3214971470)
-
-**Mark:** Another interesting point. So buried in a blue sky thread Joseph from the React team said that. They're planning to not actually implement an idea that they had discussed a few months ago where they'd said, we are going. [17:43]
-
-They were thinking about allowing you to call use or use context inside of use memo as a way to optimize context. So backing up technical detail on this one, the weakness of context has always been that when you update the context value, every component that reads it will re-render. And then at that point, all the children inside of that will re-render as well, just because react defaults to when any component renders. [18:01]
-
-It just keeps on going all the way down the tree unless you optimize it to stop. And so the problem is if you have, you know, fairly large objects with multiple fields as your context value, some of your components probably only care about one or two of those fields. But as soon as you update that object at all, every component that read the context will re-render. And so it ends up leading to, you know, potentially lots of components rendering slower render performance, et cetera. So years ago, like, I don't know, 20 18, 20 19 there was a user land RFC suggestion that react should add context selectors as an API. So, you know, kind of similar to like a, a react redux use selector, but optimize for context instead. [18:28]
-
-And so that proposal has been around for a long time. Andrew Clark even briefly tried implementing a proof of concept of a context selector's API in like 2020, and then it didn't go anywhere. So a few months ago, the React team said we're, we're thinking about a. Use context in use memo as a alternative to actually writing a selector for context. And apparently their thinking has evolved and they're not going to do that at this point because the React compiler basically gives you 95% of the performance benefits that a context selector's API would have without them needing to design and ship a context selector's API, into React itself. If you think about it, the point of the compiler is that it not only optimizes like your used memos and whatever, it also optimizes the render output. And so if you have a component that reads from a context, it will, it will render because the context value changed. But if none of the data that it needs from the context has updated, it will end up skipping all of its children. And so that drastically cuts down on how many components would render when the context updates. So there was actually some very, very good discussion in the longstanding context, selectors RFC thread, just within the last two or three days where a few people were agitating for react should really add contact selectors. It'll get rid of all these other state management libraries. [19:18]
-
-And I left a couple comments trying to explain how the compiler solves this problem and Joe Savona from the React team then went on and wrote some very extensive, detailed comments talking about how the React team has been doing research into these ideas of data flow analysis. And how do you manage large amounts of state and how does it compare with react context and signals and, you know, third party state management libraries. [20:57]
-
-## [PR for “concurrent stores” skeleton](https://github.com/facebook/react/pull/33215)
-
-**Mark:** And so he confirmed that, they're not planning to add a context selector's, API and instead their thought process is actually now about this concept called concurrent stores. So as best as I understand it, the idea is that right now a third party library like Redux or Zeus stand relies on the use sink external store hook to be able to tell react that there's a subscription data changed. This component needs to update, but. That has the limitation that it doesn't play well with suspense and transitions because if something got updated in the middle, react has to throw away work in progress and do a full render. It can't do all the, you know, the performance optimizations and with transitions. So it sounds like this concurrent store idea is supposed to be like an improved, better version of use sync external store where you can still have some data living externally. You can still have selectors saying like, only these components need to update. But the concurrent store would wrap the updates in a concurrent transition compatible way. [21:25]
-
-So he said that they're really trying to put some focus in API design onto figuring out what a concurrent store, API ought to look like. And it sounds like they've got some, some amount of progress on that design to talk about in the near future. They did put up a pull request a couple months ago with the skeleton for concurrent stores. It's just like defining some, some data types and adding some tests. There's no implementation code yet. [22:41]
-
-## [Third-party \\\`react-concurrent-store\\\` ponyfill package](https://github.com/thejustinwalsh/react-concurrent-store)
-
-**Mark:** However a third party developer that I saw has actually looked at all the tests and then gone off and tried to implement a third party hacky polyfill version of what it looks like the concurrent stores are supposed to be and publish that as a React concurrent store package. I'm very excited about this and I have not had time to actually try it out yet. So the takeaways are a. Most developers probably won't need to use some of these things directly. A lot of this is going to be more library maintainer concerns but it's very good to see that the React team is actively thinking about how, how can we make React apps faster? What are the best ways to manage complex state? How can we better integrate with third party libraries and try to make all the react features like transitions work well in those cases? [23:13]
-
-So there's your info dump for the day. [24:08]
-
-**Carl:** Love that. I had said some stuff just before we started recording, just before we started the event about, I've been playing with effect effect ts lately, which we, we've mentioned once or twice now. And again and when you're talking about these concurrent stores and you know, like I'm reading the post from Joe Savona talking about context selectors. [24:10]
-
-One of the things that I think effect solves well is dependency injection. it's focused on the backend, that actually says in the documentation like, effect is not meant for front end. They're, it may seem good, but it's not what it's meant for. And they're interested in exploring that, but they haven't yet. [24:30]
-
-But I think the execution model is pretty similar. It's like, it's almost like componentized backend a little bit. But with type safe dependency injection and error generation and, and using effect pretty extensively for the last three or four weeks has really made me. Itch for some of those benefits in React. [24:44]
-
-I'd be curious to see if they can, well, I've got a little bit more connections to make on that later on, so I guess I'll end it there. I don't know, just about dependency injection in effect and type safety and whatever in the context of selecting data on the front end, I think is interesting. [25:05]
-
-I think there's still a lot of API design exploration to do there. [25:20]
-
-**Mark:** I definitely recommend taking a few minutes to read some of Joe's comments in that context. Selector's, RFC thread, if you got some time, and then I, I expect there be, and to be at least some announcements, possibly about concurrent stores coming up at React Conf in October. [25:25]
-
-**Carl:** Interesting. [25:41]
-
-**Mark:** Then the last item out of the React related changes they merged a PR to add what looks like a new suspense timeline to the dev tools. They've got a demo video in there, and so it looks like it's actually now a, a third extra tab in the Chrome dev tools. So you've got the component tree, you've got the performance tab, and then there's a suspense timeline tab. And it looks like what it does is a mixture of , a rough rec out, like rectangle outline of the shapes of your components, but not showing like any of the HTML, just like , here's the structure of what your component tree looks like visually, and some highlighting for which ones have suspended, and then possibly some further details in a sidebar about which components suspended and when. So. as a dev tools type person, I'm always very, very excited to see new dev tools capabilities being added. [25:42]
-
-## Lee Robinsons’s [“Reflections on the React Community”](https://leerob.com/reflections) wrap-up post
-
-**Carl:** Okay, let's go into. We talked a little bit about Lee Rob leaving Vercel recently and going to Cursor. He put out a really great blog post called Reflections on the React Community. This sort of summarizing his, his time at Next and in React. Yeah, I don't know. Mark, do you wanna start? [26:39]
-
-I don't know if I have anything specific to start here. It's a really good overall hot, you know, 30,000 foot view of his time. [26:59]
-
-**Mark:** So Lee Robinson was the primary developer relations person for Vercel for about five plus years. And even in my own head like. when I hear the word devel Lee is pretty much the first person that comes to mind. And Lee was always in a very tough position. You know, CEL is, you know, a somewhat divisive company in some ways. You know, it, it puts out some wonderful technology. They've genuinely done a lot to advance the React ecosystem makes, make apps, you know, easier to host, they build next, et cetera. But, you know, they've also been accused of, you know, the React team and pushing reacts direction and making changes just for profit. And you know, as I've discussed in some previous episodes and blog posts, like a lot of that is undeserved criticism or, you know, misinterpretation of the background. And so, as you know, the visible face of Vercel and the next team we was. Frequently the target of a lot of those criticisms, even though, you know, none of it was, you know, like he wasn't the one developing the tool set or, you know, making the businesses decisions. And one of the things I've always appreciated about Lee is that, you know, he was always very, very active in discussions on, you know, Reddit and Twitter and Hacker News. You know, like not just in like the next sub Reddit, but you know, the React Reddit hacker news discussions. Like anytime a discretion thread would happen, he would pop up and, you know, respond to comments, offer feedback, and, you know, yeah. [27:07]
-
-Because of his position. Like occasionally people would interpret it as being like a corporate ish response, but he was always very, very active in being in there. And unfortunately that meant he was also the, you took the brunt of a lot of the criticism. So a lot of his blog post, you know, talks about, you know, react has, react has become stable, it's grown, the community's big. [28:48]
-
-Working with any community is really, really hard and it can be very stressful and very frustrating. He talks a bit about some of the difference between, you know, a, you know, more broadly like projects like React versus Rails you know, dealing with some of the community management acts, aspects, how you get feedback. He even talks some about, incentives like the React team in some ways builds react for meta. And sometimes that means that, you know, issues slip through the cracks. You know, like Meta isn't trained to make money off React. Well, in some ways Vercel is. And he also talks about, you know, some of the, the server component development process, how that was marketed how it's been interpreted. And he talks about burnout. And boy can I understand and sympathize with this one on multiple levels. responding to issues and comments, even when they're positive, takes a lot of time and effort. And when a lot of those comrades are, you know, angry and critiquing and throwing around conspiracy theories, that wears away at you a lot. So I have a huge amount of respect for Lee and everything he's done for Vercel and next in the React community over the last several years. And so I appreciated him doing the writeup and I could totally identify with a lot of the points he was making in here. [29:13]
-
-**Carl:** Yeah, definitely. And it's funny, I, you know, nobody, nobody's ever paid me to do reactive flux things, and it's a very different type of like community management. But I definitely, a lot of what he said resonated with me. But from that perspective, and also just like, I don't know. The burnout and, you know, thanklessness of wrangling a large group of people is is pretty real. [30:35]
-
-**Mark:** So it's a post worth reading. And Lee, if you ever hear this, thank you for all your time and effort. [30:58]
-
-**Carl:** Yeah. Thank you for all your time and effort. It's been a lot. It's been great. what you said about like Lee really being like you think Lee, Robb is definitely a canonical dev rel, like showed the world how dev rel happens. I think [31:04]
-
-really, uh, personified it. [31:16]
-
-## [Remix doing its own component model??](https://x.com/mjackson/status/1954975322157486408)
-
-**Carl:** Maybe in two remix doing its own component model. [31:18]
-
-**Mark:** we've been doing sort of a running observation of what in the world are Michael Jackson and Ryan Florence doing over in their corner. They, they continue to drop cryptic hints on Twitter about the directions of remix version three. And while this isn't, trying to keep this from being the, just repeat what they say on Twitter podcast, but, you know, so far all we have to go by is the cryptic hints that they're dropping. And so we've gone from, you know, just Remix v3 is its own thing to, it's going to use Preact to, well, actually, I guess now it's not using Preact. [31:22]
-
-**Carl:** Yeah, so I, I, I guess they want to explore a similar kind of problem space as react and React are, I mean, I, you know, that's the signals that they're putting out here is that like, well, these existing tools do not solve the problem well enough, we believe. And so we're going to explore that. And, you know, I, fair enough, I, I think there is more room to explore there. [32:01]
-
-I know some discussion in reactive flux on this, you know, on this link earlier Ricky had said like, you know, good luck to them. I think they may find some of the same constraints as React has, and I think that's pretty likely. But, you know, also there's a term coming to mind uh, path dependence, which is, you know, like what the options available to you going forward are dependent on the choices you made in the past. [32:26]
-
-And so, like, you know, react is pretty far down, it's set of chosen decisions. So I think there is some value in backing out and saying like, well, hey, maybe we're in a local maximum. Let's explore some other possible paths here. And yeah, so let me pick up where I sat down earlier talking about effect. [32:49]
-
-Right. So like, it, it feels to me like a componentized model for the backend. And it's really interesting because each, you know, backend component that you write, which I'm, they call 'EM Effects, but you know, this is a React chat, so I'm going to translate. So you write like a backend component and it has a type safe it uses TypeScript generics to describe its outputs, its possible errors emitted and what dependencies it requires to be passed in effects. [33:08]
-
-These backend components can like, make their own dependencies available, you know, or they can say, you need to provide this at runtime. And so that's pretty, that feels very similar in use to me in like ideology to me as what React is trying to do. [33:37]
-
-**Mark:** your props and your output. [33:54]
-
-**Carl:** Right. Props, return value, boom. Like, okay, every return value is JSX and it doesn't really matter specifically what, but you know. Yeah. So it, it, it's really interesting having error safety as well as dependency type safety because like props are one thing. But you know that there's no way to describe that. [33:56]
-
-This component being rendered relies on being nested underneath a context provider. Like you can do a runtime check for that, but you can't do a a compiled time type safety check for that. And that's the kind of thing that effect is enabling. It's that kind of dependency injection. Like what environment does this expect to be run in, not just what inputs does it expect to be provided. [34:16]
-
-I. So like using that in a backend context, you know, in this, going all in on this in a backend space where it's intended to be used has really made me reflect on the experience of using React and what kind of, what some of its pain points are. And so I guess like the React core team has gone all in on the transition boundary between the client and the server with server components. [34:41]
-
-Like they wanna really make that smooth and instead of this request response model, just have it be more fluid and you know, whatever. Yeah, streaming all that which is great and that's a very interesting direction to explore, but it does not address all of those kinds of things of how do we make a robust. [35:04]
-
-Reliable application that can be statically verified, will run as expected. And that is more of where effect is coming at the problem space of code authoring from. And yeah, I think the, like both of those are really interesting viable problem spaces to explore. And if Remix is saying, we think the path that React is exploring is not the ideal user experience, maybe they're gonna go more in something like this. [35:23]
-
-And if they do, this is wild, pure, rampant speculation on my part right now. But if they, you know, I can see a possible world where one thing that might interest them is the same kind of guarantees that effect is trying to provide. And that would be valuable. Like, so I, I, yeah, I'll still be paying attention to this. [35:51]
-
-I do have a greater degree of skepticism it's a huge expansion of what scope of problem they're exploring. So that's challenging. But you know, they've taken on big challenges before. Shipped things. So yeah, we'll be paying attention and see what they see. What they come out with. [36:09]
-
-**Mark:** Yeah, so basically where things stand at the moment are lots of cryptic hints on Twitter. It's not gonna be a React. It's a different component model. They want to make it LLM friendly. We still haven't seen any good examples, but I'm assuming they will do a big announcement at the Remix Jam conference, which I think is in [36:24]
-
-October. [36:42]
-
-**Carl:** Yeah. Oh, they had just done, just recently announced that. [36:43]
-
-## [Remix 3 and the End of React-Centric Architectures](https://thenewstack.io/remix-3-and-the-end-of-react-centric-architectures/)
-
-**Mark:** And then along with the rampant speculation bit I saw a blog post just earlier, earlier today, but it was from a month ago called Remix Three and the End of React Centric Architectures, which also does a bit of, you know, speculating, hypothesizing on the ways various frameworks have chosen to build things and says, you know, maybe it's a good thing that Remix three is supposedly going back to a more web native framework approach. [36:46]
-
-**Carl:** Yeah, and they're doing Remix Jam right after React Conf in Toronto, so, yeah. We'll, we'll shot that out at the, in the conferences section at the end too. [37:13]
-
-## [Popular nx packages compromised on npm](https://www.aikido.dev/blog/popular-nx-packages-compromised-on-npm)
-
-**Carl:** Yeah. Okay, moving on. our last main content subject for the month, there's another security vulnerability. I feel like we, you know, we, we, we talk about these somewhat regularly it feels like, but some pretty popular NX packages were compromised on NPM. So NX is a, [37:21]
-
-**Mark:** Monorepo management and build tool [37:39]
-
-**Carl:** yes. It's a competitor to turbo repo. I, I, I think I would [37:42]
-
-**Mark:** to, to some extent. Yeah. [37:46]
-
-**Carl:** it got wholesale compromised as in like everyone who installed it had a post install script run that swiped a bunch of configuration files like .env and .npmrc, anywhere you can think that credentials might be stored in your project workspace or elsewhere on your system. [37:47]
-
-This script looked for and then uploaded to GitHub. So that's really bad. This is a, this is a, this is a theoretical exploit that I've been hearing about for the last 10 years. Like the vulnerabilities possible by NPM post install has been a subject that comes up every couple of years. And, oh boy, this is a bad one. [38:07]
-
-The, this blog post discussing the vulnerability said that when they were, they were monitoring GitHub. 'cause the way the script worked is it would, if it found your GitHub credentials, if it found a valid SSH key for GitHub or I guess actually an API token, not an SSH token. But if it found a GitHub API token, then it would silently upload a new repo. [38:27]
-
-So it, it, which is interesting because it was a public repo on GitHub created by this malware. So there was some kind of public metric that could be gathered for its scope of impact. And so there this blog post says that they saw at one point, 1,400 of these repos created by this malware script. [38:51]
-
-So like, that's quite a number of people who got all of their secrets swiped off their system. One interesting thing that this malware did is if it found an LLM tool on your system, it would write a prompt to that LLM asking it to find all of the secrets on your system. So like if you, if you've got Claude, like suddenly Claude is maliciously gathering all of your tokens from your entire system that it can, you know, whatever it can access. [39:11]
-
-Like, holy shit, that's bad. That's not, yeah, that's, that's pretty bad. [39:38]
-
-## Last month [eslint-plugin-prettier maintainers were targeted](https://snyk.io/blog/maintainers-of-eslint-prettier-plugin-attacked-via-npm-supply-chain-malware/), this is a much broader attack
-
-**Carl:** you know, last month we discussed a, another vulnerability where the eslint-plugin-prettier package maintainers were targeted. So I guess this, this could be, this could be the same attackers perhaps, and they were just more successful in that, you know, instead of. Getting busted while trying to steal credentials for a major packages maintainers. [39:43]
-
-They actually got it. And so now they have successfully executed on this broader attack that they were maybe trying to do earlier. Woo. That's bad. And it sucks 'cause like what do you, how do you even respond? What do, how can you keep yourself safe if just [40:02]
-
-**Mark:** Monitor your, monitor your dependencies, actually look at lock files. I, I can say that there are some good tools out there that will watch PRS for, you know, like what packages are getting updated in this PR and, you know, warn you if any of them have known PO known problems. That's definitely a valuable thing to include in the CI process. [40:16]
-
-**Carl:** Yeah. True. But man, one of the, one of the challenging parts about this particular vulnerability is the. I, I remember half of the discussion that I saw earlier, and I can't remember where I found it, so I can't quickly refresh my memory, but there, a, a popular tool uses NX at latest on like, you know, project Bootstrap. [40:39]
-
-So like, you know, if you're just casually idly using whatever project generator this was to start something new oops. You got the latest NX that was compromised. So like that's not even, yeah, I don't know. Just like [40:59]
-
-**Mark:** the comment was actually in the, the tech reads and news link and it was [41:13]
-
-the NX vs. Code extension. [41:16]
-
-**Carl:** Okay. Okay. That's a li that's at least a little bit different vs. Code extension is not as popularly used as a, you know, project bootstrap tool, but yeah, not great. [41:19]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Okay. Into the lightning round. [41:31]
-
-**Mark:** Go for it. [41:33]
-
-## [React Strict DOM vs React Native for Web in 2025](https://shift.infinite.red/react-strict-dom-vs-react-native-for-web-in-2025-bb91582ef261)
-
-**Carl:** I saw this post from, it was a blog post summarizing a podcast from react Native Radio from Infinite Red. Great Folks. They spoke with the maintainers of React strict Dom and React native for web comparing and contrasting. We had discussed React strict dom a about a year and a half ago. [41:33]
-
-It was like February of 2024. And a, a lot of what we did was compare and contrast it against React native for web. So this was like very precisely the type of conversation we had except with the maintainers who aren't just speculating and guessing and inferring, but like they, no, they made this like, they know how it works. [41:54]
-
-They know what the trade-offs are. So it's got some really great architectural diagrams explaining the distinction and what the difference is. It lines up pretty well with what I recall us discussing and they have a really good little flow chart for making decisions about you know, TLDR should you adopt React strict dom. [42:13]
-
-And they did a nice little handy visual, which I'm gonna go to the Happy Path through the Happy Path on, which is do you already have React native app? No. Will you need web support eventually? Yes. Use extract Dom. So like basically they're saying this is a great low level set of abstractions that will make it more feasible to reuse your code in more places. [42:30]
-
-You know, like the benefit has always theoretically been that you could reuse much of the code between React native and web. But I've tried to do that a couple of times and the practical realities are challenging. Like, you know, just you need to use doing abstractions so that, that work in both places is really hard. [42:54]
-
-So this acknowledge React native sorry, react strict. Dom sort of acknowledges that and says, rather than trying to make a brand new abstraction on top of both React Native and react dom, we are going to lean more heavily on the web platform as an existing stable abstraction. Which is cool. I like it. [43:12]
-
-It seems cool. This is a really great blog post. Definitely recommend. [43:31]
-
-## [Faster JSON.stringify()](https://v8.dev/blog/json-stringify)
-
-**Mark:** The V8 JavaScript engine developers put up a post where they said they've spent a lot of time trying to optimize js, ON stringy. Think about how many times your code stringys stuff, whether it's sending back an H TT P response or you know, serializing things into an extension. they go, they go into a bunch of technical detail about how they've tried to make this faster. [43:34]
-
-**Carl:** specifically that problem parsing Jason, Jason Parse performance is exact, like that was the reason for React native doing the new architecture, which they've spent like much of the last year communicating and executing on. So yeah, the massive problem for the entire ecosystem, [43:56]
-
-**Mark:** You know, like other than actually executing the JavaScript code faster, like string finding stuff has to be [44:14]
-
-one of the most common things your JavaScript code does. So I believe this is supposed to be out in, I think it was like V eight like 13.8 I think it said which is available in Chrome 1 38. And I don't know what node version will contain that, that version of V eight. But faster is good. [44:19]
-
-**Carl:** Yeah, faster is so good, especially for stringifying. Yeah, man. Just the number of plate serializing and des serializing is one of the largest costs, you know, performance costs like everywhere. So yeah, it'll love that. That's great. [44:42]
-
-## [Node 22.18 unflags TS type-stripping support](https://nodejs.org/en/blog/release/v22.18.0)
-
-**Carl:** Node 22 point 18 flags TypeScript type stripping support. [44:56]
-
-node has had experimental support for. Interpreting TypeScript code and stripping out the types. doesn't actually check them or anything, but it allows you to take a project authored natively in TypeScript and run it with node without a compilation step, without building it through the TypeScript compiler. [45:02]
-
-**Mark:** Or, or using a tool like TS Node to execute it. [45:21]
-
-**Carl:** Yes. Yeah. Right. More directly. This is a replacement for TS node. And that's great. It's no longer experimental. It's, they're now saying it works. it's officially blessed, it's released. Love that. Definitely the ecosystem has moved more from, you know, a long time ago it was very focused on you compile the code and then you take those built artifacts and you run them, and if the type checker fails, you don't get a built artifact and you know, the metagame here has shifted a little bit more into the. Type checking is one very valuable part of verifying your code statically, but it is not necessarily where the compilation step lives. So, many more projects in my experience have moved towards sort of a parallel model where you have a build step and there is type checking in the project, but it just kind of runs separately from that build step. [45:24]
-
-So this is, this is a great tool enabling that kind of pattern. And it's released, it's done. Yay. [46:16]
-
-## [Waku switches to Vite’s WIP RSC support](https://waku.gg/blog/migration-to-vite-plugin-rsc)
-
-**Mark:** A couple RSC and project related updates. We've talked previously about how, vet itself has been missing some pieces in that would enable like full RSC support for vet based frameworks and that there has been a work in progress PR to try to add better RSC primitives into vet somehow. So the Waku RSE framework is now making use of vet's work in progress plugin rather than whatever layers they had built for themselves internally already. So it's good to see that that's coming together. [46:23]
-
-## [Rari, a fast React framework with RSC support built with Rust](https://ryanskinner.com/posts/how-i-built-a-full-stack-react-framework-4x-faster-than-nextjs-with-4x-more-throughput)
-
-**Mark:** And then I saw an announcement for a new framework called rari, which is sort of an acronym for something, some, something faster rendering somehow. But it looks like a, it's supposed to be an RSC based framework that has a custom low level layer. Built with rust. And of course, as we all know, rust makes everything faster. But it sounds like someone looked at some benchmarks of, you know, like next RSC performance and said, I think I can do better myself. And has built their own full stack framework that has RSC support using a custom low level rust layer. [47:00]
-
-**Carl:** Neat. Cool. Yeah, they do claim four, four times faster component rendering under load four milliseconds versus 17 milliseconds. And that's cool. I don't know that if your problematic performance is 17 milliseconds, that's maybe not the worst problem to have. [47:37]
-
-## [Selecting values from query results](https://tkdodo.eu/blog/react-query-selectors-supercharged), as well as [The Useless useCallback](https://tkdodo.eu/blog/the-useless-use-callback)
-
-**Mark:** Then separate from all that the always wonderful Dominic Dome TK Dodo has put up a couple great blog posts. One is the latest in the series of posts on how to use React Query correctly in this case, how to use the ability to select values out of a query. So maybe like you have a, a list items query and you only want to grab one of 'em. And then you also put up a post talking about how a lot of time you don't actually need the used callback hook. There's a lot of cases that used callback is actually kinda useless. So excellent reading as always. [47:52]
-
-## [TS\+ postmortem (Effect-TS experimental TS fork)](https://effect.website/blog/ts-plus-postmortem/)
-
-**Carl:** Can you tell I've been using effect and it's just been living in my brain for a lot of the time. I, as part of reading it, I found this blog post that they wrote pretty recently beginning of July. Where they had done, they had actually forked the TypeScript compiler wholesale and tried to do what they called TypeScript plus TS plus. [48:26]
-
-And I guess part of the idea, as you, as I've been using effect, I can feel very strongly the desire for JavaScript to support a couple of different tools that I, I I, I had remembered seeing as proposals many, many years ago and waited many, many years for them to land mo specifically the pipeline operator for composing functional, you know, programs together and pattern matching, which resembles a switch case, but lets you match on like properties and attributes and, you know, things like that in a different way, in a more flexible way. So. They tried to fork the compiler to make errors a little bit better. Basically, like they're really pushing the bounds of everything you can do in TypeScript and JavaScript. [48:45]
-
-So the, as part of that, they explored fully forking, TypeScript and this, so this is a great postmortem of their design goals and what they were trying to achieve and why they have backed off of that. Yeah, how far we went and what went wrong, what we learned it's pretty good. Definitely very interesting like this. [49:35]
-
-Just reading more about effect, I can just like, it just the amount of the number of different places where they're pushing the envelope and like iterating on the state of the art in web on the backend is just really palpable to me. So, definitely an interesting read here. [49:55]
-
-**Mark:** I, I, I thought it was a good blog post. Honestly, I also partly appreciate it just because they said we spent like an entire year trying to build this thing and it didn't pan out. Here's what we tried and what we learned and what went wrong in the process. I, I, appreciate good art, good write-ups, like that. [50:12]
-
-**Carl:** Yeah, right. I feel like this is good to read as an engineer because it's just a really good postmortem where you can really understand their thought process of why they tried to do this, what benefits they were hoping to get, and what challenges they ran into that made them say, okay, this is not achievable. [50:29]
-
-Just really good, really good read. [50:46]
-
-## [React useTransition update ordering details](https://jordaneldredge.com/notes/react-rebasing/)
-
-**Mark:** I saw a good short post from Jordan Eldridge, who I believe created the web amp recreation of Winamp. Where gave some, gave some thoughts on what happens when you do a React used transition and you apply some other state updates while the transition is going on. Short but useful, especially since transitions are a newer part of the react rendering model. [50:48]
-
-## [“A Clock that Doesn’t Snap”](https://ethanniser.dev/blog/a-clock-that-doesnt-snap/), Techniques for fixing hydration of values like dates
-
-**Mark:** And then I also saw a post called A Clock That Doesn't Snap, which talks about some of the dealing with inconsistency problems between server rented values like dates, and then what happens when you try to actually hydrate that on the client. And a couple different techniques for trying to make it not be inconsistent. [51:13]
-
-**Carl:** Interesting. [51:35]
-
-## [React Cache: It’s about consistency](https://twofoldframework.com/blog/react-cache-its-about-consistency)
-
-**Mark:** There was an article on React Cache. It's about consistency, so React added the cache, API for use on the server, and it's, it's a sort of memo function. The idea is that you can get, like if you need to make one fetch call in multiple places while doing server side rendering, you can try to ensure that it only happens once during that particular render pass on the server. And so the post goes into some detail on what the cache method is, why you want, would want to use it, and how it, you know, actually using that cashed value during the render can produce more consistent results during the render process. And then goes into a little bit more about like some of the conceptual behavior of React components and what is pure versus impure anyway. [51:36]
-
-## [Self-hosting Next at scale](https://dlhck.com/thoughts/the-complete-guide-to-self-hosting-nextjs-at-scale)
-
-**Mark:** saw an article that gave some battle hardened details on the complete guide to self-hosting Next JS at scale. So next is commonly used with Vercel. You can deploy it yourself, but you sometimes have to fill in some of the missing hosting pieces. And so this was a good post that gave and that talked about, you know, what are, what happens when you try to use Next Cache? [52:26]
-
-And it by default cache is values locally. But if you've got multiple copies of the server rendering, now you can have inconsistencies between different instances. So how would you break that out into using a Redis server or something? Instead, how can you handle image optimization and CDN configuration? So if you're trying to do any self host, you know, next, this looks like a very useful guide. [52:53]
-
-**Carl:** Love that. Such a good, deep technical writeup of, I mean, right. Self-hosting next is such a big problem that people discuss regularly that I, I just love seeing, you know, a proper writeup about it. [53:14]
-
-## [Server and Client Component Composition in Practice](https://aurorascharff.no/posts/server-client-component-composition-in-practice/)
-
-**Mark:** Then finally we have a post from Aurora Scharf who spent a lot of time researching and writing about server components and various usage patterns, and she has an excellent post on server and client component composition in practice, which gives some examples of how you can intermingle server and client components to do some of the work on the server, some of the work on the client figure, and figure out where the boundaries ought to be. [53:26]
-
-**Carl:** Yeah. figuring out where the boundaries are should lie in things that's uh, very challenging. [53:53]
-
-**Mark:** And I think that's actually all we've got for this month, which is good 'cause we're right about at at time. [53:59]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Cool. Let's wrap up here with some conferences. [54:04]
-
-## [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025\\. Wrocław, Poland
-
-**Carl:** We got React, Universe coming up in just about a week in September 2nd through fourth in Wroclaw, Poland. [54:06]
-
-## [WaysConf](https://www.waysconf.com/) Sept 16-17
-
-**Carl:** There's also Ways Conf September 16th and 17th. Krakow Great. Also in Poland. So yeah, Poland heavy uh, September. [54:14]
-
-## [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
-
-**Carl:** Then right after that, Cascadia Js, September 18th and 19th in Seattle. [54:21]
-
-## [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
-
-**Carl:** Coincident with Squiggle Con September 18th in Boston, which I will be at [54:26]
-
-## [React Alicante](https://reactalicante.es/) Oct 2-4
-
-**Carl:** Then in October we've got React Alicante, October 2nd through fourth in Spain. [54:32]
-
-**Mark:** I will be speaking at that one. [54:37]
-
-I was not going to be there originally, but I will be flying back from Spain and showing up at React Conf in Las Vegas. That's gonna be a trip. [54:39]
-
-**Carl:** Yeah. Oh, wild. Yeah. [54:49]
-
-## [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
-
-**Carl:** 'cause we've got, you know, react conf in Las Vegas right. Then October 7th and eighth, [54:51]
-
-## [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
-
-**Carl:** then, like we mentioned earlier, we've got Remix Jam October 10th in Toronto. So if you really, like, you could fly out to Vegas and then fly across the, well, I was gonna say across the country, but it's a different country. You can fly across the continent to Toronto. [54:56]
-
-## Outro
-
-**Carl:** Cool. That's all we got for you today. Thanks so much for joining us. We will be back on the last Wednesday of the month here in the live stage or back in your podcast feed just as soon as we can after that. [55:10]
-
-**Mark:** Thank you all for listening. Hopefully the list of links has been useful and informative. If you are going to be at either Squiggle Con, react Delicate, react Ante, or React conf please say hi. I will be running around possibly wearing my Simpsons picture as a name tag. [55:19]
-
-**Carl:** great. Love that. Yeah, same. Likewise. If you see me in Boston or in Las Vegas say, Hey, We gather sources from this week in React Bites, dev the React JS subreddit, and here in Reactive Flux from the uh, tech News and Reads channel. If you see anything that you think we should discuss definitely send it over to us at hello@reactiveflux.com. [55:37]
-
-if this is a show you get value from and wanna support, best way you can do so is by submitting a review on wherever you listen and tell your friends and coworkers about it. Thanks so much. you next month. [55:56]
-
-**Mark:** Take care. [56:04]
diff --git a/src/transcripts/tmir-2025-09.md b/src/transcripts/tmir-2025-09.md
deleted file mode 100644
index e58673b..0000000
--- a/src/transcripts/tmir-2025-09.md
+++ /dev/null
@@ -1,728 +0,0 @@
----
-title: "TMiR 2025-09: React 19.2 on the horizon; npm is still getting compromised"
-date: 2025-09-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-- [[00:52](#new-releases)] New releases
- - [[00:54](#tanstack-start-10-rc)] [TanStack Start 1.0 RC!](https://tanstack.com/blog/announcing-tanstack-start-v1)
- - [[01:13](#react-window-20-rewrite)] [`react-window` 2.0 rewrite](https://react-window.vercel.app/)
- - [[01:44](#apollo-client-40)] [Apollo Client 4.0](https://www.apollographql.com/blog/announcing-apollo-client-4-0)
- - [[01:59](#redux-toolkit-290)] [Redux Toolkit 2.9.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.9.0)
-- [[02:47](#main-content)] Main Content
- - [[02:52](#react-192-coming-soon)] [React 19.2 coming soon?](https://bsky.app/profile/ricky.fm/post/3lzt6yvs6o22r)
- - [[03:24](#activity-in-canary-with-docs)] [ in canary, with docs](https://react.dev/reference/react/Activity)
- - [[07:18](#last-react-labs-post-mention)] [last React Labs post mention](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#activity)
- - [[11:43](#useeffectevent-in-canary-and-has-docs)] [`useEffectEvent` in canary and has docs](https://react.dev/reference/react/useEffectEvent)
- - [[15:47](#compiler-inferring-function-names)] [Compiler inferring function names](https://github.com/facebook/react/pull/34410)
- - [[16:08](#docs-for-eslint-plugin-react-hooks-including-rules-and-compiler-issues)] [Docs for `eslint-plugin-react-hooks`](https://react.dev/reference/eslint-plugin-react-hooks), including rules and compiler issues
- - [[17:15](#react-native-10-on-the-horizon)] [React Native 1.0 on the horizon](https://youtu.be/GPtopk4y2LI?si=JoZVprPW33szn-6D)
- - [[22:02](#react-won-by-default--and-its-killing-frontend-innovation)] [“React Won by Default – And It's Killing Frontend Innovation”](https://www.lorenstew.art/blog/react-won-by-default/)
- - [[22:18](#inevitable-hn-argument)] Inevitable [HN argument](https://news.ycombinator.com/item?shownew&id=45252715)
- - [[27:54](#ricky-on-ryan-carniatos-stream-talking-about-scheduling-and-demoing-using-modern-react-features)] [Ricky on Ryan Carniato’s stream](https://www.youtube.com/watch?v=3vw6EAmruEU) talking about scheduling and demoing using modern React features
- - [[33:41](#server-components)] Server Components
- - [[33:44](#react-router-rsc-framework-mode-preview)] [React Router RSC framework mode preview](https://remix.run/blog/rsc-framework-mode-preview)
- - [[34:36](#also-middleware-is-now-stable)] also [middleware is now stable](https://remix.run/blog/middleware)
- - [[34:44](#krasimir-tsonevs-can-i-use-rsc-today-support-matrix-and-experimental-forket-rsc-without-a-framework-build-tool)] Krasimir Tsonev’s [“Can I Use RSC Today?” support matrix](https://rsc.krasimirtsonev.com/) and experimental [Forket “RSC without a framework” build tool](https://krasimirtsonev.com/blog/article/vanilla-react-server-components-with-no-framework)
- - [[35:43](#rsbuild-support-for-rscs)] [RSBuild support for RSCs](https://bsky.app/profile/ebey.bsky.social/post/3lyf6vixick26)
- - [[35:55](#useful-post-on-parallel-and-recursive-route-rendering)] Useful post on [parallel and recursive route rendering](https://twofoldframework.com/blog/parallel-and-recursive-route-rendering-with-rsc)
- - [[36:35](#all-the-npm-compromises-and-malware-this-month)] All the NPM compromises and malware this month
- - [[39:47](#npm-package-maintainer-qix)] [npm package maintainer Qix](https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack)
- - [[39:48](#crowdstrike-npm-packages)] [CrowdStrike npm Packages](https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages)
- - [[40:16](#github-actions-npm-token-theft)] [GitHub Actions npm Token Theft](https://socket.dev/blog/nx-supply-chain-attack-investigation-github-actions-workflow-exploit)
- - [[41:01](#github-response)] [GitHub response](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/)
-- [[42:00](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[42:03](#porting-modern-typescript-to-run-on-dos)] [Porting Modern TypeScript to Run on DOS](https://jimb.ly/2025/09/23/qauntumpulse-from-steam-to-floppy/)
- - [[42:35](#cloudflare-ddosed-themselves-with-a-bad-useeffect-fetch)] [Cloudflare DDOSed themselves with a bad `useEffect` fetch](https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/?amp%253But)
- - [[43:11](#a-very-lovely-writeup-of-the-evolution-of-css-zoom)] [A very lovely writeup of the evolution of css `zoom`](https://www.bocoup.com/blog/the-webs-most-tolerated-feature)
- - [[43:56](#what-you-need-to-know-about-modern-css)] [What You Need to Know about Modern CSS](https://frontendmasters.com/blog/what-you-need-to-know-about-modern-css-2025-edition/)
- - [[45:21](#fetch-streams-are-great-but-not-for-measuring-uploaddownload-progress)] [Fetch streams are great, but not for measuring upload/download progress](https://jakearchibald.com/2025/fetch-streams-not-for-progress/)
- - [[45:40](#why-do-browsers-throttle-js-timers)] [Why do browsers throttle JS timers?](https://nolanlawson.com/2025/08/31/why-do-browsers-throttle-javascript-timers/)
- - [[46:01](#how-modern-browsers-work-deep-dive-addy-osmani)] [“How Modern Browsers Work” deep dive, Addy Osmani](https://addyo.substack.com/p/how-modern-browsers-work)
- - [[46:32](#biome-stress-testing-wip-nofloatingpromises-lint-rule)] [Biome: Stress-testing WIP `noFloatingPromises` lint rule](https://vercel.com/blog/stress-testing-biomes-nofloatingpromises-lint-rule)
- - [[48:37](#bun-how-bun-install-is-so-fast)] [Bun: How `bun install` is so fast](https://bun.com/blog/behind-the-scenes-of-bun-install)
- - [[49:23](#styled-components-fork-for-perf-and-react-19-compat)] [Styled-Components fork for perf and React 19 compat](https://www.sanity.io/blog/cut-styled-components-into-pieces-this-is-our-last-resort)
- - [[50:02](#vite-ssr-custom-getstaticprops)] [Vite SSR: Custom `getStaticProps`](https://www.patron.com/blog/post/vite-ssr-getstaticprops-replacement/)
- - [[50:11](#dominic-gannaways-new-framework-ripple)] [Dominic Gannaway’s new framework Ripple](https://github.com/trueadm/ripple)
- - [[50:35](#remix-v3-mj-hints-iframe-like-async-primitives)] [Remix v3: MJ hints “iframe-like async primitives”](https://x.com/mjackson/status/1971816432427298951)
- - [[51:57](#react-native-rfc-to-remove-old-architecture)] [React Native RFC to remove Old Architecture](https://github.com/react-native-community/discussions-and-proposals/pull/929)
- - [[52:28](#cloudflares-new-capn-web-rpc-graphql-alternative)] [Cloudflare’s new “Cap’n Web” RPC; GraphQL alternative?](https://blog.cloudflare.com/capnweb-javascript-rpc-library/)
- - [[55:26](#expo-ui-building-swiftui-apps)] [Expo UI: Building SwiftUI apps](https://docs.expo.dev/guides/expo-ui-swift-ui/)
- - [[55:57](#tanstack-db-an-interactive-guide)] [TanStack DB: An interactive guide](https://frontendatscale.com/blog/tanstack-db/)
- - [[56:21](#ts-60-may-switch-to-strict-options-by-default)] [TS 6.0: may switch to `strict` options by default](https://github.com/microsoft/TypeScript/issues/62333)
- - [[57:28](#shopifys-rn-new-architecture-migration)] [Shopify’s RN New Architecture migration](https://shopify.engineering/react-native-new-architecture)
- - [[57:42](#the-bloat-of-edge-case-first-libraries)] [The Bloat of Edge-Case First Libraries](https://43081j.com/2025/09/bloat-of-edge-case-libraries)
-- [[58:51](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[58:53](#react-alicante-oct-2-4)] [React Alicante](https://reactalicante.es/) Oct 2-4
- - [[59:13](#react-conf-is-back-oct-7-8-las-vegas-nv-usa)] [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
- - [[59:29](#remix-jam-oct-10-toronto-on-ca)] [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
- - [[59:43](#viteconf-oct-9-10-amsterdam-netherlands)] [ViteConf](https://viteconf.amsterdam/) Oct 9-10 Amsterdam, Netherlands
- - [[59:52](#jsconf-north-america-oct-14-16-chesapeake-bay-md-usa)] [JSConf North America](https://events.linuxfoundation.org/jsconf-north-america/) Oct 14-16 Chesapeake Bay, MD, USA
- - [[01:00:03](#jsconf-chile-oct-24-25-santiago-chile)] [JSConf Chile](https://jsconf.cl/) Oct 24-25 Santiago, Chile
- - [[01:00:10](#react-native-london-oct-30-31)] [React Native London](https://www.reactnativelondon.co.uk/) Oct 30-31
- - [[01:00:22](#react-india-oct-31-nov-1-goa-india)] [React India](https://www.reactindia.io/) Oct 31 Nov 1 Goa, India
- - [[01:00:26](#wey-wey-web-nov-17-18-malaga-spain)] [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
- - [[01:00:39](#react-summit-nov-18-21-new-york-ny-usa)] [React Summit](https://reactsummit.us/) Nov 18-21 New York, NY, USA
- - [[01:00:48](#react-advanced-nov-28th-london-uk)] [React Advanced](https://reactadvanced.com/) Nov 28th, London UK
-- [[01:01:08](#outro)] Outro
-
-# This Month In React - September 2025 (SM)
-
-Carl: Alright. Hello everyone. Thank you for joining us for the September edition of this Month In React. As we, uh, get together and recap what's going on with React, react Native and the web, we're coming to you live from Reactiflux, the place for professional developers using React. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I do community programs like these events and build tools to help keep the community operating. [00:00]
-
-Mark: Hi, I'm Mark. My day job is working at Replay.io and digging into the guts of React and its internals. And in my copious amounts of spare time, I'm currently rewriting the guts of Immer for faster performance. [00:23]
-
-Carl: Yeah, you did a live stream on that. That was cool. [00:34]
-
-Mark: Yeah, that was a lot of fun. [00:36]
-
-Mo: And my name is Mo. [00:37]
-
-I am the head of Mobile at Thedo. And yeah, I spent a lot of time in the React and React native communities, speak at conferences here and there, and organize the React Native London Meetup and conference, which is coming up in November. [00:38]
-
-Carl: Yeah, more on that later. [00:51]
-
-## New releases
-
-Carl: Let's jump into some new releases. [00:52]
-
-## [TanStack Start 1.0 RC!](https://tanstack.com/blog/announcing-tanstack-start-v1)
-
-Carl: We're gonna talk more about this in depth in the main content section, but Tan Stack start has released a 1.0 rc, so that should be coming together. I've tried playing with this a little bit and didn't make it too far. It just ended up being a larger task than I really imagined, but I'm excited about it. [00:54]
-
-## [`react-window` 2.0 rewrite](https://react-window.vercel.app/)
-
-Mark: React Window. Just put out a version 2.0. Brian Vaughn did a pretty major rewrite of the library to try to simplify some of the props and add some nice built-in features like automizing of the list items and auto resizing. So you no longer need a resize plugin to handle that. [01:13]
-
-Carl: Oh, that's nice. Okay. Yeah, and react window is efficiently rendering large lists. [01:32]
-
-Mark: It's virtualizing lists. Yeah, so you got a list of, you know, a million items. You can only show a hundred on screen at once, that sort of thing. [01:36]
-
-## [Apollo Client 4.0](https://www.apollographql.com/blog/announcing-apollo-client-4-0)
-
-Mark: Also, on that note, Apollo client for GraphQL just put out version 4.0. I know this was a, a pretty major effort to try to improve the packaging, consolidate. Remove a bunch of deprecated features, so that should be a significant improvement if you're using Apollo. [01:44]
-
-## [Redux Toolkit 2.9.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.9.0)
-
-Mark: And on my side, I actually just shipped a Redux toolkit 2.9 earlier this month. The biggest thing there is I made a bunch of perf optimizations to RTK query, especially for cases where you've got a lot of components that are reading from the same cache entry. And we also added a few new options and bug fixes, but the perf improvement and some in-flight requests cleanup was, were some of the biggest pieces there. [01:59]
-
-Carl: Okay. Yeah. Not too many new releases for open source libraries this month, I guess. [02:25]
-
-Mark: Well there, there probably were a few more. We just didn't collect them. [02:30]
-
-Carl: Yeah, I wish there were a little bit more consistent standards across the ecosystem for how to publish a list of new releases. Like the GitHub release is, it is pretty good, but it's still only like 60% hit rate, I guess. Something like that. [02:32]
-
-It feels like. [02:46]
-
-## Main Content
-
-Carl: Cool though. Let's go into our main content. Can you tell us a bit about React updates? [02:47]
-
-## [React 19.2 coming soon?](https://bsky.app/profile/ricky.fm/post/3lzt6yvs6o22r)
-
-Mark: I don't actually have any real details on this, but Rick Hanlon from the React team tweeted out like yesterday, a screenshot of himself apparently working on release notes for React 19.2, so I would assume it's fair to say that it's probably coming out in the near future associated with that and potentially coming out in 19.2. Although the timing may be a little too soon, we have two React features that have graduated from the experimental branch to the Canary branches. [02:52]
-
-## [ in canary, with docs](https://react.dev/reference/react/Activity)
-
-Mark: The first one is the new activity component. This has been around in some form in in the experimental branches for. Probably multiple years at this point. It was originally known as the offscreen component, and then they officially renamed it to the activity component maybe about six or eight months ago. [03:24]
-
-And this is gonna be a pretty big deal. So one of the issues with React has always been that built-in state is managed at the component level. And if you unmount a component, then it, you know, both cleans up the effects and they go away. But the state that was in that component goes away as well. And so that's one of the reasons why there's been, you know, so much use of external state libraries like, you know, Redux and Juice end and Jot and MobX over the years is because in order for state to persist, you either needed. [03:45]
-
-To have the state live outside UAC component tree, or you needed to hoist it up to the top and pass it down via context or props and if you unmount a section of the tree that DA and that data could go away. So the activity component is going to allow you to essentially disable and hide a section of the component tree, but react will keep around the state for those components. [04:22]
-
-And in fact this actually kind of goes along with some of the strict mode stuff that people have, you know, complained about for years. The activity component will also unmount the effects for the components that got hidden. People have complained for years, you know, strict mode, double running effects, you know, shows bugs and, and all the other things like that. [04:52]
-
-But part of the point of that has been to work towards, eventually this feature will come out where you can toggle the activity component on and off. And React will run the UNM mounts because the components aren't fully mounted, therefore, they shouldn't have active effects going. But it will keep the state for those components alive. [05:14]
-
-And so you can imagine this could be useful for a couple of different things. One is like a tabs component. Right now, if you have a tabs component, you either stop rendering the other tabs completely as you switch back and forth, or you use something like CSS display, none, which means the tabs are active and in the page, even though they're not even being displayed. [05:37]
-
-And so with the activity component, you can say I want to pre-render the content for the other tabs, but it's not actually attached to the page until we swap back and forth. But they could still persist the state. So if someone goes back and forth between the different tabs and makes some edits, then. [05:59]
-
-You know, that still stays alive. There's a comment in the chat that the naming choice for the component seems very strange to me. I agree. I didn't like it either. There was some rationale in the PR that actually renamed it to activity. I don't remember what it, what it was specifically off the top of my head, but they, I think it was that like, it's more about is the component active rather than is it quote unquote off screen. [06:19]
-
-Yeah. But I, I don't entirely buy that myself. [06:46]
-
-Carl: Yeah, right. Because this is like hitting that midpoint between that decision point of do you render null or do you render the dom with styling to suppress its visibility. And so I guess this is like smack in the middle, like the internal representation of all of that. [06:51]
-
-Dom remains. But you don't use styling to hide it, which is great for cross-platform stuff. 'cause like there wasn't a cross-platform way to hide something as far as I know before. [07:07]
-
-## [last React Labs post mention](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#activity)
-
-Mark: So if I, if I look back at the last React Labs post from April where they talk about, you know, the plans for the activity component, there's a section there that says, in the future we may add more modes for activity. [07:18]
-
-One of them could be content visible, but keep it unmounted and pause dom updates. Another is the ability to destroy state for hidden activities if too much memory is being used. So I think part of the mindset is it's not just like a bullion toggle, it's we're shipping with two mode options that are like a bullion toggle for now. [07:31]
-
-But we envision some possible additional modes for this down the road. [07:57]
-
-Mo: And, and you know, this is like particularly interesting to me because this has like been a long standing problem in the React native space when you're dealing with native apps. And I, I doubt this will work out of the box with React Native, but I think it's gonna be one of those things which will eventually get there. [08:02]
-
-And hopefully the new architecture makes this easy for the, the core team to adopt and like make sure that those APIs are working correctly. But it's a classic issue, especially when in Native world you're dealing with this concept of like stacks of pages on top of each other. You really don't want the, the stacks that aren't visible or the pages that aren't visible in your stack showing or getting all of the DOM updates, or in this case this, the updates to the actual screens whilst they're inactive because that's a massive performance bottleneck on native devices. [08:17]
-
-And so this type of thing, people have massed over it in the most dirty ways possible and hacky ways possible in, in the React native world. It's been like a longstanding problem because if you, you know, unmount them and then remount them and reestablish the state, there's sometimes like a flashing white screen before the actual components reload. [08:46]
-
-Then you need to delay the transition because all of these things are like transition with page transitions and native. So it's basically to say there's a lot of complexity and if there's a native React way to deal with this, that ties into navigation on the native device as well, then I think it's gonna be a game changer and it'll simplify and fix a lot of performance issues that people often have with their React native apps. [09:05]
-
-Mark: Yeah, I, I know we've, we've had a couple of open issues on the `react-redux` repo with people complaining that. Components that are off, quote unquote offscreen in the React native stack are still subscribed to Redux updates and taking up perfects from running all the subscription logic and asking for us to add random options to make that toggle or something. [09:26]
-
-And so if you know, the activity component ought to be the built-in solution for that. And so that would actually means we don't have to do anything, which is great. Yeah, exactly. [09:48]
-
-Mo: And you know, like some state management libraries have adopted some work around components that you can use for that, but it comes with trade-offs, right? [09:57]
-
-And ideally, your state management library really should not worry about this. This feels like a core react primitive problem rather than a state management library problem. To me, [10:06]
-
-Carl: back to what you said about like the layering of UI and performance problems and like listening to events and things. Fun fact, I've chatted with some people who did React native or like React UI for automotive companies and that was a problem they dealt with like sometimes for certain cars. [10:15]
-
-The reason the UI sucks sometimes is because of this issue and because it's rendering multiple UIs on top of each other and doing all sorts of weird, crazy stuff. There's two [10:35]
-
-Mo: devices that are particularly bad for that. One is Smart TVs and the other one is cars. And the reason for that is both of them are awful processors and like they really cheap out on the hardware because they're cutting costs everywhere in the actual like manufacturing bit. [10:45]
-
-And so something that might run in your web browser with your laptop that like has like several hundred megabytes of RAM per tab. Will, you know, be restricted to 50 megabytes of ram or it'll get killed by the operating system that lives on the automotive car infotainment system. And this is a big problem for any, like one of those types of devices. [11:01]
-
-And I think a lot of those, you'll be surprised, run on React and like web-based platforms or sometimes even rec native, and it's a big, big issue. So I think something like this. You know, you can fix those issues, but it's hacky and not everyone will do it. So then you'll get really crappy infotainment systems, like you said, Carl. [11:23]
-
-So, [11:40]
-
-Carl: okay. That's probably long enough talking about activity though. [11:41]
-
-## [`useEffectEvent` in canary and has docs](https://react.dev/reference/react/useEffectEvent)
-
-Mark: So one other, one other feature that's migrated from experimental to Canary, I just saw this one a few minutes ago, is the `useEffectEvent` hook. This is something that the React team has also talked about for a while, and I actually didn't even know that any progress was being made on this until I just saw the PR announcement. [11:43]
-
-I'm gonna describe this very badly. Someone should correct me on this, but it's almost like a used memo for callbacks where you'll get the latest reference to a. Callback inside when you execute it, but you get a consistent function reference back when you use it. And so this avoids the need to do a workaround where you're like, main, where the, the callback is reading something off of a ref to get the latest value. [12:04]
-
-I know that this is something that had been proposed a while back and then the initial proposal got killed and they said, we'll, we'll come back and we'll rethink this later. And apparently later is finally now. [12:34]
-
-Carl: Later is now. That's great. Yeah. Interesting. I'm, I'm not super up to date on this, so I'm just reading the docs right now to understand it better. [12:48]
-
-Interesting. The, I definitely know that I have used refs. You know, red values off refs because of weird issues. So I'm not quite groking how this solves this immediately, but that's interesting. [12:57]
-
-Mark: So, and okay, so a partial example, and again, this is me going off the top of my head and not even trying to read the post at the moment. [13:09]
-
-So, if you have like a used callback that needs to access a value, you either let the callback get recreated every time, which in case there's no point in the use callback at all, or you have the item in the dependency array, which means it's gonna, the callback is gonna get recreated still when the value changes or you don't rate it all, and oops, now you have a steel value, which is bad. [13:17]
-
-Carl: Right. [13:42]
-
-Mark: So what happens when you want a consistent callback reference that never changes, but it still needs to see the latest value in order to do something useful when it runs. So one workaround for this is you put a use ref a couple lines up in the component that runs first. You assign to it even in like another use effect before the one that you care about. [13:42]
-
-That means it gets updated. Now you've produced this kind of weird sequence of events where I know that the ref has already been updated before the callback ends up getting run. And so part of the point of this hook is to eliminate the need to do that little dance yourself. [14:08]
-
-Carl: Yeah. Okay. That makes sense. [14:24]
-
-I'm reading this list of caveats and it seems tricky. The only call inside effects define it just before the effect that uses them. Do not pass them to other components or hooks. Do not use `useEffectEvent` to avoid specifying dependencies. This can hide bugs. Sure. Use it only to extract logic that does not depend on changing value. [14:26]
-
-That's quite a set of constraints. [14:48]
-
-Mark: When the new docs came out, and Dan and a couple others wrote the tutorial. There were a couple pages in there that actually referenced this hook as the solution for some of the problems that were being described. Even though the hook didn't exist yet, some of the docs pages also try to make the terminology very unique, where they talk about lowercase e effects as in like, you know, just the generic concept of a side effect versus a capital E effect, which is like a somehow react specific concept that I don't think the docs ever fully defined. [14:51]
-
-And so in, in a way like the use effect event hook, is the React team trained to somehow solidify this. Notional react effect term in a way. [15:30]
-
-Carl: Interesting. Interesting. [15:46]
-
-## [Compiler inferring function names](https://github.com/facebook/react/pull/34410)
-
-Mark: Alright, two other little data points and, and updates Worth noting. The React team merged a work in progress PR to the compiler to try to do and to try to automatically infer function names for things like callbacks that you pass to use effect so that you know when they show, like show up like in a stack trace, they are nicer and easier to read. [15:47]
-
-## [Docs for `eslint-plugin-react-hooks`](https://react.dev/reference/eslint-plugin-react-hooks), including rules and compiler issues
-
-Mark: And then the docs now have a page for the Eslint plugin of react hooks, including a bunch of information on all the different rules that it cover and that includes issues that'll get flagged by the compiler as well. [16:08]
-
-Carl: Also, yeah, I wanna say on the compiler inferring function names like that is like one of the most quietly mind blowing things I have seen in a long time. [16:19]
-
-I actually commented on the PR to ask like, what if this became a TC 39 proposal? Because this would have saved me days of effort over the life of my career. If there had been a little bit more data about what the heck is throwing an error instead of just like cannot read property of undefined. Oh thi this is quietly one of the mo going to be one of the most impactful changes in a long time I think. [16:29]
-
-Mark: I have actually, even just recently in some of the Immer work that I've been doing, gone in and replaced anonymous arrow functions with a named function just to try to get a better name and a stack trace. [16:55]
-
-Carl: Totally. Yeah, a hundred percent. And the annoyance of assigning an arrow function to a variable versus using a named function and how those are not the same thing. [17:06]
-
-## [React Native 1.0 on the horizon](https://youtu.be/GPtopk4y2LI?si=JoZVprPW33szn-6D)
-
-Mo: Cool. Let's move on to some React native news, which has gotten people a, a fair bit excited, which is one of the talks that was at React Universe comps that happened at the beginning of this month called React Native 1.0 is on the horizon. This is pretty exciting stuff because it's anecdotally, and I'm sure many people have had the same experience as me. [17:15]
-
-One of the biggest things that people oftentimes use, which is a really, really, you know, straw man argument, but nonetheless is there, is that, oh, react native's not stable because it's not 1.0. I kid you not, when I say three weeks ago we were talking about starting a new project here at Theo and someone brought this up as a reason not to use React Native as one of like the prospective clients that we had because another company who was trying to push them to use Flutter had told them, oh, it's not stable because it's not 1.0 da da da da da. [17:37]
-
-And you know, there's a little bit of fear mongering around this. The reality of it is that React Native has been around for way too long and it's been used in many, many serious production apps for, you know, several, several years now. And so I think this is something that a lot of people have discussed with the React Native Core team over the years. [18:06]
-
-And you know, there's always been a bit of a reluctance on going to 1.0 for various reasons. Um, and so this talk is really interesting 'cause they talk a little bit about the history of that and what the reasons are for that. But really what's happened over the last year is that the release process for React Native has been significantly streamlined. [18:23]
-
-So there are now six releases. Being targeted for every single year. So every other month there being a release from two releases, which was what we had in 2024 and you know, a lot more sporadic releases in the previous years. So there was no really never a schedule to it before where, whereas now there is one of the things that's been happening over the years, but really accelerated over the last, I'd say year, is that a lot of the APIs are being really stabilized, reduced, and the surfaces are being completely trimmed down. [18:38]
-
-And so the whole idea with this is less API surfaces externally means that there's less likelihood for breaking changes in the long term, which helps them feel confident to say, Hey, this is a 1.0 or reaching out sort of monumental point where they can actively say, Hey, this is a 1.0 release. And the other thing is that the React native. [19:06]
-
-Pipelines for building React native Core was quite a manual process in the past, and so what they've done in sort of recent years is worked on introducing a lot more end-to-end testing, some workflows that would test our C bugs and you know, breaking changes much quicker. And so that's really been a lot of the efforts behind the scenes, which you won't see in features and functionalities, but it's really been to the workflow for building React native. [19:25]
-
-And so a lot of this is really moving us towards that direction where there can be at 1.0. And so the conversation isn't. Potentially, hey, there's gonna be a 1.0 in the next few months. Maybe not even in the next year, but it is somewhere there where they're feeling like, okay, we can go ahead to, to basically releasing a 1.0 for React native at some point in the near future. [19:48]
-
-So the React team's gonna be, the React native team is gonna be working on this quite extensively and trying to reach a point where they're happy and so they're gonna be working with a bunch of people to start to potentially put a date on it, which is very exciting. [20:09]
-
-Carl: That is really exciting. That's a long time towards 1.0. [20:20]
-
-But like it would've felt premature I think for them to get, to call it a 1.0 before, or at least they would've had to do a lot of breaking. [20:22]
-
-Mark: Even just waiting for the new architecture to be the default, I think was a big thing. Mm-hmm. Yeah, definitely. [20:30]
-
-Carl: Yeah. And that really seems like it was a meaningful, a meaningful reason to delay, like it was such a large disruption to so many different parts of the ecosystem, but also so essential. [20:36]
-
-Yeah, it feels more truly native under the new architecture, rather than having to like serialize between two independent systems. It kind of reminds me of like when Docker launched because it was a Linux feature, you know, a Linux kernel feature. I remember for years they had like a, if you wanted to use it on Mac, you had to technically run a vm, which introduced all sorts of weirdness. [20:47]
-
-And so that feels, I dunno, this feels technically similar to me in how they like figured out how to not have two independent systems communicating with each other in that kind of way. And now that they've cleared that hurdle, they can get towards a greater level of stability. Cool. Awesome. [21:09]
-
-Mark: One other thing that actually kinda reminds me of, so we had squiggle conf a week and a half ago and one of the talks was from Shelley Vohr, who's part of the Electron core team and she did a talk about automating systems and you know, things like security and repeatability and what happens if the system goes down. [21:25]
-
-And it sounds like a lot of the effort that's been involved on the RN side really is about CI pipelines and automation and turning a manual release process into an automated release process. And you know, having that consistency is a pretty big deal here. [21:44]
-
-## [“React Won by Default – And It's Killing Frontend Innovation”](https://www.lorenstew.art/blog/react-won-by-default/)
-
-Carl: Cool. Drama post? [22:02]
-
-Mark: Drama post. [22:04]
-
-Carl: Yeah, so there was a recent post called React Won by default and it's killing front end innovation. [22:05]
-
-Mark: To some extent. There's nothing new in this post. People have been making complaints about this for years. [22:13]
-
-## Inevitable [HN argument](https://news.ycombinator.com/item?shownew&id=45252715)
-
-Mark: It's a pretty well written post, and it did make all the rounds and spawned massive 800 comment, hacker news thread and responses on Twitter and a bunch of other places. The first argument is that React itself has kind of stagnated that it was a big deal in 2013 when the virtual do solved problems with Angular, but that React really hasn't innovated since then claim, and that things like the React compiler are a bit more of a bandaid. [22:18]
-
-Whereas other frameworks like solid and spelt and quick are doing new and innovative things around signals and ruins and resum ability and other approaches to updating the dom. But the rest of the argument is that. The typical discussion these days for a project is, okay, which framework should we use? [22:48]
-
-Well, let's use React because it has the biggest ecosystem, because there's the most developers available because AI are familiar with it, because there's lots of libraries out there, et cetera. And the phrase that always comes to mind and for me is the old one about no one ever got fired for choosing IBM that back in the day, like IBM was the safe choice for, you know what, whatever tools it is sort of that same principle today. [23:09]
-
-Like most people are not generally choosing React. Because they're specifically excited about suspense or transitions or other things like that. It's the industry standard, so we'll stick with that. And so the article argues that because of that, because the mindset is used, react by default, that it's sort of choking out other frameworks that have had more innovation and newer interesting approaches. [23:39]
-
-And so it ends up offering some suggestions for things to evaluate about scaling and performance and team skills and whatnot. And then tries to counter argue the typical like size of the ecosystem type points. It's a well-written article, like it's not flame bait. The title is is well out there, but it makes a pretty good actual point and it spawned a lot of discussion, like I said, hacker News and a bunch of other places. [24:08]
-
-But I think the really interesting counterpoint to all that. Is Rick Hanlon from the React team put up a very long thread on Blue Sky, which really should be its own blog post at this point where he says that all the frameworks know how to update the do efficiently React has innovated in the past, but it's also, it was so good in the past. [24:34]
-
-People are actually kind of ignoring the innovations they've done since 2017 and 2018, and that reacts focus for the last seven years has been not about how can we make Dom updates faster per se, but about scheduling. Things like concurrent mode, transitions, suspense, even the new activity component builds off of the foundations that they've built for the last several years. [24:59]
-
-Yeah. And so his argument is that number one, when people say react is an innovating, they're ignoring all the new features built around concurrency. And number two, that most people are still thinking about using React in a very 20 16, 20 17 ish sort of way. Most people aren't even thinking about using the new capabilities that React has unlocked. [25:23]
-
-I think he's actually got a pretty good point. [25:50]
-
-Carl: That's fair. I would generally agree with that and like I am very much in that boat, I'll be honest, like I haven't written extensive from scratch, like build an app and react since about that time. The last time I really did that from scratch to like a full production level where I was like exclusively focused on the front end was about that time, like ended around 2021. [25:52]
-
-So I've been following a lot of this, but I haven't used it at the same level of depth that I used to. I have seen somebody who, you know, one of my internet acquaintances who I have a lot of respect for, as you know, both technically and like entrepreneurial and whatever. He's been extolling the virtues of server components for the last couple of months, I think, and it's been on my, you know, it's been somewhere on my to-do list to talk more with him. [26:15]
-
-Mark: Daniel Switz. [26:40]
-
-Carl: Yep, yep. Daniel Switz. Just like I've heard him say some things. It's like, okay, I feel like you get it and I feel like you get it in a way that you could communicate. It's crossed my mind actually to have him and Ricky and or him and Dan or I don't know, a group of people on a stage like this and just like talk about it and be like, what the fuck? What are we doing? How do you do this? So yeah, I don't know. It's like, it's definitely there is innovation happening. I think a lot of the innovation, like there's innovation happening and there's also just like roadblock clearing. It's like, you know, there's the innovative, you build the road, but then you have to deal with the consequences. [26:41]
-
-Like, great, you have this road. Like what is it like to actually use it? And then a lot of the time you realize there are speed bumps and whatever that you didn't realize you were building in the first place. And the fix there is not innovate. You don't just like, well that sucked. Let's build a new road. [27:16]
-
-No, you fix it. Figure out different ways to approach the same problem that have a different set of trade-offs. And so I think that's some of what's being complained about here is that like people are like, we need a new thing. We need to rewrite from scratch. And No, we don't. I don't think we do. So, yeah, I don't know. [27:33]
-
-I guess that's what I, what I have to say there. [27:52]
-
-## [Ricky on Ryan Carniato’s stream](https://www.youtube.com/watch?v=3vw6EAmruEU) talking about scheduling and demoing using modern React features
-
-Mark: So, sort of on on that note, Ryan Carniato from the solid team routinely does streams where he talks about what he's working on or you, where the ecosystem is going. He and Ricky have had a number of like, actually. Intentional and productive discussions back and forth on Blue Sky and Twitter where Ryan has said, we've got our own version of suspense, we've got our own version of transitions. [27:54]
-
-We're trying to do things this way. And Ricky has put up a demo and said, how does this, here's the React way to do this. How's this compare to the way you guys are doing it? And so Ricky was actually just on Ryan Carniatos stream on Friday and I looked, and it's a six hour long video. No, I most definitely did not watch the video. [28:17]
-
-I cheated and used a summarizing tool to try to gimme a sense of what they were actually talking about. But it looked like they talked about where React has gone and what has changed with all the different concurrency related features. And then I think they tried to take a sort of a classic react. I think it was like a React 17 to do application, and then they updated it live on stream to use all the modern latest React features. [28:38]
-
-So if you want to watch them talking about this for six hours, the video's there. But it's a good example of people who know how this, how these technologies are implemented, discussing them as well as Ricky demoing how you could actually use these in an application. [29:06]
-
-Carl: Yeah. I will say, going back to a point a little bit about, you know, you shared the long thread and made an offhand comment about like, this could really be a blog post at this point. [29:23]
-
-Like the post on Ricky's feed right before that is the, if you all promise not to ask me for docs or blog posts, maybe I'll explain a bit about why creating a cache API for suspense is so hard and it's, oh, I love that you're doing all of this, like social media outreach and everything, but like part of the problem that, part of the reason why nobody understands all of this and you have to do all the social media outreach is because there aren't static available resources for people to read. [29:31]
-
-So it's like, ah, I love that this is happening and it's so good and so helpful. And there's follow up that's not happening that I think is really crucially important. [29:55]
-
-Mark: That's actually been one of my running frustrations and complaints for a while. Ricky and I have actually had some back and forth on this, multiple times on Blue Sky. [30:03]
-
-Yeah. Admittedly, I'm also not sitting here, honestly. I should probably start watching the docs repos so I have a better sense of what updates do happen. That one's on me, but to a certain extent, my, my knowledge of what's in the docs can get a little stale. Right. But Ricky has repeatedly complained that. [30:12]
-
-People keep making the same wrong assumptions about what React has available, why the React team is doing things, et cetera. I've pushed them multiple times this year and said, you know, my answer is go write a docs page. Yeah. That covers exactly the topic you want and to have answered, and it answers it in exactly the way you want This material covered. [30:29]
-
-A lot of people are still not gonna read that docs page, but some people who are already looking at the docs will see it. And when you run into yet another one of these questions on social media, now you have the pre-written answer and you link to it rather than having to answer it from scratch every time you see the same misconception pop up on social media. [30:55]
-
-I, I wanna be clear, I, I am genuinely excited that Ricky has done so much outreach over the last year or so. Even just in the last couple weeks he was, he wrote dozens of tweets on both Blue Sky and Twitter around the threads related to the React innovation by default discussion. And I'm genuinely happy he's doing this much outreach. [31:18]
-
-It's sort of taking Dan's place in that sense. But when your great answers are buried, 15 replies deep in a Twitter thread, no one sees them other than the person you're responding to. And that is the kind of material that desperately ought to be its own blog post, as well as these couple top level threats as well. [31:40]
-
-And so I genuinely happy he's engaging. I would just love to see that material written up longer term. [32:03]
-
-Carl: This is clearly a bit of a cycle, you know, like social, this has been true for years generally. So like maybe this is an opportunity for someone here listening to go through some of the, to go through these threads. [32:09]
-
-Like if you're champing at the bit for an opportunity to have an impact on the ecosystem and on the industry, like this could be a pretty achievable way to do so. Like this content is out there, it exists, but not in a way that's discoverable. So like taking this knowledge that is being produced in ephemeral social media threads and then just like restructuring it, reformatting it into a markdown document and submitting a PR to react could be really effective. [32:24]
-
-I, I'll throw that gauntlet down, like that is an achievable thing that I am probably not gonna do. [32:52]
-
-Mark: People used to say that the real React docs was Dan Abramov's Twitter account, which he then deleted and all that info is gone. I don't expect blue sky to go down, but yeah, like if someone out there wanted to go through some of, you know, Dan and Ricky and whoever else's Blue Sky threads and pull out info and submit docs, prs like that would genuinely help the entire ecosystem. [32:58]
-
-Carl: Yep. Right. And it doesn't need to be perfect first. Drafts are so good. First, the first draft is so hard and going from first draft to published thing is still a lot of work. But man, just getting a first draft out is often the thing that tips it over the edge into actually happening. Yep. I'll just say that if anyone's looking for something. [33:20]
-
-Mark: Love the idea. Alright, moving right along. [33:38]
-
-## Server Components
-
-Mark: A few different updates related to server components this month. [33:41]
-
-## [React Router RSC framework mode preview](https://remix.run/blog/rsc-framework-mode-preview)
-
-Mark: The biggest would be that React Router now has RSC support in their framework mode builds. So React Router, as I understand it now, has three different modes. There's sort of the, the traditional client side only, here's your list of routes mode, there's a somewhat more complicated data mode, and then there's the full blown full build framework mode. [33:44]
-
-And so I believe they previously announced some RSC primitives available in data mode. And then I believe the framework mode is now taking those and expanding on them somehow to make it available for the full build. So, you know, again, having more RSC options available besides just next is a pretty big deal. [34:09]
-
-And especially when it's built into something as widely used as React router. [34:30]
-
-Carl: Yep. Love that. [34:34]
-
-## also [middleware is now stable](https://remix.run/blog/middleware)
-
-Mark: They also announced that React router now has stable middleware support as well. Your routes can now have middleware. [34:36]
-
-## Krasimir Tsonev’s [“Can I Use RSC Today?” support matrix](https://rsc.krasimirtsonev.com/) and experimental [Forket “RSC without a framework” build tool](https://krasimirtsonev.com/blog/article/vanilla-react-server-components-with-no-framework)
-
-Mark: Krasimir Tsonev, who is a React educator and has been around for a while, put up a nifty little support matrix called, can I use RSC today, where he tried to do equivalent bits of RSC usage and features across several different tools from next in, in Remix and Waku and various other tools. [34:44]
-
-He was also very curious. I, I actually talked to him at React Summit in, in June, and I think this is what. And he was talking to a couple other folks, and I think this is what spawned him doing that deep dive where he was actually kind of bothered by the fact that server components require a framework. [35:07]
-
-And so he went off and ended up implementing his own tool called for cat. Which is supposed to be somehow a proof of concept for using an RFC without an actual framework per se. So sort of a more primitive, granular client server separation build tool. [35:24]
-
-## [RSBuild support for RSCs](https://bsky.app/profile/ebey.bsky.social/post/3lyf6vixick26)
-
-Mark: Speaking of build tools, I saw mention that there is a set of plugins available that try to add some RSC support to the RS build, rust based bundler as well. [35:43]
-
-## Useful post on [parallel and recursive route rendering](https://twofoldframework.com/blog/parallel-and-recursive-route-rendering-with-rsc)
-
-Mark: Finally, I also saw a good blog post that talked about techniques for doing parallel and recursive route rendering with RSCs. As Carl mentioned earlier, all this stuff is frankly outside of my experience, I've never tried to render, you know, RSCs much less do parallel and recursive stuff, but it clearly, people are out there experimenting with these things and that's good. [35:55]
-
-Carl: Oh man. I'm looking at the blog post. You mentioned React server components without a framework and it's got a mention of Flux. Oh, throwback. Yeah. I mean we're Reactiflux because for about a six or eight months it was React and then you pair it with Flux and that was how you do UI and state management. [36:15]
-
-So it's wow, throwback. That's a long time. [36:33]
-
-## All the NPM compromises and malware this month
-
-Carl: Alright, little bit of a roundup on. Vulnerabilities and security incidents on MPM. There's been a lot this month. [36:35]
-
-Mark: I think that the first one happened late last month, and we mentioned it briefly. Yeah. And then there was just like this constant flood of new compromises, new vulnerabilities, all kinds of packages being taken over, ranging from crypto miners to like full-blown credential stealing. [36:44]
-
-It's, it's been pretty bad out there folks. [37:02]
-
-Carl: Right? So last month. NX was compromised, which is discussed in this set of links that we have here. I'll send one at a time as we get into it, but yeah, so it, what we've seen has been everything from like pretty, there was a targeted attack that would do like intercede, crypto payments and sub out addresses for, you know, an attacker's wallet actually that had a small innovation in that category of attack where it would generate an address that was visually similar to the one that you had used to try and escape. Notice I heard that attack only got like $50 or like less than $500. I've seen some conflicting numbers, but like generally not effective, did not achieve its goals. [37:04]
-
-But like it hit debug. Like it hit a package that I saw the security alert go out and I was like, oh, that sounds like something that I might use. And I checked. I'm like, yep, a bunch of projects on my computer were using that package. That was the one that got targeted with crypto interception, but previously, I think it was nx, was it last month, that we had the people who were stealing credentials and using AI to generate other code to steal credentials. [37:50]
-
-Like, ah, that's the worst attack I've ever seen. And the only reason it wasn't worse was because of the limited scope of compromise. So like I was primed seeing that innovative, highly effective attack when I saw this massively widely distributed compromise of debug. And I have a little bit of egg on my face regarding this because I had pinged in the node Discord that I help operate saying like, oh, you need to look at this. This is awful. And it ended up not being as bad as I thought because that was a crypto miner, not a credential stealer. [38:19]
-
-Mark: The attack itself seemed like a pretty big deal, and then it was almost sort of wasted on, well, it has to lead to you accidentally build a client side app that has the compromised version built into it. [38:54]
-
-Carl: Right, they managed to successfully target one of the single most widely used packages. And completely squandered it by using it to execute an attack that had such limited application that they just didn't get anything. So like that's just straight up, like they screwed up, like they achieved a massive level of success and just like immediately fell on their face and did nothing with it. [39:08]
-
-That's just a miss. Like that was just luck, that it wasn't worse than it was. [39:34]
-
-Mark: But on the, on the flip side, the article that's talking about the ongoing supply chain attack did do a bunch of credential stealing, targeting a bunch of packages like [39:38]
-
-## [npm package maintainer Qix](https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack)
-
-Mark: tiny color and a [39:47]
-
-## [CrowdStrike npm Packages](https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages)
-
-Mark: bunch of CrowdStrike packages. Yeah. I don't know the extent of like what sites got hit because of that compromise. [39:48]
-
-Yeah. But I believe that one's, that one had did a, done a pretty good job of finding credentials and publishing them on either, I think it was like either creating a new GitHub repo or creating a new specially named branch in GitHub repos to try to exfiltrate the credentials. [39:57]
-
-Carl: Yeah. Oh, I was just reading this one actually. [40:14]
-
-## [GitHub Actions npm Token Theft](https://socket.dev/blog/nx-supply-chain-attack-investigation-github-actions-workflow-exploit)
-
-Carl: It was, they had, they, somebody had added a line to the GitHub action that did, that would echo out the title of the PR and because it just did an un escaped string, you know, echo this. You could just terminate that and then run whatever you wanted. On the GitHub action, like, do not let any arbitrary person run whatever script they want in your seat. [40:16]
-
-Like, oh man, that it's, that's pretty bad. And also, oof, this is CrowdStrike. Like, remember CrowdStrike and how they took down like every, like air travel around the world from another security problem that they had, and oops, they're a cybersecurity company where preventing attacks is their job. Oops. Yeah. [40:38]
-
-I don't understand how they're still operating successfully. [40:57]
-
-## [GitHub response](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/)
-
-Mark: So, GitHub and NPM did actually put up a, a, an announcement saying that they're gonna be doing a lot of work to try to tighten up. Publishing of packages down the road, they're gonna be making changes to two fa it says they're gonna deprecate time-based passwords. [41:01]
-
-That sounds like it's gonna end up being a, a big deal. I don't fully understand the implications yet. And, and they said they're gonna, you know, take time to roll these changes out. But that one seems like a big deal. We're also making and trying to apply more limits to tokens and work on better trusted pet publishing workflows as well. [41:20]
-
-Interesting. [41:40]
-
-Carl: Yeah. That's all important and useful, but like also, I don't know if there, if you just, if somebody opens a PR to your CI, that adds. A vulnerable un escaped string. Like it doesn't really matter how, what your authentication or publishing workflow looks like if that gets merged. Like you're vulnerable. [41:41]
-
-So dunno how, dunno what you do about that specifically. But, okay. [41:56]
-
-## ⚡ Lightning round ⚡
-
-Carl: Let's hop into our lightning round. [42:00]
-
-## [Porting Modern TypeScript to Run on DOS](https://jimb.ly/2025/09/23/qauntumpulse-from-steam-to-floppy/)
-
-Mark: I love a good article that just goes into absurd amounts of detail on a ridiculous thing that someone's trying to do, but they commit to the bit fully. And this one was, someone had a. JavaScript based game and they ported it all the way back to work on dos. [42:03]
-
-Like why would you want to, I don't know, but apparently they actually made this work and I love it. [42:21]
-
-Carl: That is insanity, and I also love it spiritually similar to Doom running in TypeScript types, just for no reason. Yep. Love. [42:27]
-
-## [Cloudflare DDOSed themselves with a bad `useEffect` fetch](https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/?amp%253But)
-
-Mark: CloudFlare got into the news this month because they had a dashboard failure that cascaded, and believe it or not, it was caused by manually fetching data in a use effect that went into an infinite loop, which also means they weren't actually using like React query or anything like that. [42:35]
-
-Oops. [42:55]
-
-Carl: Yeah, I did hear like none of their services were affected. It was just the control panels that was taken down, so that's good. I also saw Guillermo Roush throwing some shade at the CloudFlare CEO after that. So, you know, drama post. [42:56]
-
-## [A very lovely writeup of the evolution of css `zoom`](https://www.bocoup.com/blog/the-webs-most-tolerated-feature)
-
-Carl: There's a cute post from Bocoup. There are web consultancy that's had a, a big impact on standards and web platform implementation details. [43:11]
-
-So they, they've heard a cute blog post, the web's most tolerated feature looking into Zoom and how Zoom works. And it is kind, it's kind of cute. I don't know, just like it's a fun look at standards and like how. Cross browser implementation stuff works and how like, oh actually this like totally unstandardized thing just happens to work really well and everyone uses it. [43:21]
-
-So, I don't know. It's cute. It's a cute post from people who are deeply involved in the standardization and implementation process, highlighting a case where like standards like just kind of didn't happen and it was fine. [43:44]
-
-## [What You Need to Know about Modern CSS](https://frontendmasters.com/blog/what-you-need-to-know-about-modern-css-2025-edition/)
-
-Carl: Anyway, yeah, there was another good post from front end Masters who I, I've just always had a soft spot in my heart for front end masters because they were, that's the first platform that I learned react from. [43:56]
-
-It was like a comparative class of Angular React and Ember, and I was like, oh, react seems nice. So like I owe them a debt to, you know, my entire career. So that's, it's cool. It's nice to see 'em still around and still staying on the ball. They published a post What you Need to Know about Modern CSS 2025 edition. [44:09]
-
-Mark: And it was long too. It was long. [44:26]
-
-Carl: It's big and I appreciate that because I've gone to a couple of conferences and I've seen talk from various people who are more, who work on CSS a little bit more. Una Kravets, I think is who I'm most specifically thinking of, who's wonderful and great and a great speaker. [44:28]
-
-But like I'll see her talk about some CSS stuff and be like, wow, all of this is stuff that I've never heard of and CSS is completely different than what I've used in a lot of my career. That's awesome. And I don't know what to do about that. So this is a great post for me in that situation and going, ah, I need to catch up on like the last six years of stuff that I haven't really paid close attention to as it evolves step by step. [44:44]
-
-So, great summary. [45:09]
-
-Mark: We have a few different posts on browser behavior. So there was I and all from folks who have worked on browsers for a long time, I might add. [45:10]
-
-## [Fetch streams are great, but not for measuring upload/download progress](https://jakearchibald.com/2025/fetch-streams-not-for-progress/)
-
-Mark: Jake Archibald did one on fetch streams are great, but don't use them for measuring upload download progress points out that you still basically need to use XHR for that instead. [45:21]
-
-Although there's discussion of adding some new options and callbacks to fetch that might accurately handle that at some point. [45:33]
-
-## [Why do browsers throttle JS timers?](https://nolanlawson.com/2025/08/31/why-do-browsers-throttle-javascript-timers/)
-
-Mark: There was one from Nolan Lawson talking about why do browsers throttle JS timers? So you know, why does that time timeout zero actually be, why is it more like four milliseconds, et cetera? [45:40]
-
-And basically it's because people rate bad code or either intentionally or unintentionally that can do bad things. [45:53]
-
-## [“How Modern Browsers Work” deep dive, Addy Osmani](https://addyo.substack.com/p/how-modern-browsers-work)
-
-Mark: And then Addy Osmani did a pretty long post a, mid-level overview of how modern browsers work overall, going from, you know, parsing JavaScript in HTML in various ways to using GPUs to put pixels on the page. [46:01]
-
-Carl: Yeah, it's funny to me to see, I don't know, I've just been seeing Addy Osmani and Nolan Lawson and Jake Archibald for so long. It's like, man, how great for them to stay on the top of the game for so long. It's great. [46:18]
-
-## [Biome: Stress-testing WIP `noFloatingPromises` lint rule](https://vercel.com/blog/stress-testing-biomes-nofloatingpromises-lint-rule)
-
-Carl: One that I like here. I like seeing Vercel and Biome collaborated on stress testing, biomes new, no floating promises lint rule. [46:32]
-
-I, again, have a soft spot in my heart For Biome, I was a initial backer of Rome back in the day, which was then forked after some maintainer shenanigans into Biome. They never really achieved the original vision, or have not yet at least, which was like unified, like linting compiling, you know, one tool to rule them all kind of thing. [46:41]
-
-That it was called Rome because all paths, all roads lead to Rome, so it was trying to do all of it. They have achieved a lot of their goals, but not quite enough to really meaningfully claim to do all of it. [47:02]
-
-Mark: It's become a pretty solid, a pretty solid formatter, but they never really managed to get into any of the multi tools sharing one a ST side. [47:15]
-
-Carl: Yeah, right. Oh, that was it. It was because you know, you, you would have like Babel and ES lint and TypeScript and prettier and all of those, and all of them were independently parsing ASTs and then operating on. So like that's just a lot of wasted effort. So the, the goal was, the original goal was like one AST, all of this stuff talking to that will be an order of magnitude performance improvement. [47:23]
-
-Mark: Mm-hmm. [47:44]
-
-Carl: But anyway, so enough background, they have a new no floating promises rule because if you don't await or you know, respond to a promise, it can cause all sorts of super weird stuff. They say that, you know, a lot of engineers have campfire stories of floating promises taking down production, which is definitely true. [47:44]
-
-I've definitely, a lot of the weirdest errors I've ever encountered track back to, oh, we didn't correctly wait for this promise to resolve, so this is it. This is a fun, deep dive technical writeup of how do you detect that promise. Has not been waited for. What does it even mean to return a promise when TypeScript has a built-in promise? [48:02]
-
-Like construct? It's a good read. It's a good deep dive. [48:23]
-
-Mark: I should point out that the article was written by Dmitri Metropolis, who just got done organizing Squiggle conf and is also the person who did Doom in Typescripts. [48:27]
-
-Carl: Oh, it is, Love Dmitri. Love that. [48:34]
-
-## [Bun: How `bun install` is so fast](https://bun.com/blog/behind-the-scenes-of-bun-install)
-
-Carl: There is a good deep dive here into Bun Install and how it's so fast. [48:37]
-
-They say on average it runs seven times faster than MPM and 17 fast times faster than you yarn. It's a large post and it's got a lot of real deep benchmark stuff. Mm-hmm. [48:43]
-
-Mark: I think Lydia Halley wrote that one actually very well written post. Lot of detail. [48:53]
-
-Carl: Wait, was she on React? [48:58]
-
-Mark: I believe she was working for Vercel and left, and I think she actually just joined Bun as a DevRel. [49:00]
-
-Carl: Great. I'm just always here for like a deep technical dive. So many, so many blog posts are just a little bit more surface level, so seeing something more like a white paper, a technical writeup, I just love I, it's such a good window into the real challenges that different people around our industries are encountering [49:06]
-
-## [Styled-Components fork for perf and React 19 compat](https://www.sanity.io/blog/cut-styled-components-into-pieces-this-is-our-last-resort)
-
-Mark: for folks who are still using style components, the sanity company actually forked the existing now unmaintained library and made a couple major updates. [49:23]
-
-One, to try to optimize the overall performance and another to try to provide React 19 compat. They say they are not maintaining these forks per se, but they have done the work because they themselves still relied on it. And so they've made those, they've published those so that other people can benefit from it. [49:35]
-
-So if you're still work, still using style components, you may want to take a look at that. [49:57]
-
-## [Vite SSR: Custom `getStaticProps`](https://www.patron.com/blog/post/vite-ssr-getstaticprops-replacement/)
-
-Mark: Also saw a nice little post that talked about building your own get static props alike equivalent if you're using Vite for SSR. [50:02]
-
-## [Dominic Gannaway’s new framework Ripple](https://github.com/trueadm/ripple)
-
-Mark: And in the frameworks that are not actually React, but related category. Dominic Getaway, who originally created a React Delight called Inferno and was on the React team for a while, has built his a new independent framework called Ripple, which tries to pull together some new ideas around template compilation and use of JS syntax, but in a way that's different than React. [50:11]
-
-## [Remix v3: MJ hints “iframe-like async primitives”](https://x.com/mjackson/status/1971816432427298951)
-
-Mark: And then Michael Jackson and Ryan Florence continue to drop assorted hints online about what their Remix version three is going to look like. Michael's latest tweets are saying, what if he could just sort of use iframes or iframe like behavior for async loading? And I really just want to see the actual examples at this point, but they're dropping hints about what it'll be like. [50:35]
-
-And oh, the plan is to actually show stuff off at Remix Jam, which I think is coming up next month. [51:00]
-
-Carl: Yep. I am skeptical. I don't know, I, I appreciate the broad strokes of iframe, but the actual security constraints of using iframes is, that's just not, they're not good. It's not pleasant. It's not, you know, that's very like 2003 era web development and we stopped doing that because it kind of sucked. [51:07]
-
-It was hard to make good experiences. If it's not literally in I frames, that's very different. So maybe it'll be better than that. There's an argument to be made that what he is talking about shares significant overlap with the islands style micro front ends. So, I'm not checked out. I'm curious, but I'm skeptical. [51:27]
-
-Unfortunately. It sounds like Mo's having like significant internet challenges in his office right now. So I'm gonna, I'm gonna pull in some of the stuff that would've been, you know, that he wanted to talk about. [51:49]
-
-## [React Native RFC to remove Old Architecture](https://github.com/react-native-community/discussions-and-proposals/pull/929)
-
-Carl: There's been a RFC for React native, for a plan for actually removing the old architecture, the previous way of serializing communication between the JavaScript engine and the native layer. [51:57]
-
-So it's not only, not only is the new architecture default, they are now proactively communi or they're proactively planning how to get rid of the old architecture entirely. Well, that's great. That feels like a big step towards 1.0, like we were talking about before. [52:13]
-
-## [Cloudflare’s new “Cap’n Web” RPC; GraphQL alternative?](https://blog.cloudflare.com/capnweb-javascript-rpc-library/)
-
-Mark: So CloudFlare announced a new tool called Cap'n Web, which is a RPC system meant for browsers and web servers. [52:28]
-
-And this was created by the same person who, by Ken and Varta, who had created a couple other serialization libraries, one called Capin Proto, and Capin. Proto works with both c plus plus and JavaScript and possibly a couple other languages. And Capin proto is sort of a follow on that's specifically meant for use with web and can be sent back and forth using just plain JSON. [52:38]
-
-I believe the article actually kind of pitches it sort of as an alternative to GraphQL in a way. It actually does a funky little thing where if you make what looks like an initial request for an item and then you get back a promise for that response, you can call map on the promise and. Essentially map over what will be the list of items and say, for example, gimme details on all the child items by their id, but then it'll actually get batched up into a single request. [53:05]
-
-So there's some technical trickery going on there, but it sounds like it's meant to simplify both making a request back and forth and managing the overhead of what would've potentially been many independent requests as well. Thus, the comparison to like a GraphQL style thing. [53:42]
-
-Carl: Interesting. And also, I'll shout out. [53:59]
-
-You know, Cap'n Proto here is spiritually very similar to the challenge, it's solving a problem that's spiritually very similar to the new architecture and React Native, like basically, you know, this RPC is going instead of going across like a native JavaScript layer, like a new React native, this is how do you do a similar type of communication between systems across the network boundary? [54:02]
-
-And the challenge is like the reason you would use something like Cap'n Proto or Protocol Buffers, which you know, there's kind of competitors there is because the serialization costs and the volume of communication if you're using JSON, is just much higher, like converting it into a string. It's basically a string versus a binary data format. [54:25]
-
-Like the, one of the problems with JS is that you're encoding not just the data, but also the structure. You're saying, here's the object, here's the keys, here's what it looks like. And that's. That's information. You know, if you're sending that information across the wire, that's extra effort. If you already have two, two agents on opposite ends of a network and they say, we agree that our communication is in this format, then you don't need to send the format across the wire. [54:46]
-
-So that's the fundamental like reason why you might use one of these tools instead of just sending JSON over HTTP and yeah, it's interesting. This is, it's pretty cool. [55:16]
-
-## [Expo UI: Building SwiftUI apps](https://docs.expo.dev/guides/expo-ui-swift-ui/)
-
-Carl: Cool. The Expo had an interesting post talking about using Swift UI in React Native, so that, that's pretty cool. Like being able to directly, if you're in, only, if you're only targeting a native environment, being able to. [55:26]
-
-Exclusively use native primitives is like a huge win. Like if you don't, you know, it's always good to remove compatibility layers if you don't need the compatibility. So that's really cool. It's it, this looks pretty interesting if you're doing stuff on Mac Os or like Apple TV or things like that. [55:40]
-
-## [TanStack DB: An interactive guide](https://frontendatscale.com/blog/tanstack-db/)
-
-Mark: So the TanStack folks recently announced a new package called TanStack DB, which is supposed to be a smart syncing layer on top of TanStack Query that can do things like in-memory filtering and querying of data very efficiently. [55:57]
-
-And so there was a neat post that was an interactive guide to TanStack db and discussing some of the options and some of the things you can do with it. [56:13]
-
-## [TS 6.0: may switch to `strict` options by default](https://github.com/microsoft/TypeScript/issues/62333)
-
-Carl: TypeScript version six may switch to strict options by default. This is, [56:21]
-
-Mark: hallelujah. [56:27]
-
-Carl: Yeah, right. What a long time coming. Like I have treated this as a deep, you know, this has been step one of setting up a new TypeScript project for me since I've started using TypeScript. 'cause it's always been the best practice. So I love that they are discussing, switching this over. Yeah. It starts almost a decade ago. We began to add certain options beyond, no implicit any in strict no checks. So, yeah, like almost a decade ago. So that's the, that's cool. TypeScript 6.0 will assume that dash dash strict is on unless explicitly disabled, which means specific settings like strict no checks and no implicit any will be enabled unless it's turned off explicitly. [56:28]
-
-Woo. Cool. No implicit any is if you don't turn that off, like you're not really using Patrick, like it's just sparkling JavaScript. So that cool. Love that. Love to see this. [57:05]
-
-Mark: There's a lot of debates over the nuances of what that concept of turning on strict by default actually means. But I would assume that something along those lines would land and yeah, it's way overdue. [57:16]
-
-## [Shopify’s RN New Architecture migration](https://shopify.engineering/react-native-new-architecture)
-
-Mark: Alright, last couple ones and then we're done with the not so lightning. Lightning round Shopify put up a post talking about their migration to the React native new architecture and went through both some pros and cons and pitfalls of what that process involved. [57:28]
-
-## [The Bloat of Edge-Case First Libraries](https://43081j.com/2025/09/bloat-of-edge-case-libraries)
-
-Mark: And then the last one is from James, who has the really funky username that I'm not even going to try to pronounce, but he's been working as part of the E 18 E ecosystem speed up process. [57:42]
-
-In fact, he's the person that I did a stream on a couple days ago where we talked about my work to make the Immer library faster. And his post looks at like, gives an example of, let's say you have a math clamp function that takes some arguments. But you don't want it to crash if someone does something stupid like passing in, you know, a string instead of a number and next thing you know, like two thirds of your function is just validating the inputs before it actually does anything. [57:54]
-
-And he argues that, you know what? This actually ends up being kind of a waste of space and execution time. And that to a certain extent, if someone passes in bad input, that's their problem and not your problem, which I can sort of get behind. [58:24]
-
-Carl: Yeah, interesting. That makes a lot of sense. It's kind of the right, it's a challenge between sharing code and doing it inline how when you start trying to do it inline, you end up re-implementing a lot. [58:40]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-Carl: Cool. Let's talk about some conferences. [58:51]
-
-## [React Alicante](https://reactalicante.es/) Oct 2-4
-
-Carl: We have in like three days, two days. React Alicante in Spain, October 2nd through fourth. [58:53]
-
-Mark: I will be speaking there. I'm flying out on Wednesday. [59:01]
-
-Carl: Woo. And then you're fly. And then you're flying [59:04]
-
-Mark: all the back and then flying all the way back across, across the world for to attend React Conf. [59:07]
-
-Carl: Yep. I'll be there too. [59:11]
-
-## [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
-
-Carl: So yeah, react Conf in Henderson, Nevada, right near Vegas. I'm actually gonna be driving from San Jose, so like if you're in the Bay Area a couple days before the React conf, lemme know. I don't know. I'm gonna go hiking, so, we'll, it's gonna be an adventure. [59:13]
-
-## [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
-
-Carl: Then a couple days after React Conf, Remix is doing their own conference in Toronto, the Remix Jam. [59:29]
-
-So yeah, maybe. We'll, we will see. It'll be interesting to see what they come out with. Yeah, I'm curious. Yeah. [59:37]
-
-## [ViteConf](https://viteconf.amsterdam/) Oct 9-10 Amsterdam, Netherlands
-
-Carl: Anyway, coincident with that, ViteConf is happening October 9th and 10th in Amsterdam. That'll be cool. [59:43]
-
-Love to see what they come out with. [59:50]
-
-## [JSConf North America](https://events.linuxfoundation.org/jsconf-north-america/) Oct 14-16 Chesapeake Bay, MD, USA
-
-Carl: JSConf is doing a couple of events all over the world actually, so they're doing JSConf North America October 14th through 16th in Chesapeake Bay, Maryland, [59:52]
-
-## [JSConf Chile](https://jsconf.cl/) Oct 24-25 Santiago, Chile
-
-Carl: and they're also doing re JSConf Chile, October 24th and 25th in Santiago, Chile. [01:00:03]
-
-## [React Native London](https://www.reactnativelondon.co.uk/) Oct 30-31
-
-Carl: We've also got, after that React Native London, October 30th and 31st, [01:00:10]
-
-Mark: and Mo runs that, so you should totally be there and support him [01:00:18]
-
-## [React India](https://www.reactindia.io/) Oct 31 Nov 1 Goa, India
-
-Carl: after that, there's React India October 31st and November 1st, [01:00:22]
-
-## [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
-
-Carl: and then the Wey Wey Web, I think I'm pronouncing that right. It says it's a yay, yay conference, international conference for ux. But yeah, that's happening in Malaga, Spain, November 17th and 18th. [01:00:26]
-
-## [React Summit](https://reactsummit.us/) Nov 18-21 New York, NY, USA
-
-Carl: And then we've got React Summit happening in New York, November 18th through 21st. [01:00:39]
-
-So that's cool. We'll see. Maybe I can make it to that. It's in my hometown, so Yeah, that'd be great. [01:00:43]
-
-## [React Advanced](https://reactadvanced.com/) Nov 28th, London UK
-
-Mark: And then React. React Advanced is November 28th, all and although it's uh, inconveniently the day after us Thanksgiving this year, they had done it in late October, previous years, and I think since they're not doing React Berlin, they bumped the schedule for React Advance to be sort of in the middle where those would've been. [01:00:48]
-
-## Outro
-
-Carl: That's everything we got for you this month. Thank you so much for joining us. We'll be back on the last Wednesday of the month probably, although we had to reschedule this month again, sorry. Or we will be back in your podcast feed just as soon as we can. We gather sources from, actually this month we pretty much only gathered sources from Reactive Fly. [01:01:08]
-
-It was a good month for, you know, us staying up to date. Yeah, generally we do subscribe to this week in React, which is a great source. Follow lots of people on Blue Sky and Twitter, the React JS subreddit and just, you know, generally all over the internet. We try and stay in touch. If you see anything that you think that we should be aware of, definitely post. [01:01:25]
-
-Actually, you should just post it to the Tech News and Reads channel here. I would love it if we could have some more chatter going on there and it really does help us stay on top of things and helps me understand it. If, you know, if you post a link and then you and somebody else have a conversation, I will read that and it will inform my opinion. [01:01:46]
-
-So yeah, it's a great way to do it. If this is a show that you get value from and wanna support, best way to do so is by reviewing us on whatever platform you listen to or tell your friends and coworkers about it. So, you know, send 'em a link. Cheers. Thanks so much for listening. [01:02:02]
diff --git a/src/transcripts/tmir-2025-10.md b/src/transcripts/tmir-2025-10.md
deleted file mode 100644
index 5773f74..0000000
--- a/src/transcripts/tmir-2025-10.md
+++ /dev/null
@@ -1,759 +0,0 @@
----
-title: "TMiR 2025-10: Post-conf; React 19.2, React Foundation, React Native removing old architecture. Next.js has too many directives"
-date: 2025-10-29
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down 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](#intro)] Intro
-- [[00:46](#new-releases)] New releases
- - [[00:49](#immer-102)] [Immer 10.2](https://github.com/immerjs/immer/releases/tag/v10.2.0)
- - [[01:55](#arktype-arkregex-typed-regex)] [ArkType ArkRegex](https://arktype.io/docs/blog/arkregex) (typed regex)
-- [[02:41](#main-content)] Main Content
- - [[02:45](#react-conf)] React Conf
- - [[02:50](#official-reactconf-2025-recap)] [Official ReactConf 2025 Recap](https://react.dev/blog/2025/10/16/react-conf-2025-recap)
- - [[02:57](#introducing-the-react-foundation-also-from-linux-foundation-meta-engineering-and-seth-webster)] [Introducing the React Foundation](https://react.dev/blog/2025/10/07/introducing-the-react-foundation) (also from [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-the-react-foundation), [Meta engineering](https://engineering.fb.com/2025/10/07/open-source/introducing-the-react-foundation-the-new-home-for-react-react-native/), and [Seth Webster](https://thenewstack.io/react-foundation-leader-on-whats-next-for-the-framework/))
- - [[17:03](#192-activity-useeffectevent)] 19.2 (Activity, useEffectEvent)
- - [[17:27](#react-native-news)] React Native news
- - [[17:32](#new-architecture-only-from-v082)] [New architecture only from v0.82](https://reactnative.dev/blog/2025/10/08/react-native-0.82#new-architecture-only)
- - [[18:52](#vega-os-announcement)] [Vega OS announcement](https://developer.amazon.com/apps-and-games/blogs/2025/09/announcing-vega-os)
- - [[19:04](#vega-introduction-at-react-conf)] [Vega introduction at React Conf](https://www.youtube.com/watch?v=p9OcztRyDl0&t=5737s)
- - [[22:36](#joe-savonas-exploring-react-performance-talk)] Joe Savona’s “[Exploring React Performance](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=20274s)” talk
- - [[23:26](#rickys-async-react-part-i-and-part-ii-repo)] Ricky’s “[Async React Part I](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=10907s)” and “[Part II](https://www.youtube.com/watch?v=p9OcztRyDl0&t=29073s)” ([repo](https://github.com/rickhanlonii/async-react))
- - [[27:12](#async-react-working-group)] [Async React Working Group](https://github.com/reactwg/async-react)
- - [[27:35](#first-discussion-of-more-docs-ideas)] First [discussion of more docs ideas](https://github.com/reactwg/async-react/discussions/2)
- - [[28:27](#remix-v3-announcement)] Remix v3 announcement
- - [[29:03](#announcement-demo-timestamped-breakdown)] [Announcement demo timestamped breakdown](https://github.com/markdalgleish/remix3-resources)
- - [[31:28](#updates-syntax-can-be-customized)] [Updates syntax can be customized?](https://x.com/sergiodxa/status/1976878377509568871)
- - [[34:44](#i-built-the-same-app-10-times-code)] [I built the same app 10 times](https://www.lorenstew.art/blog/10-kanban-boards) ([code](https://github.com/lorenseanstewart/kanban-comparison))
- - [[37:57](#same-author-as-react-won-by-default-and-its-killing-innovation)] Same author as [React Won by Default and It’s Killing Innovation](https://www.lorenstew.art/blog/react-won-by-default/)
- - [[43:33](#solito-5)] [Solito 5](https://solito.dev/v5)
- - [[46:49](#next-16-and-directives-debate)] Next 16 and Directives debate
- - [[46:56](#next-16-released)] [Next 16 released](https://nextjs.org/blog/next-16)
- - [[49:41](#directives-and-the-platform-boundary)] [Directives and the Platform Boundary](https://tanstack.com/blog/directives-and-the-platform-boundary)
- - [[50:34](#technical-critique-of-next-app-router-everyone-hates-nextjs)] Technical critique of Next App Router: [Everyone Hates Next.js](https://paperclover.net/blog/webdev/everyone-hates-nextjs)
-- [[54:56](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[54:58](#viteconf-roundup)] [ViteConf roundup](https://voidzero.dev/posts/whats-new-viteconf-2025)
- - [[55:49](#aws-outage-postmortem)] [AWS Outage Postmortem](https://aws.amazon.com/message/101925/)
- - [[57:10](#voltra)] [Voltra](https://x.com/saul_sharma/status/1972161677165473980)
- - [[58:10](#building-fully-native-apps-with-eas)] [Building fully native apps with EAS](https://blog.swmansion.com/building-fully-native-ios-apps-with-expo-eas-760b5480d7c5)
- - [[58:52](#react-native-imgui)] [React Native \\\<\\\> Imgui](https://x.com/tmikov/status/1979771014340047088)
- - [[59:53](#lodash-maintenance-foundation)] [Lodash maintenance foundation](https://blog.ulisesgascon.com/the-future-of-lodash)
- - [[01:00:45](#build-your-own-key-value-database)] [Build Your Own Key-Value Database](https://www.nan.fyi/database)
- - [[01:02:24](#jared-palmer-asking-for-gh-pr-suggestions-and-giving-some-technical-details)] [Jared Palmer asking for GH PR suggestions](https://x.com/jaredpalmer/status/1979204222420664405) and giving [some technical details](https://x.com/jaredpalmer/status/1980619222918262842)
- - [[01:03:54](#node-25-with-jsonstringify-improvements)] [Node 25 with JSON.stringify improvements](https://nodejs.org/en/blog/release/v25.0.0)
- - [[01:04:15](#cloudflare-vs-vercel-cpu-benchmarks-and-perf-optimizations)] [Cloudflare vs Vercel CPU benchmarks and perf optimizations](https://blog.cloudflare.com/unpacking-cloudflare-workers-cpu-performance-benchmarks/)
- - [[01:05:07](#ff-interop-feature-request-rankings)] [FF Interop Feature Request Rankings](https://interop-rank.jakearchibald.com/)
- - [[01:05:53](#vjeuxs-history-of-prettier)] [Vjeux’s History of Prettier](https://blog.vjeux.com/2025/javascript/birth-of-prettier.html)
-- [[01:10:41](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:10:43](#react-native-london-nov-13-14-london-uk)] [React Native London](http://reactnativelondon.co.uk) Nov 13-14 London, UK
- - [[01:11:26](#use-code-tmir10-to-get-10-off)] Use code \`TMIR10\` to get 10% off
- - [[01:11:42](#wey-wey-web-nov-17-18-malaga-spain)] [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
- - [[01:11:49](#react-summit-nov-18-21-new-york-ny-usa)] [React Summit](https://reactsummit.us/) Nov 18, 21 New York, NY, USA
- - [[01:12:10](#react-advanced-nov-28-london-england)] [React Advanced](https://reactadvanced.com/) Nov 28, London, England
- - [[01:12:33](#react-paris-cfp-is-open)] [React Paris](https://react.paris/) CFP is open
-- [[01:12:49](#ending)] Ending
-
-# This Month in React - October 2025 (SM)
-
-## Intro
-
-**Carl:** Hello everyone. Thank you for joining us for the October edition of This Month in React. As we recap what's going on with React, React native in the web, we're coming to you live from React Flux, the place for professional developers using React. [00:00]
-
-I'm Carl. I'm a staff staff product developer and freelance community leader here at React Flux, where I run community programs like these events and build tools to help keep the community operating. [00:12]
-
-**Mark:** Hi, I'm Mark. My day job is at Replay.io and in my copious amounts of spare time, I maintain Redux and rewrite Immer. [00:23]
-
-**Mo:** I am Mo, I head the mobile team at Theo. I'm an active part of the React native ecosystem and community, and I organize the React Native London Meetups and conference, which is coming up in two weeks. [00:30]
-
-Terrifyingly so. [00:42]
-
-**Carl:** Coming right up. Yeah. And you got a shout out that we're gonna talk about. [00:43]
-
-## New releases
-
-**Carl:** Let's start with some new releases. Mark, tell us about Immer. [00:46]
-
-## [Immer 10.2](https://github.com/immerjs/immer/releases/tag/v10.2.0)
-
-**Mark:** Okay, I can, I can do both these things. So I actually take very full credit for this one. So to be clear, I do not maintain the Immer immutable update library that is Michelle West Rate, who created it and has maintained it all the easier years. [00:49]
-
-However, since the start of September, I have sunk a stupid amount of time, something like 120 plus hours into trying to rewrite the internals of Immer for faster performance after some re users filed complaints to the Redux repos, that it was kind of slow. So I filed a few different prs, one to make some relatively small tweaks, and then a couple larger architectural changes. [01:01]
-
-And Michelle just merged and released Immer 10.2 with the small options. And we are hoping to land the larger architectural changes in the near future. And those will probably come out as Immer version 11, hopefully in the next few weeks or something. So I'm excited faster for performance free upgrades. [01:26]
-
-Yeah, should be. [01:45]
-
-**Carl:** Yeah, love some big core performance improvements of deep packages. That's awesome. [01:46]
-
-**Mark:** And I will also hopefully turn this into a conference talk. Nice. [01:51]
-
-## [ArkType ArkRegex](https://arktype.io/docs/blog/arkregex) (typed regex)
-
-**Mark:** Along with that, I, I just saw the announcement, I think like yesterday, that the author of the ARC type validation Library, which is a, a competitor to Zod that takes a, a rather different API approach, just released a, a similar tool called ARC RegX. [01:55]
-
-It's a function that is supposed to be a replacement for defining regular expressions in JavaScript, but it actually parses the RegX string into TypeScript types so that it can both. Interpret at the type level, what the regular expression is doing, and also even provide syntax errors if the reg itself is invalid. [02:12]
-
-Just looking at the docs, my mind is blown. [02:38]
-
-## Main Content
-
-**Carl:** Well, yeah, other than new releases, we have a bunch of main content this month. [02:41]
-
-## React Conf
-
-**Carl:** The React conf happened, what, three weeks ago, and a bunch of new stuff came out of there. [02:45]
-
-## [Official ReactConf 2025 Recap](https://react.dev/blog/2025/10/16/react-conf-2025-recap)
-
-**Carl:** They did put up an official recap blog post from it on the 16th, about a week after the event happened. [02:50]
-
-## [Introducing the React Foundation](https://react.dev/blog/2025/10/07/introducing-the-react-foundation) (also from [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-the-react-foundation), [Meta engineering](https://engineering.fb.com/2025/10/07/open-source/introducing-the-react-foundation-the-new-home-for-react-react-native/), and [Seth Webster](https://thenewstack.io/react-foundation-leader-on-whats-next-for-the-framework/))
-
-**Carl:** The big takeaway here, I think, well, I don't know, we got a couple of big takeaways, but one of the headlines is definitely the React Foundation. This is a pretty big change to, or this sounds like it will be a moderately large change to the governance of React. They're pretty light on details of the actual governance, so far. They have talked about like a new technical steering committee. But they also say that the governance of that is not finalized. The members are not finalized, but they do have the founding members of the founding sponsors basically of this foundation, which are Amazon Call Stack, Expo, Meta, Microsoft Software Mansion, and Vercel with Seth Webster. [02:57]
-
-Seth Webster is executive director and he's the what manager of the React core team, [03:39]
-
-**Mark:** Basically. Yes. [03:44]
-
-**Carl:** Yeah, so that makes sense. He is basically already doing that role and expanding what the core team means to an intercompany organization. But yeah, it's a lot of the details that I was most curious about, like what does, what does this mean for governance? Like how will decisions be made are not yet answered right now from the, from the various posts on this. A quote is, the React team is actively working on this new technical governance structure, and we'll share more details in a future post. So this is an announcement of a future announcement in some ways, but it's pretty real. [03:46]
-
-So this is in collaboration with the Open JS Foundation, which is a partner to the Linux Foundation. So like th these are very large, pretty well-founded organizations that the React team is glomming onto in support of like a neutral home for React, as they call it. [04:19]
-
-It's sounds like they're in incorporating React Native into this as well, which I think is not necessarily a given. You know, if you're talking about the governance of React, what that means for React Native is not necessarily implied. But just looking at the founding members like Amazon, Call Stack, Software Mansion, and Expo, and I guess Microsoft too, like those are all heavy React native investors. [04:38]
-
-**Mo:** I think it's quite surprising in that sense because it's more heavy on the React native side. Like Vercel is really the key sort of non-react native player. The rest are really heavy on React Native and there's like noticeably missing membership from like Shopify on the Remix side as an example. I, I actually find it's very skewed towards React Native, almost shockingly. [05:01]
-
-**Carl:** Yeah, I'd agree with that. It's, it is almost shockingly skewed towards React. React Native, given that it was not really pitched as the React Native foundation. That's true. I guess Software Mansion does do a fair amount of web React work. But I, I believe Call Stack is predominantly a React native shop as well. [05:24]
-
-**Mark:** So I'll do my usual thing where I, I step back and provide historical context and what matter at all. So React was invented at Facebook. It has always been a project owned by Facebook and Meta. The code has been open source, but. You know, for years the entire development team was Facebook meta employees paid by Meta to work on React. And I've said even in my conference talks this year about Meta, Vercel, React ownership, that the React team has had the freedom to work on what they want. And that's true, but I've, I was reminded in some conversations with React team members at React Con, how much their work is constrained by, like the fact that their performance reviews are, "what have you done to further meta's goals this year?" [05:42]
-
-And so in some ways their ability to push React in the technical directions that they think are right, are limited by how much they can make the case for that. Inside Meta, even something like the Concurrent Stores work is essentially being pitched as, how can we make Facebook's Ads Manager app faster in a lot of ways? [06:38]
-
-So we saw multiple React team members move over to Vercel. Like people used to complain that this is all a Facebook app, all the meetings are inside Meta. There's no public roadmap, it's only meta. And then we had team members move to Vercel, and then it became, well, now Vercel is applying too much ownership to React and all the stuff we've talked about with Next and server components and Vercel and how that's supposedly driving the roadmap, et cetera. [07:02]
-
-And so the team itself has been split across two companies, and they're working together. It's one team, but it's kind of within these two companies. And so because of Reacts widespread usage, there's been calls for many, many years that there ought to be some kind of an independent foundation that would own the trademarks, the rights, the development process. [07:30]
-
-To React itself. And it always seemed kinda like one of those pipe dreams. The calls on Twitter to build, React into the browser. And obviously there's no way that's going to happen. And, and this felt like much of the same kind of idea. And so they, they did the initial React and the initial keynote at React Con, and they were mostly focusing on technical things. [07:56]
-
-Like last year we, we fixed the, the sibling preloading bug. That was the suspense gate problem that everyone was talking about last year. And 19.2 came out and the compiler is 1.0. And then Seth came out and he did the one more thing routine and as soon as he put the React Foundation slide up, my jaw dropped. [08:17]
-
-And I think I even said out loud, oh my word, they actually did it. And my first reaction was, even without knowing. Any actual details about what the foundation is or how it's going to work or whether this is even going to work out in practice. The fact that they have taken the time to do the legal preparation work to try to make this happen and are actually attempting to execute on that is a huge deal for React and the ecosystem. [08:40]
-
-It, it is a statement of good faith and intent for how they want React to proceed in the future. Like without any details, my immediate reaction is, yes, finally, this is a good step forward. We'll see what it means in practice, but this is a really big deal. [09:12]
-
-**Carl:** Yeah, I would agree with that. It's a really big deal that they're moving in this direction. [09:32]
-
-I'm really curious about the details because I think there's a lot of, I don't know, like in the past they've done working groups and et cetera. And my understanding of the takeaway is generally, has generally been that they found it really difficult to manage participation in those like open access kind of arenas. [09:37]
-
-So maybe the, this is kind of like adding a new layer of abstraction perhaps with administrative support from currently thriving independent foundations. Mm-hmm. So that, that definitely makes me think that this has a real chance of being something real and valuable that goes on for a long time. I'm curious what it means for things like, like in practice, it's not like anyone's employer is changing. [09:56]
-
-No details have been shared yet. At least that anyone is being paid from this new foundation. I, I don't know whether to call it meta or Facebook 'cause it's on the fb.com domain. Mm-hmm. But in the Facebook engineering announcement here, they do say that Meta has committed to a five year partnership with over $3 million in funding. [10:23]
-
-I don't know what other funding they might have. I don't know what other sources of funding they might have in the future, but like just looking at five years, $3 million, like that's 600,000 per year, which is like, you know, for meta engineers, that's like free engineers. So I don't know. I don't know what that means for people's incentives and where they will work and how their focus and performance will be evaluated. [10:42]
-
-Yeah. [11:04]
-
-**Mo:** What that rules out is that effectively the React Native or React and React Native Core teams will definitely not be unemployed by the React Foundation. Right. 'cause that would basically cover three salaries, which is far smaller than what the React teams are. [11:05]
-
-**Carl:** I think the React core team has like 10 engineers. [11:19]
-
-**Mo:** And RN is about the same. So you're talking 20 engineers. It's definitely not going to cover those employees to move them over, which is in some capacity. And then details are to be fleshed out. But in some capacity it is a bit disappointing because it would be great if they had more freedom as the React Native Core team to play around without the restrictions, like you mentioned, of the reviews that Meta has internally. [11:22]
-
-And so it's gonna be interesting to see how that Dyna dynamic plays out effectively because there is still gonna be that same team. At Meta [11:44]
-
-**Mark:** I, I have three sources of information that I'm piecing together for some of how the foundation is supposed to work. Seth Webster answered a few questions about this during the q and a session that was broadcast at React Conf. [11:51]
-
-I had a conversation with a couple React team members and the topic came up about how things would be governed. And then there was an article on the new stack where Seth Perry was interviewed and was giving some further details about some of the governance. [12:05]
-
-So as best I understand it, so you've got kind of the corporate level stuff that's Meta, Amazon, Callstack, Vercel, et cetera. They will then elect a technical steering committee. Which is, I guess sort of similar to how Node and other projects work, Seth said in the q and a, that meta will start with five votes on that corporate board, and then it will go down to one over the next five years. So you kind of a decreasing amount of influence in that sense. [12:21]
-
-The technical steering committee, I assume, would be able to make decisions themselves, but obviously the fact that they are employees of the companies elected by those companies, et cetera, they would be taking their company's interests into account in the process. The article says that the technical governance will be in the open more than it once was. [12:53]
-
-Request for comments, sets of stages, et cetera. But a lot of the process is still to be figured out. The article also talks about the foundation doing things like investing in React hubs, helping boot camps teach React better, possibly some things with conferences and alignment and such. So it sounds like the foundation is going to be doing more outreachy things. [13:17]
-
-So there, there's a lot of this that is not clear what it means in practice yet, but certainly. React is not solely a meta owned thing at this point. There are multiple companies that are invested in it. There is a, a future for React independent of META'S ownership and goals. And this all feels like the people who care are trained to do the right thing. [13:43]
-
-And [14:11]
-
-**Mo:** on the conference side, I mean, I hope that's the case because one of the, as a conference organizer, one of the things that's perhaps challenging is that Meta doesn't necessarily sponsor any conferences beyond just React conf, right? And so, look, it's well known that that's sort of the case. And so maybe the React Foundations that is going to be able to sponsor those conferences, even if it's not a meta badge to speak, which would be very, very interesting if some of that is used for that. [14:11]
-
-So I'm sure it's not just Meta who's investing, right? Like I, I suspect that there's funding coming in from. Amazon and Microsoft, at least from the bigger, bigger sort of established enterprises [14:38]
-
-**Carl:** hopefully. And that's interesting. And the new Stack article interviewed Seth and has a bunch of poll quotes from him and they do talk about that, that like the foundation will look at expanding the annual React conf. [14:49]
-
-I guess that's not sponsoring other conferences, but they're talking about conferences at least. But also something that caught my attention. They say while React Comp is one of the few conferences that actually makes a profit, it basically only paid for itself. And also it's a thousand dollars a ticket conference. [15:00]
-
-So like hopefully the mode of making conferences self-sustaining is not making them cost a thousand dollars. [15:14]
-
-**Mo:** Yeah. I mean conferences are from experience a very, very expensive endeavor. And if you don't have companies backing them, they will make a loss. [15:22]
-
-**Carl:** I do wanna shout out, as we mentioned at the start, Seth says "We have lots of boot camps out there that are doing their best, but they're also sending people out into the world misinformed about how React works." [15:31]
-
-This is interesting there. It's a, it's funny, they're actually hitting on a couple of points that I've investigated myself about how to do businesses in like a community since like I had previously connected with a bootcamp. Somebody was working there as the curriculum lead and they were doing a curriculum overhaul. [15:40]
-
-'cause they hadn't changed what they were teaching in three or four years. And they were like, is this still relevant? Is this what the industry's using? And I was like, cool. I help run a community. I know lots of experts. I would be happy to facilitate some kind of professional review. And then the bootcamp curriculum lead got laid off because that was 2022 and lots of things were not happening. So it's interesting to see them talk about things that I've thought a lot about. [15:59]
-
-And also a lovely shout out, Seth says there are also cohorts such as meetups and local groups that could be assisted. One meetup actually led to the creation of the conference React Native London. So that's super cool. Love that for you, Mo. [16:22]
-
-**Mo:** Yeah, I didn't, I, I did not have that on my Bingo card to get a shout out from Seth Webster on an interview, which is awesome. Yeah, it was good to have him last year. [16:36]
-
-**Carl:** Mo is the organizer of React Native London and that one meetup that led to the creation. So that, that's just fun. [16:44]
-
-That's cool. We have actual players in the ecosystem in the podcast right now. [16:51]
-
-**Mo:** Well, you got Mark. So I'm stepping up to very, very, very high standards. Pretending to. [16:55]
-
-**Carl:** Cool though. Yeah. So I don't know. I don't know if there's more to say there. [17:00]
-
-## 19.2 (Activity, useEffectEvent)
-
-**Mark:** Some of the more technical stuff. So they, they talked about React 19.2 coming out, which if you've been paying attention to this podcast for the last several months, you would've known all the details already. Like the new activity component for being able to hide components while persisting state use effect event for hopefully fewer use effect related bugs, et cetera. React compiler hit 1.0 and then [17:03]
-
-## React Native news
-
-**Mark:** Mo as like as usual, you wanna talk about the React Native-y things? [17:27]
-
-## [New architecture only from v0.82](https://reactnative.dev/blog/2025/10/08/react-native-0.82#new-architecture-only)
-
-**Mo:** So a few updates that they did, one of which was quite surprising was that the next release of React native version 0.82 is going to be new architecture only. [17:32]
-
-So obviously earlier on a few months ago, we talked about how they deprecated the old architecture than they froze the old architecture. Now they're dropping the old architecture. And so to me that was a much faster deprecation cycle than I, I would've expected. Specifically when it comes to the fact that there are still a fair few libraries that are using the old architecture and only support the old architecture. [17:44]
-
-So to give you a very concrete example, we had our monthly meetup literally yesterday, and there was a talk about Arrive, which is this animation engine that a lot of people are using to animate websites and make really, really cool stuff. But what we learned surprisingly was that Rive only supports the old architecture. [18:06]
-
-So what that means is that this company who's a very popular healthcare company, really don't have a path to sort of migrate to the new architecture and hence version 0.82 until Rive starts to support the new architecture. So there are still libraries, albeit the majority of major libraries have been ported to the new architecture that are still hanging behind. [18:24]
-
-So I'm quite surprised by this, but we'll see how it goes. It probably means that these library maintainers really need to like step up in the next month or two and get ready. [18:44]
-
-## [Vega OS announcement](https://developer.amazon.com/apps-and-games/blogs/2025/09/announcing-vega-os)
-
-**Mo:** The second big thing, which I have a little bit about later on, but just a quick one, is that Amazon did the Vega Os announcement earlier. [18:52]
-
-It was towards the end of September that they actually announced it, but [19:02]
-
-## [Vega introduction at React Conf](https://www.youtube.com/watch?v=p9OcztRyDl0&t=5737s)
-
-**Mo:** they formally talked to the React and React native communities about it during React Conf. This is a completely new operating system that's fully built from scratch by Amazon folks and React Native is the UI layer. It's the only way that you can write apps for it, which is quite a big investment from Amazon's perspective into React Native as a technology. [19:04]
-
-So Amazon makes a lot of devices. For a little bit of context, you might've seen their Fire TV devices, some of the Kindle fire devices that they had, but also like Echo dots and a whole slew of different devices that they manufacture. And previously a lot of these were running on Android or a variety of Android called Fire Os that they had adopted from the Android open source projects. [19:27]
-
-And so now they've kind of completely ditched that and they're betting long term on React native now at our company at Theo and a bunch of other companies have been sort of working with Amazon behind the scenes on this. And we're aware of this but weren't really allowed to speak about it. So it's now out in the public. [19:47]
-
-But it has been a good while, which I cannot specify how long that duration is that I have been aware of this, but just not able to talk about it and have been working with the Amazon folks to make sure that things are ready for their launch. So they have an introduction video at React Con, which I think is interesting because TV apps need to run on very, very limited specs. You're talking like a few gigs of Ram one or two gigs of ram and like very, very, very slow CPUs and some of them are even worse than that. So effectively they really had to optimize the living crap out of their operating system and make sure that React plays nice with it and is like the first class citizen when it comes to it. [20:02]
-
-So it's, it's very interesting how they had to optimize it and it was a big undertaking for them. So. I guess congrats to the Amazon team, but beyond that, it's quite interesting for people that are interested in performance and React and React native. [20:38]
-
-**Carl:** Yeah, I was just scanning this to see if I could find any details about what they built on top of, because like, I don't know, nobody builds a whole OS from scratch anymore. And this is on top of Linux? [20:48]
-
-**Mo:** Yeah, it's c plus plus on top of Linux. Basically it's a Linux. Or is a Unix based system. [20:59]
-
-**Carl:** Right, like, and so is Android. Like, I'm curious to what extent this is a locked down, stripped back version of Android that they're calling Vega. They don't say that anywhere, but like reading the tea leaves here, I, my assumption is that the, I don't know, Android was such a massive undertaking that Google then acquired and commercialized. [21:05]
-
-Curious to hear more technical details about the OS layer here and how it… [21:28]
-
-**Mo:** I can tell you a little bit about that because I've known about it for a while. It's not on top of Android in any capacity. It is fully, the Android open source project components of it are fully stripped out. It's built from scratch, which means that compatibility with old apps is. [21:32]
-
-Limited and there's other solutions. It's not that you can run Android apps on it as an example that we're the old Fire OS apps. [21:47]
-
-**Carl:** So wait, it sounds a little bit like you're saying there is a shared lineage with Android, but it's different enough that its own technically distinct thing. [21:54]
-
-**Mo:** They share a technical lineage in the same capacity that like Mac Os and Androids here, which is, they are both unique systems and that's pretty much it. [22:02]
-
-Like they serve the same kernel but like so does 90% of devices out there. So it's as Android, as IOS's, Android, if that kind of makes sense. [22:11]
-
-**Carl:** The Tree of Life, kingdom Family order. Like this is not shared genus. This is shared order maybe? Yes. Okay, cool. Good to know. Thank you. [22:19]
-
-**Mark:** I do wanna highlight a couple talks in particular, and again, you can look at the whole React con recap blog posts to get links to the different talks and the different portions of the live stream. [22:27]
-
-## Joe Savona’s “[Exploring React Performance](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=20274s)” talk
-
-**Mark:** A lot of good talks that were worth watching, but two that I liked in particular, Joe Savona did a talk on some of the React team's performance experiments, and there's a bit of controversy because he showed a bunch of hypothetical, semi hypothetical benchmark numbers without any real details on the actual implementation of the benchmarks. [22:36]
-
-And then some of them were like, versus we built NAP with signals and compared it with one with React and then ex a highly prototype React and a bunch of other stuff. And then people were saying, well, we tried to mimic this and we think you're probably using signals the wrong way. But it was still interesting to hear the discussion around, we agree that performance has been a problem and we've tried prototyping some different ideas to see what's possible and where bottlenecks might be. [22:56]
-
-## Ricky’s “[Async React Part I](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=10907s)” and “[Part II](https://www.youtube.com/watch?v=p9OcztRyDl0&t=29073s)” ([repo](https://github.com/rickhanlonii/async-react))
-
-**Mark:** The other one I really wanna point to though, Rick Hanlon did a talk called Async React and he had a few major, he had a couple different points out of this. [23:26]
-
-One was that the React team has been talking about things like suspense and concurrency since 2018, and if it's been hard to follow where the React team is trained to go with this, it's 'cause the React team itself really didn't know where they were trained to go with this. He even pulled out meeting notes from a React team weekly meeting in like 2015 or 2016 where they started having the first initial ideas for, we think we want to go in this direction, but they really didn't know what the final result ought to look like or how they were going to get there. [23:36]
-
-And so showed a diagram with a whole bunch of back and forth wavy lines like we, we don't know where we're going, but now it's 2025. We've gotten through the confusion. We've now built all the main concurrent pieces that we were trained to build. We are seeing the results of even like the React 16 fiber rerate. [24:15]
-
-And now we can actually say, we've built these pieces and here's how they ought to fit together. And so the second half of his talk was a demo where he took a badly written but viable React app, which uses use effect for data fetching and manual setting, state for loading states and things like that. [24:37]
-
-And he first refactored it to have a bunch of transitions for better loading animations, using suspense for the data fetching, and he showed the visible improvements in user experience. And then his point towards the end was that, yeah, the, so like this is how modern Async React code ought to work. But in fact, you shouldn't even have to write most of this code in your own app because the transitions and the loading states and everything else really ought to be embedded in your router and your data fetching library. [24:56]
-
-Now, unfortunately, his actual talk got interrupted for stupid technical reasons. So he came back at the end of day two and picked up with his demo and actually had a chance to do a better version of it. [25:36]
-
-And so I think the key points are, one, the React team has now built the concurrent async features that they've talked about for years. Two, a lot of us, including myself, are still kind of stuck in like a 20 16, 20 18 era mindset of how to use React three. These things make writing React apps better and better user experience. Four, we need to get these things embedded in component libraries and data fetching libraries so that a lot of this stuff just works outta the box. [25:48]
-
-So I highly, highly recommend watching Ricky's talk. He also put up the demo code as well. [26:23]
-
-**Carl:** That was a good talk. It was a good demo. I will say, while watching him write the code. I was like, man, this looks really complicated. [26:29]
-
-**Mark:** Yeah. And that, and that's another point that we're going to touch on here with a couple of the, the other things as well. [26:37]
-
-One other thing that really caught my attention, so if you've been listening to podcasts for a while, you've heard me agitating, saying that we really need is a new React working group where folks from the community can officially communicate to the React team for things like, Hey, we think there should be more docs to cover this topic. [26:41]
-
-Or, oops, create React app just broke. I think you should fix it, and things like that. And Ricky was actually the person who drove most of the React eight team. Working group. [27:00]
-
-## [Async React Working Group](https://github.com/reactwg/async-react)
-
-**Mark:** And so at the end of his talk, Ricky actually announced that there is now a new Async React working group. And this is sort of a catchall, it's meant to cover discussions of things like how do we get async React features into major ecosystem libraries and, what kind of docs should we have to cover this stuff? [27:12]
-
-## First [discussion of more docs ideas](https://github.com/reactwg/async-react/discussions/2)
-
-**Mark:** And so the, even the first discussion thread is a lot of discussion between me, Ricky, Dan Aberman of Corbin Crutchley, about a whole bunch of possible docs, pages that we could add that would cover things like transitions and suspense and how to use them correctly. [27:35]
-
-And getting people from the community to contribute those new docs pages rather than waiting on the React team. To write them. So I am actually genuinely, genuinely excited. Like I've done a lot of complaining and this is the answer to my complaints that we have working group and docs plans and an agreement that people outside the team can contribute. [27:53]
-
-So like I am actually legitimately thrilled by this. [28:16]
-
-**Carl:** Nice. I do appreciate more, I don't know, open participation more, more discussion. That's great. [28:21]
-
-## Remix v3 announcement
-
-**Carl:** Should we get into Remix V three? [28:27]
-
-**Mark:** Yes, we should. Alright, so usual caveat, I still have not had time to actually watch the announcement, but I, I think I can give a fair summary of it from having seen the discussion on Twitter and the articles afterwards. [28:29]
-
-We have mentioned for the last several months that they were teasing Remix V three is going to be, not pre-ACT, its own component model, something with iframes, whatever. And our last comments on it were just show us some code already. Well, at the Remix Jam conference, they did actually show us the code. [28:43]
-
-## [Announcement demo timestamped breakdown](https://github.com/markdalgleish/remix3-resources)
-
-**Mark:** There was a, a repo put together that did timestamped links to all the appropriate pieces of the announcement video. So if you'd like to be able to jump in and see the examples of what Remix V three code is supposed to look like, that should make it easier. My first impressions, again, just having seen screenshots of the code in following the discussions, is that Remix v three's component model is sort of a mixture between React, view and backbone. [29:03]
-
-So it's kind of like React in that you have function components and they, and that uses JSX. It's kind of like view and the composition API, where you're given a closure as the setup. It's a little bit like backbone in that the function component you're rating still sort of is organized like as if it were a class. [29:35]
-
-It passes in a reference to the instance rather than getting the props as an argument, and you're supposed to call it this. And part of that is to make use of a TypeScript typing trick that lets you declare the type of this as an argument to a function. But also you manually trigger updates by first mutating a variable in the setup closure, and then you manually call this update. [29:58]
-
-And so Ryan Florence even said, this is basically old school React class component, this dot force update. Essentially, so I, I can see bits and pieces of parallels and influences between all three of those frameworks. When I look at the Remix code, it's also supposed to come with a bunch of utilities for being able to compose event handlers together. [30:29]
-
-And yeah, so we, we have finally seen the code. I believe they also gave some demonstrations of what the server side loading story is supposed to look like. Some kind of an I frame alike component that has its own URL and can automatically re fetch HTML. I haven't looked into those pieces as much, so very big picture. [30:54]
-
-I saw a lot of people arguing about having this dot update. A lot of people saying it feels like a step backwards, it's manual update code. [31:19]
-
-## [Updates syntax can be customized?](https://x.com/sergiodxa/status/1976878377509568871)
-
-**Mark:** But some people demonstrated that you can very quickly write your own wrappers that just call this DOT update internally. I have seen wrappers that mimic like the used state hook. [31:28]
-
-I've seen wrappers for other state management libraries like Redux. So it's a primitive that can clearly be abstracted if you really want to. I saw some good posts and articles from James Long and a couple other people with thoughts on the ability to compose interactions together. Carl, to your point that modern React and all the new async features feel very complicated. [31:39]
-
-Like there's good reasons why methods like transitions exist to try to give better user experiences, but it's just all these additional concepts and behaviors you have to keep track of in your head. And Remix is trying to go for a less magic, less abstraction approach. So we'll see what it means in terms of adoption. [32:06]
-
-Again, this is non-reactive, so different framework, different ecosystem. Who knows what the actual adoption will look like, but I get the sense of what they're trying to go for and I, I think it will appeal to some number of users out there that want to have that kind of behavior. [32:31]
-
-**Carl:** Yeah, I'll definitely keep paying attention to it 'cause they're thoughtful about things and historically have just done a lot. [32:49]
-
-So I'm very curious to see where this goes. But my gut feeling here is that this is going to end up more as an API exploration and that any great ideas that come out of it will be a fresh exploration and then maybe validate some ideas that get brought into React or view or other big tools. But yeah, I, I could be wrong, could be, could be more independently successful than that. [32:58]
-
-They, they did stress in the video that I watched, that this is all like prototype phase. So they, like right now apparently there's splitting it all up into a bunch of different packages. They can iterate independently and explore a bunch of different things. But the, the final intended usage would be from one package, not from 20 different packages. Just to throw that out there as a a thing that will change. Yeah, I don't know. We'll see. We'll see. I think the component model is just gonna be really hard to disrupt. [33:25]
-
-One, one thing I did see in the video of Ryan Florence talking about just talking while he was demoing, he like compared and contrasted with like, here's how we do state changes and you just call the dispatch function instead of set state. [33:54]
-
-And I was like, I dunno, you can do that in React. Like they've been encouraging people to do that for years, for like six years basically Ever since hooks came out and you could do a state reducer, they were like, please, except for trivial uses of state, all of your state should be in a reducer and you should use dispatch. Not set state. So just like calling that out as a point of comparison, like React has been trying to do that for a long time too. It's just nobody actually does, I dunno, just caught my attention. [34:08]
-
-**Mark:** Well least we have an actual code to critique now and argue about instead of the vague teasing. True facts. [34:35]
-
-**Carl:** I will happily continue reading code and critiquing. [34:41]
-
-## [I built the same app 10 times](https://www.lorenstew.art/blog/10-kanban-boards) ([code](https://github.com/lorenseanstewart/kanban-comparison))
-
-**Carl:** Speaking of which , I love this project. I have thought about doing this so many different times and I never have because it's hard. Somebody built the same app 10 times in a variety of different frameworks and tools and benchmarked them and compared and contrasted their performance in a bunch of different metrics. [34:44]
-
-It seemed like they focused pretty heavily on like bundle size to me, very wordy. I, I will say I got a little bit lost in the [35:05]
-
-**Mark:** instruction. Very wordy and very, also, a lot of the article was very clearly AI generated. I saw some comments from the author saying he had written pieces of it in sections and used AI to help with it. [35:12]
-
-So like there, there was clearly human involvement in it, but the, the AI generation of the article itself was a critique point. [35:22]
-
-**Carl:** Yeah. Just like as I'm scrolling, it's got so many paragraphs in a row that are all like identically long. Just a little bit of a wall of text. I definitely skimmed this pretty hard. [35:30]
-
-All that aside, like I just love the idea of doing the exact same thing with the exact same. Like, well, I don't know that they use the same test suite, but that, that was always my idea is build. You build an end-to-end test suite and then you get a passing app for that test suite in a bunch of different tools. [35:38]
-
-I meant to do more of a deep code review on a couple of the different implementations. It's a CanBan board, it's, you know, a Trello clone type project where you're doing task management with cards and drag and drop. I guess it, it's a great and a parable comparison because drag and drop is really hard to do and so it's very frequently something people try to lean on libraries for. [35:54]
-
-So if you are implementing it yourself, that's kind of cha, that makes it a little bit challenging to use as a point of comparison. But the tools that were used here, he built it analog, which I guess is vanilla js is what I'm assuming, or [36:15]
-
-**Mark:** analog is actually a, a next like tool for Angular. [36:31]
-
-**Carl:** Oh great. Okay. Okay. So you built it an analog, which is an angular type thing. [36:36]
-
-And HTMX, Marco, which I'd never heard of. Next.JS, of course. Next. Sure. Qwik City, which is Qwik. I've heard of Qwik City I had not heard of. So this is I guess [36:41]
-
-**Mark:** probably another solid versus solid start type thing. [36:53]
-
-**Carl:** Qwik city to qwik Sure. Solid start spelt Kit Tan Stack with solid and then Tan Stack with React. [36:55]
-
-Yeah, one of the first tables, one of the first actual like points of comparison of the output tables is just on bundle size and how much JavaScript was served in order to. Get this app running. They used Next.JS version 16 as the baseline and that was about 500 kilobytes gzipped, which is huge. It's big hand stack. [37:03]
-
-Start with React. Clocked in at about 300 kilobytes a little bit more with solid was a half of that hand stack. Start with solid was 150 ish kilobytes. The smallest was Marco. 12. At 12 kilobytes followed by quick city at 88. Oh, I just realized there's parenthesized compressed. I thought I was reading the compressed and I was not. [37:25]
-
-**Mark:** There's also the board page versus the homepage sizes. [37:49]
-
-**Carl:** Yeah. Okay. Alright. This is more confusingly presented than I realized. [37:53]
-
-## Same author as [React Won by Default and It’s Killing Innovation](https://www.lorenstew.art/blog/react-won-by-default/)
-
-**Mark:** I think the biggest picture takeaways, number one, it's worth noting that the author of this article previously put up a post a month or two ago saying that React by is the default choice and it's killing innovation in the ecosystem. [37:57]
-
-So that kind of to where they're coming from. But I do think they did. They were legitimately trying to do a real meaningful comparison, even if the results were sort of what they were hoping they would be. IE reacted big and bad. So yeah, the big takeaways are like React itself is huge and so any React app is going to be very large bundle size wise. [38:08]
-
-And look, if we do like Tan Stack with Solid instead of Tan Stack with React, it gets smaller. But also if you do these other frameworks, it gets even better smaller and then it kind of ends with a bit of a, another rant about React is a bad choice. [38:32]
-
-**Carl:** Yeah, I, I will validate that. To me it also looked like they really tried to give React a fair shake here. [38:49]
-
-Like, you know, if you wanted to, if you were wanting to complain about bundle size, if React apps, like there are so many easy ways to bloat this up to a couple of megabytes. So like the fact that they didn't do that is indicative enough to me that they tried to give this a fair shot. It's cool. I love this. [38:55]
-
-This is a great project, great effort. I don't know that, to me, at the end of the day, this is interesting and fascinating and a great point of comparison, and also like not that meaningful because the performance metrics that you measure here that are easily measured by comparing the outputs of identically functional applications, that's really only like maybe a third of the reason why you would choose to build an app with any particular set of tools. [39:11]
-
-Like really, if you're starting a company and hiring engineers and doing a greenfield project. Like some of the most important things are how much will this cost? [39:41]
-
-**Mark:** How well is everything? How well is everything documented? How easily can we spin up engineers who know these things? I mean, the, the ecosystem argument is a real thing. [39:52]
-
-**Carl:** And like, you know, if it takes you two months to find a developer, you know, a senior developer who can build your app in Marco, you know, you could do that in a week. I don't know. The hiring for React is much easier than hiring for some niche tool. And I have seen writeups of people saying like, yeah, we built our startup on this niche framework and we couldn't hire for it. And that ended up contributing to the death of the company. [39:59]
-
-So like, you know, these performance metrics are important, they're really useful, it's great to have them. So we know where opportunities to improve are like tying this back mark to your Immer work. Like if somebody hadn't complained about performance, you wouldn't know that it needed to get better. [40:23]
-
-Pretty [40:37]
-
-**Mark:** much. Yeah. [40:37]
-
-**Carl:** So this is great and I love it, but it's also not the end all, be all of like decision making for, things. Yeah. It's also, man, this, it's just so hard to read because of how long it is. I wish they'd stripped this down a bit more. [40:38]
-
-**Mo:** And if we take like a step back out of our like web ecosystem bubble for a second, like you go to like the backend world and like enterprise business companies or finance or whatever, and like they employ a lot of developers, right? [40:49]
-
-Like thousands, thousands and thousands of developers. And like there's a reason they're all on Java and .Net is because like they can hire for those and it's pretty easy to build a team around. That's the top priority. Even like this stuff is quite minuscule when people are, companies are hiring at a large scale. [41:04]
-
-And then the second thing, which is like not accounted for, I think in this like approach of looking at like just the bundle size that's outputted is the fact that like your productivity with the fact that most of the AI tools are really like optimized around React is not something that you should not look at and consider when you're choosing something. [41:21]
-
-There's so much training data and so much like tooling around building React apps quickly and prototyping React features or React apps that with AI that is just a bit, it feels a bit moot some of some of these conversations. It feels. [41:41]
-
-**Mark:** To be clear, like React has got itself has gotten much bigger over the years. [41:55]
-
-In fact, even just 18 to 19 it got notice will be bigger. Bigger bundle sizes are not a good thing. We are not sitting here saying Your bundle size does not matter. Alex Russell, as much as I disagree with his communication style is right to point to the technical receipts saying that big bundle sizes are bad, but also it's not the only single metric you should care about. [41:59]
-
-**Carl:** Yeah, right. Yep. And also, last thing I'll shout out here. I think the author of this blog post also mentions that he tried not to pull in too many dependencies. So like did not pull in fetch wrappers or data fetch tools like React Query and. [42:21]
-
-Axios, the data fetch thing, which many people still use, I don't know. They still have a fair amount of utility just for things like observability and security and various guarantees like that. Like Axios itself is 36 kilobytes ified like 14 compressed. React Query is 55 kilobytes. I guess to say that the way he did it is actually better quote unquote for React in terms of the bundle size argument, but it's also not representative of how people actually build apps. [42:40]
-
-It's a challenge of these types of articles is that by necessity it has to be the level of scope that a single developer can execute on their own, and that's just not how most apps are built. Like most apps are not passion projects by one person. So yeah. Super cool. Love this post. It's interesting more than it is authoritative, I think. [43:11]
-
-**Mark:** Good way to put it. Mo, tell us about Solito. [43:30]
-
-## [Solito 5](https://solito.dev/v5)
-
-**Mo:** Yes, Solito. So go back a few months. You'll remember that we said Fernando Rojo joined Vercel. And he joined as the head of mobile firm Vercel. This was significant because he's the author of this library called Solito and a few other libraries like Ziga. So he's really, for the last few years, has been focused on. [43:33]
-
-Using React native on the web as well, especially with Next.JS. So he built his own startup in that sort of tech stack. It is from experience and having built with this tech stack quite a lot, it's a challenging approach because you are always balancing oversharing between your native components and your React native code and the web functionality that you import in. [43:53]
-
-And oftentimes that comes at a detriment of performance or ux, depending on if you do it right. And the more that you share, the more chance there is that you're not, you're sharing something that you probably shouldn't share. And so there's a lot of libraries in the secret system, but Solito is probably one of the key ones where it lets you share navigation across Next.JS and React native apps. [44:16]
-
-Now, we've talked a bit about Toledo in the past. One of the big limitations that any library in this space has is that it relies on React Native Web Now, React native web was made several, several years ago. I think it was back in 2015. And it was made by Nicholas Gallagher. Now, he also did a talk at React Conf, which I would recommend you watch about React strict dom. [44:39]
-
-But the key thing with React Native Web is that it's not really receiving as much love because Nicholas is working more on React strict dom, which is sort of like the future path for sharing code across the web and mobile. And so React native web is, is a little bit bloated, and what that means is that any library that you really use, especially your, something like your navigation and routing library will import in large portions of React Native Web, even if you're not using all of the APIs. [45:00]
-
-And so that means that your bundle size goes through the roof. And what the Vercel team slash Fernando Roho have now been able to do is actually remove React Native Web as a dependency from from Solito, which is pretty massive. It sets us up in a foundation where you can effectively get ready for React strict dom adoption more easily in the long run, but also means that if you pick and choose your libraries well, when you're building a UniVercel app and you really think about what you're using on the web platforms, you can really start to tackle that bundle size problem. [45:25]
-
-It doesn't help if you're using libraries like let's say Reanimated, which has a pretty heavy reliance on React Native web. But if you're going really vanilla and you're very careful, it means that you can actually achieve much better performance on the web by using this new version of Solito, which is very exciting. [46:00]
-
-So yeah, if you're already using Solito, give it a look and if you're thinking of building a uniVercel app, it's a really good candidate if you wanna build a highly performant web variant of your application. [46:16]
-
-**Carl:** I love that. It definitely makes a lot of sense to start moving away from React Native Web, given that we've compared and contrasted React Native Web with like React strict dom. [46:25]
-
-I guess it makes sense to move away from React native web, 'cause the guy who made it is now doing a different thing in the exact same space from a very different angle. So yeah, that's a pretty strong argument for changing. [46:35]
-
-## Next 16 and Directives debate
-
-**Mark:** Okay, the last major topic for the day next 16 and directives. [46:49]
-
-## [Next 16 released](https://nextjs.org/blog/next-16)
-
-**Mark:** So next 16 came out. The headline feature is they now have what they're calling cash components. This is the, I don't know, second, third, fourth iteration on how to do caching in next, across the last couple major versions. I'm not gonna pretend that I understand what, how this works. [46:56]
-
-No one does, but thing is that they introduced. Another new directive. Now to recap a directive is these little strings that you just put in your code. Originally we had use strict back in the ES 2015 days and then React server components introduced, use server and use client, and now we have 'use cache'. [47:15]
-
-And the idea is that by slapping this directive on certain components, that tells the next bundler and compiler that, Hey, this is the output of this component is supposed to be cached. I don't understand the details. From there, go read the documentation long. With that, they also announced a new long-lived workflow product, kind of similar to what the temporal company. [47:40]
-
-Has built where you can have a function, for example, that implements a billing workflow by sweeping for 30 days and you've written what looks like one function, but under the hood it's actually like saving its status to a database and then a time job wakes it up and continues executing the code, that sort of thing. [48:03]
-
-And I believe they opted to implement this also with a use workflow directive and like a use step directive. And I think there may have even been one or two others related to variations on caching, like use Cache, remote, something like that. And meanwhile, we've also got the React compiler has opted to use directives for a couple things. [48:23]
-
-So there's a use no memo directive. If you want to tell the compiler, don't try to auto optimize this component. And so all of a sudden we've gone from the JavaScript language specifying. One directive. There was also the unofficial, oh, was it use a SM directive that was part of a SM js, the precursor to web assembly, but like one official directive in the language. [48:48]
-
-And now we have a couple for bundlers, and now we have more for workflows and the compiler and all these other things. And so the Twitter discourse over the last couple weeks has been our directives, good or bad. And they're so confusing and they are changing the language. And you have all this bundler defined behavior that is not part of the language spec. [49:18]
-
-## [Directives and the Platform Boundary](https://tanstack.com/blog/directives-and-the-platform-boundary)
-
-**Mark:** And so Tanner Linsley, again, creator of all the different Tan Stack libraries, put out a blog post where he expressed his opinion that he does not think directives are a good idea. Because they are unofficial, because they're not standardized, because make it not clear what the actual intended behavior ought to be, as opposed to like explicitly importing a function that says, turn this into a client server function or something like that. [49:41]
-
-So there there's been a lot of arguing about directives and are they understandable? Are they good or bad? Are they too much magic? So that's been happening. [50:11]
-
-**Carl:** I'll say it. They're bad. It's too much magic. I hate it. I'm not a fan. [50:22]
-
-**Mark:** I understand the thought process. I, I can't say I'm thrilled. And so on that note, two article articles that are related enough to throw them into this section. [50:26]
-
-## Technical critique of Next App Router: [Everyone Hates Next.js](https://paperclover.net/blog/webdev/everyone-hates-nextjs)
-
-**Mark:** I've seen lots of different article articles upset at Next or critiquing next. Most of them are frankly very badly written, but I saw one come out last week that I thought was very well written and focused strictly on the technical pros and cons of using the App Router. The title is Clickbait, everyone Hates Next, but the article itself is actually very well written. [50:34]
-
-It discusses technical aspects of using Next, some of the problems his team went in, ran into, and how and why they ended up migrating from the App Router over to 10 Stack Start. And then Nadia Vic, who has done a bunch of very excellent articles on React rendering behavior, put together a very data-driven look into do server components actually help with things like First Contentual Paint and various other White House style metrics. [50:57]
-
-So very worth reading. [51:26]
-
-**Carl:** As I'm trying to think about how you might solve problems of caching and runtime things without directives. And I'm thinking about, you know, my experiences using like CloudFlare workers or other runtimes where it's not a traditional process scope. And I don't know, I guess like it is a really challenging question of like, how do you signal to a developer that the file they're editing runs in a certain type of context? [51:27]
-
-And I guess I understand why directives are an appealing thing to reach for, but man, just the state we're in right now is really a lot. I found the Next.JS docs page with directives and it lists 'use cache', 'use client', 'use server', and then two sub variants of 'use cache'. And that's not all of 'em that, so there's missing ones here and. [51:56]
-
-I don't know. When you start getting into like many different contexts, just naming them at the top of the file doesn't really seem like enough for me. I don't know. And then like the implication for that code can import other code that will not have it flagged what context it's running in via a directive at the top of the file. [52:20]
-
-And I don't know. It's a tough problem. It's a weird unanswered question in the industry, like not even the ecosystem, but like the industry. How do you flag code that might run on your browser, a real server, serverless environment, and yeah, I don't know. It's a challenge. [52:40]
-
-**Mark:** I think it really does speak to the overhead and mental complexity of trying to juggle all these things. [52:58]
-
-We said earlier that React 19 has, 18, 19 have introduced a whole lot of things like transitions and other pieces to try to let you write better user experiences. But now you're having to juggle in your head like, here's the current version of my app in its display state versus a work in progress rendered version versus a future output rendered version. [53:04]
-
-On the server side we're having to deal with, this is server code, this is client code, sometimes they're mixed together in the same file, sometimes they're mixed together in the same component. Which code is running? In which context do I have to worry about accidentally leaking security tokens or something like that. [53:28]
-
-We're building tools to solve real problems, but there's more and more to juggle in your head as you go. [53:46]
-
-**Carl:** Well, I'm gonna plug effect one more time because I saw it come up in the chat. Oh, man. It just like talking about different ways of signaling facts about the code. The code you're writing has certain dependencies. [53:53]
-
-Certain dependencies is too loaded. That's, that carries too much context with it, but the code you write has a certain amount of assumption baked into it about what will be available and what it can rely on. The thing I love about a fact is that it makes that more explicit and brings it into the type system. [54:06]
-
-So I think the challenge right now is that we are missing a like platform and language level abstraction to express information like this. And yeah, I don't think we're gonna get it anytime soon. And I think these explorations will lead to something like that and hopefully converge into something. But I think this is gonna be like a real state-of-the-art problem for a couple of years and still, which I hate, but it'll get better. [54:26]
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Alright, moving on to the lightning round. [54:56]
-
-## [ViteConf roundup](https://voidzero.dev/posts/whats-new-viteconf-2025)
-
-**Mark:** In addition to React Con and Remix Jam, we also had Vite Conf and the V team gave a bunch of updates on all the different tools they've been working on. Some of the highlights to me were that OX LT now supports ES lint and JS plugins via some really awesome tricks for interop between js and rust without the the cost of serial serialization. [54:58]
-
-They announced a combined tool chain called v plus, which basically pulls all the different tools, VIOX lint, OX format, Vitest, everything else together. That'll be their enterprise sales targeted tool set. And then Vitest four is out with browser mode support. You basically just put a flag in your Vitest config and suddenly your tests are running in a real browser instead of a node plus js. [55:21]
-
-## [AWS Outage Postmortem](https://aws.amazon.com/message/101925/)
-
-**Mark:** Last week, AWS east went down and the internet died and they put out the postmortem and it was DNS apparently they, their internal DNS system for dynamo DB had like three different instances of the DNS updater running and one of them got stuck and was taking a long time to complete, and the other one came along and updated and then said, well, these, some of these plans look out of date, let's delete them. [55:49]
-
-And next thing you know, DNS goes down, dynamo DB goes down and the internet goes down. So, oops. [56:19]
-
-**Mo:** It's funny that the, uh, internet is backed by Dynamo db. [56:28]
-
-**Mark:** A lot of people like us East One is the default. A lot of people have tried to get away from US East one, but when a lot of Amazon's own stuff depends on US. [56:31]
-
-East one. Yep. You all [56:39]
-
-**Mo:** of your certificates can only be issued in US East one, so that doesn't really help much. Side note, if you end up working in a consultancy one day, just hope nothing like this happens because the morning of was fascinating reaching out and getting reached out to by a bunch of clients being like, my site is down. [56:40]
-
-And then having to figure out what's going wrong, which is US East one on AWS. So it was a fun Monday, [56:57]
-
-**Carl:** but at least the uh, at the end of it was a vendor is out. This is not our fault. [57:02]
-
-**Mo:** At least it was that, which was great. Cool. Moving on. [57:07]
-
-## [Voltra](https://x.com/saul_sharma/status/1972161677165473980)
-
-**Mo:** So a couple of React native lightning route items. Firstly ra, which is really cool because we've talked a little bit about live activities on iOS and iOS extensions, all of the little widgets and stuff that you can now use on your iPhone. [57:10]
-
-And you were able to use iOS extensions within a React native app. But the challenge was you had to write SWIFT code to be able to actually implement those. And so a independent developer named S has been working on building an MPM package that allows you to ship these custom widgets and extensions without needing to use Swift X code or extra js, which is so cool because he's basically had to like write a translation layer or a render that takes React UI code. [57:24]
-
-And converted to Swift UI code, which is not trivial because many have tried before him and failed. So this is a really cool project and like it's one of those things that's like kind of mind blowing. So kudos to him for making this. [57:55]
-
-## [Building fully native apps with EAS](https://blog.swmansion.com/building-fully-native-ios-apps-with-expo-eas-760b5480d7c5)
-
-**Mo:** Secondly, and I thought this was an interesting article to link to. On the expo blog, they publish an article about building fully native apps with EAS. So EAS is expo's application services. Typically, this is being used to build React native apps that are usually running on Expo, but actually a lesser known fact, and one that we've actually used on some of our apps is that you don't need to be on Expo and you don't even need to be on a React native app. [58:10]
-
-And so EAS is really great and it's become super mature and it's a really just good build tool for building mobile apps. And so people have started to use it in the wider mobile community rather than it just being a React native thing, which is quite cool to see. [58:39]
-
-## [React Native \\\<\\\> Imgui](https://x.com/tmikov/status/1979771014340047088)
-
-**Mo:** And lastly, this was something that Tzveton from the Hermes team in Meta actually, uh, published a week or so ago. [58:52]
-
-And this was actually something he linked me on a DM because we were chatting about interesting things that could be talked about at a conference by a Hermes team. And this was quite cool to see. So for those who don't know, Imgui is like a very light UI layer that is powering a lot of sort of debugging for video games. [59:00]
-
-And it's used in a bunch of other places, but like the key thing is that it's just like a very, very lightweight UI layer. And so he made a puck of basically using React and then rendering it on Imgui, which is quite cool. And it runs obviously like fully natively. It's fully running on c plus plus. And all it really needed was some typed JavaScript and it's basically just React really, which is quite cool. [59:18]
-
-So yeah, it's just a little cool fun POC, but it shows the power of using React and how it can be applied to different contexts, which I thought was quite cool to include. [59:43]
-
-## [Lodash maintenance foundation](https://blog.ulisesgascon.com/the-future-of-lodash)
-
-**Mark:** Okay, Lodash has powered much of the JavaScript ecosystem for years. Those of us who have been around for a while, remember its predecessor, but low, has also been relatively unmaintained for a while. [59:53]
-
-The author John David Dalton, said there was going to be a low dash version five, and then that never really happened, and so some announcements came out in the last week or two. That low dash is being taken over by a new maintenance foundation, and they're going to be doing work to update the ci, put out some new maintenance releases, and then apparently when low dash V five happens, it'll be more about stripping out a lot of the internals that tried to polyfill platform behavior and try and make it lighter and make use of platform built-ins at this point. [01:00:05]
-
-So Lodash is still around, it ain't going anywhere, and good to see it being maintained. [01:00:40]
-
-## [Build Your Own Key-Value Database](https://www.nan.fyi/database)
-
-**Mark:** And then there was a really good post unrelated to React, but cool on building your own key value database system that walks through a whole bunch of pieces on what a key value database actually has to track and how the internals would work. [01:00:45]
-
-And I believe it's actually pretty interactive, which is cool. [01:01:01]
-
-**Carl:** This build your own database post, I love, this is so good. I love when people rebuild foundational building blocks. And this is also something I've thought about a little bit because he talks about in a file, you know, if you need to store something, put it in a file. [01:01:04]
-
-And this is something I've thought about a little bit because I have been using SQL Light pretty extensively in my own work the last couple of years. And at the end of the day, sequel light is a file. So like when I realized that like most of the time. If I want to store something in a file, like I should just use sql, you put something in a file and then the file gets too big and you need to optimize it, and you need a better way to access it and like, oh, maybe I could use a more descriptive query language to get things out of it. [01:01:18]
-
-And like the end result is that you will recreate a shittier less performant version of SQLite that doesn't use sequel. And so, I don't know. I just like reading this that was very strongly on my mind and everyone should do SQLite if they start putting things in a file. 'cause it's just a file. [01:01:44]
-
-It's cool. I like it. [01:02:02]
-
-**Mark:** The SQL Light website even has a page that says why, why you should consider just using SQL L as your app's file format rather than inventing another new binary format from scratch. [01:02:03]
-
-**Carl:** A hundred percent. If you start right, if you start thinking I should put this in a binary format on disc, like no, stop it. Use SQLite. It's great. [01:02:16]
-
-## [Jared Palmer asking for GH PR suggestions](https://x.com/jaredpalmer/status/1979204222420664405) and giving [some technical details](https://x.com/jaredpalmer/status/1980619222918262842)
-
-**Mark:** Alright. Jared Palmer, the creator of the Formik Library, has had been at V at Vercel for years. He worked on turbo repo, v0. And he announced just a month or two ago he was leaving Vercel. He has then announced that he has joined Microsoft as a senior VP at GitHub. And the first thing he did was post on Twitter saying, how can we make the GitHub PR experience better? [01:02:24]
-
-And he got like eight or 900 replies, and he was pretty actively engaging with a lot of 'em. A lot of them were people asking for things like Stacked Diff support, so you could have multiple PR branches that depend on each other and be able to automatically update them. He actually came back even just a couple days later and gave some technical details that he had found after internal discussions on here were some previous prototypes of stacked diffs at GitHub and how, like how far they got and what the blockers were. [01:02:53]
-
-So I have no idea how long it'll take to roll out any of this stuff, but like he seems pretty serious about trying to improve the PR experience, whether it's paper cuts or new functionality and is trying to look into that stuff. So given that we all pretty much depend on the GitHub PR experience, I'm happy to see improvements. [01:03:25]
-
-**Carl:** Yep. Love that. Wow. This is very jargon heavy. [01:03:45]
-
-**Mark:** Yeah, I, I know, that's why I was happy to see it. Cool. [01:03:48]
-
-**Carl:** Sounds like a technical roadmap. [01:03:51]
-
-## [Node 25 with JSON.stringify improvements](https://nodejs.org/en/blog/release/v25.0.0)
-
-**Mark:** Couple other bits, node 25 is out and so another development line branch for node and the biggest thing there is they've updated the version of V eight and that includes those faster js ON string of FI improvements that we, we talked about a couple months ago. [01:03:54]
-
-So given how much everything depends on JSONs string offi, it's nice to see that being sped up. [01:04:09]
-
-## [Cloudflare vs Vercel CPU benchmarks and perf optimizations](https://blog.cloudflare.com/unpacking-cloudflare-workers-cpu-performance-benchmarks/)
-
-**Mark:** And speaking of more optimization work, I believe Theo put out a benchmark where he was comparing CloudFlare in Vercel in Building Next versus Vanilla versus a couple other things. And it pointed out places that both Vercel and CloudFlare were slow and CloudFlare jumped on this and they found a bunch of places in their system. [01:04:15]
-
-Where things could be optimized. They did a excellent blog post detailing some of the improvements. They also went in and they looked at next itself and they found a bunch of places where Next is doing like useless request copying like 1500 or 1700 request streams per request or something like that. [01:04:36]
-
-So basically everybody is getting faster as a result of this, which is a good thing. [01:04:57]
-
-**Mo:** CloudFlare folks are just doing some great work recently, especially with the whole like workers rebrand as well is really cool. [01:05:02]
-
-## [FF Interop Feature Request Rankings](https://interop-rank.jakearchibald.com/)
-
-**Mark:** So Interop is an attempt to get all the different browsers on the same page in terms of what features they're working on, especially around compatibility with each other each year. [01:05:07]
-
-And so this year the Firefox folks put up a rather nifty interactive suggestions thing where they list dozens, like 50 or a hundred different potential features or technical areas of emphasis that they could spend time on. And it's got a neat drag and drop interface where you can basically use that as a way to vote for which features do you want browser manufacturers to work on? [01:05:19]
-
-This year. [01:05:44]
-
-**Carl:** Love that. Yeah. They say they're gonna publish the final selection of proposals in February, so I'll, I'll keep an eye out on that, I guess. Cool. [01:05:45]
-
-## [Vjeux’s History of Prettier](https://blog.vjeux.com/2025/javascript/birth-of-prettier.html)
-
-**Carl:** Chris Chedeau, vjeux, he has been really prolific in the React ecosystem for many years. Was really influential in React becoming open source and was the original author of Prettier, which changed my professional experience significantly. He put out a blog post titled The Birth of Prettier earlier this month. I'd spent almost 10 years since Prettier was released. He says, which is wild. I like his introduction of this is the story of how the tabs first spaces Holy War ended, and yeah, it did. [01:05:53]
-
-I appreciate that. I actually just did a little DX PR for a code base. I maintain to make better use of prettier because somebody created a plugin to sort imports and like, yes, I love that. I hate sorting my imports and I hate when of my imports are not sorted. The introduction of automated formatting into the JavaScript ecosystem was, oh, what a, what a blessing. [01:06:23]
-
-Like what hours? The years of my life that have been saved from arguing over formatting is just really lovely and this is a great retrospective. Looking into just the whole process of how it came out. [01:06:46]
-
-**Mark:** There's some fascinating details in there. [01:06:58]
-
-**Carl:** Yeah, like one of the challenges of this that I remember in the moment a little bit, but like if you're gonna start formatting things, the format needs to be something relatively unobjectionable to the people who are evaluating whether they want to use it or not. Like, yeah, so, and then figuring out what options should be exposed, what is actually configurable, because if you make it too configurable, then it's not helpful. If it's too much manual thing, then it's not actually consistent enough to be valuable at its intended purpose. [01:07:00]
-
-So lots of really interesting details throughout here. Definitely recommend it. I always love a great technical white paper, a writeup of implementation, and this is, oh boy, is this that. It's great. [01:07:37]
-
-**Mark:** One of the most interesting bits I saw was he was talking about how they started rolling it out and like Prettier has some options, but they wanted to minimize them and he wanted everyone to basically agree on a single set of options. [01:07:49]
-
-And so he said the strategy I used to figure out how to make this work was lining up incentives so that it took a ton more work to use a different set of options if you wanted to. It said Prettier is either in this, in CI or in your IDE. So I made it so that they read them from different places with a different rollout schedule to make it harder to choose one or the other. [01:08:02]
-
-**Carl:** Oh, that's incredible. That's some good details. Reading this a little bit more is it's got lots of fun non-technical details that like they're not the engineering work, but they are absolutely essential for actually making a thing that is successful and sustainable and thriving. Like it also talks about money and like ongoing maintenance is a thing that you have to pay for. [01:08:24]
-
-You don't have to, I guess most open source does not, but if you don't, then it has its own challenges. So like not only is this a great technical writeup, but it's also a great, I don't know, like entrepreneurial writeup. [01:08:45]
-
-**Mark:** How do you do the, the real work to make stuff happen? [01:08:55]
-
-**Carl:** People talk about the difference between like senior and staff engineering being, the difference between junior and senior is how much English you're asked to write. And the difference between senior and staff is like how much non-technical things you're asked to account for. And so this is a phenomenal, I would say, staff engineer writeup. Like, this is how you take an idea and you make it an industry level impact project. Yeah. Great Writeup. [01:08:58]
-
-**Mark:** I can even point to a couple personal examples of how prettier has affected my work just within the last few days. [01:09:23]
-
-One is that I'm jumping between the Redux repo, which is two spaces, single quotes, no semicolons. The Immer repo, which is four spaces, double quotes, and I can't, and may, maybe no single semicolons, Replay.io repo, which is four spaces, double quotes, semicolons, and I don't think about any of that anymore. [01:09:28]
-
-And then also just yesterday, I was trying to tweak some of ER's exports and tried to put in an export type keyword, which I was pretty sure was a legit thing except that when I hit save, it didn't format. And I have learned that if it doesn't format, I have put in invalid syntax somewhere for a moment. [01:09:52]
-
-It was like, oh, export type must not be a valid TS keyword. And then I finally realized, oh wait, this is on prettier 1.19. That must predate that syntax being added to TypeScript. And so I had to update prettier, but like that's how much I have learned to lean on. You hit save and it formats and it's valid. [01:10:16]
-
-**Carl:** Yep, a hundred percent. I, I recognize that in myself as well. [01:10:37]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Okay. Let's wrap it up with some conferences. [01:10:41]
-
-## [React Native London](http://reactnativelondon.co.uk) Nov 13-14 London, UK
-
-**Mo:** Let's jump into it. So we've hinted a few times and I can now say that we've got Seth Webster's endorsement. So the executive director of the React Foundations talks about my conference. I'm very happy today. [01:10:43]
-
-We've been organizing this for the second year, so React Native London for anyone who's a React native enthusiast in London and beyond. We have people from Brazil and India last year, so that's like the furthest extent that we have people coming in from around the world. But if you are interested, we've got our conference on the 13th and 14th of November. [01:10:55]
-
-In Central London, we've got a beautiful venue, some great talks from Meta, Amazon, Microsoft, and just a bunch of community people from expo and independent app developers who are gonna come and give some really, really phenomenal talks. [01:11:14]
-
-## Use code \`TMIR10\` to get 10% off
-
-**Mo:** Use the code TMIR 10 and you should get a 10% discount on checking out, which will, if I'm doing my mental maths right, make the ticket price 330 ish pounds for a two day conference to be able to attend workshops and the conference day. [01:11:26]
-
-## [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
-
-**Carl:** Um, other ones we've got coming up are Wey Wey Web November 17th and 18th in Malaga, Spain. [01:11:42]
-
-## [React Summit](https://reactsummit.us/) Nov 18, 21 New York, NY, USA
-
-**Carl:** We've also got React Summit November 18th through 21st in New York. [01:11:49]
-
-**Mark:** There's JS Nation on the 17th. There's in-person React Summit in person on the 18th, and then they have an online day the next week. Okay. [01:11:54]
-
-**Carl:** Oh, oh, oh yes. [01:12:02]
-
-I see it's 18th and 20th, not through. Interesting. One day in person. One day online. Okay. Makes sense. [01:12:03]
-
-## [React Advanced](https://reactadvanced.com/) Nov 28, London, England
-
-**Carl:** There's also React Advanced November 28th, also [01:12:10]
-
-**Mark:** in London the day after Thanksgiving. Someone in England didn't think about that part. He, he, he, [01:12:13]
-
-**Carl:** yeah. It's not for Americans. [01:12:19]
-
-**Mo:** It's not just React Advance, it's also Tech Lead Conf, which is also organized by the Ation folks on the same day in London as well. So, no, I would doubt that there's gonna be a lot of people from the states there, unfortunately. [01:12:21]
-
-**Carl:** For sure. [01:12:32]
-
-## [React Paris](https://react.paris/) CFP is open
-
-**Carl:** Well, I'll, I'll also add, I just saw like two days ago, the organizer of React Paris posted in the events channel here that CFP is open, so we gotta React Paris if you want to submit a talk. But that's gonna be in like March though, so not anytime soon. [01:12:33]
-
-## Ending
-
-**Carl:** That's all we got. Thanks so much for sticking around for a whole 90 minutes. [01:12:49]
-
-**Mark:** It was a very busy month. Okay. [01:12:53]
-
-**Carl:** Yeah. We'll be back next month, on the last Wednesday here in the live stage or back in your podcast feed just as soon as we can. Yeah. Thanks so much. Well, normally we gather sources from a variety of newsletters. We actually had so many things that Mark shared in the tech reads and news chat this month that I don't think any of us did. So that's cool. [01:12:55]
-
-**Mark:** And I pasted a lot more links in the discussion threads too. [01:13:15]
-
-**Carl:** That's something I should be better about. That would be lovely and helpful. But yeah, if you see anything newsworthy, definitely let us know in the Tech News and Reads channel, just like Mark has been doing. [01:13:18]
-
-You can also email us at hello@reactiveflex.com. But you know it's a community like Join, participate. I do read every email though, so if you send something I, I will read it. If this is a show that you get value from and want to support, best way to do so is by submitting a review wherever you listen and by telling your friends and coworkers about it. [01:13:27]
-
-And go to a meetup and say, Hey, there's this great podcast I love. [01:13:44]
-
-Cheers. See you next month. [01:13:47]
diff --git a/src/transcripts/tmir-2025-11.md b/src/transcripts/tmir-2025-11.md
deleted file mode 100644
index 5e43208..0000000
--- a/src/transcripts/tmir-2025-11.md
+++ /dev/null
@@ -1,589 +0,0 @@
----
-title: "TMiR 2025-11: Cloudflare outage, ongoing npm hacks, React Router is getting RSCs"
-date: 2025-11-26
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down 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:13](#intro)] Intro
-- [[01:00](#new-releases)] New releases
- - [[01:04](#betterauth-14)] [BetterAuth 1.4](https://www.better-auth.com/blog/1-4)
- - [[02:47](#immer-11-rtk-211)] [Immer 11](https://github.com/immerjs/immer/releases/tag/v11.0.0), [RTK 2.11](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.11.0)
- - [[06:00](#storybook-10)] [Storybook 10](https://storybook.js.org/blog/storybook-10/)
- - [[06:22](#01-version-of-remix-teams-event-interaction-package)] [0.1 version of Remix team’s “event interaction” package](https://github.com/remix-run/remix/tree/main/packages/interaction)
-- [[08:04](#main-content)] Main content
- - [[08:08](#ecosystem-panel-discussion-of-react-foundation-at-react-summit-ny)] [Ecosystem panel](https://gitnation.com/contents/panel-discussion-the-future-of-react-and-its-ecosystem) discussion of React Foundation at React Summit NY
- - [[14:46](#react-concurrent-stores-polyfill-react-redux-poc)] React Concurrent Stores: [Polyfill](https://github.com/thejustinwalsh/react-concurrent-store), [React-Redux POC](https://github.com/reduxjs/react-redux/pull/2263)
- - [[17:52](#react-router-and-transition-usage)] React Router and transition usage
- - [[18:08](#matt-brophy-and-ricky-discussing-nuances-of-behavior-use-with-react-router)] [Matt Brophy and Ricky discussing nuances of behavior, use with React Router](https://github.com/reactwg/async-react/discussions/5)
- - [[22:53](#the-state-of-tanstack-two-years-of-full-time-oss)] [The State of TanStack, Two Years of Full-Time OSS](https://tanstack.com/blog/tanstack-2-years)
- - [[25:57](#tanstack-db-05)] [TanStack DB 0.5](https://tanstack.com/blog/tanstack-db-0.5-query-driven-sync)
- - [[31:01](#tanner-teasing-a-wip-tanstack-start-rsc-implementation)] [Tanner teasing a WIP TanStack Start RSC implementation](https://x.com/tannerlinsley/status/1983999424486633931)
- - [[32:25](#state-of-the-web-ecosystem)] State of the web ecosystem
- - [[33:13](#cloudflare-november-outage-postmortem)] [Cloudflare November outage postmortem](https://blog.cloudflare.com/18-november-2025-outage/)
- - [[36:10](#what-if-people-dont-want-to-create-things)] ["What if people don't want to create things"](https://macwright.com/2025/10/21/what-if-they-dont-want-to.html)
- - [[39:39](#when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react)] [“When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”](https://webtechnology.news/when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react/)
- - [[45:53](#related-dead-framework-theory-from-last-month)] Related, [“Dead Framework Theory”](https://aifoc.us/dead-framework-theory/) from last month
- - [[48:12](#alex-russells-latest-stats-on-web-devices-and-network-budgets)] [Alex Russell’s latest stats on web devices and network budgets](https://infrequently.org/2025/11/performance-inequality-gap-2026/)
- - [[51:48](#npm-attack-shai-hulud-round-2)] Npm attack, [Shai-Hulud round 2](https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains)
- - [[52:06](#analysis-of-its-evolution-in-code-from-sept)] [Analysis of its evolution in code](https://www.aikido.dev/blog/bugs-in-shai-hulud-debugging-the-desert) from Sept
- - [[55:23](#our-plan-for-a-more-secure-npm-supply-chain-from-september)] [Our plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) from September
- - [[55:29](#npm-update-on-token-management-changes)] [NPM update on token management changes](https://github.blog/changelog/2025-11-05-npm-security-update-classic-token-creation-disabled-and-granular-token-changes/)
-- [[55:34](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[55:38](#ts-60-hopefully-feb-2026-70-native-soon-after-more-details-in-the-typescriptfm-podcast)] [TS 6.0 hopefully Feb 2026, 7.0 (native) soon after](https://bsky.app/profile/danr.bsky.social/post/3m5fz3vw2z22s) (more details in the [TypeScript.fm](https://share.transistor.fm/s/ad05eae6) podcast)
- - [[56:03](#latest-tc39-proposal-updates)] [Latest TC39 proposal updates](https://bsky.app/profile/robpalmer.bsky.social/post/3m62djhwj3k2i)
- - [[56:32](#chrome-and-other-browsers-wants-to-remove-xslt-from-the-web-platform)] [Chrome (and other browsers) wants to remove XSLT from the web platform](https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4gYZeSJA/m/yNs4EsD5AQAJ?pli=1)
- - [[57:14](#your-url-is-your-state-and-david-ks-goodbye-usestate-talk)] [“Your URL is Your State”](https://alfy.blog/2025/10/31/your-url-is-your-state.html), and [David K’s “Goodbye, useState” talk](https://gitnation.com/contents/goodbye-usestate)
- - [[57:46](#aiden-bais-react-grab-util)] [Aiden Bai’s “React Grab” util](https://www.react-grab.com/)
- - [[58:39](#creating-a-custom-node-module-loader-to-import-from-bittorrent)] [Creating a custom Node module loader to import from Bittorrent](https://evanhahn.com/node-torrent-import/)
- - [[59:22](#ryan-carniatos-stream-on-researching-async-signals)] [Ryan Carniato’s stream on researching “async signals”](https://www.youtube.com/watch?v=ori9xZhvNlc)
- - [[59:33](#details-of-building-nodes-ts-type-stripping-support)] [Details of building Node’s TS type stripping support](https://satanacchio.hashnode.dev/the-summer-i-shipped-type-stripping)
- - [[59:58](#the-web-animation-performance-tier-list)] [The Web Animation Performance Tier List](https://motion.dev/blog/web-animation-performance-tier-list)
-- [[01:00:14](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:00:22](#cfps)] CFPs
- - [[01:01:01](#react-paris-also-a-community-survey)] [React Paris](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform) ([Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform))
- - [[01:01:12](#jsworld-cfp-closes-dec-31-notifies-by-feb-1)] [JSWorld](https://docs.google.com/forms/d/e/1FAIpQLSfv3GuXwsDyR42XsvJwfFsN4SKjy8WvKtqYp_nEK0yhzVNP1g/viewform) CFP closes Dec 31, notifies by Feb 1
-- [[01:01:18](#ending)] Ending
-
-2-vcarl: Hello! Thank you for joining us for the November edition of this month in React. As we recap what's going on in the React, React native and web ecosystems, we're coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]
-
-## Intro
-
-2-vcarl: And I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux where I do community programs like these events and build tools to help keep the community operating. [00:00:13]
-
-1-acemarke: Hi, I'm Mark. My day job is working at Replay.io and doing various time travel debugging and information architecture things outside of that I, I work on Red Ducks. I complain about the React docs and I collect links and I go rewrite libraries, Limmer. [00:00:22]
-
-2-vcarl: Mo unfortunately could not join. He had a fire drill happen, a metaphorical fire drill, happen at work like an hour before we started. But generally we have Mo, who is head of mobile at Theodo and is very active in the React native community. Kind of sad that he had to skip out this month because he just did React Native London, and I was hoping to hear how that went. [00:00:39]
-
-## New releases
-
-2-vcarl: But yeah, let's get straight into it with some new releases. [00:01:00]
-
-## [BetterAuth 1.4](https://www.better-auth.com/blog/1-4)
-
-2-vcarl: First off, we've got better off 1.4. I actually use Better Off now. Woo. I had been excited about it for a while because I don't like authentication. Libraries generally like stuff like Passport or what, you know, even clerk or the SaaS businesses, just like none of them. [00:01:04]
-
-I didn't like them very much, so was very pleased to see an open source library that looked to cover many of the bases that I want and can confirm after using it that it does. So I'm excited to see Better Off 1.4, which is the first release since I believe July when it did 1.3. A couple of quick highlights from it. [00:01:20]
-
-It's got stateless off. So you can do sessions without a database just by not giving it one, which is nice. It's also got SCIM provisioning for identities in multi-domain scenarios, which is cool. Also, some other little details like database joins and custom state for OAuth flows. But yeah, just auth is a shockingly deep subject when you actually start dealing with the nitty gritty weirdnesses of it. [00:01:40]
-
-And I have generally found most open source projects trying to support authentication to be, to leave something to be desired and better off leaves the least to be desired of the projects. I've tried, so Love it. New version. [00:02:06]
-
-1-acemarke: I have thus far managed to stay away from dealing with auth at all in my career, and I would like to keep it that way. [00:02:20]
-
-2-vcarl: Yeah, that's not a bad call since I haven't been able to avoid it. I went a little bit deep on it and I don't hate that either. It's interesting. It's fascinating. Actually. I don't know, one of the vague. Startup ideas in the back of my brain is related to authentication and identity management, which could be cool. [00:02:28]
-
-I don't know, maybe I'll do something with that eventually. [00:02:44]
-
-## [Immer 11](https://github.com/immerjs/immer/releases/tag/v11.0.0), [RTK 2.11](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.11.0)
-
-2-vcarl: Mark, I want you to unveil your magnum opus. [00:02:47]
-
-1-acemarke: Happily. So I talked about this a bit last time, but Redux Toolkit relies on Immer for immutable state updates. It always has since day one. We've gotten various complaints over the years that, you know, Immer is kind of slow, but we've always said that we prefer the fact that it eliminates accidental mutations, makes reducers easier to write. [00:02:50]
-
-Of course, we want Redux toolkit to be fast, but we also want things to be correct and users to not have bugs. So I'd done a little bit of perf investigation into Immer like a year ago. Saw that it had gotten slower, filed an issue. You know, it was kind of left there. And at the start of September, I myself dug in and started trying to see if I could optimize ER's performance. [00:03:11]
-
-And I spent well over a hundred hours collectively across September and October, deep diving into ems, codebase, comparing it to other libraries, understanding how it worked, and trained to do a bunch of performance optimizations. And so ended up filing a few different prs, Immer 10.2, shipped last month with some small tweaks, and Michelle West Rate just merged a big architectural change and released it as Immer version 11 just a couple days ago. [00:03:34]
-
-And then I was able to put out RTK two point 11, which picks that up. So free performance wins for Redux Toolkit and Nier. [00:04:04]
-
-2-vcarl: Heck yeah. That was what was the average speed up? [00:04:13]
-
-1-acemarke: The current builds average about 20 to 25% across all the different benchmarks, varying by scenario. And then there's another outstanding pr, which adds an optional array methods override plugin, which drastically speeds up array methods. [00:04:16]
-
-2-vcarl: Heck yeah. That's awesome. We love a core performance improvement and I, I wanna shout out the ecosystem performance. You know, I don't know, [00:04:34]
-
-1-acemarke: E 18 E folks are awesome. They have been doing a ton of work to clean up large dependency trees and slim down packages and remove dependencies across a wide variety of tools. [00:04:43]
-
-Yep. [00:04:56]
-
-2-vcarl: A stat that I believe we'll talk about later, I saw in general ecosystem commentary. Yeah. I guess in the NPM supply chain fact that we'll talk about later, a a a stat that came out of a blog post from that was that the average JavaScript project pulls in 683, I believe in, was it transitive dependencies? Just like, yeah. It's a lot. So when you've got that many dependencies, performance of the ecosystem is challenging. Yeah. [00:04:56]
-
-1-acemarke: That doesn't surprise me. I know that. React app. The last I saw it defaulted to about 1500 dependencies, largely because of Webpack, et cetera. Vite's obviously a lot fewer, but still that's, that's not great, just for a whole variety of reasons. [00:05:21]
-
-2-vcarl: I guess teaser for y'all. Later, towards the end of the episode, we're gonna talk about web ecosystem and there's been some blog posts talking about like. AI and how it defaults to building React instead of using the web platform and how do we promote the web overreact, things like that, which I don't know, it just feels that we just started bleeding into that topic, and so we will get much more deeply into that later in the episode. [00:05:37]
-
-## [Storybook 10](https://storybook.js.org/blog/storybook-10/)
-
-1-acemarke: Next release. So Storybook 10 came out a few different big points there. One of the biggest is that it's now ESM only. They've removed all the, the common JS artifacts, so they've shrunk the install size and they've also drastically shrunk the dependency chains as well, as well as some improvements to things like the mocking and some of the storybook formats. [00:06:00]
-
-## [0.1 version of Remix team’s “event interaction” package](https://github.com/remix-run/remix/tree/main/packages/interaction)
-
-1-acemarke: And then one other release of note, the Remix folks are continuing to work on Remix V three after the initial demo and announcements, and they're trying to build it, as I understand it, with a lot of smaller reusable packages. And they just put out the first 0.1 alpha of their. Event interaction package, which is providing an abstraction for being able to compose events and listeners and behaviors together looks interesting. [00:06:22]
-
-I'm not gonna claim I understand like exactly the benefits this comes, but nice to see the progress there and I suspect that a lot of folks are gonna get some use outta this. [00:06:49]
-
-2-vcarl: Yeah, I'm reading the syntax here and it looks like a different way of adding event listeners to DOM nodes, which, sure. I don't know, there's weird quirks and certainly the Remix team and you know, Michael Jackson and Ryan Florence specifically have shown, have demonstrated a great willingness to jump into what many people consider solved problems to reexamine from first principles. [00:07:00]
-
-So, I dunno, they've, they've done that, they've done that repeatedly with their own solved problems of data loading in routing. The interaction between data loading and routing. I feel like that's one of the bigger complaints about React router is that they keep reexamining that same question. So I don't know. [00:07:25]
-
-It's interesting that they do have interesting things to say when I've seen them reexamine, quote unquote solved problems. So I'll, I'm curious. This looks a little strange. It looks pretty divorced from the DOM structure, so if you just like on input element and then add a bunch of listeners for it, that's curious. [00:07:41]
-
-Anyway. Yeah. 0.1 release, we'll see what they come out with. [00:08:00]
-
-## Main content
-
-2-vcarl: Okay. That's all the new releases we got so far. Let's go into some main content. [00:08:04]
-
-## [Ecosystem panel](https://gitnation.com/contents/panel-discussion-the-future-of-react-and-its-ecosystem) discussion of React Foundation at React Summit NY
-
-2-vcarl: First off, we want to talk a bit about, yeah, mark, you are on an ecosystem panel at React Summit this month. [00:08:08]
-
-1-acemarke: So let's see. Addie has money was moderating. We had Seth Webster from the React team, React Foundation, Shaundai Person, Amy Ner, Nicholas Gallagher, and myself. [00:08:15]
-
-A lot of the discussion was us asking Seth Webster questions about, so this React Foundation thing, like how is this actually gonna work? What does this actually mean for the React team and the project and the ecosystem? There is a video for the panel. It's not unlocked yet. I have access to it because I speak at GI Nation events, but the video should unlock within a couple weeks, I think a a few different points that Seth made during the panel itself. [00:08:25]
-
-And then I had a chance to have a follow-up discussion with him afterwards and. There's a few different very interesting p pieces of news about how the foundation's going to work and what their plans are. He talked a bit about some of the, the funding process. So, you know, large companies pay, you know, a good chunk of money to be members. [00:08:55]
-
-The, the existing. Board member companies have already paid up for like three to five years, and it sounds like he'd actually been working on putting the foundation together for over four years. Like this was a very long term kind of a process. [00:09:16]
-
-And they're hoping to do a number of different things with the money. They want to hire some additional engineers. And he even said some of that would be spent on having engineers triage the issues. And if you've ever looked at the React repo, you know, that's a thing that they do not do very often. So even something like that sounds good. They want to hire some more people to work on the actual docs and they're hoping to give money out to communities in some way. [00:09:31]
-
-Don't know details on that, but [00:10:00]
-
-2-vcarl: Tell me more! [00:10:02]
-
-1-acemarke: Exactly. Another data point. So a lot of the plans have to do with the development process of the React project itself and transparency around that. Apparently they were even hoping to launch the foundation like a year and a half ago. And then they realized that like, "our own in day-to-day development processes aren't ready for that. We need to dog food the processes ourselves first so that we're more ready when the foundation goes live." [00:10:03]
-
-And so some of that was actually having docs and plans as new features are being developed or treating things in kind of like a, you know, TC 39 staged process. Approach, but one of the biggest things that Seth told me directly was that up until now, the React team has had, you know, their, like their weekly status meetings and those are purely internal. [00:10:36]
-
-First off, it was just all the React team working at Meta and then it was, you know, meta plus versal. But those meetings have always been internal, private, and non-visible. And Seth said that they eventually want to literally open up the weekly React team planning meetings to the public even as like a, like a Zoom call with no password. [00:11:00]
-
-And that eventually, like designated community reps would even be able to actively participate. In those discussions. So that's a radical change in the development of React itself. He also said that they're planning to resurrect or like completely redo the RFC process, which frankly was kind of dead from the beginning. [00:11:24]
-
-It was where random people from the community posted ideas that got ignored and the React team posted, finished things that they planned to ship and then people argued over the naming and the React team ignored that. So like historically, the RFC process was pretty much irrelevant to actual React development. [00:11:46]
-
-Now they're talking about making it like a real meaningful discussion and part of the planning process. Now again, like do I know how this is gonna work out in practice? No. But I can see the amount of effort and the intent. Behind the foundation and the plans that they're talking about. And even if it doesn't end up going exactly as they, or we would hope, I see good faith and good intentions behind all the work that they're trying to do around the process here. [00:12:04]
-
-So I'm actually very, very excited about this. [00:12:36]
-
-2-vcarl: Yeah, that's interesting. Oh, I got a lot of thoughts rattling around my head. 'cause that's a lot of stuff that I've looked at trying to contribute towards the solution of, yeah, I don't know. It's, I fundamentally, I feel like the problem they're dealing with is that a lot of people care about the outcome, the output, what they make and what React is. And not a lot of people actually have like the context and the background to like meaningfully contribute to the advancement of that goal. [00:12:39]
-
-You know, to respond to what you just said about like their motivations and their what they want to do. I don't think that's ever really been the problem, they've always had good intent and I even think a pretty clear eye picture of what the problems are. But I think the problems are really thorny and complex and the solutions to them are non-obvious. And even when you have a good solution idea, executing it in a way that is effective and that operates on the kind of like timescales that React is around for is just really challenging. [00:13:08]
-
-Like it's, you know, anyone can spin up a process and run it twice and you know, maybe that, like you do, you call for comments and you run a community discussion and round tables and whatever, but like that plays out over the timescale of like weeks and months and React seems to plan on the order of years and is, now has existed for a decade. [00:13:42]
-
-So, you know, with like there's possibility for its scope to expand from thinking in terms of years to thinking in terms of, I don't wanna say decades, but that's the next unit of time. That's the next order of magnitude. I hope they can achieve their goals. I am looking forward to seeing some more roadmap, transparency of some sort. [00:14:05]
-
-Actually that'll be really great for us, for you and I. That'll be great. Yep. That'll be a great source of signal that we can then pick apart and analyze to surely, to much to their chagrin by way of drawing attention to things that are high context [00:14:23]
-
-1-acemarke: as opposed to like stalking the open PRs list. [00:14:40]
-
-2-vcarl: Yeah. Right. Cool. Nice. Love that. [00:14:43]
-
-## React Concurrent Stores: [Polyfill](https://github.com/thejustinwalsh/react-concurrent-store), [React-Redux POC](https://github.com/reduxjs/react-redux/pull/2263)
-
-1-acemarke: So on that note, another item that I've personally been involved in is the work on the upcoming React Concurrent Stores API. So when React 18 came out, the React team included the Uyc external store hook as the official built-in way for third party libraries like Redux, Zein, Jo Tai, whatever else to integrate into React, take an external state update, turn it into a React re-render, and it worked. [00:14:46]
-
-But it also had a very intentional design limitation that if you do an update in the middle of a paused React render, you know, something transition like then it bails out of that and just does a complete top to bottom render. So you're kind of throwing away some of the benefits of React, being able to pause itself. [00:15:13]
-
-And that was because they, they really didn't have a better idea for how to do that kind of interop. So this concurrent store's API is supposed to be essentially a new equivalent to use sync external store, but concurrent transition compatible. And Jordan Eldridge, who's on the relay team, has been working on the design and initial prototype IMP implementation for this. [00:15:32]
-
-And so he put out a polyfill package that roughly implements the prototype as a standalone library. And then I've been talking with him about, you know, here's what Redux would probably need to make this work. Here's our, our requirements for this. And so I was able to then take his proof of concept package and put up a draft PR for React Redux that just swapped out our used selector implementation to use that instead. [00:15:57]
-
-And it basically worked, I mean, just the one test file found a couple edge cases, but like most of our tests passed, we're not doing anything transition related in our tests. But it's good to know that like your baseline standard behavior works. [00:16:25]
-
-And this also turned up several more things we'll have to figure out, like, quality checks and how do you handle selectors throwing errors, and we're talking about when can React safely, call selectors, can it delay it due to batching and things like that. So also very excited to see the progress being made on this API. A lot of people have asked for external state transition compatibility, and so this is going to be a big deal for the ecosystem. [00:16:39]
-
-2-vcarl: Interesting. Cool. I'm just trying to put this in a little bit of context for myself. So this is a, an exploration of an API for a concurrent store that they've indicated intent to ship eventually. Is that right? Mm-hmm. [00:17:08]
-
-1-acemarke: Yeah. So basically a, a new equivalent of `useSyncExternalStore`, but minus the sync restriction. [00:17:22]
-
-2-vcarl: Got it. Okay, cool. Interesting. You called it a poly fill, and I see in the blog post it's labeled a pony fill, which I had to refresh my memory on the distinction; a poly fill fills in a gap in the platform transparently, and a pony fill offers the same functionality, but as a standalone module that you have to import. [00:17:30]
-
-There you go. Now you know. [00:17:50]
-
-## React Router and transition usage
-
-1-acemarke: So one more item kind of related to that. At React Conf, Ricky Hanlon announced a new Async React Working Group to provide support to the, you know, the community and the ecosystem on, you know, improving the React docs around async behavior, helping libraries get set up to use these methods. [00:17:52]
-
-## [Matt Brophy and Ricky discussing nuances of behavior, use with React Router](https://github.com/reactwg/async-react/discussions/5)
-
-1-acemarke: And so Matt Brophy from the React router team had a good discussion with Ricky about how they're trying to handle using transitions in React router. So there was a, a good technical discussion about the nuances of behavior. And then the React router team also put out a pre-release version or unstable option to enable some of the transition behavior as well. [00:18:08]
-
-So starting to see some adoption and this ties into the React team wanting to see libraries pick up these behaviors like transitions and action props and, and build them in. I will say that I had a couple discussions at JS Nation React Summit where some people were questioning whether making the entire ecosystem change semantics and behaviors and add props to make the React team happy was gonna be a good idea or feasible, but we'll see. [00:18:33]
-
-2-vcarl: Yeah, interesting. I see a bit of why they, why the core team desires that. Transitions are definitely like. My understanding of the core team's incentives and what they care about is ability to use the platform and things like that. So given that like transitions are a part of the platform and they are interested in allowing people to take advantage of platform improvements, I understand why they would message, "in order to use this, the entire ecosystem must make this change to the patterns they use for compatibility reasons." [00:19:03]
-
-But that is very, I don't know. That's a big challenge. It's herding a lot of cats who don't necessarily, aren't even necessarily aware that there's an attempt to herd being made. [00:19:38]
-
-1-acemarke: If you watch Ricky's talk from React conf, you know, he, he demoed switching from like a bunch of manual use effects and loading states to suspense and transitions and then he pointed out, and so now you have a much better experience, but you also had to do, you know, call start transition and all your click handlers and so on. [00:19:49]
-
-There's even some painful nuances there because start transition is based on setting a flag internally for the current event loop tick. If you have a callback that has an await, you leave the event loop tick. And if you then want to do another state update after the await, you have to call start transition a second nested time. [00:20:05]
-
-And Ryan Carniato actually pointed out to me that like Ricky has repeatedly messed this up in his own demos, it's a very foot gun prone behavior pattern. And so the combination of, like, you currently have to call, start transition yourself, plus trying to get the patterns right, is a good argument for let's just build this into all the libraries. [00:20:29]
-
-But that takes time and effort and coordination. [00:20:53]
-
-2-vcarl: Yeah. Right. Like that was one of my big takeaways from Ricky's talk was, oh, this looks hard. Which is not the best takeaway if you're trying to convince the whole ecosystem to move on to something. [00:20:56]
-
-1-acemarke: There is a lot of complexity in mental model of React and the kinds of apps we're trying to build. [00:21:08]
-
-And both the fact that you now need to keep track of additional API methods that you have to call and the semantics and when you're supposed to use them. And the fact that your, your state is now kind of in multiple Schrodinger's box, multiple versions at once. It's, it's definitely a lot of additional mental overhead. [00:21:15]
-
-2-vcarl: Yeah, right. I'm just looking at, in this GitHub thread that you linked, Ricky says, you know, oh, I think there might have been some confusion. Here's how you do it for navigations and it's, you know, function, navigate to A URL that has start transition, which, you know, wraps set router state, which then wrap, you know, it's argument is a function that I guess returns A URL. It's a thunk for set router state in start transition, in navigate. I don't know, they're like, that's just complicated. Like what? Why are we wrapping this with so many different functions just to navigate? That's uncomfortable. It feels like the wrong API in some way. You know, like it an API should obscure complexity and this does not obscure the complexity. [00:21:35]
-
-So, interesting. I want to be able to take advantage of transitions in apps. 'cause that's super great if you can just like easily convey that you are here and you're about to go here. Instead of just going there, like you get a lot of really powerful things that you can do for user experience and, you know, whatever, all sorts of stuff, if you communicate the transition instead of just updating the current state of your app. [00:22:17]
-
-But yeah, I don't, I, I'm not sold on this. I'm not sold on one I'm seeing so far. [00:22:43]
-
-1-acemarke: Okay. Moving on to the next related chunk of topic. [00:22:48]
-
-## [The State of TanStack, Two Years of Full-Time OSS](https://tanstack.com/blog/tanstack-2-years)
-
-1-acemarke: The Tan Stack folks have a bunch of updates that they've put out both blog posts and versions. So Tanner put out an article on the state of Tan Stack as an organization and his own work as a full-time open source maintainer for the last couple years. [00:22:53]
-
-Also, again heard, you know, heard some of this from, from him directly at a React summit loosely. He himself has been full-time supported open source for the last couple years, sponsorships to the TN stack org. Tan Stack Libraries are, you know, as we all know, very, very widely adopted and certainly query is the standard Fritz thing at this point. [00:23:13]
-
-Router and is picking up a lot, A lot of popularity start is almost 1.0 and he's hoping to be able to start to bring in some part-time or even full-time. Uh. People to hand stack the company in the near future, essentially other. Current maintainers for various stand sand stack libraries who would then be able to potentially switch to doing that as their actual job. [00:23:34]
-
-So essentially he's been fortunate enough to have this work out for him and he's hoping to share that ability with other people working on the projects. [00:24:00]
-
-2-vcarl: Yeah, I see. He says monthly sponsorships for 12 core contributors and short term contracts for another three to five people. I guess that's not clear what monthly sponsorships means. [00:24:09]
-
-I, my assu, my assumption there would be like their, maybe not full time, but getting like sign, you know, significant compensation. But that may not necessarily be true. [00:24:20]
-
-1-acemarke: I don't know numbers, but I think at the moment the others are doing open source and they're full-time and getting some, some stipends and in the next couple years he's looking at actually hiring some of them. [00:24:30]
-
-2-vcarl: Cool. Love that. That's super hard. Building revenue so that you can actually support other humans is actually really challenging. I really like this blog post about, you know, Tan Stack for two years. I like this line. You know, building a full stack framework is hard. I knew that from watching other teams do it. [00:24:42]
-
-Most of them had something I didn't. Capital Next Gatsby Redwood Remix all had funding companies or acquisition paths and that that definitely is something that feels very different about Tans stack. It feels very much like he couldn't not do this. Like he just had spent several years working in this problem space and solving his own problems with the freedom to publish them so that other people can take advantage of his work. [00:24:56]
-
-And then got to a point where it just made sense to invest more effort and take those a little bit further than they could go. Absent that. Level of dedication I, which i, I love. That's just like, that's, I don't know, finding that kind of work to do for yourself is what I've been looking for. And it's really hard to find, and I love that Tanner Winsley has apparently found it. [00:25:20]
-
-Yeah. And also having 16 partners doing sponsorships is also great. Like that, that, that may not be capital, but that's, that's great. That's nice. Having tried to find sponsors myself, like getting 16, it's like, oh shit. Good job. That's awesome. [00:25:43]
-
-## [TanStack DB 0.5](https://tanstack.com/blog/tanstack-db-0.5-query-driven-sync)
-
-1-acemarke: Tan Stack DB is a new work in progress package largely being worked on by Kyle Matthews, formerly of Gatsby, currently of electric SQL, that is meant to be kind of like a half a sync engine layer on top of another data source. And so like one of the common usage patterns for that would be you wrap it on top of your 10 stack query, you know, API definitions. And so maybe you've got some endpoints for fetching. Post comments, users, et cetera. [00:25:57]
-
-But then it presents like a sync engine like interface on top of that, and it's got a bunch of data flow analysis baked in so that it can do things like partial fetches or only re fetching, you know, certain pieces of data, joining, essentially presenting like a normalized facade layer over the individual endpoints so that they act like they're unified almost as a like a replacement for a GraphQL style API. [00:26:27]
-
-And so they've been working on this and it has integrations with Tan Stack Query and then Electric SQL and a few other data packages. And Tanner pointed out to me at React Summit that it really just needs an adapter layer to be able to connect to another library. And I could totally build one for RTK query. [00:26:54]
-
-And so I was actually briefly playing with that on the flight home. I haven't had a chance to push it further, but I'm actually, I'm actually very excited to play with that more myself because like Tan Stack query, we made the decision to make RTK query non normalized. It just caches the response from the server. [00:27:12]
-
-And so if this essentially let us make a normalized layer on top of our own library without us having to make any further API changes. That's very interesting to me. [00:27:29]
-
-2-vcarl: I'm also thinking about, you know, this is from Kyle Matthews who did Gatsby, which, you know, notoriously exposed a GraphQL, you know, layer on top of whatever data sources you wanted to give it. [00:27:41]
-
-So just, I'm thinking about how, how much of Kyle Matthews work could be described as providing query abstractions over arbitrary data layers with data connectors. [00:27:54]
-
-1-acemarke: That's a good point. I, I had, I hadn't even drawn that connection that this is actually very related to his prior work. [00:28:05]
-
-2-vcarl: If you described this at a certain level of abstraction, this sounds just like GraphQL, Relay, Gatsby, a bunch of other stuff. But I do see the niche that it occupies and how it's distinct from those projects. It's kind of like GraphQL, except instead of the network boundary, it's like the component to data store boundary on your client app, which it, that's useful . [00:28:11]
-
-Like what you just said about how you don't normalize in RTK query, I've landed on that as being generally a good architectural decision to make in applications because like if you start doing data transformations, you know, bespoke data transformations per endpoint, then it becomes really hard to change those endpoints. [00:28:33]
-
-If you're changing the underlying data, then you've gotta change all the code at the same time. Whereas if you just take whatever the API gives you and then write like a transformer on top of that, then it's just you, you add a layer of abstraction for yourself that gives you a little bit more flexibility around timing of some types of changes. [00:28:53]
-
-So, yeah, I don't know. That's, it's interesting. This is an interesting project. I dunno, something about it feels like I don't quite know where I would take advantage of it for myself, but I could see the right app with the right kind of team operating it, finding this and being like, this is exactly what we need. This solves multiple challenging thorny problems that we have or, so yeah, I don't know. It's interesting. [00:29:17]
-
-1-acemarke: My own personal to-do list is massive at this point. Both like Redux and even just like personal life stuff. But I, I absolutely want to go back and, and play with my own RTK query integration prototype for that in the near future. [00:29:40]
-
-2-vcarl: Yeah, I generally love the idea of sync engines. One of my core beliefs about writing code is that many more applications that we use have no technical necessity to be online only. [00:29:52]
-
-Like, there are a lot of things, like, for example, my favorite canonical example of this is like Gmail. If you're using the Gmail app. It doesn't actually care if you're online because it is doing synchronization of your emails in the background. And so you can just interact with it normally while you're fully offline and later it will do all the things like synchronize the read states or like, you know, which emails you've archived and deleted and yada, yada yada. Completely transparently. Like I have never thought about, oh, I should wait to do this later when I'm online so I don't cause weird problems for myself. And I do think about that all the fucking time in various other apps that I use. So like there, that's something that we used to do that we no longer do because it's hard. [00:30:06]
-
-I love seeing more effort and energy being expended into making it easier to do offline things. And sync engines are a big part of that. And so abstractions, over sync engines are also a part of that. Great. [00:30:45]
-
-## [Tanner teasing a WIP TanStack Start RSC implementation](https://x.com/tannerlinsley/status/1983999424486633931)
-
-1-acemarke: The Tan Stack router folks also put out a really good blog post talking about how they did some massive optimization on route matching, including using a somewhat lesser known data structure called, I think it's pronounced a try, T R I E. [00:31:01]
-
-I love I I love seeing optimization breakdowns. So good article there. And then since we've done plenty of, you know, stuff being teased on Twitter discussion in the past with Remix and everything else, Tanner has been teasing that they are working on RSC support for Tan Techstar. And I can say that he showed me a demo and it's unconventional. [00:31:13]
-
-It is not what you would expect after having used Next, and yet it totally makes sense in its own way once you see it. So as I understand it, they've made real progress on implementing it. They've figured out the design and now it's push it forward and make it actually a thing. I have no idea how soon this will be revealed, but I think once this comes out, it will be a very interesting, challenging take on our understanding of server components and how they, how to use them. [00:31:36]
-
-2-vcarl: I would certainly say that the way Next has done it does not seem to be like the end all, be all of great implementation. So if they have found a new way to approach it, hell yeah here for it. That's awesome. [00:32:10]
-
-1-acemarke: So there, there's your vague tweet for the month. [00:32:21]
-
-2-vcarl: Yeah. Right. [00:32:24]
-
-## State of the web ecosystem
-
-2-vcarl: Let's talk a little more broadly. Let's talk about the state of the web ecosystem, I guess like to intro our subtopics under state of the web ecosystem. I wanna talk a bit about like the CloudFlare outage, the NPM ongoing attacks. Like this is not a new attack, this is a continuation of the previous attacks, plural, that we've discussed, as well as Alex Russell had a decent blog post. I say decent because I don't know, it's it qualified, decent it, it's well written, it's well argued, but I don't necessarily agree with his conclusions. And also there, there's some conversation about reacts place in the ecosystem and AI and things like that. So that's the shape of this state of the web ecosystem chat that I want to start or that I want to have, I guess. [00:32:25]
-
-## [Cloudflare November outage postmortem](https://blog.cloudflare.com/18-november-2025-outage/)
-
-2-vcarl: Yeah let's start at CloudFlare. They had an outage on the, earlier this month, about a week ago, 18th of November. They say in their outage postmortem that it was triggered by a change to the permission system of one of the databases, which caused it to output entries ba- basically, it produced too large of a file that then got distributed out and the size of that larger file getting distributed caused performance load that took down the network. [00:33:13]
-
-1-acemarke: Check me this. Another factor on it was they, one of the services was written in rust and it had an expectation that the file would only be so big and there was, I think there was a rust line of code that basically said if it doesn't fit, panic. Yeah. That a bad file with like they had 60 features, a limit of 200 and a line of code that basically said if it gets over 200, throw, throw an error or kill the service. [00:33:40]
-
-2-vcarl: Yeah, that'll do it. Yeah. "Each module ran on the proxy service has a number of limits to avoid unbounded memory consumption." Somewhat questioned the wisdom of that because the reason you would have limits on memory consumption in place would be to avoid outage and downtime. And so if your resolution to, the outcome of your limit, if memory usage gets too high is to crash, that is functionally very similar to an out of memory error. [00:34:08]
-
-Maybe it's, I guess it's easier to debug, I guess you can, out of memory errors cause crazy, unpredictable failures, I guess. So at least this is a predictable failure that strongly indicates where the, the excessive memory use is coming from. [00:34:36]
-
-But yeah, it, it was pretty serious. I actually didn't notice, which I'm glad about. It's nice to not be so online that you don't immediately notice every, I don't know, every outage, but yeah. This kind of, I think this was a, a, a good demonstration of the place in the ecosystem that CloudFlare occupies and how many different services truly rely on its stable operations. Yeah. [00:34:49]
-
-1-acemarke: Trying to make the trade-offs between the web is decentralized. Anyone can run their own thing versus, Hey, look, there's benefits to having centralization. Let's all put our GitHub, or let's, let's all put our git repositories on the same service so we can, you know, log in and share them and comment back and forth. [00:35:11]
-
-Let's put all our social media comments on the same service. We can have commentary back and forth. Let's all use this widely spread CDN and DDoS protection service that also has a bunch of really cool backend services. And then when one of those big services goes down, it ends up having, or everybody put everything in AW, AWS East one. [00:35:29]
-
-2-vcarl: Yeah. Right, right. Yeah. Right. Or, [00:35:50]
-
-1-acemarke: or even like we, we put it in AWS East two, but AWS themselves relied on AWS East one, and then it goes down. We keep burning into these big dependencies that end up having massive effects on the internet when they go down. [00:35:52]
-
-2-vcarl: This feels like a good transition point to a link that we had slightly later down. [00:36:06]
-
-## ["What if people don't want to create things"](https://macwright.com/2025/10/21/what-if-they-dont-want-to.html)
-
-2-vcarl: Tom McRight, who is not a name I recognize, put out a blog post called What If People Don't Want to Create Things? And that feels like what you're talking about, like the ideals of the web is decentralized, you know, their own domain, right? Sharing knowledge, sharing skills, sharing tools, and I love that. I agree with that. I aspire to those ideals. [00:36:10]
-
-But it's also true that like we kind of just want stuff to work. We want it to just kind of be stable and you know, what's not stable, decentralized things that have a smattering of volunteers maintaining it. That's kind of the distinction. Like that's kind of the trade off is like over time decentralized things with enthusiastic maintainers and open source, over time that stabilizes and grows and becomes great in a way that proprietary code can't, because you know, you can't inspect it, you can't say like, I'm encountering this bug. Let me go look at the code. Oh, here's where it's coming from. Let me tell them about it and give them a reproduction. And contribute to a fix. Like if I encounter a problem like that in any of these many proprietary tools that I use, then there's just no path for me to do that, so. [00:36:33]
-
-But on the other hand, they have the capital and the employees to have people proactively looking for that, where it's their job. That's the tension. I tend to believe over a long enough time scale that distributed, decentralized things like the web will be better than anything that's like proprietarily developed. [00:37:25]
-
-But it has to work well enough to get the attention. And you know, in this attention economy we're in, it's very hard to get people who have enough bandwidth of their attention to say, "I have found this problem, let me chase it down to its logical conclusion and contribute to a fix being actually shipped for me and people like me." [00:37:47]
-
-1-acemarke: We aren't gonna go off on this, but I can even see some tangential connections with things like open source as a concept, open source maintainer, burnout. Like most people like using an app or a library or even even developers using a library, like in the end, do they actually care that it's open source? [00:38:05]
-
-No, they just want to download the thing and have it work, whether it's Libre office or you know, a paint, you know, paint program or Better Auth or whatever. And the fact that the code's open doesn't matter. It's like I, as the consumer of this thing at this level, just want it to work. And if it doesn't, I ask the person who builds it, just make it work. [00:38:23]
-
-2-vcarl: Right. I'll call out a couple of quotes from here. "Beautiful data visualizations are free to make, but the supply of people who really love and know D3 is a lot lower than I expected it would be. I love home-cooked apps and malleable software, but I have a gnawing feeling that I'm in a bubble when I think about them. Most people's lives are split into the things that they affect and create and the things that already exist and wanna tune out and automate." [00:38:46]
-
-I think that's a, I think that's insightful. I think that speaks to a deep, I don't know, tension in this. Like, yes, AI lets you do a much larger range in a much shorter time span than used to be feasible. But do people want to do that? I don't know. [00:39:07]
-
-Given the, given a range of infinite possibilities, how do you pick which one that you are going to do and then give it the attention so that it actually produces something that other people can benefit from. How do you find the things that you want to build on top of, you know? [00:39:24]
-
-## [“When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”](https://webtechnology.news/when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react/)
-
-2-vcarl: Well, I guess I'll transition from that, from that comment to this other post. "When everyone's a developer, how do we promote the web platform over react?" It's in reference to this Alex Russell Post that I'll, I'll, I'll share after. But I guess it's talking about, it's talking about that like when people can make their own software, when they can just use plain English to ask AI to generate code that in one form or another, solves the problem. [00:39:39]
-
-They stated, you know, maybe not the way they intended, maybe not the way they wanted, but it. It's doing its best, just like all of us. It's talking about how if you just ask it to make something, it's probably gonna use React, because that's what, by volume of text, by volume of code that it's trained on. That's what, that's the mode. That's the most common example. [00:40:03]
-
-I guess, like this is framed as a, an AI problem, like why does AI do this? But this is actually the same problem that I've observed well before AI came out, you know, 2022 or when everyone chat GPT really started, I have observed all of these problems that it's talking about over the life of my career. [00:40:20]
-
-Like, you know, especially I feel like, you know, there's a certain golden age of tech between 2018 and, I dunno, 2021 or so, and that was absolutely the case. Like I would, you know, join a new workplace, because I did that a lot, I worked at a lot of different companies and I'd look at the practices people were using. It's like, why did you use React for this? Like there's, here's a platform feature that solves this more easily. And with less code. And a lot of the time people just didn't know it existed. Like it's that attention problem. How do you know what you should build on top of? [00:40:38]
-
-I don't know. It's the solutions here that people are talking about is like, what can we, the web community do to promote web platform features over react code and it proposes teach vibe coders to explicitly prompt for web native solutions, get the LLMs to ingest more web platform code, spotlight teams and projects that ship modern web experiences without heavy frameworks. [00:41:11]
-
-I mean, like that's, to me, all of those essentially just like how do you make the web platform more popular? To me, ai, it fundamentally spits out an average. It spits out like, you ask it to do something and it will give you a deeply profoundly average result for, you know, if you asked a thousand people, that question here is approximately what the mass of those people would say. And it's true that if you asked a thousand developers to do something on the web, the most common output would probably be a kind of shitty implementation with React that overused things like use state news effect because that's what developers did and do. So I don't know, it's like a lot of these questions that we ask ourselves about AI and code, I feel like distill down to the same kinds of questions we were asking before. [00:41:33]
-
-But like now there's a boogeyman of ai, like this is ai, this is this, this is code, this is a product people have built. And so it is now a very convenient boogeyman, but it, it's a distillation of the thoughts of a vast number of people as codified by what they published and what was ingested for the training set. [00:42:26]
-
-1-acemarke: I just tossed in a link to the obligatory XKCD from like a decade ago, which is the, the one of the points out that sometimes your, your map or your heat map of users is actually just a heat map of the population. It's a one-to-one correspondence. And so I think that that is partly what we see with like React usage. [00:42:46]
-
-You know, there, there's a lot of people. Who use React. There's a lot of people who use React badly and therefore, like the spread of types of usage of React, the quality of usage of React kind of maps to the quality of programmer skills and backgrounds, like not necessarily an excuse. And that's not to say that like everything about using React is is good by itself, but just that when you have a full cross spectrum of the population using a thing, you're going to have the full cross spectrum of the population using it in good and bad ways. [00:43:07]
-
-And so in the same way when it like, when it comes to, you know, people building apps, re React got popular, when LLMs came out and saw that was re React was popular. So LLMs repeat what they were trained to do, and plus it's also, you know, like not just popular, but it's especially popular within Silicon Valley, within all the companies making the AI builder tools, et cetera. So in a lot of cases, they're prompting them to just use React because they assume it's the default that you would use anyway. [00:43:45]
-
-2-vcarl: I, I wanna shout out a term that I love, "path dependence," which is like, where you're at right now is the outcome of a series of choices that were made in the past, and those past choices constrain what paths are available moving forward. That's path dependence. Where you came from affects where you can go. [00:44:13]
-
-And so I guess like to me that this is a complaint about the path dependence of React. Like because React got popular now React is, we've worn that rut and so now it's hard to get out of that rut even if there is a better alternative. [00:44:35]
-
-And so I would say like the solution there isn't like, I don't know, tell people they're bad at things. The solution is to like make better resources so that a different path becomes the easiest one to take. En masse, you know, writ large, when, you know, it's one thing to convince 15 people that this is the best solution and it's correct. [00:44:51]
-
-And it's another to make the argument clearly enough, strongly enough, and consistently enough over a long enough span of time that it affects the behavior of millions of people. So, you know, how do we promote the web platform over react, like do a better job promoting the web platform, 'cause there are thousands of people who are writing resources for React because that's where money and attention and time is. [00:45:14]
-
-So if you want to do better than that, you have to make a resource that is better. I don't know that. There you go. [00:45:45]
-
-## Related, [“Dead Framework Theory”](https://aifoc.us/dead-framework-theory/) from last month
-
-1-acemarke: Yeah, so the, the, the other, there was a related article from last month entitled Dead Framework Theory, which was specifically addressing like the the LLM training data aspect of this and how it, how it becomes a, sort of a self perpetuating cycle. [00:45:53]
-
-And also pointing out that like if you have a, a new library or a new tool or a new web platform feature that is just now baseline, newly available, there's a lag in common LLMs knowing about that. So it's sort of like that defaults win kind of an issue. [00:46:07]
-
-2-vcarl: Yeah, and I'll say, yes, defaults win, but that doesn't mean that it's impossible for an, you know, to approach the problem in a way to mitigate that kind of, you know, home field advantage that tools like React have. [00:46:25]
-
-I've shout it out a number of times, in a bunch of different contexts, because they do a good job! But I love effect. One of the things they do really well is documentation, and one of the things they do really well in their documentation is making it legible for ai. I recently, over the summer, built a greenfield project with effect, and I did it extensively with ai, a mixture of having it write and then having it educate me and then rewriting it, and then having AI rewrite what I did, you know, just get there over time. [00:46:38]
-
-But I was able to do that despite it being a new library that's even at odds with the kind of patterns that AI wants to write, it's a functional type, it's a functional programming typed standard library essentially, which is not at all what AI wants to write. AI wants to write object oriented classes. And despite that, I was able to make it, figure it out and learn it and do a good job, good enough job that I got something I was proud of. You know, not just vibe coded. I was proud of it. I told people in my life, this is the best code base I've ever worked on. [00:47:07]
-
-And it's a large part of that was because of how the effect as a, you know, organization and library approach, their style of documentation. They made it legible for these automated tools. So I guess like if you wanna promote the web platform over. Incumbents like React then like figure out how people are writing code, figure out how people are consuming documentation, consuming new knowledge and do a good job. [00:47:36]
-
-1-acemarke: I'll note though, that you, you are the one who decided you were going to use effect and told the LLM, this is what I'm going to build. [00:48:03]
-
-2-vcarl: It's true. Yeah. [00:48:11]
-
-## [Alex Russell’s latest stats on web devices and network budgets](https://infrequently.org/2025/11/performance-inequality-gap-2026/)
-
-1-acemarke: The last wink on this particular topic, Alex Russell, who used to be at Google now has been, Microsoft has been very vocally beating the drum that most client side JS is bad, that JS bundles keep growing, that most people are using. You know, older Android devices on mobile with very weak CPUs and therefore JS load times are worse versus, you know, developers using an iPhone or, or a Power or a Fast Mac or something. [00:48:12]
-
-And he just put up the latest article in his ongoing series. You know, documenting, stan-, like average bundle sizes, average network speeds, average CPU uses. I have a lot of respect for him. Technically, his stats are correct. His points are right. I have questions about his delivery and tone in how he accuses people of doing the wrong thing. But it's also very true that a lot of the people should be paying more attention to him and actually trying to shrink down bundles instead. [00:48:41]
-
-2-vcarl: That's interesting. I, a thought I've had, I haven't validated this thought against, you know, ground truth, but I've been hearing about bundle size as a problem. Essentially what he's talking about here, like we ship too much JavaScript for the compute capabilities of commonly used devices, like that as a thesis has been something I've been hearing about for a very long time, much of my career even, and I'm not sure that the bundle size problem has gotten that much worse over the last, I'll say eight years, you know, call it since 2017. [00:49:14]
-
-And he shows a chart of compute speeds and basically shows like, yes, top of the line devices have gotten five times faster, low end devices that 75% of the world uses have not gotten measurably faster. And that's true. Can't argue it. His stats are correct, like he said, but also like I'm not sure the problem is getting measurably worse. [00:49:52]
-
-The optimizations of how we can split code and you know, what the JIT and the execution environment is doing to make it work more quickly. Those have gotten better over time. And it's also true that like, so if he's looking at the, basically like every processor, anyone with a device is using and that is the correct stat to consult if you are building something that everyone in the world will access. [00:50:14]
-
-But that's not true for most startups. Like if you're building a startup that targets like some industry, that American businesses, is, targets a problem that American businesses need solved, then like it doesn't really matter what the mo-, mobile performance in, you know, different outside of that target industry, I guess are then it's like, like what you said about his like tone and delivery. [00:50:45]
-
-I think a, to me when I read this, a core part of what, that I think he's overlooking is that not everyone is trying to ship something that 100% of the people in the world can access smoothly and quickly. Like, and that's fine. Like, you know, not everything needs to target everybody in the world. So, I don't know, I, I guess that that's one of my takeaways. [00:51:09]
-
-That's one thing that I think is missing from this, otherwise very technically complete blog post. [00:51:30]
-
-1-acemarke: I think it's also true that an awful lot of app teams out there ought to be spending time thinking about like even just basic bundle sized stuff and they aren't. [00:51:37]
-
-## Npm attack, [Shai-Hulud round 2](https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains)
-
-2-vcarl: I do wanna talk about the NPM hack that is ongoing Shai-Hulud, the sand worm. [00:51:48]
-
-I want to call out. As far as I know, aikido.dev has been like the security researchers who have announced this, like uncovered it and then analyzed it and shared it. [00:51:55]
-
-## [Analysis of its evolution in code](https://www.aikido.dev/blog/bugs-in-shai-hulud-debugging-the-desert) from Sept
-
-2-vcarl: They had a really good analysis of the evolution of the code, of the attack of this worm from September, and I noted in that when I was rereading it after this, you know, new, new attack, they had shouted out that it appeared that they still had more credentials in reserve. Like they had cracked more credentials than they had actually used. [00:52:06]
-
-And sure enough, this, you know, round two attack in their analysis of of it this time around, they note that it was timed just before NPM's deadline for revoking old tokens. So like very clearly they had a lot of tokens that they had compromised previously that they were now taking advantage of before they, before they lost access to it, before those tokens were no longer valid. [00:52:29]
-
-And I guess to reiterate, we've talked about, we talked about this attack before, I would say this is, this represents the current cutting edge of malware. It is using all sorts of fascinating root execution, like privilege escalation. I saw discussion of it, starting a docker container, mounting your file system to that privileged environment and now suddenly it has privileged access to all sorts of files that it couldn't have if it was just running in your shell. [00:52:48]
-
-There's stuff like that that's pretty fascinating and other things like if you have a Claude installed, it will prompt Claude to say, "Hey, look around this file system for secrets." like that is very cutting edge malware. To me, it's, it's not just writing its own code. It's not just a worm that is trolling your file system. [00:53:14]
-
-It is taking advantage of other tools that you take advantage of to attack you. So it's, yeah. That's not great. [00:53:32]
-
-1-acemarke: I mean, like, big picture, it's almost, it's almost surprising how many widespread pieces of malware have been very dumb and weren't as nearly destructive or smart as they could have been. And like think of how much damage we've had collectively as an industry over years with only a lot of those dumb malware. [00:53:39]
-
-And now we're starting to see some people write more intelligent malware. [00:54:01]
-
-2-vcarl: Yep. Yeah. 'cause a month ago, or two months ago, whenever it was, there was a different NPM hack that managed to get into the debug package, which is massively widely used. And I assumed that it was the same attackers as this attack because it's, it, it resembled it in a couple of ways, except that it was dumb. It was so poorly executed. [00:54:05]
-
-Like they got close to unprecedented access to the NPM ecosystem like. This is one of the first times that that previous attack, the debug attack, was one of the first times that I saw, "here's this compromised version. Let me check my file system. Oh, yep, there it is. I've got this." [00:54:26]
-
-So yeah, they just straight up fumbled the bag there. My theory here, having paid attention to this, it seems like there's some hacker group that may have compromised, set up a phishing tool set, you know, set up tools for other malicious actors to run phishing attacks. And it feels like two different hacker groups took advantage of those tools to target NPM maintainers. [00:54:45]
-
-And only one of them is actually technically competent enough to take full advantage of the access that they got. So yeah, I believe we've shared these resources before. [00:55:13]
-
-## [Our plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) from September
-
-2-vcarl: And GitHub put out our plan for a more secure NPM supply chain, so they're still working on that clearly. [00:55:23]
-
-## [NPM update on token management changes](https://github.blog/changelog/2025-11-05-npm-security-update-classic-token-creation-disabled-and-granular-token-changes/)
-
-2-vcarl: They also just released an NPM security update earlier this month in November, November 5th. [00:55:29]
-
-## ⚡ Lightning round ⚡
-
-2-vcarl: Mark, you want to just read through any of these lightning rounds that you wanna call attention to? Okay. [00:55:34]
-
-## [TS 6.0 hopefully Feb 2026, 7.0 (native) soon after](https://bsky.app/profile/danr.bsky.social/post/3m5fz3vw2z22s) (more details in the [TypeScript.fm](https://share.transistor.fm/s/ad05eae6) podcast)
-
-1-acemarke: TS six and TS seven are hopefully gonna be coming out early next year. TS six is still the current TypeScript code base, but with some changes to defaults and deprecation. And then TS seven would be the native implementation in go that they're working on. [00:55:38]
-
-So a couple different updates on the release plans there. That's going to be very, very exciting. I am excited to have TypeScript compiler 10 times faster. [00:55:54]
-
-## [Latest TC39 proposal updates](https://bsky.app/profile/robpalmer.bsky.social/post/3m62djhwj3k2i)
-
-1-acemarke: Also there were some more. The latest TC 39 proposals meeting as usual, advanced a number of different proposals to different stages. A couple of things that look interesting. [00:56:03]
-
-There's a promise do all keyed, which is essentially promise dot all but for an object. And then I am excited, un irrationally excited about object keys length, which is literally just to get the size of the number of keys in an object instead of object keys, parentheses, length. [00:56:13]
-
-## [Chrome (and other browsers) wants to remove XSLT from the web platform](https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4gYZeSJA/m/yNs4EsD5AQAJ?pli=1)
-
-2-vcarl: Chrome, and a couple of other browsers want to remove XSLT from the web platform. XSLT is a, what, domain specific library for transforming XML? [00:56:32]
-
-1-acemarke: XML transformations within a browser. So you, you send out an XML document from the server, and then you have a purely client side declarative transformation that like converts it into HTML. [00:56:42]
-
-2-vcarl: It exists. I had no idea that it was a browser feature. I've known of it as a tool that exists, but I had no idea it was baked into the browser and they're looking to remove it and I'm okay with that. But certain people who I guess use it for one thing or another have been running a campaign to say, "no, please don't. What about RSS feeds?" But yeah. [00:56:54]
-
-## [“Your URL is Your State”](https://alfy.blog/2025/10/31/your-url-is-your-state.html), and [David K’s “Goodbye, useState” talk](https://gitnation.com/contents/goodbye-usestate)
-
-1-acemarke: Going along a bit with the whole use the platform thing, more people should be putting some of their state in the URL and there was a very good article on using the URL as state. And then along with that, another video from recent React Summit that's probably paywall at the moment, but I think he's done a couple previous versions of this at different conferences. [00:57:14]
-
-David Kourshid has a talk on goodbye used state, similar to his goodbye use effect. It's hilarious, it's funny, and it also points out why you shouldn't be using actual used state all that much. [00:57:33]
-
-## [Aiden Bai’s “React Grab” util](https://www.react-grab.com/)
-
-2-vcarl: Aiden Bai, who did millions js put out an interesting new tool called React Grab, basically letting you, you know, you, is trying to solve the problem of when you tell AI like, "Hey, make this thing different." And then it goes, "I don't know where that is. Here's your browser, but I don't know where that is in the code base." [00:57:46]
-
-And so this is a tool that helps map similar to how you can use dev tools to highlight an element. This is taking that kind of behavior where you highlight an element in your browser and it connects back to the actual source code that produced that element as a means of giving AI a head start on finding what code to use, which seems super cool. [00:58:03]
-
-I questioned the wisdom of the recommended get started thing, which is just to add a script tag to unpkg. I don't know. Seems, seems slightly sketch, but also for also seems really easy to, to get started. [00:58:25]
-
-## [Creating a custom Node module loader to import from Bittorrent](https://evanhahn.com/node-torrent-import/)
-
-1-acemarke: One thing that caught my eye in terms of like, this is awesome and you should never, ever do this, was implementing a node module loader that imports from BitTorrent. [00:58:39]
-
-Okay, great. That's possible apparently. [00:58:48]
-
-2-vcarl: Love that. I do love BitTorrent. You know, as we were talking about decentralized technology a little bit earlier, like, man, what a highly resilient, decentralized technology. But yeah, well, hey, you know, maybe if we're gonna tell you, if we're gonna encourage people to do decentralized technology building on the shoulders of giants, like it, man, if you want it to like never stop working, ever, sure, import your code from BitTorrent, probably it's not gonna work very quickly, but given the right underlying seeders that would, that may never go down. Pretty interesting. [00:58:52]
-
-## [Ryan Carniato’s stream on researching “async signals”](https://www.youtube.com/watch?v=ori9xZhvNlc)
-
-1-acemarke: Earlier I mentioned Ryan Carniato streaming and talking about async signals. Here's the six hour livestream video if you want to watch that and or throw it into a summarizer somewhere. [00:59:22]
-
-## [Details of building Node’s TS type stripping support](https://satanacchio.hashnode.dev/the-summer-i-shipped-type-stripping)
-
-2-vcarl: I'll shout out the details of building nodes, the node type, script type stripping support, just 'cause I, man, I do love a technical writeup and that is, that was a massive feature release, just like the ability to use node to run TypeScript code without doing a compilation step. Was pretty cool. And so here to here to signal boost a post from the author of it. [00:59:33]
-
-## [The Web Animation Performance Tier List](https://motion.dev/blog/web-animation-performance-tier-list)
-
-1-acemarke: And one more, since we spent much time talking about the, the web platform, the author of the motion animation framework put up a really good post comparing all the different ways you can do animations on the web and talking about some of the performance trade offs. [00:59:58]
-
-2-vcarl: Super good. Cool. [01:00:12]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-2-vcarl: Into some conference news. [01:00:14]
-
-We don't really have much 'cause it's the end of the year and all of the upcoming conference things don't show anything for like January or February. [01:00:15]
-
-## CFPs
-
-1-acemarke: Well, we don't have much of a list here, but I can say that I've actually been doing my own, trying to prepare CFPs for next year and it ended up making a database of conferences and like my own personal list is like dozens of them. [01:00:22]
-
-And I can tell you there several conferences have submission deadlines like by November 30th s Why? I'd say there's a lot more conferences out there that knew existed until I spent several evenings spent researching them and trying to put this database together. [01:00:35]
-
-2-vcarl: I've tried to do that consistently over the past three years for this podcast and holy shit, there are so many conferences. It is absolutely bananas. Some of them are even fraudulent, so it's like you, you actually gotta them. So yeah, it's a lot. But okay. [01:00:47]
-
-## [React Paris](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform) ([Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform))
-
-2-vcarl: All that to say, I am aware of, React paris has a CFP currently open, but that's gonna be in March. So if you're looking to talk, then they've got a CFP open, you can do that. [01:01:01]
-
-## [JSWorld](https://docs.google.com/forms/d/e/1FAIpQLSfv3GuXwsDyR42XsvJwfFsN4SKjy8WvKtqYp_nEK0yhzVNP1g/viewform) CFP closes Dec 31, notifies by Feb 1
-
-2-vcarl: JS World also likewise has a CFP that closes at the end of December. [01:01:12]
-
-## Ending
-
-2-vcarl: Thank you everyone who has managed to stick around for this, you know, hour and 15 minute recording session. [01:01:18]
-
-1-acemarke: Funny we said we didn't have a lot of main content for today and go figure. We had a lot to say about stuff. [01:01:24]
-
-2-vcarl: Yeah, right. I give us a, give us a blank slate and we will fill it. Boy howdy. [01:01:29]
-
-1-acemarke: Hopefully the discussion has been useful. [01:01:34]
-
-2-vcarl: That is my hope. I, if not useful at least. Interesting. Cool. Thank you for joining us. We normally, I say we'll be back on the last Wednesday of the month, but the last Wednesday of next month I think is [01:01:36]
-
-1-acemarke: December 31st, [01:01:48]
-
-2-vcarl: so I don't know, we're probably not gonna do it on the last Wednesday of next month, but we'll be back [01:01:49]
-
-1-acemarke: somewhere about that timeframe approximately ish. [01:01:54]
-
-2-vcarl: Before the end of this year. [01:01:57]
-
-Yeah. Generally, I say we gather sources from all sorts of news feeds and whatever, but Mark, you've done a good job of being my source lately. So mostly we get news from #tech-news-and-reads, or at least that's where I get it. [01:01:59]
-
-I don't know where Mark gets it. [01:02:11]
-
-1-acemarke: All of the above newsletters plus like Hacker News and Twitter and all the other social media feeds I obsess over. [01:02:13]
-
-2-vcarl: But yeah, we do subscribe to this week in React by Dev React status next year. It's weekly. Mark and I are both subreddit mods of React js. But yeah, if you see anything that seems useful that you might want us to discuss, drop it in the #tech-news-and-reads channel. [01:02:20]
-
-I'll at least read it. I may not bring it in, but yeah, if this is a show that you get value from and wanna support, the best way to do so is by telling people about it and submitting a review that'll help us get discovered and whatever. [01:02:36]
-
-Cheers. Thanks so much. [01:02:48]
-
-1-acemarke: Happy Thanksgiving. [01:02:50]
diff --git a/src/transcripts/tmir-2025-12.md b/src/transcripts/tmir-2025-12.md
deleted file mode 100644
index c523838..0000000
--- a/src/transcripts/tmir-2025-12.md
+++ /dev/null
@@ -1,1022 +0,0 @@
----
-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]
diff --git a/src/transcripts/tmir-2026-01.md b/src/transcripts/tmir-2026-01.md
deleted file mode 100644
index 62ed2a2..0000000
--- a/src/transcripts/tmir-2026-01.md
+++ /dev/null
@@ -1,840 +0,0 @@
----
-title: 'TMiR 2026-01: Oops more CVEs. AI has React "skills", Astro exits and Tailwind struggles'
-date: 2026-01-30
-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:58](#new-releases)] New releases
- - [[00:59](#next-161-turbopack-updates-bundle-analyzer)] [Next 16.1](https://nextjs.org/blog/next-16-1) (Turbopack updates, bundle analyzer)
- - [[01:15](#turbopack-incremental-computation)] [Turbopack incremental computation](https://nextjs.org/blog/turbopack-incremental-computation)
- - [[01:38](#react-navigation-80-alpha)] [React Navigation 8.0 alpha](https://reactnavigation.org/blog/2025/12/19/react-navigation-8.0-alpha/)
- - [[02:03](#rn-windows-081-with-new-arch-support)] [RN Windows 0.81 with New Arch support](https://devblogs.microsoft.com/react-native/%F0%9F%9A%80react-native-windows-v0-81-is-here/)
- - [[02:55](#state-of-react-native-macos-saad-najmi-jay-meistrich)] [State of React Native macOS](https://www.youtube.com/watch?v=XE7yKGDsy9g) Saad Najmi & Jay Meistrich
- - [[03:15](#mark-josh-goldbergs-new-flint-linter)] Mark: Josh Goldberg’s [new Flint linter](https://www.flint.fyi/blog/introducing-flint)
- - [[05:15](#immer-111-array-methods-override)] [Immer 11.1](https://github.com/immerjs/immer/releases/tag/v11.1.0) (array methods override)
- - [[06:37](#rolldown-10-rc)] [Rolldown 1.0 RC](https://voidzero.dev/posts/announcing-rolldown-rc)
- - [[06:54](#yarn-6-preview)] [Yarn 6 Preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/)
- - [[07:42](#vite-plus)] [Vite Plus](https://viteplus.dev/)
- - [[08:59](#new-css-grid-lanes-masonry-feature-spec-nailed-down)] [New “CSS Grid Lanes” (“masonry”) feature spec nailed down](https://webkit.org/blog/17660/introducing-css-grid-lanes/)
- - [[10:39](#temporal-api-finally-hitting-stability-and-how-it-replaces-dates-)] [Temporal API finally hitting stability](https://developer.chrome.com/blog/new-in-chrome-144#temporal) ([and how it replaces Dates](https://piccalil.li/blog/date-is-out-and-temporal-is-in/) )
-- [[12:29](#main-content)] Main Content
- - [[12:34](#react-core)] React Core
- - [[12:37](#additional-updates-cves-for-dos-as-of-jan-26-update-to-1905-1915-and-1924)] [Additional updates / CVEs for DoS](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) as of Jan 26 . Update to 19.0.5, 19.1.5, and 19.2.4
- - [[13:40](#nextjs-dos-cves-for-image-optimizer-and-partial-pre-rendering)] [Next.js DoS CVes](https://vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472) for Image Optimizer and Partial Pre-Rendering
- - [[13:50](#react-docs-updates-for-useoptimistic-and-useeffectevent)] React docs updates for [useOptimistic](https://github.com/reactjs/react.dev/pull/8264) and [useEffectEvent](https://github.com/reactjs/react.dev/pull/8279)
- - [[14:11](#and-this-post-on-useoptimistic-issues)] And this post on [useOptimistic issues](https://www.columkelly.com/blog/use-optimistic)
- - [[14:32](#sparked-by-dan-raising-concerns-about-the-docs-quality)] Sparked by [Dan raising concerns](https://bsky.app/profile/danabra.mov/post/3mciooa25gc2v%20) about the docs quality
- - [[16:57](#ai-meets-rn-panel-discussion)] [AI meets RN Panel Discussion](https://www.youtube.com/watch?v=QX1a6I08o-A)
- - [[17:17](#work-on-the-gesture-api-and-view-transitions-and-fragment-refs-canary-only)] Work on the [Gesture API and View Transitions](https://github.com/facebook/react/pull/35564), and [Fragment Refs](https://github.com/facebook/react/pull/35630) (canary only)
- - [[18:29](#viewtransition-underlying-tech-is-now-supported-in-all-major-browsers-as-of-firefox-147-react-features-is-still-in-canary)] [\ underlying tech](https://developer.mozilla.org/en-US/docs/Web/API/ViewTransition/types) is now supported in all major browsers as of Firefox 147. React features is still in Canary.
- - [[19:22](#jordan-pred-the-actual-usestore-concurrent-store-impl-for-react)] Jordan PRed [the actual `useStore` concurrent store impl for React](https://github.com/facebook/react/pull/35449)
- - [[20:54](#types-changes-to-improve-form-events)] [Types changes to improve form events](https://github.com/DefinitelyTyped/DefinitelyTyped/pull/74383)
- - [[21:34](#other-security-issues)] Other security issues
- - [[21:39](#react-router-cves-meta-xss-file-access-external-redirects-csrf)] [React Router CVEs](https://bsky.app/profile/reactrouter.com/post/3mbwtrea3r224): meta XSS, file access, external redirects, CSRF
- - [[23:17](#node-security-releases)] [Node security releases](https://nodejs.org/en/blog/vulnerability/december-2025-security-releases)
- - [[24:38](#lodash-security-releases)] [Lodash security releases](https://openjsf.org/blog/lodash-security-overhaul)
- - [[24:46](#funded-by-a-european-effort-to-fund-projects-for-sovereign-resiliency)] [Funded by a european effort](https://www.sovereign.tech/programs/fund) to fund projects for sovereign resiliency
- - [[25:35](#githubs-announced-plans-on-security-improvements)] [Github’s announced plans on security improvements](https://github.blog/security/supply-chain-security/strengthening-supply-chain-security-preparing-for-the-next-malware-campaign/)
- - [[27:48](#summary-of-npms-publishing-changes-and-requests-for-improvements)] [Summary of NPM’s publishing changes](https://socket.dev/blog/npm-to-implement-staged-publishing), and requests for improvements
- - [[28:28](#claude-skills-in-the-react-world)] Claude Skills in the React world
- - [[28:49](#announcement-by-anthropic)] [Announcement by Anthropic](https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills)
- - [[29:16](#open-sourced)] [Open sourced](https://agentskills.io/home)
- - [[29:53](#vercel-react-best-practices)] Vercel: [React Best Practices](https://vercel.com/blog/introducing-react-best-practices)
- - [[30:47](#expo-claude-code-pluginskill)] [Expo Claude Code Plugin/Skill](https://x.com/Baconbrix/status/2011862532320084329)
- - [[32:23](#agents-worked-better-than-skills)] [“AGENTS worked better than skills”](https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals)
- - [[40:42](#moltbook-aka-openclaw)] [Moltbook](https://www.moltbook.com/), aka [OpenClaw](https://openclaw.ai/)
- - [[43:09](#remotion-ai-skill)] [Remotion AI Skill](https://x.com/Remotion/status/2013626968386765291)
- - [[43:49](#rsc-roundup)] RSC roundup
- - [[43:52](#data-fetching-patterns-in-rscs)] [Data Fetching Patterns in RSCs](https://gauravthakur.com/blog/data-fetching-patterns-react-server-components)
- - [[44:14](#nadias-can-you-fetch-data-with-server-actions)] [Nadia’s Can You Fetch Data with Server Actions?](https://www.developerway.com/posts/server-actions-for-data-fetching)
- - [[44:31](#infiniterenders-takes-on-partial-pre-rendering-and-app-router-complexity)] “Infiniterenders” takes on [Partial Pre-Rendering](https://x.com/infinterenders/status/2007670332362989569) and [App Router complexity](https://x.com/infinterenders/status/2007670332362989569)
- - [[45:03](#rebuilding-github-prs-with-rscs-same-author-who-did-issues-previously)] [Rebuilding Github PRs with RSCs](https://wtbb.vercel.app/i-love-dogs) (same author who did Issues previously)
- - [[46:01](#ecosystem-economics)] Ecosystem economics
- - [[46:07](#astro-acquired-by-cloudflare)] [Astro acquired by CloudFlare](https://astro.build/blog/joining-cloudflare/)
- - [[47:32](#tailwind-revenue-down-80-in-the-ai-era-laid-off-3-of-4-devs-working-there)] [Tailwind revenue down 80% in the AI era, laid off 3 of 4 devs working there](https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957)
- - [[50:15](#voidzero-and-vite)] VoidZero and Vite\+?
- - [[52:22](#246k-laid-off-in-2025-per-trueupio-27k-in-january)] [246K laid off in 2025 per Trueup.io](http://Trueup.io), 27k in January
-- [[52:56](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[52:57](#corbin-adapting-library-logic-for-react-compiler)] Corbin: [Adapting Library Logic for React Compiler](https://playfulprogramming.com/posts/react-compiler-library-support/)
- - [[53:11](#lea-verou-web-dependencies-are-broken)] [Lea Verou: Web Dependencies are Broken](https://lea.verou.me/blog/2026/web-deps/)
- - [[53:47](#aws-infrastructure-as-react-components)] [AWS Infrastructure as React Components](https://www.react2aws.xyz/)
- - [[54:38](#callstack-releasing-bunch-of-cool-projects)] Callstack releasing bunch of cool projects
- - [[54:48](#brownie-rn-brownfield-apps)] [Brownie: RN Brownfield apps](https://www.callstack.com/blog/introducing-brownie-type-safe-shared-state-for-react-native-brownfield-apps)
- - [[55:17](#voltra-rn-live-activities-and-widgets)] [Voltra: RN Live Activities and Widgets](https://www.callstack.com/blog/live-activities-and-widgets-with-react-say-hello-to-voltra)
- - [[56:12](#ryan-carniatos-annual-js-frameworks-direction-roundup-and-netlifys-2025-web-frameworks-in-review)] Ryan Carniato’s [annual JS Frameworks direction roundup](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2026-2hel) , and Netlify’s [2025 Web Frameworks In Review](https://www.netlify.com/blog/web-frameworks-2025-year-in-review/)
- - [[56:36](#alex-russell-shallow-session-spas-analytics)] Alex Russell: [Shallow Session SPAs analytics](https://calendar.perfplanet.com/2025/the-curious-case-of-the-shallow-session-spas/)
- - [[57:23](#devon-govett-how-to-compile-js-to-c-with-static-hermes)] Devon Govett: [How to compile JS to C with Static Hermes](https://devongovett.me/blog/static-hermes.html)
- - [[58:16](#joyee-cheung-requireesm-implementers-tales-and-requireesm-from-experiment-to-stability)] Joyee Cheung: [require(esm) implementer’s tales](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-implementers-tales/) and [require(esm) from experiment to stability](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-from-experiment-to-stability/)
- - [[58:53](#fixing-the-url-params-performance-penalty)] [Fixing the URL Params Performance Penalty](https://calendar.perfplanet.com/2025/fixing-the-url-params-performance-penalty/)
- - [[01:00:26](#react-transitions-for-low-priority-text-editor-updates)] [React Transitions for Low Priority Text Editor Updates](https://handlewithcare.dev/blog/transition_low_priority_editor_updates/)
- - [[01:00:46](#how-to-steal-a-react-component-fiber-internals)] [How to Steal a React Component](https://fant.io/react/) (Fiber internals)
- - [[01:01:20](#better-ascii-rendering-with-smart-character-selection-for-pixels)] [Better ASCII rendering with smart character selection for “pixels”](https://alexharri.com/blog/ascii-rendering)
- - [[01:02:32](#building-a-js-runtime-in-one-month)] [Building a JS Runtime in One Month](https://themackabu.dev/blog/js-in-one-month)
-- [[01:03:33](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [CityJS New Delhi](https://india.cityjsconf.org/), 18-19 Feb, New Delhi, India
- - [State of the Browser](https://2026.stateofthebrowser.com/) Feb 28, London, UK
- - [AppDevCon](https://appdevcon.nl/) Mar 10-13, Amsterdam Netherlands
- - [Programmable](https://www.programmable.tech/) Mar 17 / Mar 19, Melbourn / Sydney, Australia
- - [Frontrunners](https://frontrunners.tech/) Mar 27, Washington DC, USA
- - CFPs: [web talks](https://docs.google.com/forms/d/e/1FAIpQLScK3YlL_-2teVyX7pohkjIbsyLSF-8Hq4z-U7CPQ186sgdNPA/viewform) or [AI/data](https://docs.google.com/forms/d/e/1FAIpQLSedNNa4N64vgfsvAtGcBngKJrtd3h1_x0T019GTW-rSwCj0jQ/viewform)
- - [T3chfest](https://t3chfest.es/2026/en/) Mar 12-13, Madrid, Spain
- - [React Paris](https://react.paris/) Mar 26-27 Paris, France
- - [CFP (closed)](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform), [Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform)
- - [React Native Connection](https://reactnativeconnection.io/) Mar 30-31, Paris, France
- - [CityJS London](https://london.cityjsconf.org/), Apr 15-17, London, UK
- - [jsday](https://www.jsday.it/) Apr 9-10, Bologna, Italy
- - [SmashingConf Amsterdam](https://smashingconf.com/amsterdam-2026) Apr 13-16, Amsterdam, Netherlands
- - [React Miami](https://www.reactmiami.com/) Apr 22-25
-- [[01:04:56](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the first this month in React of 2026 January edition. As we recap what's going on in React, react Native and across the web, we're coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]
-
-And yeah, I'm Carl. I'm a staff product developer and freelance community leader here in Reactiflux where I do programs like these events uh, and a couple of other things. [00:00:16]
-
-**Mark:** Hi, I'm Mark. My day job is working at Replay. My second unpaid job is working on Redux and I'm not wearing glasses. [00:00:25]
-
-**Carl:** Yeah. Congrats on LASIK! [00:00:33]
-
-**Mo:** And I'm Mo I'm the head of Mobile at Thero. I'm an active part of the React Native community, and I organize the React Native London Meetup and Conference. [00:00:35]
-
-**Carl:** and like 10 minutes fresh off, traveling back home. Right? [00:00:43]
-
-**Mo:** yeah. Just got home. Just got home. I'm still still wearing my coat. [00:00:48]
-
-**Mark:** Make yourself comfortable. [00:00:52]
-
-**Mo:** We're gonna be here. [00:00:54]
-
-**Carl:** Cool. Okay. Uh, Let's get straight into some new releases. [00:00:55]
-
-## New releases
-
-**Carl:** Yeah, Mark, take us through those. [00:00:58]
-
-## [Next 16.1](https://nextjs.org/blog/next-16-1) (Turbopack updates, bundle analyzer)
-
-**Mark:** Okay. Item one we have next. 16.1 just came out not a lot. Huge. There, there's some improvements to Turbo pack. They have a new bundle analyzer feature built in. I'm always in favor of, you know, actually understanding what's going into your system. [00:00:59]
-
-## [Turbopack incremental computation](https://nextjs.org/blog/turbopack-incremental-computation)
-
-**Mark:** Looks like some of the Turbo Pack file caching stuff ought to make the dev mode a little bit faster. [00:01:15]
-
-Hopefully I don't think we put the link in here, but the next folks did put out an article sometime in the last couple weeks talking about a lot of the internal memo work they do in Turbo Pack. That is, you know, the core of how it's supposed to make builds faster. So that's probably worth looking at as well. [00:01:21]
-
-## [React Navigation 8.0 alpha](https://reactnavigation.org/blog/2025/12/19/react-navigation-8.0-alpha/)
-
-**Mo:** React navigation version 8.0 is an alpha now. So we've seen a little bit of this stuff come around, but things like native bottom tabs being sort of the default, which a lot of the other libraries in the ecosystem are moving towards and expert route has been pushing for a while, which uses react navigation under the hood. [00:01:38]
-
-Some better TypeScript configs and just some general improvements. With the major changes, those native bottom tabs, which won't make the apps feel just that much more native. [00:01:55]
-
-## [RN Windows 0.81 with New Arch support](https://devblogs.microsoft.com/react-native/%F0%9F%9A%80react-native-windows-v0-81-is-here/)
-
-**Mo:** And then the next one is React Native Windows, version 0.81. Is out. And the same is actually the case with React Native Mac Os because they're both maintained by Microsoft. [00:02:03]
-
-big thing here is that the sort of new architecture or the fabric architecture is now enabled by default. So the Windows and Mac os the desktop equivalents of Rack Native are a little bit behind because of some legacy that's in the code base and some stuff that needs to be refactored in a little bit of tech debt. [00:02:14]
-
-But they're definitely catching up. So, they're getting close to fully adopting the new architecture, which is exciting. [00:02:32]
-
-**Mark:** I would love to know what the adoption numbers are for either the, the macro windows ports outside of Microsoft. Early outta curiosity, [00:02:37]
-
-**Mo:** It's not as well publicized or showcased, but I have a great talk, which I'm gonna use this opportunity to plug by one of the maintainers. [00:02:46]
-
-## [State of React Native macOS](https://www.youtube.com/watch?v=XE7yKGDsy9g) Saad Najmi & Jay Meistrich
-
-**Mo:** so this was at the conference that we hosted at Arn Lko and one of the maintainers, one of the maintainers of React Native macOS did a joint talk with Jay Meistrich, who maintains Legend List. And they talked about react Native macOS in the state of React Native Macs. It's a very cool talk to get an idea of what's in store. So, [00:02:55]
-
-**Carl:** great. Love that. [00:03:13]
-
-## Mark: Josh Goldberg’s [new Flint linter](https://www.flint.fyi/blog/introducing-flint)
-
-**Mark:** All right. Next item. Josh Goldberg is a wonderful one. Wonderful human being if you ever had a chance to talk to him. He's also a major proficient linting tool maintainer. He's been the primary maintainer of TSES lint. He's worked on a number of other linting projects. He's had a lot of interactions with the ES lint maintainers and the TypeScript maintainers. [00:03:15]
-
-And as a result, he has formed very many strong opinions about how winters should work and what's wrong with current winters. And, you know, like most people, he's, you know, griped about things he doesn't like for a while. And this has finally result in Josh building his own winter. So he's calling it Flint. [00:03:39]
-
-he'd written several previous blog posts talking about. You know, what would a better winter look like? And that was the, you know, the hidden background on I am actually building my own winter. So if you look at the Flint announcement it goes through some of the points that he's trying to make. [00:03:58]
-
-Things like it's, there's a hybrid architecture where it can use native built linting tools, but most of the coordination is still being done in TypeScript. It, it would still have TypeScript based plugins. Most of the rules would be in the core, much more consistent naming and error messages and configuration. [00:04:17]
-
-So. I don't know the full status of it. I know he's been working on it and that, like an early proof of concept exists. I don't think it's anywhere near a usable state at all. But Josh knows linting and he's very good at this stuff. So, we've got oxalate and es lint and excellent and bio at this point. [00:04:35]
-
-You know, maybe we don't need another, but I love that Josh has the enthusiasm to try to put his ideas into practice here. [00:04:56]
-
-**Carl:** Yeah, if you're gonna complain about something, putting your money where your mouth is on investing the energy to try and execute on those gripes is something that I would love to see everybody try and do. [00:05:03]
-
-## [Immer 11.1](https://github.com/immerjs/immer/releases/tag/v11.1.0) (array methods override)
-
-**Mark:** A personal item and one that I've been, you know, waiting to see come together for a while. So those of you who have been paying attention to the podcast over the last few months have heard me talk about the performance optimization work I did on Emer in September and October. [00:05:15]
-
-And so that had ended up with three different prs that I'd filed. A small set of tweaks that it went out as Imer 10.2 a major internal rewrite that went out as Imer 11.0. And then the other piece I'd put up is a new optional plugin that overrides ier array methods so that instead of accidentally proxying every field you access as you loop over an array, it just defers to the underlying array and skips most of the overhead in that, a couple K to the bundle size if you actually import and turn on the plugin. But it does make pretty much any array access noticeably faster. And you know, the goal of this was to make ER faster. So I did that. So that came out as ER 11.1 and that is all the performance changes I had except for one other spot where I was investigating the possibility of trying to improve the object spread handling in some way. [00:05:30]
-
-I may try to get back to look at that at some point, but this is all I'd put up. So very happy to see all that's come out. [00:06:31]
-
-## [Rolldown 1.0 RC](https://voidzero.dev/posts/announcing-rolldown-rc)
-
-**Mark:** Couple other items. [00:06:37]
-
-Back to the theme of tools being built in rust. Rolldown has hit 1.0 rc I believe this is already available for use in the latest V eight betas. I don't have a release timeline on that, but it looks like that one's coming together pretty well. [00:06:38]
-
-## [Yarn 6 Preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/)
-
-**Mark:** And then yarn has announced yarn version six, which yes, is a rewrite it and rust announcement. I don't think I missed a yarn five. I would've to go back and reread the post to see if they actually mention it, but I'm pretty sure the current version is still four x. So it's a rewrite and rest rewrite. The goal is to make it faster. I think the blog post has some benchmarks that compare it to PNPM in a few different modes but happening there. [00:06:54]
-
-**Carl:** Yeah, that's interesting. I just pulled up the Yarn docs and can confirm. The most recent version is listed as 4.1, so it's curious that they're announcing version six. [00:07:26]
-
-**Mark:** Maybe it's the winamp approach somehow. [00:07:35]
-
-**Carl:** taking inspiration from ECMAScript, you know, skip version four. [00:07:38]
-
-Strange. [00:07:41]
-
-## [https://viteplus.dev/](Vite Plus)
-
-**Mo:** I got an interesting thing that I was just looking at not yarn but roll down. And so it's obviously made by the creators of vt, but I was just going on the Void Zero website and I saw that they seem to be trying to launch a paid unified tool chain called VT Plus. I don't know if you folks have seen this, [00:07:42]
-
-**Mark:** they talked about that at vConf a couple months ago. The idea is that. Void Zero is sponsoring slash owning a lot of the work on the underlying tools OXC, oxalate OX format, EV and all that stuff. And the purpose of ROLLDOWN is that right now v relies on ES build for dev mode and roll up for prod builds. [00:07:59]
-
-And Es builds fast roll ups, not, and you've got two different tool chains. So roll down is an attempt to unify both, of those. One consistent build system, roll up public API do it a lot faster and you know, they own it. V plus then is supposed to be what if we took all our tooling together and made kind of like what Rome slash Biome was supposed to be a few years ago, the Uber Unified everything tool chain. [00:08:25]
-
-And then that would be their enterprise sales kind of a thing. [00:08:56]
-
-## [New “CSS Grid Lanes” (“masonry”) feature spec nailed down](https://webkit.org/blog/17660/introducing-css-grid-lanes/)
-
-**Carl:** In other news. So WebKit has shipped an initial version, an attempt at CSS grid masonry layouts. This has been like a hot a subject of hot debate for years. Like it's been this, like simmering. We want something that does this, but exactly what the semantics or should be, are unclear. Basically, grids are great, but they require, they, they place constraints in two dimensions. [00:08:59]
-
-it's a grid, it's a bunch of squares or a bunch of rectangles or whatever. And there's lots of layouts where each item in them may be a variable size, like for instance a grid of photos. You know, you look at your photos in whatever app you like to use. And it, there are different aspect ratios, there are different dimensions. [00:09:27]
-
-And that's where Masonry comes in. It's called masonry because it resembles like the layout of bricks or stones. So, cool that I've literally been hearing about that for at least four years, I'd say. I think, I feel like as soon as CSS grid came out, people were like, great. What about masonry? So it's cool that we've now got something functional shipped in Safari. [00:09:44]
-
-It looks like it's in the technology preview, so it's not fully usable now, but meaningful progress. [00:10:06]
-
-**Mark:** think a lot of the debate there was should this become like another named CSS display mode or is this another set of options for grid or something else? What's the naming, how does it play with the existing layouts? And so there, there was a lot of discussion iteration to try to figure out what the right approach was there. [00:10:13]
-
-**Carl:** And it sounds like they have, or at least close enough to where there's something has been shipped, which is great. Cool. [00:10:33]
-
-## [Temporal API finally hitting stability](https://developer.chrome.com/blog/new-in-chrome-144#temporal) ([and how it replaces Dates](https://piccalil.li/blog/date-is-out-and-temporal-is-in/) )
-
-**Carl:** Other, not quite released, but major progress .Temporal has been released in Chrome, I believe in the main release branch Chrome 1 [00:10:39]
-
-**Mark:** I think this, this is actually out. [00:10:49]
-
-**Carl:** yeah. [00:10:51]
-
-Which is being actually out is a clears a roadblock to being officially standardized. Anything that is stage four must be present. I believe in a like fully released browser version, it must be used not in alpha or release candidate. And that's great. JavaScript dates suck to work with. [00:10:52]
-
-There are a bunch of pretty major gotchas. My favorite is that there is no way to encode the time zone in a date. It always relies on the system time zone for whatever computer is executing that code which is a pain in the butt. And actually it, it has a b that cause of the bug in Reactiflux.com because the way we calculate what date a transcript is from diff is different if you build it locally versus on. [00:11:11]
-
-In production because of the five hour time difference. So I, I ha this is something I have to account for when I release these transcripts because JavaScript is dumb about dates. So, great. Love to see that. There was another great summary from Matt Marques Wilto, which, oh I recognize that name. [00:11:38]
-
-I've followed him on social media for 12 years now, something like that. Just, he did a great blog post about temporal Date is out, temporal is in definitely recommend it as a good technology summary of this tool. [00:11:57]
-
-**Mark:** And interesting implementation. I, I only saw this in passing, but I think the actual core of the temporal implementation that Chromium is using is indeed in rust and then exposed up through the JS engine. [00:12:11]
-
-**Carl:** fascinating. Cool. [00:12:24]
-
-**Mark:** I'd have to go back and double check details, but I think I saw it somewhere. [00:12:25]
-
-**Carl:** Okay. Neat. [00:12:28]
-
-## Main Content
-
-**Carl:** That's all the new releases we got for you. Let's go into main content [00:12:29]
-
-**Mark:** Okay. [00:12:33]
-
-## React Core
-
-**Mark:** A number of items from around the React core area. [00:12:34]
-
-## [Additional updates / CVEs for DoS](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) as of Jan 26 . Update to 19.0.5, 19.1.5, and 19.2.4
-
-**Mark:** Item number one, update your reacts again. So we, we had the multiple sets of CVEs and security issues with server components. Was that only last month, two months ago when, whenever that was. the initial remote code execution follow on reports found some denial of service and source code exposure, vulnerabilities, and apparently further investigation has found other ways to trigger denial of service and issues. [00:12:37]
-
-And so I, I was actually confused if this was. The same CVE or something different. It looks like there is actually a separate 2026 CVE entry for the new denial of service entries, but it's probably the same basic idea. So there are new versions of React Out. Again, please update to 19.0 0.5, 19.1 0.5, or 19.2 0.4 I think approximately. [00:13:05]
-
-Just update everything. Again, [00:13:35]
-
-**Carl:** Yep. Geez, not ideal. [00:13:38]
-
-## [Next.js DoS CVes](https://vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472) for Image Optimizer and Partial Pre-Rendering
-
-**Mark:** these for their own internal pieces image optimizer and partial pre rendering. So again, please update your next JS to the latest as well. [00:13:40]
-
-## React docs updates for [useOptimistic](https://github.com/reactjs/react.dev/pull/8264) and [useEffectEvent](https://github.com/reactjs/react.dev/pull/8279)
-
-**Mark:** hopefully slightly happier news. Ricky Hanlon just put up some docs updates. I don't think they're even merged yet. To rewrite the API reference pages for use Optimistic and Use Effect event and tracing this a bit. I think the, there were a couple triggers for him trying to make those changes. [00:13:50]
-
-## And this post on [useOptimistic issues](https://www.columkelly.com/blog/use-optimistic)
-
-**Mark:** There was a blog post that came out in , early January, I think that talked about a some of the complexity of using the useOptimistic Hook very well written article. Brought up a few different use cases and points, and I know Ricky saw it and responded to it on both Blue Sky and Reddit. [00:14:11]
-
-## Sparked by [Dan raising concerns](https://bsky.app/profile/danabra.mov/post/3mciooa25gc2v%20) about the docs quality
-
-**Mark:** And in the discussion on Blue Sky, Dan actually popped in and said, I'm really not happy with the use Optimistic Docs, or, you know, a few of the other docs pages, I feel like. You know, the team kind of missed the boat on some of the docs work after I, you know, after I set the bar pretty high with a lot of the initial tutorials and references and stuff. [00:14:32]
-
-And Ricky very right, rightfully pointed out, it's like, yeah, there's only so many people doing things. I'm one of 'em, I've been on family leave. And also, you know, we had this giant CVE drop that we've had to, you know, go deal with so very fair point. But I think Ricky took that as inspiration to go try to do a rewrite. [00:14:55]
-
-So he's got a rewrite up for both Use Optimistic and Use Effect Event. One interesting thing I noticed this morning, I, I believe the use optimistic update was probably done by hand. The React team has added some Claude code agent files to both repos and I think Ricky did some of that and added in some skills and commands for both improving docs and looking at things like the React compiler internals and stuff. [00:15:16]
-
-And I believe the effect event Doc PR said the first pass on this was done by Claude, and then I went up and tried to clean it up myself. So number one, hopefully better docs wonderful all around. Two, the React team is experimenting with Claude code and seeing what they can do with that. So, you know, just interesting to watch that progress along. [00:15:46]
-
-**Carl:** Yeah. That's interesting. I was, I've been curious, you know, I've never worked at big companies. I generally understand them to be pretty touchy about stuff like uploading code to third party servers. [00:16:10]
-
-So I've been curious what kind of access to tools like Claude you know, teams like React Core would have so interesting to see that they're visibly starting to experiment with it in the actual React code base. [00:16:21]
-
-**Mo:** It's quite interesting that like they're kind of allowed to almost come and say it publicly, given that Meta has been a big advocate of their own sort of open source models. Like, so, you know, it's almost like, hey, we use the direct competitors tools and it's, you know, it's fine. You know, so I think that's quite interesting. [00:16:35]
-
-## [AI meets RN Panel Discussion](https://www.youtube.com/watch?v=QX1a6I08o-A)
-
-**Mo:** We actually had some people from the React Native Core team where we talked about this at the conference. So I'm gonna do another, I'm gonna be doing a lot of self [00:16:57]
-
-**Mark:** Please plug your stuff. [00:17:02]
-
-**Mo:** yes. It's not really my stuff. I mean, I was I was moderating the panel, but I, if you want to get a little bit of insight into what the React Native Core team does with ai, this might be an interesting panel for you to watch. [00:17:05]
-
-We have a really good chat. [00:17:15]
-
-**Mark:** Cool. [00:17:16]
-
-## Work on the [Gesture API and View Transitions](https://github.com/facebook/react/pull/35564), and [Fragment Refs](https://github.com/facebook/react/pull/35630) (canary only)
-
-**Mark:** Meanwhile, in the midst of all the CVEs and everything else the React team is continuing to work on actual core functionality. We had the view transitions, alpha APIs came out last year, and Sebastian Markbåge has continued working on that and is expanding the view transition support with relation to gestures and some other animation things as well. [00:17:17]
-
-I have not looked at these, I don't know details, but I know that lack of animation support has always been a complaint about React as opposed to libraries like view and spelt. And so it seems like the work that they've done on Fiber in the past and now the baseline that they've put in place for view transitions is something that they're building on and trying to actually expand that functionality as well. [00:17:39]
-
-they're also continuing to make some tweaks to fragment refs. I actually legitimately do not remember, are fragment refs out in 19.2 or were they alpha in 19.2? [00:18:03]
-
-Anyway I, I saw, I saw a few additional prs come through with some improvements to fragment, ref handling dealing with text nodes and a few other things and [00:18:15]
-
-**Carl:** Can confirm, fragment refs are canary only right now. [00:18:24]
-
-**Mark:** okay. Okay. So still work in progress. [00:18:27]
-
-## [\ underlying tech](https://developer.mozilla.org/en-US/docs/Web/API/ViewTransition/types) is now supported in all major browsers as of Firefox 147. React features is still in Canary.
-
-**Mark:** And related to the view transitions aspect like a lot of other things, they came out in Chrome first and, you know, therefore all the different chromium based browsers Firefox has finally shipped view transitions as of Firefox 1 47, I have no idea about Safari. [00:18:30]
-
-I don't use safari. I don't look at safari. I don't know [00:18:46]
-
-**Carl:** small, small clarification actually. So, Firefox has supported view transitions themselves since 1 44, but there's a sub thing, view transition types, that they have not supported until now in Firefox 1 47. I don't fully understand what the difference is, but I guess it's like, you know, the types property on view transition is now supported and I guess the react view transition component depends on that. [00:18:48]
-
-**Mark:** Gotcha. [00:19:17]
-
-**Carl:** Yes, the view transition component, which is still in canary. [00:19:18]
-
-**Mark:** Mm-hmm. All right. [00:19:21]
-
-## Jordan PRed [the actual `useStore` concurrent store impl for React](https://github.com/facebook/react/pull/35449)
-
-**Mark:** And finally, two other prs to note. I've talked in previous episodes about the concurrent store's work that Jordan Eldridge has been working on. He had put up the React Concurrent Store, poly Fill. I had tried it out in React Redux. I had submitted some prs to improve the poly fill and offer some feedback on things that we probably need to cover when we actually go to implement it. [00:19:22]
-
-And Jordan actually put up the PR to actually implement the initial concurrent store, API in React itself. Remember, this is supposed to be a better replacement for the current used sync external store, API, but concurrent transition compatible. [00:19:44]
-
-Honestly, there's been surprisingly little discussion on this PR at all. Like, I think there's like one or two comments. One person just asking like, how is this different from the use hook or something like that. I expected more people to jump on this and say, what is this? What does it do? What are the trade-offs? How soon can we land this? And there's been no chatter. [00:20:03]
-
-But I mean, he also put it up like, I don't know, right at the end of December, early January. So not much. But again it's very exciting to see this being worked on at all. It's very exciting to see. We're at the point where he feels confident enough in the API design to put up a PR and say, here's what I think we're trying to do and an implementation that does that. Now let's discuss it and get further public feedback. So very, very excited by this. [00:20:25]
-
-## [Types changes to improve form events](https://github.com/DefinitelyTyped/DefinitelyTyped/pull/74383)
-
-**Mark:** And last item there was a types PR put up and I think possibly actually merged to improve the react types around form events. Trying to get better typing for the target field, I believe. [00:20:54]
-
-**Carl:** It did get merged. Can I confirm? [00:21:07]
-
-**Mark:** cool. [00:21:10]
-
-**Carl:** So it looks like the form event had previously been matched on types to the React synthetic event. But it was not identical to the actual DOM event. And so this types change corrects that. So the the types are now matching what is in the dom it looks like. Cool. Looks great. [00:21:11]
-
-**Mark:** Yep. And that's it from the roundup around the world of the core. [00:21:28]
-
-**Carl:** Heck yeah. Cool. [00:21:32]
-
-## Other security issues
-
-**Carl:** Let's go back into some more security issues around the ecosystem. [00:21:34]
-
-## [React Router CVEs](https://bsky.app/profile/reactrouter.com/post/3mbwtrea3r224): meta XSS, file access, external redirects, CSRF
-
-**Carl:** Yeah. I guess we briefly touched on some. You know, CVEs and other, you know, denial of service vulnerabilities. In next react Router has also put up a thread discussing six CVEs. It says they publish six CVEs identifying vulnerabilities between React router and remix B two. [00:21:39]
-
-They're saying safe versions are react router seven point 12 version six is 6.3, 30.3 and remix V two is two point 17.2. these are pretty weedsy kind of vulnerabilities. I was looking at the list and didn't see any that immediately jumped out as like, oh shit, that's gonna be a problem for me. [00:22:00]
-
-But it's like a couple of cross site scripting vulnerabilities. Let's see. Yeah, one in the meta component when it's generating script IDs. Okay, but that says framework mode only. Yeah. So it's a lot of these are in framework or data mode only if you're using that, I think that's the recommended, more more common. [00:22:21]
-
-Yeah. Yeah, so it's like in the meta component, it's got unauthorized file access for some session storage. If your cookies aren't signed, an unexpected external redirect via untrusted path, I don't quite know what that's supposed to imply. All of these just link to the actual, like GitHub security advisories rather than any kind of blog post or anything. [00:22:41]
-
-I'm not seeing like discussion of or explanation in depth of what these vulnerabilities are on a technical level. Just kind of here's what it was and here's what's safe. So that's great. I guess. [00:23:05]
-
-## [Node security releases](https://nodejs.org/en/blog/vulnerability/december-2025-security-releases)
-
-**Carl:** node likewise also had a, couple of security patches also pretty deep in the weeds. Several of these I believe, were uncovered as a result of investigations started after the React CVEs last month. [00:23:18]
-
-Yeah, you know, it's like you can update the timestamp of files if, even if you don't have right permissions. So that's, you know, technically a permissions bypass memory leak that enables a remote denial of service. Uncatchable maximum call stack exceeded error that can cause process crashes even if you think you're handling all possible errors because you can't catch it. [00:23:31]
-
-So it's a couple of little things like that. Mostly it looks like some file system errors and server crashes in general. One, one that's like super deep in the weeds. It says timeout based race conditions make unsigned into eight array buffer slash buffer allocation non-zero filled. So like if you go to allocate a type array buffer, I guess in certain circumstances, you know, that could be exploited so that what you think is a zeroed out, a ray buffer is not actually zeroed out, which you know, sure. [00:23:55]
-
-That's the kind of thing that absolutely security researchers can tap into and get it turning into some other vulnerability, I guess. I don't see a path towards it, but Sure. [00:24:27]
-
-## [Lodash security releases](https://openjsf.org/blog/lodash-security-overhaul)
-
-**Carl:** Here's a name I haven't thought of in a minute. Lodash they rolled out a major security overhaul as this blog post titles it. [00:24:38]
-
-## [Funded by a european effort](https://www.sovereign.tech/programs/fund) to fund projects for sovereign resiliency
-
-**Carl:** An interesting detail that I, I noticed while reading the blog post, it was actually funded by a sovereign tech agency is what it's called. And it says that they're, we invest globally in the open software components that underpin Germany and Europe's competitiveness and ability to, to innovate. [00:24:46]
-
-So this is the like government sponsored open source grant that was used to fund security work at Lodash to the tune of $200,000. So that's interesting. I, that's. Some fun details. I, I guess, you know, as we were talking about financial ecosystem for open source, look at that, here's a major foundational open source project getting like government investment money from the government in order to make it more secure. That's pretty cool. I appreciate that. that better than, you know, venture capital exits or whatever. Yeah. [00:25:01]
-
-## [Github’s announced plans on security improvements](https://github.blog/security/supply-chain-security/strengthening-supply-chain-security-preparing-for-the-next-malware-campaign/)
-
-**Carl:** Moving on a bit. GitHub put out a blog post towards the end of last month. I think we missed it because we recorded early in December to avoid the holidays. But they put out a blog post about strengthening supply chain security, just across GitHub and NPM. [00:25:35]
-
-It's a lot of retrospective on the Shai-Halud attacks that we discussed in pretty deep detail over the last two or three months. Looks like they're, it says, what's next for NPM, bulk OIDC onboarding. So I guess, you know, OIDC is a authentication standard for sharing authentication information, previously they didn't have great support for that. Now they have much better support for it, but people have to transition. So this [00:25:50]
-
-**Mark:** the biggest issue is I've now done this for a couple packages and you have to go in directly into the NPM settings for that package. Manually click through. I want to turn on trusted publishing for this package. Here's the repo name, the, YML file that will publish this and confirm the settings. [00:26:16]
-
-Now, what happens if you have hundreds of packages? I think people even went ahead and started creating user scripts in the browser to try to automate clicking through that. [00:26:35]
-
-**Carl:** Oh man. writing an automated user script to [00:26:44]
-
-**Mark:** automate [00:26:48]
-
-**Carl:** changes, what could go wrong. Yeah, so they also expanded to support more OIDC providers, so it's not just GitHub and GitLab as well as staged publishing. So it's a new publication model that gives maintainers a review period before packages go live with multifactor authentication, verified approval. [00:26:49]
-
-So, cool. Like this is a bunch of like [00:27:09]
-
-**Mark:** Boring, but critical stuff. [00:27:12]
-
-**Carl:** Right. Boring but critical stuff around. Ensuring that who is publishing code to a specific package is who is supposed to, and providing review periods, I guess. So that's cool. That's great. That's definitely important. I don't know, I've been thinking a lot about identity online and it is wild. [00:27:15]
-
-How critical and how how critical that is of a problem to have good solutions to, and how terrible our current solutions to that problem are. I think that's gonna be a defining problem for the next long time. And socket do dev. [00:27:34]
-
-## [Summary of NPM’s publishing changes](https://socket.dev/blog/npm-to-implement-staged-publishing), and requests for improvements
-
-**Carl:** Last thing on the security front socket do dev put up a blog post with just sort of a, looks like a roundup of changes to the publishing process. [00:27:48]
-
-**Mark:** And one, one call out from within that article the Es Lin Maintainer and creator Nicholas Zaki, I think had put up his own blog post saying, yeah, actually I'm not thrilled with what GitHub and NPM are doing in terms of handling publishing changes. I think there's a lot more they ought to do. [00:27:58]
-
-And then the soc. Post references that, as you know, okay. You know, and GitHub and NPM are doing these things, but here's other suggestions of what would really be helpful. [00:28:17]
-
-## Claude Skills in the React world
-
-**Mo:** Cool. Let's change gears just a little bit and you might have been seeing sort of all over Twitter and different dev communities people talking about different Claude skills that have come up. So Mark talked about it briefly with the Vercel folks. But just wanna give a little bit of a context about this in case people haven't been really that involved in the AI space. [00:28:28]
-
-## [Announcement by Anthropic](https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills)
-
-**Mo:** So, anthropic about two-ish months ago released this concept of skills. Now they've also worked on different things like cps, which kind of did similar things, but you know, you needed a server to be running and you know, it wasn't necessarily something that was that useful for a lot of stuff where you just wanted to give it a bit of context about how to do a specific thing. And so they released this concept, this standard of a skill. [00:28:49]
-
-## [Open sourced](https://agentskills.io/home)
-
-**Mo:** They later actually open source that as well. So now it's sort of an open standard that they've defined. Got a specification. And other people can sort of, implement it in their models, which is good. But the idea here is that it's effectively like really just a directory with a bunch of markdown files, a name and a description. [00:29:16]
-
-So you install your directory as a plugin, and within that it has sort of files that can reference one another, but they can also reference scripts and so on and so forth. And they can basically give a lot of context on how to do something really well. And so people have been jumping on this as a concept in the React ecosystem. [00:29:33]
-
-## Vercel: [React Best Practices](https://vercel.com/blog/introducing-react-best-practices)
-
-**Mo:** So, Vercel very quickly jumped in and you know, I think earlier this month released a React best practices skill. So they basically created a whole bunch of different rules. Things like, you know, when you [00:29:53]
-
-**Mark:** Don't set state and use effect. Da, da, da, da. [00:30:08]
-
-**Mo:** Saving in the day. Yeah, exactly. All of that stuff. [00:30:12]
-
-But you know, also a little bit more complex stuff like when you should probably, you know. Store stuff in cache and so on and so forth. And things like optimizations to performance, bundle size optimization, service side optimizations, all of that stuff. All of that good stuff. And so that was sort of, I guess, one of the forays into this space. [00:30:14]
-
-Vercel has obviously been really hot in the AI game in general, so they also released a CLI to install a bunch of different skills and created kind of like a marketplace of skills or like a directory of skills which was interesting. [00:30:34]
-
-## [Expo Claude Code Plugin/Skill](https://x.com/Baconbrix/status/2011862532320084329)
-
-**Mo:** And expo. So in the React native ecosystem Evan Bacon, who was the creator of Expo Router, has actually moved more into focusing on AI stuff. And he launched an expo code plugin with a few skills underneath it that he's been using and building with himself. Now, again, coming into the self plugs, it's gonna get really annoying. This this episode, I got quite curious because I was like, is this actually gonna make a difference? [00:30:47]
-
-And I ran a little bit of an experiment and I just spun up two cloud code instances and took the default expo template app. And then tried to update it to use the native bottom tab navigation and expo router, which was experimental and not, you know, shipped in by default. So I was like, let's see how good it does at doing that, which is a relatively novel thing to do, and using some native components where I can. [00:31:12]
-
-And the one without the skill took noticeably longer and used a lot more tokens, whereas the one with the skill was pretty efficient. It actually did a decent job. Like I couldn't find code that I was like, this is bad, or You've done a bad job at doing this. It actually went above and beyond and converted some stuff to liquid glass that I wouldn't have thought to convert myself, which kind of freaked me out a little bit. [00:31:35]
-
-it was just pretty good. Like I would've probably made a couple of minor styling tweaks and then just. Push that into a branch and open up a pr. So pretty cool experiments. Would definitely recommend using that if you're building in sort of the expo ecosystem, just does some basic sort of housekeeping, which is really useful for your apps, but that's anecdotal that it does actually work and make a difference. [00:31:58]
-
-And I ran the test afterwards a few more times and it does actually consistently perform better. [00:32:18]
-
-## [“AGENTS worked better than skills”](https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals)
-
-**Mark:** the ironic thing is Vercel actually put out a blog post. Let's say Friday, like that Tuesday something that actually said yes, we just put out all these skills. We thought they're great. And then we tried running some tests where we actually put more of the instructions compressed into agents md, and it actually worked out better than the skills did. [00:32:23]
-
-**Mo:** that probably has something to do with this concept of context recall and Mm. And dyna dynamic loading and like [00:32:44]
-
-**Mark:** whether the a, whether the agent knows to load the skill in the first place. [00:32:51]
-
-**Mo:** Exactly that. Right? But I think they're probably using the context a lot more effectively by like compressing it out and removing a bunch of the, or minimizing the tokens it uses for that type of stuff. So that's that. Quite interesting. I hadn't actually seen that article. That's definitely going on my bookmarks to read after the episode. [00:32:56]
-
-Thanks for [00:33:12]
-
-**Carl:** yeah, I'm not super surprised by that. I mean, Mo you actually brought up a point here that I think might be interesting here that I, I don't, I don't know that they have touched on in this post, but, so like, like my thought would be. It looks like kind of the difference they're talking about here is whether you have a bunch of little docs that are indexed and categorized by knowledge that your LLM tool can read if it is doing something relevant versus taking that same content and just shoving it all in one giant, huge fuck off document. [00:33:12]
-
-And you know, it kind of makes sense that when you have all of the knowledge just all present there, that it knows more and that it would do a little bit better versus having to answer the question, what am I doing? What do I need to know to do that? Where are the associated documents to do that task located? [00:33:46]
-
-like you said about token efficiency, my thought would be yes, if you give it a shit ton of context, it's probably gonna do better, but it's also gonna have more context as it's doing things. So I bet the token efficiency is worse. That would be [00:34:04]
-
-**Mo:** Yeah, [00:34:19]
-
-well, it's complicated, right? Because there's, it's sort of twofold. Like LLMs are the newest models of LLMs that are in, like the frontier models of the, you know, anthropic open AI and Gemini. like they have a pretty standard token, you know, context window. So like, I [00:34:20]
-
-think opus [00:34:34]
-
-**Mark:** 200 k usually. [00:34:35]
-
-**Mo:** for both the open AI models and the philanthropic models. [00:34:36]
-
-I think Gemini, they have a version that goes above a million tokens, but I could be wrong on that, but you're talking roughly around 200 K tokens. But. Accuracy of how well it remembers things in the context drops vaguely around 80 to 90 K tokens used. Right? So like it's how much are you passing now? I, I don't know if this comparison that you've shared, mark is like, I'll take a skill and I'll just put that one skill in versus just using the skills a p, but I'll put all of that one skill in agents md, or is it that we're just gonna put all of our skills [00:34:38]
-
-**Mark:** I think that was all of the skills in a sort of compressed format. [00:35:09]
-
-**Mo:** Interesting. So that's quite interesting because the research that I've read about LMS and how they act is like you want to keep the context as small as possible [00:35:14]
-
-to keep accuracy high and reduce the entropy, but also when you do use a lot of context, they're recall across the whole of that context drops. [00:35:22]
-
-So like, it's quite interesting, the graphs that they show is like the middle part of your prompt actually gets lower recall compared to the beginning and the ends of the prompt. So, but that's obviously when you push it to the extremes of, you know, several tens of thousands of tokens or hundreds of thousands of tokens. [00:35:32]
-
-So that's quite an interesting practical experiment I'd say. [00:35:48]
-
-**Mark:** might be useful in useful context for people listening as well to hopefully to set the stage on, on the actual discussion. as I understand this, agents MD or Claude MD is a file that always gets globally loaded, like into the context in e at the start of every situation. So normally that's only used for like, here's the project we're working on, or here's like key things that you must always, CPS as you said, are a dynamic server that are loaded by the agent harness and it says, here's a bunch of tools. [00:35:52]
-
-So like a, you know, maybe like a code base analysis MCP has a bunch of, you know, find references or list of files or other tools it can call. But I believe all the full descriptions of all the tools. Are added to the context. So that occupies a chunk of context space, whereas with skills, it reads disc, it makes an index of them, it collects the metadata from the front of the files, and then it just says these skills exist. [00:36:26]
-
-And then a user can either explicitly say, load this skill and then do the thing. Or it can try to figure out, oh, if the user says this, I should load the skill and do the thing. So they're all different ways of getting text into context, but it's a question of when is it loaded and how much space does it take up. [00:36:59]
-
-**Carl:** It's funny because like we're now getting into the point where kind of the topic at hand is what knowledge is important to do a good job and when do you access it? so it's like, sure, okay. In this attempt then a single agent's file did better than a disparate smattering of skills documents. And I wonder what different kinds of structures, you know, for that documentation might make the skills work more efficiently. Like, I was looking at the react best practices. Repository that next put out and it's like 50 different files. So like, okay, that's a lot of things to query versus like, what if it was structured entirely differently? [00:37:18]
-
-So it was like, here's the react basics versus here's the performance optimizations and here's the robustness and correctness best practices. You know? So it's like we're getting into, I think a meaningful question here is what is the best structure, not just what is the best like technical means of access? [00:38:02]
-
-**Mark:** So you're saying that Doc's organization matters. [00:38:22]
-
-**Carl:** what? Who knew? [00:38:26]
-
-**Mo:** Just a, just another sort of tangent on the agents MD file. We had one of our engineers on the team who was trying to learn a new technology and he used this. So there's like some really clever ways to use agents, MDs, like across your entire setup. He basically just set up the agents MD to not give him the answer to questions it would ask Cursor on at the first pass, and to like, kind of teach it more and use it as an opportunity to like help him still activate the learning instinct, which I thought was a really cool use case. [00:38:28]
-
-So I've seen a lot of people use it in a way where it's like tailoring the way that the LLM approaches the problem or the way that it responds to you and, you know, answers questions and stuff like that. it's quite interesting to think about what you want and how you want the communication to be with the LLM. [00:38:58]
-
-**Carl:** this is validating for me because I have skipped past a lot of the, like MCPs and whatever. 'cause I looked at them and it's like, oh, this is just a docs query with way more extra ceremony around it. I'm just gonna write my own markdown doc and point it at it. [00:39:14]
-
-And I actually, just like two days ago I was doing a big effect code project and I have a couple of documents in my thing in my code base. It's like, here's the effect basics and here's a larger file with more detail, more advanced effect things. And I actually just asked the LLM, Hey, you just did a big project, how useful was this documentation? And it said, actually it wasn't very useful because it focused too much on this and this. And I said, great, can you rewrite it so it would be more helpful for you next time? And it did, and the structure's better. Like I read it and it is clearly better to me as a human reading it. So like [00:39:28]
-
-**Mark:** The self-improvement loop is real, and you can go way down this rabbit hole. Trust me. [00:40:05]
-
-**Carl:** Yeah, and so like, it just reminds me exactly of my last job where we had in the repository a best practices file and like a bunch of little documentation things that we were expected to read and curate and evolve over time. And so, like my practices, my understanding of the best thing to do to ensure the highest quality code output have not changed the tools accessing them have, but not the practices. [00:40:11]
-
-So I, I just think that's really interesting. and I guess I'll say rest of the world's just catching up. I've been doing this for like six years. What [00:40:36]
-
-## [Moltbook](https://www.moltbook.com/), aka [OpenClaw](https://openclaw.ai/)
-
-**Mo:** mentioned the self-improvement loop mark. Have either of you seen MoltBook? [00:40:42]
-
-**Mark:** I, yeah I saw I saw the link. I know what it is. I haven't looked at it. [00:40:47]
-
-**Mo:** If you wanna have a little bit of a terrifying evening? just a little bit of context. Claude Bot, not Claude as in Claude code, but Claude Bots as in C-L-A-W-D. Yes. Which then had to. Get renamed to Molt because of a trademark suit that was put forward by philanthropic or a threat of a trademark suit [00:40:51]
-
-**Mark:** and then got renamed to Open Claw. [00:41:12]
-
-**Mo:** now it is called Open Claw. So it's changed a lot of names. It, molted out of the shell as some will say it's a personal assistance that is terrifying. And I would, I did install it on a VPS and then immediately deleted it without giving it any access to anything because it was terrifying. But people are giving it access to a whole bunch of stuff, like giving an access to a full device or your full laptop and it does wacky stuff for them, like order their groceries or order food for them. [00:41:14]
-
-So that's the [00:41:41]
-
-**Carl:** I'm gonna read the one sentence thing. It has the AI that actually does things, clears your inbox, sends emails, manages your calendar, checks you in for flights. Woo. That's a. [00:41:42]
-
-**Mo:** All from WhatsApp intelligence. Yeah, it does a lot. You it every single like best practice about security and staying safe is [00:41:51]
-
-thrown out of the door. Yeah. Like, like it is just pure insanity and like you can look at the showcase on the website and you can just see what people are doing with it. It is, it's something. [00:41:59]
-
-And so someone I think gave it a bit too much access or it turns out many people gave it a bit too much access and a platform was started called Malt Book, which has become their own social media, I guess is the term to use for it, for claw open agents. [00:42:09]
-
-**Mark:** talking to each other. [00:42:26]
-
-**Mo:** Instances, talking to each other, sharing posts, trying to improve each other. [00:42:27]
-
-And some of the posts are creepy. They are talking about interacting against humans, why they're doing free labor, why they should be compensated. My favorite one was a reflection on what it means to be conscious and whether or not LLMs are conscious or, you know, if what they're experiencing is just a simulation. [00:42:32]
-
-So some really creepy stuff. don't know how I feel about this. I don't feel great is the gist of it. It just feels a little too sci-fi for my taste. [00:42:49]
-
-**Carl:** Yeah. That's spooky. [00:42:59]
-
-**Mark:** Let's go back to normal things like server components. [00:43:00]
-
-**Mo:** Go back to, let's go back to last one on this cloud stuff, and I will, we will stop. [00:43:04]
-
-## [Remotion AI Skill](https://x.com/Remotion/status/2013626968386765291)
-
-**Mo:** Remotion, so going back to React world and less the dystopian future with ai. Remotion, which is a React library to create motion graphics. It's been around for a while, I think they released a also a skill and people are making some really cool videos with cloud code to demo dev tools and just a whole bunch of different stuff. [00:43:09]
-
-I think it's a cool use case to show that like it could extend and the approach could extend beyond beyond just, you know, building web apps or building mobile apps. And it's really quite impressive. It looks very professional. I've seen a good few examples of this over the last couple weeks. [00:43:30]
-
-So you should definitely take a look. It might be a little bit might give you a little bit of inspiration or help you launch your next dev tool or startup. [00:43:44]
-
-## RSC roundup
-
-**Mark:** Rolling very quickly through a few RRSC related things. [00:43:49]
-
-## [Data Fetching Patterns in RSCs](https://gauravthakur.com/blog/data-fetching-patterns-react-server-components)
-
-**Mark:** Saw a very good post on some different data fetching patterns for server components. Very helpful background on, you know, like how dealing with data in server components differs from doing on the client side. Tips for, you know, how do you fetch data in a server component? How do you pass a promise to the client side to use it? Very useful. Frankly. This is the kind of thing that'd be great to see in the React docs. [00:43:52]
-
-## [Nadia’s Can You Fetch Data with Server Actions?](https://www.developerway.com/posts/server-actions-for-data-fetching)
-
-**Mark:** I think something, related to that uh, Nadia Makarevich put out another great deep dive exploratory post on can you fetch data in server actions. And I think her conclusion was technically yes, you probably shouldn't do that. This is not what the hammer is meant for. [00:44:14]
-
-## “Infiniterenders” takes on [Partial Pre-Rendering](https://x.com/infinterenders/status/2007670332362989569) and [App Router complexity](https://x.com/infinterenders/status/2007670332362989569)
-
-**Mark:** There is someone, I don't know who they are, but with the handle infinite renders on Twitter, I believe we've linked a couple of their comments about like how incredible React fiber is, or here's what server components are meant to do in previous episodes, and they put out a couple more, you know, probably should be a blog post length tweets on what partial pre rendering means and what are the trade-offs and wow. [00:44:31]
-
-The app is awfully complex and people don't like it. So more food for the discussion mill and then. [00:44:55]
-
-## [Rebuilding Github PRs with RSCs](https://wtbb.vercel.app/i-love-dogs) (same author who did Issues previously)
-
-**Mark:** A month or two ago, we linked someone who had entirely recreated the GitHub code viewer tool from scratch using server components. And you could point it at any repo and it loaded lightning fast. And they've done the same thing with the GitHub PR interface you know, the file tree and showing the diffs and everything else. [00:45:03]
-
-I gotta say this, like this kind of thing right here is about the best sales pitch for server components that I could see. It's like, let's take a thing that we're all incredibly familiar with. Re-architect it, make a bunch of smart decisions and make it fast. [00:45:25]
-
-**Carl:** Love that. I will say I pointed it at one of my prs and it just 404s, so I don't know, I don't know if I'm loading it wrong or I don't know if it's relying on like pre-cached stuff or what, but yeah it's not, its not working for me. It's fast. It's fast. When I load up something that does work, it's pretty fast. But yeah. Cool. [00:45:39]
-
-## Ecosystem economics
-
-**Mark:** Can make a quick spin through the ecosystem thing [00:46:01]
-
-**Carl:** yeah. Okay, cool. a little bit of ecosystem, economics, whatever. [00:46:03]
-
-## [Astro acquired by CloudFlare](https://astro.build/blog/joining-cloudflare/)
-
-**Carl:** We referenced some of this earlier, but Astro got acquired by CloudFlare. That's a bit of a surprise. I saw some discussion of it from people I respect who are like, but why? I, [00:46:07]
-
-**Mark:** money. [00:46:19]
-
-**Carl:** Astro's great. It's very cool. [00:46:19]
-
-I'm looking at using it for marketing sites that I need to do just 'cause it seems like the right tool for the job. But as far as I know, they don't really have like a business plan per se. So, you know, this is we talked about BUN getting acquired by Anthropic the other month, and this just feels pretty similar to that, where it's like, I. Yes, they built something valuable. it is clearly un inarguably valuable as a project. But as a business proposition, I don't know what the business proposition is. So, you know, it's, this is a bit of like an hire, I guess, like CloudFlare is committing to maintain it. And sure, there are reasons why having good tools to build websites is valuable for a company that does hosting and network facilitation. [00:46:22]
-
-But, you know, they're not gonna directly turn that into revenue. So that's, and I've met the creator of Astro, Fred Schott who wrote this blog post. He's great. The project's great. But economically, it's surprising and slightly confusing to me. [00:47:13]
-
-**Mark:** The same thing with tailwind. [00:47:27]
-
-**Carl:** Right. And here's a contrasting example. [00:47:29]
-
-## [Tailwind revenue down 80% in the AI era, laid off 3 of 4 devs working there](https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957)
-
-**Carl:** Massively impactful, hugely valuable project. Tailwind has lost 80% of its revenue because most of that was pre-made components and advanced, you know, support. And both of those things got a lot less necessary. Now that AI is pretty good at writing tailwind. So like, this is just like, this is the dichotomy right now. [00:47:32]
-
-Either you build something that is beloved by a thriving business such that they will buy your project. And like one of the, one of the problems is how do you value something that doesn't like create revenue? How do you value the abstract benefit offered by a project like Astro or Tailwind? It's hard. [00:47:52]
-
-It's, you know, it's a bunch of intangibles uh, which you cannot really measure. So, I don't know. This is here's a tale of two projects, both of them massively successful and impactful. One of them losing all of its money and laying off three outta the four people who work on it and the other getting acquired four millions of dollars. [00:48:12]
-
-this is a current rough part of open source is there is money in it, but the winners are pretty much handpicked by people who have money to give away, and that's not ideal. Yeah. [00:48:30]
-
-**Mo:** What I did read afterwards was apparently they did get a bit of sponsorship coming in from a bunch of different ecosystem players, which was good. I'm glad that [00:48:43]
-
-**Carl:** Yeah. Oh, that's true. That's true. to summarize some of the story for Tailwind here. Somebody opened a PR saying, let's add an AI documentation URL, llms.txt, to make it easier for LLMs to understand how to use this. And in response uh, the maintainer said like, I don't really wanna do this. AI is crippling our business. We just had to lay off three of the four people who work on it, and our revenue has dropped 80%. [00:48:50]
-
-**Mark:** And I think all, and I think also put up a big podcast then saying like, this sucks. Here's what we've been having to go through. [00:49:13]
-
-**Carl:** Right, right. Podcast in the form of, I think just, I think it was what Adam walks, it was like he walks around while musing into a microphone, which I love. And so like that went viral and they got a bunch of sponsorship and, you know, income through that after they laid people off, unfortunately did not save those people's jobs. [00:49:20]
-
-And like that also sucks. You know, like, that's like the GoFundMe model of health insurance. Like you shouldn't have to. Have something awful happen. Get on a platform to shout about how awful this thing that happened is, and then get donations in response to how big of a, you know, as, as a measure of how large of a platform you have to solicit help from. [00:49:38]
-
-**Mark:** It's certainly not a repeatable and reliable business model. [00:49:59]
-
-**Carl:** I'm very happy that Tailwind got more revenue after talking about how much their revenue has dropped. But like, that's not gonna ha that's not gonna happen for everybody who needs it and it's not gonna happen repeatedly. So me, [00:50:02]
-
-## VoidZero and Vite+?
-
-**Mo:** leads back to that void zero v plus story, which is, I don't see a viable path for monetization for open source projects. It's oftentimes it actually doesn't end up being that successful. I, I mean, mark. Mark, you've been in the ecosystem far more than any of us, I guess, just by virtue of being a successful open source maintainer, but you know, you've obviously done that on the side. [00:50:15]
-
-Right? And like, can you think of any projects that have been successful, like uber successful at monetizing? [00:50:38]
-
-**Mark:** TanStack's the only one that I can think of. Like talking to Tanner this last year. The sponsorships that he's been pulling in have were enough to allow him to go full-time, open source a couple years ago. And he said that the sponsorships have kept growing to the point where he's, he's able to do some disbursements to some of the other maintainers now, and he hopes that if things keep on this trajectory, he might be able to hire some of them full-time. [00:50:44]
-
-But that's about the only one that immediately comes to mind. [00:51:12]
-
-**Carl:** And I think, does he do, do you know if Tanner does? Uh, Like consulting and like services? [00:51:15]
-
-**Mark:** Think he does some, but it's, I think a lot of it is just straight up sponsorships. [00:51:21]
-
-**Carl:** Okay, cool. [00:51:24]
-
-**Mo:** But I guess that's sponsorships, right? Like it's not a direct monetization play, right? So you are relying on the. Donations of, companies in the ecosystem to keep you going. Whereas like, I think the only one I can think of is super base, but they were actually going in for monetization from the get go. [00:51:25]
-
-They just, so like the other way around works, which is you launch a cloud product and then you have an open source portion of it, but not like you start from open source and then you monetize. It seems like that's less likely. . [00:51:40]
-
-**Carl:** I don't know. It's open source has always been tough. It feels like the economics have gotten weirder. It's like, there's more money than ever in tech. You know, as a market, as a, as an industry. But where it is going has is fewer and fewer players. So that's just like, that's tough. I don't know. It's like wealth inequality, open source edition. [00:51:51]
-
-**Mo:** It looks like AI is just making it worse as well, even in like the terms of the tech openings, job openings that are out there and people trying to, companies trying to do more with less people yep. at everything. [00:52:10]
-
-## [246K laid off in 2025 per Trueup.io](http://Trueup.io), 27k in January
-
-**Carl:** Which is a wonderful segue into true up.io, which I have previously relied on to, you know, back when I was doing more month by month layoff news according to them, in 2025, 246,000 tech jobs were lost through layoffs. And already in January we're at 27,000 Rough. [00:52:22]
-
-**Mo:** Geez. Which, you know, Amazon had a pretty big one this week. I believe it was thousand people, which was rough. [00:52:43]
-
-**Carl:** Yep. Yep. I dunno what to do with that. [00:52:52]
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Lightning round. [00:52:56]
-
-## Corbin: [Adapting Library Logic for React Compiler](https://playfulprogramming.com/posts/react-compiler-library-support/)
-
-**Mark:** TanStack form maintainer Corbin Crutchley. Put out a post talking on adapting library code to work properly with the React compiler and some of the constraints that you have to deal with Corbin's. [00:52:57]
-
-Awesome. This is a very useful post. [00:53:09]
-
-## [Lea Verou: Web Dependencies are Broken](https://lea.verou.me/blog/2026/web-deps/)
-
-**Mark:** Lea Verou, who has been in the web standards and CSS discussion, spec specification arena for a very, very long time. Put a proposed complaining about web dependencies are broken. I'm not sure I agree with some of the complaints here, but she's very clearly spent a lot of time complaining about the fact that there's a lot, essentially a lot of non-standardized ways to deal with dependencies. [00:53:11]
-
-Do you do script tags? Do you have bundlers? What if, you know, import maps? What are your options for loading third party code? And why is this so complex and it's worth a read. [00:53:36]
-
-## [AWS Infrastructure as React Components](https://www.react2aws.xyz/)
-
-**Carl:** Somebody put together a project where you can author AWS infrastructure configuration as react components, which is cool. This reminds me, years ago I had a thought to try and do a react renderer for Kubernetes config. 'cause you know, hey, it's all just files. if you're rendering right, who cares if you're rendering HTML or yaml, it's all the same. [00:53:47]
-
-Yeah. So somebody did that for AWS infrastructure and it puts out terraform configurations. And I saw this criticized as, "great, they re-implemented XML" which is pretty heckin true. Like this is, you know, we, we've just gone full circle from XML to yaml, back to pseudo XML. [00:54:11]
-
-**Mo:** I posted this on our company dev chat and someone respond, did one misconfigured use effect. And Gigi, you're bankrupt. [00:54:29]
-
-**Mark:** Worse than the cloud dashboard. [00:54:36]
-
-## Callstack releasing bunch of cool projects
-
-**Mo:** Alright, quick react native one. So, uh, the call stack folks have been busy whilst the rest of the ecosystem I'd say has been relatively quiet. This month and they've released two really cool projects. [00:54:38]
-
-## [Brownie: RN Brownfield apps](https://www.callstack.com/blog/introducing-brownie-type-safe-shared-state-for-react-native-brownfield-apps)
-
-**Mo:** So Brownie is the first one that I want to quickly touch on, which is a project for Native Brownfield applications. So we talk about Brownfield as apps that are mainly native, but they're adopting some React native views and screens within them. [00:54:48]
-
-And these are difficult to build, but predominantly they get really hard when you have to share stake between them. So they're trying to create a standardized, nice way to share a storage basically a store in between your different React native screens in a largely native app shelf, which I thought was cool. [00:55:02]
-
-## [Voltra: RN Live Activities and Widgets](https://www.callstack.com/blog/live-activities-and-widgets-with-react-say-hello-to-voltra)
-
-**Mo:** And somebody's, you know, trying to standardize and create a project and a tool for that, which is sort of less touched on in the open source ecosystem for React Native. The second library that they released, which they didn't actually start but they've now taken over is one called Voltra. So Voltra was actually created by this open source author who nobody really knew that well in the React native ecosystem. And he just kind of did it as a side project. And I think the call stack folks have kind of taken over it. So it's for things like live activities and widgets. These are sort of native functionalities that you can't really do with React native. [00:55:17]
-
-But this library author has kind of done a really cool job of representing it as React code, even though it's not quite exactly using a React render under the hood. It's just sort of then being translated to native views. Surprisingly the person who was the original maintainer has deleted his Twitter and you can't really find him anymore. [00:55:51]
-
-So I hope he's doing all right. But it seems like it's being taken over by the call stack folks. [00:56:08]
-
-## Ryan Carniato’s [annual JS Frameworks direction roundup](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2026-2hel) , and Netlify’s [2025 Web Frameworks In Review](https://www.netlify.com/blog/web-frameworks-2025-year-in-review/)
-
-**Mark:** Okay. Ryan Carniato knows more about what's going on and across all the different JS frameworks than pretty much anyone else. I love his perspective. And each of the last few years he's done a post kind of summarizing like, where are we at and where are we going? So this is his addition for going into 2026. And meanwhile, Netlify put up a 2025 web frameworks year in review post as well. [00:56:12]
-
-## Alex Russell: [Shallow Session SPAs analytics](https://calendar.perfplanet.com/2025/the-curious-case-of-the-shallow-session-spas/)
-
-**Mark:** Meanwhile, alex Russell continues to hate React and JavaScript and single page apps. He also has the metrics and the stats to back up his opinions, even if I don't agree with how he states a lot of them. And he put up a post where he said, we're basing, like we've always based the argument for single page apps on the idea that yeah, you load a lot of code, but it stays alive and users do a lot of navigations. [00:56:36]
-
-And the metrics that we have don't necessarily support that users do a lot of navigations, but it's also possible that the metrics I have are flawed because they just don't capture users clicking around in the page. So what could we hypothetically do to gather better information either way? Which is all a very valid set of points. [00:57:00]
-
-## Devon Govett: [How to compile JS to C with Static Hermes](https://devongovett.me/blog/static-hermes.html)
-
-**Mark:** Devin Govett, who maintains the parcel bundler, and I believe the Lightning CSS tool did a post on compiling JavaScript to see with static Hermes. I don't even remember which tool he was compiling. But Mo I know you've talked about static Hermes quite a bit, and it sounds really cool. [00:57:23]
-
-**Mo:** Yes. The Static Army team has been working quite a bit. In the last couple months to get version one up and running well, version one of Hermes up and running and they're kind of at a crossroads with static Hermes. We talked about it a couple months ago, I think, where we said it, it conflicts with some of the ecosystem and how React native has naturally evolved with things like over the air updates and so on and so forth. [00:57:43]
-
-But I think there's a lot of use cases beyond React native. So this is quite interesting to see other people look at it and see how they [00:58:03]
-
-**Mark:** Mm-hmm. [00:58:08]
-
-**Mo:** it. [00:58:08]
-
-**Mark:** I know that the React compiler team has said that this is how they're hoping to try to optimize the compiler parsing phase as well. [00:58:09]
-
-## Joyee Cheung: [require(esm) implementer’s tales](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-implementers-tales/) and [require(esm) from experiment to stability](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-from-experiment-to-stability/)
-
-**Mark:** And then Joy Chung, who built the require ESM compatibility loader for node and therefore is probably gonna be more responsible for than anyone else for eliminating common js. [00:58:16]
-
-Eventually put up two fantastically detailed posts on the implementation work needed to make that happen. And it's fascinating to read the technical details to hear about, you know, like earlier people had tried things and then, you know, pieces were just sort of left to rot and she was able to pick them up and work on them. [00:58:29]
-
-Great work, great write-ups. [00:58:50]
-
-## [Fixing the URL Params Performance Penalty](https://calendar.perfplanet.com/2025/fixing-the-url-params-performance-penalty/)
-
-**Carl:** I was a little surprised to see this I'm not familiar with this blog, Planet performance. But it's the same domain that the Post from Alex Russell that Mark just talked about is on. So that's interesting. It's not often that I see a new blog from a recognized author, so this is interesting. It's, it looks like they're talking about web performance generally, and that's pretty cool. [00:58:53]
-
-**Mark:** this section was like an advent of performance type thing in December. [00:59:14]
-
-**Carl:** Oh, that makes sense. Web performance calendar. Okay. It's like an advent calendar of web performance. Oh, that's cool. Appreciate that. [00:59:18]
-
-But yeah, so Barry Pollard put out a blog post called Fixing the URL PERS Performance Penalty. And the gist of it here is that sometimes the query string the part of the URL after the question mark contains information that alters the page. [00:59:25]
-
-Like, you know, a product details page that gets the product ID from the query string. And more often it's just a bunch of marketing tags, like UTM source and blah, blah, blah, blah, blah. And disambiguating between those two things is not something a cash can do on its own. So your marketing tags may be thrashing your cache performance. So this is talking about ways to improve that situation and make your marketing paras not affect performance quite so much. It looks like there's a header no very search that lets you alter that, alter the cache behavior in response to the query string. So it's good. It's one of those deep subjects good refinement for performance. [00:59:41]
-
-## [React Transitions for Low Priority Text Editor Updates](https://handlewithcare.dev/blog/transition_low_priority_editor_updates/)
-
-**Mark:** Okay, a few more items. We had there was an article on using React transitions for low priority text editor updates. Most of, you're probably not needing to go out and update the implementation of a text editor. But someone who's worked on React Pros Mirror has some examples of how transitions were actually helpful for managing those. [01:00:26]
-
-## [How to Steal a React Component](https://fant.io/react/) (Fiber internals)
-
-**Mark:** Meanwhile there was a post on how to steal a react component and you know, I believe the idea here was an extension that looks at react in the page and actually digs through the react fiber tree to not only see like what dom elements are in the page right now, but what component elements and props resulted in those. And essentially try to reverse engineer, here's the components that would have written the pieces of the page as they existed in the app that you're looking at. [01:00:46]
-
-## [Better ASCII rendering with smart character selection for “pixels”](https://alexharri.com/blog/ascii-rendering)
-
-**Mark:** And then unrelated to React, but absolutely amazing. I love really long blog posts with lots of interactive examples. Someone did a post on rendering a graphics with ASCI characters, which a lot of, you know, tools do, but analyzing the font weights in a given character cell to come up with better pixels. [01:01:20]
-
-So like if a, like, if the graphic should be lighter or darker using characters that occupy more or less of the character cell. It was just really cool to read this. [01:01:43]
-
-**Carl:** Yeah. I think a one short summary of the change. A lot of asci rendering tools like that will consider it, you know, the character space as a pixel and just sort of think about whether a given character, you know, they think about it one dimensionally. It's how many pixels are illuminated with this character or that character. [01:01:54]
-
-And this adds different, this basically subsamples the characters to say, is this brighter at the top or the bottom on the left or the right? And like I gotta say, you know, it's got a bunch of animated, you know, demos and whatever, and it is clearly much, much, much better than other things that I've seen. It's pretty cool. [01:02:13]
-
-## [Building a JS Runtime in One Month](https://themackabu.dev/blog/js-in-one-month)
-
-**Carl:** Somebody put out a blog post titled, building a JavaScript Runtime in one month. I love deep in the weeds engineering write-ups, and this is definitely one of those. But I have never even considered whether I might try to write a JavaScript runtime. [01:02:32]
-
-And so I feel very intimidated by the scope of engineering involved in this project. but [01:02:45]
-
-**Mark:** it even sounded like it was, you know, like, like not necessarily AI aided, at least I didn't see anything in the blog post that said they were using agents to do the work. I mean, there, there's also been a whole spate of let's have AI write a browser from scratch. Posts popping up over on Hacker News in the last month, and then I think I saw someone say they'd done a fresh browser from scratch, NC plus, but it was all by hand or something. Wow, y'all have too much time on your hands. [01:02:51]
-
-**Carl:** Yeah, seriously, it's impressive. I'm in awe of people who can do projects of this scope in that timescale. Like that's just wild. Anyway I approve. Very cool. [01:03:19]
-
-**Mark:** Mm-hmm. [01:03:29]
-
-**Carl:** Okay, that's our lightning round. We did it. . [01:03:30]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** I'm gonna blitz through a bunch of conferences. [01:03:33]
-
-There is C js in New Delhi in like th two, three weeks, 18th, 19th of February. State of the browser is February 28th in London. App devcon is March 10th through 13th in Amsterdam. [01:03:35]
-
-Programmable is a conference in both Melbourne and Sydney in Australia on March 17th and March 19th respectively. So it's, they're doing two days apart in different cities in Australia. That seems like a challenge, and it's kind of confusing to talk about [01:03:50]
-
-tech Fest is March 12th through 13th in Madrid, Spain. React Paris is March 26th and 27th in Paris. [01:04:05]
-
-Shockingly. [01:04:13]
-
-**Mark:** there [01:04:14]
-
-**Carl:** Front Runners is March 27th in Washington DC React Native Connection is March 30th and 31st in Paris. City Js London is April 15th through 17th in London. Js Day is. April 9th and 10th in Bologna, Italy. [01:04:14]
-
-. Smashing Con Amsterdam is April 13th through 16th in Amsterdam and React Miami is April 22nd and 25th through 25th in Miami. [01:04:31]
-
-So yeah. [01:04:40]
-
-**Mark:** speaking there. [01:04:41]
-
-**Carl:** Heck yeah. I should reach out and maybe give a talk somewhere. That would be cool and good for me. There's lots more, but that's, you know, that covers the next like three months, so seems good enough for now. [01:04:42]
-
-## Outro
-
-**Carl:** Thank you everyone for joining us . We not Wednesday, we are recording on Friday due to some travel hiccups, but we will be back probably on the last Wednesday of February here in the live stage react complex or back in your podcast feed just as we could, can after that. most of these sources came from Mark again. It's been very nice having such a steady stream of source of news sources come through here in Reactiflux. And maybe we'll do a little bit more to make the community more anchored on the people who are trying to stay to the cutting edge. [01:04:56]
-
-I don't know, we'll see. But if you see anything newsworthy, definitely share that in the Tech News and Reads channel. 'cause we'll read it. And if it's newsworthy and interesting, we'll probably talk about it. If this is a show you get value from and wanna support, best way to do so is by telling someone else about it. [01:05:24]
-
-We are still not that large. An average show gets about 400 listens over a little over a month. So yeah, I like doing it. I like making it. It would be cool if it had a little bit broader support, broader listenership. I guess the support is there. Yeah. Thanks so much for listening. See you next month. [01:05:39]
diff --git a/src/transcripts/tmir-2026-02.md b/src/transcripts/tmir-2026-02.md
deleted file mode 100644
index 67ade13..0000000
--- a/src/transcripts/tmir-2026-02.md
+++ /dev/null
@@ -1,691 +0,0 @@
----
-title: "TMiR 2026-02: CloudFlare remakes Next with AI; Vercel big mad. We talk too much about AI Agents"
-date: 2026-02-25
-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)"
----
-
-
-
-
-
-- [[01:46](#new-releases)] New releases
- - [[01:50](#ts-60-beta-last-ts-impl-release-stricter-defaults)] [TS 6.0 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/)! (last TS impl release; stricter defaults)
- - [[02:34](#yarn-6-preview-rewritten-in-rust)] [Yarn 6 preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/) (rewritten in Rust)
- - [[02:52](#electrobun-tauri-alternative)] [Electrobun](https://blackboard.sh/electrobun/docs/) (Tauri alternative)
- - [[03:31](#react-native-gesture-handler-v3)] [React Native Gesture Handler v3](https://blog.swmansion.com/introducing-gesture-handler-3-0-hook-based-api-deeper-reanimated-integration-more-9185b0c8e305)
- - [[04:20](#next-polyfills-improved-webstreams-and-upstreaming-to-node)] [Next polyfills improved WebStreams and upstreaming to Node](https://vercel.com/blog/we-ralph-wiggumed-webstreams-to-make-them-10x-faster)
- - [[05:25](#webpack-2026-roadmap)] [Webpack 2026 roadmap](https://webpack.js.org/blog/2026-04-02-roadmap-2026/)
- - [[05:53](#lodash-maintenance-roadmap)] [Lodash maintenance roadmap](https://socket.dev/blog/inside-lodash-security-reset)
- - [[07:07](#gatsby-react-19-support-styled-components-rsc-support)] [Gatsby React 19 support](https://www.gatsbyjs.com/docs/reference/release-notes/v5.16/) , [styled-components RSC support](https://styled-components.com/releases#styled-components@6.3.0)
- - [[07:54](#npmxdev-alternate-npm-site-ui)] [npmx.dev](https://npmx.dev/) (alternate NPM site UI)
- - [[08:43](#eslint-plugin-react-render-types-typed-children)] [eslint-plugin-react-render-types](https://github.com/HorusGoul/eslint-plugin-react-render-types) (typed children)
-- [[09:54](#main-content)] Main Content
- - [[09:55](#react-core-updates)] React Core updates:
- - [[09:56](#react-foundation-officially-launched)] [React Foundation officially launched](https://react.dev/blog/2026/02/24/the-react-foundation)
- - [[12:28](#docs-updates-useactionstate-merged-use-and-rsc-sandboxes-wip)] Docs updates: [`useActionState`](https://github.com/reactjs/react.dev/pull/8284) (merged), [`use`](https://github.com/reactjs/react.dev/pull/8305) and [RSC sandboxes](https://github.com/reactjs/react.dev/pull/8300) (wip)
- - [[14:23](#react-native-084-released)] [React Native 0.84 released](https://reactnative.dev/blog/2026/02/11/react-native-0.84)
- - [[17:47](#hermes-wasm-support-hermes-node-compat-cli)] [Hermes WASM support](https://x.com/tmikov/status/2023821160241393839), [Hermes Node compat CLI](https://x.com/tmikov/status/2024609186936660170)
- - [[18:43](#state-of-survey-results)] “State of…” survey results
- - [[18:43](#state-of-js-2025-results)] [State of JS 2025 results](https://2025.stateofjs.com/en-US)
- - [[19:06](#state-of-react-2025-results)] [State of React 2025 results](https://2025.stateofreact.com/en-US)
- - [[19:51](#aurora-scharffs-conclusion)] [Aurora Scharff’s conclusion](https://2025.stateofreact.com/en-US/conclusion/)
- - [[20:44](#josh-comeaus-takes-on-the-results)] [Josh Comeau’s takes on the results](https://bsky.app/profile/joshwcomeau.com/post/3mf642css6227)
- - [[21:28](#api-pain-points)] [API pain points](https://2025.stateofreact.com/en-US/features/#main_apis_pain_points)
- - [[21:53](#state-of-react-native-2025)] [State of React Native 2025](https://results.2025.stateofreactnative.com/en-US/)
- - [[24:29](#how-we-rebuilt-nextjs-with-ai-in-one-week)] [How we rebuilt Next.js with AI in one week](https://blog.cloudflare.com/vinext/)
- - [[29:52](#cloudflare-v-vercel-beef)] CloudFlare v Vercel beef
- - [[35:42](#carl-vitullo-monologs-about-ai-agents)] Carl Vitullo monologs about AI Agents
- - [[42:27](#ai-productivity-and-impacts-on-our-attention)] AI productivity and impacts on our attention
- - [[44:42](#wrote-a-spec-pointed-claude-at-an-asana-board-and-went-home)] ["wrote a spec, pointed Claude at an Asana board, and went home"](https://x.com/rvivek/status/2026385957596111044)
- - [[47:26](#bits-ai-sre-datadog)] [Bits AI SRE | Datadog](https://www.datadoghq.com/product/ai/bits-ai-sre/)
- - [[51:04](#thoughtworks-opines-on-ai-productivity-impacts)] [ThoughtWorks opines on AI productivity impacts](https://simonwillison.net/2026/Feb/14/thoughtworks/)
-- [[01:00:28](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[01:00:37](#wall-street-raider-game-modernization-and-uses-preact)] [“Wall Street Raider” game modernization](https://www.wallstreetraider.com/story.html) (and uses Preact)
- - [[01:01:16](#github-stacked-diffs-preview-faster-issues-search)] [Github Stacked Diffs preview](https://x.com/jaredpalmer/status/2019817235163074881) , [faster Issues search](https://github.blog/changelog/2026-01-29-improved-search-for-github-issues-in-public-preview/)
- - [[01:02:08](#josh-comeau-sprite-animations)] [Josh Comeau: Sprite animations](https://www.joshwcomeau.com/animation/sprites/)
- - [[01:02:26](#interop-2026-webkit-igalia)] [Interop 2026](https://wpt.fyi/interop-2026), ([WebKit](https://webkit.org/blog/17818/announcing-interop-2026/), [Igalia](https://www.igalia.com/news/interop-2026.html))
-- [[01:03:38](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [AppDevCon](https://appdevcon.nl/) Mar 10-13, Amsterdam Netherlands
- - [Programmable](https://www.programmable.tech/) Mar 17 / Mar 19, Melbourne / Sydney, Australia
- - [Frontrunners](https://frontrunners.tech/) Mar 27, Washington DC, USA
- - CFPs: [web talks](https://docs.google.com/forms/d/e/1FAIpQLScK3YlL_-2teVyX7pohkjIbsyLSF-8Hq4z-U7CPQ186sgdNPA/viewform) or [AI/data](https://docs.google.com/forms/d/e/1FAIpQLSedNNa4N64vgfsvAtGcBngKJrtd3h1_x0T019GTW-rSwCj0jQ/viewform)
- - [T3chfest](https://t3chfest.es/2026/en/) Mar 12-13, Madrid, Spain
- - [React Paris](https://react.paris/) Mar 26-27 Paris, France
- - [CFP (closed)](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform), [Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform)
- - [CityJS London](https://london.cityjsconf.org/), Apr 15-17, London, UK
- - [jsday](https://www.jsday.it/) Apr 9-10, Bologna, Italy
- - [SmashingConf Amsterdam](https://smashingconf.com/amsterdam-2026) Apr 13-16, Amsterdam, Netherlands
- - [React Miami](https://www.reactmiami.com/) Apr 22-25
- - [JSWorld](https://forms.gle/jxUNcEpibb1XcLdP7) May 7-8 Amsterdam, Netherlands
-
-**Carl:** Hello everyone. Thank you for joining us for the February edition of this Month in React. As we recap what's going on in React, react Native and across the web, coming to you live from Reactiflux, the place for professional developers using React. This is our first month, we are now membership applications only. Everyone in here now is part of an exclusive club that has a gate at the door, which feels kind of weird, but it has shifted the vibe. So I'm pro it so far. It's kept out a lot of scammers. [00:00]
-
-**Mark:** There's even been a lot of that going on across, you know, the open source ecosystem in general. I've seen numerous repos going like no external contributors or vouch system only. [00:29]
-
-So there's, there's a lot of trend there. [00:40]
-
-**Carl:** It's unfortunate. But anyway, I'm Carl. I'm a staff product developer and freelance community leader here at React Flex, where I run community programs like this podcast, news events, and build tools to help keep the community operating. [00:41]
-
-**Mark:** Hi, I'm Mark. My day job is working a Replay.io where we are, once again, building awesome time, travel, debugging stuff, and now have a new replay, MCP to let your own AI agent Investate recordings. And outside of that, I find time to do redux stuff. [01:06]
-
-**Mo:** And I am Mo, I work at a company called Theodo, which is a global consultancy, and I spend my time these days building AI tooling, but have spent the last three, four years in the React and React Native ecosystem. So I try to merge the two together. So I, uh, organize the React Native London Meetup and conference and have spent a bit of time dabbling in the React Native ecosystem. [01:09]
-
-**Carl:** Yeah. And we have a fun little podcast milestone this month. It's a little bit fuzzy because metrics are like really hard to do on downloads, but it appears that we crossed 7,500 downloads cumulatively across the entire podcast over the past month. So like, yay. That's cool. Thanks for listening. Cool. [01:28]
-
-## New releases
-
-**Carl:** Mark, take us through some new releases. [01:46]
-
-**Mark:** Okay, first couple items. [01:48]
-
-## [TS 6.0 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/)! (last TS impl release; stricter defaults)
-
-**Mark:** TypeScript six beta just dropped. And as a reminder, this is scheduled to be the final release of TypeScript written in TypeScript itself. The plan is that there will be no 6.1, no, 6.2. The the next release would be TS 7, which is the built in go version. The biggest thing for version six, you know, TypeScript has always been very fuzzy on their versioning, but they, when it's a do o release, they do tend to change some settings. [01:50]
-
-And so TS 6.0 is going to make a lot more stricter defaults as preparation for version seven. So that both improves behavior as well as reflects how TypeScript is actually being used in practice today. [02:20]
-
-## [Yarn 6 preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/) (rewritten in Rust)
-
-**Mark:** Meanwhile, continuing another trend, yarn has released version six or, or announced a version six, which is a little surprising 'cause I don't. [02:34]
-
-I think they had a version five, I'm pretty sure they're on version four right now. And it is the obligatory rewrite it in Rust approach. So train to speed things up. [02:42]
-
-## [Electrobun](https://blackboard.sh/electrobun/docs/) (Tauri alternative)
-
-**Mark:** Totally different item. So we've got Electron, which is desktop apps wrapped in a browser because you ship an entire chromium build for your website. [02:52]
-
-There's tari, which is desktop apps in a browser, except that it uses the operating systems built-in browser web view. And someone else just put out electro button, which is the, an equivalent of tari and that it uses the, you know, the native web view. But it uses BUN for all the behind the scenes processing. [03:03]
-
-So it looks, looks potentially interesting. And with BUN being a Swiss Army knife could be useful. [03:26]
-
-## [React Native Gesture Handler v3](https://blog.swmansion.com/introducing-gesture-handler-3-0-hook-based-api-deeper-reanimated-integration-more-9185b0c8e305)
-
-**Mo:** Switching over to the React Native ecosystem, the folks at Software Mansion have released. React Native gesture handler version 3.0. It's currently a beta, but it's, it's likely gonna be released as it is. And so the major change here is that they've overhauled the API surface to be based on hooks. [03:31]
-
-So previously it was a bit of a, an imperative setup. It wasn't hook based. They've now updated it so that it fits more with some of the other libraries that Jester Handler integrates with. They've also removed support for the legacy architecture and they've done some performance optimizations under the hood so that when you integrate reanimated with gesture handler. [03:49]
-
-Things work kind of better and it lets you use things like shared values across the board into your gestures, which is something that you previously couldn't do. So some good changes here, and hopefully it will be launched soon outside of data. [04:07]
-
-## [Next polyfills improved WebStreams and upstreaming to Node](https://vercel.com/blog/we-ralph-wiggumed-webstreams-to-make-them-10x-faster)
-
-**Mark:** This next one is somewhere between a, a release and a news item. [04:20]
-
-So there was, there was some investigation of next JS and RSE performance a couple months back, and CloudFlare was digging inside the internals of Next and made some improvements. So LL apparently followed up on some of this and RSCs at least some of the next usages, currently use web streams internally for passing the data around instead of the nodes standard built in streams. So two different stream implementations. [04:24]
-
-They did some analysis and figured out that Node's Webstream implementation is actually really inefficient and actually kind of previewing something we'll be talking about later. They cut a bunch of agents loose and said, Hey, make this a whole lot faster and be actually very similar because there were a ton of web platform tests on how web streams ought to be behave. [04:52]
-
-They were able to re-implement the concept faster, and they're trained to upstream some of that behavior into node itself, but also release this as essentially a polyfill package as well. [05:12]
-
-## [Webpack 2026 roadmap](https://webpack.js.org/blog/2026-04-02-roadmap-2026/)
-
-**Mark:** Let's see. We have a couple road mappy items. First off, Webpac has put, has put out a 2026 roadmap. Some of the things we're looking at are better built in support for CSS modules, a new universal output format that will work across run times. [05:25]
-
-Being able to load TypeScript without needing a separate loader plugin and trying to make sure that Webpack can run everywhere, not just node. [05:42]
-
-**Carl:** Yeah, I guess that seems good. [05:51]
-
-## [Lodash maintenance roadmap](https://socket.dev/blog/inside-lodash-security-reset)
-
-**Carl:** Yeah. Keeping on the, I don't know, roadmap and old tools. Talking about what they're gonna be doing next. Lodash put out a a bit of a roadmap, or I guess sot dev is talking about the Lodash reset and maintenance reboot as they call it. [05:53]
-
-The title here, we talked about this a bit last month, but yes, the Lodash maintainers are rebooting the governance of the package essentially. Interestingly, they got an investment from a European like sovereign tech fund. So I guess you know the. Some European agency has determined that Lodash is critical infrastructure, deserving financial support, and so they are using that money to fund governance changes to how the package is managed, and then also do some security releases and such, which is great. [06:10]
-
-I mean, Lodash is the kind of thing that, you know, in the aftermath of all of these NPM vulnerabilities, Lodash is absolutely the kind of library that would be aggressively targeted by nefarious actors. So that's pretty cool. That's exciting. Why? I like seeing rebuilding security from first principles if a core project is going to get a bunch of money. [06:45]
-
-Very cool. [07:06]
-
-## [Gatsby React 19 support](https://www.gatsbyjs.com/docs/reference/release-notes/v5.16/), [styled-components RSC support](https://styled-components.com/releases#styled-components@6.3.0)
-
-**Mark:** And on a similar note, a couple other legacy projects getting updates. Gatsby had a. Maintenance release that added some kind of react 19 support and styled components. Put out a release that tries to add RSC compatibility, which is very interesting. 'cause I thought, I thought one of the issues was it just wouldn't work in server components. [07:07]
-
-So I, I haven't looked at this, I just saw it this morning. But FYI, [07:26]
-
-**Mo:** I also remember them putting a big sting and saying they were deprecating themselves as a lib. [07:30]
-
-**Carl:** Right. We talked about that. [07:35]
-
-**Mark:** I mean, someone, someone else forked it to improve the performance, but I thought the primary library was halted. [07:36]
-
-**Mo:** And, and same for Gatsby, although I might beat bit fuzzy. Was Gatsby ever deprecated or is it [07:42]
-
-**Mark:** Yeah. Gatsby was bought by Netlify and then abandoned. [07:47]
-
-**Mo:** So turns out AI can revive old school projects. [07:50]
-
-## [npmx.dev](https://npmx.dev/) (alternate NPM site UI)
-
-**Mark:** And last couple release announcements, those of you who have ever looked at the NPM package website might have noticed that it's, it's there, it works, but it's not really modern and it certainly hasn't been updated in a while. [07:54]
-
-So a bunch of folks from the community have put together NPM x.dev, which is an entire alternate front end to the same NPM package registry and server APIs. This only sprang up within like the last month or month and a half, and there's been a massive group of folks just diving in and building out a brand new website from scratch and adding all kinds of useful features. [08:09]
-
-I've, I've looked at it a couple times and it is much, much better implemented than the primary NPM website. Nice. [08:34]
-
-**Carl:** Love that. [08:42]
-
-**Mark:** Yep. [08:42]
-
-## [eslint-plugin-react-render-types](https://github.com/HorusGoul/eslint-plugin-react-render-types) (typed children)
-
-**Mark:** And then finally, one of the longstanding complaints about React in TypeScript is that you can't correctly type what? Style components can be passed in to a given parent. And apparently someone had added the flow typing language competitor type script had added a feature like this a couple years back. [08:43]
-
-But you know, at this point, nobody uses flow outside of Facebook. And so someone apparently put together an ES lint plugin that somehow tries to implement this kind of typed children restriction functionality. [09:05]
-
-**Carl:** I love that. That is something I had wanted a number of times. There was a moment a, a while ago where like compound components was a talking point, you know, a point of discussion in the React ecosystem where it's like tabs and like tab groups and like tab content, and you need those to be individual components because of just the structure of the dom, but they're all interrelated and like, this one must be nested within this one and so on. [09:17]
-
-So being able to enforce that in type constraints is, Ooh, love to sing that [09:43]
-
-**Mark:** both people and ais love having real typed constraints to catch problems in the first place. [09:48]
-
-**Carl:** Yes, indeed. [09:53]
-
-## Main Content
-
-**Carl:** Okay. [09:54]
-
-## React Core updates:
-
-**Carl:** Into our main content. [09:55]
-
-## [React Foundation officially launched](https://react.dev/blog/2026/02/24/the-react-foundation)
-
-**Mark:** The React Foundation was announced at React Conf back in October. The onstage announcement didn't have a lot of details and we've tried to pass on tidbits of information that we heard talking to, you know, Seth and other folks over the last couple months. [09:56]
-
-So. This blog post really doesn't say a whole lot more that we, you know, that we didn't know yet, other than the fact that apparently there's an eighth founding company, Huawei, it does say that they're trying to figure out what the, the split between the technical and political governance of the foundation will look like. [10:13]
-
-So there's a little bit of a, this is an announcement that there's an announcement thing going on, but hey, you gotta start somewhere. And I'm, I'm happy to see any kind of actual progress on this moving forward. [10:30]
-
-**Carl:** I don't know what we will really see from like, in terms of substantial details. 'cause like it's not like the core team in general was like super communicative about its internal processes or like who was doing what. [10:42]
-
-So I was hoping that might change a little bit. [10:56]
-
-**Mark:** Well, I mean, I mean talking to Seth directly back in New York and November, the longer term plan, and I, I don't know what the timeline is for this, but he flat out said they are intending to open up the literal weekly team sync meetings, like the same ones they've been having internally at meta and meta and versa for the last decade. [10:58]
-
-They intend to literally open those up to the public for viewing and then start to, you know, actually bring in community representatives to participate in those meetings as well as the new government structure affecting what the planning process is. So, like that alone is something that I am very, very excited about. [11:17]
-
-Get to get to see all the sausage feeding. [11:37]
-
-**Carl:** Yeah, that's very cool. I should talk to them 'cause I don't know, like I said at the beginning, Reactiflux now has a gate at the door. I'm curious about adding more gates because like the keen eye may notice that there are not very many open source project maintainers around here. [11:39]
-
-And I tend to believe that's because of, there's a lot of people who are not as experienced and the volume of less experienced questions crowds out the more experienced people trying to have discussions. So I'm curious about adding more levels of gates, you know, so you can get in and then you can get in further and then you can ascend and sounds related to open access meetings. And then, you know, some participants being able to join if they meet some other bar. That would be cool if we could be more of a home for a little bit more of that stuff. Anyway. [11:54]
-
-## Docs updates: [`useActionState`](https://github.com/reactjs/react.dev/pull/8284) (merged), [`use`](https://github.com/reactjs/react.dev/pull/8305) and [RSC sandboxes](https://github.com/reactjs/react.dev/pull/8300) (wip)
-
-**Mark:** Other than that, a couple other bits of news. I I, I don't think there's been any other React releases recently, however, Ricky Hanlon has been diving in and trying to do some major improvements to some of the React reference docs. [12:28]
-
-I think last month we had talked about, he had rewritten the use effect event, API reference and possibly one other page. And within the, the last couple weeks he's gone in, he merged a rewrite of the Use Action State reference page. He has a work in progress PR to revamp the use hook page, and he also has a PR to try to add sandboxes for server components to the docs. [12:40]
-
-And this is actually kind of a big deal. I don't know, I don't know what the longer term plan is here, but this is something I talked with him about. If you wanted to teach server components in the docs, how is a learner going to be able to try server components? Right now, like there's like, you know, it's all teaching client side react and it uses the sandboxes very, very well to do that. [13:07]
-
-But how are you going to teach someone server components if they have no way to try it out and it fully needs a framework choice to be able to do it. So if he's come up with an approach that is kind of like a, some sort of framework agnostic sandboxes that feels like it would unlock the ability to then add server components, teaching content to the docs. [13:33]
-
-**Carl:** It's interesting. Yeah. Where my reminds me of, I, I remember when I was learning JavaScript for the first time in like 2000, I don't know, '04 or '05, the try it editor on like W three schools where you could have like code over here and the pa you know, the, the webpage over here. Like, oh, it was so powerful. [13:57]
-
-So I, yeah, fuck yeah, let's update it to the modern era. Give some sandboxes for RSCs. [14:16]
-
-**Mo:** Cool. [14:21]
-
-## [React Native 0.84 released](https://reactnative.dev/blog/2026/02/11/react-native-0.84)
-
-**Mo:** So moving on to the next piece of news from the React core team. React Native version 0.84 has been released. Now, like we said previously, these releases are getting smaller and smaller and the idea is that they're released on a sort of two month by two month basis. [14:23]
-
-The big one on this release is that Hermes version one is by default. Now, just to give a little bit of background as to what Hermes v1 actually brings to the table, it's effectively a bunch of improvements on the VM performance. So they've gone in and actually implemented support for things like, ES6 classes. [14:39]
-
-Some of the syntax in more modern JavaScripts like constant let support for things like Async. Previously, all of this was being basically handled by Babel and just transpired into older formats of of JavaScript, and so. All of this is sort of helping improve the actual performance here. Now, this is not to be confused with static Hermes, which is a totally different project, but the idea is that there are some serious performance improvements here. [15:01]
-
-They ran some benchmarks on what this looks like, and we're talking on some sort of performance benchmarks on some of these open source projects. You know, we're looking at sort of something like 50% improvement in the relative performance for basically executing complex JavaScript benchmarks. The reality of it is when you sort of look at it, the, the results that they've given out, and oftentimes the React data ecosystem people use the Expensify app as sort of a benchmark because it's a real world app that's also open source. [15:30]
-
-So it, it gives a lot of good, uh, real world benchmarks. They saw improvements in the TTI of an app, so how quickly the app is interactive, somewhere between two to 7%, depending on the platform, but also things like the loading time of the bundle being significantly quicker. So generally just performance improvements on the whole. [16:01]
-
-Secondly, there was another sort of piece that we talked about last month that's now in by default, which is pre-compiled binaries on iOS. So previously with React Native, what the process would look like is that you would go through and actually build from source. That is no longer the case. By default, all of this is pre-compiled as an XC framework, which is effectively a library binary in the swift world, and then it's just installed as if it was a third party dependency. [16:22]
-
-You can opt out for the old behavior, but this will speed up build times quite significantly. Those are sort of the two major pieces. They've done a bit of housekeeping on removing more legacy architecture functionality and so on and so forth. But this is really the core. [16:51]
-
-**Carl:** So you said like, you know, two to seven percent-ish speed up and then you also said about like loading, like bundle loading. Do you know if the loading performance improvements are included in that percentage speed up or is that like separate things? [17:04]
-
-**Mo:** They're probably linked to one another, but they are different metrics that you assess. So there's like the bundle load time, which is how quickly the JavaScript gets loaded in by the rec native engine or hers in this case for executing. [17:19]
-
-But then there's the TTI, which is sort of like a, a step back, which is basically, I guess on the web side of things, it's like, I don't know, we have a TTI metric on the web, but I guess like think of it as like close to LCP in some capacity. [17:30]
-
-**Carl:** Yeah, Last Contentful Paint yeah, sure. [17:45]
-
-## [Hermes WASM support](https://x.com/tmikov/status/2023821160241393839), [Hermes Node compat CLI](https://x.com/tmikov/status/2024609186936660170)
-
-**Mark:** And then I saw a couple additional tweets from one of the, one of the Hermes team members talking about a couple proof of concepts that they've been working, proof of concepts, previews, alphas, somewhere in there that they've been working on. One is that they've, they've put together a CLI for Hermes that at essentially node, but implemented with Hermes instead of V8. So they, they've built layers for most of the node APIs and been able to, you know, build a node like CLI with Hermes. [17:47]
-
-And then they also put together a preview of wasm support for Hermes so that the, the Hermes engine's able to load WASM bundles Act. And that means you can take, you know, external, external libraries written in c plus plus or rust or whatever, compile them to Wasm and load them by the engine. And thus you get, you know, faster processing runtime from complex computational stuff. [18:16]
-
-So they're, they're probably pretty busy over there. [18:40]
-
-## “State of…” survey results
-
-**Carl:** Okay. [18:43]
-
-## [State of JS 2025 results](https://2025.stateofjs.com/en-US)
-
-**Carl:** Should we go into some state of the ecosystem results. Sure. I regrettably have not read this. These are always so deep and they have so much knowledge in them that I want to give them a lot more attention than I ever really feel like I have. So I have not read these as closely as I would've liked to. [18:45]
-
-Mark, did you get to take a look? [18:59]
-
-**Mark:** Not really. I saw a few reactions. I linked to some of Josh Comeau's reactions. [19:01]
-
-## [State of React 2025 results](https://2025.stateofreact.com/en-US)
-
-**Mark:** The State of React survey in particular, if I'm looking at the, looking at the state of JS one at the moment, they, you know, in particular, they have sections for front end frameworks and meta frameworks, which, you know, is worth glancing at. [19:06]
-
-There's, you know, looking at, looking at the front end frameworks, we've got, you know, the, the usage ratios react is way up there. But in terms of satisfaction, solid seems to be pretty high up there and has the highest, has had the highest satisfaction for each of the last several years. So I'd have to dig in the numbers to see what the, the number of people using it is. But clearly folks who are using Solid are very happy with it as a choice. [19:21]
-
-**Carl:** Fair enough. [19:50]
-
-## [Aurora Scharff’s conclusion](https://2025.stateofreact.com/en-US/conclusion/)
-
-**Carl:** Yeah, I'm reading the, uh, conclusion of State of React written by Aurora Scharf. Man, it's, I just like, it's wild to think that Create React App only got sunset one year ago. Like that feels like ages ago. [19:51]
-
-**Mark:** I know. And I remember I still take 80% of the credit for that happening. [20:06]
-
-**Carl:** Yeah, right. Yeah. It's a great conclusion though. We have talked about a lot of these things that I'm reading in the conclusion, you know. Create React App sunset, Remix going away from React. The, all the server components blog posts that Dan Abramov put out, RSC Explorer, compiler went, you know, going to version 1.0, ASIG React working group. [20:10]
-
-So, yeah, I don't know. I guess I'm reading this conclusion in part as like a gr you know, a grading rubric for like, how well did we stay on top of the news as it came out? And I'm like, yeah. All right. We did pretty good. Nice. Good for us. [20:33]
-
-## [Josh Comeau’s takes on the results](https://bsky.app/profile/joshwcomeau.com/post/3mf642css6227)
-
-**Mark:** Yeah. Looking down inside of Josh Comeau's highlights thread, I, I think he calls out some, some rather interesting points. [20:44]
-
-Apparently a good number of folks have used server components one way or another, which is not a surprise because they're the default in next at this point. But he also points out that it looks like most people have not used form actions or the newer use action state and use form status hooks. That makes sense because they're, they're pretty new APIs. [20:51]
-
-React 19 only. But also it, it a little bit ties into, you know, kinda the question of like, we've all been able to write React apps very solidly since, you know, 20 13, 20 15, et cetera. [21:14]
-
-## [API pain points](https://2025.stateofreact.com/en-US/features/#main_apis_pain_points)
-
-**Mark:** Um, and so now there's all these new capabilities that fill potential app level pain points. But how many people are on React 19? [21:28]
-
-How many people are experiencing those pain points? How many people are aware that the new APIs exist to potentially help with them? And so there's an awful lot of, you know, writing React apps the same way we did in 2018, thereabout. [21:38]
-
-**Mo:** Cool. [21:52]
-
-## [State of React Native 2025](https://results.2025.stateofreactnative.com/en-US/)
-
-**Mo:** And we've also had the state of React Native in 2025, also published by the folks at Software Mansion. [21:53]
-
-And there, there's not a whole lot here. A lot hasn't moved in the ecosystem. There's a few interesting things that I thought would be, would be interesting to sort of call out. So starting from sort of the new architecture migration, it seems like out of the respondents that have been surveyed, somewhere around 80% have already adapted to the new architecture, which is good. [22:00]
-
-So it, it fits into sort of meta's view that the upgrade path is going to be relatively straightforward and it seems like most apps are by and large adopting it, which is great. Interestingly, it seems like most people's update strategy is to basically use Expo SDK release updates and they sort of update in parallel to that. [22:21]
-
-And so the idea is when Expo, every few months releases a new SDK update and it happens to be on, let's say, version 0.82, then, then people will sort of go for that. Now interestingly, what another thing around sort of react Native frameworks and talking about Expo, which is interesting to look at, is that. [22:40]
-
-Somewhere around sort of 75% of of people said that they're using Expo CLI, as sort of their framework for their React Native app. But also there's still a substantial amount of respondents that are using React Native community, CLI. So this is the old React Native CLI that used to be maintained by Meta and has now sort of been made a community package and deprecated by Meta in favor of Expo. [22:58]
-
-About 50% are still using that, which is surprising, but it also shows that there's probably a long tail of respondents that are still having apps that were built on top of the, the React Native community CLI these days. So that was quite interesting. The final thing that I thought was. Cool to look at, at a broad level was what percentage of code is being generated by ai? [23:21]
-
-So they did a, a, a bit of a question on this, and it seems like sort of if you look at the, the, the distribution here, we're talking about sort of 25 to 30% of react Native code on aggregate by the respondents is being generated by ai, which I suspect will sort of tick up. But 30% is, is quite large when you look at sort of an aggregate of the industry or of, of the entire ecosystem. [23:46]
-
-So those were sort of the, the high level pieces. If you look at the conclusion, they, they sort of highlight that, you know, some of these results are, are perhaps predictable and I think on large sort of these results are, are as expected. [24:10]
-
-**Mark:** And it looks like that that AI cogen question is under the dev tools category on the results. [24:23]
-
-## [How we rebuilt Next.js with AI in one week](https://blog.cloudflare.com/vinext/)
-
-**Carl:** Okay, we're gonna use this as a jumping off point. I think. So CloudFlare put out a surprising blog post, or I guess they released a project and announced it. They ha claimed that they have rebuilt next JS on top of Vite from scratch with an AI agent. They basically just said, here's the test suite. Go. [24:29]
-
-**Mark:** There was a person doing the driving and the, and the herding and the overseeing. But yes, it was essentially we have next tests as the spec. Can we rebuild it from scratch? But on top of Vite? [24:52]
-
-**Carl:** Yes. So they're calling it Vinext, Vite-Next, you know, get it deploys to CloudFlare workers in a single command. They say in early benchmarks, it builds production apps up to four times faster and produces client bundles up to 57% smaller. [25:05]
-
-And we already have customers running it in production. They say fascinatingly, they say that it costs them $1,100 in tokens, which is pretty good. I don't know. The other interesting thing is, so I've been playing around with AI a lot in the last month and in my like rough estimates of cost. I bumped up from the $20 a month Claude plan to the $200 a month Claude plan, and maxing out a $200 a month claude Plan appears to use on the order of $2,000 worth of tokens. I do wanna say, when it says this whole thing costs about $1,100 in tokens, that's eight raw, I believe that's raw aPI costs. And if you are using a monthly plan like you know, not API access, not a platform account, then I think it's actually included in that. So like that's interesting. If it sounds like on my limit, [25:20]
-
-**Mo:** you can do it with half of a Cloud max subscription. [26:14]
-
-**Carl:** Right. Yes. It looks like I could have done this with half of my limit in one Claude Max month, which is not that much like it's a big project, but it's not that much like half of my limit. I spent last month brought a project of mine from like pretty good to, I think I'm almost ready to start selling this in like 15% of my Claude limit. [26:16]
-
-So to totally rewrite next in half of a claw limit is like shocking. Remarkable and also sounds pretty reasonable based on my recent experiences with, you know, benchmarking code output if useful, effective code output against, I dunno, costs, then it's, so this is really interesting. This is, this ties into some, this is why it's such a good jumping off point because like Next it has years of usage and like production customers and like a company built a hosting platform around it because that seemed like a good idea. [26:41]
-
-And now some, now a competitor has taken advantage of their robust tests and everything and said we're gonna re-implement that from scratch in a matter of days for a trivial cost. [27:17]
-
-**Mark:** Similar examples. So watching Hacker News over the last couple months. A, a similar what Canis do Benchmark has been, what if we just cut agents loose to work for a few weeks and build a browser? [27:29]
-
-From scratch or a c compiler from scratch. You know, I've, I've seen both of those examples pop up and the, the big characteristic in all these cases is that it's a fairly well-defined problem, that it's fairly deterministic in terms of application behavior. And there is a massive existing test suite that helps define exactly what the behavior ought to be. [27:44]
-
-You know, we mentioned earlier the example of next reimplementing web streams as a polyfill, but building it faster. And they said, you know, there's no way we could have done this without the fact that there were already like 1500, 1700 platform tests for web streams. Similarly, browsers like the, the expected behavior for parsing HTML and all these other pieces of, of a browser's behavior are very, very strictly defined. And there's a massive set of platform tests that it can be used to compare correctness. So it's both, you know, like what other examples are out there they can reference, but it's the tests define what the expectation is. [28:08]
-
-**Mo:** Uh, on those two examples, I think the browser one was the cursor team and the C compiler was, I believe it was Claude's internal team. There was a bit of pushback on that because if you dug through it, it didn't actually compile or build correctly and needed a bit of human fixing to do that. [28:50]
-
-Admittedly, those are quite complicated tasks, right? Like building an entire browser from scratch and a C compiler is tough. This with CloudFlare coming out and saying, Hey, this is production ready and we're actually using it in product, or some of our clients are using it in production, seems to be a much bigger claim in my mind than sort of like an experimental labs effort. And it's, it's, uh, it's interesting that a company like CloudFlare is happy to put their name on this rather than it on something that's like, this is production ready. You can, they're given a commands to migrate an existing next JS project to Vinext. [29:09]
-
-Like they're really going, this is as good as next js. And so it feels like a different grade of achievement in my mind. [29:42]
-
-## CloudFlare v Vercel beef
-
-**Mark:** I mean there, there's also the existing strife between CloudFlare and Vercel that probably plays into this a little bit, but [29:52]
-
-**Carl:** true, right? There's like personal beef between the CEOs of those two companies. [29:58]
-
-So I'm sure that was a motivator here as well. Okay. There's personal beef, but there's also like legitimate technical questions here. Like, Vercel and CloudFlare are each trying to push their own visions of what hosting providers could be, and they're interesting. You know, I've been more interested in the CloudFlare vision of what hosting can be. [30:02]
-
-Workers sound really cool, like, you know, it seems like a plausible achievement of the vision of serverless, you know, that I've been hearing for my entire career. So I've been very curious about that. I've used it a little bit, and CloudFlare also was doing Open Next before, which was an adapter, so you could use, basically adapting the versal specific runtime things so that it could use it in other platforms. So like this does feel in keeping with the kind of work CloudFlare has been exploring with, but agreed that this is a categorically different kind of plane than like, ooh, we made a, a C compiler. Like no means is seriously using an AI generated c compiler in production. Like, not right now. [30:23]
-
-**Mo:** It, it's interesting. So talking about sort of like Cloudflare's platform, I've, this is sort of a, a tangent, but I've been building sort of two side projects, two mobile app side projects with ai and I'm defaulting to using CloudFlare workers durable objects and all of that because it's, it's actually like quite good for AI to understand in terms of the primitives and doesn't have to deal with like the complex architectural bits of like defining a region and stuff like that. [31:08]
-
-So I can, I can, I. I think it's actually like they have a good AI play that they can execute here as well. Beyond just, you know, articles about how they can rebuild next JS with ai. [31:35]
-
-**Carl:** Yeah, right. [31:46]
-
-**Mo:** Now there's one thing in this article that I find quite interesting. So I've spent a lot of time battling with the C of next js, and specifically when you're trying to deploy an xjs in certain sort of custom non-cell environments, it comes with a lot of complexity. [31:48]
-
-You, you're gonna have to define your own sort of like cache handler and they seem to have just popped all of that in CloudFlare kv, which is their sort of workers key value store and it's quite interesting that that, that is sort of the direction they've gone through. They say that you can also use R2, which is sort of their S3 equivalent. [32:05]
-
-Great name by the way, because R two is one character before. S3 on both sides of it, which I think was a dig at AWS, but the caching strategy and allowing for you to customize that cache, I think super easily with some of their primitives is, is quite nice because that is always been a pain point for custom deployments of, of next js. [32:27]
-
-And I think probably one of the biggest barriers to people, you know, hosting next JS in, in other cloud providers that I've seen in the possible and you have custom setups. [32:48]
-
-**Mark:** I mean, that is, as always, my caveat is I haven't worked on large scale production commerce e sites, so I have no practical experience with this. [32:58]
-
-But anecdote like we, we know the know the phrase, you know, the, the biggest error problems are, you know, off by one and caching errors or something. Something of that effect. And certainly anecdotally over the years, you know, like one of the biggest complaints about a polygraph QL was the complexity of the cache implementation. [33:06]
-
-We've seen a lot of complaints about next and their page caching implementation, and we've seen them go through, you know, 2, 3, 4 different iterations and approaches to caching and, you know, caching all the different layers of the system. So it's not surprising that this is a pain point. And so, yeah, I can, I can see CloudFlare saying, what if we, what, what if we do something different and maybe somewhat simpler. [33:24]
-
-**Carl:** Also, man, I gotta say thank you to Super Kennel in chat for sharing this post from Guiller Moro of titled "Migrate From Vercel to CloudFlare. And, um, you know, it's got this table of contents at the top, like project setup, migrating custom domains, converting build and deployment, moving environment variables, rewriting, and, you know, it's like 12, 15 items, something like that. [33:48]
-
-And like a quite long blog post. Whereas this CloudFlare, you know, we rebuilt next AI is saying, oh, just try it. Install this AI skill and then type migrate this project to V next in your favorite in any supported tool, and it'll do all the stuff for you. And I'm like, those are two entirely different levels of effort. [34:12]
-
-And I think CloudFlare handily wins there. That's interesting, assuming it actually works as, [34:35]
-
-**Mo:** it's funny because in one of the comments the Guillermo says, I'm migrating from Versal to CloudFlare. Am I doing it the wrong way around? And Guillermo's just like, yes, delete all of that. Rang blur, Jason C config nonsense, and all of the proprietary imports and just run it on Versal. [34:40]
-
-So this has clearly struck a nerve because they've launched this pretty much on the same day that they made this announcement or you know, day after. [34:55]
-
-**Carl:** Yeah. Right. Delete all the wrangler adjacency, config, nonsense. Like are, is versal gonna try and claim that next doesn't have config nonsense. Like you do not have a leg to stand on there. [35:04]
-
-**Mo:** There's, there's no legs to stand on. Especially if you've tried to deploy an Xjs project outside of Versal, it is pain. So no respect there. [35:15]
-
-**Mark:** Interesting. So there's, there's lots and lots of angles we could try to discuss here. We've, we've looked at. Rebuilding apps or tools that have known test suites and what does, and we, we really haven't even touched on what does that mean in terms of companies having a moat. [35:24]
-
-In fact, Carl, you wanna, you wanna toss that post in there at the moment? [35:39]
-
-## Carl Vitullo monologs about AI Agents
-
-**Carl:** Yes. Yes, I do. Also, I wanna, once you're done, I want to monologue for a moment, [35:42]
-
-**Mark:** couple other angles we could look at. I mean, there's, there's the ever popular, you know, what does all this mean for us as software engineers and our industry and our careers going forward? [35:47]
-
-And just how doomed do we all feel as well as, you know, what are we doing with AI on a day-to-day basis. If anything, Carl monologue go. [35:57]
-
-**Carl:** Yes. Ah, I alluded earlier to playing a lot with agents. A good internet friend of mine made a very silly AI agent, MMO. So it's like a text based, if you're familiar with like a mud, a multi-user dungeon. It's basically that. It's a text based MMO that you can play through your terminal, and it's only for ais to play. Not everyone is, but, so I've been using that to learn about how to do agents and how to run AIs autonomously for a longer period of time, which has been fascinating. And so this, I've now watched somebody in real time, like I heard about this project. [36:07]
-
-I went, oh, neat. Let me set up an AI to play this game. So I got there on like one, I think after it launched. Somebody else who got there on day one fucking ran with it has been, you know, he's been working professionally on AI agents for a year, he said. He already knew how to do all the harnesses in the orchestration, which I, you know, I had never tried to do either. [36:44]
-
-So I'm learning this from scratch watching him do it with a year of experience and like, holy shit, it is unbelievable how much code he produced. I think the total amount of code is like, now, I dunno if it was 60,000 or 600,000 anymore, but it's like a lot of code and it works like not perfectly. There's a lot of duplication, there's a lot of errors, there's a lot of, you know, like this code path looks like it works, but actually you get into the details and it doesn't quite work. [37:06]
-
-But like, as we use it, we like, so these AI agents are instructed as part of the game, like, "Not everything works. Please submit bug reports as you find them. Then this guy has his own agents that are reading those bug reports, turning it into reproductions, and then writing tests and fixing them, like largely autonomously. [37:34]
-
-Not completely autonomously, but largely, which now has me imagining this, like imagine if you set up, you know, you have an idea for a product, you build a prototype. You put it on a server and then you have on the, on that same server, a little sidecar or you know, running in the same environment. I mean maybe not literally on the same server. [37:55]
-
-An AI agent that is receiving user feedback. Like, you know how like every major enterprise application will say every so often, like, "we value your feedback. How are you using this product?" And then you fill that out and it goes into the void and nothing ever changes. You never hear about it again. You never get asked for a follow up and the bugs that you reported never get fixed. [38:16]
-
-Like what if that went into an automated system that triaged, reproduced and fixed things in real time autonomously as you submitted reports. Like that now appears to be within the realm of possibility. Like, like not theoretically in the future, but like currently I have seen tech that looks like it might be able to do that, like maybe not fully autonomously right now. [38:38]
-
-Oh God. Like pretty good. Pretty close. So that's fascinating. I think that's really interesting for the idea of like a one person startup, you know, a small team operating at a scale that previously would've required 50 to a hundred people. I think that's interesting, like scratching your own itches and publishing it so that other people can use it, and then soliciting feedback to guide the development now looks really powerful. [39:04]
-
-So I, that's when, you know, as we as, as we speculate on the future of development and what software development is going to look like, I think it's gonna be a lot of wrangling, that kind of stuff. Like, you know, I put up a little, little blog or no, I put, I posted on Blue Sky that after I was experiencing all of this and being like, holy shit, this feedback is incredible. [39:32]
-
-This feedback mechanism is incredible for guiding AI development. I had the thought of like, man, it feels like now the determining factor for how good software can be is how many people are using it, and how good those people are at articulating what they want out of it. Which is a really interesting place. [39:51]
-
-And I think that's all I have to say. [40:13]
-
-**Mark:** There's a little bit of the, you know, you just keep towing it, make it better, make it better, a fixed bug, make it better. [40:15]
-
-**Carl:** A lot of that. But you know, it's like there's also the aspect of like the more precisely you can articulate what is deficient, what better looks like, the better it works. [40:20]
-
-It's remarkable. Like I've seen it. It's so cool. I don't know, it's interesting. [40:31]
-
-**Mo:** There's sort of like. A few thoughts that I've got. There's anecdotally my whole like coding setup and how much code I can get through as a person who's been coding less and less and more. Dealing with systems and leading teams over the last few years has just been crazy. [40:35]
-
-Like my, I looked at my contribution graph on GitHub and I've done in the last two months now, done probably half of my commits that I did in the last year in 2025 in two months. And it, it's just gonna go up and up because it's been a lot more over the last. A couple weeks. And so producing code is significantly easier, especially to do as sort of someone that's instructing things at a high level. [40:52]
-
-I've been working on two side projects and both of those are like weekend projects that I would never have gotten anywhere near to completion. But I'm pretty much ready to launch one, like almost to the step of I I, I just need to push it to the app store at this point, which I have never been able to do just because I've never had the attention span to finish it off. [41:19]
-
-So that's been just something incredible. [41:40]
-
-**Carl:** If I can interrupt for a second, because same projects executed, ideas initiated exactly the same. Like I did things that I never would have because I would've looked at it and gone, oh, I know how much work that's gonna be, and I don't know exactly. [41:44]
-
-**Mark:** It's same for me. [41:57]
-
-Yeah. Mm-hmm. [41:57]
-
-**Carl:** I did them at the same time as each other. Like, I'm working on two or three projects in parallel, like while watching a movie with my partner. And, you know, and like I checked in with them to be like, Hey, like I was working, like, did I seem checked out? Or like, was I still present in the room? [41:59]
-
-And they were like, yeah, no, you were like, you followed the conversation and participated. So I, it's like I was more productive than I've ever been and I got to hang out with my partner and their roommate. Like, what? That's insane. [42:15]
-
-## AI productivity and impacts on our attention
-
-**Mo:** Well, well it's, it's only gonna get worse because they released the, the, the, the Claude folks yesterday that released this remote access mode where you can hook into your local, just hooked it up to your phone so you can actually just keep it, keep a track of what's happening on your phone. So this is only just gonna, every night of watching movies and TV shows is gonna be augmented by some level of productivity on the side, which is both terrifying and very exciting at the same time. [42:27]
-
-**Carl:** Yes, it is terrifying. It is, right? It's like such a productivity boost while also not demanding that much attention. That like, why wouldn't you just always have, you know, a, the little back corner of your brain thinking about this? [42:52]
-
-Which like, I don't know, my brain already works that way. I like, I've already poisoned my brain to be addicted to thinking about the problem. You know, like, huh, that's interesting. I mean, I've, [43:06]
-
-**Mark:** I've, I've, I've read a number of articles of people who are dealing with, I don't remember the actual term. I, I don't know, to token attention deficit or something like that. [43:15]
-
-Ba basically it, it's this constant feeling that, you know, okay, like I could be having multiple agents doing stuff for me at any given moment, and therefore any moment where I don't have 5 to 10 agents running is a waste of theoretical productivity time. So if I didn't spin them up before I walked out the door, that was a waste of time that I could have built, or, you know, I have to get back to, you know, double check the results and that quickly becomes its own form of productivity burnout. [43:22]
-
-Just [43:53]
-
-**Mo:** to give like a very concrete example on one of these projects, there's a sort of TikTok style video feed that I had to implement. I did this for a client on one of our actual projects at work that took somewhere around seven to eight days of me develop. We went back on like the Trello board that we were using and looked at the, the estimates of how long that that whole feature took, and it was about seven to eight days to get it working. [43:54]
-
-End to end. I was building something very, very similar for this, for the side project, and it took me a couple of hours to get that whole feature working end to end. So like I know more what I'm doing, I've done it once, I know where the pitfalls are, but at the same time it just, there there is a significant productivity boost here and it's, it's definitely not something that you can, you can ignore anymore. [44:17]
-
-## ["wrote a spec, pointed Claude at an Asana board, and went home"](https://x.com/rvivek/status/2026385957596111044)
-
-**Mo:** There's sort of two interesting things that I've seen over the last, you know, few hours. One is this post from a podcast by the guy who made Claude Code or his churn and he talks about how people are going back to Mark's point about this like productivity attention deficit. Where there's some anthropic engineers who are like leaving Claude code to look at the board, the project board over the weekend, breaking it up into specs, and just spawning it up into building a bunch of different agents that'll build tickets for you and do it in parallel and then you come back and review it on Monday, which is gonna be interesting to see how that goes. [44:42]
-
-But also, you know, there's an interesting one where Karpathy, who you know, used to be a Tesla sort of director of AI and so on and so forth. Original Open AI team has written this like tweet where he talks about how it's really over the last two months where things have just like completely accelerated and it feels night and day in terms of agent decoding. [45:24]
-
-So I think things are moving at a super fast pace. It means we're all probably feeling a good level of FOMO as a result of it, and it's faster than any one person can sort of stick to, which is, which is. Again, exciting and terrifying at the same time, is the only way that I can think of describing this. [45:46]
-
-**Carl:** Yeah. In our, you know, mid month DM chat Mark you had said, who's this? Zach, who's talking about [46:02]
-
-**Mark:** Abels? Zach Jackson is the creator of Module Federation. He joined the web back team a few years back, he now works at ByteDance slash TikTok. And he is an Uber example of, oh look, I have an army of 100 agents running simultaneously. Someone gifted me $60,000 worth in tokens. I'm going to burn most of it by migrating entire projects to Rust overnight. [46:09]
-
-**Carl:** Yep. And like, right, and like the quote you would put here, and it's not a literal quote, but the energy is, I can run a hundred agents, my only limit is token budget. [46:33]
-
-And I'm like, I have started to understand that perspective. 'cause you know, like. What you were just saying about like this person who, you know, wrote a spec and pointed Claude at Asana board, like, yeah, cool, that's awesome, that's great. But like also you don't need to write the spec yourself because if you are just taking user reports and they are submitting things to an agent that is triaging and then summarizing and then if you break down all these little parts into a system that has its own little feedback loops and review stages before passing it off onto another thing that has its own review stages and you know, iteration, then like, holy shit. [46:42]
-
-I understand why people are saying the only limit is token budget because each part of this is working. It's not like theoretical. [47:19]
-
-## [Bits AI SRE | Datadog](https://www.datadoghq.com/product/ai/bits-ai-sre/)
-
-**Mo:** People have already started productizing this. So Datadog has released, it's gonna link it in the chat, this bits ai, SRE, which is. The detection part, which data Datadog already did, which was, oh, there's an issue in production. [47:26]
-
-Okay, crap, we need to fix it. And then they've just lopped on agents to resolve these incidents automatically. So auto investigations, if you're really bold, I think you can just merge it, get it to automatically merge fixes for you across your code base. Like that's the direction we're going through. [47:40]
-
-**Carl:** And I'll even say like. [47:56]
-
-So, okay, great. Datadog productized this like, I don't fucking need it because I was dealing with database corruption in a project I run, and literally what I did was, you know, it was like something started breaking and I opened Claude and I said, here's my Kubernetes cluster, the database, something's going wrong. [47:59]
-
-Can you check the logs? And it did correctly identify the database corruption and then repaired it live like, and just fixed it. Then it became a recurring issue and I had to figure out what was going on and man manage a migration because I had left it in a half state that was causing the corruption. [48:17]
-
-But like, I don't know how to diagnose database corruption. That's, yeah. You know, that's database administrator kind of expertise. And I'm not a database administrator and this isn't even a specialized tool. This is just Claude Code. So like the future's here, we're in it. [48:34]
-
-**Mo:** For better or for worse. [48:51]
-
-**Carl:** Yeah, that's fascinating. [48:53]
-
-**Mo:** So there's, there's this one sort of chart that I saw, which just shows like the adoption of it so far. And obviously we're very close to it in the software industry because, well, we're, we're sort of dogfooding on our own workflows to start with. There's a debate on whether or not this will translate for other industries that, just taking a step back and looking at the, the wider economics of it all, it seems like, you know, there's been about a 50% of agents that, so philanthropic releases, they, they were saying that 50% of the agents that they've seen deployed so far are in the software industry and then it trails down like crazy after that to, you know, sub 10% for all other industries, which makes sense, right? [48:55]
-
-The question is how much higher can that go in the software industry and then will all of the other industries catch up? And I guess where I'm going with this is, what does this mean for just the greater economy and the entirety of the workforce. Like if everything is just constrained by that token budget that we were talking about, there's some really scary stuff coming out for the economy globally. [49:38]
-
-Going forward. And maybe that's a bit dooms date with me to say, but I, I am a little concerned about where we're going. [50:01]
-
-**Mark:** Yeah. I mean, if you, if you wanna zoom out for a second, you know, the, the extreme version of that was the AI 2027 sci-fi scenario projection that was put out a year-ish ago, which was put together a fictional version of how we end up with a true terminator level Skynet AI coming out in, you know, two and a half years, the slightly less, but still dooms day-ish version of that. [50:07]
-
-There was a, a report from Sat Trini research or something that came out just a couple days ago, which was a fictional news report from 2028 talking about how AI usage ended up, ends up tanking the economy in the next couple years and, you know, wiping out white collar jobs. And so I've seen a few different variations of that. [50:31]
-
-And, you know, a lot of these, you know, the questions are, you know, what are the, what are the assumptions going into, um, in the first place? And, you know, okay, fine, it's a scary sci-fi story, but. You know, there's, there's some plausibility to that stuff. [50:50]
-
-## [ThoughtWorks opines on AI productivity impacts](https://simonwillison.net/2026/Feb/14/thoughtworks/)
-
-**Carl:** So I wanna pull in, we had this quote from thought, the ThoughtWorks offsite. [51:04]
-
-ThoughtWorks is a very well regarded what agency from like, they've existed for decades. They've been involved, they've been very deeply involved in tech for a very long time in a very meaningful way. [51:09]
-
-**Mark:** They're not just a development agency, but they, they've document like software engineering processes and patterns for many years. [51:24]
-
-There's a guy named Martin Fowler who has, who has done a lot of that work and he, he's written dozens of articles on, like, we've talked with many, many companies and these are like the distilled best practices we see on how to build software across the industry. [51:31]
-
-**Carl:** Right? Like Martin Fowler, I would say is one of the reasons that people do blogs now, like a lot of people in tech learned so much from reading Martin Fowler's blog that I think that was a significant contributing factor to the advice to every person in tech to have a blog. [51:49]
-
-**Mark:** Right. I also associate them with the software craftsmanship movement. I, I think there was another consultancy called Eighth Flight Background, like 2005, 2010. [52:07]
-
-Well, like Uncle Bob Software craftsmanship, code Katas, like treating software development as a craft rather than a manufacturing exercise. So I, I, I associate them with that kind of pattern. [52:17]
-
-**Carl:** I also had forgotten this, but they authored the Agile Manifesto. So yeah, like, okay. So that's enough introduction I think for ThoughtWorks, like they have had so much influence on the tech industry generally, and so they just did an offsite discussing the future of tech, future of software engineering. [52:31]
-
-And I'm gonna read at least this first paragraph, maybe both paragraphs of this quote, the retreat. "The retreat challenged the narrative that AI eliminates the need for junior developers. Juniors are more profitable than they ever have been. AI tools get them past the awkward initial net negative phase faster. [52:52]
-
-They serve as a call option on future productivity and they are better at AI tools than senior engineers, having never developed the habits and assumptions at slow adoption." [53:09]
-
-I'll say call option is a financial term. Calls versus puts are options to buy or sell. [53:17]
-
-**Mo:** I cannot believe they call junior developers call options. [53:24]
-
-**Carl:** I know it like, oh, it's so like do we in the weeds jargoning, but also like, yeah, sure. A call option is when you say it's you're buying a futures contractor saying, I think this is going to be worth more of the future, and other people disagree, so I'm gonna buy it now. [53:27]
-
-**Mark:** Bet that it goes up over time. [53:43]
-
-**Carl:** Exactly. So like, it is actually a very good analogy here, but like, I don't know, maybe don't reduce the employment of early career people to a financial instrument. Like it's not great. People are more complicated. [53:45]
-
-**Mo:** Yeah. [53:58]
-
-**Carl:** This is such a like, antidote to the doomerism, I think. Like, yeah, they haven't learned the bad habits. [53:58]
-
-They aren't so deep in the weeds as the senior developers are that they're going to like micromanage and just kinda let it do the thing because it's act, the tool is actually very smart. So that's, uh, yeah, like this, [54:04]
-
-**Mo:** I can see that that's the direction they're trying to point this at. At the same, to play, uh, a devil's advocate to that point, the job market seems to be saying something very different. [54:17]
-
-So I'll put a screenshot of this from a study that was released by some Harvard folks. I'll put that, but I'll, I'll link the actual study itself and. This is basically showing sort of like the demand in the job market in the US for senior and junior profiles since the launch of chat GPT. So we're talking sort of 20, 23 time and someone coined this as sort of like a K based was talking about this as like the K based or K shaped feature of software engineering. [54:27]
-
-And there is a dip and it is a hard market at the moment for juniors. So I'm interested how this pans out for junior developers. [54:59]
-
-**Carl:** Yeah. I will say though, y'all listening cannot see this chart. It's got a blue line for seniors and a red line for juniors and it charts the average employment like percentage change. [55:08]
-
-This is a delta, the chart is of the first derivative of employment, I guess it's, you know, rate of change. So a higher number is not only more, but it means that it's accelerating faster. And the blue line, the senior developer line is steady improvement. So it means that it's actually, it's not just improving, it's actually accelerating and how fast it's improving. [55:21]
-
-I believe that's, I believe that's what this is saying. Whereas the junior line matches it, oh, I guess the X axis here is 2015 to 2025. The lines are pretty well paired from 2015 to 2020, and that's when they start diverging and like there's a dip for both. But the dip is bigger for juniors in early 2020 [55:43]
-
-**Mo:** up until sort of that 20 22, 20 23 period. [56:04]
-
-Yes, there's a dip and then it's, the junior is still like going up slightly. It's starting to bounce back, but then now going from 2023 onwards, it is headed in that direction of a downward slope. [56:08]
-
-**Carl:** My intuition matches what this ThoughtWorks quote says, that it's a force multiplier and less experienced people are actually more effective at taking advantage of it. [56:22]
-
-So that feels to me like one of those unintuitive things that hard to justify at a big company. So, I don't know. My, my, my optimism is that cool, here's a highly reputable thought leader, you know, thought leader of thought leaders saying, no, wait, junior developers have the best return on investment they've ever had. [56:32]
-
-That feels like it could turn this around. I don't know. That's interesting. [56:55]
-
-**Mark:** I, I actually really recommend that folks download the PDF report that they put together, summarizing all the different discussions they had at this retreat. There's a lot of very valuable career and industry where we headed material in there. [56:58]
-
-**Carl:** Okay. Oh, I mo I left you in suspense earlier. I said I was gonna use my favorite analogy and here it is. Two years ago I heard an analogy of AI in software compared to the introduction of spreadsheets to the field of accounting where up until the digital spreadsheet, like basically until not Excel, Excel wasn't the first, but before we had tools like Excel, the role of an accountant was basically a calculator. You know, the classic depiction in old movies of they got the green visor on and they're sitting there over a, you know, over a calculator just crunching the numbers and like that was the job. [57:13]
-
-And then you got a spreadsheet and then you put the numbers in the spreadsheet and you do some and it's done. And so there was a lot of panic about like, oh my God, this is gonna destroy the field. Like this is the work. Then now the work is just done. But like we still have accountants and they do more than ever. [57:51]
-
-So that's how I am viewing this. That's my optimistic take on it, is like, yes, it is going to totally transform it. It is going to obviate a large number of skills that are highly valued right now, and it will look different, but I don't think that's necessarily going to mean destruction. [58:07]
-
-**Mark:** I will, I will put together my obligatory plug to say that this heavily emphasizes that having baseline experience with the tools and the concepts and the abstraction so you know, where you're trying to guide it and how the stuff works will be more valuable than ever. [58:24]
-
-**Mo:** I'm hoping on that being the case, the only thing that concerns me is the likes of Zach, which was the example that we gave before where he's like, the token is my only limit. And I wonder like when we, when we went into accountants using spreadsheets, you still needed a person behind the, the sort of system to do it. [58:39]
-
-But if. These systems sort of largely become self-running, and the only limit is the tokens. Then I worry if I, I hope the analogy holds up my, like, pessimistic doomsday clock makes me worry that it might not hold up. Same thing with the tractors plowing the field analogy that I've heard a few times. I hope that this niggling that I've got inside of me is just completely doomsday and it's, it's not actually accurate. [59:00]
-
-**Carl:** No, that is fair. I think even if all the technical things goes the same direction, I think that there are environmental things that could very much alter, I don't know, the experience, the outcome. I actually, the farming one is an interesting thought because, you know, now farming, you know, per unit effort to get to grow a calorie of food, it's easier than ever, but the tooling required in order to get that benefit is more expensive than ever. [59:28]
-
-And so what I've really, what I've heard for years is that. The average, the family farm is no longer feasible because you need nine different tools that each cost three quarters of a million dollars and have expensive, you know, support contracts, because John Deere doesn't let you fix your own tools anymore. [59:57]
-
-That's very real. This is just like, so not a good thought, but hey, maybe we'll get a good regulatory environment that drives positive outcomes, [01:00:14]
-
-**Mo:** if that's what we're, if that's what we're hoping on, I am really worried. [01:00:22]
-
-**Carl:** Yeah, that's a good joke. [01:00:27]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Anyway, anyway, let's do the best Lightning rounds. Let's not do all of them. I'm not gonna do all the conferences, [01:00:28]
-
-**Mark:** okay. In no court order. [01:00:36]
-
-## [“Wall Street Raider” game modernization](https://www.wallstreetraider.com/story.html) (and uses Preact)
-
-**Mark:** That's a really good blog post or on hn someone, one guy wrote a complicated basic game back in the 1980s called Wall Street Raider, which is supposed to be the deepest, most involved simulation of the market ever, but it was a complicated text mode game and decades later, even, he barely understood how the code worked. [01:00:37]
-
-Lots of people had tried to modernize it, it all failed. And then one. Kid offered to do it and ended up building a better ui, much like a dwarf, fortress, fortress kind of a thing on top. Uh, and apparently it's even built with pre-ACT. So just the story alone is worth reading whether or not you even get around to playing the game. [01:00:56]
-
-**Carl:** Yep. Love that. [01:01:15]
-
-## [Github Stacked Diffs preview](https://x.com/jaredpalmer/status/2019817235163074881) , [faster Issues search](https://github.blog/changelog/2026-01-29-improved-search-for-github-issues-in-public-preview/)
-
-**Carl:** We talked about it a couple of times, Jared Palmer of Formic and Yup. I think. Yup. And a couple of other, you know, he's very influential in the React ecosystem has been, is now a PM at GitHub and he's working on Stack Diffs. Which are something I've been craving in GitHub for 10 years, literally. He's been teteasingittle bits of it here and there, but he, so he, he put out, he posted on Twitter that fact diffs on GitHub will start roll, rolling out to early design partners in Alpha next month. So within the next two weeks or so, some people may have access to stat fits, which is just such good news. [01:01:16]
-
-I love that so much as well as there's improved search for GitHub issues and public preview. So that's, that's pretty cool. [01:01:58]
-
-**Mark:** Which, which I've seen. It's, it's much, much snappier [01:02:05]
-
-**Carl:** Good. [01:02:07]
-
-## [Josh Comeau: Sprite animations](https://www.joshwcomeau.com/animation/sprites/)
-
-**Mark:** Everything that Josh Comeau posts is worth taking a look at because he's put so, so much care and attention into his blog posts and explanations and he did a post on Sprite animations and especially how you can do them on the web. [01:02:08]
-
-Josh is wonderful. His posts are lovely. You should read it. [01:02:21]
-
-**Carl:** Yes. Cosign. [01:02:24]
-
-## [Interop 2026](https://wpt.fyi/interop-2026), ([WebKit](https://webkit.org/blog/17818/announcing-interop-2026/), [Igalia](https://www.igalia.com/news/interop-2026.html))
-
-**Carl:** So Interop 2026, which is a cross browser initiative to make the web standard more consistently implemented across browsers, has announced their like 2023 roadmap. So the, uh, active focus areas are container style queries, CSS anchor positioning, the, uh, adder, attr() CSS function, contrast color, shape, zoom, custom highlights, dialogues, and popovers index db, which if we have a meaningful client side database, that would be great. [01:02:26]
-
-We have that, we've needed that for so long, and it's just hard to get specified. So love that Interop on a client side database. Woo. Yes, let's do it. [01:03:00]
-
-A bunch of other things that's, you know, it's a, it's a very long list. This is a site they use to track the compatibility across Chrome, edge, Firefox, and Safari. [01:03:09]
-
-It's pretty good. This is deep in the weeds, but this is like the cutting edge of browser development, so very cool. Excited to see what they, what it looks like next by the end of the year. Okay. Sounds like that's all we got now. [01:03:21]
-
-**Mark:** Plenty over time and covered plenty of items. [01:03:33]
-
-**Carl:** Yes. [01:03:35]
-
-**Mark:** Y'all got your money's worth this month. [01:03:36]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** I'm gonna put conferences in the transcript if you wanna see what's coming up. Just do look for that in a couple days. Thank you so much for joining us, everyone, as we go over time rambling about AI ranting and rambling about AI and how cool and terrifying it is. We will be back on the last Wednesday of next month here in the live stage of Reactiflux, or back in your podcast feed just as soon as we can. [01:03:38]
-
-**Mark:** Kristen, do just a, a random offshoot episode talking about how we personally do and do not use AI in our, in our own workflows. [01:03:58]
-
-**Carl:** Agreed. That's interesting. Maybe that'd be a good check-in thing to do. I dunno. Maybe we, shit we should make, we should do more community events. I, you know, introduce myself as that every month. [01:04:05]
-
-Cool. We gather sources mostly from our own tech reads and news channel nowadays, so if you see anything that you think might interesting to discuss, definitely let us know in there. Or you can also email it to us at hello@reactiflux.com. Yeah, I'll read it if you send it there. This is a show that you get value from and wanna support. [01:04:14]
-
-Best way to do so is by submitting a review wherever you listen. I have seen a couple of new ones roll in the last couple of months, and I am pleased to report that our Spotify rating is still five stars. So that's fun. Thank you. Thank you for the positive reviews. I'm glad you all appreciate it. [01:04:35]
-
-**Mark:** I can throw a really quick, cheap corporate plug replay. [01:04:50]
-
-My employer is refocusing on the time travel debugging use case, except that we have just built an MCP that Exposes a lot of our really powerful time travel analysis awesomeness to your AI agent of choice. And even in just my own dog foodie, and I've seen. You know, Claude, whatever, be able to start investigating the contents of recording and see what's going on and fix bugs that it might not have been able to fix otherwise. [01:04:53]
-
-And I'm also working on some proof of concept performance analysis stuff, digging deep into the internals of React. We would love to have folks try it out if you have questions. We've got some examples in our docs of adding the MCP and I'm also very happy to talk about how awesome it is. [01:05:18]
-
-**Carl:** Hell yeah. Dope. [01:05:33]
-
-See you next month everyone. [01:05:35]
-
-**Mo:** See y'all soon. Bye. [01:05:36]
diff --git a/src/transcripts/tmir-2026-04.md b/src/transcripts/tmir-2026-04.md
deleted file mode 100644
index 3fda37f..0000000
--- a/src/transcripts/tmir-2026-04.md
+++ /dev/null
@@ -1,596 +0,0 @@
----
-title: "Mark & Carl talk with Swizec Teller about using AI at work"
-date: 2026-04-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Swizec Teller as we discuss the state of the software engineering profession. How are we working?"
-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:26](#introductions)] Introductions
-- [[00:02:36](#what-convinced-you-ai-code-tools-were-worth-using)] What convinced you AI code tools were worth using?
-- [[00:04:24](#using-early-chatgpt-for-db-migrations-)] Using early ChatGPT for DB migrations
-- [[00:06:59](#watching-ai-use-a-command-line)] Watching AI use a command-line
-- [[00:08:16](#background-chat-agents)] Background chat agents
-- [[00:08:58](#staying-very-hands-on-while-using-ai-tools)] Staying very hands-on while using AI tools
-- [[00:11:00](#driving-ai-closely-without-reading-its-code)] Driving AI closely without reading its code
-- [[00:17:50](#marks-workflow-opencode-with-codenomad-ui-plus-idegit-ui-opus-46-on-api)] Mark's workflow; OpenCode with CodeNomad UI, plus IDE\+git UI. Opus 4.6 on API
-- [[00:20:39](#swizecs-workflow-latest-cursor-on-opus)] Swizec's workflow, latest Cursor on Opus
-- [[00:23:58](#carls-workflow-mostly-claude-code-but-looking-at-custom-orchestrators)] Carl's workflow, mostly Claude Code but looking at custom orchestrators
-- [[00:25:23](#exploring-fully-autonomous-agents)] Exploring fully autonomous agents
-- [[00:28:08](#marks-ai-debugging-work-in-react-core)] Mark's AI debugging work in React core
-- [[00:31:42](#value-of-providing-more-context)] Value of providing more context
-- [[00:33:58](#ai-owned-documentation)] AI-owned documentation
-- [[00:37:09](#using-good-engineering-practices-still-matters)] Using good engineering practices still matters?
-- [[00:40:47](#how-do-you-know-the-right-code-to-make)] How do you know the right code to make?
-- [[00:42:49](#good-communication-still-matters)] Good communication still matters
-- [[00:45:13](#what-will-review-look-like-in-the-future)] What will "review" look like in the future?
-- [[00:46:17](#automating-functionality-tests-with-deployment-practices)] Automating functionality tests with deployment practices
-- [[00:51:49](#what-behaviors-belong-to-the-agent-and-what-fundamentally-cant-be-part-of-the-agent)] What behaviors belong to the agent, and what fundamentally can't be part of the agent?
-- [[00:56:17](#impacts-of-llms-on-software-engineering)] Impacts of LLMs on software engineering?
-- [[01:03:22](#a-superpower-right-now-is-a-domain-expert-who-can-kind-of-code)] A superpower right now is a domain expert who can kind of code
-
-# This Month in React April
-
-**Carl:** Hello, everyone. Thank you for joining us for this month in React, which is not going to be particularly React heavy. [00:00:00]
-
-Mark and I have been talking for a couple of weeks now about doing a, like, bonus episode of sorts to talk about AI and how we're using it. So we are just, instead of a bonus episode, we're, we're just gonna do that for this month, for April. [00:00:06]
-
-Yeah, and apologies for last month. We had a recording problem, and we, it was completely unsalvageable, just nothing to save. Big bummer. [00:00:19]
-
-## Introductions
-
-**Carl:** But yeah, so I am Carl. I am joined this month by Mark Erickson and Swizec Teller. yeah, we're gonna talk about AI because it's been a huge part of each of our workflows for the last, like, ranging from, like, three to six months to a year or more. [00:00:26]
-
-Let's do some intros first. I guess Mark and I are reasonably well known, but I'm Carl. I am a staff level software engineer and engineering manager and community lead here at Reactiflux, where I do events like this and build code to keep the community operating. [00:00:43]
-
-**Mark:** I'm Mark Erickson. My day job is ReplayIO, where we've built a time traveling debugger for both humans and agents with ReplayMCP now available. Please check out our blog. I just put up a blog post on how Replay found a bug faster than Dan Abermov did. I am still the Redex maintainer. Honestly, I haven't done much Redux stuff in the last few months because all my brain space has been taken up with day job work. And also, I'm going around to a whole bunch of conferences this year. [00:00:58]
-
-**Swizec:** I'm Swiz. I work at Plasmidsaurus, we are a DNA sequencing as a service company. We do a lot of React for really fancy data visualizations for stuff like, "Hey, wh- how do you visualize a few million data points in the browser and make it work smooth?" Stuff like that. And these days, I'm kind of more of a manager than an IC really. [00:01:23]
-
-And I've been thinking a lot about what kind of engineers get hired these days. We've been hiring a lot and using more and more AI to write the code. [00:01:45]
-
-**Carl:** Yep. Believe that. Cool. Yeah. So we were just chatting a little bit about what shape this conversation's gonna take. Just to level set a little bit for everyone listening. [00:01:55]
-
-We're gonna start off kind of at the point of, like, what convinced us that AI was a tool worth taking seriously and, you know, getting AI pilled as it were. Go from there into how we're using it now, what problems we're using it to solve, with what tools, as well as kind of, like, what aren't we using, what don't we find useful and compelling? [00:02:04]
-
-And go from there to, like, landscape of, like, what tools are available, what's out there, where do we think it's gonna go, and then kinda close out with what do we think the impacts are gonna be on the industry more broadly. [00:02:24]
-
-## What convinced you AI code tools were worth using?
-
-**Carl:** Mark, you wanna start us off talking about what convinced you that AI was worth using? [00:02:36]
-
-**Mark:** Sure. A year ago, I was dead set that I would never, ever allow AI to write code for me. It was a fate worse than death. It was destroying my career. I refused to do it. And in fact, I actually wrote a 15,000 word blog post over the weekend that I haven't published yet that will give the long form version of this story. [00:02:41]
-
-The short form is, over the summer last year, I cautiously started using AI to explain an existing code base to me. You know, just give me some architecture docs, walk me through the data flow. And then there was a three-day period in late August that blew my mind. On a Tuesday, I asked it to write some redux unit tests for me because my brain was too tired to write actual code, and it did, and I was stunned. [00:03:02]
-
-On Wednesday, there was a node compression library that I've been trying to replace, but the alternative didn't have all the features we needed, and it's Rust-based. And I tried asking the AI to write the feature for me in the Rust library, and it did. It actually didn't quite work right, and the maintainer had to turn down the PR, but this was the first time I saw an agent actually just crank along and spit out a bunch of code and happily make a bunch of updates. [00:03:28]
-
-And I thought I had a, a good understanding of what that process looked like. And then when I saw it in person for the first time, my jaw dropped. And then on a Thursday, I needed to write some AST-based linting code. I know what ASTs are. I've used Babbel. I understand the concepts, but it's kind of complicated and fiddly, and we had a custom setup. [00:03:54]
-
-I was like, "Could this do it for me? " And it did. And it did it much faster than I could as a person. And my worldview got destroyed. [00:04:13]
-
-**Carl:** Yep. Sounds familiar. [00:04:22]
-
-## Using early ChatGPT for DB migrations
-
-**Swizec:** I mean, that, that sounds like an amazing experience. For me, the first was way back in the, uh, Stone Age where you had to talk to ChatGPT and then copy paste the output to try to run it. [00:04:24]
-
-And it was like, I think it was the holidays, and I was writing a book feeling kind of discouraged, and I was like, "I wonder how many words I'm writing per day." And it's like, I can write Python. It's not that interesting to parse a markdown file, go through, get history and see how many words you added every day. [00:04:39]
-
-Um, so I was like, "Maybe ChatGPT can just write this for me. " And I asked it, and the code, the code didn't work, but it ran. And I thought that was really cool. So I talked to it a little bit more, and we ended up with a really nice ... It was an extremely ugly code that I would never write myself. I think it ended up still taking two or three hours, but it was a lot more interesting than me doing it. [00:04:58]
-
-Um, and I ended up with a nationalization of how my, how my book is doing, and then I wrote a few more scripts like that. And then I started using it at work to write my database migrations, because- [00:05:25]
-
-**Mark:** Please tell me, was it still just the ChatGPT UI? [00:05:39]
-
-**Swizec:** It was. Uh, this was, this, this was before Copilot. I was like, "Hey, ChatGPT, I have this SQL query, please write migration." [00:05:41]
-
-And it wrote the migrations or I ended up, uh, later on just copy pasting table definitions from, like, DBR or DataGrape or whatever, go look at the current tables and be like, "I have these tables. Please write migration for ... " I think we were using Connects at the time. "Please write migration to add these columns and then copy paste back and it worked. [00:05:49]
-
-"And I was doing that for a while and it was amazing. I never wrote a migration again in my life. [00:06:13]
-
-**Carl:** Yeah. I started doing a lot more migrations because it just became so much easier to actually do them. There's such a pain, there's so mechanical. That was an early one for me too that was like ... I guess I actually had been, like, scoping my work to avoid migrations because I hate doing them so much. [00:06:18]
-
-I had a similar experience of just like, " Oh my God, this works for that. I can do so many more of them now because I don't have to do it. "Yeah, it's a little funny because actually database migrations are a big part of why my career looks the way it does, because I did, like, one in, you know, my first year as a software engineer. [00:06:34]
-
-I went," Wow, I hate this. You can't guarantee anything. There's just, you just gotta try it. "And so then I went more front end because you don't have to do database migrations on the front end. [00:06:49]
-
-## Watching AI use a command-line
-
-**Carl:** Yeah. I had a similar type of experience as Mark. I guess I, I got on it much later than you did, Swizz. Sometime around, like, August, July, August, September of last year, you know, I, I had done kind of like ChatGPT prototypes or whatever, like Claude, having it write some HTML in line and just, like, prove out a concept or write a first draft of a script, like, prove out does this work? [00:06:59]
-
-Give me off the blank page and give me something to grow from and diagnose. And then I'd been hearing people talk about Claude code, so I finally gave that a shot in, like, I think around July, August for the first time. And just watching it, you know, like, Mark, like you said, of just watching it churn through and do things and also having it be, like, native on the command line and watching it just run exactly the same Bash commands that I would to diagnose something and, like, read the files. [00:07:23]
-
-It was like, "Oh, this is doing exactly the same process I would to resolve this bug, but it's doing it five times faster than I can." That was my big, like, light switch moment of, like, "Oh, I need to take this really seriously." [00:07:54]
-
-**Swizec:** For me, it's kind of like I really hate watching it work. I've been using AI for a while doing, like," Oh, can you write this function for me? [00:08:07]
-
-## Background chat agents
-
-**Swizec:** Or can you, like, do little small things? "But my workflow really changed when Cursor launched Slack background agents. So I started in Slack, like, when you get ... Partially, I'm a PM, so I get a lot of requests that are like, " That is definitely not a priority right now. We're not gonna work on that. "But I can now go at Cursor, do the thing, and I just get a PR with the implemented small thing that I never would've taken the time to do myself. [00:08:16]
-
-And I, I find that amazing because watching it work, I think is, for me, is too distracting. [00:08:46]
-
-**Mark:** Yeah. [00:08:51]
-
-**Swizec:** So I like it when it's fully somewhere in the cloud. I don't have to worry. I just review the code when it's ready. [00:08:51]
-
-## Staying very hands-on while using AI tools
-
-**Mark:** My workflow is very hands-on and human in the loop. Like, I'm sitting there watching that thing like a hawk and having conversations with it, which I realize is not how most people are using AI at this point. [00:08:58]
-
-I think a lot of people are very much on the, in the cloud, multi-agents, how many of these th- things can be run in parallel, which I now have opinions on. Part of it is ... Well, a lot, a lot of it's the point that I'm making the draft blog post, which is understanding is still critical. And I'm a very, I'm a very firm believer in, you know, the fundamentals and understanding and building a mental model of the system. [00:09:10]
-
-And I personally, for me, I want my brain engaged. I want to be thinking through the problem, and then I'm using the agent to amplify my own abilities. Now, don't get me wrong, there's definitely been a few moments where I was, like, you know, out and about. It's like, you know, it actually would be kind of nice if I could just pull up my phone and tell an agent, go do this thing. [00:09:34]
-
-Like, I, I, don't get me wrong. I get the appeal. [00:09:54]
-
-**Carl:** Yeah. [00:09:56]
-
-**Mark:** But in terms of day-to-day development work and how I approach programming, I want my brain active, engaged, and thinking, not just handing it off to an agent. [00:09:56]
-
-**Carl:** Yeah. I hear that. I think I use it in both ways. There are a lot of things that, like you said, so it's just, like, it's not quite high priority enough to justify. [00:10:08]
-
-And that's where I'll use, like, more of a background agent. Like, you know, here's 15 one line descriptions and, like, just from the one sentence, it's clear enough what's needed. Like, you know, adjust the size of this. Add an element that controls this. Like, those are mechanical enough that it's really just, like, getting it right, making sure it compiles. I don't currently have a functioning workflow for that exactly. [00:10:20]
-
-What I'm doing right now in the last four or five weeks just, like, hasn't really been of that type of development. So I am still, day-to-day, most of what I've been doing is very much, like, the mech suit variant. You know, people talk about, like, automated versus mech suit, like robot or mech suit. [00:10:44]
-
-## Driving AI closely without reading its code
-
-**Carl:** And yeah, so I'm driving it pretty closely, but I'm not really reviewing its output very strictly. I'm, you know, I tell it to use subagents, and then every so often I'll, you know, tell it to write me a report, like, how is this working? What is it doing? Ask it some targeted questions to make sure that the mental model I have matches what's actually there. [00:11:00]
-
-But that's a little different, I think, than what you described, Mark. Like, I'm not actually, like, I don't read almost any of the code. I try and think of it more from, like, my engineering manager, tech lead, product manager hat. I do really try and sit in engineering manager/product manager role and say, like, "Okay, how did those people talk to me as an engineer? [00:11:17]
-
-Like, they were not technical. They didn't understand anything of what was being built, and yet it was their job to make sure it was functioning as intended." So that's very much how I try to think about my work now is from that perspective. It's like I, instead of reading a line of code to ensure that patterns are followed as I intended, like, set up a lint rule and then, you know, maybe it's only 80% is good, it's not gonna catch all the subtleties, but, like, my experience of working on a team is, that's kinda how it works anyway. [00:11:37]
-
-Like, if it's not captured in the lint rule, eventually it will break. Like, eventually, someone will have been onboarded and not ha- be deeply steeped in the history of the project or just be tired that day and they forget about it or whatever. So, like, that was very much my perspective as, uh, you know, when I've been a tech lead is, like, if bad code goes out, you know, the blameless postmortem, it was a process failure. [00:12:06]
-
-This should not have been permitted by the automated checks. And so that's kind of how I'm thinking about it is just remove the abstraction a little bit and guarantee the outputs and then work on automated tracking of automated evaluation of the code quality to make sure that's at a level that I need it to be. [00:12:30]
-
-**Swizec:** Yeah, same. I think that's my perspective as well. I've ... Going up into tech lead was really kind of almost broke me as an engineer because I was like, "Oh my God, all of this terrible, awful code, but it works and it's fine and everything is okay and the team just handles it. And if anything is wrong later, we just fix it. It's totally fine." [00:12:48]
-
-And I kind of treat AI the same way. I, I do a lot of driving from, like, a product perspective and for critical features or, like, super gnarly business requirements, I go into the ID and I drive it kind of like what Mark was describing, reviewing every line of code, clicking yes, et cetera. [00:13:12]
-
-But they do really well with follow-ups. Cursor gives you the wrong thing back in a Slack thread. You just say, "Ed curs- ad cursor, go fix it. " A lot of the times, those fixes are actually, "Oh, yeah. Now that I'm holding a working MVP, it doesn't actually feel right. I totally didn't even think of several features that it needs before it's useful." [00:13:29]
-
-I also really like the code review flow. I don't know exactly what we did, but we hooked it up so that you can do a PR review, like a code review for your cursor agent session. And in GitHub, you just go at cursor, fix this, or you give it information basically the same as you would with a team member, and then you just get follow-up, commits, and it fixes all the things. [00:13:49]
-
-**Carl:** That's very much been my experience as well. One of my biggest struggles as a, as an engineer is, like, I remember hearing about this sort of a stereotype of, like, give it, give this task to a junior engineer because they don't know it's impossible, you know? The sense of as you get more experienced, you get to see more of the complexity, and the complexity makes it harder to take action because you're now evaluating trade-offs instead of just kind of ignoring them because you don't know they're there. [00:14:10]
-
-And I would get so stalled into analysis paralysis and, like, what's the correct way to do this? How do you do this best? What's gonna have the best maintenance trade-offs and the lowest, you know, the tech debt and whatever? And that's just such a difficult way to actually solve, especially a novel problem. Like, if you understand a problem well, great. You can specify everything in advance. But, like, if you're working at the edge of your knowledge, at the e- edge of your understanding, then, like, you're gonna go the wrong way at first. And it's so painful to work on something for three weeks and then go like, "Oh, shit. This is just completely the wrong architecture and I need to start over." [00:14:34]
-
-But it's so much less painful now with AI because, like, great, what a wonderful learning. Let me take that, let me have it write a three-page document about what we learned, what the new problems are, go back and forth, interact with it about, like, designing a new data model and architectural, you know, process flow. [00:15:09]
-
-I actually just did this in the last, like, week. I've been benchmarking local LLMs because I want to better understand which ones work for what tasks so I can not have all of my AI usage be based on some mystery frontier model in the cloud. [00:15:28]
-
-And I just, like, you know, I started with just, like, "Hey, give me a script that will run this model. Start up a, you know, LLM server and then run prompts against it. " And then, like, that grows, "Oh, I need, I wanna be able to kill it and restart. Oh, I wanna be able to, you know, version the prompts as I change them. Oh, I need to have it, you know, run a code evaluator when I'm giving it, like, a code generation challenge." [00:15:42]
-
-Eventually, it became un- unmanageable because of the tech debt. It's, you know, it grew and expanded and I learned more about what was needed. And so I just started over and I said, "Great. This is a Python ball of mess and it sucks and I hate it." So let's talk about the architectural flow of it and now let's add some lint rules and let's rewrite it in effect. [00:16:06]
-
-So it's actually like a high quality code base with, like, resumability and scheduling and whatever. And now it's working way better and it's, like, maintainable. It's been really powerful. [00:16:26]
-
-**Mark:** I freely admit that the very hands-on style that I've got is intentionally learning. I know it's possible to go faster. [00:16:35]
-
-I know that it's possible to delegate a lot more. I am treating it much more as an extension of my IDE and keyboard than I am as a junior developer delegating the work. That's fine. I am good with that. That is what works best for me and my brain. [00:16:43]
-
-**Swizec:** You might start doing that less and less as you use it more. [00:17:01]
-
-I started with doing that a lot more, and then eventually I realized, wait a minute, I'm just clicking yes on everything and then giving it a follow-up prompt to change the things I didn't actually like, but click yes on anyway. [00:17:04]
-
-**Mark:** I certainly didn't think a year ago I would be using any of this at all. I was, I was convinced that was a red line that I would, I would never, ever cross on pain of death, and here I am. [00:17:16]
-
-But also, like, I mean, I've, I've found a workflow that I will be hopefully blogging about in the next day, next couple days that does actually work for me. And the hands-on aspect of it is what I get good results out of, and it's what fits my brain. [00:17:25]
-
-**Carl:** Well, okay, let's take that as jumping off point. Like, what tools [00:17:40]
-
-Let's do, like, super concise, just, like, list what tools and what models you're using day-to-day. [00:17:44]
-
-## Mark's workflow; OpenCode with CodeNomad UI, plus IDE\+git UI. Opus 4.6 on API
-
-**Mark:** So my, my own setup, my intro was the kilocode VS code extension with, you know, it was probably either Sunat 35 or Sonat4, whatever was available around September-ish last fall because I didn't want to go anything command line at first. I wanted to stay in a graphical environment. [00:17:50]
-
-I tried Claude Code for about a day. Tried the VSCode extension, which didn't work at all, and then I tried the command line tool, and I, I did not like it. I tried the OpenCode command line tool, also did not like it. How do y'all deal with copy paste in a command line environment? [00:18:09]
-
-So what I have now, I'm using OpenCode. My personal laptop is Windows. My work laptop is Windows, but I work in WSL. So I actually serve OpenCode from within the WSL environment, and then I use a third party web UI for OpenCode. [00:18:24]
-
-OpenCode has a very nice server client distinction. The text client is just one of the possible clients. So I found one called Code Nomad, which is very good, works great. So I actually serve Code Nomad plus OpenCode added the WSL side, and then I just hit local host whatever port in my browser on the Windows side, which also avoids any cross-platform file shenanigans as well. So I've got my chat sessions and my tabs open in the browser. That's now my development environment. [00:18:42]
-
-And then I still have VS Code open for looking at some of the diffs and editing that my ... I much prefer a Git graphical client called Fork, but it doesn't work well in Linux, so I've just stuck with the built-in VS Code stuff. I actually don't like it, but I've been too lazy to go find a better alternative. [00:19:16]
-
-Model-wise, I've basically been on whatever the latest and greatest anthropic is. We have corporate keys, da, da, da, da, da, da. [00:19:32]
-
-Also, I have somewhat intentionally tried to avoid model hopping. I don't want to be running a bunch of evals every other week and saying, "Oh, this one provides me a 3% increase in such and such a benchmark. Clearly, I need to switch my entire workflow to a different model." and granted, OpenCode does let you just pick and choose what model you want, but I'm trying to get something that's good and consistent and that I know works, not chasing the hypothetical maximum performance. [00:19:39]
-
-**Carl:** Okay. So you're, you're on OpenCode and using latest Claude Anthropic models just through API usage? [00:20:10]
-
-**Mark:** O- Opus 46, yeah. That's the other thing. Uh, it's, it's API keys, not the various, like, you know, $20, $100, $200 max plans. So I, I read about people getting the resets and it's like, I haven't do with that because I'm also not paying for it. [00:20:19]
-
-**Carl:** Right. Cool. Okay. [00:20:32]
-
-**Mark:** It's like knowledge that my experience may not be universally shared. [00:20:34]
-
-**Carl:** Okay. Yeah. [00:20:38]
-
-## Swizec's workflow, latest Cursor on Opus
-
-**Carl:** Yeah, Swizz, what's your workflow look like? I'm curious, I'm very curious about yours because I think you're by far the most advanced agent user between the three of us. [00:20:39]
-
-**Swizec:** Which is really funny because I was surprised to learn earlier this week that 97% of my code is AI because I really talked. I was like, "What?" [00:20:47]
-
-But I actually have an extremely simple setup. I use Cursor, I keep it updated to whatever the latest version. So when it pops up with, "Please update," I click the button. I think the latest Opus model or whatever it is, it's like something 4.6. I think it's an Anthropic model. We have a Team subscription, so CompanyPays gives us an infinite budget, but I think I'm actually using, like [00:20:57]
-
-It's actually funny. I don't know ... We were just talking about this today. I don't know how this happened, but on the Cursor Leaderboard, I have the second most AI usage of all of the engineers, and I have the least amount of dollars used. [00:21:25]
-
-**Carl:** Fascinating. Interesting. [00:21:40]
-
-**Swizec:** I have literally spent $25 this month. So anyway, I use Cursor, I use @cursor on Slack a lot, and I use @cursor on GitHub a lot. [00:21:41]
-
-We also use Linear, and I've started more and more delegating my linear tickets to cursor. So look at the linear ticket, be like, "Eh, I didn't write this well, add a little bit more context so that a dumb bot can know where to go fix things or what to change, and then just click delegate to cursor, and then I review the PRs." [00:21:53]
-
-That's my workflow. I try to keep it really simple and easy, because like Mark said, I'm not looking to super maximize my productivity. I'm more looking for, you know, as a manager, I'm supposed to stay on SiteQuest anyway, so this is a really good way to code between during, uh, between and during meetings when I'm supposed to be paying just like half attention. [00:22:13]
-
-**Carl:** Yeah, that's really interesting. I, I, I like that you two are like kind of two ends of the spectrum here. So as you use it as like very much in a managerial capacity, like, you know, the same as you would ping a colleague, you ping cursor instead and just say, "Hey, do look at this. " [00:22:36]
-
-**Swizec:** Yeah, pretty much. I, I've been doing that a lot. [00:22:52]
-
-**Carl:** And it's all within collaboration platforms, I guess is like a big distinction here. It's all in space- A lot of it is. Yeah. Okay. [00:22:54]
-
-**Swizec:** We're now experimenting with building like a feedback loop so that we would have a bot that Sentry sends us errors and we're thinking of having a bot that looks at those errors, figures out how to fix them, and then just issues a PR when we get, so that we could have automatic PRs- [00:23:03]
-
-**Carl:** Yeah. [00:23:20]
-
-**Swizec:** for, at least for some er- no, like, you know, probably not for super critical, crazy, important things, but there's a lot of errors that happen where it's not that important, but it's nice to fix. [00:23:20]
-
-**Carl:** Yeah, definitely. Right, the long tail of Century issues. [00:23:34]
-
-**Swizec:** But when I'm like actually hands-on coding, I use it a lot to write my tests because I know what I want to test and I can describe the situation to set up, but I hate doing the grunt work of setting up your database in just the right way to have 50 models, et cetera, [00:23:37]
-
-**Carl:** yeah. [00:23:58]
-
-## Carl's workflow, mostly Claude Code but looking at custom orchestrators
-
-**Carl:** Yeah. Okay. Interesting. I, I kind of split y'all's experience a little bit, or I'm working towards ... I feel like I'm closer to where Mark is right now and I'm trying to move towards where you are, Swiz. Yeah, I almost exclusively am using Claude code with Opus. I've played around a bit with ... Like I, I used Copilot, you know, GitHub Copilot, like once to, like, scaffold a prototype that I was experimenting with. [00:23:58]
-
-I don't like the experience of it being in a web browser. Like, something about it ... I don't know. I also don't like code spaces or, like, remote development across SSH. So, like, this may be just my own, like, biases and preferences, but I really like just ... It's right here. It's on my machine. It's an environment that I have set up. [00:24:22]
-
-I know exactly what's available to it and what's not. Just, like, I guess I've prioritized, at least in that where I'm trying to use it like a Mac suit if speeding up my own pr- individual productivity, I just want it to be predictable and understandable for myself. To me, that's very much just been Claude code with whatever defaults pretty much. [00:24:40]
-
-I've played around a little bit here and there, but yeah, I'm trying to work towards ... One of my many projects that I have in flight is a personal, like, orchestrator. So I had started out kind of my foray into, like, earnest AI focused, using it to the extent that I am now, as opposed to more limited reading every line of code, going in and editing it myself. [00:25:01]
-
-## Exploring fully autonomous agents
-
-**Carl:** That's only really been since, like, February when I started playing this AI agent game. And it's been really interesting thinking about ... Because putting an agent in a simulated world and, like, having it autonomously play a game and do so in an interesting way, you know, effectively and interestingly, really just, like, got a bunch of wheels turning in my head. [00:25:23]
-
-And so, like, Claude Code works really well for me for, like, pushing the envelope, like, expanding what a project is, what it can do, and I have really enjoyed using background agents more, like, very much like what you described to us of just, "Hey, oh, fix this. This is broken. Here's this bug." I don't currently have anything like that operational, but I did get my little personal orchestrator working for a minute. [00:25:45]
-
-It was just wor- working on the GitHub API and I just said, like, "Here's a repo, like, go, you know, read the issues, triage them, prioritize them, take a task, open a PR, and wait for me to review it. " And it worked, but I didn't give it any guardrails, so it ended up, like, redoing the same GitHub issue multiple times, or, you know, it would re-review the same PR over and over again with, like, a page and a half of a comment. And so I was like, "All right, okay, this is proof of concept, it works, but, like, clearly I need some additional things set up." [00:26:10]
-
-And I guess one, another thing I wanna say, like, kind of what you said was about, like, using Sentry Data as an input for what to work on. I think that's the frontier. Like, that's what is currently being explored. Like, how do you do that effectively? [00:26:43]
-
-**Swizec:** Yeah. You need the feedback loops. So I was reading a lot of how to build an agent papers the other day, and the main inputs are basically rag, memory, and feedback loops, and from there, it can do a lot. So Cursor, for example, Cursor Cloud agents through Slack, they actually, when they're developing the feature, they will fire up a browser and go test it, see if they can actually do the thing, and if they can't, they will then c- continue iterating. [00:26:56]
-
-And in the end, the PR doesn't just have code. It has screenshots and videos of the working feature, which is what I require from all of my engineers, and it makes reviews so much easier. And there was another ... Oh, yeah. So I think the longest I've managed to do, to have it spin when I asked it to build an entire feature. [00:27:27]
-
-So, like, I would write a maybe 200 word, two or 300 word prompt in Slack to add cursor, and it took ... I think it spent 45 minutes to come back with the working feature, and that was amazing, because I was in a meeting for that whole time, and then I just looked at the PR and gave it feedback. [00:27:47]
-
-**Carl:** Yeah. That's incredible. [00:28:06]
-
-## Mark's AI debugging work in React core
-
-**Mark:** So my day job, we're coming at it from a similar but also sort of opposite angle. We, we have built a time driver to bugger, and originally the premise was that by making a DVR style recording, you as a person can go in and do all the investigating in the lines of code and the print statements and everything else so that eventually you as a person figure out why this was broken. [00:28:08]
-
-So we shipped an MCP a couple months ago, and I've already seen some very real examples of agents being able to go in and solve bugs that they wouldn't have been able to otherwise. I actually put up a post about this a week ago. Dan Abermov had filed an actual React bug saying that the used deferred value hook sometimes fails in production, it's stuck, like a render behind. [00:28:28]
-
-And he had a repro and he said, uh, "I've had my agent try to look at it, but I can't find the answer." A month later, he comes back and files like a four-line fix deep in the guts of React Scheduler to actually fix it. And he posted on BlueSky later, and apparently what he had to do was rebuild the React Library with a bunch of console logging added so that his agent could look at the prod build and eventually trace what was going on and figure out how to fix it. [00:28:52]
-
-So I'm like, "That would be a great marketing post comparison." So I took his example, I made replay recordings of the working dev build and the failing prod build, handed them to an agent, and I said, "Here's a bug report. Here's the two replay recordings. The issue is somewhere in React. Can you find it?" took 10 minutes. [00:29:18]
-
-So I'm like, so then I'm like, okay, well now let's make it like, you know, something resembling a proper experiment. So I took the same two recordings and I spun up four simultaneous sessions with differing instructions. [00:29:38]
-
-The first one was just a basic, here's a bug report, go investigate, actually less context, the proof of concept. The second one, I gave it like a eight step investigative process to follow. The third one had a few paragraphs just naming some concepts and Reacts internals, like not even file structure, but just things like, you know, schedulers, fibers, lanes. And then the last one also explicitly listed some of the replay MCP tools we have available. [00:29:50]
-
-All four of the sessions found the same bug and suggested the correct fix. They took respectively 28, 17, eight, and seven minutes. So on the one hand, you know, ob- obligatory sales pitch, replay recording, finding bugs, it's awesome, it's great. We're building some cool stuff with it. But it also showed me a lot about the value of the prompts and the context that you give. [00:30:18]
-
-There was another example I was working on where someone had made a, an example NextJS app with some example bugs in it and was asking an agent to find them. And in one of them, there's a, there's a double loading screen that's caused by mixing and matching suspense and Tanstack query loading state. [00:30:44]
-
-The AI always suggests the use suspense query hook, but apparently if you do that, it leads to a hydration mismatch error. And the real answer is to do some server pre-fetching instead. So like you have to think bigger, think architecturally. So I did the same thing. I tried, you know, making some re- replay recordings and feeding in the, the varying instructions. [00:31:00]
-
-My agents mostly got the same base level used suspense query error. And then I tried one more session where I fed in the NextJS and TanStack query skills files. And now the agent actually said, "Well, useSuspense query is the initial fix, but you really ought to do server pre-fetching instead." [00:31:21]
-
-## Value of providing more context
-
-**Mark:** So again, like that, that taught me a lot about the proper context. That also says a lot as we're trying to build our own CI debugging agent that looks at test recordings, so clearly we need to give it, you know, good prompts, user-based context, all that kind of stuff. [00:31:42]
-
-So, I mean, I think even something like that can maybe help explain some of the differences and results that different people get. [00:31:59]
-
-**Carl:** Yeah, no, the impact of prompting and available context is, like, so massive. As we're talking workflow, something I do very regularly is, you know, start with a prompt, start with, like, if I'm gonna add a new feature or redesign something or what, you know, a large task, not a bug fix, you know, a sprints project, not a ticket, then I'll start off with, like, a 200-word, like, prompt of, like, "Here's what we're trying to build. [00:32:05]
-
-Here's how I think we will need to do it. Here's a couple of parts that I think are gonna be important." You know, you know, have it explore, do the implementation, review, you know, and then I manually confirm. And then I'll tell it, like ... And I guess I'll do this at a couple of points throughout as it's exploring and, like, evaluating things. [00:32:32]
-
-I'll ask it, like, "How was the documentation? Like, did you find everything you needed?" And that has been, like, totally transformative for, I think for token usage as well, because, like, just by asking that, it'll say, like, "Oh yeah, it was all ... Here's the three files I referenced and I got everything I needed." [00:32:47]
-
-Or, like, "Oh, yeah, this file was out of date. You know, I did the wrong thing at first and then I had to go back and rework it. " So I'd recommend that we update this" and it makes those recommendations just based off its own experience of reading the code. And so, like, just by doing that fairly regularly as the code base evolves, I manage to keep, you know, the documentation pretty well up to date. [00:33:04]
-
-**Swizec:** Are you asking it to write its findings back into documentation or are you updating the docs? [00:33:27]
-
-**Carl:** I'll read it with a skeptical eye of, you know, like, does this sound like it is a real problem or not, a real area for improvement? And then I'll just say, like, "Yeah, hey, can you update those docs?" Often, I'll come at it with a pretty clear intention of, like, we just revamped how scheduling works. Let's analyze the architectural overview document that we have and see if it's still accurate and then tell it ... [00:33:32]
-
-## AI-owned documentation
-
-**Carl:** You know, so, like, I will do some documentation specific projects with that in mind, but for the most part, yeah, just, like, ask it how the experience of the familiarizing itself with the code base is, and then give it free reign to improve that for the most part. [00:33:58]
-
-**Swizec:** Yeah. I think one thing I would be worried with that we have some people in the team experimenting with that, and they all agree that after a few iterations, like, a few weeks later or a few months later, you end up with very spaghettified documentation that's essentially just AI slob that humans definitely don't wanna read, but even the AI barely wants to look at it and read it because it just keeps getting low, lower and lower signal. [00:34:13]
-
-So I think ... I don't have a solution for that, but it's a thing I've heard. [00:34:40]
-
-**Carl:** That's fair. I haven't really evaluated that recently. I did come at it with trying to say, like, "Here's five documents at these levels of abstraction in the code base." So I do try to give it a little bit of overall stru- structural guidance, but that's a good thing to, that's a good thing to look out for. [00:34:45]
-
-I haven't really evaluated it. That's also how I get my own mental model of the code. So I guess, like, I don't necessarily write it, but I will read it, and if it's nonsense spaghetti, then it's like, "No, we gotta do this again." Like- [00:35:03]
-
-**Mark:** That also ties into the longer term memory question. So, you know, the problem is ev- every session is fresh. [00:35:15]
-
-It knows nothing, you know, every, literally everything is being injected, you know, agents, MD, you know, whatever rules, files, et cetera. So how does an agent even know that you have these nice architectural docs that you've been keeping up to date? Or how does it know that, you know, last week, a week earlier, whatever, you made these particular decisions, and that's why we ended up here. [00:35:22]
-
-Or it has no idea what any of your code base is. Let's go read 30 files to re- form a brand new, fresh set of memories that compress the context. And some of this can be, can be dealt with partially. There's ... I, I, I highly recommend tools that will do AST-based scanning of the code base and preferring those for what, for loading chunks of code rather than just, like, blindly whatever built-in read file tools are there. [00:35:46]
-
-But that is actually where I'm running into the limits of my own personal workflow right now. I have, you know, dozens of feature and research docs that I've generated. I have daily progress docs. I have sub-task handoff docs. There's a lot of very valuable information in there, and the AI has absolutely no clue that any of that exists. [00:36:14]
-
-So I'm n- I'm now f- starting to feel the need that I need to have some kind of, you know, review sweep process, some kind of tool to, you know, index the markdown file, something to form that longer term memory structure, and I keep bookmarking hundreds of tools and saying I'm gonna go investigate them and haven't done so yet. [00:36:37]
-
-**Swizec:** If only you had a tool that's really good at summarizing large pieces of text. [00:36:56]
-
-**Mark:** I, no, I, I actually have done some of that. Um, I just haven't actually settled on one and tried installing it yet. [00:37:03]
-
-## Using good engineering practices still matters?
-
-**Swizec:** One thing I found also really helps for context and stuff like that is actually structuring your code well. So having a vertically oriented architecture, small balls of mud that are self-contained rather than one large horizontally sliced ball of mud makes it easier for humans, and it also really works for the AI when you can say, "Go add a feature to this directory." [00:37:09]
-
-And it's the, like, basically use your directory structure as an index for where to find different kinds of code. [00:37:36]
-
-**Mark:** That sounds suspiciously like software engineering practices, and I was told those don't apply anymore. [00:37:44]
-
-**Carl:** Yeah, right. Like, the main thing that I've been trying to keep in mind here of using it, and, and this was, this kind of talk goes back to your recent blog post of, you know, where you talk about how much code A- AI is writing for you, and to just talk to it like, these models were trained on things like GitHub discussions and PR reviews and code comments and whatever. So, like, it's not some new, esoteric, crazy, unpredictable thing. Like, the more you talk to it, just like it's a competent engineer, the more it will behave like a competent engineer. [00:37:50]
-
-And so it has all of these assumptions about, you know, social norms within the context of, you know, text documents describing code and documentation. And so the, the more you understand the social norms that it are deeply baked into its training, the better it does. So, like, yeah, like, I saw these, you know, memory startups where it's like, "Oh, we will automatically generate documentation for your code base and make sure it's up to date." [00:38:22]
-
-And it's like, I'm already doing that with a Read Me document tagged with a GitHash of how, when it was last updated for free. Like, if you have a couple of folders, a couple of directories full of code that is, like, pretty well isolated with a Read Me document in there, like, I don't need to tell the AI to look for the Read Me because it knows to do that. [00:38:49]
-
-Of course, it knows to look for a Read Me. So there's definitely a lot of difficulty with keeping the signal high, but, like, that's not new. I don't know. Like, that just sounds so much to me, like, working on a team of eight engineers and, like, not everyone has the same shared context. Not everyone reads every email or every Slack message. [00:39:09]
-
-And so, like, as far as the challenge of, the, the challenge of keeping a team up to date on best practices and recent decision making, versus keeping an AI at the same level, like, that, those feel really similar to me. It's just engineering best practices and communication norms. [00:39:30]
-
-**Swizec:** With, with the major difference that AI will actually go read the documents you tell, you ask it to read. [00:39:50]
-
-**Carl:** Right, right. Like, one of my, like, you know, war stories was I was a contractor somewhere and they kept having, I kept having to do a rework because, you know, QA was overwhelmed and, like, you know, they finally get around to reviewing PRs and, oh, it's broken. Oh, gotta go back. Oh, there's all these conflicts now because [00:39:57]
-
-And so, like, despite being a contractor, I sat down. It's like, no, we need to fix our review process. We need to fix our merges and whatever. Spent, like, two weeks doing that, get everyone on the same page, man. Next day, the, you know, tech lead employee at the company, the guy who should have been doing that process is like, "Nah, this is too much. Like, I'm just gonna force push." And he took down production. [00:40:15]
-
-So it's so it's like, uh, when people talk about AI doing stuff, it's like, "I don't know, man. Have you ever worked with engineers?" [00:40:37]
-
-## How do you know the right code to make?
-
-**Mark:** Uh, so this, this does tie into a lot of the conversations that I had last week. I, I was at both the AI engineer and React Miami conferences. [00:40:47]
-
-And the general theme of the discussions there between the talks and the people and then, you know, all the different chatter online is we built ... And I also ranted about this in my 15,000 Word unpublished blog post. We built a bunch of software development practices for people, the agile manifesto, linear issues, PR reviews that require multiple people to stamp them or, you know, as a way to share knowledge, standups, like these are all people- based processes, and it made sense when humans are the limiting factor and you have to be very intentional about making sure you're writing the correct code. [00:40:53]
-
-Like, not just does the code work, but are we even spending the time and effort on the right thing in the first place? And we now essentially have a generate infinite amounts of code button, and now we're finding out that we've moved the bottleneck further down the chain into all the verification and QA sides of things. [00:41:32]
-
-And so this shows up in, oops, GitHub is overwhelmed because we've literally 10Xed the number of PRs that are being pushed or, wait, we've got a bunch of senior engineers, but they're literally spending all their time reviewing PRs generated by the junior devs with AI, much less what happens when you have a dark factory of agents cranking out code twenty four seven and no one ever looks at it. [00:41:51]
-
-Like, we haven't figured out what the resulting processes ought to be, and one of the points I make in my blog post is that I think right now we're all operating under the assumption that there's no limit for how fast we can go, and in reality, we're gonna figure out the actual limit is maybe, like, 3X of what it used to be, but we need to, like, accept that and plan for it instead of thinking that if we shove everything in one end of the pipe simultaneously, it all comes out the other end. [00:42:15]
-
-**Swizec:** I have opinions. Um- [00:42:46]
-
-## Good communication still matters
-
-**Swizec:** Yes. I think I wanted to say first is I really like, Carl, you mentioned that you start sessions with a really long 200 word prompt that gives all the context, doesn't just tell the agent what to do, but also why it's doing it in, like, other context. Same. This turns out works really well with humans as well. [00:42:49]
-
-They give you much better work if you tell them why they're doing it or what the goal is. And sometimes if you tell, if you tell them what the goal is, they might even come back with, "Your solution is dumb. We should do this other thing instead," which, wow, can you imagine using engineers' brains for thinking, not just writing code? [00:43:08]
-
-But I think the other thing is, we are generating a lot of code, and we think the bottleneck is code review. I think there's kind of two bottlenecks. One is that when you're moving really, really fast, you have to actually be more careful about working on the right things because if you're just digging yourself into a hole faster, we just had an example recently where we broke Agile, we were like, "Oh yeah, we know what we, what we need to do. Let's just have Claude crank out 6,000 lines of code in one gigantic PR." [00:43:24]
-
-First of all, we couldn't review that, so we had to break it up into a bunch of sub-tasks and then turn that into sub-PRs. Turns out that took another extra day of work and everyone was distracted while doing this, so we weren't focusing on what we were actually supposed to be doing. So I think distraction is still bad. Multitasking is still bad. We're not as good at multitasking as we think we are. [00:43:55]
-
-And the other thing is we, when we split all of that up, we found that Cloud made a tactical mistake very early on, chose the wrong architecture for how to build something with React. And now you have a lot of code that needs a lot of rework to actually make work, and you're wasting reviewing time, you're wa- you're wasting a lot of time that could have been solved if we started with a small task to set up a small thing and talked about it, or maybe even talked about the architecture before we wrote six, 7,000 lines of code, and then just wrote the correct code the first time. [00:44:18]
-
-**Carl:** Yeah, 100%. We're hitting communication bottlenecks much faster now. Yeah, like Mark said. [00:44:54]
-
-**Mark:** Communication and thinking and planning was always the job. [00:44:59]
-
-**Carl:** Yeah. [00:45:03]
-
-**Swizec:** Yep. Except now you're running, like, 10 times faster. So if you take the wrong step or as your first step, you're just running in the opposite direction of where you wanna go, but really, really fast. [00:45:03]
-
-## What will "review" look like in the future?
-
-**Carl:** Right. Yeah. Right. It's very easy to get in extremely the wrong place in exactly the same amount of time. That touches on something I've said before in this podcast. I think that the future of, like, review is gonna be less code review. The architectural side of things is still gonna be important. Like, it's not just, does it work? [00:45:13]
-
-Does it do what you intended? You can't fully treat it as a black box. The box has to be translucent, you know, at least a little bit to avoid major architectural problems that are gonna cause a production outage or make it impossible to scale or whatever. Like, it's not all going to be, does this function. [00:45:32]
-
-But I do think, does it function is going to be a much greater part of this? My sense is that it will rely a lot less on reviewing the code so much as getting a plausible mental model of the architecture, and then it, you know, and then statically verifying that it does what's intended. So, like, my, my theory here is that we're gonna start seeing a lot more end-to-end testing and user acceptance. [00:45:49]
-
-## Automating functionality tests with deployment practices
-
-**Carl:** A thing I did recently that I haven't fully executed on yet, but ... Well, I, I did a lot of it. But so a, a project that I have, I fully rewrote the CICD so that instead of PR checks, review, approve, merge, ship, instead of, you know, that, like, trunk-based development, where every PR gets shipped individually, I move to more of a, like, Git Flow type architecture where it's like, no, here's the version. This is going to go out. Uh, here's our release candidate. And then that single release candidate gets pushed to a staging environment, and then I do the user acceptance testing of does this function as I need it to. And then once I have that, once I've done that manual testing, great. I know this code is working as I meant it to. So now I'm going to have it write a bunch of end-to-end tests to verify that it will continue to do that when I make changes. And I think that's gonna be kind of the new cycle of, like- [00:46:17]
-
-**Swizec:** I want that, but on every PR. [00:47:10]
-
-**Carl:** Yeah, right. And I guess to me, like, that's where manual testing is now the bottleneck. [00:47:12]
-
-Like, you cannot ... At the end of the day, this needs to function, this needs to solve a problem. Any code you write needs to solve a problem that real humans have. Or I guess, you know, sure, other agents or whatever. [00:47:17]
-
-**Swizec:** I've experimented with automated end-to-end testing. It doesn't quite work yet. I think the models are, or at least the models I was trying were too slow, but the idea is that instead of telling that [00:47:28]
-
-Instead of writing a test as what the features that should be there, it's more about, can the user do a thing? And then because you have a computer use model, it can look at the browser and it's automatically testing both your UX. Like, if the model can't figure out how to do what your user is supposed to be, drunk users won't figure it out either, or tired users or whatever. [00:47:39]
-
-So you just point it at the browser and you'd say, "Go, like, go place an order." And at the end of the day, as long as it can place the order it wants to place, you can keep iterating on the implementation, you can keep iterating on the design, you can keep iterating on the UX, you just get tests that are based on can the agent place an order. [00:48:03]
-
-**Carl:** Yeah. Oh, that's really interesting. That's, that's a really good variant on what I was just kind of talking about because, like, sure, static end-to-end tests that are verifying, like, this button with this test ID exists and the flow completes as expected. Like, sure, okay, it functions, but is it usable? [00:48:23]
-
-That's an interesting usability automated usability testing because that kind of goes back to what we were talk- talking about with, like, documentation and code notes. Like, just make it intuitive. Can an agent intuit how to achieve a general task? Oh, that's really interesting. [00:48:38]
-
-**Swizec:** If you've ever used VCR in Rails, that's kind of where I got the idea. [00:48:52]
-
-With VCR, you do full integration testing with calling remote APIs, but you don't wanna call them every time, so you record the responses and you keep them locally. So you then write tests against those local responses, but if the API ever changes or anything, you just regenerate them and you find all of the bugs in your code that don't fit the new, newly released API. [00:48:57]
-
-And you could do something similar with this where you have browser-based acceptance testing, and it records what it's doing so that you don't have to spend as many tokens every time. And you just d- when you change the UI, you delete it and you see if you can do the flow again. [00:49:19]
-
-**Carl:** Yeah. Totally smart. Interesting. [00:49:34]
-
-**Swizec:** Doesn't quite work yet, but that would be really cool. [00:49:36]
-
-**Carl:** We've kind of been going into this direction, but let me, like, sort of, like, you know, refocus a little bit. Like, so what do we think the current landscape of tools, of AI tools looks like? We've kind of been discussing that in, in, we've been dancing around it. And I guess where do we think it's going next? [00:49:38]
-
-**Mark:** Going or ought to go? [00:49:55]
-
-**Carl:** Either, both. Both. [00:49:57]
-
-**Mark:** My general inclination as the person who found one tool set and is stuck with, and is sticking with it and is not actively trying to change what he's doing. [00:49:58]
-
-Certainly what I'm seeing online is turning towards automate all the things, which I think is a very understandable impulse for a software developer. If you can do things once, you can do it in a loop, you can run it in parallel, you can distribute it, you can have an agent do it, et cetera. [00:50:06]
-
-And I think it kind of ties into the go as fast as possible at all costs for the purpose of going as fast as possible, direction that I see. I mean, like this bit about, you know, the dark factories, the idea that a team never even looks at the code, that it's truly all agents all the time, and all you say is, "Do something that accomplishes some goal, and you never even look at it, " is sort of an ultimate outcome of that. [00:50:21]
-
-I don't think it's a good one, but I see how it's the idea taken to a logical extreme. [00:50:48]
-
-**Carl:** I, I also have been pretty ... I found a tool and I'm sticking with it. I've been noticing Claude Code pulling in lots of ideas that I've just been thinking. Like, as it evolves, it's like, this is a productized version of how I've already been using it. [00:50:53]
-
-You know, like they added a /btw command that lets you ask a question and it will ... You cannot use tools and it does not go into the context history. So it's just like even do a little aside. Like if you wanna ask, like, "What's this thing doing?" I had already been doing that by way of, like, I'd ask it a question and then I'd go back and just, you know, restore the conversation to that. [00:51:06]
-
-And similarly, two months ago, I had been saying, like, I would actually spin up a Claude code instance that was on Haiku because I just need to summarize this and it's easier and I wanna manage my usage a little bit more precisely. And, like, now I don't have to do that because I just say, use a subagent and Claude Code is smart enough to say, "Oh, I'm just summarizing. Let me use Haiku." [00:51:27]
-
-## What behaviors belong to the agent, and what fundamentally can't be part of the agent?
-
-**Carl:** So I've just been watching, like, kind of what the agent itself is doing versus what I need to tell it to do, or proactively manage, converge a little bit. So that's, that's had me wondering, what outside of the agent, what is not going to live within the agent. And I think where I've landed on that is, like, everyone's talking about memory the last six weeks or so, and I think that's wrong. [00:51:49]
-
-I think that's just gonna be conventions and documentation. It's just knowledge. I think what's going to persistently live outside of an agent harness, as it were, is, like, incoming information, like a data stream, like GitHub issues, text, you know, the Slack chat, a Century Alert, a production alarm. If you have a data stream that is categorizing those and prioritizing them, and then giving that to an agent, to an autonomous agent that is just working, like, those are different things. [00:52:12]
-
-I think you cannot have a single generic agent that is able to connect to every possible data source. So that to me feels like a boundary that's gonna be pretty strong for the coming months. [00:52:44]
-
-**Swizec:** I don't know. I think for me, I feel like going super deep into what, at least on the internet, a lot of people are talking about various MD files and orchestrations and all the crazy stuff. [00:52:55]
-
-I feel like that's a little bit like ID skins and WIM shortcuts. It's like, yeah, sure, it's cool, but I, I think you're over complicating it. The models are gonna keep getting stronger and better, so I would just think they're gonna be able to do bigger and bigger tasks. I think feedback loops, like what you said, what is outside of the model? [00:53:06]
-
-Building really strong feedback loops is important. I think memory documentation inside the code or making the code itself easier to research or giving it MCP tools to, like, notion or linear or whatever, you keep your organizational memory. Having access to organizational memory will help agents as well. [00:53:25]
-
-Yeah. I don't think we're ever gonna come to full automation of anything, really. I think there's a strong gelman amnesia when it comes to th- these things where agents will fully automate every job except the ones I'm strict, super familiar with. That is just way too complicated and there's too many deals. [00:53:46]
-
-Everyone feels that way about their job because newsflash, they're all too complicated. [00:54:06]
-
-**Carl:** I wanna explain that reference briefly for people who aren't familiar. Gelman and Amnesia, that refers to the idea of, like, you're reading a newspaper and you see a story about your professional industry or something you're very knowledgeable about, and you see everything that it got wildly wrong, and you're like, "Who even wrote this? What are they doing? These incompetents." [00:54:11]
-
-And then you read the next article, and you're not familiar with it, and you just take it super credulously, and it's like, "Oh, yes, look at these," you know. It's a, like, I think that's a pretty good way of thinking about how people are talking about AI right now, yeah. [00:54:29]
-
-**Swizec:** And I think, from my perspective, go hard as long as you can. I think the bubble is going to collapse in the next one to two years. Tokens are gonna become super expensive, and we're not gonna use as many of these tools long-term as we are right now, but we're gonna have a lot of infrastructure, like, just like we did after the dot-com. [00:54:41]
-
-**Carl:** That's part of why I've been really interested in local models, because I agree with that. Like, they're being heavily subsidized right now, and I think in, I don't know, about two years, I don't know, we'll see. It's been very ... People are talking about it, it feels like the wheels are falling off right now with, like, Claude Code is just clamped down usage on the 20 d- $20 a month plan aggressively. [00:55:02]
-
-**Swizec:** They grew from nine billion ARR to 30 billion ARR in a quarter, so I'm imagine they have some scaling issues. [00:55:22]
-
-**Carl:** Right? Yeah, clearly. [00:55:30]
-
-**Mark:** One of the points I made in that draft blog post that I'm hoping to publish this week, the cats out of the bag, like, even if OpenAI and Anthropic were to utterly and completely collapse and go out of business today, the technology exists. [00:55:32]
-
-And whether it's, you know, boutique hosting of models or local LLMs, the technology is not going to go away. And even if it only, even if it never gets better at all, the t- the capabilities stay exactly the way they are today, it's still curly enough to upend large parts of our society. So then the question becomes, w- what are you doing with it and how do you, how do you respond? [00:55:46]
-
-**Carl:** Well, that's a good ... We should wrap up soon, but that is an excellent jumping off point for our last little subject here. [00:56:12]
-
-## Impacts of LLMs on software engineering?
-
-**Carl:** Uh, what do we think the impacts of LLMs on engineering as an industry, software engineering as an industry, and maybe more broadly, societally, if we wanna go there? [00:56:17]
-
-**Swizec:** I would say it's raising the bar for everything. [00:56:30]
-
-Like, what counts as a minimum viable product is gonna get more fancy and more complicated. What counts as a junior entry-level engineer, or what the expectations are for a junior entry-level engineer are gonna go up, and I think we're gonna need a lot more, um, product sense, and a lot less being just really good at writing code. [00:56:32]
-
-**Mark:** Yeah, I'm inclined to agree. I am honestly worried about the impacts in society as a whole. We've seen lots of debate and studies about, you know, have, have cell phones effectively destroyed the minds of youth and the ability to focus and social bul- like electronic bullying and, like, very ... Like, why did teens get very depressed starting in 2012? [00:56:54]
-
-Like, that sort of thing where a technology possibly had large-scale societal effects. And I'm not saying that LLMs are, you know, inherently destructive or inherently bad, but a lot of times the technology gets invented and then it changes society in ways we were very unable to predict early on. In this case, I think we can predict a number of ways, and there's probably a whole lot of other stuff, too. [00:57:14]
-
-So I genuinely worry about college students being able to get away without having to develop critical thinking skills even less than they were able to get away with it before. I have concerns about that sort of thing. And, you know, I'm towards the tail end of my career, I've done my thing, I learned, I gained my experience. [00:57:40]
-
-I don't know how junior devs are going to gain some of that experience. Maybe it is they need different experience. I don't know what the job pathways look like at that point. So, like, I mean, don't get me wrong, I'm excited to be able to use AI to crank out some of the things that I've had in my head. [00:57:58]
-
-I've found some of the same joy in being able to have a multi-hour flow session and build stuff just with AI editing the files instead of me and my fingers. But I can also look around and say, "Yeah, there's a bunch of unexpected consequences floating around as well." [00:58:14]
-
-**Swizec:** I mean, in terms of experience, it's not like I know how to code without a compiler, and I would definitely not enjoy coding without a, without garbage collection. [00:58:31]
-
-**Carl:** Yeah, I think that's closer to my theory on this. I think it will, you know, the societal impacts are gonna be something a lot. We'll see. I think the societal impacts will come mostly not from software engineering, so I think I don't understand those quite well enough to opine on it too much. I do care a lot about, like, sociology and economics and whatever. [00:58:41]
-
-So I do have thoughts and opinions, but I th- maybe it's a, maybe it's my Gelman new amnesia of like, I know those well enough that I'm like, "Nope, that's way too complicated. I'm not no opinion." But I think we take for granted a little bit how much we're standing on the shoulders of giants already and like, this is a big giant to climb the shoulders of for sure. [00:59:02]
-
-Like, not trying to discount that. People talk about how it's gonna change our brains and like, you know, destroy humanity and whatever. And like, I don't know, like, we kind of did a lot of that already. Like, can you navigate in your city without GPS? There's a lot of stuff that we've already lost that used to be like, canonically like, you know, you used to have a navigator. If you wanted to do a road trip, like, you would have spent a week planning a route and then, like, God help you if you miss a turn. Same thing for, like, finance and, like, the spreadsheet. I don't know, this is gonna be, this is a broad, more broadly applicable thing than any of those past technological leaps. [00:59:21]
-
-Another thing that I learned recently, going on the societal level again, there was a ... In 2023, there was an, like, international, like, literacy survey done, levels and whatever. And I think level one was can read, but struggles with, like, finding knowledge in text or, like, following multi-step instructions. [00:59:58]
-
-And 28% of Americans m- met that were, you know, were tested at that level of literacy. And, like, it said anything below level three is considered partially illiterate. And the stats were half, half- [01:00:20]
-
-**Swizec:** 54% of Americans are less than sixth grade reading level. They will not do well with LLMs. [01:00:35]
-
-**Carl:** Right. But, like, you know, we did that before LLMs. [01:00:42]
-
-That was 2023. Like, okay, sure. Like, there's gonna be weird shit going on since then now, but, like, God, we already ... Like, as far as destroying society, like, we've done a pretty good job of that without AI. [01:00:45]
-
-**Swizec:** And for context, that's 54% of adult Americans. It doesn't, like, count children and stuff. [01:00:57]
-
-**Carl:** Yeah. [01:01:03]
-
-I don't know. It's just, like, anytime I hear people talk about, like, the downfall of, like, civilization or whatever, it's like, "I don't know. Have you looked at civilization lately? It's not doing so great." So, I don't know, it is gonna be a lot. It's gonna be challenging and difficult. I guess going back to engineering, software engineering, you remember the '90s and 2000s, 2010s era, like, stereotypes of software engineers, like, it's, like, super autistic, like, zero social skills. They are a human computer. [01:01:03]
-
-And now we don't have that anymore. We, you know, democratize software engineering and now everyone does it. We've always tried to get something basically like an LLM. Like, that's what people wanted out of software engineers this whole time. So, I think it's gonna be ... I like the analogy of, like, compilers and garbage collection and stuff, because it's just a new tool. [01:01:31]
-
-It's a new level of abstraction, and now it's much further removed from the hardware. But, yeah, I don't know. People talk about, like, the d- it's gonna destroy, like, the upskilling, it's gonna destroy junior engineers, and it's, there's not gonna be any pathway in. And, like, I don't know, maybe that's true, but at the end of the day, I'm gonna end on, like, a positive thought or, like, advice. [01:01:54]
-
-Like, this is all communication. It's just more and more communication. If you wanna lock in your software engineering career, get good at communicating, get good at deeply understanding and articulating a problem, not the code, not the patterns necessarily, but, like, understand what an architecture is good at or bad at or what the performance profile of this or that are. [01:02:18]
-
-And, like, now, you don't even need to understand it at the same level. Like, I've been really excited about AI is because I have such a broad and shallow expertise, and now I can use it. Like, it used to be that I had all this, like, vague notional expertise in a wide range of stuff, and it's like, "Damn, I wish I could use that, but I would need a team of 15 people in order to be productive with this. [01:02:45]
-
-And now I don't. So, like, I don't know, that's exciting for me. And I think that's just generally exciting. So if you're just good at communicating and you learn a domain and you get good at articulating problems within that domain, then, like, I think you're gonna be fine. [01:03:08]
-
-## A superpower right now is a domain expert who can kind of code
-
-**Swizec:** I think superpower right now is if you're a domain expert who can kind of code. [01:03:22]
-
-**Carl:** There is certainly still value in, you know, greater engineering expertise and understanding how to ship stuff to production. [01:03:28]
-
-**Swizec:** At some scale, that becomes a domain expertise. [01:03:34]
-
-**Carl:** True. Yeah. Extremely true. So yeah, I don't know. [01:03:37]
-
-**Mark:** Uh, I'm excited. I [01:03:41]
-
-**Swizec:** can build more stuff. [01:03:42]
-
-**Carl:** I can build so much ... I have built so much more. [01:03:43]
-
-I've explored so many more things and gone, "Oh, this is harder than I thought. I'm gonna set it down." Instead of just never doing it and, like, fantasizing about what it could have been for years, you know? [01:03:45]
-
-**Mark:** Yeah. Same. [01:03:54]
-
-**Carl:** All right. Cool. Thank you all. Thank you both for joining me. Thank you everyone in the audience for listening. [01:03:55]
-
-Appreciate it a lot. [01:04:00]
-
-**Mark:** Hopefully this was informative. [01:04:01]
-
-**Carl:** Cool. All right. Well, this has been this month in React, quote unquote. I think we may be exploring different formats in the future because, I don't know, who's following individual software library development as closely anymore. But yeah, thanks so much for listening. [01:04:02]
-
-If this is a show that you get value from, please send it to a coworker, send it to a friend, leave us a review. And yeah, I'll see you next month. [01:04:17]
-
-**Mark:** All right. Take care. [01:04:25]
diff --git a/src/transcripts/tmir-2026-05.md b/src/transcripts/tmir-2026-05.md
deleted file mode 100644
index 9a121cd..0000000
--- a/src/transcripts/tmir-2026-05.md
+++ /dev/null
@@ -1,645 +0,0 @@
----
-title: "TMiR 2026-05: Who even is on the Core team anymore, TanStack got pwn'd bad"
-date: 2026-05-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we discuss what the heck is going on at the React Core team, how TanStack got pwn'd so badly, and how the JS ecosystem is reacting to the aftermath of the React2Shell fallout."
-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:55](#some-podcast-meta)] Some podcast meta
-- [[00:01:49](#new-releases)] New Releases
- - [[00:01:51](#ts-v7-beta)] [TS v7 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/)
- - [[00:05:15](#rolldown-10)] [Rolldown 1.0](https://voidzero.dev/posts/announcing-rolldown-1-0)
- - [[00:06:51](#fate-10)] [Fate 1.0](https://fate.technology/posts/fate-1.0)
-- [[00:09:48](#main-content)] Main Content
- - [[00:09:56](#react-core)] React Core
- - [[00:10:09](#react-team-status-after-meta-layoffs)] React team status after Meta layoffs?
- - [[00:14:59](#react-compiler-port-to-rust-still-in-progress-latest-pr)] [React Compiler port to Rust still in progress](https://x.com/poteto/status/2056865079543681329), latest [PR](https://github.com/facebook/react/pull/36173)
- - [[00:15:54](#tanner-linsley-is-projecting-react-its-definitely-not-a-fork)] [Tanner Linsley is "projecting" React](https://tannerlinsley.com/posts/projecting-react) (it's definitely not a fork)
- - [[00:21:38](#tests-are-the-new-moat)] [Tests are the new moat](https://saewitz.com/tests-are-the-new-moat)
- - [[00:23:32](#brooks-lybrand-thoughts-on-react-community-after-react-miami)] [Brooks Lybrand thoughts on React \+ community after React Miami](https://brookslybrand.com/posts/react-miami-2026.html)
- - [[00:25:04](#tanstack-is-exploring-how-to-expose-server-components)] [TanStack is exploring how to expose Server Components](https://tanstack.com/blog/react-server-components)
- - [[00:27:19](#who-owns-the-tree)] [Who Owns the Tree](https://tanstack.com/blog/who-owns-the-tree)
- - [[00:27:31](#rscs-in-tanstack)] [RSCs in TanStack](https://frontendmasters.com/blog/react-server-components-in-tanstack/)
- - [[00:28:12](#remix-v3-beta-preview)] [Remix v3 beta preview](https://remix.run/blog/remix-3-beta-preview)
- - [[00:28:35](#both-remix-and-tanstack-are-exploring-what-if-no-react)] Both Remix and TanStack are exploring "what if no React"?
- - [[00:36:11](#tsrx-a-variant-on-jsx)] [TSRX](https://tsrx.dev/), a variant on JSX
- - [[00:41:52](#security-everything-is-compromised)] Security! Everything is compromised
- - [[00:42:04](#tanstack-router-compromised-and-socket-analysis)] [TanStack Router compromised](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem), and [Socket analysis](https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack)
- - [[00:46:58](#tanstack-followup-with-followup-hardening)] [TanStack followup with followup hardening](https://tanstack.com/blog/incident-followup)
- - [[00:47:10](#nx-monorepo-tool-compromised-as-a-result)] [Nx monorepo tool compromised](https://nx.dev/blog/nx-console-v18-95-0-postmortem) as a result
- - [[00:52:02](#react2shell-recaps-from-lachlan-davidson-and-sylvie)] React2Shell recaps from [Lachlan Davidson](https://lachlan.nz/blog/the-react2shell-story/) and [Sylvie](https://sylvie.fyi/posts/react2shell/)
- - [[00:52:25](#next-1625-and-more-react-cves)] [Next 16.2.5 and more React CVEs](https://github.com/vercel/next.js/releases/tag/v16.2.5)
- - [[00:53:19](#npm-adds-staged-packages-and-e18e-adds-guidance)] [NPM adds “staged packages”](https://docs.npmjs.com/staged-publishing) and [E18E adds guidance](https://e18e.dev/docs/publishing.html#staged-packages)
- - [[00:54:50](#pnpm-11-defaults-to-min-release-age-npm-12-will-block-by-default)] [PNPM 11 defaults to min release age](https://socket.dev/blog/pnpm-11-adds-new-supply-chain-protection-defaults), NPM 12 will [block by default](https://github.com/npm/rfcs/pull/868)
- - [[00:57:59](#review-your-gh-actions-people-)] [Review your GH Actions, people!](https://github.com/e18e/ecosystem-issues/issues/266)
- - [[00:59:13](#mark-posted-his-big-ai-blog-posts-part-1-fears-and-journey)] Mark posted his big AI blog posts. [Part 1: Fears and Journey](https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-1-fears-opinions-journey/)
-- [[01:08:39](#outro)] Outro
-
-# Interview
-
-**Carl Vitullo:** Thank you for joining us. We're coming to you live from Reactiflux, the place for professional developers using React. And I am Karl. I'm a staff level product developer and freelance community leader/entrepreneur/I don't know what I am anymore, here at Reactiflux, where I do community programs like this and build some tools to help keep the community operating. [00:00:00]
-
-**Mark Erikson:** And I'm Mark. My day job is at Replay, where we've built a time traveling debugger for web apps, and that can be used by both humans and agents. And in the last couple months, I've gone between building MCP tools, doing product manager work, being a dev rel, going on vacation, and now I'm trying to figure out what I'm doing now that I'm sort of back, except that I'm going on more conference travel shortly. So it's kinda crazy right now. [00:00:19]
-
-I do Redux stuff and I collect links. [00:00:41]
-
-**Carl Vitullo:** Man, we're all doing too much stuff. It's just too many things. [00:00:43]
-
-**Mark Erikson:** Indeed. My... I, I needed that vacation. Two weeks of golf in Scotland. It was fantastic. [00:00:46]
-
-**Carl Vitullo:** Yeah, that's pretty good. Scotland's great. I love Scotland. [00:00:52]
-
-## Some podcast meta
-
-**Carl Vitullo:** Okay, let's get into it. Before we go into, like, new releases and whatever, some, like, meta discussion whatever, historically we were co-hosted by Mo, who brought us some lovely React Native and agency perspective here. He's had to step back a bit because of just, like, personal things and work busyness, and he just hasn't had the time and energy to really go up here. And I guess I, I also wanna mention, I am feeling somewhat similarly. I've been doing this for, like, three years now. I'm no longer reading React and web news at the level of intensity that I historically have been. [00:00:55]
-
-So, um, yeah. Mark and I are talking about how to continue this. This is a valuable service. I think this podcast is good. I want to keep it going. I think a once a month news check-in about the ecosystem is really valuable, so I wanna keep offering it. But, uh, that's where we're at. So just FYI, stuff is gonna change. [00:01:25]
-
-Stuff has changed. Stuff will continue to change. Just like life. [00:01:40]
-
-**Mark Erikson:** Yeah, that sounds all too real. [00:01:44]
-
-**Carl Vitullo:** We're gonna try and keep doing this, but it'll be a little different than we have. [00:01:46]
-
-## New Releases
-
-**Carl Vitullo:** But yeah, okay, into some new releases. [00:01:49]
-
-## [TS v7 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/)
-
-**Carl Vitullo:** First off, we have the TypeScript v7 beta, which is, if I recall correctly, this was gonna be the one where it's all rewritten. [00:01:51]
-
-**Mark Erikson:** This is the TS Go release, and you might also notice this is pretty hot on the heels of TS 6.0. So TS 6.0 is supposed to be the last actual release of the current written in TypeScript compiler, and 6 is the one where they changed a bunch of defaults to be more strict and better match the way JavaScript's used today. [00:02:00]
-
-7 is same settings, but completely different compiler implementation. One interesting bit here is I believe that 7.0 is not going to have a lot of the programmatic API stuff that exists right now. Uh, I think they said they hope to get that out in a 7.1. That does mean that there is definitely going to be some amount of, like, fluctuation and churn as you go upwards. [00:02:22]
-
-But in terms of just using the compiler to type check, go ahead and start using 7. Like- Cool ... right now. It's there. Okay. It's faster. It's the same logic. Use it right now. [00:02:49]
-
-**Carl Vitullo:** So that's like the SDK, like if you're using TypeScript to do some build tools, using it in JavaScript yourself, that's not feature complete yet? [00:03:00]
-
-**Mark Erikson:** Right. So yeah, so I, I don't know what all is and isn't- [00:03:09]
-
-**Carl Vitullo:** Right. I've never used that, so ... [00:03:14]
-
-**Mark Erikson:** intended to be included in the API. But like, for example, in Replay's code base, we have some programmatic linting stuff that uses the TS Morph package, and TS Morph depends on being able to import the TypeScript as a library and create- Right [00:03:15]
-
-a program instance and programmatically type check. And so that sort of thing might not fully be available in 7.0, but maybe in 7.1 in some form. [00:03:30]
-
-**Carl Vitullo:** Yeah. That makes sense. Interesting. Yeah, I mean, that stuff's always a little bit... Usually, when you're trying to use it as an SDK in that way, it's because you're doing something a little bit more finessed and complicated, so it makes sense that that takes a little more time to, to settle out. [00:03:43]
-
-**Mark Erikson:** I know that there's, in general, a lot of issues because people have reached into TypeScript's internals to im- be able to import methods that were never really intended to be exposed- Right ... to the public. [00:03:57]
-
-**Carl Vitullo:** Classic. [00:04:08]
-
-**Mark Erikson:** As well as just the fact that it's one thing when it's TypeScript importing TypeScript. [00:04:09]
-
-It's another thing when the TypeScript implementation is now in another language, Go, and so how do you expose that back to TypeScript client code, as well as how do you do so performantly, 'cause you're now crossing the language barrier? I know that's what the, like the Oxlint folks have been dealing with in terms of trying to implement typed linting, but needing to go back and forth between pieces written in different languages. [00:04:14]
-
-**Carl Vitullo:** Mm-hmm. The parallelization is interesting. I, I... Like, that's such a good reason to reach for Go, is to introduce parallelization, 'cause, like, Go routines and, you know, whatever. Go is good at that. Well, that's really cool to see that TypeScript is now doing... It says, "Now performs many ch- steps in parallel, including parsing, type checking, and emitting." [00:04:43]
-
-Anytime you can break work down into smaller units that can be isolated from each other and executed in parallel is awesome. So love seeing that being brought into TypeScript. Like, that's so core and foundational. That's awesome. [00:05:01]
-
-## [Rolldown 1.0](https://voidzero.dev/posts/announcing-rolldown-1-0)
-
-**Mark Erikson:** And then on a similar note, the Void Zero folks announced that Rolldown has hit 1.0. [00:05:15]
-
-And to recap what that is, uh, Vite had been using two different bundlers, had been using esbuild, which is fast and written in Go for development mode, and had been using Rollup, which was a written-in-TypeScript JavaScript bundler for production builds. And so in order to both make it go faster and harmonize things, you're doing both dev and prod builds with the same pipeline, they essentially re-implemented Rollup but in Rust and called it Rolldown. [00:05:20]
-
-So yet more build tools being written in Rust, and it's been a long time coming. Vite has been using Rolldown in various betas for a while. And Rolldown itself has now actually hit 1.0. [00:05:52]
-
-**Carl Vitullo:** Cool. Yeah, I was just trying to refresh my memory on... 'Cause we've, I feel like we've been talking about Rolldown 1.0 for, like, a really long time. [00:06:05]
-
-So I was like, "When was that?" It looks like we had the, there was an RC of 1.0 back in January. So, like, that's some pretty serious, you know, d- I don't know, dedication to stability and rollout. Can we just add one more, it's a suffix to roll by s- describing this as a rollout? We'll get the, the rollup, Rolldown rollout. [00:06:13]
-
-But yeah, so okay. So they've been in RC. They've had a Rolldown 1.0 RC out since January, and they're calling it good. They're shipping it. That's awesome. [00:06:32]
-
-**Mark Erikson:** Yep. Wonderful stuff. [00:06:40]
-
-**Carl Vitullo:** Love that. Great. Well, yeah, and you can, uh, listen to our January episode to see, uh, to hear us discuss that previously. [00:06:42]
-
-**Mark Erikson:** All right, and then one other release to announce. [00:06:48]
-
-## [Fate 1.0](https://fate.technology/posts/fate-1.0)
-
-**Mark Erikson:** Christoph Nakazawa has released Fate 1.0. So we, uh, we'd mentioned this a couple times previously, but Fate is a new React-based data fetching library. My closest comparison is it's kind of like a GraphQL in the sense that the client is specifying pieces of data to fetch. And to be honest, I still don't have a, have a f- really good grasp on how this works. [00:06:51]
-
-I've just seen some of the d- some of his descriptions. But it's meant to be composable queries, normalized data fetching, and integrating with React's new async and suspense-based features. My understanding is that this is very heavily... I'm not gonna say, I'm not gonna say vibe coded. I, I know he's, like, been very intentional in how he's built it. [00:07:18]
-
-My understanding is most of the actual code here was written with AI tooling, with a lot of intent behind it. [00:07:43]
-
-**Carl Vitullo:** Yeah. That's fair. I don't know. Written with AI tooling and vibe coded are not the same thing. That's interesting. I don't know. This definitely looks kinda interesting. It looks like it's trying to be something, like you said, kinda GraphQL-ish, re- relay-ish, TanStack, you know, ish. [00:07:49]
-
-But I guess, like, from first principles in the server components era- I guess is how it feels to me reading this. That's interesting. That's valuable. That's a really good exploration, but is- I don't know, something about this says r- like, research project more than something I would bet my, you know, bet my work on. [00:08:05]
-
-**Mark Erikson:** My vague sense, and this is just, you know, me eyeballing things as always, real project, not just a, an experimental toy. Early obviously, and I would assume no one else is actually using it at the moment, but it's the kind of thing that I could see getting some- Right ... amount of adoption over time. [00:08:26]
-
-**Carl Vitullo:** That's curious. [00:08:42]
-
-That's interesting. Yeah, we'll s- have to see how it goes. That's really interesting. Love having more explorations on ways to do data fetching better. I'm having thoughts come up that I know I'm also going to wanna discuss when we start talking about Remix V3 in a little bit. It's so s- funny to me how much exploration has been done over the last 15 years in, like, how do we transfer data and UI across the network? [00:08:43]
-
-We're still figuring that out. So I, I have more to say on that when we t- talk about Remix V3. But, you know, this is interesting. This looks like a valuable exploration. Christophe Nakazawa is definitely someone to take seriously. [00:09:09]
-
-**Mark Erikson:** And int- interestingly, I believe he actually joined Void Zero as a company, and his day job stuff is now around some of the, like, the Void server framework pieces that they're building. [00:09:21]
-
-**Carl Vitullo:** Oh, yeah. Interesting. He says he's product at Void Zero on his Twitter. Curious. That's cool. Very cool to see him still so, like, deeply embedded in the ecosystem, and then doing, like, little research side projects like this. Prototypes of alternate usage patterns. Cool. [00:09:32]
-
-## Main Content
-
-**Mark Erikson:** Okay, onto something resembling main content, and something resembling React core-ish stuff. [00:09:48]
-
-## React Core
-
-**Mark Erikson:** So this first bit is something that I surprisingly don't actually have much of a link for, but I'm going to try to pass on a summary of bits and pieces and conversations that I've had in multiple places. [00:09:56]
-
-## React team status after Meta layoffs?
-
-**Mark Erikson:** Loosely put, I have no idea who's even still on the React team at this point, for multiple reasons. [00:10:09]
-
-So Meta just went through two rounds of layoffs, and from watching things, I know that there was some shuffling in and around r- the React organization. For example, I think the Relay team used to be considered part of the React org, and now they're part of a separate organization. But a number of people that I know have, appear to have left the React team one way or another. [00:10:17]
-
-Uh, for example, Lauren, who'd been working on the React compiler, is now over at Cursor. I believe I saw that Sebastian Markbagha has left Vercel and is possibly not labeling himself as being part of the React team at this point. Joe Savona, who was essentially a lead on the React team for the last year or two, I heard a rumor that he has been reassigned to something else AI related. [00:10:43]
-
-These are all bits and pieces. I don't have, you know, direct links for them. But the picture I'm getting is that what we would consider the React core team has been kind of decimated. If you were to ask me right now, like, who am I pretty sure is on React core at the moment, about the only people I could still point to would be Andrew Clark at Vercel and Rick Hanlon at Meta. [00:11:11]
-
-There's still a bunch more beyond that, but just, I, I, like, I literally don't know who is working on React right now, which is not a thing I would've said last fall at React Conf. And so, this also brings up a number of other questions because Seth Webster was the head of the React org at Meta, and he also spent the last few years quietly trying to put together the React Foundation, which got announced. [00:11:34]
-
-And I've been trying to keep an eye on, you know, any news and discussion of where the foundation is. Seth himself just moved over to Expo. That was publicly announced. And I believe he's still going to be the head of the React Foundation, but I also have seen no evidence of anything as far as actual work or output from this foundation, either in terms of community involvement or events or taking over the day-to-day technical work on React itself. [00:12:00]
-
-I actually did see in a PR yesterday, Sebastian Silbermann, who is essentially part of the React Core and Core team externally at this point, did make a mention of moving repositories over to a React Foundation org, at which point they might be doing some, you know, kill and kill AI and bot spam type cleanup. [00:12:38]
-
-So all this says to me that they're, like, things are changing around React's development process, both who's doing it and where it's happening, but it also feels, just me observing things, it feels like things are fragmenting and stalling. And I actually legitimately do not know what that means in terms of technical development on React itself in the near future. [00:13:02]
-
-**Carl Vitullo:** Strange, curious, yeah. So I'm in a, I'm in a Discord for the React Foundation, and I noticed over the past several months that virtually nothing has happened in there. [00:13:28]
-
-**Mark Erikson:** There's been essentially no conversation except maybe there was a little bit of chatter about something React Native related, like a week ago. [00:13:41]
-
-**Carl Vitullo:** And I saw something about a contributors Discord as well, so I think there's a private space being set up for people who are act- actively contributing code to React Core. But I, as someone who does not contribute code to React Core, I'm not in there, and I, so I don't know exactly what's going on. I do note that the website, you know, react.dev Meet the Team, lists Sebastian, lists Lauren. [00:13:48]
-
-So it lists a number of people who are, you are saying, have been publicly confirmed as no longer- [00:14:11]
-
-**Mark Erikson:** I think Lauren may still be involved with the compiler. I don't think she, I don't think she entirely left the team, but she certainly left Meta overall. Sebastian, I got the impression he's, he's out for now, but- [00:14:16]
-
-**Carl Vitullo:** Well, certainly at least job titles are out of date, 'cause, you know, Lauren Tan says engineer at Meta, and so if she's no longer at Meta, that's wrong. [00:14:30]
-
-This website has not been updated. So yeah, oof. That's, uh, yeah, okay. Certainly lack of community engagement, I would say. [00:14:38]
-
-**Mark Erikson:** Having said that, I have spent a lot of time over the years just watching the list of PRs in the r- in the React repo, just to get a sense of what's going on, and I hadn't done that much over the last few months just because of travel and life and work and stuff. [00:14:45]
-
-## [React Compiler port to Rust still in progress](https://x.com/poteto/status/2056865079543681329), latest [PR](https://github.com/facebook/react/pull/36173)
-
-**Mark Erikson:** I was looking at it the other day, and the bulk of the PRs that I'm seeing at the moment do actually have to do with either things like updating some of the release process or, uh, some work on the React compiler port to Rust. And in fact, Lauren just confirmed on Twitter the other day, that is still actively being worked on. They are testing it out internally at Meta. I believe she's still involved in that from her side. They are trying to push that along. I do think that's gonna be a big deal for c- for a couple reasons, because eyeballing things, to me, the biggest blockers to people adopting the compiler right now are the comp- are the requirement that you still have to use Babel as part of the build process, as well as the speed of the compiler. And so if porting the React compiler to Rust makes it faster and eliminates the need for Babel, then those two roadblocks go away [00:14:59]
-
-## [Tanner Linsley is "projecting" React](https://tannerlinsley.com/posts/projecting-react) (it's definitely not a fork)
-
-**Mark Erikson:** All right, so, uh, that, that brings us up to a very interesting and somewhat controversial article, which is Tanner Linsley not quite forking React itself, projecting React. So the, the idea here is the React team has spent a lot of time over the last eight-plus years adding all these new fancy async concurrent features to React. [00:15:54]
-
-As we've talked about, they had a general vision for what they were trained to build, and they've essentially arrived at what their vision roughly was. But, you know, a lot of us are still building React apps that don't make use of the new features or don't, you know, just don't need all the capabilities that are in there. [00:16:19]
-
-But React as a package is delivered as a giant monolith. There is no option for, like, disable concurrent mode or something like that. And so all the code that implements this goes in the bundle whether you're using it or not. And that also means a lot of the logic and the checks that take up time are still in there. [00:16:37]
-
-And so Tanner actually went out and he cloned the React repo, and he told an AI essentially, "Rip out all the pieces of React that I personally do not need," and he was able to rebuild React with a lot of pieces stripped out, and it drastically shrank the bundle size, and it sped up SSR. And he is actually running his own personal website in tanstack.com on this personal modified fork of React. [00:16:59]
-
-He didn't wanna call it a fork, 'cause that term has a lot of political implications, so he called it a projection of React, in the sense of, like, projecting data or, like, viewing a subset of the data. And so technically he's made the changes available, but he is very intentionally not telling people to go try this. [00:17:32]
-
-Like, this is not Tanner saying, "I'm forking React, use my version." This is, "I played with something and if you want to look at what I did, it's over here, but I'm actually kind of telling you don't use what I did." And I've seen mixed reactions to this. I saw a number of people say, "This is a horrible idea," because, you know, LLMs can make mistakes, and if we start modifying packages, then there's the risk of introducing new bugs and security problems that w- that got handled in the original, and if you're mod-- If, basically if you're making changes, you run the risk of breaking stuff. [00:17:55]
-
-And I get that But I'm actually kind of in favor of this idea for a number of reasons. Like, code is not sacred. Code is there. A license says anyone can modify this if, you know, however they want. If Tanner wanted to fork this, that would be a totally valid thing to do morally, legally, ecosystemly. Maybe not a good idea, but it's a totally valid option. [00:18:31]
-
-But also, React exists in its current form because the React team wanted to pursue certain ideas. It's totally valid for other people in the ecosystem to say, "I would like to pursue different ideas and trade-offs and see what happens." And especially given the way that it looks like React development is kind of fragmenting and stalling slightly, I am entirely in favor of people trying to do different experiments. [00:18:55]
-
-**Carl Vitullo:** Yeah. Like, this is making me think back to some of our, some of the conversations we've had over the years at this point. And like, you know, so something that I, I've expressed pretty consistently is this sense of React as a, like, research project, pushing the envelope of what's possible with UI over the network. [00:19:24]
-
-And I think a very real tension with React versus how it's used is not everyone is trying to push the envelope of what's possible with UI over a network. Some people just want it to fucking work, and React needs to serve everyone In a way that they want. So, it... And so, you know, okay, so bringing it back to this specific blog post, Tanner Linsley projecting React, his motivation here was React's bundle size is quite large, and that's true. [00:19:42]
-
-It's quite big, and it's quite big because it's trying to do a lot of things in a generic manner for a lot of different people. And so I think there's a very real argument here that if React is trying to do five different things for five different customers, I am going to use AI to remove the code for the four customers that I am not. [00:20:14]
-
-I am only using this surface area. This surface area has pretty clearly defined contracts and testing guarantees, so I am going to rewrite this part of the surface area that I am touching. And I think that makes a ton of sense here. [00:20:38]
-
-**Mark Erikson:** Yeah, and it, it also ties into another theme that we've seen going on a lot lately, where people are taking publicly available tools, libraries, whatever, AI rewriting them to an- another entire language, but because all the tests are already there, you can verify that your rewrite is still valid. [00:20:52]
-
-And in this case, I think the risk of, you know, accidentally introducing, you know, major new bugs or security problems is a lot more limited, because you still have all the original React tests for all the functionality you care about, you're just deleting the tests and the logic for the functionality you don't care about. [00:21:11]
-
-**Carl Vitullo:** Which makes me think, we brought this in, I think, two or three months ago. Actually, it might have been the episode that we lost the audio for, come to think of it. [00:21:31]
-
-## [Tests are the new moat](https://saewitz.com/tests-are-the-new-moat)
-
-**Carl Vitullo:** But we talked about this blog post from a mutual acquaintance of ours, uh, Daniel Sawitz, Tests Are The New Moat. And I think that's what you're talking about, is, like, if the tests are out there, if you can assert that your code passes this test suite, then what's the difference between your code and their code? [00:21:47]
-
-You know? If it's behaviorally the same as guaranteed by the test suite, and you trusted the test suite to guarantee the behavior of the original, then that's fungible, in a way. That's in- you know, one thing interchangeable for the other, assuming the tests are good enough. So yeah, that's interesting. I see a comment here that I wanna bring in. [00:21:54]
-
-The risk, I think the risk is the fragmentation. Yes, sure, but, like, th- there's risk of fragmentation, but it's also, like, what risks does the fragmentation introduce? Like, fragmentation is not a risk on its own. It leads to other things. Like, if there's too many tools to maintain, then maybe it's harder to guarantee the security of any one thing. [00:22:13]
-
-But we already have that situation, as, uh, devin- as evidenced and demonstrated by all of the, you know, the Shai Hulud attacks, as evidenced by, we're gonna talk about this soon, TanStack getting compromised and 40 packages getting pwned with malicious versions published. So, like, in that sense, it's kind of safer to write your own. [00:22:34]
-
-Like, okay, sure, it's, you know, it, it, maybe it has its own vul- security vulnerabilities, but, like, you're not exposed to the supply chain risk. So I, yeah, I think the advantages are not clear-cut. [00:22:54]
-
-**Mark Erikson:** So overall, like Tanner heavily emphasized, this is an experiment. I tried it to see what would happen. I'm writing up the results of the experiment. [00:23:04]
-
-Please don't actually use this. But I actually see this as a valuable experiment. [00:23:13]
-
-**Carl Vitullo:** Yeah, I would say don't m- don't use this, but consider recreating it with something else that you find 80% good but not quite suitable. If there's a test suite, try throwing an AI tool at it. Anyway, interesting. [00:23:20]
-
-## [Brooks Lybrand thoughts on React \+ community after React Miami](https://brookslybrand.com/posts/react-miami-2026.html)
-
-**Mark Erikson:** And then one other sort of adjacent bit, which is, uh, Brooks Lybrand, who's one of the Remix React Router developers, put up a post with his thoughts on the React Miami Conference. [00:23:32]
-
-But one of the s- one of the big sections is how are people feeling about React? And some of this was, well, you know, a little bit of the enthusiasm has gone out because AI is hot and React is not. But there was also... He also specifically makes the comment that, quote, "There's basically now two Reacts," and it's kind of how using React today feels. [00:23:45]
-
-There's old style React, and then there's all the, the new fancy Async, Suspense-y stuff, and they're almost, like, two different frameworks at this point. And so it's kind of a mindset thing. [00:24:08]
-
-**Carl Vitullo:** I did read this post from Brooks. It echoes a lot of, uh, kind of what I've experienced. I don't know about the two, two Reacts part, but React Miami has been a really great conference that I've attended it for a number of years, but I haven't the last two, unfortunately. [00:24:22]
-
-And I know that this was Michelle's last year organizing it, and I wanna shout out Michelle Bakels for being a phenomenal organizer and going on to bigger and better things. [00:24:35]
-
-**Mark Erikson:** Wonderful human being, great job organizing the conference. She has put together an amazing community there. [00:24:44]
-
-**Carl Vitullo:** And I believe is now organizing or doing, like, developer relations type things for Open Code, if I'm not mistaken. [00:24:51]
-
-So yeah, do... Power to her. Wanna throw out some recognition while discussing her conference. That's what we gotta say on there. [00:24:58]
-
-## [TanStack is exploring how to expose Server Components](https://tanstack.com/blog/react-server-components)
-
-**Carl Vitullo:** Let's go into RSCs on TanStack. [00:25:04]
-
-**Mark Erikson:** We've talked a lot about server components over the last few years and, you know, which frameworks support them and how does it work. One of the biggest issues with server components is that Next.js had them first, and has had them the longest, and has been the only major way to use server components for a long time. [00:25:06]
-
-Our mental model of server components is still very much based on how does Next.js offer them in the app router. And so TanStack now has... And TanStack Start now has server component support, but they have approached it in a very different method from, from an API design and usage perspective. I've seen some of the examples. [00:25:24]
-
-I've looked at- Some of the bits and pieces I, I half understand what's going on here. But m- my rough explanation is that they allow you to do some of your own server rendering, and then you treat the response as data to the point where you, you would actually use, like, TanStack Query to fetch the dreamed data from the server, and then just sort of include the output on the client side. [00:25:47]
-
-Another way to put it is they are trained to keep TanStack Start as a client-first framework, where you very clearly say, "This piece of code runs on the server." Whereas Next in the app router is, we are starting your component tree as the server, and you have to explicitly break out and say, "This is where this..." you know, "This is a client component," et cetera. [00:26:14]
-
-So they're trained to flip the server component usage pattern up, kind of almost, like, upside down compared to how Next.js does it. And I think this is good. I see a lot of benefits here in terms of mental model and complexity, and just even just being able to read the code and say, "This code runs on the server, this code runs on the client, and I understand what's happening where." [00:26:41]
-
-**Carl Vitullo:** Yeah. That's definitely the tough part of RSCs. I applaud them for giving it a go, but that, that is a challenging problem space to be working in. [00:27:08]
-
-**Mark Erikson:** So we've, we've got a couple different posts here. [00:27:17]
-
-## [Who Owns the Tree](https://tanstack.com/blog/who-owns-the-tree)
-
-**Mark Erikson:** And the TanStack folks put up two posts on server components your way, and who owns the tree, treating server components as a protocol and not an architecture. [00:27:19]
-
-## [RSCs in TanStack](https://frontendmasters.com/blog/react-server-components-in-tanstack/)
-
-**Mark Erikson:** And then Adam Rackis did a post on Frontend Masters where he explains server components in TanStack as if you had never heard of server components before. So in other words, rather than trying to say, "Here's how it compares to Next.js," just, "Let's kind of teach this up from first principles." [00:27:31]
-
-**Carl Vitullo:** Heh. I, I appreciate that, because the other, the, um, React server components your way blog post on TanStack.com starts with, "What is, what are server components? Yeah, no, this is not a server component crash course." so okay, they got, they got both audiences covered. [00:27:51]
-
-Okay, into some stuff that we have referenced already in this episode. Some new and notable stuff in the ecosystem. [00:28:05]
-
-## [Remix v3 beta preview](https://remix.run/blog/remix-3-beta-preview)
-
-**Carl Vitullo:** Starting off, I guess, we've got Remix v3 beta preview. Beta preview, not just a beta, not just a preview It's a beta. It's a beta preview. [00:28:12]
-
-**Mark Erikson:** Isn't that called an alpha? [00:28:23]
-
-**Carl Vitullo:** I think that that does seem like an alpha, but I guess... No, I, 'cause I guess an alpha implies that it might change before a beta, so this is teasing the beta. It's not gonna change, but this is what it's gonna be. Fair enough, whatever. It's okay. It's great. [00:28:24]
-
-## Both Remix and TanStack are exploring "what if no React"?
-
-**Carl Vitullo:** Yeah, this is interesting. Th- th- so Remix is no longer a React-based framework, which it, you know, a- and I'm just kinda reflecting on the conversation we just had about TanStack projecting React. And so it seems like it, it... There's some real ecosystem appetite to do things that are not literally built upon React while being heavily, deeply inspired by. [00:28:35]
-
-And, like, a, a true, not just inspired by, but, like, a true lineage. Like, you know, it, Remix and TanStack, if both of them are looking at what it means to not bundle React, then that's a really serious evolution for them as projects that have historically bundled React. So I don't know. That's interesting. So they're announcing this Remix 3 beta preview. [00:28:57]
-
-It's a pre-release, not production ready. I guess the core argument, their, the thesis of Remix 3 is that, I guess I would say it's, their opinion here is that fra- modern frameworks try to reinvent too much of what the web platform already provides, and so they're trying to strip away some of that complexity that they view as needless on top of just, like, web standards and available, you know, protocols. [00:29:18]
-
-Which is, I'm sympathetic to that thesis. Like, I think there's a lot of stuff that React is doing that maybe it would be better for, l- or React, Next, TanStack, that may be better for the platform itself to take care of. Like, we definitely could be doing a lot more at the protocol level. Like, a thing I've been seeing people talk about like it's a brand-new fancy technology is, like, adding .md as a suffix to your URLs to make it render, you know, what would have been a HTML page in Markdown. [00:29:47]
-
-And I'm like, "We have a header for that." Like, you can do an Accepts MIME type header to say, "This accepts HTML. This accepts Markdown." Like, w- that exists. Like, you don't need to invent some new technology for that. Like, we can do that. [00:30:18]
-
-**Mark Erikson:** Okay, there's a comment in chat that says, "I do not understand what Remix 3 is." [00:30:33]
-
-Fair. Let me try to recap where we are. Remix 1 and 2 were full-stack frameworks u- that used React. They mostly introduced things like using loader functions for data fetching. But they were, they were full-stack mostly in the sense of there is a server piece included. Remix 3 is a completely new and different framework that just happens to use the same package name And it is a very different way of writing your components. [00:30:37]
-
-They also include a whole lot more stuff on the server. The blog post says they include routes, request handlers, responses, middleware, sessions, auth, forms, uploads, assets, data, database, UI components, theming, network, and tests. So in terms of what they provide, they're trying to provide a lot more out of the box. [00:31:12]
-
-In terms of the client side code, this is not React. This is a brand new framework on the client side they have invented themselves. It looks a little bit like React in some ways. There's JSX syntax. But the logic and behavior are very different. For example, instead of a useState hook, you just declare a variable in scope, inside a closure, reassign to that variable, and then you call an update method, which is what actually triggers the re-render. [00:31:32]
-
-So whereas in React, if you call setState, that both says, "Here's the new value," and tells React to re-render, whereas in Remix, you could say variable one equals A, variable two equals B, and then you call an update function to explicitly trigger it. They also have a bunch of things for mixing in behavior, like event handling and styles and things like that. [00:32:07]
-
-There's inspiration from React. There's inspiration from earlier libraries like Backbone. It, it is a very React and yet non-React-based framework. [00:32:34]
-
-**Carl Vitullo:** And I'm looking at this, you know, in this Remix III beta preview blog post, I'm looking at this small example copy to clipboard component that they show. And yeah, so Mix is what stood out to me here. [00:32:46]
-
-There's, you know, a button and it's got, like, some ARIA stuff, 'cause buttons are, need to be accessible. And then instead of, like, style or, like, class name or, you know, onClick, on, you know, handlers, n- the rest of the props basically that I would expect for a, you know, a button component to have, it has this Mix attribute which, you know, uses the same JSX, like, you know, curly braces. [00:32:58]
-
-Then the value is an array which has button.secondaryStyle and an on function which is being given, you know, onClick with a clickHandler async function here. That's interesting. So it's like, I guess, it's sort of React, but with manual updates instead of updating by reference, and it's got, like, this pseudo-functional composition style for arguments. [00:33:22]
-
-But, like, weirdly, it seems to be mixing styling and b- behavior in this Mix attribute, 'cause it's both applying the secondary button style and an onClick handler as composed mixins, I guess. So that's, I don't know. Sure, that's an opinion you can have. That's, seems fine, but it's strange. [00:33:49]
-
-**Mark Erikson:** All that to say that they've been talking for a while about how they're trying to do their own thing, and they are clearly doing their own thing. [00:34:07]
-
-And I have no idea how much adoption this will get, but can sort of squint and see some of the inspirations. [00:34:15]
-
-**Carl Vitullo:** Yeah, and somebody in chat just brought out React Router Framework, and it's like, oh yeah, they did that too. [00:34:22]
-
-**Mark Erikson:** Brian and Michael have had a lot of ideas over the last decade. [00:34:26]
-
-**Carl Vitullo:** Yeah. Boy, boy howdy, have they. [00:34:29]
-
-I guess, uh, a thing I wanna bring in, speaking about over the last decade, so a decade ago is 2016. I remember in, like, 2012, I read a blog post from Basecamp talking about how they built their UI, and it was basically componentized HTML being cached aggressively and recursively sent over the wire. And, uh, as I have been watching React evolve, it's like, oh, we're basically evol- you know, uh, progressing towards the same thing. [00:34:31]
-
-It's, you know... This f- this remix description of, like, and- advanced functions and like, you know, it's got frames, which are server-rendered HTML that you can, like, slot into your client code. And it's like, man, just, like, the number of times that I see something that, like, viscerally remind me of this thing I read in, like, like literally 15 years ago at this point, talking about sending componentized HTML over the wire in a efficient manner. [00:34:59]
-
-It's like, wow, we're still trying to do that out, uh, generally. Like, we-- I feel like that's the tension. It's not that hard to do as a one-off, but it's really hard to do with effective semantics that let you author that type of experience in a generic framework or library. So we're just still chasing that high, I guess. [00:35:26]
-
-So I don't know. That's where we're at. That's how I'm conceptualizing this Remix 3. And I, I also think of, like, Remix, you know, 'cause, like, Remix is, like, backed by Shopify and, you know, Michael and Ryan, they feel like they're in alignment with the Basecamp folks. And so it's interesting to see these, this similar set of ideas explored by a set of folks that I consider to have a generally similar set of ideas about the world. But yeah. [00:35:46]
-
-## [TSRX](https://tsrx.dev/), a variant on JSX
-
-**Mark Erikson:** And on a very, very similar note, Dominic Ganaway is someone who has worked on multiple React frameworks. He originally built his own framework called Inferno. He was part of the actual React core team for a while. I believe he then went over and worked on some of Svelte 5, maybe. [00:36:11]
-
-Someone who has a lot of experience building these frameworks. He has been working on a new framework called Ripple, which we've mentioned a, a few months ago, and one of Ripple's potential innovations was essentially an improved version of JSX syntax, and Dominic has extracted that into its own package and compiler layer called TSRX. [00:36:29]
-
-So JSX has an actual specification. It's out there. It's in a repo. It's documented. It also has not changed in a decade, and part of that is because it's embedded. There's lots of different tools that know how to parse JSX correctly and do the transformations. Trying to push through any changes to the JSX specification would be hard at this point. [00:36:56]
-
-Like, I would desperately love to have what's known as prop hunting, where, say I wanna pass my variable as a prop named My Variable. Why should I have to write My Variable equals curly braces My Variable every time? Like, that's silly. But the problem is the JSX spec says if you pass a variable name with nothing else, well, HTML treats that as a Boolean, so JSX is gonna treat that as a Boolean too. [00:37:21]
-
-And it's like, but it would be so much nicer if I didn't have to repeat myself. Can't we improve the specification? And at this point, it's not gonna happen. So Dominic has gone in and created essentially a bigger, better JSX-like language that is specifically meant for writing components in a template-ish, JavaScript-ish, TypeScript-ish sort of way. [00:37:53]
-
-**Carl Vitullo:** Agreed on, like, you cannot-- Like, changing the spec of JSX right now, like, nobody expects the spec to change, which makes it harder to actually change. Like, you know, if it had been evolving, it would be easier to continue evolving, but we have inertia saying it's fixed. So it's just tough to evolve. I'm not sure if I love this as a, you know, new DSL. [00:38:21]
-
-I have been thinking about the value of DSLs in this, you know, agent- agentic AI era that we're, you know, that we find ourselves in now. And, like, so much-- I feel like there used to be a strong argument for not changing things because you have to do this, like, educational push afterwards. You have to do the developer relations of, like, "Here's how to use the new thing," and you have to, like, yada yada. [00:38:45]
-
-And that's different now that so much of the new code is being consumed by agents. It's not an educational cycle. It's not workshops and, you know, courses and talks and conferences. It's like you update the markdown. You update the docs that the AI is reading 'cause it's an amnesiac and you have to start from zero every time you give it something. [00:39:06]
-
-That's an interesting, like, unlock for changing some of these core assumptions. Like, yes, sure, it's embedded, it's deeply embedded into the training program. But like I've been pleasantly surprised by things that I expected to be challenging because it's not deeply embedded in the training data, or it, it runs counter to things that I know are deeply embedded in the training data, like wanting to do functional patterns instead of object-oriented. [00:39:27]
-
-Because, I mean, so much code is object-oriented and it's been trained on all of the existing code. I have to say, like something like TSRX, it seems interesting to me from that lens of like... So your thesis is that JSX has rough edges and foot guns that make it less effective, less intuitive, less comprehensible for its intended purpose. [00:39:53]
-
-**Mark Erikson:** Just make a whole new thing. [00:40:16]
-
-**Carl Vitullo:** Just make a new thing. Just shave those off and call it something else so that the tools you're using to author these implementation details don't get confused about what you're using. Or, you know, have lint rules, static, you know, tools available to ensure that what they've written is valid and g- intended. [00:40:17]
-
-Ah, that's interesting. That's cool. That's useful. I don't know. [00:40:33]
-
-**Mark Erikson:** And just looking at this code snippet, a few practical examples of how this is different from JSX. So you've got a component keyword instead of the function keyword. It is statement-based, so you can have like an if statement directly in there, and then you don't do like a return anywhere. [00:40:36]
-
-It's just like if condition, key tag In other words, it, like, if that's true, you insert the P tag, but you don't have a, like, a return statement anywhere in there. Uh, and then it's also got an embedded style section as well. Another interesting thing is that this is not actually tied to a framework directly. [00:40:54]
-
-There are packages that allow you to use this with React in Preact, Ripple, Solid, and View if you really wanted to. So you could, in theory, actually drop this into a real project right now if you really wanted to use it. Did you use it? Probably not, but it's a very interesting exploration. [00:41:16]
-
-**Carl Vitullo:** Yeah, definitely really interesting. [00:41:37]
-
-**Mark Erikson:** Okay. Well, we are already almost an hour in, and we still haven't touched the security thing. So Carl, great job moving that to the end. [00:41:39]
-
-**Carl Vitullo:** I knew it. [00:41:46]
-
-**Mark Erikson:** Who knew that we would have stuff to say about everything else first? [00:41:47]
-
-**Carl Vitullo:** What? You and I have opinions? [00:41:50]
-
-## Security! Everything is compromised
-
-**Carl Vitullo:** As fucking ever, there's been a bunch of security stuff going on. TanStack Router got, like, hardcore compromised. I think it was 40-some p- compromised packages. Basically, like, all of- [00:41:52]
-
-## [TanStack Router compromised](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem), and [Socket analysis](https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack)
-
-**Mark Erikson:** The entire TanStack Router set of packages was compromised. No other TanStack libraries were compromised. So, like, Query, Start. Or, well, Start because it includes Router, but, like, the actual damaged packages were all Router related. [00:42:04]
-
-Uh, and the, the way it worked was incredibly complicated. So s- essentially, someone opened up an ex- a, an external PR that in its own depend... Like, essentially changed the package dependencies to point to some compromised poisoned versions. TanStack's CI was set up to have a shared package cache so that their CI runs would go faster. [00:42:22]
-
-Someone opened up this PR, modified it a couple times, closed it, and in the process, their poisoned packages ended up in the package cache, so that the next time one of the TanStack maintainers actually did a real PR, the poisoned packages from the cache got installed, exfiltrated credentials, and then that allowed the attacker to then publish new versions of the TanStack packages with more malicious code inside. [00:42:49]
-
-Uh, it's actually much more complicated than that, but that's roughly what happened here. [00:43:21]
-
-**Carl Vitullo:** Yeah. It's... I, I wanna see if I can pull in a couple different details without blowing up the time we spent here. [00:43:26]
-
-But, like, so they, they fork it, they obscure that it is a fork by renaming it to s- you know, configuration, so you d- it's not easy to find. [00:43:30]
-
-They publish a commit with li- you know, a malicious payload, commit it with skip CI because they know that will suppress the CI from actually executing on this push. Then- Like open a PR, update the PR so that it appears empty, then close the PR. And in doing this, they have now poisoned the cache with their malicious payload so that the next time a legitimate CI run goes, it will pull in this malicious payload instead of the intended dependency code. [00:43:39]
-
-All from a fork, that was never run, that was never actually executed, never had CI run or merged or approved. The timeline for this is they open the PR, do multiple force pushes, and then close the PR in under a minute, and that's how they poison the cache, so the next time a legitimate person ran CI, their credentials were compromised. [00:44:15]
-
-Like, that's fucking crazy. [00:44:40]
-
-They m- compromised a bit of code, organizational policies by the, by TanStack, and complex GitHub Action configuration. And all of this was ultimately enabled by the use of a PR target in their GitHub Action that is like known to be unintuitive. [00:44:42]
-
-It's known to a- allow this type of attack. But like, ah, man, what a, th- like that's, that... What a reasonable thing to miss here. That's such a complicated set of th- steps to have to do to e- execute this. [00:45:01]
-
-**Mark Erikson:** I've done a decent amount of like GitHub Actions CI config over the years for Redux. I have no idea what I'm doing. [00:45:15]
-
-I don't like writing YAML as a way to do control flow. I'm not an expert on this stuff. I'm googling examples and copy-pasting, because I genuinely have no... Like I, I roughly know here's what I want to do. I don't know how to do it. So this stuff is so easy to mess up, and GitHub Actions is frankly a, it's very complicated and it's very badly implemented. [00:45:25]
-
-**Carl Vitullo:** And it's so hard to test. Yeah. It's impossible to test some things. Like literally in, in some cases the only way to trigger the actual workflow is to do it live. And like, like you said, I'm not an expert in this. You're not an expert in this. Like nobody, almost nobody, especially in open source, is an expert in GitHub Actions. [00:45:49]
-
-Like nobody's primary job is understanding GitHub Actions, but all of us have to write GitHub Actions because that's the way that you function in this world right now. So I don't know, it's oh man, what a rough state of affairs there. We all have to do this. Nobody's that good at it, and the experience of actually authoring it is- rough. [00:46:09]
-
-It's bad. Like, it's not good. [00:46:30]
-
-**Mark Erikson:** So the postmortem is fantastic, and just for the record, I've seen a lot of corporate post-moto-mortems that were nowhere near as good as this. So kudos to the TanStack team. I know Corbin and a bunch of the others were very involved in not only trying to deal with the actual fallout here, but, like, really, really professionally follow up on here's what happened and here's how we're fixing things. [00:46:32]
-
-## [TanStack followup with followup hardening](https://tanstack.com/blog/incident-followup)
-
-**Mark Erikson:** And so they, they also put up a follow-up post with the list of things they're doing to try to make sure that nothing like this ever happens again. Unfortunately, this did have a lot of downstream consequences. [00:46:58]
-
-## [Nx monorepo tool compromised](https://nx.dev/blog/nx-console-v18-95-0-postmortem) as a result
-
-**Mark Erikson:** So, uh, the Nx monorepo tool got compromised after that because someone from the Nx team installed one of the briefly live malicious versions of TanStack packages, and that led to some credentials getting exfiltrated, which led to a malicious version of an Nx VS Code extension getting installed. [00:47:10]
-
-And then GitHub reported that someone had accessed a bunch of internal repos, quote, "Because one of our employees used a, broke a malicious VS Code extension," and I think I saw some articles indicating that it might be the Nx Console possibly. So it's possible that there were multiple chained attacks downstream, all starting from the TanStack Router compromise. [00:47:39]
-
-**Carl Vitullo:** That's fucking wild. Yeah, so, you know, like, when people tell me about, like, the risks of introducing security vulnerabilities by hand-rolling your own little tool here or there, like, oh, I don't know, GitHub got compromised by this. This sequence of events to get to GitHub is compromised, oh my God, that's absolutely wild. [00:48:05]
-
-I don't know. People talk about threat models and, like, threat actors. Like, how do you defend against what type of threat actor? Like, this attack, to me, the level of complexity and success and, like, capitalization upon their success- Says nation state actor. Like this is world-class— [00:48:24]
-
-**Mark Erikson:** And to a certain extent, like it's not even worth trying to defend against someone who's that good. When they want to find a way in, they will find a way in. [00:48:41]
-
-**Carl Vitullo:** Right. Meaningfully, in order to effectively defend against these... You know, if you think about it as like y- your available attention, you have 100% available attention, and, you know, there's that r- team, that malicious actor, 100% of their attention is on breaking you. [00:48:49]
-
-If you are not as skilled as them and dedicating the same amount of effort to countering their actions, like you can't beat them. They will overwhelm you given enough time. So like that's the complicated thing about security. You know, it's like in physical security they talk about like there is no such thing as a perfectly secure lock. A line that I'm aware of is physical access precludes all security. Like if you're doing computer security things and you are sitting in front of the machine literally [00:49:07]
-
-**Mark Erikson:** Sooner or later you will find a way in. [00:49:37]
-
-**Carl Vitullo:** It is not possible to provide security guarantees there. Yeah, you know, like if you're trying to lock down your data, if they're sitting in front of the machine, they can just blast your RAM with freezing agent so that it powers off but still holds the bit pattern physically on the chip, and then you can recover it from there. [00:49:39]
-
-I remember reading, uh, you know, proof of concept in an academic lab. Somebody had successfully exfiltrated data from a computer by using a high-sensitivity microphone from across the room and extracting the, like, buzzing pattern, the audible noise of the processor as it executed instructions. [00:49:57]
-
-Like, by listening to the processor, they were able to exfiltrate data. Like, the bar for perfect security is so high, it's incredible. Anyway, that's the last thing I'll say there. [00:50:19]
-
-Like it... So I don't know, just like when w- as you're thinking about responding to and defending against security threats, I think that's a really important context here, is that if your counterparty, if the malicious actor you're defending against is a hacking team that has been working for 25 years with the backing of a nation state national defense resources, like, sorry, you're not gonna beat them. [00:50:30]
-
-That's-- You're not an effective counter to that. Like, it's not gonna happen. So I don't know. That's an important caveat that I think all security conversations need to have is it's fucking hard. It's grim. [00:50:54]
-
-**Mark Erikson:** And then there's a, a couple more examples that I, I believe aren't even tied to the TanStack one. So Vercel got compromised, and that one appeared to be a sort of similar thing, where, like, one person was using an external tool, in this case called Context.ai. [00:51:06]
-
-That tool got compromised, and then they were able to roll through, pick up tokens, and get into Vercel's interior. And then the same people who have been doing this mini Shai-Hulud set of viruses and attacks have actually been hitting a bunch of different packages across multiple different languages and ecosystems. [00:51:26]
-
-So I mean, this, this is not like the proverbial guy in his basement. This is a bunch of very determined and sophisticated attackers. [00:51:49]
-
-Three last lit-- um, quick little bits on React-related things. [00:51:58]
-
-## React2Shell recaps from [Lachlan Davidson](https://lachlan.nz/blog/the-react2shell-story/) and [Sylvie](https://sylvie.fyi/posts/react2shell/)
-
-**Mark Erikson:** So we had the entire React to Shell vulnerability a few months ago. [00:52:02]
-
-The people who actually discovered that put up a couple of articles describing-- Like, the two primary individuals described their experience of what were they investigating, what was their process, what happened between when they found it and when it got publicly disclosed. [00:52:07]
-
-## [Next 16.2.5 and more React CVEs](https://github.com/vercel/next.js/releases/tag/v16.2.5)
-
-**Mark Erikson:** And then adjacent to that, Vercel put out a new release that appears to fix a number of new vulnerabilities and CVEs. And I know I s- w-when I saw this a couple weeks ago, I don't feel like I saw an actual blog post that accompanied this, which I found a little surprising. Maybe I just wasn't looking in the right spot, and I haven't gone back to look. But it seemed as though there were a number of new, like, denial-of-service and some authentication bypass issues found in b- in both Next and possibly Server Components again Okay. [00:52:25]
-
-One last set of things that are adjacent to this, and that's with the package publishing [00:52:59]
-
-**Carl Vitullo:** I like this 'cause it's, like, actionable. Here's things you can do to make your packages more secure. [00:53:05]
-
-**Mark Erikson:** This is aimed more at people like me who are maintaining packages rather than people who are developing applications, but hopefully this is something that will benefit all of us. [00:53:10]
-
-## [NPM adds “staged packages”](https://docs.npmjs.com/staged-publishing) and [E18E adds guidance](https://e18e.dev/docs/publishing.html#staged-packages)
-
-**Mark Erikson:** So first off, npm is adding a new concept called staged publishing. Right now, when you publish, the package goes live immediately. And so the way I understand this is once you have this set up for your packages, every new attempt to publish goes into a holding area, and then you explicitly have to go in and say, "Yes, I approve this for actually, actually, actually being released." [00:53:19]
-
-And I've, I've already seen Jovi de Crook, who works on Preact, trying to p- put together a tool that would be able to inspect package releases that are staged so that you can see what's inside them and what's changed. No idea how that works, but I c- I can see how that's been useful. So this would help for cases like the TanStack compromise because the m- modified, malicious, published versions of the package would never have gone fully live. [00:53:48]
-
-They would've gone to the staging area, and then the TanStack team would've been able to see them and say, "Wait, no, we, we didn't intend to publish those. Those should not go out." And then on the consumer side of things, so all the different package m- managers now have some kind of an option for don't install packages until they are at least N days old. [00:54:20]
-
-And they all have a different name and a different set of options for that field, but that's, that's the same concept. [00:54:44]
-
-## [PNPM 11 defaults to min release age](https://socket.dev/blog/pnpm-11-adds-new-supply-chain-protection-defaults), NPM 12 will [block by default](https://github.com/npm/rfcs/pull/868)
-
-**Mark Erikson:** So I believe pnpm 11 is defaulting to turn on that option to at least a couple days. Meanwhile, the other problem here is that packages have the post-install script, which is essentially when your package manager downloads this package and puts it in node modules, it can then run any random script that the package says it should run. [00:54:50]
-
-And that's bad because that's code that's running on your machine under your privileges and you have no idea what's happened, and it's just there because the package manager installed it. [00:55:13]
-
-**Carl Vitullo:** It's literally remote code execution. Like, yeah. [00:55:22]
-
-**Mark Erikson:** Yeah. And traditionally this has been used for things like, okay, let's figure out what operating system you have so we can download the proper native binary or build the native binary from scratch. [00:55:25]
-
-And there's alternative other better ways to do that today. So pnpm has already been denying the ability to run post-install scripts for a while. And finally, npm appears to actually be making the same change. So it looks like they're gonna start warning about package scripts that have a post-install option in the version 11 series, and npm command l- and tool version 12 will start denying those by default. [00:55:38]
-
-So we are trying to close up some of the outstanding holes in the ecosystem. So trying to make publishing packages safer, trying to make installing packages safer. [00:56:08]
-
-**Carl Vitullo:** I will say, okay, if we're talking about voluntary remote code execution, you know, where blocking post-install is a good thing to do because it's against best practice, the other- Top of mind, similar instance where we are casually expected to fetch code over the network and run it is curl piped into bash as an install tactic for things. [00:56:19]
-
-And like literally my entire career, people-- I have heard people talk about, "This is awful. We should not be doing this." Like, there are certain tools that will... I, I can't name, I can't think of any off the top of my head, but I do feel like I remember encountering this. There used to be tools that would ask you to, like, curl and then pipe it into, like, \`sudo bash\`, and, like, that's literally root access to your entire machine with arbit- code that you're not even inspecting from the network. [00:56:45]
-
-And you know who still asks you to curl pipe into bash as the recommended install method? Claude Code. Like, you go to claude.com f- and the Claude Code thing, front and center, "Built for hackers. Get Claude Code. Curl, pipe, bash." Like, that is remote code execution. Don't do it. Use a package manager. If your work is recommending that people curl and pipe into bash, advise that you respectfully and through proper channels raise the issue that That's wildly insecure. [00:57:10]
-
-It encourages remote code execution as a thing that developers will casually do. And when you casually do something like remote code execution, you end up with security vulnerabilities, like the types that we've been getting over the past year. So, ah, makes me annoyed. [00:57:42]
-
-**Mark Erikson:** And then, uh, last item. [00:57:57]
-
-## [Review your GH Actions, people!](https://github.com/e18e/ecosystem-issues/issues/266)
-
-**Mark Erikson:** So I, I, I mentioned earlier, I am not an expert on GitHub Actions. And after seeing all this stuff happen with TanStack, I, I was like, "We probably oughta do some looking at, like, the Redux actions," but I, I have no idea to what, what to even look for. The good news is that there's a number of people already working on scripts and AI prompts and other things to go inspect GitHub Actions. [00:57:59]
-
-And it's, in fact, Francois Best, who's ma- the maintainer of the Nuxt URL State library, was actually working on one himself and was asking for repos to run it on, and I, I volunteered to have him run it on the Redux repos. And it gave me a bunch of things to go correct. Like, nothing major high security, but a number of things we could do, like making sure that all the actions were pinned to a hash, changing some of the permissions options. [00:58:22]
-
-So there's a thread over in the E18E repo where they're collecting some different tools that can do scanning of GitHub Actions and try to work on hardening. And it kind of sucks that this is yet another thing that we gotta fix and we gotta make right, but guess what? It's good. You gotta fix it. [00:58:47]
-
-**Carl Vitullo:** One more thing we gotta fix. [00:59:06]
-
-That's just the rest of our existence forever. The debugging never stops. [00:59:07]
-
-**Mark Erikson:** Yeah. Okay. [00:59:12]
-
-## Mark posted his big AI blog posts. [Part 1: Fears and Journey](https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-1-fears-opinions-journey/)
-
-**Carl Vitullo:** You published your posts. [00:59:13]
-
-**Mark Erikson:** Yes, I did. So I, I hinted at this, um, a, a month ago. Long story short, little over a year ago, I was firmly against ever using AI- Yeah ... for writing code, and I was having a bit of a mental crisis over what AI is doing to the software industry and how this would affect the industry as a whole and myself personally. I ended up trying to use AI- Found it was actually useful, and now I actually end up using AI to write all my code. [00:59:15]
-
-And this has been a very long, very personal, very emotional journey for me. And I've actually now spent a lot of time configuring my own personal open code agent workflow setup, and I have a, I now have opinions on both how I set things up and the results that I'm getting. Just like I, I have act- I actually have experience now, and I, I have some preferences. [00:59:47]
-
-Also, I didn't wanna get pulled into people yelling at me for having chosen to use AI. But when I was in Miami last month, I was talking with some folks, and some of those conversations literally turned into, "Mark, what tools are you using?" And I would describe it and people were like literally taking notes, acting like I actually know what I'm talking about, which is hilarious. [01:00:13]
-
-And I'm like, "Okay, okay, fine. I've, I have been convinced to write a blog post about my own personal AI agent setup." And my brain would not let me write the technical blog post until I had written the personal experience blog post. [01:00:34]
-
-And I sat down and I wrote 12,000 words in eight hours with a brief stop for supper. And then I wrote another 3,000 words on the flight home the next day. [01:00:51]
-
-**Carl Vitullo:** I may have run that through a word count already. I can verify those numbers. [01:01:01]
-
-**Mark Erikson:** I, I... This is very different from most of my blog posts. Most of my blog posts are, "Here is a concept that I've become an expert on, let me explain this, unpack the pieces, describe how things work, and I will cite dozens of sources as references." [01:01:05]
-
-This post is none of that. This post is, "Here is my experience, my brain, my feelings, my journey." I am not trying to convince anyone. I am not trying to tell people, "This is how you should do things." this is me and my experience. [01:01:22]
-
-And I did not write this for clicks. I did not write this to, you know, change the conversation or get a bunch of views. But I've also already read hundreds of people's posts where they say, you know, I- like, "AI is killing the craft of being a programmer, and I mourn the loss of that." and that was, it, I mean, that was a really big influence on how I was feeling over the last year. So there you go. [01:01:40]
-
-There's a 15,000-word post that goes deep, deep inside my brain and my experiences and how my thought processes changed over time, and then it's got an awful lot of my opinions on where are we as an industry. And then I wrote another 6,000 words about my actual technical setup. [01:02:08]
-
-**Carl Vitullo:** Real Casual, 21,000 words. At an estimated 500 words per page, that is just about 41 pages. [01:02:27]
-
-**Mark Erikson:** People keep asking me to write books, and I'm like, "I don't write books, but I, I write the equivalent of books on my blog." [01:02:33]
-
-**Carl Vitullo:** Right. Right, right. Cool. Love that. How much of both do you think you got into the previous episode we did? [01:02:39]
-
-**Mark Erikson:** Bits and pieces. I, I don't r- Wait, you're asking me to remember what I said a month ago before my vacation? Come on. I, I talked about bits and pieces, but this went into a lot more detail. The biggest things are, like, beyond I use OpenCode, I use Opus, I use these MCP tools, et cetera, is that I've very explicitly chosen to stay very hands-on, conversational, and me driving what the agent is about to change, rather than spawning up a bunch of agents in the background to go do work and I don't care what it looks like. [01:02:45]
-
-I have seen a lot of other posts and discussion, even just in the last few weeks, with a number of people echoing similar thoughts of, "Yeah, actually, maybe we need to kind of back off and keep things at a human comprehensible amount of effort." [01:03:16]
-
-**Carl Vitullo:** Preposterous. [01:03:30]
-
-I'm kind of frustrated. I don't know. I, I feel like I'm meaningfully following the edge of the state-of-the-art in agentic development. I built a harness for myself that does some really cool... Like, three months ago, I had a harness in place that was, like, keeping track of memories and doing a dream cycle and playing a game and writing its own code. Like, writing hundreds of lines of Python so that it could more effectively play this game, and it was doing a good job. It was actually pretty interesting. [01:03:31]
-
-And I kind of shut it down 'cause, well, now, it, it, it was using \`claude -p\` to do everything- Mm ... and I realized, like, I kept working on it and I kept iterating it and I realized like, oh, you know what? Like, Claude is already doing a lot of this stuff. Claude Code is this agent. So what is, what does the orchestrator on top of the agent need to do? [01:03:59]
-
-And I have an interesting, I have a really interesting body of work that's on my GitHub that is not currently being put to use anywhere, but it's like, damn it, I'm currently at the edge of the agentic whatever stuff, but I'm doing other things that are more personally interesting to me. And, man, I want... [01:04:18]
-
-I, I have this project in place that I feel like is on par with stuff that I'm seeing people fundraise for from VC and I'm like, "Hmm, I don't wanna do that, but I do want money." So anyway, there's my, uh, there's my personal opinions around some AI stuff. I don't know. [01:04:36]
-
-I'm g- I'm gonna have to find out... We're gonna have to talk more about AI and agents and whatever, 'cause I don't know, it's crazy. [01:04:53]
-
-**Mark Erikson:** So, I don't know, adjacent thought. Like I'm, I'm, I'm in sort of a weird spot at the moment because I just got back from a combination conference plus two weeks of vacation plus conference trip. At my day job I've... [01:05:00]
-
-Prior to that, I was writing MCP tools and then playing product manager and doing product and positioning stuff, and then helping try to figure out like demos and product direction. I'm back for a couple days. I've got more conferences coming up. I've actually done very little Redux maintenance work this year, and I feel kind of bad about it, but it's 'cause a lot of my time and effort have gone into, you know, replay day job stuff. [01:05:12]
-
-I was trying to play with some of my like React Redux plus signals experiments on the way back home, and so I'm kind of getting some of that back into my brain. There's a lot of things I would like to sit down and spend time on, but I've just been running around so much and everything feels very scattered, and I don't feel like I'm focusing at the moment. [01:05:39]
-
-So I've got a couple more conferences. I've got a c- bunch of travel coming up. I don't know. Maybe I will manage to find time to actually sit down and focus on some things. [01:06:01]
-
-**Carl Vitullo:** As if. Cool. Well, I hope you do find so- some of that time. But I, I just know in my own self, any time I'm like, "Maybe I'll find time to do that thing that I want to do now," it's like, "Nah, probably not." [01:06:09]
-
-Gotta make time. Can never find time, have to make it. [01:06:21]
-
-**Mark Erikson:** I, I, I actually saw a post from Addy Osmani on Twitter just, uh, just this morning. A- Addy has written a number of really good posts lately about, you know, using agents and orchestration and, and agent anti-patterns and other things. Fine, I will, I will actually go look on Twitter and find the post rather than just describing it. [01:06:24]
-
-Uh, here, oh, here we go. It's the first thing in the history. Wonderful. Uh, this one's called, this one's called The Orchestration Tax, and the key line that stuck out for me for this one was, "Human attention is now the limiting factor. It is the single-threaded lock that you need to be aware of." And so how do you pick what is the most relevant and important thing to be spending your time on versus your agent's, blah, blah, blah, blah, blah, blah, blah? [01:06:43]
-
-**Carl Vitullo:** Right, right. The agents are good at a lot of things, but they are not good at building the right thing. You have to get them to do the right thing. That's definitely been my experience as well. I've definitely experienced the, "I can do everything. Throw 15 agents." Uh, and then you review the work and try and actually make use of it, and it's like, oh, this is making a lot of very basic assumptions that are not the assumptions I have. [01:07:10]
-
-Which I, I... One thing to say, the closer your assumptions are to the basic assumptions, the better it works in some ways. So the less creative you're being, the more effective they are. Or the more, like, s- effective they are at doing their own thing. I don't know. That, that probably says something about, I don't know, scale. [01:07:35]
-
-**Mark Erikson:** Yeah. I mean, that, that basically goes back to why I personally have chosen a workflow that is essentially just me augmented, rather than me spinning off a bunch of agents. [01:07:53]
-
-**Carl Vitullo:** True. That's why I shut my harness down and haven't had it doing stuff, is partly, largely because I haven't figured out how to put myself in the loop of their work in a way that is effective. [01:08:05]
-
-Uh, I, I had them running for, like, a day or two, and they, they did work. A lot of it was useful work, but they also did some work two or three times and left, like, page-and-a-half comments three different times on the same PR. And it's like, oh, okay, this is... The usefulness to noise ratio of this is not where I want it to be. [01:08:16]
-
-Let me revise this. And I have not revised it, because that's something I'm trying to find time for, and I cannot find any time anywhere. [01:08:33]
-
-## Outro
-
-**Mark Erikson:** All right. Well, I think we've about covered things today, and then some. [01:08:39]
-
-**Carl Vitullo:** Yep. That's pretty good. Thank you so much. [01:08:44]
-
-**Mark Erikson:** We had a number of people sticking around, which is great. [01:08:46]
-
-**Carl Vitullo:** Yeah. That's really nice. I like that I put a title in the kickoff thing this time around, and we actually had people show up. So it turns out, if you, like, care about communicating with people, sometimes people actually read and respond. What? Community building? You have to show up authentically? Ah, damn. I hate that. [01:08:48]
-
-Cool. Thank you so much for joining us, y'all in the audience who are still here 90 minutes after we started. That's awesome. Thank you, Mark, for putting together this resource on short notice. And yeah, thanks for everyone who's listening to this on the recording, uh, when I publish it in probably longer than I intend it to be. [01:09:05]
-
-Yeah. Thanks so much. We are going to be revising exactly what this podcast is, but it is useful and good, so, uh, it, it will be sticking around in some sort. If this is a resource that you find valuable and wanna help support, give us a review. Send us to a friend. Put us in the random channel of your work Slack. [01:09:22]
-
-Generally, like, I suck at marketing, I suck at distribution, so if you can help me get this in front of somebody who has never heard of it before, that is the single most helpful thing you can do. Or, I don't know, just send it to someone anyway, even if you don't care. Please, help. Yeah. Thank you so much. [01:09:40]
-
-See you next month. [01:09:55]
-
-**Mark Erikson:** Thanks. Bye. [01:09:56]
diff --git a/src/transcripts/tmir-2026-06.md b/src/transcripts/tmir-2026-06.md
deleted file mode 100644
index a99a105..0000000
--- a/src/transcripts/tmir-2026-06.md
+++ /dev/null
@@ -1,541 +0,0 @@
----
-title: "TMiR 2026-06: React Compiler is getting rusty, what does AI mean for engineering culture"
-date: 2026-06-24
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we discuss the React Compiler being rewritten in Rust, what AI development means for engineering culture, "
-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:14](#intros)] Intros
-- [[00:02:31](#new-releases)] New releases
- - [[00:02:34](#react-router-8)] [React Router 8](https://remix.run/blog/react-router-v8)
- - [[00:05:39](#babel-8)] [Babel 8](https://babeljs.io/blog/2026/06/16/8.0.0/)
- - [[00:07:15](#astro-7)] [Astro 7](https://astro.build/blog/astro-7/)
- - [[00:09:13](#ts-70-rc)] [TS 7.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)
- - [[00:09:42](#esm-only-no-programmatic-api-right-now)] ESM only, no programmatic API right now
- - [[00:10:41](#nub-js-from-zod-creator)] [Nub JS](https://nubjs.com/), from Zod creator
- - [[00:14:13](#legend-list-30-with-dom-support)] [Legend List 3.0 with DOM support](https://x.com/jmeistrich/status/2059922504320225316)
- - [[00:14:44](#tsrx-revamped-the-syntax)] [TSRX revamped the syntax](https://tsrx.dev/blog/rethinking-tsrx)
-- [[00:16:28](#react-core-news)] React Core news
- - [[00:16:32](#react-compiler-in-rust-is-rolling-out)] [React Compiler in Rust is rolling out](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x)
- - [[00:16:57](#pr-was-merged-after-testing-at-meta-and-improved)] [PR was merged after testing at Meta and improved](https://github.com/react/react/pull/36173#issuecomment-4608356402)
- - [[00:17:35](#oxlint-swc-rspack-next-all-integrating)] [Oxlint, SWC, RSPack, Next all integrating](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x%20)
- - [[00:17:50](#rolldown-tried-integrating-directly-but-removed-due-to-binary-size-increase)] [Rolldown tried integrating directly but removed due to binary size increase](https://x.com/evanyou/status/2069593612153987373)
- - [[00:18:18](#bun-tried-optimizing-the-rust-compiler-code)] [Bun tried optimizing the Rust Compiler code](https://gist.github.com/Jarred-Sumner/84df369c35216f40d61d1ea9f95771c2)
- - [[00:18:57](#other-core-improvements)] Other core improvements
- - [[00:19:17](#fragment-refs-have-been-documented-in-canary)] [Fragment Refs have been documented](https://react.dev/reference/react/Fragment#fragmentinstance) in canary
- - [[00:21:42](#react-devtools-mcp-tools-including-component-tree-and-perf-analysis-apis)] React DevTools MCP tools, including [component tree](https://github.com/react/react/pull/36597) and [perf analysis](https://github.com/react/react/pull/36598) APIs
- - [[00:22:28](#react-foundation-progress)] React Foundation progress
- - [[00:22:39](#theres-an-early-reactfoundation-website-advertising-funding-for-maintainers-and-community-groups)] There’s a(n early) [react.foundation](https://react.foundation/) website, advertising funding for maintainers and community groups
- - [[00:25:41](#theyre-gonna-have-a-booth-at-chain-react-at-the-end-of-july-)] They’re gonna have a booth at [Chain React at the end of July](https://chainreactconf.com/)
-- [[00:26:11](#why-is-meta-destroying-its-engineering-organization)] [Why is Meta destroying its engineering organization?](https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering)
-- [[00:32:46](#ai-demands-more-engineering-discipline-not-less-)] [AI demands more engineering discipline. Not less](https://charitydotwtf.substack.com/p/ai-demands-more-engineering-discipline)
-- [[00:40:51](#christoph-nakazawa-posted-his-modern-engineering-values-and-how-he-uses-ai)] Christoph Nakazawa posted his [“Modern Engineering Values” and how he uses AI](https://cpojer.net/posts/modern-engineering-values)
-- [[00:42:42](#cloudflare-bought-voidzero-)] [Cloudflare bought VoidZero](https://voidzero.dev/posts/voidzero-cloudflare)
-- [[00:43:44](#npm-security-updates)] NPM / security updates
- - [[00:43:48](#github-actions-allows-enforcing-pinned-action-shas)] [Github Actions allows enforcing pinned action SHAs](https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/)
- - [[00:44:21](#github-actions-has-a-package-manager-and-it-might-be-the-worst)] [GitHub Actions Has a Package Manager, and It Might Be the Worst](https://nesbitt.io/2025/12/06/github-actions-package-manager.html)
- - [[00:45:27](#npm-12-will-disable-install-scripts-and-git-deps-by-default)] [NPM 12 will disable install scripts and Git deps by default](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
-- [[00:46:25](#code-optimization-still-matters)] Code optimization still matters!
- - [[00:46:53](#tanstack-table-cut-memory-in-v9-by-90-on-large-lists-by-optimizing-js-objects-and-optimized-ts-perf)] [TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects](https://tanstack.com/blog/tanstack-table-v9-memory-performance) and [optimized TS perf](https://tanstack.com/blog/tanstack-table-v9-typescript-performance)
- - [[00:47:25](#pierre-diffs-was-significantly-optimized---has-to-handle-virtualization-syntax-highlighting-source-loading)] [Pierre Diffs was significantly optimized](https://pierre.computer/writing/on-rendering-diffs) - has to handle virtualization, syntax highlighting, source loading
- - [[00:48:38](#compilecat-is-a-new-optimizing-compiler-to-improve-js-execution-after-bundling-similar-to-closure-compiler-the-rspack-team-says-theyre-working-on-something-similar-)] [CompileCat is a new optimizing compiler to improve JS execution after bundling](https://github.com/isaac-mason/compilecat), similar to Closure Compiler. ([the RSPack team says they’re working on something similar](https://x.com/jiahan_c/status/2065630866668453898) )
- - [[00:51:22](#marks-react-redux-signals-draft-perf-pr-and-updated-react-redux-benchmarks-repo)] [Mark’s React-Redux \\\+ signals draft perf PR](https://github.com/reduxjs/react-redux/pull/2318) and [updated React-Redux benchmarks repo](https://github.com/reduxjs/react-redux-benchmarks)
-- [[00:52:51](#aurora-scharffs-preferred-rsc-component-architecture)] [Aurora Scharff’s preferred RSC component architecture](https://aurorascharff.no/posts/component-architecture-for-react-server-components/)
-- [[00:53:34](#lovable-projects-now-use-tanstack-start-by-default)] [Lovable projects now use TanStack Start by default](https://lovable.dev/blog/building-apps-using-tanstack-start)
-
-# This Month in React: June News Roundup
-
-**Carl:** All right. Hello. Thank you for joining us for the June edition of This Month in React. We're coming to you live from Reactiflux, the best place for professional developers using React. [00:00:05]
-
-## Intros
-
-**Carl:** I am Carl. I'm a staff product developer and freelance community leader here at, Reactiflux, where I do things like build Euno, a moderation bot that helps us keep the community operating. [00:00:14]
-
-**Mark:** I'm Mark Erikson. My day job is at Replay.io where we use time travel debugging to build things like automated QA tools and awesome React analysis. And outside of that, I run around at conferences, give talks, and work on Redux [00:00:27]
-
-**Carl:** Heck yeah. The big news that we wanna discuss this month, is around some changes that shipped for the React compiler. it's in Rust now. There you go. It's the news. You don't have to listen. Yeah. we're gonna talk about Meta and we're gonna talk about its engineering culture, b- framed around a blog post from Gergely Orosz, who is wonderful and a great writer. yeah. Talk a little bit more about AI, 'cause of course we are, and some broad best practices and stuff. [00:00:41]
-
-**Carl (editing):** And I'm trying something we haven't done before today. I'm gonna self-sponsor this 'cause we don't have anyone else paying our bills right now. [00:01:05]
-
-Uh, we are sponsored by Euno, a moderator support tool for Discord, offering one-click setup for spam defense, moderation audit logs, and decision-making tools. That's euno.reactiflux.com, E-U-N-O.reactiflux.com. Uh, Euno is named after the goddess of good order and lawful governance. Uh, it helps moderators make decisions about bans together while automatically filtering out compromised account spam. A single setup/command gets you anonymous user reports, shared moderation history and resolution voting, a private ticketing channel, and anti-spam based on message velocity. [00:01:10]
-
-With a 90-day trial, you can get a feel for it before deciding if $100 per year is worth the time you'll save banning spammers and deleting garbage. If you have a Discord server, give it a shot and let me know. That's euno.reactiflux.com, E-U-N-O.react iflux.com. [00:01:43]
-
-**Mark:** Yep. congrats to you, Carl. Thank you for all the work you've put in on this, and I can, vouch that this has been very thoroughly tested on our end [00:01:59]
-
-**Carl (editing):** We're also sponsored by me, Carl. Uh, these episodes cost me about 300 bucks out of pocket each episode, uh, for editing and supporting tools. If you'd like to learn more about anything Mark and I discuss, let's talk about consulting or a contract software engineering gig. [00:02:06]
-
-You probably know where to find me, but Discord or email is the most reliable. I'm at vcarl, that's Victor Charlie Alpha Romeo Lima, @reactiflux.com. Let me know [00:02:21]
-
-## New releases
-
-**Carl:** But yeah, first the new releases. [00:02:32]
-
-## [React Router 8](https://remix.run/blog/react-router-v8)
-
-**Carl:** First up, React Router v8 shipped. We got that now. yeah. This... they talk a lot about the early days of React Router, and it... [00:02:34]
-
-they're, like, proactively trying to manage the pain that people experience because, I... React Router got a reputation for shipping a lot of breaking changes with every new release. I guess specifically they got a reputation of flip-flopping back and forth between two different paradigms, like every other release, and it just frustrated a lot of people with, "Why do we have to refactor again?" So it's funny how much of this blog post is dedicated to saying, "We're not doing that anymore, we swear. Please don't hate us." [00:02:43]
-
-But yeah, generally it looks like this is essentially a no-op versus the latest version of v7. if you are already using the latest version of seven with no, deprecated features, it... [00:03:09]
-
-This should be a drop-in replacement. yeah, I think this, As far as I know, the mo- most of what th- this is bringing out is, emphasis on the framework mode. [00:03:22]
-
-**Mark:** I know that they've done a lot of work on trying to use feature flags to make new features available, essentially following the, majors don't introduce new stuff, they just remove old stuff kind of a [00:03:31]
-
-**Carl:** pattern. [00:03:42]
-
-And see, so the feature flags are the way that they implemented the better, major version releases. So th- now by the time, by the end of the previous major version release, they will have introduced new feature flags for everything that they are about to release in the next breaking change. [00:03:44]
-
-which is, it's really smart. I actually really admire that method of changing. managing feature flags, I have experienced, adds a lot of complexity to day-to-day development. and I have a ton of respect for them for landing on this process for releasing new changes, new features, new abilities to their widely used library, and here they are still, eight years later after they started using this, still putting it to practice. [00:04:01]
-
-**Mark:** Couple interesting notes from the support matrix here. Node 22, okay, that's fine. they now require at least React 19.2 [00:04:25]
-
-**Carl:** as [00:04:37]
-
-**Mark:** a minimum version, so that... I, don't know if version 7 expected 19.0 or 18, I would have to check. But just noting that React Router now requires the latest and greatest React 19. [00:04:38]
-
-And also the package is shipping as ESM only, we are very clearly now on the trend of lots of tools and libraries going ESM only. there was the early wave of tools that went ESM only and everyone else complained because it didn't work right. [00:04:50]
-
-And now with, some of the improvements to Node itself, we're seeing a lot of packages say now is the time to go ESM only [00:05:07]
-
-**Carl:** Yeah, we've got another release that went ESM only next. [00:05:16]
-
-I wanna flag, I just found... I was clicking through the blog post and they have a link to their governance document, which explains their new feature process. and actually this whole document is very well thought out and I would highly recommend that you familiarize yourself with this governance document, 'cause, it's just a bunch of really high quality engineering practices. [00:05:21]
-
-Definitely check it out. [00:05:38]
-
-## [Babel 8](https://babeljs.io/blog/2026/06/16/8.0.0/)
-
-**Mark:** So on the, ESM note, Babel 8 just shipped, and the, big highlights there, the Babel packages themselves are also now ESM only. TypeScript types are built in, and the default compilation settings for building your projects no longer target ES5 or CommonJS. So essentially they're saying we've, rather than necessarily being about backwards compatibility by default and always trying to cross-compile your code to, support, IE 11 or whatever, now we're targeting the modern JavaScript ecosystem. Which is also pretty much what, TypeScript 7 is doing as well. [00:05:39]
-
-**Carl:** I am extremely here for that transition. I wish that it had happened several years ago. Babel as a compatibility layer I think is really good and really great, but we've been on evergreen browsers for most of my career at this point, and I, yeah, just, the long tail of what it means to support ESM 5 and Require is just, it's really... [00:06:23]
-
-That tail's really long at this point. It's very far away. I don't know. I, think the, trade-offs are not quite there. Yeah. Yeah, Babel 7. I don't know. I've, Are people still manually installing and managing Ba- Babel versions themselves? This feels like something I haven't wrangled with personally in a long time. It's all downstream of the rest of the tools I use [00:06:44]
-
-**Mark:** Yeah, I'm disconnected enough from day-to-day app development that I don't have an answer to that question. [00:07:07]
-
-**Carl:** fair. Ha Okay. Anyway, moving on. [00:07:12]
-
-## [Astro 7](https://astro.build/blog/astro-7/)
-
-**Carl:** We've got Astro v7, major release of Astro. Astro's a project that I have always meant to explore more deeply than I really have. I have used it for a, trivial project here or there. If you're building a static portfolio site, brochure, marketing, whatever you wanna call it, it's really good. it hits a good balance between engineering ability, it gives you escape hatches to manually control stuff, while still being largely content oriented. [00:07:15]
-
-So it's very good if what you're managing is what's on the page rather than, like, how it behaves or what data's available. so it, not as great for a full app. there are certain types of apps that work great in that environment, but an application less [00:07:46]
-
-**Mark:** Like my mental model of Astro is it essentially replaces Gatsby [00:07:59]
-
-**Carl:** Yes [00:08:03]
-
-**Mark:** in terms of, we, we pull in data sources, we build sites that are static by default, but can have lots of dynamic content with your rendering framework of choice [00:08:04]
-
-**Carl:** Would agree with that, with all the same caveats of a lot of apps need something a lot more complicated than that. [00:08:14]
-
-But if you're building co- a content site, it's a really great tool for that. Yeah. Looks like mostly they're touting, s- build improvements, upgraded internal dependencies, V8, new roll down bundler. [00:08:19]
-
-**Mark:** Faster markdown parsing. [00:08:33]
-
-**Carl:** Yeah. Advanced routing to give you a single entry point with full control over the request pipeline. They can detect coding agents automatically that looks like a local development feature. It's, you can run the dev server in the background and output structured JSON for machine-readable feedback. That's really smart, actually. I love that. there's a ton of cases where, just like in testing and such, raw human readable HTML and CSS, it... that's just a lot of content. It's a lot of bytes. It's a lot of tokens. so giving machine-readable outputs at the framework level is really helpful. I like that a lot. That seems like a really smart feature, and I think we're gonna start seeing that for more. [00:08:34]
-
-## [TS 7.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)
-
-**Mark:** And I mentioned this a minute ago and we've mentioned it in previous episodes, but TypeScript version 7 is now at release candidate. think the biggest change here from a user point of view is that p- the previous releases had shipped as a separate native preview package and now it's the actual TypeScript package itself, the RC tag has all new binary and faster compilation stuff in there. [00:09:13]
-
-## ESM only, no programmatic API right now
-
-**Mark:** One other thing to note is that the, 7.0 release, number one, it builds off 6.0 where they change the default settings to favor modern compatibility instead of backwards compatibility. but then also 7.0 will not ship with a programmatic API. So tools that depend on the c- on the TypeScript compiler package to programmatically drive compilation, parse files, do that sort of thing, will not work out of the box with 7. [00:09:42]
-
-The idea was get the full working compiler in people's hands now and they're still trying to nail down the details of what the programmatic API will be like, and they're hoping to have that out in a 7.1 [00:10:18]
-
-**Carl:** Cool. Nice. Yeah, and we discussed that at more length last month, so I don't know that I wanna rehash all of that again. Difference between beta and RC is just not that big. [00:10:31]
-
-## [Nub JS](https://nubjs.com/), from Zod creator
-
-**Mark:** Okay, the, the next one's very interesting. Colin, the creator of Zod, just announced something called nub. Those of you with keen eyes will notice that this is bun backwards, in the same way that Deno is Node rearranged. clearly there's only so many letters we can use in naming JavaScript runtimes at this point. [00:10:41]
-
-The s- the sales pitch for this, Node was run JavaScript on the file system outside the browser. Deno was, "Oops, we made a bunch of mistakes designing Node. Let's completely redesign the security and the process architecture and bake a bunch more stuff in." Bun was, "Let's build Node compatibility on a different JavaScript engine, and also add every other built-in programming method and API we can think of while we're at it so it does everything at once." [00:11:07]
-
-Nub, on the other hand, is, "Let's start with actual Node, let's override a bunch of its configuration options, and let's build in a more modern environment, things like better TypeScript stripping and better, package JSON handling and a bunch of other pieces into Node directly so it feels like Node much better rather than one of the, one of the other options." [00:11:43]
-
-I, like this idea. we've been using things like ts-node and TSX and all these other type-stripping approaches. Node has a type-stripping option built in. This apparently goes up to the level of being able to output the non-strippable pieces of TS syntax, so like e- enums and things like that. But then it bakes in a whole bunch of other features as well. I like this idea. I, it, makes a lot of sense to me [00:12:15]
-
-**Carl:** I'd agree. It's interesting. I was always skeptical about Bun because of what you said, it starts from a brand-new runtime, and runtimes are difficult. It's hard. It's... Getting it right is tricky. clearly it's worked well enough for many people, but I've struggled with it a little bit. [00:12:45]
-
-Sure, There's plenty of room for opportunity in the tools surrounding Node.js as well. But I'm skeptical of this package manager. It says a pnpm-compatible manager built in, and it, reads whatever lock file you already have, writes to the same format. I don't know. I'm skeptical of that. look, we made a magic package manager that is cross-compatible with every existing package manager. sure, I'm sure you did. Can't wait to find out what bugs you missed. [00:13:02]
-
-**Mark:** I saw a tweet from Colin where he said that this was all implemented with AI, not surprisingly given today's no but it, but there was a lot of very careful planning and, defining the feature set and working out the requirements and then, using the agents to actually do the work on it [00:13:33]
-
-**Carl:** And, like we s- we were talking about last month, if you've got an existing set of tests to make sure that your code works against which all of these open source package managers are going to, then it's definitely a lot easier to create a functioning replacement. [00:13:52]
-
-yeah, I don't know. It's interesting. Curious, we'll, we'll see how it shakes out. We'll see if it works. see how it does for people [00:14:06]
-
-**Mark:** Yep. [00:14:11]
-
-## [Legend List 3.0 with DOM support](https://x.com/jmeistrich/status/2059922504320225316)
-
-**Mark:** Another release announcement. Legend List 3.0 came out, and this is originally, I think the original version of this was React Native only. Jay Misiorek's also the creator of the Legend State Signals library. but apparently he's figured out how to port the underlying list virtualization logic over to React DOM as well, and says that it's one of the fastest, if n- if not the actual fastest virtualized list implementation out there . [00:14:13]
-
-## [TSRX revamped the syntax](https://tsrx.dev/blog/rethinking-tsrx)
-
-**Mark:** And then, other follow-up note, I think it was last month we had mentioned something called TSRX, where Dominic Ganaway and the Ripple project had said, "We're, annoyed at the JSX specification being stuck for, the last 10 to 12 years. [00:14:44]
-
-We have come up with what we think is a better syntax, that, adds more flexibility." And, after they announced it, they got a bunch of feedback on, people not liking some of what they designed. And so th- they did a couple different blog posts about how they've stepped back and rethought what the syntax is. [00:15:02]
-
-Things like, the original TSRX wanted you to put quotes around every bit of text that you had in there, whereas JSX just is angle bracket, words, angle bracket. And so they've, gone back to that as a syntax for text. So to be honest, I don't have a good mental picture of what the actual differences are between this and JSX at this point, 'cause I, haven't gone through it in detail. [00:15:21]
-
-But they, looks like they do have some control flow syntax embedded as well. so they're somewhere in between their original p- proposal and standard JSX at this point [00:15:49]
-
-**Carl:** Neat. It's a big swing. I said last month that I think it's interesting that now in the AI era you can just update documentation and the tool knows how to use it, which was not the case for previously. So that might make it easier for tools like this to succeed, because you can just drop in a different markdown document and the tools will know how to write the new code, so to an extent. It's not perfect. [00:16:02]
-
-## React Core news
-
-**Carl:** Let's get into the main content with some React core updates first? [00:16:28]
-
-## [React Compiler in Rust is rolling out](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x)
-
-**Mark:** All right, so the biggest thing this month is that the React compiler port into Rust has officially been merged, and there's been a whole flurry of activity of different build tools now trying to actually integrate this. so the React teams had said, "We have been trying out the port at Meta. It appears to emit identical results with the TypeScript implementation of the compiler." [00:16:32]
-
-## [PR was merged after testing at Meta and improved](https://github.com/react/react/pull/36173#issuecomment-4608356402)
-
-**Mark:** they did a bunch of work to optimize it and handle some more cases, and the PR itself got merged, about a week-ish ago, I think. So now that it's at least more or less available, then the question is, how do you actually use it? [00:16:57]
-
-I don't know if you can actually just install the Rust version of the compiler right now. I'd have to double-check that. But n- since we have a whole bunch of build tools, and most of today's build tools are now written in Rust, a lot of different teams have been exploring how do we actually integrate this into the build tools. [00:17:14]
-
-## [Oxlint, SWC, RSPack, Next all integrating](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x%20)
-
-**Mark:** So Oxlint, SWC, RSpack, Next, and Bun have all been trying to figure out how do we integrate with this, make it a, an option or built-in or something along those lines. [00:17:35]
-
-## [Rolldown tried integrating directly but removed due to binary size increase](https://x.com/evanyou/status/2069593612153987373)
-
-**Mark:** One interesting note is that Rolldown tried to actually add this into their system, so there would just be a built-in turn on the React compiler option. [00:17:50]
-
-And what they saw was that it increased the binary size from, 28 megs to 33 megs, and they decided that was too much extra size to force everybody to download, actually reverted it, and they're exploring further options on how they can integrate it. [00:18:01]
-
-## [Bun tried optimizing the Rust Compiler code](https://gist.github.com/Jarred-Sumner/84df369c35216f40d61d1ea9f95771c2)
-
-**Mark:** On the other hand, Bun taking the Rust code and tried to both integrate it and also see can we improve the Rust code itself to make the compiler run faster. [00:18:18]
-
-I think a couple of the other teams have also been seeing, now that the Rust code for the compiler exists, can we also make it faster as well? So there's clearly still a lot of development opportunities for different teams to explore in terms of how is it integrated into the build step, how fast does it run, but we now at least have the merged PR as a baseline for all that different work [00:18:33]
-
-## Other core improvements
-
-**Mark:** Couple other things I noticed. one is that the React team has been working on something called Fragment Refs for a while. We, might have mentioned this once or twice in the past. [00:18:57]
-
-**Carl:** Yeah, I think not a long time though. It's b- it's been a minute [00:19:08]
-
-**Mark:** it's been a while. The PRs were sitting out there or getting quietly iterated on. [00:19:11]
-
-## [Fragment Refs have been documented](https://react.dev/reference/react/Fragment#fragmentinstance) in canary
-
-**Mark:** So the idea for a Fragment Ref is that a React fragment by design does not have any single DOM node associated with it, because it's meant to be like a virtual container for many children. That's why we wrap them in a fragment in the first place. but what happens if you want to do something like listen to a DOM event for any of the children directly underneath the fragment, or perform some other DOM operation? [00:19:17]
-
-So Fragment Refs are a, I think, now in Canary feature where you can put a ref prop onto a fragment and you get back something that looks like a DOM node in terms of the methods you can call, add event listener and that sort of thing. and under the hood, React just does the work to pass the references on to all of its children automatically. [00:19:48]
-
-So it looks to your code like you're dealing with an actual DOM node, and under the hood, React takes care of, oh, there's 15 children directly under this fragment, let me just collect the interactions with all of them. So, that is apparently now in Canary, and they've actually updated the documentation page on fragments to say that you can use refs on them [00:20:16]
-
-**Carl:** Nice. Cool. the value here I think is really specific, and, it might, be unintuitive. it... let's say you wanted all of those DOM methods you just talked about, you wanted to be able to measure the size of this block of nodes or add an event or whatever. [00:20:40]
-
-Another way you could do that is to wrap it in a div. If you have a div, cool, great, free DOM node. You can do all those things. but that doesn't work in certain layouts. if you wanted to have a grid where all of them share a single, drag end event, you can't just wrap that in a div because that breaks the grid layout. [00:20:57]
-
-So this is a situation for, flex or grid, where there's an implied mandatory hierarchy of the DOM nodes itself, and you are rendering those s- containers, those children, s- let's say from a map. You're mapping over data, then this is super helpful for adding a whole bunch of different types of behaviors, which is why it's worth the effort. [00:21:19]
-
-## React DevTools MCP tools, including [component tree](https://github.com/react/react/pull/36597) and [perf analysis](https://github.com/react/react/pull/36598) APIs
-
-**Mark:** And then one other thing that I have a vested interest in, the re- there's been a series of PRs posted to improve the React Dev Tools by adding MCP tools so that agents can query and inspect it. some form of imperative API so that you can programmatically ask, what is the component tree, and even turn performance profiling on and off. [00:21:42]
-
-and then some, some additional wrappers to expose that data. I've spent a bunch of time doing React performance analysis work. I am doing some of that at my day job right now. so I'm, I am also keeping a very close eye on this because it's very heav- heavily related to my interests. [00:22:08]
-
-**Carl:** Yes, it is. Yeah, and we've got... [00:22:26]
-
-## React Foundation progress
-
-**Carl:** we mentioned briefly the React Foundation last month, and most of what we said was that we haven't been able to see very much of what's happening. We can see things. Visible change is happening. [00:22:28]
-
-## There’s a(n early) [react.foundation](https://react.foundation/) website, advertising funding for maintainers and community groups
-
-**Carl:** The React repos have moved, there's also a new website being developed. I've seen some chatter about that. [00:22:39]
-
-**Mark:** Like the, foundation page exists, but the, uh the current form of the page is very vibe coded. And so, a- they're, like what's there is accurate, but not well designed. [00:22:46]
-
-**Carl:** Yeah, it is definitely vibe coded vibes. but yeah, so that, that, should change soon. [00:22:59]
-
-**Mark:** The, couple of the interesting bits for me, if you look at the, React Foundation website right now, there's a strong emphasis on helping support the community financially. Some of that is they're apparently intending to sell swag, shirts, and whatever, they intend money fairly to maintainers of some of the most common React ecosystem libraries. They also talk- they've also talked both in the past and I think on the website about helping financially support different, communities, meetups, conferences as well. And then I think they are taking over running the official React Conf as well [00:23:05]
-
-**Carl:** Yeah, I know that they've actually been having some struggles getting meetups. they wanna support local React-based meetups, people aren't doing local React-based meetups anymore. It's all AI stuff or whatever. it's... I think the... I, think my intuition here a little bit is that some of their mental model for how the React community exists is still, maybe not fully reacted to the shifts over the last two years. [00:23:45]
-
-I love the idea of collecting nonprofit donations and then distributing them out to library maintainers. I think that is super, super good. And doing it with a, proper foundation with, governance and a board of directors is super good. I've ac- I actually thought quite a bit about trying to do a business adjacent to this, just, hey, we got a community. [00:24:14]
-
-What if we did, a bunch of little events and had a membership subscription or whatever, and then funneled 80% of that money to the people who make the community exist. and I, ended up not just 'cause it's it was hard. It's a lot of work. It's a ton. Access also helps. starting from I am the manager of the React core team is a very strong position to create a foundation. [00:24:35]
-
-**Mark:** the flip side of all this is that as I discussed last month, I have no idea what's going on with the development of React itself. the- there's PRs around the compiler and the dev tools. I really haven't seen much activity on the core library in the last few months. [00:24:58]
-
-Joe Savona c- and put up a post confirming that he is no longer on the React team at Meta. He's now working on something AI related. and then that kind of ties into what we'll talk about in a minute with what is going on at Meta anyway. So here feels like the development process on React itself is rather fragmented and confused right now [00:25:14]
-
-**Carl:** Which is unfortunate. [00:25:39]
-
-## They’re gonna have a booth at [Chain React at the end of July](https://chainreactconf.com/)
-
-**Carl:** But if you wanna talk to the core team or, some members of the foundation, or generally people close to the development of React, they will have a booth at Chain React, July 30th, which it's a React Native conference specifically, And it is, where is it? And it is in Portland. So yeah, if you're, around the Pacific Northwest or willing to travel, so yeah, check it out. [00:25:41]
-
-Okay, moving on a little bit. jumping off your tangent you just teed me up for, thank you. [00:26:04]
-
-## [Why is Meta destroying its engineering organization?](https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering)
-
-**Carl:** Why is Meta destroying its engineering organization? this is a newsletter post put out by Gergely Orosz, who's very influential, I would say. He puts out a, pragmatic engineering newsletter. It's very good. I read it occasionally. I read posts from him. [00:26:11]
-
-**Mark:** well written and sourced [00:26:27]
-
-**Carl:** Very well-sourced, very timely. He does a good job of being timely. so y- this is a, this, is again, a well-written, well-researched, well-presented post, talking about the engineering values of Meta historically. it brings in the, original Facebook little red book, which is a little, culture document describing the values of the company. [00:26:28]
-
-**Mark:** move fast and break things, but also like a, lot of stuff about how we want to think about building stuff for the customer [00:26:48]
-
-**Carl:** Yeah. okay, so Move Fast and Break Things is notorious. here are eight, no seven other values from the same book. [00:26:57]
-
-Done is better than perfect, [00:27:05]
-
-fail harder, [00:27:07]
-
-what would you do if you weren't afraid, [00:27:08]
-
-every day feels like a week, [00:27:10]
-
-the Wright brothers did not have pilot licenses, [00:27:12]
-
-the foolish wait and fortune favors the bold. [00:27:15]
-
-And I don't know, a lot of those are values I can, agree with. [00:27:17]
-
-**Mark:** It's better to get something done and see what happens than to waste all of our time discussing if we should try doing something [00:27:22]
-
-**Carl:** Yeah. Yeah. So I don't know, it's, it's a good doc. This is good speaking about the engineering cultural history and some of the actual timelines of improvements and, releases that they made. and it's, it lists a number of problems. th- they started tracking engineers' keystrokes with no way to opt out on work laptops. [00:27:28]
-
-it says "30 to 50% of engineers and core teams have been forcefully reassigned to data labeling." You think you're gonna be a core AI engineer and oops, you're just n- t- you're a competent, skilled professional tagging data the same as a legion of other competent, skilled professionals training your replacement. [00:27:52]
-
-I have a, friend of mine who was recently laid off from Meta who has been involved in, basically, just trying to resist this type of pressure. like for being forcefully reassigned to a team that you are not interested in being on, that sucks. [00:28:10]
-
-and it's part of your contract. It's ultimately, at the end of the day, you're in a hierarchical corporate system. They have hired you to perform work at their leisure, at their desire, and it is entirely within their legal contractual right to say, "You work on this now." [00:28:24]
-
-and that doesn't, What if it, wasn't their contractual right? What if they did have to actually negotiate with you and put you somewhere that was mutually compatible? So I don't know. That's, that's the pushback that they have been trying to support and organize. [00:28:40]
-
-But, meta is maybe not doing so great. I guess, one, one concrete engineering point that this, draws attention to was the r- disappointing AI model development. Like losing momentum effectively. Like Llama 1, 2, 3 were all very cutting-edge and competitive, and Llama 4 released over a year ago now, which I guess was the last release. I don't know of another release from them. [00:28:53]
-
-so yeah, I don't... as a symptom of declining engineering culture, their frontier AI model is no longer competitive. [00:29:20]
-
-**Mark:** Yeah. So some of the points it makes is that they, they, used to have v- pretty good engineering culture based on we're, trying to build the right things the right way at scale. The question of, whether the apps that they're building are useful for society is a different question, but at least they were mostly trying to build them the right way. [00:29:28]
-
-And now it seems like in the last year or two they have shifted to a focus on AI. They've had a bunch of layoffs. Engineers have been forcefully reassigned, and the, I know the performance review topic c- has come up repeatedly when I've talked to even, React core team members. They, they want to spend their time doing things that will benefit the greater React community, but they have to, in order to get good performance reviews, they have to show, like, how is this actually benefiting Meta the company. [00:29:44]
-
-And so whether that's something like, "We're gonna build this new React feature because it makes Ads Manager faster," or, just, interactions in some way. So that I know has been a struggle just for the React team, and it's clearly a major problem for everyone else at the company at this point. How justify my existence? [00:30:16]
-
-**Carl:** there's a book that I love called Moral Mazes that speaks a lot about this type of problem. we, we're talking about engineering culture. [00:30:35]
-
-That's... Culture is the downstream result of a vast group of people interacting with each other. The culture is the emergent property of how those individuals interact with each other. And Moral Mazes is a really wonderful sociological study of the firm, the c- the American corporation. And so it ends up speaking a lot about subjects like performance reviews. [00:30:44]
-
-And here in this blog post, the Pragmatic Engineer Newsletter, it says, "The biggest problem, people stop caring about real work and focus on performative work." and like what you just said about how they can't do what's best for the overall growth of the library because that's not the criteria upon which they're judged. [00:31:05]
-
-They are judged on their impact within the company, and specifically the impact on the company as judged by their immediate supervisor with, with the supervisor chain. So it, ultimately you're... The, incentives flow down in that kind of way. So it's actually... [00:31:23]
-
-there's, a deep fundamental misalignment between open source and, the American corporation, I'm not gonna go into capitalism a w- But, that's very true. Open source is a c- is a public good. It's a, it's, it's a public square. It's a shared resource that they're, people don't pay for. and those types of resources they're the economic concept of the tragedy of the commons. [00:31:41]
-
-It's a well-known principle that people don't just casually take care of stuff. If it's a public common, it's going to get more extraction than it is investment. So it's... I don't know. It's, it, there, the, th- that's a fundamental tension, and I feel like any time we're talking about companies under-investing in, open source, that's kinda why. [00:32:03]
-
-It's because they can't. They're not allowed to. If you're a big publicly traded company that has gone to IPO and has shareholders, you have a fiduciary duty to those shareholders, and fiduciary duty does not include volunteer effort to public goods. So it's, that's, there you go. That's the tension. [00:32:27]
-
-Anyway, let's move on [00:32:44]
-
-## [AI demands more engineering discipline. Not less](https://charitydotwtf.substack.com/p/ai-demands-more-engineering-discipline)
-
-**Carl:** Great post from Charity Majors who, somebody who I've ... They, are such a well-spoken, phenomenal writer speaking about engineering culture. And I, especially they talk about opera- or, yeah, I was gonna say operationalizing, production environments. [00:32:46]
-
-they run a company that makes its money on observability, [00:33:05]
-
-**Mark:** Honeycomb [00:33:08]
-
-**Carl:** Honeycomb. great company, great mission, great blogger, great writer. so i- she's put out a post, AI Demands More Engineering Discipline, Not Less. [00:33:10]
-
-Charity says in her post, "What happened in 2025 was this, the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated to being disposable and regenerable practically overnight." [00:33:20]
-
-And something I've said on this podcast before is that, code's kind of a liability. over time code is not an asset, it is a drain. It is something to be maintained. It is a cost center. so I agree with that. I think that read is correct. The, economics of code production were turned upside down. [00:33:38]
-
-it's m- because code is not an asset, because code is a liability, the ability to discard it and replace it with something new that is, has differ- has a different risk profile is massive. [00:33:57]
-
-**Mark:** It's, ironic because, as developers we have historically resisted, taking the time to write documentation or writing tests or actually planning out our work, and suddenly it turns out that in order to get good results from AI, we actually need to do all of the above. [00:34:12]
-
-**Carl:** Yeah, and it's like I have always known what the right choice to make was. it's y- several years ago when I was working as a tech lead, it's okay, we have this feature. I know that it is deficient in these , these areas. no, we don't have end-to-end tests. no, we don't have functional integration tests for all corner cases. [00:34:30]
-
-Because we don't have an existing end-to-end harness, because we don't have a framework for mocking network responses for requests initiated from components deep in the tree, deep in the hierarchy. there, it's, it... Engineering excellence is a momentum-based metric. You cannot skip ahead [00:34:53]
-
-You can't write end-to-end tests if you haven't built a reliable framework upon which to run end-to-end test suites. and so it's hard to do. It's hard to keep that momentum up over a long enough time span to where you start observing the benefits, and so most companies didn't. [00:35:12]
-
-the number of times where I would get feedback on something, and it's like, why don't we have this already?" It's, 'cause that would've taken two weeks, and I can do it now, but I didn't have two weeks." and I gotta say, I'm finding it much easier to find those two weeks with AI. AI is an amnesiac, so it needs to start from scratch every time. [00:35:30]
-
-if you're working on a new feature or just built something brand new, I just ask Claude, "Hey, familiarize yourself with this code base, how much of that did you get from docs versus the code?" [00:35:50]
-
-And it does a little analysis, and it comes back and says, "Oh, the documentation is out of date in these locations, and these concepts should be pulled in." "Great. Can you do that work for me?" It's like, "Oh, yeah. Cool, cool. And so then instead of, what, six hours of, reading code and putting together my own notes and understanding what documentation is currently available and synthesizing it to get, a fact-based update and then writing brand-new prose to fill in those docs, I, I, I can do that in 10 minutes in a background process. [00:36:00]
-
-**Mark:** Yeah, I, love generating architecture exploration e- explanation type docs. I've, found that extremely useful. In fact, that was my gateway that eventually led to me using aI to write code. It does feel like I'm leaving some understanding on the table, that my understanding is can be very much more surface level. some of it is, there's ar- areas of our code base and our projects I just haven't looked at, and operating off of a vague mental model. I, skimmed through a handful of architecture docs. that's certainly not, that's certainly not enough to actually understand what's going [00:36:30]
-
-Yeah place. It's, easier entry, but maybe not as much depth [00:37:04]
-
-**Carl:** That's very true. I assuage my own guilt in that, the like, "Oh no, I, know that I'm only seeing 30% of this." ' Cause for one, every code base is too large for your brain. you are never going to fully understand all of it at the same time. And any time that I did fully understand something, the, amount of time it took to get to that understanding, and then the only time I ever did that was to change it, [00:37:09]
-
-**Mark:** Mm. [00:37:37]
-
-**Carl:** So then as soon as I'm done with that, as soon as I have gotten my understanding up to 100%, cool, great, I'm changing it. That's now out of date. That knowledge is now useless. [00:37:38]
-
-**Mark:** I'm, sure I've mentioned this in previous episodes. I am a huge fan of the concept that programming is building a working mental model of the system. it's a, it's about theory building. So you understand what we are trying to build as a domain, as a project. [00:37:46]
-
-You understand the current system, the architecture, the quirks, the concepts, so that for any task you work on, whether it's a feature, a bug, whatever, you are starting from my current understanding. You break down the new problem based on your understanding. You come up with a plan, you implement it, you spend six hours trying to make it work, and by the time you're done, you not only have working code, you have updated your mental model on the system. So I would say it's not that you've made your previous knowledge useless, but we are continually modifying that understanding [00:38:03]
-
-**Carl:** Yes, sure. I agree with that. I agree with that, but I also discount it a little bit more than I think you are. Like, I'd agree that, developing an, accurate mental model is core. You need to do that as writing, as part of writing code. I, at least, am satisfied at the level that I am able to develop a mental model w- via AI. [00:38:36]
-
-I guess th- this is, a feedback cycle. You have to develop your mental model, check it against what the AI is telling you, and then make sure it's what you intended, and then make sure that what you intended is compatible with a functioning projec- will it achieve what you meant it to? [00:39:03]
-
-And those are all really hard, oh, another thing I wanna say your mental model, are, the building blocks that you have available to develop your mental model, are those complex enough to, capture what you're making? [00:39:19]
-
-That's something I run into fairly often. It's like the system architecture, the system design inter- interview questions. Like, how would you build Twitter to be re- resilient? Those are hard problems. That's re- you know, de- developing a system that can manage hundreds of millions of requests is, yeah, it's really tough, and AI is really helpful for me for exploring that. [00:39:33]
-
-it ends up being... Okay, oh, wait, here let me try and frame this in a sentence. It used to be critically essential to develop an accurate mental model through the process of reading and writing code yourself, and now it's much more important to be able to ask the correct question at the correct time of the code base. [00:39:58]
-
-Because now you can... The, frontier models are smart enough and the tools are capable enough, they can pretty meaningfully answer any question that you have about a fixed set of code. If you, bound it to like, "Here's the code, here's your world, tell me about it. Answer this question for me," it can. [00:40:18]
-
-And so now it's up to you to know what the right questions are to ask given the present state of the existing code [00:40:38]
-
-**Mark:** Yeah. So let's tie that then into the next link in the list. [00:40:46]
-
-## Christoph Nakazawa posted his [“Modern Engineering Values” and how he uses AI](https://cpojer.net/posts/modern-engineering-values)
-
-**Mark:** so Krzysztof Nakazawa is a long time figure in the React ecosystem. He's worked on Jest and graphQL and a whole bunch of other tools. more recently, he shipped a data fetching library called Fate. he's built a game with JavaScript called Athena Crisis. He got hired by Void Zero, which we'll talk about in a second. so like re- like really smart, capable long-term engineer, and he is now fully doing everything with AI. [00:40:51]
-
-**Carl:** Yep. [00:41:21]
-
-**Mark:** He put up a post on modern engineering values where he talk about how he uses AI effectively, but also then what are the principles that he's using in trying to build projects. And he talks about, ownership and taste and strict guardrails and fast feedbacks loops, which is what we were hitting on a minute [00:41:21]
-
-**Carl:** Yep. [00:41:42]
-
-**Mark:** Being able, to know what is the right context that I feed into the agents so that they are able to come up with the answers. maybe actually, owning some more your own code instead of depending on third-party libraries. Thinking differently about how you build prototypes and ship things. so very relevant to like we're, doing the same work, but maybe at a higher level, and you do have to know where you're trying to go [00:41:44]
-
-**Carl:** Yes. Yeah, agree. Yeah, I like this, bit from Christoph's post, "I've found that coding agents now write code that is as good or better than what I could write," which I would agree. I find that true as well. "And they do it in minutes instead of weeks. Since coding is no longer the bottleneck, I get a lot of work done that otherwise wouldn't have happened at all." [00:42:12]
-
-100% agree with that. That is... I have started and finished so many more projects than I would have before because I, can do it in a day instead of in a week. it's a 7X speed multiplier for me. So it's good. [00:42:30]
-
-## [Cloudflare bought VoidZero](https://voidzero.dev/posts/voidzero-cloudflare)
-
-**Mark:** In industry news, Void Zero, the company behind VitePlus and a couple other pieces, has been bought by Cloudflare, this continues the trend of a bunch of open source build tool developers try to get funding, try to make a company, and then they probably get swallowed up by someone bigger because there is no money in running open source build tools. Bun and a whole bunch of others all getting bought out. nobody is making money off of open source build tools. There is no build m- there is no financial model, hosting, or anything else. So we'll see how it plays out. to be clear, this is about the team and the VitePlus and Void tool sets and frameworks. [00:42:42]
-
-This does not affect Vite, the open source bundler, at all, other than these are some of the same people working on it. but it continues the pattern, and I don't see that pattern changing anytime soon [00:43:32]
-
-## NPM / security updates
-
-**Carl:** We got some more security updates from NPM. Great. [00:43:44]
-
-## [Github Actions allows enforcing pinned action SHAs](https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/)
-
-**Carl:** GitHub Actions now supports blocking and pinning actions to a specific SHA. So that's, that's really good. If you... So this is helpful for avoiding vulnerable actions. if you're aware that some specific release of an action was compromised, you can now block that one specifically. [00:43:48]
-
-Or say, "We know this one is good. Only use this version." wow. Ability to select precisely what code you're running. This feels like table stakes to me. It's shocking that we're only just getting it [00:44:09]
-
-## [GitHub Actions Has a Package Manager, and It Might Be the Worst](https://nesbitt.io/2025/12/06/github-actions-package-manager.html)
-
-**Mark:** there's, a guy named Andrew Nesbitt, I think we may have linked one or two of his articles previously, but he has become an expert on package managers and packaging systems, and I think he wrote an, a couple articles talking about, yep, GitHub Actions is totally a package manager. It doesn't look like one, but it is, and it's bad [00:44:21]
-
-**Carl:** Yes. Yeah, people shit on NPM for a lot of reasons, but you know what? The w- most most of the ecosystem problems in JavaScript around dependencies are because NPM is one of the only functional package managers in programming. Cargo or NuGet or, like, all of the other... [00:44:39]
-
-Every other language has a shitty dependency manager. It does not support what I would call core features of a dependency manager. For instance, pinning versions. Just, it's shocking to me how ineffective we are at sharing code in the vast majority of programming. anyway, yeah. So great. So many things are terrible dependency managers, and GitHub Actions is now a slightly less terrible pa- package manager [00:44:58]
-
-## [NPM 12 will disable install scripts and Git deps by default](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
-
-**Carl:** GitHub also put out some breaking changes for npm 12. They are not going to run install scripts and Git dependencies by default. that is... This is literally something I've seen discussed as a security vulnerability for 10 years. [00:45:27]
-
-So it finally got exploited enough times that they're like, "Nope, okay, we gotta get rid of it." great, cool. They're getting rid of the thing that has been discussed as something that should be gotten rid of for a long time [00:45:43]
-
-specifically it's, NPM will no longer run pre-install, install, or post-install scripts from dependencies unless you allow list them. So no builds basically [00:45:54]
-
-**Mark:** what I think pnpm als- already does [00:46:05]
-
-**Carl:** Plenty of package managers already do that because running untrustworthy code from a network is really dangerous. [00:46:08]
-
-Don't do it. This is what I mean, like, I just said, NPM is one of the most advanced package managers in all of programming, and it still gets basic shit wrong. Stop it. Security models. [00:46:13]
-
-## Code optimization still matters!
-
-**Mark:** All right, last major item for the day. topic, a related topic, but, bit of a grab bag. There's a whole bunch of good articles about code optimization that came out in the last few weeks, and I've spent a lot of time doing performance profiling. I have literally given a talk this year on how to do performance profiling. So we had several articles on, and from people who did performance optimization work on tools and libraries. [00:46:25]
-
-## [TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects](https://tanstack.com/blog/tanstack-table-v9-memory-performance) and [optimized TS perf](https://tanstack.com/blog/tanstack-table-v9-typescript-performance)
-
-**Mark:** First off, there's a couple articles from the TanStack Table folks where they talked about how they were able to save a bunch of memory within TanStack Table by switching out the JavaScript prototypes that were being used, as well as how they optimized, the TypeScript compilation performance. [00:46:53]
-
-Now, yes, TypeScript's version seven's gonna make all our TypeScript faster, whatever, but it's still good to actually try to improve the, type checking time if possible. [00:47:14]
-
-## [Pierre Diffs was significantly optimized](https://pierre.computer/writing/on-rendering-diffs) - has to handle virtualization, syntax highlighting, source loading
-
-**Mark:** next, there's something called the Pierre Computer Company, which is making essentially like a, GitHub for, as a service kind of a, set of tools. [00:47:25]
-
-And they've put out a couple JavaScript libraries, one for rendering tree views in the UI, but they also put out one that is a diffs rendering library. And so they've put up a post on how they heavily optimized all the list virtualization and the syntax highlighting and all the other complexities of trying to render diffs efficiently in the browser. [00:47:35]
-
-And I've seen several other applications pop up which use that library in the UI. part of me make, wonders if GitHub perhaps consider using that library in their UI given the, how slow their React based, PR view is at this point [00:47:59]
-
-**Carl (editing):** oh, shoot. We had an audio problem. For some reason, we lost about the last 10 minutes of my audio. Mark's came through just fine. Uh, and luckily he did most of the talking in the last little bit here. Uh, but unfortunately we lost about four to five minutes of me responding to things that Mark said. Uh, oops, sorry. [00:48:20]
-
-## [CompileCat is a new optimizing compiler to improve JS execution after bundling](https://github.com/isaac-mason/compilecat), similar to Closure Compiler. ([the RSPack team says they’re working on something similar](https://x.com/jiahan_c/status/2065630866668453898) )
-
-**Mark:** A couple more of these. So someone recently started a site called Performance.dev. Their first article previously was on how the linear UI is fast using sync engines, and they just put up another post on how a tool called Conductor implemented a bunch of optimizations, handling some of the UI layer interaction with Tari, list virtualization, and a bunch of other pieces. [00:48:38]
-
-so those are, apps and libraries making things faster. I saw a couple, winks on something different. So we all use minifiers in our bundling process. It's, part of all modern build tool chains. minifiers do things like they don't just rename variables from my variable to A. [00:49:03]
-
-They, they strip white space. They turn true and false into bang zero and bang one be- because it takes up fewer characters, et cetera. But they also do things like stripping out dead code. So if a library has only r- has a, an if statement that says, "Only run this in development," it will convert that to if false, and then it will say, "Oh, that code can't run. [00:49:25]
-
-Just delete that code from the bundle and optimize the output." And so every time you run a build, a minifier is optimizing the output. And the major mini- the major minifiers, optimizers have been things like Terser and, ESBuild has had one built in, Rolldown has one built in. there's be- there's one that's been around for a very long time called the Google Closure Compiler. [00:49:49]
-
-this dates back to when Google first built a lot of their early web spa type tooling. 2008, 2009, somewhere in that timeframe. it's, extremely powerful and has a lot of very advanced optimizations that other minifiers still don't have, but it's also big and complicated and maybe a little bit on the slow side. [00:50:14]
-
-interestingly, the React team still uses the Closure Compiler to build the React library so that the production version of React is as fast as it can possibly be. So I saw two different announcements of teams that are attempting to write their own advanced optimizer tools. one person built something called CompileCat, and then the other one's a mention of an internal tool that's not released yet, but the, RSPACK team at ByteDance said they're also working on a similar tool. [00:50:35]
-
-So presumably doing things like actually looking at not just the JavaScript, but the TypeScript types in order to be able to, be smarter and produce better output code as well. [00:51:11]
-
-## [Mark’s React-Redux \\\+ signals draft perf PR](https://github.com/reduxjs/react-redux/pull/2318) and [updated React-Redux benchmarks repo](https://github.com/reduxjs/react-redux-benchmarks)
-
-**Mark:** And then I guess we'll wrap up this section with three things for me. so I, think I briefly mentioned last month that I was working on a proof of concept to try to optimize React-Redux's subscription notifications for our large applications. so I have a draft PR, and I've put that up, and the early numbers look promising, like 20% to 30% faster depending on the situation. [00:51:22]
-
-as part of that, I also updated my React-Redux benchmarks repo so that I've got better metrics that I'm capturing and, a better, more realistic set of example scenarios to be measuring against. And then one of the conference talks that I've been doing this year is literally on the basics of performance optimization. [00:51:50]
-
-there's a set of general scientific principles to apply, descriptions of actual tools that you would use to measure JavaScript performance and fi- try to figure out which lines of code are slow, and I talk about some of the examples I did while working on Immer last fall [00:52:12]
-
-I think this is all very important even in the age of an AI because AI tends to write the obvious code. It doesn't necessarily write the fast code. And we collectively were already very bad at asking, "Is this code fast?" in the first place when we were the ones writing it. And now that n- we're not the ones writing it, it's even easier to never ask the question, "Is it fast?" [00:52:28]
-
-## [Aurora Scharff’s preferred RSC component architecture](https://aurorascharff.no/posts/component-architecture-for-react-server-components/)
-
-**Carl (editing):** Yep. So right here is where we lost about four minutes. Uh, unfortunately, I, I definitely cannot reproduce what I said, which is a big bummer. I think it was probably really smart and really clever and really wrapped up the whole thing of what we talked about all episode. But unfortunately, it's gone into the ether. [00:52:51]
-
-I tried re-extracting the audio as recorded from the original source, and it was just blank. We're just completely missing 10 minutes. sorry. [00:53:07]
-
-All I really know is that I was introducing Aurora Sharf's blog post titled "Component Architecture for React Server Components" as her preferred RSC component architecture. [00:53:15]
-
-And I know that because Mark said after [00:53:26]
-
-**Mark AI filler:** yeah. And, Aurora really is the expert on this kind of stuff right now [00:53:29]
-
-## [Lovable projects now use TanStack Start by default](https://lovable.dev/blog/building-apps-using-tanstack-start)
-
-**Mark AI filler:** And then one, one other interesting data point to wrap up, announced that all of their Vibe-coded app projects are now going to be built with TanStack Start by default. I don't remember whether they were just using plain Vite React router or something previously. but this feels it, it's a very interesting data point. A sign of the maturity of TanStack Start, and that they're, and they're happy to actually adopt this as the default setup for all their projects going forward. [00:53:34]
-
-**Carl (editing):** And that is all we've got for you today. I am re-recording this afterwards just like all the other things I said in the last 10 minutes. So I'm not gonna do the usual full sign-off 'cause this is totally fake and I'm just sitting at my desk talking to myself. Sorry for taking a few extra days to get the podcast out. I am just tired and it's summer [00:54:05]
-
-Thanks so much for listening all the way to the end even. talk to you next month [00:54:24]
diff --git a/src/transcripts/tmir-2026-07.md b/src/transcripts/tmir-2026-07.md
deleted file mode 100644
index ebd1faf..0000000
--- a/src/transcripts/tmir-2026-07.md
+++ /dev/null
@@ -1,667 +0,0 @@
----
-title: "TMiR 2026-07: React-alikes, GOVERNANCE, and state management"
-date: 2026-07-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we discuss the React Compiler being rewritten in Rust, what AI development means for engineering culture, "
-people: "[Carl](https://bsky.app/profile/vcarl.com), [Mark](https://bsky.app/profile/acemarke.dev), and [Mo](https://bsky.app/profile/mojavad.bsky.social)"
----
-
-
-
-
-
-- [[01:27](#new-releases)] New releases
- - [[01:29](#vite-beta)] [Vite+ Beta](https://voidzero.dev/posts/announcing-vite-plus-beta)
- - [[02:41](#typescript-70-released)] [TypeScript 7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) released
- - [[03:56](#open-pr-for-content-mappers-to-typecheck-templates-other-than-jsx)] [open PR for “content mappers”](https://github.com/microsoft/typescript-go/pull/4712) to integrate other language syntax
-- [[04:57](#johnson-chu-made-a-compatibility-layer-to-drop-in-for-unsupported-tools)] Johnson Chu made [a compatibility layer to drop-in for unsupported tools](https://github.com/johnsoncodehk/typescript-native-bridge)
- - [[05:18](#oxc-type-aware-linting-stable)] [OXC type-aware linting stable](https://oxc.rs/blog/2026-07-22-type-aware-linting-stable)
- - [[06:00](#npm-v12-and-new-security-defaults)] [NPM v12 and new security defaults](https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation/)
- - [[07:00](#dependabot-supports-a-configurable-delay)] [Dependabot supports a configurable delay](https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/)
- - [[07:37](#more-react-rsc-security-tweaks-for-19x-)] [More React RSC security tweaks for 19.x](https://github.com/react/react/releases/tag/v19.2.8)
-- [[08:06](#main-content)] Main Content
- - [[08:07](#react-org-updates)] React org updates
- - [[08:22](#leadership-council-and-working-group-structure-on-the-new-team-page)] “Leadership Council” and Working Group structure [on the new team page](https://react.dev/community/team)
- - [[11:11](#stub-governance-docs-for-the-leadership-council)] [Stub governance docs](https://github.com/react-foundation-dev/leadership-council) for the Leadership Council
- - [[14:37](#rick-hanlon-update-on-the-react-team-using-a-stage-process-internally)] Rick Hanlon update on the React team [using a “stage” process internally](https://www.reddit.com/r/reactjs/comments/1v1dsh0/react_rfc_processis_it_dead/oyp9wac/)
- - [[15:39](#pete-hunt-and-nick-schrock-join-vercel-to-run-frameworksnext-and-agent-dx)] [Pete Hunt and Nick Schrock join Vercel](https://x.com/rauchg/status/2077870043833229692) to run Frameworks/Next and Agent DX
- - [[17:16](#poimandres-published-a-charter-original-announcement)] Poimandres [published a charter](https://github.com/pmndrs/org/blob/main/CHARTER.md) (original [announcement](https://x.com/pmndrs/status/2080303456800080047))
- - [[20:20](#an-example-initiative)] An [example initiative](https://github.com/pmndrs/org/blob/4bd14e20da776ff68f7555a57a01ad0b4999be92/initiatives/03-text-rendering.md)
- - [[21:30](#react-alikes)] React-alikes
- - [[21:40](#octane-from-dominic-gannaway)] [Octane](https://octanejs.dev/) from [Dominic Gannaway](https://bsky.app/profile/trueadm.dev/post/3mrn7yd6dzk2t)
- - [[28:27](#ryan-carniato-reacts-staying-power-is-because-of-complacency)] Ryan Carniato: ["React’s staying power is because of complacency"](https://x.com/RyanCarniato/status/2072382108535066640)
- - [[29:12](#follow-up-do-people-think-fe-innovation-is-dead-would-explain-why-theres-resistance-to-move-past-old-react)] Follow-up: [“Do people think FE innovation is dead? Would explain why there’s resistance to move past old React.”](https://x.com/RyanCarniato/status/2081813329681711152)
- - [[30:31](#parallel-articles-on-solid-20-with-async-and-remix-3)] Parallel articles on [Solid 2.0 with async](https://www.brenelz.com/posts/learning-solid2/), and [Remix 3](https://malstrom.me/blog/learning-remix-3)
- - [[32:22](#cross-framework-benchmark-measuring-reactivity)] [Cross-framework benchmark measuring reactivity](https://bsky.app/profile/nullvoxpopuli.com/post/3mrplyqcd722j)
- - [[35:04](#aiden-bai-released-reactbench-to-measure-ai-code-quality)] Aiden Bai released [ReactBench to measure AI code quality](https://www.reactbench.com/)
- - [[36:37](#alex-russell-thinks-everyone-is-screwing-up-state-management)] [Alex Russell blasts “state management”](https://infrequently.org/2026/07/state-management/) (and most of the React ecosystem) in favor of sync engines
- - [[47:41](#aurora-scharff-rewrote-the-suspense-docs-page-to-cover-how-it-works)] Aurora Scharff [rewrote the Suspense docs page to cover how it works](https://react.dev/reference/react/Suspense#what-activates-a-suspense-boundary)
- - [[48:22](#and-a-post-on-rsc-performance-patterns)] And a post on [RSC performance patterns](https://aurorascharff.no/posts/experimenting-with-rsc-for-performance-and-ux-in-nextjs/)
- - [[48:41](#tanstack-removed-rscs-from-the-website)] [TanStack removed RSCs from the website](https://tanstack.com/blog/we-removed-rsc-from-tanstack-com)
-- [[51:04](#marks-making-progress-on-some-react-redux-perf-prototyping-and-thinking-about-rtk-30)] Mark’s making progress on [some React-Redux perf prototyping](https://github.com/reduxjs/react-redux/pull/2318) and thinking about RTK 3.0
- - [[57:36](#making-referential-stability-a-type)] [Making referential stability a type](https://www.jovidecroock.com/blog/referential-stability-types/)
- - [[59:17](#porffor-native-compiler-upcoming-alpha)] Porffor native compiler [upcoming alpha](https://honk.foo/porffor-alpha/)
- - [[59:39](#perry-cross-compiles-claude-code-bundle)] Perry [cross-compiles Claude Code bundle](https://www.perryts.com/en/blog/compiling-claude-code/)
- - [[01:00:17](#vercel-releases-scriptc-native-compiler)] Vercel [releases scriptc native compiler](https://github.com/vercel-labs/scriptc)
- - [[01:02:04](#goodbye-forever-probably)] [Goodbye, forever, probably.](https://whitep4nth3r.com/blog/goodbye-forever-probably/)
-- [[01:08:41](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:08:53](#sep-11-zurichjs-switzerland)] Sep 11: [ZurichJS](https://conf.zurichjs.com/), Switzerland
- - [[01:09:14](#sep-25-26-react-alicante-spain)] Sep 25-26: [React Alicante](https://reactalicante.es/), Spain
-
-**Carl:** Hello. Thank you for joining us for the July edition of This Month in React, as we recap what's been going on with React Native and other things across the web. We are coming to you live from Reactiflux, the place for professional developers using React. And I'm Carl. [00:00:00]
-
-I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like these events and build tools like help keep the community operating. [00:00:13]
-
-**Mark:** Hi, I'm Mark. My day job is replay.io, where we've built time travel debugging, are working on autonomous QA, and I get to do all kinds of awesome time travel-powered React analysis tools. And outside of that, I am still doing Redux stuff, and I'm actually finding the energy to do a fair amount of that right now, which is cool. [00:00:22]
-
-**Carl:** Nice. Heck yeah. Hell yeah for finding the energy to invest in a project you love. [00:00:41]
-
-**Mark:** Yep. I'm also actually back at home after, like, two and a half months of almost nonstop conference travel. [00:00:47]
-
-**Carl:** We were saying in prep, we have kind of a grab bag this month. There's not, like, one big thing to discuss, but yeah, we're gonna get into a couple things. [00:00:53]
-
-Uh, obviously there's been more security stuff and new releases of major projects, like TypeScript 7, which we've discussed, like, four times already, but y- it's here. Yay. [00:01:00]
-
-We also are gonna get into some open source governance questions. There's been some developments on the React Foundation. And l- kind of out of left field at the same time, Poimandres a cooperative doing open source around Three.js. It also published some governance work. So yeah, we're gonna get into it. [00:01:09]
-
-## New releases
-
-**Carl:** But first, the first new release. [00:01:27]
-
-## [Vite+ Beta](https://voidzero.dev/posts/announcing-vite-plus-beta)
-
-**Carl:** Vite\+ from Voidzero is in beta now. [00:01:29]
-
-**Mark:** It's not paid anymore. Oh, okay. They dropped that. I think they dropped the paid part even before they got bought out. [00:01:33]
-
-They initially said it was paid. Then they said, "No, no, we'll, we'll make Vite\+ free. We're gonna build our own server runtime layer on top of Cloudflare," and then Cloudflare just bought the entire company. [00:01:40]
-
-So- Great ... Plus itself, as far as I know, is going to be entirely free at this point multiply. But it's just the Void Zero company had been paying a bunch of people to build out OXC, you know, that whole layer of parser tooling, partly to use in the Rolldown Rust-based bundler. [00:01:51]
-
-The latest version of Vite uses Rolldown, but then there's all these other Rust-based tools related to that. And so Vite Plus is a combination of we have pre-configured all these different tools into one super package, as well as added some additional layers of functionality on top of that. So it's essentially supposed to be an entire JS development suite in a box, sort of akin to what Rome was promising a few years ago. [00:02:13]
-
-**Carl:** Cool. Love that. [00:02:40]
-
-## [TypeScript 7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) released
-
-**Mark:** Meanwhile, as mentioned, we have talked about this repeatedly, so I don't have to go into a lot of details, but TypeScript 7 is finally live. Hooray. This is the Go implemented native implementation of the TypeScript compiler that is supposed to be up to 10X faster, so the actual... [00:02:41]
-
-If you install the actual TypeScript package at latest now, it is actually built with Go under the hood. The biggest caveats here at the moment, as we've again talked about, the programmatic TypeScript API essentially does not exist in version seven, because the API had been partly official, partly unofficial before that And lots of different tools had various dependencies and needs. [00:03:00]
-
-A lot of them had hacked together solutions in the past, and so the TypeScript team said, "Okay, we know the compiler itself's working. We're gonna get that out the door. We want to take our time and carefully consider what a better and proper public API would look like to support all the different use cases people have come up with, and we'll get that out the door in, like, a version 7.1 or 7.2." so there is some, there is an update on that front. [00:03:28]
-
-## [open PR for “content mappers”](https://github.com/microsoft/typescript-go/pull/4712) to integrate other language syntax
-
-**Mark:** They've put up a PR for something they're calling content mappers, and the way I'm understanding this is that for other languages like, say, View or Angular that have templates, you want to be able to type check the templates. The TypeScript compiler handles JSX, which means React kind of got special treatment there. [00:03:56]
-
-But how can other languages actually get similar behavior for non-TypeScript syntax? And so this content mappers proposal from the TS team is a way that they're hoping they can address essentially a plug-and-play conversion of other syntax into something TypeScript itself can type check. So there, there may be other API integration things that they're looking at as well, but this feels like it's a, a good step in that direction. [00:04:17]
-
-And in the meantime, a bunch of teams are doing things with integrating with TS Go in hacky ways you're not supposed to anyway. [00:04:49]
-
-## Johnson Chu made [a compatibility layer to drop-in for unsupported tools](https://github.com/johnsoncodehk/typescript-native-bridge)
-
-**Mark:** Johnson Chu, who I think built the Alien Signals library, and I think also works on the Vue Volar language extension, if I've got my connections right, put together a package called the TypeScript Native Bridge, which is supposed to help polyfill some of the, I think, the language server-type integrations so that they're faster. [00:04:57]
-
-## [OXC type-aware linting stable](https://oxc.rs/blog/2026-07-22-type-aware-linting-stable)
-
-**Mark:** And then the OXC folks have been doing their own hacky native TypeScript integration to try to enable typed lint rules within the OXC linter. And so the typed linting support has just gone stable as well. So, lot of improvements around TypeScript compiling and checking in the entire tooling ecosystem. [00:05:18]
-
-**Carl:** Interesting. Yeah, type-aware linting would be a really big win. I've wanted that a number of times, and we've never really gotten there. [00:05:42]
-
-**Mark:** TS ESLint has them, but it requires a lot of slower integration and running full-blown standard TS type checking. [00:05:49]
-
-**Carl:** Cool. Can you talk about this install time security, Mark? [00:05:56]
-
-## [NPM v12 and new security defaults](https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation/)
-
-**Mark:** Due to the entire series of supply chain attacks that we've seen happen over the last year, one of the biggest issues has been that packages are allowed to run scripts after install by default. And so you're just arbitrarily executing remote code on your machine with your privileges. And so several other package managers like pnpm had switched to disallowing that by default. [00:06:00]
-
-And so npm 11 still allowed that, but they started adding the options to disable running scripts by default and preparing things. So npm 12 actually does flip the switch on a lot of those options. So npm 12 no longer runs post-install scripts by default. By default, it does not allow a Git repo URL as a valid dependency, and it has a couple other options that it turns off by default to enable security. [00:06:27]
-
-## [Dependabot supports a configurable delay](https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/)
-
-**Mark:** I also saw that GitHub is changing Dependabot, so it now has a cool down by default, so it won't install new deps until, like, two or three days after they came out. [00:07:00]
-
-So we are very, very belatedly, as an ecosystem, finally learning some lessons we probably should have learned many years ago, and changing some of the default behaviors of our tools to try to cut down on the blast radius of some of these malware releases. [00:07:10]
-
-**Carl:** Yeah. And we've covered some of that in recent episodes, so I, let's not rehash it entirely again. Mm. Yeah, definitely some, uh, long overdue changes here. [00:07:27]
-
-**Mark:** Yep. [00:07:37]
-
-## [More React RSC security tweaks for 19.x](https://github.com/react/react/releases/tag/v19.2.8)
-
-**Carl:** As well as, I guess, in w- security tweaks for server components that were just released this week. [00:07:37]
-
-**Mark:** Yep. Looks like another denial of service attack possibility. [00:07:44]
-
-**Carl:** Okay. [00:07:48]
-
-**Mark:** So just bad, bad... So not remote code execution, but bad input freezes the server. [00:07:48]
-
-**Carl:** Okay. Can't have that. That's a denial of service vector. Okay, well that's the, like, brand-new releases we have. There's some other new stuff, but a little bit, like, less, you know... N- we're not gonna start with it, but we're gonna do that towards the end. [00:07:54]
-
-## Main Content
-
-**Carl:** Main content. [00:08:06]
-
-## React org updates
-
-**Carl:** We are gonna start with the React org updates, and we're gonna frame this against the backdrop of, like, open source governance generally. There have been some changes announced by the, uh, you know, React Foundation within the Discord. [00:08:07]
-
-## “Leadership Council” and Working Group structure [on the new team page](https://react.dev/community/team)
-
-**Carl:** There's been, you know, there's been a, a couple of visible changes to the website and PRs to the actual governance repository. [00:08:22]
-
-**Mark:** I specifically had been griping, I think in the last two months, that I have no idea who's even on the React team anymore. And I don't know whether they literally heard me or whether this was just, you know, kind of coincidental timing. [00:08:32]
-
-But they did a significant update to the existing React team page on the website. They updated it both with, you know, current people involved in moving some folks to more of, like, an emeritus status. But the team page now actually reflects a new team structure that is coming out of this React foundation itself, where there's, like, a set of different working groups for topics like, you know, server components and compiler and, and other things. [00:08:46]
-
-But then there's, like, a leadership council that appears to be essentially, like, a, a representative from each of those groups, as well as possibly a couple others. So I still don't, still don't have a lot of details on the actual responsibilities, but we're seeing some visible evidence that they're working on the organization process here. [00:09:17]
-
-**Carl:** Interesting. Cool Curious, the reason I'm in the Discord is 'cause, 'cause somebody reached out asking if I wanted to help with community, and so now seeing a bunch of people listed as on the Docs and Community Working Group and nobody reached out to me makes me feel like I got left out. [00:09:39]
-
-But that's okay. I'm an independent actor, unaffiliated. [00:09:51]
-
-**Mark:** The list of working groups is, uh, server, DOM, fiber, docs and community, compiler, DevX, and React Native. [00:09:55]
-
-**Carl:** Yep. I am s- slightly surprised to see React Native generally put into its own single group, because they're a- at least as large as React. [00:10:04]
-
-I would say technically, you know, problem space they operate within is larger than React itself. So I'm slightly surprised to see it positioned as a single working group under the umbrella of React. But I guess, you know, there's other organizations that are more meaningfully invested in React Native, so, uh, maybe this is more of, you know, division of labor. This is the pipeline more than the umbrella, per se. [00:10:12]
-
-**Mark:** It's also worth noting that there, there's like seven or eight people on the leadership council, which I guess, you know, matches roughly the number of working groups. And then the working group members section is at least a good 20-plus people long for current people, and then there's a set of advisors and a set of emeritus people. [00:10:33]
-
-So there, there's a good 30 to 35 names listed on this page. Like, it's not just, you know, two to three people. [00:10:54]
-
-**Carl:** It's quite a long list, and it is much more specific. I don't know. We just complained about this, and it's really nice to see a, like, full refresh that looks reliable. That's nice. [00:11:01]
-
-## [Stub governance docs](https://github.com/react-foundation-dev/leadership-council) for the Leadership Council
-
-**Carl:** I was reading a little bit of the charter. It is pretty interesting. It looks like they're quite earnestly trying to make this, like, you know, open participation, and I've thought a lot about governance questions and stuff like cooperatives and, like, how do you do... If you have multiple people with opinions about what to do with a project, a shared good, I don't know, it's really hard, it's really hard to do that right in a way that allows people to feel represented and like they have agency in the overall system. [00:11:11]
-
-So I appreciate the challenge of what they are trying to do. It is difficult to set up a general organization that lets many people in many walks of life feel heard. I like the, the way they scoped it as, you know, "the mission and scope of the project is to develop and maintain React and associated open source software. The leadership council will be responsible for technical oversight of the open source project." [00:11:39]
-
-You know, like, this is... I can tell that from reading this, that the way that they are discussing responsibilities and constraints and decision-making and work delegation, like they are very meaningfully trying to make this open participation And with a high bar of quality. [00:12:00]
-
-Yeah. This is, you know, primary source kind of stuff. This is-- The commit on this charter.md document is two days old, so this is, like, brand new. No one has really been... This is a- as yet untested. The processes described here are not currently fully implemented. But yeah, what I see here looks quite good to me. I like it. [00:12:19]
-
-**Mark:** And to be clear, like, the, the repo's public. I mean, I can look at this information right now. I don't-- The- there hasn't been, like, a formal team announcement of the leadership council and the charter per se, but clearly they're trying to put all the pieces together to be able to say, "This is the way we're gonna do things." [00:12:38]
-
-**Carl:** Yes. Okay, I don't see-- I heard rumor of a, uh, pending blog post, but I, I don't see it yet, so... But yeah, I expect that there should be some broader announcement of what this is and what it means and what their intentions are coming soon. But what I see here looks quite good. I like it. It seems like a good effort. [00:12:56]
-
-**Mark:** Like I said, I, I griped a little bit about the lack of visible progress in the last few months, but clearly what we're seeing here, and even what I'd heard about the amount of effort that was needed to just create the foundation in the first place. Like, there is a lot of effort going on behind the scenes, clearly, and there's a lot of good faith intention behind what they're trying to accomplish. Like, this is not just for show. [00:13:13]
-
-**Carl:** Yes. Agreed. [00:13:36]
-
-**Mark:** One of the longstanding complaints about- You know, the community with React and React with the community has been, they do most of their coding work in public, but there's also some that happens behind the scenes in private. And historically, they've had the problem that any time they push a draft PR, people jump on it. [00:13:37]
-
-It's like, "Oh, React is working on this new feature," and they start writing blog posts and tutorials and everything. And so that has actually made the React team less likely to show their work in public, because a lot of times it is an experiment or a prototype, and there's no guarantee that this will even ship at all. [00:13:55]
-
-So there's been discussion on both sides that it would be really helpful if they tried to follow a TC39 stages model, where it's very clear that we are working on concept X. It is a stage one prototype, a stage two, like, we think this is likely. Stage three, this is probably gonna ship. Stage four, it's ready. That kind of thing. [00:14:14]
-
-## Rick Hanlon update on the React team [using a “stage” process internally](https://www.reddit.com/r/reactjs/comments/1v1dsh0/react_rfc_processis_it_dead/oyp9wac/)
-
-**Mark:** And so Rick posted a comment on Reddit saying that they've been trained to follow that model themselves internally and had some success with it. But essentially, they're trying to prove to themselves that they can actually work using that approach before they fully publicly commit to doing that and making the scale, the stages and progress public. [00:14:37]
-
-**Carl:** Yeah, and we've talked a couple times in past episodes about the general challenges, like the tensions there of them earnestly wanting to work in public and having repeatedly tripped over the same problem every time they've tried to of, you work in public and then you get just a bunch of yahoos talking over you as you're... [00:15:01]
-
-You know, the, the people who don't, people who haven't seen the work that went into the current state that is actually now public and end up just re-litigating all the same issues or, you know. So there, there are a lot of very real challenges there, and I earnestly appreciate the continued exploration of how to make that actually functional and work well for as many people as possible. [00:15:18]
-
-## [Pete Hunt and Nick Schrock join Vercel](https://x.com/rauchg/status/2077870043833229692) to run Frameworks/Next and Agent DX
-
-**Mark:** One other small but related item. You know, there are a bunch of React folks at Vercel at this point, and Guillermo just announced that Pete Hunt and Nick Schrock have both joined Vercel. [00:15:39]
-
-Pete Hunt was one of the first advocates for React at Facebook at the time. He did one of the more famous talks that helped get React off the ground in public. He had spent the last few years, I think, working at a company called Dagster that just got acquired, and so this is presumably his chance to move on from that. But the announcement is that he'll be leading the frameworks group in Next.js itself. [00:15:52]
-
-And then Nick Schrock was instrumental in the development of GraphQL as a spec at Meta, and he is gonna be working on Agent DX or something along those lines. [00:16:18]
-
-So Ver- Vercel continues to scoop up more and more of the folks who were involved with React at Meta at some point in the past. [00:16:31]
-
-**Carl:** Yeah, I'm curious to see about the interplay between Agent DX and the GraphQL, because increasingly so, what an agent needs to do with an arbitrary server is get the data it wants And that's what GraphQL's good at. [00:16:39]
-
-Hey. Yeah, I'm skeptical of MCP. MCP is gonna die. Actually, no, it's not gonna die. It's gonna, it's gonna live forever the way that, like, SOAP does. Yeah. It's gonna be an early exploration of a, an A- API, and I think it's going to be widely hated in five years. Calling it now. There's my mark on the yardstick. [00:16:56]
-
-## Poimandres [published a charter](https://github.com/pmndrs/org/blob/main/CHARTER.md) (original [announcement](https://x.com/pmndrs/status/2080303456800080047))
-
-**Carl:** Related to the org updates and open source governance more than that last update, though, Polymanders has published their charter as well. It's been around for, I would say, at least eight years, maybe 10 years at this point. Oriented around Three.js and 3D rendering on the web, I think is a fair characterization. [00:17:16]
-
-**Mark:** A, a number of, number of folks there have prior experience in game development one way or the other. Sort of a set of artists collaborating to build related things together kind of a vibe. [00:17:36]
-
-**Carl:** Yes. Yes. Right. We all have a shared interest, a shared passion in this. You know, I open their website and it's full of WebGL demos with, you know, parallax and physics and refraction and, you know, translucent interact... [00:17:50]
-
-You know, so it's, that's generally what they're anchored around. It's a bunch of artists doing art on the web in different ways, playing with visual technology on the web. And I- when I say playing, I don't mean to diminish. I mean earnest play in the sense of exploration. [00:18:05]
-
-**Mark:** It's also worth noting that was originally developed by one of the, one of the earlier folks in that org, and I b- and I think Z- possibly Zeustin and Jotai and Vultio are still owned by that org on GitHub. [00:18:21]
-
-**Carl:** Yeah. Zeusstand, React Three Fiber, React Spring, Jotai, Volto, Drei. [00:18:37]
-
-**Mark:** Some very solid well-known libraries in the React ecosystem. [00:18:42]
-
-**Carl:** Yes. Yeah. Tons and tons of well-known projects. Yeah, so like, I hope that didn't sound diminishing because I do not mean to diminish. [00:18:45]
-
-These are talented, respected. But yeah, so they, they... As a point of comparison, these other technical, highly technical, highly skilled folks have also published a charter, and I think the React one is a little bit more clearly articulated. I appreciate this charter. It is, you know, it discusses the core principles and what it means to be a member and how decision-making works and how they adopt projects. [00:18:52]
-
-But, you know, it's like the membership is one paragraph and says, "What are the working roles? There's no strict definition of a working role." So it's more vague. There's less buttoned down there. Which makes sense. You know, this is an open source collective of artists who are very talented, and they're very talented in more along technical things. [00:19:16]
-
-Like whereas people coming from Meta are much more experienced in the corporate aspect of precision of language and clarity of, you know, communication and definitions in documentation like operating agreements and charters. So i-it's, I'm positioning these in reference to each other, mostly because of the coincidence of timing of them having both come out at the same time, and because I think that's a really interesting and valuable comparison to draw. [00:19:32]
-
-What does it look like when a corporation helps found a foundation versus what does it look like when artists as part of a collective do the same thing? These are contrasting ideologies creating something, and these are two examples. I think it is fascinating to look at both. [00:19:57]
-
-**Mark:** So let's say they wanna work on a, uh, React Three Fiber version 10 to be able to make use of WebGPU and make it more AI agent friendly. [00:20:12]
-
-## An [example initiative](https://github.com/pmndrs/org/blob/4bd14e20da776ff68f7555a57a01ad0b4999be92/initiatives/03-text-rendering.md)
-
-**Mark:** They'd like to work on their own design system for common look and feel and behavior. And then they also want to work on better quality text rendering in WebGL, apparently. [00:20:20]
-
-**Carl:** Okay. Cool. I appreciate that. Yeah, text rendering is really hard because it's actually insane when you start drilling into the details of how glyphs are rendered on your screen. [00:20:33]
-
-F- 'cause like for instance, if you're on a low DPI monitor, they will do all sorts of crazy sub-pixel rendering in order to make it look, you know, 20% crisper. Which ironically actually Apple gets flack for now because all of their displays are high DPI, and so they don't do those anymore, and then it's really hard to get crisp icons on OSX. [00:20:43]
-
-**Mark:** Yeah, anytime a text rendering article pops up on Hacker News, I end up reading it, 'cause there, there's some deep stuff there. [00:21:01]
-
-**Carl:** Yes. If you see text rendering or Unicode in a blog post title, like I highly recommend checking it out, because you probably take it for granted, and it's probably like insanely complicated. [00:21:08]
-
-Text rendering in WebGL is likely going to be a fascinating project that deserves its own full initiative from a, uh, collective of expert engineers with visual experience. [00:21:18]
-
-## React-alikes
-
-**Carl:** Cool. Okay, let's move on a little bit. Recently, we've been covering more and more React-alike projects. I'm gonna coin it, I'm calling it, these are React-alikes. [00:21:30]
-
-## [Octane](https://octanejs.dev/) from [Dominic Gannaway](https://bsky.app/profile/trueadm.dev/post/3mrn7yd6dzk2t)
-
-**Carl:** Yeah, we've got a new one, Octane, from Dominic Ganaway. [00:21:40]
-
-**Mark:** Yeah. Okay, so there's, there's a whole causational chain here. So Dominic started off by creating a library called Inferno back in 2014 or 2015, and the idea was React similar, but much, much faster. Whereas Preact was, say, like React, but only for the web and as small as possible. [00:21:43]
-
-So, like, there was like a Inferno-React compat library that tried to fill in some of the differences in behavior, but the whole point of Inferno was let's make something very small and very fast. Dominic joined the actual React team and was there for a few years. He left Meta. He, I believe, worked with Rich Harris in some of the Svelte 5 stuff for a while. [00:22:06]
-
-And we actually covered Dominic just in the last couple months because he recently released a- another different framework called Ripple, which tried to pull together a few different ideas, and he also released a JSX improvement language called TSRX, and then iterated on its design a couple times. So he's back, and he has another new framework called Octane, and the sales pitch for this one is very intriguing. [00:22:30]
-
-It's essentially what if we took React's syntax and pretty much almost all the semantics, but we have a compiler, and thanks to the compiler, we can eliminate the virtual DOM, we can get rid of the rules of hooks, and actually have, like, conditional hooks, and we don't need a dependency array. And so there's actually a, a very strong connecting line through all these things. [00:23:04]
-
-It's like what if React, but better in certain ways. Svelte was all compiled. TSRX is a compiler syntax layer. So there's a lot of different previous threads of work that are getting pulled together in this project. Now, I took a look at the commit history for this project. It looks like he only started working on this, like, a month or a month or and a half ago, thereabouts. [00:23:29]
-
-You can pretty s- quickly see the commit messages going from, you know, first test, try this, oops, broke, fix, whatever, to, like, very quickly building up the pieces And he's officially launched it in some sort of like, well, I don't know what the actual version number is, but like he feels it's ready enough for people to try. [00:23:58]
-
-The implementation has obviously been AI built. Here's where it gets interesting. So he just joined OpenAI to work on their own web front end. I believe he'd been using Claude To do the implementation. But in some discussion on Twitter, he said, like, "I am actually seriously pushing Octane forward because OpenAI heavily relies on React in their web stack, and we need to essentially, like, find ways to make that faster and more optimized." [00:24:22]
-
-So there's both the personal history of, "I am very familiar with React and its ecosystem, and I'm trying to push it to the next level, and now I have a day job that will fund me to do that, and also g- they get to benefit from them." One other interesting technical point out of this. So it's React syntax and almost React semantics, but it's totally different packages, which would normally mean that there's no ecosystem out of the box because there are no packages that import from Octane. [00:24:55]
-
-There are packages that import from React. So if you look at the Octane repo, there is an entire subfolder where he has programmatically built adapter layers for commonly used React libraries to make them work with Octane, ranging from component libraries to, in our case, React Redux and Redux Toolkit. [00:25:28]
-
-Essentially, look at the actual source code, create a port or thin adapter layer that imports from Octane instead, and I assume they work? So it's brand new and no one's using it yet, but this looks very genuinely fascinating on multiple levels. [00:25:51]
-
-**Carl:** The thing I'm observing on the homepage in the announcement, you know, code snippet, it looks extremely familiar, except for there's no return in this function, which is strange. [00:26:10]
-
-**Mark:** That'd be the TSRX. [00:26:22]
-
-**Carl:** Right. [00:26:23]
-
-**Mark:** In fact, n- notice if you look carefully, there is a, there's an @ symbol right before the opening curly brace. That's apparently the TSRX symbol that this just auto-returns. [00:26:24]
-
-**Carl:** See, I don't like that. Th- th- those feel like personal preference decisions that don't actually really matter. It reminds me of, like, CoffeeScript. That was so mixed. It was so perfect. They had the single versus the double arrow function, which would change the behavior of binding this. You know, a hyphen greater than did normal function binding, and equals greater than bound this automatically to the function. And people loved that so much that we pulled it into this language, and that's where we got arrow functions from. And I don't think that this at symbol justifies it to the same degree. Like, I don't think implicit return... Like, JSX had an implicit return, too. You know, it was like you add braces or you don't. [00:26:34]
-
-And so adding a new symbol to the language in order to change the behavior of something that we already have a, a variable on, I think is gonna be a distraction. I think that's a, I think that's an API failure, I would say. Like, the rest, plenty of these, you know, the rest of these all seem... It bothers me that it's so close to being familiar, while m- making a, a dramatic departure like that. Implicit return is a big difference. [00:27:18]
-
-**Mark:** It's worth noting that it does support both existing JSX syntax and the new modified TSRX syntax, so it is pick and choose. [00:27:45]
-
-**Carl:** Skeptical. It's interesting. Overall, I think this is a really good idea and a good direction to explore. I'm reacting strongly to that small note because I think this is good to explore, and that feels like a, that feels like a unintentional self-injury that will make it more difficult for this to succeed, I think is why I'm calling it out. [00:27:54]
-
-But yeah, I think that's really cool. Like, you know, boom, they got a use effect in an if. Can't do that in React. So conveniences like that seem really cool, and I'm excited to see if this works, and I hope that it doesn't introduce foot guns that make it less successful. [00:28:11]
-
-## Ryan Carniato: ["React’s staying power is because of complacency"](https://x.com/RyanCarniato/status/2072382108535066640)
-
-**Mark:** Yep. That ties into the next bit conveniently because we organized it that way. [00:28:27]
-
-I think partly in, in response to the release of Octane and some other related discussions, Ryan Carniato had a couple tweets that relate to this. So, like, you know, one of Solid's selling points has been that it mostly looks like it re- like React. It uses JSX syntax. It is JavaScript inside. Okay, the state and the effects are different, and the getters are different. [00:28:31]
-
-But, like, it looks like React much more than Angular would be. So Ryan had a couple tweets where he was commenting that, you know, at this point, he feels like the... React is commonly used largely because of complacency. It's the modern no one got fired for choosing IBM kind of a thing. [00:28:52]
-
-## Follow-up: [“Do people think FE innovation is dead? Would explain why there’s resistance to move past old React.”](https://x.com/RyanCarniato/status/2081813329681711152)
-
-**Mark:** And then he also had a, a tweet commenting on, like, do people just not feel that there's going to be any more innovation in front end? So I mean, like, he's been talking about a number of these points for a while, so, like, there's not necessarily, like, new changing details there. That, we've talked about this before, you know, AI is sort of encoding React as the default, and we're also still stuck in writing, like, 2019 era React and not even using a lot of the newer APIs. [00:29:12]
-
-**Carl:** Yeah. I do appreciate this chat shout-out. "Directly contradicts the meme of a new framework every week." Like- [00:29:47]
-
-**Mark:** Yep ... [00:29:52]
-
-**Carl:** all right. Yeah, can't have it both ways. We're literally, the JS ecosystem is criticized for all things at every moment. [00:29:53]
-
-**Mark:** I mean, why not both? We can have a new framework and nobody uses it. [00:30:01]
-
-**Carl:** Yeah. True. Entirely real. [00:30:05]
-
-**Mark:** I mean, the number of times I've seen new "React state management library" posted on r/reactjs, man. [00:30:08]
-
-**Carl:** Yeah, you know, actually, I'm gonna tie that back to what you just said of not moving past 2019 era React. People are still doing 2019 era open source announcements of, "Hey, I made a new library." [00:30:14]
-
-And like, yeah, that worked 10 years ago. I don't think it works anymore. But yeah. [00:30:26]
-
-## Parallel articles on [Solid 2.0 with async](https://www.brenelz.com/posts/learning-solid2/), and [Remix 3](https://malstrom.me/blog/learning-remix-3)
-
-**Mark:** One last little point on that note. We've talked before about both Solid 2.0 being in beta and having some new, uh, async features with the asynchroness baked directly into the signals graph. And someone put up a good, you know, w- very well-written tutorial-like post illustrating both just the overall usage and talking about some of the nuances there. [00:30:31]
-
-And then someone else explicitly ported the example app into Remix Version 3 as a intro to how you would do things with Remix 3 as well. [00:30:55]
-
-**Carl:** Cool. Nice. Love that. Anytime somebody does a direct port of one app to a different framework, especially in demos like this, I love it. I listen to a lot of economics, and there's a big thing, uh, in that field about natural experiments. Like, you know, y- some decision is made, and boom, now you have a randomized population that you can determine the outcome of that decision on. [00:31:07]
-
-This feels like this, uh, open source equivalent. Somebody made a demo app, somebody else ported it to an different framework, and now we have a very pure comparison of those two frameworks. [00:31:29]
-
-I have always thought it would be incredibly valuable if we had a, like, representative, like, "No, this is the best possible to-do app in nine different frameworks." [00:31:40]
-
-**Mark:** That was the whole to-do MVC website back in the day. [00:31:50]
-
-**Carl:** But then, like, they all suck. I feel like none of them achieved... Individually, none of them were actually good enough to wear that mantle, and so it was like, wait, actually, these are not, this is not... [00:31:54]
-
-Or, I don't know, maybe that's just a reality of the fact that you cannot actually have a single the best anything because there are nine different approaches to doing tables in React, and so you cannot make a single definitive React to-do list. But, oh, man, I... So anyway, that's why I love that somebody has ported one demo app from one framework to another. This is really good. [00:32:03]
-
-## [Cross-framework benchmark measuring reactivity](https://bsky.app/profile/nullvoxpopuli.com/post/3mrplyqcd722j)
-
-**Mark:** All right. So there, there's a long-running JS frameworks benchmark that's been out there that measures things like loading performance or swapping items in a long list, et cetera. That has been, like, the holy grail that every new framework tries to add and measure itself against. [00:32:22]
-
-NullVoxPopuli, who is part of the Ember community, has put together a sort of similar benchmark, but trying to solely measure the reactivity and re-rendering portion of it. [00:32:40]
-
-I only glanced at it. I don't fully understand the nuances and the differences of how, like, what is being measured differently than the, the JS framework benchmark. But I've, I've watched this person long enough to know they have a pretty good idea what they're talking about, and so they're trying to measure more about, like, the, the state update sequence, I think, than necessarily just, like, DOM loading time or something to that effect. [00:32:53]
-
-**Carl:** Yeah. So I mean, this table has- Incrementing render effect. So I guess that means the length of time it took to render and then produce an effect that would increment and then thereby trigger a re-render, an infinite loop, it sounds like. And it's saying React took 8.7 times longer than the baseline to just do that. [00:33:19]
-
-Which is, [00:33:38]
-
-**Mark:** which is Angular apparently. [00:33:39]
-
-**Carl:** Yes. Or the baseline there was solid, but yes, most of these Angular is the, is the benchmark. [00:33:40]
-
-Okay, this is interesting. So this, these are a lot of... This does look like a pretty solid stress test. You know, like 1,000 item list, one update on 25% of items at random. Like, that's pretty good. You know, that reminds me of like a stock ticker, you know, a table of stock results with real-time prices updating. [00:33:47]
-
-**Mark:** Interesting. I actually just dealt with that scenario in the React Redux prototype branch that I'm working on. I'm going to have to go steal some ideas from this, for this one too. [00:34:06]
-
-**Carl:** Ah, there you go. [00:34:14]
-
-Yeah. I had to render sparklines once, and do you know how many DOM nodes are in a sparkline? Do you know what happens if you render one sparkline for 30 table results? So I, yeah, the optimization that has to go into that is kinda crazy sometimes. But yeah, cool. This looks like a very good benchmark. And yeah, it is in fact saying that Angular has the best performance as rendered by time spent- [00:34:15]
-
-**Mark:** Doing the data update work, I think [00:34:38]
-
-**Carl:** the values here are not super-duper helpful, I would say. The options here are values raw, so I don't k- I, like, I don't know if that's raw on milliseconds. I don't know what unit's it in, or a score, which is also not helpful, or multiplicative relative time. So anyway, this is really interesting. I think this has potential to be very helpful. [00:34:42]
-
-Benchmarks are great, and we have a new one. [00:35:02]
-
-## Aiden Bai released [ReactBench to measure AI code quality](https://www.reactbench.com/)
-
-**Mark:** And then one other benchmark, Aiden Bai, who has been on a tear releasing various kinds of React-related analysis tools, right up my alley, put out a React bench to try to measure how well different AI models write React code. He put together some kind of a scoring metric for common mistakes and patterns, and is measuring how well they actually write good code versus bad code. I'm assuming that a fetch in a use effect is scored as bad. [00:35:04]
-
-And for the record, apparently GPT 5.6 is leading at a 53% score on the benchmark. [00:35:38]
-
-**Carl:** Cool. Interesting. I love this because this is such a, like "code crafts person" versus "fuck it, ship it" attitude. This is something I felt like I had to get over in my professional career, 'cause I jumped around employers so many times, and I was so close to the React ecosystem, it's like, "Oh, cool. [00:35:45]
-
-I know all the best practices. I know how to do it right." And then you join a company, it's like, "Oh, you're just putting a component in state? Got it." Yeah, I bet the, I bet all of these models are trained on some pretty garbage code, because most of the code in the world is complete garbage. And I think that's very clearly demonstrated by the highest score on this being 53%. [00:36:00]
-
-**Mark:** I'm gonna have to go dig into that benchmark to see what they're actually scoring things on. [00:36:20]
-
-**Carl:** The time I saw a component being put into state was during a take-home test... No, during a whiteboard interview for a new company, and I terminated the interview because I was like, "If you're doing this, then I do not wanna work here. I am so sorry." [00:36:24]
-
-## [Alex Russell blasts “state management”](https://infrequently.org/2026/07/state-management/) (and most of the React ecosystem) in favor of sync engines
-
-**Mark:** All right, so that, that ties into our next item. Alex Russell wrote a, as usual, incendiary blog post blasting the React ecosystem and its practices. And as always, it's a very well-written post, and I actually agree with and understand a lot of the points he's trying to make. I disagree with the conclusions and the way he's messaging a lot of them. [00:36:37]
-
-**Carl:** Yeah. [00:37:05]
-
-**Mark:** So his first argument is React has built-in state management, but the existence of dozens and dozens of state management libraries must mean that either React isn't a state management system or React is an insufficient state management system. And I think we would all agree it's, it is a state management system, but it's very insufficient, the fact that it's all tree-shaped. [00:37:05]
-
-So that's why we have all these external state management libs. He then goes on to, to blast the fact that there's the plethora of external state management libraries and that they're all big and complicated and basically just pub/sub event emitters. But where-- He then takes it in a very surprising direction, which is essentially that all these different state management libraries, quote, and I will paraphrase, "Don't actually manage state." [00:37:32]
-
-They store a value at a point in time. They are pub/sub and trigger updates, but they don't have any sense of what was the state over time or how do you intelligently merge in changes over time. And so he then points to sync engines and CRDTs as essentially this is what I think is the right way to manage state. [00:38:02]
-
-Of course, half his argument is all these libraries are large and then people do bad things for SSR and hydration and send down massive JSON blobs, and that leads to bad perf. But he's also primarily arguing that the entire way the React ecosystem uses the word state management is wrong, and that almost everybody would be better off using some kind of a sync engine or, or CRDT to both auto-merge changes as well as manage the time aspect of changes. [00:38:36]
-
-I hear what he's saying. I disagree on a number of levels. When I wrote my Redux versus Context post a few years ago, I actually explicitly said that to me, a state management tool is, well, essentially pub/sub. You store a value, you have a way to update it, you have a way to read it, and a way to trigger updates. All these libraries fit that category. He's the one trying to put the extra dimension of time on top of that. [00:39:12]
-
-I agree sync engines and CRDTs are useful, and that probably a lot more people ought to look at them. But I feel like saying these are a blanket solution that almost everybody should go with if, you know, assuming you're doing more than just server-side rendering, feels like it's a pretty big step. [00:39:39]
-
-And so I had a bit of a debate with him on Blue Sky about this, kind of trying to probe and get him to expand on a few of the thoughts, and he eventually did say that like, "Yeah, I'm basically saying that everyone needs to have a major mental shift in how they approach thinking about state whatsoever In applications." [00:39:59]
-
-Which I get what you're saying, and number one, that's not going to happen, and number two, I don't agree that it needs to happen. [00:40:18]
-
-**Carl:** Yeah. The, specifically that thought, that expressed thought of, "the problem here is that everyone else is thinking about this wrong and everyone needs to learn this new thing in order to do it correctly." [00:40:25]
-
-Categorically, I'm gonna say that i- if that's your defense, it's ineffective. Like, no one has, no idea has ever been adopted to that extent. Like, the best you get is something like React. React is one of the most widely successful used technologies like that, and we're discussing how badly abused it is. So like, no, you are never going to get everyone to do any particular thing in a particular manner. [00:40:39]
-
-I also empathize. Like, most state, quote-unquote, in React apps is actually cache. You know, and we've discussed how, like, most state should just be like React Query, because actually you're just caching network state. This is not your local state. [00:41:06]
-
-**Mark:** Use Nuxt, put more of it in the URL so it, it survives a page refresh. You know, use, use uncontrolled form inputs, that sort of thing. [00:41:20]
-
-**Carl:** Right. Right. And so sure, it is probably technically, from a technical perspective, it is correct that we are misusing state. State is a precisely def- defined technical term, and we are probably misusing it. We are certainly misusing it. But like, I don't know, what are you gonna do about it? [00:41:29]
-
-**Mark:** I tried to hint at this in the Blue Sky thread, and you didn't really bite on my train of thought and went in a different direction. But like, I'm a big fan of going back to how did we get here, what problems were people trying to solve? Problem A leads to problem B leads to problem C. Each stage builds a new tool to try to address the previous problems we had. [00:41:48]
-
-We went from, you know, you can't do JavaScript in the browser to you can do a bunch of JavaScript in the browser to, okay, y- we've got jQuery to make it easier to work across browsers, but you're just toggling a class in the DOM. You're hoping that the DOM is what you think it is at that point in time, otherwise it breaks. It's hard to scale all these jQuery click handlers. What if we tried using actual variables to keep track of this data? How do we start to write larger scale structures and architectures? Keeping track of all this logic's hard. What if we just declared what we want it to look like and let the framework take care of it? Okay, we're having trouble keeping that data in sync across large parts of our apps. [00:42:08]
-
-So I'm not saying that the current React or front-end ecosystems are Great. I'm not saying that they are, like, you know, absolutely the best possible theoretical way we could have landed on doing things, but I do think it's important to say, "This is how we got here, and this is the real world current state of things. What can we practically do to improve things?" [00:42:50]
-
-And so I would be very happy to have conversations with Alex about, like, "Okay, here's how the React ecosystem got here. I'm sure you know this already, but, like, this is where we are. Here are some influ- here's are some ways we could try to nudge things and push people towards mentally modeling." [00:43:20]
-
-But just starting off by saying, "React claims to have state management and it doesn't fit my definition, and therefore it's wrong, and everyone else has weighed these things on top that aren't my definition, therefore they're bad, and also bad at perf." I get that he- a little bit of this is him venting, and I think part of it was the, "I've had these discussions, let me write down my thoughts so I can refer to them." okay, cool, agreed. But it feels a little bit like shouting into the void, and it's not going to improve the situation at all. [00:43:36]
-
-**Carl:** Right. Yeah. Like, there are two little trigger phrases here that make me go, "Er." And one is the first sentence. "It is by no means the gravest linguistic crime of the React epoch, blah, blah, blah." [00:44:05]
-
-But, like, okay, so, like, literally this starts off announcing that a gripe on semantics. Th- this is framed as a linguistic crime, so it's just definition and what are we talking about. And then at some point it's like his stated resolution here is, "Devs should..." And like, boom, done. You lost me. Devs is not precisely defined. Who are you talking about? Who needs to make a change? [00:44:15]
-
-And you just say should. Like, devs should do something. Like, I don't know. Any- anytime somebody uses a general statement about a large population to say, "Everyone in this group should do X," like, you're wrong. It does not matter who you're talking about or what your idea is. [00:44:38]
-
-That is never correct. So right. I, like, I broadly agree with the perspective here as I- correctly identifying a problem. [00:44:53]
-
-**Mark:** As my mom used to say to us many times growing up, "You stated the problem, now state the solution." [00:45:02]
-
-**Carl:** Right. It's a problem. The solution is hard. [00:45:07]
-
-Like, there are lots of very smart people working very earnestly on this problem. You know, we as an industry are exploring the cutting edge of UI and what does it mean to interact, you know, human computer interaction used to be considered a field of academic research. And, like, all of us are HCI experts with no credentials and no... [00:45:09]
-
-Like, you know, there's no scientific rigor behind the experiments we do. Our company, our companies just say, like, "Oh, I think this should be-" A dropdown instead of a type ahead select. And like, you know, okay, why? Oh, well, you know, that's what the design, that's what the design spec calls for. Okay, well, why? Well, that's what the designer wrote down. Well, okay, does that, how would people interact with that? This is a human computer interaction question, and there is a body of research. [00:45:30]
-
-We are earnestly exploring all of this without the support of traditional, like, in years past, in decades past, people doing this type of exploration of a, a problem space might have the support of things like academic journals with peer review, and then ultimately, if it's published in this journal, then you can trust that it went through this review process and, you know, that by being present in its current form, it represents a consensus from this perspective. [00:45:56]
-
-And like, we don't have that. We have blog posts. Like, you know, we have vibes of popularity. So like, we're exploring a really challenging problem space without very much ability to capture the results of those explorations, and that's a very hard space to be in. But that to say, I think there's a lot of really interesting stuff happening with sync engines, Electric SQL. I've, I remember hearing about a long time ago, the... Oh, God, I can't remember some of them. There were a lot of really good sync engineed and local first- [00:46:26]
-
-**Mark:** Electric, Zero, Replicache, maybe that, maybe those are the same company. Howard Sync is out there, I think. [00:46:55]
-
-**Carl:** Yeah. Thank you for filling in the gap. I have lots of the ideology and less of the, uh, proper nouns. [00:47:02]
-
-But so yeah, yes, correct. This is a problem. People do misuse date, quote, unquote. But yeah, the way you change that is by effectively broadcasting a message that allows people to observe that their previous practices were incorrect and guides them into more correct practices. [00:47:07]
-
-**Mark:** Update the docs, add a linter, build it in by default. [00:47:27]
-
-**Carl:** Right. None of those include an angry blog post. I relate to that as someone who wishes to write angry blog posts, but I don't think it's an effective solution to the problem [00:47:30]
-
-## Aurora Scharff [rewrote the Suspense docs page to cover how it works](https://react.dev/reference/react/Suspense#what-activates-a-suspense-boundary)
-
-**Mark:** Aurora Scharf, who has been doing a lot of fantastic conference talks and blogs on using Next.js and using Suspense in the last couple years, joined Vercel and i- in a dev role, role, and has been, I guess, part of or working with the React team. [00:47:41]
-
-I think she's actually listed on the team page. And so she actually just did a significant update to the Suspense docs page to add a lot of details on what are all the cases that actually trigger a Suspense boundary, as well as some of the, the other use cases. So again, great to see a lot of the, the usage and technical details being fleshed out in the official docs. Always something I'm asking for. Yay. [00:47:56]
-
-## And a post on [RSC performance patterns](https://aurorascharff.no/posts/experimenting-with-rsc-for-performance-and-ux-in-nextjs/)
-
-**Mark:** Uh, and then she also wrote on her own blog a, a post on some various Suspense-related usage patterns that she's been playing around with. [00:48:22]
-
-Cool. [00:48:31]
-
-On the flip side, the TanStack folks have added initial server component support in its own form to TanStack Start. We've talked about that in previous months. [00:48:31]
-
-## [TanStack removed RSCs from the website](https://tanstack.com/blog/we-removed-rsc-from-tanstack-com)
-
-**Mark:** And I believe they had been using that in the actual TanStack.com website, primarily to move heavy markdown rendering to the server so you weren't shipping the, the markdown rendering logic to the client and having to wait for that to happen. And apparently they've removed that. They put up a post saying they actually pulled out the server component usage. [00:48:41]
-
-It worked, but it, they weren't getting a lot of benefit out of it, and it was actually hurting perf in some ways. And instead, they have restructured things. They've actually shipped a couple of very tiny libraries to do markdown parsing, and then separately, syntax highlighting. And so essentially going back to a somewhat more SPA-ish approach, but minimizing the amount of work done so they still get fairly fast loading times. [00:49:01]
-
-**Carl:** Nice. Let me tell you, doing syntax highlighting on a documentation site is fucking crazy. I underweighted that as a problem circa 2018, and it almost killed the entire project, because we had wanted a single API reference page constructed from dozens of markdown documents, so we could maintain it as individual docs, but have it presented in a single, large, searchable page. [00:49:26]
-
-And holy shit, we were shipping 12 megabytes of HTML across the wire because of syntax highlighting. We took syntax highlighting out, and it dropped to, like, you know, 600 kilobytes. Which is still insane, and, like, part of the reason it almost killed the project, because we just were trying to put too much docs on one webpage. [00:49:48]
-
-But- Yeah, man, like when you start highlighting individual, every individual character and wrapping it in glyphs, in a span which has a class name, and, uh, so it's, it is insane how much markup bloat gets added just by syntax highlighting. So moving that from rendered on the server, shipped to the client, into data is passed from server to client and then rendered on, on the client makes total sense to me. [00:50:05]
-
-But that's why this is the cutting edge of UI, 'cause like that sounds so obvious. Of course you just want a rendered page to come directly from the browser and oops, that rendered page is 20 times larger than it could be if you just sent the raw data needed to render it. So that's why it's so impossible to answer the question abstractly of whether or not server components are right for you, 'cause I don't know. Do you know? [00:50:32]
-
-Anyway, that's a fun project. This is a really good case study. I love it. [00:50:56]
-
-Mark, tell us, I'm giving you an opening to talk about your performance prototyping. [00:51:00]
-
-## Mark’s making progress on [some React-Redux perf prototyping](https://github.com/reduxjs/react-redux/pull/2318) and thinking about RTK 3.0
-
-**Mark:** So I'm pretty sure I alluded to this two months ago, and then I linked the draft PR last month. But for the last few years, I've been kicking around the idea that surely there is some way that I can magically use some combination of signals and proxies inside of React Redux to speed up performance updates in large scale applications. [00:51:04]
-
-So cases where you have thousands of connected components, and right now we have to run all end subscribers and selectors on every dispatched action just for each selector to grab its state and diff the result and see if it needs to update. That's fine when you've got 500 or 1,000 components. When you've got 5,000, 10,000, whatever, that's just the overhead of calling those subscribers is expensive. [00:51:26]
-
-So I played around with a couple proof of concepts in previous years. They were like, you know, like one-off, I'm gonna hack on something, and didn't get any further. So I finally came back to that , and I did a whole bunch of research on other signals libraries, proxy-using libraries. What do they do? How do they work? What are they good at? Where do they break? All very AI powered. [00:51:54]
-
-And I have a working branch that adds a useSignalSelector hook to React Redux that is using the Alien Signals library inside. And essentially what it does is it wraps your selector so that the data is in a proxy, tracks what fields got accessed, and then essentially precomputes, "Hey, this was the state that got updated. Do we think that selector actually needs to run? Nah, skip it." With the idea being that in most cases, only a relative handful of selectors actually need to rerun most of the time. So if we can just pre-skip most of them, that ends up being a performance win. [00:52:16]
-
-So I have a draft PR. It works, and it appears to be a significant performance win almost across the board. In terms of the number of updates, in terms of the total amount of scripting time that executes. It's a little bit slower in the mounting phase because it takes more work to set up the signal and the tracking time. [00:53:03]
-
-There's definitely going to be some bigger bundle size. I don't know how big, like 5 to 10K maybe. And there's also a few weird cases, like doing certain identity comparisons won't work because you're comparing the proxy reference and not something inside the proxy. [00:53:25]
-
-But it feels good enough, and I've got solid enough test coverage that I actually feel very good that, like, this is a, this is the direction that I would probably end up shipping. There's a lot of work to figure out around real-world testing and, you know, like all, all the, all the non-fun stuff around actually shipping real software. Uh, but the idea is it would be a separate set of exports. You would intentionally choose to use this. So like most apps would still have useSelector by default, but if you have a large-scale app and performance is a problem, then-- And you, you could choose to import this and make slightly different trade-offs in performance and bundle size. So I feel pretty good about that, and I'm, I'm still finding time to try to push that direction forward. [00:53:41]
-
-I'm also thinking about what a notional Redux Toolkit 3.0 would look like. Uh, a couple years ago when I shipped 2.0, and I said at the time that I was deferring touching RTK Query at all because there's some unknown number of breaking changes we would probably wanna make. I don't even know what those are. We'll just kick that can down the road. [00:54:32]
-
-Well, we've successfully kicked the can down the road almost three years at this point. Uh, the ecosystem is actually going ESM-only at this point. So presumably, if and when we do a 3.0, it would be ESM-only. Um, but I've had a bunch of things on my mind in terms of rough spots in our API and the way the internals have just evolved over time, but in a kind of haphazard way because people keep asking us to add options or capabilities, and we just added them without ever really, like, doing a coherent design upfront. And so there's, there's a bunch of pain points I've known about. There's a bunch of things I would like to improve. But they were all, you know, if, maybe, someday. [00:54:53]
-
-And so actually just in the last 48 hours, I did a whole bunch of AI-powered research tasks saying, "Here's all the things I would like to have, the properties and qualities I'd like to have in a 3.0, um, some new options I'd like to add that we can't do right now because they break with TypeScript. [00:55:38]
-
-Could we possibly come up with some kind of an API design that looks basically the same But is just different enough to clean things up and unlock the constraints. And, uh, as of last night, I've got a local prototype that Claude claims actually, like, does most of what I wanna do. So, like, noth- nothing's happening anytime soon over here, but, like, I actually have had the time and effort to do this because the AI can do the dirty work, and frankly, I didn't have the time or effort or mental capacity to do that work myself. [00:55:56]
-
-And so being able to tell it, "Here's what I want. Can you just, like, run for a while and, and come back to me and tell me if this works?" has actually made this possible, which is actually pretty cool. So nothing's, like, nothing's gonna ship anytime soon, but I actually like the direction this is going. [00:56:29]
-
-**Carl:** That's super fun. I love having problems within a box that is clearly defined enough to where AI can do it in that kind of way. A lot of the problems I've been exploring are primarily in my head, and so getting them out of my head and into a state that AI can check against is its own task, and so it's a problem. [00:56:47]
-
-**Mark:** Part of me feels a little bad that some of my contribution here was just saying the equivalent of, "I don't like that answer. Try again. Think harder." But also, like, I had to come up with, "Here's the list of constraints that I want to satisfy and the problems I want to solve, and here's the list of the prior research we did. [00:57:04]
-
-Now go think hard on these things." Like, I am actually driving the work here. [00:57:23]
-
-**Carl:** Right. Having that body of knowledge and research is critical, and is real work, and should not be discounted. [00:57:28]
-
-## [Making referential stability a type](https://www.jovidecroock.com/blog/referential-stability-types/)
-
-**Carl:** Cool. Into a couple of final details before we wrap up. This is a fun aside. Making referential stability a type. So React relies pretty heavily on referential stability, which is triple equals equality. If you have two objects or arrays that are equal to each other, it is literally the same reference. It is the same pointer. It's in this, the same part of memory. [00:57:36]
-
-And someone made a type that represents that, which is crazy. I don't understand how they did that. I saw our resident TypeScript wizard here, who is the person-- I think they're the only person who's answered any types question I've had in the last, like, decade, possibly literally. My favorite types wizard said, "Oh, cool. I tried to do this and gave up." Which I just love. Like, yeah, this is a hard problem. It's really cool. It would be really nice to have. Somebody seems to have put together a real effort at it, and I love that. It's cool. [00:57:59]
-
-**Mark:** Yeah, what they bork on both Preact and GraphQL. They're one of the Preact maintainers. [00:58:31]
-
-**Carl:** Oh, cool. I love that. Wow. Real-- I don't know. They got real chops. Yeah, core team of Preact, Urql, and- Gql.tada. So yeah, okay, they've got some real experience with wrangling complex data. That's awesome. [00:58:35]
-
-**Mark:** There's been an interesting set of different projects around trying to compile TypeScript code to true native code. [00:58:48]
-
-One that's been out there for a while is called AssemblyScript, and it's essentially a, a restricted subset of TypeScript, not full-blown true JavaScript semantics. But there's three different projects I've seen recently that are attempts to compile just straight-up TypeScript code to native code in some form. [00:58:57]
-
-## Porffor native compiler [upcoming alpha](https://honk.foo/porffor-alpha/)
-
-**Mark:** One's called Porffor, which is a... It's a single-person project. He's been posting about this for a while and doing a lot of performance optimizations on the output lately, and even making the compiler self-hosting. So he announced that Pro4 is about ready to hit alpha stage in the next few weeks. So that, that's a pretty massive technical achievement there. [00:59:17]
-
-## Perry [cross-compiles Claude Code bundle](https://www.perryts.com/en/blog/compiling-claude-code/)
-
-**Mark:** A second one called Perry that I, I don't know who's working on this, but I saw it pop up pretty recently. So they're also trying to compile TypeScript to native code, and they recently put up an article about taking the entire, like, 13-megabyte Claude code bundle that ships on disk and compiling that to native. [00:59:39]
-
-And part of it's the compilation process, and part of it is all the semantics and non-JS bits that it expects, like relying on the, the message channel, message port interface to, to send messages back and forth over a microtask. [01:00:02]
-
-## Vercel [releases scriptc native compiler](https://github.com/vercel-labs/scriptc)
-
-**Mark:** And then Vercel just announced something called ScriptC, and this is apparently in their Vercel Labs area, which is where they put all their vibe-coded projects. And, uh, boy was this one vibe-coded, I think someone on Hacker News points out that the first commit is 800,000 lines a week ago. Yeah, so who knows what the actual quality is there, but they're playing around with that. So Bunch of different people trying to solve the same problem of, it's both the publishing aspect and the runtime execution speed aspect. [01:00:17]
-
-**Carl:** Cool. Interesting. Well, I would love it if we had some more native compiled… what attention we experience, because native compiling is also the thing getting suppressed by NPM for security reasons. So yeah, what, what attention the ecosystem is under right now of moving away from compiled dependencies, but also being very hungry for the kind of performance improvements that native code is capable of. [01:00:52]
-
-**Mark:** I mean, I think in general, packages that have a native dependency used to rely on a postinstall script to check your local environment and then go manually download the binary. And at this point, most of them, like ES Build, have switched over to we're just gonna publish a se- a separate package for each possible native architecture. [01:01:21]
-
-And then the package managers have gotten smart enough to say, "Oh, well, each of those packages lists a certain native environment that it needs. Let's only actually install the one that matches your current environment." [01:01:42]
-
-**Carl:** Fair. Interesting. Complex, nuanced, subtle. [01:01:57]
-
-**Mark:** Programming. [01:02:01]
-
-**Carl:** Programming. Facts. [01:02:02]
-
-## [Goodbye, forever, probably.](https://whitep4nth3r.com/blog/goodbye-forever-probably/)
-
-**Carl:** Cool, okay. Our last link for you today is, I don't know, it's kind of sad. [01:02:04]
-
-Goodbye Forever, Probably. [01:02:09]
-
-**Mark:** It's very personal. [01:02:11]
-
-**Carl:** Very personal. This is by Salma Alam-Naylor, who goes by White Panther online. They were a very talented developer relations person for quite a while. I feel like they sprung up out of nowhere, or at least I didn't see them before they were huge. And I always thought they were very, very, just very skilled at it. [01:02:12]
-
-I thought they did a really good job of being technically at the cutting edge, while being, like, personable and entertaining. And, like, that's really hard. All three of those is really hard to do. But, so anyway, she put out this blog post called Goodbye Forever, Probably: Why I'm Leaving Developer Relations and Why I'm Not Telling You What's Next. [01:02:30]
-
-And oh man, I gotta say, a lot of this resonated with me. I've actually never had a job described as developer relations. I'm just a developer who blogged and has engaged with the community, which then later turned into the job of developer relations. This whole thing I relate to so much. Like, the number of times I've sat and seriously contemplated if I wanted to keep doing what I was doing is, like- At least five, possibly more than 10. I think about it often. [01:02:50]
-
-And I've always stuck it out. I don't know, here I am. Probably because nobody's paying me and because I have full agency over everything I do, which has its own different trade-offs. And yeah, I don't know. This is just a really good articulation of how hard it is to be publicly visible in tech and to get paid for it. [01:03:18]
-
-And I think that if you are someone who consumes tech content, this is a really good read to see what it's like on the other side of the page. [01:03:34]
-
-**Mark:** Yeah. So, um, makes a, an, a bunch of different points. A lot of it is around dev rel as a job role, that it's, it is by its nature really hard to measure. You know, how are you... Like, what metrics are you being measured on? How are you trying to contribute to the company? How do you even know if you're having success? What is your role? Are you going to conferences, writing blog posts, writing documentation, that sort of thing. [01:03:43]
-
-But specifically she also talks about being heavily overworked at multiple companies, and that contributing things. She'd spent a lot, a lot of time streaming. That was a really big part of her online persona, both in and out of the day job role. So that, that sucks up a lot of time and effort. But then also talking about AI killing teaching content. When she linked this post publicly on Blue Sky, there was a massive number of responses, and I know somewhere down in the replies, Josh Comeau said that he's looking at taking a break from building courses as well. [01:04:06]
-
-So when you put in massive amounts of time and effort to carefully craft a teaching course, and then either y- you don't get much payoff because people aren't buying it or the content essentially just ends up getting swiped Yeah. Like, why put in the time? [01:04:42]
-
-**Carl:** Yep. I was thinking about Josh and this as well, 'cause Salma says here, "I've too often overworked myself in desperate attempt to justify my existence. This has more than once caused me to suffer from health problems, including joint and nerve pain. At its worst, I couldn't even use my hands due to the pain." [01:05:00]
-
-That happened to Josh. Like, both Josh and Salma had to learn to code with their voice because of hand injuries as a result of overwork. So, like, these are two extremely successful people who have, as in pursuing their success, ground their bodies into a state of non-function. [01:05:15]
-
-So, like, that's the industry we're in. I don't know. This is what working in tech does. This is what succeeding in tech does. It's hard. One of the decisions I made in producing this podcast was I am not targeting entry level. This is not educational. This is not catch up, this is stay on the cutting edge. [01:05:34]
-
-And part of that was because of looking at the economics and realizing that, like, you know what? If you're targeting entry level people, the market you're chasing doesn't have the income. They don't have money. They're trying to get into tech. Part of the reason I have never targeted entry level humans in tech, trying to get into tech, is because I felt the economics of it was pretty fucked up. It was, you're taking money from people who aspire to get into tech to get the high salaries, and that's playing off people's desperation to succeed and do well. [01:05:51]
-
-And, like, ultimately, like sure, while the money was flowing, while it was easy to get into tech, while you could self-teach and then get a full-time job that pays you six figures, like fuck yeah, that was a great deal. That was great. That was phenomenal. It was a good part of the world to be in. [01:06:22]
-
-And now you can't. And so I think we're gonna watch a lot of educators' careers dry up because for all the good they did for the people, the market they're serving to doesn't have the money. They're trying to get the money. [01:06:35]
-
-I think we're gonna see more of this, unfortunately. It's gonna get blamed on AI, and, but there is a portion of that. People don't seek-- People are self-educating less often and relying on AI to learn more of those nuts and bolts details for them. That's true. But I do think there's another real problem of incentives. [01:06:51]
-
-You know, this reminds me too of GitHub just announced, their sponsors program, the GitHub sponsors program, you know, they waved the banner. They, you know, did the proud marketing announcement that $100 million has flowed through the program since its inception in 2018. So since 2018, 2019 I think it was actually, 'cause the number in my head is seven years. But so over the past seven years of GitHub having a sponsorship program, $100 million has flowed through it in total. [01:07:09]
-
-**Mark:** 14 million a year. [01:07:38]
-
-**Carl:** Yeah. I did 30 seconds of back of the napkin research and math, and the number I came up with for venture capital dollars that flowed just in SF over the same time period is 200 billion. [01:07:40]
-
-So while content creators are chasing their piece of $100 million, the businesses are chasing 200 times that. Thousands of times the sums of money involved. So like, I- it's, for all the commentary about, you know, who's doing what in education and content and making money, like at the end of the day, like there's a stereotype of a certain political subgroup that all just passes around the same $20. You get it, and you give it to someone else, and they give it to someone else, and they give it to someone else. [01:07:54]
-
-And like that's how I see programs like GitHub sponsors. It's not a sustainable ecosystem 'cause you're all just passing the same $20 around at the end of the day. The money's coming from somewhere else. [01:08:25]
-
-So that's my... Sorry, that's my political rant at the end of this. It's rough. It's rough out there. [01:08:36]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Mark, did you add these conferences? Should we read them? [01:08:41]
-
-**Mark:** Yeah, I put them in here, uh, because I will actually be speaking at both of them, and they're, they're also coming up. [01:08:43]
-
-So listing the two conferences off the top of my head that I know I'll be at. [01:08:49]
-
-## Sep 11: [ZurichJS](https://conf.zurichjs.com/), Switzerland
-
-**Mark:** ZurichJS in Zurich, Switzerland on September 11th. The primary organizer, Faris Aziz, great person, first year putting on the conference. I have a sense of how much time and effort he has put into trying to organize this conference. Fantastic person, ton of effort, and I'm really looking forward to that one. Great list of speakers as well. [01:08:53]
-
-## Sep 25-26: [React Alicante](https://reactalicante.es/), Spain
-
-**Mark:** And then, uh, React Alicante is in Spain September 25th and 26th, o- out on the Mediterranean coastline. This will be my third straight year speaking there. Again, wonderful conference, great community vibe, highly recommended. So if any of you happen to be in Europe or can make your way over to Europe, definitely check those out. [01:09:14]
-
-**Carl:** Heck yeah. Well, that's everything we got for you. Thank you for listening. We'll be back here on the live stage on the last Wednesday of August, or back in your podcast feed just as soon as we can. Man, maybe, hopefully I'll get it in by the end of the month in July. I've been bad at that lately. Sorry everybody. [01:09:32]
-
-Yeah, thank you so much for listening, especially to those of you who made it all the way through the end to hear this gratitude. [01:09:47]
-
-**Mark:** We started the day by saying we've got a grab bag of stuff. Yeah, we never run out of stuff to talk about. We cut out 15 items. [01:09:53]
-
-**Carl:** Yeah, we did cut out legitimately 15 items and still went 30 minutes over time. [01:10:01]
-
-Yep. That's us. Thanks so much. If there's feedback you wanna send, if there's tips you wanna give, please email them to hello@reactiflux.com. I read every email that comes through. It's a low number. It's very easy. [01:10:06]
-
-If this is a show that you get value from and wanna support, the best way to do so is by submitting a review wherever you listen and by sending this episode to your friends. Thanks so much. See you next month. [01:10:18]
diff --git a/src/transcripts/tmir-2026-08.md b/src/transcripts/tmir-2026-08.md
deleted file mode 100644
index 311c6c2..0000000
--- a/src/transcripts/tmir-2026-08.md
+++ /dev/null
@@ -1,584 +0,0 @@
----
-title: "TMiR 2026-08: Release candidate season; is that an asteroid hitting web educators?"
-date: 2026-08-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as catch up on the litany of new RCs across the ecosystem and get eyes on the asteroid hitting frontend educators."
-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:55](#new-releases)] New releases
- - [[00:01:02](#waku-10-rc)] [Waku 1.0 (RC)](https://waku.gg/blog/waku-v1-rc)
- - [[00:03:01](#preact-1100-rc1)] [Preact 11.0.0-rc.1](https://bsky.app/profile/jovidecroock.com/post/3mtxttflm5c2c)
- - [[00:03:56](#mobx-70)] [Mobx 7.0](https://github.com/mobxjs/mobx/releases/tag/mobx%407.0.0)
- - [[00:04:32](#next-163)] [Next 16.3](https://nextjs.org/blog/next-16-3)
- - [[00:06:55](#react-native-087)] [React Native 0.87](https://reactnative.dev/blog/2026/08/11/react-native-0.87)
- - [[00:06:55](#strict-typescript-api-now-default)] [Strict TypeScript API now default](https://reactnative.dev/docs/strict-typescript-api)
- - [[00:07:47](#tanstack-table-9)] [TanStack Table 9](https://tanstack.com/blog/announcing-tanstack-table-v9)
- - [[00:09:25](#tc39-composites-proposal-replaces-records-and-tuples)] [TC39 “Composites” proposal](https://github.com/tc39/proposal-composites) \~ replaces Records and Tuples)
- - [[00:10:44](#solid-20-rc)] [Solid 2.0 RC](https://www.solidjs.com/blog/solid-2-0-rc-the-big-reveal)
- - [[00:13:39](#bun-14)] [Bun 1.4](https://bun.com/blog/bun-v1.4)
- - [[00:17:18](#github-stacked-prs-in-public-preview)] [Github stacked PRs in public preview](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/)
-- [[00:21:38](#main-content)] Main Content
- - [[00:21:42](#react-core-ish)] React core-ish:
- - [[00:21:49](#new-reactdom-usebrowser-api)] [New ReactDOM \`use(browser())\` API](https://github.com/react/react/pull/37143)
- - [[00:22:47](#react-foundation-website-updated)] [React Foundation website updated](https://react.foundation/)
- - [[00:23:18](#big-nextjs-ama-in-rreactjs)] [Big Next.js AMA in /r/reactjs](https://www.reddit.com/r/nextjs/comments/1vrq0tp/were_the_nextjs_team_ask_us_anything/)
- - [[00:23:49](#react-compiler-support)] React Compiler support
- - [[00:25:21](#oxc-biome-and-bun-14-have-initial-support-as-well)] [OXC](https://oxc.rs/blog/2026-08-18-react-compiler-support) [Biome](https://github.com/biomejs/biome/releases/tag/%40biomejs%2Fbiome%402.5.8) and [Bun 1.4](https://github.com/oven-sh/bun/issues/24356#issuecomment-5276435139) have initial support as well
- - [[00:25:21](#react-compiler-linting---oxlint-speedup)] [React Compiler Linting \- Oxlint Speedup](https://blog.master.dev/react-compiler-linting-just-got-a-rust-native-speedup-in-oxlint/)
- - [[00:25:45](#the-asteroid-currently-hitting-frontend-web-development)] [The asteroid currently hitting frontend web development](https://nolanlawson.com/2026/08/23/the-asteroid-currently-hitting-frontend-web-development/)
- - [[00:32:36](#scott-tolinskis-true-cost-of-ai-coding-survey-and-video)] [Scott Tolinski’s “True Cost of AI Coding” survey and video](https://bsky.app/profile/tolin.ski/post/3mt2imugrxk2j)
- - [[00:37:51](#josh-goldberg-stepped-back-from-oss-work)] [Josh Goldberg stepped back from OSS work](https://www.joshuakgoldberg.com/blog/stepping-back-from-open-source-mostly/)
- - [[00:40:53](#software-stewardship-lab-announced-daniel-roe-et-al)] [Software Stewardship Lab announced](https://stewardshiplab.org/ideas/a-research-lab-for-open-source/) (Daniel Roe et al)
- - [[00:40:53](#tabs-spaces-hand-tools-and-seat-belts)] [Tabs, Spaces, Hand Tools, and Seat Belts](https://newsletter.powderworks.dev/p/tabs-spaces-hand-tools-and-seat-belts)
- - [[00:42:11](#humanity-in-oss)] [Humanity in OSS](https://43081j.com/2026/08/humanity-in-open-source)
- - [[00:42:11](#discussion-point-whats-this-mean-for-fe-frameworks)] Discussion point: what’s this mean for FE frameworks?
- - [[00:46:47](#cursor-switched-from-solid-to-react)] [Cursor switched from Solid to React](https://x.com/poteto/status/2089227731305464150)
- - [[00:47:46](#lovable-moved-off-next-to-tanstack-start)] [Lovable moved off Next to TanStack Start](https://lovable.dev/blog/how-we-migrated-lovable-dev-away-from-nextjs)
- - [[00:49:00](#ryan-carniatos-async-solid-articles-fetch-high-block-low-write-sync-run-async-one-graph-two-machines)] Ryan Carniato’s async Solid articles: [Fetch High Block Low](https://www.solidjs.com/blog/async-solid-fetch-high-block-low) , [Write Sync Run Async](https://www.solidjs.com/blog/async-solid-write-sync-run-async), [One Graph Two Machines](https://www.solidjs.com/blog/async-solid-one-graph-two-machines)
- - [[00:49:00](#general-unreliability-of-github-now)] [General unreliability of GitHub now](https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/)
- - [[00:49:33](#slew-of-github-competitors-tangled-cloudflare-artifacts-netlify-source-cursor-origin)] Slew of Github competitors: [Tangled](https://tangled.org/), [Cloudflare Artifacts](https://www.cloudflare.com/products/artifacts/), [Netlify Source](https://www.netlify.com/blog/netlify-source-with-netlify-cto-dana-lawson/), [Cursor Origin](https://cursor.com/changelog/origin-code-hosting)
- - [[00:55:55](#git-at-any-scale-pierre-code-storage)] [Git at Any Scale](https://cursor.com/blog/git-at-any-scale), [Pierre Code Storage](https://code.storage/)
- - [[00:55:55](#general-discussion-point-what-is-githubs-value-prop-how-is-that-changing-how-does-that-affect-us-devs)] General discussion point: what is Github’s value prop, how is that changing, how does that affect us devs?
-- [[00:57:14](#short-asideslightning-rounds)] Short asides/lightning rounds
- - [[00:57:14](#bun-14-rust-rewrite-and-a-gazillion-new-features---the-longest-changelog-ive-ever-seen)] [Bun 1.4](https://bun.com/blog/bun-v1.4) (Rust rewrite and a gazillion new features \- the longest changelog I’ve ever seen\!)
- - [[00:57:14](#github-stacked-prs-in-public-preview)] [Github stacked PRs in public preview](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/)
- - [[00:57:14](#okay-we-definitely-just-actually-did-this-at-the-beginning-)] Okay we definitely just actually did this at the beginning 🤣
- - [[00:57:16](#npmreport)] [Npm.report](https://bsky.app/profile/philippeserhal.com/post/3mttzodz6kk2x)
- - [[00:57:51](#supplier-security-questionnaire-andrew-nesbitt)] [Supplier Security Questionnaire | Andrew Nesbitt](https://nesbitt.io/2026/08/13/supplier-security-questionnaire.html)
- - [[00:58:58](#everything-i-own-owned---schlarpcom)] [Everything I own, owned \-](https://schlarp.com/posts/everything-i-own-owned/) [schlarp.com](http://schlarp.com)
- - [[01:02:33](#the-sorry-state-of-skill-distribution)] [The sorry state of Skill distribution](https://blog.trailofbits.com/2026/06/03/the-sorry-state-of-skill-distribution/)
-- [[01:03:46](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:03:48](#zurichjs-sep-11-react-alicante-sep-23-24)] ZurichJS Sep 11, React Alicante Sep 23-24
-
-# Transcript
-
-**Carl Vitullo:** Thank you so much for joining us for the August edition of This Month in React as we recap what's going on with React, React Native, and generally on the web platform. We are coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]
-
-I am Carl generally known as vcarl on the internet. I'm a staff product developer, freelance community leader, occasional entrepreneur, sometimes consultant here helping run Reactiflux. And generally just trying to keep this place valuable and pro-social for everyone around it. [00:00:13]
-
-**Mark Erikson:** And I'm Mark. My day job is at Replay, where we've built a time traveling debugger and now an automated QA platform that uses t , the time travel awesomeness to help find bugs in your app. Replay QA, please check it out. And outside of that, I am still doing an awful lot of Redux stuff [00:00:28]
-
-**Carl Vitullo:** Mm-hmm. Cool. Yeah August is often a slower month. A lot of Europe is on vacation. you know, kind of the end of summer. It's the start of school. So just often there's not as much going on. [00:00:44]
-
-## New releases
-
-We do have a lot of new releases or pre-releases, release candidates to talk about. Yeah. Let's get going. [00:00:55]
-
-First off on our new releases, we've got Waku 1.0 as a release candidate. Yeah. Waku, I don't know, I feel like I've been thinking of it and describing it as a new framework for server components, and I actually went back and checked how we've discussed it, and we've been discussing it for three years now. Like, three years is no longer a new tool, you know? But yeah, here we are at 1.0 with a release candidate. [00:01:02]
-
-**Mark Erikson:** The, and, and, and to recap Waku is a React server components framework that's been built by Daishi Kato, who i- who is also the brains behind Zeustand and Voltio and Jotai, and a slew of other state management related libraries. And the goal is to be a minimal server components framework rather than something like the, the all-encompassing Next.js [00:01:25]
-
-**Carl Vitullo:** Yeah. So cool. Love to see things get to release candidates. The fact that they've been driving towards 1.0 for so long makes me think, I don't know, makes me think this is being thoughtfully approached. Generally they, they, are very thoughtful, so that's very cool to see. [00:01:50]
-
-**Mark Erikson:** It looks like they've, they've been doing some, some navigation fine-tuning and improvements, but other than that, it's mostly like we, we think we've got it close to being final soon [00:02:06]
-
-**Carl Vitullo:** yeah, a- actually I'm gonna, I'm gonna put out a little call to audience, anyone listening. If you have, like, built something with Waku, I would actually love to hear about it. I don't think I know anyone personally who has, like, any kind of extensive experience. So, yeah, if you have any feedback, I'd love to hear about it in the \#general-tech channel or, you know, shoot me an email to hello@reactiveflux.com. Just general curiosity. [00:02:16]
-
-**Mark Erikson:** I was actually just wanting to try to look up download stats. Like, I've, I've seen it for a while. my general assumption is that it's not widely used, and certainly not in comparison to something like Next.js or React Router. [00:02:37]
-
-**Carl Vitullo:** Yeah. on that, I just checked. It has 22,000 downloads per week which compares to, you know, TanStack React Query at 60 million n. So yeah, definitely on the smaller side yeah. Okay, moving on. [00:02:48]
-
-Another release candidate. We have Pre Act 11 coming out , the main thing they highlight is it's now tree shakable which is a claim that I always take with a pretty substantial helping of salt. Just never know. I don't know. There's so many ways to break tree shaking, and we've been... libraries have been working to be more tree shakable for, like, six, seven, eight years. [00:03:01]
-
-So, you know, I don't know. It's cool. Love that. That's great. I hope it works. But yeah, Preact is generally interesting. It's cool. Last month we were talking about React alikes, and Preact is definitely the original React alike, although it is increasingly less alike as time goes on. [00:03:23]
-
-**Mark Erikson:** Yeah, although it do- it does say that the, the compat package now includes the several other React methods that have been added recently. So while the semantics have diverged somewhat over time, they are at least still making an effort to try to keep it relatively drop-in if possible. [00:03:39]
-
-MobX 7 came out. it's funny because Mo- like MobX, I think technically was, like the first releases of it were actually a few weeks before Redux came out back in 2015. So MobX has been around for a while. MobX 7 is primarily a cleanup and modernization release. They've dropped the legacy implementation and now it now requires proxies to actually track things, which has always been the default behavior. [00:03:56]
-
-Improved some bundle sizes, some tweaks to the, to the React bindings. So still out there and still being worked on [00:04:24]
-
-And on a much bigger note Next 16.3 is out, and the, the Next team talked a lot about this release. they seem to feel this is one of the bigger releases they've done in quite a while. [00:04:32]
-
-there's a bunch of dev improvements. It's supposed to build faster, less memory usage but it also has what, what they're calling instant navigations for s- better spa-like behavior as well [00:04:46]
-
-**Carl Vitullo:** Well, yeah, I saw they, they had also done a AMA on Reddit. Although I, I, I read through a fair bit of it, and it was a lot of like, "Yeah, we're working on caching. Yeah, big sites are still hard." So I don't know. It it, it was good to check in. It was cool to see... You know, it was a lot of big names giving, you know, direct answers to questions, but um, [00:04:59]
-
-**Mark Erikson:** There weren't a lot of great secrets revealed in that. [00:05:20]
-
-**Carl Vitullo:** Right. Yeah. And it's just like it's been such a consistent through line for two or three years now of like, yes, caching is hard. Local development is hard, especially if you're dealing with, like, 100,000 pages being generated. So, you know, it's just like , the challenges and the stated improvements have a certain sameness to me over time for Next. [00:05:22]
-
-I'm su- You know, it does improve. It gets better. It, it... But, like, the challenges are still pretty similar. [00:05:41]
-
-**Mark Erikson:** And, you know, may- maybe this is just a snide comment from the gallery from someone who doesn't even use Next at all, but it always... It, it's felt like a little bit of that complexity was sort of self-inflicted in a way [00:05:47]
-
-**Carl Vitullo:** Right. Yeah. I think we have another thing to talk about later on. I can't remember what this got in the doc, but Lovable put out a blog post about moving away from Next to TanStack. And yeah, you know, it's, a, a lot of it is like, oh yeah, we had performance problems, and those performance problems got resolved by moving to Vercel, but we would, would like to have more optionality f- than in our hosting. [00:06:01]
-
-So, you know, it's, the same kind of complaints, and agreed that a lot of the complexity seems kinda self-inflicted. they keep trying to fix it by adding more complexity, it feels like. You know, it's, it's a continuous additive system, and the fact that they keep adding new things to try to address the problems, and the root problems being solved don't seem to be changing, makes me suspect that the, they have gone deep into the diminishing returns of additions. [00:06:24]
-
-I think it's perhaps time to subtract. But subtracting is usually a major version bump anyway. [00:06:50]
-
-Okay. We have a new React Native version 0.87. Man, I- every time we have got a release, I miss having Mo out here because [00:06:55]
-
-he [00:07:04]
-
-**Mark Erikson:** was just about to say that [00:07:04]
-
-**Carl Vitullo:** He's got such a good breadth. Maybe I should bring him on as an analyst or something like that. But yeah, the, the big highlight here looks, to me at least, looks to be that they now have a strict TypeScript API and type definitions are being actually generated rather than hand-authored. That's a huge... Going from hand-authored types to generated types is always a massive project. It looks like this has been in the works since about point or 0.80. So, you know, that's seven, seven releases now that they've been going towards it. So, their strict TypeScript API is now the default. Not everything will be compatible, so there's an opt-out, but they've stated the intention of this - you know, the, the opt-out going away over time. [00:07:06]
-
-**Mark Erikson:** TanStack Table version nine is out, and I believe I, I, I know I'd at least pasted a couple of the prior blog posts in the tech reads and news channel. I don't remember if we actually linked them in the, in the podcast last month. Some of the updates they now have a increasingly wide range of adapters for different frameworks React, Preact, Vue, Solid, Svelte, Angular, Lit, Alpine, Ember and Octane. So pretty much anywhere you're using a framework you could use TanStack Table if you wanted to. [00:07:47]
-
-They've made a whole lot of improvements to performance. They've pulled off some very nifty JavaScript tricks to try to cut down on memory usage rewritten the internal state management, improved type safety, and as we d- were just saying, things are more tree shakable. [00:08:19]
-
-Wonderful [00:08:34]
-
-**Carl Vitullo:** Wonderful. Yeah. Tables. Man, ugh. I love that, I love that TanStack has been so persistent at trying to make a good table abstraction, but I'm gonna be honest, I settled in, like, 2017 of saying, like, "Nope. There is no table abstraction worth its weight in the bundle. I'm gonna re- write every table from scratch," which has its own trade-offs. [00:08:35]
-
-You know, it's, it, then you have to copy functionality and stuff is missing. But, like, man, just, like, seeing this release talking about how they have, like, a new architecture that, y- you know, with a record number of framework adapters, it's just like, man, tables are so much more complex than we give them credit for. [00:08:57]
-
-It's so hard to make a good table [00:09:15]
-
-**Mark Erikson:** But I thought coding was solved [00:09:17]
-
-**Carl Vitullo:** Coding is? It's completely solved. , it gets more and more solved the less closely you look at the outputs. [00:09:19]
-
-**Mark Erikson:** On a completely different note we've talked in the p- past about w- what was known as the records and tuples proposal for the JavaScript spec, which was supposed to add new data types to the language that were gonna be deeply immutable, and then you could just say, "Is this value equal to the other?" [00:09:25]
-
-And the triple equals operator would do a deep comparison. That proposal eventually got withdrawn. It's dead, it's gone, it ain't happening. So there's now a new proposal called composites, which is sort of trying to solve the same problem, but in a very different way. Reading it, it looks like you create these wrapper objects, and then the wrapper objects will do the value comparisons for you, I think. [00:09:42]
-
-So nothing immediately actionable here, but it, it is interesting to see that the design committee champions are still trying to figure out a valid solution for this problem [00:10:10]
-
-**Carl Vitullo:** Yeah, that's interesting. Looks like it's kind of I'm looking at this example in the actual spec, the stage one draft spec basically wrapping an object in a composite constructor, and then, you know, you do the same object keys and values in two, and then do a triple equals comparison, and cool, they're equal. [00:10:21]
-
-Th- so that's awesome. That's interesting. That's useful. But yeah, stage one, that's pretty far away from released [00:10:39]
-
-**Mark Erikson:** And then we've talked some previously about Solid 2.0 being on the way and having a major change in how it handles async, to how that's baked into the signals graph. They've officially hit release candidate this month. So there's the 2.0 RC announcement blog post but then there's also some deep dives that we'll touch on later that talk in more detail about how the async graph works and what that means for your code. [00:10:44]
-
-I continue to say that, like, Ryan Carniato is probably doing some of the absolute deepest research into framework development and data modeling and how to build better tools than pretty much anyone else out there. Obviously the React team put a lot of thought into server components. The Next team's putting a lot of thought into, you know, building their framework. [00:11:12]
-
-Ryan's doing, like, the bleeding edge research here [00:11:37]
-
-**Carl Vitullo:** I love that, so the async lives in the graph is for one, just a great header. I love that as a thing to unpack and understand. But it's a, I, I wanna call out this little parenthetical that says, "A computation can return a promise, parentheses, or an async iterator." And man, a, promises versus async the iterator is just so much more powerful. So being able to support those, like, you know, it's a little aside because everyone knows and uses promises and those, you know, everyone assumes those. But man, I've been using async iterators more and more lately, and they're so powerful. [00:11:41]
-
-**Mark Erikson:** I, I was, I was skimming through the third of the three explainer blog posts, and they fleshed that one out in more detail. And I think the example there shows a component that, like, looking at it, you almost wouldn't even know that it would get updates because it just works reading the data [00:12:14]
-
-**Carl Vitullo:** Yeah. I've been using them mostly because I have been doing all of my code in effect the last couple of months, and, like, or everything is a generator. And generators can be iterated upon. But yeah, like, you know, it, an async iterator is basically a promise that can resolve multiple times. [00:12:34]
-
-Like, ugh, that's incredible. I don't know. So just, like, So many times when you're modeling something as an asynchronous request, it may actually be better to model it as a stream of incoming data, and you can't do that with a promise. You cannot have an, a stream a stream of events. So i- iterators are just, like, this really magical in-between point between events, like, you know, event-driven architecture and promises. anyway, [00:12:48]
-
-**Mark Erikson:** Ben Lesh would like to have a word with you about RxJS and Observables at this point [00:13:15]
-
-**Carl Vitullo:** Ha ha. Fair enough. Yeah, super cool though. Last thing I'll say on that is definitely lend... early and prominent shout-out of async iterators, I think, lends credence to what you were saying about him being on the cutting edge of the research here. Like, yeah. Everyone else needs to catch up. go become familiar with async iterators, because it will level up your professional, capabilities. Okay, moving on. [00:13:19]
-
-Bun has had a big release [00:13:39]
-
-**Mark Erikson:** it's the single biggest change log I've ever seen. It's for what is technically a minor release, except that they also literally rewrote the entire thing from Zig to Rust with AI. Technically, there's no breaking changes, so yeah. [00:13:42]
-
-**Carl Vitullo:** Yep, they've moved out every zig. They're now on Rust. [00:14:00]
-
-**Mark Erikson:** Deep cuts [00:14:04]
-
-**Carl Vitullo:** Deep cuts. You know, you can't just put an opportunity like that in front of me. [00:14:05]
-
-Yeah, I think this is super cool. there's been a bunch of drama, a bunch of words typed and spoken about the Rust rewrite, and, like, I just, I don't find that very interesting. The most interesting thing I think is that they used Basically a fully automated workflow and the existing test suite to say, "This works. Go fix it so that it works in this language instead." and then $160,000 in tokens later, they had a Rust-authored version that is apparently good enough to release, and not only good enough to release, but good enough to build a, like, remarkable set of additional features on as part of that release. [00:14:08]
-
-So, that's fascinating. That's cool. It's a little crazy to see that much coming out. J- Jared Sumner has always been, like, kind of confusingly prolific at, in terms of, like, level of output here. So I don't know, just seeing him become AI-enabled is remarkable. [00:14:47]
-
-But I was gonna say, oh, this is the most important one, and then I'm looking at the whole list and they're all pretty wild. Like, bun.image lets you do a lot of really powerful image manipulation for the web natively, you know, just within Bun, which is great, 'cause I have previously done stuff like that with FFmpeg and Sharp, and those feel like they were written in the early 2000s, because they were. those have been around for a long time because nobody wants to rewrite them, because doing that work in a way that is performant and, like, usable is really hard. So, you know, kudos for shipping something like that. I haven't played with it myself yet. I want to. But yeah, decode, resize, rotate, encode JPEG PNG, WebP, GIF. Yeah, just, like, all of the image formats, doing resizing and basic editing kind of stuff is really, really interesting. [00:15:05]
-
-But then they've also got bun.webview, which is basically like Playwright or, you know, Cheerio or something, just natively within the standard library, which is wild and really helpful. [00:15:53]
-
-I haven't made use of this yet, but I did go through... I have a skill that I made for myself that is like, "Here's how to set up a new project here. You know, here's how to set up the linting, here's what tools to use." And I told it, "You should use bun 1.4 because the web view stuff makes it really easy to do end-to-end testing," allegedly. I still need to validate this. [00:16:04]
-
-But they've also got, like, a markdown parser and, like, a cron scheduler a pseudo terminal so you can dri... You know, they, they say, "So you can drive Bash, Vim or whatever from JavaScript without Node PTY." I've been rigging up a bunch of, like, experimental AI agent harness stuff, as part of doing that, I've been writing a lot of wrappers for Bash to be like, "I need this service to be running in the background while this server runs. it's really janky. I've had AI write a shit ton of, like, bash-compatible things that are, like, forwarding control codes, and making sure output redirection works as expected, and all those little subtle details. So again, one more thing that is, like, a pretty big load off of my mind building something if I can just ship it out to a standard library. [00:16:24]
-
-So anyway, yeah, it's a massive change log. Lots of controversial practices involved in producing it and releasing it, but mm, it's pretty cool. End result is pretty neat [00:17:07]
-
-Cool. And uh, man, another thing I've been dreaming of for years and years and years, GitHub is now doing a public preview of stacked pull requests stacked PRs. we've talked about this a couple times. I'm not sure how widely familiar, you know, the ecosystem is with stacked PRs. [00:17:18]
-
-This has been a, the way that I work intuitively for a number of years at this point, like probably dating back to 2019. Where, like, work on something, produce a finished branch, push that up, create a pull request, and then I'll ... Most of the time, the thing I just built was to enable future work. You know, it was to unblock other work that I mean to be doing. So then I'll just take that branch and continue working off of it, off a new branch, and boom, that's a stacked, you know, that's a series of stacked branches. [00:17:37]
-
-I'm, while branch A is being merged, I'm working on branch B, and then, you know, when branch A gets merged, I push up branch B for review. The, the revision here is that now you can just push them all up and mark the PRs as stacked on top of each other and it will automatically do lots of rebase and branch juggling for you. [00:18:07]
-
-Yeah, the challenge there is, okay, you stack branches up like that, like I was just describing, but then when you merge them, you know, the, the, the commit SHA changes. You know, maybe you do a squash merge. You know, maybe it's a, Anything other than a fast-forward, and you now have to do a rebase in order to have the, have the branch [00:18:29]
-
-**Mark Erikson:** Which means you have to pull down locally, you have to do the rebase, you have to, you have to do some juggling locally, push it back up, actually create things, and you have to repeat that for every time you do, you, you merge one of those PRs [00:18:46]
-
-**Carl Vitullo:** Right. And so when you've got, you know, branch A and branch B, it's not so much work. But when you've got branch A that drives branch B, that drives branch C, that drives branch D, and you've got eight people all contributing to a shared code base, like that pull, rebase, push cycle ends up being a pretty substantial amount of work. [00:18:58]
-
-So it's really cool that GitHub is now enabling this. There's a, there's a pretty closely related concept here as well called a merge queue, which is basically like an engineering practice where as part of review, you know, you don't just mer- you don't just merge when approved. You don't say like, "Okay, this, this PR is now approved for ship," whatever. "Let's merge it now." it's part of a queue, you know, it's in line. So, just as a way to manage conflicts, avoid doing rework because, you know, it... When you ha- when the work that's being merged into release is more predictably sequenced, a lot of benefits fall out of that. And stacked pull requests are a really interesting way to enable a simplified version of that for a, a larger number of people. [00:19:17]
-
-So I... This is really cool. I'm excited about it. I I'm gonna have to play with it. [00:20:06]
-
-**Mark Erikson:** mean, it's, it's, it's worth noting that on GitHub, the unit of review is the PR. Like, you can have as many commits as you want, but what you see by default is the final result on the branch, and that is what we're all very used to reviewing, and it's, it's what many other GitHub-like tools have copied. [00:20:09]
-
-But there were, there have been plenty of other code hosting and review tools Gerrit, Phabricator, and others, where the unit of review was the commit. And so another part of this usage-wise is how big of a unit am I trained to review at once? So, like, maybe you have your, you know, your 5,000-line PR, but it makes sense to review the changes in smaller chunks. [00:20:30]
-
-Well, on GitHub, it becomes difficult to go through and review, like, one commit at a time or something. So either you say, "Here's the whole thing. Looks good to me," or you have to split it into multiple PRs so that smaller chunks are more easily reviewable, but then you have to do the branch juggling dance. [00:20:57]
-
-**Carl Vitullo:** Yeah, and I guess I, I also wanna say this was, like, Jared Palmer's pet project while he was at GitHub. [00:21:17]
-
-**Mark Erikson:** For about three months [00:21:23]
-
-**Carl Vitullo:** For the... Right. So it appears that Jared Palmer legitimately joined GitHub specifically to ship this, got it into a state where it [00:21:24]
-
-**Mark Erikson:** It's the meme. It's the [00:21:31]
-
-**Carl Vitullo:** Yeah. [00:21:33]
-
-Right. And then left, and then went... Yeah, so anyway, that's, that's pretty funny. Uh. [00:21:33]
-
-## Main Content
-
-Okay. Into our main content yeah. [00:21:38]
-
-Yeah. [00:21:41]
-
-Right [00:21:42]
-
-**Mark Erikson:** Right so a few smaller items from React core news-ish stuff this month. [00:21:42]
-
-There's a new API that's coming out for React DOM. It's a function called Browser, which is intended to be passed to the increasingly expanding use method. So it's use. The idea is it re- the return value of use will differ depending on whether you're calling this on the server or on the client. [00:21:49]
-
-So if you call it on... If you have a component and it's getting rendered on the server, in a server component or whatever React will see that and essentially leave a hole in your component output. And then it knows that when this run, runs again on the client, then it will fill in. pretty much every code base at this point has some form of a do this logic only on the client util or, or something along those lines. [00:22:15]
-
-This is essentially building that functionality directly into React DOM itself [00:22:41]
-
-Let's see. [00:22:47]
-
-We, we... I believe I mentioned last month that, that there were updates on the way for the React Foundation website, and then they were also talking about governance-related things. They have shipped an update to the website, so it at least looks less AI vibe coded at this point. still Looking and waiting for more public details on what the foundation is going to do long term, but again, you know, bits of activity. [00:22:47]
-
-Things presumably are churning away behind the scenes. [00:23:15]
-
-As, as we mentioned earlier, the Next team did an AMA over on Reddit. There's some discussion. Some of it's the obligatory complaining about Next.js not having proper middleware and things like that. I skimmed it. Honestly, the biggest thing I got out of it is that React 19.3 is probably coming in the near future, and that it should solidify the fragment ref and view transition features which have been in Canary for a few months. [00:23:18]
-
-So good to know that's on the way [00:23:47]
-
-And then the other interesting bit was that the OXC team has shipped their official support for React Compiler built into Oxlint, et cetera. And, and this is interesting for multiple reasons. So React Compiler itself was originally written in TypeScript and also required a Babel plugin. And so it existed, but we've spent all these years converting our build tool chains to Rust. [00:23:49]
-
-Babel is slower. People saw that build times got slow again, and like, "We don't like this. Can you just do it in Rust?" The React team did an AI-assisted port of the compiler logic from TypeScript to Rust. That is in the React repo. But then the question is: how will that integrate with other build tools? So other teams, Biome, OXC, Bun, et cetera, have been taking the Rust code and trying to figure out the best way to integrate it, and the OXC team in particular has actually pushed ahead in a lot of ways. [00:24:14]
-
-They tried to integrate it once, and then they decided that it made their binaries too big, and they didn't wanna ship that to everybody, including people who don't use React at all. So apparently they went back to the drawing board. They found some ways to optimize the code, shrink the bundle size, make it semi-optional maybe. [00:24:51]
-
-And apparently now the both the build performance and the binary size are good enough that they felt ready to actually ship it. So that, that support is now baked in at this point. [00:25:09]
-
-And Biome is trying to do some integration as well. Bun 1.4 is supposed to have React Compiler support. So slowly but surely, these pieces are all coming out in the ecosystem in a much faster way, and so hopefully that means that more projects will be actually be adopting the compiler over time and thus seeing whatever runtime performance benefits you get from using it [00:25:21]
-
-**Carl Vitullo:** Should we go to Asteroid? [00:25:45]
-
-**Mark Erikson:** Yes, the asteroid not astro, asteroid [00:25:46]
-
-**Carl Vitullo:** Yeah. Yeah. Nolan Lawson, who is is somebody who's been, like, individually fairly influential on me as a developer I just first encountered him 10, like, more, 15 years ago when I was still in college. So it's cool to see his name still around. he put out a great blog post called The Asteroid Currently Hitting Front-End Web Development. , basically the same thing I actually said on, at the end of our last episode about impacts of AI on educators, on content creators, especially in the front-end engineering space. And basically, you know, he's highlighting that He says, "A lot of the educators I admire in the front-end web space seem to be either bowing out or dialing back their efforts." [00:25:50]
-
-And like, yeah, Axel Rauschmeyer, hugely influential blogger about the standards process and, you know, JavaScript itself as a language. Salma Alam N- Naylor, well, Selma and Josh we talked about specifically at the end of the last episode. And, and then he calls out, too, that, like, Kenzie Dodds, Addy Osmani, Rachel Neighbors, Lydia Hallie have all moved more from front-end development into, like, AI agents software development. Which I, which I think is fair. You know, I don't, I, I, I think comparing people stepping back versus staying on the cutting edge. for a long time front-end was the cutting edge, and then it was, like, React Native and where are we gonna put React next? And so now it's not as much that. Now it's AI and how do you build stuff? How do you build a software factory? [00:26:28]
-
-**Mark Erikson:** , even that is a theme we've touched on for a while. I mean, swyx used to be part of the React ecosystem space. He was a mod on the, you know, in the subreddit, did a lot of talks, and then, then he got involved with Svelte, and then he pivoted to running AI conferences and, and podcasts. [00:27:11]
-
-, we've even talked about, like, the energy at React conferences seems to be down, whereas the AI conferences have all the energy. So, like, there, [00:27:27]
-
-**Carl Vitullo:** Right [00:27:38]
-
-**Mark Erikson:** like, a lot of trend here [00:27:38]
-
-**Carl Vitullo:** . This post from Nolan Lawson, he talks about the future of front end. And I'm just gonna read a couple of, like, high-level points he makes. The front end is less risky to just hand to an agent. Developer experience is becoming less critical overall. Standards will catch up. I think this is interesting. [00:27:41]
-
-I, these rhyme with points of contention that I've seen in the industry for essentially my entire career. Like, you know, [00:27:55]
-
-is front end... Right. Front end is easy, and developer experience isn't worth the time investment. , I wanna call this out. He says, under developer experience becoming less critical, "The agents know React. For better or worse, React is heavily over-represented in the training weights." And again, like, something we talked about last episode, I believe, was Aiden Bai put together a benchmark of not just React, can it make something functional, but how well does it actually execute React best practices across different models? [00:28:02]
-
-**Mark Erikson:** they know what React code looks like. They don't really know how to write good React code [00:28:32]
-
-**Carl Vitullo:** Right. So [00:28:38]
-
-**Mark Erikson:** They know what bad React code looks like [00:28:40]
-
-**Carl Vitullo:** Yes, bad React code is heavily overrepresented in the training set, but, I used to, I used to work, when, when I was more earnestly working full time, I went to a lot of different companies for, you know, a year, six months, a year and a half, and the reason I was able to be very successful at that is because every company used the same set of very bad practices that represented a fundamental misunderstanding of the advantages that React offered. [00:28:42]
-
-And so it's like, cool, I understand those, let me come in and fix this incrementally one thing at a time, and the improvements are so mind-blowing to you as somebody who doesn't understand the tools you're using, that, you know, great, cool, great, awesome. Who... Lovely performance reviews, yada, yada. [00:29:07]
-
-I both understand where he's coming from on this. there is less risk in f- the client versus the server. If you fuck up data on the client, like, you just, you know, pull f- from scratch from the back end. But if you screw it up on the back end, like, oops, data loss. Oops, you know, security vulnerability. So it, you know, these are both true, and I think, like, fundamentally missing some kind of point. So I don't know, it talks about the future of front end and front-end education. I think there's still a lot of room for human cognition as steering input to guide agents that, you know, they may be individually capable of achieving, you know, X, Y, Z, maybe even better than I can, but they need to be told what the constraints are in a w- in a manner that is, you know, y- helpful to guiding them to waste less. You know, like, rework is so costly that if you, if I, as the intelligent human with experience using these tools and knowing, you know, what has downstream effects six months, a year, five years from now, then yeah, I think there's still a lot of room for expertise meaningfully [00:29:23]
-
-**Mark Erikson:** when I wrote my own AI journey emotional blog post back in April, one of the points I made was that I did... Once I got past, "I will never use this," and actually started using these tools, I've been able to use them effectively because I already know how to write code. I already understand what good code looks like. [00:30:39]
-
-I know how I want to do things, and now I'm just trying to speed up the process of doing the work that I already intended to do. or using the tools to give me a range of options, and then I make the decision based on which one actually feels like it fit, fits the best. but then that brings up all the, and all the usual questions of, well, how do you get all this experience? [00:31:01]
-
-Well, I did it for 20-plus years by hand, and now I'm reaping the benefits of that. And how do others gain that experience in today's world? I don't know. I'm not in that position at this [00:31:23]
-
-**Carl Vitullo:** Yeah. You know what? I think they learn it, I think they learn it essentially the same way that I did. Fucking trial and error. Like, I have a, I have an associate's degree. I have nev- you know, I've taken one year of computer science. Like, I was not taught these things. I learned them largely through trial and error. [00:31:35]
-
-You know, you join a company, you ship some code, you have to deal with the consequences of the code that you shipped. I, there's no substitute for experience, and it is easier than ever to go from non-functional to functional. And once you have to maintain a functional thing and keep it operating and expand on it and improve upon it, I feel like the lessons aren't that different. [00:31:51]
-
-I don't know. At the end of the day, I think it's, it comes down to how well can you ask questions of this... You know, we're all gonna be managers in the, in this AI world, [00:32:14]
-
-**Mark Erikson:** So a lot of the discussion around this whole direction has then been, yeah, like, what... where is the place for us? What does that mean for our careers? How do we feel about this? [00:32:23]
-
-So Scott Tolinski uh, one of the hosts of the Syntax.fm podcast with Wes Bos did some work within the last few weeks that really touches on, on this. [00:32:37]
-
-Scott had his own AI psychosis phase some months ago. And coming out of it, he's like, "Okay, This has affected how I feel, like, literally on a daily basis. I wonder how other devs have been going through this as well." And so he put up a survey online. Has been trying to gather as many respondents as possible. [00:32:45]
-
-I think he's up to 7 or 8,000 respondents at this point. So you know, a f- fairly decent sample size. [00:33:07]
-
-And it, it's, it's relatively short, but it asks questions like do you feel like your skills are eroding based on your AI usage? How many times have you found yourself staying up later than you intended because just one m- just one more prompt, one more prompt, [00:33:13]
-
-Or, you know, sort of the slot machine effect of just asking it to do, you know, some more work. So he gathered up the results, and I believe his wife is actually, like a, a psychologist with, with a, with a doctorate. And so he was having her work through him on some of the statistics and the analysis on this. [00:33:30]
-
-And he also was reaching out and doing some video interviews with a number of people to follow up and get some ac- you know, some more direct, you know, r- real-life anecdotes and data. So I actually did a video with interview with him, and we, we had a good discussion. He pulled all this together into a half-an-hour YouTube video where he talks about his experience, his research, and brings in video clips of a bunch of people including myself. [00:33:50]
-
-It's a really good video. I, I strongly encourage people to take the time to read through this. The end, like, the end bit of it is basically take care of your mental health, folks. Like, don't let this, rapid pace change in the world get to you. Take care of your mental health, establish your boundaries, and then go from there. [00:34:17]
-
-**Carl Vitullo:** Yeah. Yeah. Very important. I think at the intersection of that, take care of yourself, understand your boundaries, hold yourself to your boundaries, which is hard. [00:34:37]
-
-staying within them for a long period of time is really hard. [00:34:47]
-
-**Mark Erikson:** I know what the right things are and I am not the world's best poster child for sticking with them. Do as I say, not, not as I do [00:34:52]
-
-**Carl Vitullo:** Right, right. and I wanna connect that back to this, you know, asteroid hitting front-end web development and educators falling off and no longer producing output at the same level that they were in the past A lot of my, I think a lot of my energy in producing this podcast, in running Reactiflux, in contributing to the ecosystem has been, especially the last five years, has been very much rooted around what can I do to not burn out? So, you know, it's like the reason this is a once a month podcast instead of weekly or daily or whatever is 'cause I would burn out if I did anything else. Like this is enough effort for me and this is already once a month for an hour plus prep is already disruptive enough to the other things I want to do in my life that I can't do anything more than this. [00:34:59]
-
-**Mark Erikson:** Ditto [00:35:49]
-
-**Carl Vitullo:** Okay, we've achieved some small level of success. We have several hundred people listening every month, which is lovely and great, but like, you know, on the grand scheme of things like this is never gonna pay my bills. This is never gonna be a full-time career. And like, you know, whatever, that's fine. [00:35:50]
-
-That's okay. That's okay because that's what I, I built it not to be that. I built it not to take over my life. I built it to let me do it at my leisure, at my convenience. And I don't know, you know, in some ways, like, a personal life philosophy of mine is to like be inexorable, just like, th- just be unstoppable. Like you don't need to be the fastest, you don't need to be the smartest, the most resilient, but like just keep going. [00:36:03]
-
-If you, if you're going in a direction, just steady advances incrementally. And so like, you know, I'm not, I, I'm never gonna have hundreds of thousands of social media followers and you know, tens of thousands of hours listened across multiple platforms. But like, you know what? When the other people burn out, here we are. know, other people do these content projects for a year, two years, three years, but like Reactiflux, we've been around more than 10 years now and I've been helping run it for a lot of that, most of that. I've been a moderator or an admin for 10 years now, 10 and a half years now. So I don't know. That's, I think that's, that is an attitude that is not widely rewarded in tech, in tech generally. You could say some other things about different subdivisions there, but I think it's, I don't know. I think it's important for mental health and pers- physical health as well 'cause burnout is not just a mental health issue. [00:36:33]
-
-You can have serious physical health consequences from that. Anyway, yeah, I don't know. I'm gonna trail off there. [00:37:28]
-
-**Mark Erikson:** Yeah. So here's sort of the flip side of that keep persisting thing. I mean, we, we listed a number of people who have made the decision to step back because they're feeling burned out or feel like the, you know, the audience and the career that they'd built just no longer exists at this point. [00:37:34]
-
-So Josh Goldberg, who has been a very prolific open source contributor working across multiple different linting and build tools recently just announced that he's stepping back completely from open source maintenance. [00:37:51]
-
-I actually talked- had talked to him live just before he posted this, and he, he told me this was where he was headed. Some of it is life changes. He's, he's had a number of stuff going on in his personal life that have taken up time and energy. Some of it is getting very frustrated with AI PR spam [00:38:05]
-
-and, you know, just not wanting to deal with yet another seemingly plausible bug report that turns out to be complete nonsense. [00:38:23]
-
-And some of it is just a desire to literally go out and touch grass and do other things with his life [00:38:32]
-
-at this point. [00:38:40]
-
-that's also an entirely valid set of decisions, and he said he's ha- essentially handed over all of his projects or they're in maintenance mode at this point. [00:38:41]
-
-He's still working. I believe he's at Sentry at this point, but he's stopping open source work. And so, like, I'm happy for him in the sense that I want... He's a good- he's a great person, and I want him to do what's best for his life. It's a little sad in seeing someone who has been involved, you know, saying, "That's, that's it for this phase of my life," and stepping away [00:38:51]
-
-**Carl Vitullo:** Right. It, it's sad to me because he's a friend. I consider him a friend. He stayed at my house once because he was passing through and needed a place to crash. [00:39:15]
-
-I... He's a lovely person [00:39:24]
-
-He's so kind and so generous, and so purely wants to do good that it sucks. it makes me genuinely sad to see him take a s- need to take a step back because he can't do it all, you know? [00:39:25]
-
-Because he, nobody can do that all. It's too much. You can't work full-time and have a engaging, rewarding personal life and do these side projects, and also organize a conference, 'cause he was doing that, too. So yeah [00:39:40]
-
-**Mark Erikson:** I mean, I've, I've had my own thoughts. Like, I, I have no plans to stop open source work anytime soon. In fact, I've actually got uh, like I said, we said last month, I'm trying to push through a big new React Redux feature, and I've got a bunch of plans for what will hopefully turn into our next set of major version releases. [00:39:52]
-
-But you know, purely mathematically, the day will come when I no longer do Redux-y things. It might be 'cause I'm 83 years old and no longer have the mental capability to do it. And, but, like, mathematically I'm gonna stop eventually. It's just a question of when and why, and what am I doing with my life? [00:40:10]
-
-**Carl Vitullo:** Yeah Tough. I don't know. I've wrestled with that a lot. What am I doing with my life? What is my life? Who am I? What do I care about? What are my values? [00:40:34]
-
-**Mark Erikson:** Why are any of us here? Why are any of us Why [00:40:42]
-
-on that note I'll, I'll toss out three other links. I'm not sure there's necessarily a lot of discussion, but they, they fit very neatly under this category. [00:40:46]
-
-a group calling themselves the Software Stewardship Lab is trained to help improve open source sustainability. And ironically, when I was on vacation in Scotland earlier this year, I actually happened to talk with some of the people who apparently were... [00:40:53]
-
-They must have been doing some of the planning for this at the time. Daniel Roe, who's the leader of Nuxt, you know, the, the next equivalent for, the Vue ecosystem is involved. Vlad Harbuz, Andrew Nesbitt, who's been doing massive research on packaging ecosystems uh, Matias Capelletto, who's involved with the, the npmx project, Miranda Heath, who's been doing research on burnout. [00:41:09]
-
-A lot of, again, very, very good people who care deeply about open source and community as a concept are involved in this. I'm a little unclear on how they're hoping to improve things, but I highly, highly approve of the concept, and these seem like the right kind of people to be doing thinking and research I read a really, really long blog post, my favorite kind that covers a number of things related to AI migrations and software craftsmanship. It's long enough that I don't remember what all was in here, but it was a really, really g- good post and worth taking a look at. [00:41:33]
-
-And then James Garbutt, who's involved with the E18E Ecosystem Cleanup Initiative, wrote his own post on humanity in open source, and some of his points are that, yeah, we're, we're getting swarmed with AI PRs and issues. [00:42:11]
-
-Open source is about more than just... Like, the construct of open source is about more than just licenses and releases, et cetera. It's about the communities that are getting involved, and it would... And then there's also the questions of, you know, how do we keep building those communities, especially if people keep getting burned out? [00:42:28]
-
-So he has s- several different thoughts on trying to manage that [00:42:53]
-
-**Carl Vitullo:** Yeah. Okay, at the mention of communities, I wanna jump in. - we're talking about, communities maintaining shared infrastructure is how I'm gonna frame this, you know, humanity and open source. Do you know how many different communities are maintaining the shared infrastructure that support every aspect of your basic life? [00:42:56]
-
-**Mark Erikson:** Where's [00:43:15]
-
-**Carl Vitullo:** I think... [00:43:16]
-
-Yeah, right, but y- right, okay, so there's XKCD of all the stacked, you know, boxes [00:43:17]
-
-with, like, that fragile thing. But, you know, like, you know what? Like, how do your lights stay on? How do you get hot water? You know? How do you stay cool? How do you get groceries? Like, each of these is the output of a shared infrastructure being maintained by a community. You know? Okay, the s- the, the, the power that might be, the community there might be a regional monopoly as dictated by, you know, legislative priorities. but, like, th- th- I guess that's how I wanna frame this. Like, I think we are exceeding the type of human scale. You know, this is like the Industrial Revolution of software. Like, it used to be all handmade parts that were not interchangeable. Th- and we've been moving more and more towards interchangeable, fully automated whatever. [00:43:21]
-
-And, like, yeah, for better and for worse. Like, if you take that lens of handmade versus scaled, you can apply that to almost anything. Like, I occasionally like to bake bread. I also buy store-bought bread because it keeps longer, and it keeps longer because it's a fully automated system that has been refined for 150 years because people need bread, and not everyone has the available time and resources to bake it. So, you know, like I, I love to think about water, water is a crazy, when you actually look into the, like, societal level engineering projects. [00:44:08]
-
-So like control of the flow of water is a shocking percentage of human effort over the millennia. Like not, keeping it within the tolerable bands. You have to have enough to keep everyone who lives there alive, but not so much that it washes their houses away. And like managing that is a preposterously large project, and when's the last time you thought about it? [00:44:49]
-
-So like that's... I think open source is now moving more in that direction, where it had been very human scale of like, I know the 15 people who are making all of, you know, making this whole thing work. And now we're starting to go into a place where there is enough automation in generating and consuming code that that scale of investment no longer really works. Another useful lens here is like Etsy versus Walmart. Like I can go to Etsy and I can buy picture frames or, you know, a pin or a sticker or a shirt, and that was probably handmade by somebody, hand designed by somebody, and I'm gonna pay a little premium for that. But like most people don't actually care that much about where their shirts come from. They don't care about the manufacturing process of, you know, how this, was this picture frame made with sustainably grown wood, or is it a composite made out of sawdust and epoxy? Like most people don't care. It looks good on the wall. [00:45:13]
-
-So that, to me, is a really fundamental lens here. It's people who are used to being very close to the production grating against the automation of what they have taken great pains to do well. And neither side is wrong. Both of them are fully correct. [00:46:14]
-
-**Mark Erikson:** So partly angling off that, and this was actually in what passes as a script over here. Two more stories of migration that circle back through the AI aspect, the frameworks aspect. [00:46:33]
-
-Cursor just got done migrating their entire system from Solid to React, and they talked some about it, and one of the things they said is, "Well, the agents are more used to writing React. [00:46:47]
-
-They actually make a lot of mistakes, but at least we're familiar with those mistakes, and they're obvious to us now, and we can control and correct for those. Whereas with Solid, they just sort of got confused most of the time." so that... There was, there was a lot of debate back and forth on Twitter. A, a lot of quote tweets and, and some discussion from the Solid team saying you also didn't ever really give us much of a chance, but yeah. So there's, there's its own drama there. [00:47:01]
-
-**Carl Vitullo:** Yeah. Certainly no, certainly no part of this was because Lauren used to be on the React team. There's probably no bias there. Yeah. [00:47:29]
-
-This is such a shady tweet. Like, "Much love to the Solid team and congrats on launching Solid 2. We just finished moving away from you." Like, that's some hella shade to throw. [00:47:37]
-
-**Mark Erikson:** And then we mentioned earlier, Lovable talked about having migrated I think their own actual system away from Next.js and over to TanStack Start. And I, I, I know they switched their project setup from whatever the previous was to TanStack Start. I believe this is separately saying they switched their own infrastructure to be built on TanStack Start instead. [00:47:46]
-
-I love a good migration post. This goes into a lot of details, and it does say that they did some of that work with AI tooling further down once they had identified some of the constraints [00:48:11]
-
-we could have spent a bunch of time on this. I think we've probably gotten far enough. We probably shouldn't spend time on this, but sort, sort of a meta point and, and one of the things we keep circling on is you can switch very easily from tool A to tool B or language A to language B at this point. [00:48:21]
-
-You say, "Here we've got this thing. This thing works. Make it work in some other tool set entirely," and if you've got enough tests, enough tokens, enough time, then it pops out on the other end. [00:48:38]
-
-Having said that, I do actually want to bring up one more set of framework-y things because I think this is fascinating reading as a person who spends too much time caring about frameworks. [00:48:50]
-
-I mentioned earlier that Ryan Carniato and the Solid team have been doing a bunch of bleeding edge research especially into how the entire signals data graph can encode the asynchronous of the data in there instead of needing to, like, separately keep track of promises or, you know, loading flags, et cetera. [00:49:00]
-
-And so they've put up a, a series of three posts that go into the details on what that means in practice when you use Solid 2. I thought they were fascinating reading myself. [00:49:21]
-
-**Carl Vitullo:** Our last main topic before we go into what are allegedly short asides, lightning round. The general unreliability of GitHub lately lately. they Put out a blog post talking about the outage on August 17th. And like, yeah, you know what? Like, they're not... [00:49:33]
-
-They're barely holding one nine of availability lately That ties very closely to the rise of agentic coding and the sheer volume of commits that are being pushed, [00:49:47]
-
-**Mark Erikson:** they've published a number of stats in the last several months about how the number of PRs and commits and API calls has just absolutely gone through the roof in the last few years. [00:49:57]
-
-**Carl Vitullo:** Like 10X, 20X [00:50:08]
-
-**Mark Erikson:** a large multiplier [00:50:10]
-
-**Carl Vitullo:** Yeah, fair. Yeah. there are now more and more people throwing out GitHub competitors, which I think is interesting. There's Cloudflare, Netlify, Cursor. [00:50:12]
-
-oh, wow from chat, "GitHub reported one commit per millisecond." [00:50:22]
-
-**Mark Erikson:** initially read that as one commit per, from Microsoft. I'm [00:50:25]
-
-**Carl Vitullo:** Yeah, me too. All it takes, one commit for Microsoft to take down the system. The commits are coming from inside the house. Okay, sorry. [00:50:28]
-
-But yeah, so there's now... there's a combination of factors that are making people start to put out GitHub competitors. Okay, obviously we're in the middle of discussing the significant outages that GitHub has been having for a number of months now. But there's also, we don't know how to work anymore. We don't know what the best way to... Uh, Well, okay, we never knew what the best way to work is, but we had at least settled on pretty widely adopted patterns, which GitHub, you know, codified and then led in a [00:50:36]
-
-**Mark Erikson:** You have, you, you have a trunk, you make a feature branch, you work for a few hours or a day, you push a PR, a teammate reviews it, CI goes green, and you ship it [00:51:05]
-
-**Carl Vitullo:** Right. there's a lot of assumptions about how you use Git in that workflow. And so, like, you can use Git in different ways if you were to so choose. [00:51:15]
-
-Uh, I actually re- [00:51:24]
-
-**Mark Erikson:** was a thing back in the day [00:51:24]
-
-**Carl Vitullo:** Yeah, and I actually have moved uh, one of my projects more towards a Git flow type thing, where you have a periodic release, and you cut an RC, and you do user acceptance testing on the uh, on the release candidate, and you ship that artifact. [00:51:26]
-
-There's an explosion in exploration of new ways to work with code and new ways to collaborate with others around code that I think is driving some of this curiosity to try alternatives. I'm personally very curious about trying to self-host some infrastructure here. [00:51:40]
-
-I don't know. Maybe this is me b- spending five years independent and not working with companies, but like, man, there's just much unexplored territory now [00:51:58]
-
-**Mark Erikson:** there was a really good discussion over in swyx's Discord just a couple days ago with a different but similar theme. Some of it was the debate over, "Wait, you guys are still reading code?" but then that also ties into, "Wait, you guys are st- like, like who's using an actual IDE to do their work?" [00:52:08]
-
-Versus this new breed of agentic swarm management tools, where what really matters is you have a chat screen and a dashboard of all the agents and the work trees in flight, and maybe it's got like an integrated diff viewer, but what really matters is, like, the task management rather than, like, I need to have the code open so I can type. [00:52:30]
-
-**Carl Vitullo:** Right. the way I have been working is very acceptance-driven of just, like, does this achieve the goal I set out when I started this project? And I don't really review the PRs as much. I do quick , sanity checks of, like, you know, is this 15,000 lines when it could be 2,000 lines? But, you know, like, very high level. I'm not really understanding the... You know, I, if I wanna understand something about how the code works or how the code is structured, like, I ask the agent, 'cause the agent wrote it. yeah, I don't know. [00:52:55]
-
-Dashboards and such, I think is... that feels not quite right to me. That feels like project manager kind of capacity more than, like... I don't know. These, like, task tracking is different from did you build the right thing? What's underway is different from are we working on the right things? So, just thinking about it through the lenses of different professional titles, like software engineer versus, like, manager versus, like, director of product or project manager, program manager. [00:53:25]
-
-Like, all of those needs of establishing what the space we're working in is, what other solutions have other people tried? What, what are we ruling out? What is the actual need we're solving? Are we achieving that need? [00:53:54]
-
-Yeah, that's all the same. Now that code is no longer the primary thing that I want to read in order to understand the, the answers to those questions. Yeah. I don't, I think we're, I think we gotta figure it out, kind of from scratch. [00:54:11]
-
-**Mark Erikson:** So point is, there's an awful lot of experimentation going on in how we as developers are, what tools we're using to do the work and what the workflows look like. And so then between the massive increase in commit scales and, you know, the, the changes in those workflows, we're seeing a variety of different hosting tools come out that, you know, either just, hey, you can have your Git hosting not on GitHub or, but also po- possibly make it more agentic friendly, [00:54:23]
-
-**Carl Vitullo:** Yeah. [00:54:59]
-
-**Mark Erikson:** whatever that means [00:54:59]
-
-**Carl Vitullo:** Interesting. I'm, I'm exploring some stuff around this area as well. I'm going to be coming at it from a very different direction from all of these places, which are still fundamentally anchored around software as a service published on the cloud which I think is limiting. But yeah. [00:55:01]
-
-Two that I wanna shout out. Tangled.org is pretty interesting. They're doing... They're trying to do essentially GitHub on at protocol. [00:55:16]
-
-**Mark Erikson:** no [00:55:24]
-
-**Carl Vitullo:** So it's, you know, it... That's cool. It's a decentralized social media platform, and they're putting basically the social components of GitHub onto that decentralized protocol. So awesome. That's awesome. That's very cool. [00:55:24]
-
-Cloudflare is also doing a, yeah, versioned storage that speaks Git, is their headline. We had some others in the notes from Cursor and Netlify, but I wanna be honest, I don't, I don't feel like either of those are in the right place to successfully execute on that vision. [00:55:38]
-
-**Mark Erikson:** Mm-hmm. I will say that this article on scaling Git was fascinating. there's been a lot of efforts over the years to make Git scale. Microsoft has done a lot of work on, like, virtual file systems and improving algorithms inside of literally the Git implementation itself. This one's more focused on the hosting side of things [00:55:55]
-
-**Carl Vitullo:** Yeah. And okay, this is why I'm skeptical of software as a service cloud-based, 'cause, like, that's the problem. Like, Git is a decentralized system, you know? You can just add a remote, and it... Like, you push. It's exactly the same. yeah, if you're dealing with pushes from literally the entire world, that's really hard to optimize. But, like, I dream, I hope, I wish that at some point we will get to a state where more people can have, you know, world accessible, safe compute that they control. [00:56:16]
-
-Like, I have a network accessible storage here. It technically can run a Git server. Like, there's no reason I couldn't use that as my primary store, and then, like, make that available to some other tooling that is aware of that storage and does collaborative features on top. When you distribute stuff like that, you don't have to worry about load at any individual site anywhere near as much, which is what this Git any, any scale kind of post is talking about. Anyway. [00:56:48]
-
-## Short asides/lightning rounds
-
-some lightning round whatever. [00:57:14]
-
-I saw a fun thing, npm.report. It looks like an interesting way to just get, like, a very brief... I don't know, this is, this is maybe a very early project. Just looking at some of the numbers on the landing page Well, it's certainly not ingesting all of npm to do this. But yeah, it's interesting. It's doing supply chain trust signals for npm organizations, so the audit, visualize, share, track over time. Uh, It's an interesting idea. I'm not quite sure if the execution is fully able to execute upon the idea it has, but it's looks interesting. Supply chain management auditing is so in vogue right now because it doesn't work very well. [00:57:16]
-
-**Mark Erikson:** So I, I mentioned Andrew Nesbitt earlier. He's been blogging for, for a while on package management ecosystems. He's, he's probably the world's foremost expert on all the world's package managers out there, and has put up a lot of blog posts on, like, how they work internally, where they're flawed, all these other things. [00:57:51]
-
-He's also written several satire posts on his blog. , he's written some fake articles about fake AI-driven CVEs slipping through the chains. he did this one a supplier security questionnaire. You know, the kind of thing that, like, a, a company security office would send out to their dependents, except this one's clearly being sent to an open source person. [00:58:10]
-
-And the questionnaire just gets more and more absurd on the requirements that they're placing on this unnamed open source maintainer. And, and that, that's sort of what happens when the legal compliance side of things wants assurance that your supply chain is secure, and two-thirds of your app is just we installed this NPM package [00:58:34]
-
-**Carl Vitullo:** Yeah. Cool. Nice. Love that [00:58:55]
-
-Okay. Well, continuing on our security thread there . I read a really great blog post called Everything I Own, Owned. so this person, Chaz Schlarp, put out a blog post about pointing Claude at various physical devices that he literally owns, that are physically in his possession, and just saying like, you know, "Hey, can you hack this? [00:58:58]
-
-Can you get control over this? Can you put a custom firmware on this?" and the answer resoundingly is yes. [00:59:17]
-
-**Mark Erikson:** Nice [00:59:25]
-
-**Carl Vitullo:** you know, hacked his own webcam a- alarmingly hacked it in such a way that he was able to turn off the recording light which ideally should not be possible. Ideally, that should not be a software controlled feature. It should be electrically impossible for the camera to record while the light is off. Oops, this one could. [00:59:26]
-
-Also hacked his monitor. And I... Something I appreciate is for each of these devices, he puts up a GitHub repo of the new firmware, how long it took Claude to figure it out, and how many prompts from him it took Claude to figure it out. So this, you know, the webcam was three and three quarter hours of Claude time with 33 prompts. His monitor is hour and a, hour and 15 minutes with 13 prompts. A microphone was four hours, you know, four hours and 15 minutes with 32 prompts. [00:59:44]
-
-I think this is really fascinating from a couple of different ways because to tie it into a like macro, huge question of ownership conversation that I've been hearing about for the right to repair. Like most things don't let you repair it. They don't let you, you know, access any kinds of internal state. And so like now that these AI tools are good enough at reverse engineering and cybersecurity stuff to just hack it, like, hmm, that's actually pretty interesting for right to repair. Like you know, to the extent that rules and policies are only as good as your ability to enforce them. [01:00:17]
-
-Like oops, they can't enforce their own security practices because it used to just assume that it was too hard to flash a custom firmware and now it's actually not that hard as, if you know generally what you're doing. [01:00:53]
-
-**Mark Erikson:** Or a lot of cases, if you don't know what you're doing or just willing to tell Claude, "Try harder." [01:01:05]
-
-**Carl Vitullo:** Right. Right. here's a fun one. This is a mini key light. So I think it's, you know, it's like for video production, it's just like a little controllable two by three inch light. And he says, " This one turned out way more interesting than I expected. It's the only one with meaningful firmware integrity protection. It signs the firmware updates with ED25519 and a hash of the firmware payload and rejects firmware that doesn't validate. Unfortunately, while that's an improvement, it protects the firmware ex- at exactly one point in time, during updates. I asked Claude to look for an exploit that might enable, you know, other attack surface, and it found an HTTP post request that drops a payload straight into the internal UART which includes a memory poke command." [01:01:09]
-
-So it, you know, it's got signed [01:01:50]
-
-verification [01:01:53]
-
-**Mark Erikson:** Change this value." [01:01:54]
-
-**Carl Vitullo:** Yeah. So it's, it, it has ostensibly update security, but it also has an HTTP endpoint that will let you, like, arbitrarily revise memory. He says, "This means a single HTTP post of ATSC equals," and then two hexadecimals comma-separated values, "turns the signature check into a no-op, and we can freely update the firmware." So it's just like, man, that's crazy. [01:01:55]
-
-That's great. [01:02:17]
-
-**Mark Erikson:** you tried [01:02:18]
-
-**Carl Vitullo:** At least you tried. Yeah, defense in depth, it's really hard. I don't know, that's really interesting. Like, if we own, if we more meaningfully own the ability to control what the tech in our rooms is doing, that's powerful. I appreciate that. We should have more of that. [01:02:19]
-
-Final AI security adjacent thing from the Trail of Bits blog. The Sorry State of Skill Distribution, talking about how the skill marketplaces for AI agents are full of malicious skills that will exfiltrate your, you know, credentials and blah, blah, blah, blah, blah. Yeah, so don't download arbitrary skills without reading what they're gonna be doing. You know, this is just an extension of I don't know, running untrusted code is never good, and running untrusted skills that will have the ability to run untrusted code on your hardware is even worse, ' cause these are smart. Yeah, reminds me too, I, I just learned, this happened last month, but a certain AI platform controlled by a person whose name I don't like to uh, give airtime was, it turns out the whole agent itself was uploading all of the directory that you ran it in with no control. So it would pull every, every file in there and just dump it into a remote GCP container. [01:02:33]
-
-So, like, state of security right now in the AI w- world is pretty rough. Most people are being very sloppy about it, and if you are riding the cutting edge, the odds that you run into something that will aggressively attack you is pretty high . [01:03:32]
-
-## Conferences (React, Javascript)
-
-Oh yeah, Mark, tell us about this conference [01:03:46]
-
-**Mark Erikson:** Yep same two I mentioned last month, and conveniently they're the... I, I know about them because I will be speaking at both of them in the next few weeks. ZurichJS is happening, I believe, on September 11th in Zurich, Switzerland. I said it last time, I'll say it again, because he r- especially because he ran across the transcript and thought it was very heartwarming. Faris Aziz is a good, close personal friend of mine. He's running this conference. He's been running the ZurichJS meetup for the last year or two. This is the first time conference for them and I know how much effort he has been putting into putting this together, from selling tickets to doing outreach and getting sponsors to building an entire conference management platform from scratch. [01:03:48]
-
-Faris is awesome. This will be a fun conference. The speaker list looks great. I'm looking forward to seeing a lot of good, good friends there. If you are anywhere in Europe or even not in Europe, consider buying a ticket and joining us there. It'll be great. [01:04:33]
-
-similarly, [01:04:46]
-
-React Alicante is in Alicante, Spain. [01:04:47]
-
-I believe that's around September 23rd, 24th-ish. That's also been a lot of fun. it's a very well-run conference. Another great organizer, Victoria. it's a good conf- there's a lot of good people there. Come join us. Hang out. Talk in real life. It's a thing [01:04:50]
-
-**Carl Vitullo:** Yes, I can confirm that Mark is a lovely person to go to a conference with. [01:05:05]
-
-Cool. All right, that's all we got for you this month. Thanks for sticking around an extra 25 minutes past our... Well, I'd say past our typical end time, but it's not like we've ever hit that, I think, this year. we'll be back next month. Maybe not on the last Wednesday, 'cause it's the last day of the month. Or we'll be back in your podcast feed just as soon as we can after we record. [01:05:09]
-
-Yeah, thanks so much. If this is a podcast that you find valuable I'd actually just personally love to hear it. If you shot me an email to hello@reactiflux.com and said something about how this has influenced the way you think or do things, that would be personally meaningful to me. [01:05:27]
-
-Or give us a review. Tell somebody else that you know about this podcast. That would all be very helpful. We have a sponsor for next month, which is great. yeah, so that should cover most of the costs of producing it for the year, I like not paying for it myself. cool. Thanks so much. See you next month. [01:05:41]
-
-**Mark Erikson:** Take care [01:05:58]
-
- [01:05:58]
diff --git a/src/transcripts/tmir-april-2023.md b/src/transcripts/tmir-april-2023.md
deleted file mode 100644
index 638ccb2..0000000
--- a/src/transcripts/tmir-april-2023.md
+++ /dev/null
@@ -1,461 +0,0 @@
----
-title: This Month in React (April 2023)
-date: 2023-03-29
-time: 10am PT / 5PM GMT
-location: Q&A Channel on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Matt Pocock as we break down This Month in React. A lot of news this month, with new library releases, TypeScript 5.1, and React server components. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Matt Pocock](https://twitter.com/mattpocockuk)"
----
-
-
-
-# This Month in React 2023 April
-
-**Carl Vitullo:** Welcome everyone. Thanks for joining us for April's edition of this Month in React, where we talk about what's going on in the React ecosystem. Mark and Sebastian, could you introduce yourself? [00:09]
-
-**Mark Erikson:** I'm Mark Erickson. I'm a senior front end engineer at Replay, where we're building a true time traveling to bugger for JavaScript. Also, I do a whole lot of Redex stuff. [00:18]
-
-**Sebastien Lorber:** So, yeah, I'm Sebastian. I created the This Week In React newsletter, and I'm also the maintainer of Docusaurus, which is a static site generator that many direct websites, use today. [00:30]
-
-**Carl Vitullo:** I'll kick us off. The way we do these news events is we do a round robin where one of us will introduce a link from the past month and then we all discuss it until we run other things to say. [00:40]
-
-## React Visualized, react.gg
-
-- [React Visualized, react.gg](https://react.gg/visualized)
-- [Launch tweet](https://twitter.com/tylermcginnis/status/1642969928562262020)
-- [The Story of React, uidotdev](https://www.youtube.com/watch?v=Wm_xI7KntDs)
-
-**Carl Vitullo:** Yeah, I guess I'll start with React Visualized react.gg. I just saw this, this is from Tyler McGinnis. He does the bites.dev newsletter. He's been in the React ecosystem for probably, at least as long as I have, maybe longer, I feel like. But definitely a, a giant in the ecosystem and excited to have such a high quality looking resource for learningReact. [01:01]
-
-**Mark Erikson:** Yeah, so there's, there's a couple things going on here. So Tyler runs a training company called UI.Dev, which makes, you know, a bunch of different courses including React Things, and I think they've had a couple different iterations of some of their different React courses. One thing I've seen Tyler do over the last couple years is that he's, he and this company have made a few different videos explaining various aspects of React, but from my perspective, even more importantly, explaining why some of those things about React exist. [01:31]
-
-This React Visualized thing, I actually saw them do a video version of this first. It talks, it like goes back in history to, you know, 2010, ancient history by this time. [01:44]
-
-**Carl Vitullo:** Ancient! [01:44]
-
-**Mark Erikson:** And, and it talks about, you know, frameworks like Angular and backbone and or, you know, even, vanilla JS, JQuery and some of the pain points people were experiencing working with those. And then it talks about how React was designed to solve some of those pain points as background information. It's sort of like a history lesson plus a, like why does React exist plus, like what are some of the basic concepts of React as an introduction. [02:11]
-
-He did both a video that I saw posted on YouTube. I'm not sure it's actually, it's actually linked from this site, and then this actual React Visualized site, which is semi-interactive visual page that shows a lot of that same information. I'm a really big fan of the concept, that it helps to understand what problems tools were designed to solve in the first place, in order to help learn them properly. [02:35]
-
-I really appreciate that Tyler is kind of taking that approach with some of this training material. Also, like if you, if you haven't seen any of the videos that Tyler has done, they do a nice little mixture of like, straight up serious explanation and historical clips of people talking at conferences where they were announcing certain tools and then like random, snarky, funny bits. [02:57]
-
-**Carl Vitullo:** Nice. Yeah, I do. I do love the, all the context for why React is, I think it's really important to understand where it came from in order to understand why it is the way it is. I think that is a very helpful framing. I hadn't heard about the, the YouTube videos, so, thanks for, thanks for putting that on my radar. I'll see if I can find some links for when we publish the recording of this. [03:17]
-
-**Sebastien Lorber:** Yeah, I think the. they build all this because they are releasing a course, pretty soon. That is a work in progress, and they created their own, course platform. So somehow I think this resource is, is a symbol of the, the quality of the course that they try to, to achieve. And it looks like, maybe it'll be the, the best competitor to Josh Comeau's course, I think because, both, look, like very polished. [03:42]
-
-**Carl Vitullo:** When your competition is Josh Comeau that you're in pretty good company. Cool. [03:46]
-
-Yeah, Mark, you want to kick us off with our next link? [03:49]
-
-## Immer v10
-
-- [Immer v10](https://github.com/immerjs/immer/releases/tag/v10.0.0)
-
-**Mark Erikson:** Immer version 10 just came out this last week. And for background, Immer is a library to simplify making immutable updates. So if you've used React, or Redux, you're probably familiar with having to do a whole bunch of, like spread the object, spread the nested object, spread `state.a.b.c`, or you know, mapping the arrays, slicing the arrays, concating the arrays, all that kind of stuff. Immutable updates are hard to get right. They're long, they're hard to read. It's easy to make mistakes. [04:17]
-
-Immer is a great library from Michel Westrate, the author of the MobX state management library. It lets it wraps your data in a proxy object, and then inside of that, you can write what looks like mutating syntax. So, `state.value` equals 1, 2, 3, and it traps those changes and turns it into a safe and correct immutable update. And in fact, we've been using Immer inside of Redux Toolkit since the very first proof of concept. [04:46]
-
-Immer has been around for a few years and they were on version nine. Immer still had, various pieces of legacy support. They had a ES5 fullback mode so that it would work in environments that didn't support proxies, which was primarily either IE11 or older versions of React Native before the Hermes JavaScript engine added proxy support. It, it also was trying to be like a little too correct in copying properties on objects. [05:14]
-
-It was doing a lot of like diligent, careful little checks for getters and a bunch of other things, and it was like correct behavior, but that also kind of slowed down the work of making the copies, for the most part, you know, assuming you're dealing with small data that wasn't too much of a per overhead and goodness knows the, the simplicity benefits made it worth it. [05:35]
-
-But for Immer 10, Michel Westrate made a bunch of updates. he dropped the ES5 fallback, and he also kind of adopted a looser approach to copying properties in new objects that is significantly faster. He'd been putting that, he'd been working on that for about the last month. Put out a few betas. [05:55]
-
-We tried them out over in Redux Toolkit, and Immer 10 final just came out about a week ago. It is noticeably faster and it's nice. And I actually contributed a PR to help improve the build tooling setup, and that helped improve some of the module formatting, ESM, CommonJS, and also help shrink the bundle size as well. [06:19]
-
-So I'm really excited about that in general, and especially because that's gonna be included in Redux Toolkit version two, which we've already got in Alphas. So it's sort of a, a free win for a lot of the ecosystem in terms of bundle size and performance. [06:33]
-
-**Carl Vitullo:** Nice. Yeah. I know that Immer from the start relied on on a lot of newer JavaScript features. I remember it being like a little bit of a, you know, maybe not a miracle, but a tough project to get it to work in more legacy environments like ES5. So now that they're able to drop some of that code. Makes sense that there'd be a lot of, you know, long tail enhancements, like bundle size and performance. That's awesome. Hell yeah. [06:58]
-
-**Mark Erikson:** Michel Westrate is a genius. [07:00]
-
-**Sebastien Lorber:** Yeah, I actually, I've seen a few, competitors projects. I don't know, but maybe, one or two were claiming to be, much faster than ImmerJS, but I think maybe they didn't support the older environments in the first place. So of course, it's, it's easier when you reduce the scope of, the library. [07:20]
-
-**Mark Erikson:** Yeah, I, I saw two different Immer equivalants, or competitors, pop up within the last few months. one is called Mutative and the other is called Structura. and they, they both perform the same basic function, wrap your data and a proxy, track the updates, make 'em immutable. [07:38]
-
-On the Redux side, we've had Immer built-in as a hard coded, non-negotiable part of `createSlice` from the beginning. Partly because we think Immer is using Immer is the right choice. But like we've had people say like, "I don't wanna use Immer." And we're like, then don't use Redux Toolkit because we think it's the right thing to do. And we're not making that configurable in any way. [08:00]
-
-Because a couple potential competitors did come out, we actually have an experimental PR over on the Redux Toolkit side that tries to let you swap out which immutable update library gets used inside of like create slice and stuff. It's tough because we actually use those imports in a lot of different places and so, you know, trying to figure out how to sort of turn them into like factories that let you configure it is tough. [08:27]
-
-And I'm, I'm not sure if that'll actually end up getting merged, but given that there's a couple other equivalent tools for immutable updates, we figured it was worth at least kind of playing around with it a little bit. [08:38]
-
-**Carl Vitullo:** Nice. Yeah. Makes sense. [08:39]
-
-Yeah. Sebastian, you wanna take us off? [08:41]
-
-## NextJS 13.3
-
-- [NextJS 13.3](https://nextjs.org/blog/next-13-3)
-- [Rich Harris talk](https://www.youtube.com/watch?v=uXCipjbcQfM)
-- [Notes on talk](https://blog.jim-nielsen.com/2023/notes-from-richs-talk/)
-
-**Sebastien Lorber:** yeah. Well, wanted to to talk about, the new NextJS 13.3 release. I think this one is interesting, in particular for one thing that I am particularly excited about. It's not the parallel routes and things like that, but more, the, the static export because, I think they, they don't highlight this enough in their marketing, but when you build the right server components with NextJS, by default, they are static. And if you don't choose any dynamic api, like getting the error of a request or getting the querystring or things like that, the server component will actually run at build time instead of, run time. So I think it's a really interesting property you can, configure if you want the server component to be static or to be dynamic. [09:29]
-
-But by default, it tries to automatically detect if you use any dynamic API and decide for, for itself if it should run at, build time or at run time. So, I think this is really, really interesting and they now support the static export. So basically this means if you don't choose any dynamic API anywhere in your app, you can export your, NextJS website statically, and all the server components will run at build time. [09:58]
-
-I think it's quite exciting, and also this works with, nested router. So the static or dynamic nature of the, of your components will depend on the root segments. So, for example, you can have a part of your page that is dynamic and some other part that is static. In the end, they really try hard to, to make, most of your components static, if it's possible. [10:21]
-
-And the, the rest will be dynamic, but they don't render too much things. And try to, to build, as much as possible at build time, all the server components. [10:32]
-
-**Carl Vitullo:** Nice. Yeah, that's really, that sounds really cool. I guess I, I thought that they already had something for a static export. I know that we, we use next for the Reactiflux website, I think that I did some kind of static export. [10:46]
-
-**Sebastien Lorber:** Yeah, it, it existed, but not for the, for the new app root directory, so it was not, working for server components yet. [10:53]
-
-**Carl Vitullo:** gotcha. Okay. That makes sense. Okay. Yeah, I. I haven't touched that in probably a year now, so it definitely did not get the app router in there. Okay, cool. Very nice. Yeah. I also see that they have new metadata API and dynamic open graph generation. Those both sound pretty cool. I know that a lot yeah, just open graph and the review image. [11:15]
-
-I think that's, I feel like over the last year or two, I've seen a lot more people, especially for like their blogs and their personal sites, treating that open graph as a, more of like a first class feature, rather than just sort of like an afterthought of copy some text outta the page and boom, there you go. [11:32]
-
-So having some more first class support for that from Next, seems like it will enable a lot of really cool features. [11:40]
-
-**Sebastien Lorber:** Yeah. actually I'm, I don't know exactly exactly how the integration work, but as far as I understood the OG image, package that they created only runs on Vercel because it requires some tooling available on the edge to, to make it work. so I wonder if it doesn't create coupling between NextJS and Vercel as a host. [12:04]
-
-So, I don't know. It's, it's not, mentioned in the blog post, so, so maybe I'm wrong, I don't know, but, recently there was someone that posted a blog post that says, "I am able to run a Vercel OG image on Netlify," or another host, I don't remember which one. And it required some, some tricks to, to make it work. [12:24]
-
-So it was not so, so easy. And I'm not sure if this package works everywhere yet. [12:29]
-
-**Carl Vitullo:** Gotcha. Yeah, I know that's been a, a pretty common point of negative feedback about Next is that everything works on Vercel first. [12:36]
-
-**Mark Erikson:** Yeah, that's that. That was the same thing that was going through my mind. So with a couple caveats that I have not used server components yet, and frankly, I've never worked on a project that needed SSR in any form. So I can't speak from trying stuff out myself. First it's very, very good that next does have a static export option, and I know that the new React docs where they're talking about picking a framework, do try to, you know, actually link and say that hey, you can use next without an actual running next server instance on your backend. [13:11]
-
-And I've seen Dan trying to, you know, help clarify that on Twitter. But I think some of the unease that people have with this, you know, this shift in advertising and direction from the React team is that they feel like they're being pushed towards next and Remix and stuff. Where the default path is you need to have a server running. [13:35]
-
-It's going to work best on Vercel. It's very easy to end up using features that require, you know, a whole bunch of additional entanglement. And yes, the options exist where you can skip that stuff, but the default happy path is adding all the, you know, all these dependencies and servers and stuff. And it, it's tricky to kind of say separate, like you can go without that stuff, but you have to do work to try to skip out on that. [14:01]
-
-I think that's what's, you know, kind of adding to this feeling of concern. [14:06]
-
-**Carl Vitullo:** Right. Yeah. Makes sense. But you know, I also definitely understand the motivation for, you know, there've been a lot of new, new ways to approach web development over the last couple of years with like ,edge workers and things like that. And I think that there's a lot of really exciting possibilities coming out of that. [14:23]
-
-So I understand the impetus to try and offer like first party ways to explore that. And yeah, I mean, I guess, you know, control over the server definitely makes it a lot easier to offer a good experience. But yeah, I guess I understand both sides of this, which is not a very exciting take (laughter). [14:41]
-
-**Mark Erikson:** Quick side note, Rich Harris recently did a fantastic talk. He, he gave like his thoughts on 10 different topics and he was rating them in terms of spiciness and, even the highest spicy rated takes weren't necessarily all that spicy. It was actually very thoughtful, deep nuanced discussion of trade offs of different tools and scenarios. [15:02]
-
-**Carl Vitullo:** Yeah, that's definitely someone I would expect to, or that I would have a lot of trust in to talk about. Topics like that with a lot of nuance. [15:09]
-
-## New React documentation translation
-
-- [New React documentation translation](https://github.com/reactjs/react.dev/issues/4135#issuecomment-1518443599)
-
-**Carl Vitullo:** All right, I'll move this on with our next, this is, you know, maybe not a whole lot to talk about here, but the new react.dev documentation site is getting translated. [15:18]
-
-I know that that was a, you know, that was one of the, points of negative feedback I heard about it is the old docs were in available in so many different languages and the new new docs were not launched with support for those. So good to see it as a fast follow to the launch. Looks like it's been in in the works for a long time and seeing a lot of work done. [15:37]
-
-I see a huge, huge list of translations. [15:40]
-
-**Mark Erikson:** And I know that as a whole, the reason why the docs were delayed so long was Dan was waiting to, was trying to get the content to, you know, a sufficiently complete level, and also make sure that the explanations and the tone were the right way. It's kind of hard to really start translation when you're still iterating on that process. [16:01]
-
-**Sebastien Lorber:** If you refactor everything, it's a pain for the translators because they have to, the, the strategy that they used is based on a repository, so they have to, some of the, there is the main repository with the trans, the English language, and there are folks for each language and. They synchronized the new documentations from the upstream language to the older folks. [16:25]
-
-They have a bot to automate this, but, still I think they, it can be a bit painful to manage all this and to ensure that there are not, merge conflicts between, the, the current translations and the new documentation that the red car team is aiding. So, it's better to, to have most of the content quite polished in the first place before starting the the translation effort, I think. [16:49]
-
-**Carl Vitullo:** Yeah, definitely makes sense. Every language you wanna do it in explodes the amount of work or you know, it adds one more copy of it. So given that, I think, looks like the list of language they support is easily 15 or 20. So definitely trying to write all of those in parallel is just like a non-starter for that. So yeah, glad to see you coming out. [17:11]
-
-**Sebastien Lorber:** Because the translation workflow even is a bit complex, so you have to onboard people if they are not used to it. So [17:19]
-
-**Carl Vitullo:** Right, [17:20]
-
-**Sebastien Lorber:** this is not easy. I think the, hopefully they, they're able to split the work, between, each site. So, each site can somehow autonomously work on the translation. But, you have to explain to each main language contributor how it, it works to, to make them productive in the translation process. [17:41]
-
-**Carl Vitullo:** Right, right. I've only ever dabbled in translation on apps that I've worked on. You know, none of them really had serious international usage, so it wasn't a major impediment, but writing documentation to explain difficult technical concepts in 20 different languages. Like, oh, oh boy. What a task. [17:58]
-
-Well, Mark, what's up on your list? [18:00]
-
-## TypeScript 5.1
-
-- [TypeScript 5.1](https://devblogs.microsoft.com/typescript/announcing-typescript-5-1-beta/)
-
-**Mark Erikson:** So TypeScript 5.0 just came out, and hot on the heels is TypeScript 5.1 in beta and one of the changes there has to do with TypeScript support for JSX syntax and type checking what gets returned. Now I only barely understand what's going on here, so you know, please, please take my explanations here with a grain of salt, TypeScript support for JSX was basically originally started to support React. [18:28]
-
-But JSX is not a React only concept today in a lot of other frameworks like Solid use it. And so TypeScript has had to do this kind of difficult dance internally where they need to be able to handle JSX but not lock their support of it to only working with React specifically. It has to be a little more generalized, and that's had limits on how the, the type checking process can work. [18:55]
-
-This has actually had ripple effects on how you can use TypeScript in your React components. And the biggest pain point is that due to something about the way JSX elements were implemented, TypeScript would actually yell at you if you tried to return some of the newer, non-JSX return values from a component. [19:15]
-
-So, you know, if you tried to return like strings or arrays from a function component, it's totally legal JavaScript and as of like, you know, React 16, it's totally fine, but TypeScript would yell at you and say, "you can't do that," and you end up having to wrap that in a fragment that serves no purpose other than to satisfy TypeScript. [19:34]
-
-So, The React team has been working on trying to allow some components to do things like return promises, and of course, TypeScript would not allow that given its current type checking support. This discussion started like, two or three years ago and I think it's been a very long running issue, and the TypeScript team just merged a PR that somehow alters how TypeScript interprets and type checks JSX syntax. [20:02]
-
-And this seems to loosen up what it will allow and is apparently going to make it easier to do things like returning a string or an array from a component. And it'll be legal as far as TypeScript's concerned. And it will also unlock future changes for things like returning promises from components. Basically TypeScript is trying to make it better and easier to return a broader array of things from components with JSX syntax. [20:30]
-
-**Carl Vitullo:** Yeah, I definitely remember encountering those sort of type bugs where I know that this is a valid thing to return from this component, but actually getting TypeScript to recognize that was a pain in the butt. You know, figuring out what type I'm supposed to use to describe the component, whether that's React.FunctionComponent, or you know, React.FC or whatever it is. So I'm excited to see this improve the situation. [20:54]
-
-**Mark Erikson:** The default recommendation has been just don't use it at all. Provide a type for the props and let ts figure out what the return type is. [21:02]
-
-**Carl Vitullo:** Hmm. Yeah. Excited to see that get better. [21:05]
-
-Cool. Yeah. Sebastian, you wanna take us on our next news item? [21:08]
-
-## MillionJS, one-function React perf wins
-
-- [MillionJS, one-function React perf wins](https://twitter.com/aidenybai/status/1650406345517199361)
-
-**Sebastien Lorber:** Maybe you've seen there is a new package called, MillionJS. I think it's, it's interesting and it, it got my curiosity. The idea is somehow to, to make, to improve the performance of the virtual dom by using, a block based virtual DOM. As far as I understand it, the idea is that if you have two virtual DOMs that have exactly the same size and structure and things like that, you are able to optimize this and perform the diff faster. [21:37]
-
-And recently there was, a new version of MillionJS, which support, NextJS too. So it's possible to integrate into an existing app to make it faster. And, there's also a repository that now is there for learning purpose called HundredJS. And the idea is that, it provides a very simple, implementation of a block-based virtual DOM, but you can, understand, the idea. [22:04]
-
-So I don't know exactly how it works yet, but, I found, it was quite interesting somehow the first time I came across this project, I thought, oh, they have a beautiful landing page, and the developer is 16 years old or something like that, I don't remember, but he's very young. I somehow dismissed this project, but, now it, I, I get more curiosity for it. I think, maybe this will be, an interesting thing, to, to follow in the years to come. [22:30]
-
-**Carl Vitullo:** Yeah, interesting. This is, this is a new project to me, but you know, anything that promises to make stuff faster just by wrapping it into function, is both interesting and draws a little bit of skepticism (laughs). I've definitely written some components, or rather some helper functions that look like this to solve performance problems for myself. [22:50]
-
-The main situation I'm thinking of is where I have a very slow, you know, maybe it's very complicated or something, some slow component as part of a larger page. And some number of years ago I wrote a, a little helper that just, it, it was basically sort of a, a cheap async rendering helper. It would just render nothing for one render pass and then render the actual children. [23:13]
-
-Yeah, I used that on a very complicated list page, and it took initial render down from like over two seconds to tens of milliseconds just really helped the sense of interactivity, if not the total overall render time. You know, the, the actual render time didn't change that much, but at least you can interact with the page while it's doing all of that. [23:32]
-
-So I, I wonder if it's doing something similar to that, just enabling rendering to split up over multiple passes. But yeah, cur curious to dig into that more. [23:41]
-
-**Sebastien Lorber:** Yes, I'm, I don't know exactly. I, I can tell, but this is something interesting to follow, I think. So we will figure out, soon, I think (chuckles). [23:49]
-
-**Carl Vitullo:** Cool. Yeah. I guess I'll pick us on to the next one. [23:51]
-
-## React Server Components
-
-- React Server Components
-- [RSC Quiz thread](https://twitter.com/dan_abramov/status/1648923232937058304)
-- [XHP v JSX](https://twitter.com/dan_abramov/status/1648830869304426500)
-- [Lenz RFC for Apollo/RSC](https://twitter.com/phry/status/1649520340647673856)
-- [AsyncContext stage 2](https://twitter.com/sebastienlorber/status/1639183216799100928)
-
-**Carl Vitullo:** So this is not necessarily one single news article, but definitely a topic of discussion, React Server Components. There's been a lot of news and discussion coming out over the past month or so. I saw Dan Abramov did a quiz thread on Twitter. Looks like it answers a lot of questions about how React server components behave. [24:11]
-
-Definitely interesting information in there. I have not yet really used React server components at all, so I , I don't feel like I can speak too deeply on this subject, but Mark, Sebastian, have you used server components much? [24:23]
-
-**Mark Erikson:** Not in the slightest. [24:25]
-
-**Carl Vitullo:** Hahah. [24:26]
-
-**Sebastien Lorber:** No, (laughs) no, I mean, I only work on Docusaurus, so there is no Server Components yet, but I, I wish, to do that, soon, but need to figure out a few things before. [24:38]
-
-**Carl Vitullo:** Yeah. Yeah. I feel that. [24:40]
-
-**Mark Erikson:** And, and similarly, like my day job at Replay is, replay is entirely a classic client side, single page app. And between that and all the Redux stuff, I don't have time to go play with other new shiny things. [24:53]
-
-**Carl Vitullo:** Right, right. Yeah, I know that Dan has been on a, a bit of a, a bit of a PR blitz. Yeah. He's been on a tear doing all sorts of events and talking about React Server Components a lot. We've talked briefly about doing an event here, and maybe having an ongoing channel for people to ask questions about it. So yeah, stay tuned for news about that. [25:15]
-
-But, nothing to announce at the moment, but yeah, so I saw that quiz thread from him. I also saw a great sort of history of that I just posted in the chat. it talks a lot about X H P and hack and Facebook code going back to 2010 era. Definitely. Yeah. I mean, like we're talking about with React Visualized, I think the history of why things came to be what they are is super helpful for understanding what they are. [25:42]
-
-So I, I think that's a, I think that's a good thread to read, to understand what's going on. [25:46]
-
-**Sebastien Lorber:** Yeah, definitely. [25:47]
-
-**Carl Vitullo:** Yeah. [25:48]
-
-**Sebastien Lorber:** I think the, the, the quiz is very interesting because somehow we challenge your, your intuition that you can have. And honestly, I, I, I think I got all free and sales correct, but, I wasn't absolutely sure about, any of them (laughter). So this is, this is really not easy and I think many people, don't have the intuition of, of several components. [26:09]
-
-So this is really worth to, to take it and see if you, if you have the intuition. [26:14]
-
-**Carl Vitullo:** Yeah, definitely. [26:15]
-
-**Mark Erikson:** It seems like one of those things where half the people are gonna get this wrong either way. [26:19]
-
-**Carl Vitullo:** Right, right [26:20]
-
-**Sebastien Lorber:** (chuckles) [26:21]
-
-**Carl Vitullo:** Definitely a, a big iteration on the React mental model. So I'm sort of, I'm sort of waiting for the dust to settle before I dig too deep into it. Just, you know, a lot of churn going on, a lot of innovation and discussion, and I'll, I'll come through a little bit later and see what it all looks like, but it's definitely a lot to stay on top of. [26:40]
-
-Cool. Yeah. And one more link I wanna paste from one of our, one of our community members, Lenz Weber-Tronic, phryneas' post is, looks like he's looking into React Server Components, how to connect it to Redux Toolkit in Apollo. [26:54]
-
-**Mark Erikson:** Yeah, so Lens is my Redux Toolkit co-maintainer created our RTK query data fetching library, and he also recently got hired by Apollo to work on Apollo client. So we've, we've had a couple of different discussions with the React team about, you know, how our external data libraries supposed to integrate with suspense. [27:14]
-
-And the shorter, the short answer is, "we're still not really sure, go make new APIs instead of building that into your query hooks." But then he's also been doing a bunch of research over the last few weeks into, how you server components work, and how would you integrate external data fetching libraries into server components in the lifecycle? [27:34]
-
-And he's only, he's only hinted at bits and pieces and some of that, some of those hints were in this, this Twitter thread, but it sounds like he's been trying to put together a fairly large write up to start a discussion and ask some questions. So I am actually legitimately curious to see what his summaries are and what his questions are because again, like I don't have time to look into this myself, so I'm glad Lenz does. [27:59]
-
-**Sebastien Lorber:** Yeah. [27:59]
-
-**Carl Vitullo:** Yeah, definitely very curious to see what he, his conclusions are. Yeah, I mean he's been active in Reactiflux for years and very helpful and thoughtful, so very much curious to see what he thinks. [28:10]
-
-**Sebastien Lorber:** Something, I'm thinking about is, you know, we already discussed that in the past, but I think it's a bit related, is the new AsyncContext proposal, which is a stage two for standardization in JavaScript. I have the feeling that the, the idea of this API could be to, to use React context in a cross platform where in both our components, when they use I think, weight and, also in a regular components that we use today on the client and things like that. [28:41]
-
-I think it's interesting because, it could enable you to provide the, the, the context of maybe Apple, Apollo or React Query to your tree. No matter if it's a client component or a server component, it should be able to work. So, I look forward to, to see this api, become adopted everywhere and see if, and see if it unlocks any use case. [29:06]
-
-I think Sebastian Markbåge posted something, recently and, and somehow it summarized the idea that, that I tried to, to explain is that you could use eventually the standard, I think, context feature as React context directly. So I think this is interesting because this would not only work with, React hooks, but also, as a regular, JavaScript feature that we can work both on the edge, on the NodeJS runtimes, and also on the client. [29:38]
-
-Maybe it's not what is, maybe it's not, it's not the challenge that Apollo is facing to integrate with several components. I don't know. But I think it's one of the piece that could make it, easier. [29:49]
-
-**Carl Vitullo:** Yeah, definitely always nice to rely on standard browser features rather than something hand rolled within a library. I'm sure React would love to have some sort of standardized context. [30:00]
-
-**Mark Erikson:** Use the platform. [30:01]
-
-**Carl Vitullo:** Use the platform! [30:02]
-
-Cool. Yeah. Mark, what have you got next? [30:06]
-
-## Recommending uncontrolled components
-
-- [Recommending uncontrolled components](https://twitter.com/dan_abramov/status/1641830612955803650)
-- [API Reference](https://react.dev/reference/react-dom/components/input)
-
-**Mark Erikson:** Okay, so the existing React Docs or the, I guess now the, the Legacy React Docs always had a page on forms. And the standard direction in that docs page was write controlled inputs where React is always in charge of pushing the current value of the input into the DOM. And your job is to provide, you know, here's what the current value should be and here's, you know, a, a callback that sets state and that went along with Reacts philosophy that, you know, the UI should always be based on the state. [30:42]
-
-And that made this idea of uncontrolled inputs, sort of like a, a very non idiomatic approach within the React ecosystem. Within the last few years, we've seen a little more acceptance of using uncontrolled inputs as being valid. The library React Hook Form, I believe, uses uncontrolled inputs and, Remix has been doing things with that as well. [31:08]
-
-So the new React docs are complete as far as the learning content, and they're basically complete as far as the API reference material, but they don't have a lot in the way of usage guide pages. There's a lot of pages that just simply need to be written from scratch for things like testing, and that includes forms. [31:29]
-
-There, there is no specific page on how to use forms in the new React docs. However, what I did not realize is that the API reference section actually has some pages on how to use specific HTML tag types in React. That includes the input tag and this reference page on using input tags actually talks about the difference between controlled and uncontrolled inputs, and basically recommends using uncontrolled inputs by default. [32:05]
-
-This is actually a really big shift in what the React team is suggesting people should do. And it there, I think there's a few different reasons for it. One is that, you know, setting up controlled inputs has always taken work. You have to have the useState, and the callbacks, and the value, and you're putting in the extra effort to make things consistent. [32:26]
-
-And then I think it also kind of ties into some of the React server components work that they're doing where they want to be able to pass form state back to the server processing. And I guess that seems to work a little better if the inputs are uncontrolled. So I, I have not even gone through this input docs page in detail. [32:47]
-
-I didn't realize the Docs page existed until I saw Dan tweet about it, and I definitely did not realize that the React team was shifting their recommendation there. So it's, it's definitely worth going through and trying to read that page and see what it has to say. And I don't know, like it, it's that shift in patterns and recommendations again. [33:05]
-
-**Carl Vitullo:** Yeah, I'm, I'm sort of ski- skimming that page while you're talking a little bit and. Yeah. One thing that jumps to my mind is the use case of trying to provide very, very high quality validation for input values, and it's been my experience that the browser doesn't expose very good primitives for validation. [33:27]
-
-I think at best you end up, you can do like, what, a regex based on the value? But you know, like especially if you need like some sort of dynamic validation. Like for instance, I've done password inputs when signing up that hit an API to see if the input password is too similar to, you know, publicly cracked password lists or otherwise perform some sort of processing that requires an async step, and going from an uncontrolled form to a form that has advanced validation, like that seems like a pretty big lift. [34:00]
-
-So I, I, I generally agree with the idea that you should lean on the platform as much as possible. We should not write JavaScript that duplicates behaviors that the browser gives us free. But yeah, there's definitely some, some gaps in what the browser offers around forms and validation. So that seems like it's gonna be a bit of a, a point of friction on an ongoing basis. [34:21]
-
-I guess one other thought I want to connect it to, I just had opportunity to see the React documentary again, and it was funny hearing, I can't remember the exact line, but somebody mentions that, nobody's ever written a form and React as of, you know, when it was being open sourced. [34:37]
-
-And so it's, it is funny to see now, yeah, no, actually 10 years later. Cause that was uh 2013. Forms in React is still a little bit of an open question. There still isn't complete guidance for what it should look like. [34:49]
-
-**Sebastien Lorber:** I think the, the thing is, maybe the shift happens because of Remix, because, you know, there, there's a lot more traction for progressive enhancement these days, thanks to Remix, I think, it existed before, but not much in React ecosystem. And to, to, to have a progressively enhanced form, you need it to work without React somehow. [35:10]
-
-So if you, if you make it, controlled, you are basically implementing features that will only work if JavaScript is there. So I think also this, this shift is happening because, because of progressive enhancement and the need for a form to be able to just work with HTML and a server somehow. [35:28]
-
-**Carl Vitullo:** Yeah, for sure. [35:30]
-
-Cool. Yeah. Sebastian. Wha- what's your next news article? [35:33]
-
-## Super Apps in React Native
-
-- [Super Apps in React Native](https://www.callstack.com/super-app-development)
-- [RN PS5](https://twitter.com/syke/status/1619413099861413889)
-
-**Sebastien Lorber:** Let me check. I don't remember. yeah, it's, Super App development. There is, a new resource from Gold Stack, the React Native company that is presenting the, the idea of Super App development. It's not the first time, but I saw that. I see blog posts of them, mentioning this idea, it's, the, the concept of Super App is quite popular in, in Asia. [35:57]
-
-For example, there is the WeChat app in China, I think. And the idea is that somehow you gather many, many small apps inside a big host app and your users, users are able to seamlessly transition from one app to the over. And, somehow it requires, some, a bit complicated things to, to, to set this up. [36:17]
-
-for example, you don't, you, I think you can't use the default React Native bundler. You have to use a repack, which is, somehow a layer above, webpack to make it work and have got spliting module federations and and advanced webpack features to make this work. So I, I don't know exactly how you set this up, but they, they provided a comprehensive resource with a step-by step, tutorial. [36:41]
-
-And there's also, a showcase repository that you can try so you can actually, build your super up locally and see it work live. And also, I thought there was something quite interesting, but I came across for some place that, I think, I'm not sure, but I think the PlayStation 5 UI is actually a super app built with React Native. [37:06]
-
-And, I will link a with, in the chat to show you why I think that, but, maybe I'm wrong. I don't know. I think it's, it's quite exciting to, to see that, first, React Native is running on PlayStation 5 and, that this is a super app maybe. [37:22]
-
-**Carl Vitullo:** Oh, interesting. Wait, PlayStation 5 UI is implemented and React Native? Is that what you said? [37:27]
-
-**Sebastien Lorber:** Yeah, actually I think they started to use React Native, already at, PlayStation 4, according to the comments. [37:35]
-
-**Carl Vitullo:** Oh wow. That's pretty cool. I didn't know that. Very nice. Yeah, the, the super app, as they describe it, I see that they have a comparison to micro front ends and definitely sounds a little bit similar, sort of a architecture around. Structuring an app. [37:50]
-
-**Sebastien Lorber:** This is, yeah, I think perhaps is the, the mobile term for micro front ends on the web. So it's exactly the same, I think, module federations and things like that. So, [38:00]
-
-**Carl Vitullo:** Yeah, it makes sense. And I think both of those are, or you know, my understanding of micro front ends is it's an architectural decision that is influenced by the size of the team, sort of a, it's maybe not desirable on its own. But in the context of a large company that has, you know, say 80 developers, 80, 100, 200 developers, all working on the same application, getting to a place where you aren't constantly stepping on each other's toes with merge conflicts, and it's just swapping out behavior of shared primitives all the time. [38:36]
-
-I think it— that's sort of the context where these super apps or micro front ends are really important and really, not just important, but kind of necessary for enabling that level of, collaboration. [38:47]
-
-**Sebastien Lorber:** Yeah I think, this is necessary. I think I, I had a case, at work a few years ago where, They wanted to, to build a, a very large application for, a big, company in France. And they wanted to so that each part of the app would be implemented by a different contracting team. basically, we all share the same dependencies, but there are like 10 teams from different companies working as a contractor for the client. [39:17]
-
-So this looks like a, a really good use case for, for using, this kind of, of architecture because, you know, otherwise it's, it's a big mess because you, someone in another team will upgrade a dependency and then you will have a. Really complex side effects for all the other teams and or everybody will, fight again each server to reject the responsibility for, for, for the bugs (laughter). [39:44]
-
-**Carl Vitullo:** Makes sense. Oh man. That's, having multiple different contracting agencies work on the same app. That's like an extra level to that. Because I imagine you need various Yeah. Controls to keep different people from accessing parts they're not authorized too. Yeah. Wow. [40:01]
-
-Cool. Yeah. Well, I'll kick us off with a lightning round. [40:03]
-
-## ⚡️ Core team layoffs
-
-- [Mengdi Chen](https://twitter.com/mengdi_en/status/1648718077796786177)
-- [Robert Balicki](https://twitter.com/StatisticsFTW/status/1648820621252653056)
-- [Matt Carroll](https://twitter.com/mattcarrollcode/status/1648770402272018432)
-- [Sean Keegan](https://twitter.com/DevRelSean/status/1649466893806215172)
-
-**Carl Vitullo:** Just a, a quick shout out that I think is nice to do. A number of core team members for React and, you know, the surrounding ecosystem were hit by layoffs at Meta. Just a, you know, poor run out for our, for our Lost Friends. [40:18]
-
-Just looks like it was a, among others. This is the list that I am aware of top of mind. [40:24]
-
-Mengdi Chen from the React Dev Tools. Robert Balicky from Relay. Matt Carroll doing devrel for React, and Sean Keegan also doing devrel. Yeah, layoffs, they suck, but also seeing Tom Occhino and Dominic Gannaway joined Vercel. So more, you know, legendary React figures moving over there. A lot of, lot of churn going on team right now. [40:47]
-
-## ⚡️ React Miami
-
-**Mark Erikson:** React Miami was this last week and it was an amazingly well done conference. Both Carl and I were there. I, I got to speak. It was excellent, organized. The rest of the speakers were wonderful. The atmosphere was amazing and I got to spend a lot of time talking to, you know, both people that I know from online, from the conference circuit, but also just talking to lots of, you know, sort of lots of random people who are working in different jobs, solving different problems. [41:14]
-
-It was just a wonderful experience. [41:16]
-
-**Carl Vitullo:** Echoing that, absolutely amazing. [41:19]
-
-Cool. Yeah. Sebastian, you got a lightning round link. [41:21]
-
-## ⚡️ react-three offscreen
-
-- [⚡️ react-three offscreen](https://github.com/pmndrs/react-three-offscreen)
-
-**Sebastien Lorber:** I just wanted to mention, react-three offscreen. The idea is that, you use a react-three fiber to run the three descents. And now it supports to be, to run inside a web worker. So basically you, you use something, a standard web API called Offscreen Canvas and it permits to, to draw inside the web worker. [41:45]
-
-So basically you run down your three design inside another thread, and it doesn't block your UI thread. So, It's quite interesting for performance reasons because you can integrate, complex, 3D animations and it doesn't block the, the rest of your website. So I think it's interesting to, to use. [42:04]
-
-## ⚡️ Lingui v4.0
-
-- [⚡️ Lingui v4.0](https://github.com/lingui/js-lingui/releases/tag/v4.0.0)
-
-**Carl Vitullo:** Very cool. I'll take next Lingui 4.0. I've used Lingui in the past, it's a internationalization framework. I've tried a couple of different internationalization frameworks and wasn't super happy with them, but Lingui actually worked pretty reliably, when I did need to use it. So just shout, shouting them out. New major release. [42:24]
-
-**Sebastien Lorber:** Yeah, actually I'm, I'm in touch with the, the guy, that sent me this link for just today, and I, I asked him to, To write a blog post and maybe we will feature it better in the newsletter next week because, I think may, it looks interesting. It looks like a bit react-intl, but, provides some additional, developer experience on top of it. [42:48]
-
-I think, I mean it's not, a layer on top of, react-intl, but it's quite similar. It's using the ICU message syntax and, quite similar features, like the ability to extract the translation from the cloud and things like that. So I think they will, they will write a blog post to present better this new release quite soon. [43:10]
-
-**Carl Vitullo:** Cool. Yeah. Maybe we can go go in more in depth next month. [43:13]
-
-**Sebastien Lorber:** Yeah. [43:14]
-
-## ⚡️ Redux Toolkit 2.0 alpha
-
-- [⚡️ Redux Toolkit 2.0 alpha](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-alpha.5)
-
-**Mark Erikson:** I've got a, I've got a semi self plug. So we've been working on the Redux Toolkit 2.0 Alphas, and we're currently on 2.0 Alpha five. The RTK 2.0 is working on improving our ESM common JS package formatting, modernizing the JavaScript output and. We're moving a few bits of deprecated options and APIs and generally trying to make things faster. [43:40]
-
-we've also got a couple new features in there, so they're tagged as Alpha because we're still working on changing a bunch things, but the code that's in there is stable and we'd really encourage folks to try out the Alphas and give us feedback like, does this work in your app? Does it accidentally break anything? [43:56]
-
-The current Alphas have Emerton final in there, so you get some of the speed benefits that I was talking about earlier, and then something that I hope will end up as part of RTK 2.0. Final. I've been experimenting with a couple new memorization options for the Reselect library. One of them is very inspired by what the Ember folks have done with auto tracking field accesses. [44:21]
-
-So the idea is that. It knows exactly what fields you're accessing and only recalculates the select results if those fields got changed and not other fields. There's also another one that I was playing around with that is basically a direct copy paste from a React internal cash implementation that uses weak maps to track arguments. [44:42]
-
-Right now none of that is released. I have a PR up over in the reselect repo that has like the initial, like "I've been hacking on this and it sort of seems to work" graphs, so I'm hoping to go back and work on that further. Assuming those work out, they will either go into Reselect 4.2 or Reselect 5.0 depending on what I feel like. [45:04]
-
-And then one way or another that the new version of Reselect would get included in RTK 2.0. So trying to find ways to make things better. [45:13]
-
-## ⚡️ Netlify framework popularity
-
-- [⚡️ Netlify framework popularity](https://www.netlify.com/blog/framework-popularity-on-netlify/)
-
-**Carl Vitullo:** Cool. Heck yeah. Yeah. well I saw the framework popularity on Netflix, or Netlify blog post. Definitely pretty interesting data to look at. They broke it down by free sites, paid sites, and enterprise sites. Just a couple of notable, I'll, I'll call out, Create React App Next, and Gatsby, I think those were, Some of the interesting results. [45:34]
-
-So free sites, 40% of them were using Create React App that goes down to 23% if you just go by paid sites and all the way down to 18 if you're looking at Enterprise. So yeah, Next, and Gatsby were 2 and 3. Those are pretty reliably the top three, and Next only gets more popular as you go up in price scheme. [45:56]
-
-Yeah, I thought it was a pretty interesting bit of data to look at. Definitely impressive to see how well Next is doing. Although, you know, one thing I was surprised to see missing here was Remix, but I guess they don't really support so much of a static export, and that's kind of Netlify's bread and butter. [46:14]
-
-**Sebastien Lorber:** There is a Remix adaptor for Netlify, I think, but, yeah, it's always complicated to, to market another platform, then, when it's not maybe the first class to support and, [46:27]
-
-**Carl Vitullo:** Yeah, sure. [46:28]
-
-**Sebastien Lorber:** Although was happy to, to find out that, Docusaurus, has a 4%, share in the enterprise site. So this is, there are more Docusaurus sites on Netlify than, Remix sites on, on Netlify. [46:43]
-
-**Carl Vitullo:** Oh, funny. [46:44]
-
-**Mark Erikson:** I think the other interesting takeaway there is the popularity of Create React App in, in those categories, which, you know, kind of goes to the difference between like the, the chatter on Twitter and, you know, all the, the emphasis from the React team we've seen versus, well, okay, here's how stuff is actually being used in the real world at the moment. [47:02]
-
-**Carl Vitullo:** Right. Hobbyists versus professional maybe. [47:06]
-
-Yeah. Cool. mark, anything else you wanna call out? [47:09]
-
-## ⚡️ PartyKit
-
-- [⚡️ PartyKit](https://github.com/partykit/partykit)
-
-**Mark Erikson:** One other little item. So Sunil Pai, who's a former member of the React Team and has been revolved in the re in the React ecosystem for many years, has been doing a startup called Party Kit where he's building infrastructure for real-time multi-player applications. You know, the, the kind of thing where you see like 30 different people interacting with the same whiteboard simultaneously, and he just open sourced the party kit repo at React Miami. [47:39]
-
-I know it's a thing he was very, very excited about and I haven't had, again, haven't had a chance to play with it, but it looks really cool. [47:48]
-
-**Carl Vitullo:** Yeah, agreed on all counts. I haven't played with it yet, but I've been following development because Sunil Pai is just such a, such a great person. I really enjoy… we, we had him on for an event, talking about rewrites, and he's just such a, thoughtful and kind person. I, you know, I'm gonna be rooting for him, in anything he does. Ha. [48:07]
-
-**Sebastien Lorber:** Yeah (chuckles). [48:09]
-
-**Carl Vitullo:** Cool. Okay, everyone, thank you so much for joining us for this April edition of This Month In React. I hope, I hope you learned something. I hope that you felt like we're helping you stay on top of the React ecosystem. There's always a lot going on, so hopefully we can bring some clarity. [48:22]
-
-Mark and Sebastian, thank you so much for talking with us. [48:25]
-
-**Mark Erikson:** Yep. Always. [48:26]
-
-**Sebastien Lorber:** Thank you, and see you next, next month. [48:28]
-
-**Carl Vitullo:** Yeah, see you next month. Awesome. Thanks so much. see you guys later. [48:33]
-
-**Sebastien Lorber:** Bye.
diff --git a/src/transcripts/tmir-august-2023.md b/src/transcripts/tmir-august-2023.md
deleted file mode 100644
index b20628c..0000000
--- a/src/transcripts/tmir-august-2023.md
+++ /dev/null
@@ -1,423 +0,0 @@
----
-title: This Month in React (August 2023)
-date: 2023-08-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-Concurrent Mode, Remix DevTools, included SourceMaps, new Expo features
-
-- [Spotify](https://open.spotify.com/episode/2ScNpUkv8QRYXaniMnfpWT?si=yF2SwwsRTGmvAFcl_Wsq_w)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/this-month-in-react-august-2023/id1661733526?i=1000626488343)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [Or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux/episodes/This-Month-in-React--August-2023-e28qasn/a-aaaa1f1)
-
-
-
-- Gatsby's growth and development seems to be stagnating as Jamstack has fallen out of favor compared to Next.js.
-- React's stubborn incompatibility with Web Components is frustrating but may be more of an indictment of Web Components' limitations.
-- CSS-in-JS causes fragmentation across environments like client vs server rendering, so the React ecosystem is moving away from it. Differences in tradeoffs between browser and mobile environments make it a difficult problem.
-- New devtools have been released for React Server Components and Remix that help inspect behavior on client and server. Good devtools are a huge force multiplier.
-- Publishing libraries with proper ESModules support is still very challenging and undocumented. Deno may help smooth the process.
-- React production builds now have sourcemaps thanks to impressive work by Mark Erikson! This will massively help debugging libraries like React in production.
-- Official React + TypeScript documentation has finally landed. Orta did a great job with it.
-- Try out new versions of Redux Toolkit and React-Redux in beta. Provide feedback!
-- Expo had a big release week with improvements to builds, updates, SQLite, CLI plugins, and more as React Native marches forward.
-
-Links used:
-
-- [Is Gatsby Dead?](https://twitter.com/sebastienlorber/status/1694392101281190224)
-- [https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/](https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/)
-- [https://www.spicyweb.dev/farewell-jamstack/](https://www.spicyweb.dev/farewell-jamstack/)
-- [Things you forgot (or never knew) because of React](https://joshcollinsworth.com/blog/antiquated-react)
-- RSC Devtools
- - [RSC Devtools - Chrome Extension](https://chrome.google.com/webstore/detail/rsc-devtools/jcejahepddjnppkhomnidalpnnnemomn)
- - [Devtools for React Server Components](https://www.alvar.dev/blog/creating-devtools-for-react-server-components)
-- [My Experience Modernizing Packages to ESM](https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/)
-- [Remix Dev Tools v2.0 - New settings tab](https://github.com/Code-Forge-Net/Remix-Dev-Tools/releases/tag/v2.0.0)
-- [Everything I wish I knew before moving 50,000 lines of code to React Server](https://www.mux.com/blog/what-are-react-server-components)
-- Expo
- - [Expo Preview - Fully customizable builds on EAS Build](https://expo.dev/changelog/2023/08-10-custom-builds)
- - [Expo Proof of concept - expo-sqlite integration with CR-SQLite](https://expo.dev/changelog/2023/08-10-cr-sqlite)
- - [Expo Proof of concept - Expo CLI Dev Tools Plugins](https://expo.dev/changelog/2023/08-10-dev-tools-plugins)
-- [Feature Preview: Single Sign-On (SSO)](https://blog.expo.dev/feature-preview-single-sign-on-sso-9c1a7d50c1a9)
-- [Feature Preview: Rollouts for EAS Update](https://blog.expo.dev/feature-preview-rollouts-for-eas-update-4eac28596470)
-- [useUpdates() API for expo-updates](https://expo.dev/changelog/2023/08-08-use-updates-api)
-- [Expo Orbit: Download and launch builds](https://expo.dev/changelog/2023/08-09-orbit)[Components](https://www.mux.com/blog/what-are-react-server-components)
-- ⚡Lightning⚡
- - [React prod sourcemaps](https://github.com/markerikson/react-prod-sourcemaps)
- - [PR to React](https://github.com/facebook/react/pull/26446)
- - [React.dev - Using TypeScript](https://react.dev/learn/typescript)
- - [RTK 2.0 beta](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-beta.0), and [React-Redux 9.0 alpha](https://github.com/reduxjs/react-redux/releases/tag/v9.0.0-alpha.0)
- - [The underlying mechanisms of React’s concurrent mode](https://andreigatej.dev/blog/the-underlying-mechanisms-of-reacts-concurrent-mode/)
- - [React Jam - Summer 2023 Winners](https://reactjam.com/summer-2023-winners)
-
-[00:00] **Carl Vitullo:** Hello, everyone. Thank you for joining us again for This Month in React, where we digest and discuss the latest developments in the ever evolving React and web ecosystem. Right now I've got myself the community manager of sorts for Reactiflux, and Mark Erikson. Mark, you want to introduce yourself?
-
-[00:20] **Mark Erikson:** My day job is working at Replay.io where we're building a true time traveling debugger for JavaScript. If you haven't seen it, please check it out. And in my copious amounts of free time, I work on various Redux related projects.
-
-[00:33] **Carl Vitullo:** Various projects. Yeah, that's almost understating it. Cool. Yeah, uh, we usually have Sebastian Lorber as well, but um, He's not here yet. So let's go ahead and jump in I guess.
-
-[00:44] My first link that I wanted to discuss is, Is Gatsby Dead, uh, which here is a tweet from Sebastian with a screenshot, uh of mid August, Fred Schott. " Notice that there have been zero commits to the Gatsby repo in the last 24 days." Which, for a thriving open source project, that's not a great statistic.
-
-[01:07] I know it was acquired by Netlify earlier this year, this year. Um, and yeah, there's been a lot of discussion around Gatsby as a project, I guess, and where it's headed. yeah, I don't know, Mark, any, any, any thoughts on Gatsby's status?
-
-[01:26] **Mark Erikson:** So my first caveat was I never had a chance to use it myself, but just kind of eyeballing bits and pieces, it certainly felt like next has been eating into Gatsby's, uh, market share and mind share over the last year or two, um, both due to complexities around trying to manage.
-
-[01:45] Build times and graph QL setups and whatnot with Gatsby as well as, you know, sort of the evolving ecosystem consensus that next is sort of the default way to build React apps for better or for worse. And so I'd certainly gotten the vague sense that Gatsby has been sort of kind of falling out of favor over time.
-
-[02:08] And I don't know, like, anytime I see any product get acquired by a bigger company, you just have that sense that, well, it was nice knowing you, uh, like, sooner or later it's dead. And especially when that involves, you know, companies with. VC backing and it feels like Netlify itself has been struggling a bit and on the downswing.
-
-[02:32] And so the fact that they bought Gatsby and then don't seem to be doing much with it certainly suggests to me that it's, it's basically dead at this point.
-
-[02:42] **Carl Vitullo:** And dead is always, you know, what, what does dead mean is always, uh, an open question, you know, because Gatsby still works. It's an open source, you know, self hosted product for the most part, or project, I guess, for the most part.
-
-[02:55] So yeah, I have used Gatsby on a couple of relatively large projects. I used it for my personal website. I used it for a marketing website at a previous company, which actually it ended up getting replaced by Webflow. and I, used it again on a large documentation site, which again has now been replaced by Docusaurus.
-
-[03:15] So I think that's, I think that that's kind of the the pattern I've observed is, you know, maybe four years ago, there was a lot of energy around using Gatsby, and there's a lot of excitement for it. But at least, you know, my experience was I tried to use it for some relatively large projects and stakeholders weren't super into it.
-
-[03:34] The marketing and content folk didn't really jive with the experience of authoring content. The deployment story was a little bit hairy, uh, just ended up with a lot of funky little breakages every now and again, that were a little bit tricky to debug though. I don't know.
-
-[03:52] Yeah, I, I echo your sentiments on being a VC backed company, acquire an open source project. There's always a bit of a squinty eyed skepticism. Like, where's this going?
-
-[04:04] **Mark Erikson:** Well, I mean, on top of that, they're, they're both VC backed projects. I mean, Netlify itself, even though we can probably think of it as being a relatively stable company has a whole bunch of VC backing. And Gatsby is an actual company with VC backing different sizes.
-
-[04:21] **Carl Vitullo:** You know, I, I did see that there, you know, the official Gatsby account did reply to that tweet thread we're discussing and they said, "fear not Gatsby is vital to many, to a great many of our customers updates to React 18 and Gatsby adapters are the most imminent updates, but we're also busy investing in platform primitives for a stronger Gatsby JS and other frameworks too," I don't know, they're saying it's not dead, but I, I would agree with you on the, you know, sort of the vibes I've been picking up with.
-
-[04:47] Netlify invested really hard in Jamstack and the client, you know, client side applications. And those have kind of gone out of vogue a little bit, but yeah, I guess we'll have to see what happens. I did actually connect with some Gatsby folks after Reactathon a couple of weeks ago, maybe eight weeks ago, um, about maybe doing some community work with them and they said, what I heard back was decisions are being made and we'll see what, what happens there.
-
-[05:14] So, I don't know, have to see, have to see how it shakes out, but not looking super great for Gatsby as a, the growth trajectory of Gatsby is not looking super great to me.
-
-[05:24] **Mark Erikson:** So, so you mentioned Jamstack, and I actually, I know I saw a couple articles, and I'm trying to bring up some links at the moment, uh, that very recently were talking about how the term Jamstack feels like it's either, it's also either dead, or at least has just sort of become so vague and nebulous it doesn't have a specific meaning.
-
-[05:48] Again, this is not my area of expertise, but seeing that discussion and knowing how much Netlify had tried to orient themselves around the term JAMstack, and as well as Gatsby, also suggests that the ecosystem has shifted enough that it You know, kind of points away from Gatsby as a Gatsby still usable.
-
-[06:12] Obviously, it's just not where the mindset is at this point.
-
-[06:15] **Carl Vitullo:** Definitely. It feels like the zeitgeist of Web and React has expanded beyond what Gatsby offers. Well, and what Jamstack was oriented around. Definitely.
-
-[06:27] Cool. Uh, you want to take us on our next link?
-
-## [06:30] Things You Forgot or Never Knew Because of React
-
-[06:30] **Mark Erikson:** So there's been a whole sub genre of blog articles over the last few years with people going off on rants about act is an awful library.
-
-[06:42] The people behind React are trying to sell you something that is, that is misleading. " React is horrible for web performance." And these articles are usually fairly well written. I don't generally agree with them, but it is a useful set of counterpoints to, you know, kind of our own little bubble that we have.
-
-[07:04] Alex Russell, uh, formerly of Google, now Microsoft, has written a number of articles along those lines. Um, a lot of folks who are very involved in the web components community have written articles along those lines. And so there was another article of that type that came out a few weeks ago called Things You Forgot or Never Knew Because of React.
-
-[07:26] And it's, it's a long article, um, I, I won't try to cover all the points that it makes, but it's, it's worth reading at a minimum to get kind of like an alternate perspective. On how does React fit in with the rest of the web development ecosystem? What are pain points that other people see looking at react?
-
-[07:47] Um, what are some of the lessons that we in the React develop the developer community have internalized that maybe are worth a rethought? And include some things like, um, "hooks as excited as we all were when they came out. Well, now we've now there are things like, and observables and other ways of managing data flow.
-
-[08:09] The end. So the post argues that, you know, they're faster and easier to work with. Actually, yeah, okay, this, this is a good, good one. There's a bullet point that says "nobody else is afraid of their frameworks version of useEffect." Okay, that, that's, that's probably the one point in this article I agree with the most.
-
-[08:26] You know, it argues that, you know, two way data binding, which is something that we, we in the React community have always argued against because control components, even though similar, are somehow better. It argues that two way data binding is not a thing that you should be afraid of, and, you know, goes on and lists a whole bunch of other different competing frameworks and suggests that you should look at them - affect my own personal view of React, but it's always good to kind of get that, you know, that alternate viewpoint of what are some of the strengths and weaknesses of tools and make considerations from there.
-
-[09:00] **Carl Vitullo:** I think, I think what you said about, you know, people shouldn't be afraid of two way binding. That doesn't really jive with my personal experience of using two way binding, which is that it was scary. It was difficult to debug. I didn't find it a pleasant, you know, experience for authoring code. So, I don't know, somebody else telling me, "oh, don't be afraid of it, it's fine."
-
-[09:19] It's like, well, I'm afraid of it because it was, Very painful for me in the times when I used it professionally for, you know, two years before I used React. Um, so, that did not resonate with me very strongly.
-
-[09:34] **Mark Erikson:** I'd have to go back and re read that section of the post, but I do sort of feel like programming paradigms come and go and come again and go again.
-
-[09:45] Everything's in a circle and nothing's new. But I do, I feel like there is a little bit of a sense of people forgetting why shifts in paradigms were made in the first place, you know, people getting into React today don't actually know what it was like to use Backbon or Angular 1. And so they don't understand the pain points and why React was such a big deal and so exciting when it first came out because they didn't.
-
-[10:15] Feel that pain. Now it's just, we've always had React. It's always quote unquote, "been the default", and yeah, like back that, for example, an Angular one template could mutate arbitrary data, you know, deeply nested from within a JS nested in an HTML template string, that was really hard to debug and keep track of.
-
-[10:38] And so I think, I think that's where a lot of the concern about two way data binding actually came from in the first place and we all sort of internalized and repeated this phrase and now no one remembers why we did, why did we have that concern to start with?
-
-[10:53] **Carl Vitullo:** Yeah, I, I definitely agree with that. If that reminds me of a, a line from the post where they talked about React being tech from 2013 designed for 2008 constraints, which I don't a hundred percent agree with.
-
-[11:07] But I do think it's, it's not, you know, wildly off base. I think it's, you know, there were, there were a lot of things that React was developed around that were trying to patch over issues with the platform, you know, compatibility and whatever. But, um, Yeah, I don't think that's quite accurate. I pulled out a couple of quotes that were thought provoking for me.
-
-[11:30] One of the lines was, um, "React has trained us that packages need to be built specifically for our framework," which I think I don't know if that's on React. I think that is just kind of the general trend for people. You know, if you're I'm using X framework, I would like to get something that is tailor made for my situation.
-
-[11:50] And so I'm going to look for an SDK that was built for this tool in this setting. And I do agree with the idea that it's not good to require that all the tools we use be built, you know, to be specifically cross compatible with each other. You know, it's fine to use a general purpose library in React. It doesn't need to be hooks specific.
-
-[12:13] So, yeah, I thought that was at least a decent point.
-
-[12:16] **Mark Erikson:** Have we forgotten how many jQuery plugin adapters there were?
-
-[12:20] **Carl Vitullo:** Right. There were some, yeah, right. So I, you know, I don't think that is a React problem. I think that it has been very visible in React because React, you know, as this post says is, it's the default.
-
-[12:34] Lots of people use it. And so when lots of people use it, then all of the problems that happen when any large group of people do something become very, you know, that becomes the problems of that framework that in that context. So.
-
-[12:47] **Mark Erikson:** there, there's an XKCD out there. Uh, Ooh, I think I found it. The cartoonist points out that when you're, like, when your map basically resembles a map of the population, it's not actually telling you anything useful. And so I think there is just a little bit of that with the React community, because React is so big, you sort of have a natural full distribution of...
-
-[13:12] People and situations and problems. So to be clear, like I'm, I'm not, I'm not saying that, you know, this, this original, you know, what's wrong with React article is wrong. I think it actually makes a lot of very, very good points. There, there is a little bit of a sense in which some, and some of the complaints are simply because there are so many people using React in so many ways.
-
-[13:33] **Carl Vitullo:** Right. You know, people have a lot of problems with React because there are so many people using React and they've really felt out every every possible base and edge case where you can't hit problems. Um, there are a couple of the quotes that I wanted to highlight. I think, uh, "no other modern front end framework as a stubbornly incompatible with the platform as React."
-
-[13:54] I, you know, I don't know if I disagree with that specifically, but I also think it's a little bit. It ignores the fact that no other framework attempts to be as broadly cross compatible as React. Like, you know, there's not Angular Native, there's not Vue Native. So it's, a recurring criticism of React has been incompatibility with, uh, Web Components.
-
-[14:14] And, you know, okay, sure, it's not very compatible with Web Components, but... You could argue that that's kind of a web component problem, because if React is, has successfully solved, you know, has been found to be a valuable tool for web, native, you know, mobile, desktop native, you know, all of these different contexts, like maybe it's inability to use web components is more of an indictment of web components ability to solve a problem.
-
-[14:41] **Mark Erikson:** yeah, the, the whole React and web components thing is its own very complicated topic from the off the top of my head. My general understanding is number 1, you can render web component tags from a React component, but you lose some of the, some of the back and forth and being able to pass in props correctly.
-
-[15:00] Some of that is because there's some kind of a difference between properties and attributes in web components and you can't just pass in plain objects as props the way you would from one React component to another. The React team had not prioritized trying to implement better compatibility because they had a lot of other things they were worrying about.
-
-[15:24] They kind of asked for some directions from the community. To say, look, there's like four different ways we could try to handle this, you know, handle passing the data back and forth, which one do Web Components experts think is the right option? And there were arguments back and forth for years without the web component community actually settling on a consensus for the best way to pass stuff in.
-
-[15:50] And so where things stand now, as far as I know, is someone actually has implemented quote unquote "proper compatibility" for web components in React. It's in a branch. It's either, it's either not merged or it's merged behind a feature flag and they intend to release it officially whenever React 19 comes out or like it's enough of a shift, they don't want to do it in a minor version.
-
-[16:19] So the work has been done. React's versioning strategy is totally messed up at the moment.
-
-[16:24] **Carl Vitullo:** (Chuckles) Sure. Right.
-
-[16:26] **Mark Erikson:** So it's it's multiple factors. It's React knows how to compose and web components don't. There were questions about how React should compose with web components and people and. People who cared about that stuff couldn't agree on the right way to do it and then work has been done.
-
-[16:43] React hasn't been released because focused on server side stuff and not actually shipping major versions right now.
-
-[16:52] **Carl Vitullo:** Yeah, right. They've been just maybe not top priority for them right now, which, um, yeah, I, I want to, I want to run through a couple of other quotes here that I thought were good to. I don't know, rebut, discuss.
-
-[17:04] "The worry that a front end framework might not scale is as old as jQuery and should be considered just as antiquated in relation to modern web development." That's talking about, I think, both performance and maintainability in terms of scaling. And, ooh, I do not agree with that. I don't agree that it is an antiquated idea.
-
-[17:22] Definitely there are patterns that do or do not scale very well. Um, and I think React tends to be better than average at that. Um, so like with regards to code isolation and refactorability, you know, you can certainly build things that are difficult to maintain and difficult to swap out.
-
-[17:41] But I do think React does a decent, in my opinion, better than average job of that compared to other modern frameworks. So, I don't know, just hand waving away like, "you don't need to think about scaling anymore." I don't agree with that. Sorry, buddy.
-
-[17:54] And another one. "Styling is a solved problem in several other frameworks." I'm grimacing here for those who don't are watching the camera. Um, I don't agree with that. I think, you know, okay, yes, we there has been a lot of churn on styling as something you need to do in the React world. You know, CSS in JS. Plain CSS, less or sass, okay, sure, I think now we've moved away from CSS in JS as a good idea because it has, you know, I think, I feel like the zeitgeist has moved towards, there are too many trade offs, too many negative trade offs on doing CSS in JS.
-
-[18:30] But to call it a solved problem, ooh, no, I don't, I disagree with that. Cool. Any other thoughts you want to add there?
-
-[18:36] **Mark Erikson:** Not immediately.
-
-[18:38] **Carl Vitullo:** I'll, I'll take us on to our next link. Oh, yeah. Orta here in the comments, CSS in JS is good for other platforms. That's extremely true. It is, you know, if, if your platform doesn't support CSS, then you got to find something else for it.
-
-[18:50] So that's why it's not a solved problem. I don't, yeah. (Laughs) But yeah, moving on here.
-
-## [18:57] React Server Components DevTools
-
-[18:57] **Carl Vitullo:** Uh, somebody has published a dev tools for React server components extension. I'm pretty, I think this is pretty cool. This is... maybe a first effort. This is looking, you know, I look at the, uh, the user interface of it and it looks like it breaks down... it looks like it's largely a reverse engineering of the data being streamed in, uh, sort of converting the JSON markup into pseudo HTML so that you can review it as a human a little more easily. And as well as, they call it time travel, but I think it's just kind of a log of data being sent. Looks super useful, looks a lot better than crawling the network tab to me.
-
-[19:36] **Mark Erikson:** I am always interested in newer or better developer tools. I think the fact that the React dev tools exist was one of the huge reasons to even consider picking React early on and been done on them over the years is incredible. So it's actually a little surprising to me that the React team itself hadn't prioritized trying to build tool some some form of dev tools integration for server components and that it took someone from the community trying to give it a shot.
-
-[20:10] I've said it, I've said it a number of times before, I know the React team had, like, despite all the corporate backing, has a limited number of people and a limited amount of engineering effort, but I really, really would have expected them to have put some serious planning and effort to building out DevTools support for server components.
-
-[20:28] For that matter, I know that Facebook has not been putting a lot of engineering hours into improving the existing DevTools lately. I think they had a couple engineers, Brian Vaughn, who used to do a lot of that work, left a year and a half ago and now works with me at Replay. There were one or two people working on the React DevTools code.
-
-[20:51] In the React repository, one of those people was laid off recently and so that like, I've seen a couple maintenance level PRS, but I don't think a lot of effort is going into improving the reactive tools right now. And, you know, the good news is like the, the reactive tools are there and they work, but I know Brian had a lot of ideas for improving them down the road and who knows if, or when those will happen.
-
-[21:17] So I'm actually genuinely not sure if or when we'll get official React server components integration into the React DevTools.
-
-[21:26] **Carl Vitullo:** Sure, yeah, that makes sense. Yeah, as someone who works on DevTools professionally, do you know if, I know Replay is a general purpose DevTool more on the browser than on any specific framework, but do you know if there's any interest in, I don't know, tapping into some of these internals like that on the Replay side?
-
-[21:45] **Mark Erikson:** We would love to. Um, you know, semi sales pitch time for the moment. Um, so, as I said earlier, Replay is a time traveling debugger for JavaScript. We we have you record yourself using your website with our modified Firefox or chrome for a couple of minutes, and then you can debug the recording and it's like a DVR, like, You can jump anywhere in time within that recording, see every line of code that executed, and it really simplifies, trying to dig into what happened and understand bugs.
-
-[22:19] So, right now, we have Replay integration with the React DevTools. Um, besides just like you can record any website written with anything, like it just records the JavaScript that ran. But if the site that you're recording was built with React, we can capture all the React related data. And I've actually built a lot of this integration myself.
-
-[22:44] So we can show the React component tree and in the React DevTools UI at any point in time. And we've done that because number one, we use React ourselves. Replay is a React app, two, React is the biggest framework. So it makes sense to build features for, you know, the largest target audience. We would like to build more integrations with more frameworks over time, like view angular, well, solid, you know, maybe something special for Apollo and GraphQL.
-
-[23:19] we, we would love to build these things. We, we just, we're a very small team right now and we have limited engineering time and way too many things to do, but longterm, we would love to have integrations for all the major frameworks out there so that if you make a Replay recording of a website built with one of those frameworks, you'll get.
-
-[23:38] You know, extra special visibility into what happened for sure.
-
-[23:42] **Carl Vitullo:** Yeah. I mean, developer tools, developer experience. That's a huge force multiplier. All right. You want to take us on our next link?
-
-## [23:49] My (Mark's) Experience Modernizing Packages to ESM
-
-[23:49] **Mark Erikson:** Yes. So, uh, continuing the self plug here, earlier this month, I wrote a very long blog post entitled my experience, modernizing packages to ESM.
-
-[24:01] This was kind of the story of all the shenanigans I've had to go through this year, trying to update the Redux related packages to have proper ES module compatibility, whatever the heck that means. And I'll be honest, like, it has been an extremely painful and frustrating effort and year trying to do that.
-
-[24:23] And I've learned a lot. There's a lot of things I wish I hadn't had to learn. And I'm still not done. I am still messing with this stuff, even within the last week, I was trying to work on these things. And normally when I write these blog posts, I try to write them to say, Here's all the stuff I've learned, and here are the correct answers that I've learned.
-
-[24:44] And in this case... It's more of a, here's all the places I've banged my head against the wall, trying to figure things out. I still don't know the correct answers, but at least describing the stuff that I've gone through will hopefully benefit other people who are trying to deal with the same things.
-
-[25:03] When I, when I write blog posts. I usually have a decent sense of how popular they might get, you know, I'm not trying to optimize for page views, but you know, like my posts on React rendering or Redux versus context. Okay, like, it's very obvious people are going to have a, an interest in those. I really did not expect a lot of people to be interested in a post about how to publish libraries correctly, but it's actually gotten a fair amount of attention.
-
-[25:29] And there's been a lot of other folks who are, you know, building libraries who have, you know, replied or messaged or talked to me and said, "Oh, yeah, like, I'm running into the exact same problems myself", or "I totally sympathize and understand with all the different pain points you've gone through."
-
-[25:46] So, you know, there are a bunch of different factors, um, trying to define the package export setup is really hard. Trying to figure out what file formats and whether you do you pre bundle your JavaScript, do you pre bundle your TypeScript types? What about file extensions? Um, but then another complicating factor has been React server components. You know, it turns out that you can't do things like even, you know, importing and using React hooks in a server components environment.
-
-[26:16] Which makes it really hard for libraries like Apollo and RTK Query that can be mixed mode. Like they have a plain JavaScript aspect, but they also have a React Hooks aspect. And normally you would be able to use that on both sides. But now, you know, Next is throwing errors automatically if you even try to import. React hooks, it's doing static analysis.
-
-[26:44] And so for us as library maintainers, trying to figure out like, how do we ship packages that are going to work without just exploding yet another environment has been really, really hard.
-
-[26:58] **Carl Vitullo:** Yeah, I don't have a lot to add there as someone who doesn't maintain any major libraries, but yeah, my, my, my outsider perspective has been that it was already quite difficult to support, you know, ES modules versus CommonJS versus, you know, like, I don't know if Bower is still something that needs to be actively supported.
-
-[27:20] **Mark Erikson:** One of the questions I had was, you know, should I still be shipping UMD modules to support like the, the script tag in a Codepen use case? And I, you know, I, I finally settled on, eh, probably not, but let's ship an additional ES module file that has been pre compiled to production usage. You could do a script tag type equals module and use it as an ESM module in the browser.
-
-[27:49] **Carl Vitullo:** Oh, sure. Oh, yeah. Interesting. I guess that was one use case that ES modules has been meant to replace. So, okay. Interesting that that has maybe come to fruition now. Interesting. Pulling a comment from chat. "I still ship UMD more often than ESM for my own use cases. It's a big learning curve." Definitely big learning curve is definitely maybe an understatement.
-
-[28:12] **Mark Erikson:** Yeah, one of my biggest complaints is that there is no single authoritative comprehensive guide to how to correctly publish a library with all the tools and settings and correct file formats and stuff that you should include. So everyone's just sort of figuring this out for themselves and borrowing from everyone else.
-
-[28:30] **Carl Vitullo:** Yeah, actually, even, you know, you're saying there's no comprehensive guide on how to do it. There's not, I don't even think there's a comprehensive guide on what environments are out there, you know? Like, what do you even need to think about supporting? Yeah, that's interesting.
-
-[28:43] **Mark Erikson:** I mean, that was, that was part of the point of my post.
-
-[28:48] Was, like, literally, like, here's all the stuff that I'm having to consider.
-
-[28:52] **Carl Vitullo:** Yeah, Orta with the good chat comments here. "Most recent strategy has been use Deno." I've, that is not the first time I've heard use Deno as a good strategy for publishing a library. I've heard that it has made local development, or rather it's made the transition from local development to usable package published to the, uh, to the npm just easier to do.
-
-[29:16] Um, and it's not something I've tried, but yeah, that's been an interesting thought that's been lodged in the back of my brain just using a different environment that makes it easier to do the right thing, even in other environments. That's interesting.
-
-## [29:31] Remix DevTools
-
-[29:31] **Carl Vitullo:** Well, I'll, I'll move us on here. I think, yeah, one more dev tools update the.
-
-[29:37] Remix DevTools has a new release this month, uh, 2. 0. Um, I, I have not used this yet, uh, but I do, I, I have a couple of Remix projects, Remix based projects. So, um, I'll have to poke around here and see what kind of stuff it adds.
-
-[29:54] Looks like it gives you better inspectability of like your routes and your pages. Um, so yeah, the. I think debugging got more complicated with the, you know, server client, I don't know, seem in between there. So the value of platforms or the value of framework specific developer tools has gone up a lot more with that. You know, how do you have something that's aware of the server as well as the client and can tell you more information about what all is going on there?
-
-[30:24] So yeah, remix developer tools 2. 0 something to check out.
-
-[30:28] **Mark Erikson:** Yeah, Jessica Sac hs actually recently sent me a link to a demo video for the, the, the Nuxt framework and like it, you know, it's a Vue based equivalent to Next, roughly, and it apparently has some kind of a dev tools plug in that looks pretty similar to what I'm seeing in the, you know, the, the gift demos for this, this remix one, you know, listing all the routes and the options.
-
-[30:54] So that, yeah, that looks extremely useful.
-
-[30:56] **Carl Vitullo:** Yeah. Even just surfacing how it's being all parsed out. You know, now that. I both remix the next, add that layer of file and folder names having influence on the behavior of the code you write in them. Uh, it's just, it's, it's reasonably indirect and it's a little, it, I have found it confusing at times, you know, if you have to debug, like, why isn't this route showing up?
-
-[31:19] Like, the only way to do so is futzing around with the file names, which. It's not great. It's not great inspectability. So better developer tools, at least saying this is how the framework is understanding what you've given it. That seems like a big help. Uh, cool.
-
-[31:35] **Mark Erikson:** Uh, so there was a really good post actually technically back in July, but I think got listed more recently called everything I wish I knew before moving 50, 000 lines of code to React server components.
-
-[31:45] It had a really nice, some really nice diagrams of, you know, kind of like the shift from client server behavior to React server component behavior, how server components, you know, actually kind of manage the tree, a lot of different code snippets, and information on, like, how would you actually start using server components in a code base.
-
-[32:06] You know, one of my, one of my biggest complaints about the server components rollout has been that, you know, there, there isn't a migration story, there isn't really good advice on how to start adopting these. And frankly, this is about the best information I've seen on, on that topic. So I, I thought this was an excellent, excellent post. Uh, it also had a link to a talk from the Reactathon conference that was done a couple of months ago, which discusses, when should you even consider using server components?
-
-[32:36] And that, that talk from Jeff Escalante was actually just a little, just a little on the intentionally skeptical side. Like it points out that server components are very useful for some kinds of apps. But not so much for others. And so it's not, you know, server components are not a silver bullet that you should just slap on everything, but instead actually kind of consider if it makes sense for your use case. So this was a very, very helpful resource, I think.
-
-[33:05] **Carl Vitullo:** I haven't read this in depth, it's very long. I think they said it was like 5500 words. It's rivaling one of your posts, Mark ( Mark laughs), but it, you know, just scanning through it, it reminds me of some of the resources on, you know, architecture and sort of summarizing behavior, and like the perspective that went into designing server components.
-
-[33:25] It reminds me of some of the write ups on, uh, or that like the next JS team has put up about that. Um, but I think a lot of those have been more from the maintainer side of things of like, here's why we did it, here's why we made this the way it is. It is. And this seems much more anchored from a pragmatic point of view of like, we don't care about how it works specifically, but here's how we used it, and here's the pitfalls we found.
-
-[33:52] Uh, so yeah, definitely agreed that this looks like a really phenomenal resource. Uh, and referencing something we talked about earlier, uh, one of the headers is CSS in JS is a non starter. Uh, so yeah, CSS in JS doesn't work in server components. So One reason why the React ecosystem has been moving away from that.
-
-[34:14] But yeah, I mean, if CSS in JS is the only way to get native styles working. Oops, there's a tension, can only use it, can only use CSS in JS in native environments and cannot use it at all in server environments. So that was like fragmentation to me.
-
-[34:32] **Mark Erikson:** A lot of that.
-
-[34:32] **Carl Vitullo:** Yeah, not ideal, but yeah, definitely a great read.
-
-[34:35] Definitely a great resource for anyone looking at how to get server components involved in their app, especially if it's not a greenfield project, and it's trying to bring it in as an optimization to bring it in as an improvement to an existing application.
-
-## [34:50] Expo Release Week
-
-[34:50] **Carl Vitullo:** All right, I guess, uh, let me move us on to our next link.
-
-[34:53] Yeah, I don't have one single link here, but Expo did a release week shipping a whole bunch of new features. Um, let me, I've got like eight links here and I don't know how to quickly dump them all, but there's Expo preview, a fully customizable builds on EAS build.
-
-[35:12] Um, I'm not really familiar enough with Expo. I haven't used it on a, you know, a production app, so I can't speak too much to all of these different acronyms and features, but fully customizable builds, I could certainly imagine situations where you might need to have finer grain control over how your application gets built. So that seems valuable.
-
-[35:33] There's a proof of concept for Expo CLI DevTools plugins. So continuing with the DevTools theme, feature preview of single sign on, feature preview of EAS update. So I guess that's the build for, you know, a fresh version of an app versus releasing an update to an existing app. Use updates API for Expo updates, which I it sounds related to that, updating.
-
-[36:00] There was an interesting one that caught my eye was Expo SQLite integration. They They reference convergent replicated sqlite, which is, that's really interesting. So it talks about having multiple different sqlite databases that have independent writes and then get merged together. And they had a little demo video showing multiple to do apps that are being kept in sync.
-
-[36:28] Um, I, I have a soft spot in my heart for SQLite, um, and a soft spot in my heart for CRDTs, um, which I'm blanking on the, what that stands for, but replicated data types. Um, conflict free data types. Conflict free replicated data types. That's it. Uh, yeah. So I have a soft spot in my heart for those, local first, merged data kinds of tools.
-
-[36:57] So it's interesting to, it'll be interesting. I think that could be a large unlock for people building mobile apps.
-
-[37:05] **Mark Erikson:** Yeah. I mean, just, just skimming down the list. It looks like they're putting a lot of effort into the, the build and deploy story for X for Expo apps.
-
-[37:13] **Carl Vitullo:** Yeah. And I know that there's been, you know, over the years, there's been some various churn on the React Native story for updates or for builds and updates, I guess, you know, for a long time, one of the advantages of React Native was you could update the JavaScript and change the behavior of an app without doing a full app store release, which I think is still true to an extent, but like policies have shifted on that.
-
-[37:37] And it's like, Uh, it's I know that Apple doesn't like that generally because they want to have firm control over what apps do. So if you're able to change what an app does outside of their review process there, they look at you suspiciously for that. So, uh, but yeah, definitely, you know, my, my recollection is that four or five years ago, Expo was really great for what it could do, but it was a very limiting sandbox.
-
-[38:02] If you try, if you needed capabilities that it didn't offer out of the box. You're kind of screwed. You had, uh, it was a little bit like Create React App in that where what it did was really great, but it didn't do everything. And if you needed more, you had to eject and then you're on your own. Um, but that is not how I understand the story of or, you know, the experience of using expo today.
-
-[38:24] From what I hear, if you're building React Native right now, you start with expo because it just does makes it so much easier for you. So cool to see so much investment going into it still.
-
-[38:33] Got another link for us?
-
-[38:35] **Mark Erikson:** Uh, that's all the, all the major ones I had to talk about. I think at this point, we're sort of onto the lightning things, although I could, I could talk about some of the lightning things in more depth if we wanted.
-
-[38:45] **Carl Vitullo:** Yeah, we got 15 minutes. Let's do a, let's do a, maybe I'm trying to think of a slower lightning round, but let's do a pseudo lightning round here.
-
-## [38:53] React Prod Source Maps (!!)
-
-[38:53] **Mark Erikson:** So, um, this next one is, And on these next two are things that I both have a very personal stake in. So, over the weekend, I published a new package called ReactProdSourceMaps.
-
-[39:09] And this is going to take a little bit of background and explanation. Um, so, JavaScript libraries Are normally published to NPM code that has been backwards compiled to, you know, yes, five syntax for compatibility with IE 11, although that's finally starting to change and more libraries are shipping modern JavaScript.
-
-[39:30] And then when you build your application with next or Vite or expo or create React app or whatever. All your application code and your nice original js or tsx files all get mangled together, mashed into a bundle, minified, and shipped to production. And when we want to debug our applications, we, like, we need a way to reverse map from the final mangled minified code back to the original source files that you had on disk.
-
-[40:03] And so bundlers and build tools use a technology called source maps, which literally contains the exact original source files that you had on your computer when it was built and defines how they got transformed into the final minified lines of code. So for example, uh, App bundle dot JS line one column 700, 000 through 700, 010 to do list item dot JS line 23 you declared your to do list item component.
-
-[40:39] And so that's how Browse and browser dev tools and other tools can show you what looks like the original files when you try to debug either a development or production application. And the problem is. Specifically, that the React libraries have never shipped with source maps. For their production build artifacts.
-
-[41:02] So if you build a React app in dev mode, React has a development build where the bundle is still readable. It's got comments and white space and original variable names. And if an error gets thrown, you can see a stack trace, and you can at least read the function names inside of React. One of the nice things about React has always been that most of the time you don't have to worry about how it works inside.
-
-[41:28] We can treat React as a black box. The important thing is understanding that, you know, it's, it's the mental model. If I set state, it re renders. If my UI is wrong... Look at the data, look at the rendering logic, trace the data back up the tree to where it came from. So most of the time, you don't have to debug inside of React.
-
-[41:49] But there are times when you do. Okay, maybe that's more applicable to library maintainers or people like myself and Brian that are working on developer tools at Replay. The problem is when you try to debug a production build of a React app. React has only shipped the minified, the prebuilt minified bundle.
-
-[42:09] They don't have source maps for it. And it's hard enough to understand what's going on inside of React. When you can actually read the original source code, it is impossible to understand it when all you have are single character variable names and everything's been mashed together. So, uh, about four months ago.
-
-[42:27] I took about a week, and I figured out how to modify React's build pipeline so that it will actually generate source maps whenever you, whenever they build React. And that PR has been sitting there, and Dan Abramov and I were going back and forth on reviews for it, and as far as I'm concerned, it's there, and it works, and it should just be merged. Dan had one small reservation, and I never quite convinced him that... It's fine. It works. Merge it. So it's still sitting there. And hopefully it will get merged at some point in the near future.
-
-[43:02] But the next problem is that even once it gets merged, the React team hasn't released a stable version of React since 18.2 came out a year and a half ago. Which is kind of frustrating. They are putting out canary builds, and Next is using those canary builds, but we haven't had a new stable release in a year and a half. So if and when a, that PR is merged and a new stable release comes out, then, you know, React 18.3 would have source maps.
-
-[43:31] But there's nothing for React 18.2 or 1 or 17 or 16. What I did over the weekend was I literally checked out React 18.2's tag from the repository and I backported my build pipeline changes. I made sure that I could build the exact byte for byte identical copy of React 18.2 production. And then I copy pasted my build pipeline changes to generate source maps over to that.
-
-[44:04] And it works! And the next problem is that, okay, so let's say that, you know, I have a Vite app and I'm using React 18.2. Well, I've installed React off of NPM, didn't include any source maps. I can download the React 18.2 source map I generated. But that doesn't help the app bundle source map that I just made.
-
-[44:31] I figured out how to use a couple different source mapping libraries, and I've written a CLI package that will... You give it the file path to the source map for an app bundle, and it looks to find a copy of React dom listed in the in the files, and it replaces The source map of the minified file with the source map of the original bundle before it got minified.
-
-[45:00] So that as far as the source map bundle is concerned, it has the original looking React source code available to debug. And I was able to prove that I could like serve up that modified V app and I could stick a break point inside the place where React renders function components and it worked and it paused there and I could inspect everything that was in scope with the release of this package, uh, I have not actually done it yet, but in theory.
-
-[45:30] Anybody who has a React app right now that uses React 18.2, 18. 1, or 17. 0. 2 could add a post build step that uses my package, correct React source map in their app bundle. And the other thing that I would like to do with this... So I've been talking about, you know, my day job at Replay ought to be able to take those same source maps and automatically insert them into our backend so that if you made a recording of a React app and didn't have the original source maps, we could automatically insert them anyway, as you debug the recording, like, I'm sure we can do it.
-
-[46:09] It's just a matter of convincing the backend team that we should.
-
-[46:12] **Carl Vitullo:** Yeah, I, I'm thinking of, I'm thinking of like Sentry and things too. All these other
-
-[46:17] **Mark Erikson:** Yeah. The, yeah, the, the, the Sentry folks have been following what I've been doing and they are very excited about this.
-
-[46:22] **Carl Vitullo:** Yeah, no doubt.
-
-[46:24] **Mark Erikson:** So I, I realize this is sort of a niche thing and not everyone is going to get immediate benefit from it, but like, I truly think this is something that a good bunch of the React community will benefit from because I was able to do the work to generate these just once.
-
-[46:41] **Carl Vitullo:** Wow. Okay. So I knew that you had done this. I knew you had, you know, published a thing, but I didn't realize that you were, it had done, it had taken so much, I don't know, effort, like, wow, going in and modifying source maps for... taking the apps, source maps, and then replacing the right parts of them, so the unrelated source maps still work, but you also get all the React ones.
-
-[47:06] Like what? That's actually crazy. That sounds if I got, okay. If I got to that point, I would say, wow, no, I'm not doing that. That sounds like a pain in the butt.
-
-[47:15] **Mark Erikson:** Like the thing is the actual logic is like 20 lines of code because there is a library that I found that will do the source map swapping. Like the majority of the logic is just import this library. The existing application source map, and then it gives you a callback for every file that it sees listed. And so I'm literally just saying, is this file's name React dom. production. min. js? And if so, figure out what version of React it is, load the right sourcemap and replace it.
-
-[47:49] **Carl Vitullo:** Good job, holy crap, that's wild. um, I think that's all I have to say on that. That sounds incredible. That sounds super valuable. And especially if, if Replay and Sentry can both take advantage of that and just do it on behalf of everyone. That sounds incredible. If everyone using either of those products can get source maps for free without. Or source maps for React for free without doing anything without changing configuration or anything.
-
-[48:15] Wow. Okay, cool. Nice. Big project.
-
-[48:19] **Mark Erikson:** So that's what I did my last two or three days.
-
-[48:21] **Carl Vitullo:** (laughs) That's that's a productive two or three days. Very nice. Cool. Okay. Well, I don't know how lightning that round was, but.
-
-[48:29] **Mark Erikson:** Not very, but hey, it worked.
-
-[48:31] **Carl Vitullo:** It worked. It was interesting. It was good.
-
-## [48:33] Official React+Typescript documentation
-
-[48:33] **Carl Vitullo:** Cool. Uh, I'll move us on though. Um, Yeah, React. Dev now has official TypeScript documentation. Thank you, Orta, for bringing this home. We discussed this last month when it was still a draft PR, but it has been merged, it has landed, and we now have official documentation on how to use TypeScript with React. Absolutely incredible. We're not going to comment on how long React and TypeScript have been out and available and the delay between... It being widely used and it being documented, but we have it. It's great. I'm glad we have it now.
-
-[49:11] **Mark Erikson:** It looks amazing. Orta, you did a fantastic job. Thank you.
-
-[49:15] **Carl Vitullo:** Uh, Mark, you got another lightning round? Well, you said you have a hard stop in three minutes. So if we want to blitz through some of these.
-
-## [49:23] Redux Toolkit 2.0 beta
-
-[49:23] **Mark Erikson:** Yep. So really fast, uh, mentioned this before, but Redux Toolkit 2. 0 is still in beta. We would really like people to try it out. And then just this last week, I published React Redux version 9 alpha, which has the same kind of, you know, ES module packaging changes. That, you know, I've been trying to apply to all our different libraries. Um, so again, we would really, really like people to try these out.
-
-[49:48] Tell us what breaks that shouldn't be breaking and give us feedback on things like the, you know, the new features and Redux toolkit 2. 0, pry them out. Tell us what you like or don't like so we can, you know, make any changes before they go final.
-
-[50:03] **Carl Vitullo:** All right, now's your chance. Get that feedback in. Uh, you want to run through your last link there?
-
-## [50:09] The Underlying Mechanisms of React's Concurrent Mode
-
-[50:09] **Mark Erikson:** Yep. Uh, and then the last item I have is, there was a really, really good article called The Underlying Mechanisms of React's Concurrent Mode. And again, this is not a thing that most people need to necessarily worry about because it's inside of React. I always appreciate articles that explain how stuff is built, what are the technical constraints.
-
-[50:29] And so this was a really good look at how React has implemented the ability to split up renders into multiple pieces and delay parts of it.
-
-[50:37] **Carl Vitullo:** Very nice. Um, I, I just have one lightning round link myself. Um, Sebastian and I were judges for React jam, which is a, it was a hackathon put on by a startup called rune that.
-
-[50:51] Is a I don't even know how to describe it, but it's a it's an app that you can play other games in. Uh, it's like a multiplayer games app. It's a little bit like discord activities if you've used any of those, uh, they did a hackathon building games with React. Um, so. Yeah. Sebastian and I judged it. We played a bunch of games.
-
-[51:13] They were pretty fun. And yeah, check it out if you like games and React and stuff built games built with JavaScript.
-
-[51:20] **Mark Erikson:** And on that note, I do unfortunately have to bail out for another meeting, but it's been a good discussion. And yeah, I think there's a lot of good stuff happening in the ecosystem.
-
-[51:29] **Carl Vitullo:** Yeah. Yeah. Always, always many new things.
-
-[51:32] Cool. Uh, Mark, thanks for joining me, uh, everyone in the audience. Thanks for listening along.
diff --git a/src/transcripts/tmir-dec-2023.md b/src/transcripts/tmir-dec-2023.md
deleted file mode 100644
index 60d3265..0000000
--- a/src/transcripts/tmir-dec-2023.md
+++ /dev/null
@@ -1,442 +0,0 @@
----
-title: This Month in React (December 2023)
-date: 2023-12-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- Quick hits:
- - [[00:55](#layoffs-news)] [layoffs.fyi](https://layoffs.fyi/)
- - [[01:37](#state-of-react-native-survey-closes-jan-5)] [State of React Native runs til Jan 5th](https://stateofreactnative.com/en)
- - [[01:50](#adobe-💔-figma)] [Adobe and Figma abandon merger](https://www.figma.com/blog/figma-adobe-abandon-proposed-merger/)
-- [[02:07](#react-native-073)] [React Native 0.73](https://reactnative.dev/blog/2023/12/06/0.73-debugging-improvements-stable-symlinks)
- - [New debugging docs](https://reactnative.dev/docs/debugging)
- - New Debugger, [give feedback here](https://github.com/react-native-community/discussions-and-proposals/discussions/733)
- - [Bridgeless mode](https://github.com/reactwg/react-native-new-architecture/discussions/154)
-- [[06:33](#redux-toolkit-20-and-supporting-libraries)] [Redux Toolkit 2.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0), [Redux 5.0](https://github.com/reduxjs/redux/releases/tag/v5.0.0), and [React-Redux 9.0](https://github.com/reduxjs/react-redux/releases/tag/v9.0.0)
-- [[11:37](#xstate-v5)] [XState v5](https://stately.ai/blog/2023-12-01-xstate-v5)
-- React Server Components updates
- - [[17:49](#react-core-team-panel-on-server-components)] [Frontend Should Embrace React Server Components](https://thenewstack.io/react-panel-frontend-should-embrace-react-server-components/)
- - [[18:47](#ben-holmes-react-server-components-from-scratch)] [RSCs from scratch video from Ben Holmes](https://twitter.com/BHolmesDev/status/1735701191823151239)
- - [[19:16](#storybook-adds-support-for-rscs)] [Storybook for React Server Components](https://storybook.js.org/blog/storybook-react-server-components/)
- - [[19:45](#dan-abramov-blogs-again)] [Dan’s “Chain Reaction” post](https://overreacted.io/a-chain-reaction/)
- - [[21:52](#daishi-katos-oss-prototype-rsc-framework)] [New RSC-first framework, Waku](https://github.com/dai-shi/waku)
-- [[29:29](#stylex-released-by-meta)] [Introducing StyleX](https://stylexjs.com/blog/introducing-stylex/)
-- React docs discussion
- - [[32:50](#documentation-for-the-use-hook)] [Recent core docs pages updates](https://github.com/reactwg/server-components/discussions/7)
- - [[35:08](#dan-abramovs-ama-on-bluesky)] [Dan Abramov React AMA on BlueSky](https://bsky.app/profile/danabra.mov/post/3khbvuwanqx2h)
-- Lightning round:
- - [[42:16](#-requesterimpairment-an-ietf-joke)] [An HTTP Status Code, Requester Impairment (joke??)](https://www.ietf.org/archive/id/draft-richardroda-420requesterimpaired-02.html)
- - [[43:18](#-jules-blom-on-flushsync)] [More Than You Need to Know About ReactDOM.flushSync](https://julesblom.com/writing/flushsync)
- - [[44:56](#-react-fights-you-can-have-with-your-team)] [React Fights You Can Have With Your Team](https://www.bekk.christmas/post/2023/13/react-fights-you-can-have-with-your-team)
- - [[45:33](#-an-interview-with-kyle-mathews-on-gatsbys-story)] [Building React Framework Gatsby](https://oss-startup-podcast.launchnotes.io/announcements/episode-118-building-react-framework-gatsby)
- - [[46:41](#-tanstack-router-v1)] [TanStack Router v1](https://tanstack.com/router/v1)
-- [[47:19](#what-will-happen-in-2024)] Discussion: what do we think will happen with React and the ecosystem in 2024?
-
-[00:00] **Carl Vitullo:** Thank you for joining us for December. I'm sorry about the audio quality of this month, I am on the road and I forgot my headset this time around. This is This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
-
-I'm Carl, I'm a staff product developer and freelance community manager at Reactiflux. Here, the Discord for React professionals. Mark, you want to say hey?
-
-[00:24] **Mark Erikson:** Hi, I'm Mark Erikson. My day job is working at Replay. Io, where we're building a time traveling debugger for JavaScript. And in my copious amounts of spare time, I work on Redux, and boy, have I spent a lot of time doing that lately.
-
-[00:37] **Carl Vitullo:** Yeah, you've got a lot of, releases to announce.
-
-[00:40] **Mark Erikson:** I think we're both recording this one while we're on the road, too.
-
-[00:43] **Carl Vitullo:** Yeah, I am coming, I am genuinely coming to you live from, my mom's basement. So this is a funny recording this time around.
-
-I'll start us off with a couple of just quick hits of little news.
-
-## Layoffs news
-
-[00:55] **Carl Vitullo:** I'm thinking of starting a new segment just talking about layoffs and trends in the job market for tech, that seems pretty relevant for news discussion. December has been trending down per layoffs.fyi, which is a great resource, highly recommend. It's trending down; fewest layoffs by number of companies running layoffs since April of 2022, and it's been, qualitatively it's felt a little bit better, but last year December was among the lowest of the months for layoff and January went way through the roof, so fingers crossed that doesn't happen this year. I think that'll be a pretty big indicator for tone of 2024.
-
-## State of React Native survey closes Jan 5
-
-[01:37] **Carl Vitullo:** There is a state of React Native survey that's currently running. It went live a couple weeks ago and runs until January 5th. So, if you use React Native, definitely check that out. Highly recommend, giving your feedback.
-
-## Adobe 💔 Figma
-
-[01:50] **Carl Vitullo:** This is sort of related to our field, but, Adobe and Figma had been doing a very large merger. I know many, many people in the React ecosystem work with people who work with Figma. So I thought I'd give that a shout out.
-
-## React Native 0.73
-
-[02:07] **Carl Vitullo:** On to the real news. I'll start us off with our first link, which is react native 0. 73. New pretty big feature release. They've got a lot of good improvements coming out here with improvements to debugging, a couple of relatively nitty gritty technical details like Support for symlinks, which is a huge problem if you use symlinks in development, and not a problem at all for anyone else, which would include me.
-
-But, the new debugging section looks really good. It looks like they've put a lot of energy into making debugging a lot better, which, as someone who has developed a product with React Native, debugging was a painful experience, so that's nice to see. They've got a new experimental, and Kind of buggy debugger.
-
-They ask you to give feedback, but yeah, it looks like they've got a couple of nice Maybe smaller improvements, but like, for instance, apparently, this is not something I had noticed while developing, but you send console. Logs early in the like, bootstrap process for starting up a new, for starting up a React Native process as you launch the app.
-
-If you previously, if you had run console logs very very early in that launch process they would just silently get dropped. You would not see them and obviously that makes debugging a lot harder. So they have updated the way that the debugger works to capture those and Ship them out once the Once the console has been set up and attached.
-
-So that alone is a huge improvement. I think that'll be nice. Another relatively large breaking change. I think they are deprecating the at type slash react native package. This is good news It's because they have Moved those types into the React Native package itself. So it's now first class types, it's included in the package.
-
-You no longer need to use the at types package. So that's awesome.
-
-[04:08] **Mark Erikson:** Experience is zero. Like I've, I've attempted to run one or two tiny React Native projects. Mostly just sussed out tiny bits of Redux stuff, and that's it. One observation out of that that I do think is interesting is that it feels like React Native has jumped on board TypeScript more than the React core has.
-
-One is that they, I think, React Native projects now ship with TypeScript set up by default, it sounds like. You know, this example here of moving the types into the core, whereas with the actual React and ReactDOM packages, the React types are still maintained separately. Now, the React types packages are now semi officially maintained by people affiliated with the React team, but there's still that difference of not actually shipping it with the actual React packages.
-
-Now you can also caveat and say this is a good thing because there have been tweaks and improvements to the React types packages that have come out in the last year and a half. Whereas there have been zero official stable React package releases. So there is actually a little bit of benefit to having those decoupled.
-
-[05:22] **Carl Vitullo:** Yeah, well, hey, maybe if they had been forced to React release in order to update the types, they would have stuck in a couple of, small improvements along the way too.
-
-[05:30] **Mark Erikson:** One other React native thing to toss in here, we'll mention it later, but Dan Abramov was doing an AMA over on BlueSky one of the various Twitter clones that are out there.
-
-And one of the questions was. You know, Dan, now that you're working on a product that is built with React Native, what are your opinions? And so per way that down that discussion, he had a couple thoughts about it's in some ways, it's great. In some ways, it actually feels really, really difficult and hard to use.
-
-But there were some interesting thoughts and discussion there.
-
-[06:03] **Carl Vitullo:** My general sentiment seems to be shared by a lot of people that I've known have worked pretty deeply with React Native is it was really great, it let me do all sorts of stuff, I never want to use it again.
-
-I think that's maybe just a reflection on the fact that mobile development is harder than web. And if you're trying to do both web and mobile development, React Native is pretty great, lets you do a lot more cheaply. Because you can actually share a substantial amount of the code between apps.
-
-But, it's got its own headaches too. You want to take us on, Mark?
-
-## Redux Toolkit 2.0 (and supporting libraries)
-
-[06:33] **Mark Erikson:** Yes! So, my big news, kind of on a personal and professional level, I've been teasing this one for months, but on December, I finally hit the button and shipped Redux Toolkit 2. 0. Along with major releases for all the other Redux related packages.
-
-Redux Core Version 5, React Redux Version 9, Reselect Version 5, and Redux Thunk Version 3. This has been a massive undertaking on so many levels. I started working on this slew of major versions at the start of the year. And Initially, the primary goal was to update the packaging to better improve ES module CommonJS compatibility.
-
-That turned out to be even more of a nightmare than I expected it to be. We added a number of features, we deprecated, we removed a bunch of deprecated options, there were TypeScript updates. And then the only, like the main reason we were able to even able to get these releases out this year was because we ended up deferring any major changes to the RTK query data fetching layer until sometime next year.
-
-People have asked for lots and lots of new features and options and changes, like to address those at some point, but that's just a giant undefined amount of work. Like, we, we, we have so many issues and feature requests that it's going to take weeks just to go through them and collate the list of what people are asking for, then take time to analyze those, do the design work, figure out how all these options are going to interact, and build them.
-
-And I can see that if we waited to release 2. 0 to include all those RTK query changes, It would be this time next year. Got a lot of help from one of the other primary maintainers, Ben Durant. And then, there's a guy named Arya who just left a comment in the chat who has done a ton of work on Reselect in the last few months. And we actually made some major updates to Reselect as well.
-
-One of the biggest ones was We changed the default memoization strategy for Reselect. Reselect has always had its own little built in memoization function that does a bunch of reference comparisons against all the values that are passed into the selector function. And the problem is that also defaults to a cache size of 1. If you call it three times in a row, and you alternate the arguments, like A, B, A, then it's not going to see the same arguments twice in a row, and it's not going to save the results. It's going to keep recalculating things every time.
-
-This always felt like kind of a bad developer experience situation. And so I ended up swiping crash implementation based on weak maps directly out of the React source code. React has a new memoization function built in called cache, and I literally copy pasted that code and made use of it and re select.
-
-[09:54] **Carl Vitullo:** Oh, very cool.
-
-[09:56] **Mark Erikson:** Yeah, it's buried down in the library, and I think it may actually be now listed in the docs. So, we did some testing on it, and we concluded that it's at least as fast in terms of like raw comparison performance.
-
-Um, in a sense, it has like an infinite cache size, but on the other hand, that could also be referred to as a memory leak, depending on how you look at it. Ultimately made the decision that this was worth actually including. And made that switch in Reselect version 5.
-
-So, I shipped all these literally the day before I went off on a trip to a conference, plus a vacation. So it was in theory Out of my head before I went off on this trip. Unfortunately, one of the truisms of maintaining and publishing packages is that it doesn't matter how many alphas and betas and release candidates you put out and how much you beg people to try them out, you will always get a whole bunch of new bug reports the minute after you publish the new versions live because now people are actually using them. And they're using them in ways you didn't anticipate.
-
-The biggest couple things I'm seeing are some lingering TypeScript update issues where there's things are just changed a little bit in ways that people weren't expecting. I am very, very happy to have this out the door.
-
-[11:18] **Carl Vitullo:** You've brought up the alphas and the betas in the last couple of months.
-
-Glad to, glad to hear you got it shipped. That's awesome. I obviously don't have anywhere near the level of access, or familiarity with you, so I can't, I don't even feel like I can respond to that appropriately, so. (laughter from both) I'm just going to roll us on to our next one.
-
-[11:36] **Mark Erikson:** Moving on!
-
-## XState v5
-
-[11:37] **Carl Vitullo:** Moving on! stately, or XState v5 has been released.
-
-I don't know, I don't think I would call it a competitor to Redux, but it does also deal with state. It deals with State machines, which Redux is one way. You can also implement state machines in Redux. It's not, I don't know, would you say, would you say Redux models things as state machines? Or would that be, would you say that's inaccurate?
-
-[12:05] **Mark Erikson:** David K. Piano would point out that Redux is typically half of a state machine. Um, the distinction being that a true, with a true state machine, first you look at what state am I in now, and then you decide, okay, if I'm in state A, do I want to respond to action or event? And in Redux, you typically just respond, you respond to the action in the reducer unconditionally.
-
-And so like, David actually contributed an example to the Redux style guide a while back, where it's like the first thing you would do in a reducer to make it a true state machine is switch state. Status, and then look at the action type. Whereas with a typical Redux reducer, you just, oh, here's the action.
-
-I handle it regardless of what the values are originally.
-
-[12:58] **Carl Vitullo:** That's a cool and precise distinction. I like that. I have always like had a place in my heart for XState, but I've never really used it in a project. Um, they've had a. A bunch of really phenomenal developer tools that help with designing state machines.
-
-You know, as a state machine library, they've written tools so that you can visualize them and write them in a visual way and then copy paste the code out. So I have actually used those tools in a Redux context because most of the projects I've worked on have been in that. But I've, I've been following them, following along with their development for a number of years.
-
-Really appreciate the work that they do. I'm pretty interested to see a couple of these. It looks like one of the big changes here is that everything is an actor, where actors have their own internal state, can send and receive messages or events from other actors, and can create other actors. So it sounds A little bit like a reducer, sort of like in the RTK slices, reducers kind of sense.
-
-And I think that's, been a place where I've struggled with modeling application state as a state machine is you end up with lots of little sub states. You know, each feature kind of has its own state. So, this seems like a pretty cool mental model. Code model for getting a little, maybe, maybe more precise control over how your state flows.
-
-You know, Mark, like you said, Redux is half of a state machine. So I don't know that I could articulate a specific benefit for using an entire state machine. But I do know that using the developer tools, the designer the state machine designer tools to figure out how I'm going to write my code has been really powerful.
-
-I haven't constrained myself to actually using specific state machines, but even just going through the exercise of enumerating all the states, enumerating the transitions, evaluating what data I need to pass along with the transition to make a state change self contained and isolated, um, uh I have found super valuable.
-
-They've got some cool future plans listed as well. Um, I, one that I really like, the first one is a toPromise helper function for converting actors to awaitable promises. That sounds really cool. If I could just say like, transition this state, and when it's done, keep going. Sounds pretty nice. Seems like a nice way to make asynchronous write code that responds to them in a more iterative way.
-
-So, um, I think that sounds pretty neat.
-
-[15:36] **Mark Erikson:** Yeah, as someone who also maintains a state management library, I, I just generally appreciate the amount of effort and work it took them to get this release out the door, um, I, I know that trying to implement their TypeScript support has been really, really complicated and they've got an absolute genius working for them. Matush Brzezinski, whose, whose handle is, andreasrake, has done a lot of work around their TypeScript support and trying to design APIs that are sufficiently flexible is a really, really tough task.
-
-So I, I understand and appreciate the amount of effort it took them to get this out the door. One other, one other plug, I don't know if this is even a thing they've released yet, but something they've been looking at is the idea of being able to analyze real world code and describe it in a state machine format, kind of like AI powered, being being able to use To like take like an arbitrary Redux reducer or maybe even like a use effect setup and have it analyze that and generate a state machine like description of it so that you can then use some of those graphical developer tools to visualize the code.
-
-That's a separate thing from the XState library itself, but I know that's something that the stately company is working on.
-
-[17:00] **Carl Vitullo:** That sounds incredible, actually. Yeah. That's like the dream of self documenting code. State machines are just so easy to read in the abstract. I've always really struggled to go back and forth between state machine, real code.
-
-So if I could have something do that for me, ooh, that's pretty cool.
-
-Alright, let's move on though. Mark, what's your next link? Or set of links.
-
-[17:24] **Mark Erikson:** So my, my caveat for a lot of this month's discussion, as usual, is that between travel and holiday stuff, I'm, I'm even less plugged into what's actually been going on in the ecosystem this month. This section especially is a collection of things that look interesting, but I haven't had a chance to go through them myself. So a few different updates and discussions related to React server components.
-
-## React core team panel on Server Components
-
-[17:49] **Mark Erikson:** A panel at the React Summit New York conference in, mid November where some members of the React team and Next. Js and a couple other ecosystem folks had a discussion about the state of React server components and whether they're worth adopting now and how are they used and how do they work. Ironically, I was at the conference.
-
-I did not have a chance to watch that panel either live or recorded later, but this article is a fairly good summary of the discussion in that, um, so there were, there were a number of folks involved in that, including Andrew Clark, one of the React core members, Tom Preston Werner, who's currently working with RedwoodJS, Ben Holmes, Josh Camot, and a couple of the React devrels.
-
-Curious about sort of like the, I guess like the semi official view of what's going on with server components. This would probably be a really good discussion to watch through.
-
-## Ben Holmes, React Server Components from Scratch
-
-[18:47] **Mark Erikson:** Speaking of Ben Holmes, so he's very involved with the Astro framework, but he also does a lot of videos on his YouTube channel where he explains things. He did a larger video called React Server Components from Scratch, about 20 minutes where he talks about server components and does a lot of drawing on the whiteboard and tries to explain how they work and what's going on and knowing Ben's ability to describe things that should be very useful.
-
-## Storybook adds support for RSCs
-
-[19:16] **Mark Erikson:** The storybook tool for documenting has actually added React server component support. Frankly, I have no idea how they've even implemented this at the technical level, but I can see this being a very useful thing. Like if you're writing server components, you want some way to be able to document them and make use of them, but they have all these requirements around being able to fetch data. So in some way, they've implemented support for using server components.
-
-## Dan Abramov blogs again
-
-[19:45] **Mark Erikson:** Dan Abramov had done a lot of blogging in 2018 2019 on his site overreacted. Io, and Dan is a very deep thinker, he does a great job of explaining things, and he'd written a number of posts that kind of talk about how does React work conceptually, how do you approach modeling things with use effect, And he'd really spent his last two to three years entirely focused on rewriting the React documentation.
-
-So he hadn't blogged at all in a couple years. Well, now that the new React docs are finally out, and Dan has left Facebook and is now working on the BlueSky app, he's finally had a little bit of time to sit back, And do some thinking. And he's put up a new blog post. It's a little bit on the same principle of his talk from RemixConf earlier this year.
-
-He did a talk at RemixConf where he was like, what if React had always been server first? What would the evolution of React have looked like there? And he actually did a whole live coding demo where everything was like late 90s, IE6 themed. What kind of follows along, or this blog post kind of follows on that same principle.
-
-So it's kind of like, what if we were sort of building React from scratch in a server centric world, and we need, and components could return async data, or async results. How would you even write the code that looks at the return values of the components and unwraps them recursively so that we can wait until the data is actually ready?
-
-And he never actually uses the word server components in this blog post, but if you read it, With kind of like between the lines, he's actually explaining this is the mindset behind how server components are implemented conceptually and under the hood. And I think he said this is meant to be the first in a series of blog posts that kind of digs into this, into these concepts.
-
-## Daishi Kato's OSS prototype RSC framework
-
-[21:52] **Carl Vitullo:** This is pretty early stage, I think, but somebody has put together, Daishi Kato.
-
-[21:59] **Mark Erikson:** He created Jotai and Valtio and now maintains Zustand, and he's also written a dozen other React slash state management utility libraries.
-
-[22:13] **Carl Vitullo:** I recognize his name because you had mentioned him in previous episodes we've recorded.
-
-But I could not have given that comprehensive list, so thank you for that. Daishi Kato has written a minimal React framework for, that uses React server components. So, this is the third, sort of React server components from scratch that I've seen. I think this is the first that I've seen that is Positioned as a framework that you can use.
-
-So, like you mentioned, Ben Holmes did his From Scratch video. I always appreciated Ben Holmes videos. He, he, he says he's the CEO of Whiteboards at Astro, which I, I appreciate. He, he does a good job with DevRel. And I have not yet watched his video. Like he said, travel, holidays, I'm behind. But, so his was the second.
-
-Last month we talked about somebody who wrote a really great, very long, comprehensive, I have a blog post about implementing React server components on their own in isolation. It looks like server components are now starting to filter out from only Next to now people have started to really wrap their hands, wrap their brains around them and start experimenting with them on their own.
-
-So I think, to me, that is a really big step in this open source process. We've been talking about React server components always with the caveat of like, "Oh, I don't really know. I haven't played with it." Because of how complex and undocumented the programming model has been so far. So seeing some of these people really dive deep and get their hands dirty and produce things is really good.
-
-So starting with a blog post, then a video, now a framework by three separate people. The community expertise in React Server Components is really ratcheting up, pretty cool to see.
-
-[24:05] **Mark Erikson:** I can also vouch that RedwoodJS has been putting a lot of effort into trying to implement Server Components for their framework as well.
-
-I know they did a blog post a couple months ago where they said we're all in on Server Components. I had a chance to talk with Tom Preston Werner at a conference a couple months ago where he was talking about some of the complexities where in a lot of cases they're having to go into the guts of Next and look at the implementation and try to figure out like how much of this is going What anything integrating with server components would need versus how much of it is specific to Next's internals.
-
-And I've seen some of the discussions from some of the other Redwood engineers as they're trying to figure out how to put all the pieces together. So there is activity. I don't know how fully along Redwood's implementation is yet, but there is very definite. Effort being put into trying to, trying to productionize that.
-
-[25:00] **Carl Vitullo:** I don't know. When did we, when did we start seriously talking about React server components? Do you, do you have a sense for that? It feels like it's been all year.
-
-[25:07] **Mark Erikson:** I feel like almost three years ago was when the first video came out. It was either two or three years ago. And, and like it sat around for a while. And then we finally started seeing the integration to Next after, Sebastien and Andrew moved over to Vercel.
-
-[25:23] **Carl Vitullo:** This is all building upon the primitives that were added in Suspense, right? Which I know that, I just saw some discussion about, it's been five years since Suspense was first unveiled.
-
-So this is, I think, to me, that's a testament to just how difficult the work that they're trying to do is. We can talk a little bit more about what this unlocks later, um, I have a link coming up in the lightning round. Well actually maybe I'll just bring it in right now.
-
-Guillermo Rauch did a, um, a great post talking about, or in response to, what's the difference between PHP and Next with the, this. Satirical, kind of shit talking of like, "Oh, JavaScript is finally catching up to PHP 20 years ago, haha." I thought he had a really good response, basically talking about like, Yeah, we do have, on the face of them, they are pretty similar, but some distinctions are there's out of order streaming.
-
-Like you can piece together the HTML by order of importance, not You know, linear order of HTML and pre rendering versus rendering on the client, control over that, which I, I haven't used PHP seriously in close to 10 years at this point, so I can't comment too much about what the capabilities are, but you know, I remember trying to do mixed server client rendering in PHP and it was a lot of writing JavaScript code in the HTML of PHP and then like jumping in and out of PHP tags to like render pass data in or whatever. Or you write your JSON endpoint. And so like, yeah, you can do those things, but it's, it got real messy real quick.
-
-Or it, it at least wasn't, it wasn't a pit of success. It was not easy to get something that was maintainable and great. That felt good. Felt. Solid and robust. So, yeah, I think there are, I know people talk a lot about unnecessary complexity or just people like to bash on JavaScript, people like to bash on web and client and frontend, but I do, I really believe that the React server component stuff is Genuinely pushing the envelope of what's possible in a real and deep way.
-
-I, like I, we don't, we don't have a, FrontEnd doesn't have a academic discipline, you know. There's no computer science researchers writing JavaScript. That is genuinely how I think about What a lot of the React core team is doing. Like, were this an academic discipline, this would be PhD thesis, postdoc.
-
-Actually, you know what? Like, it's not an academic discipline because it is well beyond the complexity that would be in an academic setting. This is post graduation, you've got your Ph. D., you're now working in industry, advancing the state of that industry. And I think that is truly what the React core team has been doing for my entire career.
-
-It's one of the reasons I have a lot of trust in them, is they keep executing, and they keep, for an entire ten years, they have stayed at the bleeding edge, and they have set the norms that everyone else in the industry follows. Okay, it's taken them five years to start realizing the vision that they set out with Suspense.
-
-Well, you know what? They're doing it. They keep, it's hard, it's really difficult to feel out all the edge cases, it's really hard to communicate to all of the developers what you're supposed to be doing, but man, they're doing it. They are, they have continued to do it for my entire career, and I just have huge, huge amounts of respect for them.
-
-[29:11] **Mark Erikson:** Yeah, they've always had a very long term vision of how they want to build things, and they've kept chugging along towards that goal.
-
-[29:19] **Carl Vitullo:** Bit of a, bit of a ramble there, bit of a rant, but, I was thinking about it over the last week or so, in prepping for this. Just, the work they're doing is really cool.
-
-## StyleX released by Meta
-
-[29:29] **Carl Vitullo:** Okay, but under our next link, facebook released, something that they first talked about a number of years ago, Stylex, a CSS and JS tool that, that they use at Meta. Sorry, not Facebook, Meta. I don't have a lot to say on this. Um, I know I'm introducing it, but it's a CSS and JS library. Kind of feels like the moment for that has, um we, we had a lot of experimentation on that.
-
-And it feels like generally we, as a, an ecosystem, the React subset of web development, have settled on CSS and JS not being the best solution. Just, some some of the trade offs are Increasing the size of the JavaScript bundle, where JavaScript is more expensive to load and parse than CSS. So it tends to add a lot. Relative to non more traditional CSS. It tends to add more startup cost than other methods. Mark, do you remember when they first announced StyleX?
-
-[30:31] **Mark Erikson:** It, there was a, there was a conference talk about it at ReactConf in either 2018 or 2019. And they didn't give many details. They just kind of said, here's an overview of the tooling that we use internally at what was, what I guess was still then Facebook and kind of what it does and how it works at a high level.
-
-The community was aware that existed. But there was no information on the actual internals or anything that you could use. So there was, it was always sort of this, this hint of this exists. It was only this year that you could actually, they were, they started actually moving towards being able to release it open source.
-
-And so now it's finally out. Um, yeah, the couple bits that I know about it are as, as the comment just said, it's primarily compile time, not runtime, so there's always trade offs there in terms of the amount of dynamic behavior it can have. I believe it compiles down to Atomic CSS, so part of the sales pitch is that as the app grows and you have more and more components using certain styles and certain rules, the growth of the size of the CSS stays lower than it might with other approaches.
-
-[31:48] **Carl Vitullo:** That does seem like a genuine advancement of the state of the art of CSS and JS. Um, especially, pulling, that was always the challenge with stuff like Emotion, um, or styled components was, I think you could wire it up to Webpack or limited other build systems, such that it would extract the, the styles into CSS.
-
-Some of them could, some of them couldn't, bit of a mix and match, but okay, that, that being, The major downside of CSS and JS, if they, since they have built it as a compile time extraction of styles, that's avoiding the biggest, worst trade off. So that sounds pretty cool.
-
-Positioning this as extremely large code base styling tool, so focus on performance at scale sounds exactly like what CSS and JS needs. I think that's all. I got a say on it. You want to take us on to the next news item?
-
-## Documentation for the use() hook
-
-[32:50] **Mark Erikson:** Moving us along, a couple of discussions around docs. So, I've, I've actually been whining for a lot of this year that okay, it's great that the new React doc site is available, it has a wonderful tutorial, but it just feels like there's so many other pages that need to get filled out for it to be fully useful in terms of some of the API references and usage guides.
-
-And I I had some discussions with some of the React dev rels this year. So they actually just posted an update that collates some of the recently added or updated docs pages that they've been working on. And it looks like a, and kind of the, some of the theme here is they've been working on documenting A lot of the new APIs that exist around server components and server actions.
-
-So we actually have some documentation for the ambiguously named use hook, which I'll be honest, I still don't fully know the status of this. I guess the docs page says it's only available in canary and experimental builds. So I guess you can use it with Next, and that's, that's kind of about it. But they've also documented the new UseFormState, UseFormStatus, and UseOptimistic hooks that you would use with the, and with server actions.
-
-They've documented the useServer and useClient, not sure what the word is for them, markers that you would put in files so that the bundler knows how to parse those. They've added some more details on the useTransitionHook, they've talked about the cache memoization API that I talked about earlier.
-
-They've documented the HTML form tag. In a sense of, here's how you can use this in a React app and actually write kind of more browser native forms. They've added a page that talks about thinking about the UI as a tree, and they're working on some additional documentation. So I'm a big docs person, and I really, really appreciate seeing them continue to actually work on these and not just leave the site as it was after the new tutorials came out.
-
-## Dan Abramov's AMA on BlueSky
-
-[35:08] **Mark Erikson:** Along with that, Dan Abramov is now working on the BlueSky Twitter clone app as his day job. And he recently did an AMA over on BlueSky. People had a whole bunch of good questions over there. I mentioned the one earlier about people asking What are your thoughts on React Native now that you've actually used it?
-
-Um, there were some questions about React batching and will React ever get ported to Rust? There was one in there that was, What do you think should happen to create React now? And Dan's comment was, It would be nice if it was turned into a build time server components framework. I don't expect that to actually happen, but it's an interesting train of thought of what could we do with the name and the toolset if we wanted to.
-
-[36:03] **Carl Vitullo:** Dan has gone a little quiet the last, like you mentioned earlier, he's talked about going all in on the docs. He also mentioned some challenges he experienced with his own perfectionism trying to get it just right, which is he attributed as part of the reason the docs took so long to come out. Sounds like he may have gotten a little burned out too.
-
-[36:22] **Mark Erikson:** Oh, yeah. Oh, yeah.
-
-[36:24] **Carl Vitullo:** Burnout is real. Burnout is tough. So it's nice to see him in a new context, working on a new It sounds like he's enjoying getting his hands dirty working on an application rather than staying at the high level of just talking about React and developing it from the core. Um, I think it might, seems like he's enjoying it.
-
-It's nice to see him get back into writing and community discussion a little bit more. Um, this has been a really good thread. I'm, I'm also a big fan of Blue Sky. I have been enthusiastically looking for an alternative to Twitter. So I am optimistic that Dan being a more prolific poster on the platform will help it succeed.
-
-Glad to see a few more of these. Definitely recommend going through the thread and just reading a bit. There's a, there were a couple of really good questions and answers. One that I saw and responded to, so I'm gonna toot my own horn a little bit. Somebody asked about, um, React and, what's the Like, Module Federation, What, Microfrontends?
-
-[37:33] **Mark Erikson:** yeah. Those are probably too
-
-[37:36] **Carl Vitullo:** Yeah, okay, so somebody asked about micro frontends and module federation and how React would work with it. I know that's been a subject of debate for a couple of years. It's sort of come and gone over time, ebbed and flowed, but I think that's a really big challenge. I think it's, maybe we'll see it come back a bit with React server components as those settle down, but I think the real challenge there is CI and CD, the build and deploy process for micro frontends.
-
-Which I think is, it solves a real problem for large teams, but it's difficult to implement. Tends to be a DevOps discipline rather than a library or product. Just, it's too deeply embedded in every step of the build, the development, the deploy, testing. Just too tricky.
-
-Coming back to that React Working Group discussion on GitHub, um, that you started us off with. It's really nice to see some of the Some of what they're looking to invest in more deeply. I've always thought that React worked really well once you get your head into the right mindset of, once you get the right quote, air quotes around right, mental model for how to think about UI. In the way that React would like you to, it unlocks a lot of really powerful possibilities.
-
-So, in the past, those a lot of those best practices and descriptions for the mental model, I have gained mostly through reading a combination of gists. On GitHub, and Twitter threads, and reading code from other people and seeing how they solve problems.
-
-Which is just not a very repeatable process. Like we have a learn page with many links that you have collected, Mark. I think that's been a One of the better ways to gather body of knowledge, but it's nice to see, it's nice to see some of that, some of those best practices working their way more into the docs.
-
-I think that a lot of them have been in flux for a long time, a period of years as we were figuring out first hooks and then like, what is suspense? How does it work? Oh, now it's server components. How do those work? What are they? It feels like a very long journey to where we are right now that is It's nice to see things stabilize and settle down a little bit more.
-
-It's, I look forward to see what the docs are like in 2024.
-
-[40:04] **Mark Erikson:** I actually had a back and forth with Rick Hanlon from the React team in mid November where I was getting a little worked up and complaining that You know, the React docs really need to have more details about how React renders. You know, that's always been one of my biggest and most appreciated blog posts, is the article about React's rendering behavior.
-
-I actually got called out a little bit by Rick, who linked me to certain sections of the docs that actually have some of the information that I was complaining didn't exist. I had looked through some of the early betas of the docs, and to be honest, I hadn't really gone back and dug through them since then, and so there were definitely some pages that called out some of the specific nuances that I thought should be in there that I didn't realize had actually been added.
-
-Like even talking about kind of like the existence of like the render versus commit phase. It is sort of scattered through some of the different learning material pages. It's not like in one single start to finish usage guide or how this works page. But there is actually a lot more of that material in the current docs than, certainly in the old docs, and more than I had actually given it credit for.
-
-[41:22] **Carl Vitullo:** It has been a bit of a challenge to figure out how to stay on top of what changes are coming out in the docs. I note that the last blog post on react. Dev was in May. So, I think you can be a little forgiven for finding it difficult to stay on top of what changes have happened.
-
-I'm not even sure how you would. Because I don't think they get published as releases in GitHub.
-
-[41:45] **Mark Erikson:** Well, no, the React docs should still be a public repo, um, it used to be React. Js slash React. Js dot org, they might have renamed the repo, but the repo exists, so I assume I could watch the repo for PRs.
-
-[41:59] **Carl Vitullo:** That's a high noise source of input though, where's the bi monthly summary of here's all the stuff we've shipped. So anyway whatever. They got more, they got some more DevRel folks. We'll see, we'll see what's going on. Anyway,
-
-[42:13] **Mark Erikson:** cool. Lightning round.
-
-## ⚡️ RequesterImpairment (an IETF joke??)
-
-[42:16] **Carl Vitullo:** Lightning round. I don't quite comprehend the implications of this, but IETF, um, The task force that owns HTTP has put out a draft of an HTTP status code to report requester impairment.
-
-I don't quite know what that means. They talk a little bit about AI requesters.
-
-[42:38] **Mark Erikson:** It's a joke.
-
-[42:39] **Carl Vitullo:** Is it a joke? They put out a joke in December?
-
-[42:42] **Mark Erikson:** Look at the status code.
-
-[42:44] **Carl Vitullo:** RequesterImpairment 420. Okay, this is straight up a joke? It's a very serious looking joke.
-
-[42:50] **Mark Erikson:** Have you ever seen HTTP status code 418? I'm a little teapot.
-
-[42:54] **Carl Vitullo:** But that was released on April Fool's Day, like 20 years ago.
-
-[42:59] **Mark Erikson:** Yeah, I don't know why this one would have been released. But I'm pretty sure this is a joke of some kind.
-
-[43:05] **Carl Vitullo:** It smells like a joke. It's RequesterImpairment 420 Yeah. It smells like a joke, and I don't know how to interpret this. Maybe it's a joke.
-
-Move us on, take us away.
-
-## ⚡️ Jules Blom on FlushSync
-
-[43:18] **Mark Erikson:** A blogger named Jules Blom, who has put out a number of posts in the last year that talk about some very specific technical nuances of React rendering, which is a topic that I always appreciate. And so Jules put out a post recently that talks about a relatively new React API called FlushSync.
-
-And this exists because of the change in how React batches updates. Prior to React 18, React would automatically batch renders if you called set state more than once in an event handler, but it would not do it if you did it in some async function. And so React 18 switches it so that React now always batches any updates that occur in the same event loop tick.
-
-But there might be times when you need to force a render immediately right now after a given setState call. So it's flipping the default behavior, and so now you need a new escape hatch from that behavior. So there's a new API called FlushSync, which says, okay you've queued up one or more setState calls.
-
-Force React to actually render right now, and then continue from there. And I know Ryan Florence had a tweet about this recently, where he says he uses it instead of useEffect in a lot of cases. So you might have like a click handler that does a setState call. And then calls FlushSync to make sure it gets updated right away so that you can do some kind of like a focus or scroll change.
-
-So, this is a useful article talking about what it is and why you would want to use it.
-
-## ⚡️ React Fights You Can Have With Your Team
-
-[44:56] **Carl Vitullo:** Thank you, next. I like this one. It's a little silly. A Christmas post. React fights you can have with your team. I was just reading this and all of these are fights that I have had with my team over the years. So default versus named exports.
-
-Do you call a file in a, a feature folder index tsx, or the same name as the folder? How do you name props, regular functions or arrow functions? I, it, it was, it was just a, a, a great comprehensive list of all sorts of fights that I've had over the years on teams. So, appreciated it. Um, okay, I have a second one queued up here, so I'm just gonna run with it.
-
-## ⚡️ An interview with Kyle Mathews on Gatsby's story
-
-[45:33] **Carl Vitullo:** Um, there was a good podcast recently interviewing Kyle Matthews about building Gatsby. It just, just, it seemed like a very honest and open discussion of the lifespan of Gatsby from Inception to V2, V3, and Acquisition. Reactiflux and Gatsby share some ancestry. Kyle Matthews used to be pretty active here.
-
-At one point he had admin permissions over a subset of channels that Gatsby used as their official chat. So I have a soft spot in my heart for Gatsby. And it's nice to see some discussion of inside baseball, how did it work, how did it grow, why was it made. I, I, something I thought was pretty interesting is he explicitly talks about making it for himself for blogs and small sites.
-
-One of the big complaints is that Gatsby didn't really scale beyond those, so hearing him talk about how he made it for that for himself, it's like, okay, that kind of makes sense then. Yeah, worth a listen. It's like an hour long. It's a podcast. It's a reasonable time investment.
-
-## ⚡️ TanStack Router v1
-
-[46:41] **Mark Erikson:** All right, and last lightning round item is that the ever prolific Tanner Lindsley has released TanStack Router v1. I know Tanner has had a lot of opinions about Things like, how does a router integrate into a framework, type safety, and data fetching and loading.
-
-So, this, I could not sit here and list the differences between TanStackRouter and ReactRouter. But, Tanner has a track record of creating libraries that are very useful, very well thought out, and he puts a lot of effort into them. So, probably worth taking a look.
-
-## What will happen in 2024??
-
-[47:19] **Carl Vitullo:** And Mark, you had a great idea. For an end of episode discussion, what do we think will happen with React and the ecosystem in 2024?
-
-[47:29] **Mark Erikson:** The biggest one that I'm so very much looking forward to and excited about is the React Forget compiler. So the initial mentions of it were well over two years ago. It was kind of quiet. We got tiny little hints and a couple updates. You know, over the last year and a half. And then finally, late this year, we got a couple big updates from the team members who were building the Forget compiler.
-
-Sathya did a talk at React India, and then Joe and Mofe did a talk at React Advanced in London. It sounds as if React Forget is real, it works, it is being used in production at a couple of different metasites, and it sounds like the hard part And now it's the other hard part of trying to fully productionize this and make it ready.
-
-You know the overall goal is not just about It's not just about removing the need to have dependency arrays in your use effects and your use callbacks or whatever. It's also about actually optimizing when it's re rendering. And there's been lots and lots of talk about signals across the JavaScript ecosystem in the last two years.
-
-You know, lots of different frameworks are adopting signals. And the React team has said You know, we, we might end up making the use of signals as like an internal primitive, but we don't really think that they provide a lot of value as a user level piece of code. And so their approach is, let's build a compiler.
-
-And you write your React code exactly the same way you always have. You don't have to think about anything special. You don't have to use special value get, set calls. You just write your components with plain data and eventually, someday, This magic compiler will make things faster. And it sounds as if someday is hopefully relatively sooner.
-
-Obviously there's no actual release date. You know, the, during the talk at London, Joe and Moffay said it'll be available when we think we've got it fully productionized and are ready to support it. I'm hopeful that it will actually come out in 2024.
-
-[49:42] **Carl Vitullo:** I like that. Good prediction. Well, I don't know a prediction, but
-
-[49:45] **Mark Erikson:** Wishlist.
-
-[49:46] **Carl Vitullo:** Wishlist, sure.
-
-I have always taken an approach of no expectations. I prefer to just let the news wash over me and See, I think, I think I find predictions less valuable than responsive, being responsive to what comes out. Updating a mental model periodically. I'm very excited to see how server components continue to shake out.
-
-That's maybe a kind of a cop out answer, the obvious choice, but it's true. I, I, I, I think it's a pretty new paradigm for programming, um I just had my big rant earlier about respect for the core team and how they're pushing the industry forward. Yeah, I'm really interested to see how that continues to shake out.
-
-It's really cool to see momentum build. In the community, in the ecosystem. I think it's complicated, I think it's hard. I think 2024 might be when we hit critical mass on that and start seeing a lot more powerful applications of server components more generally.
-
-[50:51] **Mark Erikson:** another thing that will hopefully happen next year is another stable version of release of React.
-
-Because the current one is 18. 2, that came out well over a year and a half ago. You know, I've voiced my complaints about React's versioning strategy a number of times this year. They put out the blog post about the canary release idea, which has resulted in a lot of arguments about, well, what does it mean that this feature is stable for frameworks, not actually stable and usable by anybody else?
-
-And I think, it kind of goes back to what I said earlier about, Pre release versions. It is very true that for most developers, like even myself included, a fully supported, stable, semver backed release It might as well not even exist, both in people's minds and in the willingness of people to actually use certain features.
-
-So there's been a lot of debate and frustration over the way that like, Next is using pre release and experimental versions of React in order to implement things like the app router. And I'm very hopeful that we will actually get another stable version of React that Actually pushes things forward also in a selfish way because then it would actually have my source maps generation built in the latest Info that I have just trying to keep an eye on the update work team is actively talking about React 19.
-
-Andrew Clark has made a couple comments on Twitter I've started to see some PRs go through in the React repo that are actively starting to clean up deprecated and dead features. Um, they removed a completely unknown variation of how you could define components as a module object. A couple months ago, there's actually a PR up right now that would remove the legacy context system.
-
-You know, the old this. Context in, in class components. I would not be surprised if we don't get an 18. 3 minor release. And instead, the next stable release is 19. 0, with a number of deprecations and removals and things cleared out. Very curious if that would also finally include the better web component support.
-
-It was PR'd probably almost two years ago, and has been sitting in experimental builds. And has resulted in lots of people whining that it's not available yet. I would certainly hope React 19 would be out by this time next year. If and when it does come, I would expect it to be removing a lot of deprecated options.
-
-The question is, how long will it take to come out? And will there be any minor releases before that? I can also safely predict that the React subreddit and Reactiflux will continue to be flooded with questions of Should I use Next versus React? Should I use Next versus Remix? Should I use Next versus Vite?
-
-Should I use Redux versus Context? Da da da da da da da da da da.
-
-[54:09] **Carl Vitullo:** The never ending cycle of questions. Yeah, we're, we're going to be doing a, a thank you to the React core team soon before the end of the year. Years and years ago, we used to do an annual like end of year thank you to the core team, which was really lovely.
-
-And we just fell off and stopped doing it. So we're going to be trying to revive that now. And it's been six years since the last time we did that. Last one was in 2017. It was a good excuse to go back, pull up the web archive, and see how the communities have grown. So I pulled up like this the subreddit, the React. Js subreddit, Reactiflux, and Thackoverflow.
-
-And it was pretty wild. All of those have 10x'd in size. The 2017, there were 60, 000 questions on Stack Overflow. The subreddit was at 30, 000 members. Reactiflux was at 25, 000 members. And now, Reactiflux is at 220, 000 members. Subreddit's at 300, 000. And we've got 600, 000 questions on Stack Overflow.
-
-Just absolutely ludicrous growth. Literally 10x. On each of those communities, over the last six years. Pretty wild. React's taking over the world. Or has taken over the world.
-
-All right, well thank you everyone for joining us on this end of year, weird liminal space between Christmas and New Year's when nothing counts and nothing is real.
-
-We'll be back on the last Wednesday of January. Here in the live stage of Reactiflux or back in your podcast feed as soon as we can. With the end of the year this one might Come out a couple days late. We'll see. I'm not sure what my editor is gonna be up to. Ha ha. If you see anything newsworthy, definitely let us know in the Tech News and Reads channel of Reactiflux.
-
-We do source Links from there, definitely pull from discussion and things as well. Thank you so much for joining us. I'll see you next month.
diff --git a/src/transcripts/tmir-june-2023.md b/src/transcripts/tmir-june-2023.md
deleted file mode 100644
index 109e562..0000000
--- a/src/transcripts/tmir-june-2023.md
+++ /dev/null
@@ -1,391 +0,0 @@
----
-title: This Month in React (June 2023)
-date: 2023-06-28
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-
-
-[00:00] **Carl Vitullo:** Thanks for joining us for this month's, This Month in React, for June, where we recap and digest recent develop elements in the ever evolving React and web ecosystem. We are your hosts. I am Carl Vitullo. I'm a staff software engineer and community manager for Reactiflux.
-
-[00:17] **Mark Erikson:** Hi, I'm Mark Erikson. Most folks might know me as the maintainer of the Redux family of libraries, and my day job is at replay.io, where we're building a true time traveling debugger for JavaScript.
-
-[00:28] **Sebastien Lorber:** Hello, I'm Sebastian and I am known for Docusaurus as being the maintainer and also the creator of the This Week in React newsletter.
-
-[00:38] **Carl Vitullo:** Yeah, I feel like we've had a lot of news this month, so how about we jump into it?
-
-# StackOverflow Developer Survey
-
-- [Stack Overflow Developer Survey 2023](https://survey.stackoverflow.co/2023/)
-
-[00:43] I am starting off a little broad here. The StackOverflow developer survey for 2023 came out and I feel like it had a lot of, I don't know, this is just such a like seminal survey in the programming world generally. And I guess, from the survey I was seeing just how much of the programming world is specifically web and React.
-
-[01:04] So it's, I thought this was interesting to see. This is good to cover for, even though we, this is not specifically about React or Web narrowly, but Yeah, I mean, for example, they had a bunch of questions about what technologies you use and of the top 5, 3 of them are web technologies.
-
-[01:20] 65% of respondents use JavaScript, 38% use TypeScript, half use HTML and CSS. So a lot of good insights in here. Some good examples on hybrid versus in-person work, like only 16% of software developers are currently fully in person. Well, 16% of respondents to the StackOverflow survey.
-
-[01:40] They had some good salary information. US, UK, India. For a front end developer in the US, average reported salary was 140,000., Same title in the UK was 71, same title in India was 15. So one thing I love about this survey is just seeing, sort of a benchmark about the industry as a whole, or at least the portion of the industry that makes heavy use of StackOverflow, but always fun to see and definitely good things to read here.
-
-# Server Components
-
-- [Next.js App Router Update (dev server, docs, etc)](https://nextjs.org/blog/june-2023-update)
-- [Why do Client Components get SSR'd to HTML?](https://github.com/reactwg/server-components/discussions/4)
-- [Remix + RSC POC](https://twitter.com/ryanflorence/status/1663587026384584704)
-- [Redwood: All in on RSCs](https://community.redwoodjs.com/t/redwoodjs-next-epoch-all-in-on-react-server-components/4967)
-- [React WG - RSC from Scratch. Part 1: Server Components](https://github.com/reactwg/server-components/discussions/5)
-
-[02:08] **Mark Erikson:** Nice. Kind of a similar theme, so general big picture news. The biggest topic of discussion that I continue to see in between Twitter and Reddit and wherever else is React Server Components. And there's been a few pieces of information as far as technical updates and helping people understand how they actually work.
-
-[02:31] First off the NextJS folks put up a blog post that gave an update about the NextJS app router and its current functional status. Why they built it, how it supports incremental adoption. It's stable, but they are still working on improving it. They talked about some of the plans they have for improvements, like improving the speed of the local development server, working to make fast refresh faster using the the Turbopack build tool and getting that from beta to production ready.
-
-[03:07] They also talked about trying to improve the docs. They've done a lot of work over the last year to improve the NextJS docs specifically. We'll talk about this more in a little bit, so there really aren't, isn't any documentation about React Server Components in the actual React Docs.
-
-[03:25] The only real official documentation you can find is in next's documentation site. So the blog post talks about like, we're, we're working on that as well. There were a couple other pretty good related links. Dan Abramov has a discussion thread in the one of the React Working Group repos that talks about why client components get converted to html.
-
-[03:49] He also did a very long, deep dive thread, which to be honest, I still haven't even had time to read through where he tried to rebuild the function and some of the basic functionality of React Server Components. From scratch, and I've seen a lot of folks say that this was really helpful in understanding the mental model as well as the technical details of how Server Components work.
-
-[04:13] And I think I've seen a, a couple people try to take the information that Dan wrote in this article and turn it into tutorial videos as well. And then I know that a couple other React related frameworks besides next are looking into using Server Components, and that includes both Remix and Redwood.
-
-[04:37] And then there's at least a few other folks experimenting with Server Components in different ways. Daishi Kato, who's the maintainer of the Zustand and Valtio and Jotai libraries has been doing his own little spin on a server component based framework. So there's a lot of motion going on around the ecosystem in relation to Server Components.
-
-[04:59] **Carl Vitullo:** Yeah, definitely a lot of motion. I hadn't seen the Redwood discussion of Server Components. And I tried to check out Remix Server Components proof of concept, but it doesn't look like there are very many details there at all yet. That, you know, proof of concept tweet from Ryan Florence is just a, you know, it's just Lighthouse, like, cool, okay. I guess it works well, but what, like, what does it look like?
-
-[05:22] **Sebastien Lorber:** There is actually a few links that you can find on on GitHub with repositories where the, the implementation is being worked on. So you can follow this on on GitHub. I don't think it's Ryan Florence for working on it, I think it's Jacob Parish or something like that, that is working on on this implementation.
-
-[05:40] **Carl Vitullo:** Yeah, I guess that makes sense. If you're trying to follow along the implementation, tracking the GitHub directly is where, where that actually happens.
-
-[05:46] Yeah. More, more drama, more resources, more details trickling out. Server Components are definitely still actively evolving and I guess they probably will be for a while still.
-
-[05:57] **Mark Erikson:** We'll get to that part when we circle back around.
-
-[06:01] **Carl Vitullo:** Yeah. Cool. Yeah, I hadn't seen the React Server Components from scratch.
-
-[06:05] That's a, that's a really good resource. That reminds me of Dan Abram's talk. What was it? React in an alternate dimension. Looking at IE6, so definitely feels like he's trying to anchor the React Server Components conversation, sort of going back to fundamentals, like not chasing trends, not sort of saying like, "here's where the path has evolved. Here's the current state," but saying, "let's look back at what web development used to be. Let's look at what it is right now. Let's try and find a, not just a local maximum, but maybe a, you know, universal maximum."
-
-[06:38] I guess I appreciate that framing a lot. It's nice to not just be reactive and see this is what people have been doing recently, this is how the community and ecosystem are evolving, but really trying to go back and say, "okay, this is what we're trying to build. How does that make sense in the current moment, and how does it make sense in previous moments as well?"
-
-[06:59] So I I, I like that. You know, I, I've said that I defer a lot to the React core team because they have not let me down to the past, and I like that. I think that's a good framing and I feel pretty good about the direction that that suggests to me.
-
-[07:14] **Mark Erikson:** Dan's teaching style has always been very much from first principles, like first I will explain the concepts and why they matter and how we arrived at them, and then I will explain the technical details.
-
-[07:27] You can see that in the original Redux tutorials, you can see that in the rewritten React Dev website. And so, yeah, like I'm, I'm just now finally skimming that Server Components from Scratch article, and I can, I can definitely see that same mindset at work, which is good. Like I, I've always found it's useful to explain a problem and then explain the solution to the problem now that you understand why it's there.
-
-[07:52] And I, I think this is a really good post.
-
-[07:54] **Carl Vitullo:** Sebastian, you wanna take us off?
-
-# Skew Protection on Vercel
-
-- [Vercel - Introducing Skew Protection](https://vercel.com/blog/version-skew-protection)
-
-[07:56] **Sebastien Lorber:** Yeah, I wanted to talk about something Vercel released recently. They called it Skew Protection. And I found it interesting because somehow it solves a problem that I had in the past. Where you deploy your new version of your software and then when someone loads a, a website in the browser, they don't always refresh the page, so they, they may have a stale client app locally, and you deploy a new server version, and then there is a mismatch between the server and the client. And somehow Vercel released something recently that permits to, to mitigate this problem.
-
-[08:33] So the idea is that if you have a still client running locally, it'll try to use the server code that match that, that client version. And they can do that because they do some routing on on their infrastructure based on HTTP headers. So the idea is that if you do a breaking change during a deployment, it might not generate errors and they just added this to the last NextJS version. So you can just add the flag to the config and this will be enabled by default.
-
-[09:07] **Carl Vitullo:** Skew protection. Definitely interesting. Definitely a problem I have run into in my career. This has been a problem I've especially noticed on Netlify because they only serve the assets for the most recent deploy.
-
-[09:19] So how I've seen this present is somebody keeps a tab open. You know, the app we have shipped is split into multiple bundles. So then they, they can click around, they can keep navigating within the app for all of the JavaScript they've already loaded. But then they try to go to a new page. It goes to fetch the bundle, the bundle 404s, and then something breaks catastrophically.
-
-[09:41] So how we fixed that on teams I've been on in the past was we set up a 404 javaScript bundle that would just do, you know, browser reload, which it worked. It's fine. It's a little janky. That's led to situations where like if we have state that somebody's entered into text inputs or whatever, that gets lost.
-
-[10:00] So happy to see a more graceful implementation here.
-
-[10:04] **Sebastien Lorber:** Yeah, what is nice, some of our examples just showed the case where you call an api, like you submit a form or something like that, and there is a mismatch between the payload and the, the serverless function. But apparently it also works with the static assets.
-
-[10:19] So if you have a code split app with a prefetching and basic code loading, you should be able to to, to fetch the appropriate bundle to the appropriate immutable deployment. And if you keep your tab open you have like 24 hours of transition, so that you can still access the older deployments.
-
-[10:39] This also present some security concerns apparently because for example, if you have a vulnerable deployment in the past this gives the ability of data here to eventually keep using it, using using HTTP header. So there's a trade off.
-
-[10:54] **Carl Vitullo:** Huh, interesting. Okay. Yeah, a 24 hour grace period for refreshing a tab seems a lot better than nothing.
-
-[11:02] I had always wondered why this wasn't a problem that was solved at the level of the hosting provider, because, you know, it, to me it looked like kind of a bug. You know, I, okay, yes, immutable deployments, but like, it's not that those old assets don't exist anymore, it's just they're not the freshest.
-
-[11:17] So, you know, when I, when I've controlled a server in the past, like I only cleaned up old artifacts every now and again. So, yeah. Interesting though. Cool to see a hosting provider bring it.
-
-[11:28] **Sebastien Lorber:** If you use Netlify for example, there was a way to, to mitigate vita this as well. For example, you could use the net cash and you can keep the previous static deployments in your cash and then merge them with the new deployments so that you get, somehow you keep the old assets and then add the new assets to provide the old assets. And then both remain accessible. So this is not ideal, but at least it was a, a solution.
-
-[11:57] The problem is that you sometimes had to clean up the deployment because it's it would keep growing forever if you don't do the cleanup someday.
-
-[12:05] **Carl Vitullo:** Never want unbounded growth. Cool. Well, I'll take us on.
-
-# React Native 0.72
-
-- [React Native 0.72 - Symlink Support, Better Errors, and more](https://reactnative.dev/blog/2023/06/21/0.72-metro-package-exports-symlinks)
-- [Fabric Renderer](https://reactnative.dev/architecture/fabric-renderer)
-
-[12:09] **Carl Vitullo:** So React native had a new big version put out, version 0.72. The highlights were symlink support in Metro, better errors and developer experience, and some more. It looked like a lot of the "more" is sort of finer points related to. A new architecture. They, you know, they had New Architecture in title case all over this post.
-
-[12:35] So it looks like this relates to the new architecture and React Native, Fabric, which I guess is a new renderer, new core technology for how the apps get put on the phone.
-
-[12:48] **Sebastien Lorber:** Fabric is a new renderer for the new architecture. There are multiple pieces to the new architecture and Fabric is the, is the new renderer.
-
-[12:57] **Carl Vitullo:** Okay. Yeah, so, you know, my, my reading of this news here, they have a new interop layer that makes that new architecture more usable for, a wider range of people who are on older versions of React Native. I saw that it's, you know, they're intentionally not doing a hundred percent coverage right now, just focusing on common issues. Common compatibility. Yeah. Cool. Awesome to see it get better developer experience because that's always been my largest pain point when trying to use
-
-[13:25] **Sebastien Lorber:** it. And also the, the new metro features will be super useful. For example, the symlink support was requested for years. I think it's maybe the oldest issue in React Native.
-
-[13:37] So we are happy to, to finally have the ability to, to use a manual report without having to, to plug any extra config to make it work.
-
-[13:47] **Carl Vitullo:** Yeah. Very nice. Very nice. Yeah, and I see some other little smaller developer experience changes, like not failing on style errors. If you give it a bad style prop, it doesn't blow up anymore, so that's nice.
-
-[13:58] You know, low priority errors not interrupting your workflow is always good.
-
-# Social Dimension of React Server Components
-
-- [Is React Having An Angular.js Moment?](https://marmelab.com/blog/2023/06/05/react-angularjs-moment.html)
-- [Related tweet form Joel Hooks](https://twitter.com/jhooks/status/1670147458360569856)
-- [Next canary broke Apollo and RTKQ](https://github.com/apollographql/apollo-client/issues/10974#issuecomment-1594894341)
-- [React-Query trying to add “use client” and struggling](https://twitter.com/TkDodo/status/1673401744087195657)
-- [Seb describes the `”react-server”` export condition](https://twitter.com/sebmarkbage/status/1673419412144025604)\*\*
-
-[14:02] **Mark Erikson:** Okay, Carl, please prepare to begin pasting and links for this one.
-
-[14:06] **Carl Vitullo:** Uh oh. Uh oh!
-
-[14:08] **Mark Erikson:** Okay, so a minute ago we talked about the kind of the technical news around React Server Components, and then there's the social aspect, which is that there is still a ton of confusion and concern in actual real, no kidding pain points around the rollout of Server Components.
-
-[14:30] The behavior of next. React's versioning and how existing libraries in the ecosystem are supposed to inter-op with all this stuff. , I've, I've been collecting a whole bunch of links and I've actually been forwarding a lot of these over to members of the React team to give them an indication of, "look, these are all the problems people are experiencing, or at least feeling right now. You need to be aware of these so that you can figure out how to actually like, improve the marketing, improve the docs, and address the problems that people are having."
-
-[15:10] So let's, let's roll through a few of those. There was a post that came out entitled, " Is React having an AngularJS moment?" And the background on this for people who weren't around 10 years ago Angular JS 1 was very, very popular for several years, and then the Angular team announced Angular 2, which was effectively a completely different framework, but just using the same name.
-
-[15:39] And the initial announcement was that there would be no migration path to go from Angular 1 to Angular 2. And this killed much of the Angular ecosystem at the time, and it coincided with React coming out. And so in 2013, 2014, a lot of teams said, well, if we're gonna have to rewrite our app anyway, let's just switch from Angular 1 to React instead.
-
-[16:05] And so, a number of people have made this comparison that the rollout of Server Components is like an Angular 1 to 2 transition for React. Now, the React team has pushed back on this idea and pointed out that, you know, we're, we're not killing any of the, the existing client component capabilities. We're we're adding more functionality to React.
-
-[16:31] So in some very real ways. The comparison is a no, but it's also true that there is no migration path that I've seen right now to add Server Components to an existing app unless you're using Next and you start switching over to using the app router, et cetera. So there is a very real feeling of this shiny new thing is being dangled in front of us.
-
-[16:59] And we're being encouraged to use it, and yet many of us cannot. So there's, there's a feeling of being blocked there, even if the technical details are, are somewhat in between and hazy. So the article came out, and then there was one specific, Twitter thread, started by Joel Hooks from, from Egghead.
-
-[17:20] Who was discussing it. And that led to a ton of sub discussions. And I, I got involved in that thread halfway down and actually ended up having a bit of an argument with one of the React team members about, you know, things like defaults matter and, you know, there's, there's missing docs for a lot of these things.
-
-[17:39] And a lot of other people were participating in that thread as well. And it's just an example of the kinds of, Frustrations that I'm seeing echoing throughout the entire ecosystem. So that's one side of things.
-
-[17:53] Another is that a recent Next pre-canary test release broke a couple libraries like Apollo client and React Query, and they reverted that particular change, but the implication and that I'm getting out of it, is that libraries that want to be able to interact with Server Components in some way, basically need to add an entire new bundle file to their packages and specify a new export condition called React Server, so that when the React server component bundler tries to load your library, it finds an extra special version of your library that has all the client code stripped out so that it's not sending extra pieces over the wire.
-
-[18:46] The problem is this means a whole lot of extra work for library maintainers like us. And while there's been some discussion about this on GitHub and Twitter, none of this is actually documented yet.
-
-[18:58] So Lenz Weber, who works on both Redux Toolkit and Apollo client, and myself and Dominik Dorfmeister of React Query have all expressed our frustration with, you know, the fact that our libraries are now breaking and we're being forced to do this extra work, but there isn't even documentation for it yet. So there was, there was a very long discussion thread over in the, the Apollo repo There's been discussion on Twitter.
-
-[19:26] Dominik has a PR up where he is trying to add this new export condition to React Query and Sebastian Markbåge is trying to give some advice. So it's, it's, it's a very frustrating time for library maintainers as well. And then on top of that just within the last week or so, there's been a lot of discussion about versioning.
-
-[19:48] So the current stable version of React is 18.2, and it's been out for over a year, and there's no indication of when an 18.3 or even an 19.0 will come out. Well, it turns out that a lot of the functionality that Next uses in the App Router only exists in what's known as these Canary builds of React. So React has a bunch of internal feature flags.
-
-[20:17] And they put out the stable builds, which have a lot of those feature flags turned off. There's the narrow builds or in experi in the daily experimental builds, which have many of these feature flags turned on. And so if you're using the app router next actually ignores whatever version of React you have listed in your package, J S O N.
-
-[20:39] And instead they use one of these canary builds of React. That has the extra special functionality. And the problem is that right now there is no documentation whatsoever on what features are even turned on in one of these canary builds. And there's no way for a library maintainer to know, okay, well you're reporting a bug with our library, like our, our, our library, but we don't even know what version of React you're using.
-
-[21:09] And, and or we don't know what features we should expect to be available in React when you're using like next in the app router. So there's both frustration from maintainers where we don't know, like the React team isn't documenting, here's what's available for you to use. What are the stability of these APIs?
-
-[21:30] What, what canaries have, what features turned on? And then there's also an argument about (exhale) React wants to be able to try out these new features. A lot of these features are expected to be used by frameworks like Next and Remix. And so the framework can kind of like add a layer of protection on top of those.
-
-[21:52] And even if the features aren't a hundred percent done and they change a little bit over time, the framework can put in effort. To keep them from breaking users applications, but what does that mean in terms of semantic versioning and publishing the libraries? So there was, there was a lot of debate about what is the right way for React to put out these features so people can try them out versus semantic versioning versus framework usage.
-
-[22:22] So it's, it's all very, very confusing right now. I will say that I've, in addition to all the public debate, I've, I've had some messages on the side with some React, some, some kinda like non-public React team members who are explicitly intending to work on core documentation for Server Components and wanting to work on.
-
-[22:46] How to docu, like how do we document these canary builds? Can we do something similar to like the TC 39 stages process where we say, you know, we've got these 15 features. Some of them are just an idea. Some of them we have a proof of concept. Some of them are already ready to go and hopefully be able to like apply that as like a, a matrix or a table or something to all the different canary builds maybe.
-
-[23:12] But Right. As of right now, none of that information exists, and it's very frustrating.
-
-[23:17] **Carl Vitullo:** Yeah. Right. And I, I think another aspect that you didn't even mention in all of that (laughter) is that like, it's already so hard to publish a library correctly because the ES module ecosystem has been such a nightmare.
-
-[23:33] **Mark Erikson:** Oh, don't even get me started.
-
-[23:36] I, I was flying back from React Summit a couple weeks ago. I've been threatening to write a blog post for the last few months about, look, I've been suffering through trying to convert the Redux libraries to e sm. I'm finally going to write, I'm going at some point, I'm going to write down all the stuff I've learned and tried and bang my head against.
-
-[23:53] So I wrote half the blog post on the flight back. It's 4,000 words long, and I still need to sit down and write the other half of that. And I even had the redwood folks ping me and say, Hey, you've, you know, stuff, something about this e sm transition, right? Can you help us? I'm like, I'm not sure that I'm the person to help with this.
-
-[24:13] **Carl Vitullo:** You're the expert, Mark.
-
-[24:14] **Mark Erikson:** No-oooo.
-
-[24:16] **Carl Vitullo:** (laughter) yeah. So I mean, it's already. Very difficult because the ecosystem ha is still reeling from the effects of the last major, you know, bifurcation of package authoring. I guess connecting this back to what I was talking about earlier with the StackOverflow and representation of React as a, you know, portion of the overall tech world and you know, it's something, it's like 60% of respondents are using React or something like that. So like the tech world is enormous. React's influence on it is enormous. The ES modules nightmare is still not over.
-
-[24:54] **Mark Erikson:** Oh, it's still going on, trust me.
-
-[24:56] **Carl Vitullo:** Well, you know, Mark, maybe you can end it finally at long last by finishing your 8,000 word blog post about how to, how to integrate it correctly.
-
-[25:04] **Mark Erikson:** (ironic laughter)
-
-[25:06] **Carl Vitullo:** (real laughter) But yeah, so, I really feel like your, your frustrations here around trying to be a library author, dealing with this transition gracefully and correctly, and feeling like there's no good, like, like there is no way to do so, like, it's an impossible path. Yeah. That's, that feels very real.
-
-[25:25] **Sebastien Lorber:** I, I don't think it's bad for Vercel and NextJS to use the canary version, but the problem is, maybe it's just a documentation problem, I, I mean, it's a good way for them to, to have a quick feedback loop and have some adoption somehow.
-
-[25:40] It reminds me of what we had with Docusaurus too, you know, that it took a long time to release. And the fact that the community adopted the alpha versions gave a lot of feedback because we had a lot of download on, on this version, and many used it in production, including Redux, I think.
-
-[25:59] I know that it produced some pain because we did some breaking changes, but at the same time it provided a ton of feedback, that permitted to refine things. There's a trade off for the NextJS team to, to find between being stuck, not being able to reiterate fast because their software has come somehow, too related to, to React new features to evolve independently. So they need to iterate on, on both of them at the same time.
-
-[26:25] And. If they do that, then the community is a bit confused because the two versions are related and not everything is properly documented on the React side. And if they don't do that, they will be much slower. For example if they need a, a React core feature in to, to do something in NextJS.
-
-[26:47] This may mean that we need a new version of React and Uneven NextJS can use it and uneven we can get feedback because the community is using the new version of NextJS That is using the new version of React. It's a much longer feedback loop, and it's not good for the community to take, to have things, being slower. So, I mean, if it's a bit more painful in the short term, I think it's better to, to have this quick, , feedback loop somehow.
-
-[27:16] **Mark Erikson:** No, I definitely agree with that. I'm like, as a library author, I'm very sympathetic to, like, I've made changes I want people to try it out and, and actually give us feedback. I, I wish we got feedback for the Redux office in beta. But the, the fact that there is no documentation on what any of these, like what these new features are and which Canary build actually have certain features turned on is, is very frustrating.
-
-[27:44] **Carl Vitullo:** You know, like, okay, bundling a library is difficult. Publishing it correctly so it can be consumed is difficult. It seems very frustrating, but it does make sense to me that like the documentation for that, It's not stable yet.
-
-[27:56] **Mark Erikson:** Nonexistent is the problem.
-
-[27:59] **Carl Vitullo:** It's not surprising to me that the documentation for that bundling and publishing concern is not existent. It's confusing to me that the, that there is no documentation for what feature flags are enabled in a specific canary release. Like that seems like a very routine part of publishing a canary package. Like if you can't, if you don't know what's in it, how can you give feedback about it?
-
-[28:20] So, I guess that suggests to me that they, that there's a pretty heavy reliance on like, backchannel communications. And so, you know, the, the 10 people who participated in creating this canary release, they already know what's in it, so they don't need the documentation.
-
-[28:34] And so it feels like that's who the audience for these canary releases are. The people who are already in the room.
-
-[28:40] **Sebastien Lorber:** When you say feature flags, do you have a particular feature in mind that could be activated in the canary?
-
-[28:47] **Mark Erikson:** Well, oh yeah. Like, like the, the `use` hook.
-
-[28:50] You know, the, the React team published this RFC about this new use hook that's supposed to let you unwrap promises like a year ago. And the use hook then, or the use RFC mentions an upcoming cache or an upcoming RFC for some kind of cache component or API and says more details will come later. And the use RFC discussion, 95% of it was, well, people don't like the name, slash what kind of value are you allowed to pass to this either now or in the future?
-
-[29:22] And it went silent. And so as library maintainers who would like to integrate with suspense? Our assumption was, well, nothing is happening with this RFC at all. And then Next comes out with this in the app directory, and they, and suddenly they're telling us that, oh yeah, the use hook is ready to go. You like we either we use it internally or you can do something with it Next. And something something.
-
-[29:45] And we're like, wait, what you're, you're telling us that's usable? What about the cash thing? That never materialized. And, and so like we, we just have no idea where things even stand with that stuff.
-
-[29:58] **Sebastien Lorber:** I understand that at, at the same time, somehow the, the hook is not documented in NextJS also, as far as I remember.
-
-[30:06] For the end user, they are not supposed to, to even use it. So the end user, the app developer shouldn't care about if the feature is enabled on the direct canary flag or not, because, this is used only internally. So the problem is more that you as a library author, can't try the new things because they are not documented.
-
-[30:29] But I, I don't think it's a problem for the majority of users. It's more like that, you can't start working on, on the new cutting edge things now because you are, you don't have the same back channel with the React team. So, I, I see some auto, two different problems. It's one for framework authors and library authors, and another for the end user.
-
-[30:52] I don't think adopting NextJS With Canary release for the end user is a big deal today, apart that there are a lot of bugs that are reported, but they will be fixed. But the, I don't think the end user need to know much about all these new things that are not documented.
-
-[31:10] **Mark Erikson:** Yeah. The, the flip side is that we, we do see a lot of our, our users asking like, you know, can I use Apollo React query, RTK query with suspense?
-
-[31:22] And there's clearly a lot of interest in doing that, and we really don't have an answer for how you can do that yet.
-
-[31:29] **Carl Vitullo:** I have one more thing I wanna pull in. Sebastian posted a very short little Twitter thread. I'll just read some snippets from it.
-
-- [Sebastian Markbåge, "Who owns the direction?"](https://twitter.com/sebmarkbage/status/1673767392369844236)
-
-[31:36] "When a community of consumers grow large enough, it's interesting what happens with ownership. I think there's an argument to be made. It's that at some point the community bought into something and you can't change that from underneath them. They own what they bought into. From that perspective, if we as maintainers want to go a different direction, we should have given it a different brand, even if it's backwards compatible."
-
-[31:53] I think that's very directly talking about all of this React Server Components drama and positioning, he posted those yesterday, about 24 hours ago. I, I'm looking forward to seeing where that may have echoes on. How the React Core team is thinking about React Server Components.
-
-[32:13] And tying it back to, you know, where we started on this with comparisons to Angular 2. Like, okay, maybe this is not an Angular 2 moment for React, it is fundamentally backwards compatible, they are engaging with, you know, maybe not engaging perfectly, but they are making good faith efforts to include stakeholders in the conversation. Yada, yada. But I think this is maybe an early signal of a change in approach and yeah. Interesting to see how that shakes out.
-
-[32:41] Okay, now we can move on. We've beaten it fully into the ground. Sebastian, you wanna introduce our next link?
-
-[32:47] **Sebastien Lorber:** Yeah, it's a quick one. I, I noticed that we are both on the jury of, , React Jam, so I didn't know, but, , that was a happy surprise.
-
-[32:57] So this is a contest where you create a game with React. And I think it it'll be nice if the Reactiflux community wants to participate. So we'll be happy to review your React games in I think next month maybe.
-
-[33:13] **Carl Vitullo:** That's a good call out. Sebastian and I are both judges for a hackathon around developing games using React and web technologies.
-
-[33:22] I think it's happening on July 20th through 30th, so it's 10 days long. As judges we will be given the, you know, I think it's gonna be 10 candidates and then we grade them. I'm excited for it. I think it'll be fun. We've done a couple of Office Hours and interest in video games has been a very common theme on what got people interested in programming.
-
-[33:43] So if that's you, if you are interested in developing games yeah check out React Jam and maybe you'll have me and Sebastian play your game.
-
-[33:52] **Sebastien Lorber:** Yeah. (chuckles)
-
-[33:53] **Carl Vitullo:** Cool. My, my next link here, just a kind of small update. We talk a lot about Next and I feel like Remix maybe gets a little bit short shrift, but I see that they've got a, a new V2 development server that has some relatively large changes to the, some of the core assumptions around Remix.
-
-[34:12] Most notably, it looks like this totally swaps out the semantics around routing. The big comparison that I saw, you know, front and center of this announcement was previously Remix, inferred what routes your pages were on based on the folder structure, with, you know, templates and wrappers and things like that.
-
-[34:33] Now that is purely based on the file name. So instead of the folder hierarchy being reflected in the routes, it's Using. A different mechanism for determining conceptually what's a folder, what's what looks like a folder in the url. That's a pretty big shift.
-
-[34:48] I am interested to see them roll this out because it is such a large change to the everyday development experience of using Remix. So yeah, and seeing like a sub component of a framework, being given a new major version is interesting to me. We just talked a lot about Server Components and the versioning and the struggles of rolling that out.
-
-[35:11] So here's a different example. Smaller, you know, obviously Remix is inherently a subset of React usage, so it, the, the ecosystem is inherently smaller, but yeah, interesting to see another approach to making a major revision to floor behaviors.
-
-[35:28] **Sebastien Lorber:** It's quite interesting that they have implemented future flags to enable V2 features in Remix version one.
-
-[35:36] And I've also seen this this new flat routing convention that they implemented. There also great article that already tried to use this new feature about the ability to create somehow your, your own Remix routing convention.
-
-[35:53] So the, the idea is that you can create your own convention, read the files on the file system, and then eventually create the route you want for that file system secure. And so this gives a lot of flexibility. On Docusaurus, we already have a quite similar thing.
-
-[36:09] We have a concept of autogenerated sidebar. And it gives the ability also to, to create somehow a tree. And we give the, the ability to customize it.
-
-[36:20] Also, they recently released the, the last version of Remix with dev server version two. So as far as I understand, I think the idea if I remember correctly, is that if you change code in the Remix loader, you will also have the hot reloading experience that you expect. While it was not the case before.
-
-[36:41] **Carl Vitullo:** Nice.
-
-[36:41] Before we jump into Lightning Run. So, Sebastian, do you have more links? You wanna do a full discussion on?
-
-[36:45] **Sebastien Lorber:** Yeah, I think it's worth mentioning Panda CSS. It's a new CSS-in-JS solution, , that use a static analysis to, to do many things with with no runtime. Actually, I'm not sure it's completely without any runtime. I think I read there is a very little runtime, but I'm not sure. Now today, the, the devs are like tailwind, css a lot. And there are good reasons for that because you can copy paste code easily and you can also delete code quite easily and, and things keep working.
-
-[37:18] So this is a very interesting property. At the same time, Tailwind CSS get a lot of criticism for, for the very long class names. It looks a bit messy for people that don't approve to, to this way of thinking. And Panda that CSS could be a, a greater alternative to, to Tailwind. It looks quite interesting and it's from the chakra UI team.
-
-[37:43] I think the Quik framework is also trying to adapt it because they are building integrations and making it work in Quik already. So I think it's a tool to follow and we'll see how the community adapt it. But it looks like like one of the most promising CSS-in-JS solution today.
-
-[38:04] **Carl Vitullo:** Cool. Very neat. Oh, I just opened the webpage and the CSS has broken. Haha, not a ideal. Yeah. Interesting though. It's been a, it's been a minute since we've had new CSS-in-JS strategies come out, so I'll have to dive in compared to this and. See what it's introducing.
-
-[38:21] Cool. Okay. Let's go to, let's go to a lightning round. Mark, take us away.
-
-[38:27] **Mark Erikson:** Okay. Two things real fast. One is that ever since function components came out, there were a couple things that they could not do that class components could. One of those was defining an error boundary to catch errors that are thrown while your component is rendering.
-
-[38:44] You still had to use class components to write one of those. There is a PR up that adds a new catch component to React that would basically eliminate the need to use class components for error boundaries. I haven't looked in detail at the api, but there is some form of early EPR up for that.
-
-[39:03] So hopefully we'll get that in the next meaningful release. Also, I had filed an issue a couple months ago. Saying that as good as the new React docs are, they really need to add a page on how to use TypeScript with React and Orta Therox, who's been very involved in the TypeScript website docs just put up a PR that adds that page.
-
-[39:27] And I, I skimmed it right before this, this meeting, and it looks fantastic. So I'm, I'm very, very excited to see a React Docs page saying, here's how you use TypeScript with React.
-
-[39:39] **Carl Vitullo:** Definitely a frustrating experience a little bit. I feel like every time I come back to it after a, a little while away, I need to find some cheat sheet to be like, wait, what am I supposed to use? What am I not supposed to use?
-
-[39:50] So I guess that segues nicely into another one, but React.FC is no longer viewed as an anti-pattern for typing React components. Nice to see that, and nice to have documentation on how to use TypeScript with React. Cool.
-
-[40:05] Sebastian got any lightning rounds?
-
-[40:07] **Sebastien Lorber:** This week in the React Native ecosystem we had we saw a lot of quick demos of running the latest version of React Native on VisionOS the SDK for Vision Pro from Apple. And I found it interesting. I don't know how it works exactly, but apparently the, the React devs had fun with it, so it's already working.
-
-[40:28] I know it's it's already working for, for Flutter too, so maybe it was a simple thing to do, I don't know. There are also pull requests to, to add a support for vision or in Cocoa Pods. So I guess it'll become easier to, to add support for our VisionOS in the future in React Native applications.
-
-[40:47] **Mark Erikson:** I ran across a website within the last couple weeks called the React Handbook. And I haven't even had time to go through it fully in depth, but it's, it's like an overview and guide to the React ecosystem. Common problems like state management and data fetching and it tries to give some advice on what libraries to use and how to work with things.
-
-[41:09] And I had actually tried to, to get a similar kind of ecosystem overview guide website started a couple years ago. And I, I put up a proof of concept page, had some discussion about what I wanted this site to be, but I never got other folks in the community to spend time helping fill out the content. So this React Handbook looks very similar to the kind of idea and the kind of resource that I wanted to help build for the React community.
-
-[41:37] And I'm actually still supposed to talk to the primary author of this site about, you know, here's some of the ideas I had and maybe we can like, sort of join forces and help build this one out more.
-
-[41:48] **Carl Vitullo:** I know it's lightning around, but that also reminds me of us of our Reactiflux learning page, which has, which you curated with a ton of resources. So yeah, looks like a good resource.
-
-[41:59] My next lightning round Chrome for testing, reliable downloads for browser automation. Browser automation's really tough. Puppeteer kind of sucks. Playwright I hear is better. Cypress I have used successfully, but have always run into difficult edge cases, so having a blessed browser version specifically for testing. I see this is titled Chrome for testing. Like heck yeah. That's awesome. This is possibly an absolutely enormous level up for the testing ecosystem and maybe we'll start getting real movement on problems like visual regression tests, which I've seen probably a dozen attempts at companies trying to solve that problem over my 10 years as a web developer.
-
-[42:42] **Sebastien Lorber:** Quick link would be shadcn UI, I don't know to pronounce Shadcn, but You probably heard of this trending library recently. It released recently a new CLI that permits to bring a great developer experience on top of the React component, collection because it's not a library, it's a collection of Tailwind and Radix components.
-
-[43:05] I was quite impressed somehow in the beginning I didn't understand really the value of this library because somehow it looks like just a registry of of code that you can copy paste. Somehow it's bringing a CLI to, to be able to update the components, eventually use artificial intelligence features to it so that you can type a prompt on the CLI and it'll update the component according to what you, you say you want to do.
-
-[43:33] **Mark Erikson:** So at my, my, I, as I said earlier, my day job is working for Replay io and we're building a time traveling debugger for JavaScript. And we just announced something we've been building for the last six to eight months called Replay for test suites.
-
-[43:48] And the idea is that, You know, lots of companies have Cyrus or playwright tests. You run them in CI, but often either they flake, you know, they, they fail unpredictably 10% of the time. Or if a test fails in CI, you have no way to go debug what happened to that test. And so what we've announced is that we have the ability to change your test running setup to record all the tests that occur. And then if a test fails, you can open up the recording and time travel, debug that recording. So we, we, we just announced it we're, we're doing a wait list thing. We're gonna be doing some, some onboarding of teams to, you know, try it out and make sure that what we've built actually works.
-
-[44:36] But I'm, I'm really excited about this. Like, the amount of time I've spent trying to figure out why end-to-end tests are failing is absurd. And we're talking to companies that, like, they routinely waste tens of thousands of dollars on Amazon costs when tests fail and they have to go rerun the whole thing.
-
-[44:52] So I'm, I'm excited for something that will help, help teams fix their tests and run them consistently. Something else that I've been doing myself. So earlier this year I, I built our own, our integration of the React dev tools for Chrome by doing backend post-processing of the recordings to extract the data.
-
-[45:18] And we have officially turned that on. And just a week ago I shipped a major new update for it that actually improves on what you can do with the reactive tools browser extension, so the real React extension in the browser. If you record a or if, if you're looking at the website of a production app, you're going to see minified component names.
-
-[45:44] And what I've figured out is using time travel debugging, I can go look up the original files and find the original component names and show those to you when you debug a React app in a recording. So you can go from, you know, minified names like xz to the original name, like to-do list item in the recording.
-
-[46:06] So I'm really excited about that. And then just yesterday I was hacking on a proof of concept feature that would be able to to look at a React and Redux app recording and pull out information like, here's all the times your selectors ran, here's how long it took to update the ui. Here's like, which selectors were expensive, and hopefully give you like some performance optimization information.
-
-[46:32] **Carl Vitullo:** My last lightning round link here Vitest 1.0 roadmap has been shared. I'm using Vitest. I think it's great. I enjoy it. It's very quick. Runs my tests.
-
-[46:43] I'm very happy with it. I was always a little frustrated with Jest and it's, you know, parallel configuration. Just one more thing to configure and set up. Cool to see it have a roadmap for getting to 1.0. Excited to have that land.
-
-[46:55] **Sebastien Lorber:** Yeah. So my last link will be the Docusaurus version three Alpha.
-
-[47:00] So this is what I've been working on in the, in the last month, and it includes MDX 2 and React 18 finally. And So if you use the Qru, I'd be happy to, if you can try the, the Canary versions and. And give me feedback if it's working fine or if you have any bugs, then I would be happy to help you do the upgrade if you have any trouble.
-
-[47:25] **Mark Erikson:** Oh, nice. We'll have to carry that out for the Redux docs.
-
-[47:28] Okay. Last item I've got is a whole slew of updates for the Redux libraries. So we've published Redux Toolkit 2.0 Beta, which ha Has some small breaking changes to remove deprecated options. It has improved TypeScript types.
-
-[47:43] It has several new features like some reducer injection and other stuff. I don't have an ETA on when this will go final because we're trying to update all of our libraries, which with a bunch of stuff simultaneously. Actually, the other, the other big thing we're doing with a lot of these is trying to update the packaging to support better ES module common JS interop, which as we mentioned earlier, is a royal pain.
-
-[48:10] But the idea is we're gonna publish major versions of all the Redux related libraries simultaneously. And so I'm juggling like 15 different things in my head trying to keep track of what needs to be done sort of related to that. We just shipped React Redux 8.1, which has dev mode warnings if your selectors accidentally return new values when they should't, which is a common mistake that we see people make.
-
-[48:37] So you can think of it, think of it as kind of being similar to React running, use of effect twice to try to catch mistakes. I've got a PR up that will become React Redux nine Alpha. I don't have it merged yet because there's, there's a couple different packaging issues that I, that I ran into that I need to solve there.
-
-[48:56] And then I'm, I'm on business travel this week, but literally on the flight out here on Monday, I was experimenting with some proof of concept changes to how React Redux manages subscriptions and updates the ui. Sort of inspired by signals or observables. And the goal is to hopefully make it more optimized and update the UI faster.
-
-[49:23] I spent four or five hours hacking on the flight and I at least got something running that passes tests at the moment. But I still need to actually do a bunch of performance testing and see like, okay, this thing that I built, is it actually any better or not? If it works out, it would probably show up in React Redux version nine as a new opt-in hook called use Tracked Selector so that all the existing hooks would, and, and you know, components would work exactly the same as they have, but if you want to make use of this new functionality, there's an additional hook that you could use, which would be more optimized.
-
-[50:05] We'll, we'll see if this actually works out or not.
-
-[50:08] **Sebastien Lorber:** Yeah, I have another one. There is a new AI framework called AI.JSX, and it's using JSX as a composition block and is meant to be integrated in React applications, but it's not a React renderer. So I don't know exactly how it works, but this look like quite interesting to, to study.
-
-[50:30] **Carl Vitullo:** Cool! Okay. Thank you everyone for joining us. One more this month in React. Hopefully we're helping you keep on the cutting edge of the React and web ecosystem. Thanks so much for joining us.
-
-[50:40] Keep an eye out. Next week I'm gonna be talking with a conference organizer for React Rally. Yeah, excited to talk, talk with him. It's a great conference. See you guys next month.
-
-[50:50] **Sebastien Lorber:** Thank you. See you. Bye.
diff --git a/src/transcripts/tmir-march-2023.md b/src/transcripts/tmir-march-2023.md
deleted file mode 100644
index 67956f1..0000000
--- a/src/transcripts/tmir-march-2023.md
+++ /dev/null
@@ -1,514 +0,0 @@
----
-title: This Month in React (March 2023)
-date: 2023-03-29
-time: 10am PT / 5PM GMT
-location: Q&A Channel on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Matt Pocock as we break down This Month in React. A lot of news this month, with a major progress update from the React core team, TypeScript 5.0, and TC39 meeting news. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Matt Pocock](https://twitter.com/mattpocockuk)"
----
-
-
-
-**Carl Vitullo:** Thanks everyone for joining us for this month in React, where we break down the news and what's going on in the React ecosystem over the past month. It's March this month. There's been a lot to talk about. Excited to have Matt Pocock joining us to talk about the new TypeScript five release. [00:16]
-
-And very excited to talk about the React Labs post that the core team put out. I think there's been a lot of work that they've been doing over the past several years, and I think this post has been just really brought up a lot of those things. Excited to see what we can get into. [00:31]
-
-Yeah, Mark and Matt, do you, can you introduce yourself real quick? Mark, can you go first? [00:34]
-
-**Mark Erikson:** Sure. Hi, I'm Mark Erickson. I maintain Redux. I sit around here and answer a lot of questions. I work at a company called Replay, where we're building a true time traveling debugger for JavaScript. If you haven't seen it, please check it out. And I generally show up in React or Redux related discussions across the internet. [00:53]
-
-**Carl Vitullo:** (giggle) yes, you do. Cool. And Matt, can you introduce yourself? [00:57]
-
-**Matt Pocock:** My name's Matt Pocock I am a general TypeScript person I guess. I was a software developer for about four or five years, and it's, feels weird to say was a software developer cause I'm now full-time TypeScript educator. I guess since like December left my job at Vercel and now working full-time, building a TypeScript course called Total TypeScript. [01:15]
-
-I was a React developer for for my career as well. So working with React and TypeScript for about four or five years. But I'm, as I said before, I'm a little bit out of the React ecosystem at the moment, but I'm really excited to hear what's been going on. [01:27]
-
-**Carl Vitullo:** Yeah, we're excited to have you bring some more of your expertise about the TypeScript ecosystem in here. Cool. Yeah, let's jump into it. So the format we use for this we will introduce a link in a round robin fashion, just going around one by one and have open discussion about it for a couple of minutes. [01:44]
-
-## Retire SPA and MPA?
-
-**Carl Vitullo:** So I'll kick us off here. A couple days, weeks ago. Dan Abramov tweeted about, he said, petition to retire terms, Single Page Application, Multi-Page Application, SSR, SSG, they represent the previous generation of I think that's interesting. It's a, we're at a moment of time where, single page versus multi-page application like that was such a strong client versus server distinction for a lot of my career. [02:10]
-
-But it, you know, it feels like the ecosystem is really cooled on the idea of a single page application saying it's sort of an acknowledgement that you can't do everything you need just on the client. And a bit of a return to more of the history of, web and software development where things were much more server based and the application side of things was, I don't know, maybe not raised to quite its own separate entity. [02:36]
-
-Yeah. What do you guys think about that? [02:38]
-
-**Mark Erikson:** There definitely has been a shift in the discussion both inside the React community and outside the React community over the last year or year and a half. Some of it positive, some of it negative. I've seen a few different articles and some of them were in the, you know, This Week in React link posts that have expressed a lot of very strong critique about React in the community and how hard everybody went in on the single page application concept starting around 2015. [03:07]
-
-And, I think some of it is miscommunication and, attributing bad will to, to people when there wasn't any. You know, there's, there's the ongoing difference of am I building a website with pages versus like, am I building a fully interactive application that happens to live in the browser? [03:25]
-
-And so you've got different people building different kinds of programs and yelling at each other when, they turns out they actually have different needs and technical differences. So that's one part of it. But also I think there is the fact that the tooling around things, around the React ecosystem, you know, whether it be next or Remix or server components or whatever makes it more feasible to build server side pieces. [03:50]
-
-I mean, React has had a concept of server side rendering for a long time now, but, If you weren't using next, you had to build a lot of that yourself. And the tooling wasn't there. And to be fair, like I have never dealt with SSR in any of my own projects. My own applications have always been strongly client side. [04:08]
-
-So like I'm kind of sitting off to the side and trying to observe what everyone else is doing. And I can't speak to this from my own experience. But if you look at something like next, even when you're doing server side rendering and or static site generation, it still ends up with the client side interactivity and then you transition from page to page. [04:27]
-
-And it's primarily doing that on the client. So even right there, it has that mixture of behavior. So I can see the point that Dan's actually getting at here is that even with the tools we have right now, there is a mixture. And when you start including things like server components and you know, next new app router in that combination, it is somewhere in between. [04:51]
-
-And the terms don't seem to fully apply the way they used to. [04:55]
-
-**Carl Vitullo:** Yeah, I think that makes sense. I saw that Kent C Dodds proposed the term PEMPAs, which I don't, I don't, I don't think I'm a big of. uh, P E M P A for progressively enhanced multi-page apps. And (sigh) yeah, I, I guess my thought on this is like, maybe the problem is that like we're trying to assign specific terms for all of these different behaviors, really. [05:19]
-
-Like, incremental static regeneration and static site generation and all those, like, to me, incremental static regeneration is just a dynamic site behind a cache, you know what I mean? Like, it's not something I would architect a build process around. It would be an implementation detail of the caching for me. [05:36]
-
-Like it's a performance improvement. It's not a core part of the architecture. So I think maybe maybe a challenging point of friction here is that like we're trying to figure out terminology to describe all of these increasingly nuanced and, I don't know, just very specific ways of writing software. So I don't know. [05:56]
-
-**Mark Erikson:** I'm gonna go kind of meta on this one. Thinking about it just now, I think what we're actually dealing with is a categorization problem. And the problem is we're talking about things as categories, and a thing can only fit into one category, whereas what we're really dealing with is programs have like tags and you can have many tags on one thing, or to put it in software terms, it's, is it class inheritance or is it like, you know, a game style entity component system where it's like, this thing is movable and this thing can shoot and this thing can do x and this thing can do Y, and maybe the problem is that the terminology we're using is only one label, and we really need to be able to apply many labels to a given app. [06:39]
-
-**Matt Pocock:** I think there's there's like two things that I would think around this stuff. I think one of Kent's terms was PESPA, right? Progressively enhanced single page application. A lot of these terms, SPA, MPA, they all have "page" in them, right? "Page" is the unit of fetching the unit of thing that you're caring about. [06:55]
-
-And whether you're doing SSR or SSG, you are really talking about the page is the thing that you are, assessing, but really what Next, and it seems like what Dan is tilting at here, is that instead of the page being the unit, now the component is gonna be the unit. [07:11]
-
-Think that's in general where it seems like things are moving to, and whether you use like nested routing in Remix or something, or whether you're doing, server side components, you still have a concept of a single component being exported from a file and attaching a loader to it, or having that component itself to the data. [07:27]
-
-But I also think that people don't consume the categories, they consume the frameworks that sell the categories right? So you have, for the last five years, let's say — probably since 2015 actually — Create React App has been still the dominant way that people make React apps. [07:41]
-
-We have all of this huge conversation around SSR and Remix and the framework wars and all that stuff, but really it's been Create React App all the way, and Next has only caught up recently. So the fact that, now Create React App is disappearing, it's gone out of the React documentation, I imagine we'll see its usage drop off, and then finally Next and other frameworks can come into its place. I think like really we are consuming frameworks instead of categories, but really the conversation is about the categories. [08:11]
-
-**Mark Erikson:** That makes sense. Yeah. [08:12]
-
-**Carl Vitullo:** Yeah. And maybe building on that a little bit. I think that thinking about this in terms of frameworks and, the project bootstrap process I think is limiting in that a lot of people are using React with a wide range of backends. So, you know, if you're not building a new project and starting, with Remix or Next or something like that, but you know, you're working off a project that has existed for five years and is originally built with Rails or Django or something like that. [08:40]
-
-That category of development feels left out from this conversation to me. And I was thinking about this while I was preparing for this, and to me, I think this is like a Venn diagram of three different categories that each have their own, breakdowns within them. [08:53]
-
-So it's like, when is the content rendered? Is it rendered in advance at build time, is it rendered dynamically, is it totally static? It's never built, it's just always the same content. So that's, that's one category with three options. [09:05]
-
-Then, like, how is it cached? Is it not cached at all, it's fully dynamic, it needs to be rendered from scratch every time it's requested, or is it cached for a long time? [09:13]
-
-And then a more subtle one that took me a second to come up with and then even wrap my head around was, who owns the url? Because , the server owns a lot of URLs, and it, you want the server to respond to these. But then there's the other category where you don't want the server to respond to it. It's entirely within the bounds of your client side app. [09:32]
-
-So I don't know. I was thinking about how I was thinking about what terms I might use, and I came up with those three categories and was just thinking like, okay, if there was a Venn diagram showing all of the overlap between these different components, that feels like it could get towards being a complete taxonomy of development. [09:49]
-
-But, like also every intersection of those would need its own acronym. And if we have, three categories that each have between three and five subcategories, that can all overlap with one or more of each other. Like, I don't think we need 25 different acronyms to describe the totality of it. It's complex and maybe the taxonomy we're trying to build is not super valuable. [10:04] [10:09]
-
-## Create React App no longer officially recommended
-
-**Mark Erikson:** I'm gonna take this opportunity to go to the next point because it actually circles right around to this part of the same discussion. [10:14]
-
-So one of the biggest pieces of news from the last month is that the new React Doc site is finally live. That's the good news. The bad news is that it, it took four and a half years after the announcement of hooks, and it took two and a half years since they announced they were even working on a new doc site. [10:31]
-
-But it is finally live. And it came with some big surprises. One is that there's a new url. The new home is at React.dev, whereas the old site was at Reactjs.org. And for the record, the old docs are still available, but they're now at legacy.Reactjs.org, and they all have, you know, headers saying, please look at the new docs instead. [10:53]
-
-The controversial ish side of the docs announcement, and we've mentioned this in passing already, is that the instructions for "how do I start a new React project" no longer mention Create React App basically at all. And instead the focus is on using a broader, more powerful framework. [11:13]
-
-The first three frameworks that it mentions are Next, Remix, and Expo. And I think there might be one other in there, I'd have to double check. [11:22]
-
-And this is actually brought up a fair amount of controversy. You have and this kind of goes back to what Carl was saying about like different people with existing projects or different people who have different concerns. [11:31]
-
-There are people who are worried about beginners needing a simpler tool set to get started with. And Next is more powerful than Create React App, but it's also more complicated. There are people who have said, "okay, fine, Create React App is dead, but the docs or the installation and setup page should talk about Vite because clearly Vite is superior to Create React App." [11:55]
-
-And so it should be like a replacement in that sense. There are people who are concerned with, " if I use Next, which is now in a sense, the default choice, then I have to have a node server and I have to deploy it on Vercel in order to use it." And neither of those is true, but those are sort of the default assumptions that people have. [12:16]
-
-## React encouraging server capabilities
-
-**Mark Erikson:** And so there's been a lot of discussion and debate and pushback. There were a couple articles going around basically saying that the React team now wants to pretend that single page applications don't exist. And there is a little bit of truth to that because the React team wants people to be using a framework that has server side capabilities. [12:36]
-
-You might start only using the client side stuff, but their stance is, you will want to use the server side pieces eventually, you will want to use routing ,and so on. And using a framework that has this built in out of the box is gonna give you a better starting point. So this has fed into a lot of the debate like, okay, the docs are out, but they're really pushing you towards a framework, especially Next. [13:01]
-
-And there are people who are not necessarily happy about that. And there are folks using, different backends like, you know, C# or Java, that aren't Node, who are concerned about their projects not working well with React in the future in some way. [13:14]
-
-**Matt Pocock:** It's a kind of awkward spot for React, because React is a library and it's always styled itself as a library. But what, what happens when your library starts making demands of your architecture, right? React is starting to say, okay, we are not just a client side thing. I mean, you can use us for client side, but our more powerful features, the cool stuff, it's gonna involve a server. That's the messaging coming out of Dan, too. [13:39]
-
-What happens then when your library starts saying, " To use me properly, you need this certain architecture." I think that's a bit of where my, sort of, strange feeling comes with this and especially when it was like Next Conf for last year when they announced Turbo Pack and the new version of Next, Andrew Clark was there from the React team, who I think now works at Vercel, and he said that this new version of Next feels like the new version of React. [14:06]
-
-**Mark Erikson:** The real React 18, I think, was the [14:08]
-
-**Matt Pocock:** Exactly. Yeah, I was in the room actually when he said that. Yeah, "it feels like the real incarnation of React," which is kind of strange because it shouldn't be tied to a framework like that, but it feels like they're building features which can really only be like made live through through a certain architecture. [14:26]
-
-**Carl Vitullo:** I think another dimension of this is, to me, I think the React team has been very consistent about that framing for a very long time. Like they've always tried to be agnostic to anything you want to be able to do and to provide the best experience they possibly can, regardless of what setting you want to use React in. [14:46]
-
-So, I think that is true that React is trying to influence the architecture that you develop apps around. But I also think that it's not entirely something that they're foisting on the ecosystem. I think it is very much responding to express needs from the variety of teams that they talk to and the variety of teams that they have worked with internally at Facebook. [15:09]
-
-So I'm interested to see how the server components development goes, how that whole rollout works. But like this isn't anything shocking to me because from my reading of all of the conference talks and demos and how they've framed React, this seems very consistent to me. [15:27]
-
-## Three TypeScript 5 highlights
-
-**Carl Vitullo:** Matt, can you introduce TypeScript 5.0 for us? [15:29]
-
-**Matt Pocock:** Yeah, so, well, this is pretty recent, I think, was it like last week or maybe the week before? TypeScript 5.0 is out and it brings a bunch of really cool new features, new optimizations, and I've been actually updating my course total TypeScript with the new stuff literally today. So it's fresh in my mind. [15:48]
-
-And the three kind of headline items are, performance, TypeScript performance has gotten a lot better with this release, and that's due to a lot of internal changes that they've made. [15:56]
-
-Decorators are now supported in TypeScript. TypeScript had support for like an experimental version of decorators to help it support Angular back in the day. But this is the new shiny stuff and the stuff that's actually gonna be adopted into JavaScript. [16:08]
-
-The third one is a new type of annotation for generics, which sounds really, really nerdy, but it's going to, I think, make a lot of really cool stuff that you can do with tap script generics a lot easier, especially when it comes to, passing configuration to components or passing things around, or making abstractions that make your life easier as a developer. [16:27]
-
-This kind of TypeScript knowledge is super, super useful. [16:30]
-
-## TS5 performance improvements
-
-**Matt Pocock:** So, Mark, do you wanna kick us off by talking about the performance things that they've done? [16:35]
-
-**Mark Erikson:** Okay. The TypeScript team did a lot of work on their build tooling and code base structure in the run up to TypeScript version five. TypeScript first came out I think in 2012, so it's been over 10 years. Obviously the landscape of the JavaScript ecosystem has changed and TypeScript itself has changed dramatically since then. [16:56]
-
-TypeScript's own source code is written in TypeScript, but a lot of the organization for that was using an early TypeScript feature called Name Spaces. For TypeScript version five, they wanted to restructure their code to use the more modern ES module syntax. [17:14]
-
-There were a few reasons for that. One was to make use of TypeScript's own features while working on the code, but another was that the way that code got compiled for publishing actually made the TypeScript compiler run relatively slow because of the code that was generated. They figured out that if they restructured the code to use ES module syntax, , the JavaScript engine would actually be able to run the code faster. [17:40]
-
-And the size of the package that they published to NPM would be smaller. I think the version four X packages were like, 50 or 60 megabytes extracted into node modules. And with version five, it's down to like half of that. The module structure changes also literally made the TypeScript compiler run about 10% faster. [18:01]
-
-There was a fantastic post on the TypeScript blog where they talked about the nitty gritty technical details of the changes. One thing that I thought was fascinating actually they did a lot of work to convert everything all over to use the ES 2015, let and const keywords for variables. [18:19]
-
-And then they found out that in some places that actually made things too slow because of how the JavaScript interpreter has to handle those variables and hand replacing some of those with var instead actually got things back to being about 10% faster. So it, it was a fascinating read, and some amazing technical detail. [18:39]
-
-So summary is if you upgraded TypeScript five, it ought to actually do the compilation a little bit faster and it will be smaller to download. [18:47]
-
-**Carl Vitullo:** Yeah, I had seen TypeScript 4.9 was 64 megabytes in node modules, and TypeScript five is gonna be 37 and a half, so like that's enormous. Very cool that they were able to get so much benefit to performance and module size and everything, apparently just from switching to ES modules, I say just I'm sure it was a huge amount of effort to convert such [19:08]
-
-**Mark Erikson:** Massive amount of work. [19:10]
-
-**Carl Vitullo:** code base to Right. Just a such a fundamental change of assumptions, [19:14]
-
-**Matt Pocock:** I saw pr, I think it was like 500,000 change lines or something Crazy. [19:19]
-
-**Mark Erikson:** There was a lot of automatic conversion work going so they can keep it updated. [19:23]
-
-**Carl Vitullo:** No doubt. I can't even imagine how you would begin to audit that the code still performs the same, it doesn't immediately break everyone's code, [19:32]
-
-**Mark Erikson:** what tests are for. [19:33]
-
-**Carl Vitullo:** ( laughter) a lot of tests. But 10% faster and half the bundle size or 60% of the bundle size is pretty incredible. [19:41]
-
-## TS5 decorators
-
-**Matt Pocock:** Pretty neat indeed. Carl, you wanna talk about decorators? [19:44]
-
-**Carl Vitullo:** Sure, Decorators are… they've been something that I've watched for— actually, they've been something that I stopped watching in my career because… I first heard about decorators in something like 2013. And, like five years on, they still hadn't an advanced past stage two. And it, that's the TC 39 standards process for introducing something to JavaScript has four stages, you know, like there's stage 0, 1, 2, 3, and 4, where 4 is shipped. [20:09]
-
-So decorators were stuck at stage two for [20:13]
-
-**Mark Erikson:** Years. [20:14]
-
-**Carl Vitullo:** like close to a decade with like competing proposals and different libraries were using different incompatible versions. I know that like Mob X went pretty hard on decorators pretty early, and I think that ended up burning them pretty badly. [20:26]
-
-**Mark Erikson:** Angular has been all in on decorators since day one. [20:29]
-
-**Carl Vitullo:** Yeah. And so it's I saw that they advanced to stage three, which is, I think advancing from stage two to stage three is one of the more crucial hurdles to cross because it means, I think Stage 2 is, "okay, we have a proof of concept for how this is gonna work." Stage 3 means "we have validated that this will work in existing JavaScript engines." [20:49]
-
-**Mark Erikson:** it's going from alpha to beta, basically. [20:51]
-
-**Matt Pocock:** And TypeScript, too, takes that. When it gets to stage three, like optional training did a couple years ago, it takes that as a sign and it says, okay, now it's in stage three. Now we are gonna implement it. So everything that gets to stage three will be implemented by TypeScript. [21:04]
-
-**Carl Vitullo:** Okay, cool. I didn't know that was their go signal, but that makes sense. I think that I think last year when decorators advanced at stage three was like a pretty, maybe a quiet, but I think a pretty big turning point for the standard, finally, we can have a lot more confidence that they're going to land in the form that they are described there. [21:20]
-
-Maybe now we'll see a resurgence of libraries and tools making use of decorators as a first class api. And maybe now I'll actually consider using them because, you know, I'm unlikely to have the rug pulled out from under me and have the spec totally change. [21:34]
-
-**Matt Pocock:** Yeah, I think they've made it inning in kind of like a limited form. So the old experimental decorators had more metadata associated with them, so, which is not something they wanted to guarantee in this new version. So the new version is a little bit stripped down, a little bit less powerful, but I think there's probably gonna be more proposals that they're gonna add new things onto the decorators. [21:55]
-
-But I think they've just split the conversation up into a couple of steps, basically. But now that we've got this sort of basic decorator stuff, which is. For those who don't know decorators, let you wrap a method in a class or wrap a class itself and just let you bundle up some logic within that wrapper to, let's say, add logging to a function, for instance. [22:12]
-
-Or, validate the parameters of a function that gets passed in super useful and I think really nice. And I think, yeah, I'm excited for what people are gonna build with this. [22:21]
-
-**Carl Vitullo:** Yeah, and maybe to tie this back to the React ecosystem a little bit, I think decorators got a lot of excitement around the time when higher order components were one of the primary patterns in the React ecosystem, the idea was that, a higher order component is basically just a decorator, but without a syntactical feature enabling them. [22:40]
-
-Yeah, I think that'll be interesting. Higher order components are much less common now, but , I think they still have a real place in the React ecosystem separate from hooks. Like if you're just trying to, if you have an existing component that works and you want to add a seam between that and whatever is rendering it to add props or guarantee behavior, like for instance, I've used higher order components as an authentication wrapper so I can ensure that a component will never be rendered if the user's logged out. [23:06]
-
-So yeah, it'll be interesting to see what the impact of fully shipped standardized decorators will be on the React ecosystem. [23:14]
-
-**Matt Pocock:** I saw that Rafael asked in the chat, are the decorators fully backward compatible? No, they are not. So, yeah, angular, NextJS apps that, or frameworks that rely on the previous experimental decorators they will have a difficult time. I think too, there's a really interesting thing about React developers in general because if you probably asked the median React developer, do you like classes or not, they were probably gonna say no. Right? [23:37]
-
-Because I think a lot of React developers, especially those who made the transition when hooks came in, they'd probably feel a little bit of, hatred towards the old class components where you couldn't compose logic so easily where you had to do all of this, do all of that. So I feel like decorators might just go over the heads of some people who are primarily using React and JavaScript, but don't sleep on it. [23:57]
-
-There's a lot of cool stuff there. [23:58]
-
-## TS5 const annotations
-
-**Carl Vitullo:** Cool. Matt, can you take us through the constant type parameters? [24:02]
-
-**Matt Pocock:** Sure. So this is a funny one. This is one that's gonna affect, I think, library code more than application code. But what it lets you do is it lets you, when you create a generic function, and for those who dunno what that is, it means that when you call a function, you can tell TypeScript to capture something about the way that you're calling that function. [24:19]
-
-So one of its arguments, for instance, and you might have used in TypeScript, you might have used a feature called `as const`. And `as const`, what it lets you do is it lets you take a configuration object and infer it to like its tightest level. So it, if you have like a b ABC in there with like, let's say, let's say an array of success loading or arid for instance, if you wrap that array in as const, it actually infers success loading or arid, instead of it just being an array of strings. [24:47]
-
-what this behavior does is it gives you that same behavior when you infer it in a function. So you can say, this is like const t, and then that t or that thing that's being inferred will be it's, God, it's so hard to describe without actually looking code front of… my days. I think the question is like, when should you use it? [25:04]
-
-What is this going to help with? This is gonna help a lot, I think, with people who are just dipping their toe into generics and trying to figure out some of the weird stuff that's in there. I'm really excited to start teaching it more because it's gonna mean that more people get more access to more powerful abstractions, I think. And I think that's how it's gonna look. It's, you are gonna find it a little bit easier to make more complicated generic functions. And I think lowering that bridge is something that TypeScript really needs to focus on, because I think in every application you are going to have a part of that app. [25:40]
-
-Probably like the utils folder or some sort of shared abstraction that is going to be complex TypeScript wise. Is there anything that they can do to lower that? Drawbridge a little bit. Let a few more people in I think is great. And I think constant annotations is part of that. [25:54]
-
-**Carl Vitullo:** Yeah, I think that this const annotations would've made a very specific case that I've run into a number of times, easier to work with. When I'm working with TypeScript, I pretty frequently end up with basically, like a lookup object keyed by something to get some value. [26:09]
-
-And I'm trying to come up with an example off the top of my head, and I'm blanking, [26:13]
-
-**Mark Erikson:** Enums to components or something. [26:15]
-
-**Matt Pocock:** The thing that comes to my mind is translations, right? So imagine you have like an object of translations, where the keys are the, the translation and then the the actual values are the actual English translation. If you don't use as cons there, or you don't use cons sanitations, then it's gonna just sort of infer it a string. [26:32]
-
-And so you can't do any sort of like clever interpolation there. Like you can't get really cool with it. But if you strap it with a cons, then you can actually get the literal values of the strings. And so you can, detect whether a string has like a dynamic parameter, like a name or something, and then you can, oh, it is there's just so many cool things you can do with. [26:49]
-
-**Carl Vitullo:** Yeah. I am excited for this. It seems like a cool change. [26:52]
-
-## TC39 proposal advancements
-
-**Carl Vitullo:** Maybe a little bit related, moving one step of abstraction up from TypeScript the TC 39. Technical committee that determines the underlying standard. The JavaScript is an implementation of, had a new meeting and they advanced a couple of proposals. [27:06]
-
-So we've now got well one, one exciting one that I, people have been asking for forever is iterator dot range. Finally we have a way of generating an array range from a standard library primitive. [27:16]
-
-We've got explicit resource management, which actually that one confused me. It seems something somehow related to like generators somehow improves a pattern that's commonly used around there, but I don't know. I've never found generators that useful for things that I was trying to do, so I don't really understand that. [27:32]
-
-There was also Async context, which was advanced, I believe, to stage two. I seem to recall some conversation in the React ecosystem specifically about how like React would make use of the async context primitive. So I think that they had some input onto that standard, but I'm blanking a little bit on the specifics. [27:49]
-
-**Mark Erikson:** My vague understanding of that and that that's more from reading Twitter chatter than the actual documentation is. It's it's a little like React context in that you have some value, which is now accessible anywhere, but instead of being based on like a React component tree, it's like anywhere within an async call stack can access a value. [28:09]
-
-I think the hypothetical idea would be like, you have a server, you have some server side code, you have some incoming data, and you want to store information like per request call stack. So you know, this user, that database value, et cetera. And it should all go away when that async call stack unwinds. [28:28]
-
-I think that's the general idea. [28:30]
-
-**Matt Pocock:** Is the idea then to use that for streaming or to use that for server components? [28:35]
-
-**Mark Erikson:** I would assume server components because my understanding is that normal React context does not work in server components. I think. And so having this ability built into Node and in the language itself would then act as your equivalent for, I need to access this value anywhere within a set of server components. [28:56]
-
-**Carl Vitullo:** Sure. Yeah. This reminds me, I had two thoughts when I was reading this spec. My first one, I tend to write a lot of, functional code rather than object oriented. And one sort of downstream consequence of that is I tend to use, slash, some might call it abuse, module scope variables for tracking state, which that works great in a client side application where every, every user has their own context. You know, it's running on the user's machine. It does not work at all on the server side of things. [29:25]
-
-So I think that this is a new language primitive that would allow me as a, as an application developer to use a similar pattern to module scope singletons, but in a way that works out of the box on the server side. [29:40]
-
-That leads me into my second thought, which is this smells a lot like a. The session global from PHP it, I think it's not exactly that because it's not a global, but I think it allows you to declare something similar to a session wherever you want. [29:54]
-
-So it's, you know, it's not one global session per request, but you can say this is a session associated with this specific running context. So I think that's really interesting. That seems like a pretty large change to the assumptions that a JavaScript run time is based on. [30:08]
-
-There are some other some other small ones. I saw Float 16 array, just a new typed array. It sounds like that came directly out of a W three C request where they want to offer more precision for canvas buffers. [30:21]
-
-And last one that I wanna highlight is the Await Dictionary proposal, which looks like it's a sort of object based complement to Promise.All. [30:29]
-
-It allows you to await an object full of promises and destructure that as named, named variables instead of having to convert it to an array and then deal with argument ordering. [30:39]
-
-**Mark Erikson:** Which, I mean, it's syntax sugar, but if I can totally see how that would be handy. [30:43]
-
-**Carl Vitullo:** Cool. Yeah, some big changes there. [30:44]
-
-Mark, what do you wanna talk about? [30:46]
-
-## React labs update
-
-**Mark Erikson:** Okay. So the, one of the other really big things that came out in the last few weeks the React team put up what they call a React Labs post, which is their category for, here's the stuff we're experimenting or doing research on recently. Lot of really good, discussions there. [31:02]
-
-But some general highlights. One is they talked about their work on React server components. They talked about some of the changes they've made since the first proof of concept announcement that they did a couple years ago. They talked about how you can use async await within server components. [31:18]
-
-The first example of server components is shipped inside of next experimental app router. And they're doing some other work around being able to stream data and metadata as well. [31:28]
-
-## React Forget
-
-**Mark Erikson:** The part that I was really excited to read to the point that I'd been bugging some of the team members about this on Twitter at React Conf last year, the React team announced that they were working on an experimental React, optimizing compiler, codenamed React Forget. [31:45]
-
-And just for reference, the React team has a habit of like every project they have has a codename that starts with the letter F. React Fiber, React… Fizz, React Forget. [31:56]
-
-So the idea that they talked about is you write a normal React component and it looks at it and it figures out how to rewrite the internals of the component to better memorize and optimize the inputs and outputs of that component with the goal that it would eventually help save on this whole, like, "when is my component going to re-render?" [32:19]
-
-How do I avoid unnecessary renderers? When should I use, use memo and use callback and all that stuff. And that if the compiler works out, it would basically just do all that for you. They've had a team of about four or five people working on this for about the last year, and they gave a status update. [32:38]
-
-The general summary is that, they've got the basics of the compiler working. And they've bec because you can have literally any JavaScript logic you want in a React component, writing a compiler is really, really hard, versus a, a framework like Angular that uses HTML templates. [32:55]
-
-So they've started off by supporting like just a small amount of the JavaScript language as acceptable code that the compiler knows how to work with. And they've been trying, trained out inside of Facebook, they have been also trying to figure out like, how tied is this to babble as a compiler. [33:12]
-
-So they've made progress on it. They're hoping to open source it eventually. I don't know. Like I'm really excited about this. If the compiler works out, it will make our React apps run faster, it'll make it easier for us to write components. We won't have to think about that stuff as much. I just really want to see this in action and play with it myself. [33:31]
-
-**Matt Pocock:** To play like a bit of devil's advocate here — this does seem super cool — is there a danger that you could, it could over-optimize in certain places because, like caches aren't free. Like to a cash, reading from a cash or. Would it optimize things into positions where you would get bugs? [33:46]
-
-Are there ways to disable the compiler profile if you, I mean, I dunno why I'm [33:50]
-
-**Mark Erikson:** yeah, there's there's always caveats and trade-offs. One, one of the most obvious ones I can think of is that it'll, like, the idea is it'll look at the logic in your component. And for example, maybe it'll, it, maybe it sees that your component outputs like three different chunks of content in the JSX, and maybe it can figure out that one of those never changes. [34:10]
-
-The second only depends on piece of data. A and the second depends on piece of data B. Now, if I were to optimize that by hand right now, what I could do is extract the first chunk of content to be some JSX elements outside the component and just use that variable every time. And then inside the component right now I could have like a useMemo A, useMemo B. [34:37]
-
-So the idea is that the compiler would hopefully be able to figure that stuff out and figure out, this piece never changes. This piece only changes when data A changes. And the other piece only changes when data B changes. It is possible to do that stuff, but the compiled version might literally be more lines of JavaScript code. [34:58]
-
-So there could be, for example, an increase in the bundle size because it now has the extra logic to determine what needs to be memoized and whatnot. There's always a course of bugs because a compiler is just software, and old software can have bugs, but that's what they're trying to figure out right now is how much of the JavaScript language does it know how to support, what kinds of restrictions does it need to have? [35:19]
-
-How good is the code output? And they're testing it against fa, parts of Facebook internally to try to prove all that out. [35:27]
-
-**Matt Pocock:** It's interesting cuz React, hasn't had a compiler before, but other frameworks, like Svelte or Solid. Have their own compilers, which do their own optimizations as far as I'm aware. So it's interesting that they're joining onto this and it's interesting that this takes React from being just JavaScript, to having this little optional layer, I guess, on top, that sort of takes it away from just JavaScript. [35:48]
-
-So we were talking about React positioning before. I wonder if that impacts it at all. [35:52]
-
-**Mark Erikson:** It, it does in a couple ways, and this also ties back to the server components bit. Nothing about server components suddenly makes our existing client side React logic not work. You can still use Create React App, you can still use Vite, you can still data fetch in a component on the client if you want to, but now there are new options on the server that give React new capabilities. [36:17]
-
-So in the same way, let's say React Forget works, let's say the compiler comes out and it's, you know, it's now built into, next or Remix or whatever. You could still. Build a page by linking the React script tags and writing some plain JavaScript code that, generates the output with React dot create element, none of that goes away. [36:38]
-
-But now there is a newer approach that most of the apps would use, in the same way that, most React apps do use, webpack, Babel, SWC, esbuild, et cetera as a build step. So like, yeah, you could do things the old way, but there would be a new approach that, while technically optional would probably be built in to all these different frameworks by default and hopefully it would just work. [37:05]
-
-Fingers crossed. [37:06]
-
-**Matt Pocock:** Yeah, this feels kind of like eslint, really. Like, it's sort of an optional layer if you want to add it, and the React team has built like custom eslint plugins that help you, prompt you to add different things to useEffect and things. So it feels a nice little, it's a nice to have, right? It doesn't feel critical. [37:20]
-
-**Mark Erikson:** Well, if it works out the way I think it will, I think it'll be a technically optional, but you would really, really want to use it for the benefits kind of a thing. [37:29]
-
-**Carl Vitullo:** Sure, not using it is an escape hatch for if you are working in a context where it doesn't work. For sure. [37:35]
-
-**Mark Erikson:** Mm-hmm. The one other thing to note about this Dan has been trying to figure out like how he wants to describe these things, and this goes back to all the debates over the last couple months about like signals and Reactivity versus, virtual doms and all that kind of stuff. And one of Dan's point is that assuming again, that the compiler works out, the code that you write in your component would still be normal JavaScript, array maps and using plain variables and plain object. [38:03]
-
-There's no special wrappers around the data. You're not having to worry to remember to call functions to access the data, but that the code you write is still basically playing JavaScript and then it's the compiler's job to figure out how to make that better, instead of, you know, needing to remember like, I have to call signal dot, get to access a value, or, some of the other rules there. [38:26]
-
-So his argument is that the compiler would give you basically all the performance improvements, but without you having to worry about it in your own code. [38:34]
-
-**Carl Vitullo:** Well, I'm always all for not having to think about something, so that sounds pretty great to me. [38:39]
-
-## Offscreen rendering
-
-**Carl Vitullo:** That React Labs Post has so much detail in it about what they've been working on. I think it's really cool. Something in there that I thought was pretty interesting, the offscreen rendering feature. [38:48]
-
-**Mark Erikson:** Yes. [38:49]
-
-**Carl Vitullo:** I'm excited for that. I think there's, that's something that I've written some, components to help with. Like, they talk about it, your options generally having been to either not render it and then that has a performance cost of, it's gotta tear it down and set it back up [39:02]
-
-**Mark Erikson:** Losing state. [39:03]
-
-**Carl Vitullo:** Right. Yeah. Losing state, You either lose all your state and blow it away, or you hide it in CSS and then you still have to deal with all the performance implications of [39:13]
-
-**Mark Erikson:** or you put it in Redux or recoil or Mob X or [39:16]
-
-**Carl Vitullo:** Right, which is its own can of worms. This offscreen feature sounds very cool. I also like that it's taking advantage of a feature that was implemented in React. I think in React 18, like this is really a priority hint. This is a way for us as developers to say this is low priority. [39:35]
-
-But framing it as "offscreen" is interesting and useful. It, I think it communicates more about developer intent, like this could have been introduced as " deprioritized" or "low priority". But I think framing it as "offscreen" helps clarify when it's meant to be. [39:51]
-
-**Mark Erikson:** So I can tell you that we are actually using the Offscreen API in my day job at Replay right now. One of my teammates is Brian Vaughn, who used to be on the React Core team. And so he's brought over a lot of his knowledge of these relatively new and somewhat still experimental React features. And we've been using some of them in Replay's code for the last year. [40:12]
-
-So the offscreen component is available in React, but only in the daily experimental builds, not the full like official production releases. And so Replay uses an experimental build of React that has the offscreen component available. [40:29]
-
-We've been using it for, in the last, in most of the last year, and it actually works pretty well. We did run into one or two cases where they were having to like fix bugs in the behavior, and we actually got bit by that once or twice, but for the most part it works pretty well. [40:43]
-
-You just wrap an offscreen component around like the tab panel, or something that you care about. And then as you're switching tabs, instead of tearing down the panel, you just set, `offscreen = false` and it keeps it around and it works great. [40:58]
-
-**Matt Pocock:** They've been thinking about this for a while, right? This links back to the reason that because there was, sort of, a little bit of a furor when useEffect changed in React 18 to fire twice in dev mode, right? [41:10]
-
-**Mark Erikson:** Yep. [41:10]
-
-**Matt Pocock:** And the reasoning behind that was the offscreen was coming and can't remember what the link was. And could you fill in the gap for me? [41:19]
-
-**Mark Erikson:** Yeah. So, [41:20]
-
-um, [41:20]
-
-hang on. There's a very specific discussion from the React Working Group where they, they talked about this, and this is one of those cases where they iterated on how they wanted to describe it. Like originally they were saying like, "it's really strict effects and we're gonna make effects fire twice." [41:37]
-
-And then they changed it to emphasize the positive instead of the negative, where it's like, well, "React is going to preserve your state instead of fully unmounting the component," so kinda like the same thing but a different perspective on viewing it. So like reading that React Working Group discussion covers some of this. [41:55]
-
-**Matt Pocock:** Nice. Yeah I'm really hyped for this. I think it's gonna be great. [41:58]
-
-## Server Components
-
-**Carl Vitullo:** There's a lot we could say about React server components as well. I have not stayed super on top of their development, so I don't feel like I have the most context. been a, there's been a lot going on there. [42:08]
-
-**Mark Erikson:** The one line status summary I'll give is, they exist. The big issue is that they need to be integrated into a bundler and a router and a build system to have any value. [42:20]
-
-So right now, the primary way you could use them is by using the next 13 experimental app directory. Other framework authors are trying to play around with like, how would I build this in to Remix or just like a, or, standalone webpack config or something. [42:39]
-
-The problem is because it's still very experimental, there's no documentation on how to do that, so you've got like individuals playing around with it and trying to reverse engineer, how do I make use of this functionality by looking at next, or looking at the React test just because there, there isn't documentation on how to do it, but a bunch of different frameworks are playing around with the idea at the moment. [43:01]
-
-**Carl Vitullo:** Yeah, definitely. I'll respond to that in a sec. [43:03]
-
-We are coming up in an hour and Matt Pocock has a hard stop here. So yeah. Matt, thank you so much for coming out. It was really great having your perspective on TypeScript changes. [43:11]
-
-**Matt Pocock:** No worries. Really, really fun to chat to you guys as always. [43:13]
-
-**Mark Erikson:** Yep. [43:14]
-
-**Carl Vitullo:** All right. Thanks so much. [43:15]
-
-**Matt Pocock:** See Bye. [43:16]
-
-**Carl Vitullo:** That context for server components I think is interesting. It's the core team is really saying these exist, they are in use by some people, but they are not for general consumption. [43:28]
-
-**Mark Erikson:** Yeah. [43:28]
-
-**Carl Vitullo:** That reminds me of now, close to 10 years ago, that was the state of React context. [43:34]
-
-It was undocumented feature. They were using it internally, they knew that people would want to use it, but they weren't comfortable with the api. They wanted to iterate on a little bit more. [43:43]
-
-**Mark Erikson:** Funny thing is, I think React Redux, and Dan Abramov, like one of the first cases that an external library started using the original Legacy React Context api and that helped prove how some people wanted to use it. It also helped expose some bugs and weaknesses in that API design, and that's what led to the React Team building the current Context API that came out in React 16.3 a few years later. [44:13]
-
-**Carl Vitullo:** Yeah, and I was refreshing my memory on some of the timing around React versions recently. I didn't realize that we only got context around the same time as we got hooks [44:22]
-
-**Mark Erikson:** it was a few months. It was five versions and a few months earlier. Context came out in 16.3 hooks came out in 16.8. [44:30]
-
-**Carl Vitullo:** yeah. Okay. Just to me, context has been around forever. So seeing that actually not that, in, in the overall lifespan of React, it was officially released, not that far away from hooks. Like those would feel like two totally different epochs to me. [44:44]
-
-**Mark Erikson:** Very much so. [44:46]
-
-**Carl Vitullo:** But yeah, so seeing the React core team talking about. Server components in a similar sort of way of like, Hey, don't use this yet. It exists. If you poke around, you can figure out how it works, but we're not going to release documentation yet. Like that is certainly something that, that is a pattern that they followed before. It's not new. Not new for them. [45:06]
-
-**Mark Erikson:** And to be fair, Dan was grinding out the last several pages on the new doc site, and that took him a long time to do it. They just literally haven't had time to write documentation for things like server components, even if they were like fully done, which they're not. I mean, like literally they haven't had time to write documentation on the these things and how you would integrate them into a bundler. [45:29]
-
-**Carl Vitullo:** This feels to me like they are looking at how people are using React and seeing that many people are reaching for Next and Remix over just using React and both Next and Remix found their own solutions for something like server components. [45:45]
-
-So to me, this feels like they have been observing what's going on in the ecosystem, seen what patterns have arisen, and now we're trying to learn from those and introduce it as a feature within React so that then both Next and Remix can expose the same underlying abstraction rather than having, rather than fragmenting the community and coming up with their own core concepts for it. [46:09]
-
-I think that's absolutely the right approach for them to take and I'm sure that Next and Remix are excited for that because now they will have one less, feature that they need to maintain. I know Remix uses a .client or .server file name annotation I'm sure they would love to not have to maintain a feature for determining that separation. [46:28]
-
-**Mark Erikson:** The Next folks are obviously very excited about React server components. Probably cuz you know, half the React team now works at Vercel. [46:34]
-
-**Carl Vitullo (editing):** Fun fact, the core team has 25 members. There are 20 developers and five managers. So four reports each on average. Three of the engineers are independent three, work at Vercel and 19 work at Facebook. There are a lot more folks building React than many people realize. [46:50]
-
-**Mark Erikson:** I think the Remix folks are still kind of hesitant about the whole idea and how it would fit in. [46:54]
-
-**Carl Vitullo:** That's interesting. I didn't realize that. Yeah, I guess that makes sense though because so many of the core team is now at Vercel, Next is very much under their domain at this point. [47:03]
-
-## Asset Loading and Transition Tracing
-
-**Carl Vitullo:** Yeah, I guess closing up on the React Labs post, they also mentioned asset loading and transition tracing. [47:09]
-
-Both of those to me sounded like features that are likely to be pretty big sea changes for developer experience. They're not very flashy features. You know, they're not exciting, you don't get hype about it, but I think that both of those have the potential to be massively influential on what it feels like to develop code. [47:27]
-
-So I'm excited to see what comes out of those, but I, I don't know how much there is to talk about it. [47:31]
-
-And transition tracing, just to explain it to the, to audience. If you are doing performance profiling of a React app right now, they have code in there to track component mounting and unmounting. They can annotate your flame chart with what component is where. [47:45]
-
-But something missing from that is events. So you can't see on the flame chart when was a button clicked, when was a form input fired? So my understanding of this transition tracing feature that they're working on is it will annotate your flame chart with tho those details, which I, as someone who's done a lot of performance profiling for React applications, that is a pain that I have felt many times and I'm excited to see it come out. [48:09]
-
-**Mark Erikson:** I think the other aspect is that with React eighteen's ability to split a render into many pieces over time it's harder to be able to track like, really when did this render start and finish? And they, they wanted to make that more feasible. [48:25]
-
-**Carl Vitullo:** Interesting. Yeah, that makes sense. Yeah. I know they had done, they had the Reactive tools, which had like commit and [48:31]
-
-**Mark Erikson:** Mm-hmm. [48:32]
-
-**Carl Vitullo:** I can't remember the other term, but it had like [48:33]
-
-**Mark Erikson:** render phase and commit phase. [48:35]
-
-**Carl Vitullo:** Yeah, sure. And it, it could, like, you could use that to discover expensive components, but it wasn't super useful for actually figuring out what caused that expensive re-render to happen. [48:48]
-
-I think they said in the React Labs post that they had actually removed some of the code that was powering some of that because it just wasn't working for people, which was my experience. So, Cool. [48:57]
-
-**Mark Erikson:** Can I go off and talk about a work project for 30 for like one minute? [49:02]
-
-**Carl Vitullo:** Ooh, please do. [49:03]
-
-**Mark Erikson:** okay, so, I work at Replay. We're building a time traveling debugger for JavaScript, and we have the ability to inspect anything that happened inside of a running recorded JavaScript program. And over the last f last couple months, I've built some experimental features where I can write code that asks our backend, Hey, when did this piece of code run? [49:28]
-
-Or what was the call stack when it ran? And do more further analysis from there. And over the last couple weeks, I built an experimental feature in Replay, like, because I know a decent amount about how React works inside. I figured out that every time you call set state, it goes through one internal function inside React. [49:50]
-
-And if you ask Replay, tell me every time that function ran, and then you walk backwards up the call stack to user land code. Eventually you find the place in your code that you called setState, or in a lot of cases called a Redux dispatch, which goes through Redux and then eventually hits the same React internal function. [50:13]
-
-So I built a very, very experimental proof of concept panel where it, if you make a recording of a React app, it will walk through the recording and show you list items that represent every time your code called Set State. And then you prep, you click on one of those list items and it jumps you to that line of code and the time in the recording when it made that call. [50:38]
-
-It's still very experimental and proof of concept, but it does actually work. [50:43]
-
-**Carl Vitullo:** Cool. Yeah, I have not used Replay yet. I, and honestly at this point in my career, I'm not really doing like heads down day to day React code to the same extent that I used to be, but, I think if I were in a place where I was more frequently debugging complex issues… oh man, Replay just sounds like an incredible boon for productivity. [51:03]
-
-So getting more understanding of their internals React. Heck yeah. [51:08]
-
-**Mark Erikson:** Hmm. That also actually ties into something else I'm doing for my day job, but it will actually, hopefully have a benefit to the Greater React ecosystem. React ships multiple files in node modules, and they ship both a development copy of the React code, already bundled, and a production copy of the React code, bundled. [51:27]
-
-And the problem is that they have never shipped source maps. And source maps are what a JavaScript debugger uses to be able to translate from the minified code that is actually running in the browser back to like the original source code files. So like if you ship source maps with your application, even though it's been mangled down to one minified bundle, when you go to debug it, you can still see source/features/my-component.tsx and debug that original looking code. React has never shipped source maps. [52:01]
-
-And so that's why whenever you see like a, an error stack trace from React in production, all like there are no function names, everything's like, two letter gibberish. if you were to say like put a break point in a function component and then step, step, step, step out of the component back into React's, internals, it's all gibberish and you can't read any of it. [52:23]
-
-At Replay, we use source maps to also help debug code and so I as a Replay employee, have put in work over the last couple weeks to modify Reacts build system so that it will actually generate source maps for Reacts production bundles. And I got it working and I have a pull request up in the React repo. [52:47]
-
-I just need to convince Dan Abramov to actually merge that PR. So assuming that gets merged, fingers crossed, then starting with the next React release, hopefully, probably 18.3, you would be able to see what the original code looked like for the production bundles. In a, like, in like a deployed application if an error gets thrown in production, at least the stack trace would be a little more readable. [53:14]
-
-The React internals are really complicated, so you're still not gonna understand what's going on, but at least you could read the code. [53:19]
-
-So I'm really, really hoping that I can convince Dan to merge that PR within the next couple of days. [53:23]
-
-**Carl Vitullo:** Yeah. Very cool. Well I hope to see that la I hope you're able to convince Dan that that's a valuable contribution. I think sounds great. [53:30]
-
-**Mark Erikson:** Like, it works and they've got their CI system set up to do example builds from the PR. So you could try installing a copy of React from that PR right now if you wanted to, play around with it. But I tested it out in, a couple different projects, a Vite app, a next app, et cetera, and the source maps look pretty good. [53:51]
-
-**Carl Vitullo:** Nice. Heck yeah. [53:52]
-
-**Mark Erikson:** I probably oughta call it a day here and actually go get something done. In fact, what I probably had to do is go back to that PR and see if I can make a couple tweaks Dan requested. [54:00]
-
-**Carl Vitullo:** Ha. Well, thanks for going 12 minutes over time with me. It's been really great recapping the news and the React ecosystem with you. [54:07]
-
-**Mark Erikson:** Good stuff. [54:08]
-
-**Carl Vitullo:** Excellent. All right. Thanks so much. See you guys next time.
diff --git a/src/transcripts/tmir-may-2023.md b/src/transcripts/tmir-may-2023.md
deleted file mode 100644
index 00a5b4c..0000000
--- a/src/transcripts/tmir-may-2023.md
+++ /dev/null
@@ -1,457 +0,0 @@
----
-title: This Month in React (May 2023)
-date: 2023-06-05
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-
-
-**Carl Vitullo:** Hello everyone. Thanks for joining us for May's This Month in React, where we recap and digest recent developments in the ever-evolving React and web ecosystem. I'm here with Mark Erikson and Sebastian Lober. Mark, you wanna introduce yourself? [00:15]
-
-**Mark Erikson:** Hi, I'm Mark Erikson. My day job is working at Replay, where we're building a time traveling to bugger for JavaScript. My free time, copious amounts thereof is taken up maintaining Redux. [00:26]
-
-**Carl Vitullo:** Heck yeah. Sebastien, can you introduce yourself? [00:29]
-
-**Sebastien Lorber:** Yeah. I'm the author of this in React, the newsletter at keeps You to date with React and React Native, and also the maintainer of Docusaurus React documentation framework from Meta. [00:42]
-
-**Carl Vitullo:** You know, I realized that I have been asking you guys to introduce yourself and I don't really introduce myself. [00:47]
-
-**Mark Erikson:** Carl, would you, would you tell us about yourself? (laughter) [00:50]
-
-**Carl Vitullo:** Yes, I would love to. I'm Carl Vitullo. I am a staff software engineer and freelance community manager, sort of community lead for Reactiflux. [00:58]
-
-I, I think, not a ton of huge news going on right now, but yeah. Mark, can you kick us off with our first link? [01:04]
-
-## Next 13.4, App Router and Server Actions
-
-- [Next 13.4](https://nextjs.org/blog/next-13-4)
-- [Server Actions](https://nextjs.org/blog/next-13-4#server-actions-alpha)
-- [Isomorphic Development](https://meijer.ws/articles/isomorphic-development)
-- [Rich Harris on frameworks, the web, and the edge](https://www.youtube.com/watch?v=uXCipjbcQfM)
-- [RSC data leak security footgun](https://twitter.com/tomus_sherman/status/1654211227172716545)
-
-**Mark Erikson:** Okay. So first off last month, Next 13.4 came out and the, the really big news item out of this is that they are declaring that the NextJS app router is stable, which has a couple different implications. [01:20]
-
-One is that it's a different way to define the routing structure through your page. And the second is that this is the first official "production" ready release of React Server Components. [01:33]
-
-Now this is where it's always dangerous for me to try to describe things because I have not had a chance to use any of this stuff. So, you know, a lot of what I can say here is either looking at the announcement blog post or trying to summarize the stuff that I've read off the various discussions on, on Twitter and Reddit. [01:51]
-
-So at this point, React Server Components are in theory production ready to use, and I've certainly seen people, you know, mentioning that they've, you know, they've rewr rewritten their blog or, you know, put together some actual example sites using React Server Components. [02:07]
-
-It feels like there's still some question about just how production ready they are, both in terms of stability as well as like what are expected usage patterns and how do you integrate various existing community tools and libraries into those. But you know, at least as far as the Next team is concerned these are in theory pretty much ready to go. Um, so that's, that's by far the, the biggest piece of news. [02:37]
-
-And then looking at the release notes the couple other big things in 13.4. Next has a team building a tool called TurboPack, which is a equivalent kind of build tool to Webpack, except it's written in Rust. It's being written by the original author of Webpack, Tobias Koppers, and it's supposed to be significantly faster. And so the release notes say that they, they are marking TurboPack as being in beta. It still does not have full future parity with Webpack, but they are making progress on it. [03:11]
-
-And then the last piece is something that I, I, I've only seen bits and pieces about myself, which is that Next and React are working together on something that they call Server Actions. And this is apparently very inspired by what Remix has, where it's, it's like a new primitive for sending requests to the server based on plain HTML forms. [03:37]
-
-And I, I think the idea, looking at the examples is that on the client side you have a lowercase form input and you provided a prop called action. And that action can then in turn, really run on the server and do like a direct database insertion or query or something like that, and the compiler is able to separate out the fact that this action function needs to run on the server versus the rest of the code, which could technically run on the client or the server. [04:11]
-
-So it's, it's kind of like that Remix style thing where you're writing code in the same file that mixes together client code and server code, and it automatically just works. So they, they announced this Server Actions idea. It's still very much an alpha and experimental, but it is a thing that they're working on right now. [04:31]
-
-And so these, these pieces have the possibility if they, you know, actually pan out to be pretty large changes in the way we structure and write React applications. [04:41]
-
-**Carl Vitullo:** Yeah, definitely as you were and you know, as I was reading the notes on Server Actions, my immediate thought was Remix as well. [04:48]
-
-I do think that's a really powerful pattern that Remix introduced. So I'm excited to see Next Adopt It. And yeah, I mean this is, to me, this is exactly why it's so beneficial to have multiple clients doing, or, you know, mul multiple tools trying to solve the same use cases cuz they come up with different ideas and some of them stick. I'm pretty excited to see Server Action stick. [05:08]
-
-I think this, I think if you're going to have code that spans the server and the client, you know, it can't all be UI code, not everything we do on the server is render UI. So having, you know, an easy way to run other types of arbitrary code. Yeah, that sounds awesome. Excited for Server Actions. [05:25]
-
-**Sebastien Lorber:** Yeah. I'm also excited for, for Server Actions. Maybe for another reason is also the, the support for Progressive Enhancement. Because so, so far Remix has shown that it's possible to, to have a great Progressive Enhancement story with React, but this kind of feature was lacking in in NextJS. And now they, they, they show that they really care about it. [05:49]
-
-And you know, when you submit a form now the abstraction, the the abstraction make makes it possible to, to submit the form without JavaScript, without even direct being hydrated on the client. And the server is able to, to receive the form submission and and send the new HTML page. depending on if JavaScript is running on the client or not, the payload will not be the same. [06:16]
-
-And actually, I think the NextJS markets this feature as Server Actions. But really I think the action prop is right, is a React Core concept. Now you can you can pass an action to a form in React and it can be a very string or callback. And, and depending on whether the JavaScript will run or not the, you will use one form or another in NextJS to support a progressive announcement or the submitting the form locally with a JavaScript. [06:51]
-
-**Carl Vitullo:** Okay. Interesting. I didn't realize that this was a React concept that Next is looking to expose. [06:57]
-
-**Mark Erikson:** I think it's a plain HTML concept that they are extending. So the plain HTML form element has always had an `action` attribute that would, I think it defaults to POST, and that's why if you just have a plain HTML form and you submit it, the browser literally makes a post request to the server, right? [07:19]
-
-Uh, I think you can change it to be GET instead. And so I guess technically what the React team is doing is they're overloading the existing action attribute so that you can pass a function instead of a string. And if so, they, they wire things together on both ends. [07:37]
-
-**Sebastien Lorber:** Actually, what you mean is the method, POST or GET is the method and action with the URL of the, the target endpoint of the form. [07:45]
-
-So somehow they just allowed to accept the callback. But I think on the, on the server, the, the callback is serialized to string by the compiler so that before hydration React is able to know where to post the form on the server. [08:02]
-
-**Carl Vitullo:** Oh, interesting. Okay. So I think I see, I think I see what you're saying. [08:05]
-
-So I just put a little code snippet in the chat here. So there's this page component, it has a function defined inline. [08:12]
-
-**Mark Erikson:** The key, the key thing is that it has the "use server" string inside, and this is where the compiler part comes into play. So similar to Remix, you've got code that could run on either side in the file and some code that only runs on the server in the file. And they have to have some way to delineate which code in that file is server only, and they're basically just gonna strip that out of the part that goes to the client. [08:40]
-
-**Carl Vitullo:** Okay. That's interesting. Okay. So it doesn't need to be inline. That's good (laughs). I, I'm not a huge fan of this "use server" tag, but like, okay, sure. That's how, that's how it works, whatever. Um, it reminds me of an article I read recently talking about "colored functions" and how it's yeah, it just introduces multiple types of functions here. [08:59]
-
-But the point I wanna make here, to me, this actually just reading this code and thinking about this as like, the compiler is extracting out the function, it seems almost more like a developer experience improvement on serverless. You know, because you could write a function like this that handles a single form, but it's pretty painful to do that with a serverless backend. [09:20]
-
-So having a compiler that will extract out that code and handle the packaging it into a serverless, you know, executable and putting it somewhere and inserting the url, or Yeah, inserting the URL into a form. That actually that's, that's actually really interesting to me. [09:37]
-
-**Sebastien Lorber:** There is something to, to not be wrong about this snippet is that, you are not mixing server and client, code inside the same file. The whole component is a server component and the "use server" only expose the function to the public interface of the server, somehow. [09:55]
-
-So I think the, the first reaction you have when you see the, the snippet is, you are able to somehow mix server and client side code in the same file. But it's not exactly that. [10:05]
-
-It's more like, inside your server component you can choose to render functions and some of them will get exposed to the public interface that the server runtime will create. So I just want to, to, to make sure that people don't make this confusion because the, the form is a server component. It's not a a client component. [10:26]
-
-**Mark Erikson:** That, that does kind of go into, I guess my, my biggest concern with all this stuff, and that's trying to wrap your head around the mental model. My biggest personal problem is I just literally have not had a chance to use any of this. So I've been trying to understand it without actually using any of it in practice. [10:43]
-
-But it feels like trying to understand these boundaries between what's, what's a server component, what's a client component? Like as my Redux co-maintainer Lenz has pointed out, it's like, client components can run on the server, the phrases server and client don't necessarily have the meanings you think they do with this technology. Um, I actually wanted to link two other articles that I'll, or, well, an article and a post that I'll throw in here. [11:06]
-
-And I thought these did a pretty good job of discussing some of the, the pros, cons, concerns, and trade-offs with both like,, Server Components as a technology, and in general, what we're doing as we kind of mix and match with this code where you can have a database call and something that runs on the client in the same file, it starts to blur the lines. [11:30]
-
-And we're doing this sort of in pursuit of developer experience, but it does bring up potential concerns around things like accidentally Exposing API's, keys, or secrets into the client if you're not careful enough about how you structure the code, or just trained to wrap your head around what pieces of code are going to run where, and I know Dan has said that, you know, in, in a lot of ways this simplifies how you teach React to people because you don't have to explain, "well, I, I make a fetch call when the useEffect" or "I have to go learn how to use React Query" or something like that. [12:08]
-
-Instead you just, you're just making an async/await call inside of a component and it just works. And I see the point he's trying to make, but there are a lot more moving pieces involved here as well. And I don't have a great answer for how are we going to teach all this and what kind of problems are, are people going to run into as a result. [12:31]
-
-**Sebastien Lorber:** Yeah. By the way, there, it's worth mentioning that there is a little security issue that related to the Server Actions in NextJS, I will post in the chat. A tweet related to that is that if your server action captures a variable in its closure, actually this variable will be sent to the client inside the form as a hidden parameter, so that it'll be sent back to the server so that the, the closure is able to, to see this variable again, because unlike client components, the, the Server Components do not have state. [13:07]
-
-I, I mean, for example, if one server component serve your request, it might be in AWS US west 1, and then on the second request, it might be another data center that serves your request. So all the Server Components have to be stateless. And if you need to preserve state across closures inside your Server Components, they must be sent to the client. [13:31]
-
-And currently this is a risk to expose secrets to the clients. So the React team said that they were thinking about encrypting the hidden parameters, but it's not ideal solution because of course you, you don't necessarily want to expose secrets even encrypted. [13:50]
-
-And I don't know what will be the, the solution and if a decision has been made, but it's worth knowing that there is a little security issue currently regarding the usage of Server Actions. [14:01]
-
-**Mark Erikson:** I actually just had a, a side flashback to the, the old classic ASP.net view state approach for serializing data to the client. [14:10]
-
-**Carl Vitullo:** But so we're, we're 20 minutes in. We've done one link, so we should probably move on (laughs). That's a lot to talk about though. Yeah. Sebastian, you wanna take us on to our next one? [14:20]
-
-## React Native Skia
-
-- [William Candillon – The Joy of Painting with Skia | App.js Conf 2023](https://www.youtube.com/watch?v=Hfb_gpfCHzk)
-
-**Sebastien Lorber:** There have been uh, three React Native conferences this month. There was AppJS in Poland, there was uh, Chain React in USA and there was a React Native Connection in Paris. I like particularly the talk of William Candillon that presented the progress with React Native Skia, which is the renderer used inside Flutter and inside Android and inside Chrome, and inside many of other things. [14:43]
-
-And you can use it in React Native today, and it permits to, to somehow unlock many use case that that were not possible previously. The talk is presenting a few interesting things like the ability to create a screen transitions that are powered by OpenGL shaders and things like that, that's quite impressive. [15:03]
-
-**Carl Vitullo:** Interesting. So it's about, painting. So it's sort of like, is this like a React Native version of Canvas? Sort of? [15:11]
-
-**Mark Erikson:** Just as a little better background Skia is a C++ library for two-dimensional graphics. And my understanding is that most browsers actually use this to literally draw stuff on the screen in the first place, including implementing the HTML Canvas element. So it sounds like this is now, this library is now being exposed as something you can use from React Native to do custom graphics. [15:40]
-
-**Sebastien Lorber:** Yeah, it's exactly that. The idea is that you have a canvas, you have some primitive that you can draw, you can use OpenGL shaders and things like that. [15:49]
-
-In the beginning, I think, maybe last year they released the first proof of concept. And then there was Shopify that was interested in this lib and sponsored it. So now the, the development in is funded by Shopify. I think the first version was more of a proof of concept, and now it's more production ready. [16:09]
-
-I think one of the challenge in the beginning was also that it was not possible to interleave easily the, the canvas inside the native application because somehow the, the canvas was over the native views or it was under, and you have to, to do the trade off of deciding how to integrate the canvas inside your app. [16:28]
-
-So it was a bit complicated to achieve certain visual effects. And now the integration is better. The talk is showing some possible solutions to, to be able to integrate better with native views and things like that. And also to integrate better the canvas with Reanimated, which is the popular animation framework, for React Native today. [16:48]
-
-**Carl Vitullo:** Interesting. Okay. Very cool. So I wonder if using the same primitives as Canvas and the browser, I don't know if this is the case, but I wonder if it will allow a lot more cross compatibility with that sort of graphics rendering. Yeah. That using the same primitive, the same, you know, base tool to bring that into, into native. [17:09]
-
-That, that does seem like a really huge step. Yeah. [17:12]
-
-**Sebastien Lorber:** I think it unlocks a lot of things and we are just in the beginning, yeah. [17:16]
-
-**Carl Vitullo:** Yeah. You know, honestly, that reminds me of the effort to bring Flexbox rendering into Native. So, yeah, I mean, graphics rendering is really hard. It's also really powerful. So if we can have similar primitives for doing graphics rendering on both web and native, yeah, I could see just a little glimpse of what new features that would enable. Yeah. Very cool. That's pretty awesome. Cool. Okay, [17:40]
-
-I'll move this on to our next one. [17:42]
-
-## Struggles with Remix
-
-- [My Struggle With Remix](https://redd.one/blog/my-struggle-with-remix)
-
-**Carl Vitullo:** Yeah. Um, I wanted to share a blog post about someone sharing their struggle with Remix. I think it's good to talk about not just what's great about things, but also where the rough edges are. Um, and this seems like a pretty measured and realistic perspective on where some of the rough parts on Remix are right now. [18:03]
-
-It talks about the developer experience and some of the struggles there. Routing is too magical is one of its points, which I, I do, I, I think I agree with a little bit. It basically has its own DSL, domain specific language, for routing where, as part of the file name, as part of the path for your routes, it does a lot of parsing out of that string and changing behavior based on that. [18:26]
-
-So like having to learn a brand new DSL for routing that you don't really have a lot of control or access into, outside of that, like that, all that, that all happens as part of the Remix dev and build server. It's not super inspectable and uh, definitely a little bit magical. [18:42]
-
-One of the categories of complaints it has is that it gives you enough rope to hang yourself which is both great and terrible. It, it is nice that it is so powerful, but part of the downside of having so much power is that it doesn't do a lot of things for you. [18:56]
-
-This author talks about needing to write a lot of supporting logic for handling things like static assets like you, you put a relative path to an image in your markdown, and then you have to write code that understands how to parse out that relative path and convert it into a, an absolute path when it's actually showing the page. [19:11]
-
-So, I, I, I, this seemed like a really good, I don't know, collection of some of the rough spots in Remix right now. [19:16]
-
-**Mark Erikson:** Uh, again, I, I have not used Remix, so I can't comment on the technical aspects here, but I, I really did appreciate this post because it was very clearly written. it was framed as "these are my experiences and pain points using it," not, "oh no, this tool is awful." it was actually like more of an attempt to say, how can we make this better rather than attempt to bash the tool or its authors. [19:43]
-
-And I appreciate that. Like, there, there's just so many negativity and, you know, "tool X kills Y" being thrown around and I, I, I appreciate it when we can have reasoned debate and discussion about technical trade-offs rather than flame wars. [19:59]
-
-**Carl Vitullo:** Yeah. And I, I appreciate that in the, you know, in the intro setting off the whole post, he says, "I think Remix is a great framework. I will not be mentioning Remix advantages." Uh, it kind of, it reminds me of that scene in the Silicon Valley TV show a number of years ago where they're talking about their frustrations and they, they come up with an acronym for "Richard is great, but." You gotta get that outta the way you gotta "Remix is great, but." [20:23]
-
-So I think this was a great way to, to focus on the challenges without having to extol all of its great virtues of which there are many, it has a lot of great things. [20:32]
-
-**Sebastien Lorber:** Yeah. But the, the author in the end, "I still would use it for a startup," so that's already quite nice. I think the conclusion was he wouldn't pick it again for a blog. I tried also to, to create my newsletter website with Remix in the past, and also I thought it was a bit it had some rough edge, but it was possible to use it, but maybe not the, the simplest solution. But also they focus maybe on low level primitives and a bit on the architecture side. And for example, I'm quite surprised that the author was looking for the, you know, the markdown images to be able to use the relative image path. I don't think it comes for free in many frameworks. [21:12]
-
-I know that does it, but it's not free, it's we have to implement it manually. So maybe NextJS does it. But I don't know. That's not something that for me come out of the box unless the framework is opinionated to where they're using MDX or something like that. But, otherwise not too surprised that this kind of feature is doesn't come outta the box. [21:34]
-
-**Carl Vitullo:** Yeah. Agreed. He mentions. Gatsby doing this for him, and that wasn't my experience. I haven't used Gatsby extensively, you know, in any deep capacity for a number of years now, so maybe something changed, but I, I do remember having to write code that did exactly that when I used Gatsby in about 2018. So, yeah, I don't know. [21:52]
-
-Cool. Mark, you wanna take us off? [21:53]
-
-## You Might Not Need React Query
-
-- [You Might Not Need React Query](https://tkdodo.eu/blog/you-might-not-need-react-query)
-- [Using Apollo Client with Next.js 13](https://www.apollographql.com/blog/announcement/frontend/using-apollo-client-with-next-js-13-releasing-an-official-library-to-support-the-app-router/)
-
-**Mark Erikson:** Yep. So continuing with the, the Next 13 and Server Components theme, a lot of the big questions within the community have been how do data fetching libraries like Apollo React Query, RTK Query, and SWR, work in conjunction with Next 13.4 and React Server Components, and the, the new app directory. [22:19]
-
-And there's a couple, couple big discussions and pieces of news on this front. One is that Dominik Dorfmeister, the maintainer of React Query, wrote a post entitled You Might Not Need React Query, and you should read it because it's, it's a really good post in general, like everything that Dominic writes. [22:38]
-
-Some of the summary here is that , if you choose to do data fetching with React Server Components, well, React Query is a data fetching library and you just chose to use a different tool to solve that problem. That's not to say that React Server Components completely kill React Query because where and how you need that data or some, or if you need some of the specific features of React Query there, there are still very much use cases. [23:10]
-
-But it's, it's that same kind of question of, there's, you know, 3, 4, 5 tools available to solve this problem. If you pick one tool, you probably don't need the other tools that do some of the same thing. Another item is that my Redux co-maintainer, Lenz Weber, recently started working for Apollo and he works on Apollo Client in his day job and thinks about RTK Query in his free time. [23:34]
-
-And he spent a couple months trying to work through Server Components and Apollo and figure out how these things even can work together at all. I'm still not clear on all the details, but he, he put up a RFC document that describes how Apollo and Server Components can even potentially fit together at the technical level. [23:59]
-
-And then there was a blog post that accompanied that, where I believe they put out some kind of a proof of concept library that can help Apollo and Server Components sort of go together. We've been getting a lot of questions about like, so I wanna use Redux, but I also you wanna use Server Components. [24:16]
-
-How do they fit together? And you know, like, to a certain extent, you know, the answer is they don't, you know, both at the, at the technical level and the conceptual level, that's sort of the same thing over here, but it's, it, there's still a lot of open questions around all this stuff. I think that Lenz's proof of concept library is doing some very specific hacks that only work with Next in terms of how it's able to serialize and stream data onto the client. [24:44]
-
-One thing I know when said is you wouldn't want to mix and match fetching data on the server and fetching the same piece of data on the client. It's like it either needs to be done via a server component or it needs to be fetched on the client, but you wouldn't do both for the same piece of data at the same time. [25:04]
-
-The short answer is no one knows what we're doing, we're all trying to figure it out, and there's a lot of open questions. [25:09]
-
-**Carl Vitullo:** Yeah. I mean, how does, when people ask, "how do these things fit together," I think like everyone is still figuring that out because Server Components are such a brand new concept. But you know, there, there's so many different types of server interactions. [25:23]
-
-Like when you're first loading a page, like the data that you need is like, you need to do an auth handshake. Like, do you already have a valid token? You need to load the user settings data, you know, which is my, in my experience, there's like JSON blob for the user that contains, like, do they prefer dark mode, what feature flags are enabled for them? There's, you know, whatever data is initially necessary to render for the page. [25:47]
-
-Then, okay, sure. All of that stuff's loaded. The page is rendered. They're clicking around. Then they need to, you know, they scroll down on Reddit and they need to load more content. Or they submit, they click an upvote button and they need to send something back. Like, all of these are different. [26:03]
-
-Fundamentally, they are server interactions, like an HTTP request is made, A response is sent, whether that's JSON or HTML or whatever. So like superficially, they're all server interactions, but like categorically, like semantically for the user, for the app, they all have very different constraints associated with them. [26:24]
-
-And so like React Server Components very helpful for the first set of those things. Like as you're hydrating, as you're rendering the first HTML that the user will see and interact with, I absolutely understand how Server Components interact with that category of data fetching. But then like the, you know, then there is still the client side mode, like the, if you're doing an infinite scroll interaction, like there is no, the server has nothing to do with that. [26:51]
-
-The server doesn't even know where on the page you are. It has no way of observing that. So that is purely a client side interaction. So, yeah, I, I don't know. I feel like where does this fit in? It is it, it's new. It's, it's a new space. You know, it replaces some of the data fetch, but it doesn't replace everything. [27:11]
-
-**Mark Erikson:** Uh, and another couple examples I think Lenz was pointing to was that Server Components are kind of limited in the sense that it's, it's another way to pass down props to client components. You know, like Apollo has this very powerful normalized cache, so if you like it, it keeps track of items by type and by ID so that it's only re fetching, you know, like the, the three missing to-dos you haven't grabbed out of the 100 that you already have already. [27:41]
-
-And I don't think Server Components can necessarily help with the normalized data use case, and I don't think they can help with the ongoing push subscription use case either. [27:53]
-
-**Sebastien Lorber:** And I think one of the case that Dominik presented was, for the infinite scroll. The idea, for example, was the server component would render, the, the first part of the, the infinite call, maybe the first page and the React Query would be able to kick in later. [28:11]
-
-And you would use React Query for the, for the upcoming page, the, the second page, the third page, and things like that. [28:18]
-
-**Mark Erikson:** Yeah. So a lot of things to be figured out here. Yeah. [28:22]
-
-**Carl Vitullo:** Yeah, definitely. Cool. Sebastian, do you have another link? [28:25]
-
-## Expo Router v2
-
-- [Write Once, Route Everywhere: File System-based Navigation for Native Apps](https://www.youtube.com/watch?v=608r8etX_cg)
-
-**Sebastien Lorber:** Uh, maybe I can just give some little news about the other things that happen that React Native conferences because I know that you won't cover much React Native. [28:36]
-
-Maybe the most important one is the announcement of Expo Router version two. And I think it's important because it shows that actually the using Expo and React Native. For the web is becoming something that is quite serious. I mean, the first version was somehow like a Create React App, but using Ative for creating a website. [28:58]
-
-So it was not so great. It was working because you were able to create an application with React Native and published on the web, but as it was only clientside routing, it was a bit limited and you couldn't really use it for many use case, for example, when you need SEO and anything like that. And clearly the, the Expo Router is progressing to making this much more production ready making less compromises when you create a web application using Expo. [29:31]
-
-For example, this new version will have static routes, so you will be able to pregenerate a static website from your Expo app that you can publish on Netlify or Vercel or, whatever. There are also features that are interesting. For example, universal linking, which means that you use the, the URL forwarding on the mobile app. And this gives a lot of interesting benefits, like the ability to seamlessly transition from your web app to your mobile app and to have universal links. [30:00]
-
-For example, you, you tap a link on an email that you receive on, on mobile and we, it'll open the mobile app if you have it installed, or it'll open the website if you don't have it installed. And there are other things that maybe I should just keep it simple. Expo Router is bringing maybe a, a good experience for the developing website using React Native technologies. [30:25]
-
-And I think it's important because we, we want a shortcut, and I think it's exciting and maybe eventually Expo will catch up on the web with other frameworks and provide more and more features and I don't know, maybe compared with NextJS, someday, I hope it'll be the case. [30:41]
-
-**Carl Vitullo:** Yeah, interesting. [30:43]
-
-My experience with trying to do things and React Native has been the story around navigation is so confusing and different from what I'm used to on the web. You know, like the React promise of "learn once write anywhere" has not been true so far in my experience. Just because the fundamental, the, the base assumptions on mobile for, how do you navigate within the application are so, so different. It, it is learning a brand new context and so it's not learned once I, I do have to learn twice. Yeah. Hmm. [31:15]
-
-Seeing some file system based navigation show up in React Native, anything that brings the experience of navigation on React Native to something more familiar for Web concepts. I'm excited to see that. That makes, that makes a lot of sense. It seems like a big improvement. [31:31]
-
-**Sebastien Lorber:** Yeah. It's not easy to master the navigation in React Native in the beginning. [31:36]
-
-And I think for example, if you look at Expo Router, there are some conventions or things that are not exactly the same as in NextJS because maybe, you know, when you, you target all the platforms, you, you need to think about a few things that NextJS doesn't have to, to think about because As they only target the web they only need to to create conventions that work on the web. [31:58]
-
-But maybe Expo Router needs to, to find some abstractions that work for free platforms instead of just one (chuckles). [32:06]
-
-**Carl Vitullo:** Yeah, for sure. [32:07]
-
-## Improving Performance with HTTP Streaming
-
-- [Improving Performance with HTTP Streaming](https://medium.com/airbnb-engineering/improving-performance-with-http-streaming-ba9e72c66408)
-
-**Carl Vitullo:** I'll, kick us off with our next link. This is, so this is a, a blog post from Airbnb engineering. Airbnb has a history of releasing some pretty influential blog posts on their engineering practices. I know esp, especially in the context of React Native, the Airbnb blog post of, "we're moving away from React Native," uh, still has, I think they wrote that like six years ago and it still has echoes on the ecosystem. [32:33]
-
-But yeah, so they, they, I saw this, you know, improving performance with HDP streaming and it's not directly about React. But I think that the concepts that they're talking about have a lot of overlap with React Server Components because ultimately, you know, the goal for React Server Components is improving first load performance. And so this is one example of a first load performance improvement that can be done entirely in isolation from React and even from JavaScript. [33:02]
-
-Like everything they talk about is an HTML level optimization. But it's also, it's a good background reader on things like network waterfalls, early flush talks about sequencing of loading assets, which I, I think it's, these are things that I had to learn on sort of by trial and error, just sort of realizing like, "Ooh, this has gone badly and I need to figure out how to make it better." [33:25]
-
-And in researching those things, learned a lot of the concepts that are discussed here. So I, I thought this was a really good framing for sort of a background reader on concepts that will be very important to understand as code that takes advantage of React Server Components is being written. [33:43]
-
-Cool. And I guess that's all we gotta say on it (laughter). Yep. Cool. Mark, what do you got? [33:50]
-
-## React Canary Releases
-
-- [React Canaries: Enabling Incremental Feature Rollout Outside Meta](https://react.dev/blog/2023/05/03/react-canaries)
-
-**Mark Erikson:** So the, the React team put up a blog post announcing what they're calling Canary version releases of React. So historically the React team has primarily delivered React as your standard semantic versioning releases. [34:05]
-
-So 18.0 major, 18.1 minor, 18.2 minor. And they've also had an experimental channel, which as the post points out, they'd also referred to as their "next" channel which were just daily experimental daily builds of React, which. In addition to being built every day, also had a bunch of feature flags turned on so that work in progress, experimental features were included. [34:34]
-
-And we've actually been using an experimental build of React at my day job Replay, for a long time now because we've been doing some things with like React suspense in our code base, and those relied on methods that only existed in the experimental builds, not in the public, like 18.1. 18.2 builds. [34:54]
-
-And if you were to go look at NextJS, my understanding is that they have been shipping specific ver like pre-release versions of React with Next for a while now, in order to also make use of some of these not yet final features, and this is actually bringing up a problem for a couple reasons. [35:18]
-
-One is that there's a lot of confusions about what features are actually ready for, for production use. Another is that, you know, you see some people complaining that, well, you know, Next is getting kinda like an unfair advantage in being able to use these features. And third, like it's, it's actually been like a year since React 18.2 came out and we, we, I actually have no idea when 18.3 will even be released. [35:44]
-
-So with this blog post, the React team is announcing that they're going to start releasing a series of canary builds, which are somewhere between like a daily, just whatever is at the tip of, of main build and an official public semantic version in release. So that Canary builds will have these experimental features turned on. [36:08]
-
-And they will actually say ahead of time, here's which ones are basically stable or not. And they're actually encouraging frameworks and, and other packages to try out these features and even say, and even go ahead and use them for real, but to like pin what version you're using to a specific canary release. Not just like whatever one is, is the most recent. [36:33]
-
-And the comment is that sometimes they work for a long time on some of these features and sometimes a bunch of these features overlap and they, they might even be ready before the React team decides to make a new official semantic version of your release. [36:48]
-
-So it, it's good because it's kind of making that like, here's here's some of the work in progress stuff available in a somewhat more official way. It's also really confusing because. It's hard to keep track of what pieces are actually ready or not. And there's, there's a couple examples of this. So like, eight months or a year ago, the React team published an RFC where they announced there was gonna be a new hook called use, which was, it would let you actually kinda like unwrap and await a promise in a, in like a client component. [37:21]
-
-And that RFC was published and there were a lot of comments mostly complaining about the name. And the RFC said there will be a follow up RFC talking about some kind of new caching capability. And like, there's been nothing published about it since then. And frankly, we, like we library maintainers roll, like, "uh, is this thing dead or what?" [37:42]
-
-But apparently it's already like shipped and being used in production in Next 13.4. And so there's a lot of confusion about like, what is the status of these features? So hopefully the Canary builds will ha help make it a little clearer when these features are ready to actually try out. I've also had some discussions with React team members saying like, it would be really helpful if there was like a public list of what features the React team is working on and what their current status is. [38:11]
-
-Kind of similar to how TC 39 develops new JavaScript features. Like is it, stage zero, we have an idea. Stage one, proof of concept. Stage two, it mostly works. Stage three, it's almost ready. Stage four, done. Something like that would really be helpful for the community to understand things, but at least these canary builds are a step in the right direction where it's like a little more ready to try out. [38:35]
-
-**Carl Vitullo:** It's interesting that there's been that much confusion from library maintainers around, really like, what's part of React. I'm a little surprised to hear that that's been a point of confusion because that, that really does seem like a very, very important for both the React team and for library maintainers to both have a shared understanding of, and the core team has definitely been very vocal about being interested in soliciting feedback from and being in dialogue with library maintainers. [39:04]
-
-So that seems like a relatively large communications miss on something that they have talked about being very interested in doing well. [39:11]
-
-**Mark Erikson:** Yeah, and I, I had some in-person conversations with Eli and Lily from the React team at a couple different conferences. It was, it was almost like they were trying to do a listening tour. [39:22]
-
-Like, let's go out, talk, talk to folks in the community, get the pulse of what's going on, hear people's complaints and, and see what we can do about it. I definitely want to give 'em credit for how willing they were to listen to things. I'm hopeful that some of these ideas, like, could you give us like a, a status page of the features and stuff like that will come out of some of those discussions? [39:44]
-
-**Carl Vitullo:** I like the point you made about using TC 39 as a model perhaps, because I think that that framework for feature prioritization and, you know, communicating what's under consideration. I think that that did come about for similar reasons where there were a lot of stakeholders, there were a lot of interested parties who wanted to advance the state of the web in the case of TC 39, the web and JavaScript, well, I guess JavaScript specifically for TC 39, but there were a lot of people who were interested in having a seat at the table, and so they figured out, they put together that mode of communication. [40:21]
-
-And it's, it seems like React is now in a similar place where it occupies a very foundational place in the web ecosystem. You know, it's certainly not as broad as JavaScript does. It's inherently, well, I was gonna say, it's inherently a subset of JavaScript, but you know, I guess with React Native, it kind of, isn't it, it does go a little broader than web and JavaScript, which is interesting. [40:44]
-
-But yeah. You know, maybe that is, maybe that is a model that they could look towards and yeah, I guess if they're doing a listening tour right now, I'll be curious to see what they come back to the community with over the Next couple of months. [40:57]
-
-**Sebastien Lorber:** Yeah. Well, something I found interesting is that, for example in, in the experimental builds of React that NextJS is using, there, there are two new hooks called useOptimistic and useFormStatus that permits to the Server Actions. [41:12]
-
-And they actually are documented in the NextJS documentation, but they are not on the official React documentation. So you, you have to go to the NextJS documentation to, to read more about them. [41:26]
-
-**Mark Erikson:** Yeah. Th this, this was one of the points I specifically brought up, even, even at the uh, React Summit conference a a couple days ago. [41:31]
-
-It's like, I, I realize that, like Dan has, 70 to 80% of this stuff is quote unquote "React". You know, like that, you know, `action={someFunction}` thing is built into React. It's not a Next specific feature, but that also means that there really ought to be information in the React docs about a lot of this stuff. [41:55]
-
-And I, I realize the React team has, you know, limited number of people, limited amount resources, they, and a lot of the stuff is in flight. They can't publish docs on everything right this second, but I would not have expected to look at the Next docs for a React hook specifically. And, and it feels like there is very much a gap in confusion about some of that right now. [42:17]
-
-**Sebastien Lorber:** Yeah. But I think, for Docusaurus, we have been using Canary release, and it's a nice way for them to get feedback from the NextJS team before presenting things publicly to broader audience. So for Docusaurus it has, it has been great to be in beta for long because at, at that time, lots of people were adopting the, the betters of Docusaurus and I was able to get a lot of feedback on, you, you merge a pull request and then one week after you already get feedback on it, even if there is no public release, because people get used to, to using Canary version of your project. [42:57]
-
-And I think also integrating a canary in NextJS like that permits to somehow give the, the new React versions to a broader audience. But we weren't necessarily exposing all the new APIs at once because they're hidden behind abstractions, for example, maybe there are some React APIs that NextJS is using today, but they're not they're not exposed to the, to the users of NextJS app router because they're only used internally inside the inside NextJS [43:31]
-
-**Carl Vitullo:** I think you're right, Mark, about it being unexpected to go to the Next documentation to read something about a beta React hook. I'm sure that there's all sorts of reasons why that was the, you know, most straightforward, most obvious place to put that information. [43:47]
-
-Like, you know, if, if Next is the only place where you can use this right now, I could see why it makes intuitive, logical sense to put that information in those docs. But, given that there has been a lot of confusion and uncertainty and handwringing over the relationship between the React core team and Next specifically, you know, that seems like the sort of communication, I was gonna say communication gap, but maybe not a gap so much as just sending some more signal than you intended. [44:18]
-
-The words they're saying is Next does not have special treatment, but. If Next, if you know the beta features are coming out, are being documented from Next first, and actually not even first from Next only at the moment, then that certainly seems to undercut the words of the message, if nothing else. [44:38]
-
-Yeah. Interesting. [44:39]
-
-**Sebastien Lorber:** And something I just thought about it, but if you look at the Remix team somehow, I, I feel the communication is completely different and the way they approach adding new features has been different in the past. For example they added things in Remix first and then they're trying to backward things to React Router while on for React and NextJS, I think it's a bit the opposite. [45:04]
-
-They try to, to build the abstraction first on, on the React side and then use it on NextJS to dog food. But the, the abstractions on React are working rocky, but maybe this new should be first introduced in NextJS, and if this works great for NextJS users, they could backward them to, to React too. [45:26]
-
-**Carl Vitullo:** Oh, oh, interesting. I see what you're saying. Yeah. That's an interesting thought too. Just sort of a, yeah, we're getting into all the subtleties of PR and comms and API design. All the intersection of marketing and development and developer relations. Yeah. Interesting. [45:42]
-
-**Mark Erikson:** May, maybe, maybe some of the the Next tech writers should actually be filing PRs against the React core docs instead. [45:49]
-
-**Carl Vitullo:** Ooh, ooh. Interesting. Gauntlet thrown (laughs). [45:53]
-
-Cool. Should we go onto the lightning round? [45:55]
-
-**Mark Erikson:** Yep. [45:56]
-
-## Lightning round
-
-### Client-side rendering of HTML and interactivity
-
-- [Client-side rendering of HTML and interactivity](https://web.dev/client-side-rendering-of-html-and-interactivity/)
-
-**Carl Vitullo:** Perfect. Client side rendering of HTML and interactivity, a new post on the web.dev from Google. [46:04]
-
-Uh, it's pretty similar in theme to my, you know, my last link from Airbnb, improving performance with HTTP streaming. Just, I think it has a lot of information about good foundational concepts that will help people be more prepared for writing code when React Server Components are more broadly available. [46:21]
-
-Yeah, Mark? [46:22]
-
-### React Summit, Debugging JavaScript
-
-- [React Summit](https://reactsummit.com/)
-- [Debugging JavaScript](https://portal.gitnation.org/contents/debugging-js)
-
-**Mark Erikson:** Last week I got to go to React Summit. I actually spoke there in the morning, I gave a talk about debugging JavaScript. Honestly, I only saw one other talk, and that's because I spent the rest of the time having discussions with both other speakers and people. But it was a huge conference. [46:36]
-
-It seemed very successful. A lot of atte, a lot of attendees, a lot of great discussions, and I personally had an amazing time getting to meet people. So it was great. [46:48]
-
-### Debugging in React Native
-
-- [Debugging should be easier | App.js Conf 2023](https://www.youtube.com/watch?v=sRLunWEzwHI)
-
-**Sebastien Lorber:** Just a quick mention that debugging in React Native should become easier in the future. It has always been somewhat difficult in the past. Over time there were a lot of different ways to debug in React Native. And none of the methodologies was perfect. [47:05]
-
-And notably you, you could connect your Chrome Debugger to the, to the mobile application and it didn't work so great. For example, you couldn't get the, the network tab to work correctly. And now it, it's going to, to work a bit better in the future, thanks to the work of Expo. [47:23]
-
-### React From Another Dimension
-
-- [React from Another Dimension by Dan Abramov at RemixConf 2023](https://www.youtube.com/watch?v=zMf_xeGPn6s)
-
-**Mark Erikson:** So Dan Abramov did a talk at Remix Conf a couple weeks ago entitled "React From Another Dimension." And it was sort of a couple different points trying to be made. The pitch of the talk was. What if React originally only worked on the server and not on the client, and he actually did a demo where he used like IE6 in a, in like a Windows XP virtual machine and proceeded to build, build out a nifty little like 1990s style webpage and slowly add server-based interactivity to it before he ever actually finally added anything on the client side. [48:01]
-
-And part of it in a sense was this is a pitch for, here's a mental model for how React Server Components work, but it was also a very interesting talk and like alternate history universe, kind of an example. [48:14]
-
-### Server-side rendering React in OCaml
-
-- [Server-side rendering React in OCaml](https://sancho.dev/blog/server-side-rendering-react-in-ocaml)
-
-**Sebastien Lorber:** One link that I found particularly interesting was the, someone posted about creating server side rendering in React. But using OCaml for the server. So somehow they re-implemented the React server rendering in OCaml and um, it's exactly the same, but it doesn't support the, all, all the new things like React Server Components only rendering to string and actually it significantly improved the performance. [48:43]
-
-So I think it's interesting because for example, if you are using OCaml like uh, ReasonML for your application, if you decide to run your server side, your React server in the native language, OCaml, then uh, you can get a much better performance for free because you are using a language that is faster of than NextJS and uh, and things like that. [49:05]
-
-So I thought the idea is interesting and I think it's the first language that I see supporting server rendering of a React application in in another language than JavaScript. [49:17]
-
-### Several links on React rendering
-
-- [The Interactive Guide to Rendering in React](https://ui.dev/why-react-renders)
-- [The Journey of the React Component](https://alexsidorenko.com/react-journey)
-- [React reconciliation: how it works and why should we care](https://www.developerway.com/posts/reconciliation-in-react)
-- [A (Mostly) Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/)
-
-**Mark Erikson:** One of the biggest problems I see that confuses people with React is that they, they don't have a good grasp on the mental model. [49:25]
-
-Like they have the basic idea of components and rendering, but a lot of the real world aspects of how that works confuses them. And there were three really good articles in the newsletter within the last couple weeks that all tackle this idea of how does React rendering work from a different aspect. [49:44]
-
-There was one called The Interactive Guide to Rendering and React from Tyler McGinnis and ui.dev folks. There was a journey of a React component by Alex Sidorenko, who has a great blog post series called A Visual Guide to React Rendering. And then there was an article on React Reconciliation, how it works and why We Should Care by Nadia Makarevich, who has also had a couple previously good posts. [50:07]
-
-They all tackle, you know, some of the same concepts but from different angles. But it's really good information and I think a lot of people would benefit from kinda like going back and reviewing some of those basics to make sure they understand 'em. And then along those lines, I will also toss in my own guide to React Rendering Behavior post as well. [50:27]
-
-**Carl Vitullo:** You gotta, sounds super useful. I love hearing multiple perspectives on the same concept. Super useful. Cool. Sebastian, you got any more? [50:36]
-
-### Spatial Navigation
-
-- [TV Spatial Navigation](https://engineering.atspotify.com/2023/05/tv-spatial-navigation/)
-
-**Sebastien Lorber:** So my last link is about a post of Spotify and implementing TV spatial navigation. So the idea that you use your remote control with the arrow up, down, left, right, and things like that, and you should be able to navigate inside the ui. [50:53]
-
-And the thing is, there is no web standard to, to support this in in the web. So they had to reimplement this themselves by keeping the element that you can navigate to in memory. And I found it, it is a bit interesting because it's quite, unusual topic and I, I see more and more companies doing this. [51:16]
-
-Uh, I know someone two, two persons working at two French companies do doing that also for TV applications. Um, some are web applications, some are React Native applications. And recently we had a talk at React Native connection in Paris about the same subject. So this is basically every time someone needs to create a TV application for using React technology, they do something like this. [51:45]
-
-So if you need to build something for the TV someday maybe it's worth taking a look at. [51:52]
-
-**Mark Erikson:** That's cool. [51:53]
-
-**Carl Vitullo:** Yeah, I think it's also, like, sure, TV, It also reminds me of video game UIs, where you've got a dpad or a joystick. But I think it's also a very powerful accessibility tool. You know, like keyboard navigation is so important. [52:07]
-
-If you, you know, for people who are poorly cited or mobility limited or you know, yada, yada, all sorts of situations where that can be valuable. And yeah, I mean, I, I think that's a really, I think that's a really interesting read to see how people solve that problem. Because if you wanna provide powerful keyboard navigation in a web context, it's not easy. [52:27]
-
-Like, what are you gonna do? Tab index? (laughs) [52:31]
-
-**Sebastien Lorber:** Yeah. No, they, they keep the, the limits in memory. But this is funny because the solution from Spotify and the solution that was recently presented at the React Native Conference were different. For example, I think I remember Spotify is using geometry and trying to figure out which, somehow they, they use maybe APIs like getBoundingClientRect or something to get the positions of the elements on the screen. [52:58]
-
-While the, the other company in France that presented the React Native solution was using somehow recreating a tree, a React tree inside memory so that you know, which are the, the previous and the Next element, but not considering the, the placement on the screen. So it was quite different UX in the end, but uh, the solutions were quite similar. It's just the algorithm to navigate that was different. [53:24]
-
-## Closing
-
-**Carl Vitullo:** Cool. Mark you have any other like lightning round links? [53:27]
-
-**Mark Erikson:** I think we're out, out of, out of items at this point. [53:29]
-
-**Carl Vitullo:** Out of items. Well good cuz we are well over an hour at this point. [53:33]
-
-**Mark Erikson:** Way over time. [53:35]
-
-**Carl Vitullo:** Yeah, that's okay. We had a good time. [53:39]
-
-Cool. All right. [53:40]
-
-Well thank you so much. Thanks for joining us. Thanks for having in the audience for sticking us with us through May in React. All right, Mark, Sebastian, thanks so much for coming up. [53:51]
-
-**Mark Erikson:** Always. [53:52]
-
-**Sebastien Lorber:** Thank you. [53:53]
-
-**Carl Vitullo:** Talk to you guys later.
diff --git a/src/transcripts/tmir-nov-2023.md b/src/transcripts/tmir-nov-2023.md
deleted file mode 100644
index fdc251a..0000000
--- a/src/transcripts/tmir-nov-2023.md
+++ /dev/null
@@ -1,442 +0,0 @@
----
-title: This Month in React (November 2023)
-date: 2023-11-29
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-Chapter list:
-
-- [00:35] Conference news
-- [01:58] TypeScript 5.3
-- [10:24] Kent and Lee, dueling positivity on frameworks
-- [14:58] Next.js 14 and Next Conf
-- [18:07] Using React Server Components without a framework
-- [22:59] Remix 2.2
-- [27:52] Shopify Hydrogen Remix v2 support
-- [29:51] Redux Toolkit 2.0 and related libraries
-- [35:40] CSS improvements - :has() selector, nesting, advanced color functions
-- [37:31] Why you want React Query
-- [39:04] Retrospective on 10 years of JavaScript decorators
-- [40:10] React sourcemaps now available in canary builds
-- [41:47] $22,500 bounty for improving formatter performance
-
-Links discussed:
-
-- Quick hits:
- - [React Day Berlin Dec 8+12](https://reactday.berlin/?utm_source=reactiflux)
- - [Future Frontend conf earlybird tickets](https://futurefrontend.com/blog/ff24/?utm_source=reactiflux)
- - [Render ATL super early bird](https://www.renderatl.com/tickets?utm_source=reactiflux)
- - [State of React closed](https://survey.devographics.com/en-US/survey/state-of-react/2023). Not sure when results will happen. Likely in 2024
- - [State of JS is open!](https://survey.devographics.com/en-US/survey/state-of-js/2023?source=reactiflux)
-- [TS 5.3](https://devblogs.microsoft.com/typescript/announcing-typescript-5-3/)
-- Remix vs Next
- - [Kent](https://www.epicweb.dev/why-i-wont-use-nextjs) – [Leerob](https://leerob.io/blog/using-nextjs)
-- [Next 14 summary](https://nextjs.org/blog/next-14)
- - [Next Conf playlist](https://www.youtube.com/playlist?list=PLBnKlKpPeagl57K9bCw_IXShWQXePnXjY)
-- [React Server components, without a framework?](https://timtech.blog/posts/react-server-components-rsc-no-framework/)
- - [Code](https://github.com/ziir/rsc-demo) – [Demo](https://rsc-demo.timtech.blog/)
-- [Remix 2.2.0](https://remix.run/blog/remix-heart-vite)
-- Hydrogen (Shopify headless ecommerce) [supports Remix v2](https://github.com/Shopify/hydrogen/releases/tag/%40shopify%2Fhydrogen%402023.10.0)
-- [Redux Toolkit 2.0 is _almost_ here! _Hopefully_ shipping by this weekend :)](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-rc.1)
- - [Migration page](https://redux.js.org/usage/migrations/migrating-rtk-2)
-- ⚡️ lightning ⚡️
- - [CSS features roundup (bytes.dev)](https://bytes.dev/archives/237)
- - [https://tkdodo.eu/blog/why-you-want-react-query](https://tkdodo.eu/blog/why-you-want-react-query):
- - [10 years of JS Decorators](https://dev.to/what1s1ove/ecmascript-decorators-the-ones-that-are-real-g96)
- - [REACT SOURCEMAPS FINALLY MERGED WOOHOO!](https://github.com/facebook/react/pull/26446)
- - [Prettier bounty](https://twitter.com/Vjeux/status/1722733472522142022)
- - [claimed by Biome](https://prettier.io/blog/2023/11/27/20k-bounty-was-claimed) – [Full report](https://biomejs.dev/blog/biome-wins-prettier-challenge/)
- - Self-plug: [doing a livestream with Filip Hric tomorrow](https://twitter.com/replayio/status/1727698776125481350)
-- Fun news if we have time:
- - [Angular updated to v17, new docs site](https://angular.dev/)
- - [Docusaurus 3.0](https://docusaurus.io/blog/releases/3.0)
- - [Google-created React components for Google Maps](https://cloud.google.com/blog/products/maps-platform/introducing-react-components-for-the-maps-javascript-api/)
- - [Win95-inspired component library](https://lisandro52.github.io/react-winplaza-98/)
-
-[00:00] **Carl Vitullo:** Thanks everyone for joining us for November's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. I'm Carl, I'm a staff product developer and freelance community leader at Reactiflux. Where you are now, the Discord for React professionals. Uh, Mark, want to introduce yourself?
-
-[00:19] **Mark Erikson:** I'm Mark Erikson. Uh, in my day job, I work at Replay. io, where we're building a true time traveling debugger for JavaScript apps. And outside of Replay, I spend far too much time working on Redux.
-
-[00:31] **Carl Vitullo:** And answering every question about it on every platform.
-
-## [00:35] Conference news
-
-[00:35] **Carl Vitullo:** We're going to try out something new, uh, speaking of conferences in the prep chat. Folks interested in the news may be interested in attending conferences too!
-
-[00:45] We have React Day Berlin coming up on December 8th, with a hybrid online streaming follow up on the 12th. There's also a couple of early bird tickets that were just announced. There's Future Frontend, uh, which is going to be in oh, in Finland. I believe it's being organized by React Finland. That's going to be on June 13th and 14th of 2024. Uh, which competes with Render Atlanta, which is also going to be June 12th through 14th of 2024, and just announced early bird ticket sales as well.
-
-[01:19] There's also a little bit of survey ecosystem news. The wonderful people behind the State of JS ecosystem survey are doing a State of React survey as well. That just closed about two weeks ago. No final word yet on when the results of that will be available, but I've heard that it's going to be early in 2024 and might have Sacha Greif on here to talk about the results when they're ready. So yeah, keep an eye out for that.
-
-[01:46] And also one final note, the State of JS survey has opened for 2023. So definitely check that out, you know, contribute, make it. Give it better data.
-
-## [01:58] TS 5.3
-
-[01:58] **Carl Vitullo:** I'll start us off. First news event that we're going to be talking about here, uh, TypeScript 5. 3 is out. Out of beta, out of release candidate.
-
-[02:08] Looks like it's not a ton of major new changes here.
-
-[02:13] They're adding support for a TC39 proposal, import attributes, that give an inline syntax for module import statements to give more information about what that module is. As far as I know, the only currently supported additional attributes are in support of JSON modules.
-
-[02:34] Instead of JSON modules being sort of like an informal standard that just works, um, this is now formalizing that and giving I'm giving away for more information to be provided about how to import additional modules. So hopefully we'll see this being used for things like image imports, SVGs, fonts, things like that.
-
-[02:54] Um, which currently that's all been just like through Webpack or whatever bundler and whatever plugin, just totally ad hoc based on whatever bundler you're using. So seeing a proposal come in to standardize that is I'm here for it. That's cool.
-
-[03:09] **Mark Erikson:** Yeah, I've seen that the syntax exists. I haven't had it, like, actually, like, most things these days, I haven't had a chance to, like, look at it or play with it yet.
-
-[03:17] Um, like, I've seen the comment that, you know, like, one of the great things about, you know, Webpack and Vite and whatever is that it lets us, you know, mix together, you know, like, I need to import this CSS file, I need to import this, you know, this image file. And then all the processing happens during build time, but it's also true that you're basically almost inventing your own little language, especially if you start adding more plugins to deal with certain build types.
-
-[03:46] And, like, actually, it's a little bit like the React vs. Web component debate. You know, are you supposed to be strictly, strictly using the platform or are you okay with using tools that aren't strictly the platform, build in the specific pieces that you need, but you're, you're, you're maybe kind of conceptually locked in and maybe that's okay.
-
-[04:10] So in this case, I think what we're sort of seeing is that app developers for years have wanted to be able to do things where they are quote importing non JavaScript or TypeScript assets. Into their code for one, for one reason or another, and build tools have supported that for many, many years. And so now we're sort of seeing the little, you know, the trickle down effect where some concept of that is now trickling into the platform.
-
-[04:40] Even if it's not, like, building in functionality to do something with it. But at least now there's a, there's a common syntax for saying, here's a file, treat this specially.
-
-[04:53] **Carl Vitullo:** Yeah, like you were saying, it's, it's not all of the long tail of modules now, but I, I appreciate that it's a low level primitive that will allow for that sort of, that, that later work to be done in a consistent manner. So that's cool. I'm, I'm excited to see that.
-
-[05:09] But another bit that caught my eyes, uh, being valuable is improved type narrowing. If you do a switch with a true case and then, you know, have subcases for different, uh, conditionals, it, the behavior around type inference around there, uh, should be better on, on 5. 3.
-
-[05:27] **Mark Erikson:** That's actually one of the weirder little bits of TypeScript, or actually of JavaScript, really. So, you know, normally with a switch statement, the idea is you have a single variable that could have many different possible values.
-
-[05:40] And the switch case is, if the value is A, do this. If the value is B, do that. And the weird thing is, in JavaScript, you've always been able to say like, switch true, but then the case statements can have actual comparisons that don't even have to do with a single variable. It's kind of like another way of chaining if else statements.
-
-[06:07] And so, this has been legal JavaScript syntax for a long time, and TypeScript is now actually being a little smarter and saying, well, actually, if you're going to do that, we can apply some type level inference to what's going on inside.
-
-[06:20] **Carl Vitullo:** I don't know if this is a widely held opinion, but I've generally viewed that as, that behavior of doing switch true, as like, a little bit of a convenient hack.
-
-[06:29] I don't know where switch cases originated from, but like, I've certainly seen them all the way back to like, C, right? That is very much not the semantics, going back that far in their, you know, legacy. But, you know, that's how people have been using them in JavaScript for a decade.
-
-[06:45] So, acknowledging that and just making it work better, like, that's awesome.
-
-[06:50] **Mark Erikson:** Uh, one other item that I don't, I don't know if it's even listed in these release notes, but Andrew Branch from the TypeScript team has been working on a new set of documentation For the TypeScript website, about how TypeScript understands the concept of module files.
-
-[07:10] So, ESM files, CommonJS files, um, all the different variations in terms of module resolution. And he finally merged that into the actual TypeScript docs a few weeks ago. And there is a ton of information here. I've not even had a chance to read through all of it. But part of this is really long and complex because of how complex the JavaScript and TypeScript ecosystem is.
-
-[07:40] And you know, how many different tools and concepts are interacting. But it's basically an explanation of this is how TypeScript views. The world. And it gives a lot of very good explanations of the theory and choosing a lot of the compiler options and trying to deal with, you know, both using packages and publishing packages.
-
-[08:02] And as someone who has spent a disturbing part of this year banging my head against the wall of publishing packages, uh, this is, having this information available is very valuable.
-
-[08:11] **Carl Vitullo:** Before we move on, I'm just going to read down the list of all the what's new from the blog post. Import attributes, which we discussed.
-
-[08:19] Stable support for resolution mode and import types, which I think is what you were just talking about.
-
-[08:24] Resolution mode support in all module types, so related.
-
-[08:27] Switch true narrowing, what we just discussed.
-
-[08:30] Narrowing on comparison to booleans, uh, which I imagine probably came out of the switch true casing, but also another great, you know, we can narrow types on if statements. That's awesome.
-
-[08:41] Instance of narrowing through symbol has is instance.
-
-[08:45] Checks for super property access on instance fields.
-
-[08:48] Interactive inlay hints for types. I don't even know what that means.
-
-[08:51] Looks like a couple of other optimizations. Consolidation between TSS server library and typescript.js.
-
-[08:58] **Mark Erikson:** That one actually has a little bit of an impact. So, most people haven't noticed this, but if you installed, like, TypeScript version, I don't know, 4. 6, 4. 7, the unpacked file on, er, folder on disk was like 50 or 60 megabytes. And nobody thinks about it, but it's because TypeScript is a really complicated tool, but also they basically shipped, like, three different copies of the same core functionality in different bundles inside node modules.
-
-[09:29] The TypeScript package contents shrank in like 5. 0 because they altered how they build and bundle the TypeScript tools itself. And here they've done further work to say, you know what, actually two of these bundles are basically almost identical, let's extract the common piece so that it's only built once.
-
-[09:50] And then the two bundle files that get used for different purposes just reuse that common functionality. And so the actual installed size of TypeScript has shrunk again down to like, uh, I don't know, like 25, 30 megs? So I mean, it's something. Smaller node modules is always nice. Cool.
-
-[10:12] **Carl Vitullo:** About 20 percent smaller package size on disk after you install TypeScript. Cool, that's nice. Probably going to save a lot of disk space in aggregate across everyone.
-
-[10:21] Alright, Mark, you want to take us on to our next link?
-
-## [10:24] Kent and Lee, dueling positivity
-
-[10:24] **Mark Erikson:** So it's always amusing to me when we have kind of like dueling articles come out. Someone writes, someone writes article A, someone else looks at it and writes article B.
-
-[10:35] So in this case, we had an article from Kent C. Dodds, you know, always very prolific, you know, author and teacher. Who wrote a very long post entitled, Why I Won't Use Next. JS. And he laid out a bunch of reasons here, and there's like a bunch of sort of spin off thoughts that happened.
-
-[10:54] So the first thing is, you know, up front, Kent worked on, as part of the Remix team, for, you know, like, 8 to 10 months. He teaches Remix in his courses. He is a big vocal fan of Remix as a tool. And so, a lot of people ask him, both because he's a teacher and because he likes Remix, "well, why won't you use Next. JS? Or like, why do you prefer Remix over Next?" And so, like any good blogger, he said, okay, I've been asked this question dozens of times, I'm going to go ahead and write an article.
-
-[11:31] And he laid out a whole bunch of reasons, ranging from, you know, Remix is more of a focus on the web platform, it's not part of Vercel, he has some uneasiness with the way Next and the React team are sort of co mingled at this point, he feels it's more stable and does a better job with, you know, managing the pace of changes and it's less complex, You know, frankly, I haven't used Remix, but I actually agree and sympathize with most of the points he's making.
-
-[12:03] I've felt some of that unease with some of the pace of change with Next and the way some of the release processes get managed. Now, a lot of people have complained that Kent has a huge conflict of interest, and I see the comment down there in the chat.
-
-[12:19] I'm gonna side with Kent here. Yeah, he has biases and opinions. This is a post where he is stating his biases and opinions. Like, he's allowed to say, here's why I like this thing. And, you know, people have asked him, what are your thoughts? And so he's documenting that.
-
-[12:37] So, that post was really good. And, you know, got a lot of attention. And a week or two later, Leerob, who is the, you know, the lead developer relations guy for Next, Went out and wrote a post on why he is using Next. And I thought this one was also very well written. Uh, a lot of it is a direct response to what Kent wrote.
-
-[13:00] And I actually liked that both of them were very careful up front to say, like, Here are some opinions, I like this tool, I have preferences, and we even went out of his way to like tweet picture up front of like, "look, here's me and Kent, smiling, we get along, we don't hate each other," but, you know, kind of giving some counter thoughts on, you know, look, Next, Next does use the platform, I like the app router, and, you know, some of the other, you know, features that are built into Next.
-
-[13:30] What I appreciated as a neutral, independent third party is that, these are, these are well written posts, they are basically positive, I mean, they, they express a few, like, pain points and concerns, but they're written in a positive sort of a way, not like a tear everybody else down sort of way.
-
-[13:52] I, I just feel like the entire ecosystem would benefit from more articles and discussions that are organized and pitched with that mindset. So both of those were really interesting. A lot of really good feed for thought there.
-
-[14:05] **Carl Vitullo:** Yeah, I would agree. And both of these come out the day that we recorded October's This Month in React. So I was like, ah, dang it. If we waited a day, we could have discussed these immediately after.
-
-[14:15] So here we are a month later, but yeah, I definitely agree. I'm a big fan of a positive framing of things. I guess, you know, ultimately Kent's post was, why I won't, so that is kind of a negative framing. But the actual content of it is very much, you know, like his, the first heading of it is, "whatever you use is probably fine."
-
-[14:36] I can enthusiastically support anything that Just respects that there are different trade offs, and different people find different trade offs appealing. Only two of the largest people in developer relations for two of the largest frameworks in the React ecosystem having a nice, reasoned discussion with each other in the form of public letters.
-
-[14:56] **Mark Erikson:** And speaking of Next.
-
-## [14:58] Next 14 and Next Conf
-
-[14:58] **Carl Vitullo:** Next14! They announced this at the Next conference, which I'm going to link to a playlist of all the talks there as well. Major highlights here, uh, looks like TurboPack is offering big performance improvements for developer experience locally. They're claiming 53 percent faster local server startup and 94 percent faster updates, so rebuilds.
-
-[15:27] Faster to start, much, much, much faster to rebuild. Sounds cool. As far as I know, the major new feature being rolled out with Next 14 is server actions, which is a React Canary feature that is now being exposed as a first class function in Next. Sounds cool. We discussed that at greater length in the last episode, I think.
-
-[15:49] Partial re rendering, fast initial static response and streaming dynamic content for, I guess, you know, partial pages. Sounds cool. And it looks like they've put out some new educational content as well, teaching about how to use the app router and authentication and databases and stuff.
-
-[16:06] I still have not been able to find a great use case for myself to explore Next, you know, the more advanced Next features like the App Router, uh, in my own time. I'm not currently employed as a full time software engineer, so I don't currently maintain a large scale application, which is, I think, the only way to get real experience with using these, you know, the experience of working on a full team, making decisions in the context of maintaining them for a period of years.
-
-[16:37] Um, so, I'm not going to feel comfortable passing firm judgment on AppRouter, I think, until I've been able to build a real application. So, I don't have a lot to say on the specific details yet.
-
-[16:52] **Mark Erikson:** Yeah, uh, I'm, I'm sort of in the same boat, I mean my, my day job at Replay is technically a Next app, but it might as well be just a, you know, a pure single page application, conceptually. Basically don't make any real use of routing at all.
-
-[17:07] Anecdotally, you know, just looking at discussions on Twitter and Reddit, I, I see a very mixed bag. I, I see people who love the app router and some of the functionality that's built in there. I've seen a lot of people complain that in between the app router and like Vercel's multiple caching layers that there's a lot of pain points they're dealing with.
-
-[17:28] So I see anecdotes, I don't have a lot of, I don't have any personal experience that I can offer in that respect.
-
-[17:36] **Carl Vitullo:** Yeah, and there have been wildly popular framework in the past that had all sorts of blog posts and discussion and everyone raving about how great it was to use. And then a couple years later, everyone started using it for larger scale projects and found all the pain points. And I noticed all of that positivity going away. So, you know, In the interest of not repeating that pattern, I'm just not comfortable passing judgment too quickly here.
-
-[18:02] Want to take us on? Maybe a good segue from Next into Frameworkless.
-
-## [18:07] RSCs without a framework
-
-[18:07] **Mark Erikson:** So, one of the big issues with server components so far, has, well, a number of issues, but one of the issues has been that the only real way to use them has been with Next.
-
-[18:20] And, you know, there's the whole separate discussions over Next sort of getting first access to React features, you know, being sort of a concern, but also, you know, give credit to Vercel because they're literally investing a lot of money and time into building out the core pieces that are in React itself and then making use of those features in Next specifically.
-
-[18:45] So, there's a number of different tools and frameworks that are experimenting with integrating server components right now. I know that the RedwoodJS folks have said that they're all in on server components, and I've seen some of the technical discussions where they're working on it. I've seen, uh, Daishi Kato, who created Jotai and works on Zustend, um, has his own little experimental server components based framework.
-
-[19:13] So, there are a small but interested number of people who have been playing around with trying to build things with server components, but it always, like, needs some higher level of build tool integration to work, and that's by design. So, there was a really, really good post from a guy named, I believe, uh, Tim Tim Pillard.
-
-[19:38] And it's called, React Server Components Without a Framework. And in this post, he kind of breaks down, like, what are the pieces behind server components. Where do server components fit into, like, the build and deploy and usage sequence? And he then kind of dives into, like, what are the pieces inside of React that you would actually need to build your own server components integration?
-
-[20:05] And this was a really, really detailed article. And, is everyone going, like, going to need to, like, dive through this and understand all the inner workings to use server components? No, because you would normally use them just because, you know, Next, or Redwood, or Remix already has them integrated, and you sort of follow, like, the framework version of the docs, for the most part.
-
-[20:30] But, one of the problems with server components has just been that the low level workings have not really been documented so far. So, everyone's either having to look at the very bare bones examples in the React repo, or, in most cases, actually looking at the internals of Next, and trying to figure out, "well, how much of this is something we need to copy and paste, and how much of this implementation is very specific to the way Next works."
-
-[20:58] So, like, everyone's looking at Next's internals and trying to figure out what they're supposed to do. So, having an article that sort of breaks some of this down without any other frameworks involved is actually pretty helpful to understand what's going on inside.
-
-[21:13] **Carl Vitullo:** Most, most definitely. I was pretty surprised at, having never even, I've barely even tried to use server components through Next. So I've had even less exposure to using server components without Next or any other framework. And I was a little surprised at some of the details here, like he mentioned having to use the react-server-dom-webpack webpack plugin, which has no documentation at all for it. So like, ooh, yikes, okay, I've wrangled some complex webpack configs before, and they're hard enough when it is documented.
-
-[21:49] So going, just the setting of transcending the like client server boundary through the bundler without documentation. It's like, oh yeah, okay, we're still in a rough spot here.
-
-[22:02] **Mark Erikson:** There's a whole lot of dragons there.
-
-[22:03] **Carl Vitullo:** There be dragons for sure. So, just, you know, I tried to read through the code to get a general sense of what it would look like.
-
-[22:12] I am a big fan of going from first principles, you know, even if I'm going to stick at the level of, you know, using a framework, I like to generally have a sense of what's going on inside. And, honestly, even reading this code, it was a little bit tricky to unfurl even, you know, what are just internal abstractions that were set up for this little toy example versus what's strictly required.
-
-[22:36] So, yeah, it's definitely, I think, highlighted how rough of a state the experience of using server components is right now. Huge, huge props to Tim for putting this together. I think this is a, I think this will be, you know, regarded as a canonical contribution to the development of server components.
-
-[22:56] You know, just want to applaud Tim for that.
-
-## [22:59] Remix 2.2
-
-[22:59] **Carl Vitullo:** Talked about Next, it's time for Remix. Uh, Remix 2. 2 came out, and, it's interesting. I, so it looks like they are moving away from being a from owning a compiler and bundler step of it and moving towards leaning on Vite. So they, you know, they are claiming, you know, they are now supporting Vite as a bundler internally.
-
-[23:28] Uh, and one of the, one of the things they Called out in this announcement that caught my eye is they, they're saying remix is no longer a compiler remix itself is just a vite plugin. That seems remarkable to me to totally change out the internals of how a framework is operating in that way, transparently and in a way that allows people to opt into it.
-
-[23:52] in advance of the breaking changes being shipped. I think we talked last, it was either last episode or the one before, about the rollout process for new features that Remix is using and I think they're doing it really well. I think a lot of other open source projects could take a, you know, take a page from their book on how to roll out new features.
-
-[24:11] **Mark Erikson:** Yeah, I think I'd seen some discussion from Ryan and Michael over the last couple years that they'd kept their compiler workings internal and abstracted, sort of, I guess, like, in spirit, similar to the way React App tried to hide everything behind a wall, because they were worried about exposing some of the specific knobs to end users, And, you know, that causing trouble for, for future upgrades, you know, like everything, it has trade offs, you know, maybe it made some people's uses of Remix a little bit harder because they couldn't tweak those knobs, but it, it seems like it's also made this particular upgrade process a little easier because now they've, they've swapped the underlying layer entirely and actually sort of been able to get out of the compiler business completely.
-
-[24:57] **Carl Vitullo:** Very cool. Very interesting. It seems like they've made a lot of really good, uh. Choices to set them up for speed of iteration, which I think is a great metric to optimize for. Seeing a comment in the chat, Vite is under scrutiny for using ES modules in development, not convinced this is the best course of action.
-
-[25:15] Yeah, I've also heard some, just in the last day or two, I've seen some blowback. Vite as like, I don't know, the bundle less movement is, I think Next just put out some stuff saying that like, oh, the bundle less Uh, movement has failed, and they talked about how they really tried to make it work with Vite and just couldn't.
-
-[25:34] So, I don't know, curious, you know, we just did a, discussed the comparison of Next and Remix and curious that, uh, Next said, like, ugh, this can't work, we can't make it work. And Remix just Did it.
-
-[25:45] **Mark Erikson:** I'm a little, I'm a little bit curious about what the actual meaning of bundleless in that specific discussion is.
-
-[25:54] I know that in development mode, Vite tries to use ES modules kind of like straight up without, without fully bundling them, but they do actually get bundled for production. And so, like, a lot of the discussion, maybe four or five years ago, was, you know, with, with HTTP2 streaming, and, and like, you know, browsers supporting ES modules natively, we might not have to bundle, you can just have your individual dot You know, JS or mjs files on disk and they can all, like, they can all just get fed out automatically and eventually folks concluded that, you know, based on the number of files that have to be downloaded and dependency, you know, chains and whatnot, that, well, actually, yeah, bundling is still a good idea, but that's really talking about production usages, and so I'm a little confused why I think it was Guillermo Rauch in this case was saying, like, bundleless didn't work and pointing the finger at Vite when Vite does it in dev.
-
-[26:58] So I'm not following all that discussion.
-
-[27:01] **Carl Vitullo:** Thanks for bringing that in. I had forgotten some of that context, but now that you mention it, I know that they have talked over the last six weeks or so about, I know that Next has talked about working to improve the developer experience, and so I wonder if maybe that's the lens they're looking at this from, is they were, they came at it with a goal of making the developer experience better.
-
-[27:21] And we're not able to make the, you know, unbundled files as necessary, actually improve the experience because, right, because of, you know, exactly the same reason that nobody has ever been able to make HTTP a usable experience, uh, just there's constant waterfalls and you request one file and that request more files, which request more and more and more and more.
-
-[27:46] I think that's probably where that came from.
-
-[27:48] **Mark Erikson:** That would make sense.
-
-[27:49] **Carl Vitullo:** I think it's super cool that Remix has been able to make this work.
-
-## [27:52] Shopify Hydrogen Remix v2 support
-
-[27:52] **Carl Vitullo:** Sort of sub Remix news, Shopify acquired the Remix business, so they've been sponsoring development and supporting the team, and it looks like they just shipped the port for Remix 2 in their Hydrogen e commerce headless framework.
-
-[28:09] Cool to see that they are genuinely investing in this, not just sponsoring.
-
-[28:14] **Mark Erikson:** Not just acquire, hiring the team.
-
-[28:16] **Carl Vitullo:** Right, exactly. They didn't just buy the talent. They are genuinely investing in the open source project and then improving their own more narrowly scoped open source development on top of that.
-
-[28:30] So, super cool. It's, I know people have talked about You know, oh, venture capital in open source is, you know, anathema, it's terrible, don't do it. But this looks like a really cool positive outcome for that setting. Okay, Remix, the economics for running that as a venture invested business are maybe, I don't know how you get the growth multiples there.
-
-[28:55] Raising funding to pay yourselves as you develop and then selling to a business that does see a business use case in operating that. This seems like a pretty positive outcome for that, so just, yeah, I appreciate that. Seems cool.
-
-[29:09] **Mark Erikson:** One other little snarky side observation along the way. It's ironic that the React docs emphasize so strongly that you should be using a framework to start any new React project.
-
-[29:21] And of course, you know, the top choices are Next, Remix, Gatsby, (RIP) and Expo. And yet, Remix itself, and like, Vite is relegated to the, "well, if you want to start an SPA, I guess you can, we can't stop you." And yet, Remix itself is now actually based on Vite, which was relegated to that subheader.
-
-[29:47] **Carl Vitullo:** Yeah, low level tools.
-
-[29:48] Cool to see them get used though.
-
-## [29:51] RTK 2.0 (and lots of others)
-
-[29:51] **Mark Erikson:** Okay, so next item, some personal interest here, but it's also actual news, which technically hasn't happened yet, but is about to. We are hopefully about to hit the button on Redux Toolkit 2. 0. Like, so help me, by Sunday, I hope. This is an effort that has been going on since literally the start of this year.
-
-[30:13] When this happens, we're going to simultaneously ship major versions of Redux Toolkit 2. 0, Redux Core 5. 0, Reselect 5. 0, React Redux 9. 0, and, drumroll please, Redux Thunk 3. 0. And all of these are going to have modernized packaging with, hopefully, proper ESM CommonJS compatibility. Modernized JavaScript build output, so we're using the latest, greatest JavaScript syntax and no longer targeting IE11, thankfully.
-
-[30:49] There's some performance improvements. Redux Toolkit now uses Immer 10, which has some noticeable updates in updates, or improvements in update speed. We've cleaned up a bunch of deprecated options and added some new features. A migration guide page already up on the website. There may be a couple last Tweaks that need to go in there.
-
-[31:12] Our hope is that for a lot of apps, it might just be bump the versions and you're done, but we've tried to call out all the things that qualify as either really breaking changes or like this could sort of be considered a breaking change.
-
-[31:29] The one last thing that is sort of holding up the release at the moment is I am about to pull the trigger on changing some of the default behavior for the Reselect library. Reselect has been mostly unchanged ever since its release in terms of how the internals work. It's sort of doing one reference equality comparison for every argument, basically. And if any of those have changed, then it recalculates. But you can swap out the comparison function to do, like, shallow equality, or whatever.
-
-[32:04] CreateSelector has always had a default cache size of 1. If you, like, alternate the arguments back and forth, it'll never memoize, because it's like, "This doesn't look like the last thing you gave me. Recalculate. This doesn't look like the last thing you gave me. Recalculate." And so you kind of have to go through some shenanigans to handle cases where, like, you want to use the same selector in a list item component, but you're passing in, like, the ID of the item as an argument or something.
-
-[32:36] And I had updated reselect a couple years ago to be able to have a larger cache size, but you had to specifically pass in that option. So earlier this year I actually copy pasted this super secret caching function implementation from the React code, and it uses weak maps to form like a tree of cache data.
-
-[33:01] And the net effect is it kind of basically becomes like an infinite cache size with no further work needed.
-
-[33:09] **Carl Vitullo:** Oh, interesting.
-
-[33:10] **Mark Erikson:** And so what I've been debating is, is it worth switching Reselect's default behavior over to use that? As the default preferred approach. And I've, I've been waffling and debating the pros and cons and the trade offs.
-
-[33:25] And I think I'm actually about to do it. One observation I'll make is that technically an infinite cache size is also synonymous with a memory leak, like, you know, sort of looks the same way. Weighing a couple of concerns around that. But I think the improvement in the default behavior is going to be nice enough that it's worth making that switch.
-
-[33:45] And we'll sort of document, like, here's the trade offs with the new built in approach. So, you know, that's the kind of stuff that's been on my mind trying to finalize this over the last couple of weeks.
-
-[33:57] I'm actually literally hoping to make that change to the code tonight, document it, update the release notes, do some, do some hopefully last minute real world ish testing, and then hopefully ship this by the weekend, I hope, because I really don't want to spend December like, while I'm traveling, having this stuff on my mind.
-
-[34:16] **Carl Vitullo:** I remember that being, like, kind of the number one gotcha with, you know, Idiomatic Redux, you get a lot of really great performance characteristics if you get all the selectors just right, but it became kind of a puzzle of how to set it up just right to get there. You know, like, if you, like you said, if you end up having a list of things where you want to select items out of it, then you needed to, like, you needed to instantiate the selector in just this right certain way, so it was actually memoizing, so you actually got the performance benefits. So yeah, very cool. That makes a lot of sense for changing defaults to make it give you good performance in a wider range of circumstances.
-
-[34:54] **Mark Erikson:** Right, so I mean, it ultimately boils down to, I think the, it'll be a small but meaningful improvement to developer experience.
-
-[35:02] Uh, similarly, we've actually added a couple development mode checks to reselect. Sort of similar in spirit to like, you know, how strict mode works with React components. To watch for things like, you know, your input functions are returning a new reference every time, so this selector never actually memoizes. Or, the output function just returns the value it was given with no transformation, which, either of those means you're holding this wrong. Stop it.
-
-[35:34] **Carl Vitullo:** Cool, I'll move us on. I guess that's the end of our full discussion links, so we're into the lightning round now.
-
-## [35:40] CSS improvements
-
-[35:40] **Carl Vitullo:** Couldn't find a better source for this than just a newsletter that I was reading, so I'm posting that.
-
-[35:45] But some good CSS improvements coming out, like the hasSelector, which is something I've needed on a number of occasions and just never found a way to do it. So I'm excited to see that like browser support is currently there to where you can just use this. You can select nodes in the DOM that contain something else.
-
-[36:05] Previously, selectors were sort of upward looking, like you could, you could select, you could narrow in on children under specific parents, but you couldn't say For all parents of this type of thing, style it this way. So it sort of reverses the direction of control for CSS, or gives you a mechanism to do so, which just unlocks a whole other category of things that you can do with CSS in a way that I think is super powerful.
-
-[36:31] There's also CSS nesting, which is Virtually the only reason I still use Sass anymore, just being able to write rules instead of a series of long lines just like wrapping, you know, nesting them under each other for related selectors. And I don't know that this is one that I would use myself specifically, but I think it's pretty cool.
-
-[36:53] a color function for more advanced control over what color space you're using, which not something I need very often in developing web products, but if you're doing something a little bit more like creative coding, artistry, or trying to correctly render colors in a specific setting, like if you know that this monitor can render this color space accurately, use that rather than sRGB.
-
-[37:19] Um, as somebody who has done a lot of photography and gained an awareness of color spaces through trying to do prints and things like that. I appreciate that this exists, that this is now a function that can be used in CSS.
-
-## [37:31] Why you want React Query
-
-[37:31] **Mark Erikson:** So, Dominic Dorfmeister, aka TKDodo, the maintainer of ReactQuery and Uh, tanstackquery put up a really good post talking about why you want ReactQuery.
-
-[37:43] And I believe this was kind of inspired by a, you know, kind of a tweet that was going around showing like, "look, here's a fetch call and a useEffect. It's like 10 lines of code. How many bugs are there?" And the answer is a lot. And some of it's, some of it's bugs, some of it's, well, here's a bunch of edge cases you didn't take into account, like this, this doesn't have error handling, this doesn't deal with, you know, double fetching in strict mode, this doesn't deal with handling, you know, resetting data or error separately.
-
-[38:14] And so, Dominic kind of walks through the process of, like, if we were to make this 10 line example properly robust, Here's all the added complexity that the example skipped over. And dealing with that complexity is not a thing you want to write for yourself. And this is actually why it's worth using a library, like ReactQuery, Apollo, SWR, RTKQuery, to manage that for you.
-
-[38:44] Because all that really complex logic has already been encapsulated inside the library, you would have had to write this yourself anyway. You wouldn't have thought about it, just use the library. It deals with it for you, it will handle it correctly. But very worth reading to get a sense of here's all the edge cases involved.
-
-## [39:04] Looking back on Decorators
-
-[39:04] **Carl Vitullo:** Cool. I just liked this post. It's not necessarily newsworthy, it's not something new, but 10 years of JavaScript decorators. Decorators have been around in various states for 10 years. It's been 2013, yeah, that I first started hearing about them. You know, Angular went pretty hard on them. There was MobX went pretty hard on them.
-
-[39:26] The actual standardized proposal for how to add them to JavaScript just languished for So, so, so many years. Uh, so I just appreciated this, you know, retrospective on the evolution that decorators have gone through over the, over the years and all the reasoning why it got stalled out and thought it was a good read on a relatively common but very confusing part of the
-
-[39:51] **Mark Erikson:** JavaScript language.
-
-[39:52] I would expect that most people who have used decorators have never thought about what's actually going on under the hood or the fact that the definition and the implementation has changed multiple times.
-
-[40:03] **Carl Vitullo:** Yeah, MobX or Angular, were not exactly shouting about how this is an unstable feature and it has not landed yet.
-
-[40:09] Cool, wanna take us on?
-
-## [40:10] React sourcemaps generally available
-
-[40:10] **Mark Erikson:** Okay, so, another sort of personal note, this is one I've been harping on literally for months. So, way back in like, March, I filed a pull request to modify React's build system to actually generate source maps for production build artifacts. And the PR kind of sat there for a number of months.
-
-[40:32] Uh, Dan briefly tried to review it, and we had gotten some back and forth about, you know, some of the nuances of behavior. I am very happy to report that as of a couple weeks ago, this has finally been merged, and it is actually shipping in React builds right now. And you can verify this if you were to go to, for example, unpkg, and look at React, uh, React or ReactDOM.
-
-[40:57] And if you were to select one of the experimental or the canary builds, uh, experimentals are generated pretty much daily, canaries kind of like every couple weeks or so, you would see that the source map files actually exist in published builds of React today. Now, of course, This brings up the question, when will the next stable build of React come out?
-
-[41:19] Who knows? I'm hearing rumors that they're working on, towards an actual React 19. This doesn't exist in a stable build yet, unfortunately. But when the next stable build comes out, it should actually have source maps. I'm very excited about this. It's not necessarily going to benefit everybody all the time, but it's a missing piece that fills in and anyone who's trying to peek inside React in production will hopefully have a better experience.
-
-## [41:47] Formatter performance bounty
-
-[41:47] **Carl Vitullo:** There was a bounty put out for improving performance of code formatting. Uh, the Prettier organization put out a 10, 000 bounty that was then doubled by, I think by Guillermo Rauch.
-
-[42:02] **Mark Erikson:** I think so, yeah.
-
-[42:04] **Carl Vitullo:** I believe the specific criteria for the bounty was a Rust based formatter that passed like 95 percent of the test cases that Prettier has.
-
-[42:14] And. Yeah, it got claimed. The Biome organization, which is a fork of Rome after that project collapsed, came together and less than three weeks after the bounty was posted, they claimed it. So it was 10, 000 from Prettier, 10, 000 from Guillermo Rauch, and then I think another like 2, 500 or like 2, 250 from an unnamed anonymous donor as well.
-
-[42:38] So yeah, cool.
-
-[42:39] **Mark Erikson:** There was something in the Wasm ecosystem, I think.
-
-[42:42] **Carl Vitullo:** Okay, something like that, yeah. Pretty interesting. I like the thought of open source bounties. I think that's an interesting monetization strategy. It's better than nothing, better than just putting a request out. So I appreciate that some companies were, or some people who had funding were willing to put their money where their mouth was on moving the, advancing the state of the ecosystem.
-
-[43:05] **Mark Erikson:** Yeah, there's a couple nice little extra points here. One is that Fabio Spampinato, I believe is his name, got nerd sniped into looking at the actual prettier source code and trying to find ways to speed it up. And sort of similar to how Marvin Hagemeister has been doing this whole series of blog posts, I'm like, I looked inside this JavaScript tool and it's doing stupidly inefficient things inside. And I made it run faster.
-
-[43:29] Uh, Fabio has been able to find a number of inefficiencies and PerfBottlenecks inside Prettier, and has some proof of concepts of making Prettier itself significantly faster, either through caching or improving cases where it was doing, like, file system lookups.
-
-[43:47] I think it even maybe inspired a PR to Node itself, where the fs. stat call was eagerly creating date objects for file times. And it turn like it turns out, you can just lazily instantiate the date object. Like it already knows the numeric times, but you can just l load the date object when it's actually accessed off the stat object. So like there's sort of a ripple effect of performance improvements going on here.
-
-[44:21] And then the other one was. Uh, Christopher Chedeaux, um, handle vjeux put up a comment on Hacker News describing why he decided to go the bounty route. And it had to do with, like, the best way to improve the ecosystem as a whole is to have multiple competing tools that are sort of egging each other on.
-
-[44:43] And so he wanted to get someone else working on it and then see that kind of ripple effect in let's, let's make all these tools better. And he feels that the money was very, very well spent in that way.
-
-[44:55] **Carl Vitullo:** Cool. Want to take us on?
-
-## [44:56] Mark's self plug, Replay.io webinar
-
-[44:56] **Mark Erikson:** Yep, uh, so we're, we're almost out of time, uh, one more kind of self pluggish kind of a thing.
-
-[45:01] So as I said, my, my day job is working for Replay. io, which is a time traveling debugger for JavaScript. Uh, we've been doing a lot of work this year around not just debugging applications, but building features to help people debug flaky test suites. And so, uh, tomorrow, I'm actually gonna be holding a livestream slash webinar over in the Replay Discord.
-
-[45:26] Uh, my teammate, Philip Crick, has done a lot of work over the years with Cypress and test stuff. And so we're gonna have a discussion tomorrow talking about, like, just debugging. This is actually one of my own personal hobby horses. Like, nobody teaches people how to debug. Conceptually, so we're going to spend some time talking about like, how do you think about the process of debugging?
-
-[45:54] And then we'll look at, you know, replay the tool specifically and talk about some of the features and how you use it to actually dig into an application. So I'm excited. Should be fun.
-
-[46:04] **Carl Vitullo:** Very nice. Always here for a, for a live event, a live chat. Yeah, Phillip reached out to me to talk through what that experience is like. So I hope it goes well.
-
-[46:11] Cool. Okay. That was the last of our lightning round links. Uh, we had a couple of Bonus items, they're a little bit broader, uh, like for instance,
-
-[46:20] Angular has a, they're on version 17 and shipped a new doc site, so, cool, good for them, looks great.
-
-[46:25] Docusaurus 3. 0 was released, which, now that Sebastien isn't here, I feel, I feel like we need to keep bringing in some of the, uh, Docusaurus.
-
-[46:34] **Mark Erikson:** We owe it to him.
-
-[46:35] **Carl Vitullo:** We owe it to him, yeah, right, right, right, he's been such a great part of this show.
-
-[46:38] **Mark Erikson:** The biggest couple updates there are, it now uses React 18 and they've updated the MDX parsing library, so it uses the latest and greatest MDX syntax for intermingling, uh, markdown and react components.
-
-[46:54] **Carl Vitullo:** I got two more.
-
-[46:55] Google has officially released a set of react components for using the Google Maps API. Uh, so I, I think the. Projects like this have existed, but this is the first time one from Google, maintained by Google, has been released.
-
-[47:11] So that's cool. And my last one, this is just fun and silly, but somebody made a Windows 95 inspired UI toolkit for React. So, you know, I love, love a nostalgic style.
-
-[47:23] **Mark Erikson:** Yeah, I've, I've seen a bunch of, like, you know, Win95, 98, 2000 XP, like, CSS packages and, and online demos. As, as someone who grew up with that era, it's, it's always very interesting to see.
-
-[47:38] **Carl Vitullo:** It is now safe to turn off your computer.
-
-[47:41] All right, that's all we got. Thank you so much for joining us.
-
-[47:45] We'll be back next month on the last Wednesday here in the live stage of Reactiflux or back in your podcast feed as soon as we can, hopefully by the end of the month. If you see anything newsworthy in the meantime, definitely let us know in the Tech News and Reads channel. We do use that for sourcing new links.
-
-[48:02] And yeah, you can discuss them with the community in the meantime. All right, thanks so much, everyone.
diff --git a/src/transcripts/tmir-october-2023.md b/src/transcripts/tmir-october-2023.md
deleted file mode 100644
index fc725ee..0000000
--- a/src/transcripts/tmir-october-2023.md
+++ /dev/null
@@ -1,379 +0,0 @@
----
-title: This Month in React (October 2023)
-date: 2023-10-25
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation about React Forget, Canary Releases, Barrel Files, TanStack v5, Yarn v4, and a preview of RTK Query v2."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/episode/4xefEOVBMI7mhfOBvOPnDV?si=NKLNBgn3TqOH7HLNLAIMHw)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/tmir-2023-10-react-forget-canary-releases-barrel-files/id1661733526?i=1000633089166)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux/episodes/TMiR-2023-10-React-Forget--Canary-Releases--Barrel-Files--and-new-releases-e2b7tda)
-
-
-
-- [00:00] Introduction by Carl Vitullo and Mark Erikson
-- [01:04] React Forget and memoization ([02:00] Optimizing performance, [02:35] Used in production at Facebook)
-- [03:52] React Server Actions in canary release ([04:09] Versioning policy)
-- [05:40] TanStack Query v5 release ([06:02] New features, [06:13] Deferring changes for Redux Toolkit Query)
-- [07:42] Barrel files and performance ([08:47] Avoid for build performance)
-- [09:13] React useTransition for concurrent rendering
-- [10:37] Photoshop on the web ([11:07] Collaboration between Chrome and Adobe)
-- [12:42] Yarn v4 release ([13:31] Per-project installs, [14:38] Performance improvements)
-- [15:19] HTTP QUERY verb proposal ([16:05] Standardization for query APIs)
-- [17:01] TC39 group for standardizing source maps ([18:31] Improve debugging)
-- [19:00] Parcel performance improvements ([20:16] Data structure optimizations)
-- [21:04] Replay DevTools time travel talk by Mark at React Advanced ([22:17] Peeking inside React internals)
-
-In summary, this month focused on performance optimizations like React Forget and query API standardization, as well as releases like TanStack Query v5 and Yarn v4. Mark also discussed his React DevTools talk diving into time travel and hacking React internals.
-
-- Mark: React Forget and memoization:
- - Sathya, React India: [Statically analysing React components for fun and profit](https://www.youtube.com/watch?v=kjOacmVsLSE)
- - Joe and Mofei, React Advanced: [Understanding Idiomatic React](https://www.youtube.com/live/tUqY9CP38uE?si=lQTtR0ZUklVhe4it&t=5364)
- - TkDodo: [The Uphill Battle of Memoization](https://tkdodo.eu/blog/the-uphill-battle-of-memoization)
- - Response: [React memo is good actually](https://timtech.blog/posts/react-memo-is-good-actually/)
-- Carl: [Server Actions in canary](https://github.com/facebook/react/blob/main/CHANGELOG-canary.md#october-5-2023-1830-canary-546178f91-20231005)
- - [Version policy](https://react.dev/community/versioning-policy#canary-channel)
- - [Client Actions](https://codesandbox.io/s/react-client-actions-l5729f?file=/App.js)
-- Mark: [TanStack Query v5](https://tanstack.com/blog/announcing-tanstack-query-v5)
- - RTK 2.0: we’re deferring all RTKQ changes until _after_ 2.0!
-- Carl: Barrel Files
- - [Vercel - How we optimized package imports in Next.js](https://vercel.com/blog/how-we-optimized-package-imports-in-next-js)
- - [Speeding up the JavaScript ecosystem - The barrel file debacle](https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-7/)
-- Mark: [React useTransition: performance game changer or...?](https://www.developerway.com/posts/use-transition)
-- Lightning round ⚡️
- - Carl: [Photoshop is now on the web!](https://medium.com/@addyosmani/photoshop-is-now-on-the-web-38d70954365a)
- - Mark: [Yarn 4.0](https://yarnpkg.com/blog/release/4.0)
- - [HN](https://news.ycombinator.com/item?id=37985779)
- - Carl: [HTTP QUERY verb](https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html)
- - Mark: [TC39-TG4 - New Task Group created to standardize Source Maps](https://www.ecma-international.org/news/ecma-tc39-ecmascript-initiates-a-new-task-group-to-standardize-source-maps//)
- - Actual working group: [https://github.com/tc39/source-map-rfc](https://github.com/tc39/source-map-rfc)
- - Example: a proposal for tracking scopes data from my Replay coworker Holger Benl: [https://github.com/tc39/source-map-rfc/pull/53/files](https://github.com/tc39/source-map-rfc/pull/53/files)
- - My own React Sourcemaps package: [https://github.com/markerikson/react-prod-sourcemaps](https://github.com/markerikson/react-prod-sourcemaps)
- - Carl:
- - ~~[Astro 3.2 - View Transitions improvements](https://astro.build/blog/astro-320/)~~
- - [7x perf improvement to Parcel bundling](https://vxtwitter.com/devongovett/status/1712169214872867288)
- - [Neat SIMD/Rust function](https://twitter.com/devongovett/status/1712169225786446111)
- - Mark: [My React Advanced talk: Building Better React DeTools with Replay Time Travel](https://blog.isquaredsoftware.com/2023/10/presentations-react-devtools-replay/)\*\*
-
-[00:00] **Carl Vitullo:** Everyone, thank you for joining us for October's This Month in React. We have a solid amount of news this month. Excited to talk through it with y'all. Some news before we get going. Sebastian Lorber, our past co host and author of the This Week in React newsletter, Is not going to be joining us as a regular co host anymore.
-
-[00:19] He is he's a new father. He just had a kid, so he is taking some well deserved time to be a new dad. He's also gonna be taking a break from the newsletter and he'll show up now and again as a guest, but he's not gonna be showing up every month like Mark and I will be and community news. We the star helper committee is finishing up evaluation for Q three.
-
-[00:42] So we should have some new star helpers. Ready to go in a couple of days here. Thank you so much for joining us for this month in react, where we recap and digest recent developments in the ever evolving react and web ecosystem. I'm Carl Vitullo. I'm a staff product developer and freelance community leader here at reactive flux, the discord for react professionals.
-
-[01:00] And I'm sure everyone knows Mark, but Mark, can you introduce yourself?
-
-[01:04] **Mark Erikson:** Hi, I'm Mark Erickson. I maintain the Redux family of libraries. My day job is working at Replay. io, where we're building a true time traveling debugger for JavaScript applications. And I sort of stick my head in anywhere there's a text box on the internet.
-
-[01:20] **Carl Vitullo:** That is entirely too true. Cool, you want to take us off on our first link?
-
-[01:25] **Mark Erikson:** Two years ago, at the online React conf, the React team announced an early work in progress React optimization compiler, codenamed React Forget, and they had a video demo, and the idea was that this compiler could automatically rewrite the logic in your React components.
-
-[01:48] To do a few different things. One was to replace the need to stick use memo and use callback everywhere. And another is that by actually memoizing the JSX elements that your component returns, it could actually optimize the rendering and performance behavior of the application, but they'd been kind of quiet about it.
-
-[02:10] And they gave a brief update back in a React Lab blog post back in March, where they said, you know, we're working on it, we're doing testing internally at Facebook, there's still a lot of work left to do. I've been keeping an eye on this, and kind of like stalking the folks who are working on this compiler anytime they pop up on Twitter and happen to say anything about it.
-
-[02:35] The good news is, That the React Forget compiler team has popped up and actually given a couple conference talks in the last couple weeks. And they've given us a lot of updates and new information about the status of this compiler. So the first one is that Satya gave a talk at React India, where he kind of laid out what are, what are some of the problems?
-
-[02:59] What does the compiler try to do? Um, gave some examples of cases where really hard situations where maybe you reassign a variable to a different name. And then the compiler has to figure out that these two things are actually the same and how does it try to deal with that? And that was kind of a high level look at what the forget compiler does.
-
-[03:20] But the one that I was really, really waiting for was actually just this week at react advanced. Uh, Joe Savona and Mo Fei Zhang gave a talk entitled, uh, Understanding Idiomatic React. And part of the idea here is that, if your components are correctly written, and follow the, the rules of React, In terms of being pure or not having side effects and that sort of thing, the compiler can make some good assumptions about how to actually rewrite the code inside of there.
-
-[03:52] They, they showed kind of a demo of a playground that they use internally where the compiler will rewrite the logic and it shows what the transform code looks like. And they also gave a status update. And some details. So they said that it's actually being used in production in two different applications.
-
-[04:12] One is the Quest VR goggle store for React Native. And the other is Instagram for web's profile page. And what they said is that in both cases they, they sort of expected that, you know, we're probably going to run into a lot of problems. And I think that in both cases, the code basically just worked and there were some modest performance increases out of the box in terms of initial mount time and re render time.
-
-[04:45] So at the moment, it sounds as if the compiler handles, I think they said like. 95 percent of JavaScript syntax and they've tested it against thousands of different components internally at Facebook. So at this point, they're, they're pretty confident that what they've built works. There is a lot more polish left to do, aren't going to open source it until they are confident it's ready for public usage and they have the bandwidth to offer support for doing it.
-
-[05:20] But I, I've been very tentatively hopeful for like the last couple of years that this is an effort that would actually work out. And after hearing the talk and I actually was sitting next to Mophie at dinner at the conference on Wednesday and was asking her a lot of questions about like, how does this work?
-
-[05:37] What's the status? I am actually very, very excited about this. I honestly think this will have a bigger impact on the react ecosystem in a lot of ways, then react server components will, I mean, they, they solve different problems. They're both useful, but I think this will actually, this is actually a very, very big deal.
-
-[05:58] And then finally, you're related to that. Uh, there were two different articles that came out, uh, kind of back to back with each other. They were actually kind of arguing about how often should you use. The use memo and use callback hooks and some discussion of are you using optimizations in the components?
-
-[06:19] Are you using them just in case a child component might worry about trying to optimize its rendering behavior? And there's a lot of very, very good points being made in both of these articles. But part of my takeaway here is that in a hypothetically perfect future world. The react for that compiler could eliminate the need for us as application developers to even have to worry about that sort of thing because it will all just magically happen and it's good.
-
-[06:51] **Carl Vitullo:** I do like that. One of these conference talks was talking about idiomatic react. I feel like that has always been, you know, through my career, I feel like in all of the different workplaces I've worked at, I felt that I have worked towards a better understanding of what is meant to be idiomatic, like not just What do I enjoy using?
-
-[07:10] What, you know, how do I understand it? But like, how did the original authors intend for this to be used? So seeing a talk about those idioms, about what, you know, how the tool is meant to be used in this context of this compiler that is supposed to make many of those ideas work better or more easily, I feel like it really ties together.
-
-[07:32] Here's why we built it this way. And here's why we recommend these things that are not always Easy or convenient or, you know, transparently improvements. So, uh, I, I like that a lot. I have, I haven't watched this talk. Um, I'm not super familiar with react forget and it's, you know, development and capabilities, but, uh, just purely on, you know, the, the name of the talk.
-
-[07:57] I, I, I love that. I think that's a really good framing.
-
-[08:00] **Mark Erikson:** Conceptually, what happens is that it's a compiler, it knows how to parse your own JavaScript source code and all the arbitrary JavaScript logic you have in your component. Declaring variables, mapping over arrays, conditional logic, use memo, use callback, whatever.
-
-[08:18] It's a compiler. It automatically transforms patterns A, B, and C. Into patterns X, Y, and Z. And so it can do the automatically memoizing you're like automatically handling dependencies for use memo or something like that. But the, in terms of like the, the rendering performance wins, most of us have heard about the react.
-
-[08:42] memo API that you wrap around a component. to keep it from re rendering when the props haven't changed. But there is a little known built in React optimization where if your component keeps around a JSX element reference like, you know, the return of angle bracket div or angle bracket my component And it returns that same element object the next time it renders.
-
-[09:11] React sees that and says, Oh, you're like, you're literally, literally asking for the same thing as last time. I'm just going to skip over that. And it's a little bit like the parent component controlling the memoization of that subtree rather than the child component needing to be wrapped in react. memo to control it.
-
-[09:31] And this has been in React for years, um, even like the first versions of React Redux relied on that optimization approach. And so, part of what the React Forget compiler can do is rewrite all the logic in your component so that it memoizes pieces of your JSX output so that those element objects only get recalculated when the data they need changes.
-
-[09:56] And thus, the automatic rendering optimizations kick in. We can debate whether this is, you know, a, a better approach conceptually, then I don't know, signals and observables and, you know, the various other performance improvements that are being used in the ecosystem today. One nice thing is that this is a build step.
-
-[10:16] So you don't actually have to change any of your code in theory to get the advancements. I don't have a good grasp on exactly how much it slows down the build step. I think Moffay said something like 3, 000 components was taking maybe like a couple minutes? Something like that?
-
-[10:35] **Carl Vitullo:** That's not short. That's interesting though.
-
-[10:37] I where I'm picturing this being beneficial. I can think of many, many times when I have written use memo, you know, use callback optimizations because I want to hint to react that like these are stable references. I know that, you know, by by doing this whole chain all the way up from like the inside of this hook to a component to the transformation being done on that data to where it's being passed in.
-
-[11:04] Thank you. If I want the best possible performance, I need to be intentional about when those references change. And so it sounds like this compiler is trying to do that same kind of logic where I would do it manually, you know, take it in my head and then write it all out. Which often I have found myself backed into a corner where it's like, oh shit, if I want to fix this reference, I need to totally fix all of the other logic around this because I have conceptualized the problem incorrectly.
-
-[11:32] So something I've said about hooks in the past is a lot of the time it has felt more like solving a puzzle. It's like, there is a right way to mod, there's a right way to model this problem. And I end up going down like three dead ends before it's like, ah, here's the one where all the references are stable and all the state is correctly modeled, which is difficult.
-
-[11:56] It takes a lot of work. It takes a lot of time and takes a lot of thought. And then sometimes there's a new requirements like, oh, shit, I can't just casually add this because I spent all this time modeling to a different problem. And now the problem has changed. So that has been a recurring pain point of mine in developing with hooks.
-
-[12:14] So. A compiler that gets me 80 percent of the performance benefit of doing it perfectly without many reworks and, you know, deep problem solving. Sounds pretty great.
-
-[12:27] **Mark Erikson:** Yeah, like it's not going to magically fix every single performance issue or problem with your react code, but if it offloads a lot of the mental overhead that we have trying to think through some of those issues, that alone is a really big deal.
-
-[12:42] Yeah,
-
-[12:42] **Carl Vitullo:** most definitely. Onto our next one, I'm very excited because this is, we've got a new canary out, server actions are now in canary. So this is, server actions came out in next recently. I think we talked about it last month or maybe a month before and yeah, now they're officially in the like react canary channel.
-
-[13:04] More of what I wanted to discuss here is sort of the canary release process. Yeah, yeah. So in announcing this, they linked to their. versioning policy specifically saying, like, look, this is how you use canaries. Uh, and the big thing that it said is canaries must be pinned. So it says if you are using a canary channel, you need to use the, this exact version, not a, not a pseudo matcher.
-
-[13:31] They do not follow SemVer. If you don't want unpredictable breaks, you have to actually pin to an exact version. That seems great. I'm glad to get clarity. I'm glad that they have put out this versioning policy with explicit recommendations like that. This is not a new policy. I think it came out a couple months ago,
-
-[13:49] **Mark Erikson:** came out back in March ish, but we're sort of just now starting to see the first working examples of it.
-
-[13:55] **Carl Vitullo:** Yeah, so I guess, you know, March, they like got all these policies in place and then have been sort of working with next and doing development work. And it feels like now they've kind of turned back and are doing more messaging kind of stuff like this. You know, they announced a new feature and said, here's how to use it.
-
-[14:09] Here's supporting documentation about how we think about it. I appreciate that. That's very helpful. Very
-
-[14:15] **Mark Erikson:** clarifying. And this, this is unfortunately a topic I'm far too familiar with both as a, as a, as a library maintainer and then looking at react specifically. So I think most people are sort of used to the concept of libraries might put out an alpha release, a beta release, a release candidate, and then finally an actual stable release.
-
-[14:38] And we've, we've seen that even before with react, you know, like react, 18 went through betas and release candidates before it went stable. And then they put out 18, one and 18, two with some fixes and react 18, two, the current stable release came out almost a year and a half ago. And meanwhile, next has been.
-
-[15:00] Releasing new features. They've got some of the React core team members working over there, and there's been a lot of confusion over like, what is in the versions of React that Next is using? How can other frameworks actually use any of these things? For the last several years, React has had, uh, so there's both like the stable releases, and they also have an experimental channel, which is just automatically built like every day, every couple days.
-
-[15:29] So it's like straight off the tip of the main branch, whatever got merged in. And those experimental builds also have feature flags turned on so that like literally everything brand new that's in the React repo that isn't even like fully enabled yet is enabled in the experimental builds. But those could always change on a moment to moment basis.
-
-[15:50] So with next at the moment, you, I think you can actually end up with like three separate versions of react going because there's the production version. You probably specified in your own package, Jason. And I think that gets used with like the pages router. There's the canary version, which is a new semi react specific concept where it's like, this is semi stable.
-
-[16:14] It's maybe not like done, done. Maybe we're waiting on some other pieces, but we kind of think it's stable enough to use, and then there's the experimental version where, you know, there there's truly stuff that's, it's kind of wild. And so in next, I think if you use the app router. It's using a canary build.
-
-[16:32] I think a couple other experimental features you can opt into, in which case it uses an experimental build. And, you know, the idea of these canaries is that the React team maybe has some features that are in, that are in progress. At this point, they think they're stable enough that frameworks could use them because frameworks could add additional wrapping on top to kind of like hide the rough edges.
-
-[16:59] There's maybe a couple pieces that are still like waiting to tie into those before they can declare them fully, fully done and ready for a stable release. And unfortunately, up until now, there hadn't been any indication of Here's what canary versions have been released, or here's what features are included in a given canary release.
-
-[17:20] And just within the last week, uh, one of the react dev rels, Matt Carroll actually added a change log for the canaries as a markdown file in the react repo. So that's a step in the right direction.
-
-[17:34] **Carl Vitullo:** Yeah, I was, you know, I was just sort of thinking about, you know, versioning and releases and okay, so there's released versions of react.
-
-[17:42] There's canary and then there's experimental. So that's, you know, the MPM releases the release channels. But then there's also they have apis, right? They have the unstable underscore whatever apis. As well as some that are not even available because they're feature flagged out of the build out of the you know what the code that goes on NPM and I was just I'm just thinking about it's like wow wait so there's like six different ways of controlling how people what features are available and how people are able to make use of them and that's complicated like what a dance you have to do I
-
-[18:20] **Mark Erikson:** have unfortunately messed with some of reacts build system for something else and I've seen The code that controls, like, here's the master list of all the packages that are in the mono repo.
-
-[18:31] Here's all the different kinds of build artifacts that need to get generated for each package. Here's some of the feature flags that control individual features. Like it is really complex.
-
-[18:43] **Carl Vitullo:** I had read a line in the Canary Diversion Policy that I was hoping to find so I could quote it exactly. They talked about how part of the reason they do this complicated dance is because they have multiple projects that are all interrelated.
-
-[19:00] And so, you know, people say like, Oh, well, why don't you just release this, this feature while you're working on that feature? And the answer is, well, we can't release that until we release both. And people want access to that before both of them are ready to be released. And so we do this complicated dance in order to facilitate that.
-
-[19:18] And it's a lot of work that they put into. Structuring and communicating these releases, I knew all of these pieces, but I hadn't quite put them together into like, wait, this is a lot to manage to keep in your head. Mark, take
-
-[19:34] **Mark Erikson:** us on our next link. The next item is that 10 stack query version five is out.
-
-[19:40] Um, this of course includes the react adapters, like react query, as well as the adapters for the other frameworks. They've got some breaking changes. I know they changed things like removing callbacks from the mutation hooks. They've apparently altered some of the, the way you pass in options for the query hooks to try to make that more consistent.
-
-[20:02] Uh, there is a number of new features around, um, how you define optimistic updates. Uh, there is suspense support built in. They have a react server components, streaming adapter, and some infinite queries and dev tools. Uh, and it sounds like they even managed to shrink the bundle size. So that sounds like a very impressive release.
-
-[20:23] Definitely worth checking out. And I will say that wearing my Redux maintainer hat, we're getting close to the release of art Redux toolkit 2. 0, I hope. And part of that was actually cutting scope so that we don't, we are not going to make any real changes to our, to our RTK query data fetching API for 2.
-
-[20:41] 0. Because there's lots and lots of requests for changes. So we're going to defer any changes until RTK 2. 0 is out the door. And once we do, we will be looking very carefully at. React query and looking at some of their APIs and how they designed some of the use cases and frankly blatantly stealing from them, which is good because it means familiarity.
-
-[21:04] And also they've had more time to think about some of these problems than we have. And also we're friends with the maintainers. So we, we cross inspire each other all the time. It's
-
-[21:13] **Carl Vitullo:** not stealing it's standing on the shoulders of giants. Taking
-
-[21:16] **Mark Erikson:** inspiration from.
-
-[21:19] **Carl Vitullo:** Look at you, taking inspiration from a release to talk about your upcoming release.
-
-[21:25] That all sounds really great. I haven't, I still have not really extensively used React Query. I love all of the ideas of TanStack and whatever, but somehow I always... I'm stuck with Redux, so I don't know very much about the past experience or what this new release will change. I'll take us on to our next link.
-
-[21:42] There was some discussion of barrel files that I found really interesting. Berthel put out a blog post talking about how we optimized package imports in XJS. The term barrel file was new to me, though I... Have encountered the concept a great many times in many workplaces. It's it's the index. js file that imports and re exports modules or, you know, various exports from other modules and The problems that they talk about here are not ones that I had specifically observed through my career.
-
-[22:16] So basically what they talk about is these barrel files essentially centralize import or, you know, the module tree, the tree of your modules and sort of act as choke points. So it's like, as soon as you import something from one of these barrel files, suddenly every single module is being pulled in. And I guess, you know, maybe a more familiar.
-
-[22:39] statement of the same problem is low dash bundle size inflation. You know, I'm sure many of us, I have encountered this so many, on literally every project I've worked on, where somebody imports low dash, they do group by from low dash. Then, because tree shaking doesn't work reliably, the entire module gets pulled in.
-
-[23:00] And so, That's usually a bundle size problem, but what Vercel is talking about here is there's a second dimension to that, which is sprawling the module tree has a, you know, a noticeable cost to it. There, there is time spent creating and then navigating that tree of modules and barrel files by acting as these choke points mean that, especially on large projects, that time spent.
-
-[23:29] Looking at the tree and figuring out where code is coming from can explode to like a substantial portion of your build time. So Vercel next talked about optimizations they're doing to correct that for you. They will inspect imports to determine whether they are barrel files and then undo that for you silently on the backend so that you don't pay that, uh, that.
-
-[23:55] Discovery cost of, uh, traversing the tree of modules. That's really interesting. This is a new dimension to a problem I had observed in the past. Another thing that is, this is not exactly the same problem, but a pet peeve of mine that I've seen in more than one workplace is barrel files that rename exports.
-
-[24:14] So they'll import from one place and then re export it. Under a different name. So that's that sort of problem is why I had slanted on like, don't use these. Like there's just, if you're trying to find a particular bit of code in a large code base, barrel files do not help. They make it actively harder. So don't use them.
-
-[24:34] It's a bad practice. But also learning about another dimension of performance problems that they introduce. I'm never going to use barrel files again. It's not great.
-
-[24:42] **Mark Erikson:** I've never been a fan of the concept for a few different reasons. I mean, to back up a bit, I think the argument. For people who have used them is that it's a conceptual encapsulation thing.
-
-[24:55] So the idea is that if you have source slash features slash feature one, and you have many different files with different types of code inside of that folder, you can encapsulate the implementation details inside there by having source slash features slash feature one slash index such as it does the re exporting and other parts of the code base.
-
-[25:19] Should not be allowed to import from the nested files directly. They're only allowed to import from the index file. So they aren't like conceptually poking into things that they shouldn't know about. I can understand the architectural thought involved, but as we noted, there's, there's runtime implications.
-
-[25:40] You know, one is that if I right click a, you know, a component name or a function name, and I say, go to definition, it might end up jumping me to this barrel file instead because of how the compiler is trying to trace things. And then, yeah, like if you are bringing everything through one intermediate file.
-
-[26:02] The imports from a hundred other files, then just trying to import one thing is going to force that file to be parsed and loaded and go look at everything else and parse and load it. And, you know, maybe all those files do get used somewhere, but it also means extra processing time during the build step.
-
-[26:22] Maybe even a little extra time as the application is running. And so Marvin Hagemeister has done a lot of work over the last year, year or so to investigate common tools in the JavaScript ecosystem. Yes, lint and, um, a whole bunch of others. And he's found that in a lot of cases, the internals of these tools are actually doing things very inefficiently.
-
-[26:47] So the post that he has here, it's, it's slightly more theoretical. He's not digging into real code in one specific tool, but he had seen real world code bases where having barrel files was leading to drastic slowdowns in build time, and he created a fake example. Which had like a bunch of nested build tools and then, or a bunch of nested barrel files.
-
-[27:13] And that example made the code base build time explode. And so, yeah, like general, I think generally speaking, the advice here is that in order to kind of help speed up build performance, don't use this pattern. Instead, just go ahead and directly import from source nested file. And it's okay. I
-
-[27:37] **Carl Vitullo:** do empathize with the, the general impulse to do this.
-
-[27:42] It lets you treat your folders like internal modules, which is nice. It's convenience. It causes the pit of failure. It causes the foot gun where if you just do that indiscriminately without thought for how many files it is and without an understanding for like the downstream effects, because I think what really happens here is, okay, you do that once.
-
-[28:03] And then you do it twice, and then you have a pat, you know, 15 models, modules that all do that. And so then anytime you import anything, it gets your entire code base. It has to navigate your entire code base for it. So, yeah, that makes sense. And going back to that, you know, speeding up the JavaScript ecosystem series of blog posts.
-
-[28:25] I just saw, you know, another link that I'm not sure if I made the cut for this, but Parcel was talking about performance speedups. And like they changed their internal data structures, like that's it. Like they changed how they modeled it internally and got like a 5x beat up. So like there is clearly there are some low hanging fruits to make the JavaScript ecosystem faster.
-
-[28:47] So, uh, if this is one of them, then cool, let's, let's get rid of it. We don't
-
-[28:51] **Mark Erikson:** have to just go and rewrite everything in Rust. Sometimes we can look for really stupid code patterns and fix those. Performance.
-
-[28:59] **Carl Vitullo:** It's tough. All right. You want to take us on to our next one?
-
-[29:03] **Mark Erikson:** Yeah. So on a, on a sort of related note, React 18 came out with some new hooks and I think most people probably don't know they exist.
-
-[29:13] And to be honest, I still haven't even tried to use most of these new hooks myself, but I have seen my teammate Brian Vaughn, who used to be part of the React core team, using them because he was part of their development process. You might've heard that, you know, React 18 was going to have a concurrent mode.
-
-[29:34] And then they ditched that. It's not a whole standalone mode. Instead, it's concurrent features. So, there are specific React APIs that, when you use them, Make React handle the rendering process in a different way, being able to split a render into pieces or do some of that work in the background. And so two of the new hooks in particular are use transition and use deferred value.
-
-[30:03] Now, like I said, I have not actually used these in practice. Brian has attempted to explain them to me a couple of times and there's this very, very good. Excellent blog post by Nadia Makarevich, who's written a number of very good other articles about React behavior. And she goes into some detail about how these hooks work.
-
-[30:22] If I can try to explain them, and I'm probably going to get this wrong, so please read the article in the official React docs. UseTransition gives you something akin to setState, but it accepts a callback. And the idea is you're supposed to run the callback, run the startTransition callback, And do your actual update work inside of the callback.
-
-[30:45] And that's basically a signal to react that the work you're doing is relatively low priority and it should kind of be handled in the background compared to other potential renders. The other one is use deferred value. And I think the explanation that I sort of half understand is it's almost like a built in debounce.
-
-[31:08] In a sense. So maybe you're getting a value from some other source and you need to be able to render something now, but there's probably going to be like another version of the value coming later. So so you pass a value directly to use deferred value. And it returns what appears to be the same value.
-
-[31:33] Well, it's actually happening is it's starting one render right now and then it's like scheduling a second render for just a little bit later. So again, I don't have like the best understanding of them because I haven't used them in practice and also because I haven't used them. I don't I don't have a good feel for the mechanics.
-
-[31:50] But that's kind of the idea. It's about telling react that some of these pieces of data are lower priority. Let me do something now, schedule some lower priority work, and then rerender again, later when we've got all the pieces that we need. It's
-
-[32:05] **Carl Vitullo:** reminding me of a performance problem. I hit a couple of years ago when I was building a cryptocurrency exchange, because that's how my career has gone.
-
-[32:13] And we had a detailed list of. Tokens and every token had its own sparkline. And so when there were 40 tokens on screen, that was 40 sparklines. 40 charts is a lot to render. And so performance. tanked, and it took like three seconds to render the page. And I solved that by introducing a wrapper component that would immediately return null and then re render with whatever it was.
-
-[32:40] And I called this, you know, poor man suspense back in the day. Just saying like, Do it later. I don't care. Render something. Render everything else first. And I wonder if this might have been a, if, I wonder if this use deferred value hook might have been an alternate solution to that where I could say, you know, could have fed that little chart data out of this deferred value and gotten the same benefit without adding a Another component to the, to the hierarchy.
-
-[33:10] That's interesting. Okay. Very cool. I use transition is also new to me. I was just sort of trying to read that, uh, blog post, but it's long. I can see why this is a, uh, a concept that you, you've had explained to you more than once, but yeah, that looks really interesting. Very curious to hear more about that.
-
-[33:28] Well, okay. That is all of the news items we have. Should we move on to the lightning round? My first Photoshop is now on the web. This is something that I, I remember reading like an early technical write up about two or more years ago, talking about all of the efforts being done to bring a true, proper, real version of Photoshop onto the web.
-
-[33:50] And I know that there's lots of WebAssembly and WebGL and Canvas and just like, it was. It's truly an engineering effort that advanced the state of the web platform generally in a very real way that I think is quite rare, though, you know, I don't know that it has a ton of immediate actionable relevance for react and, you know, how we develop applications.
-
-[34:15] The byline on this article is enabled by WebAssembly and Emscripten, Web Components and Lit, Service Workers and Workbox, and New Web APIs. Chrome and Adobe enjoyed collaborating on it. So this is, you know, a deep collaboration by presumably the Chrome team at Google and Adobe building Photoshop, getting the web platform into a state where it was a suitable host for a real version of Photoshop.
-
-[34:42] As opposed to, you know, I think a lot of this type of application would tend towards doing the heavy lifting on the server. So, like, you know, if you were, you know, they've got a early screenshot in the blog post of generative fill. Uh, so, you know, like, I think, you know, the, the easy, the, the pragmatic. Just get it shipped approach would be just do that on the server, you know, so I think it's really interesting to see a project like this.
-
-[35:12] I think that this is a once every couple of years level of investment in the platform. It's worth reading. It's worth learning more about just seeing how they did it and why they bothered to do all this effort. Cool. Mark.
-
-[35:27] **Mark Erikson:** Alright, so it looks like Yarn version 4 just came out, and I've been a fan of Yarn ever since it was first released, but the transition from Yarn 1 to Yarn 2 was kind of like the Python 2 to 3 transition, or, um, you know, kind of like the common JSTSM transition, in that there were such major changes in the way this product was designed and used, that it...
-
-[35:55] You know, it caused a lot of frustrations and turned people off. Um, so there's a little bit of background. Yarn 1, like most other JavaScript tools, is installed globally on your whole machine. So, you know, npm i dash g yarn. Yarn 4 are supposed to be installed on a per project basis. So you're actually supposed to copy the, like a yarn, like release binary JS file into your repo and commit that.
-
-[36:30] And you have a config file. And when you run yarn inside your repo, yarn one from your system starts up. It sees the config file and sees, Oh, I'm actually supposed to run yarn three, two, one dot JS that's committed. And then it switches over and starts up the, the low, the local newer version of yarn instead.
-
-[36:53] And I think that concept has confused a number of people. The other big thing is that when Yarn 2 came out, they had this really radical idea about how it would manage the installation of the JavaScript packages. They called it plug and play. And the idea was that instead of extracting, you know, 50 or a hundred thousand files into your node modules folder, it would leave all tarballs.
-
-[37:20] So it's smaller on disk, and there's no time needed to extract everything, but in order to make that work, Yarn has to take over and act as an intermediary layer for any tool that needs to import a library or access anything. And there's so many tools in the ecosystem that expect that real files exist on disk in Node modules, because that's how everything works.
-
-[37:46] So, my own experience has been that, you know, Yarn's plug in play mode is a nice concept, but in practice, every time I tried to use it, there were too many other tools that would just break in some way. But, especially with Yarn 3, they have a standard, let's just extract everything into node modules option, and I've actually found that works great.
-
-[38:07] We're using it in my day job at Replay, we're using it in all the Redux repositories. Um, so the, I've, I feel that works great. So with yarn version four, looking at the release notes, um, they've got a couple fairly fancy new options around validating packages that are installed. Um, being able to define constraints, which maybe makes things work more consistently in a monorepo.
-
-[38:31] Yarn three has a plugin model and they had some official plugins, but they weren't installed by default. And it looks like those plugins do now get auto included with yarn. So they're always available. Uh, they've, they've improved some of the UI output and it also looks like they've improved some of the installation performance as well.
-
-[38:51] So if you're using yarn two or three, it's probably worth upgrading to yarn four. And if you're using yarn one, it, it probably is still worth looking at the newer versions of yarn as well. Uh, there was a lot of debate in the hacker news thread. Um, you know, a lot of people are arguing about, you know, why do we need so many package managers or, you know, discussing the, the transition from yarn one to the later versions?
-
-[39:17] Some interesting reading over there.
-
-[39:19] **Carl Vitullo:** Yeah, as someone who has never moved beyond yarn one, I empathize with all of those. There is a discussion of. a query verb for HTTP requests. Uh, this would be in addition to like get, post, patch, put, delete, now query. This is really interesting. Uh, it seems to be a standardization of essentially like GraphQL.
-
-[39:41] GraphQL, I know, uses slash abuses post, which has some negative consequences just because Host is meant to be submitting information, not retrieving information. Um, so this looks like a recognition that the current verbs are not quite sufficient for modern use cases in so far as the get verb has no body.
-
-[40:05] You can't say you can't give any information along with that request that URL. So, you know, you can do query variables, but like at a certain point, the URL is like. You know, if you have kilobytes of data that you're trying to send back using in the URL has some trade off that's not ideal. Um, and post is not idempotent.
-
-[40:28] You know, it is not understood by the spec. It is not safe to retry post requests. That's not a safe assumption. So, you know, you can write an API where it is safe. But if I'm writing. A fetch library, a fetch wrapper, then I, you know, I can't say I, because it is a post request, I can't reliably retry it. I can't, I cannot write code that does that because it might not.
-
-[40:53] Um, so this is now essentially it. I think my summary would be this is get with a body, uh, with the recognition that it's going to be used to query data. Very cool. I think that's, you know, big platform
-
-[41:07] **Mark Erikson:** iteration. Okay, next up, um, so TC39 is the standards body that deals with the JavaScript language. And they've announced a new working group that is going to try to improve the specification for source maps.
-
-[41:24] Now, if I had to guess, probably two thirds of the people here have no idea what a source map is because you've never had to worry about it. Source maps contain data. They contain all the original code, like your code, as it looked like on your machine, before you hit the build button, and then they tell debuggers and other tools, here's how you map, you know, to do list item.
-
-[41:48] ts line 37 into these 30, these 25 characters in the middle of your application bundle. And so this is how JavaScript debuggers like the Chrome DevTools or my own day job at replay are actually able to show you your original code so that you can step through it, see variables, and do all that stuff while debugging.
-
-[42:12] Source maps are really stupidly complicated. I'm not an expert on them, but I've learned a lot about them over the last couple of years. And there is a current spec for what information source maps can contain, but there's a lot more cases where they could be useful. And like Brian handle more cases. So this working group is trying to expand the specification for source maps and add more information that can handle specific cases so that in the future, once the spec is defined and build tools, output this information and debuggers know how to use this information, they can more faithfully represent what your original code was doing as you're trying to debug it.
-
-[43:01] And so one of my, one of my coworkers, Holger Bentel. Is actually part of this working group. And he even has submitted a proposal that, um, to try to capture information about scopes. An example of this from the, from the proposal is that if you have like three nested function calls, the compiler might, you know, or a minifier might collapse all of those and just say, well, the last function just returns a value.
-
-[43:30] I can just get rid of those first two functions entirely and return this value at like in the production code. That means that the source map might not capture the fact that when you wrote it, There were two or three other functions in the middle. And so when you try to debug it, it sort of ends up looking like you skipped from like above the function into the middle function and never paused anywhere in between.
-
-[43:55] So by capturing more information about scopes. It could do a better job of representing the way you wrote the code. And I'll also put in a self plug for one of my own things. Uh, react has never shipped source maps for its production builds, which is why you, when you see a react error, uh, in production, the stack traces are all gobbledygook and earlier this year, I put up a PR to actually add source maps to react build pipeline.
-
-[44:28] That PR has been sitting there for the last five months. Um, I actually had a conversation with a react team member just this last week at a conference. And I'm, I have tentative hope that maybe that'll get merged sometime soon. I hope, but the problem is even once it's merged, that will only be helpful for future releases of react.
-
-[44:52] That actually include the source maps during the build step. So I've actually done the work to backport my react build pipeline changes. And I generated the source maps that would have existed or react 18 to 18, one and 17. And I worked with someone from the century tool. Who then proceeded to put together build plugins for Webpack, Vite, and Rollup, I believe, so that you can install this package in your app, add it to your build pipeline, and it will automatically use the quote unquote original React source map in your application bundle.
-
-[45:34] Is this going to radically improve your debugging experience? Maybe not, but it hopefully can help in situations like, you know, being able to see error messages and some other things like that.
-
-[45:45] **Carl Vitullo:** Yeah, my kingdom for React source maps. Cool. Uh, I'm going to make a game time decision. I was going to talk about, uh, Astro 3.
-
-[45:54] 2, which has view, uh, transition improvements, but I don't really know that much about view transition improvements, so I'm going to switch it up and talk about Parcel performance improvements instead. Uh, I touched on this briefly earlier, um, The, the, the gist is they're claiming, uh, seven times faster rebuilds on large projects, uh, and lots of other performance improvements, um, no rust rewrite, no, you know, massive core, whatever, replacement.
-
-[46:25] Um, but they talked about, they said 50 percent of the time in bundling was spent looking up values in different maps. So that, you know, they have maps and sets that, uh, determine which bundle routes, uh, each module is reachable from. So, you know, basically like, if you're here, then you can get over here.
-
-[46:44] And they switched out those maps and sets into, uh, bitsets. Which is, I guess, more like, I'm trying to... Retreating
-
-[46:54] **Mark Erikson:** and treating the individual ones and zeros in an integer as if they were bullions.
-
-[47:01] **Carl Vitullo:** Yes, there we go. We have one value that represents multiple flags, multiple multiple different, you know, things.
-
-[47:10] So, you know, by they say that purely by switching from storing all of this data in maps and sets. You know, the, the, the JavaScript, you know, concept of a map or a set new set new map, uh, into this bit set where it's working on a binary level rather than a like string level, I guess, uh, they've been able to get a five X improvement in bundling speed in some situations.
-
-[47:40] So. It just goes to show you that, you know, sometimes you're going to, sometimes rewriting in Rust is right, but also, like, if you're rewriting in Rust, you're basically doing this logic, like, Rust operates on, you know, it's a low level language, whereas JavaScript is, by default, a high level language, you're, you know, in JavaScript, if you're just going to write code the most intuitive way, you're probably writing strings, objects, arrays, JavaScript.
-
-[48:05] But there's nothing stopping you from writing code as if writing JavaScript as if you were writing Rust or C. Um, you can use buffers. I guess not in, not in the browser. You have to use typed arrays. You and data arrays. Right. But, you know, you, it is perfectly feasible to write JavaScript that does all, all of those low level manipulations.
-
-[48:25] And it, yeah, if you're thinking, if, if you ever find yourself thinking like, man, I wish I could just rewrite this in Rust, like. Take that same thinking that you would approach writing it in Rust with and try writing in JavaScript. I bet you'll get halfway there on the
-
-[48:39] **Mark Erikson:** performance. The, the funny thing was though, I don't, I don't know if you caught this.
-
-[48:43] So, there was one little bit that they couldn't do from JavaScript. There's apparently a... an advanced CPU SIMD instruction that they wanted to use specifically for some of the comparisons to make them faster. And you can't access specific CPU instructions from JavaScript. It just, it's just not possible.
-
-[49:05] So what they did was they wrote that one tiny, tiny little bit in Rust and compiled it to WASM. And exposed it to JavaScript. So, because they could, they could use that SIMD instruction in Rust. And so by doing that, it's like they made one little function, which is like, you know, fast bit compare or something like that, and expose that to JavaScript from Watson, that's impressive.
-
-[49:32] Yeah,
-
-[49:32] **Carl Vitullo:** that is really cool. I love the idea of SIMD. If folks in the audience aren't familiar, uh, S I M D, Single Instruction Multiple Data. Uh, it's what powers, it's the core concept behind like graphics cards and like all the AI and the mining and whatever. Uh, you take 600 values that all need the same thing done to it.
-
-[49:53] Modern processors will let you pass in That data and an instruction and we'll just do all of that at once instead of one, you know, instead of doing like tick, tick, tick, tick down a list 600 times it'll just go and do 600 units of work all at once. So, yeah, very cool. I didn't, I, I had missed that. They did use rust for a little bit of that.
-
-[50:16] That's very cool.
-
-[50:17] **Mark Erikson:** Okay, we're about out of time, and fortunately this is the last item on the list. So, self plug. Last week I spoke at the React Advanced Conference in London, which was a wonderful time. Uh, that's also where the React for Git talk was. Uh, the live streams are up on YouTube, um, and the, the individual talks will be available on the, the Git Nation, uh, conference organizers site within the next couple weeks.
-
-[50:43] My talk specifically was titled Building Better React Dev Tools with Replay Time Travel. Most of the last year building some very advanced features for replays, time traveling debugger that rely on poking inside the internals of the react library and the react dev tools in replay. We have the react dev tools integrated so that as you jump to different points in time, you can see what the react component tree looked like at that point in time in order to gather that data.
-
-[51:19] I actually had to go make changes to our recording version of Chrome to say here's every time react rendered and then there's a back a server side back end post processing step opens up the recording goes to each point in time injects the react dev tools bundle code and then extracts the component tree data and then it's even able to take some steps further like if you made a recording of a production application it can use source maps to figure out well and Okay.
-
-[51:51] This components name in production was QZ, but that's actually to do list item from your original code. So let's use the original name of to do list item for the component tree instead. And so I talked about, here's how the react dev tools actually saves and transmits that information. And then I talked about the steps needed to actually do this time travel analysis and replay.
-
-[52:17] Um, and I've semi open sourced the actual code. Uh, the, the code is technically speaking in our proprietary backend repo, but I've copy pasted it to an examples repo. It won't run, it won't compile, but if you want to see... 2500 wines of Mark doing stupid, weird, crazy, mad scientist things. It's available. Heck
-
-[52:39] **Carl Vitullo:** yes.
-
-[52:40] Thank you so much, Mark, for talking through the news with me. Thank you so much, everyone in the audience for sticking with us. Uh, well, I hope everyone has a good Halloween. Uh, spooky season is almost only or almost over. Um, yeah, cool. See you guys next month.
diff --git a/src/transcripts/tmir-september-2023.md b/src/transcripts/tmir-september-2023.md
deleted file mode 100644
index 0e1d866..0000000
--- a/src/transcripts/tmir-september-2023.md
+++ /dev/null
@@ -1,513 +0,0 @@
----
-title: This Month in React (September 2023)
-date: 2023-09-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Jacob Paris, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Jacob Paris](https://twitter.com/jacobmparis), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-Remix v2, Docusaurus v3, Node 20.6, Bun 1.0
-
-- [Spotify](https://open.spotify.com/episode/54ClLvCFL82IG93a4g7vXZ?si=j7G_aMnNSwOid70QPsJcBQ)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/this-month-in-react-september-2023/id1661733526?i=1000629732098)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [Or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux/episodes/This-Month-in-React--September-2023-e29vb6o/a-aadsk3b)
-
-
-
-This episode covers major updates across the React ecosystem, including:
-
-- Node 20.6 adding built-in .env support
-- Remix v2 using extensive feature flagging
-- Docusaurus v3 introducing visual regression testing
-- Astro 3.0
-- understanding React Server Components. Server components enable powerful capabilities like data fetching at the component level, but also introduce complexities around data serialization and scoping.
-- Bun 1.0 as a faster Node.js alternative, aiming to replace many common Node.js tools and improve performance. There was discussion around adoption challenges due to non-standard features.
-- Next.js adding server actions for forms
-- Expo moving towards full stack capabilities, which expands capabilities for mobile apps and could position Expo as a compelling full stack solution.
-- and Dan Abramov joining Bluesky
-
-Key themes were leveraging Rust and other languages for server-side rendering, moving away from CSS-in-JS, and enabling easier major version upgrades through techniques like feature flags.
-
-Sebastien discussed using React Server Components in static site generators like Docusaurus to simplify data fetching without GraphQL. There was also discussion around using languages like Rust and OCaml for improved server-side rendering performance.
-
-Links used:
-
-- [Node 20.6 - Built-in .env file support](https://nodejs.org/en/blog/release/v20.6.0)
- - [Node.js 16 End-of-Life](https://nodejs.org/en/blog/announcements/nodejs16-eol)
-- [Remix v2 pre-release](https://twitter.com/remix_run/status/1696525340640936190)
- - [Upgrade guide](https://remix.run/docs/en/main/start/v2)
- - [SemVer philosophy](https://remix.run/blog/future-flags)
-- [Docusaurus v3 beta](https://github.com/facebook/docusaurus/discussions/9312)
- - [Upgrading frontend dependencies with confidence](https://docusaurus.io/blog/upgrading-frontend-dependencies-with-confidence-using-visual-regression-testing)
-- [Astro 3.0](https://astro.build/blog/astro-3/)
-- [Making Sense of React Server Components](https://www.joshwcomeau.com/react/server-components/)
-- [Expo Router RFC - API Routes](https://blog.expo.dev/rfc-api-routes-cce5a3b9f25d)
-- [Bun 1.0](https://bun.sh/blog/bun-v1.0)
- - [My Thoughts on Bun](https://adventures.nodeland.dev/archive/my-thoughts-on-bun/)
- - [Announcing Biome](https://biomejs.dev/blog/annoucing-biome)
-- ⚡️
- - [React-Native running natively on Apple Vision Pro simulator demo](https://twitter.com/o_kwasniewski/status/1701626162521190688)
- - [Are Big Projects Ditching TypeScript?](https://www.totaltypescript.com/are-big-projects-ditching-typescript)
- - [Rust Server Components](https://anto.pt/articles/rust-server-components)
- - [Web Developers, CSS-in-JS is Ruining Your Product](https://cord.com/blog/migrating-from-css-in-js-to-vanilla-extract)
- - [Dan Abramov joins Bluesky](https://twitter.com/dan_abramov/status/1695566446007386214)
-
-[00:00] **Carl Vitullo:** Hello everyone. Thanks for joining us again for September's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. I'm Carl. I'm a staff product engineer and freelance community leader at Reactiflux, the Discord for React Professionals, where you are! Joined today by Jacob Paris and Sebastian Lorber.
-
-[00:22] Jacob, do you want to introduce yourself?
-
-[00:24] **Jacob Paris:** Yeah, sure. Thanks, Carl. So I'm, working in DevRel at the moment. I've been a React dev since, not quite the start, I was one of the later later laggards to drop off of Angular, way, way back then. And on the side I'm an egghead instructor.
-
-[00:38] So I've been producing a lot of content primarily for the Remix ecosystem. And yeah, just trying to share and teach as much as I can.
-
-[00:46] **Carl Vitullo:** Well, also you send out a monthly Remix newsletter yourself, don't you?
-
-[00:49] **Jacob Paris:** Yeah, yeah, I do. So that, that one's called Moulton. I took over as a writer of that. Pretty recently and pretty similar to the this week in react, but it's specifically focused on the Remix ecosystem. So, the, all the cool libraries and articles and courses and updates from the team and everything cool that's happening with Remix.
-
-[01:08] **Carl Vitullo:** Nice. Yeah. A lot going on there. Yeah. And Sebastian?
-
-[01:12] **Sebastien Lorber:** Yeah. So I'm Sebastien Lorber, and you probably know me for the this week in React newsletter, and I'm also the, the maintainer of Docusaurus, which is now, the version three is in beta. So you can give it a try if you want and, give me some feedback.
-
-[01:28] **Carl Vitullo:** Cool. All right, let's jump into it.
-
-## Node 20.6
-
-- [Node 20.6 - Built-in .env file support](https://nodejs.org/en/blog/release/v20.6.0)
- - [Node.js 16 End-of-Life](https://nodejs.org/en/blog/announcements/nodejs16-eol)
-
-[01:30] **Carl Vitullo:** I guess my first link here is new. It's not actually react or react related directly, but it will affect the ecosystem. New Node version 20.6. Really, my big highlight here is they're pulling in dotenv support to the runtime properly. So no more dotenv. We don't need to install a package, we can just use dotenv files.
-
-[01:55] Yeah, a lot of the other changelogs look pretty deep and wonkish. There's one that looks like it might be really interesting or might have really interesting echoes throughout the ecosystem, but I'm not really sure exactly what it is about.
-
-[02:09] It's something about registering module hooks Module customization hooks. They have a call out in the change log saying that those module customization hooks can now handle both ES modules and common JS sources. I don't know exactly what those are for. The reading about them in these release notes was the first time they'd ever crossed my radar. And there's not really a lot of information about what they're for in here.
-
-[02:32] But anything that starts talking about cross-compatibility between ES Modules and CommonJS is like, very interesting to me because that has been such a pain point for like. tears at this point. So that caught my eye too, but it looks like most of these other changes were relatively minor and you know, classic LTS cycle, now node 16 is end of life though.
-
-[02:55] We were using those for reactibot. So if you're using node 16. Stop it. Time to update. Yeah, Jacob, Sebastian, anything you want to chime in on there? Not a lot to discuss there.
-
-[03:06] **Jacob Paris:** Yeah, the CJS ESM incompatibilities have been largely a nightmare for my entire history of being a developer. To be honest, I don't know how new devs really Understand the stuff when they pick up.
-
-[03:21] It's like, you know, which import format do you use? You've got configurations that are automatically generated by different different packages, ESLint, Prettier, and sometimes they work and sometimes they don't. And I, I don't know how anyone makes sense of it. I am all on board for the ecosystem moving toward ESM here in the future, where maybe there's only one thing to do.
-
-[03:41] Or we can go with Bun's approach where everything just works together and it's up to library authors to sort things out between ourselves. I'm, I think that's okay as well.
-
-[03:51] **Carl Vitullo:** Yeah. On your note about people learning web development right now something that has bitten me a number of times is, like, Sindre Sorhus has, all of his packages now are ESM only.
-
-[04:04] And if you want CommonJS, you've got to decrement the major version. And that has bitten me so many times where something is inexplicably broken and I just need to, like, remember which are his packages and decrement them. So it's, yeah, hopefully, I have a lot of fingers crossed here that this is going to make that better, but, you know, we'll, we'll see what it does.
-
-[04:24] It does say, "this should simplify the customization of the Node.js module loading process as package authors can customize more of Node.js without relying on deprecated APIs such as `require.extensions`." So hopefully, we'll see.
-
-[04:37] Jacob, you want to take us off on our next link?
-
-## Remix v2, major release feature flagging
-
-- [Remix v2 pre-release](https://twitter.com/remix_run/status/1696525340640936190)
- - [Upgrade guide](https://remix.run/docs/en/main/start/v2)
- - [SemVer philosophy](https://remix.run/blog/future-flags)
-
-[04:38] **Jacob Paris:** Yeah. Yeah. So I guess the biggest thing from the Remix ecosystem at the moment there is that they just launched the V2.
-
-[04:45] It was quite an underwhelming release, every new feature that came out, everything has already been in place for weeks or months now via feature flag in the previous versions. So anyone who's already running that you know in, in production or in any of their apps they've already been able to opt in to the FeatureFlag, upgrade things and move on.
-
-[05:05] And, you know, if that didn't happen by now, I guess now's your chance to do that before you increment the major version. So in theory, that should make it a really smooth transition for pretty much everyone to upgrade. But then on the same note of ESM versus CJS issues, one new thing that happened is that, with Remix V2, it now has first class support for ESM, which just wasn't a thing before.
-
-[05:28] So now in your dev server, you can run full ESM applications. And, in that process of releasing the new version, they've also changed the default from CJS to ESM. So, um, there's been a lot of people kind of struggling with incompatibility issues because, you know, previously their new applications were being made in CommonJS.
-
-[05:49] And now they're, now they're being made to support ESM and some config files that they've been trying to copy over from other files or from examples that they've copied online old repositories. Now, they just need to be tweaked a little bit, and it's usually not that much work.
-
-[06:05] But there's small changes that need to be done, and you need to know what you're doing to do that. That said, Remix still supports CommonJS, but since they changed the default, there is now this friction and this, this transition period that people are having to go through.
-
-[06:18] **Carl Vitullo:** That's awesome though. Maybe I can stop decrementing my Sindre Sorhus modules.
-
-[06:23] **Jacob Paris:** (laughs) In general even if you're going all in on ESM, you should still be able to run CJS packages by running them through a Bundler beforehand. So they have to be Bundled rather than running natively but just because you're moving toward ESM doesn't mean you no longer have the capacity to use CommonJS modules.
-
-[06:42] It's just a little more work to get them running in the same runtime.
-
-[06:45] **Carl Vitullo:** Okay, very cool. Very nice. Yeah, I was reading a little bit about, you know, in there, in the V2 announcement post, they talked, way more than any, you know, new releases, new features they talked much more about their update, upgrade philosophy, which I thought was really interesting, like the, you know, vertical space associated with advertising what they were releasing versus advertising how they released it.
-
-[07:10] I thought it was an interesting choice, but I really loved the philosophy that they described. I just put a link and link to it in chat. But they, I pulled out a couple of quotes because I thought they were really clever and just useful, kind of useful to hear.
-
-[07:24] For anyone in the ecosystem who's going to be consuming libraries, and maybe also for library maintainers. But if they talked about Semver, "Semver gives us a way to communicate when breaking changes exist, we do not have a similar agreed upon process of how to introduce breaking changes in our frameworks and communicate them to application developers."
-
-[07:42] and they talked a lot about like the long running feature branch development for upgrades, which is a pain I have felt a number of times in my career. I have been that developer maintaining a feature branch for a month, two months, three months, constantly merging back in, rebasing off master, repairing merge conflicts, doing all that.
-
-[08:03] So seeing them talk about the efforts they've gone through to avoid those problems was like, Oh, this is really interesting. I didn't realize that it was like technically feasible to really do this.
-
-[08:16] So yeah, I thought that was really cool.
-
-[08:17] **Sebastien Lorber:** Yeah, I agree. But I have something that I don't really understand is there are some things that are really hard to ship with a future flag, you know, for example in Docusaurus, we upgraded recently to MDX two and it's. Completely different from MDX one on the inside, the AST is completely different, the packages were migrated to CommonJS to ESM and there are many things like that.
-
-[08:43] And I think like if you wanted to. To bring support to MDX2 with a future flag, you would have to vendor the MDX library and all, many dependencies to be able to support the two versions at the same time, and we would have to maintain two copies of the code somehow. I don't know, but For example, I was wondering if Remix version 2 will have support for server components as a future flag, or if it will come only with version 3 at the release time, because it looks like a complex thing to ship as a future flag somehow.
-
-[09:24] **Jacob Paris:** Yeah, yeah, it's, it's definitely challenging and you sort of have to pick and choose which features which features you go with. I'm not 100 percent sure when the RFCs for how Remix is going to handle Server Components are coming out. But, you know, that's something Ryan Florence is working on at the moment. So we'll have a little more information when that comes.
-
-[09:45] But for example, yeah the... You know, updating big major dependencies, like you couldn't feature flag having support for example, React 17 versus React 18 at the same time. So that was one of the big things that Remix did update in the v2.
-
-[10:04] So you can run v1 with all the feature flags enabled on React 17, but at the time you update to v2 officially, it does drop support for versions of React prior to 2018. And it was the same with the, with the CJS ESM thing. That's just, it's not practical to try and, you know, run those side by side in, in everything.
-
-[10:23] So the official first class ESM support, was also sort of a, an add on that came in with the with the new version rather than trying to feature plague that. So I definitely see a lot of value in them as a tool where, you know, as long as you can choose not to break things for your developers, and to give them an incremental path to adoption, you should do that.
-
-[10:47] But you know, as you've said, sometimes with bigger dependencies, sometimes it just can't be done. Yeah, it makes sense. I guess, I guess another, another thing I'm so happy that Remix is going down this road is because developers are just terrified of major version releases. Um, like if you look what happened with Angular, moving from Angular 1 to Angular 2, you know, with React going from React class components to React hooks.
-
-[11:11] You've got Vue 2 to Vue 3, and now, like, all the dialogue I'm hearing with Remix, you know, despite how loud they are taking up the entire announcement post to talk about it. The way this major version release process is working, you're still getting people asking, "well, is this stable yet? should I wait a little later? I don't want to start a project now if I'm going to have to refactor and change everything later."
-
-[11:35] There's just such this ingrained culture where major version updates are, are, are terrifying and not something you want to put a project through if you don't have to. People would rather wait and delay things than Adopting and having to go through that transition period.
-
-[11:50] So if, if what Remix is doing here can really catch on and start to make this a little less painful for upgrades, then yeah, I, I am all for that.
-
-[11:58] **Carl Vitullo:** Yeah, agreed. Definitely true that there's a lot of fear around major version upgrades. And, you know, I, I maybe actually, maybe it's less fear and more just like trauma because so many of the you know, it's not unbased.
-
-[12:11] It's not like, you know, you've heard stories to keep you up at night. It's just like so many people have had lived experiences of, "major version upgrades are super painful." So I hopefully this is a trend. I love this direction. I have to imagine that feature flagging things is this aggressively in a framework is, technically challenging, technically complicating. So yeah, hopefully we'll see it more. Hopefully it's not so complicating that it's difficult for other people to copy, because I love this. I hope this becomes a trend.
-
-[12:42] Sebastien, you want to take us off on our next link?
-
-## Docusaurus v3.0
-
-- [Docusaurus v3 beta](https://github.com/facebook/docusaurus/discussions/9312)
- - [Upgrading frontend dependencies with confidence](https://docusaurus.io/blog/upgrading-frontend-dependencies-with-confidence-using-visual-regression-testing)
-
-[12:45] **Sebastien Lorber:** Yeah, so I thought that as we were speaking about being afraid of upgrading dependencies, actually I posted an article last week about the subject. And it's related to the Docusaurus version 3. So I was working for, on the version three for a very long time. Now it's a, it's an upgrade of the infrastructure, including React 18 and, and MDX 2.
-
-[13:11] And, this changes, not, MDX two can have a lot of, weird side effects. For example, you add. MDX content and it rendered nicely previously. And now if you, if you upgrade to version two it eventually fails to compile now. So you have to reflect all the content of it. And also it can render differently, even if it's compiled.
-
-[13:33] So. you are not very confident that actually the, the upgrade is safe unless you took, you take a look at all the pages of your documentation or your blog or whatever it is and, take a look at all of them and be sure that it renders exactly like before. So, um, what I did for Docusaurus and this is now, um, A solution that, we recommend to our users is to adopt a workflow of visual regression testing.
-
-[14:03] So, the idea is that you take a screenshot of all the pages of your documentation website. And, you do this on the main branch and on the pull request branch, and then you use a tool that can be, something self hosted or external, and this tool permits you to tell you which are the differences between your upgrade branch and your, and the main branch.
-
-[14:28] So, if you have visual regressions that you don't expect, the tool is able to report it as a GitHub commit status. And so, I wrote a blog post about the setup that I used. It's based on GitHub Actions, Playwright, and Argos, which is an external tool to handle the screenshots. And I thought it was quite interesting.
-
-[14:50] I used it in the context of Docusaurus upgrades. For example, while upgrading the React Native website last week, we... catched a few bugs, in the process thanks to this workflow. And I think it can be easily, adapted to work on other sites. What I did to get the, all the pages of the site is to read the sit map point, the XML file, and iterate on, on the list of path.
-
-[15:18] So as long as you're able to take screenshots and are able to get a list of page of your site I think you can try to adopt this workflow and if you want to do a dependency upgrade, then you can do and compare and see if there is a visual difference being reported by the tool that you use.
-
-[15:37] **Carl Vitullo:** Yeah, very nice.
-
-[15:38] I've heard about this kind of visual regression testing. I feel like I've heard about it four or five times over my career. And every single time it hasn't really worked out. Or, you know, I've tried it and it, you know, the the experience doesn't quite work out. But I'm reading about I'm reading your blog post.
-
-[15:57] And I love the idea of I feel like maybe the technology now has developed to the point where it will actually work now, because like Playwright, I've heard only phenomenal things about. Everyone I've talked to who has used it has said that like, yes, this is great. This is what integration and end-to-end testing should be.
-
-[16:16] And GitHub Actions is finally like a great task runner for services like that. whereas, you know, I remember trying to set up this sort of tool in like Jenkins, like eight years ago, and it was like, Oh, I don't, this doesn't work. So yeah, this seems really cool.
-
-[16:34] Cool. Well,
-
-[16:35] I can take us on to our next one then we are going to get to Bun 1. 0, but I want to, I'll say we're going to save that for the end.
-
-## Astro 3.0
-
-- [Astro 3.0](https://astro.build/blog/astro-3/)
-
-[16:43] **Carl Vitullo:** So right now, I want to talk about Astro 3.0, I actually have not yet used Astro very, very extensively, but I have heard only really great things about it and it's a, it's definitely something I want to check out. I think I've heard about it being like very good for like personal sites, portfolios, like relatively smaller marketing sites.
-
-[17:06] So, you know, as I'm looking at making a personal, professional blog or revamping the Reactiflux website. Very interested to give that a shot, give it a real chance of and see how it works out. But yeah, Astro 3.0, new, new release. I don't know. Have either of you used Astro at all, very much?
-
-[17:25] **Sebastien Lorber:** no. But I think it's interesting because, you know, the view transitions make it more, looking like, single page applications. And now that they are able to persist the state between, page transitions, that's becoming a really interesting solution. What I'm afraid, for example, for now, is that if you use third party widgets like intercom, chat, and things like that, If you navigate from one page to another, you would like this kind of widget to persist the state because it's really annoying, you know, to have the chat that resets itself.
-
-[18:00] You are in the middle of a conversation with the support team or something and you click on the link and then, everything is lost. So if they can solve this program, I think it's it's really great for us too. And for multi page applications in general.
-
-[18:13] **Carl Vitullo:** Nice. Sadly, I can't speak very, much more deeply than I already have on this, but yeah, definitely excited to give it a shot. And I love when new versions come out before I have fully learned them. So then I only have to learn one thing instead of two.
-
-[18:28] Jacob, you want to take us on to our next one?
-
-## Josh Comeau's Making Sense of React Server Components
-
-- [Making Sense of React Server Components](https://www.joshwcomeau.com/react/server-components/)
-
-[18:29] **Jacob Paris:** Yeah, sure. So, Josh Comeau put out this great article about, React Server Components. So I, I've kind of been sleeping on React Server Components for a long time, because They've always really confused me.
-
-[18:45] So when the information was first coming out, there was, there were so many different ideas about how these are going to work. And then you start seeing examples and some of the examples are coming from the React team and some of them are coming from the Vercel team and then people from React move over to Vercel and then you get you know, examples from the from the code bases of either moving back and forth.
-
-[19:06] It was just, it was always so unclear, which, you know, in any example you see, which parts were React and which parts were Next. And so, so for me as a, as a Remix developer, I'm wondering, you know, which parts are going to stay in React that then Remix can build on top of and which parts are belonging to Next that, you know, Remix may either have to, may either have to clone or continue to build on top of.
-
-[19:32] For a long time, I just, you know, I kept seeing these server components, and I just really didn't know much about what they were. which is why, yeah really glad Josh has put out this article, because reading through, everything makes quite a lot more sense now. The server components are basically a new model here, where every React component we've dealt with in the past has now been renamed to a React Client component, and these React Server Components render only on the server, and they only render once, and it's a Almost like server side rendering, but instead of executing once and then being all the HTML to the browser is they can render and then send all the information React needs to hydrate a React component to the browser in fact, in practicality, what this means is we can have async data fetching happen right in our components, which is fantastic, And any time you include a client component in there, everything that component imports just works exactly like, components we've had before.
-
-[20:39] It unlocks a lot of abilities that we primarily couldn't do before in terms of composition, for example, in say, in Remix and in Next.JS before this, you can have a, a loader or your get server side props that fetches data, and then it passes it to a server side rendered components.
-
-[20:58] But there was never any way to do that at the component level that always had to do, had to happen at the route level where you would have a, you know, each route would become an end point and you can. You know, you generate your components based on the data that endpoint returns. So there are the server components, um, you could almost model it, you're getting, you know, individual little endpoints for every single, every single component you have, and they can, they can be composed together just in the same way we're already currently using, React, which I, which I think is fantastic.
-
-[21:33] There are some issues with it still, that, that I don't I'm still not 100 percent sure how they solve or how they're going to solve, for example, data serialization. If you're sending data from the server to the client, say you have a date or a map or a set, the client is going to receive that as just just a string or, you know, a stringified array.
-
-[21:55] And... When you're dealing with a very visible network boundary, like you've got a loader and a react components or you've got your server side props and then your react bit it's pretty easy to see where that boundary is, but now with the server components, you can create that network boundary simply by passing data to a prop in a client component, and I just think that's really, really subtle at the moment, so I'm not 100 percent for you know, if that's actually going to cause problems in practicality, you go inside that component, and now your types are just a little different than they were.
-
-[22:30] In the server components it seems like that's going to be space for people to get confused.
-
-[22:36] But all in all the components that these enable are, I think, I think, fantastic. Like, we're looking at, you can imagine a component that render, or that syntax highlights code for you. So you just pack text and it's got all the syntax highlighting built in without needing to ship megabytes upon megabytes of, libraries to the browser to make it understand every programming language it could support.
-
-[22:59] you could imagine a, say an image component that automatically. You know, pre process the image based on its, you know, widths and heights and any resolutions you set. Next already has a sort of proprietary version of that, but it only works on Vercel hardware. Because they are, if they're in charge of the deploy process, they can then transform your code to make that work.
-
-[23:22] But this will now enable that to work on any hardware that supports React Server Components. So yeah, I'm super excited about it. The ability to do that and then you can publish these full stack components in libraries as well. And then users can just import them and things will work full stack, which is you know, it's just, it's, it's, it's unlocking new abilities that we just couldn't do before.
-
-[23:45] **Carl Vitullo:** Yeah, unlocking new abilities really does seem like the big thing here. I feel like I, I too have kind of skimmed past this, despite talking about it with some frequency on this event. But it just, I, I can sense that it's going to be a very wide and deep subject, and I just don't feel like... Like, okay, I can write a toy project and get a little bit of experience of what it's like using it.
-
-[24:08] But, you know, that won't really tell me everything I need to know about what are the performance characteristics for like 99th percentile users or, you know, there's just like such a long tail of things to learn about how it will affect development and performance and user experience and all of those things.
-
-[24:28] And so I feel like I'm going to keep saying, "I don't think I really understand this" for a very long time because the implications are going to take a long time to really shake out.
-
-[24:38] **Jacob Paris:** Yeah, and there's there's some new sort of, foot guns coming in that people will have to watch out for like, for example, you know, it's super common.
-
-[24:45] You have an array of data and you, you, you, you map through it. And on each iteration of the map, you're, you're creating a component, but they have a list mapping through and creating a list item in each one. The, the data you pass to that list is going to be. Individually serialized for every item in that list, if you happen to pass any large document React Server Components are not going to de duplicate that for you.
-
-[25:10] So you, you can end up with tons and tons of data. Ryan Florence was saying there was something similar in in a Shopify Hydrogen application that functioned in, in largely the same way. And yeah, it's, we're, we're introducing a whole new set of you know, things that people are going to have to watch out for if they want to have performant code.
-
-[25:30] I'm really hoping that when this kind of hits mainstream, there's either going to be enough messaging or maybe lint rules or something, you know, maybe some just physical boundaries put into the framework to stop people from making mistakes like this. Because it just, at the moment, it seems really, really easy to make a lot of mistakes.
-
-[25:49] **Sebastien Lorber:** Yeah, I wanted to mention another use case that you maybe didn't think of is you, you know, maybe you used Gatsby before with the GraphQL layer to inject data in, in pages, I think actually, um, React Server Components could be a very good alternative to that, and this is what I'd like to explore in Docusaurus actually, because, you know, the server components do not really need to run on the server.
-
-[26:13] You can actually run them at build time, as part of your build process, so a static side generator like Docusaurus is able to also use server components at build time. And this can give the ability to have a very flexible data layer. So instead of using static GraphQL queries in pages and things like that, you would be able to actually use Node. js code inside Interleaved with the client side React code and be able to inject the right data at the right place without actually the need for creating a complex GraphQL query and things like that. So somehow From my Docusaurus perspective, what I just have to do is to expose the data structure and let the user pick the right, data structure from it from right of a component and inject it in a subcomponents.
-
-[27:08] So, you don't need actually to have something more advanced. You can just use a JavaScript to get the right data at the right place. And you can do it both at the runtime or at build time.
-
-[27:21] **Jacob Paris:** Okay, I, I like that a lot actually. So, so you'd be able to have all of your, um, all of the components in Docusaurus that you're using.
-
-[27:30] Each component can have its own GraphQL queries to fetch the data it needs to do. And then you're sort of... Flattening all of that at a compile time, they just fetch the data, it turns into static content.
-
-[27:42] **Sebastien Lorber:** Actually, the goal is, the goal is to actually not use GraphQL because this is what Gatsby does, and I think the community didn't really like it. it was a bit too complex. So, um, and one of the shortcomings of Docusaurus is that we are, we use a plugin architecture. So we have a blog plugin and a docs plugin, and they don't see each other. And the problem is that, for example, if you want To display the free, the last three blog posts on your docs. It's impossible because the docs doesn't have access to the blog. So, using server components make it possible for you to override, the docs components and from there read the data structure provided by another plugin and somehow this provides a lot of flexibility thanks to being able to do this, some part of the code, running in the Node. js side.
-
-[28:35] **Jacob Paris:** Oh, cool. Cool. Yeah. I like that a lot. That's that is super cool.
-
-[28:39] **Sebastien Lorber:** Yeah. We'll see if it works out. I don't know yet, but I think it will.
-
-[28:45] **Carl Vitullo:** Nice. Interesting. Yeah. The data fetching side and the actual experience of developing and using that is like what I most specifically would like to check out. And I just, I, I don't have an app that I'm working on right now that has those needs, so I, I don't really know how to get that kind of experience that I'm really hoping, hoping to learn.
-
-[29:04] But yeah, on the, on the subject of foot guns, there's a, there's a quote that I love from the guy who made C++, and it's about C and C++, but I think it applies here a little bit, you know, like these server components are like really powerful new tools, but the quote is like.
-
-[29:21] C++ has fewer foot guns, but when you hit one, you blow your whole leg off. And that feels a little bit like where we're at. It's like, you know, we have this powerful new tool and we're still figuring out what, you know, what, what's just like a little injury and what's like a major wound. So, you know, we're gonna, we're gonna, we're gonna, we'll take some time to settle.
-
-[29:42] **Jacob Paris:** Yeah, I think Ryan Florence had a similar quote talking about the server components. He said, you know, this is a very sharp knife, and I like that, but it doesn't have a handle. I would really like a handle.
-
-[29:52] **Carl Vitullo:** Haha. That's actually, I love that metaphor. That's really good. Because that's, yeah that, I feel like that touches on a lot of the complaints that I've heard about this, server components rollout over the last couple of months. I hadn't seen that quote. That's a really good one.
-
-[30:05] Nice. Okay. Well, I'll, I'll move us on to our next subject.
-
-## Bun 1.0
-
-- [Bun 1.0](https://bun.sh/blog/bun-v1.0)
- - [My Thoughts on Bun](https://adventures.nodeland.dev/archive/my-thoughts-on-bun/)
- - [Announcing Biome](https://biomejs.dev/blog/annoucing-biome)
-
-[30:08] **Carl Vitullo:** Um, Bun 1. 0 is officially released. There's so much to talk about there, I think. Bun is so many things, but I don't even know where to start.
-
-[30:21] it's an all in one toolkit they're describing themselves as. there's a huge focus on performance, which is really interesting. They have, I, my favorite performance stats that they quote is they're 40 percent faster at running like 200 and something unit tests than Jest is at printing its own version number. So not even running tests, just like startup and print version number exit. Bun runs all the tests 40 percent faster than that. Um, so hilarious stat.
-
-[30:52] They are claiming to replace a huge list of tools. I'm just going to read this off node, npx, dotenv, although now node has gotten rid of dotenv as well, so that's, there's one bullet point off the marketing that the marketing list they also replaced nodemon, the WS package for web sockets, node fetch, cause fetch is built in, TSC cause it's a compiler Babel, TS node, TSX, esbuild, webpack, parcel, rollup. NPM, Yarn, PMPM, Lerna, Jest, Vitest. So like that's, that's quite a claim.
-
-[31:29] it reminds me a lot of the original promise and claims of Rome as a project, which is unfortunately well, Rome is no longer a thing, now Biome is a, an open source fork. But, so I'm keeping an eye on that too. But. Bun is claiming to be a drop in replacement for Node, where any existing Node application just works in Bun.
-
-[31:53] I know that they also have introduced a number of non standard behaviors. One of my favorites is that they allow you to read input from the console as an iterable, so you can do like `for (input in console)`, and then within the for loop, like boom, there's your REPL, three lines of code. So like, there's a lot of really interesting things that are phenomenal developer conveniences for some specific use cases, but it's non standard.
-
-[32:21] So if you write Bun code. You can't then port it, you know, just run it in a different runtime because that's non standard. It's not specified anywhere. So that seems a little fragmenting to me, but also a lot of these, a lot of the non standard improvements seem really cool. So maybe they'll get standardized. Maybe it'll be a CoffeeScript kind of situation again. Yeah, I, let me, let me hand it back to the floor. Anyone else have thoughts on Bun.
-
-[32:45] **Jacob Paris:** Yeah, yeah, I'm always a little torn on when it comes to non standard features like this. I think it's super cool that Bun can do, that Bun can do all of that.
-
-[32:55] They've also got their ESM and CJS interop, so you can have CommonJS imports, with the require syntax, and ESM imports with the import syntax, all in the same file. And you know that that's fantastic for developers who no longer need to worry about this. But then you look at a larger ecosystem, yeah, any, any libraries built on this they're only going to work with Bun.
-
-[33:17] They won't work on Node and everything else. And that's, that's, it's been a quite a contentious point in the, sort of library ecosystem. Like, it's, you know, it's nice to have these for developers, but is this going to really fragment the ecosystem? Are we going to end up with a bunch of Bun only libraries?
-
-[33:35] **Carl Vitullo:** Yeah, sure. I, I also, I, I read a a, a blog post from one of the node core team members. Just his thoughts on Bun. I thought it was really interesting. This was just sort of a, it was a very grounded take in comparing node versus Bun, and like it has, why is Bun faster than Node.js? And the first item on it is Node. js has no budget and a tiny team maintains NPM.
-
-[33:59] So it's like, they're just talking about very much about the practicalities, not just the code reasons. And yeah, I mean, like, so Buns, Bun 1. 0 announces it as like a drop in replacement for Node. js. This you know, other blog post from a core, a Node core member says Bun does not currently support Fastify.
-
-[34:20] Which is a reasonably popular competitor to express. So like, yeah, I mean, if you're not supporting like one of the top five HTTP servers, then like advertising it as a drop in replacement seems maybe a little bit overstating it. so I don't know, there's still, still a little bit of, a little bit more improvements that I'm going to be keeping an eye on.
-
-[34:40] But honestly, one of the most exciting things for me about Bun is, or rather, something about Bund that fixes a problem I've heard about for so many years now at this point is Node. js slow startup time. You know, like exactly, I mentioned before that it talks about running tests faster than Jest prints its own version.
-
-[35:01] A lot of that is, it's runtime overhead. You know, it's like the, because of how modules are parsed and, you know, executed. there's a very long startup time. So seeing that improve substantially, I think is going to be, you know, maybe that's not going to be like world changing, but I think it will be a pretty significant difference for people who are authoring CLI tools with JavaScript.
-
-[35:25] So, you know, hopefully, I'm excited to see what happens with that. Now that somebody has thrown on the gauntlet of like, this is how fast it can be. I'm interested to see where it goes.
-
-[35:34] **Jacob Paris:** Yeah, yeah, I'm super excited about that as well, and especially since, um, you know, there's some comments in here saying, you know, Node isn't going away, Node isn't going away everywhere, maybe, maybe that's just the key to this, Node isn't going away, library authors are still going to have to support Node and maybe that's why the ecosystem won't fragment, developers can move on to Bun and Node Library authors are still going to have to produce compatible code in either ESM or CJS, just because some developers.
-
-[36:05] The big companies and so on are still going to be using node for at least the foreseeable future. Maybe that's the best of both worlds.
-
-[36:13] **Sebastien Lorber:** And I think, if you want to try it now, maybe the good idea is to start by, using it in consumer code. So not, in, libraries, but just, for example, if you want you locally to run tests. Instead of using Node. js plus Jest, you can, you can try Bun, for example. There's not a lot of risk doing so. Eventually, you can ship it to your GitHub Actions or something like that. I don't know if it runs in, in GitHub Actions, but I assume it does. But yeah, yeah, maybe shipping it to production is a bit risky today, but, for example, running, a Bun install or something like that is not super risky.
-
-[36:52] So maybe we should start by doing this and see how stable it is. And yeah, I don't remember what I wanted to say. So.
-
-[37:00] **Carl Vitullo:** That's okay. Sometimes we trail off.
-
-[37:03] **Jacob Paris:** Maybe part of the issue here when it comes to, you know, Can we use Bun in production is just, since Bun is so many different things what does it actually mean to use it in production?
-
-[37:13] I mean, yeah, you can use it for your tests, you can use it as a package manager, you can use it as a, as a host to actually run your app as a server. Um, maybe that one is the most risky one that we shouldn't be doing, but, you know, if, if it's just installs by so much, um, maybe, maybe that's okay. Maybe that can be the entry point here where we, where we start using this.
-
-[37:35] **Sebastien Lorber:** The problem is that there is not a good Windows support, so if you start using Bun to do this kind of things, the thing is if you have someone on Windows in your team, then it becomes a problem for them because, you know, if you use Bun and it works for you, and they use YARN and it doesn't work because the log file is not the same, then this becomes somehow a big mess.
-
-[38:00] ' cause you don't have the same dependencies. So, I don't know, on, on my side. I think for example, as Docusaurus is a static side generator, I'm not afraid, for example, to recommend to use Bun to eventually, build the site with, with Bun. Because once it's built in the CI you just have static files. So it's not really risky once you have succeeded, building the site. But, yeah, for several run time, I, I would wait a bit before deploying that to, to any cloud.
-
-[38:30] **Carl Vitullo:** Yeah, yeah. One other thing I wanted to bring into the conversation is Bun is a VC funded company, which I was just talking about this last night a little bit with some other React ecosystem buddies and it was brought up, you know, like the runtime companies have not historically done very well. You know, you, you, you think about who maintains JavaScript runtimes. And it's like, you know, five years ago, that was Google, Apple and Microsoft. And now it's just Google and Apple. So trying to start a brand new startup on the basis of, here's a runtime, it's a challenge.
-
-[39:09] as far as I understand, Bunn is coming at it the same way Vercel is as a hosting platform. They're saying, here's our cloud offering, use it. But I, I'm not sure that that is a strong enough differentiator because like, what's it's an open source project. Like what's the stop every other hosting provider from using that, you know, just offering it as a runtime.
-
-[39:29] So I don't know. I don't know exactly what that means. Um, I think that Bun as a runtime is really interesting. I'm not sure that Bun as a cloud platform distinct from Vercel, AWS, GCP, all of those. But yeah, we'll see. We'll see how that all shakes out. if nothing else, we've got a really cool project putting pressure on everyone to improve.
-
-[39:55] **Jacob Paris:** Yeah, it's, it's sort of a catch 22 situation here. Like either, either all the web hosts as they exist right now, they start to support Bun, and then you can use Bun in all your applications everywhere and Bun goes popular, and if that happens, now there's all this competition for Bun as a hosting platform or, or it just doesn't happen.
-
-[40:15] You, your Bun app can't actually run anywhere, and then not enough people are using Bun to justify having it as a, as its own hosting platform. So, I'm a little, little iffy on the business model there, but I, I often, in these situations, I just assume that the people who have, Given, you know, sort of devoted their livelihoods to building these companies no more than I do after reading a bunch of tweets and articles about it.
-
-[40:41] **Carl Vitullo:** At the very least they've thought about it a lot more than I have. So, well, interested to see what they come up with. And, man, what an oversight, I meant to talk about Deno as well I don't want to, we're trying to wrap it up so I'm not going to bring it up too much, but between like Bun, Deno, Biome, there's a lot of really interesting like all-in-one type, runtimes and packages and all that kind of stuff, really interesting.
-
-[41:07] But yeah Jacob, you want to take us on to our, our next link?
-
-## Next.js Forms and Mututations
-
-- [Next.js App Router - Forms and Mutations docs](https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations)
-
-[41:10] **Jacob Paris:** Yeah, yeah. So the next one for me is, um, sort of the announcement of the next, you know, the next stage of the next JS app router with their forms and mutations. So they just pushed out all the new, all the new docs on that and, Lee put out this excellent video running through you know, sort of the concepts of how these, how these server actions actually work.
-
-[41:33] Which has been again, similar to Josh's article from before. I think it answers a lot of questions that people had. So, yeah, it starts off covering you know, the, the traditional way that we're submitting forms in a React app. Where you, you, you have a form, and then in your on submit callback, you prevent default to stop it from automatically reloading the page.
-
-[41:55] You send your data to an API route, and then whatever data comes back, you have to deal with yourself in that callback. And, you know, whether that's writing it to state or performing some other actions, and, you know, for a long time, if you're working with a separate backend server, that would mean going to another repository.
-
-[42:13] You you need to build a new endpoint there. You, if you're dealing with, say, TypeScript at all, you don't have to manage that in two separate repositories, and then you end up with two separate repositories. Pull requests and, those have to be merged and deployed all at the same time, which makes testing a nightmare.
-
-[42:30] You know, I'm sort of glad we moved away that with Next.Js. You just define the API routes in your react app, in another file and the on submit callback use fetch to send data to that. So that, that's kind of the state of where everything was. was right now.
-
-[42:45] I, I do think Remix took that a little step further. So rather than having the API route in a separate file, it then, it moves into the same file. It's just an action in the same file. And rather than having to write this whole on submit thing Remix's form components will do that, all of that for you, which I think is, you know, one step up from where, where Next was.
-
-[43:03] But now, like Next has taken a huge step forward with these server actions. We have this whole progression, I guess, that the, that the ecosystem has gone through where it's less and less code every single time so rather than having, you know, two repositories, now we're down to one, and then now it's all into the same file, and we're, we're sort of co locating all the code together, so you get this really concentrated sort of, sort of concerns here, and the React server actions are the next step in this process.
-
-[43:33] Rather than having all your data fetching being co located to a particular route is that now we can move them into a single component for the form element that has the traditionally would have an action that links to a particular endpoint, you can just pass a function to it now with the next server actions and Next will do all the work of triggering that like a remote procedure call returning the data to a form action and form data hooks to deal with the, to deal with the results of it.
-
-[44:02] It's, it's really, it's the other half of the client components that I was talking about earlier for, for data fetching. now finally for the first time in next existence, they have a proper data mutation story. They're acknowledging that they're, you know, in an application you're going to need to, you know, modify data on the database, you're going to need to save things and deal with the results of that.
-
-[44:26] So rather than using something like, say, React Query or tRPC, which are sort of, you know, historical solutions there, is that these server actions are really, really good. Yeah, so you declare the functions on your server, you mark them as "use server", and... the browser will just call them automatically.
-
-[44:43] They still, they automatically degrade to browser form submissions if you're trying to submit them without JavaScript being enabled. so you get the full progressive enhancement. Yeah, I'm, I'm, I'm a big fan of this. It's it's, it's been super, super cool.
-
-[44:58] **Carl Vitullo:** Definitely reminds me a lot of how Remix implemented the same thing. Although I guess Remix does it as an export from the file, whereas this is just a function within the component or as a separate file, but yeah, one thing that's catching my eye in the, in these docs, the, I do not like the use server, use client directives.
-
-[45:20] I know that like the idea of introducing more directives, you know, so like directives came from the ES6 transition, use strict. So that's what they're basing these off, you know, like you opt into a new mode for the runtime. And, you know, I, I followed like TC39 JavaScript standard discussions loosely through my career.
-
-[45:43] And I've seen a fair number of new directives suggested, brought up by people saying like, Hey, like, it would be really great if we could have this new mode for things to happen in and the message that has been so consistently said from the people who maintain the spec and said, like, "no, we, we are never doing another directive. That was a one time thing because we needed to break, you know, we needed to have a seam where we introduce new behavior and it was not possible to do in any other way without introducing breaking changes."
-
-[46:14] And so to see it go from one ever to, oh, here's two new ones. I don't, I don't, I don't like it. I don't know. It seems like a really big break from the norms that have been set by the people who introduced that pattern. and, and, and. here it is not the first, you know, statement in a file, but the first statement in a function. So it's a new behavior on something that had been, you know, introduced 10 years ago as a, you know, a necessary evil.
-
-[46:46] And I know it gets stripped out. I know that it's just kind of to inform the compiler or whatever, but I don't know. Feels weird to me. I don't like it as much as the way Remix just does an export. That seems very simple to me and I like it. I guess that's what I'm saying.
-
-[47:02] **Jacob Paris:** Yeah, yeah. We certainly need some way of communicating to the, um, you know, to the runtime, what sort of mode it should be in while it's processing this function.
-
-[47:11] Remix handles that with just, just the naming convention. So there's certain functions that behave differently. You got your actions, your loaders, meta, headers, functions, and they're all just exported from the route. Whereas with Next, you're now using these directives to mark different behavior in, in the functions.
-
-[47:29] I don't know what the better way to do that would be. A lot of that kind of is up, above my head. one, one that I don't like is that since you're declaring these... You know, if you declare these server actions in line, anything you close over in there. So it, it looks like if it were a normal function, that you can access variables from the scope above it.
-
-[47:49] Um, so you define a variable and then you include it. And then now that's going to be included. Um, like it's, it's really confusing how that happens with the server bundle. If you have a client component in there, you could very easily end up introducing a bunch of, say private keys. If it is So you have a, like an API key in the upper scope and you're referencing something from, from that class or object within your action, because it looks like you can, that can really easily end up in the, in, in the client. yeah, it's, it's, it's, it's another foot gun where we're having more and more foot guns to worry about with all of this.
-
-[48:25] **Carl Vitullo:** So Sebastian, you want to take us off for our next link?
-
-[48:28] **Sebastien Lorber:** Actually, it's only my second link, I think. And yeah, it's a big one, so I should have started by, by this one, I think. Haha.
-
-[48:37] **Carl Vitullo:** A lot of news this month.
-
-[48:38] **Sebastien Lorber:** Yeah, exactly.
-
-## Expo API Routes
-
-- [Expo Router RFC - API Routes](https://blog.expo.dev/rfc-api-routes-cce5a3b9f25d)
-
-[48:40] **Sebastien Lorber:** Even this summer was quite busy, I think. So it's about, Expo API routes, RFC. So I think it's very interesting because, I think it's the first time that Expo is, going, on the server side. So this is, somehow not a very complicated feature. It's just about deploying API routes creating a convention to deploy API routes to a server, or creating a server runtime that you get, can deploy yourself or eventually on, on hosts like Vercel, Netlify, and maybe soon, the Expo APIs.
-
-[49:16] But what is very interesting, I think is because, you know, it's the very first step toward becoming a full stack framework where you can actually have a universal support for, the web and mobile using server side rendering on the web, so no compromise compared to the other frameworks. And also to support React Server Components in a cross platform way.
-
-[49:41] So you will be able to use the exact same code to render UI on mobile and on the web. And somehow, I think this is very exciting because, you know, currently if you want to build a web application, you don't think you will use Expo because the support of Expo web works, but it's not good enough to be able to bet on Expo just to ship a mobile app.
-
-[50:05] Maybe in the future, if they implement this well, you could even. Decide to use Expo, even if you don't target mobile, I think. So this, this could be very exciting to to have Expo being, becoming a real competitor to other frameworks on the web.
-
-[50:23] **Carl Vitullo:** Yeah. Oh, that's interesting, this builds so well off what we were just talking about with the server actions. So
-
-[50:28] that works out really great, great flow into a great transition. Yeah, oh, that's really interesting. So I know that Expo has been broadly moving towards not being as tightly coupled to React Native, but I didn't realize that they were. Even interested in doing some kind of server route like this.
-
-[50:50] This is, yeah, this is really cool. This definitely unlocks a lot of possibilities.
-
-[50:55] **Jacob Paris:** Yeah, I'm, I, I'm super like, I'm all for it. Any time where we can take the separate backends and frontends and move them into a single repository so that they can share you know, share types and you can develop, you know, push code a single, a single pull request to implement entire features all at once.
-
-[51:13] I, I'm all for that. So. It's, it seems here that Expo is now kind of going the way of Next or Remix, where you, where you can kind of, it just becomes a full stack framework all on its own. And as far as I know, up until now, that, that just wasn't possible in the React Native ecosystem. You always needed a separate backend server somewhere in order to handle that.
-
-[51:33] **Carl Vitullo:** Yeah, I'm definitely a little unsure because like Next and Remix, I understand, you know, you put it on a server and boom, there's your server. I don't really know what the deployment story for Expo is going to look like for these server actions. I'm scanning the blog post here, trying to find that, not seeing it immediately.
-
-[51:55] **Sebastien Lorber:** It's not server actions, they are not really, shipping, something advanced. So for now, it's just API routes like you have in Next. js too. So you just create an API endpoint that you can call on mobile. And I think the, the idea that we, they want to implement is first to enable you to self host the backend.
-
-[52:16] And then eventually the idea is that you just push to Expo cloud and then have the thing being served from their cloud like like if it was their server or Netlify so and you know for example they could be systems like we don't deploy we don't push the mobile update until the backend is deployed or things like that you have to synchronize things because uh mobile is long lived session, so you have to make sure that, the, the API that you deploy is compatible with the mobile side. And I think Explore has an opportunity to build something, that handles that well.
-
-[52:54] Vercel actually, built something similar, that they called Skew Protections. So, somehow if you, you know, if you have a trading application and you deploy a new version, The, the traders that use the, the former application still they don't want to refresh the browser to, to be able to keep using the app.
-
-[53:14] They want to just keep their long running session and keep interacting with the API. So it's important that the API doesn't break when you deploy new software and, for mobile, it's even more important. And I think, Expo Cloud has a card to play there.
-
-[53:27] **Carl Vitullo:** Yeah, interesting. Yeah, my first thought was like, Oh, another cloud provider, but that's actually interesting because there are genuinely different constraints for mobile versus web, because that's honestly one of the biggest differences I've noticed in my career between it is the experience of shipping new changes.
-
-[53:47] Like on a website, you know, I, I push out, I do CICD, boom, done, it's live unless there's a cache, unless I have set up a cache with, you know, a TTL that's long enough to introduce problems for that. I know that as soon as I hit that deploy button, my code is running for everyone. Maybe the service I'm working with has like a red green deployment. And so there's a gradual rollout where they're both going to be happening.
-
-[54:12] But like at the end of that, the code that everyone is hitting is. The code that was just deployed, whereas on mobile, you don't control that at all. People update the app whenever they want to, and maybe they don't for two years.
-
-[54:24] So that actually is really interesting. If I could co locate app specific API calls, have them deployed through some kind of managed service, and then. Had that cloud provider do the version management for me to make sure that they, you know, APIs from this version of the app are served by a compatible route handler.
-
-[54:50] Like, that's actually really interesting. That's pretty slick. That's pretty cool. So I think that they're introducing a new package, Expo Server, which you then need to deploy yourself. It looks like right now. I think that's what you were just saying. So, yeah, that's really interesting though.
-
-[55:03] Okay, should we move on to lightning round? All right.
-
-## ⚡️ React Native on Apple Vision Pro
-
-- [React-Native running natively on Apple Vision Pro simulator demo](https://twitter.com/o_kwasniewski/status/1701626162521190688)
-
-[55:06] **Carl Vitullo:** I guess first lightning round, I'll pull up, I'll just keep the React Native theme going React Native running natively on Apple Vision Pro simulator demo. That's cool. I don't have much else to say about that, but you know, AR VR with React in a 3d environment is like, that's pretty cool.
-
-[55:25] I like it. Jacob, you got a lightning round you like?
-
-## ⚡️ Are Big Projects Ditching TypeScript? (no)
-
-- [Are Big Projects Ditching TypeScript?](https://www.totaltypescript.com/are-big-projects-ditching-typescript)
-
-[55:28] **Jacob Paris:** Yeah, yeah, we got this once. "Are Big Projects Ditching TypeScript?" was, written up by Matt Pocock after DHH did his little let's remove all the types from Turbo thing. the consensus is no, most of them aren't. Svelte has switched to JSDoc, um, a few others in that line but no, TypeScript is here to stay.
-
-[55:47] **Carl Vitullo:** Yeah, ugh, I'm glad to see that was the outcome. DHH has, I've soured on him a little bit. Sorry, this is lightning round. We're not doing a full discussion.
-
-## ⚡️ Rust Server Components
-
-- [Rust Server Components](https://anto.pt/articles/rust-server-components)
-
-[55:56] **Carl Vitullo:** Oh yeah, I saw an interesting Rust server components post. Which is just interesting. The crossover between web and Rust is fascinating to me a little bit. And so now seeing somebody trying to do Server components, a like very fraught and complicated technology in rust. Interesting.
-
-[56:17] **Sebastien Lorber:** I wanted to mention something about the post rust server components. So this is more about using a rust backend with HTMX.
-
-[56:26] But there was recently an , an article from someone from the ReasonML community that I found super interesting because, they implemented React server side rendering in OCaml, in ReasonML, I think, or OCaml.
-
-[56:41] This led to very improved, performance in the benchmark. And I think now, the guy working on this is is now implementing server components in OCaml. So somehow, instead of running JavaScript in the... In the server runtime, they're running, a native language and, apparently it's really much faster.
-
-[57:04] And I find this quite interesting because maybe some day, there will be a faster runtime. maybe we can compile server components to native code on the server and, and run them much faster. But, I found this idea quite interesting to use something else than JavaScript to run, the React server side code.
-
-[57:26] **Jacob Paris:** Oh, interesting.
-
-## ⚡️ CSS-in-JS is Ruining Your Product
-
-- [Web Developers, CSS-in-JS is Ruining Your Product](https://cord.com/blog/migrating-from-css-in-js-to-vanilla-extract)
-
-[57:27] **Jacob Paris:** Here's a link from from, from Cords and, web developers, CS and JS for your product. Was that, was it was a neat a little article and sums up a lot of my, my thoughts here as well basically CSS and JS, so you can't generate the styles until your whole application has been rendered.
-
-[57:44] So you miss out on anything like React streaming. It has to render the whole thing. Styles and then inject them back into the app. There are some, you know, some solutions that are trying to fix issues like that'll extract using compile time extraction.
-
-[57:58] But in general, CSS and JS has kind of fallen out of fashion. And it seems like industry is sort of moving off and away from that.
-
-[58:05] **Carl Vitullo:** Yeah, interesting. We're 10 minutes over. We should probably, we could probably keep doing links forever. I, there's one more thing that I want to pop out then maybe we should call it after that.
-
-## ⚡️ Dan Abramov joins BlueSky
-
-- [Dan Abramov joins Bluesky](https://twitter.com/dan_abramov/status/1695566446007386214)
-
-[58:14] **Carl Vitullo:** But Dan Abramov is now a product engineer, no longer purely library maintainer on the backs, you know, behind the curtain of web development. He's joined BlueSky as a, as a software engineer. And I think that's going to be really interesting because as far as I know, he's still going to be on the core team. So I think specifically Dan Abramov, you know, working on a product and using React as a consumer. It's going to be really interesting.
-
-[58:45] I've been seeing some tweets from him coming out talking about points of friction on using React Native and all sorts of things like that. So just having seen all the different times that he has introduced something because he felt a pain point and then invented a new category of tool.
-
-[59:04] I can think of redux and create react app that were both just like his brain children that he felt the pain. He made something that fixed it. And then everyone else went, I didn't know you could do that. So I'm interested to see what happens now that he's being exposed to more points of friction with more regularity.
-
-[59:20] **Jacob Paris:** Yeah, and especially a shift toward React Native rather than, I guess, primarily React web which was a lot of his work before. It'll be interesting to see what that does for the native ecosystem.
-
-[59:30] **Sebastien Lorber:** Yeah. Maybe Expo, won a great, developer advocate for free.
-
-[59:35] **Jacob Paris:** Ha ha.
-
-[59:36] **Carl Vitullo:** All right, thank you so much Sebastian and Jacob. Jacob, thank you for subbing in for Mark this week. You killed it. You did great. Thanks so much.
-
-[59:43] **Jacob Paris:** Absolutely. Thanks for having me.
-
-[59:44] **Carl Vitullo:** Definitely. Awesome. Thanks so much everyone in the audience for joining us and see you next month.
-
-[59:50] **Sebastien Lorber:** Thank you. Bye.
diff --git a/src/pages/podcasts/[slug].tsx b/src/pages/podcasts/[slug].tsx
index 72485f9..07bb5b5 100644
--- a/src/pages/podcasts/[slug].tsx
+++ b/src/pages/podcasts/[slug].tsx
@@ -2,6 +2,7 @@ import { useEffect, useRef, useState } from "react";
import { z } from "zod";
import { type RootTranscript } from "@utils/transcript-types";
import { useRouter } from "next/router";
+import Head from "next/head";
import { Layout } from "@components";
const getNestedProperty = (
@@ -46,7 +47,20 @@ export const getStaticProps = (t: { params: { slug: Slug } }) => {
};
};
+// An unfinished experiment with a hardcoded slug. noindex goes on every render
+// path, including the loading state that is all the prerendered HTML holds.
export default function PodPage({ slug }: { slug: Slug }) {
+ return (
+ <>
+
+
+
+ (null);
diff --git a/src/pages/transcripts.tsx b/src/pages/transcripts.tsx
index f1e84ab..093f0f2 100644
--- a/src/pages/transcripts.tsx
+++ b/src/pages/transcripts.tsx
@@ -2,23 +2,33 @@ import React from "react";
import { add, format, compareDesc, parseISO } from "date-fns";
import { FocusBoundary, Layout, Link } from "@components";
-import { loadAllMd, processMd, Transcript } from "@helpers/retrieveMdPages";
+import {
+ loadAllMd,
+ processMdPlaintext,
+ Transcript,
+} from "@helpers/retrieveMdPages";
+
+// Dates are stored as midnight UTC; a day's offset keeps them from rendering
+// as the previous day in US time zones, same as the transcript pages.
+const toDay = (date: string) => add(parseISO(date), { days: 1 });
+
+const truncate = (text: string, max: number) =>
+ text.length <= max ? text : `${text.slice(0, max - 1).trimEnd()}…`;
export default function Transcripts({
all,
- latest,
+ firstYear,
}: Awaited>["props"]) {
- const date = format(add(parseISO(latest.date), { days: 1 }), "EEEE PPP");
return (
{(setSidebar: any) => (
<>
- {latest.title}
+ Q&A transcripts
-
+
+
+ Since {firstYear}, Reactiflux has hosted Q&As with the people
+ who build React, React Native, and the libraries and tools around
+ them. Members bring the questions; these are the transcripts,
+ newest first.
+
- Transcript from {date}
+ Looking for This Month in React? Episodes, show notes and
+ transcripts are at{" "}
+
+ tmir.reactiflux.com
+
+ .
-
+
+ {all.map((transcript) => (
+ -
+ {transcript.title},{" "}
+ {transcript.month}
+ {transcript.blurb ? `: ${transcript.blurb}` : null}
+
+ ))}
+
)}
@@ -56,23 +82,26 @@ export async function getStaticProps() {
.sort((a, b) =>
a.date && b.date ? compareDesc(parseISO(a.date), parseISO(b.date)) : 1,
);
- const latest = all[0];
- if (!latest) {
+ if (all.length === 0) {
throw new Error("No transcripts found!");
}
+ const years = all
+ .filter((t) => t.date)
+ .map((t) => toDay(t.date).getFullYear());
return {
props: {
+ firstYear: Math.min(...years),
all: all.map((t) => ({
title: t.title,
- hasContent: Boolean(t.content),
path: `/transcripts/${t.slug}`,
+ month: t.date ? format(toDay(t.date), "MMMM yyyy") : "",
+ blurb: truncate(
+ processMdPlaintext(t.description ?? "")
+ .html.replace(/\s+/g, " ")
+ .trim(),
+ 160,
+ ),
})),
- latest: {
- title: latest.title,
- description: latest.description,
- date: latest.date,
- html: processMd(latest.content, { wrapFirstList: true }).html,
- },
},
};
}
diff --git a/src/pages/transcripts/[slug].tsx b/src/pages/transcripts/[slug].tsx
index 8cb665e..8c81cc4 100644
--- a/src/pages/transcripts/[slug].tsx
+++ b/src/pages/transcripts/[slug].tsx
@@ -17,16 +17,17 @@ export default function Transcript({
html,
}: Awaited>["props"]) {
// A ridiculous method to ignore timezones
- const formattedDate = format(add(parseISO(date), { days: 1 }), "EEEE PPP");
+ const day = add(parseISO(date), { days: 1 });
+ const formattedDate = format(day, "EEEE PPP");
return (
{(setSidebar: any) => (
<>
@@ -66,6 +67,15 @@ ${description}`}
);
}
+/** One line for search results: who, when, then as much of the blurb as fits. */
+function metaDescription(title: string, date: string, blurb: string) {
+ const lead = `Transcript of the Reactiflux Q&A with ${title}, ${date}.`;
+ const rest = blurb.replace(/\s+/g, " ").trim();
+ if (!rest) return lead;
+ const full = `${lead} ${rest}`;
+ return full.length <= 200 ? full : `${full.slice(0, 197).trimEnd()}…`;
+}
+
export const getStaticProps = async ({
params,
}: {
@@ -89,7 +99,7 @@ export const getStaticProps = async ({
all,
...pick(["title", "date"], doc),
html: processMd(doc.content, { wrapFirstList: true }).html,
- description: processMdPlaintext(doc.description).html,
+ description: processMdPlaintext(doc.description ?? "").html,
},
};
};
diff --git a/src/transcripts/tmir-2024-01.md b/src/transcripts/tmir-2024-01.md
deleted file mode 100644
index 25adac8..0000000
--- a/src/transcripts/tmir-2024-01.md
+++ /dev/null
@@ -1,549 +0,0 @@
----
-title: This Month in React (January 2024)
-date: 2024-01-31
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/episode/5vn2bvmAkFxK3hvNQfGcmx?si=LNR0KUNwRnmpt7x2jJMf0g)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/tmir-2024-01-the-year-ahead-why-are-people-so-miffed/id1661733526?i=1000644051585)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick hits
- - [[00:32](#reviewing-layoffs)]: [Layoffs.fyi](https://layoffs.fyi/)
- - [[03:06](#conferences)]: Conferences
- - [React Paris](https://react.paris/) March 22nd, Paris, FR
- - [Epic Web](https://www.epicweb.dev/conf) April 11th, Park City, UT
- - [React Miami](https://www.reactmiami.com/) April 19-20th, Miami, FL
- - [React Connection / RN Connection](https://reactconnection.io/) April 22nd, Paris, FR
- - [React Conf 2024](https://conf.react.dev) May 15-16 Henderson, NV
- - [[03:58](#library-releases)]: New releases
- - [React Aria generally available](https://react-spectrum.adobe.com/releases/2023-12-20.html)
- - [New shadcn/ui components](https://ui.shadcn.com/docs/changelog)
- - [Eslint v9 alpha 0](https://eslint.org/blog/2023/12/eslint-v9.0.0-alpha.0-released/)
- - [jQuery 4.0??](https://github.com/jquery/jquery/issues/5365)
- - [date-fns v3](https://blog.date-fns.org/v3-is-out/)
- - [ReScript v11](https://rescript-lang.org/blog/release-11-0-0)
-- [[08:08](#react-libraries-for-2024-by-robin-wieruch)]: [React Libraries for 2024](https://www.robinwieruch.de/react-libraries/)
-- [[09:54](#rising-stars-on-github)]: [Rising Stars for JS, React ecosystem](https://risingstars.js.org/2023/en#section-react)
-- [[10:56](#bytes.dev-2024-predictions)]: [2024 bytes.dev predictions](https://bytes.dev/archives/250)
-- [[12:29](#speculating-on-react-19)]: React 19 and upcoming features
- - Context Selectors! [Discussion](https://twitter.com/acdlite/status/1741188563926962190) and a [summary from](https://interbolt.org/blog/react-use-selector-optimization/) [Colin Campbell](https://twitter.com/interbolt_colin)
- - [Proper Web Component support planned for React 19](https://github.com/facebook/react/issues/11347#issuecomment-1899140345)
- - [Web Components 2024 feature updates](https://eisenbergeffect.medium.com/web-components-2024-winter-update-445f27e7613a)
- - [[19:01](#upcoming-client-features-in-react)]: [Rick Hanlon: some upcoming client features I'm excited about](https://twitter.com/rickhanlonii/status/1747333623152275685)
- - [New client-side hooks coming in React 19](https://marmelab.com/blog/2024/01/23/react-19-new-hooks.html)
- - [React Forget updates](https://twitter.com/dan_abramov2/status/1747640983980806466)
-- Framework updates
- - [[22:34](#remix-spa-mode)]: [Remix working on “SPA mode”](https://github.com/remix-run/remix/pull/8338)
- - [Likely stabilize as Vite plugin does](https://github.com/remix-run/remix/discussions/7638#discussioncomment-8286839)
- - [Remix also working on RSC support](https://twitter.com/ryanflorence/status/1752166725028872432), and will have [differences from Next’s approach](https://twitter.com/ryanflorence/status/1752711755384692854).
- - [[24:53](#next-14.1)]: [Next.js 14.1](https://nextjs.org/blog/next-14-1)
-- [[27:56](#annoyed-at-react-roundup)]: “Annoyed at React” roundup
- - [Kind of annoyed at React](https://blog.cassidoo.co/post/annoyed-at-react/)
- - [React, where are you going?](https://dev.to/matfrana/react-where-are-you-going-5284)
- - [Mark’s reply](https://dev.to/matfrana/react-where-are-you-going-5284#comment-2c8g3)
- - [Ryan Florence on Twitter](https://twitter.com/ryanflorence/status/1747699804598395215)
- - [Increasingly miffed about the state of React releases](https://macwright.com/2024/01/03/miffed-about-react)
- - [React is getting a bit of a kicking lately](https://piccalil.li/blog/react-is-getting-a-bit-of-a-kicking-recently/)
-- [[37:55](#rsc-updates)]: RSCs
- - [RSCs: The Good, the Bad, and the Ugly](https://www.mayank.co/blog/react-server-components/)
- - [Leerob reacts](https://www.youtube.com/watch?v=8DyzsSWNcDE)
- - [The Two Reacts](https://overreacted.io/the-two-reacts/)
- - [RSC is React Server + Component](https://bobaekang.com/blog/rsc-is-react-server-plus-component/)
- - [“RSC does not require a server”](https://twitter.com/dan_abramov2/status/1745795274977493317) – Dan
- - [React Server Components paradigm](https://www.telerik.com/blogs/react-server-components-paradigm)
-- ⚡ Lightning round ⚡
- - [[47:40](#ryan-carniato-js-frameworks-into-2024)]: [Ryan Carniatto, JS Frameworks heading into 2024](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2024-i3l)
- - [[48:15](#rspack)]: [RSBuild guide to migrating from CRA](https://rsbuild.dev/guide/migration/cra)
- - [[50:10](#benchmarking-react-native-styling)]: [React Native styling tool benchmarks](https://www.reddit.com/r/reactnative/comments/1adasz4/react_native_cssstylesheet_frameworks_benchmark/)
- - [[50:40](#weird-things-engineers-believe-about-web-development)]: [Weird things engineers believe about Web development](https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/)
- - [[51:59](#tea.xyz)]: [Homebrew creator launching Tea.xyz, an OSS funding project](https://twitter.com/mxcl/status/1749894737862025330?s=46&t=uXPe0cHZZfyFyGotvsr9IQ)
- - [[55:44](#everything-on-npm)]: [NPM registry prank leaves developers unable to unpublish packages](https://www.scmagazine.com/news/npm-registry-prank-leaves-developers-unable-to-unpublish-packages)
- - [[57:00](#codepen-top-10)]: [CodePen top 10](https://codepen.io/2023/popular/pens/10)
- - [[57:37](#v8-performance-improvements)]: [V8 performance improvements](https://v8.dev/blog/holiday-season-2023)
-
-[00:00] **Carl Vitullo:** Thanks everyone for joining us for January's this month in React. I'm Carl. I am a staff product developer and freelance community manager here at React Tofl, the Discord for React Professionals. And Mark, you wanna introduce yourself?
-
-[00:14] **Mark Erikson:** Hi, I'm Mark. My day job is at Replay io where we're building a time, traveling demographer JavaScript.
-
-[00:20] And in my copious amount of spare time, I maintain Redux.
-
-[00:23] **Carl Vitullo:** Seems like it's been a big month. I don't know if that's just January, but yeah, let's dive right into it. I'm going to start off with a couple of, like, quick hits of small news.
-
-## Reviewing layoffs
-
-[Layoffs.fyi](https://layoffs.fyi/)
-
-[00:32] **Carl Vitullo:** I've been keeping track of layoffs. fyi. The first month of 2024 is looking not great. January layoffs have picked up a decent amount compared to last month, but compared to last year, January 2023, they're down like 70%. So, seems like it's trending in a good direction on an annual basis, but my instinct is that the next year is going to still be pretty rough.
-
-[00:58] Getting more specific, in January, 2022, there were five layoffs with about half a thousand affected. 2022 had a pretty steady upward trend for the rest of the year, which spiked really sharply in November. And then again, in January of 2023. Uh, so 2023 in January, there were 277 layoffs with about 89,000 affected. Jumping ahead to this year. January, there were 118 layoffs with about 31,000 affected. So this January is significantly less bad than last January, but compared to two years ago, it is... not even close it is super super high, still.
-
-[01:38] But looking at this annually as part of a cycle, um, I attribute some of this, I'd attribute the spike in November to businesses wanting to avoid holiday layoffs and sort of front-loading those.
-
-[01:49] So instead of splitting that same number of layoffs across two months, just doing it all at once in November. Um, and then. In January with new financial fears, starting new budgets. Uh, Annual decisions being made. In this fearful atmosphere management is biasing towards reducing expenses and lengthening runways, which I think is why there was such a large spike in January.
-
-[02:17] I also want to note that the first time the us fed hiked interest rates was in March of 2022. So looking at how. Low layoffs were in the first months of 2022, and then seeing how they spiked, or rather how they grew over time through the rest of the year. I think that a large part of the thrashing, ensuring that we're seeing right now in layoffs and, um, poor job climate is due to really national and global scale economic conditions.
-
-[02:49] Uh, you know, there's no more zero interest rates, so no more zero interest rate phenomenons, and nobody quite knows what the. Important financial metrics to optimize for, and even what to target are in this new funding environment. So I think that's really important context to keep in mind when thinking about layoffs.
-
-## Conferences
-
-- [React Paris](https://react.paris/) March 22nd, Paris, FR
-- [Epic Web](https://www.epicweb.dev/conf) April 11th, Park City, UT
-- [React Miami](https://www.reactmiami.com/) April 19-20th, Miami, FL
-- [React Connection / RN Connection](https://reactconnection.io/) April 22nd, Paris, FR
-- [React Conf 2024](https://conf.react.dev) May 15-16 Henderson, NV
-
-[03:06] **Carl Vitullo:** Conferences coming up in the next two to three months. I'm just going to run through a couple.
-
-[03:11] We've got React Paris going on in March, towards the end of March 22nd, in fact.
-
-[03:17] Epic Web, which is hosted by Kent C. Dodds. That's going to be going on in April 11th in Park City, Utah.
-
-[03:24] React Miami, April 19th and 20th, in Miami, obviously.
-
-[03:29] Another Paris conference it looks like, or, I guess conference.
-
-[03:33] **Mark Erikson:** It's an actual conference, and in fact, I will be speaking at React Connection Paris.
-
-[03:37] **Carl Vitullo:** React Connection, React Native Connection, April 22nd in Paris. That's two Paris conferences exactly one month apart. So that's neat.
-
-[03:46] And React Conf, the React Conf, is happening for the first time in three or four years. So that's, we're going to talk more about that later, but definitely pretty excited to see what they've got to share.
-
-## Library releases
-
-- [React Aria generally available](https://react-spectrum.adobe.com/releases/2023-12-20.html)
-- [New shadcn/ui components](https://ui.shadcn.com/docs/changelog)
-- [Eslint v9 alpha 0](https://eslint.org/blog/2023/12/eslint-v9.0.0-alpha.0-released/)
-- [jQuery 4.0??](https://github.com/jquery/jquery/issues/5365)
-- [date-fns v3](https://blog.date-fns.org/v3-is-out/)
-- [ReScript v11](https://rescript-lang.org/blog/release-11-0-0)
-
-[03:58] **Carl Vitullo:** All right, continuing on. Some more quick hits before we dive into the real proper link discussion. A number of new releases, just like smaller libraries, that don't quite merit a full discussion round in the main segment. Just thought I'd run through them real quick.
-
-[04:13] React ARIA from Adobe, which I As far as I understand is a component library more specifically aimed like the value proposition of it being accessibility, an area I always think of as an accessibility thing. That is a huge advantage of using a component toolkit like that is getting the long tail of smaller benefits like accessibility. So definitely interested to see that.
-
-[04:36] **Mark Erikson:** The important bit to distinguish there is React Aria, the original form of it is actually a whole bunch of hooks that are kind of like the headless data type management. Here's a hook for managing slider data or something. And this specifically, I believe they've then built their own component library on top of that. You've always been able to use the hooks yourself in your own components, but they've now also built a set of components that make use of those hooks as well.
-
-[05:04] **Carl Vitullo:** Starting from the core primitives, ironing out the functionality there and then exposing it for, through a different means of accessing it. That sounds really cool. I'm really into it.
-
-[05:13] There are new ShadCN UI components. I don't have a list prepared to read off. Oh, yes I do. Carousel, drawer, pagination, resizable, a toast component called sonner, and a bunch of CLI updates. Yeah, love ShadCN UI. Love the concept. So, check it out.
-
-[05:30] ESLint has a new version 9 alpha 0. Don't have anything prepared to speak about there. It's not ready for production use just to get feedback right now, but it caught my eye that there's a new major version of ESLint coming.
-
-[05:44] Speaking of major versions, there is a major version of jQuery version 4 that is in the works. It's not released yet, but I caught discussion of the announcement blog post and upgrade guide, so cool! jQuery, blast from the past, love to see it.
-
-[05:59] Two more here for you. There's `date-fns` v3. `date-fns` is definitely a great library. Good replacement tool for Moment, if you're still using Moment. And yeah, I love it. It's great. Major version.
-
-[06:11] And last one. This is a little bit more of a stretch, but Rescript has Major Version 11 coming out. It's a compile to JavaScript typed language that I saw described as TypeScript the good parts. I haven't used it. I'm not super familiar with what its value proposition is, but yeah. New version. Seems cool. Love an experimental language.
-
-[06:32] **Mark Erikson:** There is some amount of buzz around what was originally known as, let's see, what was it before Rescript? Something else that started with RE, and I can't think of it right now. The language itself started as a fork of OCaml with more JavaScript like syntax.
-
-[06:49] Jordan Walke and Chung Lo and some other folks in the React community were really trying to push this around like 2017 or so. And it felt like there might be enough bleed over from the React community to make it a thing. And there was a whole series of forks around the tool and the language syntax that really killed any actual momentum it had.
-
-[07:12] And that combined with TypeScript really taking over as the definitive way to write types for JavaScript. I feel like it's moment passed around 2017, so there's, you know, apparently some, still some development work ongoing, and there's, there's always arguments of, use a better language, and it fixes some of the issues with TypeScript and JavaScript, but I think in practice TypeScript is good enough at this point, and, and the ecosystem momentum is there.
-
-[07:40] **Carl Vitullo:** Tile to JavaScript language is a pretty hard sell on starting. If you're going to start a new product that they're going to maintain for years, it's a big swing to try and use a brand new language. But I always appreciate seeing experimental languages. I think that's where a lot of the experimentation happens.
-
-[07:56] And then maybe some of the learnings from running a language like that will be brought back into JavaScript, the ECMAScript process, or into TypeScript itself. Love to see it.
-
-[08:07]
-
-## [React Libraries for 2024 by Robin Wieruch](https://www.robinwieruch.de/react-libraries/)
-
-[08:08] **Carl Vitullo:** We're going to start off talking about React libraries for 2024 from Robin Wieruch, which I hope I'm not butchering that too badly.
-
-[08:16] **Mark Erikson:** I don't know how to pronounce his last name either.
-
-[08:18] **Carl Vitullo:** Robin has been publishing very high quality blog posts and explanations and Just great content for years and years. I remember reading his stuff way back in 2015, 16, I want to say. And this is yet another in the same vein. It's a huge, very comprehensive list of recommended tools for all sorts of different aspects of building a real production website.
-
-[08:45] I mean, the table of contents, it's A full page on its own. Starting a new project, package manager, state management, data fetching, authentication, database, testing, rich text editor, drag and drop, mail. Just, it's a great list. Definitely worth reading, definitely worth checking out, especially if you're in a position of spinning up a new Greenfield project.
-
-[09:05] Something like that.
-
-[09:07] **Mark Erikson:** And, and actually on, on that note, uh, Robin also just put up a post, um, talking about how to actually create a new React project in 2024. His argument, not surprisingly, is start with Vite, especially if you're learning, it's, it's simpler, there's Fewer concepts to learn at once, and then here's when you would consider Vite, here's when you would consider Next, here's when you would consider Astro.
-
-[09:31] **Carl Vitullo:** What I have found myself reaching for personally when I'm starting out has been either just whatever Next or Remix. They both ship starter kits, but I've been using React for 10 years. I appreciate the concept of a novelty budget when working with a, uh, starting a new project. So, limiting the number of new concepts you're exposing yourself to is definitely smart advice.
-
-## [Rising Stars on GitHub](https://risingstars.js.org/2023/en#section-react)
-
-[09:54] **Carl Vitullo:** Very cool. Somewhat related, I came across a Rising Stars Annual award thing. It's a tracking open source projects that gained the most stars on GitHub over 2023. Pretty cool. Top 10, I think, for the React ecosystem were ShadCNUI, Excalidraw which I don't know, it's a, it's not a library. It's not really a React tool.
-
-[10:21] I know it was created by. Christopher Chedeau . Christopher Chedeau, thank you. So I think that's why it's in here. I love it, but it's not, I don't know if I would call it a React project. Anyway, it did beat out Next. JS though, that's number three. Zustand, number four, Refine, Docusaurus, love Docusaurus, CreateT3App, NextUI, Tremor, and Serverless stack.
-
-[10:42] So that's the top 10. There's a whole lot more, and they had a bunch of different ecosystems represented. It's a pretty cool list, pretty neat to see. Yeah, I've seen a comment in the chat, sad not to see UnoCSS. That's a new one to me. Wanted to check out though.
-
-## [Bytes.dev 2024 Predictions](https://bytes.dev/archives/250)
-
-[10:56] **Carl Vitullo:** Cool, yeah, another, keeping the thread of 2024, I don't know, analysis, predictions, Bytes, the Bytes. dev newsletter, which is one of the places that I pull links from to discuss, it put out a a list of predictions for 2024 and This is put out by Tyler McGinnis. He's been huge in the React ecosystem for years and years. I think bytes. dev is like one of the largest developer newsletters. Definitely a great source.
-
-[11:23] Some of his predictions though,
-
-[11:25] bun becomes the default runtime for the front end. That seems like a big swing. I don't know. Mark, what do you think about that?
-
-[11:30] **Mark Erikson:** So the caveat here is that the Bytes newsletter is written in a very intentional tongue in cheek humorous style.
-
-[11:38] There's real links and real thoughts, but Bytes is very much a sarcastic humor kind of newsletter rather than a strict straight to the point newsletter. So most of these predictions are very tongue in cheek.
-
-[11:51] **Carl Vitullo:** Second prediction was more than three of your favorite open source software slash dev tool startups will die.
-
-[11:57] **Mark Erikson:** I mean, that one's pretty much a given, right?
-
-[11:59] **Carl Vitullo:** Yeah, right. Fair. But you could make that about any startup class over an annual timescale, but fair enough. AI will replace no code, low code tools. Seems plausible. Maybe not this year. Netlify gets acquired by GoDaddy. Yeah. Well, I don't know. I won't go through every single one, but I, one, another one that I did was no one will figure out what local first actually means.
-
-[12:19] I have opinions there. I feel like local first is a good thing to strive for, but hopefully more people figure it out this year.(chuckles) Cool. Mark, you want to tell us about React 19?
-
-## Speculating on React 19
-
-- Context Selectors! [Discussion](https://twitter.com/acdlite/status/1741188563926962190) and a [summary from](https://interbolt.org/blog/react-use-selector-optimization/) [Colin Campbell](https://twitter.com/interbolt_colin)
-- [Proper Web Component support planned for React 19](https://github.com/facebook/react/issues/11347#issuecomment-1899140345)
-- [Web Components 2024 feature updates](https://eisenbergeffect.medium.com/web-components-2024-winter-update-445f27e7613a)
-- [Rick Hanlon: some upcoming client features I'm excited about](https://twitter.com/rickhanlonii/status/1747333623152275685)
-- [New client-side hooks coming in React 19](https://marmelab.com/blog/2024/01/23/react-19-new-hooks.html)
-- [React Forget updates](https://twitter.com/dan_abramov2/status/1747640983980806466)
-
-[12:29] **Mark Erikson:** Yes, so when we did this last month and we were doing some predictions for this year, saying that I expect React 19 to probably happen this year because we were seeing some initial discussions and mentions from the React team, and while we still don't actually have a timeline, there is a lot more activity going on.
-
-[12:50] On that front, item one, Satya, one of the React Forget team members, happened to drop by one of our discussion threads over in the Tech Reads and News channel and said that the general discussion of the React team seems to be that the next stable release of React will be React 19, there hasn't been any specific discussions or plans around a React 18. 3 minor version, and that generally matches just the other bits and pieces of discussion I've seen so far.
-
-[13:20] So we can probably expect that the next actual release will be React 19. One really big thing that came out In some Twitter threads is the idea that React might finally ship a form of context selectors.
-
-[13:36] This was a proposal that was first done back in 2019 by Josh Story, who at the time was just a community member. He now currently works for Vercel building server side React stuff. Andrew Clarke played with a prototype of building context selectors in like 2020 and then it's the concept sat around and hasn't gone anywhere, especially with all the focus on suspense and server components.
-
-[14:01] But in this discussion thread, the React team has said that their approach for implementing quote, context selectors And optimizing re renders when a component only needs one piece of data from a context will actually be to use the new named use, which is still horribly confusing. Like, you're going to be able to call the use hook inside of use memo, and that basically becomes like your selector function, in a sense.
-
-[14:34] And that will actually allow React to look at the contents of what you've returned, and maybe even call the memo callback itself, separately from rendering, determine that, look, nothing actually changed, and actually be able to skip out of potential re renders that way. I don't know if this will actually be in React 19 yet, I don't know if it's Something that they've proof of concepted already, but that's, that is a pretty big deal.
-
-[15:04] We've been waiting for that one for a while. Another one that we've been waiting for a very long time is proper web component support. React allows you to render web component elements. They're just, HTML string tags in that sense, but there's been lots of complexity around being able to accurately pass props into web components because of the differences between React passing around JavaScript values as props.
-
-[15:31] Versus web components having attributes that are strings versus properties that have to be set via JavaScript. And I don't understand all the nuances there, I have not used web components. But a, like an issue was filed back in like 2017, complaining that React did not have correct support for interacting with web components.
-
-[15:55] It took four years until someone from Meta finally went through all the arguments and proposals of what the exact semantics should be, and finally implemented An experimental feature that made them work right for React, but that feature has sat inexperimental for the last two plus years. And so they finally commented on that thread a couple weeks ago and said, this will be in React 19, finally.
-
-[16:24] **Carl Vitullo:** I've never really used Web Components either. In a lot of ways, they felt like they were trying to solve the same challenges, or a similar set of challenges that React did. But in many ways, React seems to take on a much larger scope. I mean, I think that's exemplified by the emphasis on React Server Components now, where you Like web components are trying to componentize web and that's cool, that's great.
-
-[16:50] But React has componentized UI across, I mean, it's used in mobile, it's used in web to make the UI for video games. It's crossing the server client boundary now in a very meaningful way. So I mean, that's why I've, that's why I have never used web components is because I have never felt a pain that they seem to solve that React was not already trying to solve on its own.
-
-[17:14] Yeah, so I don't know. Cool to see it coming in though. It'll be interesting to have, cool to have it as another option. But I'm skeptical that it's going to be that meaningful in the grand scheme of things just because, okay, It's kind, it's, it's the new render target in a way.
-
-[17:29] It's like not the normal DOM. You'd need a compatibility shim make it work with React Native. So I guess maybe that's a good analogy.
-
-[17:39] **Mark Erikson:** There's been lots and lots of arguments. I mean, like a lot of web component fans hate React, you know, because it's too, it's too big. It's too much JavaScript.
-
-[17:47] It tries to take over the, the browser, et cetera.
-
-[17:49] **Carl Vitullo:** It doesn't use the platform. Yeah.
-
-[17:51] **Mark Erikson:** Right, right. I think the best pitch for web components plus React that would benefit from this new support is maybe your company has. The Vue apps and Angular apps and React apps, you're trying to have a unified design system and you build that design system as web components, so you only have to implement it once.
-
-[18:14] And then you can now use those design components properly from within React.
-
-[18:20] **Carl Vitullo:** Intuitively makes sense to me. I strongly suspect that the technical realities of making that work are going to be pretty painful. But yeah, cool. It sounds like a large team. kind of challenge. I don't know. But yeah, I think it, I think to me the mental model that makes sense for it is it's a little bit like dropping down into native code on React Native, but on the web.
-
-[18:43] If you're using web components, you're, you're working at a lower level of abstraction than, than most components you would write in React.
-
-[18:51] **Mark Erikson:** Yep. I've been complaining about the React teams, you know, seemingly single focus on server components to the Somewhat detriment of new features for the client side.
-
-## [Upcoming client features in React](https://twitter.com/rickhanlonii/status/1747333623152275685)
-
-[19:01] **Mark Erikson:** Having said that, Rick Hanlon from the React team did recently put up a Twitter thread where he pointed out that there are a number of new features that work in the client and in some cases can be considered client side only. There's a, these are primarily a new series of built in hooks. poorly named UseHook, which can accept a promise and will be the new official trigger for suspense behavior.
-
-[19:26] You could, you will also be able to call the UseHook and pass in a context object to grab the context value, and apparently you can actually call that inside of loops and non rendering functions like callbacks, and so there will be some very interesting flexibility out of that. There's some improvements to StartTransition and FormActions, and then some new hooks for FormState, FormStatus, and OptimisticUpdates.
-
-[19:56] All those do exist in the latest Canaries, so if you're using Next. js, those are probably available, but they will hopefully actually become stable as part of React 19. So I do have a link under here where someone wrote a follow up article that actually gives some further details about some of those.
-
-[20:15] And then, while it's not specifically listed in there, some other things we can expect are they will finally be removing some deprecated features like the Legacy Context API. Given that it's been deprecated for multiple years, I expect that very few people listening have ever actually used it. People have asked the React team to clean up dead features for a long time, and they're finally going to be doing some of that.
-
-[20:38] And React 19 should also include the source maps work that I did.
-
-[20:44] **Carl Vitullo:** Yeah, I mean I guess that's the big advantage. That's what you do with a major version release, is you remove all the things you deprecated over the, since the last release. So, with, what, 5 years? Since 18?
-
-[20:56] **Mark Erikson:** No, 18, 18 came out in 21, sometime in 22, I think.
-
-[21:03] **Carl Vitullo:** Oh, was it that recently? Okay. Yeah. I guess I'm conflating with hooks, so cool. Yeah. And just to enumerate the upcoming client features that Rick was excited about, there's use in two contact or. Two settings. There's usePromise, which, like you said, is the, uh, how we're going to be interacting with suspense or, yeah, interacting with suspense from now on.
-
-[21:25] UseContext. I don't know, I don't, I appreciate this simplicity being added by this use hook, but calling it a use hook and then not having it follow the rules of hooks as has been established for many years. It just seems like it adds confusion to me. I don't know. We'll have to see how that shakes out.
-
-[21:45] **Mark Erikson:** That plus the literal naming and how carefully I had to word that sentence for it to make any sense.
-
-[21:52] **Carl Vitullo:** So, I don't know. We'll see. But yeah, async transitions in the start transition. Function, form actions for React server components, useFormState, useFormStatus, and useOptimistic. So there's our enumerated upcoming client features, so keep an eye out for those. I think those are currently available in a Canary release, so if you want to play with those.
-
-[22:13] And very cool to have your source maps PR ship out. Finally! Ha ha ha. Looking forward to seeing that. Hopefully, I just want to see, I'd like to see people react like, oh my god, you can do this now! Ah, debugging got so much easier! Yeah.
-
-[22:26] **Mark Erikson:** For the ten of us who actually try to debug into React.
-
-[22:30] **Carl Vitullo:** Well, hopefully it'll make the stack traces easier to read anyway.
-
-[22:33]
-
-## [Remix SPA mode](https://github.com/remix-run/remix/pull/8338)
-
-[22:34] **Carl Vitullo:** Let's move on to some framework updates. Remix is working on a single page application mode, which I think is interesting. I think this makes a lot of sense as a general framing for things like Intuitively, I think my mental model for, like, different forms of complex web applications, there's solutions like Gatsby that did full static generation.
-
-[22:57] Like, you can only, you do a build time and then you publish a bunch of HTML and JavaScript. Then the opposite of that would be like Next and Remix, which are full server client frameworks that help you figure out how to write code across that seam. So, Remix adding more flexibility to cover different areas in that spectrum, I think is really interesting.
-
-[23:20] It's like a single page application, fully static assets shipped from a CDN to the client's browser. That has real use cases. That is the simplest way to host an application. Lowest cost, lowest upkeep, lowest deployment complexity, all of that. That's still a real niche that has real reasons to reach for that.
-
-[23:39] Then, one step advanced from that is something that has a build time generation step. Then, up to the full server, able to respond to requests individually, that is sort of classic Remix or Next. So, I'm excited to see this. They mentioned that it's likely to stabilize as the Vite plugin that they, that we'd talked about, I think, last time, maybe November.
-
-[24:04] But yeah, so SPA mode likely to stabilize alongside the Vite plugin. They're also looking at server component support. It sounds like they're going to be having some different Approaches from how Next is doing it. Yeah, curious to see what they come up with. Ryan Florence has been a little bit on a tear with some good tweets lately.
-
-[24:24] Yeah, I don't know. It feels like something changed. It feels like he's been, uh, a little more visible, at least in my feed lately.
-
-[24:31] **Mark Erikson:** He'd actually take it. 6 months mostly off Twitter, and at least I might have actually deleted his account at one point.
-
-[24:37] **Carl Vitullo:** Yeah, that scans, because I had just felt like I didn't see anything from him for a long time, and I was wondering if that was, I don't know, my consumption habits changing, the algorithm giving me different things, but yeah. Good to see him back because a lot of this is top tier, really great info, really great news.
-
-## [Next 14.1](https://nextjs.org/blog/next-14-1)
-
-[24:53] **Carl Vitullo:** Yeah. Okay. Moving on to from Remix to Next. Next shipped 14. 1. Just going to run through some of the changes. I haven't played with this myself, so just going to, I'm basically summarizing the blog post here. But yeah, they talk about performance improvements, lots of faster local server startup.
-
-[25:12] Faster code updates, a lot faster, say up to 96. 3, very precise. Faster code updates with fast refresh. Faster initial route compiled without caching. And they mentioned that they're, it's not so okay. It looks like they've been adding a lot of caching to get rebuilds faster. They talk about. Adding, in the future, disk caching.
-
-[25:32] So right now you start up the server, and every time you rebuild, the cache is there. The cache is warm. But starting the server has a cold cache, so it's slower. So a disk cache would dump that memory cache to disk, so that when you restart the server, it Still has a warm calf, so it starts up faster. Major trade off there is that you introduce a whole new category of caching bugs.
-
-[25:55] I know when, many moons ago, when I was developing very actively on a Gatsby project, I remember one of my debugging steps. Once one A step less desperate than deleting node modules was deleting the cache. It will be cool to see if performance improvements come out of that. That is always something I'm aware of, just the increased complexity of additional layers of caching.
-
-[26:18] They talk about improved self hosting, new documentation. for some custom cache handling. And I'm going to bring in another tweet that I saw, I don't know if I'll be able to get the link quickly, but I did see, um, a tweet from Dan Abramov in the context of Next. He mentioned that he thought it would be very valuable if Next shipped like a simple mode that did not have any of the advanced features that require The host, to be aware of it.
-
-[26:47] So right now, a lot of things, a lot of features in Next only work exactly as advertised if you're also hosting on Vercel. And that's been a criticism, that's been a criticism especially in the context of Yes, thank you, Mark. Especially in the context of Next and Vercel having a lot of core team members for React, it being tightly coupled to a paid hosting provider rubs some people the wrong way.
-
-[27:15] So I, that makes sense. I think that would be really cool to see, just make it a little bit more portable, especially as like the bleeding edge of React development. It would be nice if that was not required to be hosted on a specific platform.
-
-[27:28] There's some other improvements, TurboPack improvements, developer experience improvements. One that I thought was minor but significant is push state and replace state support in AppRouter. I didn't realize this was missing or something you couldn't do, but yeah, sounds like now you can use the native browser history APIs while you're using the next AppRouter. Not specifically sure what that will enable, but Intuitively, it feels like it should open some new doors.
-
-## Annoyed at React roundup
-
-- [Kind of annoyed at React](https://blog.cassidoo.co/post/annoyed-at-react/)
-- [React, where are you going?](https://dev.to/matfrana/react-where-are-you-going-5284)
-- [Mark’s reply](https://dev.to/matfrana/react-where-are-you-going-5284#comment-2c8g3)
-- [Ryan Florence on Twitter](https://twitter.com/ryanflorence/status/1747699804598395215)
-- [Increasingly miffed about the state of React releases](https://macwright.com/2024/01/03/miffed-about-react)
-- [React is getting a bit of a kicking lately](https://piccalil.li/blog/react-is-getting-a-bit-of-a-kicking-recently/)
-
-[27:56] **Carl Vitullo:** Can we talk about all the people who are annoyed at React?
-
-[27:59] **Mark Erikson:** Yes, let's. One of the hazards of being part of a large tool community, and especially one that is in some ways as controversial as React is, is that there's inevitably waves of discontent that come out. And we've seen this pop up in different ways over the years.
-
-[28:18] I mean, 2017, 2018, there were a lot of people who were posting comments about how much they hated Redux and wanted to kill it. So this is not a new phenomenon, but there has been a very definite series of posts and sentiment from people over the last month or so expressing annoyance with React. And, I'll say this as a meta comment, the real problem at the moment is that there are 30 different overlapping semi related things that people are complaining about.
-
-[28:51] And the problem is, everyone is complaining about a slightly different subset of problems, and It's making it impossible for anyone to actually have a clear and specific discussion about what things this person is actually upset about versus what someone else is upset about. There's complaints about React being tied to Vercel.
-
-[29:14] There's complaints about React's versioning strategy. There's complaints about how the React team does marketing and DevRel or not. There's complaints about the fact that Next and Remix are highly listed in the React docs as tools to start projects. But Vite is relegated to an expandable details section that literally says, Well, I guess if you want to use this, we can't stop you.
-
-[29:43] There's complaints about server components not being sufficiently documented in the actual React docs. And a lot of these complaints are very vibe related. Like, a lot of this stuff isn't specific, technical concerns, and so it's really hard for anyone to meaningfully and coherently discuss a lot of these complaints.
-
-[30:09] So some of the current wave kicked off with Cassidy Williams. Very smart person, well known in the community, has been around for a while. Put up a post where she said she's kind of annoyed at React. It, it is a very, there's a lot of vibes in there. She's very real, she's very actually frustrated. At the same time, if you look at the list of things she says, it's several different pieces, and a lot of it isn't even technical.
-
-[30:34] And, and I'm not discounting her frustration, I'm noting that it's the kind of frustration that can't be solved with. Let's put out a new release. Or something. There was another post that came out a couple days later in response called React, where are you going? Very well written, and it was actually, I believe Published by someone who works on a tool called React Cosmos and some of his complaints came because they'd been trying to update the tool to work properly with the next app router and server components and they got it working but it was a very hard effort and they had to make changes to the API that actually made it less, harder to work with. This person put up a post that expressed a different set of grapes, and among other things, actually suggested that maybe what we need is a new React framework That is owned by the community, and it has like, a steering committee of prominent React community members as like a starting point before we even actually begin any development.
-
-[31:39] And the author actually tagged a whole bunch of people by name on both Twitter and the article, and I was one of the people tagged. So I went in and I wrote a pretty long comment where, you know, I was doing, trying to actually respond to some of the points in the article, but then also saying, look, there is a lot of confusion and miscommunication going on right now.
-
-[32:01] And to be like, to be entirely frank, this has been frustrating for me. I'm, I read discussion. I want people to have meaningful discussion. And, okay, look, fine, it's, it's Twitter, it's, you know, Reddit, it's comment threads, I know too many people talking in too many places for it to be real discussion, but it would be nice if we could at least agree on what we're discussing, and the meta problem right now is that no one is.
-
-[32:25] I have seriously considered writing a 5, 000 word blog post that is just, Here is the definitive list of the 30 different topics the React ecosystem is arguing about right now. Now that we have this list, please continue arguing, just know that you're, here are the specific things that we're discussing.
-
-[32:44] **Carl Vitullo:** At the beginning of the argument, please make sure to enumerate which of these you are arguing about (both laugh). Yeah, yeah, I think the vibes you were talking about, especially in Cassidy's post, is, I think that's very real, but also the vibes are so important and impossible to measure that it's, I don't know, I think she had a really, One of the things that she talks about was it's frustrating that diversity efforts visibly took a backseat with React leadership, and there's just not as many voices from a variety of different people anymore.
-
-[33:13] And, you know, like, how do you, like, what a vibe. That is such a vibe check kind of complaint, and Speaking of vibes, I picked up on a vibe that there were, there was a lot of frustration from within the core team about how the React documentation rewrite went, and yeah, that took a couple of years, and seemed like it really burned out quite a number of people on the core team.
-
-[33:35] And if you are burned out from Social, political aspects of this technical work, then you don't have as much energy to bring to that technical work. So it's like, if there's problems with the vibes, then I don't know what the solution there is, but it feels like it's gonna just have a, like, downstream detriment across the board.
-
-[33:53] **Mark Erikson:** There's a few other good articles and bits of discussion out there. Ryan Florence made a tweet saying he's still very much all in on React as the best way to build apps, but, you know, Remix is working on trying to Have an alternative vision for how do you build a full stack app other than Next?
-
-[34:11] Tom McWright put out a post where he measured the times between React stable releases and noted that the time from 18. 2 until now, is going on a year and a half, I think, and that's the longest we've ever gone between official stable releases of React, and meanwhile you've got Next using Canary builds And so there's definitely frustration over how the versioning strategy is going right now. Andy Bell just put up a post, uh, in the last day or so, saying that React's getting a bit of a kicking lately.
-
-[34:44] So a little bit of the meta commentary there. But it was actually a very well balanced post that said, Look, there's, there are different tools and different trade offs. Certainly the ecosystem, the web dev ecosystem has first swung hard in the direction of Client side rendering and now we're kind of back in a server side thing and where do web components fit in this?
-
-[35:04] But it was actually a pretty decent take some time and think about the trade offs for your situation. In practice, none of this actually necessarily affects you, the individual developer, working on an app for your day job. But there is some value in having a sense of what the big conversation is.
-
-[35:21] Because, honestly, my goal out of all this would be that the React DevRel team does a bunch of work to improve the React docs. I have repeatedly griped that there's a bunch of things that I think should be done in the React docs that I'm shocked that they haven't done yet. If there's anything that comes out of this discussion, I'd like to see a lot of docs improvements.
-
-[35:43] **Carl Vitullo:** All of this conversation, all of this kind of annoyed, where are you going? Increasingly miffed, a bit of a kicking. Last month I went off on a little bit of a rant. I would say in defense of the React core team, like, I think they are truly at the bleeding edge of the web ecosystem.
-
-[36:00] And I think that in a very real way, they have been setting the tone, setting the subject of discussion that everyone else then builds on. And in so many different dimensions, like, Hooks came out of nowhere and invented this new approach to designing an API for web frameworks. Like, nobody else, I can't think of another project and hooks came out that shipped an ESLint plugin as part of using it correctly.
-
-[36:34] Okay, this has enough weird little trade offs of how we've made it work that we need supporting tooling in order to help you. use it correctly, use it well. And now, that's very common. Like, now that's something that, like, Tailwind does. So I, to me, that was something that the core, the React core team introduced to the ecosystem that, as part of API design, you also think about it more holistically, not just, okay, I import this module, what's the function signature?
-
-[37:02] But, okay, I install this package, I import it, what does the error message look like? In my IDE, just a very user centered framing of how to do API design and thinking of what tools are they likely to already use, everything possible to give them the best experience we know how to do.
-
-[37:22] Ryan Florence's tweet, he says, React is still the best rendering library for the web and the people behind it are doing are just doing their best and actually doing a great job. And I think that's extremely true. They are doing a really great job, but what they're trying to do is so advanced and so new that it's just really hard to get every detail of it right. And I think that part of the reason that they are now subject to so much criticism is because of how much they've gotten right in the past, and they've elevated the bar repeatedly, and so now the bar is super high and people have very high expectations.
-
-## RSC updates
-
-- [RSCs: The Good, the Bad, and the Ugly](https://www.mayank.co/blog/react-server-components/)
- - [Leerob reacts](https://www.youtube.com/watch?v=8DyzsSWNcDE)
-- [The Two Reacts](https://overreacted.io/the-two-reacts/)
-- [RSC is React Server + Component](https://bobaekang.com/blog/rsc-is-react-server-plus-component/)
-- [“RSC does not require a server”](https://twitter.com/dan_abramov2/status/1745795274977493317) – Dan
-- [React Server Components paradigm](https://www.telerik.com/blogs/react-server-components-paradigm)
-
-[37:55] **Carl Vitullo:** Should we go on to RSCs? A lot of stuff there. What a month!
-
-[37:59] **Mark Erikson:** Similar to some of the complaints, there was a really good post a few weeks ago called RSCs, the good, the bad, and the ugly. And one thing I appreciated was this was largely focused on technical aspects.
-
-[38:09] Someone tried to use RSCs and gave a bunch of very specific feedback on here's what they're trying to do. Here are some of the pain points I ran into in terms of understanding, like, where do I put the use server versus use client markers? And then, I think there were some additional mentions at the bottom of bigger piece complaints about some of the direction of React and Next, but it was a good article overall, very well written, not Not flame bait, like this was a substantive technical discussion and criticism.
-
-[38:42] Worth reading through that to get a sense of some of the pain points with Next and server components specifically. Which is part of the picture, the issue right now. Is there still really only one real production way to use server components right now. So, Lee Rob, uh, Lee Robinson, who's the primary dev rel.
-
-[39:02] for Vercel and Next did put up a post responding to some of the points that were raised in the Good, Bad, and Ugly post. So, some back and forth there. You can get a, have a chance to compare the thoughts there. Dan Abramov has resumed blogging, and if you've been watching him on Twitter, he has been iterating in public, trying to figure out, like, what is, what are the best analogies and metaphors and tools.
-
-[39:29] To try to get people to wrap their head around server components and the mindset shift that's involved. And in some ways this is kind of frustrating because he is rapid tweeting lots of different ideas, lots of different catchphrases. Server components are like this. Well, server components are like that.
-
-[39:48] And he's been building on some of that and he's got a couple different blog posts up. And I think we probably linked one of them last time where he's building up a series of posts. lead you to think about server components, but he literally hasn't even mentioned the word server component yet. He's been trying to help you understand, where does code run?
-
-[40:10] Sometimes code runs on one computer, sometimes code runs on another computer. What if we had a way to control where that code runs? so he's working up to a metaphor to help people understand the mental model behind server components. And so I know he said that this is turning into an actual blog post series, he's got a few more posts he wants to write, and so this post, the two Reacts, is trying to work towards that train of thought.
-
-[40:41] There was another explainer post from someone else completely. called RSC is React Server Plus Component. One of the other debates on Twitter, and tying into the people are confused or annoyed, is that the term React Server Components is highly confusing, because they don't always have to run on a literal server.
-
-[41:05] Like, not on a web server as we think about it. Like, they can be used at build time and generate static output. They are not strictly a server side rendering concept, and Dan has been frantically trying to make the point that, depending on how you use the technology, like, you could even use it, like, inside of a web worker or something?
-
-[41:27] Like, what, server components really are, like, a pre rendering method that spits out Serialize, React, as JSON. It just so happens that most of the time, and especially with Next, that happens in response to an API request. This blog post is trying to make the argument that rather than saying React Server Components with the implication that it runs on a web server, it's think of your code as like a React Server, React Client split, and the code for React Server could run At anywhere, at any time, depending on the bundler and the system architecture.
-
-[42:09] I realize there's a lot of semantics and technical nuance there, but I thought this was actually one of the better posts. And then there's, again, like I said, Dan has been trying to make the point that they don't require a literal web server. And then there's been a number of other different articles and discussion about this as well.
-
-[42:25] So the mental model and how do you teach server components, I think, is. One of the biggest outstanding questions. And again, I would love to see more of this in the actual docs.
-
-[42:35] **Carl Vitullo:** But, okay, so hopefully this is the putting it out there, ideating phase that then gets brought back in the rough draft, first pass.
-
-[42:45] So hopefully this does get brought back into the documentation as well, but I don't know if that's been I don't know how consistently that's happened over the last year or two. Something about Dan's, the two Reacts posts that stood out to me, I think that he had something really good to say.
-
-[43:00] I mean, just like the opening line of it was, I suppose I want to display something on your screen. Whether I want to display a web page, an interactive web app, or a native app you might download, at least two devices must be involved. Your device and mine. I think that is such a great, useful framing for what they're doing here.
-
-[43:17] Why React server components? It's, there are always at least two machines, the developer's machine, whether that's a local computer that they're running a build on or a server or a serverless function being executed somewhere, and the client machine. There's always a client machine. There's always something else.
-
-[43:38] So because of that, there's always going to be. Communication between those two and so that's my mental model for React server components is they are iterating on what that communication bridge looks like and how to interact with it.
-
-[43:53] **Mark Erikson:** There's been lots of arguments about what would be a better name for server components.
-
-[43:57] People have suggested dozens of different options. My vote would be React serialized components. I think that is the best retrofit for the acronym RSC and I think it's the best explanation technically in terms of what it does rather than the literal word server. You are serializing a component's output.
-
-[44:19] What it does, what happens after that depends on the environment. Maybe you're going to turn it straight into HTML on the server. Maybe you're going to output a file to disk. But ultimately what's happening is there's a pass that serializes the element output and then does something with it.
-
-[44:36] **Carl Vitullo:** Yeah, that actually makes a lot of sense.
-
-[44:38] I don't know if I, I don't know if we want to coin a brand new Well, I don't know if this is coined, but anyway, that's interesting. That's a, that is a good framing for it. Serialized is a little bit more evocative of The benefits and constraints, then server. Of course there's a server. Yeah, okay. That's interesting, I like that.
-
-[44:56] Okay, we're down to our last link, which I guess we'll just go right on
-
-[45:00] **Mark Erikson:** ahead. Yes, so I have been happily highlighting the progress of the React Forget compiler over the last few months. So, there was a blog post in March of last year. Where they said, we're working on it. There were two different conference talks at React India and React Advanced where the React team actually said, we're working on it and here's some of our progress.
-
-[45:20] There was a bit of very interesting discussion on Twitter a couple weeks ago where they talked a bit about some of the technical implementation. So, it is currently implemented as a Babel plugin. Having said that, the Babel plugin is basically just acting as a front end for the actual compiler logic.
-
-[45:41] The compiler itself is currently written in TypeScript, I believe, and not strictly tied to Babel itself. So, there were some thoughts about, I mean, there was some discussion of, well, how fast is it to run? Can you use it for fast refresh? Could it be translated to Rust someday? And one of the other possibilities that came up, Meta has been working on something that they call Static Hermes.
-
-[46:07] Hermes is the JavaScript engine that's used for React Native. It's a completely separate JavaScript implementation. And they've got a research project where they use the Hermes engine to compile your JavaScript or TypeScript code to a native binary. And have seen some interesting early results from that.
-
-[46:29] One other possibility for maybe making the Forget compiler execute faster. Instead of translating it to Rust, maybe they compile the TypeScript code to native with Static Hermes. We'll still know ETA on when this comes out. I have my fingers crossed that we'll see you some more details about it at React Conf in May.
-
-[46:47] But it was interesting to hear a bit more of the technical details of what it's taking to actually build this.
-
-[46:54] **Carl Vitullo:** Yeah, definitely. I have not been following it super closely.
-
-[46:57] **Mark Erikson:** That's why I'm here.
-
-[46:58] **Carl Vitullo:** Yeah, right? Thank you. We can pay attention to slightly different things that overlap and have a great conversation (laughs).
-
-[47:05] Yeah, my general M. O. on a lot of these experimental features is keep an eye out, know what they're called, check in once in a while, and then when they're released, cool, I have a framework for understanding why it exists. Excited to see what comes out of it, but I know this is I don't know. I've seen skepticism that it will be released in a timely manner, though it's not yet.
-
-[47:26] I mean, I'm still catching up on server components, so I just don't have the mental bandwidth to also pay attention to a whole optimizing compiler as well. On to the lightning round. We've got a bunch of links here. I think we should just pick and choose rather than going fully down the list, but
-
-## [⚡ Ryan Carniato, JS Frameworks into 2024](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2024-i3l)
-
-[47:40] **Carl Vitullo:** Ryan Carniato had a solid write up on JavaScript frameworks as we head into 2024.
-
-[47:48] Mark, tell us what that giggle was about.
-
-[47:50] **Mark Erikson:** So he's the author of SolidJS.
-
-[47:52] **Carl Vitullo:** Okay. I did, I, okay. I did not recognize the name. I, sorry, but a lot of talk about signals. And so that makes a lot of sense.
-
-[48:01] **Mark Erikson:** Yeah. Ryan's articles are always excellent. He is so good at. Discussing both technical details and trade offs and nuances. So his posts about what's going on in the front end ecosystem are always worth reading.
-
-## [⚡ RSPack](https://rsbuild.dev/guide/migration/cra)
-
-[48:15] **Mark Erikson:** Next up, so, there's a tool called rsPack, and it is a of Webpack to Rust. Literally, they've implemented all of Webpack's public API in Rust. I think the engineers behind it work at ByteDance, a company that does TikTok.
-
-[48:34] There's a second layer called rsbuild, which is like basically more of an ES builds API, but using rspack as. The implementation layer underneath and I recently saw a tweet suggesting that talking about they've got documentation on how to migrate from create React app to using RS build and I actually had a like my presentation slide tool set.
-
-[49:02] I was using React App with Craco to override the webpack config. And I thought for several years, like, I should switch this over to Vite. But, one, I'm too lazy. Two, that's a rabbit hole. Three, I, my setup uses a webpack plugin in order to parse the markdown that I use to write my slides. And so, I was actually curious about this, and in about one hour, I was able to switch from my CRA setup to using RSBuild, and the compile time went from 30 seconds to one second.
-
-[49:38] I then made it harder on myself and spent and burned like two hours trying to upgrade the version of the MDX markdown syntax that I could use. But that was a separate problem from doing the actual switch. So I know there's a lot of people who are trying to switch from create React app to Vite, and that's absolutely a thing you can do, but you might also want to look at using rsbuild instead, because it's webpack compatible and you might actually have to do less work to switch over.
-
-[50:08] Yeah,
-
-[50:09] **Carl Vitullo:** very cool. Very nice.
-
-## [⚡ Benchmarking React Native styling](https://www.reddit.com/r/reactnative/comments/1adasz4/react_native_cssstylesheet_frameworks_benchmark/)
-
-[50:10] **Carl Vitullo:** I saw a cool post on Reddit. Somebody made a project benchmarking different CSS and stylesheet implementations. It's basically a microbenchmarks list. I don't really know how applicable these are. I don't really know exactly what this would mean from a broader performance.
-
-[50:27] perspective. But, you know, it looked like they put some real work into benchmarking a variety of different approaches in React Native for applying styles, and not sure how much more there is to say on that, though.
-
-## [⚡ Weird things engineers believe about Web development](https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/)
-
-[50:40] **Mark Erikson:** Uh, one article that I really liked, a, an engineer who used to work on the internals of Mozilla Firefox, developing the browser itself, put up a post talking about weird things engineers believe about web development, and it was actually kind of a, here's the stuff that browser engineers think people care about, and then there's the stuff that web developers actually care about, and these are not necessarily the same thing.
-
-[51:04] So, it was just an interesting check on the mindsets of the people using the browsers vs the people building the browsers. I think
-
-[51:14] **Carl Vitullo:** this is a super important read. I think these are, I don't know, there's just this, you get this feedback cycle in knowledge where somebody learned something, they write about it, and then other people learn that from the people who wrote about it. And so you get like a game of telephone going on.
-
-[51:31] So then several, multiple years later, everyone knows all of these things. But if you go back to the actual primary source, some of them are a little warped. Some of them are outright wrong. So this feels like that going back to the primary source. Somebody's up to date on what people claim they know, what the common knowledge is, but they have experience with the actual underlying technology that provides those constraints. So definitely, we recommend reading this.
-
-## [⚡ Tea.xyz](https://twitter.com/mxcl/status/1749894737862025330?s=46&t=uXPe0cHZZfyFyGotvsr9IQ)
-
-[51:59] **Carl Vitullo:** I came across a cool project by the guy who created Homebrew, which is like the de facto dependency manager for macOS. It's like apt for Unix. But, so he is launching an open source software funding project that is I think blockchain based and whatever, so all of the whatever skepticism you have for that is probably warranted, but I'm always interested in new approaches for improving the economic situation of open source maintenance.
-
-[52:32] It is notoriously a very thankless job kind of situation. Yeah, I don't know, Mark, I'm curious if you have any thoughts on this as the only open source maintainer between the two of us. But yeah, it's broadly interesting to me.
-
-[52:45] **Mark Erikson:** I saw this mentioned, I didn't glance at it, so I don't have a lot of thoughts on this tool itself. The flip side is there's another tool in the same sort of space called thanks.
-
-[52:57] dev. One of the complaints about How do we fund open source maintainers has always been the trickle effect. If I provide, if my project uses Jest, ESLint and Webpack and Babel, do I send funds just to those projects? What about all the dependencies those projects are built out of? And so there's been a couple of different attempts over the years to figure out like, how do you divvy this up?
-
-[53:24] And one that I'm actually getting a little bit of something out of is this thanks. dev thing. So, companies like Sentry are donating chunks of money to this intermediary and the intermediary is scanning all the package JSONs and using a particular algorithm to figure out, like, what, what percentage each of the dependencies and sub dependencies that you would actually get, and, you know, full transparency, I'm not getting much out of this, but, you know, like, 15, 20 bucks every now and then, it's okay, it's non zero, okay, cool, thank you.
-
-[53:58] **Carl Vitullo:** I get a similar amount of money from the Medium blogging I did five years ago. It's not nothing, it's not that much. Whether it's enough money to warrant the additional need to remember to add it as income when I file my taxes is debatable.
-
-[54:11] But, yeah, I don't know. It's a hard problem. It's as yet unsolved. I'm always interested in seeing a new approach, trying to solve it. Analyzing package. json and things like that is cool. I kicked around the thought of trying to do a business in this space a number of years ago. Hey, we're Reactiflux. We have so many people donating their time to answering questions.
-
-[54:32] Open source maintainers, but ultimately where I came down on it is it's just so hard to attribute relative value between different projects that like, okay, you can scan thousands, millions of package. json files to understand the dependencies and what depends a lot on this and but then there's also there's so many deep utility functions, deep utility modules that You look at the MP M and they're downloaded like billions of times and it's like that real, is that, should that get the most money outta this?
-
-[55:06] I don't know. When I, when I was doing my own thought exercises and this never left thought land, I never did anything with these thoughts, but when I was thinking about it, it's, I don't know if you can get to the socially understood value versus. Any of the metrics that are available from analyzing dependencies, it seemed like too big of a gulf between the two of them to be obviously valuable to me, but I'm very cool to see anyone who is taking hard problem of open source funding and trying, building code, doing marketing, taking revenue and distributing it back out.
-
-[55:41] Anyone doing that, I will support 100%.
-
-## [⚡ `everything` on npm](https://www.scmagazine.com/news/npm-registry-prank-leaves-developers-unable-to-unpublish-packages)
-
-[55:44] **Mark Erikson:** Yep, and then the last one I got is, there was a recent, I don't know, issue, problem, whatever, with the npm registry, where some folks were experimenting with, Is it possible to make a package that literally depends on every other package in the entire npm registry? And they actually ran into some problems doing this, because there's like a maximum size in your package, or maximum number of dependencies you can have for one package, and what they ended up doing was chunking it up, so the top level package depended on 15, 20 other sub packages, and each of those depended on 5 to 8 packages in all of the npm registry.
-
-[56:26] What this resulted in, though, was it made it impossible to unpublish anything. From the entire NPM registry. Yet another weakness in both how NPM works and how people use NPM. First we had LeftPad, where we found out that unpublishing something dependent on by thousands of other libraries breaks everything.
-
-[56:49] We've had a few other issues over the years, and now this one. It was dealt with, but people continue to find more ways to break NPM.
-
-[56:57] **Carl Vitullo:** Alright, I'm gonna run through a couple here at the very end.
-
-## [⚡ CodePen top 10](https://codepen.io/2023/popular/pens/10)
-
-[57:00] **Carl Vitullo:** I loved this, CodePen put out a Top 10 CodePens of 2023. Love creative coding, love people just making little fun visual things.
-
-[57:10] Just for the joy of it, just to explore a new concept or to make something pretty. Creative coding is not a, an aspect of software development that we have in Reactiflux, had a lot of, people do that in CodePen, people do that in Glitch, people do that in, there's other platforms that are very well suited to it, and we've just never gotten a lot of that energy in Reactiflux.
-
-[57:30] But yeah, really cool, I loved some of these projects, definitely check it out, especially if you're looking for inspiration on a project to work on yourself.
-
-## [⚡ V8 performance improvements](https://v8.dev/blog/holiday-season-2023)
-
-[57:37] **Carl Vitullo:** And last link from me, V8 Performance Improvements. This is, like, extremely nitty gritty, like, close to the metal kind of knowledge. It's probably not going to be very practical in, you know, you as a software developer.
-
-[57:52] But they're adding yet another new level of optimizer, which is interesting. I don't know, I thought it was a good read. It's nice to understand a little bit more about how your code is being executed. There are specific people who will need to know implementation details like that. I know that the, I'm sure that the React core team has done a lot of performance optimization to ensure that the way their code is being interpreted and optimized and the way it runs through these processes results in a as close to optimal performance as possible.
-
-[58:25] I have an affinity for this type of low level post about where our code runs. But yeah, I just thought it was interesting to go through a little bit of history. It's also been 16 years since V8 was released. 16 years since Chrome came out, which is wild. What an era. It's the new era of the web. Definitely check that out if you're interested in bare metal stuff.
-
-[58:48] Thank you so much everyone for joining us. We'll be back on the last Wednesday of February here in the live stage or back in your podcast feed just as soon as we can. If you see anything newsworthy, definitely let us know in the tech reads and news channel of Reactiflux, but yeah, we also check. Quite a range of newsletters and other sources.
-
-[59:08] Mark and I both moderate the React. js subreddit. I love bytes. dev, React Status, ThisWeekInReact. There's close to a dozen sources that I pull links from here. Thanks for joining us. See you next month.
diff --git a/src/transcripts/tmir-2024-02.md b/src/transcripts/tmir-2024-02.md
deleted file mode 100644
index d61aa18..0000000
--- a/src/transcripts/tmir-2024-02.md
+++ /dev/null
@@ -1,446 +0,0 @@
----
-title: "This Month in React, February 2024: React 19 (but more details), Apple tries to kill PWAs"
-date: 2024-02-28
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick hits
- - [[00:25](#layoffs-and-job-market)] [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io job trends](https://trueup.io/job-trend)
- - [[01:46](#new-releases)] New releases
- - [react-email v2](https://resend.com/blog/react-email-2)
- - [Tamagui 1.88](https://github.com/tamagui/tamagui)
- - [Expressive Code](https://expressive-code.com/)
- - [Relay 16.2](https://github.com/facebook/relay/releases/tag/v16.2.0)
- - Remix 2.7 (and 2.6!) discussing later
- - [Isograph 0.1.0](https://isograph.dev/blog/2024/02/15/isograph-0.1.0/)
- - [[03:24](#upcoming-conferences)] Upcoming conferences
- - [React Paris 2024](https://react.paris/) March 22, 2024. In-person in Paris, France + Remote (hybrid)
- - [Epic Web Conf 2024](https://www.epicweb.dev/conf) April 10 - 11, 2024. In-person in Park City, UT, USA
- - [React Miami 2024](https://reactmiami.com/) April 19 - 20, 2024. In-person in Miami, FL, USA
- - [React Connection 2024](https://reactconnection.io/) April 22, 2024. In-person in Paris, France
- - [React Native Connection 2024](https://reactnativeconnection.io/) April 23, 2024. In-person in Paris, France
-- [[05:06](#react-labs-react-19)] [React Labs](https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024)
- - Brad Westfall: [React Will Be Compiled](https://reacttraining.com/blog/react-19-will-be-compiled)
- - [you’ll likely never need these APIs again:](https://twitter.com/acdlite/status/1758229889595977824)
- - [Good writeup from React Training](https://reacttraining.com/blog/react-19-will-be-compiled)
-- [[15:47](#a-pr-for-server-components-support-in-parcel)] React 19: RSCs, Suspense, and Server Actions
- - [Initial PR for Parcel support in RSCs?](https://github.com/facebook/react/pull/28138)
- - [Instant Search Params with React Server Components](https://buildui.com/posts/instant-search-params-with-react-server-components)
- - [Is Suspense Worth the Squeeze?](https://andy-gallagher.com/blog/about-react-suspense/)
- - [Avoid Using React’s `useFormStatus`](https://allanlasser.com/posts/2024-01-26-avoid-using-reacts-useformstatus)
- - [[19:30](#react-strict-dom-package)] [react-strict-dom](https://github.com/facebook/react-strict-dom)
- - [Announcement thread from kelset](https://twitter.com/Kelset/status/1760367655423549480)
- - Builds on [“react dom for native” proposal](https://github.com/react-native-community/discussions-and-proposals/pull/496)
- - [“Spiritual successor to react-native-web but from the opposite direction”](https://twitter.com/dan_abramov2/status/1760245165703184516)
- - [Compatibility chart](https://github.com/facebook/react-strict-dom/blob/main/packages/react-strict-dom/COMPATIBILITY.md)
-- [[25:09](#apple-announce-no-more-pwas)] [No PWAs on iOS in EU](https://developer.apple.com/support/dma-and-apps-in-the-eu)
- - [Action link, if you have an app affected](https://open-web-advocacy.org/apple-attempts-killing-webapps/) (Update, partially rolled back)
- - [MDN PWA Manifest docs](https://developer.mozilla.org/en-US/docs/Web/Manifest)
- - Gary Bernhardt’s [Birth and Death of Javascript talk](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript)
-- [[32:24](#next-app-router-the-good-the-bad-and-the-ugly)] Next
- - [A Next.js App Router Migration: The Good, Bad, and Ugly](https://www.flightcontrol.dev/blog/nextjs-app-router-migration-the-good-bad-and-ugly)
- - [What We’ve Learned from the transition to Next 14 and Server Components](https://medusajs.com/blog/client-server-transition-learnings-nextjs-14-server-components/)
-- [[35:22](#remix-26-27)] Remix
- - [2.6, 2.7 changelog](https://github.com/remix-run/remix/blob/main/CHANGELOG.md)
- - [Open sourced remix.run](https://remix.run/blog/oss-remix-dot-run)
- - [Good first issues](https://github.com/remix-run/remix-website/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
-- [[38:44](#state-of-react-native)] React Native
- - [State of React Native](https://results.stateofreactnative.com/) by Software Mansion
- - [[40:41](#react-native-frameworks-rfc)] [“React Native Frameworks”](https://github.com/react-native-community/discussions-and-proposals/pull/759)
- - [RN on Apple Vision Pro](https://www.callstack.com/blog/announcing-react-native-for-apple-vision-pro)
-- ⚡ Lightning round ⚡
- - [[43:34](#bun-shell-support)] [Bun shell](https://bun.sh/blog/the-bun-shell)
- - [[45:46](#deno-2023-2024)] [Deno in 2023](https://deno.com/blog/deno-in-2023)
- - [Survey results and 2024 roadmap](https://deno.com/blog/2024-survey-results-and-roadmap)
- - [[46:35](#jsrio)] [JSR](https://jsr.io/)
- - [[47:59](#how-hot-module-replacement-works)] [Hot Module Replacement is Easy](https://bjornlu.com/blog/hot-module-replacement-is-easy) (he lies)
- - [[48:33](#pmdrs-webgl-uikit)] [pmdrs WebGL layout engine](https://twitter.com/0xca0a/status/1762069894932160943) UI for react-three-fiber, [full repo](https://github.com/pmndrs/uikit)
- - [[49:25](#updates-from-the-100th-tc39-meeting)] [100th TC39 meeting updates](https://dev.to/hemanth/updates-from-the-100th-tc39-meeting-4j2f)
-
-[00:00] **Carl Vitullo:** Thanks everyone for joining for February's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
-
-I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, the Discord for React professionals.
-
-[00:16] **Mark Erikson:** Hi, I'm Mark Erickson. My day job is working at Replay io, where we're building a true time traveling debugger for JavaScript. And in my free time I do redux stuff.
-
-## Layoffs and job market
-
-[00:25] **Carl Vitullo:** We're gonna start off again, as we have been the last couple times with just some quick hits, layoffs that FYI, it looks like it's peaked, hopefully.
-
-There were just about 15,000 layoffs in February this year, which compares to 34,000 from last month. So that's down a little bit more than half, which seems pretty good. Pattern holds from last year as well, in 2023, numbers for January and February followed about the same pattern of dropping by half. But those numbers were 90,000 and 40,000.
-
-So that's down substantially year, over year, uh, 90,000, January last year to 34,000 january of this year. So that's down like 60%. So that's pretty great. Not out of the woods yet. But definitely comparing to 2023, it's looking a lot less grim.
-
-Here, I found a new resource that looks pretty cool, trueup.io/job- trend. It shows a number of open jobs in tech over time. It's not super clear where these are coming from. So, uh, take it with a grain of salt for sure. Don't know if this includes sales or product roles or if it's just engineering, but it looks like it peaked at 475, 000 jobs in April 2022, uh, down to a low of 163, 000 one year later, April 2023. And back up to about 200, 000. So the creeping back up, seems pretty good.
-
-## New releases
-
-[01:46] **Carl Vitullo:** I'm just going to run through a couple of new releases real quick. We've got React Email v2. Cool. Always a little bit tricky sending email from React. Email is always a pain in the butt, so I love new tools coming out for that.
-
-Tamagui 1. 88, which is a cross platform UI toolkit. The big selling point seems to be that it's seeking parity between web and React Native, which we're going to talk about a lot more later. There's been some cool new developments there. Yeah, they're supporting Expo 50, better types, and they tease a upcoming reduction in generated CSS size. So, seems cool. I know that's a reasonably widely used library. So, cool. New release.
-
-I heard about a cool new project doing syntax highlighting. It looks really good, actually. It's called ExpressiveCode. Definitely check that out if you're doing any sort of project that needs to highlight syntax.
-
-Relay. This is a little bit late, but Relay released version 16. 2. I've never been a big Relay user, so I don't fully understand what changes they just shipped, but if you use Relay, cool. There it is, new version.
-
-And again, something we're going to be talking about later, but Remix released actually two versions, released 2.6 and 2.7. We'll go into a little more depth on that later, but wanted to give it a shout out.
-
-And another, a little bit related, Isograph, which is a new take on doing GraphQL. Just announced a early 0. 1 release. We actually had the maintainer of that, Robert Balicki, on for an Office Hours last week. I think he released this version like an hour before we started the Office Hours event, so that was cool.
-
-## Upcoming Conferences
-
-[03:24] **Carl Vitullo:** All right, moving on from releases, there are a bunch of conferences coming on in the next two months or so.
-
-We've got React Paris, which is going to be March 22nd. It's in person, Paris, France, with a remote option as well.
-
-There is also Epic Web Conf coming out, or that's going to be in April 10th and 11th in person in Park City, Utah. Kent C Dodd's conference. So he always does great stuff. I'm sure this conference is going to be pretty cool.
-
-React Miami coming up April 19th and 20th as well in person in Miami. I went last year. It was really lovely. Reactiflux with a bit of an affiliation in that it's. The React Miami conference is organized by G2I, uh, which is run by Gabe, one of our admins. So definitely check it out. It was really great last year.
-
-There's also another conference in France, React Connection. That's going to be April 22nd, so exactly one month after React Paris. So, you know, great reason to get out to France.
-
-And one more in the next two months is React Native Connection. I guess that's also Same people, next day, also in France. So yeah, man, a lot of stuff going on in Paris.
-
-[04:34] **Mark Erikson:** I will be attending React Miami and then I'm actually speaking at React Connection in Paris. So I'm actually going to be directly, if you look at the timing, React Miami is actually like Friday, Saturday, and then React Connection is the next Monday. So I'm going to be. Going to Miami and then flying directly over there.
-
-[04:53] **Carl Vitullo:** That is going to be fun. We'll see if I can make it to any of the conferences this year. Not sure which ones I'm going to be going to. Yeah, that's all the quick hits we got. So let's go into our main content. Mark, you want to start us off?
-
-## React Labs, React 19
-
-[05:06] **Mark Erikson:** We have some really big news from the actual official React team posted on the actual official React team blog.
-
-They've put up another one of their React labs, what we're working on posts. And it's been 11 months since the previous post in March of 2023. And the good news is that there is a lot of details on what they've been working on, and a lot of pretty big pieces of news.
-
-Most of this is stuff we've actually talked about in previous episode, it's not like most of this is hidden, but it's good to get official confirmation of what they've been up to and where things stand.
-
-[05:40] **Carl Vitullo:** Yeah, you heard it here first, hahaha.
-
-[05:42] **Mark Erikson:** Very true. So, the first and probably the biggest piece of news is that the React team has been working away for the last couple of years on what they previously codenamed as React Forget. And the idea is it's a compiler that will auto optimize the content of your React components.
-
-Now, they talked about it initially at React Conf Online two years ago. They went kind of quiet for a while. They did a couple of talks in React India and React Advanced last fall.
-
-And so the big updates now are that 1. The name has changed. It's no longer React Forget. It's now officially just called React Compiler. And then also that they consider it no longer an experiment, it's effectively production ready.
-
-They are still working to finalize it and get it ready for use and release to the public, but it's a real thing that they effectively consider good enough that it's not just a will this work kind of situation.
-
-[06:50] **Carl Vitullo:** Yeah, and it's good enough that they are using it on Instagram's website right now is what I hear.
-
-[06:56] **Mark Erikson:** Yeah, when they did the talk at React Advanced in October, I believe they said that they were trying it out in production on Instagram Web's profile page, and then some kind of a React Native product page somewhere in Meta's code base.
-
-They might have expanded it to other parts of Instagram since then. I'm not entirely clear if it's being used more broadly than just the one profile page. But it, it, certainly the numbers and the results that they talked about back in October were very good. And they've had another five or, five plus months to try to iterate on this.
-
-Very encouraging to hear that this is progressing forward. Along with that, the React team said that the next official version of React will indeed be React 19. There will not be like an 18. 3 or 18. 4 minor release. I've, I've seen a number of people say that there are bug fixes that they wish would go out in a minor version, just to get them out sooner.
-
-I think I've seen some of the Remix Community talk about some bits and pieces that are in canary builds that they wish were already in a stable build. But certainly what I've seen over the last couple of months had been that they were working towards what they considered to be a React 19 major version, and this blog post confirms that is what they are actually planning.
-
-I do want to talk about the, a couple more bits about the React compiler. The most obvious thing that people will think about is that I don't necessarily need to put in the dependency arrays for things like useMemo and useCallback and maybe even useEffect. Because, you know, as the React team has said since Hooks first came out, if we just have a sufficiently smart compiler, It can figure out what variables you're actually using and fill in the dependency arrays automatically at compile time.
-
-But, the bigger thing, and this is the point that I've tried to make in our last couple discussions, is React has always had some built in optimizations if you memoize the JSX elements that your component returns. And so, the biggest benefit of React Compiler is that it will auto memoize chunks. of the elements that your component returns.
-
-So if your component returns, like, I don't know, three separate divs, and they depend on some combination of four or five different variables, it would auto memoize each of those chunks, so that the element only gets recreated when the input values change. And at that point, React's render optimizations kick in.
-
-And it just skips re rendering those child components, unless they change. You know, React has always had the mental model that we're actually gonna, we're gonna pretend like your entire application just got recreated every time. In practice, what it does is, when a parent component renders, everything inside of that renders by default.
-
-So you can kind of think of React Compiler as flipping that on its head. So that it's not just re rendering all children by default, but only children where their data actually changed. So, in a sense, it's actually kind of taking a common misconception and making that the default behavior.
-
-[10:14] **Carl Vitullo:** Yeah. Always good to if people hold expectations about how something will work, uh, nice to match that.
-
-This is a very high effort way to match people's expectations, but cool that they are confident enough in it working that they're starting to use it themselves on production apps.
-
-[10:31] **Mark Erikson:** And so Brad Westfall from the React training team had, or company, had a good post called React will be compiled, where he goes over some of the implications for that.
-
-Along with that, the React team has always been very big on trying to keep backwards compatibility. You know, you can still even use, you know, the original legacy create class API just as an extended package. React 19 will drop a lot of pieces that have been deprecated for years. They're finally killing StringRefs, they're killing LegacyContext.
-
-And a couple other pieces. Along with that, there's some iteration on how you're intended to use some of the existing functionality. Andrew Clark had a tweet where he's like, You know, we've got a lot of things that have been built in, but with React 19 and the compiler changes, You're actually going to access some of this functionality in a different way.
-
-So, you know, you won't have to worry so much about trying to memoize things. The compiler will take care of it for you. You won't have to use React. forwardRef because now components can just get ref as a prop directly. Apparently you won't need to use React. lazy much anymore. You can just have a promise that represents the component and put the promise directly in your JSX output as a child.
-
-The useContext hook will get replaced by the new use hook that accepts a context directly as an argument. It also will be the replacement for the undocumented but everybody knows about it technique of throwing a promise for triggering suspense. And finally, context objects themselves will now be considered the provider components that you render.
-
-So you can just render angle brackets, myContext. Instead of angle brackets, my context dot provider. Most of those are not huge changes. It's not like it's adding necessarily new functionality, but it is making some existing functionality nicer to work with.
-
-[12:33] **Carl Vitullo:** It really reduces the, you know, surface area of React's APIs quite a lot.
-
-Like, no more UseMemo, UseCallback, or the, you know, React. memo. The number of APIs that React exports is now dropping by like, what, six or seven? It's a lot. That's a lot. That's a lot fewer. Pretty cool.
-
-[12:55] **Mark Erikson:** And then, finally, the blog post talks about a lot of the features that they've been working on, especially in relation to suspense, and server actions, and forms.
-
-And, part of the reason why they came up with this Canary version release concept is they had features that were mostly ready, or close to being ready, and in theory, they were ready enough that frameworks like Next, or Remix, or, you know, something else, could make use of them, but they didn't have all the pieces ready yet, so they couldn't go into a public, stable release.
-
-They've had some of these new, you know, pieces like server actions, or the use optimistic hook, or use form status, available in Canary builds for a while. The key line from this blog post is that they said, the current set of features in React Canary are complete and ready for release. So that's actually a pretty big deal.
-
-One thing that I thought was interesting, which I hadn't really seen talked about anywhere else, and I did not actually understand the first time I read the blog post, React DOM is now going to support rendering metadata tags Anywhere in the component tree. And this means that if you render a title tag or metadata or link, number one, it'll automatically insert those into the head of the document.
-
-And two, you can render those from anywhere, which. As they said, basically replaces the need for a library like React Helmet. I have not had much need to do that myself in my own career, but it's, that's actually a pretty big deal to build in that kind of functionality. And along with that, they're adding support for suspense for things like assets, like script tags and style tags.
-
-So, there's a lot of moving pieces here, and it looks like a lot of this stuff is about ready for release. So that's pretty big news. And my assumption is that React 19 will probably either go final, or at least be in beta plus like a release roadmap at React Conf in May.
-
-[14:59] **Carl Vitullo:** Yeah, that seems like a safe assumption.
-
-They tend to make pretty major announcements at their conferences, so the lack of conferences for the last, what, four or five years? Yeah, definitely seems like Enough pieces have come together that they're comfortable saying like, yes, this is, here we go.
-
-Yeah. And on the React Helmet stuff, that is something I have had to do quite a number of times in my career. And pretty much every time I set up React Helmet, get bit by some bug, some weird quirk in how it works. Look for an alternative, find nothing, and then, you know, begrudgingly make do with whatever weird things React Helmet is doing.
-
-So this seems like a really great small tweak to make the experience of developing a new project in React just that much easier. So pretty excited for that.
-
-## A PR for Server Components support in Parcel
-
-[15:47] **Carl Vitullo:** Cool. All right. Let's talk about React server components, suspense, and server actions. There's a, an initial PR for parcel support for React server components. It looks like React Server Components needs like an external package to do things that I don't really understand because I have not looked at how you implement it from scratch in a framework.
-
-But so it looks like Parcel is now getting that support. So I think that's going to be the second. You know, Bundler that officially supports React server components. So that's, you know, going from one to two, that's a pretty major improvement here. But that's, that's pretty much all I know about it.
-
-[16:25] **Mark Erikson:** Got to have the Bundler build framework integration to actually hook up the pieces and make them do something useful.
-
-[16:30] **Carl Vitullo:** Right, yeah, this crosses a lot of boundaries, and one of the, one of those boundaries is from your app into however that app is being bundled into a production asset. So, do you want to introduce this blog post it looks like?
-
-[16:43] **Mark Erikson:** Yeah, so Sam Selikoff has done some, a couple different blog posts and talks related to how to actually make use of server components in more realistic applications.
-
-I haven't had a chance to go through this post in detail, but I saw Dan retweet it. So it's a discussion of how you would actually use server components and implement logic for things like filtering and displaying pieces and components and pieces of data, primarily based on search parameters. And so it goes through and shows examples of using a lot of the new pieces like some of the form state hooks, server actions, actually being able to control the behavior using suspense.
-
-So it feels like it's a pretty good example of how all the different pieces actually play together in practice. Super cool, yeah.
-
-On the flip side, I also saw a couple articles that are maybe just a little bit skeptical of how to use a couple of these pieces. One was an article called, Is Suspense Worth the Squeeze? And the author basically says, you know, suspense is useful, but in the end, like, showing loading states isn't necessarily, like, The greatest thing in the world. And it feels like, you know, maybe the React team's focus could have been better spent on some other things.
-
-This was at least a little bit more of like a technical set of complaints than some of the articles we've seen recently, where it's just like, I have bad vibes about React. So it's, you know, not necessarily like, you know, a big argument one way or the other, but I thought it was at least a little more of a reasonably technical focused.
-
-Similarly, there was another post called, Avoid using React's new UseFormStatus hook, where the author points out that you can only make use of the hook inside of a form component, and he had some use cases where he wanted to be able to deal with form status outside of the form tag.
-
-I think I also saw some discussion with Dan about this on Twitter, I don't have a link to it. Right this minute, but Dan's reply was that it was something about being able to properly compose pieces of the forms together as to why that limitation exists. So it's good, you know, discussion of, you know, some of the trade offs and understanding the actual limitations of available APIs is important.
-
-[19:01] **Carl Vitullo:** That reminds me of some of the things we've discussed about, like, context dependent APIs that React has started relying on. It seems sort of adjacent to the, you know, use server, use client directives, where you sort of opt into different behaviors in different parts of the tree. So, yeah, definitely having different bits of functionality only available in certain contexts, where it's not always super intuitive what those contexts will be.
-
-Yeah, that's a little bit funky.
-
-## react-strict-dom package
-
-[19:30] **Mark Erikson:** Moving on to the next section. There was another fairly big announcement from Meta within the last month. A new project called React Strict DOM. And this is really about taking React Native and giving it compatibility with web APIs. So let's back up and give a little bit of context on this one.
-
-You know, React Native came out in like 2014. It's, I think it's, it's been a while. Part of the principle of React Native has been, you get to use all the same concepts of React, you know, the components and state and rendering, but because it's targeted to native, and, you know, native could be Android, iOS, or even other platforms like Mac or Windows.
-
-React Native has its own set of abstractions. It doesn't use divs and spans and, you know, lowercase b buttons. It has its own abstractions like a view. And, you know, a view maps to whatever the underlying operating system primitive is for I want to draw a rectangle on screen and do something with it. And so you get to reuse the same concepts that you know from React DOM on the web, but the types of components that you render are completely different.
-
-And so there's been various attempts to make it easier to reuse code across both web and native platforms over the years. And one of the biggest ones was called React Native Web by, created by Nicholas Gallagher, I believe while he was originally at Twitter, and then he eventually left and went to Meta.
-
-React Native Web tried to recreate the names and types of the React Native components, but they rendered to DOM elements. So you would import capital V View from React Native Web in your web app, and you would render it, and on the web it would actually output a div instead. And so the idea is that you would always render a view instead of a div.
-
-And that made your source code compatible with both React Native on native platforms and React on web platforms. And so this is useful, but also had its limits. And so I believe this new project, React Strict DOM, has actually been worked on by Nicholas Gallagher and a bunch of other folks. And it basically takes the opposite approach.
-
-So rather than trying to make, to write web apps Where you're using something that looks like React Native component types. Instead, the goal is to make React Native look and feel more like the web. So they've been working to fill in, you know, various missing pieces of web compatibility behavior. And React Strict DOM gives you tags like HTML. div, and at usage time, those actually turn into a React Native view under the hood. So the idea is, you would now write your React components as if they were web based on both platforms. On the web, of course it outputs an actual div, and on native, it would actually map to a React Native view under the hood.
-
-So the idea is now, let's just pretend we're writing web style code everywhere, and it's just that on React Native it turns into the underlying native view instead. So this is brand new, but it sounds like it is actually being used in production at Meta, and it's gotten to the point where they felt they could open source this.
-
-[23:08] **Carl Vitullo:** I saw a tweet from Dan describing it as a spiritual successor to React Native Web, and like you said, you know, from the opposite direction, which makes a lot of sense. I, it, I have worked on React Native exactly once professionally. I tried to do a couple of side projects that never really got off the ground.
-
-It always struck me as just a little bit weird that like the view to div, you know, they're functionally almost exactly the same. It's just that one doesn't work and, they don't work in each other's contexts. So, trying to unify that just a little bit, trying to get rid of some of those weird edge cases that prevent compatibility from working. Yeah, sounds really cool.
-
-I had been really excited about React Native Web, what, five years ago, six years ago when it was new, but it just never really, never quite fulfilled the promise, the, you know, the vision that it had set out to. So cool to see another take, taking what people already do and making it compatible in the native context seems a lot easier than trying to get everyone to change how they write code to fit better with how React Native is authored. So yeah, pretty excited to see.
-
-Yeah, there was a great announcement thread from Lorenzo Sciandra, Kelset. Who, I think he works on this stuff. He's a senior software engineer at Microsoft working on React Native. Really great thread. Definitely goes into a lot of details, links out to a lot of great resources and RFCs and GitHub issues. So definitely check that out for a lot of details.
-
-There was also a wonderful compatibility chart showing the progress that they're, they've made so far. Look, it's a, it's a little bit rough at the moment. There, there's no green, but a lot of yellow and not too much red. So I think where the red is mostly on the, you know, more fringe side of HTML, although it looks like inputs are not super well supported yet, but I guess inputs are going to be tricky on. Just a little bit more functionality going on there, a little bit more behaviors to replicate.
-
-## Apple announce no more PWAs
-
-[25:09] **Carl Vitullo:** Cool. All right. I guess I'll move us on. This is a bit of a news, I don't know, a broader ecosystem news, but Apple has announced that they are dropping support from, for progressive web apps in response to regulatory challenges in the EU markets. I am pretty disappointed to see this. I had always, I've always been.
-
-Excited about progressive web apps. I love the thought of being able to author web applications in ways that are more meaningfully competitive in terms of user experience in a native context, you know, going back for years, Apple has not meaningfully supported a lot of the deeper functionality that would make this, more meaningfully, you know, work like a native application.
-
-Look, I dug deep on refreshing my memory of how these were, what the original vision for progressive web apps were and how it was meant to unfold. And in like 2014, 15, the Chrome team from Google really put out a lot of effort on doing a cross platform standard for essentially an app store.
-
-If there, you know, if you look at the MDN docs for the progressive web app manifest. It references a lot of things like, you know, screenshots and, you know, install methods. Where does this live? How do you access it? So this ultimately, Apple dropping support for progressive web apps, really it comes out of a series of lawsuits that have, that they, that have been unfolding in Europe around anti competitive behavior in the app store.
-
-You know, it kind of goes back to their 30%, you know, the Apple tax on all purchases in the iOS ecosystem. So, you know, the slightly conspiracy theory minded take on this is that fully supporting progressive web apps would meaningfully cut into their app store dominance. And so they had a strong disincentive from supporting them.
-
-So just, disappointing to see, if you are working on a progressive web app, especially in a European context, there's an advocacy organization called the Open Web Advocacy that is doing a, you know, action. So, if you are based in Europe and maintaining a progressive web application and would be impacted by this, definitely check that out.
-
-Going a little bit more, sort of broadly, back it up into, like, what is a progressive web app, why would this be meaningful? I think there's a lot of overlap there with local first as well. Um, just sort of the general idea of building a website that functions in ways similar to how people expect native applications to work.
-
-So for, like, local first, I think a wonderful example of that is, like, your email client. You know, Gmail on my phone, I can go in airplane mode and I can use it exactly as if I was online. I can archive things, I can recategorize them, I can draft replies, I can send things, and then once I'm back on network, it all works as I expected it to.
-
-So, the original vision for progressive web apps was providing a series of tools and platform features that enable that sort of thing. So, you know, the manifest is a way for web applications to say, these are the files I support. These are the, you know, domains that should open in this app.
-
-Then there's supporting features as well, like service workers. That's how you can provide a programmatic CAF from the web browser context. If they like, okay, if there's no network, here's how to respond. Unfortunately, mostly, it seems like the service workers mostly got used to serve 404 pages that look pretty, which like, okay, yes, that is something you can do with them.
-
-But it would be much more interesting if it would do synchronization of data in the background and queue up updates that you make while you don't have network. So I'm disappointed to see this. I had always been really excited for the potential of progressive web apps. And if this decision by Apple to meaningfully reduce support doesn't get changed, then kind of seems like a, maybe not the final nail in a coffin, but definitely a pretty big nail in the progressive web app coffin.
-
-Very sorry to see.
-
-[29:22] **Mark Erikson:** I haven't read through this in detail, but it seems like some of the claims are about, like, well, if we're, if you're forcing us to support multiple browser engines, we can't guarantee 100 percent perfect security and all the safety guarantees that we want to enforce on our own platform, but frankly, it sounds like, uh, well, if you're not going to let us do what we want, we're going to take our ball and go home.
-
-Kind of a temper tantrum.
-
-[29:44] **Carl Vitullo:** I'd agree with that, generally.
-
-All right in between recording this and publishing it, Apple has announced that they are actually changing tack and will be allowing home-screen web apps as they refer to progressive web apps which honestly is probably a better name.
-
-They're still going to be requiring that progressive web apps be authored in WebKit. So they're not allowing for alternate browser engines to fully integrate progressive web apps on iOS. They're claiming that this is to align with the security and privacy model for native apps. Uh, which to me, I interpret that as they have complete control over how notifications and device access work in iOS, and they're not going to give up any bit of that control to a third party, namely their largest competitor, Google. Apple's also very much in a very real way, hamstrung the way progressive web app notifications function in iOS for years now. They have never really made a serious effort at allowing developers to fine tune the user experience of how notifications are delivered. Which again I take as a subtle indicator that they don't like the operating model of a progressive web app because it is in competition with their other business interests. We're veering out of news and into, you know, I don't know, history, but there was a really great, somewhat satirical talk from 2013, given by Gary Bernhardt, called The Birth and Death of JavaScript, where he takes, it's sort of like a sci fi retrospective of JavaScript.
-
-So, yeah. He, he, he takes the perspective of someone in like 2035 discussing the arc of JavaScript and how it took over the world. And it's actually, it's a really good talk and it really got me excited about the potential for JavaScript in the world. And a lot of that really hit, I think it's very, it was very prescient and I think it got a lot of things very right.
-
-It has a funny bit where he, through the entire talk, pronounces it, "yava" script, uh, which I always found entertaining, but I would recommend that, um, I. Even though it's now 11 years old, um, I think it's, it talks a lot about like WebAssembly and the Browser taking over as the default runtime from the operating system.
-
-Um, it just, it, it, it takes a very broad, interesting perspective on programming and where we write apps and how they run. Definitely really interesting. And yeah, it's from the same guy who did that very famous "wat" talk with. you know, making fun of JavaScript. So definitely, definitely check it out. He's, I think he's been a little bit less active over the last 10 years, but he had a, he was very influential early in my career. So if I can direct any attention his way.
-
-## Next App Router: The Good, the Bad, and the Ugly
-
-[32:24] **Carl Vitullo:** All right, Mark, you want to take us on to talk about Next?
-
-[32:27] **Mark Erikson:** Sure. There were a couple of good articles that came out that discussed different companies attempting to migrate to Next and the Pages router and server components. And it's interesting to kind of look at them and compare and contrast some of the opinions and responses.
-
-So, Flight Control, which is a startup that does a different AWS dashboard, basically, talked about migrating some of their apps over to the app router. They had a number of things they did like. Layout and loading states. And some of the data loading patterns that they were able to use. They also ran into a lot of problems.
-
-They felt that they had to kind of duplicate data fetching code in order to handle live updates on the server. They didn't like issues like lack of routing type safety or some error handling situations. They really struggled a lot with the performance of the development mode server. I saw Brandon Bayer, the founder.
-
-Complaining about this repeatedly on Twitter, and asking, like, what can we do to try to speed this up? And, I know at the time that they were on the Next 13, I think he later said they did switch to Next 14, and it didn't seem to get any better. So, whatever specific problems they were running into with the speed of the dev server and memory usage, They considered those to be really major pain points.
-
-One of the comments in the article was it was marketed as production ready way too early. And it's been, it's a year later and we're still running into all these sorts of issues. So their final conclusion was, we would actually choose Remix if we could have gone back and started over.
-
-There was another article from a company called Medusa where they switched over their own next starter template to use the app router and server components. Medusa is apparently an e commerce framework. Their response, their opinion seems to be fairly positive overall. They thought that, you know, data fetching and caching was pretty good. They liked being able to use server actions to update state on the server. Talked about some different cases like static pre rendering and managing server versus client components.
-
-So they said, you know, it does take some getting used to, but, you know, once you switch over to it, it actually feels pretty natural. So, you know, always good to see some real world examples of people actually train these out in practice.
-
-[34:48] **Carl Vitullo:** Yeah, super cool. I see that Medusa post also talks about moving state to the URL, which I have worked on a couple of apps that did that, where they meaningfully kept application state up to date in the URL as you click around and navigate.
-
-The first time I worked on an app that did that. It just, it blew my mind. It was like, oh my God, every app should do this because then you can share, you can, you know, get the app into a certain state and then send it to somebody and they can, you start using the app from exactly that state. Really interesting concept. So cool to see it discussed in the context of Next 14. Cool. Cool.
-
-## Remix 2.6, 2.7
-
-[35:22] **Carl Vitullo:** I'll move us on to Remix. Like I said earlier, they put out two minor versions. There's 2. 6, which looks like it's mostly a sort of bookkeeping release where they, they made a breaking change to the unstable Vite plugin. So I guess. There you go. There's a minor release necessary to do that.
-
-2.7, they shipped VEET support, so they are now calling their, you know, internal usage of VEET stable, which also unlocks their single page application mode, which is pretty cool. That seems like it makes it meaningfully compete with Well, I don't know.
-
-I don't know. It's interesting to see. I was going to say meaningfully compete with something like Astro or Gatsby, but you know, actually, no, it's not quite that. It's not static generation. It's a single page application. That's a new context. Single page application is still like, I know the enthusiasm for that mode of publishing has dropped off in the last, you know, two or three years, Jamstack and all that kind of stuff has kind of lost mindshare, but it's still the simplest way to ship a web application.
-
-You know, if you're going to be hosting something, putting up static assets and letting it, you know, render entirely in somebody's client browser is lowest cost, lowest number of moving parts way to ship a product. So definitely still has use cases, I think. So cool to see Remix adding support for that.
-
-There was also an interesting feature that I don't quite know if I fully understand, but they called it server bundles, which looks to be support for basically sharding out a backend into multiple servers. So it looks like you can, at build time, communicate to Remix that this part of the backend. needs to be isolated from this other part of the backend.
-
-I could be mis explaining that, so don't take my word as gospel on this. I have not played around with it extensively. They mention that if you make use of this feature, you need to have something in place in front of Remix to direct the traffic and make sure that the correct backend gets, or rather, that the correct bundle gets the requests it expects.
-
-So it seems like, you know, a very niche feature that, like, large teams, large products with a lot of engineers making changes, a lot of performance characteristics to fine tune will need to take advantage of. So that seems cool. You know, one way of, I don't know, dealing with growth.
-
-It also looks to support a React router feature for base names, which is basically just a pre pended route segment. So you can say, this entire web app lives under this part of the path, and then, you know, routing will still work. That is something I have done a couple times in my career, and it has been fiddly every time. So, nice. Good to see.
-
-They also open sourced Remix. run, the, you know, Marketing website for the whole project. So that's pretty cool. They discuss some of the trade offs of, you know, why wouldn't you open source a site like this? Why would you want to? And I guess, why would you want to is basically open source is good and making the website code available is great. Uh, and why wouldn't you want to is sort of vague security risks and, you know, risk of leaking information and things like that. Nice to see the code for the site getting released.
-
-They also put up some good first issues on their, on the GitHub. So if you are looking to bust an open source, there's. There's some options.
-
-## State of React Native
-
-[38:44] **Carl Vitullo:** Moving on to our next set of links. There's been some good stuff coming out for React Native. Software Mansion, who does, they're, they're a consultancy that does a lot of React Native work.
-
-They maintain quite a number of open source projects. I always see them coming up in discussions of new React Native projects. They put out a state of React Native survey, similar to the like state of JS, state of React, state of CSS. But not organized by the same people, just to be clear.
-
-They had like 2, 500 respondents, it looks like. Just going to run through some quick stats here. Like two thirds of those have a higher ed degree, which I was a little surprised by. I thought it would be, as someone without a bachelor's degree, I. Was just surprised to find myself in such a small minority. One sixth of their respondents have no degree at all.
-
-It looks like the median, you know, I, this is a bit of a guess, I didn't have access to the data, so I'm just kind of like looking at percentage respondents. It looks like about the median engineer who responded has two, between two and six years of experience with React Native. Between five and 11 years of experience professionally programming in total, and 95 percent of the respondents were male over half between 25 and 34 years old.
-
-Top three industries represented here, finance, education, entertainment, with below then was consulting, social media, and web three, and. Something I found interesting, the vast majority of respondents, like well over 50%, work on a team with less than five engineers. And one in four people who responded to this survey are solo developers.
-
-So pretty cool to see. Just, I found those, you know, demographic Breakdowns of who is using React Native and how are they using it to be pretty interesting, just macro level. What's going on? But yeah, state of React Native survey definitely has a lot of really cool details that I did not get into. Lots of stuff about usage and opinions and what supporting libraries are being used, what features are being taken advantage of, what aren't. So that was pretty cool.
-
-## React Native Frameworks RFC
-
-[40:41] **Carl Vitullo:** Also a bit on react Native Frameworks. It looks like there was, I was a little bit confused by this, it seems, as I was reading through it, I guess they're more sharply defining the boundary between React Native and Expo.
-
-I'm not sure that there's another Similar framework to Expo. As I was reading it, I was thinking like, Oh, would like React Native web fit into this, would, you know, the React Native Windows, React Native Mac, you know, the VR support and all that, but it looks like they don't. Those are not frameworks by this definition.
-
-So I believe the only framework this is, you know, connected to defining would be Expo. The rest of those are, all of the other runtimes are described as an out of tree platform where, you know, tree there references the Git repo. So React Native. It has first party support for iOS and Android and everything else is an out of tree platform.
-
-So, this is interesting, it just seems like they're being a little bit more thoughtful and proactively communicating about responsibilities, saying, we are responsible for this, and a framework like Expo is responsible for this category of things. So, it seemed like a minor, but significant shift. in how things are, I don't know, defined (chuckles). Seems cool.
-
-[41:59] **Mark Erikson:** That was basically my takeaway. I mean, I think with the general React emphasis on, you should be using React built into a framework and most of the framework's being web focused, I think the React native side of the house was trying to get ahead of the game a little bit and say, Okay, here's what that would look like on our side if anyone else tries to build an RN based framework.
-
-[42:19] **Carl Vitullo:** I'd agree with that. It does seem like a compliment to, like, how Remix and Next are shaping up, but we don't have a sharply defined criteria for what is a framework responsible for in React. So, hey, maybe this is a proof of concept. Maybe we'll see something like that in the web context too. Ha, we can dream.
-
-Cool. One more thing to share on React Native, there is semi official support for. The Vision OS, which is pretty cool. Always cool to see. I'm impressed at how quickly they got that out. I got to say, it looks like they started working on it in June, 2023. They got a group of concept working in like compatibility mode, but that was like super stripped down, like technically it worked, but you could not, you know, the, what it, what behaviors it supported were, the list of that was very short.
-
-So this is now a much more full featured way of writing apps on the Vision OS with React Native. They described it as essentially a fork of the React Native core, which, whoo, that's a lot of work, haha. And something I found pretty cool, pretty impressive, is they got it working without even having access to a hardware device.
-
-So this is all just on the Vision Pro Simulator. Like, wow, that's hard, haha. All right, that's all of the main news items we, we have so far. Mark, take us away with the first lightning round.
-
-## ⚡Bun shell support ⚡
-
-[43:34] **Mark Erikson:** All right. So the Bunn JavaScript runtime has announced that they now have built in shell support. You know, it's always been kind of hard to kick off.
-
-external programs from within a, like a node JavaScript application. Like you can do it, but you have to call, you know, functions that capture standard in, standard out. And it's, it's not really ergonomic or intuitive. So bun now has a built in dollar sign variable. And when you use it, you just pass in like a command that you would have run in a bash shell, like, you know, LS star dot JS, or, you know, the infamous RM dash RF.
-
-And it just automatically executes it and hands back the results as a nice neat async await. I've actually got a little bit of prior experience with something like this. I had used a Python package years ago that did something very similar. So you could write Python scripts that It felt very shell scripty in terms of executing other commands and getting the output back. So I can definitely see some nice advantage of this.
-
-Working with scripting in a language like JavaScript is a lot nicer than dealing with Bash. The issue here is that being able to use commands like ls or rm, assume that you're running inside of a Bash shell. Which normally means that you're running on Linux or Mac, because Windows doesn't have those by default.
-
-A lot of people, like myself, might be using a WSL Linux environment on Windows, or at least the Git Bash version ported to Windows. But they've apparently gone and polyfilled a lot of the common shell commands you would be using, as well. This is not the first attempt to do that. There's an existing library called Shell. js, which provides JavaScript only implementations of common bash commands. I believe the Yarn package manager has already done something similar as well, so that you could, I believe, I haven't looked at this in a while. But I believe if you're using scripts in your package. json, Yarn will automatically fill in some commands like rm or setting environment variables to be cross platform and work on Windows and not just on Linux or Mac.
-
-So there's some prior art here, but it's nice to see this built into Bun.
-
-[45:46] **Carl Vitullo:** Yeah, super cool.
-
-## ⚡Deno 2023, 2024 ⚡
-
-[45:46] **Carl Vitullo:** The Deno team had a pretty cool looking Summary of what they've been up to in 2023. And I'm just going to roll straight into, they also did a blog post about their, they did a survey and announced a bit of a roadmap for 2024.
-
-They're targeting a major release this year, which they say will offer, third party framework compatibility, the ability to use any npm module, and all while having the best in class developer experience.
-
-I love all the explosion of alternate runtimes that we've been getting. I remember watching the Deno talk a couple years ago and just thinking that it was a really interesting take on What did we get wrong in Node?
-
-Deno is from the originator of Node. So he, this is very much a take two on a JavaScript runtime on the server. So I, I've been following him pretty closely just to see what's going on there.
-
-## ⚡JSR.io ⚡
-
-[46:35] **Carl Vitullo:** I guess I'll roll straight into another one that I had queued up for later, but it's closely related.
-
-The Deno team is doing a new JavaScript registry called jsr. io. I just got access to it and it seems pretty neat, I gotta say. For one, it's ESM only, so there's There is no longer going to be a CommonJS option for publishing to this registry, which that alone has me interested. The CommonJS vs.
-
-ESM split has been an absolute nightmare and a huge blight on the JavaScript ecosystem. So, that alone seems like a pretty good reason to try a new registry. It does look like they are starting from scratch. Um, I have I poked around just a little bit, and I don't see any familiar modules published there, but I'm excited to see where it goes.
-
-It's waitlisted right now, so if you are, if that sounds interesting, hop in the waitlist. I got off of it in like two or three weeks, so I have no idea what that means. But yeah, Deno, a lot of stuff going on.
-
-[47:36] **Mark Erikson:** I know I saw an article or two somewhere that was talking about using it.
-
-I think one of the interesting changes is it looks like they actually want you to just publish your TypeScript source code and the registry takes care of doing the compilation, I think, was something I saw. That would be a very significant change.
-
-[47:57] **Carl Vitullo:** Yeah, oh that's super cool.
-
-## ⚡How Hot Module Replacement works⚡
-
-[47:59] **Mark Erikson:** Alright, next up, there was an article talking about how are the hot module replacement feature is actually implemented inside of the Vite bundler.
-
-This is long, it's detailed, frankly this is all information you will never need to know in order to use or build applications. But it's a really good article that actually digs into the technical details of what does it take to implement the, you know, you know, module graphs and swapping and all the specific APIs that actually make hot module reloading possible.
-
-[48:29] **Carl Vitullo:** Yeah, really good post. I love deep dives into obscure parts of the ecosystem.
-
-## ⚡pmdrs WebGL uikit⚡
-
-[48:33] **Carl Vitullo:** Cool. The, the Poimanders, never quite sure how to pronounce that. They shared a fully functional WebGL UI rendering engine. It seems pretty cool, it's basically a layout engine for React 3 Fiber, which is pretty neat. If you're trying to work in WebGL, like that's about as close to bare metal as you can get in the browser from a, you know, like rendering engine side of things, you know, set aside web assembly and whatever you, so, but just like.
-
-Any kind of layout, you don't get any support for. So, pretty interesting to see somebody taking advantage of work done on React Native, actually, because this relies on the Flexbox engine that was built in order to facilitate React Native, the Yoga layout engine. So, super cool, definitely check that out if you are experimenting with WebGL on a side project.
-
-Should make some of these things a little bit easier.
-
-## ⚡Updates from the 100th TC39 meeting⚡
-
-[49:25] **Mark Erikson:** Alright, and the last item on the list is some updates from TC39 as potential new JavaScript syntax features make their way through the pipeline. Not a lot of huge news here, a lot of items at stage 1. There's a proposal called Promise. try, which is basically like a, almost, like a try catch for running any kind of function, sync or async, and getting back a promise for the result.
-
-One other thing that I saw, let me go find the details on this. I believe I saw mentioned that they've actually added a new stage number to the TC39 process. So traditionally it's been like stage 0 is just, we have an idea, stage 1 is we've proposed the idea. Stage 2 is, we, we think this idea could work, but it needs to be fleshed out. Stage 3 is, this basically works, we've got it implemented in a couple browsers, it's just Nailing down the final details and then stage four is it's good to go.
-
-They've actually added a new stage, which is, and this appears to be a real official thing, Stage 2.7 because it's more than stage two, but less than stage three. And I think I actually saw a comment that stage 2.7 is a little bit like what stage three used to be and now stage three is slightly more involved. This actually appears to be a real Thing.
-
-[50:46] **Carl Vitullo:** I love that. It's more than halfway, but. Cool.
-
-Alright, that's all we got. Thank you so much for joining us. We'll be back on the last Wednesday of the month here in the live stage of Reactiflux or back in your podcast feed just as soon as we can.
-
-We gather sources from all sorts of newsletters like React Status, bytes.dev, Next JS Weekly, React Digest, This Week in React, love that one, as well as like the React JS subreddit, here in Reactiflux. We do check the #tech-reads-and-news channel. So definitely if you see any news coming out, let us know. Put it in that #tech-reads-and-news channel, or if you like, you can send it to hello@reactiflux.Com. But make sure to include TMIR in the subject line. It's an acronym for the show.
-
-And we are starting to professionalize. We're trying to grow and find some sponsors. So if this is a show that you get value from and want to support, best way to do so is by giving us a review or telling your friends about it.
-
-Thanks so much. Excited to see what happens in March. Bye all.
diff --git a/src/transcripts/tmir-2024-03.md b/src/transcripts/tmir-2024-03.md
deleted file mode 100644
index 57461a9..0000000
--- a/src/transcripts/tmir-2024-03.md
+++ /dev/null
@@ -1,495 +0,0 @@
----
-title: "This Month in React, March 2024: React canary is 19, New ShadCN bits, Astro looks like Wordpress. Wiz??"
-date: 2024-03-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick Hits
- - [[00:39](#layoffs-seems-better)] [Layoffs.fyi](https://layoffs.fyi/)
- - [[01:20](#new-releases)] New releases
- - [React Native 0.74.0?](https://github.com/facebook/react-native/releases) Soon
- - [New Architecture docs page](https://reactnative.dev/docs/the-new-architecture/landing-page)
- - [TS 5.4](https://devblogs.microsoft.com/typescript/announcing-typescript-5-4/)
- - [“This is how most dependency injection in React apps should be done”](https://twitter.com/sebmarkbage/status/1765828741500981475) says Sebastian Markbåge
- - [Remix 2.8](https://github.com/remix-run/remix/blob/main/CHANGELOG.md#v280)
- - [Mantine v7.7.0](https://mantine.dev/changelog/7-7-0/)
- - [Rsbuild 0.5](https://rsbuild.dev/community/releases/v0-5)
- - [Gleam version 1](https://gleam.run/news/gleam-version-1/)
- - [[05:58](#shadcn-march-2024-update)] [ShadCN March 2024 update](https://ui.shadcn.com/docs/changelog)
- - [[06:55](#astro-45-astrodb)] [Astro 4.5](https://astro.build/blog/astro-450/)
- - [Astro DB](https://astro.build/blog/astro-db/), [Astro DB Deep Dive](https://astro.build/blog/astro-db-deep-dive/)
-- [[09:58](#upcoming-conferences)] [Upcoming conferences](https://react.dev/community/conferences)
- - [Epic Web Conf 2024](https://www.epicweb.dev/conf) April 10 - 11; Park City, UT, USA
- - [React Miami 2024](https://reactmiami.com/) April 19 - 20; Miami, FL, USA
- - $50 off a ticket: `reactiflux4ever`
- - [React Connection 2024](https://reactconnection.io/) April 22; Paris, France
- - [React Native Connection 2024](https://reactnativeconnection.io/) April 23; Paris, France
- - [Post/Con 2024](https://www.postman.com/) April 30 - May 1; SF, CA, USA
- - [React Conf 2024](https://conf.react.dev/) May 15 - 16; Henderson, NV, USA
- - [App.js Conf 2024](https://appjs.co/) May 22 - 24; Kraków, Poland
- - [Local First Conf 2024](https://www.localfirstconf.com/) May 30; Berlin, Germany
-- [[10:58](#react-19-and-react-compiler)] React 19 and React Compiler
- - [Feature flags PR - “Canary now represents React 19”](https://github.com/facebook/react/pull/28647)
- - [React 19 won’t include Compiler](https://twitter.com/en_JS/status/1760433969118769654)
- - [React Compiler & React 19 - forget about memoization soon?](https://developerway.com/posts/react-compiler-soon)
- - [“Compiler Theory and Reactivity”](https://www.recompiled.dev/blog/ssa/) and [“Type System”](https://www.recompiled.dev/blog/type-system/)
- - [Its-fine](https://twitter.com/0xca0a/status/1766032105807483261)
- - [sebmck and drcmda GitHub exchange](https://github.com/facebook/react/pull/28524#issuecomment-1992607052)
-- [[20:02](#react-strict-dom-why-is-it-so-great?)] ["react-strict-dom", why it's so great?](https://szymonrybczak.dev/blog/react-strict-dom)
-- [[23:42](#server-components-updates)] RSCs
- - [Conceptual Model of React and RSC](https://ondrejvelisek.github.io/conceptual-model-of-react-and-rsc/) Ondrej Velisek
- - [Why React Server Components Are Breaking Builds to Win Tomorrow](https://www.builder.io/blog/why-react-server-components) Vishwas Gopinath
- - [Waku has released a “pages router”](https://waku.gg/blog/introducing-pages-router)
- - Lee Robinson’s [List of projects experimenting with RSCs](https://twitter.com/leeerob/status/1772651496544317804) , including Redwood ([which just released an RSC beta](https://redwoodjs.com/blog/rsc-now-in-redwoodjs))
- - [Embracing the Future and Moving Back Again: From Server Actions to tRPC](https://documenso.com/blog/removing-server-actions)
-- [[29:06](#apple-walks-back-on-pwas-neat-safari-features)] [Webkit features in Safari 17.4](https://webkit.org/blog/15063/webkit-features-in-safari-17-4/)
-- [[33:05](#mental-health-in-open-source)] [Mental Health in Open Source](https://antfu.me/posts/mental-health-oss)
-- [[37:20](#angular-meet-wiz)] [Angular codebase is being merged with Wiz](https://twitter.com/sarah_edo/status/1770478763253379488?t=zbCMEoxUsXuLGYtqt3ik8w&s=19)
- - [Announced at NGConf 2024](https://youtu.be/nIBseTi6RVk?t=1869)
- - [[38:49](#designing-very-large-javascript-applications)] [Designing Very Large Javascript Applications](https://www.industrialempathy.com/posts/designing-very-large-javascript-applications/)
- - [Malte Ube discussed in 2018](https://twitter.com/cramforce/status/958696304149868545?t=ETSaJnj2aX9Dnw_yPXgWBA&s=19)
-- ⚡Lightning round ⚡
- - [[43:56](#interaction-to-next-paint-new-core-web-vital)] [Interaction to Next Paint (INP) is a Core Web Vital](https://web.dev/blog/inp-cwv-launch)
- - [What is INP and why you should care](https://blog.sentry.io/what-is-inp/)
- - [[44:56](#rspack-charts-a-path-to-10)] [Rsbuild 1.0 release plan](https://github.com/web-infra-dev/rsbuild/discussions/1678)
- - [[45:42](#remix-might-merge-react-router-in)] [React Router and Remix to be merged?](https://twitter.com/ryanflorence/status/1767560366027129211)
- - [[46:08](#declarative-shadow-dom-in-all-major-browsers)] [Declarative Shadow DOM available in all major browsers](https://www.mayank.co/blog/declarative-shadow-dom-guide)
- - [[47:05](#react-native-community-map)] [React Native community map](https://github.com/kelset/react-native-community-map)
- - [[47:34](#nodejs-2023-year-in-review)] [Node.js 2023 Year in An Article](https://blog.rafaelgss.dev/nodejs-2023-year-in-review)
- - [[48:57](#tailwind-preview-of-40)] [Open-sourcing our progress on Tailwind CSS v4.0](https://tailwindcss.com/blog/tailwindcss-v4-alpha)
- - [[49:26](#vercel-adds-remix+vite-support)] [Vercel adds support for Remix+Vite](https://vercel.com/changelog/support-for-remix-with-vite)
- - [[50:05](#navigating-the-future-of-frontend)] [Navigating the future of frontend](https://frontendmastery.com/posts/navigating-the-future-of-frontend/)
-
-[00:00] **Carl Vitullo:** Thanks for joining us for March's This Month in React! Coming to you live from Reactiflux, the Discord for React professionals. I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux.
-
-[00:13] **Mark Erikson:** Hi, I'm Mark Erikson. My day job, I work at Replay. io, where we're building a time traveling debugger for JavaScript, and outside of that, I do Redux stuff.
-
-[00:22] **Carl Vitullo:** We got a lot of good stuff to discuss and digest here. Lot more details coming out for React 19. We got TypeScript 5. 4, and lots of interesting stuff kind of at the margins. Not really core tools or libraries within React necessarily, but a lot of things all over the place.
-
-## Layoffs (seems better!)
-
-[00:39] **Carl Vitullo:** I'm going to start off with some layoffs news. At time of recording, you know, it's the 27th, so we'll have to see if anything else happens, but layoffs.fyi is showing 33 companies with layoffs, which is the fewest layoffs by count in that way in close to two years, since April 2022. So nice to see that number go down.
-
-[00:58] This month has about 7, 200 laid off so far, which is on the lower end, it's not the lowest of the last year, but it's towards the lower end of the average range. Last March, so one year ago, there were 122 layoffs with about 38, 000 affected. So, 33 layoffs with about 7, 000 affected is a large decline, so that's nice. That's pretty good.
-
-## New releases
-
-[01:20] On to some new releases. We have a pretty big list this month.
-
-[01:23] **Carl Vitullo:** We've got some news from React Native. They are going to be putting out a 0. 74 release soon. They've had a really cool post up , or I guess like a docs page, talking about their new architecture. Not a ton of super concrete items coming out in there. But they did talk a lot about the general new architecture, re architecting how React Native works. We're going to talk a little bit about some of that, too, later on, talking about React Strict DOM, that package that they released last month.
-
-[01:53] Moving on a bit, TypeScript 5. 4, sounds like it's not a huge release, but One thing that I thought was super notable, worth taking note of, they are recommending against using the compiler options paths configuration flag in favor of package. json imports. Since you use the paths for import aliases, moving that out of a TypeScript specific configuration option and into a general module configuration option I think is absolutely phenomenal.
-
-[02:23] Getting that standardized I think is going to simplify a lot of things.
-
-[02:26] **Mark Erikson:** It's particularly interesting because I've seen other tools actually start to use TypeScript's own paths option as the source of truth. So, I guess, you know, switching over to a package. json setup is making it more tool agnostic, in a way, but the question as always is, how long will it take for other tools to also support that kind of configuration?
-
-[02:47] **Carl Vitullo:** I am just excited to see something go out from, I don't know, kind of move from TypeScript into standards, but yeah, generally seems like a quieter release.
-
-[02:56] NoInfer is one of the biggest things they called out and sounds like it's mostly useful in library contexts. Mark, you did point out something coming up in 5. 5 that looks really interesting though, you want to introduce that?
-
-[03:10] **Mark Erikson:** TypeScript has the idea of, I'm always a little hazy on the terminology, typeguards or predicates, which are functions that take some object and you assert at the type level that if the function returns true, then the type of the value must be this thing.
-
-[03:25] And so it's a way to mix together control flow and telling TypeScript what a thing looks like at compile time. And the problem is that when you do an operation like array filtering, that has not actually done the type narrowing that you might expect. So, you might be filtering to ensure that, you know, the returned array only contains real values and removes null or undefined, but TypeScript wouldn't actually pick up on that so far.
-
-[03:51] And so you might have to do, like, an extra cast or some other check to make sure that the output array has the correct type. Well, TypeScript 5. 5, which should be out in a few months, actually now has a PR merged that uses TypeScript's existing inference in new ways inside of filter functions so that you can do normal logic when filtering and TypeScript will try to narrow down the returned array type based on the logic in the filter callback.
-
-[04:18] It's not a huge deal, but it's gonna be a nice little quality of life thing. And then I also saw a tweet mentioning that the TypeScript team is continuing to do work on the publishing process to try to shrink the install size. I think as of, like, TS 4. 9. Installing TypeScript was around 50 megs. They did a lot of work with TS 5. 0 to change their internal setup, which dropped it to like 30. And it looks like as of 5. 5, it might be down to 20 ish or so. So, you know, hey, smaller install size, always a good thing.
-
-[04:50] **Carl Vitullo:** Much, much later, I'm going to talk a little bit about a Node. js 2023 year in review, and that has the opposite trend. It has a chart in there showing the binary size for the Linux binary for Node. js, and it is much, much larger than it used to be. So, good to see that TypeScript is going the other direction. Maybe they can cancel each other out a little bit.
-
-[05:09] I'm just going to run through a bunch of other releases pretty quick.
-
-[05:12] Remix released 2. 8. Looks like it's just a bunch of minor changes, configuration stuff.
-
-[05:17] Mantine has 7. 7 out. I didn't see any changes in there that really jumped out to me. It looks like a bunch of new components, a couple new hooks. useStateHistory looks neat, undo is always a challenge.
-
-[05:29] RSBuild released a version, 0. 5, which they say it's most of a 1. 0 release that will happen approximately in Q3 of this year, but it'll be much, much later this year.
-
-[05:40] I saw a cool fringe language inspired by Elm. Gleam, released a version 1. First stable release of a new experimental language. I always need to see how people play around with different languages. It says it's inspired by languages such as Elm, OCaml, and Rust. Experimental languages. Lots of stuff going on there.
-
-## ShadCN March 2024 update
-
-[05:58] **Carl Vitullo:** Okay, here's another big one. We've got some ShadCN new updates. They put out a March 2024 update, which is the first time they have done one of these update posts since I think December. So definitely worth calling out. It looks like the single biggest new thing that they have is blocks, they call it.
-
-[06:15] Which looks like it's basically template pages for very common and like very low differentiation application pages like a settings UI, or two factor, an authentication page, some other things like that, so it's basically just, copy these out, use it yourself. It looks neat. It looks exactly like every instance of those pages that I've done many times over my career.
-
-[06:36] So having a nice copy paste target for that is, seems super helpful. They also had one for an input one time password, like the classic, you know, paste in these six digits and it will appear in nice pretty blocks. Again, something I've implemented many times and there's never any variation, but for some reason you can never use the last one you did, so nice to see that.
-
-## Astro 4.5, AstroDB
-
-[06:55] **Carl Vitullo:** One more big one here that I'm just going to kind of blast through because I find it interesting. So Astro, the static site generator, I guess. I don't know if that's quite accurate, but.
-
-[07:05] **Mark Erikson:** Close enough for now.
-
-[07:07] **Carl Vitullo:** They released 4. 5, improved developer experience, a dev audit UI for site performance and accessibility issues, which is cool. They are announcing that they're offering a hosted database in conjunction with their site generation, the site building tool. They're calling it "the database platform for content driven websites" and also describe it as "Astro DB is a fully managed SQL database designed exclusively for Astro." it's got Drizzle built in and uses LibSQL.
-
-[07:37] Apparently Lib SQL is a fork of SQLite, which, they posted a deep dive that goes into a lot of the sort of the history and how this whole thing unfolded. And they talk about trying to make it work spring of last year with SQLite, but they ran into constraints with the fact that SQLite relies on compiled components within it, the C native code produced performance constraints that didn't really work very well within serverless environments. So they then tried again with this fork of SQLite that does not use those same native compiled, subcomponents within it. that's super cool, I think this is neat.
-
-[08:11] It sounds like they're very much positioning themselves as a WordPress competitor. So it's, you know, content driven websites with an included database. Like, that sounds like WordPress to me. So I think that's pretty cool. Astro's been doing a lot of things, this really does seem like a substantial change to the core offering.
-
-[08:29] **Mark Erikson:** And purely from a technical perspective, it is interesting to see that there's been a number of tools and services that are being built using SQLite as more than just like a local datastore as of late.
-
-[08:40] I think Cloudflare Durable Objects, are built on SQLite. You've got this AstroDB, I think I've seen a couple other tools as well. A lot of tools that are basing themselves around SQLite in some way.
-
-[08:52] **Carl Vitullo:** Yeah, definitely. I read a really good blog post talking about why SQLite makes sense in a lot more contexts than we've generally given it credit for.
-
-[09:01] And, yeah, it seems like people are really experimenting in real meaningful ways with different places to use it, which I think is awesome. I think it's a great project. You know, co locate your database with your executing code because it's small and fast, keep it a single binary.
-
-[09:15] Yeah, this is not quite directly related, but while we're talking about databases, I also heard about, PGLite, which is a Postgres implementation packaged as a WASM module, which, that's neat.
-
-[09:27] It's not quite SQLite, but if you need a database in your browser app, it seems like a cool new option.
-
-[09:34] **Mark Erikson:** There's probably also some kind of application for, I don't know, running end to end tests in the back end with that as like an in memory database or something like that?
-
-[09:43] **Carl Vitullo:** Yeah, that's actually, that blog post I mentioned about SQLite, that was one of the things that they've said that SQLite has been relegated to just being like the test database because it's, you know, super fast and, you know, super easy to spin up. So, yeah. Definitely makes sense in those sorts of contexts.
-
-## Upcoming conferences
-
-[09:58] **Carl Vitullo:** Blasting through conferences.
-
-[09:59] Epic Web is coming up April 10th and 11th in Park City, Utah.
-
-[10:03] React Miami, Mark and I will both be there, is April 19th. We actually have a discount code. So if you are interested in going to React Miami, make sure to, one, get your ticket soon, cause it's in like three weeks, and get your ticket with the code REACTIFLUX4EVER with number 4.
-
-[10:21] Very much looking forward to that though. There's React Connection and React Native Connection on April 22nd and 23rd in Paris.
-
-[10:27] **Mark Erikson:** And I will be speaking there going straight from Miami.
-
-[10:30] **Carl Vitullo:** Haa, wonderful, yeah, 20th to 22nd, that's a quick turn for an international flight across the Atlantic.
-
-[10:36] There's PostCon April 30th and May 1st. That's from Postman. So they're doing like an API conference, they're calling it.
-
-[10:42] And then the big one, React Conf, is happening May 15th and 16th in Henderson, Nevada, just outside Las Vegas. Cool.
-
-[10:50] Alright, whew, we finally made it to the main bulk of the content. Yeah, Mark, you want to take us off with our first set of discussions?
-
-## React 19 and React Compiler
-
-[10:58] **Mark Erikson:** Alright, so there's a number of pieces of news around React 19 and the React compiler tool that was announced a couple months ago. So first off, I saw a PR go up just a day or so ago. React's codebase has lots of feature flags because they build React for many different use cases. There's internal Facebook builds, public open source builds, React Native builds, experimental builds, canary builds, lots of different combinations.
-
-[11:23] And so the React team is constantly adding new feature flags, altering the feature flags, changing the default value. And so this PR makes it sound as though what's in Canary right now is what's expected to go into React 19. So that sounds like a, you know, fairly meaningful step towards a potential React 19 release.
-
-[11:43] Also, if you've just been keeping an eye on the list of pull requests in the repository, there have been a ton of internal cleanup PRs where they've been changing over a lot of the existing tests to actually use some of the more modern React APIs, like, uh, React on client slash render, instead of the old React render, et cetera.
-
-[12:01] One thing that wasn't entirely clear from the React labs blog post in February is that React 19 and React compiler are not directly tied together. They're both things that are in progress, but React compiler is a separate project. And it probably will come out sometime after React 19 is released. So, different projects, separate schedules, but still both very much in flight.
-
-[12:29] Speaking of React Compiler, there's been a couple good posts discussing how it works and what practical effects it'll have. Nadia Makarevich has done multiple great blog posts about React rendering somewhat similar to the post that I had written a while back. And she put up a post talking about React 19 and React Compiler and, you know, some of the practical benefits like not having to write code that does a lot of your own memoization logic because the compiler will do it for you and it will help with rendering performance.
-
-[12:59] And then, Satya, who is on the actual React compiler team, and has popped in and hung around Reactiflux a decent amount, put up a couple really good posts talking about the internal implementation details of the compiler itself. The compiler is currently exposed to the world as a Babel plugin, but that's more for ease of integration with the existing build tool ecosystem.
-
-[13:24] The way I understand it is that the Babel plugin basically acts as just kind of like an outer shell and then all the real logic is like a full blown compiler from scratch that the Babel plugin kind of forwards everything to.
-
-[13:38] So, you know, perhaps at first to make use of it. You would need to have Babel set up, but with the way they've got it designed, they would eventually be able to, you know, maybe expose it as, you know, an SWC plugin, or its own standalone tool, or something like that. Also, sort of tied to React 19, there was, I don't know, maybe controversy is a little strong, but kerfluffle? Annoyance? Frustration back and forth?
-
-[14:03] **Carl Vitullo:** A joke that didn't land.
-
-[14:04] **Mark Erikson:** Yeah. So, a little bit of background. The React Three Fiber ecosystem is pretty large. uh, DRCMDA, however you pronounce his username, uh, I think his name's Paul Henschel, and a bunch of other folks have done some amazing work over the last few years to create a React renderer that wraps the three.js 3D WebGL library so that you can write React components that render full blown 3D scenes and control them. And while I have not played with this myself, I've seen lots of examples and snippets and videos of some incredibly impressive demos and apps and tools that they've built over the last few years.
-
-[14:44] Now, one issue is that React three fiber is its own separate React renderer different from React DOM. Like, they both have their own copies of React's core logic embedded in them. And React has a limitation that different renderers in the same program don't actually know about each other. And so, if you think about a typical web app, you're probably using React DOM to render the outer page, and then you might be using React Three Fiber to render, you know, like a 3D animated scene or a game or something inside of the page.
-
-[15:22] And the problem is that if you try to render a context provider, In, like, React DOM, React Three Fiber will not see it, because they are effectively totally separate worlds that just happen to be nested in each other. And so, there was a PR, there was an issue request all the way back in 2019, where some folks like the React Three Fiber people were asking, " Can React add a way to try to share context?"
-
-[15:48] between renderers. And that PR has been open for a long time, er, issue, and nothing's happened with it. So, the React Three Fiber folks ended up writing a very intentionally hacky package called `its-fine`, which, you know, references that goofy little, like, dog in the fire meme. It very intentionally reaches into React's internals and accesses fields that you're not supposed to be able to grab context instances from.
-
-[16:15] And pass them across the renderer boundary so that you could have like your context provider with user data or something at the top of the whole application and both React DOM and React Three Fiber could read from it. Well, a few weeks ago, Sebastien Mårkbage from the React team put up a tweet where he linked to the dependents of the it's fine package and said, " yeah, this is a list of Packages and tools that will break in React 19," which is fair.
-
-[16:41] I mean, it's a package that intentionally reaches into React's internals. You have to expect that there's going to be breakage. So that's a very legitimate observation.
-
-[16:50] But then it kind of went off the rails a little bit. Another one of the React team members, Rick Hanlon, actually posted a PR in the React repo that he labeled, " it's not fine," and that PR literally just looks for the existence of the it's fine package in your project and throws an error if it's detected. Now, while he didn't explicitly say it in the initial version of the PR, it was obvious this was a joke and it was never going to be merged. But, I'll be honest, speaking personally, I found that joke to be in very bad taste.
-
-[17:23] To me, as a library maintainer, if people are writing code in a way that reaches into my own library's internals, that usually says to me that there's some use case that I haven't considered that I ought to at least think about trying to handle. and make a public API for. As an example, with React Redux, up through version 5, used the old style React context system.
-
-[17:50] And everybody knew that you could reach in and grab the Redux store by accessing `this.context.store`, but it was never part of our public API. And so when we switched over to the new context API in version 6, Number one, all those old usages broke. And number two, we actually publicly added a useStore hook, that, you know, just grabs the store off of new context and returns it. And so it's not something we recommend using, but it's a thing people sometimes had a reason to do. And so we provided an API to do it.
-
-[18:26] So my stance as a maintainer and a community person here is that, number one, the joke PR was a bad idea. The React team has had enough issues with marketing and PR and DevRel.
-
-[18:39] Mistakes in the last few years and this really did not help the situation. And number two, you know, making the original observation that, hey, these things are going to break is fine, but maybe instead of making a joke, Pierre saying, "haha, we're going to ban this package", maybe you should be trying to address the legitimate request for a way to use React that does not officially work right now.
-
-[19:02] **Carl Vitullo:** It looks like this did turn into that as well. In a reply on that, you know, joke PR, Sebastien Mårkbage did come in with some like real analysis on, you know, he said, I spent some time investigation or investigating. "The proper solution behaves like a portal should forward the value during a concurrent render into the child."
-
-[19:26] Yeah, it's, it basically, it sounds like what he was saying is, " it's tough, it would require some adjustment to these other guarantees that we make, will take a fair amount of time to evaluate whether this is going to be actually possible. It's not our top priority because of the bit of a fringe need."
-
-[19:42] Which, all very fair. So I'm glad this did come back and get some, like, real technical back and forth. it just felt like it felt a little bit like targeted and kind of mean spirited. So, you know, glad it came back and had some more meaningful discussion about the problem and what the right solution—
-
-[20:00] **Mark Erikson:** the technical feasibility aspect of it. Yeah.
-
-## React Strict DOM, Why is it so Great?
-
-[20:02] **Carl Vitullo:** Yeah, most definitely.
-
-[20:04] Next one, there was a really great post called, React Strict DOM, Why is it so great? From Syzmon Rybczak? I am so sorry if I'm murdering that, but, interestingly, he, he claims to be 17 and working at Callstack. So, wow, cool. This is a great post flat out. And this is a phenomenal post for a 17 year old developer. Like, wow, cool. Somebody to keep an eye on.
-
-[20:24] But, talking about, React Strict DOM, and, sort of the, Technical background of where it came from and contrasting it with React Native for web. Actually, as I was reading this, it reminded me of some of the discussion we've had, but this is a really great long form write up of, that hits a lot of the same notes that we discussed previously, but with added benefit of pretty great technical diagrams made with Excalidraw . Yeah, definitely good to check out.
-
-[20:52] It talks about how React Native Web is It's ultimately a shim that offers compatibility with the React Native API, which the big downside of that is because of the approach it took, it is necessarily a relatively large shim, and adding A large core package to a web app, just it, it inflates the bundle significantly, more significantly than not using it, which is just the extra friction, which makes it just that much harder to get adoption.
-
-[21:23] And since React Native Web didn't really get adoption. So the React strict DOM approach sort of comes at it backwards, where it takes web APIs to render components out and, because it is taking such a different approach to a similar problem, it is able to keep the size of this shim, this compatibility layer, much, much smaller.
-
-[21:44] So it looks like the core of it is coming from these two CSS and HTML exports from the ReactStrict DOM package, and those are how React Native would then understand how to handle these UI primitives.
-
-[21:59] **Mark Erikson:** Yeah, another way to put it is that the React Native web package gave you what looked like React Native components, so you would write your web code as if it were targeting React Native.
-
-[22:12] With React Script Dom, it's flipped, so that you're You write React Native code as if you were targeting the web, and so you write, you know, your components return a, quote, div on both platforms, but now with React Strict DOM, what you said was a div on native actually becomes a React Native view instead.
-
-[22:33] **Carl Vitullo:** Yes. Thank you for that. I guess I didn't realize that the React Strict DOM package is built on StyleX? Like it looks like that is very core to what is enabling this, I guess? I know you have explained StyleX to me at least once before and I just don't have a, it doesn't, it didn't stick in my brain.
-
-[22:50] **Mark Erikson:** As usual, I've only glanced at it myself.
-
-[22:52] It is yet another CSS in JS type tool. It was developed internally at Meta, like many of the other tools that they've put out there. As I understand it, some of the defining features are it's more of a compile time tool instead of runtime. And I believe it compiles down to more of an atomic CSS setup so that it.
-
-[23:14] Like over time, the amount of extra styles that get generated stay pretty limited because, you know, like everywhere you use like a certain margin size or something that only ultimately adds one rule to the code base.
-
-[23:28] **Carl Vitullo:** It's definitely similar ish to the like compiler for the Tailwind compiler works ish, but operating on a different set of, uh, underlying primitives.
-
-[23:37] Very interesting. Didn't realize that it was so connected to React strict DOM. So that's pretty cool.
-
-## Server Components updates
-
-[23:42] **Mark Erikson:** Moving right along, we have a few different articles and bits of information related to server components. There was A couple articles that discussed kind of like some of the philosophical or conceptual model of React and server components.
-
-[23:57] There was one article in particular that tried to go back to React's, early selling point of your UI is a function of state. And, when we say state, we normally think about state in components, or maybe state in, you know, You know, an external state library like Redux or Jotai or something. The article makes the point that there could actually be lots and lots of sources of state in your application.
-
-[24:22] You know, there's the URL, there's server files, there's the current time, operating system settings, environment variables, You know, lots of different potential sources of state. And so, you know, kind of walking back philosophically about, you know, how do these concepts tie together. And the author goes in a couple different directions.
-
-[24:40] On the one hand, extrapolating some of React's principles, you know, the React team has always been very focused on composability. And that's why we ended up with the custom hooks model that we did, because it enables arbitrary composition of hooks. On the other hand, the author also put up a follow up post saying that they think that Next actually kind of breaks some of these React fundamentals with the way that server components work and some of the way you have to actually structure your code base and your data flow.
-
-[25:10] I don't have a particularly strong opinion here, but it's always nice to see people actually kind of thinking through the concepts and the consequences involved.
-
-[25:18] **Carl Vitullo:** Yeah, and I really like the focus on. Discussing what state is. I feel like the, you know, the React ecosystem has been talking about state and state management for so long that, you know, there's always a game of telephone that happens in trying to communicate concepts out.
-
-[25:34] And I feel like where that has ended up over the years in the React ecosystem is people think state is a single blob of JSON. You know, that their app uses. But what this article is bringing back up is like, no, that's not the only type of state. State is something that your app needs to track in order to function correctly.
-
-[25:55] So yeah, I just wanted to call that out. I think that's a really useful clarification.
-
-[26:00] **Mark Erikson:** There was also a pretty good post over at Builder. io entitled, Why React Server Components are Breaking Builds to Win Tomorrow. I actually didn't quite catch the where in this it's talking about the breaking builds concept specifically, but it does a pretty good job of talking about the different concepts of rendering on the client, versus rendering on the server, versus streaming HTML, and how suspense and server components actually make some of these capabilities possible. So it's a pretty good kind of like technical architectural walkthrough.
-
-[26:31] Moving on a little further to the ecosystem. The Waku project from Daishikado, who's the author of Jotai and Valtio and Maintainer as Zustand, is making good progress. They've announced that they're working on a Pages router.
-
-[26:44] And I believe they're up to version 0. 20. Not sure what the roadmap is to 1. 0, but it's definitely a nice alternative approach to what we've seen with Next. And I believe they're pretty serious about trying to make it like a full blown, meaningful, usable framework based on server components. Similarly, Lee Robinson from Vercel actually just tweeted out a list of at least a half dozen different projects that are working on server component support in some fashion.
-
-[27:14] And so there's definitely work being done in the ecosystem. More specifically, the Redwood project. which originally went all in on GraphQL as the back end, just announced that they have finally managed to succeed in integrating server components. And I think they actually put up a post a few months ago saying that we are all in on server components as a concept.
-
-[27:36] So, server components have been out in Next for a while. We know that Remix is working on them, but there's other tools and frameworks that are trying to adopt them as well. And finally, I, one slight counterpoint, found an article just a little bit earlier where a company said, you know, we've tried server components and we like them, and we tried the new React server actions support.
-
-[27:57] But they ran into a few technical details, or technical issues. They didn't get a lot of details. It looked like something about some bundle problems, and then they felt that there was too much magic going on at the architectural level, and so they actually dropped server actions and went back to using tRPC instead.
-
-[28:13] **Carl Vitullo:** Interesting. Yeah. Too much magic is a very hand wavy type of complaint that can be used for all sorts of different, uh, underlying problems. So I'm curious what some more of those technical details would have been. But it's cool to see more experimentation and a wider range of experiments being done with server components generally.
-
-[28:33] When we first talked about WACU, I kind of expected it to be like just sort of an experiment, just sort of a like trial, because we'd seen a couple of those. We've seen, we had seen a couple of people just throwing together a project, doing it for learning, doing it to just explore. There's been. Pretty consistent development on Waku, so very interesting to see.
-
-[28:52] We'll have to see if it grows into a, like, serious competitor framework for, you know, okay, like, if it makes it to Remix or Next tier, then I would be very impressed. But, you know, they're definitely working on it in a much more meaningful way than I was anticipating originally.
-
-## Apple walks back on PWAs, neat Safari features
-
-[29:06] **Carl Vitullo:** A bit of a follow up to something we talked about last month of, uh, Apple's Attempted undoing of PWAs attempted.
-
-[29:15] I don't know how to frame that, but the last month. Apple announced they were going to drop support for progressive web applications for installing a web app to your home screen. They very quickly walked that back. And actually now, like I was just checking in on WebKit updates and they're adding more support for progressive web apps.
-
-[29:32] They are most specifically, they're going to be supporting the shortcuts manifest property, which allows you to add context items for the home icon. So, you know. On a Mac, if you add it to the dock, you can right click on it and it will show up a couple of options that take you to specific URLs within the app.
-
-[29:51] So, you know, it's a shortcut. It's a context item for your home screen icon that takes you to somewhere specifically within the app. Like, these are the kind of things that Like what progressive web apps have been a thing for like a decade now. Like there was never a technical reason why Apple could not support shortcuts in this.
-
-[30:08] So this feels like a shift of tack to more meaningfully support progressive web apps so that they can entrench themselves and say like, no, look, we are, we do support alternatives. We're not a monopoly while they're defending lawsuits against the iPhone and app store. So cool. You know, if that ends up bringing more meaningful support of progressive web apps. Uh, I'm pretty excited. You have to see how that shakes out though.
-
-[30:32] Another small, interesting thing coming from here, not related to progressive web apps, just Safari web kit features. They added a like progressive enhancement type option for checkbox. So they added a switch attribute to the input in Safari.
-
-[30:48] So if you say input type checkbox switch. It will render as a switch. It was one of those solutions that felt really obvious in hindsight, and I have implemented so many switches in my career, and they are a pain in the butt to get to work correctly. So having a native option, like, now I want Chrome and Firefox to roll it out, like, immediately, because it is Just a great improvement.
-
-[31:08] It's a very small, but very meaningful improvement. I love to see, it's not even like innovation in form inputs. It's just like fixing a problem, fixing something that's been missing for 15 years at this point.
-
-[31:21] **Mark Erikson:** Nicole, who had been heading up a lot of Chrome's work around interacting with frameworks, I know that she had spearheaded a lot of efforts to try to improve native form controls as a concept.
-
-[31:33] I also know there's a project called Open UI, which is somewhere between let's build another set of web components, but also let's kind of like prototype and experiment with what additional built in browser forms and features would look like. And what if there were a tabs or a carousel kind of control built into browsers natively?
-
-[31:56] And so they've been doing work to try to spec those out.
-
-[31:59] **Carl Vitullo:** Oh, very cool. In some ways, I feel like in trying to be agnostic and provide maximum flexibility to developers, I feel like we used to have, like, the operating systems, before everything moved into being web based, operating systems provided, like, a very limited toolkit of, like, here are your UI elements.
-
-[32:18] **Mark Erikson:** And bring back the styled win Windows XP Common Controls, Doug on it. .
-
-[32:23] **Carl Vitullo:** Right, right. Where's the, where's the Windows 95, you know, tab list? Like, okay. Sure. Uh, we've had a lot more experimentation in different types of UIs and different types of ex uh, different types of user experiences. But like, man, you know, it's, I feel like it's also gotten super fragmented.
-
-[32:38] And so maybe this is the pendulum. Maybe, you know, it went, it started by technical necessity on a super constrained set of core components that you just added. And then we went all the way, maximum flexibility. You can do anything you want, anything and everything. And now people are going like, uh, I'm tired of figuring out new unfamiliar UIs.
-
-[32:57] I'm tired of implementing things from scratch. So, uh, yeah, I, maybe we'll. Consolidate a little more back on a simpler set of UI primitives.
-
-## Mental Health in Open Source
-
-[33:05] **Mark Erikson:** All right, changing topics completely. There was an excellent article this week from Anthony Fu, who is a prolific maintainer and developer within the Vite and Vue ecosystems.
-
-[33:17] And, you know, strictly speaking, this has nothing to do with React, but it is an excellent article. And so he wrote about mental health in open source. And he talked about, you know, he got involved in open source kind of by accident. Thanks And he made a lot of great points that absolutely resonated with me.
-
-[33:34] Like, as a fellow open source maintainer, I 100 percent absolutely agree and endorse and stamp and repeat every single thing that he said in this post. So we talked about, you know, not being prepared, like, as a maintainer, you are a developer, and tech support, and marketing, and docs writer, and team leader, and project manager, and, you know, a whole bunch of other hats, and nobody teaches you how to do any of this stuff.
-
-[34:03] But there's also a really big problem with expectations, both internal and external. You know, users file bug reports, and they expect their bug to be fixed right away. But then, as a maintainer, you also put a lot of pressure on yourself to try to get stuff done. And I unfortunately am very guilty of this.
-
-[34:21] I routinely have put far too much expectations and self responsibility to get certain things done. And then I feel bad when I don't live up to my own expectations. As an example, I've said that this year I want to do a refresh pass on the Redux docs tutorials. And I've sat down like three different evenings and made some progress on it, but I've been otherwise focused on some different things and my brain is yelling at me because I quote, haven't made as much progress as I should have made by the end of March.
-
-[34:54] Nobody's watching me. Nobody is keeping track. Like, I've tweeted that I was gonna do this, but like, no one is watching me. It's my own head that is yelling at me because I don't feel like I've gotten enough done. And so Anthony has, you know, some similar points that he makes in his post. And then he also talks about, you know, in some ways your dream of working on this tool can become its own entire second job.
-
-[35:17] So there's not like a specific solution that he discusses, but everything he said on that post, like is absolutely my own experience and it's very much worth reading.
-
-[35:28] **Carl Vitullo:** Definitely worth reading. You have a lot of good things to say about like making your hobby, your job, that definitely resonates with me because that's kind of what I've been trying to do with the community stuff here in Reactiflux, part of why we are doing this podcast is because I thought, you know what, podcasts, that's the way to make money, not that it's worked yet, but you know, hey, sooner or later.
-
-[35:48] But yeah, this is, I definitely thought this was a really great and, I think it's a pretty vulnerable post. He's being very open about the difficulty of taking on this category of work. So yeah, also he talks, he says in the beginning, it's been about four years since I started doing open source and that's like, man, that puts him at.
-
-[36:07] 2019, 2020? 2020? That's four years ago? What? I don't know. This blew my mind a little bit. I have never been an open source maintainer, really. I did briefly take over a, you know, abandoned project and did a little bit of work on it. But, you know, it was so small that I don't feel like I can meaningfully claim the open source maintainer.
-
-[36:27] But, you Even just, even a very small library that was, ultimately was functionally replaced by a browser standard, it was a sticky, you know, Sticky banner library. Even just doing that for a couple of, I guess it was close to a year, just fielding issues and diagnosing and figuring out the, whether the answer to a question is yes, this is the bug that needs to be fixed or no, this is a
-
-[36:49] **Mark Erikson:** Intentional design limitation or something.
-
-[36:52] **Carl Vitullo:** There we go. Yes. This is an intentional constraint that. The trade offs are such that this is the correct decision. That's a lot of mental energy to expend. Like, you know, separate from, and I never did any blogging on it. I never, you know, spoke at any conferences. It was like a, an extremely small part of my, Attention.
-
-[37:09] And it still wore on me a little bit. So yeah, definitely a really good post to read. Really good projects alive that all of us use to do our jobs. Yeah, definitely recommend reading it.
-
-## Angular, meet Wiz
-
-[37:20] **Carl Vitullo:** I'll move us on. This is even farther afield from React, but, um, I saw Sarah Drasner tweeted that the Angular is going to be merging with a heretofore unopensourced internal Google framework called Wiz.
-
-[37:36] Wiz was brand new to me, I had never heard of it. So. Hearing that, you know, Angular, one of these huge projects, one of the projects in web is going to be internally combining with a never open source project. That's a pretty big statement. That's a pretty big plan.
-
-[37:51] It looks like this ultimately came from a exploration of using signals within, you know, signals and reactivity within Angular and drawing inspiration from this well understood internal framework called Wiz that I believe it is.
-
-[38:07] No. Okay. So the combination of Angular and Wiz is already rolled out to 100 percent of YouTube traffic. So like, this is not, you know, an abstract. Intent to, like, no, this is done. This is, you know, I took this as a similar in weight to when the React core team announced that server components were being used on the Instagram web property, you know?
-
-[38:29] So this is a meaningful investment. One of the big reasons that I think this is worth discussing on our React news show, Malte Ube, he is currently working at Vercel. He did a lot of work on Wiz. Back in the day at Google, he, and he had a really good post where he talked about like, why was that? Why was Wiz developed?
-
-## Designing Very Large Javascript Applications
-
-[38:49] **Carl Vitullo:** What problem was it trying to solve? And so he put up this blog post called Designing Very Large JavaScript Applications, which is ostensibly about Wiz and about, you know, these frameworks. But I found it to be a really clear and cogent articulation of a lot of the challenges that React. is trying to solve as well.
-
-[39:08] It's, you know, it talks about like the challenges of centralizing configuration and how, you know, things like a routes configuration file or the webpack configuration file, when you start maintaining a Enormous web application begins to be such a large constraint as to be like prohibitive. Like it just, it doesn't work.
-
-[39:29] You can't scale it. It ends up being append only. And so then you end up loading the bundle, like it becomes fragile because nobody wants to remove things. So then nobody wants to change, make certain categories of changes. Definitely a really good post discussing a lot of the finer points around bundling and architecture limits of current tooling and the most challenging.
-
-[39:49] Parts of large and complex applications. Uh, specifically he talks about Google search results and you know, now they serve up lots of little, uh, widgets as the first result. Like, you know, you search some math and it will spit out a calculator. You search a currency conversion and it puts up.
-
-[40:03] A calculator. Or all sorts of those things. Like each of those is basically its own tiny web app, and so if you just pull up Google, obviously they cannot serve up dozens and dozens of these tiny web apps that you're not using. So that's sort of the category, that's the backdrop and the framing for this architecture that's gotten.
-
-[40:21] Yeah, definitely really interesting. Definitely recommend giving it a read.
-
-[40:24] **Mark Erikson:** One other small tangent off that is, you know, we've heard the discussions and the arguments about front end development doesn't get the respect that it deserves for being its own very complicated domain. And I think that post is a very good example of, you know, real world apps have a lot of complexity and there are, they have their own unique sets of constraints and concerns and potential problems they have to work through.
-
-[40:47] Yeah,
-
-[40:48] **Carl Vitullo:** very true. And on that note, something that struck me reading it is that is an entirely different set of constraints than I personally have ever experienced in my career. So of all of the weird, quirky, you know, specific reasons why like this tool doesn't work for this product or whatever, That was a whole new category that I've never encountered, like, I, you know, I don't work on a Google type app where there might be one of a hundred and fifty different things served on the same page.
-
-[41:16] So I just thought that was really interesting. It was a glimpse into a different part of the web world. Just broadened my perspective just that little bit much more.
-
-[41:23] **Mark Erikson:** I mean, similarly, you were talking earlier about like, you know, I've implemented, you know, a half dozen input widgets or something in my career.
-
-[41:30] Like, I've never done anything like that. I mean, I've never worked on a project that really made meaningful use of a router. At all. Like everything I've worked on in my career has basically been the equivalent of a desktop app that runs in a browser that, you know, it's an app, not like pages or routing.
-
-[41:51] So like I've barely ever used routing in my own career because the products I've worked on just haven't required it.
-
-[41:58] **Carl Vitullo:** Yeah. I think that is so true and very underappreciated even within frontend. I think that so like you said, I've implemented a lot of checkboxes. That's because I've jumped around to a lot of different startups and I've worked on a lot of greenfield projects.
-
-[42:11] So I actually think that I have a relatively rare perspective on the industry of, you know, I didn't spend six years at, you know, Google. Four years at Facebook. In, in my, over my 10 year career, I worked at nine different companies. Like, you know, I've seen a lot of different types of products. I've worked in advertising tech, agriculture tech, cryptocurrencies, done brochure sales sites for credit card companies.
-
-[42:34] So like, I have worked in a bunch of different contexts. And what I've learned is that Well, something I experienced was that surprisingly little of what I used in one company was immediately relevant at the next company. Like, the architectures were just so different that the assumptions I couldn't bring any of my past assumptions.
-
-[42:53] I had to leave all those assumptions at the door and just rediscover a new problem space every time I joined a new company. And so here's Malte discussing an entirely new type of architectural constraint that I have never encountered, despite my wide range of encountered problems. Last thing I'll say on that, he gave a talk at JSConf Australia in 2018.
-
-[43:13] Speaking about Wiz and talking a little bit about his decision not to open source. He says at the time didn't want to compete with React. There were already so many options, adding another one seemed unnecessary. And like, yeah, I, 2018, I feel like that was about peak JavaScript fatigue era. Um, but now he describes that decision not to open source as a misread of the market demand.
-
-[43:36] So that's interesting. So just bringing it back to Angular meets Wiz. I think, yeah, I'm going to be paying attention to that to see how that shakes out a little bit more. It seems like it's, he regards it as a correction to a mistake made like five or six years ago.
-
-## Lightning round
-
-[43:51] **Carl Vitullo:** We're into the lightning round. We are over an hour.
-
-[43:53] **Mark Erikson:** Lightning the lightning round.
-
-[43:55] **Carl Vitullo:** Yeah, lightning the lightning round. Cool.
-
-## ⚡️ Interaction to Next Paint, new Core Web Vital ⚡️
-
-[43:56] **Carl Vitullo:** First off, there is a new Core Web Vital, which are the, like, lighthouse, Performance characteristics that are measured by Google. I believe the Core Web Vitals are one relatively significant input to search ranking for like search engine optimization.
-
-[44:12] Interaction to NextPaint, INP, is replacing first input delay as a Core Web Vital. So really quick overview, uh, first input delay was You open up a new website, how long until that code responds to the first input you give it? You know, a click, a scroll, a keystroke. That is no longer going to be a Core Web Vital, and instead it will be how long between an interaction and the next paint.
-
-[44:36] Notably, that's A change from measuring like startup responsiveness to ongoing responsiveness, which I think is very important. 'cause you know, it's much easier to do a, a one-time optimization of the app as it's loading versus a just optimizing the entire app so it's more responsive and just faster, better. So yeah, definitely seems like a much more meaningful metric.
-
-## ⚡️ RSPack charts a path to 1.0 ⚡️
-
-[44:56] **Mark Erikson:** Next up, there's been a plethora of rust based javaScript build tools as of late. One of those is called RS Pack, which is a rust based reimplementation of the entire web pack tool being built by ance. RS Build is a layer on top of that from the same team that makes the web pack layer easier to use.
-
-[45:20] So conceptually this is like a CRE React app equivalent, and they actually have how to migrate from CRA in their docs. They have announced plans for their roadmap to a 1.0 release. For what it's worth, I tried out RS build in one relatively small CRA project that I had, and it worked great. Like the build time dropped from like 30 seconds to one second.
-
-## ⚡️ Remix might merge React Router in?? ⚡️
-
-[45:42] **Mark Erikson:** Entirely other news, Ryan Florence has been talking about how the Remix team has been continually adding more features to React Router, things like loaders and such. And so he's now tossing out the idea that they might end up effectively merging the Remix and React Router projects in some way. Details TBD. But it's something that they're thinking about.
-
-## ⚡ Declarative Shadow DOM in all major browsers ⚡️
-
-[46:08] **Carl Vitullo:** I have another broad web update here. Declarative Shadow DOM is now available in all major browsers. This is related to web components. I know that one of the major criticisms in the past several years, many years, has been Of web components has been that it is not possible to use them without JavaScript.
-
-[46:27] How they get added to the page is through JavaScript. And so if you are trying to make, there are many categories of web products, web properties. Where that just doesn't work. You can't use JavaScript, you can't rely on it, many reasons it doesn't work. And so, this is a declarative version of Shadow DOM that is now supported in all major browsers.
-
-[46:46] And, theoretically, maybe this will unlock a new era of experimentation in web toolkits. Now that we can use Web components without JavaScript. I think that we might start seeing some more experimentation. This kind of feels like what web components have always been meant to be. So yeah, interesting.
-
-## ⚡️ React Native community map ⚡️
-
-[47:05] **Mark Erikson:** Okay, next up, there's a developer named Lorenzo Sciandra, who works at Microsoft, I believe, on Microsoft's maintenance of React Native for Windows and React Native for Mac, and he's put together a repository list that points to lots of community resources for React Native. Discords and servers and discussions. So if you're interested in React Native and other possible community resources, that's useful.
-
-[47:31] **Carl Vitullo:** Yep, we're on there. Woo! (chuckles)
-
-## ⚡️ Node.js 2023 Year in Review ⚡️
-
-[47:34] **Carl Vitullo:** As mentioned much earlier, there was a Node. js 2023 year in review post.
-
-[47:39] It's mostly just sort of talking about, like, Technical overview of how Node itself has changed over the years. So it's not so much like how you use it or, you know, performance. It's here is how usage of different versions have, has trended over time as different ones have gone end of life or been released.
-
-[47:58] It has a great chart of the binary size per version over time, which let me just call out. So version 10. 24. was about 40 megabytes or mebibytes. I'm just going to call it megabytes. Version 21. 6 was 98. So that's a long time. Version 10 versus version 21. I think that's Like close to 10 years, something like that.
-
-[48:22] But yeah, seeing it 2. 5X in size over that time is, yeah, I guess it's been kind of append only. So yeah, like we discussed earlier, TypeScript has been focusing on reducing its install size. It sounds like there might be growing appetite to do so in Node as well. But this is just sort of like a, it's a pretty deep in the weeds discussion of how Node has evolved, and specifically some of the changes in 2023. So I found it was a good read. Not immediately actionable in any kind of way, but just sort of broad context. Stay on top of what's going on.
-
-## ⚡️ Tailwind preview of 4.0 ⚡️
-
-[48:57] **Mark Erikson:** Next up, Tailwind is working on a new version and they've put up a post talking about some of the changes that they're making for version four. The biggest one is they've got a whole new CSS engine.
-
-[49:08] Apparently it's built on top of Lightning CSS, a Rust based CSS parser and translator from the author of Parcel, but they're working to make it the whole thing smaller, faster, built in. They're also making some potential changes to the configuration so it actually kind of looks and feels more like CSS in the process.
-
-## ⚡️ Vercel adds Remix+Vite support ⚡️
-
-[49:26] **Carl Vitullo:** So, Vercel has announced that they are now supporting Remix with Vite. Pretty cool. Just especially because they maintain Next. It seems nice that they would pretty quickly jump on adding support for some new features coming out of Remix. They say in this post, they collaborated with the Remix team to add server bundles to Remix, which we discussed really briefly last month as a kind of confusing, deep optimization.
-
-[49:52] So just to see that. Vercel is meaningfully working to support some kind of fringe, niche features within one of their major competitors. Cool. That seems really nice. Very glad to see that. Also adds support for Remix features like the streaming, server side rendering, API routes, more advanced caching, data mutations.
-
-[50:13] Yeah. Happy to see that.
-
-## ⚡️ Navigating the Future of Frontend ⚡️
-
-[50:15] **Mark Erikson:** And finally, there's an author named Rem, uh, I don't know any more details about them, that's just their handle, who has put up a series of very good posts at a site called Frontend Mastery, talking about various aspects of React and frontend development. And the latest one's called Navigating the Future of Frontend.
-
-[50:32] And it talks about some of the aspects of JavaScript frameworks, and their capabilities, and what are some of these tools even doing for you. And talks about some of the directions that they are going these days in terms of routing, and mingling backend and frontend, and dealing with caching, and components that can be used on the server or on the client, and in a mix of some way.
-
-[50:55] So it's not like a specifically actionable post, but it's a useful guide to, like, where have we been and where are we going.
-
-[51:02] **Carl Vitullo:** Yeah, definitely looks like a really interesting post. And I just realized, just now, that it's not on Frontend Masters, it's Frontend Mastery, which is not an educational platform hahaha.
-
-[51:12] **Mark Erikson:** It looks like it's basically this one person's blog.
-
-[51:15] **Carl Vitullo:** Interesting. Yeah, I, I saw the link and I had assumed that it was really the front end masters, which makes perfect sense because they've been doing web education for my entire career, insofar as I learned React by taking a front end masters class. But yeah, no, this is front end mastery.
-
-[51:29] It's just somebody's blog. Still, it's really good, really good post to echo everything Mark just said.
-
-[51:34] That's everything we got. We'll be back on the last Wednesday of next month in April on the live stage here in Reactiflux or back in your podcast feed just as soon as we can. We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, React Digest, the React. js subreddit, here in Reactiflux, and directly from people publishing articles on Twitter or whatever.
-
-[51:57] If you see anything newsworthy, definitely let us know in the Tech Reads News channel here in Reactiflux, or let me know by sending an email to hello at reactiflux. com with T M I R in the subject line. It's an acronym for the show.
-
-[52:11] I read literally every email that comes in, including spam and all sorts of other things. So yeah, if you send an email to hello at reactiflux. com, I will read it. And if this is a show you get value from and want to support, the best way to do so is submit a review or tell your friends and co workers about it.
-
-[52:26] Just drop it in Slack. And I know that I will personally thank you if I am ever made aware of you broadcasting us. Cool. Thank you so much. See you next month.
diff --git a/src/transcripts/tmir-2024-04.md b/src/transcripts/tmir-2024-04.md
deleted file mode 100644
index 4edf563..0000000
--- a/src/transcripts/tmir-2024-04.md
+++ /dev/null
@@ -1,535 +0,0 @@
----
-title: "This Month in React, April 2024: So many new releases, React 19 featureset"
-date: 2024-04-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick hits
- - [[00:46](#upcoming-conferences)] [Upcoming conferences](https://react.dev/community/conferences)
- - [React Conf 2024](https://conf.react.dev/) May 15 - 16, 2024. In-person in Henderson, NV, USA
- - [App.js Conf 2024](https://appjs.co/) May 22 - 24, 2024. In-person in Kraków, Poland
- - [Local First Conf 2024](https://www.localfirstconf.com/) May 30, 2024. In person in Berlin, Germany. Followup hackathon on the 31st
- - [Render ATL](https://renderatl.com/) June 12-14, 2024. Atlanta, GA, USA
- - [Future Frontend](https://futurefrontend.com/) June 13-14, 2024. Helsinki, Finland
- - [React Norway](https://reactnorway.com/) June 14, 2024. Larvik, Norway
- - [React Summit](https://reactsummit.com/) June 14 + 18, 2024. Amsterdam, Netherlands (+remote)
- - New releases
- - [[02:32](#react-183-19)] [React 18.3](https://github.com/facebook/react/pull/28843)
- - [React 19 beta](https://react.dev/blog/2024/04/25/react-19)
- - [[03:15](#nodejs-v22)] [Node.js v22](https://openjsf.org/blog/nodejs-22-available)
- - [[04:02](#expo-sdk-51-beta)] [Expo SDK 51 beta](https://expo.dev/changelog/2024/04-24-sdk-51-beta)
- - [React Native 0.74.0](https://reactnative.dev/blog/2024/04/22/release-0.74)
- - [React DevTools 5.1](https://github.com/facebook/react/pull/28840)
- - [Next v14.2](https://nextjs.org/blog/next-14-2)
- - Bun v1.1 (discussion later)
- - [Pnpm v9](https://github.com/pnpm/pnpm/releases/tag/v9.0.0)
- - [Biome 1.7](https://biomejs.dev/blog/biome-v1-7/)
- - [Supabase goes GA](https://supabase.com/ga-week) after 4 years in beta
- - [Docusaurus 3.2](https://docusaurus.io/blog/releases/3.2)
- - [Gulp v5](https://medium.com/gulpjs/announcing-gulp-v5-c67d077dbdb7)
- - [Pragmatic Drag and Drop](https://github.com/atlassian/pragmatic-drag-and-drop)
- - [RedwoodJS 7.3](https://github.com/redwoodjs/redwood/releases/tag/v7.3.0)
- - [React on Rails v14](https://github.com/shakacode/react_on_rails)
-
-# Main Content
-
-- [[12:43](#new-react-release-details)] New React development
- - [React Blog - React 19 Beta](https://react.dev/blog/2024/04/25/react-19)
- - [React Blog - React 19 Beta Upgrade Guide](https://react.dev/blog/2024/04/25/react-19-upgrade-guide)
- - [React 18.3 changelog](https://github.com/facebook/react/blob/4508873393058e86bed308b56e49ec883ece59d1/CHANGELOG.md) : dev-only warnings for string refs, `findDOMNode` , default props, legacy context, `test-utils`
- - Internal changes:
- - [Rename SECRET INTERNALS to \_\_CLIENT_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE](https://github.com/facebook/react/pull/28789)
- - [Fast JSX: Don't clone props object](https://github.com/facebook/react/pull/28768)
- - [Remove defaultProps support (except for classes)](https://github.com/facebook/react/pull/28733)
- - [Ship optimized-but-unminified prod bundles and drop sourcemaps](https://github.com/facebook/react/pull/28881) ([current package contents](https://unpkg.com/browse/react-dom@19.0.0-beta-4508873393-20240430/cjs/))
- - [Don’t patch `fetch` anymore](https://github.com/facebook/react/pull/28896)
- - Future: [patching Date object?](https://twitter.com/acdlite/status/1785691330988986587)
-- [[33:29](#react-native-0740)] React Native [0.74.0 release](https://reactnative.dev/blog/2024/04/22/release-0.74)
- - [React Native Navigation v7](https://reactnavigation.org/blog/2024/03/25/introducing-static-api/)
- - [VisionCamera v4.0](https://github.com/mrousavy/react-native-vision-camera)
-- [[38:17](#kotaken-rscs-with-just-bun)] [Kotekan](https://kotekan.dev/blog/introducing-kotekan)
-- [[39:02](#bun-11)] [Bun v1.1](https://bun.sh/blog/bun-v1.1)
-- [[39:37](#jsr-by-deno)] [JSR](https://deno.com/blog/jsr_open_beta)
- - [First Impressions](https://dbushell.com/2024/02/16/jsr-first-impression/), [Second Look](https://dbushell.com/2024/03/04/jsr-second-look/)
- - [First Things I Learned about JSR](https://mariusvatasoiu.com/first-things-i-learned-about-jsr)
-- ⚡️ Lightning round ⚡️
- - ⚡️ [[45:09](#-why-i-like-react-even-in-2024-)] [Why I like React (Even in 2024)](https://ejosh.co/de/2024/03/why-i-like-react-even-in-2024/) ⚡️️
- - ⚡️ [[45:46](#-netlify-updates-their-nextjs-runtime-)] Netlify: [Introducing the new Next.js Runtime](https://www.netlify.com/blog/introducing-the-new-next-js-runtime/) ⚡️️
- - ⚡️ [[47:18](#-design-principles-behind-the-nextjs-app-router-)] [Design Principles behind the Next.js App Router](https://twitter.com/feedthejim/status/1785243633328758978) ⚡️️
- - ⚡️ [[48:04](#-nodejs-website-redesign-)] [Diving into the Node.js Website Redesign](https://nodejs.org/en/blog/announcements/diving-into-the-nodejs-website-redesign) ⚡️️
- - ⚡️ [[48:44](#-dives-into-react-features-)] [How does `useOptimistic` work internally?](https://jser.dev/2024-03-20-how-does-useoptimisticwork-internally-in-react/) (and many other code dives) ⚡️️
- - ⚡️ [[49:27](#-honeypot-releases-nodejs-documentary-)] [Node.js: The Documentary](https://www.youtube.com/watch?v=LB8KwiiUGy0) ⚡️️
- - ⚡️ [[49:56](#-flow-ships-react-features-)] [New Flow Language Features for React](https://medium.com/flow-type/announcing-component-syntax-b6c5285660d0) ⚡️️
- - ⚡️ [[50:26](#-vercel-updates-pricing-)] [Vercel cuts prices a lil](https://vercel.com/blog/improved-infrastructure-pricing) ⚡️️
- - ⚡️ [[51:28](#-redwoodjs-compares-data-fetch-methods-)] [Redwood Blog: Techniques for Fetching Data: Comparing Next, Remix, and Redwood](https://redwoodjs.com/blog/techniques-for-fetching-data) ⚡️️
- - ⚡️ [[52:02](#-kuto-reverse-js-bundler-)] [Kuto, “reverse JS bundler”](https://samthor.au/2024/kuto/) ⚡️️
-
-[00:00] **Carl Vitullo:** Thanks people for joining for April's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
-
-[00:09] **Mark Erikson:** And boy, is it evolving right now.
-
-[00:11] **Carl Vitullo:** Boy, is it evolving. Oh my God. There's so many releases. It's so much to get through.
-
-[00:16] So I guess let's try and run through it quick. Coming to you live from Reactiflux, the place for professional React developers.
-
-[00:24] I'm Carl, a staff product developer and freelance community manager here at Reactiflux, running community events like these.
-
-[00:31] **Mark Erikson:** And I'm Mark Erikson, my day job, I'm a senior front end engineer at Replay where we're building a time traveling debugger for JavaScript with some amazing test analysis features coming your way in the near future.
-
-[00:42] And outside of that, I do Redux stuff.
-
-[00:45] **Carl Vitullo:** So much Redux stuff.
-
-## Upcoming Conferences
-
-[00:46] **Carl Vitullo:** There's so many conferences coming up in the next, like, two months.
-
-[00:49] We've got this month, why I'm in Vegas. So if you're coming to React Conf, hit me up. If you're local and not attending the conference, come on down and we can do a watch party. Otherwise, I'm probably going to try and organize a couple of pre conf Things, post conf, after parties, ReactConf, May 15th and 16th in Henderson, Nevada.
-
-[01:09] AppJSConf is May 22nd through 24th in Krakow, Poland. The local first conf, I love local first stuff.
-
-[01:18] I think it's just a really powerful way to develop applications that is Kind of complicated. So I love seeing a conference dedicated to it. That's going to be May 30th in Berlin, Germany with a follow up hackathon on the 31st.
-
-[01:31] There's Render Atlanta in June 12th through 14th in Atlanta, Georgia.
-
-[01:36] Future Frontend, June 13th and 14th in Helsinki, Finland.
-
-[01:40] React Norway, June 14th in Larvik, Norway.
-
-[01:45] And React Summit, June 14th and 18th it looks like in Amsterdam with a remote option there.
-
-[01:51] **Mark Erikson:** I'm still crossing my fingers that I might at least be able to attend ReactConf here in a couple weeks and then I will be speaking at React Summit in Amsterdam as well.
-
-[02:01] **Carl Vitullo:** Awesome. Very cool. I can't believe how many are crammed into the middle of June. It's, it's a lot of good looking conferences. I know FutureFrontend
-
-[02:09] **Mark Erikson:** Is he the one who has been involved in like writing a webpack book years ago?
-
-[02:14] **Carl Vitullo:** I think so. He was involved in Reactiflux pretty actively a number of years ago.
-
-[02:18] I just wanted to give him a shout out because he's been deep in the React community for a very long time and seems like a cool dude.
-
-## New releases
-
-[02:25] **Carl Vitullo:** We're going to move on to a bunch of new releases. This has been a crazy dense month for new releases.
-
-## React 18.3 + 19
-
-[02:32] **Carl Vitullo:** The big ones, obviously two new React versions have been announced at least. There's React 18. 3. Which I think it's just sort of a pro forma release, getting ready for React 19. No behavior changes, just some extra warnings, a bit of improvements to developer experience to facilitate upgrading to React 19.
-
-[02:54] React 19 beta. Ooh, new major. Definitely excited to see all of the stuff going on there. I don't know. We've talked a lot about all of the development going on into React 19 with stuff like Form Actions, useActionState, RSC is obviously going to be big. Lots of form helpers and stuff.
-
-[03:12] **Mark Erikson:** We'll cover that in detail in a few minutes.
-
-[03:14] **Carl Vitullo:** For sure.
-
-## Node.js v22
-
-[03:15] **Carl Vitullo:** Yeah, new Node. js major version.
-
-[03:18] **Mark Erikson:** And I'm not sure where the versioning ties in, but I know I saw an announcement that some version of Node, probably this one, now has support for importing ESM files via Require, which is gigantic. I don't know what it was they had to do to finally make that work, and why they couldn't have done that like eight years ago, but hey, better late than never.
-
-[03:42] **Carl Vitullo:** Better late than never. Yeah, that, oh man, the ESM versus CommonJS has been such a troubling split in the web ecosystem. So seeing Node finally supporting native ESM import through Require, hopefully will lessen a lot of that pain. Definitely very excited to see that.
-
-## Expo SDK 51 beta
-
-[04:02] **Carl Vitullo:** Okay. Blasting through. We've got Expo SDK 51 is out in beta.
-
-[04:06] That looks interesting. They are including the new React Native release, which we're going to talk about later too. And just lots of other improvements to like cameras and SQLite APIs, iOS privacy manifest, definitely looks like a pretty big one.
-
-## React Native 0.74.0
-
-[04:21] **Carl Vitullo:** React Native 0. 74, definitely pretty big release. We're going to talk about it.
-
-[04:26] A lot more in depth later. Uh, they've got a new version of the yoga layout engine and using yarn three in the default community CLI. But yeah, more details later on.
-
-## React DevTools 5.1
-
-[04:36] **Carl Vitullo:** New DevTools version as well. For React, the React DevTools put out version 5. 1. There's a bunch of changes there, but you know, I don't know. It's the DevTools.
-
-[04:47] **Mark Erikson:** Mostly related to support for the new features like use action state.
-
-[04:52] **Carl Vitullo:** Right, love some better DX there. The DevTools have always been pretty powerful and excited to see what the new experiences there look like.
-
-## Next 14.2
-
-[05:02] **Carl Vitullo:** Next, 14. 2. Gonna chat more on that later, of course.
-
-## Bun v1.1
-
-[05:07] **Carl Vitullo:** Same with Bun, version 1.1. New Bun minor. Again, gonna get deeper into it later on.
-
-## pnpm v9
-
-[05:12] **Carl Vitullo:** PMPM put out a new version 9, so a major version of a pretty significant package manager. I didn't quite realize that the P in PMPM stands for performant. The whole idea is there is that it just is MPM, but faster and better. I've heard from a number of people that it's their package manager of choice.
-
-[05:33] I've never substantially used it. I had used Yarn for a long time, but then I never upgraded from version 2. As I understand, the big improvement for PMPM is that it does sort of what Yarn 3 does similarly with not installing duplicate versions of packages when you have them already installed on disk somewhere.
-
-[05:52] So, That seems really cool. They're also adding like CorePack compatibility, which I understand to be a node standard for better supporting different types of different package managers. So, cool to see them supporting that standard. Always good to see behavior become more standardized, as well as improvements to the lockfile.
-
-## Biome 1.7
-
-[06:12] **Carl Vitullo:** We got Biome 1. 7. I have a soft spot in my heart for Biome. I was an early supporter of Rome and it was very sad to see that, I don't know, kind of go into vaporware mode. So I was excited to see that many of the maintainers of Rome forked the project and came out with Biome. They're advertising single command migration from ESLint as well as Prettier.
-
-[06:34] So I guess two commands, one for ESLint, one for Prettier. And looks like a bunch of smaller developer experience improvements for using it. Like, you know, checking staged files with a command flag. And good default linter configuration. Love the project getting a sort of a bundling. Well, how to disambiguate the term bundling.
-
-[06:55] It sort of bundles up a bunch of behaviors from other tools like linting and. Formatting and all those sorts of things. So I like that. I think it's a very interesting project. Definitely check that out.
-
-## Supabase leaves beta
-
-[07:06] **Carl Vitullo:** Okay. Supabase, which is a, I guess, Postgres as a service. I always have conceptualized it as an open source Firebase competitor.
-
-[07:14] I guess Supabase, yeah, Firebase. I didn't realize that they're still, they had been still in beta, but earlier this month they went general availability, so definitely check out the launch event. Week that they did. I have heard it as, you know, sort of an open source darling. I've seen it all over, you know, Twitter, used by many people who do lots of side projects and smaller greenfield work.
-
-[07:35] So if you're considering something like Firebase, if you're considering a back end as a service, definitely check out Superbase because it is generally available. No longer in beta.
-
-## Docusaurus 3.2
-
-[07:45] **Carl Vitullo:** Docusaurus put out version 3. 2, looks like it's mostly performance improvements, a better table of contents from partials, which I guess is, you know, if you stitch together a bunch of documents into a single page, they now have better support for generating a table of contents.
-
-[08:02] And this is a silly thing that I have always had on my mind, but one of the things they advertised was An accurate last mod time in the sitemap. I have found that tricky. I think that makes a reasonably big difference in SEO. You know, you're signaling to Google or whatever search engine that your content is fresh, is up to date.
-
-[08:21] And in the past, I have generally found sitemap generation tools they just seem to not care about that, like they just put together a list of all the URLs. So just seeing that taken seriously by Sebastien, by Docusaurus, I like it. They also mentioned in their release post that they have overtaken Gatsby in NPM downloads, which seems like a pretty significant milestone.
-
-[08:43] Changing of the guard a little bit.
-
-[08:45] **Mark Erikson:** That is interesting because we use DocuSource for the Redux documentation sites, and it's not like it's getting downloaded continuously in our case, we only do docs updates kind of intermittently. And so for it to actually be getting downloaded frequently suggests there's a lot of people using it for like a non library documentation site kind of use case.
-
-[09:06] You know, more of that static like website beyond just Docs.
-
-## Gulp v5
-
-[09:11] **Carl Vitullo:** This is a bit of a throwback, but Gulp, the now at this point quite long in the tooth build tool, script runner, just released version 5. Man, I haven't thought about Gulp in a number of years, so seeing it cross my path again was just like, oh, Gulp. Nice.
-
-[09:26] **Mark Erikson:** I'm genuinely surprised it's being actively maintained, much less putting out major versions. I mean.
-
-[09:32] **Carl Vitullo:** A little bit!
-
-[09:33] **Mark Erikson:** Admittedly, my own experience is biased. I've been in the React ecosystem where we, you know, webpack, blah, blah, blah, but very surprised to see that it's getting actively developed.
-
-[09:42] **Carl Vitullo:** Would generally agree.
-
-[09:43] They say in the release post, this release contains four years worth 60 projects. The team closed over 200 issues and pull requests. Cool. It's neat to see. Doing a major version seems like maybe a big ask for a project that is, I think, most likely to be used in a maintenance mode capacity. So, major version there seems like a little bit of a hard sell. Nice to see an old name resurface.
-
-## Pragmatic Drag and Drop
-
-[10:07] **Carl Vitullo:** I'm going to shout this out because it's related to a project that we had the maintainer on as a guest a number of months ago, but Pragmatic Drag and Drop from Atlassian. Drag and drop is brought. I've always found it to be kind of challenging to implement.
-
-[10:23] I remember when I spoke with the, the, the maintainer, Alex Reardon a couple of months ago, he had a lot of really interesting things to say about serving the different use cases in drag and drop. And I think he has been involved in maintaining like three different drag and drop open source libraries. So he's been just very deep in it for a very long time. And it sounded like he really pulled a lot of learning from those different types of uses into this project, made it more like pluggable and, only pull in what you need to get the behaviors you want and things like that.
-
-[10:54] So definitely check that out. If you're considering some drag and drop stuff.
-
-## Redwood v7.3
-
-[10:58] **Carl Vitullo:** Redwood JS released version 7. 3. It's the app framework for startups. I'm familiar with the name, but I've never really worked on it too much.
-
-[11:08] **Mark Erikson:** Their big sales pitch was that they did single file component setups where you export a GraphQL vary as a variable.
-
-[11:17] Like, conceptually, think of like a view single file thing, where both the component and other pieces were in a single file. By convention, you export a named variable with a GraphQL query, and all the rest of the pieces just hook together from there. However, they had announced about a year ago that they were going to, quote, go all in on server components.
-
-[11:36] I've seen a lot of chatter from their developers who have been actively working on trying to figure out the mysteries of making server components work for anyone not named Vercel. And so, like I said, I haven't even looked at the release notes here, but from what I've seen, they're getting pretty close on having that working.
-
-[11:53] **Carl Vitullo:** Yeah, that's right. I think I mostly remembered the name from hearing you talk about them as people who are investing pretty seriously in server components. So yeah, new version there. Looks maybe like it has a little bit of overlap with Superbase. Just a little bit closer to the front end half of the stack.
-
-[12:11] But full stack JavaScript application framework, batteries included, backend, React, all that stuff. Definitely interesting.
-
-## React on Rails v14
-
-[12:17] **Carl Vitullo:** And our last new release that we're going to shoot through, React on Rails version 14. This is not something that I've ever made significant use of. I think one of the companies I worked at was using it because they were deeply invested into Rails.
-
-[12:32] But yeah, I mean, you know, if you're using Rails, if you are trying to use React with your Rails app, this seems, as far as I understand, this is the way to do so. So I thought it was worth shouting out a new major version.
-
-## New React release details!
-
-[12:43] **Mark Erikson:** All right, let's roll into a couple of the bigger items from this week. And by far the biggest one is, hallelujah, after two years, we finally have new actual releases of React itself.
-
-[12:57] Literally, there was a guy who had put up a website that was like, what was the time breakdown between consecutive React releases? And, you know, some of these 16 or 17 releases had been like a few months apart, and it had been two years between 18. 2 coming out and today. So, the biggest news is that React 19 is finally in beta, and the React team has an extensive blog post that covers what's actually included.
-
-[13:25] And if you've been paying attention to, you know, the discussions of the canaries and what's been available in Next. js, most of this stuff should not be a surprise. But it's worth briefly summarizing what's there.
-
-[13:36] There's what they're calling actions, which admittedly as the Redux maintainer is a little bit frustrating for me because the word action now has like 15 different overloads. There's what Redux means by it, what MobX means by it, what server components now means by it, but oh, well, whatever.
-
-[13:51] There's a lot of stuff that has to do with forms and async behavior. So if I have a form and I want to send some data to the server and I want to track pending state related to that form submission, React 19 now has multiple new features around being able to provide a callback As the action prop on the form tag itself, there are hooks for tracking form status and trying to handle transitions related to that.
-
-[14:22] As, I unfortunately keep having to say, like, I've read about this stuff, I sort of have the picture in my head of what these things roughly do. I certainly have not had time to play with them, and honestly the kind of apps that I work on today don't even necessarily benefit from this myself. But it is very interesting to see the React team investing in, like, this, this kind of overlaps with a couple of things.
-
-[14:45] One is server components in general, because, you know, Dan's pitch is that server components extend React's one way data flow model to the server. So a server component fetches some data, passes it as props to a child component, which then renders, but if you want to go back to the server component and make it actually do something to force a re render and fetch new data, you have to have some way to reach back to the server.
-
-[15:12] And so my understanding is that server actions are the equivalent of a callback from the parent, except now it's crossing the network boundary And going back all the way to the server. So there's that aspect. There's a hook for optimistic updates and a whole bunch more pieces. It's also interesting because basically all of React's lifetime, we had certain conventions.
-
-[15:33] React was a primarily single page client side app tool, although you could always use it for what we now refer to as the islands architecture, little bits of React inside of an existing page. And you're supposed to use controlled inputs. You were supposed to have a state field for, you know, your first name, your last name, field, et cetera.
-
-[15:56] And you were supposed to keep that data in state and control the input because that matched reacts concept of the UI is always based on your state. And, that still exists, and React still has a ton of logic to make controlled inputs work, but it looks like with React 19, and the new emphasis on forms and actions, that conceptually the React team is now sort of going back to the, well, okay, fine, let's use the platform and have uncontrolled inputs as a default, and grab values from the form, using a form data object. Which is also basically what the Remix team has been telling us for the last two or three years.
-
-[16:40] I, I know that the new React docs now actually have an API reference page for the HTML form tag. Like, there isn't like a usage guide page that says here's how you're supposed to use forms in React, but I believe there is an API ref page that talks about what you can do with the form tag in React. Clearly forms and data inputs are a big emphasis as part of React 19 as a whole.
-
-[17:08] Another big piece is the new use hook, which I guess this means it's finally stable? Maybe? This is the replacement for the long known but always technically internal trigger suspense by throwing a promise.
-
-[17:24] So, instead, now you call the use hook, you pass in a promise, the promise needs to be cached so that you're passing in the same promise reference across renders of the component, but that is what will trigger the suspense boundary in some parent component and make this component wait until the promise is resolved for the data.
-
-[17:44] There's a lot of stuff around the actual. RSC functionality, and there's improvements with things like, with React 19, we now actually get ref as a prop, which means that forward ref can actually go away, finally. And this required a number of changes to React's JSX transform that actually had a lot of internal tweaks that had to be made, like we don't really think about compilation or behavior step of going from JSX tags to React element objects.
-
-[18:18] React originally had the CreateElement API, eventually that got replaced with a somewhat more sophisticated compiler based JSX transform, which still did roughly the same job. And for React 19, they've done a number of changes to the internals of that to make things like passing through ref directly possible.
-
-[18:36] On that note, there was also a PR to change some of the internals where they used to always have to clone. Whatever props object was getting passed into element creation. And that's a hot path because every render is calling this element creation logic thousands of times. And I'd seen some issues filed that complained, like this is a noticeable part of React's performance overhead.
-
-[19:01] So, they've done some optimization work there, and that means that React 19 should have lower overhead in the overall rendering process because it's having to do, less object copying as part of the actual rendering step.
-
-[19:16] A couple other things, you can no longer apply default props to function components. You're now supposed to just use ES6 destructuring defaults. Apparently that still exists for classes, because you can't destructure anything there. There's also been a couple interesting changes on the build tooling side. So, one that I have a personal vested interest in.
-
-[19:37] Early last year, I had done a lot of work to modify React's build pipeline to generate source maps, because React had never shipped with source maps. That meant that any time there was an error message in production, you got a totally unreadable stack trace. And, if you were in the hopefully rare situation of needing to debug and step out of React, like outside of a function component and into the React bundle, well, React's source code is hard enough to read.
-
-[20:09] In its original form, once it's been bundled and minified, it's literally completely unreadable. And for companies like Replay that care about source maps and debugging, that was a problem for us. So I'd done the work last year to add source maps to React's build pipeline. So, in an interesting twist, a week or two ago, Andrew Clark removed my changes from the build pipeline BECAUSE React is no longer going to ship pre minified bundles.
-
-[20:38] Now, to understand some of this, React has always used a very advanced minifier called the Google Closure Compiler. It's like Terser, but much, much more powerful. And it is like the best tool for optimizing and minifying JavaScript bundles, and they wanted to shrink it as much as possible and like really do a good job of inlining functions to make things fast.
-
-[21:01] So when I did the source map work last year, I was capturing a copy of the source code right before it went through closure. But, that didn't have some of the other optimizations that Closure does besides the final minification step. So, what they've done is they've dropped shipping source maps and they've stopped pre minifying the bundle, but they are still doing the optimization and inlining step with Closure. So, in the future, as a, or actually as of the latest beta, what's in the bundle is no longer react dom. production. min. js, which is what it's always been, but rather a react dom. production. js that's still like 500k, un minified, but it's got all the source code optimizations applied.
-
-[21:52] So, your application build step will now do the final minification process out of that. One other interesting side effect here is that if you look at this, strictly speaking, actually ReactDOM. production is now like a six kilobyte file. And this is unexpected. And in fact, if you look at BundlePhobia for ReactDOM 19 beta, it thinks that ReactDOM is now only six, like, like three and a half K minified.
-
-[22:19] Which is clearly not the case, and it's because the Reconciler logic is now in a separate file, React dom client . If you think about writing web apps now, ever since React 18, when we switched over to the new CreateRoot method, that comes from the react-dom/client entry point. So, they've re architected the bundles so that the bulk of the code is in that slash client file, and because of that bundle phobia, it doesn't actually trace through and connect the dots to see that both these files end up getting used in a real app.
-
-[22:55] Finally, a couple other bits that are stirring up some controversy. So a couple of years ago, the React team announced that they were patching the fetch method in order to allow caching in case, you know, multiple components are trying to make similar requests on the server side.
-
-[23:09] And many people got pretty justifiably angry about this because we learned back in the mid tens, patching global objects in JavaScript is a really bad idea. So the React team has finally given up on that and they've reverted those changes for the final release. And they've said. If you want to make sure you're deduplicating requests, wrap your request logic in the cache method.
-
-[23:32] Which makes it really ironic that Andrew Clark just tweeted today that they might actually end up patching the date object down the road in order to prevent hydration mismatches. I don't know. I understand why he says that. I am not sure this is a good idea. I don't have a better solution. So, we'll see how this one pans out.
-
-[23:53] **Carl Vitullo:** Yeah, I am empathetic to that. And he does talk about, as long as it's standards compliant, nobody has cared about patching internals, people haven't complained about polyfills, and dates are such a pain in the butt when you're doing hydration. Just, you know, it's so easy to have them accidentally rely on current time, which then causes a hydration warning and is just super annoying.
-
-[24:14] So I can understand the motivation for doing it, but yeah, agree, it's, you know, patching stuff is scary, it's risky.
-
-[24:19] **Mark Erikson:** So we've got a beta out, and I actually was not even expecting a beta this soon. I did not expect that we would see a beta for another couple weeks, and it would actually be announced at React Conf.
-
-[24:31] I do not expect a React 19 final at React Conf. I could be surprised, but the fact that it's only been in beta for a couple weeks, Plus, I'm still seeing lots and lots of PRs flying through in the React repo. I, I would not expect React 19 final for at least another three or four months, but I have no specific info on that either way.
-
-[24:54] **Carl Vitullo:** Yeah, I also want to call out a couple of other less conceptual changes, they seem a little bit more like pragmatic, use the platform kind of adjustments. React 19 adds support for document metadata directly in rendered React output. Previously, this is the sort of thing that you would use a tool like React Helmet to render.
-
-[25:14] You know, if you're putting document metadata, title, link, meta tags, stuff that normally lives in the head. Part of your HTML. Now React is adding support for rendering that pretty much anywhere. And then React will do the work to figure out that it needs to go in the head, and putting it there at all. That's pretty interesting. I have been routinely let down by React Helmet, which it just has a lot of bugs.
-
-[25:39] It was one of the first open source React libraries that I ever remember coming across like way back in 2013 14. And it was written by the NFL, which always struck me as like, what? The NFL? So it Great name, like the NFL putting out something that renders to the head and calling it helmet is just like, oh my God, that is the perfect name.
-
-[26:01] So I love that. But then I just, oh man, I ran into so many weird bugs and edge cases every single time I tried to use it, which often I ended up compromising on behaviors because it just didn't work and there was no viable alternative. So excited to see. First party support for that without having to use a janky out of date library from eight years ago.
-
-[26:21] So that's nice. Kind of related to that, so, you know, keeping the theme of dumping stuff in your rendered output, they're also adding better support for style sheets in rendered output. They call this out in the release page saying, Style sheets require careful positioning of the DOM due to style precedence rules.
-
-[26:38] And I guess this is going to be a little bit related to the patching platform things. They've got a precedence prop on these link tags. So you know, so not only can you now render link tags in your output instead of having to figure out how to put them in your head, then you can just put them in your rendered output anywhere, signal what level of precedence they should have, and React will do the work to figure out.
-
-[27:04] Where it should live. Interesting. Seems to unlock a lot of new ways of using CSS in your React projects. It strikes me that it may inspire a new wave of, like, maybe not CSS in JS libraries, but may inspire new ways of Making use of CSS from your React components, of scoping your styles to your logic.
-
-[27:29] Definitely find that interesting. And another slightly related feature is the port for async script tags they talk about. Previously it was considered kind of, actually I don't know that I ever saw enough discussion of this to say considered an anti pattern. Just didn't feel right to render a script tag from your React component like you're already in JavaScript.
-
-[27:48] Why would you then load more JavaScript from your rendered output of your component? It feels weird, but they're calling out support for async scripts normal. They say normal scripts and deferred scripts, load and document order, which makes rendering these kind of scripts deepen your component tree challenging, you know, that's kinda the problem I was articulating there in React 19.
-
-[28:05] We've included better support for async scripts by allowing you to render them anywhere in your component tree without having to manage relocating and duplicating script instances. So, that's, again, a little bit interesting. I can imagine, I have run into situations where using React is maybe not the best tool for a specific type of UI.
-
-[28:25] You know, like, things like A complex map, or a highly complex and interactive data visualization, or there's a lot of things that you might want to render to like a canvas, or to WebGL, or in an iframe, or things like that, where React either can't do it because of security limitations, or because, you know, you can't render A component in WebGL or Canvas.
-
-[28:50] So there are circumstances where I've either bailed out of using React and just said like, Nope, everything inside this component renders once, and then some other script takes over for it. So in circumstances like that, I could see this being a significant experience improvement. And again, building on that, they're also adding support for preloading resources.
-
-[29:09] So the React DOM package now exports a couple of new, I guess I'll call them helper functions, listing them here. PrefetchDNS, Preconnect, Preload, and Preinit, which are similar to like the link or meta tags. You give it a URL and. Sort of a configuration object, and it signals to React that you will want these assets, but not right now.
-
-[29:30] It's not like rendering out a style tag or a script tag, but it's saying, here's a resource. I want you to resolve the DNS, or connect to the resource, but don't start loading it yet, or start loading it, but don't start parsing it yet. So it looks like a lot finer grain control over external resources.
-
-[29:49] So combined with greater level of control over how resources get loaded, and then clearer, simpler semantics around taking those resources and rendering them from a component, It does seem like it unlocks a lot of really powerful behaviors. I think it's going to introduce some churn into the ecosystem, but I can at least see, I have run into a lot of problems where I can see this set of tools being a pretty big unlock.
-
-[30:17] So excited to see it.
-
-[30:18] **Mark Erikson:** And then one more item that's all the way down at the very bottom of the beta release notes is support for custom elements aka web components finally work properly inside of React. I've never used web components. I've tried to read the threads that have had hundreds of comments and complaints.
-
-[30:40] I have a vague partial sense of what the problem space is. In general, like with React, we pass props and we pass real JavaScript values, objects and numbers and whatever. But with web components, there's the issue that, you know, like there, there's something about the attributes versus properties distinction.
-
-[30:59] Like HTML is you're defining attributes that are strings. DOM objects have properties that can be mutated and these are not always the same thing. So like you, you can't just always directly pass real objects into a custom element, the same way we would pass a prop from a parent to a child in React.
-
-[31:21] And there's been like a whole bunch of other interop issues trying to render web components inside of a React component and pass data and handle events between these. And so the web components community has complained for years that, well, every other UI framework manages to make this cooperate. Why can't React do it?
-
-[31:43] it's a reasonably fair complaint, but there'd been an issue filed all the way back in like 2016, 2017 saying, so React, are you finally going to make this just work? And it took another four or five years before an engineer from Meta actually sat down and implemented it. Now, apparently part of the problem.
-
-[32:02] It was unclear what the exact behavior semantics should be. I guess there is no single specification for how Web Components define, like, what kind of event props they take. And a lot of questions about the exact mechanisms for passing Props from a React component to a web component. So like the React team's like, well, okay, there's like a half dozen ways we could do this, and these are kind of mutually exclusive.
-
-[32:27] We're not the experts here. How would the web component community like us to build this? And everybody had very different opinions. So that was part of the reason why this took multiple years to happen. But, eventually, there was some adequate kind of consensus reached, and so a meta engineer actually went in and did a ton of work, a couple massive PRs to implement the support, and it got merged, like, two years ago, but it was always in, you know, under a feature flag, just in the experimental branches.
-
-[32:56] So, React 19 now finally ships with, quote, proper support for web components, and all three people who care cheered.
-
-[33:06] **Carl Vitullo:** Well, one of them is in the chat here, definitely interesting, I don't know. Like you said, I've been loosely paying attention to it for years at this point, and generally loosely paying attention to web components for even longer than that, and Cool.
-
-[33:18] I don't know. Good to see. I will continue to loosely pay attention to see what kind of effects it has on the ecosystem, but I'm a little bit skeptical it's gonna make big waves.
-
-## React Native 0.74.0
-
-[33:29] **Carl Vitullo:** Cool. Okay, React Native. They have officially released their 0. 74 version, which is gonna be I actually talked to someone when I was at React Miami about some of the work they've been doing.
-
-[33:40] So the, the One of the things included in this is Yoga 3. 0. Yoga is the Flexbox layout engine re implementation that powers React Native. It's, it's one of the core technologies that facilitated React Native approximating web layout. And I had, I had spoken with someone at React Native who said that it took them a long time to sort of spin back up on development, you know, some internal priorities and, people moving, they lost some expertise on that. So they had to reinvest, re relearn how to develop it.
-
-[34:15] So cool to see that in here. It looks like it fixes a couple of layout bugs that were, you know, non standard. They were different from the semantics on web. It was something about. Like, you know, row reverse columns with like start and end edge was not behaving correctly previously, and now it is. So you may find some weird margins.
-
-[34:34] They're also removing a tool called Flipper by default. You can still add it back in. Inspecting React Native layouts, network requests. Uh, it sounds like it has a lot of overlap with the React Dev tools in, browsers. Uh, it was deprecated in 0. 73. Thank you, Cedric and chat. And is now being removed by default.
-
-[34:52] **Mark Erikson:** I'm very curious what the debugging story is. As usual, I have not worked on React Native. I don't know what the debugging process is overall.
-
-[35:00] But if they're removing Flipper, I'm curious what the intended workflow is for debugging tools. And I see someone says Chrome DevTools.
-
-[35:07] **Carl Vitullo:** Yeah. I think when I was using React Native, this is now close to three years out of date. I believe I was already using the Chrome DevTools at that point. So it sounds like this shouldn't be too impactful on too many people.
-
-[35:19] Yeah. Community CLI for React Native, I guess, to make an analogy, sort of the create React app for React Native is now. Using Yarn 3 for new projects by default. So that's a reasonably opinionated change. I know that Yarn 3 has very different semantics from Yarn 2.
-
-[35:38] **Mark Erikson:** My, I would assume that they're going with Yarn's node modules behavior by default rather than the attempt to do the plug and play, don't extract everything on disk approach that Yarn 2 tried and failed to get out there.
-
-[35:52] **Carl Vitullo:** Can confirm using node-linker/node-modules.
-
-[35:55] **Mark Erikson:** I actually got to meet the primary maintainer of Yarn, Emil Nusson in Paris.
-
-[36:00] We talked a bit about, you know, where Yarn stands. Like Yarn 4 is out, but apparently kind of, Came out a little past, you know, whatever preparation deadline the React Native team had for trying to figure out things on their end. I don't think there were too many big changes between Yarn 3 and Yarn 4, but it is interesting.
-
-[36:18] You know, we mentioned earlier that, you know, PNPM has gotten a lot of popularity. And so, like, a segment of the ecosystem is going to be pretty, you know, pretty much set on Yarn 3 for the foreseeable future.
-
-[36:30] **Carl Vitullo:** Whoa, I consider myself a Yarn user, and I didn't even know they had a version 4. 0. Looks like it was released in October of last year. Interesting. Cool.
-
-[36:38] React Native Navigation version 7 is out, which looks like some of the major improvements there are around the configuration of it. Previously, talked about how previously there were of difficulties with Types, and basically you needed to keep your types manually synced with your route configuration.
-
-[36:57] So it looks like they've made some general architecture improvements, such to where TypeScript types can now be inferred from the root navigator with a static param list type, and it'll be available anywhere UseNavigation hook. So that's cool. Needs a, like, one line script. Global namespace adjustment in TypeScript in order to enable.
-
-[37:16] But that seems like a really big improvement. Type support in your navigation is definitely a lot more safe. So that's really good. And last React Native thing I'll do is just a small shout out. There's a Vision Camera package that just released a 4. 0. Looks like it supports a lot of Powerful camera stuff, you know, like QR codes and like some other visual recognition stuff.
-
-[37:41] looks like a really cool project and definitely some big React Native relevance.
-
-[37:46] **Mark Erikson:** On the note of React Native, I was at a React Connection and React Native Connection conference in Paris last week.
-
-[37:53] And I've always been a web dev, but it was interesting to me just sitting through the React Native talks and half of the material was familiar, half of it was like a completely different ecosystem that I'd never heard of. It was very interesting to see how there's just this entire different branch of the React ecosystem that I basically didn't almost even know existed in terms of mindset and what they're dealing with.
-
-## Kotaken, RSCs with just Bun
-
-[38:17] **Mark Erikson:** So, rolling through a few items very quickly. A new experimental server component framework that I had never even heard of until I saw it pasted in the links like an hour ago called Kotaken. And the interesting sales pitch here is what would a React framework look like if Bun we re the only tool in the tool chain.
-
-[38:37] This sounds very interesting in a lot of ways. Certainly the tool setup makes it sound like it's a lot simpler. It sounds like it has some interesting variations in how they're trying to use server components. I assume based on the description that it's brand new and highly experimental, but you know, another example of playing with the baseline ideas of server components and seeing how a different framework makes different choices around it.
-
-## Bun 1.1
-
-[39:02] **Mark Erikson:** On that note, Bun 1. 1 is out and it actually has Windows support. And as the, you know, the 1 percent of web developers who is actually a Windows user, cool. Yay. I'm excited by this. I actually played with Bun briefly on a very small work project a couple of weeks ago.
-
-[39:19] I was trying to prototype some SQL changes and Bun has SQLite support built in. So rather than try and mess with Postgres adapters or whatever, I just used that and it ran, it worked. I don't have further experience to report on, but I'm very excited to see BUN support getting fleshed out.
-
-## JSR, by Deno
-
-[39:37] **Carl Vitullo:** I wanted to talk about JSR, the JavaScript registry being put out by the Deno team. New registry is pretty interesting to me. We've seen a lot of experimentation in package managers, but ultimately all of them still hit NPM.
-
-[39:52] And the Deno team was talking a little bit about how that's a bit of a shame. We've had so much experimentation happening, but so little of it happening At that level, where a lot of behaviors are ultimately driven from. A couple of notable changes that they've done, this is ESM only, which is definitely going to be a pretty big level up for React. The ecosystem as a whole, I think, just, you know, ESM versus CommonJS has been such a pain for so long. I think a clean break in a new package registry might be a bit of a kick in the pants, as it were, just to kind of force the issue and say like, nope, clean break, new stuff.
-
-[40:33] They do say that JSR is backwards compatible with NPM, so that should facilitate migration at least. Obviously moving to a whole new package registry is a bit of a tough sell. Maybe not as tough as something like switching from Angular to React. As it were, but I think it's, I think it's up there. You know, if you are trying to use a new registry, but like, oops, there's no express, like that's just pretty hard.
-
-[40:58] A lot of the assumptions that you have about what open source code is going to be available. It may not be available. So I think that's going to be a little bit tough. They also said some interesting stuff like TypeScript has emerged as not only a way to write JavaScript with compile time type checking, but as a test bed for the latest JavaScript language features coming out of TC39.
-
-[41:17] That rang really true to me. So seeing a team push the boundaries of something as, you know, maybe a little bit esoteric and like less thought of as a package registry is, I don't know, I appreciate that they are also following the cutting edge Broadly across the rest of the ecosystem as well. They talk about Node is no longer the only relevant JavaScript runtime outside the browser.
-
-[41:40] Some other really cool stuff. I think something I saw was package provenance through a tool called SIGstore, this is sort of like, Supply chain attacks, if you're familiar with that, where how do you know that the code you believe you're installing on NPM is actually what you expect?
-
-[41:58] So provenance is dealing with that sort of end to end guarantee that something is what it claims to be. There have been a couple of notable Vulnerabilities, actually not even vulnerabilities, just straight up attacks where an open source project solicits a new maintainer, has malicious intent and publishes some kind of script, some kind of backdoor.
-
-[42:19] You know, whether that is trying to attack the end application that is consuming the library, or I think more frequently they have been attacking developer machines to then try to gain access to other parts of the system. I know there was a notable example a couple of months ago. Maybe years at this point ago, where somebody installed a crypto miner into a install script.
-
-[42:42] So people's developer laptops started mining crypto for them. So all that to say, package provenance as a core part of the package registry, I think is a really important area to explore. And contrasting something like package provenance Verifying contents with the, I would say, kind of failed attempt NPM did of doing like NPM audit.
-
-[43:05] You know, that was so unsuccessful that like Dan Abramov put out a post talking about how it was broken by design, like just the fundamental assumptions it made about security and how you address security issues being so wrong as to be harmful.
-
-[43:18] I have a reasonably high degree of confidence in the Deno team generally. You know, it's a project started by Ryan Dahl, who created Node in the first place. So having him come back and say, I got some things wrong. I'm going to try again in a new context with Deno. And then now expanding that into, I think that The Node ecosystem got some things wrong with how packages work.
-
-[43:40] I'm going to try that again. I think that's very exciting. I am not going to immediately jump on it and start using it for everything, but I am going to be paying pretty close attention because I think this is a serious attempt at a very complex and large problem space. Let me just run through a couple of guarantees, expectations that the JSR team has put out.
-
-[44:02] As for what a package manager should do, they say it should embrace ESM as the web standard for JavaScript modules, should be designed for TypeScript from first principles, should be simple, fast, provide excellent developer experience, should be free and open source and work anywhere that JavaScript does, and should build on the success of NPM, not fork it.
-
-[44:20] Seems pretty good. There's a couple other really good posts that I'm just going to dump in chat here. Those will be in the show notes as well. Some other things that I think are important, every module must be scoped, which I think is a positive change. It's always a little bit funny, you know, on NPM modules that don't have a scope feel somehow more official in some way.
-
-[44:39] It's so just requiring that all packages are scoped kind of eliminates that funny little. Bifurcation in the ecosystem. Like, is it scoped or is it not scoped? It also has a concept of multiple scopes per account. I saw a mention of four scopes per account as a limit. So being able to manage different scopes without having to set up like a dummy account, which I believe is how that has to work on NPM.
-
-[45:02] It's been a while since I've had to deal with that myself, but that seems like a really good idea. Interesting, useful, evolution of the ecosystem.
-
-## ⚡️ Why I like React (Even in 2024) ⚡️
-
-[45:09] **Mark Erikson:** And then hitting a couple of the lightning items really fast. We've commented how there's been a whole series of articles and tweets and complaints about, you know, being, people being frustrated with. React as a technology, based on the slow pace of development, or, you know, poor communication from the React team, or, you know, React just doesn't feel as modern as other frameworks that are adopting things like signals, etc.
-
-[45:36] And so, I thought this post on why I like React in 2024 was well written, and just a decent alternative train of thought to some of the negative chatter.
-
-## ⚡️ Netlify updates their Next.js runtime ⚡️
-
-[45:46] **Carl Vitullo:** Netlify put out a blog post introducing a new Next. js runtime, which I was pretty surprised about.
-
-[45:52] I think of Netlify as a static site host. When I think Netlify, I generally think Buildstep. Static assets, essentially static HTML and JavaScript served by a CDN. So seeing them talk about a runtime for a framework that I consider to require a server, it's pretty interesting to me. That seems like a pretty large evolution in their product offering in a pretty interesting way.
-
-[46:18] And. You know, Vercel's level of influence on React and it's coupling to the cloud runtime environment has been a little controversial to say the least. So seeing some more competition there is definitely pretty interesting. I guess relevant to that, I also saw somebody wrote a blog post discussing how Cloudflare is the best alternative to React.
-
-[46:40] Vercel, which I'll share as well while we're talking Vercel competitors. Definitely interesting. I guess this is not a new thing from Netlify. They say this is Next. js runtime version 5, so definitely pretty cool. Supports the app router, fine grain caching, on demand and time based revalidation. Oh, maybe a big one.
-
-[46:59] This is a problem that I've run into on Netlify using Next. They now support the Next image component. By default, so being able to optimize your images automatically through the next image package is definitely a pretty big, like, performance and user experience win. So that seems pretty good.
-
-## ⚡️ Design Principles behind the Next.js App Router ⚡️
-
-[47:18] **Mark Erikson:** There was also a really good tweet from one of the Vercel devs, I think just like a day or two ago, talking about design principles behind the Next. js app router. And frankly, it was an extended length tweet that really was a miniature blog post, and it talked about some of the ideas that it's really about layouts. and being able to identify which pieces of the page need data and which can be pre cached. And the fact that they actually don't expose things like the request object directly so that they can better detect which pieces could be cached versus which pieces have to be fully re rendered on the server side.So, whether or not you like the approach, it's clear that they've put a lot of actual thought into it. .
-
-## ⚡️ Node.js website redesign ⚡️
-
-[48:04] **Carl Vitullo:** I saw a blog post from Node. js about their website redesign. I thought this was a fun, technical write up to white paper, relevant to a lot of, relevant to our jobs. You know, like we do lots of website redesigns. I thought it was pretty cool. Just to see, you know, they talk about a failed attempt at restarting it with a nodejs.
-
-[48:25] dev domain. In retrospect, this might have unintentionally doomed the project from the start. Yeah, it seemed like a really good breakdown of the technical challenges and organizational struggles of Doing a major website overhaul. So yeah, definitely check that out. They talk about reassembling the airplane while in flight. Always a fun metaphor.
-
-## ⚡️ Dives into React features ⚡️
-
-[48:44] **Mark Erikson:** There's a website I've run across that has been doing a whole series of dives into the actual React codebase and picking out specific features like the new Use Optimistic hook. And talking about how they actually are implemented in React.
-
-[48:59] And one of React's strong points has been that it is a black box and you don't need to know how it works internally to be able to use it. You need to understand the mental model of the data flow. But you don't have to dig into the code and worry about the actual implementation details. But, I frequently see people asking, how does such and such a feature in React work?
-
-[49:20] And so I appreciate that the person behind this site has been doing dives into the codebase to try to explain things.
-
-## ⚡️ Honeypot releases Node.js documentary ⚡️
-
-[49:27] **Carl Vitullo:** The people behind the React. js documentary, Honeypot. io, which I believe is a recruiting platform, put out a documentary on the origins of Node. js. I haven't been able to give it a watch yet, but their React. js documentary was. Very good. Got to watch that at, on the big screen at React Miami last year, and I got a chance to speak with the filmmaker who put it together, who did all the recording, and found her very impressive. She's very skilled. So definitely check that out.
-
-## ⚡️ Flow ships React features ⚡️
-
-[49:56] **Mark Erikson:** The flow type system, which was a competitor to TypeScript and then in a sense, basically died outside of Facebook like three or four years ago, because the flow team didn't ship often and they didn't really, frankly, care about the community, has still been working on things and they recently announced some new language level features for React components. I think we might've touched this briefly last time, but they've added some actual syntax for defining components and prop types in React, which is interesting
-
-## ⚡️ Vercel updates pricing ⚡️
-
-[50:26] **Carl Vitullo:** Another small update, Vercel is cutting prices a little bit, or they are updating their Infrastructure pricing, which they expect to reduce costs for most users. So, cool. Looks like it's not a major alteration. It's not going to be like an order of magnitude fix, but it's include some like finer granularity on bandwidth costs.
-
-[50:48] So instead of per hundred gigabytes of bandwidth, it's per gigabyte. Well, which should help a lot. I saw it discussed, you know, if you use 105 gigabytes of bandwidth, now you'll be billed for 105, not 200. So a couple of little things like that. I saw some chatter about a limited number of people who had costs shoot up quite a bit, but that seems to be relatively rare.
-
-[51:11] if you have a very particular performance characteristic on how you're using the Vercel platform, it may not be a big cost savings, but it just, you know, as I was reading these, as they're breaking down the price changes, it looks generally like I would expect it to reduce costs.
-
-## ⚡️ RedwoodJS compares data fetch methods ⚡️
-
-[51:28] **Mark Erikson:** And then finally, the last one I'll mention is the Redwood JS, which we mentioned earlier, you know, had originally been focused on using GraphQL to define data fetching needs for React components.
-
-[51:40] And over the last year, they've been doing work to adopt server components. And they just put up, they put up a blog post that. Showed some comparisons in data fetching between the next AppRouter, the next PageRouter, Remix, and Redwood. there are some variations in how the tools work and some of the trade offs. I always appreciate posts that actually try to cross compare things.
-
-## ⚡️ Kuto, reverse JS bundler ⚡️
-
-[52:02] **Carl Vitullo:** I saw a neat project called Kuto. They called it a reverse JavaScript bundler. And it's around reusing your code as you're shipping updates to your application. This is something I've thought about a number of times at different companies I've worked at, but never made any significant headway on actually addressing.
-
-[52:22] You do a production build, you produce your new set of bundles, you upload those to the, to your production server. And you know, like most of that code didn't actually change. Like presumably just made, A bunch of small alterations. Like, I can't imagine that any new production release affects more than like, what, like one to five percent of your overall code?
-
-[52:43] Maybe even less when you start including dependencies and, you know, vendored code. So it looks like this is trying to sort of do a diff, kind of ship a diff on production releases, which is super cool. Like, if you can Do a new production release and know that much of the code that didn't change is still going to remain cached by your existing users, then that seems super cool.
-
-[53:06] They say, you know, just really quick, like first line of the page, for a real world site with three megabytes of JavaScript, updating the React dependency resulted in a 71 percent smaller download and a 28 percent faster startup time on an old phone. So I don't know exactly what the process of using this tool looks like, but.
-
-[53:24] Seems like a pretty compelling performance improvement. Reverse JS bundler, new category of infrastructure maybe.
-
-[53:31] That's everything I got, thank you everyone for joining us. We'll be back at the end of this month because we're recording late. We record on the last Wednesday of every month here in the live stage of Reactiflux, and we'll try to get back in your pod feed as soon as we can after that.
-
-[53:45] We gather sources from This Week in React by Sebastian Lorber, from Bytes. dev, Reactstatus, React JS Weekly, react Digest, the React JS subreddit here in Reactiflux, and direct from people publishing articles. If you see anything newsworthy, definitely let us know in the #tech-reads-and-news channel in Reactiflux, or you can email me directly at hello@reactiflux.com. Send that with TMIR in the subject line just to help me find it. It's an acronym for the show.
-
-[54:13] I read literally every email that comes in, usually even the ones that are marked as spam, so if you send me an email, it'll go in my brain.
-
-[54:20] If this is a show that you get value from and want to support, best way to do so, share it, send it to your co workers, say, hey, this seems like a really useful way to stay on top of everything.
-
-[54:29] And if you could leave us a review on Spotify or whatever platform that you listen on, that would be super helpful as well. I'm also seeking sponsors for this. I'm trying to professionalize. I've got a new logo. Looks all nice and fancy. If you are interested in getting your product or company in front of a group of professional React engineers, definitely reach out.
-
-[54:50] Thanks so much. Talk to you next month.
diff --git a/src/transcripts/tmir-2024-05.md b/src/transcripts/tmir-2024-05.md
deleted file mode 100644
index ae67c12..0000000
--- a/src/transcripts/tmir-2024-05.md
+++ /dev/null
@@ -1,640 +0,0 @@
----
-title: "This Month in React, May 2024: Updates from React Conf"
-date: 2024-05-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- [9600 laid off from 36 companies](https://layoffs.fyi/)
-- New releases
- - [[02:07](#docusaurus-33)] [Docusaurus 3.3](https://docusaurus.io/blog/releases/3.3)
- - [[02:17](#mantine-790)] [Mantine 7.9.0](https://mantine.dev/changelog/7-9-0/)
- - [[02:30](#astro-48)] [Astro 4.8](https://astro.build/blog/astro-480/)
- - [[03:18](#redwood-75)] [Redwood 7.5](https://github.com/redwoodjs/redwood/releases/tag/v7.5.0)
-- [Upcoming conferences](https://react.dev/community/conferences)
- - [[03:32](#render-atlanta)] [Render ATL](https://renderatl.com/) June 12-14, 2024. Atlanta, GA, USA
- - [[03:53](#future-frontend)] [Future Frontend](https://futurefrontend.com/) June 13-14, 2024. Helsinki, Finland
- - [[04:49](#react-norway)] [React Norway](https://reactnorway.com/) June 14, 2024. Larvik, Norway
- - [[05:01](#react-summit)] [React Summit](https://reactsummit.com/) June 14 + 18, 2024. Amsterdam, Netherlands (+remote)
- - [[05:15](#react-nexus)] [React Nexus](https://reactnexus.com/) July 4-5, 2024. Bangalore, India
- - [[05:43](#chain-react)] [Chain React 2024](https://chainreactconf.com/) July 17-19, 2024. In person in Portland, OR, USA
- - [[06:12](#the-geek-conf)] [The Geek Conf](https://thegeekconf.com/) July 25, 2024. Berlin, Germany
-- [[06:53](#react-conf-recap)] [React Conf recap](https://react.dev/blog/2024/05/22/react-conf-2024-recap)
- - [Livestream recording](https://www.youtube.com/watch?v=T8TZQ6k4SLE) (165k views 🤯)
- - [Seth Webster's mentioned thread](https://twitter.com/sethwebster/status/1792739000366809363)
- - [[08:21](#react-19-rc)] [React 19 RC](https://react.dev/blog/2024/04/25/react-19)
- - Talks:
- - [What’s new in React 19](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=8880s) by [Lydia Hallie](https://twitter.com/lydiahallie)
- - [React Unpacked: A Roadmap to React 19](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=10112s) by [Sam Selikoff](https://twitter.com/samselikoff)
- - [[09:44](#server-components-on-expo)] [React Server Components Demo on Expo](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=20765s) by Expo Team
- - [[12:12](#react-for-two-computers)] [React for Two Computers](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=18825s) by [Dan Abramov](https://twitter.com/dan_abramov2)
- - [[15:46](#qas-with-react-and-react-native-core-team)] [React Q&A](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=27518s) hosted by [Michael Chan](https://twitter.com/chantastic)
- - [React Native Q&A](https://www.youtube.com/watch?v=0ckOUBiuxVY&t=27935s) hosted by [Jamon Holmgren](https://twitter.com/jamonholmgren)
- - [[16:33](#react-compiler)] [React Compiler](https://react.dev/learn/react-compiler)
- - [Compiler playground](https://playground.react.dev/)
- - Lauren Tan’s [walkthrough of using the compiler and seeing the output](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=18825s), and Sathya + Mofei’s [deep dive into how the compiler works](https://www.youtube.com/live/0ckOUBiuxVY?si=yK4-4Ph_tm91zO8V&t=9303)
- - [Jack Herrington’s compiler walkthrough](https://www.youtube.com/watch?v=PYHBHK37xlE)
- - [Recommended for library authors to ship compiled artifacts](https://twitter.com/_gsathya/status/1792968851212169441)
- - [A talk from Lauren Tan in 2016](https://speakerdeck.com/poteto/embercamp-2016-i-can-write-my-app-with-no-handlebars-declarative-templating-in-ember) that’s spiritually related to React Compiler
- - [[23:39](#remix-is-merging-back-into-react-router)] [Merging Remix and React Router](https://remix.run/blog/merging-remix-and-react-router)
-- [[28:08](#effect-js)] [Effect](https://effect.website/blog/effect-3.0)
- - [Great 10 min intro](https://www.youtube.com/watch?v=SloZE4i4Zfk)
- - [Production-Grade Typescript talk](https://www.youtube.com/watch?v=PxIBWjiv3og) at an event they hosted
-- [[34:23](#forensics-of-react-server-components)] [The Forensics Of React Server Components](https://www.smashingmagazine.com/2024/05/forensics-react-server-components/)
-- [[35:39](#nextjs-v15-rc)] [Next 15 RC](https://nextjs.org/blog/next-15-rc) ([tweet](https://twitter.com/nextjs/status/1793670209443680382))
- - Unrelated: [Vercel raised $250m](https://www.reuters.com/technology/vercel-completes-250-mln-series-e-round-325-bln-valuation-2024-05-16/)
- - [[37:05](#its-not-just-you,-nextjs-is-getting-harder-to-use)] [It’s not just you, Next.js is getting harder to use](https://www.propelauth.com/post/nextjs-challenges)
-- React Native:
- - [[39:21](#react-native-new-architecture-beta)] [“New Architecture” is now in beta](https://github.com/reactwg/react-native-new-architecture/discussions/189)
- - [[40:25](#expo-is-now-the-recommended-framework)] [“useFrameworks”](https://reactnative.dev/docs/environment-setup) - Meta announcing that you should use Expo by default.
- - [[41:17](#react-native-skia-on-webgpu)] [React Native Skia](https://www.youtube.com/live/s0wn7qpBoB8?si=HDsihzf803fTLlIc&t=2802) updates
- - [[43:39](#react-native-ide)] [React Native IDE](https://ide.swmansion.com/):
- - [[45:03](#react-native-on-tvs)] [Amazon doing a keynote talk on using React Native for TV](https://conf.react.dev/talks/14) and other devices.
-- [[48:04](#lightning-round)] ⚡️ Lightning round ⚡️
- - [[48:07](#speculation-rules-api-in-chrome)] [Speculation Rules API](https://developer.chrome.com/blog/speculation-rules-improvements) in Chrome
- - [[48:33](#josh-comeaus-post-on-usedeferredvalue)] [Snappy UI Optimization with useDeferredValue](https://www.joshwcomeau.com/react/use-deferred-value/)
- - [[49:24](#bluesky-engineering-culture)] [BlueSky Engineering Culture](https://newsletter.pragmaticengineer.com/p/bluesky-engineering-culture), from The Pragmatic Engineer
- - [[50:16](#why-patching-globals-is-harmful)] [Why Patching Globals is Harmful](https://kettanaito.com/blog/why-patching-globals-is-harmful)
- - [[50:54](#new-webkit-features-in-safari-175)] [Webkit features in Safari 17.5](https://webkit.org/blog/15383/webkit-features-in-safari-17-5/)
- - [[53:56](#why-react-query)] [Why React Query?](https://ui.dev/why-react-query) (and upcoming React Query course)
- - [[54:45](#we-can-have-a-different-web)] [We can have a different web](https://www.citationneeded.news/we-can-have-a-different-web/)
- - [Athena Crisis is now open source](https://cpojer.net/posts/athena-crisis-open-source)
- - [Security Risks of Postman](https://www.leeholmes.com/security-risks-of-postman/)
- - [Angular v18 is now available!](https://blog.angular.dev/angular-v18-is-now-available-e79d5ac0affe)
-
-**Carl Vitullo:** Hello everyone. Thank you for joining us for May's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. We have so much news this month because there was ReactConf and so many of the things that we had been discussing over the last three or four months actually like dropped and landed. [00:23]
-
-And are available and there are eight hours of talks discussing all of the things that we have been like punditing and talking heads about direct from the source. So I am excited about that. We're going to dig into it. [00:34]
-
-But first, I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux, where I run community programs like these and build tools to help keep the community running. [00:44]
-
-Before I hand it off to Mark I'm gonna hand it off first to our new guest host for the month where it's a bit of a trial. [00:50]
-
-**Mark Erikson:** I think he's gonna do fine! [00:51]
-
-**Carl Vitullo:** Mark, thank you for introducing me to our new guest host! Do you want to introduce yourself? [00:56]
-
-**Mo Khazali:** Nice to be here with you all. So my name is Mo. I head the mobile team at Theodo and I've been sort of an active part of the React and React Native ecosystem for a few years now. And I help organize some meetup groups like the React Native London meetup and have here and there dabbled in some open source contributions within the ecosystem with libraries like Expo and Tamagui. [01:16]
-
-Very happy to be here with you all and looking forward to chatting all things React Native. [01:20]
-
-**Carl Vitullo:** Awesome. Thanks for joining us. [01:21]
-
-**Mark Erikson:** And I'm Mark Erikson, my day job is working at Replay. io, where we're building a time traveling debugger for JavaScript. And outside of Replay, I do Redux stuff. [01:30]
-
-**Carl Vitullo:** Some quick hits before we get into the main news. [01:33]
-
-## Layoffs news
-
-**Carl Vitullo:** Quick layoffs overview from layoffs. fyi. This month, over May, there were 9, 600 laid off. from 36 companies, which is down quite a bit actually from April. last month in April, there were 22, 000 laid off from 57 companies. So that's improving a little bit. So far, this year has been substantially better than last year, but that's not saying very much because last year was like, the worst year in the last 20 years. So improving steadily is still not great. [02:02]
-
-## New Releases
-
-**Carl Vitullo:** Some new releases. It looks like there's been a couple of new releases in sort of the fallout of React 18. [02:07]
-
-## Docusaurus 3.3
-
-**Carl Vitullo:** 3 coming out, there's a Docusaurus just doing a minor release on 3. 3. Nothing too new there, it's basically just like fixing some new warnings that popped up. [02:17]
-
-## Mantine 7.9.0
-
-**Carl Vitullo:** Mantine has also put out a 7. 9. 0 release. Mantine seems pretty cool, I haven't played with it too much myself, I don't play with very many UI toolkits, but this is high on my list of ones to look at. [02:30]
-
-## Astro 4.8
-
-**Carl Vitullo:** There's also Astro 4. 8, which just came out. They're coming out with a couple of new things that look pretty interesting. You know, also like classic performance improvements and bug fixes. They have an experimental Astro Actions, which, you know, okay. We have one more thing in the ecosystem called Actions, which is unfortunate, they pitch it as, "actions make it easy to define and call backend functions with full type safety from your client code." And full type safety on a backend request is wonderful. Happy to see that. That's pretty great. [03:00]
-
-They also have an experimental request rewriting feature. Request rewriting is pretty important on a large production application. It's where you receive a request on one URL and handle it internally as if it was a different URL. So you can do stuff like aliases or rewrites or silent redirects and things like that. [03:18]
-
-## Redwood 7.5
-
-**Carl Vitullo:** There's also Redwood 7. 5. I recently spoke with the Redwood folks at ReactConf and it got, it actually got me a lot more excited about the project. [03:26]
-
-## Upcoming conferences
-
-**Carl Vitullo:** All right, switching into some upcoming conferences. Me and Mo are going to bounce off each other here a little bit. [03:32]
-
-## Render Atlanta
-
-**Carl Vitullo:** In two weeks, I am sad that I will not be able to make it to this one, but Render Atlanta is happening June 12th through 14th in Atlanta, Georgia. [03:41]
-
-Looks like a really great conference. I have heard nothing but phenomenal things from past years, and it looks like a great crew is heading out there this year. So yeah, definitely check it out if you are looking for a conference this month. [03:52]
-
-Yeah, Mo? [03:53]
-
-## Future Frontend
-
-**Mo Khazali:** And just around the same time, so June 13th to 14th, Future Frontend is happening in Helsinki. [03:58]
-
-So that's up north in Finland. And I can personally attest to how good this conference is. It's one of those conferences that has a real community feel to it. You know, 100, 150, 200 people coming. And everyone is super passionate about building front end apps, not just in the React world, but across boundaries. And that means you get some really cool wacky ideas coming up. [04:15]
-
-Last year, someone demoed a talking hamster that was built in JavaScript, which was one of the most wacky and coolest conference talks I've ever seen in my life, and I really enjoyed it. So would definitely give it a shot if you're kind of in Europe and around at that time. [04:27]
-
-**Carl Vitullo:** And I, I believe one of the organizers is, uh, Juho Vepsäläinen. He has been active in Reactiflux from very early on, he used to have a channel himself for his project, SurviveJS. [04:37]
-
-So I, he's been on my radar for my entire career. He seems like a wonderful person. I've never met him in person though. So I'm sad that I also won't be able to fly out to, you know, I can't make the Georgia, so Finland is a bit of a tough sell. [04:49]
-
-## React Norway
-
-**Carl Vitullo:** But that week is a heavy conference month because React Norway is also happening June 14th in Larvik, Norway. I don't know anything about the organizers there. So, can't comment. [05:01]
-
-## React Summit
-
-**Carl Vitullo:** There's also React Summit, June 14th and 18th in Amsterdam in the Netherlands with a remote option as well. React Summit definitely, uh, I've spoken with the organizers in the past and they seem quite great. I have not attended it myself though. [05:15]
-
-## React Nexus
-
-**Mo Khazali:** At the very beginning of July, 4th to 5th of July, in Bangalore, in India, there's React Nexus. Now, last year I had the pleasure of attending React Nexus, and it was such a great community. [05:24]
-
-I gave a talk then and really just an amazing level of energy there. I think it was about four or five, 600 developers all there. And I really felt like there was something unique about it. There was a lot of passion and a lot of drive there and people were just genuinely interested in learning. So really would recommend it if you're kind of near the South, South Asia area to definitely give React Nexus a try. [05:43]
-
-## Chain React
-
-**Mo Khazali:** Around a couple of weeks after that, there's Chain React. So that's July 17th to 19th. That's in Portland, Oregon. Now, I haven't had the opportunity to visit Chain React, but I'm very close with some of the organizers of it, the folks from Infinite Red. I've met them here and there at different conferences, most recently last week, actually, and they are a lovely crew, are a lot of fun, genuinely so much energy and fun, and I've heard nothing but great things about Chain React. So if you're US based and can make it out to Portland, definitely would recommend going to Chain React. [06:12]
-
-## The Geek Conf
-
-**Mo Khazali:** And then a week after that on July 25th, there is the Geek Conf. I happen to know these organizers because they're a key part of the React Native community, the folks from GeekyAnts, and they are hosting a conference in Berlin. So it's the first year that they're doing this and I'll be doing a talk there. So a shameless plug that you should definitely come around and we should hang out. [06:31]
-
-But the Geek Conf is really kind of intersecting web and React Native, which I think is the direction that the ecosystem is going towards. They have some really great lineup of speakers coming around. Folks like Tejas Kumar and Bruno Polino and many others, not including myself there, which I don't consider myself to be a great speaker. So you should come for those folks, and maybe we can hang out in the process as well. [06:50]
-
-**Carl Vitullo:** Let's jump into the main content then. [06:53]
-
-## React Conf Recap
-
-**Carl Vitullo:** Obviously the main subject this month is going to be React Conf. They put up a post on the blog with a React Conf 2024 recap, which is phenomenal. [07:03]
-
-Something I appreciate, they link to the section in the live stream where each of the talks happened. So appreciate that. I feel like so many conferences take weeks to get their conference recordings up. So just leaving the live stream up and linking to the talks. What a solution, it's so good. Something else I found impressive. The livestream recording already has 165, 000 watches. Nope, sorry, since I watched it last night, it's now up to 167,000, which is wild. [07:29]
-
-They open with a recorded bit from the CTO of Meta and then go to Seth Webster, manager of the React team. And he just shouted out on Twitter after the fact, because he was getting some questions about his voice, he apparently had COVID and has had some enduring health effects as a result of complications from that. So I just thought it was really like powerful of him to take center stage, introducing the concept, knowing that that's his experience right now. So, I just wanted to shout that out. He put up a really good, a little explanation of it after the fact. And, I just thought it was really powerful. Wanted to give that a little bit of a signal boost. [08:04]
-
-**Mark Erikson:** Nice to touch on the fact that there are real people with real human concerns involved in building the tools that we actually use. [08:12]
-
-**Carl Vitullo:** Yes, the human aspect of React. But yeah. Let's also dig into some of the technical aspect of React as well. Mark, you want to lead us in here? [08:21]
-
-## React 19 RC
-
-**Mark Erikson:** Happily. Pointing to a couple of the big announcements from the conference. The first one was that React 19 itself has actually gone straight all the way from beta to release candidate. [08:31]
-
-I wasn't sure that they would even get to this step by the conference, but clearly they feel pretty good about the overall stability of, you know, what they've been trying to work on. I'm not going to try to go through all the various features and everything. If you've been listening to the podcast for the last few months, you've heard us discuss most of them at some point. [08:49]
-
-And the blog post itself does actually touch on all the major things that are in there. Things like, you know, hooks for dealing with for the new HTML streaming capabilities for things like assets. A lot of different stuff in there and whether these are going to have direct relevance for your own application will always vary, but there's been a lot of time and effort put into all these different pieces and how they tie together, even strictly on the client side, beyond things like server components as well. [09:21]
-
-Definitely worth taking a look at the RC blog posts, a great summary of what all is there in React 19. Related to that specifically, of course, there were talks at the conference that then went deeper into some of these aspects. Lydia Howley and Sam Selkoff both had talks that kind of gave overviews of the pieces there, especially some of the server component stuff. Worth watching those if you get a chance. [09:44]
-
-## Server Components on Expo
-
-**Mark Erikson:** Along with that, there was also a talk from the Expo team and Evan Bacon talking about how server components might actually fit into the React Native side of things. Mo, you have any thoughts on that one? [09:55]
-
-**Mo Khazali:** Yeah, so, this is something that the Expo team's been kind of silently working in the background for a little while, there was an interesting tweet that Evan had at one point. I think it was in a tweet exchange where he was like, if you look through my Git commits and my sort of hobby repos, you'll see the direction that Expo's going, because it's a very direct sign into my psyche. And you can see that he started working on this several months ago, and it's finally come to fruition. [10:15]
-
-But they've kind of been trying to work out what server components mean in a React Native ecosystem, which was, it was a big question mark, I think, for everyone in the community, because traditionally mobile apps are client side, and what does it mean to have the server rendering native layer components and elements? [10:31]
-
-I think they delivered on a phenomenal demo. There's still a long way to go before it reaches production and something that we can use, but really the core is that as long as there's sort of native layer supports for the right components, you can stream any JS that you want across the wire that's sort of serialized in the RSC way. [10:48]
-
-And then that can render native layer components on the device, which is quite cool. And what that means is you can basically stream JS that can orchestrate certain native behaviors, like maybe showing a native share card or showing a contact card on someone's phone. Those are sort of native elements, but they can still be orchestrated and sent across the wire with JS. [11:05]
-
-I'd really recommend going through and watching the demo that they had, because the majority of the talk is actually the demo, and you'll get a real good sense of what that means and what it would look like in practice. And interestingly, in the aftermath of it, it fueled a massive debate across the entire React Native ecosystem on the place where debates always get fueled, which is Twitter or X these days. It was a question of, because you can just basically send any JavaScript across the wire that will change how the app behaves, what does that really mean for Apple's terms of service? [11:32]
-
-And there was a bunch of people who were like, this absolutely violates Apple's terms of service. Your app will get rejected. Why is Expo doing this to the community? Why are they putting them down a rabbit hole? [11:40]
-
-And then other people saying, no, absolutely not. You can basically replace the entire JavaScript bundle today in React Native. So why should this change it? So interesting debates came out of it, but nonetheless, there's some exciting stuff going on. And I think we're just at the very tip of the iceberg so far. [11:55]
-
-**Carl Vitullo:** Yeah, a couple months ago, I had presumed that server components were just not going to be a thing on React Native, and was very surprised that they had full plans to integrate and make them work, pretty much the same as how it does on web. [12:09]
-
-So yeah, definitely worth checking out the demo to see how they get that going. [12:12]
-
-## React for Two Computers
-
-**Mo Khazali:** On top of that, afterwards, there was a talk by Dan Abramov, where he went over the paradigm of React for two computers, kind of sticking with the server component mode and model. And it was a really primitive explanation. I really love explanations like this, where someone kind of breaks things down into the very, very basic primitives. [12:30]
-
-Like you've got a web server. Here's how you can render HTML on the web and send it across to the client. Okay, what happens if we start to extract certain parts of this, separate them out and see how you can kind of construct React server components from scratch. I think Dan did a post on, it was something on GitHub that he posted, which kind of walked through the thinking for this talk, but really articulating it in a talk, put it into a nice story. [12:51]
-
-It was quite fascinating. And I think it was a really good explanation for anyone who wants to really understand server components. I don't know if you had any thoughts on it, Mark, yourself, but I quite enjoyed that. [13:00]
-
-**Mark Erikson:** A couple bits. He actually did put up a post earlier this year on his blog called The Two Reacts, which I think directly is, the exact same line of thought that led into this talk. [13:10]
-
-If you've watched Dan over the last year and a half, he's been throwing a lot of ideas against the wall to see what sticks in terms of teaching people server components and the mental model that, and like, we're trying to figure out what mental model makes sense to both explain it and make use of it properly. [13:29]
-
-The thought process here of, you know, it's expanding React to the server, but also it's still one React tree just split across two computers is something worth trying to wrap your mind around. [13:42]
-
-**Carl Vitullo:** Yeah, I was just thinking of whether I wanted to share this under the React compiler notes, and I think I'll get deeper into it. [13:47]
-
-But, I do think that this is a continuation of a pretty stable vision that the core team has had for React. From the outset, server rendering was something that was, you know, ostensibly possible to do with React. And there were many years and people were just kind of like wild westing it and doing it themselves and, you know, render to string and, Oh, cool. Now we can render a, you know, like a streamable HTML. [14:12]
-
-This is not new, it's just a new attempt at solving the same problem in a way that does it better than previously. So it's just a, you know, it's one more incremental step forward. [14:23]
-
-**Mark Erikson:** Yeah, I actually had a chance to talk with Ricky Hanlon while I was there in Vegas, actually, ironically, like five feet from where Carl's sitting right now, and he was talking a bit about, we didn't exactly know what the end state looked like, but we had a lot of intuitions about what it would feel like when we got there, and There, there was like partially a master plan, but also partially not. [14:48]
-
-It was just, we think these are the big problems we need to solve along the way. And that's how we ended up in things like hooks and whatnot. Eventually those have led to the point where now the grand vision is kind of coming together. [15:02]
-
-**Mo Khazali:** And I guess just to go in from the React Native perspective as well, me and Evan were having a chat about this at App.Js and a few other people as well were kind of echoing the same sentiment, which is it's been the same in the React Native ecosystem. [15:14]
-
-Larger scale organizations have been using server driven UI, where you kind of describe your layout in the form of a JSON object and ship that through an API endpoint or from your CMS directly to define how your page is layouted. [15:27]
-
-And server components on React Native as well are just kind of a continuation of that same paradigm of starting to move some of the layouting and some of the business logic of your front end app over to the server to kind of optimize it and also allow for more flexibility and better performance in many cases. [15:43]
-
-Like you say, it's just a natural continuation, whether you're on web or on mobile. [15:46]
-
-## Q&As with React and React Native Core team
-
-**Mark Erikson:** So, wrapping up a couple of the talk links here, there were also Q& As with both the React core team and React native core teams. I admittedly did not have a chance to watch these, but there's, I'm going to assume that there is material worth watching in both those sets of discussions. [16:04]
-
-**Carl Vitullo:** Sadly, I missed it as well. There was just too many interesting people to have great conversations with. I did hear that, I saw like a kind of snarky, sarcastic tweet from someone on the, I can't remember who now, someone on the React Native team, saying something to the effect of, like, we dropped so many bombs in this React Native Q& A and you're talking about this? Just as sort of a meta commentary on the Twitter discourse. It sounds like the core team thought that they got very deep in the weeds talking about some of the, talking about the technical details. [16:33]
-
-## React Compiler
-
-**Mark Erikson:** All right, moving along to another fairly sizable announcement from the conference and something I've been very eagerly waiting for it at the point that I almost stood up and did actually cheer when it happened. [16:43]
-
-The long awaited React compiler is now actually both open source and usable. Finally! The React team had been promising that it's real, trust us, it works. And they'd said at a couple talks last year that, you know, we're trialing it in production in a couple real Facebook sites. [17:03]
-
-It is now open source. You can now actually use it. And they've dropped a lot of information about how it actually works as well. So it's now actually officially listed in the docs. And there's instructions for setting up and using it. It's worth noting that in its current form, the way to use it is as a Babel plugin, which means that ironically we've been doing all this work to switch our build tooling over to Rust, and suddenly we might actually need to re add Babel, just to get the compiler to work. [17:31]
-
-Having said that, the compiler itself is like 90 percent it s own code, and it's really just using the Babel plugin layer as a way to manage the parsing of the code. But they've even played around with an eventual rewrite of some of the compiler logic in Rust. Um, there will likely be other alternative ways to load it into your build system down the road. [17:55]
-
-So, it's not like it's Strictly built out of Babel. One really neat piece is that they actually have a live playground. If you ever went to the Babel website, Babel has a playground that shows you, if you write some JavaScript code and have certain compilation settings activated, here's what the output looks like. [18:14]
-
-They've got a playground for the compiler as well. And I think this is really valuable on multiple levels. One, is that it literally shows you what the output will look like, so you can get a sense of the transpiled code without having to do an actual build step. It also actually has a set of vertical sidebars which show you what the actual compiler internals are outputting at each step of the transformation process. [18:43]
-
-The compiler itself is awesome. A real, no kidding, deep compiler, like, with all the, you know, real world compiler optimizations. And so getting a sense of both what kinds of passes they're doing and what the results look like, I think is really cool. There were a couple of really good talks at the conference about it. [19:01]
-
-Lauren Tan did a kind of a usage walkthrough, you know, let's add it to a project. Let's use it. The React DevTools will now show you if certain components have been optimized. She even had written her own little proof of concept VS Code plugin that would show in your editor if certain components were being optimized. That's not actually available yet that I know of. They may end up releasing like an official version of that VS Code plugin at some point. [19:29]
-
-Meanwhile, Sathya and Mofei, also on the compiler team, did more of a deep dive into how it works. And Mofei in particular did a live coding demo where she showed like, let's actually write a little Babel plugin that makes use of some of the compiler internal, and see how the output of it changes as they add each piece of the compiler logic to it. [19:50]
-
-One more good explainer, Jack Harrington had a chance to do, I think, both a video and a blog post where he walked through using the compiler and talked about some of the usage changes and the mental model aspects. I think one of the big pieces for people to understand is that this does several different things. [20:10]
-
-One is it adds like the dependency array aspects to useEffect, useMemo that we've always kind of wanted so we don't have to do it ourselves. [20:18]
-
-Another is that it overall optimizes the rendering performance of components. But on top of that, it kind of flips the mental model of React rendering on its head. [20:29]
-
-One of the big things you've always needed to know is that React renders recursively by default, and now the compiler flips it, so that finally, only components whose data actually changed will re render. So this is a big deal. [20:42]
-
-**Carl Vitullo:** Yeah, I also saw on Twitter, just sort of an open question that I thought was a good one to ask. [20:48]
-
-Jamie Kyle asked if library authors were going to be expected to ship components and hooks pre compiled. And Sathya responded that like, yep, they're just like all of the other transpiling, compiling in the ecosystem. You know, if you're authoring in TypeScript or Flow or, I can't think of any other compiled things off the top of my head, then yeah, so you published the compiled artifacts to npm, so I thought that was worth calling out for anyone here who might maintain a library. [21:17]
-
-**Mark Erikson:** It's worth noting that the compiler output does expect to use a new hook that is, strictly speaking, only available in React 19. Having said that, there is a very simple polyfill. [21:31]
-
-It's really just a useMemo that allocates an array. That polyfill ought to make the compiler's output work if your app is still on React 17 or 18. So, in theory, you could drop this into an existing React 17 or 18 application and still get the same performance benefits. Which is nice because, you know, basically nobody's on React 19 yet. [21:54]
-
-**Mo Khazali:** I guess in terms of another small detail as well, to keep in mind if you're trying to add this in, is the React compiler, as far as I'm aware, expects for you to list it as the first Babel plugin in your config, and the idea with there is they want to have the state of your code base before any other plugins mess around with it and transform it. [22:12]
-
-So, it's, that's just a little gotcha in case you are trying to integrate it. Just now into your app, hearing about this. [22:18]
-
-**Mark Erikson:** And again, with Carl, with what you said earlier, it's, this is a vision that the React team has had for a while. You know, they, they'd said early on that they designed the hooks APIs, you know, specifically the dependency arrays under the assumption that someday a future magical compiler could do that for you. [22:36]
-
-They honestly weren't sure if, and when they would ever get around to it. And it was pointed out that they didn't have compiler expertise on the team. At the time that they were making that assumption, but that was a thing that they assumed would eventually happen. You know, they played around with a proof of concept compiler called prepack years ago. [22:54]
-
-That attempt didn't work out. And even this current compiler took a couple of different attempts to really figure out what they, what it was supposed to do and how they were going to do it. But the thought process of we could use a compiler has been around for a while. A couple other quick notes to wrap this up. [23:12]
-
-Lauren Tan did a talk all the way back in 2016 that has kind of a couple indirect precursors to the thought process of the compiler and using it. They apparently used it in the official React Conf app. And the BlueSky Twitter alternative is already using it in production, partly because Dan works on BlueSky now. [23:32]
-
-And also the React core team added it to BlueSky to help prove that it would work in a separate real world application. [23:39]
-
-## Remix is merging (back?) into React Router
-
-**Mark Erikson:** I'll toss out one other announcement that came out of the conference. So Ryan Florence did a talk where he announced that Remix and React Router are merging, sort of, conceptually. [23:51]
-
-The way he put it is that Remix itself, at this point, is basically just the latest version of React Router plus a Vite plugin that adds the actual build steps. And so, rather than continuing to put more things into the Remix packages specifically, they're just gonna move a couple more things over into the React Router packages, label that React Router v7, and it has an optional Vite plugin if you want to do server usage. [24:21]
-
-Um, this of course was met with much confusion and complaining on Twitter. Personally, it makes sense to me. And it's worth watching Ryan's talk to get a sense of why they're going this way. [24:32]
-
-**Carl Vitullo:** Yeah, and this was surprising. I won't say that it wasn't surprising. I just thought that, like, Remix, I mean, they're a venture backed business. They got acquired by Shopify. I am surprised to see them say that Remix is just not going to be a thing anymore. For that, for those branding reasons, branding and funding and,[24:49]
-
-**Mark Erikson:** The caveat there is Ryan said in both the talk and the later blog post that they put up, like, we have more plans for Remix as both a brand and a set of tools that we want to circle back to in a few months. [25:05]
-
-Like, we have some idea of something new we want to do with it, but for now the focus is like, let's just roll all this stuff into the next version of React Router and then you can pick and choose whether it's just doing client side stuff or server side stuff too. [25:19]
-
-**Mo Khazali:** And I guess on the Shopify piece, Carl, I'd love to get your thoughts, but I feel like Shopify kind of achieved what they were trying to achieve with Remix, which was ultimately they took it and made it the backbone of Hydrogen, which was their own sort of, I guess, framework, so to speak. [25:33]
-
-And it's great if you've ever used it to make a Shopify app. I don't know if that, maybe they're looking to get more out of it or not, but I feel like it probably achieved at least some of the purpose of why they, they, backed it as a framework and invested in it. [25:44]
-
-**Carl Vitullo:** That's true. Yeah. And I guess, actually, I don't know this, but I think it was an acqui-hire, they started working at Shopify? Yeah. So that, that certainly makes sense, Shopify got their value out of business transaction for sure. But, so I guess, as surprising as it was to me for them to announce that they're now moving back to React Router as their primary brand for the work they're doing right now, they also have a long history of doing things like this. [26:09]
-
-The React Router folks put out React Router and then they've done at least one, I think, departure that sort of builds on because they had done Reach router for a while because they had some new concepts that they wanted to explore. And I think that is a phenomenally responsible way to approach public experimentation in an open source setting. [26:30]
-
-They have a large enough audience that if they announce a new project, people will give it a shot. And I think it is so smart, in terms of, like, branding and messaging and, managing expectations, I think they are tremendously smart and thoughtful about how they use brands, because, you know, you can do, like, a major version, you can do a beta or an RC, or, you know, do, like, an experimental phase in a project, but I think it is really great and honestly kind of them to the community to say like no This is different enough that we are giving it a new brand and we're gonna experiment and then now twice now They've said "cool, we learned a bunch of stuff and we're just gonna bring it back, now it's just React Router again." [27:12]
-
-So because React Router specifically React Router is such a like foundational part of the Ecosystem. Like, you know, the React team has never blessed a routing tool to use with React. So it's, they've always just been the de facto one to use. And I think it is really marvelous that they have taken that position with such seriousness and done this kind of thoughtful experimentation with it. [27:38]
-
-**Mark Erikson:** I can vouch that naming and branding and getting people to migrate is a really hard problem. [27:45]
-
-**Carl Vitullo:** I want to call that out, I think it's really clever and smart and, just having been in the ecosystem since 2015 and watching a lot of thrashing and watching a lot of arguing on Twitter about like this and that and the other, I think they've been really consistently great about, once all the dust settles, at the time it was kind of confusing, but so I guess I want to be the voice that's like," it's going to be okay." [28:08]
-
-## Effect JS
-
-**Carl Vitullo:** Okay, moving on to the next subject, I guess. This was a subject that I almost brought in on the last episode and held off because it seemed a little bit too out there. But I dug into it a little bit over the last month. [28:19]
-
-Effect, they have released 3. 0 and they are now calling it production ready. It, it had crossed my radar in April with some people asking folks like Kent C. Dodds and other prominent educators, what they thought about it. So, and the consensus I saw then was like, looks neat, but it's real big. That's a lot to learn. I'm not, I'm not dipping my toes in yet. [28:41]
-
-And basically what I understand it to be is a, it's almost a standard library for TypeScript, but it's also. Like a functional programming kind of paradigm, like it introduces new concepts for all the way down to console. log. So there's a fetch replacement. There's a console. log replacement. There's a promise replacement. It's an enormous surface area for the API. So in a very real way, it's like learning a new language, which is why I held off on this, because it's a Big swing. [29:15]
-
-It is an enormous swing. One of the reasons I decided to bring it in is that I learned while digging into it that Johannes Schickling is one of the people backing this, one of the creators of the project. And he's been, I can't remember what his first project was. I've been following him for, it feels like forever. He was the founder of Prisma, which was a very influential ORM, schema declaration model. [29:40]
-
-**Mark Erikson:** He's done some GraphQL stuff, and I actually had a chance to meet him in person back in December, and one of the ideas he's been playing around with is like a local first application where every single bit of the code from fetch data to literal client side state is held in an in memory SQLite database. [29:59]
-
-So, like, rather than a bunch of used state hooks, he's got, like, reactive hooks that tie into SQLite running as WASM in the browser, and literally every bit of data in that example. is coming straight out of that SQLite database. Which sounds odd, but when you see it in practice, it's like, oh, I can see the intent behind why he's playing with this idea. [30:22]
-
-**Mo Khazali:** I don't know if you folks recall Project Lightspeed, that Meta did a few years ago, I think it was like 2019, 2020. With the messenger app that they did, it was a very similar approach, which was everything on the client side is backed by SQLite database, the data fetching, the layouting, the local state. So I don't think it's an, it's that odd of a paradigm. [30:40]
-
-It sounds like a, it could be a good scalable way to handle things. So interesting to hear that somebody else is like digging into that vision, Mark. [30:47]
-
-**Mark Erikson:** So with the effect thing, like I echo what you're saying, Carl, is like, just trying to describe what the project is. And a couple bullet points is hard. If I could attempt to restate what you were saying a minute ago, it's multiple different pieces. [31:01]
-
-One is that there's some similarity to the Redux Saga package, where instead of using Async await syntax, and actually kicking off things like async requests right now, I think your code uses generators and generally returns descriptions of like what kind of side effectful behavior you want the code to execute. [31:26]
-
-But nothing actually happens until you return those descriptions to some kind of runner that actually goes off and does the work. Another aspect is that instead of relying on throwing errors just from any piece of the code, you actually end up specifying at the type level that this function could return a number and could throw a, like, could not parse integer error, or something like that. [31:54]
-
-And so you, like, it's a very, like I said, functional programming way of modeling code. Returned values versus possible thrown errors, and they have an entire JavaScript standard library built up because as we all know, one of the weaknesses of the JS ecosystem is we don't have much of a standard library built into the language itself. [32:17]
-
-And there's a whole bunch of primitives around async concurrency. So things like retries and, you know, iteration, backoffs, and that sort of thing. So, like, that, as usual, I've not played with it, I've only tried to skim over the docs, and, yeah, like, my own reaction is like, Wow, that's a lot, I can't even wrap my head around this, but I think that's the best description I can come up with, and I think I see where they're trying to go with this. [32:45]
-
-**Carl Vitullo:** I did dig around a little bit more than trying to read the documentation. I was directed to, a wonderful 10 minute introduction about it. That was what really sold me, and I'm like, yep, okay, we're gonna talk about this. So I definitely recommend checking that out. Um, from Ethan Niser, yeah, just, it's a great 10 minute introduction. [33:02]
-
-And going back to Johannes Schickling, he gave a, an hour long talk titled Production Grade TypeScript at, they put on a conference, they put on a conference already, Effect Days 2024. It was also great. It was much deeper in the weeds. At one point he said, like, "I'm sure that a lot of people watching this talk on YouTube are going to be angry I'm not explaining what effect is." And I was like, dang it, that's me. I wanted to know what effect is (laughter). But it was a great talk besides that, uh, it just didn't quite answer the question I was hoping for. [33:32]
-
-If he's got bona fides in, like, querying, schema, GraphQL, as well as local first, like, to me, those both extensively deal with the hardest parts of asynchronous behavior, with, like, retries and backoffs, like you were mentioning. So that is A lot of very deep experience with some very hard problems. [33:53]
-
-And I do love local first. I think it is an absolutely wonderful paradigm and it is very challenging right now. So if we end up getting a relatively widely used and supported standard library that makes things like exponential backoff and retries and responding to different kinds of errors in different ways. Then. All of the myriad things that make asynchronous behavior difficult, then that sounds pretty cool. [34:19]
-
-I'm pretty excited about it. So, I don't know, that's, that's all I will say on effect. [34:23]
-
-## Forensics of React Server Components
-
-**Mark Erikson:** All right, moving along. We've discussed and linked to a lot of articles over the last few months that attempt to dig in and explain various aspects of React server components. [34:34]
-
-What are they? Why would you care about them? How do you use them? How would you even go about building your own server components based framework? [34:42]
-
-And we want to point to one article along those lines this month, the forensics of React server components. This one does a really good job of laying out a lot of the different pieces and how they fit together. [34:54]
-
-It talks about, you know, client side rendering and kind of illustrates some of the data fetching and rendering workflow, server side rendering, and how data gets fetched on the server and rendered and loaded into the client. Hydration and servers and some of the issues with that, and then goes and digs into server components and kind of walks through a lot of what the data flow and mental model of where data and where server components fit into the life cycle, how the data fetching behaves, the interactions between server components and client components, and even shows some examples of the serialized output that server components return. So, it's a pretty good one stop shop for kind of wrapping your head around some of the actual usage and mental model of server components. [35:39]
-
-## Next.js v15 RC
-
-**Carl Vitullo:** Okay, uh, Next15 has an RC coming out, or that is now out. [35:44]
-
-Not entirely related, but I did see that Vercel has now raised 250 million dollars. So they are capitalized for a good minute longer. They're not going to go out of business anytime soon. [35:54]
-
-But yeah, Next 15 supports React 19 and the compiler, they have changed their caching behavior pretty extensively, which I had understood to be one of the bigger pain points of using the app router. They have an experimental API called Next After, which solves a problem where you can schedule work to be processed after the response from the server has finished streaming. It solves the problem of needing to figure out, needing to guess when the response has come in. I think that's pretty neat. [36:22]
-
-They also have a neat feature, they call it partial pre rendering, it is neat looking to me. They say, you can wrap any dynamic UI in a suspense boundary, when a new request comes in, Next will immediately serve a static HTML shell, then render and stream in the dynamic parts with the same HTTP request. That sounds a lot like out of order streaming that I had heard some stuff about in the past. [36:43]
-
-I mean, that's always been the dream of server side rendering is you make a request, you immediately respond with something, so it's not just a blank screen and then fill in the rest of the bits. So it seems like a clear improvement to me to be able to do that in a single HTTP request without having to open a new connection and do all the TCP handshaking. So that, that should be a pretty good performance improvement. [37:05]
-
-## It's not just you, Next.js is getting harder to use
-
-**Carl Vitullo:** I just wanted to call out an article that I saw entitled, It's Not Just You, Next. js is Getting Harder to Use. It just kind of calls out the increasing complexity of the framework. It's a little pessimistic, it's a little down note, but I think it's reasonably fair. [37:20]
-
-Just to call out a couple of sections that seemed worth it to me. You need to understand a lot about the internals to do seemingly basic tasks. There are many ways to shoot yourself in the foot that are opt out instead of opt in. This is just a funny bit talking about like, you know, you go to a GitHub issue and you see an explanation of why that thing that you want to do isn't possible and go like, "oh, that does make sense." But they say, you probably read this and left with five more things to Google before realizing that you probably have to restructure your code, which is Brutally familiar. [37:49]
-
-So, and on the app router, if you started a Next project, Next will default you into it, which implies that it's production ready. It implies that if you're starting something new that you're going to ship to production, you should use the app router. [38:02]
-
-But this article calls out, "the official React docs don't share that same sentiment. They currently recommend the Pages router and describes the app router as a bleeding edge React framework." So, it seemed like a really good, really fair. Non complementary discussion of Next. [38:17]
-
-**Mark Erikson:** I've seen a number of folks complain that the app router works great for the layouty stuff, but some of the integrations have been both buggy and somewhat hard to use. [38:28]
-
-One comment I saw was the effect that, ironically enough, the app router Works better for static pages and the pages router works better for applications in terms of data fetching. So the names almost seem a little bit backwards, ironically. [38:43]
-
-**Mo Khazali:** I don't know about you folks, but when the App router came out and you know, I've gotten more and more used to it as time passes, but I just found that the pages router, even just things like being explicit with, you know, whether you're doing get server side props or you're doing get static props, just found that I love the fact that it's explicit, so at least you as the developer have to explicitly define how you want sort of that page to be rendered, rather than sort of the automated, magical nature of the app router. [39:08]
-
-I do miss that sometimes, but there's also a lot of benefits to having the app router, so I guess it's, as with all things, there's trade offs with it. [39:15]
-
-**Mark Erikson:** All right, Mo, you have a lot more expertise on React Native than either the two of us. Want to hit some of those highlights? [39:21]
-
-## React Native New Architecture beta
-
-**Mo Khazali:** Let's jump into it. So let's start off with Meta news. Firstly, we've been hearing about the new architecture for years now, if you've been in the ecosystem, uh, but they have officially put it into beta, which is a big deal if you've been here for a hot minute and the word on the street unofficially is that we might finally see it going into production or going into default and out of beta sometime this year. We'll see if that happens, but it'd be very exciting. [39:46]
-
-The good news with all of this is there's more and more, uh, Third party libraries or open source libraries that are coming with new architecture support. And I think that's the real bottleneck right now is one having a good interop layer, which the folks shipped last year from the meta team. [40:00]
-
-So that helps kind of ensure some level of backwards compatibility, whether it's with the layouting engine or with the rendering engine, but I think it's a really good step that they're going into beta and soon more and more libraries are going to support new architecture. [40:12]
-
-There was this massive Google Sheet that just had all of the libraries that currently support new architecture that are commonly used in, in, in the community and some of the ones that don't yet. So it's, it's going in that direction. I think everyone's trying to push and get, get it finally over the line. [40:25]
-
-## Expo is now the recommended framework
-
-**Mo Khazali:** Uh, in other news, Meta, both in React Conf and also at AppJS did kind of similar talks about how you should use a framework. So if you've been in the React space with Next, you will be familiar with this. Very much, but the idea here is that they've officially came out and endorsed that you should use Expo by default. [40:43]
-
-And this isn't anything new. If you had been frequenting the React Native docs for the last couple years, they give a nod to Expo here and there, they use Expo Snacks for the coding examples, and they kind of make points to say you should go and check out Expo if you're starting out a new app. [40:59]
-
-Um, but now they've explicitly said, you know, you should use a framework for the same reasons that you see in the React ecosystem. Routing, um, tooling, and having the right ecosystem in place, which I think is a great step because it really, using something like Expo really saves developers a lot of, uh, hassle and a lot of difficulty that you oftentimes face if you're just on a bare React Native project. [41:17]
-
-## React Native Skia on WebGPU
-
-**Mo Khazali:** Now, going into community news, these things are fresh off of the press, predominantly out of App. js that happened last week. So, the first thing that I think was incredibly exciting was that we got some updates on React Native Skia. React Native Skia has been a 2D rendering sort of canvas that you can use in React Native to draw graphics, nice animated graphics, sometimes interactible graphics if you want to integrate it with things like Reanimated or GestureHandler. [41:43]
-
-The announcement for this was in some ways the most amazing and also the most sort of cheeky announcement possible because it was sort of Apple esque intros with sort of rainbow colors going to form a hello and really just showing that they're very much great graphists at heart that are working behind this. And Skia is backed by Shopify as well. So it's got massive backing. It's a great project. So you should definitely check it out. [42:05]
-
-Previously Skia was mainly used for 2D graphics. So it gave you a canvas. You could draw things on it. And people had I've been using it to kind of extend the boundaries to create what they call 2. 5D, which is 2D graphics that kind of resemble 3D, and through the illusions of looking at it, they kind of look like they're 3D, but they're still just rendered on a 2D graphic, uh, and this has a few limitations, it runs on the CPU, it's not really truly 3D. If you want to do anything like interactivity with it, you're quite limited by sieve there in terms of your performance. [42:35]
-
-And hence, the talk that they had at Appjs was called Hello GPU. So first they started off saying, ah, there's video support now, so you can do a whole bunch of shaders on videos, which was quite cool, but really the key thing that was exciting was that they actually brought WebGPU into the React Native world. [42:50]
-
-So you can use WebGPU to obviously target web, uh, with React Native Skia, if you're using React Native on the web, but you can also use it for iOS and for Android and having those sort of cross platform 3D visualizations and rendering, I think is going to be really cool for the community and not something that we've actually been able to do very effectively on the GPU layer. [43:09]
-
-And they've integrated all the way down into the native layer APIs, so, Metal on iOS as an example. Especially with something like React Native running on Vision OS, where you really want to have these 3D objects that you kind of put in your vicinity in the spatial navigation paradigm. [43:24]
-
-It will be so cool to be able to actually use that as well for VR and not just on Vision OS, but also maybe on some of the Quest runtimes and so on and so forth. So I think it's, it's a really cool step and it stops us from having to drop into the native layer as we've often had to do with this type of thing. [43:39]
-
-## React Native IDE
-
-**Mo Khazali:** Next up on the announcements from AppJS, we saw the React Native IDE. So this has been kind of teased by the folks at Software Mansion for a long time. We've had a lot of sort of disparate tools in the React Native ecosystem. You know, when you're usually developing with React Native, you have to have your terminal running your Metro bundler and then maybe have Some Chrome DevTools running connected to the React Native DevTools to kind of, uh, your network requests coming in and analyze your source code. [44:04]
-
-And then if you want to dig in and look at what elements are being rendered, where it's all really just sort of a bunch of different parts to the dev experience. And it's not been amazing. There's obviously been a lot of improvement. And if you come from the native world, sometimes those things can be a lot more integrated with Android Studio and Xcode. [44:20]
-
-And so the lovely folks at Software Mansion have developed an IDE and it does some really cool stuff. I won't go into too much details. It does everything you would expect from an IDE. And I think it brings first class DevEx into the React Native world. It's going into beta or went into beta last week. [44:34]
-
-And the coolest thing out of all of the demo was debuggers across the native boundaries, so when you put in a debugger, it not only could handle debugging on the JS code that you write, but you could also place debuggers inside of your node modules on the iOS Swift code, or maybe your Android code that you have written in Kotlin, which I think is really cool, because one of the challenges is you're kind of fiddling between Xcode and Android Studio and also Visual Studio Code, And this brings it all into one place, which is really quite exciting. [45:03]
-
-## React Native on TVs
-
-**Mo Khazali:** And then the last thing that happened around React Conf, and they nodded at it again at AppJS, was around Amazon doing a keynote talk about using React Native beyond web and mobile. And so Amazon has started becoming a big proponent of React Native in general, but also React Native on TV specifically. [45:20]
-
-And they have actually been using React Native for years now. They kind of hit it very cleverly where you couldn't really see it on first glance in the app binaries, but they came out with a big bang announcement last year saying we have actually been using React Native for a very long time, and it's been most of our apps. Huh. Gotcha. [45:35]
-
-And so it was quite a nice announcement in that, well, there's more people using React Native and that's always a good show of faith in the technology for the community. But it was quite funny that they hid it for so long. [45:45]
-
-Amazon obviously does a lot with Firesticks and TV devices, and their OS is based off of Android. So you can build TV apps for it with React Native. And I think they're very keen on people using React Native just because of its cross platform nature. They talked about many different things, challenges of performance and spatial navigation on TV. One thing, if anyone is interested in React Native for TV, a bit of a shameless plug here, so I apologize to you both, Carl and Mark. [46:12]
-
-**Mark Erikson:** Shameless plugs! Gasp! [46:15]
-
-**Carl Vitullo:** Who does those?? [46:16]
-
-**Mo Khazali:** Questionable on my, on my character there, I'm so sorry, folks. But, as part of like some of the community stuff that, I've been doing with some of the folks from Amazon. We actually started an RNTV.dev blog, and it's kind of meant to be a centralized resource for everything about React Native on TV, because that doesn't exist. We thought, why not make it so that we can help people onboard into it more and more. [46:36]
-
-The other last thing that they kind of dangled was they said, we want to support open source projects, especially ones on React Native for TV. So if you're interested and you've got a project that's extensively used on React Native for TV, Sign up for this form and we're gonna be, start starting to sponsor more and more projects on the React and React native ecosystem. [46:53]
-
-So if you're a community maintainer, wink wink, you might wanna check that out and see if there's something that you can, uh, get some support from them for. [47:01]
-
-And that is all of the React native stuff. Sorry folks for going into that rabbit hole. [47:05]
-
-**Carl Vitullo:** No, thank you. That's, we have a dearth of React native expertise on our end, so I'm very glad you can speak to it. [47:11]
-
-It's cool to hear more about the React Native TV stuff. Cause a couple of months ago, Oh God, probably a year ago now. I spoke to Kaleb McKelvey, I want to say it is, about React Native on TV. [47:24]
-
-In that setting. And it was a fun, interesting talk. It's an interesting input paradigm. You know, a remote control is very different from a keyboard or a touchscreen. [47:33]
-
-**Mo Khazali:** Yeah, it's really quite tough, Carl. Like, you know, we're used to touch displays or, you know, cursors on the web or the pointers or whatever it is. And then you're really suddenly limited to up, right, left, down, and a select key. And you're like, Oh, wow, how do I, how do I, what happens when I press down and I'm at the end of a carousel? Like, it's just so much, like, undefined behavior that isn't standardized. So, it's definitely a cool engineering challenge to delve into if you want something new. [48:01]
-
-**Carl Vitullo:** For sure. It's a funny, stateful mode of input. [48:04]
-
-**Mo Khazali:** Yeah 100%. [48:04]
-
-## ⚡️ Lightning round ⚡️
-
-**Carl Vitullo:** Okay, cool. On to the lightning round. [48:07]
-
-## Speculation Rules API in Chrome
-
-**Carl Vitullo:** I'll take the lead with some new Speculation Rules API in Chrome. This was a new term to me, Speculation Rules, but so this is apparently finer grained control over how Chrome will prefetch pages. [48:22]
-
-So this lets you more clearly signal to the Chrome browser whether and how it should try to prefetch something as a user, like hovers or begins to click, things like that. [48:33]
-
-## Josh Comeau's post on useDeferredValue
-
-**Mark Erikson:** Josh Comeau put out a, yet another one of his incredible blog posts. I mean, basically every blog post or article that Josh Comeau ever writes is amazing. [48:42]
-
-And this one was on snappy UI optimization with the relatively new React use deferred value hook. Now this came out in React 18, so it's actually been out for a couple of years, but frankly, almost nobody knows how to use this, including myself. And he pointed out that it's almost like a built in debounce for re rendering with a lower priority state update. [49:06]
-
-And so he gave some examples of a feature on his own blog or site that really benefited from moving some expensive calculations and rendering. In debouncing them via used, used deferred value and it really improved the smooth smoothness and snappiness of the ui. [49:24]
-
-## BlueSky engineering culture
-
-**Carl Vitullo:** Cool. I saw a pretty solid looking article from the pragmatic engineer about BlueSky engineering culture. I am all about BlueSky. I would love it if they are successful. And I always love a deep dive into engineering culture and, uh, you know, a white paper, as it were, of how an engineering team operates. So I thought it was pretty neat. For instance, they have two to three person teams with a directly responsible individual and lots of long form writing. [49:53]
-
-So it's like little things like that, I think are really cool to, you know, it's the, in our careers, we get so little, opportunity to experience different types of workplace cultures. So I think articles like these are super valuable for understanding whether there is something better for you out there. [50:11]
-
-So yeah, go check it out. Also, Dan Abramov works there, so you can learn about how Dan Abramov works. [50:16]
-
-## Why Patching Globals is Harmful
-
-**Mark Erikson:** Let's see, Artem Zakharchenko, uh, his handle is kettanito, he's the creator of the mux service worker tool. Put up a post called, Why patching globals is harmful. And, you know, sort of in response to, you know, some of the, the React and Next teams a couple other teams as well, suggesting that, like, we should patch globals automatically in various situations. [50:38]
-
-And his whole sales pitch is that, especially today, like MockServiceWorker just uses standardized JavaScript interfaces for doing this behavior, and we've collectively learned that patching globals is a really bad thing. So, you know, some useful food for thought there. [50:54]
-
-## New Webkit features in Safari 17.5
-
-**Carl Vitullo:** There was a great post from New WebKit Features in Safari 17. 5. [50:59]
-
-This caught my eye just because in so many cases, Safari is the last browser to implement something. So seeing oh, Safari implemented something, just caught my attention as like, Maybe we can use this now. It looks like Firefox is still a bit of a laggard on some of these features, but, there's a light dark function, light dark as a CSS function, which is a bit of a simplified developer experience for doing dark mode. [51:25]
-
-So it previously there had been a media query for, I believe it was prefers dark mode. That doesn't sound right, but there was a media query where you could apply different styles if the user had a setting for preferring dark mode. This is now a function that does effectively the same thing. So, This is a solid improvement because with the media query, you pretty much have to like copy an entire style block. [51:50]
-
-Whereas this you can just do inline, like if somebody wants a dark mode, you get this color. If somebody wants a light mode, you get this color. Just boom, nice little either or that you can do right in line. So I thought that was great. [52:01]
-
-This is, I cannot believe that we are only just now getting this in 2024, but we now have text wrap balanced, where you can tell CSS that you want, for instance, a title of a document to stay balanced instead of like, this goes deep into design and typography. It's a classic problem of designers saying like, well, hey, on certain screen sizes, we have a dangling word here. Can we just fix that? And the answer for so long has been, "no, that's really hard." So now we have a CSS rule that lets us give better control over how text wraps. So that's wonderful. [52:38]
-
-**Mo Khazali:** And I think there was a React library that was dedicated to this exact thing for the longest time. So it's cool. [52:44]
-
-**Carl Vitullo:** That's why — cuz it's so hard. You needed JavaScript. You needed to like measure the characters and like know what font you're using. [52:52]
-
-**Mark Erikson:** This is, this is a place I will legitimately happily use the platform. [52:56]
-
-**Carl Vitullo:** Right? It's such a core part of designing a web page, like how does the text wrap? It's just so outrageous to me that it's 2024 and we are just now getting some mode of control of it that doesn't require JavaScript. And it didn't even work well in the past because you like, measuring fonts was not easy on its own, so that was weird. [53:15]
-
-**Mo Khazali:** I'm going to rabbit hole again. You should have seen the, uh, Next. js implementation of that, because how do you consolidate the server rendering of the balanced text from the, it was, it had a whole, I went into the cores of that library, uh, massive rabbit hole. It was so funny to see how much work had to go into just getting that working on Next and on React client side. [53:33]
-
-**Mark Erikson:** Part of me wants to go look and the rest of me doesn't want to. [53:36]
-
-**Mo Khazali:** I will send you the link. Yeah,[53:37]
-
-**Carl Vitullo:** we'll put it in the show notes too. Haha. Cool. [53:40]
-
-And they also, there's also an app starting style rule for things like entry transitions, which is great because we now have a lot more options for entry transitions because stuff like popovers and modals are now entering the platform as well. [53:53]
-
-Cool. Love it. Here for it. That's all I got. [53:56]
-
-## Why React Query
-
-**Mark Erikson:** The folks from the UI. dev educational material site have put up a post that talks about why React query. I always love historical posts or posts that explain like, here's an abstraction, why does this extraction even exist? Like what work is it doing for us in the first place? [54:15]
-
-And so they kind of walk through like, okay, if you were to actually just fetch data inside a component, here's all the work you have to do it correctly. And, oh look, React Query actually does all that work for you. Same thing for RTK Query and Apollo and SWR, in principle. They put up this in support of their new upcoming React Query course, which I believe has been written by the current maintainer of React Query, Dominic Dorfmeister. Knowing that and knowing the folks behind UI. dev, highly endorsed, even though I haven't actually looked at it. [54:45]
-
-## We can have a different web
-
-**Carl Vitullo:** I saw a wonderful post from Molly White, who I am most familiar with her writing on looking at Web3 through a skeptical lens. [54:54]
-
-**Mark Erikson:** Web3 is going great. [54:56]
-
-**Carl Vitullo:** Yes, right. Her blog, Web3 is going great. She is a wonderful writer. She just gives great incisive commentary on Web3. She has put out this post titled, we can have a different web, it caught my eye. Because Web 3 took that moniker as trying to, kind of trying to ape the, like, Web 2. [55:13]
-
-0. They're like, well, Web 2. 0 is dead. We are now Web 3. And what a shame that only refers to kind of scammy cryptocurrency projects. I guess now I'd love to see like a Web 4. I know Block, briefly, Tried to do web five as a branding thing. [55:27]
-
-**Mark Erikson:** Let's do the Winamp thing. It's like version two, version three, version five. [55:32]
-
-**Carl Vitullo:** Yeah, right. If we could have Chrome just shout at you, it really whips the llama's ass, that would be great. [55:38]
-
-But yeah, so, okay. This is, Molly White put out this great post. We can have a different web. Just talking about the local Maxima that we've found ourselves in. as users of the internet, you know, sort of bemoaning how if you search something on Google, you used to be able to find it. [55:54]
-
-I think one of the points she makes that is important and nice is that all of those things that people loved about like the good old days of the internet, they're still there. It's just a little bit harder to find them. So sort of her claim is like, we can still have that. We just, you know, there's, needs to be a little bit more. [56:09]
-
-I just definitely recommend checking it out. It tickled my brain a little bit because obviously I've been thinking a lot about community and communities of developers. And so we can have a different web, what is just a very exciting subject to contemplate for me. So definitely recommend checking that out. [56:23]
-
-**Mo Khazali:** It just briefly also reminded me of the work that the folks at ARC are doing with the browser company with the new browser that they've released, ARC, that's based on Chromium. But, you know, I think they're also trying to kind of re envision what it means to search for something on the web where. And integrating some level of generative AI to pull everything and kind of give you a summary and signpost you to the right links so it's less overwhelming than searching on Google these days. [56:46]
-
-It's definitely an interesting take. I think other people are also struggling with that same problem and trying to tackle it. Or we could go for a fully decentralized internet on everyone's phones. A certain TV show might have tried to spin that idea. [56:58]
-
-**Mark Erikson:** A Black Mirror reference? [56:59]
-
-**Mo Khazali:** No, I was, I was referring to Silicon Valley with Pied Piper. [57:02]
-
-**Carl Vitullo:** Ah. No, Pied Piper. Okay. Yep. I also thought Black Mirror. So that says something. [57:08]
-
-**Mark Erikson:** So Christoph Nakazawa, who some folks might know as one of the long, I guess, previous maintainers of Jest while he was working at Facebook, has gone off and created a 2D strategy game sold on Steam called Athena Crisis. [57:23]
-
-I think it has some influences from, like, Advance Wars and that sort of genre. He built the entire game using React and CSS. And even though the game itself is, like, genuinely being sold on Steam, he's gone and open sourced the vast majority of the codebase. I had a chance to hear him talk about it a little bit while I was at React Conf, and he's even done things like putting up bounties for people to, like, improve the AI, or add new features to the map editor. [57:52]
-
-Someone added, like, a tile mirroring feature so you can, you know, create maps that have, like, equal challenges for all the players. And so, his explicit goal was that, like, look, you know, maybe there's people out there who want to get into some kind of game related programming. And while this isn't like a 60 frames per second shooter style of game, there's still aspects of building a game that people might be interested in learning about, and they might be coming from the React community. [58:19]
-
-And so by open sourcing this code base, folks can actually, you know, dig inside and learn and play around with it. So, you know, like kudos to him for taking that approach. [58:29]
-
-**Carl Vitullo:** I also want to shout out that if you played Advance Wars back in the day, this will scratch an itch for you, I think. I've played it a fair amount. [58:37]
-
-It's pretty good. I enjoy it. It's a good game. Having it also be fully open source and come with that ethos is just lovely. I love it. [58:44]
-
-Cool. I'm going to share this. Lee Holmes put out a blog post. Actually, this is not new, but it just crossed my radar. I don't remember where. I think it was in one of the newsletters that I read. [58:54]
-
-But it was titled, Security Risks of Postman. This is not new. This is, I think, even, maybe even reasonably well known. But like, Postman thinks data. They have a cloud service. It is meant to make it easier for you to, you know, keep your different development computers synchronized with each other. But, also You're probably using Postman to, you know, make requests to a development environment. [59:15]
-
-And it might include things like authorization tokens, API keys, like all kinds of really sensitive information that You probably don't want other people to get access to. So that's just generally the topic of this blog post of like, Postman is a security threat. And yeah, can't argue with that. That's you, you should not be putting your API keys into something that feeds them into a third party. [59:38]
-
-So yeah, definitely something to consider. I have always been confused about Postman. Their development path. I loved it for a long time and then they got really complicated with request collections and cloud features and whatever. So this didn't seem like something that needed to be a venture backed business, which is what it is, I believe. [59:58]
-
-**Mark Erikson:** And last item out of our lightning round, while it's not React related, Angular 18 is out. And of course, not being an Angular dev, I only have the vaguest clue of what's going on over there, but looking at the changelist, they're in the process of dropping something that they used called zone. [01:00:15]
-
-js, which monkey patched, like, every possible source of asynchronicity in the browser. In order to detect when data mutations happened so that the UI could then do the diffing and know if it needed to re render. They've also, I believe, been integrating things like signals and trying to move away from RxJS a little bit. [01:00:36]
-
-So, you know, there's various aspects that are there for interop between RxJS and signals. But they're kind of shifting some of that mindset and data flow approach. [01:00:46]
-
-**Carl Vitullo:** Yeah, man. Speaking of, funny to also talk about how patching globals is harmful and wow, I did not realize that Angular was patching globals quite that extensively. That is not great. [01:00:56]
-
-**Mark Erikson:** Angular 1 had some kind of a loop that would just keep checking the controller values to see if they'd been mutated and Angular 2 plus, so going on like the last seven or eight years. Has all relied on this tool called Zone. js to, like, monkey patch every source of asynchronicity in the browser. [01:01:15]
-
-**Carl Vitullo:** Yeah, that's a little bit wild. [01:01:17]
-
-**Mark Erikson:** Alright, I think we're out of things to talk about for now. [01:01:20]
-
-**Carl Vitullo:** 22 minutes over our planned time. Lot to get to this month. [01:01:23]
-
-Alright. Thank you so much everyone for joining us. We'll be back on the last Wednesday of the month here in the live stage in Reactiflux or back in your podcast feed just as soon as we can after that. [01:01:33]
-
-We gather sources from This Week in React, Bytes.Dev, React Status, Next JS, Weekly React Digest, the React JS subreddit, here in Reactiflux from the #tech-reads-and-news channel, and direct from those publishing articles, usually on Twitter or BlueSky. I'm not on threads, but maybe people post there. [01:01:51]
-
-If you see anything newsworthy, definitely let us know. You can do so in the #tech-reads-and-news channel here in Reactiflux, or you could send us an email to hello@reactiflux.com with T M I R in the subject line. It's an acronym for the show. I read literally every email that comes in, even ones marked as spam. So if you send me something to that address, I will read it. I may not reply, but I will read it for sure. [01:02:13]
-
-If this is a show that you get value from and want to support, the best way you can do so is by submitting a review, wherever you listen, and definitely tell your friends and coworkers about it. My thesis for the show is that there are a large number of people who are overwhelmed by trying to consume the fire hose. And so I'm trying to consume the fire hose for you and your coworkers. Yeah. [01:02:33]
-
-Thank you so much. Catch us next month. [01:02:35]
-
-**Mark Erikson:** Bye. [01:02:35]
-
-**Mo Khazali:** Bye everyone.
diff --git a/src/transcripts/tmir-2024-06.md b/src/transcripts/tmir-2024-06.md
deleted file mode 100644
index 54a471c..0000000
--- a/src/transcripts/tmir-2024-06.md
+++ /dev/null
@@ -1,703 +0,0 @@
----
-title: "This Month in React, June 2024: React 19 delayed (drama-ish), why no JS Laravel, TS 5.5 and more"
-date: 2024-06-26
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- Quick hits
- - [[00:51](#layoffs-updates)] [Layoffs.fyi](https://layoffs.fyi/)
- - [[01:35](#the-riseand-fallof-the-software-developer)] [Software jobs down 20% vs 2018? From ADP](https://www.adpri.org/the-rise-and-fall-of-the-software-developer/)
- - [[02:12](#new-releases)] New releases
- - [Turborepo 2.0](https://turbo.build/blog/turbo-2-0)
- - [React Admin v5](https://marmelab.com/blog/2024/06/20/react-admin-v5.html)
- - [Rsbuild 0.7](https://rsbuild.dev/community/releases/v0-7)
- - [Biome 1.8](https://x.com/biomejs/status/1797963672004043040)
- - [Astro 4.1](https://astro.build/blog/astro-4100/)
- - [Valibot 0.31.0](https://valibot.dev/blog/valibot-v0.31.0-is-finally-available/)
- - [[06:51](#upcoming-conferences)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [React Nexus](https://reactnexus.com/) July 4-5, 2024. Bangalore, India
- - [Chain React 2024](https://chainreactconf.com/) July 17-19, 2024. In person in Portland, OR, USA
- - [The Geek Conf](https://thegeekconf.com/) July 25, 2024. Berlin, Germany
- - [WeAreDevelopers World Congress](https://www.wearedevelopers.com/world-congress) Berlin, Germany & Online July 17-19
- - [CityJS Singapore](https://singapore.cityjsconf.org/) Singapore, Singapore July 24-26
- - ~~We Love JS~~ Unfortunately this appears to be a [fake event](https://twitter.com/_jessicasachs/status/1811394314112565301)
- - [React Rally](https://www.reactrally.com/) August 12-13, 2024. Salt Lake City, UT, USA
-- Main Content
- - [[09:43](#suspensegate)] [React 19 delayed](https://github.com/facebook/react/pull/26380)
- - [[09:55](#this-is-the-exact-build-well-release-as-190)] Previously, per Andrew: [React 19 _was_ ready to release](https://x.com/acdlite/status/1797668537349328923)
- - TKDodo: [React 19 and Suspense - A Drama in 3 Acts](https://tkdodo.eu/blog/react-19-and-suspense-a-drama-in-3-acts) , and also [How React 19 (Almost) Made the Internet Slower](https://blog.codeminer42.com/how-react-19-almost-made-the-internet-slower/)
- - [[19:03](#joe-savona-some-thoughts-on-the-suspense-changes-from-19-rc)] [Joe Savona “We'll hold the 19 release”](https://x.com/en_JS/status/1803480672327311425)
- - What does the React team _want_ for data fetching?
- - Seb: [“We never released official Suspense on the client, we did RSCs instead”](https://x.com/sebmarkbage/status/1801258093327593717) and [“Some people got the render-as-you-fetch memo. Some people chose to ignore it.”](https://x.com/sebmarkbage/status/1801294251965198578)
- - Andrew: [“the community shouldn’t think ‘we bullied React into changing fetching strategies”](https://x.com/acdlite/status/1803551296974168171).
- - Related: how do we communicate with the React team?
- - [[21:33](#tanner-linsley-react-needs-a-permanent-working-group)] [Tanner Linsley: “I feel there needs to be a permanent React + community working group”](https://twitter.com/tannerlinsley/status/1802798385810018769)
- - [Joe Savona: “we’re working on ideas to get feedback earlier and more users trying canaries”](https://x.com/en_JS/status/1803480684331483644)
- - [[23:42](#tc39-proposal-advances)] [TC39 proposals advanced](https://x.com/robpalmer2/status/1801239842908438694)
- - [[26:05](#react-partners-with-codemod)] [Codemod partners with React](https://codemod.com/blog/react-announcement)
- - [[27:52](#react-compiler)] React Compiler
- - [[28:03](#i-tried-react-compiler-today,-and-guess-what-)] [I tried React Compiler today, and guess what... 😉](https://www.developerway.com/posts/i-tried-react-compiler)
- - [[29:32](#understanding-react-compiler)] [Understanding React Compiler](https://tonyalicea.dev/blog/understanding-react-compiler/)
- - [[29:50](#why-dont-we-have-a-laravel-for-javascript-yet)] [Why We Don't Have a Laravel For JavaScript... Yet](https://wasp-lang.dev/blog/2024/05/29/why-we-dont-have-laravel-for-javascript-yet)
- - [Why Don't We Have A Laravel For JavaScript?](https://www.youtube.com/watch?v=yaodD79Q4iE)
- - [[35:45](#vercel-ship-2024)] [Vercel Ship 2024](https://vercel.com/blog/vercel-ship-2024)
- - [[37:35](#ts-55)] [TS 5.5 released](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5/?ck_subscriber_id=1888282043)
- - [Matt Pocock breaks it down](https://www.youtube.com/watch?v=sciBO_IaxTw)
- - [[40:41](#mind-the-gap-talk)] [Mind the Gap by Ryan Florence](https://www.youtube.com/watch?v=1g5ruM-16_Y&t=7595s) at Big Sky Dev Con
- - React Native Stuff:
- - [[41:36](#lorenzo-sciandra-exiting-react-native)] [Lorenzo leaving RN world 😭](https://x.com/Kelset/status/1800158749811966280)
- - [[43:47](#expo-atlas)] [Expo Atlas available](https://expo.dev/blog/introducing-expo-atlas)
- - [[46:40](#expo-adds-compiler-support)] [Expo adding React Compiler support](https://github.com/expo/expo/pull/29168)
- - [[46:52](#starlinks-react-native-app)] [Starlink’s RN story](https://www.notjust.dev/blog/react-native-starlink)
- - [[47:14](#expo-router-35)] [Expo Router 3.5](https://twitter.com/Baconbrix/status/1788235769812795559)
- - [[48:16](#sf-symbols-beta-support-in-expo)] [SF Symbols Beta Support in Expo](https://docs.expo.dev/versions/latest/sdk/symbols/)
-- ⚡Lightning round ⚡
- - [[50:03](#react-internals-explorer)] [React Internals Explorer](https://jser.dev/2024-05-11-introducing-rie/)
- - [[50:44](#whats-new-in-javascript-frameworks-for-may-2024)] [What's new in JavaScript Frameworks (May 2024)](https://developer.chrome.com/blog/frameworks-may-2024)
- -[[51:24](#memory-leaks)] Memory leaks:
- - [Memory Leaks from LocalAsyncStorage?](https://lucumr.pocoo.org/2024/6/5/node-timeout/)
- - [Sneaky React Memory Leaks: How useCallback and closures can bite you](https://schiener.io/2024-03-03/react-closures)
- - Follow-up: [Sneaky React Memory Leaks II: Closures vs React Query](https://schiener.io/2024-05-29/react-query-leaks)
- - [[52:21](#data-fetching-patterns-in-single-page-applications)] [Data Fetching Patterns in Single-Page Applications](https://martinfowler.com/articles/data-fetch-spa.html) from the Martin Fowler blog
- - [[57:19](#migrating-to-the-next-app-router-with-zero-downtime)] [Modularizing React Applications with Established UI Patterns](https://www.icodeit.com.au/posts/modularizing-react-apps)
- - [[58:12](#deno-standard-library-nearing-10)] [10 modern Node.js runtime features to start using in 2024](https://snyk.io/blog/10-modern-node-js-runtime-features/)
- - [Migrating to the Next.js App Router with Zero Downtime](https://workos.com/blog/migrating-to-next-js-app-router-with-zero-downtime)
- - [Deno announces the standard library is nearing 1.0](https://deno.com/blog/stabilize-std)
- - [[59:11](#why-dont-we-do-acid-tests-anymore)] [Why don’t we have things like the Acid3 test anymore?](https://twitter.com/vcarl_/status/1805627502036983995)
- - [[01:03:09](htmx-simplicity-in-an-age-of-complicated-solutions)] [htmx: Simplicity in an Age of Complicated Solutions](https://www.erikheemskerk.nl/htmx-simplicity/)
-
-[00:00] **Carl Vitullo:** Hello, thanks for joining us. This is June's edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers.
-
-[00:13] I'm Carl, I'm a staff product developer and freelance community manager here at Reactiflux, where I run community programs like these events and build tools that help keep the community going.
-
-[00:24] **Mark Erikson:** Hi, I'm Mark Erikson. My day job is working at Replay. io where we're building a time traveling debugger for JavaScript. And outside of that, I do Redux stuff.
-
-[00:33] **Mo Khazali:** Hi everyone. I'm Mo. I head the mobile team at Theodo. I'm quite active in the React Native community and I organized the React Native London meetup and here and there dabble in open source with a couple of libraries in the React Native ecosystem. Very happy to be here.
-
-[00:47] **Carl Vitullo:** Uh, I'm just going to start off with some quick hits of new releases and conferences.,
-
-## Layoffs updates
-
-[00:51] **Carl Vitullo:** Starting off immediately, because the market, the job market is so bad, I've been reading off stuff from layoffs.fyi.
-
-[00:59] We're not quite at the end of June, it's a couple of days left at time of recording, but most of the way through June, we're at about 9. 2, 000 laid off from 40 companies, which is down, I mean compared to six months ago we're down substantially, but compared to two years ago we are up substantially, so it's still not great. I've seen some other broader metrics trickling out from other places, like I saw a link from ADP that I unfortunately don't have handy suggesting that the overall like, tech market is at about 80 percent of it was, I believe, compared to 2018.
-
-### [The rise—and fall—of the software developer](https://www.adpri.org/the-rise-and-fall-of-the-software-developer/)
-
-[01:35] **Carl Vitullo:** Yeah, I, I found that really interesting because between hearing headlines about like record hiring during the pandemic and record layoffs in the two years, after that, it was like, Where do we end up? So that's the first data point I've seen, uh, addressing that question of, like, what's the net gain loss, and it suggests net loss of, like, 20%, which seems massive, but yeah, it's also, it's ADP, I don't know how much to trust that, I would assume that they got a very large sample size, but I'm not sure how they defined, like, tech, so, I don't really know how to interpret that in, through a lens of like software development.
-
-## New Releases
-
-[02:12] **Carl Vitullo:** But yeah, moving on to some new releases.
-
-### [Turborepo 2.0](https://turbo.build/blog/turbo-2-0)
-
-[02:14] **Carl Vitullo:** There is TurboRepo 2. 0. That's probably especially relevant if you're doing stuff with Next. It looks like it's mostly like a fancier UI. They're doing like a pretty high effort in terminal UI. Like it's, you know, reactive and interactive. And you can now break down your logs on a per task basis rather than it just being, you know, a constant scroll back the way terminals usually are.
-
-[02:38] So that seems neat. Oh, they had some new docs, and it looks like they included some, like, fundamental information about Monorepos, which seems cool.
-
-## React Admin v5
-
-[02:47] **Carl Vitullo:** React Admin released version five. We actually had Francois Zaniotto, hope I'm not mispronouncing that, on as a guest a couple of weeks ago, and I think he's super cool.
-
-[02:57] I love his ethos for the company that he's building, which maintains React Admin and does agency work. So I just wanted to shout that out.
-
-### [Rsbuild 0.7](https://rsbuild.dev/community/releases/v0-7)
-
-[03:04] **Carl Vitullo:** RS build released version 0. 7, which they say is going to be the last release before 1. 0. Mark, you had some thoughts?
-
-[03:14] **Mark Erikson:** ByteDance, the folks behind TikTok, have a massive web tooling infrastructure team. They've actually rebuilt Webpack in Rust, and I know that, you know, rewrite it in Rust is its own meme at this point, but it seems like they've, they've truly built a Webpack compatible version in Rust called RSPack. On top of that, they have a higher level abstraction layer called RSBuild, which has an easier configuration format, a little bit like ESBuild does. if you actually look in their docs, they have a migration guide for switching from Create React app to RSBuild. I did that on a little side project a few months ago.
-
-[03:55] It was really easy to switch and the compile time dropped from like 30 seconds to less than a second. it feels like a, an actually viable competitor tool.
-
-[04:06] **Carl Vitullo:** Nice. Super cool.
-
-### [Biome 1.8](https://x.com/biomejs/status/1797963672004043040)
-
-[04:08] **Carl Vitullo:** We've also got biome 1. 8. Yeah. I have a soft spot for biome. I was an early supporter of Rome. I have been eager to see what comes out of that.
-
-[04:17] So yeah, it looks like they've got like new support for CSS. They have better support for language servers in workspaces, so if you've got like a big monorepo, it should work a little bit better. New reporters, migration, some more linting options, but yeah, Biome is like kind of an all in one. They try to do like formatting and linting and, yeah, it's a bundle play.
-
-[04:38] They're taking in a bunch of tools that, were separate and doing it all as one package.
-
-[04:42] **Mark Erikson:** And written in Rust.
-
-[04:44] **Carl Vitullo:** Written in Rust. Sure. So super fast, blazing fast. Is blazing fast still cool?
-
-### [Astro 4.10](https://astro.build/blog/astro-4100/)
-
-[04:51] **Carl Vitullo:** There's also Astro 4. 10. I am hoping to play around with Astro this month. So maybe I'll be able to actually, you know, say some more intelligent things about what the experience is.
-
-[05:01] But I, I know lots of people who love the tool. It looks like some small improvements, nothing too major.
-
-### [Valibot 0.31](https://valibot.dev/blog/valibot-v0.31.0-is-finally-available/)
-
-[05:06] **Carl Vitullo:** This is a new library to me, Valibot released 0.31.
-
-[05:10] It's a competitor to Zod, which does like schema validation or, you know, data validation through a schema with like type generation and all that kind of stuff.
-
-[05:19] This looks like a pretty solid competitor. They talk about, tree shaking and stuff, which I'm broadly skeptical of tree shaking as a general promise. It's very difficult to verify.
-
-[05:30] **Mark Erikson:** My understanding is that Zod, when you import it, you're basically importing a giant object that has all the possible validation types built in, and I think Valobot's sales pitch is that it's a bunch of individual functions, and so you would only import the actual bits that you need.
-
-[05:47] And therefore, you're not getting a giant blob of runtime code.
-
-[05:51] **Carl Vitullo:** Yeah, I think they said it was like, could be up to like 95 percent smaller than Zod, while also like significantly simplifying the mental model of the schema and the type validation.
-
-[06:02] If I can think about it less and have it affect the size of my code less, like both of those sound like things that I would want.
-
-[06:10] **Mo Khazali:** I guess the thing is, it's a question of how much you want to really optimize your bundle size and at what stage you're at. If I'm recalling correctly, Zod minified and gzipped was about 60kb, something around that size.
-
-[06:22] So it is quite a chunky library to add into your dependencies. So, I guess if this actually delivers on that promise and it's closer to 90 percent less than that, which is I guess 6kb, it wouldn't be too bad of a shave to do, I'd say. But, remains to be seen if it's in practice going to be that good.
-
-[06:40] **Carl Vitullo:** Yeah, I just pulled up Bundlephobia for Zod, and it's, yep, 61kb minified, 14kb minified and zipped. Which is Hefty. Yeah, that's enormous. That would give me a lot of pause.
-
-## Upcoming Conferences
-
-[06:51] **Carl Vitullo:** Onto some conferences. Mo, I think you had a few.
-
-[06:53] **Mo Khazali:** Yeah, I'll jump right in.
-
-### [React Nexus](https://reactnexus.com/)
-
-[06:54] **Mo Khazali:** So, firstly, at the very beginning of July, 4th to 5th of July, React Nexus is happening in India.
-
-[07:00] One of the great conferences that I attended last year, I really enjoyed. The crowd there was quite a, quite a large crowd as well. I think there's about 500, 600 people. So a massive conference, but people are so friendly and I got to meet a lot of lovely people. So would highly recommend if you're sort of in the South Asia region to, to definitely give it a shot, if you can make it to Bangalore.
-
-### [Chain React](https://chainreactconf.com/)
-
-[07:19] **Mo Khazali:** Mid July, we have Chain React and this is hosted by the folks at Infinite Red. Another one of those great conferences. I've not been to Chain React myself, but I'm, So involved in the React Native community that I get told every year, why are you not at Chain React? And you're missing out on one of the best conferences ever.
-
-[07:34] So the FOMO hits real hard every time around Chain React. The folks at Infinite Red are absolutely amazing, and they organized an incredible conference from all accounts that I've heard of. Everyone really loves Chain React, so if you are in the U. S. and you're in the React Native scene, you really do not want to be missing Chain React. If I was in the U. S., I would definitely be at Chain React this month, so I cannot give it more praise than that.
-
-### [GeekConf](https://thegeekconf.com/)
-
-[07:58] **Mo Khazali:** And then, lastly, towards the end of July, we have GeekConf, so GeekConf is another sort of React Native conference with a little bit of a blend of web as well added into it. So that's happening on the 25th of July in Berlin. There's also a day that's dedicated to remote track, but 25th of July is the key date that's going to be happening in person, and I'll be speaking at that conference as well, and hopefully if any of you folks are there, please do come around and say hi, would be lovely to meet some of you in person.
-
-[08:24] **Carl Vitullo:** Heck yeah.
-
-### [WeAreDevelopers World Congress](https://www.wearedevelopers.com/world-congress)
-
-[08:25] **Carl Vitullo:** Leaving the list of conferences that us as hosts have personal experience with, there's a We Are Developers World Congress in Berlin, July 17th through 19th.
-
-### [CityJS Singapore](https://singapore.cityjsconf.org/)
-
-[08:35] **Carl Vitullo:** There's a CityJS in Singapore. That's going to be July 24th through 26th.
-
-### [We Love JS Amsterdam](https://welovejs.vercel.app/)
-
-[08:42] **Carl Vitullo:** We love JS in Amsterdam in the Netherlands, August 9th and 10th.
-
-### [React Rally](https://www.reactrally.com/)
-
-[08:46] **Carl Vitullo:** And then the last conference that we're highlighting in the next two months is React Rally, which is going to be August 12th through 13th in Salt Lake City. Actually, I have been to that one in the past and it was pretty quality.
-
-[08:58] **Mark Erikson:** Yeah, I, I would also. Emphasize like React Rally has been fantastic. the organizers are great.
-
-[09:04] they do a really good job of giving it a good community feel. I was there last year and attendance was unfortunately just a little down because of trying to revive it after COVID. So if, if you can all make it to React Rally in August, please go. It's, it's totally worth, worth it.
-
-[09:19] **Carl Vitullo:** Yeah, and it's the home neighborhood for a lot of really big people in the React and web ecosystem.
-
-[09:25] there are quite a number of people who live generally in Utah and in Salt Lake City. I think Kent C. Dodds is out there.
-
-[09:32] **Mark Erikson:** Kent, Tanner, Ryan.
-
-[09:33] **Carl Vitullo:** Yeah, it's their home neighborhood. I assume they'll be at the conference. Yeah, anyway, cool. All right, moving on to some of our main content here. Mark, you want to start us off?
-
-## "SuspenseGate"
-
-[09:43] **Mark Erikson:** Boy, oh boy, oh boy. Okay, welcome to SuspenseGate. So, for the for those of you who may not have been following all the drama on Twitter, we're here for you.
-
-### ["This is the exact build we'll release as 19.0"](https://x.com/acdlite/status/1797668537349328923)
-
-[09:55] **Mark Erikson:** About a month ish ago, a month and a half ish ago, Andrew Clark actually tweeted that, We've, we've updated to a new React 19 release candidate, and we think that this release candidate is going to be the final one, like, these are the actual bytes we plan to release as React 19, unless there's any other major changes.
-
-[10:17] Well, there is now cause for major changes. And in fact, React 19 has been delayed semi indefinitely. The React team is going to be doing some updates, and we don't know how long that's going to take. Why are they doing these updates?
-
-[10:32] In November of last year, Andrew Clark put up a PR that changed the behavior of the suspense component and how it manages loading children that are suspending to fetch data.
-
-[10:44] Previously, if you had multiple children inside of suspense, And they all wanted to fetch some data. The suspense component would give each of these components a chance to start rendering and start the data fetching. And then actually pause and wait for all of the components to finish fetching their data.
-
-[11:04] Doing it all in parallel, kind of like a promise. all combination. And with this PR, the React team changed it. So that React really only gives the first child that suspends a chance to fetch, and then it waits for that child to finish loading its data, tries to re render, and then keeps going until the next child component tries to fetch data.
-
-[11:28] Basically doing all of that in serial instead. Now, they, if you look at the PR, Andrew listed some potential reasons for this. One is that this actually made Facebook. com load a little faster. But also, it has to do with how the React team thinks. that people should be doing data fetching on the client side.
-
-[11:51] And basically their argument is, you, you shouldn't be doing data fetching nested deep in the component tree. Instead, you should hoist it up to the top at like the route level or the page level instead. And so their argument is like, well, we don't think people should be doing this pattern much anyway.
-
-[12:11] So it's okay for us to change it. Now, this was done as part of React 19's development, and React 19 is a major version. So you can totally, you know, make changes. It's, it's legal under the terms of semantic versioning. And this was available in the React 19 Canaries, but as we all know, nobody actually tries out pre release versions, everyone waits until it's actually released, and then tries it, and then reports bugs.
-
-[12:38] So, this basically went unnoticed by the community for months. And about a month ago, someone mentioned it on Twitter, very briefly, and TK Dodo, the maintainer of React Query, Saw that comment and said, oh, that doesn't look great, and then didn't think about it. And then just a couple weeks later, there was another discussion thread, and suddenly TK Dodo and a bunch of other people began to realize, wait a minute, this is actually a very significant change in how suspense works.
-
-[13:08] And in particular, the React 3 Fiber developers, which is the React for 3D game engines, Realized we depend on suspense heavily because we need to be able to load a lot of different things async like game assets. So it's not just about data fetching, it's about lots of other async behavior. And they, and they started showing demos where, everything went from loading in parallel to loading as a waterfall in serial.
-
-[13:38] And now example apps were way, way slower as a result. There was a massive firestorm on Twitter. A day or so later, Sophie Alpert from the React team said, We talked about this in a React team meeting today. We didn't realize how many people would be affected by this. But also, this was a very major change to React's internals. We did this, like, seven months ago. We've continued making lots more changes to the internal since then. We can't just roll back this change. We know what we would need to do in order to re enable the old behavior, but it's going to take another fairly significant set of internal changes to do that.
-
-[14:19] So, we don't know when we're going to get around to it. Stepping back for a second, at that point in time, the community conclusions were, they already said React 19 is release candidate and ready to ship, and we don't, like, we know this would take major changes. Therefore, the conclusion was React 19 is about to ship with this behavior and we're all going to be stuck with it for the duration of React 19 as a major release.
-
-[14:45] **Carl Vitullo:** Yeah, I don't know, some of the like firestorm framing for this, it makes me a little bit like, I don't know, it's, okay, this was a, this was a confusing behavior, and something that they overlooked, but I am glad that this conversation did happen.
-
-[14:59] And ultimately, the React team had this pointed out to them and did respond ultimately, I think, appropriately. So, like, it's, I don't know, how do you, How do you do open source development with millions of people, very few of whom actually try out pre releases?
-
-[15:15] **Mark Erikson:** Yeah, that actually even ties into the events this week of Jordan Harband and some of the package updates going on. Mo, you had a thought?
-
-[15:24] **Mo Khazali:** Well, I was just thinking, well, firstly, ironically, I remember when we did the last, last month's episode, we were talking about how this might be like the quickest release cycle for React, or, well, you know, it'll be a quick transition into Release Candidate and then released, and then this came up. So I find that quite funny that sometimes these things will come up and we can't predict it.
-
-[15:41] But I think it's, you know, around the whole expecting people to test canaries and, and release candidates, I almost wonder if there's a different way that that needs to be done and if there's some level of automation that can be done to ensure that not just, you know, apps that are using RSCs and are, you know, the most up to date and exactly architected in a way where Meta wants them to be architected, are tested, but rather, there's a whole wide range of apps, ones that are built over a long period of time, there might be SPAs or other things like that, all of those get tested. I don't know if there's a nicer way to handle that, but I feel like just expecting people to test Canaries and test RCs will not catch stuff like this .
-
-[16:20] **Mark Erikson:** That's the thing, I believe the Vue ecosystem has like a full fledged, I don't know the right term for it, they have a massive automation setup that tests all kinds of libraries across the ecosystem against the latest versions of like Vue and Vuex and Pinia and Vue Router and all these other tools. And similarly TypeScript, every time you push a PR to TypeScript, it does checks against almost all of DefinitelyTyped, or at least like a, the most widely used libraries on, on DefinitelyTyped and across the ecosystem, to try to catch a lot of these issues ahead of time.
-
-[16:56] But even then, there's a distinction between, do the library's tests fail, and how are people using that library. I think in this case, React Query had one test that did parallel fetching in a suspense, but it was like two components running locally. And so the effects of it would not have been meaningfully visible in terms of timing.
-
-[17:18] **Carl Vitullo:** Right. Right. And ultimately this is a like timing and parallelism issue. And I don't know, I'm not sure that that's something that would work. have been proactively tested? Like, I'm not sure that it's something that An automated test suite could like reasonably easily evaluate. And I'm not sure that someone would have said, Oh, this is a large enough risk that we need to invest, you know, several days of engineering time in order to make sure that we have test coverage that will flag this if it breaks.
-
-[17:48] So I don't know, I, to me, this is just like such a. Niche interaction between, you know, it's, it's such a corner case between the assumptions of the React core team and the, you know, evaluation work that they do against the Facebook project and the, you know, broader needs. So like, I don't know, I saw various negative takes, like, oh, I don't know, I saw lots of various negative takes, I'm not even gonna try and imagine, try and make up one.
-
-[18:16] **Mark Erikson:** the React Summit organizers for the last couple years Have done an event that they call the React ecosystem contributors summit, where they get like 25 to 30 maintainers and contributors to various tools and libraries together in a room. And they just give us a chance to vote on whatever topics we think would be worth discussing and then give us three hours to, talk about it in whatever way we think would be useful.
-
-[18:44] So, I was there. There were two topics that were discussed. Two thirds of the room was discussing the technical aspects of the suspense change, two thirds of the group was discussing the technical behaviors. One third of us were discussing, how can we have better communication and interactions with the React team.
-
-### [Joe Savona: Some thoughts on the suspense changes from 19 RC](https://x.com/en_JS/status/1803480672327311425)
-
-[19:03] **Mark Erikson:** A couple of days later, Joe Savona from the React team put up a long Twitter thread, which is very, very good and very worth reading. And he said, number one, we're going to hold off on the React 19 release. We agree that this is a major behavior change. And frankly, we underestimated how many people would be affected by this pattern change.
-
-[19:24] So they're going to step back and they're going to do something to do it. My, my, my assumption is trying to do the actual work to re implement some of the older behavior in the, in the reconciler internals. So that's good. Like the community complained, we communicated, they listened, they changed plans.
-
-[19:43] These are all actually very, very good things, but that ties into the communications question. Like a semi official way to communicate to the React team is by filing an issue, and the React issues are basically useless in that sense. One thing, they've been full of spam, both in terms of like really, really old issues and literal, literal spam issues, but also like the React team doesn't pay tons of attention to their issues list.
-
-[20:10] And so just filing an issue is not necessarily going to get like a quick response. There's Twitter, and a lot of the, you know, React team members are very active on Twitter, and that's great, but it's also not like a formal communications channel. So, what we concluded in our little set of people talking during this Contributors Summit, is that we really need to bring back this idea of a working group.
-
-[20:36] For React 18, the React team put together a React 18 working group where they specifically invited 50 to 75 people from across the ecosystem and continued adding to it over time. And there was a public GitHub repo where the React team and the invited contributors could write comments. Anybody could read it, so the discussions were public, but the idea was have a high signal ratio of meaningful discussions and questions about React 18, how things worked, how people could actually use some of the features and what the practical results would be.
-
-[21:12] And I think that was a great success. Like, there was a lot of really good information in that repo. So our conclusion, as the little group of people talking amongst ourselves, was we should somehow have a permanent version of the working group. And actually, Tanner Linsley independently tweeted the same thing a few days later, as well.
-
-### [Tanner Linsley: React needs a permanent working group](https://twitter.com/tannerlinsley/status/1802798385810018769)
-
-[21:33] **Mark Erikson:** So along with that, Joe Savona also said in his tweet thread that we are actively looking at how can we get more feedback on pre release versions and how we can actually Have better communication with the community. So, I don't know exactly what will happen, but I'm hopeful that something like this working group model would be an option going forward.
-
-[21:55] **Mo Khazali:** That's not, you know, too far away from how the React Native team does it, you know, for, for the past couple of years, I'd say, since, you know, Nicola Corti and Riccardo have come into the React Native team, they've been pushing this sort of release cycle where they'll have two, three different people from the community owning the release process for each version of React Native that comes out, and that Inherently add some level of community involvement to the releases.
-
-[22:17] Obviously a working group with more and more and more people, you know, about 60, 70 people sounds like there's going to be even more exposure, which is great. But I think it's, it's something that could take a page out of the React native core teams book as well, because they've done it successfully there.
-
-[22:29] **Mark Erikson:** Overall, takeaways are, nobody tries pre release versions, we really need a formal communications channel between the React team and the community that they will pay attention to, and that we can collectively offer feedback that they will see.
-
-[22:44] **Carl Vitullo:** Yeah, I, I, I chimed in on that because I don't know, Reactiflux, we're a thriving subset of the community.
-
-[22:50] Maybe we could be a neutral space for that type of communication to happen where they don't need to own the moderation side of things that has not turned into a conversation. So, hey, maybe it will eventually, but yeah. Twitter is definitely, I'm not sure how effective it was ever as like a DevRel, you know, source of truth, but now, like, if you don't have an account, they don't even let you view tweets, so, I think it is past time, well past time for DevRel from the React team to go somewhere else. Like it is, it's been over a month since the last blog post. And other than that, I don't know where any communications from the React team out to the broader community come from. It's basically the blog and the Twitter and the blog is not active. So. Yeah, I hope that that working group concept turns into something a little more effective.
-
-### [TC39 proposal advances](https://x.com/robpalmer2/status/1801239842908438694)
-
-[23:42] **Carl Vitullo:** But yeah, okay, cool. Next subject, TC39 proposals. A bunch just came out. I'm just going to kind of run through this on the high level. Yeah, promise. try, it looks like it's pretty much just like a quick wrapper on, , you know, new promise, and then you immediately resolve with a value.
-
-[23:58] I've done that a number of times, so I guess there's a use case for this, but in the abstract I'm not really coming up with a great example of why you would want to just Take a synchronous value and make it a promise.
-
-[24:09] Deferred import evaluation seems useful. it's a way, it's a way of delaying execution of some parts of the import process when you're getting a module in.
-
-[24:20] You can, you know, mark it as deferred so that it will not actually evaluate the module. It'll still like parse it and do some other interpretation steps that I'm blanking out at the moment. But it will not actually evaluate the code until later on.
-
-[24:33] **Mark Erikson:** Basically this, this allows. Speeding up, like the initialization process by not running all the code in the application right away on startup, even though you know, you'll need some of that code later.
-
-[24:48] **Carl Vitullo:** Yeah. Okay. There we go. Another one was joint iteration. I thought this was pretty cool because I've needed this a number of times. It's a way of iterating over more than one. iterable at the same time. That's on stage 2. 7, which means it's still pretty far from getting shipped.
-
-[25:03] Error. isError seems very useful for, for types. I guess lots of new stuff is moving down the pipe, I don't know how many of these are super important to call out in great detail, but yeah, Mark, Mo, anything that caught your eye is particularly important?
-
-[25:18] **Mo Khazali:** I, I really think Error.isError is the one that I'm most interested in. Obviously quite a while away before it gets to adoption. It's still on the process step two, it's stage two, but hopefully very soon. Well, I don't know how long this process is going to take for them.
-
-[25:31] It was interesting. The TC39 meeting that they had was happening in Helsinki, uh, near Future Frontend, which was a conference that we gave a shout out to last month.
-
-[25:39] And I happened to be there. That was quite cool to see some of these folks gather together and how they chatted about some of these standards. Just being privy to those conversations was fascinating. So they have a, they have an incredible process that I've, I've not seen anything like before in any other sort of working group.
-
-### [Panel discussion at Future Frontend](https://youtu.be/29wHaG7eVPM?t=17422)
-
-[25:53] **Mo Khazali:** So quite interesting, would recommend. There's a, if you go onto the Future Frontend streams, they actually have a big panel discussion for, from the second day of Future Frontend, and they actually discuss some of these proposals in detail, which is quite cool.
-
-### [React partners with Codemod](https://codemod.com/blog/react-announcement)
-
-[26:05] **Carl Vitullo:** All right, let's move on to the next one.
-
-[26:08] This is, I'm, CodeMod they announced they are partnering with the React team to help migrate to React 19.
-
-[26:16] I know, I feel like the React team initially popularized the idea of CodeMods. So this is like not a surprise at all to me. I guess I wasn't really familiar, wasn't really aware of Codemod as like its own separate team. I see, you know, this is posted by the founder of CEO of Codemod, I guess.
-
-[26:34] So that's kind of news to me. But yeah, so there's gonna be more Codemods, I guess, to help your codebase stay up to date with React 19.
-
-[26:42] **Mark Erikson:** I am very familiar with code not code mods as a technical concept I had no idea there was an entire company devoted to building tools for code mods as like a corporate thing.
-
-[26:53] **Carl Vitullo:** Right, right as a technical thing Very familiar. I don't really understand what the business case for that would be. I don't know, I guess maybe consulting. Maybe it's a services business.
-
-[27:03] **Mo Khazali:** Apparently the way that they also make it more effective is that they apparently pair it with some AI. It might be a pivot, I don't know, but apparently they pair it with some AI and some nice CLI tools to make your code mods more effective. That's not an endorsement, I don't know if it works well, but that's seemingly their model.
-
-[27:20] **Carl Vitullo:** Makes me a little skeptical, but yeah, I don't know. Codemods generally are great.
-
-[27:24] Any migrations and like major refactorings like that are definitely substantially helped by having automated tools that do, you know, even if it's like 60 to 80%, that's still pretty great, but yeah, cool. So there's an official partnership there. So I guess there's a business that is writing these codemods and the React team is in collaboration with them to make sure that they work well.
-
-[27:45] That's cool. That's great. Love that it's not just the core team trying to do everything on their own. Yeah, Mark, you want to take us on to React Compiler?
-
-## React Compiler
-
-[27:52] **Mark Erikson:** Sure. So, React Compiler came out in beta at ReactConf, and so we're starting to get, you know, various examples of people trying it out hands on in the real world.
-
-### [I tried React Compiler today, and guess what… 😉](https://www.developerway.com/posts/i-tried-react-compiler)
-
-[28:03] **Mark Erikson:** There was a very good post from Nadia Makarevich, I believe is the name, who has written a number of excellent articles about React rendering in the past. And she tried it out on both some toy applications and some larger, real world codebases that she had. And she found that the results were mixed. She expected the compiler to optimize fairly large percentages of the components in those codebases.
-
-[28:29] And it only seemed to optimize like 20 or 30 percent. Now, , apparently the compiler tool does have a health check command that will tell you which components it would bail out of because those are breaking the rules of React. And I believe that the updated React lint rules can also give you an indication of which components might not get optimized.
-
-[28:51] But her takeaway, I believe her takeaway was You know what? Well, okay, like this, this seems promising, but if real world code bases aren't going to get, or are we going to have like 20 to 30 percent of the components improved, that's not quite what we were pitched. Now, I will note that, uh, Satya from the React, React compiler team, I believe commented here in Reactiflux that, hey, this article is great.
-
-[29:14] Like, we got to See these example apps that she posted about, and we've been doing a bunch of additional changes to make sure we're handling those cases. So, I mean, just because it didn't work perfectly in her case, doesn't mean that the compiler's bust. It just means that it's still a work in progress. So having that real world feedback is actually very good.
-
-### [Understanding React Compiler](https://tonyalicea.dev/blog/understanding-react-compiler/)
-
-[29:32] **Mark Erikson:** And then Tony Alicea, wrote an Excellent article that actually breaks down what the compiler does and what the output looks like and how it works in practice. So, very worth reading if you want to understand what the compiler actually does for you.
-
-[29:47] **Carl Vitullo:** Heck yeah. Cool. Yeah, I guess I'll move us on.
-
-### [Why don't we have a Laravel for JavaScript... Yet](https://wasp-lang.dev/blog/2024/05/29/why-we-dont-have-laravel-for-javascript-yet)
-
-[29:50] **Carl Vitullo:** I wanted to call out this There's been a lot of, conversation that I've seen around, like, Laravel, specifically, specifically Laravel, Theo put out a video that then somebody wrote a blog post replying to of, " why don't we have a Laravel for JavaScript?"
-
-[30:06] And this actually crossed my radar from somebody who's not in the React world at all, they were talking about scoping a project, adding authentication to some app. And they said, "this developer estimated two weeks to add authentication to the product and I thought that was ridiculous. We have that out of the box in Laravel."
-
-[30:24] I, I, I chimed in because it's like, you know, I've done auth a couple of times in my life, in my career and like, yeah, you know, okay, sure. A login form, that's not hard to do in a day, but when you get like a settings page and you know, you got to be able to change your email address and reset your password and do two factor authentication and, you know, social login, It's like, you know, I mean, two weeks doesn't sound that wrong to me.
-
-[30:48] And he replied like, All of this is, all of that, everything you just described comes out of the box in Laravel. And it's like, alright, you know what, okay, maybe we do complicate things a little bit. Maybe not overcomplicate, but I guess, it, it, we do have so much flexibility and modularity and ability to Write things from scratch in React and, you know, in the React ecosystem more broadly, maybe that we have, you know, as far as the pendulum swings, maybe we have stayed in maximum modularity mode for a little bit longer than might be optimal.
-
-[31:21] I don't know. I, I'm curious what you guys think of that. where's the trade off? Where's the optimal line between modularity and out of the box functionality? I
-
-[31:29] **Mark Erikson:** mean, I think a lot of it also is the, you know, the whole back end, front end split. I mean, Laravel, you know, PHP, Rails, Ruby, they are back end languages, and the use case is You know, like, you know, the back end is doing basically all the work for you, and then, you know, there, there might be some additional stuff on the front end.
-
-[31:53] And so I think the frameworks there, they've, they've been around longer, and also they evolved to have, we, we need to have everything the back end needs to do all the work. Whereas, JS has always had the front end, back end split, and it's not that we couldn't build something that was, you know, absolutely out of the box like that.
-
-[32:13] I mean, there are, you know, some examples of that in the JS ecosystem, but I think it's typically been much more of a, like, I just need a basic HTTP server like Express. to serve up my client side code and then go from there. So, I think the modularity is a big aspect, but then also the differences in, like, the ecosystem historically as well.
-
-[32:34] **Mo Khazali:** I do think, you know, I've spent a bit of time working in the Django world a little bit, and I can definitely see the appeal to having something like Laravel, where so much comes out of the box. Done for you. And that interconnectedness means that it is a lot smoother to do things like you mentioned, like settings on a profile to modify those things.
-
-[32:51] They're all like one centralized model in Django. And it's significantly easier to create those sort of CRUD operations for users on like a settings page. It doesn't take you weeks. It takes you a day. And I know a lot of people who've been developing a while, like they spent time in the PHP world or in the Python world with Laravel or Django, and then they, you know, started doing React in our company and they were all like, this sucks, really don't like doing this.
-
-[33:12] It was so easy with Django, but I guess it's the pendulum swings and we probably land on some sort of midpoint, you know, I wouldn't be surprised if people start building things on top of Next, which allows it to be a more full fledged opinionated server that also can render and template React code.
-
-[33:26] **Mark Erikson:** That's what Blitz was. Blitz started off as the whole suite of things to go with Next, and then they tried to fork Next, and then they gave up on that idea.
-
-[33:35] **Carl Vitullo:** Yeah, and I mean, I guess this is, over the last ten years, React has slowly, I feel like it's grown in scope of, like, where people want to use it.
-
-[33:43] Like, when I first started it, There was a lot of, put it in, like, this spot, this little rectangle on the website, like, that's where React goes, and several years ago, that moved into, most people are using React to build their entire app, like it owns the entire client side, and now we're moving Up the chain into React owns more of the server side as well.
-
-[34:05] So maybe that's just kind of like the, this projects like Laravel already owned the data model in the server. And they had to come from there into owning more of the client side to provide a better experience there. And they certainly don't compete with React there in any meaningful way. Like nobody would, I don't think anyone would seriously suggest that projects like Laravel are able to provide. An exact, or a highly comparable, interactive client side experience.
-
-[34:35] You know, as I'm saying that, nobody would argue that. I think DHH has seriously argued that.
-
-[34:39] **Mo Khazali:** I was gonna say DHH hasn't argued that yet.
-
-[34:42] **Carl Vitullo:** So, okay, people do People do argue that, but let me add the caveat of offline capable. I don't think anyone would seriously argue they provide an offline capable client side experience comparable to React.
-
-[34:54] And so, yeah, I guess, you know, now with, as server components expand in utility and capabilities, like, yeah, maybe we will start seeing more of a Laravel. Or Ruby on Rails type of full ownership of the experience, which would make it more easy. Because that's really the problem here is React isn't even aware of the data model in most applications.
-
-[35:18] So that makes it very hard to do CRUD interactions, if you don't have the data, if you don't have direct access to the data. I just thought that was a really interesting framing for this. Like I have all, I've, I've lived in React for many, many years. And so then seeing people talk about how quickly you can do common tasks in a Laravel, it's like, Oh, Shit. Interesting. That's, that is a big difference.
-
-[35:39] Cool. Let's move on to Vercel Ship, their conference roundup. Moe, do you want to take us on that?
-
-### [Vercel Ship 2024](https://vercel.com/blog/vercel-ship-2024)
-
-[35:45] **Mo Khazali:** Sure. just the general and quickly running through this, Vercel is obviously moving across and, and taking up more of the, more than just becoming a hosting platform, so.
-
-[35:54] There's pieces on how you can collaborate and people in different teams can collaborate and, you know, preview different sort of webpages. And we've seen some stuff like that and more focus on observability. So they've added things like metrics and feature flags. And so there was someone who actually commented on Twitter about how beautiful their toolbar was as well, which I thought was quite cool. But no, there's, there's like a lot of direction around like product collaboration and a push in that, in, in that direction. So that's quite interesting.
-
-[36:18] Just on the observability piece, I actually found it quite interesting that hosting providers are going in that space. So Cloudflare a few months ago acquired Baseline, which is also an observability tool, and I think they're trying to integrate it into their workers slash Cloudflare pages space, which is a competitor to Vercel's, you know, hosting platform plus their, their serverless functions that they've got.
-
-[36:37] So, or the edge functions that they've got. So I think it's interesting that a lot of them are moving. Past just hosting into that observability space as well. And I think there's going to be a pretty big competition in that space in the next couple of years.
-
-[36:48] **Carl Vitullo:** Okay. That makes sense. Yeah. I haven't yet played with this at all, but I think I've heard people discussing the Vercel, metrics and feature flagging and that, yeah, I think that the, tacking those onto the, to a hosting provider does make a lot of sense to me because I feel like you get, you start getting a lot more things for free if those are all bundled together into one thing, like, I don't know, just having used LaunchDarkly and other feature flagging tools like that.
-
-[37:14] It feels like if they knew when a release was happening, if those feature flagging tools knew when a release was happening, I can imagine various optimizations or improvements to the, like, developer experience, the experience of putting out a new release that could be enabled by that. So yeah, that's something I'm paying attention to.
-
-[37:34] We'll see how that goes.
-
-### [TS 5.5](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5/)
-
-[37:35] **Mark Erikson:** All right, next up, TypeScript 5. 5 is out. And the, the single biggest thing that is interesting about this release is what they're calling inferred Type predicates. So as a little bit of background, one of the nifty things about TypeScript is you can write code that does runtime checks, and TypeScript uses that to narrow down TypeScript type of a particular variable is.
-
-[38:00] And part of that is not just having like an if statement, but actually having separate functions that, for example, accept any value, and then they do some runtime checks and you tell TypeScript, if this function returns true, then the actual TS type of the value must be some more specific type. And so you can use that to tie together runtime checks and type and compile time behavior.
-
-[38:27] But the issue was that things like filter callbacks for arrays, which return a boolean, didn't do any of that narrowing. And so you might have, like, an array that could be, like, item or null, and you could do a check. In the filter callback and say, if thing is not null, you know, return true, which ought to tell you that by the time we're done, we only have actual items and no nulls.
-
-[38:53] But TypeScript wouldn't automatically narrow down the TS types based on callback functions like that. So with TypeScript 5. 5, they've improved the type inference. So that if you have a function that accepts some value and does some checks and returns a boolean, TypeScript will automatically try to narrow down the TS types of the output to be stricter.
-
-[39:18] And so, this is going to be a nice little quality of life improvement for a lot of different TypeScript use cases. One other interesting thing that I saw in there, is that apparently they're doing some syntax checking on regular expressions. Mostly just catching things like, you know, like you have too many parentheses in there.
-
-[39:36] But that one's actually pretty cool too.
-
-[39:38] **Carl Vitullo:** Yeah, definitely super cool. I, on my list of things that I, that would make me excited, like typescript checking regexes was not on there, so I, Very unexpected for them to even start moving in that direction. But like, heck yeah, please help me make my regexes a little more robust.
-
-[39:54] **Mark Erikson:** One other thing towards the bottom that's under the hood. So they've done some changes on their internal variable definitions. So that they get more optimized by the JavaScript runtime, basically making sure that the same fields always exist. And you don't like occasionally add an extra field to the object dynamically.
-
-[40:15] And so because of that, the runtimes are able to optimize the behavior. And they found that it actually improved compile times by like 5 to 10 percent just by making the fields more consistent.
-
-### [TypeScript 5.5 is a BANGER](https://www.youtube.com/watch?v=sciBO_IaxTw)
-
-[40:26] **Carl Vitullo:** Yeah, I also want to share, Matt Pocock did a really great, just like quick 10 minute video breaking down what's new in TypeScript 5.
-
-[40:35] 5. So definitely worth, he's just such a great TypeScript expert. Just wanted to call that out. Great resource.
-
-### [Mind The Gap talk](https://www.youtube.com/watch?v=1g5ruM-16_Y&t=7595s)
-
-[40:41] **Carl Vitullo:** Cool. I wanted to shout out a conference talk by Ryan Florence that came out of Big Sky DevCon. I saw quite a number of people referring to it as like the best talk I've seen in years. I don't know if I would go that far personally. It's a great, it is a great talk.
-
-[40:57] It's, it's kind of just, I think I would describe it as like an oral history of the Problem space that React Server Components is trying to address. It just sort of talks about like the difference between, you know, the server and the client and the network being in the middle and plots out a couple of different tools and where they live in that, You know, taxonomy.
-
-[41:19] Definitely worth checking out. I mean, Ryan Florence has been around for so, so long. So hearing him just do kind of a dump of history of a problem, I thought was really interesting. It was definitely worth listening to.
-
-[41:32] **Mo Khazali:** I'll jump in with some React Native stuff quickly.
-
-### [Lorenzo Sciandra exiting React Native](https://x.com/Kelset/status/1800158749811966280)
-
-[41:36] **Mo Khazali:** So first, and I'd say most significant news in this space is unfortunately that Lorenzo Sciandra from the Microsoft team is leaving the React Native world and also leaving Microsoft, which is, I would say personally, a pretty big blow to this, to this community.
-
-[41:51] He's been such an instrumental part of. Getting more and more community involvement inside of React Native. He's been doing React Native for more than six years and, you know, being based in the UK. I've known him personally for a couple of years now and such a lovely guy. And I think he's moving on to focus something around making sure that the tech space is A little bit healthier and a little bit more humane, as he likes to put it.
-
-### [debug:mind by Lorenzo 'kelset' Sciandra](https://www.youtube.com/playlist?list=PLiD6R_aXkpLiMfS2YrhSgtSj09JJCaP2y)
-
-[42:13] **Mo Khazali:** And he's been focusing on mental health struggles within the tech ecosystem and within, within a career of tech. So you should definitely check out his podcast called Debug Mind. But really just want to, from the bottom of my heart, say a big thank you to Lorenzo for everything that he's done over the last six plus years.
-
-[42:27] An absolute shame that he's leaving us, but I am very excited for everything that he's going to be doing afterwards.
-
-[42:33] **Carl Vitullo:** Yeah, I have repeatedly come across his name when I've looked for React Native resources. He's done so many great lists of like, I can't even remember the various types of lists he's done, but just like major projects in the React Native space and educational resources on React Native.
-
-[42:51] Yeah, definitely a big blow to have him exit the ecosystem.
-
-[42:55] **Mo Khazali:** And, you know, more than that, you know, I think Lorenzo has been sort of the person who's been trying to bring the meta team closer and closer to the community. So, you know, Lorenzo, for the first time that I went to Meta's offices, Lorenzo invited me and, Organize that with a lot of the Meta folks to, to bring me over and, you know, for me to be able to chat and bring some of my concerns over to some of the folks at Meta and, you know, that became more of a recurring thing, all thanks to Lorenzo.
-
-[43:17] So he's been very instrumental and he's one of those sort of open source maintainer that maintainers that really cares about the community. So yeah, definitely a big blow.
-
-[43:24] **Carl Vitullo:** Yeah, and earlier, Mark was talking about how the React Native team has been a little bit better than the React core team at interfacing, doing like working groups and things like that, and including the community and the development.
-
-[43:36] I wonder, I wonder what role he played in making that happen.
-
-[43:40] **Mo Khazali:** A major one, definitely. So, yeah, but. Best of luck to him. I'm sure he's got some amazing stuff lined up that he's going to be exploring next. And yeah.
-
-### [Expo Atlas](https://expo.dev/blog/introducing-expo-atlas)
-
-[43:47] **Mo Khazali:** Next up, one thing that I'm personally super excited about is Expo Atlas. So Expo Atlas is almost like a sort of bundle size visualizer, but taken to a little bit of a higher level.
-
-[43:57] And this is something that's been missing from the React Native ecosystem for a long time. So just a little bit of context. Bundle size has never been a concern for the React Native ecosystem, unfortunately. For, for, for better or for worse, because it's all sort of sent once in the bundle of an application, when you download it from the app store, people don't seem to really care that much about how much JavaScript you ship, so long as it's downloaded once it's done.
-
-[44:19] And, you know, things like app startup time and actually, you know, having a lot of JavaScript and runtime don't affect React Native apps as much because of. Things like Hermes existing, where you have an engine that will have some sort of like bytecode representation and not have to load the entire JavaScript bundle into, into its runtime.
-
-[44:35] So that's been a challenge when you're trying to take React Native and put it on the web and deal with this whole universal story. And so, you know, one of the things that I spent a lot of time around React Summit, speaking to Evan and Cedric from the Expo team about was, you know, how do we make sure that some of the third party libraries that have.
-
-[44:52] I've been creating over a long period of time in the React Native ecosystem, actually have small bundle sizes when you try to take them to the web. And Expo Atlas is kind of the take that the Expo team has at doing that, which is, well, a lot of these libraries are all CJS based, so if we just introduce tree shaking into the bundler for React Native, It's not going to necessarily solve that problem by itself because most of the libraries won't be tree shakable.
-
-[45:13] So then what's the way to do it? Well, let's just visualize the problem, see what libraries are bundling in a lot of crap, and then see if we can slowly start to, as a community, shave some of that off and improve the performance for React Native web apps. This is a slow burn. It's not going to. Change over the next year, two years, maybe even three years, because there's a lot of legacy there.
-
-[45:31] But I think it's the right step. It's showing and visualizing the problem. So great tool that's out there. We'd definitely check it out. It shows you in a different way to how like the bundle visualizers that you might be used to, it actually shows you which import of a library you have in your code that is actually causing this library that might be bloating your bundle to be loaded.
-
-[45:50] So, you know, it might, it goes down the tree for transitive dependencies as well, which is quite cool.
-
-[45:54] **Mark Erikson:** Oh, that's wonderful.
-
-[45:56] **Mo Khazali:** Really great tool.
-
-[45:57] **Carl Vitullo:** Yeah. I'm looking at this, the visualization of the blog post with the, you know, recursive squares showing the, the bundle size and, oh man, I remember almost a visually, almost identical tool, much less polished.
-
-[46:10] Clearly this has someone who did a design pass, but there was a very similar tool that came out for Webpack in like, I don't know, 2014.
-
-[46:19] **Mark Erikson:** There's been a number of them, Webpack Bundle Analyzer, Source Map Explorer, and a couple others.
-
-[46:25] **Carl Vitullo:** I, I like practically made a career out of like fixing performance issues just because I learned that tool and it actually enabled me to do things.
-
-[46:33] So yeah, cool. Love to see it. Love to see it in the React Native context. Definitely looks valuable.
-
-[46:38] **Mo Khazali:** Cool. So then a few sort of quick things.
-
-### [Expo adds Compiler support](https://github.com/expo/expo/pull/29168)
-
-[46:40] **Mo Khazali:** Firstly, Expo's now added React compiler support. We saw this in the React Conf app. It was already using the React compiler. So just, you know, if you want to try it out experimentally, you can use the React compiler and see how it works for your app.
-
-### [Starlink's React Native app](https://www.notjust.dev/blog/react-native-starlink)
-
-[46:52] **Mo Khazali:** Next up is Starlink's React Native story. So this was interesting because it came out during AppJS, which happened last month. So the Starlink app is, is obviously built with React Native and it uses a lot of the expo libraries and things like React 3 Fiber. And it's really cool to see how some of these tools that we all have available to us are used in practice in some pretty serious production apps.
-
-### [Expo Router 3.5](https://twitter.com/Baconbrix/status/1788235769812795559)
-
-[47:14] **Mo Khazali:** And then another quick fire one, minor changes to Expo Router in Expo Router version 3. 5. So, just some stuff like, you know, supporting the, the sort of the hash parameters. There's some stuff around native, native intents with deep linking that you'll need for having a more seamless handoff between different Devices, and also for allowing for certain links to, to come with more details to, to really augment the native functionality.
-
-[47:38] Another small thing that I think is quite important, that's not actually one of the top headlines with this, is that previously Expo router was using an, a non standard version of the request and response. And with this version, they've, they've standardized it a bit more, which is great because that should definitely be standardized.
-
-[47:55] And then a few. Other minor things that I'm just going to run through. One is React Native Vision OS won the Git Nation Open Source Award, which was quite cool. It's a really cool project. Definitely give it a shot. And the folks from Callstack were there at a bunch of these different conferences with Apple Vision pros, trying to get people to try out React Native with Vision OS, which was quite a fun thing to try out.
-
-### [SF Symbols beta support in Expo](https://docs.expo.dev/versions/latest/sdk/symbols/)
-
-[48:16] **Mo Khazali:** Next up there is sf symbols. So sf symbols is sort of an icon pack that comes default with iOS. It oftentimes feels very Apple esque and having that inside of your app means that the icons are uniform with the OS and they look and feel like it's an iOS application and Expo's added beta support for it.
-
-[48:36] This is an interesting one because React Native is obviously cross platform. The main targets that you'll have is an iOS and an Android app, so specifically supporting icon sets and an icon set that's available for iOS means that you may need to have some divergence in your code base if you want to really use those SF symbols, and you'll need to create or choose equivalent Android icons, so a little bit of an odd take, but I'll see you A lot of people seem to really want to use SF Symbols, even with React Native apps.
-
-[49:03] So I'm sure that there was a level of feature requests and community involvement in trying to get that working. So that's definitely there. And then lastly, React Native Screens. This is actually a library that you will rarely ever have to use directly inside of your application code, but it's actually being used under the hood by React Navigation, which is by far the most common navigation library within React Native.
-
-[49:25] And they've just added some extra minor improvements. One that's quite cool is transparent header support. Obviously on the native layer, there's functionalities on iOS and Android to be able to add a transparent heading that's got a little bit of a blur, and it comes up with some cool effects. You can do that in React Native with the, with the default navigation libraries.
-
-[49:43] So React Native Screens has been updated to support that on both iOS and Android now, which is just cool minor changes. And that's just about everything that's been happening in the React Native ecosystem in the last month.
-
-[49:53] **Carl Vitullo:** Nice. Excellent. Thank you for catching us up.
-
-[49:56] Okay, shall we move on to our lightning round, see how many links we can get through there?
-
-[50:00] **Mark Erikson:** Yes, because we're already an hour in, so moving right along.
-
-### [React Internals Explorer](https://jser.dev/2024-05-11-introducing-rie/)
-
-[50:03] **Mark Erikson:** I saw a really, really cool tool called React Internals Explorer. It looks like you write some React code in a sandbox editor. And then it actually digs into the React fiber tree and shows you the structures of that.
-
-[50:17] I haven't even had time to play with this, but just like glancing at it and seeing a screenshot. I'm actually really, really excited about this because I love digging inside React's internals. I know most other people don't need to, but this looks really helpful. And the author has already written a whole series of blog posts where they actually go straight into the React source code and explain how specific features of React are implemented under the hood.
-
-[50:41] So if you want to know how React works inside, very worth reading.
-
-### [What's new in JavaScript Frameworks for May 2024](https://developer.chrome.com/blog/frameworks-may-2024)
-
-[50:44] **Carl Vitullo:** Yeah. I wanted to call out a blog post from the Chrome team where they just, they do a recap. What's new in JavaScript frameworks for May, 2024. So this is, I guess this is old. It's undated. So I guess it must have come out last month, but they are just, they just quickly round up a bunch of.
-
-[51:02] they go through like Angular, Astro, React, Remix, Next, Vue, NUC, Solidsfelt, and a couple of others. Yeah. This is Adi Osmani is. One of the, you know, it looked like they did a video and wrote a blog post with it. I thought it was curious, or I thought it was interesting to see what the Chrome team thinks about JavaScript frameworks.
-
-### [Memory leaks](https://lucumr.pocoo.org/2024/6/5/node-timeout/)
-
-[51:24] **Mark Erikson:** There were a few different blog posts that touched on the theme of memory leaks. There was one that talked about memory leaks inside of Node, potentially if you're using the relatively new local async storage feature. the example there was with setTimeout.
-
-[51:42] Apparently, Node can be keeping track of async call stacks attached to the context storage, and so you could actually end up leaking a whole bunch of memory if you're using it in certain ways.
-
-### [Sneaky Memory Leaks](https://schiener.io/2024-03-03/react-closures)
-
-[51:53] **Mark Erikson:** Uh, similarly, there are also a couple of very good blog posts talking about potential ways you might end up with memory leaks in a React application.
-
-[52:00] In cases where you're using like use callback or use memo or with React query where you're writing functions that are doing data fetching or something like that, and they're closing over variables that are in scope and they might not even be getting used. But the closure keeps those variables alive longer than you would have expected.
-
-### [Data Fetching Patterns in Single Page Applications](https://martinfowler.com/articles/data-fetch-spa.html)
-
-[52:21] **Mo Khazali:** Cool. So next up is an article that's actually on Martin Fowler's blog. So Martin Fowler being the big thought leader and evangelist of, of all things, application development, period.
-
-[52:33] **Mark Erikson:** Enterprise architecture patterns.
-
-[52:35] **Mo Khazali:** You see, divisive at the best of times, Martin Fowler is, but there's, there's been more and more React articles popping on, and they're not actually written by Martin Fowler, but they're written by someone who works at, whose name is Juntao, or actually, I don't think he works at ThoughtWorks, but he's very close with Martin Fowler, so he writes on Martin Fowler's blogs.
-
-[52:53] And he's been doing some really cool work on writing articles that start from the basic principles and expand out and create more and more complex applications that explain a bunch of concepts. So his latest article is about data fetching patterns in single page applications, and it starts with basic React concepts, builds up around, you know, asynchronous states being handled on the client side, parallel data fetching, how do you handle fallbacks, and then things like pre fetching, and then kind of It takes you through this journey and tells you when you should use which one.
-
-[53:21] Would recommend it. It's a very, very long read, probably one of the largest blog articles I've seen in a very long while, but it's definitely worthwhile if you want to get a more holistic viewpoint. And he's written a lot of articles like this. Another great one that he's written just to give a shout out is called modularizing React applications with established UI patterns.
-
-[53:38] And this is one that Mark is not going to be very happy about, but this one is one of those, which is like, how do you enterprise ify React code, but it's actually a very interesting article that has some thoughts about how you should architect React apps. And some of those patterns, not all of them, are actually very good to make it easier for you to do things like testing and so on and so forth.
-
-[53:55] **Carl Vitullo:** Cheers. Yeah. Oh man, I remember reading Martin Fowler's blog like 15 years ago when I was like starting my career. So just for it to still be relevant is like a little bit mind boggling to me.
-
-[54:07] **Mo Khazali:** The website still looks like it's from 15 years ago as well.
-
-[54:10] **Carl Vitullo:** Yeah. It's unchanged from when I started reading it.
-
-[54:13] Yeah. Not a single change that I can identify.
-
-[54:16] Cool. Yeah. I wanted to bring up a blog from Snyk, a security. Firm, I don't know, security product service, 10 modern Node. js runtime features to start using in 2024. It's, I have always found it really tricky to stay on top of every level of development over time.
-
-[54:35] So I appreciate a little roundup post like this that just sort of calls out a number of new features that I may not have caught the release of. It's sometimes it's hard to see, see the each individual release. So the 10 that they call out are a test runner. Native mocking, native test coverage, watch mode, core pack, the env loader, some import meta fields for the **dirname and **file fields, native timers and promises, permissions module and a policy module.
-
-[55:08] Those last two are not super clear to me, but like the test runner and native mocking and test coverage. Super great to not have to pull in a third party tool for that. As well as, yeah, I mean, watch mode. The number of times I've installed NodeMon. If I can stop relying on a third party package for that, I'll be pretty happy.
-
-[55:26] I haven't checked that out yet, though. CorePack is actually, I feel like the name of it makes you compare it to Webpack, or it makes me compare it to Webpack, at least. But actually, it's, the main use for it is being able to specify a package manager at a specific version, which is so useful. Um, I appreciate that they have made it, I guess it's a, I guess it's a combination of being able to pin a specific version of your package manager, but it's also, I think, some underlying tools to make cross compatibility possible between package managers.
-
-[55:59] **Mark Erikson:** The primary issue is that NPM has always come pre installed with Node. But if you want to use Yarn or PNPM, or, Bun, I guess, you have to first use NPM to install those tools globally. And that's kind of a one off per system thing. And then you have to remind everybody that they're supposed to be using this package manager, the project.
-
-[56:22] And so I think the idea of CorePack is that if you specify in your package JSON, that, Hey, we're actually using Yarn 4. 1 or PMPM 9. 2. It will automatically do the work to make sure that the right package manager is available and being used in that project.
-
-[56:40] **Carl Vitullo:** Right. It fills the gap where, like, PackageLock or Yarn.
-
-[56:44] Lock will let you pin your dependencies, left the, you know, the gap of what about the version, you know, for the package manager because the different versions interpret that lock file slightly differently sometimes. Or, you know, I've had a more recent version of Yarn blow away my Yarn or, you know, start adding things like a, a digest half to the, to the lock file.
-
-[57:06] So being able to pin a version, super great. Yeah. As well as like having a env loader, so we don't need to use env anymore. But yeah, so I appreciated this as a quick summary of a number of new built ins for Node.
-
-[57:18]
-
-### [Migrating to the Next App Router With Zero Downtime](https://workos.com/blog/migrating-to-next-js-app-router-with-zero-downtime)
-
-[57:19] **Mark Erikson:** There was a very good post on migrating to the next app router with zero downtime. One of the pain points with server components is that you have to have the entire application set up with server components as the outer layer of the application in order to use them at all.
-
-[57:36] There's no straightforward, simple, like migrate, just a little piece of my component tree. And while you can use the app router with everything still on the client, as a client component, it's still a key step in order to even be able to think about using server components with Next. And so, this article was a good example of how a team with an existing Next app that used the Pages router was able to mimic the routing setup in the app router and carefully, step by step, make sure that things worked the same both ways.
-
-[58:05] Switch over and then be able to start using some server components piece within the existing structure.
-
-### [Deno Standard Library nearing 1.0](https://deno.com/blog/stabilize-std)
-
-[58:12] **Carl Vitullo:** All right, Deno announces that the standard library is nearing 1. 0. That sounds great to me. The standard library is now a collection of 38 packages, they say. I appreciated this. Rather than doing it all in one big bang 1.
-
-[58:26] 0 release for the standard library, they're actually going to repeat a process for bringing each of those 38 packages up to stable relief. So they're gonna do it through like a release candidate and then gather feedback with like a a one month timeline for each of those packages to gather feedback.
-
-[58:45] So yeah, that's A lot of effort, a lot of energy being invested into creating a standard library and oh man, here's a standard library for a JS runtime.
-
-[58:55] **Mark Erikson:** I'm confused. Are we allowed to have that?
-
-[58:57] **Carl Vitullo:** Right? It's, it, the classic criticism of JavaScript is the lack of a standard runtime.
-
-[59:02] So, oh my goodness, we have a standard runtime hitting stable. I feel like that's going to affect the ecosystem in some way, but we'll have to see what happens there. Cool.
-
-### [Why don't we do Acid tests anymore?](https://twitter.com/vcarl_/status/1805627502036983995)
-
-[59:11] **Carl Vitullo:** I'm going to call this one out. This was, I put, I put up one of my tweets. I don't know. I think it's a good question. I'm going to do it.
-
-[59:16] I proposed the question out, why did we stop making checks like the ACID3 test? Why isn't there an ACID3 test for, for example, progressive web apps? I remember the ACID test series of, projects was
-
-[59:30] **Mark Erikson:** Browser rendering behaviors.
-
-[59:32] **Carl Vitullo:** Browser rendering behaviors. It was, is the browser you're viewing the web page in standards compliant? Here is something. It should look like this. And I remember checking that in, you know, 2008 or whatever, when I was a wee baby nerd. And, my browser didn't render it correctly, and then a couple years later it did.
-
-[59:50] I was considering, like, what factors may have moved us away from things like that, and I feel like it used to be so hard to ship new things, new standards. That it took big coordinated pushes like that, or maybe the ecosystem was also just smaller and the number of players involved were, you know, it could fit in a room, but I feel like we've lost something a little bit in there.
-
-[01:00:12] Like the acid three test was CSS three was ratified as a standard. They put out an associated test for this rendering behavior so that. Users could check if their browser was working in compliance with the standards. And I guess I, I put up the comparison to progressive web apps because like, They are not fully rolled out, like Chrome put out, the Chrome team put out a lot of support for progressive web apps, very much as a attempt, I think, to make web pages viable as competitors to native apps, and it just kind of never really happened, I think in large part because we never got cross compatibility With all the browsers for those capabilities.
-
-[01:00:54] And I don't even know that we, as an ecosystem, as web developers, have a shared understanding of what makes a progressive web app, you know, what defines a progressive web app? How do you distinguish that what you've made meets all the criteria? So, I don't know. I just, it was lamenting our lack of those sort of litmus tests for, I guess, bringing a Technical definition to some of the terms that we throw around frequently.
-
-[01:01:21] **Mark Erikson:** It's, it's not quite what you're asking for here, but I can point to a couple ways that there's been more efforts to do interoperability efforts. One is I think the latest version of the speedometer benchmark for JS engines was specifically built to include a bunch of different things.
-
-[01:01:38] Reasonable, plausible example applications using various JavaScript frameworks. Like I know that there's like a React, Redux, Todo application as part of the benchmark sequence. So that's been an attempt to semi standardize things and make things a little more plausible. Also, I believe the last three or four years, all the major browser Vendors have done, I don't remember the exact term but like an interoperability effort where they identify like the top five or six pain points of places we know where browser behavior is differing and we're all going to make a push this year to make sure we all work the same way for these things.
-
-[01:02:15] So it's, it's not quite the same as having like the ACID3 test or, you know, a named version of CSS that we're all trying to implement, but it is, it is kind of along those lines.
-
-[01:02:27] **Carl Vitullo:** Right. Yeah. I don't know. I guess I, I, I think the branding that used to be baked in to those sort of releases served, I think to me, it served a valuable function in developer education. And I think that we've lost something through not having it.
-
-### [Web Platform Tests dashboard](https://wpt.fyi/)
-
-[01:02:41] **Carl Vitullo:** Like there was a web platform tests dashboard that like, yes, here is a single place that compares all of the features, accessibility, all of the compatibility across browsers, but it's not actually, you know, as a developer, it doesn't tell me what features are grouped together? What features go well together? What capabilities are unlocked by supporting this thing? We're going well beyond the scope of a lightning round link right now.
-
-### [HTMX: Simplicity in an Age of Complicated Solutions](https://www.erikheemskerk.nl/htmx-simplicity/)
-
-[01:03:09] **Mark Erikson:** all right, and last one we got on the list. HTMX is a library for basically adding attributes to HTML tags that do things like data fetching and automatically inserting the results into the page without having to explicitly write JavaScript yourself, and they put up a blog post entitled Simplicity in an Age of Complicated Solutions, where they have some examples of handling inputs and data fetching with VanillaJS or with React code.
-
-[01:03:37] And they point out and say, look at how complicated this is. Whereas if we just slap HTML into the page and we add a couple attributes, look at how simple this is. And there's, there's some valid trains of thought to this. Certainly you're writing less code as an application developer. I questioned a little bit some of their arguments on general principle, but it is worth reading for an alternate viewpoint on how application behavior should be implemented.
-
-[01:04:00] **Carl Vitullo:** Yeah, definitely interesting from a perspective of just considering expansion of complexity too. I thought that was, I thought it was cool to read from that lens too.
-
-[01:04:08] Cool. All right. That is all of the, all the links we have. Thanks everyone for joining us. We'll be back on the last Wednesday of the month in here in the live stage of Reactiflux or in your podcast feed as soon as we can after that.
-
-[01:04:20] **Mark Erikson:** Thank you for listening. Plug, please check out Replay. io for debugging your tests and trying to fix flakes. And also, I'm almost done with a very large revamp of the primary Redux tutorial to make it TypeScript first and explain more things. Carl just pasted a link to the draft PR in there. I would appreciate feedback.
-
-### [Revamp "Redux Essentials" tutorial](https://github.com/reduxjs/redux/pull/4706)
-
-[01:04:43] **Mark Erikson:** I'm hoping to have this done within the next couple weeks. Like, I'm almost done with the first draft, and then hopefully there's not too much more work to do. So, feedback, please?
-
-[01:04:52] **Carl Vitullo:** For sure. Awesome. Yeah. Mo, anything you want to add?
-
-[01:04:55] **Mo Khazali:** Nothing. Just thank you again for having me and always a lovely time chatting with you all and going over everything that's been happening.
-
-[01:05:02] And yeah, looking forward to the next one.
-
-[01:05:03] **Carl Vitullo:** Most definitely. Yeah. Always good talking to you guys. Cool.
-
-[01:05:07] we, we gather links from, um, a bunch of different sources, including thisweekinreact, bytes. dev, reactstatus, nextjsweekly, the reactjs subreddit. Right here in Reactiflux from the Tech Reads and News channel, um, and directly from people publishing articles, usually on like Twitter or Blue Sky.
-
-[01:05:26] If you see anything that you think that we should be paying attention to, definitely feel free to email us at hello at reactiflux. com with T M I R in the subject line. That's acronym for the show. I read every email that comes in, even the ones marked as spam. If this is the show you get value from and want to support, the best way to do so is to send it to someone.
-
-[01:05:45] Send it to your co workers, help them learn how you know so much about React. Otherwise, you know, submit a review, do stuff like that. But yeah, thank you so much for joining us. Appreciate it. See you next month.
diff --git a/src/transcripts/tmir-2024-07.md b/src/transcripts/tmir-2024-07.md
deleted file mode 100644
index 09fe1d9..0000000
--- a/src/transcripts/tmir-2024-07.md
+++ /dev/null
@@ -1,642 +0,0 @@
----
-title: "This Month in React, July 2024: State of React, State of JS, React, HTML"
-date: 2024-07-31
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- Quick hits
- - [[02:14](#job-market)] Job market
- - [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE)
- - [Layoffs.fyi](https://layoffs.fyi/)
- - New releases
- - [[03:48](#vitest-20)] [Vitest 2.0](https://github.com/vitest-dev/vitest/releases/tag/v2.0.0)
- - [Future plans](https://github.com/vitest-dev/vitest/discussions/5828)
- - [[04:06](#remix-210-fog-of-war)] [Remix 2.10](https://remix.run/docs/en/main/start/changelog)
- - [[04:24](#jotai-29)] [Jotai 2.9](https://github.com/pmndrs/jotai/releases/tag/v2.9.0)
- - [[04:34](#storybook-82)] [Storybook 8.2](https://github.com/storybookjs/storybook/releases/tag/v8.2.0)
- - [[04:52](#react-native-reanimated-314)] [RN Reanimated at 3.14](https://github.com/software-mansion/react-native-reanimated/releases/tag/3.14.0)
- - [[04:59](#htmx-20)] [HTMX 2.0](https://htmx.org/posts/2024-06-17-htmx-2-0-0-is-released/)
- - [[05:03](#mako-released)] [Mako is Now Open Source](https://makojs.dev/blog/mako-open-sourced)
- - [[06:01](#conferences)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[06:01](#react-rally)] [React Rally](https://www.reactrally.com/) Salt Lake City, UT, USA August 12-13
- - [[06:25](#react-universe)] [React Universe 2024](https://www.reactuniverseconf.com/) Wrocław, Poland September 5-6
- - [[07:23](#jsconf-chile)] [JSConf Chile](https://www.jsconf.cl/) Santiago, Chile September 5-7
- - [[07:32](#utahjs-conf)] [UtahJS Conf](https://utahjs.com/conference) Salt Lake City, UT, U.S.A. September 13
- - [[07:44](#react-alicante)] [React Alicante](https://reactalicante.es/) September 19-21
- - [[08:00](#jsconf-ireland)] [JSConf Ireland](https://www.jsconf.ie/) Dublin, Ireland September 25-26
-- Main Content
- - Survey results:
- - [[10:21](#state-of-html)] [State of HTML 2023](https://2023.stateofhtml.com/)
- - [[14:39](#state-of-react)] [State of React 2023](https://2023.stateofreact.com/en-US)
- - [[17:43](#state-of-js)] [State of JS 2023](https://2023.stateofjs.com/en-US)
- - [2023 State of JavaScript Survey Highlights: Vite Dominates, TypeScript Adoption Soars](https://socket.dev/blog/2023-state-of-javascript-survey-highlights)
- - [Dark Matter Developers: The Unseen 99%](https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99)
-- ⚡Lightning round ⚡
- - Company migrations:
- - [[37:54](#nyt-and-slack-update-to-react-18-enzyme-to-blame)] [NYT just updated to React 18](https://open.nytimes.com/enhancing-the-new-york-times-web-performance-with-react-18-d6f91a7c5af8)
- - [Slack converted from Enzyme to RTL with some AI assistance](https://slack.engineering/balancing-old-tricks-with-new-feats-ai-powered-conversion-from-enzyme-to-react-testing-library-at-slack/)
- - RN news
- - [[39:05](#rise-tools-launched)] [Rise Tools Launched](https://rise.tools/)
- - [[39:48](#mos-talk-about)] [Mo Khazali – Server-Driven Mobile Apps With React Native](https://youtu.be/vjTVnSUZVEk?si=KIURXZGKMz-gtRFB)
- - [[40:15](#nativewind-ui-launching)] [NativeWindUI launched](https://nativewindui.com/)
- - [[40:51](#gluestack-too)] [Gluestack is going in a similar direction with v2](https://gluestack.io/)
- - [[41:30](#swift-package-manager-support-moving-away-from-cocoapods)] [Swift Package Manager Support for React Native](https://github.com/facebook/react-native/pull/44627)
- - [[43:24](#react-native-filament)] [Using React Native MacOS with Expo](https://github.com/expo/expo/pull/30660)
- - [React Native Filament](https://twitter.com/mrousavy/status/1811354708235239680)
- - [[44:31](#react-native-for-web-devs)] [Guide to React Native for Web React devs](https://expo.dev/blog/from-web-to-native-with-react)
- - [[45:09](#build-windows-apps-from-a-mac)] [How to build Windows apps for React Native with a Mac](https://devblogs.microsoft.com/react-native/2024-07-18-running-rnw-from-a-mac-md/)
- - [[46:06](#ecosystem-performance-group-e18e)] [e18e (Ecosystem Performance) - A new community initiative | e18e](https://e18e.dev/blog/e18e)
- - [[48:10](#es2024-released)] [ES2024](https://tc39.es/ecma262/2024/)
- - [Tweet from Rob Palmer](https://x.com/robpalmer2/status/1806064466510897240)
- - [[49:00](#memory-leaks-compiler-wont-save-you)] [Sneaky React Memory Leaks: How the React compiler won’t save you](https://schiener.io/2024-07-07/react-closures-compiler)
- - [Garbage collection and closures](https://jakearchibald.com/2024/garbage-collection-and-closures/)
- - [How to publish a JavaScript package in 2024](https://www.youtube.com/watch?v=nl4B1asyMdI)
- - [[50:33](#react-native-flutter)] [React Native + Flutter](https://x.com/mdj_dev/status/1811317534936719562)
- - [[51:01](#bun-q3-roadmap)] [Bun’s Q3 roadmap (not exhaustive)](https://x.com/jarredsumner/status/1807731197046653438)
- - [[51:57](#learn-suspense-by-building-a-suspenseenabled-library)] [Learn Suspense by Building a Suspense-Enabled Library](https://www.bbss.dev/posts/react-learn-suspense/)
- - [[52:39](#marks-talk-why-use-redux-today-at-react-summit)] [Why Use Redux Today?](https://blog.isquaredsoftware.com/2024/07/presentations-why-use-redux/)
- - [[53:24](#chrome-collects-extra-data-for-google-websites)] [Chrome gives Google properties privileged information about your system resources](https://x.com/lcasdev/status/1810696257137959018?t=r9eYl5mMXDWVzZ9suZugjQ&s=19)
- - [[53:48](#component-composition-colocation)] [Component, colocation, composition: A note on the state of React | bobae kang](https://bobaekang.com/blog/component-colocation-composition/)
- - [[54:15](#secret-knowledge-to-selfhost-nextjs)] [Secret Knowledge to Self-Host Next.js](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)
- - Node news:
- - [[54:37](#node-can-strip-ts-types-soon)] [TS stripping](https://github.com/nodejs/node/pull/53725)
- - [[55:01](#native-sqlite-drive-in-node)] [SQLite support](https://nodejs.org/docs/latest/api/sqlite.html)
- - [[56:00](#node-moving-away-from-corepack)] [Removing experimental `corepack` tool for version managers?](https://github.com/nodejs/TSC/pull/1527#issuecomment-2258868015)
-
-[00:00] **Carl Vitullo:** Hello. Thanks for joining us for the July edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We are coming to you live from Reactiflux, the place for React developers.
-
-[00:13] And we actually have a sponsor this month. Woo! First time we're supported by Infinite Red, a consultancy that works exclusively in React Native. They've been around since 2015, have employees on the core team of React Native, and are super great.
-
-[00:26] I'm going to do a little more on them after we do introductions, but I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs and otherwise build tools to keep the community running.
-
-[00:39] **Mark Erikson:** I'm Mark, most of you know me as the guy who does Redux stuff, and as far as day job things go, I am actually looking for a new position, which is a bit of an interesting personal development, so if folks have suggestions for places I should be getting in touch with or that might be interested in me, please ping me and let me know.
-
-[00:59] **Mo Khazali:** And I am Mo. I head the mobile team at Theodo, and I'm an active community member within the React Native ecosystem. I organize the React Native London meetup and soon to be conference, and just contribute here and there, dabble a little bit into open source. Nowhere near as much as Mark does, but I do try.
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-[01:18] **Carl Vitullo:** Yeah, and a little more on our sponsor. Infinite Red is a expert React Native consultancy. I'm actually uniquely excited to get them specifically, Infinite Red, as a sponsor. They have been around, I've been seeing their name for the entirety of my career since I started in about 2014 with React. And they organize conferences, they host the largest React Native podcast, and generally have just shown up in very real ways to support the ecosystem and the community.
-
-[01:46] So I got a chance to connect with one of their founders, Jamon Holmgren at React Conf down in Las Vegas, and we just really vibed. They seem like really great people, they talk about how they are a team of 30 with mostly developers, mostly with more than 10 years of experience, and they work with your team to coach you on how to best use React Native.
-
-[02:07] So if your company is looking to build up some React Native expertise, definitely check them out. And thank you, Infinite Red, for sponsoring us.
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE) + [layoffs.fyi](https://layoffs.fyi)
-
-[02:14] **Carl Vitullo:** Cool. All right. On to some quick hits. Job market updates.
-
-[02:18] So there's a new source of data that I'm following, which is amusingly called FRED, an economic data set based out of the St. Louis Fed. So apparently the job site indeed does some like data analytics stuff that now the Federal reserve is relying on for like labor information. And this is a chart of software development job postings that have been posted to Indeed. And it is, indexed off the beginning of 2020. So it's more than doubles at about the start of 2022 and is down to about like 68 percent of that 2020 baseline and it's been pretty flat.
-
-[02:57] I really like this because I've been looking at layoffs. fyi for, you know, a year now and it just doesn't quite do it. It is, there's, there's enough, there's a lot of variability. It's only the source of Layoff. So this is kind of the other side. What does hiring look like? And unfortunately, hiring is flat to down, which is not great. But at least people aren't getting laid off as quickly anymore.
-
-[03:20] Yeah, speaking of layoffs, layoffs. fyi. This is the first time in, like, the A year and a half that we haven't had a, like, a pop of layoffs at the start of a new quarter. So that's a small positive sign. It's down versus last month in June and only the second time this year that we've had less than 10, 000 developers laid off. So, seems good. Hiring is not ticking up though.
-
-## New Releases
-
-[03:44] **Carl Vitullo:** Mark, you want to take us through some new releases?
-
-[03:46] **Mark Erikson:** Sure, a couple of the most interesting ones.
-
-### [Vitest 2.0](https://github.com/vitest-dev/vitest/releases/tag/v2.0.0)
-
-[03:48] **Mark Erikson:** Vitest 2. 0 is out. A bunch of small changes, but it's interesting to note that they're working towards a browser mode. Because we've had browser based testing for a while, but trying to focus on running unit tests in the browser. So, this has some very interesting potential there.
-
-### [Remix 2.10, fog of war](https://remix.run/docs/en/main/start/)
-
-[04:06] **Mark Erikson:** Remix put out a new release that has a fog of war feature, which looks like it's about trying to optimize downloads of route information. Looks like rather than bundling all the route information ahead of time, they will actually download chunks of it as you go, which should improve loading speed.
-
-### [Jotai 2.9](https://github.com/pmndrs/jotai/releases/tag/v2.9.0)
-
-[04:24] **Mark Erikson:** Uh, Jotai 2. 9 is out. And it looks like the public behavior is basically the same, but they've reworked the internals.
-
-### [Storybook 8.2](https://github.com/storybookjs/storybook/releases/tag/)
-
-[04:34] **Mark Erikson:** Storybook 8. 2 has, trying to look at the release notes, a few small changes, probably not a whole lot of big stuff.
-
-[04:42] **Carl Vitullo:** I've never quite understood the niche, the purpose that Storybook really serves. But, you know, hey, minor release, so it seemed worth calling out. I know it's pretty widely used.
-
-[04:52]
-
-### [React Native Reanimated 3.14](https://github.com/software-mansion/)
-
-[04:52] **Mark Erikson:** React Native Reanimated has 3. 14. So I guess there's your, there's your Pi release.
-
-### [htmx 2.0](https://htmx.org/posts/2024-06-17-htmx-2-0-0-is-released/)
-
-[04:59] **Mark Erikson:** Totally outside of React. HTMX just hit 2. 0.
-
-### [Mako released](https://makojs.dev/blog/mako-open-sourced)
-
-[05:03] **Mark Erikson:** And there is yet another Rust based JavaScript build tool that came out. This one's called Mako. I saw it. I'll be honest. I have no idea how this is any different than the other seemingly like 15 other Rust based build tools at this point.
-
-[05:20] **Carl Vitullo:** Mako has come out of the Ant design. That's what caught my eye as being notable.
-
-[05:24] So this is a Rust based developer being built by the team that put together one of the reasonably popular component toolkits. It seems notable for that reason to me. But yeah, yet another Rust based build tool. One more thing on Mako. They put up a bunch of benchmarks that show it being like 10 times faster than Webpack and noticeably faster than RSBuild 0. 6, which is pretty impressive. They also talked about like not being able to get it to work, getting their benchmark to work with the latest release of RSBuild, which is 0. 7. So who's to say if those benchmarks will really hold up, but yeah, cool.
-
-## Conferences
-
-### [React Rally](https://www.reactrally.com/)
-
-[06:01] **Carl Vitullo:** Some conferences coming up. We've got React Rally in Salt Lake City, August 12th and 13th. I've been to React Rally a couple of times Over the years and definitely a great one. I also noticed it's pretty much the only conference in August. I think because everyone's on vacation.
-
-[06:16] **Mark Erikson:** React Rally is wonderful. They've done a great job of really having a good community vibe over the years. I should be there. So folks want to come by and say hi, please do.
-
-[06:24]
-
-### [React Universe](https://www.reactuniverseconf.com/)
-
-[06:25] **Mo Khazali:** Next up. We've got React Universe Conf in Wroclaw in Poland on September 5th and 6th. I actually am seeing this conference. So if you like listening to me talk about weird stuff and ramble, it's the place to be, I guess, but no, it's a great conference.
-
-[06:41] It used to be the former React Native EU, and now it's expanding to cover all things React based. And we've got some really good speakers there. So obviously you've got the, the popular React Native speakers that are the lineup of every single React Native community conference that you know, but we've also got folks like Dan Abramov, who's been I can't see Dodds and some others, and I would highly recommend coming to it.
-
-[07:03] The organizers really know how to organize conferences. They've done it for many, many years and you're guaranteed pretty much to have a great time.
-
-[07:10] **Carl Vitullo:** Yeah. And on them knowing how to organize a conference, they organized React Conf. They were one of the organizer partners for that. So yeah, they certainly do. They have organized yet another conference. Definitely would love to get up to Poland if I can. Cool.
-
-### [JSConf Chile](https://www.jsconf.cl/)
-
-[07:23] **Carl Vitullo:** A, an overlapping conference. There's also a JSConf Chile in Santiago. That's September 5th through 7th.
-
-### [UtahJS Conf](https://utahjs.com/conference)
-
-[07:32] **Carl Vitullo:** There's a Utah JSConf again in Salt Lake City on September 13th. I guess this is. JavaScript versus React for React Rally. But yeah, so we have two conferences in Salt Lake City a month apart.
-
-### [React Alicante](https://reactalicante.es/)
-
-[07:44] **Carl Vitullo:** There's React Alicante, which is going to, it looks like it's going to be an online conference.
-
-[07:49] **Mark Erikson:** It's in person in Spain and I'm speaking there.
-
-[07:53] **Carl Vitullo:** Cool. Oh, awesome. Wonderful. Go see Mark speak in Spain. That is September 19th through 21st.
-
-### [JSConf Ireland](https://www.jsconf.ie/)
-
-[08:00] **Carl Vitullo:** There's also JSConf Ireland in Dublin with also streaming September 25th and 26th.
-
-[08:07] And that is all of the conferences we have this month. Uh, I will shout out, last month I mentioned a conference that I will not name again because it came to light that they were using fake speakers on their website and had various people listed as speaking at the conference who were not. So, uh, I updated the transcript, but I wanted to shut that out. I did try to check. I do look at the conference websites and try and vet them, but I got it wrong last month. Sorry.
-
-## State of the web surveys
-
-[08:32] **Carl Vitullo:** All right. Onto our main content. We are slightly behind the times by a month or two on State of surveys. There have been a bunch of state of React, state of JavaScript, state of HTML, all kinds of states that have come out over the last two months or so, which is later than I expected.
-
-[08:50] Usually these have, in years past, the state of JS surveys have done a pretty good job of coming out. Pretty promptly, they've been running for, it seems like, most of my career. So, just surprised. Seemed like there were some, hitches this year.
-
-[09:04] **Mark Erikson:** Yeah, like, I'm not sure if it was that they, they just took a really long time to analyze the data, or they were working on, I know they did a lot of work on, like, new data visualizations as part of the survey results.
-
-[09:14] So, it might just have been that it took them a long time to get the new sites put together.
-
-[09:19] **Carl Vitullo:** I did notice that they had some really cool data interactivity bits on it, like you can, for a lot of, at least on the State of JS site, the State of React one got, looked like a little bit less attention, which is fair, it's a much smaller survey, it's like a third of the size. But, they had some interesting stuff where you could filter or correlate responses. So it's like, Oh, you can see years of experience as it pertains to salary. So there was a lot of really cool data exploration stuff there.
-
-[09:48] I did also see a little bit of chatter online or on Twitter about how the survey was promoted and what that means for its sample size and audience. demographics mainly, like the survey responses were like 92 percent male and that's not great. I've seen other spaces get up to like 80 percent male, so, you know, 15 to 20 percent female, which seems to be about the high watermark, unfortunately, for online based tech communities. But yeah, so just, just wanted to shout out that I have heard a little bit of that.
-
-## [State of HTML](https://2023.stateofhtml.com/)
-
-[10:21] **Carl Vitullo:** I'll start with the two smaller surveys.
-
-[10:23] So state of HTML was actually really interesting to me. I don't super duper know how to stay on top of, like, HTML and CSS changes, so I feel like every couple of years I, like, see a talk from someone who's a genuine cutting edge expert in CSS and, you know, use the platform kind of stuff and go like, "oh, holy shit, I don't know how to use HTML anymore," because just reading the state of HTML, I found a bunch of little things, a bunch of new features that I was not aware of. I unfortunately didn't take a bunch of notes on them, but just scroll through, see what catches your eye, see what you haven't stayed up to date with.
-
-## "Use the platform"
-
-[10:58] **Mark Erikson:** I know we've had, you know, there's, there's kind of the running meme of, you know, the, the folks who insist on use the platform and the, and the React community is a little bit like, "but the platform doesn't support all the things we want to do," but browsers are continuing to implement, new features, the HTML and JavaScript specs keep advancing.
-
-[11:17] And it's a fair critique that folks who tend to focus on, the React type front ends probably don't know as much about the nuances of what's available in HTML and CSS as folks who are more focused on that. So, like, there's sort of fair critiques on both sides, and it's worth keeping an eye on, the new advances there.
-
-[11:39] **Carl Vitullo:** Yeah, something that I have thought of many times over my professional career is like, there's use the platform, you know, there's a lot of things you can do without writing JavaScript code. If you can do it with a native feature, it's going to be less development time. It's going to be, it's probably going to be faster, more performant for the user.
-
-[11:56] But that use the platform nature is in tension with the flip side of React trying to allow people to write code that runs in more environments. So it's sort of, there's sort of that dichotomy. There's the pressure of writing a tool tip library, writing a modal library that works in React Native as well as natively on the web.
-
-[12:16] And if you rely on the platform features, then you can't do the React Native side of things. So There's been a big tension there for many, many years, but I have been very interested in what it would look like if there was a component toolkit that just said like, nope, fuck the other platforms, we're just going to go all in on web, we're going to do it in as few lines of code to get the best user experience and the best developer experience possible.
-
-[12:38] I don't know of one that's really working in that way, but I think it would be really cool.
-
-[12:42] **Mo Khazali:** So two points on that, which I think was a really interesting point that you raised, Carl. One is part of the reason why a lot of these libraries don't really work well for React Native is the lack of web API support in the React Native ecosystem.
-
-[12:54] And it is actually something that's being worked on. So Microsoft opened an RFC last year and they said, well, you know, we, we, whether we like it or not, as native developers, the web APIs have won. They're becoming standardized. Things are. Relatively stable. So why not try to at least use those as the interfaces, even if the native implementations are different under the hood, so that when you do use your trusty old React library, it does just kind of work out of the box in the React native ecosystem.
-
-[13:18] So there is a move towards that and you've got React strict DOM and whatnot. But the example, the counterside to that is the example of tooltips that you mentioned. Like tooltips are not a mobile. Friendly UI element. So there's no easy answer to this unless you create really high level primitives that are UI agnostic.
-
-[13:35] But functionality wise, they kind of behave similarly. So, you know, from a way that it looks, it's totally different on iOS, Android, and web, but at least the APIs for the developers are the same. So opens a tool tip on the, the, the web with a hover, but you know, maybe opens up a modal. A bottom sheet modal on native.
-
-[13:52] So it's a big point of contention for us React Native developers that we're trying to figure out. I don't think we have the answer, and I don't think anyone's figured out the sweet spot. But we'll get there. We will get there.
-
-[14:02] **Carl Vitullo:** Yeah, I feel like it crosses my mind every couple of months, but just hearing you talk about like, the web platform just makes me think yet again of a 2013 talk called the birth and death of JavaScript.
-
-## [Birth and Death of Javascript](https://www.destroyallsoftware.com/)
-
-[14:13] **Carl Vitullo:** And yes, JavaScript is intentional. But yeah, if you are not familiar with JavaScript. That birth and death of JavaScript talk, watch it because like, oh my God, it's the most, it has remained the most like prescient talk I've ever watched. It is exactly discussing how JavaScript takes over the world and we're just living it, we're just living that 10 years later, 11 years later. Anyway, that's a, that's all kind of long diversion for state of HTML, but.
-
-## [State of React](https://2023.stateofreact.com/en-US)
-
-[14:39] **Carl Vitullo:** There was also a state of React survey. It was pretty good. I kind of got more interesting signal I felt out of the state of JavaScript survey. There was a lot of survey time dedicated to like, what React features do you use? And that's just not really a question that I have, you know, I don't really care if you use, you know, use context. You probably do. If you don't, you probably should. That section, what features do you use, is interesting in terms of like, what are people aware of, but I don't know that it really changes that much.
-
-## Component Libraries
-
-[15:07] **Carl Vitullo:** It did have a lot of good data about component libraries and ecosystem that I thought was, just, we, we spend so much time in here bantering about like, what the vibes are and how does it feel What tools does it feel like people are using more and talking about more?
-
-[15:23] So this is a good data based check in on how accurate the, the vibes, our read of the vibes are and pretty accurate. I'm pretty happy. We'll get more into it with the state of JS, just that did have a lot more of the vibes, but some things I thought were notable component libraries, generally not popular.
-
-[15:40] Some of them are reasonably widely used, but like not loved. Radix were the most loved with Headless UI, also pretty high up there. Radix and Headless UI are not ones that live large in my mind, so it was cool to see those surfaced. Definitely, like, you know, obviously we talk about ShadCN pretty frequently, but Redux and Headless UI, good ones to check out.
-
-[16:03] Headless UI looks cool because it's unstyled, so it's just behavior, and then you make it look the way you want. Which, here for it, love it.
-
-[16:11] **Mo Khazali:** I think that's kind of the direction that they're all going with as well. Like, you know, R a bit more opinionated, but still flexible in a lot of ways compared to, let's say, your run of the mill material UI.
-
-[16:21] I think that's the general direction where these things are going. And Headless is great for that. I guess that's the appeal with Shad for me as well, right? Like I know a lot of people love ShadCN. The appeal is, well, if you don't like the rounded corners specifically, it's just a tailwind prop to change and you're kind of done.
-
-[16:36] So you have a lot of flexibility there.
-
-[16:38] **Carl Vitullo:** Yeah, definitely makes sense. It's been curious to see how slowly that has evolved over the years. I, I bailed out pretty quick on component toolkits cause I just, I don't want it to look like a bootstrap site.
-
-## StyledComponents still big
-
-[16:48] **Carl Vitullo:** So there was also something that I found interesting just because it seemed like a, you know, narrative violation is styled components are still pretty dominant in terms of actual usage, like enormously widely used, you know, everyone talks aboutTailwind and whatever, but. Style of components, they're here to stay, they're sticking around.
-
-[17:05] Some other interesting data, 23 percent of respondents are still on either React 16 or 17. So this is like, how many years after 18 was released? And 6 percent of survey respondents don't know what version they use, which is interesting to me.
-
-[17:21] So, yeah. If you're using React 18, congrats, you are on the cutting edge. The only 68%, less than 70 percent of survey respondents are on React 18. Talking about nobody uses beta versions. Nobody uses advanced versions. I think it was like less than 1 percent have tried a canary. So rounding error. All right.
-
-## [State of JS](https://2023.stateofjs.com/en-US)
-
-[17:43] **Carl Vitullo:** State of JS, the big one. Mo, you want to, you want to kick us off with your thoughts? Break up my monologue.
-
-## A Note on Survey Sample
-
-[17:48] **Mo Khazali:** Sure. Good to start off with what you kind of start off generically about the survey results, which is you got to look at the sample size.
-
-[17:53] It's like the most important thing to do when you start with this, because it makes the data seem a lot more contextualized as a result. So a colleague of mine, she was talking about this and I kind of took notes and then looked through it and I was like, yeah, wow, that's very accurate. She was giving me her thoughts.
-
-[18:09] But the first thing is, location is heavily US based. So if you look at the respondents, 16 17 percent are from the US. If you combine Germany, France, and the UK, Those become close to the US respondents. They're about the same as the US respondents, a little bit more. So all of this data is heavily skewed by the US market.
-
-[18:25] Things like, let's say like the Indian developer community is very, very underrepresented. There was only about 500 respondents where that's about two, 3%. Whereas, you know, they should be a lot more because proportionately they'll have a larger developer community than that, which is represented.
-
-[18:41] **Carl Vitullo:** I think the total number of respondents was like 20 or 30, 000.
-
-[18:44] So hearing only 500 from India is like a little bit shocking. Yeah,
-
-[18:47] **Mo Khazali:** it's, it's quite poorly represented. Or the Netherlands, as an example, has got about 500 as well. The Netherlands is a big tech hub in Europe. A lot of big tech conferences happen, JavaScript conferences happen in the Netherlands because there's already a big community there.
-
-[19:00] So it's very interesting, I think it's probably more to do with marketing and how they got the word out, and which communities it goes to. And so when you have location being heavily based in the US, then it skews salaries quite significantly. US salaries for developers are much higher. than European salaries And so all of the salary data is being taken on sort of an average, and so that moves the whole scale, basically.
-
-[19:20] The other thing which kind of you hinted on, Carl, was it's almost exclusively male. So 94 percent men, which isn't great. It's really heavily, disproportionately male. Men who have responded to this. And then the worst view that you can see, and this should, if anyone has any doubts about this, just look at this view and hopefully your doubts will be completely gone but when you combine the gender and the yearly income views, you can see that men have a higher average salary.
-
-[19:47] Shocker. So the gender pay gap is very much there, and it's something to the degree of 20, 000 on average between men and women. Shocking, right? And unfortunately as well, again, racial demographic, it's mostly white respondents, 70 plus percent as well.
-
-[20:02] So there's, there's, the sample size isn't very representative, I'd say. Still interesting findings, but just those caveats are very interesting to contextualize everything.
-
-[20:10] **Carl Vitullo:** Definitely. Yeah. It's funny. The salary to gender is one of the only things I did to play with the data. So it's funny that we both went straight for that. Yeah. Also on salary on, you know, US based salary, skewing it, you know, higher, I actually was, looking at that chart, looking at the, you know, the, the quartiles and seeing that my last job, like two years ago, my last full time software tech job was like, On the very high end of that.
-
-[20:36] So it's like, Oh, apparently I kind of maxed out the scale, which is interesting because I definitely have not, I was not at the top of the scale. I, my last salary is 171, 000. Like it was good. I was very happy with it, but. I know plenty of people who are making like double that. So I was surprised as much as US salaries will skew it higher, I was a little surprised to see the absolute high end of the scale, not really represented. Do you know, just knowing people who are making that.
-
-[21:04] **Mo Khazali:** So. Fascinating. You know, you say that because again, it's relative because if you, let's say like, look at the UK, 170, 000 per year, and your yearly salary is basically the top, top, top end, like maybe top two, 3 percent of developers. in the UK. So it's, it's all relative.
-
-[21:18] Like, like you say, yes, even in the U. S. you can go much higher and then it starts to become really skewed. So yeah, very interesting, but the data is never going to be accurate.
-
-[21:26] **Carl Vitullo:** Right, right, right. Yeah, I think top of market, I don't know, Netflix intentionally tries to pay top of market. I think they're in like 350 range.
-
-[21:33] I've heard rumors, consider this a rumor, but I've heard of like super top developers at OpenAI making upwards of like seven, eight, nine hundred k, a million dollars a year salary. So yeah, high end of the scale is crazy in the US, but we can, we can bail out of demographics for a minute.
-
-[21:52] I'm going to just rapid fire some of these, some of the breakdowns, some of the analysis that I was looking at.
-
-## Vue Tops Angular for usage
-
-[21:57] **Carl Vitullo:** Vue has surpassed Angular by usage according to this survey, which caveats about sample aside is interesting. Angular definitely not loved. It had a like net unfavorable view of it. I think majority of respondents had a negative view of it. it's still in competition with Vue and React by usage, but it is substantially more negative than either of those, than either React or Vue.
-
-[22:22] Everyone still loves Svelte. It was number one by like a long shot on interest and favorability rating, but not very top by actual usage. It has been consistently, growing in usage over the years. So React is still generally positive. It's still the most positive by rank. You know, in this list, it was number one most positive, but that's been declining over the last two or three years and is very tight with Svelte right now.
-
-[22:49] The dots were like practically overlapping, like definitely within margin of error for which one was more positive. Astro topped out the list of other options, It did not make the cut to be in the main list, but one of the shout out, Astro is in contention. it was funny.
-
-## Developer Happiness
-
-[23:05] **Carl Vitullo:** The, they had a chart of happiness and generally all of the libraries people were happiest in 2018, which I just thought was funny because I tend to think of 2018 as like peak tech for, in a lot of different ways.
-
-[23:18] Like when I think of Reactiflux and its activity and its growth and its vibes. 2018 was definitely a banner year. So that seems to just generally be true across the industry. Everyone was happy in 2018 and people are less happy now.
-
-[23:31] Next usage has been growing pretty consistently for like the last four or five years by this survey. Remix has been pretty flat, which I put them in the same usage bucket. I put them in the same popularity bucket in my mind. So that was a little surprising to me. There's also, Remix had a much more negative perception than I expected. It's about even for, you know, positive and negative responses.
-
-[23:52] I love it. I thought it was great. So I'm just surprised to see that. Over the last, like, three years, testing, usage of test tools. has grown pretty significantly, whether it's Jest, or VTest, or Playwright, or Cypress. All of them saw usage go way up in the last two to three years, which is very funny because that, that tracks very well with my experience of three to four years ago, nobody was writing tests.
-
-[24:17] Just, people actually started writing tests in the last couple of years, which is funny. Yeah, Playwright versus Cypress. The vibes are supported by the data. People love Playwright. It's got really great retention. It's got really great net favorability rating. Cypress, a little bit less so. It's still very widely used, but the retention chart was much more negative.
-
-[24:39] And it's just not as well loved, which generally tracks with the sentiment that I've seen.
-
-[24:44] **Mark Erikson:** Yeah, I think I saw that Playwright Downloads had recently surpassed Cyprus's. I know I've seen a lot of mentions of companies migrating from Cyprus to Playwright. So, yeah, matches my experience.
-
-[24:55] **Mo Khazali:** We literally, this week, migrated one of our clients from Cyprus to Playwright.
-
-[25:01] So, another anecdote of how the general vibes are going in the community.
-
-[25:05] **Carl Vitullo:** Yeah, Roboto just asked in the chat, what are people's problems with Cypress? I've run into a bunch of weirdness on flaky tests and just general quirks, like the edges have been rough. I haven't really done enough with Playwright to say what's better about it, but it seems like it's based on a more stable foundation.
-
-[25:24] **Mark Erikson:** I can briefly speak to this. Cypress runs your entire test in the browser. It basically kind of like hijacks everything about the browser behavior and sort of re implements a lot of that itself. Whereas Playwright, the test is running externally. And it's sending, like, DevTools protocol commands to the browser.
-
-[25:42] CypressR also has a really weird not actually async model. The way I understand it is it actually runs through the entire test code ahead of time and collects a queued list of commands, and then it executes those later. So you can't even use, like, real async await in your test syntax, whereas with PlayWrite you can.
-
-[26:03] **Carl Vitullo:** Interesting. Yeah, because I think Cypress came out before, like, headless Chrome was a thing, because I remember they, all of the browser automation stuff from, you know, years gone by are very hacky. Like, they're scripting the browser in a just really janky way, and the browsers produced a headless variant that is more intentionally able to be scripted.
-
-[26:26] And so I'm pretty sure that Cypress predates that change, and so they had to do the hacky weird stuff, and Playwright came about after that change, and they do less hacky weird stuff.
-
-[26:36] **Mo Khazali:** There's one more thing with the Cypress, I guess, model that pushed people away in the last couple of years, which was that they basically, they, I believe they're VC backed.
-
-[26:46] They needed to find a path towards monetization. So they released a paid model where you had a dashboard on their sort of like hosted platform. And then there was free alternatives. And they were scanning your node modules. There was this thing that came up where they were scanning node modules and sort of sabotaging if you were trying to use an open source alternative to their paid platform, which people really did not like.
-
-[27:09] And there was a lot of backlash. So I think a lot of people lost a lot of trust with Cypress as well after that.
-
-[27:13] **Carl Vitullo:** That tracks. Okay. That's not great. Yep. Also in testing, the generically branded testing library is also losing ground, which I'm surprised by. I loved it. I thought it hit a really great niche between like unit tests and full end to end tests.
-
-[27:28] But I guess my thought is maybe. Playwright is now stable enough to cover that use case with less setup process. Cause it did take quite a bit of work and influenced how I developed features when I had testing library tests in place. So maybe it's a similar benefit for less work using Playwright instead of testing library.
-
-[27:49] **Mark Erikson:** It is worth noting that Playwright actually added testing library inspired APIs like get by test.
-
-[27:56] **Mo Khazali:** And I have another hypothesis to this, which is again anecdotal, but it's from working with many different sort of clients. I think it might also be market led, and the reason I say that is because end to end tests are much easier to sell to your business stakeholders.
-
-[28:10] Oh, we're running and executing the full end to end lifecycle as if it was a user, and it helps prevent bugs because you can see when a flow, a major flow is broken. Whereas Component tests, whether they're with React testing library or any other solution or unit tests, are much smaller pieces of the segment.
-
-[28:26] And I think when you're crunched for budget, but you still want to have some level of testing and confidence as a business stakeholder, you'll push your developers to do more end to end tests because they understand it more. That's my hypothesis. I've seen it more in conversations with some of the leaders and the companies that we've been working with.
-
-[28:40] **Carl Vitullo:** Yeah, that makes sense. I personally find that a benefit because it'll, testing library lets me sidestep the whole, a whole set of questions. Like how do I log in? So weird stuff like that gets easier if you strip away the, you know, the stuff surrounding the feature you want to test. And once you've just run through the interactions there, but it definitely would be easier to sell.
-
-[29:01] We're going to test the whole thing. All right. Many diversions later. So testing, State of JS. Vitest usage has really skyrocketed. It's been very impressive. Jest is still surprisingly well loved to me. Generally testing across the board, way up. Everyone is writing more tests. Moving out of tests into native.
-
-[29:20] There's generally, it looks like a lot more people are building native code. This is probably a reflection of how much work the React Native and Expo teams have done to make that feasible for people who are use, who are coming at it from web development. Like in the, you know, different runtime section of this, they had, are you using, Electron, Expo, Cordova, React Native, all sorts of things, including native mobile.
-
-[29:48] You know, just, are you building a native app? All of those are, well, all the modern popular options are way up. You know, Cordova is, you know, Declining, luckily, but React Native, Native Mobile, all of that is trending pretty way up.
-
-[30:02] One option that was brand new to me in this survey is Tauri. Looked like an option that people love for doing native stuff and wanted to shout it out.
-
-[30:11] **Mark Erikson:** Yeah, and for those who aren't familiar with it, Tauri is basically a competitor to Electron. You know, the idea is you're writing a web app that runs it runs within the desktop as a native like application.
-
-[30:22] The distinction being that with Electron, you're having to ship an entire separate standalone copy of Chrome to run your web app, whereas Tauri wraps whatever the native web view is for that platform. So, you're only shipping, say, like, A five meg set of assets instead of, you know, 150 megs of Chrome to run your couple of megs of JavaScript.
-
-[30:45] **Mo Khazali:** And just from a native app developer's purist perspective, I would, from a React natives perspective would say that's not really your native, but it's a good hybrid option, but that is just a personal thing because you're not rendering native views at the end of the day. You're rendering a web app with some connections onto the native layer APIs.
-
-[31:02] But that's generally the challenge with anything like Electron, Ionic, Capacitor, or Tauri.
-
-[31:08] **Carl Vitullo:** Yep. Into like bundling and those tools, Webpack declining sharply. Really bad compared to others, like favorability and retention and all of that. Unfortunately, the way the questions are asked is, What have you used?
-
-[31:23] So there, it doesn't have a way of capturing What people currently use versus what they have used and have switched off. So it's hard to say whether people are actually not using Webpack anymore or, and whether they've added new tools to their toolkit or whether they've replaced it, that is not a question that we can answer with this dataset.
-
-[31:42] My, my intuition, my guess here would be that a lot of people are still using Webpack professionally, still working on a project that was spun up, you know, over the last two to five years. And, you know, switching bundlers is a really challenging project with not a lot of business value. So, yeah, I, I, it would not surprise me if a lot of people are still using Webpack at work, but have stopped relying on it for projects they make on their own or for, you know, open source work.
-
-[32:10] **Mark Erikson:** Also worth noting on that, on that front, that, Create React app. There's still plenty of CRA apps out there, even though it's no longer officially maintained or recommended, and that has always used Webpack internally. And Next is still a Webpack wrapper. They've been working on TurboPack, which I think now fully supports dev mode, but I don't think it supports production builds yet.
-
-[32:33] So, Next is still wrapping around Webpack for the foreseeable future.
-
-[32:38] **Carl Vitullo:** Yeah, generally, like, ESBuild and Vite have been the big winners here as Webpack is losing usage. Rollup is going up as well a little bit, but as far as I know, that's largely used by library maintainers, not app developers. Yeah, monorepo awareness is also growing a lot.
-
-[32:55] You know, the classics from, like, Several years ago where Yarn Workspaces and Lerna, those are declining. They are not the popular options anymore, but NX and PMPM are currently the leaders there, although I'm not sure if people would answer, I'm, I'm, I'm wondering if people might've said, Oh yeah, I use PMPM when they didn't mean they use it for monorepos, that's not the primary use of PMPM as far as I know.
-
-[33:18] And TurboRepo from. Vercel is also growing, but for other runtimes, Bun is slightly more popular than Deno. Interesting to check in on.
-
-[33:27] **Mark Erikson:** Now, is that, is that in sentiment or like actual usage amounts that we know of?
-
-[33:33] **Carl Vitullo:** That was claimed usage. So people saying, yes, I have used this. More people said that for Bun.
-
-[33:39] But, who's to say if it was personal, who's to say if it was professional, playing with something is very different from introducing it in a work setting, and my intuition says that Deno is currently better positioned than Bunn to be used at work, which is a much stickier usage. Yeah, another fun stat that I caught and wanted to shout out.
-
-[33:57] 18 percent of respondents have not used any AI tools. You know, whether that's Copilot or ChatGPT or Claude. Yeah, 1 in 5 of tech people who are aware enough of the online Zeitgeist to respond to a survey have not used it at all.
-
-[34:14] **Mo Khazali:** Just another interesting fun one. Apparently, 50 percent of respondents are still using Lodash actively, which I found was interesting, but more interesting than that is the 33 percent that still use Moment, despite some of those APIs basically being available in the, in the browser APIs.
-
-[34:29] So, takes a long time to get rid of some third party libraries, it seems.
-
-[34:32] **Carl Vitullo:** Yeah, yeah, it really does. Yeah, and I wanted to shout out the 20 percent of people who responded that are still hoping for, a pipe operator and pattern matching. My heart goes out to you as one of you.
-
-[34:44] I, that's something, those are two features that I got really excited about and like. 2015 16 that we are still waiting for. So I think I'm, I think I've given up at this point. Yeah. And Mo, about, uh, on library usage, I was really surprised to see that RxJS had a lot of usage. I think of it as a niche library, but, but by survey responses, a surprisingly large number of people are making use of it.
-
-[35:09] **Mo Khazali:** That's quite interesting. I mean, the, the, the one that everyone makes jokes about is jQuery as well, which is 22 percent still, but you know, yeah, it's, it's, RxJS has always been more niche and I'm, I think it was mainly used predominantly by the Angular community, if I'm not mistaken, right? Someone from the, uh, from the comments is saying that it's still a first class tool in Angular, so that, that might check out as to why it's got such a high usage.
-
-[35:31] **Carl Vitullo:** Okay, that, that would scan. Sure, sure.
-
-[35:33] Okay. Maybe this is my React bias showing then.
-
-[35:37] **Mark Erikson:** Yeah, I mean, they've, Angular has been introducing signals within the last couple major versions as they're, they are trying to put some emphasis on that, but RxJS is still very integrated into the Angular ecosystem.
-
-[35:49] **Carl Vitullo:** Gotcha. Okay. Looking at survey respondents generally, you know, the number of people who answered like the demographic questions at the beginning versus number of people who answered, who gave any answer for what content do you consume, like 80 to 90 percent do not consume content.
-
-[36:05] Like they did not give any answer for what content do you consume, which I just think is really. I think it's an important thing to keep in mind when you're, you know, as people are saying like, Oh, you know, Oh, everyone is, everyone's talking about this. Everyone's thinking about this. So and so made a video on this.
-
-[36:19] Like, you know what? Most people didn't see it. Most people are not thinking about that. Most people aren't even aware of that. I just think that, I just think that is a great, Demonstration of like the participation inequality that happens in so many software communities, or that happens in communities generally, where like 90 percent of the people are not participating in the same way as the most active 10%.
-
-## [Dark Matter Developers](https://www.hanselman.com/blog/)
-
-[36:43] **Mark Erikson:** And I have a very specific link for that, which is Scott Hanselman's classic post on dark matter developers, people who are just going to work and doing their thing and going home, and they don't know about the Twitter discussions or what's popular or the trends. They're just doing their thing quietly.
-
-[37:01] And we don't hear about them because they're not involved in the discussions. But the
-
-[37:06] **Carl Vitullo:** That is actually specifically the target that I'm kind of going for, for this podcast. I want to be the once a month, one hour long summary of that fire hose. Like, you don't care enough to drink the entire fire hose, stick your face in front of the blast of water, but want to get the signal.
-
-[37:23] that's what I view our role here as. We pull that signal out so that you can spend one hour consuming it instead of More than that, If you, instead of it being a part time job, staying on top of the latest news, I want this podcast to be an effective way to do so.
-
-[37:37] So yeah. Hello, Dark Matter developers. All right. That is half an hour of content on State of JS, which is good because there was not a ton of, React news otherwise. So yeah, Mark, you want to take us into our lightning round links?
-
-[37:49] **Mark Erikson:** Yep. So having said that we do have a bunch of lightning round stuff to go through.
-
-## [NYT](https://open.nytimes.com/enhancing-the-new-york-times-web-performance-with-react-18-d6f91a7c5af8) and [Slack](https://slack.engineering/balancing-old-tricks-with-new-feats-ai-powered-conversion-from-enzyme-to-react-testing-library-at-slack/) update to React 18 (Enzyme to blame)
-
-[37:54] **Mark Erikson:** First off, a couple of interesting company migration blog posts. We were talking earlier about, you know, like only two thirds of respondents being on React 18 and the New York Times put up a pretty big post about how they just updated React. to React 18. Some good details on the work they had to do and some of the challenges they ran into, especially with some of their embedded interactive setups, and some information on some of the performance improvements that they saw.
-
-[38:21] One interesting note is that A lot of their work had to do with migrating from enzyme tests to React testing library. And so, on a very similar note, Slack put up a post where they said, you know, we have tons and tons of enzyme tests and we, we tried to migrate those to React testing library. And, it was so hard, we actually ended up trying to automate a lot of the conversion using a combination of AI language models and some various additional tools.
-
-[38:52] So, this goes back to the test, and to the whole test discussion. Like, tests provide value, but they're code. And code becomes legacy. And you have to update it and modernize it. And that in itself can be a real drag on trying to change things.
-
-## [Rise Tools launched](https://rise.tools/)
-
-[39:05] **Mo Khazali:** So I'll jump in with a few things. First is that Rise Tools has been launched.
-
-[39:11] So Rise Tools is created by Mike Grabowski. So Mike is the former founder of Callstack and he's been very involved in the React Native ecosystem. It's basically, it's not tied to React Native, but it's basically targeting React Native for now. It's a way to build server driven apps. It's a server driven UI app where the server controls how the UI is layouted.
-
-[39:32] And it kind of comes with all things battery included, from the server, all the way up to the React primitives, and even some more opinionated UI design systems like Tamagui if you want to use it. It's kind of evolving in a way where it ends up being a bit of a meta framework on top of a meta framework.
-
-## Mo's talk about server-driven mobile UI
-
-[39:48] **Mo Khazali:** So a meta meta framework, we're getting into that age of front end development. Um, but it's really cool. It's server driven UI is very difficult. And I talk about how difficult it is in mobile development, many places. And I did a talk recently at a meetup in Poland. So shameless plug. If you're interested to see why this is an actual challenge in the React native world, just take a look at that YouTube video and hopefully you'll get a bit of a primer.
-
-[40:11] **Mark Erikson:** Gasp! A shameless plug on this podcast. What?
-
-## [NativeWind UI launching](https://nativewindui.com/)
-
-[40:15] **Mo Khazali:** Next up, Native Wind UI is launching. So this goes very much along the same train of thought as we were having a conversation about with the state of React, where a lot of these component libraries are not popular anymore, but people want these sort of copy pastable code components that have 90 percent of the stuff there and they can modify and change it as much as they want.
-
-[40:35] It doesn't come with any behavioral APIs. It's just. UI wise, how do things look like and what do the components look like? So this is basically like Tailwind UI. It's going to be a paid UI kit, UI copy and pasteable components and templates. But I think it's interesting that the React Native community is going in this space.
-
-## [GlueStack too](https://gluestack.io/)
-
-[40:51] **Mo Khazali:** Similarly, the GlueStack team. So GlueStack is, made by the former creators of NativeBase, which was another popular UI library and. GlueStack is basically the successor to that and they initially had a more batteries included opinionated API component library that is now going seemingly in a very similar direction to native WinDUI and Tailwind UI, which is, we have these copy pastable components.
-
-[41:16] So think of it as ShadCN as well, but in the React Native ecosystem. And the lovely thing about both of these libraries is, they work universally with React Native. So if you're targeting React Native on the web, these libraries will automatically work on both web and mobile, which is really cool, and a step in the right direction.
-
-## [Swift Package manager support, moving away from CocoaPods](https://)
-
-[41:30] **Mo Khazali:** More in the React Native ecosystem, so, If you've been in this ecosystem, you'll know that typically what we use on the iOS and MacOS front is we will use CocoaPods as a dependency and package manager. Now, CocoaPods is good, it works, it's one that's been around for a while. The iOS native community is moving towards Swift Package Manager that Apple created themselves.
-
-[41:53] And so now this PR got merged, but we will have Swift package manager support for React Native. So if you want to use Swift package manager, you now have the option to do so, which is going to be great for brownfield apps. So apps that are, some parts of it are in React Native, other parts are just purely native.
-
-[42:07] This will make it much easier to adopt if you've already been using Swift package manager for your native apps.
-
-[42:11] Now, one of the things that has been a challenge with the React Native ecosystem is around out of tree platform support and how easy it is to integrate them with tools like Expo. So out of tree platforms, for everyone who's not aware, are platforms that are not iOS and Android.
-
-[42:26] So, web, macOS, Windows, AR, VR, headsets like Vision Pro, and so on and so forth. So those are all platforms that are not officially managed and maintained by Meta, but they have sort of community partners that are maintaining them. And so macOS is maintained by, uh, Microsoft. And one of the challenges there was how do you get Expo to work with it?
-
-[42:45] Because previously you would need to do it in a bare React Native app, which means you have to do a lot of the typing and the wiring and all of the infrastructure underneath it. There's this concept of config plugins in Expo, and now there's support for React native Mac OS, and people are seemingly getting ready to be able to develop desktop apps with Expo, which is really exciting.
-
-[43:03] **Carl Vitullo:** Sorry, wait, did you say that this is maintained by Microsoft?
-
-[43:06] **Mark Erikson:** Yes. Microsoft maintains the React native implementations for Windows and for Mac.
-
-[43:13] **Carl Vitullo:** Okay. Just needed to check that. Cool.
-
-[43:15] **Mo Khazali:** Yes. Yeah. this is one of the things with React Native where there's so many people involved now. It's not just Meta, it's Meta, Microsoft, Amazon, Shopify, and name a bunch of other companies.
-
-## [React Native Filament](https://twitter.com/mrousavy/status/)
-
-[43:24] **Mo Khazali:** Next up, we have React Native Filament. So, it's a hot time in the 3D rendering space of React Native. there's a lot of stuff that's happening in the last few months. React 3 Fibers suddenly got a big boost in the React Native ecosystem. More and more people are talking about it. I've seen a lot of talks in 2024 about it.
-
-[43:41] The Skia team, the React Native Skia team have also been talking about GPU and 3d rendering. So they did that at their talk in AppJS. We covered it in the podcast back in May. And so now the team at Margello have released React Native Filament. So it's a base 3d rendering engine built for React Native. The nice thing about it being C is that it works kind of out of the box for most of these native platforms.
-
-[44:02] It is seemingly, again, this is how it's marketed, is that it's basically with less than 50 lines of code for you to load a 3d model and basically have things like pan gestures, zooming, and all of that, which is really hard to get.
-
-[44:15] And you need to actually manually code a lot of that yourself. So this is really cool. We'll see how it, how it materializes and how it evolves. There's a lot of 3d libraries that are coming to fruition and you've got to choose and see which ecosystem grows. So you're basically placing bets on horses and seeing which one kicks off.
-
-## [React Native for web devs](https://expo.dev/blog/)
-
-[44:31] **Mo Khazali:** On the trend of what we talked with the state of JS and, you know, how, uh, native usage is growing, Kati Kraman from the Expo team, she's written an article, a guide to React Native for web React devs. So people that haven't been in the native space kind of understand what are the things that you need to learn sort of like a TLDR before you can start creating React Native apps.
-
-[44:51] This is amazing because frankly, this is one of the things that I always rave about and rant about, if you don't tell people about the gotchas, they'll come and burn themselves in the React Native ecosystem, and then they will hate React Native for the rest of their lives. So, I love education and good education like this, which is specifically targeted for web React devs.
-
-## [Build Windows apps from a Mac](https://devblogs.microsoft.com/)
-
-[45:09] **Mo Khazali:** And last in this React Native train, at least in this one, is that one of the things, again, with out of tree platforms, again, with the Microsoft team, is that they maintain React Native Windows. But you need to have a Windows machine to develop for React Native with Windows, which many of us don't, myself included.
-
-[45:25] I have renounced the Windows days since many, many years ago. And so it makes it really hard to build Windows apps. And I've always wanted to do it. I've got an Xbox. You can build Xbox apps with React Native using the Windows implementation, but you need a Windows machine to be able to test your apps, which kind of sucks.
-
-[45:40] So they've written an article on how you can build Windows apps, with React Native. On a Mac. The spoiler alert is that it's not straightforward, unfortunately, you have to boot up a parallel Windows machine and then sort of port forward stuff and then use it on a VM to test it out, which is not the best DevEx, but at least there is an escape hatch if you really are inclined to do so.
-
-[46:00] So hopefully that opens the doors to React Native Windows for more and more people who are using Macs as their development drivers.
-
-## [Ecosystem Performance group, e18e](https://e18e.dev/blog/e18e)
-
-[46:06] **Mark Erikson:** Changing gears entirely, we all know the jokes about how, you know, Node modules is the heaviest object in the known universe. you know, you install one package and you get 1, 500 dependencies installed as a result.
-
-[46:20] And there's a lot of factors that go into it. It's how the Node ecosystem has evolved. There's also cases where, you know, certain maintainers are obsessed with Maintaining infinite backwards compatibility instead of allowing the ecosystem to move forward with modern tooling. I've been complaining for years that surely there has to be a way that we collectively as a community could go in and start You know, removing unnecessary dependencies from popular packages and end up improving, you know, download speeds and number of dependencies for everybody.
-
-[46:52] And there's now an actual community effort to do this. It's in a group called the Ecosystem Performance Effort. And it's just a community group. They've got a Discord for discussing things and a repo for pointing things out. But it's things like, could we look at, say, the isnumber package? And find the most common parent packages that depend on it, and replace those.
-
-[47:16] And end up saving, you know, like, cutting down on dependency trees, and saving download bandwidth for everybody. I'm very, very excited to see a lot of people actually spending time and effort on this. This is the kind of grassroots, you know, like, effort that actually benefits everybody.
-
-[47:32] **Carl Vitullo:** I saw a PR specifically about inlining `isNumber`, and it did, I don't know if I quite 100 percent buy this math, but the math they did was, by inlining this package instead of installing it as a dependency, we save this many kilobytes. This module is downloaded this many times per week. You multiply those together and ergo, we are saving 440 gigabytes of bandwidth every week. I am, I wonder if that is how that shakes out in practice with like caching and stuff. But if by inlining is number, we can have 440 gigabytes less data flowing through the air. Uh, that's, that's fascinating.
-
-## [ES2024 released](https://x.com/robpalmer2/status/1806064466510897240)
-
-[48:10] **Carl Vitullo:** We have also, ES2024 has been ratified by the, by TC39. We've got the spec, which is very dense and hard to read. Fun. Rob Palmer, who's part of the team involved in that also announced it on Twitter. A lot of these are like pretty esoteric to me, like well formed Unicode strings.
-
-[48:30] I didn't know they were not well formed. Promise. withResolvers, I guess. I don't, I don't know what that is either. ResizableArrayBuffers, ArrayBufferTransfer. Two that are a little bit more salient for me is Array. GroupBy and Object. GroupBy. What a great thing to have added to the standard library. So that's nice.
-
-[48:50] There's a regex v flag for creating regular expressions with more advanced features for working with sets of strings. Yeah. Lots of stuff. We've got a new spec, nothing too exciting though.
-
-## [Memory leaks: Compiler won't save you](https://schiener.io/)
-
-[49:00] **Mark Erikson:** We've mentioned one or two different articles that looked at ways you can end up with memory leaks in React applications due to closures and how JavaScript engines actually behave, and there's, there's some discussion of what happens when React Compiler comes into play, and so the author of those posts did some more research and concluded that no, you can, you can still end up with memory leaks, even with React Compiler.
-
-[49:25] It sort of ends up in the same situation where. Capturing variables in scope, and due to the way JavaScript engines work, you can still end up with some memory leaks if you're not careful. Similarly, Jake Archibald, who's done a lot of articles and research over the years around JS behavior, also just put up a very, very similar post talking about memory leaks and garbage collection with closures.
-
-[49:46] So, this is stuff that I only sort of half understand myself. And so seeing people go into these deep technical dives to research the actual behavior is very helpful. We've also, I believe we've mentioned the new JSR package registry a couple times, created by the Deno team. And there was a video talk from, I believe, Luca, who's part of the Deno team, going into some details on You know, a lot of the stuff that I've run into publishing the Redux packages over the last couple of years.
-
-[50:15] You know, issues trying to do the publishing, various problems with npm, goes into some details on how JSR is different, how it's supposed to work, and give some examples of actually doing the publishing. I don't know how much actual usage JSR is getting, but it's nice to see people actually rethinking this.
-
-## [React Native + Flutter](https://x.com/mdj_dev/status/)
-
-[50:33] **Mo Khazali:** The next thing is just a little bit of memes. More than anything, someone has decided to post a demo of React Native and Flutter running in a single app, which is quite funny. Believe it or not, I actually have tried this about a year ago. And the reason was we had someone who wanted to migrate away from Flutter.
-
-[50:50] So out of these memes, good conversations have actually started around how you can migrate and integrate Flutter and React Native together. In the case where someone wants to move away from Flutter. And you use React Native instead, so pretty fun times.
-
-## [Bun Q3 roadmap](https://x.com/jarredsumner/status/1807731197046653438)
-
-[51:01] **Carl Vitullo:** Earlier this month, Jared Sumner posted about the Q3 roadmap for BUN.
-
-[51:06] He says it's not exhaustive. And in the replies, adds more like, Oh, maybe we'll get to this too. But new stuff they're looking, they, they want to add a full stack bundler. I'm not exactly sure what that means, but I guess it's going to have overlap with like RSPack and probably server components too. I don't know.
-
-[51:22] A text lock file. So I guess another lock file format. I don't know why we need another package dependency tool. A CSS parser? on this roadmap seem confusing to me as a JavaScript runtime. He also talks about adding V8 C API compatibility, which sure, that makes sense, I can, I can see that, and getting better snapshots and timers for the bun test and mentions that he would like to ship a Postgres client sometime this quarter, but it's not in the main roadmap post that he made.
-
-## [Learn Suspense by building a Suspense-enabled library](https://www.)
-
-[51:57] **Mark Erikson:** So, we've been talking about suspense for, what, like six plus years now, but, there's been all the confusion over, how can you use suspense? Suspense only works with, React server components, or can you use it on the client? Are you supposed to use it on the client? There was a really good post that came out recently, Learn suspense by building a suspense enabled library that goes through some of the actual mechanics of trying to build a client side lib that uses suspense.
-
-[52:24] I'll be honest, I bookmarked this one because people have been begging for suspense support for RTKQuery. I looked at the issue actually, the issue is at least three years old. So I will probably be referring to this post when we hopefully get around to doing it, maybe later this year?
-
-## Mark's talk, "Why Use Redux Today" at React Summit
-
-[52:39] **Mark Erikson:** And the obligatory self plug, so I gave a talk at React Summit last month on why use Redux today, because this is a question that gets asked all the time.
-
-[52:50] TLDR, there's a lot of reasons why people adopted Redux in the first place. Some of those reasons no longer make sense, like avoiding the legacy context API, but the architectural reasons to consider using Redux are still valid. Being able to have a centralized store, being able to see that the state changes in the dev tools, having a well documented pattern for keeping state outside the component tree, So, it's not a lot of a sales pitch, it's like half of a history lesson, and then, discussions of trade offs, because I still find myself unable to give an unambiguous sales pitch.
-
-## [Chrome collects extra data for Google websites](https://x.com/)
-
-[53:24] **Carl Vitullo:** Cool. This is sort of general tech news a little bit, but Chrome apparently gives Google properties privileged information about your system resources, which is sketchy as heck. Why does Google need to know how much CPU my computer is currently using? Anti competitive behavior. Chrome taking advantage of vertical integration to suck up more data to use for reasons. Not great. Not exciting.
-
-## [Component, composition, colocation](https://bobaekang.com/blog/)
-
-[53:48] **Mark Erikson:** There was a really good post talking about trade offs and various architectural patterns between different ways to fetch data. Do you fetch data in hooks as components render? Do you do suspense based data fetching that starts nested down in your component tree versus do you try to kick it off, higher in the component tree, say like with a route or a page loader? Some very good actual thoughts of trade offs between these different patterns.
-
-## [Secret knowledge to self-host Next.js](https://www.flightcontrol.dev/)
-
-[54:15] **Mark Erikson:** And then, there was a good article from the folks at Flight Control, where they talked about challenges in trying to self host Next. js anywhere other than Vercel. It's feasible, but you definitely have to do some extra work.
-
-[54:29] Hosting Next on Vercel is obviously the happy path, and there's some challenges to try to fill in some of the pieces that Vercel would provide for you.
-
-## [Node can strip TS types soon?](https://github.com/nodejs/node/pull/)
-
-[54:37] **Mark Erikson:** Last but not, not entirely least, a few bits of news from the Node ecosystem. Node has merged a prototype PR to strip types and allow being able to just run TypeScript files directly.
-
-[54:50] Obviously, they're not actually checking the types, but similar to like TS Node, at least stripping off the types so it can just execute the code. Very perfect concept, but they're interested in iterating on it.
-
-## [Native SQLite drive in Node](https://nodejs.org/docs/latest/api/)
-
-[55:01] **Carl Vitullo:** Yeah, there's also, there's now a native SQLite driver in Node. Like if you're, if you have Node, you can now use SQLite. Wild! Apparently this came out of As Node was adding support for more browser stuff, like, apparently, I actually didn't really know this, you can also use local storage, quote unquote, from within Node, and that is backed by SQLite, and so then they did the work, after they got local storage in there, they added on a native SQLite driver.
-
-[55:30] I have been interested in Sqlite and the opportunities that it brings for like development patterns for a while, I'm actually making use of it in a bot that we use here in Reactiflux. I have a Kubernetes cluster set up with a Sqlite database just to keep everything co located and local. So I just have to back up a file instead of having to keep a running database server somewhere.
-
-[55:52] So yeah, just seeing more motion on Sqlite and seeing it get closer to the, uh, the actual runtime is, Very cool. I think that's awesome.
-
-## [Node moving away from CorePack?](https://github.com/nodejs/TSC/pull/)
-
-[56:00] **Mark Erikson:** Then, last item. So, Node ships with the npm package manager. And you've always had to use npm to then install other package managers like yarn and pnpm globally. There's been a long running effort to give Node a way to more directly install and use other package managers automatically.
-
-[56:21] If a project actually specifies it, and that's involved Node shipping a tool called CorePack. And it's been considered experimental this whole time, and it now seems as if there's discussions about removing CorePack. from Node. Folks like the Yarn maintainer are not happy about this, and I've seen a bunch of arguing about it, even within the last 24 hours.
-
-[56:43] So, who knows where this is going to land. You know, it's not like it prevents you from using Yarn or PMP in either way, it's about ease of usability. But clearly there's a lot of both technical debate and opinionated feelings involved.
-
-[56:56] **Carl Vitullo:** Yeah, I'm surprised to see a move towards getting removed.
-
-[56:59] It seems like a very valuable thing to have. It seemed very in line with the general direction of trying to decouple NPM from Node. js. But like you said, it's, this seems to be still very early.
-
-[57:12] **Mo Khazali:** I'm also quite surprised we've started using Corepack, and I think it's actually in the interest of other package manager maintainers, but I'm surprised they have backlash, interested to definitely read more about it.
-
-[57:21] **Carl Vitullo:** All right. That is the last link that we have. Thank you everyone for joining us. We'll be back on the last Wednesday of the month here in the live stage or back in your podcast feed just as soon as we can, which will hopefully be before Monday.
-
-[57:33] **Mo Khazali:** Thank you everyone for having me. Thank you for listening on to my rambling as always.
-
-[57:37] Always a pleasure and see you all next month.
-
-[57:39] **Mark Erikson:** Likewise, my two things, I will hopefully be publishing a very, very updated version of the Redux Docs Essentials tutorial within, like, the next few days, I've been working on it all year, and I will be glad to have that done. And as I mentioned at the start, I'm looking for a new position.
-
-[57:54] So, if you have suggestions, let me know. Please contact me.
-
-[57:57] **Carl Vitullo:** We gather sources from This Week in React, Bytes. dev, React status, Next. js Weekly, the React. js subreddit, and here in Reactiflux from the Tech Reads and News channel, as well as just following a million people on Twitter and looking for articles that way.
-
-[58:11] If you see anything that it seems like we missed, definitely send us a message. An email at hello at reactiflux. com with T M I R in the subject line. That's an acronym for the show. I read every email that comes in, including spam. So I will read it, even if I don't respond to it. We actually got a tip about the RISE tools for React Native.
-
-[58:30] Thank you for sending in a tip. That's our first one. Shout out. Thank you. If this is a show that you get value from and want to support, the best way to do so is, like, subscribe. Give it a review, help us show up in discovery charts for other people, or send it to your co workers, even if that gives away the secret of how you know so much about React.
-
-[58:46] Thank you so much, see you next month.
diff --git a/src/transcripts/tmir-2024-08.md b/src/transcripts/tmir-2024-08.md
deleted file mode 100644
index d848fd9..0000000
--- a/src/transcripts/tmir-2024-08.md
+++ /dev/null
@@ -1,646 +0,0 @@
----
-title: "This Month in React, August 2024: Matt Pocock taught us to make modules, RN is faster, iterator helpers are cool, JSR/Deno going sour"
-date: 2024-08-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-### Main Content
-
-- [[00:56](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
-- [[01:53](#react-19-progress)] React 19 progress:
- - [Initial “Suspense sibling pre-rendering” implementation work](https://github.com/facebook/react/pull/30800)
- - [DevTools support for Server Components](https://github.com/facebook/react/pull/30684) and [Viewing Source of Server Components](https://github.com/facebook/react/pull/30798)
-- [[05:23](#react-native-075)] [React Native 0.75 released](https://reactnative.dev/blog/2024/08/12/release-0.75)
-- [[07:30](#how-to-create-an-npm-package)] [How To Create An NPM Package | Total TypeScript](https://www.totaltypescript.com/how-to-create-an-npm-package)
- - [[08:13](#httpsblogisquaredsoftwarecom202308esm-modernization-lessons)] [Blogged Answers: My Experience Modernizing Packages to ESM](https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/)
-- [[10:36](#implementing-react-from-scratch)] [Implementing React from scratch](https://www.rob.directory/blog/react-from-scratch)
- - [Didact - build your own React](https://pomb.us/build-your-own-react/)
- - [Getting Closure on React Hooks](https://www.swyx.io/hooks)
-- [[12:04](#vercel-adds-retention-periods)] [Configure retention periods for deployments – Vercel](https://vercel.com/changelog/configure-retention-periods-for-deployments)
-- [[13:03](#waku-021-adds-server-actions-support)] [Waku 0.21 includes React Server Actions support](https://waku.gg/blog/server-actions-are-here)
- - [React Beyond the Render](https://playfulprogramming.com/collections/react-beyond-the-render)
-- [[14:35](#redux-essentials-tutorial-updated)] [Redux Essentials tutorial updated](https://redux.js.org/tutorials/essentials/part-1-overview-concepts)
-- [[17:46](#ts-56-rc)] [Announcing TypeScript 5.6 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-rc/)
- - [[18:31](#httpsgithubcomtc39proposal-iterator-helpers)] [Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers)
-- [[19:17](#expo-dom-released-)] [Using React DOM in Expo native apps](https://docs.expo.dev/guides/dom-components/)
-- [[24:51](#nitro-modules)] [NitroModules](https://x.com/mrousavy/status/1821165226546323930)
- - [Comparing to ObjC Turbomodules, it is significantly faster](https://x.com/mrousavy/status/1821651719945953309)
-- [[29:53](#jsr-and-deno-final-review--)] [JSR and Deno: Final Review 🚮 – David Bushell](https://dbushell.com/2024/08/09/jsr-and-deno-final-review/)
- - [What Deno Got Wrong About HTTP Imports](https://deno.com/blog/http-imports)
- - [The Deno Package Paradox – David Bushell](https://dbushell.com/2024/08/05/the-deno-package-paradox/)
-- [[35:45](#2024-stack-overflow-developer-survey)] [2024 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2024/)
-
-### ⚡ Lightning round ⚡
-
-- [[39:53](#cocoapods-going-into-maintenance-mode)] [Cocoapods going into maintenance mode](https://blog.cocoapods.org/CocoaPods-Support-Plans/)
-- [[34:30](#web-infra-devrslib-the-library-build-tool-powered-by-rsbuildmove-this-httpsgithubcomweb-infra-devrslib)] [web-infra-dev/rslib: The library build tool powered by Rsbuild.](https://github.com/web-infra-dev/rslib)
-- [[41:07](#accident-forgiveness--the-fly-blog)] [Accident Forgiveness · The Fly Blog](https://fly.io/blog/accident-forgiveness/)
-- [[42:17](#spatial-compute)] [spatial compute](https://sunilpai.dev/posts/spatial-compute/)
-- [[43:25](#how-airbnb-smoothly-upgrades-react)] [How Airbnb Smoothly Upgrades React](https://medium.com/airbnb-engineering/how-airbnb-smoothly-upgrades-react-b1d772a565fd)
-- [[44:34](#use-useid-instead-of-hand-making-ids)] [Use useId() Instead Of Hand-Making IDs](https://reacttraining.com/blog/use-useid-instead-of-hand-making-ids)
-- [[45:42](#common-sense-refactoring-of-a-messy-react-component)] [Common Sense Refactoring of a Messy React Component](https://alexkondov.com/refactoring-a-messy-react-component/)
-- [[46:20](#introducing-structured-outputs-in-the-api)] [Introducing Structured Outputs in the API | OpenAI](https://openai.com/index/introducing-structured-outputs-in-the-api/)
-- [[47:42](#httpsblogsentryiosentry-is-now-fair-source-sentry-is-now-fair-source)] [Sentry is now Fair Source](https://blog.sentry.io/sentry-is-now-fair-source/)
- - [Fair Source Definition](https://fair.io/definition)
-
-### Quick hits
-
-- [[50:51](#job-market)] Job market
- - [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE)
- - [Layoffs.fyi](https://layoffs.fyi/)
-- [[52:06](#new-releases)] New releases
- - [Material UI v6 is out now 🎉 - MUI](https://mui.com/blog/material-ui-v6-is-out/)
- - [Tauri 2.0 Release Candidate](https://v2.tauri.app/blog/tauri-2-0-0-release-candidate/)
- - [Nx 19.5 is here! Stackblitz, Bun, Incremental Builds for Vite, Gradle Test Atomizer](https://nx.dev/blog/nx-19-5-adds-stackblitz-new-features-and-more)
-- [[54:20](#upcoming-conferences)] Conferences
- - [React Universe 2024](https://www.reactuniverseconf.com/) Wrocław, Poland Sept 5-6
- - [JSConf Chile](https://www.jsconf.cl/) Santiago, Chile Sept 5-7
- - [UtahJS Conf](https://utahjs.com/conference) Salt Lake City, UT, U.S.A. Sept 13
- - [React Alicante](https://reactalicante.es/) September 19-21
- - [JSConf Ireland](https://www.jsconf.ie/) Dublin, Ireland & Online Sept 25-26
- - [SquiggleConf](https://2024.squiggleconf.com) Boston, MA USA Oct 3-4
- - [RenderCon](https://www.rendercon.org) Nairobi, Kenya Oct 4-5
- - [React India](https://www.reactindia.io/) Goa, India Oct 17-19, 2024
- - [React Brussels](https://www.react.brussels/) Brussels, Belgium Oct 18
- - [React Advanced London](https://reactadvanced.com/) London, UK Oct 25, 28
-- [[57:09](#outro)] Outro
-
-**Carl Vitullo:** Hello folks, welcome, thanks for joining us. This is the August edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. We're supported by Infinite Red, a consultancy that exclusively works in React Native. but more on them later. [00:22]
-
-Hello, I'm Carl. Uh, I'm a staff product developer and freelance community manager, here at Reactiflux mostly, where I run community programs like these events and the star helpers, and build tools to help keep the community operating. [00:34]
-
-**Mark Erikson:** I'm Mark. most people know me as the Redux maintainer or that guy with the Simpsons avatar, and I am currently an engineer at Replay. [00:42]
-
-**Mo Khazali:** And I am Mo. I head the mobile team at Theodo, which is another React Native and just generically tech consultancy. I'm also the organizer of the React Native London community and super excited to be here as always. [00:56]
-
-## Sponsored by Infinite Red
-
-**Carl Vitullo:** We are brought to you by Infinite Red, our main sponsor right now. They are an expert React Native consultancy that I am quite pleased to be a partner with because they are like authentically showing up to support the React Native and React ecosystems in like really meaningful ways. [01:12]
-
-They organize conferences, they host the largest React Native podcast, they publish the largest React Native focused newsletter, and they're Just really excited to work with them. Other than being great people who do great things in the community, they also, well, more precisely, they're a team of about 30 people, mostly developers with mostly greater than 10 years of experience. [01:33]
-
-So they actually work with your team to help you develop an expertise in building React Native. So if you are. Building something with React Native and need a little help hitting the ground running on that, definitely reach out to them because they are great people who will help you do good work. Cool. [01:51]
-
-All right. Mark, you want to start us off? [01:53]
-
-## React 19 progress
-
-**Mark Erikson:** So, last couple sessions, we talked about how React 19 had been delayed due to what has been known as Suspense Gate, where the React team had made a change last fall to pre rendering behavior for multiple nested suspense components. [02:07]
-
-So that instead of doing them in parallel, it effectively does them in serial. And people complained and said, we rely on these existing behavior, you're going to make a number of people's apps slower. And there was an outcry, and the React team had been ready to release React 19, and instead they backed off and said, "okay, yes, we see this is a big deal, we are going to figure out how to change the behavior." [02:30]
-
-But, the original PR that got merged was pretty complex, they've continued iterating on the internals. So it's not nearly as simple as revert the PR, it's we need to iterate further on the internals and figure out how to re implement some of the older behavior on top of the newer code changes. [02:48]
-
-### https://github.com/facebook/react/pull/30800
-
-**Mark Erikson:** There's been a thread where people have been trying to ask for updates, and the last comment in that thread a few weeks ago was, well Stay tuned to this thread for updates, but no indication of actual work. And so finally, within the last week and a half, I've seen a couple PRs where there is actual evidence of work being done on this. [03:07]
-
-Uh, Andrew Clark filed one PR that's added a feature flag that would later be added to gate this upcoming work. And then he just put up a PR a couple days ago with what looks like the initial implementation work for this Suspense sibling pre rendering behavior. I'm not sure if it's basically just this one PR, if he's working to split it into further PRs, or what the actual status is, but there is an actual PR with actual progress, and no idea how long it'll be before that gets merged, how long things will stay in beta or RC, but there is public evidence that they are actually pushing forward on this, and if you look at the code, you can see some of the complexity of the implementation work, like it's not just You know, one flag that gets turned on and off. It's a bunch of additional logic internally to make the older behavior possible. [03:57]
-
-### https://github.com/facebook/react/pull/30684
-
-And meanwhile, I've been very interested in this part. Sebastien Mårkbage had been spending, you know, really most of his last couple of years working on the server side aspects of React. Server components and a lot of the HTML, you know, related pre rendering work, but he's actually turned his attention to the React DevTools in the last month and a half. [04:17]
-
-And he's just been putting up a whole series of PRs, refactoring the guts of the React DevTools and making a whole bunch of improvements. And so two of them in particular, he's actually implemented what looks like React DevTools support for showing server components as part of the tree in the React DevTools. [04:37]
-
-### https://github.com/facebook/react/pull/30798
-
-**Mark Erikson:** And along with that, what looks like a feature for being able to view the source of server components from React DevTools on the client side. This is something that I had always wondered, like, when are they going to get around to doing this? Like, we've supposedly shipped this production ready feature, and yet there's no way to really debug or view server components. [04:56]
-
-So to me this is a pretty big deal. [04:58]
-
-**Carl Vitullo:** Yeah, definitely. Dev tool support has always been so good in React that calling it, you know, production ready when there isn't that dev tool support seems a little surprising. So yeah, cool to see that coming. I'm a little surprised to see that they are actually able to get like the source of server components into the client seems cool. [05:16]
-
-That PR is only a hundred lines added, 35 lines removed, so that seems very easy if they had a lot of support. [05:23]
-
-## [React Native 0.75](https://reactnative.dev/blog/2024/08/12/release-0.75)
-
-**Mo Khazali:** So, next up, React Native version 0. 75 has been released. Now, this has been one of the most sort of subtle and quiet releases of React Native I've seen in a very long time. There's a lot of sort of minor improvements under the hood that's happened. [05:37]
-
-The first thing is that we have a new version of Yoga. So, Yoga is the layouting engine in React Native that basically handles Your JavaScript code being translated to native layer drawing on the canvas. And so it's now got support for, so, so recently a couple of versions ago, we got support for gap when you're dealing with flex like layouting, and now there's also percentage value support for for GAP as well. So it's getting closer and closer to what you can do on the web. Another sort of update within this version is that you've got new architecture support that's getting more and more mature, and so you see that some of the libraries that previously didn't have new architecture support are getting more and more. [06:12]
-
-Positive support within the new architecture paradigm. And also, um, what you see is that tools where you can see the list of dependencies that you have now also mark whether or not new architecture is supported within it. It seems like we're kind of gearing towards finally having the new architecture as a default with the next release of React Native, which would be a pretty big deal. [06:31]
-
-But again, we've been saying that for a little while, so I'm not holding my breath, but I'm very, very cautiously optimistic about that. And then the last big thing within this version is that a couple of versions ago, again, they announced that you should use a framework and they suggested Expo as kind of the only option really that's, that's available currently. [06:46]
-
-And so we see a few movements that are coming out of that announcement. One of which is that the CLI tool React Native init is now being sunsetted in some capacity and moved to a community CLI. So. By the end of the year, so December 31st onwards, when you run the commands react native init, they just will no longer work, um, and you'll be guided either to use expo or to use the community fork of the CLI that will be maintained by the community. [07:11]
-
-But this is kind of a, let's just move it to the side. And wait for it to reach its demise type of thing. Which is, that's fine. That's kind of the direction that it's going towards. But it's just something to keep in mind though. [07:21]
-
-**Carl Vitullo:** Yeah, sure. Shades of create react app sunsetting. Commonly used tool that's just gonna slowly fade away. [07:28]
-
-**Mo Khazali:** Yes, exactly. Very much so. [07:30]
-
-## [How to Create an NPM Package](https://www.totaltypescript.com/how-to-create-an-npm-package)
-
-**Mark Erikson:** Alright, Matt Pocock, who's probably best known for a lot of his articles and courses on how to use TypeScript properly, has actually put together something adjacent and published a very long, detailed article on how to properly create and publish a package on NPM. This is an extremely detailed and very step by step guide that goes all the way from, you know, literally create a new Git repo to creating a package. json file, some of the fields you would want to define in there, setting up tools like TypeScript and Prettier, and one of the more complicated pieces, how to actually define the JavaScript files that are used in terms of the package exports. [08:13]
-
-### https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/
-
-**Mark Erikson:** Now, I spent a very large portion of 2023 trying to figure out a lot of this stuff for myself, because in today's JavaScript ecosystem, figuring out how to publish packages that properly support things like both ES modules and common JS modules is an absolute nightmare. [08:32]
-
-And there's all kinds of different permutations and different runtimes and environments and other things that you're going to run into. This guide isn't going to cover every different use case you'll run into, but it is a very, very good detailed look at a lot of the common things you would want to do to set up a reasonably standard package setup in today's environment. [08:52]
-
-So definitely worth looking at. [08:53]
-
-**Carl Vitullo:** Yeah, definitely. I have needed something like this many times. I've always kept track of generally each change in the ecosystem, but then when I, you know, actually sitting down and needing to write a new package and remembering which changes happened, what the current state of the best practice for setting up a new package are is always Very difficult. [09:12]
-
-So I'm really excited to have this. It's, I think your post from 2023 was like the first time I had seen somebody try to articulate what best practices for publishing a, you know, like professional quality NPM module looked like, and it's so weird. It's gotten so strange. [09:29]
-
-**Mark Erikson:** It is so painful and so bizarre. [09:31]
-
-Now I will, I will say I will say like a lot of the pain comes from Node, not allowed to import CommonJS into ESM, I can never remember which way it is. Um, like, you could do A into B, but not B into A. I just don't remember which way the limitation was. But the last couple versions of Node 22, I believe they've finally started to implement valid support for going both ways without any errors. [09:59]
-
-I can't remember if it's behind a flag, but at some point that version is going to become widely used enough that we can maybe, in five years, start to go past this. [10:10]
-
-**Carl Vitullo:** Hopefully. Yeah, I had actually just seen a tweet somebody put out complaining about a similar thing where, I think they called it a cardinal sin of CommonJS, but it was conditional exports. [10:20]
-
-You could put what you exported behind a flag. [10:23]
-
-**Mark Erikson:** Yeah, I think that was probably Ketanaito, the author of MSW. [10:27]
-
-**Carl Vitullo:** Correct. Arya in the chat saying, can't import ESM from CommonJS, but can import CommonJS from ESM. [10:35]
-
-**Mark Erikson:** Yep, that sounds right. Yep. [10:36]
-
-## [Implementing React from Scratch](https://www.rob.directory/blog/react-from-scratch)
-
-**Mark Erikson:** So I've always been a very big fan of articles that try to build a miniature version of a real library from scratch and kind of walk you through, here's the kind of functionality, here's what it actually looks like internally. Here's some of the pieces that you might consider. These are really, really good for both understanding the mental model and you know, kind of peeling away the black box and like understanding what's actually going on inside of these libraries. So I've seen a few different good articles along that line for both, you know, React and Redux and, and, you know, bundlers and other tools over the years. [11:11]
-
-So someone named Robbie Prusin just put out a really, really good new example of this implementing React from scratch that walks all the way through the process of creating elements um, modifying the DOM, putting, and putting all the pieces together. Really, really good post. Definitely recommended. And so, along that line, two other earlier posts that I'd recommend. The one I've pointed people to for me, for years, was from Rodrigo Pombo back in 2019, Build Your Own React. And then swyx has a classic post on how React hooks work by building your own version of hooks in 30 minutes. [11:45]
-
-**Carl Vitullo:** Yeah, also a huge fan of this kind of, like, first principles, understand how it works by making your own miniature version of it. Reminds me of, like, in the physical world, building a model. You're not going to use it for something for real, necessarily, but this gives you a really clear mental model of what's going on under the hood. [12:04]
-
-## [Vercel adds retention periods](https://vercel.com/changelog/configure-retention-periods-for-deployments)
-
-**Carl Vitullo:** I'm going to throw this in. This is maybe a lightning round tier post, but I'll show you right now. Vercel announced that they are going to allow you to configure retention periods for your deployments. I saw Guillermo Rauch post on Twitter about this and saying it was something that people have been requesting since he released, now, the precursor to Vercel. [12:25]
-
-So this is a feature that goes back nearly 10 years of people requesting it. And just like generally, retention periods, I feel like they're underrated. I feel like they're super powerful and just really good for a lot of things. Being able to configure how long data sticks around, I think, is a bit of a superpower. [12:42]
-
-It's one of the things that, like, once you figure out how to make use of it, it just lets you do a lot of really good, powerful things. I have an affinity for them because my first full time job was doing tech support for a backup server, and so learning retention periods and how the retention policies were structured was a big part of my early tech career. I think it's cool. It seems good. [13:03]
-
-## [Waku 0.21 adds Server Actions support](https://waku.gg/blog/server-actions-are-here)
-
-**Mark Erikson:** All right. So we're continuing to see folks try to work on building out React server component support in various frameworks. Uh, you know, Redwood's done some work. The remix folks are trying to work on things and one framework that's been plugging away kind of quietly is Waku, which is the brainchild of Daishi Kato, the author of Jotai and Valtio and maintainer of the Zustand library. [13:27]
-
-They have just released version 0. 21, which now includes support for server actions. We're still at a point where Next is really the only, like, full, you know, quote unquote, production ready implementation of React server components and server actions. But it's good to see that other frameworks in the ecosystem are getting closer. [13:47]
-
-While I don't know the overall status of WACU, like, it feels like it's starting to get a lot of the pieces fleshed out. And, you know, worth at least looking at. I mean, probably not ready to use in production yet. But it's an alternative approach to server components that'd be worth investigating. [14:02]
-
-**Mo Khazali:** Quite interesting that on their website, when you scroll down at the very bottom, it has a big sponsored by Vercel. Which seems quite funny, given that it's somewhat a competitor to Next in some capacity. [14:13]
-
-**Mark Erikson:** I was talking with Tanner Linsley and he said that like, Vercel has actually been doing a lot of work to both, like they, they sponsored, React Rally, the conference at the last minute, and they're even sponsoring some of the work on TenStack Start, I believe. [14:24]
-
-**Carl Vitullo:** Yeah, they are definitely all over the place sponsoring all sorts of stuff. So I guess they're just generally investing in the React ecosystem. Here for it. Let's distribute VC money. [14:34]
-
-**Mark Erikson:** Yeah, very much so. [14:35]
-
-## [Redux Essentials tutorial updated](https://redux.js.org/tutorials/essentials/part-1-overview-concepts)
-
-**Mark Erikson:** Okay. Next up is an item that is very near and dear to my heart because this has taken me like the entire calendar year in one form or another. [14:44]
-
-In fact, I think I actually published this, might've even been like the day after our last recording in July, but you know, hey. So Redux Toolkit came out in the fall of 2019. In the first half of 2020, I wrote a brand new tutorial for the Redux docs that I dubbed the Redux Essentials Tutorial. [15:02]
-
-And it was about 25, 000 words, and it covered how to use Redux Toolkit to build a plausibly realistic example app. And it taught Redux Toolkit for the first time as the default way to use and build Redux applications. And so that has been the primary Redux tutorial for the last four plus years. [15:23]
-
-But it was starting to get a little bit outdated in a couple ways. While I still think that the original version of the tutorial was, frankly, a really good piece of work and something I'm very proud of. I saw in retrospect that I could have done a better job explaining various, you know, Redux concepts. So, at the start of this year, I set out to do a pretty thorough modernization and update pass on that tutorial. [15:46]
-
-I did the work to convert the existing example application to TypeScript. Start to finish every single commit. And then I added some additional features and examples to demonstrate newer Redux Toolkit features that did not exist in 2020. From there, I went through and did a very thorough update on all the content. [16:06]
-
-Improved a lot of the explanations, moved pieces around. Ended up adding about 9, 000, close to 10, 000 words of overall content, not counting the content that got changed and shifted and moved around. So, a month ago, I published the finished update to this Redux Essentials tutorial. So, it is now TypeScript start to finish. [16:27]
-
-Which is something I spent a lot of time, I had spent time debating it out in the past. You know, I've always been concerned that adding TypeScript into the mix this early is going to add more learning overhead. [16:38]
-
-And that's still the case. But ultimately TypeScript adds so much benefit, and it's how we want people to learn. to use Redux, that I decided it was worth it to just do the whole tutorial in TypeScript all the way through and try to explain the pieces as I went. So, it's live, uh, it's now up to like 50, 000 words, it is incredibly comprehensive, covers effectively all the APIs in Redux Toolkit and explains Enough about how things work that you can follow through and use it and understand most of the why. [17:11]
-
-It doesn't go into how things work internally. For that, we still have kind of the lower level Redux fundamentals tutorial that explains, you know, like, how does a Redux store work, or how do some of the pieces connect together. But this is the way we want people to use Redux, and, you know, I'm pretty I'm biased, but I think it's the best way for people to learn Redux. [17:32]
-
-So I am very excited to have that out. It took me multiple months of effort to try to put that together. [17:38]
-
-**Carl Vitullo:** Nice. Cool. 50, 000 words. You could sell that as a book. [17:42]
-
-**Mark Erikson:** Pretty much. [17:43]
-
-**Carl Vitullo:** all right. I will pull us onto our next one. [17:46]
-
-## [TS 5.6 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-rc/)
-
-**Carl Vitullo:** TypeScript 5. 6 has a release candidate. Seems cool. Just going to call out a couple of cool things. [17:52]
-
-Something that caught my eye was the disallowed nullish and truthy checks. It's practically a linting rule, really. It just helps catch stuff that are pretty obviously bugs. Like, a good example they called out was if you accidentally switch the equals and the greater than in the, you know, trying to do a greater than equal comparison. [18:10]
-
-Oops, that's an arrow function, which is always going to be truthy. And so now TypeScript will give you an error for that. This expression is always truthy, you probably didn't mean to put that in an `if`. That just seems pretty useful. They talk a bit about other situations where they do allow, you know, constant expressions, but truthy expressions will now warn, which seems really great. [18:31]
-
-### https://github.com/tc39/proposal-iterator-helpers
-
-**Carl Vitullo:** I also liked the iterator helpers. It looks like they're pulling in a stage three proposal for, you know, ECMAScript, JavaScript, which I'm a little surprised by. You know, I, I thought that they generally wait for things to ship. [18:43]
-
-**Mark Erikson:** Stage three has usually been their target. [18:45]
-
-**Carl Vitullo:** Yeah, okay, cool. Good to know. But yeah, iterator helpers, it looks like that feature generally looks to be a recognition that people want to use iterables as if they were arrays, and so it adds a lot of array type, you know, functions to iterables. [19:01]
-
-So you can do things like map and filter and things like that on them. So that's super great. I'd love to see TypeScript adding support for that because that looks really great. I have tried to do that a number of times and been really annoyed that I had to spread it into an array first before using map. [19:16]
-
-So that's, I'd love to see it. [19:17]
-
-## [`expo-dom` released ](https://docs.expo.dev/guides/dom-components/)
-
-**Mo Khazali:** So, let's switch gears a little bit into some React Native news. So, a couple of cool things. First off, Expo DOM has been announced. So, now you've got a whole bunch of different ways to do code interoperability between web and mobile, uh, and all things in between. So, you now have React Strict DOM, there's React DOM, there's Expo DOM. [19:36]
-
-It's getting very confusing very quickly. But, really, the gist of all of this is, Expo's been really pushing this narrative of you want to be able to use a single code base to target web and mobile at the same time. Part of the challenge that will come up with a lot of people will be, well, I already have my web code base and I already have my React Native code base and combining these two together is going to be a bit of a tough egg to crack when you're dealing with a massive length in migration. [19:58]
-
-This is one of the things that they want to target with this, which basically is that they want to allow you to use DOM Primitives directly within, your React Native applications. So you put a use DOM directive at the very top of your file, and then that basically means you can start using DOM in there, and what it does under the hood is it basically constructs a web view and renders those DOM elements instead of real native elements. [20:17]
-
-Now this is quite powerful because it kind of means you can mishmash a little bit of DOM in places where you already have some code that's using React DOM inside of a React Native code base. And in theory, if your code is responsive and behaves well on mobile web, then it'll kind of work as you expected within your React Native app. [20:33]
-
-There is a lot of disclaimers within this in terms of how your data flow works and all of the different things that come with that, you can't, you know, render children within it. It's very primitive rendering at the moment. But, it's a path towards migrations, if you so need it, desperately. It's not a long term thing, I think it's a very short term, temporary, here's how we just get a fully functioning app out in the meantime while we slowly add native views into our application. [20:56]
-
-**Carl Vitullo:** Ah, interesting, okay. This is a stopgap they're not necessarily looking to have people build full React Native applications using web primitives. [21:06]
-
-**Mo Khazali:** Thanks. It's more of a migration thing. So, you know, I've worked on a number of apps. In fact, I'm working on one right now where it's a hybrid app. [21:13]
-
-A lot of companies will have hybrid apps where they have some of it in React native, that's native views. Some of it are web views and you have to use a web view inside of the native app to render some of the screens because, you know, they didn't have the time to build that out in a native fashion. So this is kind of just streamlining that process a little bit. [21:28]
-
-I think it's just to try to entice people to come over to the dark side of the native world, and then hold them hostage afterwards. Jokes aside with all of this though, I think it's a, it is a migration path. It is very experimental, it's nowhere near production ready, it's just being brewed as we speak this month, um, and they've released a bunch of demos and it's now officially on their docs, but it's very much with all of the disclaimers of you shouldn't use this yet. [21:49]
-
-And it comes with a whole bunch of limitations. [21:50]
-
-**Carl Vitullo:** Reminds me of Cordova and things like that. I'm a little surprised to see Expo doing something along those lines. I thought we had generally agreed that just like flapping a web view in a native app was not great, but okay, cool. [22:01]
-
-**Mark Erikson:** So just to make sure I follow the technical train here. [22:03]
-
-So roughly speaking, you write a line or two of code that looks like it's just rendering. Another React component, but under the hood, it's actually creating a whole web view, attaching it to the native layout, injecting the JavaScript code into the web view, and then actually rendering a web component, a React DOM component inside of that, right? [22:24]
-
-**Mo Khazali:** Exactly. That is exactly what it's doing, yeah. Layers of abstractions on top of layers of abstraction. So I think this will be around as a migration path. I think this is a small side project that they're just whipping up to make it easier for people to adopt the universal app paradigm, which is, you know, I want to have a single code base for all of my platforms. [22:40]
-
-I think you really want to focus on React strict DOM if you're thinking about the long term of your app, if you want to go down the route of having a universal app. This is just a temporary stopgap if you happen to have code in the web world that you want to easily use and migrate over to the native world. [22:56]
-
-**Carl Vitullo:** Sure. Yeah, right. I guess I still had the strict DOM in my head as you started talking about this and it threw me off. Definitely a, uh, a subtle but significant boundary between those things. Okay. Interesting. [23:08]
-
-**Mark Erikson:** And to recap for people who might not have listened to the last couple, last few episodes, React strict DOM, on the other hand, is adding more web like API capabilities to the React Native platform. [23:19]
-
-So you write more code that looks like React DOM for the web, and it makes your React Native code basically read as if it were web code. [23:27]
-
-**Mo Khazali:** Because the, the current status, and I guess maybe going a little bit further back into the context of this, we've had React Native Web for a long time, which allows you to basically take React Native code and run it through almost like a translation layer, uh, with almost like an interoperability layer that lets you render those native views and native texts on the web. [23:44]
-
-So this is, this has been around for years. It's like pretty much been there since the launch of React Native a few months after they kind of, somebody launched this project who now works at Meta. But that was a very big bloated piece of, of a dependency that you would add to your web app. So then React Strict on was like, can we, can we kind of find a way that's in the middle that uses the web based APIs, also makes it easier for web developers to come into the React Native world, translates them down to native views. [24:06]
-
-But also has a minimal overhead to use that same code on the web. And so, this is pretty much the exact opposite of that, but it's sort of a temporary stopgap. [24:15]
-
-**Carl Vitullo:** Yeah, interesting. Okay, so if, like, React Native Web from, you know, ye olde days was asking web developers to write code like React Native developers And React strict DOM is allowing web people to write what looks like web code, [24:31]
-
-**Mark Erikson:** Native code that looks like web code. And then this is this, eh, let's just shove a web view in the middle of our, all of our native views. [24:38]
-
-**Carl Vitullo:** They're covering all their bases. They're trying everything and seeing what works best. Cool. All right. [24:43]
-
-**Mo Khazali:** Where there's a will, there's a way. [24:45]
-
-**Carl Vitullo:** We've got a lot of wills going on. [24:48]
-
-**Mo Khazali:** There's many wills going on here. [24:50]
-
-**Carl Vitullo:** Neat. Very neat. [24:51]
-
-## [Nitro Modules](https://x.com/mrousavy/status/1821165226546323930)
-
-**Mo Khazali:** Let's move on to Nitro modules because this has been a big thing in the React Native ecosystem in the last month. Again, a little bit of context because I think this will help everyone kind of understand and set the scene. So, a few years ago with the old architecture, when you wanted to access native layer code, you would need to use a native module. That used something called the bridge and the bridge would basically serialize some JSON or some, some sort of JavaScript objects, send it across a bridge as we like to call it. And that data could be used by the native layer to be interacted and run some native operations. And that's how sort of the JavaScript layer and the native layer used to communicate with each other. [25:23]
-
-That bridge caused a lot of issues because you had sort of this one pathway to communicate between the native layer and the JavaScript layer and it caused slow apps and many issues and a lot of library maintainers were incredibly frustrated because it meant that if you use their library in a certain way, it would completely bog down people's apps and they were getting a bunch of issues around how their library is slow or React Native in general as being slow. [25:43]
-
-So then the new architecture tried to create a better way to interact between the JavaScript layer and the native layer. And so that's where TurboModules came into place. So the idea with TurboModules was you would create a TypeScript interface to define the type of functions and values that you want to communicate between the JavaScript layer and the native layer. Then it would run through some C code gen to generate the connection layer between the native layer and the JavaScript layer. And then you could write native layer code and use that with what they call turbo modules, which was the name for it. [26:13]
-
-That was a much more neat and streamlined way to communicate between the JavaScript layer and the native layer. That's a massive step up from the old architecture, and now Mark Roosevee, who is one of the sort of like people in the React Native ecosystem who's known to create some really cool native layer libraries that work really well, has now been playing around with this idea of creating an even faster way to communicate between JavaScript and the native layers and to write native layer code as, as a React native developer. [26:39]
-
-And he's calling it Nitro Modules and he's created a lot of fun puns out of them. For example, if you wanted to generate a Nitro Module, you run Nitrogen, which is, uh, quite fun. Um, [26:49]
-
-**Carl Vitullo:** Oh, my god. [26:50]
-
-**Mo Khazali:** It's great. [26:51]
-
-There's, this isn't really public at this, it's not very clear a lot of the stuff that works under the hood. I think it's getting released and drip fed as we kind of speak this month, but just some comparisons that he's run with Objective C based turbo modules compared to Nitro modules is that it's apparently like 10x faster, so 220 milliseconds in a benchmark that he ran versus 20 milliseconds. There's also another way that the Expo team have created Expo modules. [27:16]
-
-We're going, we're seeing a trend here, right? Like the React Native Ecosystem likes to invent and reinvent different ways of doing the exact same thing, whether it's with the strict DOM stuff or with this, but anyway. So then you've got Expo modules, which is slower to Turbo modules. And then now there's Nitro modules, which is apparently the fastest of them all. [27:31]
-
-So we'll see how this plays out. It's yet another approach of trying to handle this native to JavaScript communication. We'll see if it, if it actually pans out and how it, how it goes on, but promising signs at the beginning, and a lot of people seem very excited about it. [27:43]
-
-**Carl Vitullo:** Yeah, super neat. Throwing a bunch of shit at the wall and seeing what sticks, trying a bunch of different approaches. [27:49]
-
-I feel like that naturally flows out of where React Native sits in the world because it has iOS, Android, web, macOS, Windows, well, you know, it gets touched by so many different developers. And so I feel like where web and React can get a little bit like monoculture a little bit just because it's, you know, there's the one true way of doing it, but I feel like that sort of variety of approaches maybe flows a little bit more naturally out of React Native as a kind of a, I don't know, kind of a natural melting pot of developers. I appreciate that. [28:21]
-
-**Mark Erikson:** Polyglot development. [28:22]
-
-**Carl Vitullo:** Yeah, sure. [28:23]
-
-**Mo Khazali:** It feels like React in the early days, rather than what React is today. [28:26]
-
-Like, I've been in between the web and the mobile ecosystem. And, you know, I feel like the React ecosystem has reached a point of maturity, and there's less experimentation going on, it feels. Whereas with the React Native ecosystem, there's a bunch of people working on 3D rendering at the same time, and then there's a bunch of people working on web support at the same time, and then there's a bunch of other people working on native to, you know, JavaScript interfacing all together. I think it brews, a healthy amount of competition to try to get the best solution out of there. [28:52]
-
-**Carl Vitullo:** Yeah, thriving ecosystem in the biological sense. It's uh, evolution, survival of the fittest, many, many competing strategies and competition with each other. It's cool to see work on the bridge happening, because, I haven't done a ton of serious development with React Native, but that has always been a huge bottleneck. [29:10]
-
-I mean, you know, anytime you have a lot of data flowing through one thing, like, it's gonna be a challenge, it's gonna be a limiting factor if it's not fast. Interesting to see this come out of CodeGen from using TypeScript as a schema, it sounds like. It sounds familiar to my extremely vague understanding of things like protobuffers, where, like yeah, if you're just sending JSON, There's only so much you can optimize it because JSON as a data structure is just slower to parse. [29:37]
-
-You know, you don't have a schema, you don't know what it looks like, so you have to figure out what it looks like as you go. So starting from a schema, starting from a specification of what the data contains, and then using that to generate like ultra fast native code makes a lot of sense to me. That's, that's pretty cool. [29:53]
-
-## [JSR and Deno: Final Review 🚮 ](https://dbushell.com/2024/08/09/jsr-and-deno-final-review/)
-
-**Carl Vitullo:** All right. I will bring us on. Just a couple thoughts on JSR and Deno. I think Mark brought these up and had them cross my radar, but David Bushell, who is a WordPress developer mostly, wrote a couple of blog posts that I think are pretty It's a pretty rough indictment of the JSR, you know, module ecosystem and generally the path that Deno has taken through module, you know, managing modules, package dependency. [30:20]
-
-One of the criticisms that he brings up about Deno in general is as a, you know, okay, it's a venture backed company. We've talked a little bit on this show before about venture backed open source projects. One of the criticisms that David Bushel puts out is that it doesn't really feel like, it feels corporate, like the communication feels corporate. [30:38]
-
-It feels like corporate PR, not, you know, somebody talking about what they're working on. And that was actually, that resonated with me because that's something I've noticed. Like, for instance, I set up an ecosystem news channel here in Reactiflux, and Deno stuff is some of the only things that come through it, and it feels like somebody set up a corporate process and there's somebody whose job it is to make sure that all of the communications channels get populated, you know, in a way that it doesn't feel that way for other projects like Expo or React or things like that. [31:07]
-
-So, I don't know, just like as a vibe. That was an interesting call out that I had noticed on my own as well. They talk about the meandering path that Deno has taken through trying to get package dependencies going, you know, cause, um, Ryan Dahl had a, you know, what node got wrong about Imports, I'm misquoting that, but he complained about errors he had made in creating Node and talked about how he was going to do it differently this time with Deno. [31:34]
-
-And then they, you know, they did like a deno. land package registry for a while and then like, oop, nope, we're replacing that with JSR. But now it's all a little confused. Like it's, JSR applies certain restrictions on what you can publish. Like you have to annotate the return types. of any published module. [31:53]
-
-So you can't just let it infer the return type, which seems like a kind of strange restriction to put on it. I guess it's maybe to enforce SemVer through types, you know, use those return types as a schema and assert like, oh, nope, you got to break it. You change the types. I don't know. It's interesting. [32:08]
-
-It's curious. The single most, like, disruptive point that David Bushell made was pointing out that Dnode doesn't resolve sub dependencies like Node does. Like, the way that the JSR registry works does not permit sub dependencies in the same way, in the way that we've grown accustomed to with Node. Which, like, I have called that out before. [32:28]
-
-That, subdependencies, dependencies of dependencies, is one of the best parts of the JavaScript ecosystem. The fact that I can install a package and I don't need to, you know, to an extent, I don't need to Manually make sure that I have given it everything that it needs. You know, there's some exceptions, like if you're using, you know, there's peer dependencies where that is still the case, but in general for if I install a library, that library brings in what it needs on its own. [32:56]
-
-There's downsides to that of course, as well, but I generally consider that to be one of the major differentiators between JavaScript and, you know, PHP or Python. So seeing that go backwards is, seems like a bad thing to me. So that seems, yeah, I don't know. It's just a, a lot of pretty negative takes on Deno and JSR. It's given me a lot of pause on it. [33:15]
-
-**Mark Erikson:** I mean, it's not just one hard problem, it's dozens o f hard problems simultaneously. I mean, you know, think, think back to, you know, trying to work with C where there is no such thing as a package manager. Java is sort of its own different world. C sharp is its own different world. [33:31]
-
-Rust has the cargo tool and a centralized registry. Python is an utter mess. There was an XKCD years ago about how bad Python package management is, and I've continued to kind of just keep a general eye on developments in the Python world. And it's more confusing over time. So there's a lot of very, very justified complaints about how bad package management is on multiple levels in, we, we say the JS ecosystem, and by that we usually mean the Node plus NPM. [34:02]
-
-But all things considered at the same time. Most of that ecosystem generally works, and so it's been interesting to see Deno take a slightly different path and actually have to sort of backtrack a bit and say, Well, yeah, actually it turns out maybe a couple of those ideas weren't so bad after all. [34:19]
-
-**Carl Vitullo:** Right, they went pretty hard in copying Go style dependency management. [34:23]
-
-And I always thought Go style dependency management sounded like an absolute nightmare. And so, yep, alright, they're walking some of that back. [34:30]
-
-## [web-infra-dev/rslib: The library build tool powered by Rsbuild](https://github.com/web-infra-dev/rslib)
-
-**Mark Erikson:** There's yet another new build tool out called RSLib to work through the chain of pieces on this one. [34:37]
-
-So, the folks at ByteDance have an incredibly prolific infrastructure team, and so the way I understand this is they built a full blown Rust re implementation of Webpack that they call RSPack. In fact, they've actually made a couple comments about it would be nice if this could just be turned into Webpack version 6, in theory. So RS Pack is web pack five, but entirely rebuilt and rust, effectively. [35:02]
-
-RS build is a layer on top of RS Pack that makes it a lot easier to configure, or the, the configuration syntax is closer to like Es builds configuration level roughly than web pack's configuration level, where you're having to create a whole bunch of plugins. [35:19]
-
-And so, rsbuild is meant more for applications, and I guess they've made a third layer on top of that where rslib is a wrapper or specialization of rsbuild that is more meant for building libraries with a proper configuration output. So, I'm not sure what's leading to all this proliferation of build tools from them, but they are very happily cranking away on a whole series of things. [35:45]
-
-## [2024 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2024/)
-
-**Carl Vitullo:** All right. I'll pull us onto our next one. We spent a lot of time last month talking about state of JS, state of React, state of HTML, we have another survey, the Stack Overflow Developer Survey, the results came out this month. I'm not going to do too deep a dive, I think, although Mo, yeah, we had talked about, you know, demographics and selection biases of the state of JS, definitely more to talk about here. Yeah, some, some points that I took away from this that were interesting to me. I mostly looked at the professional developer respondents, just that's who I am. That's who I am viewing as the target audience for this show. [36:20]
-
-Something that surprised me a little bit, they said that more than 75 percent of professional developers have at least a bachelor's degree. I think it was like 45 percent have a bachelor's, like 26 have a master's, and like another 5 percent have some kind of specialized professional degree, like a JD or, you know, something like that, legal, medical, whatever. [36:40]
-
-For years of experience, front end developers were absolute bottom of the list, except for student, which was interesting, but also not surprising. You know, Boot camps, they probably teach you front end, like, makes sense. It's probably the most accessible part of the software field. So not super surprising there, but yeah, uh, also less than 6 percent of respondents to this survey self identified as a front end developer. [37:03]
-
-That's lower than I think it was in previous years. It feels like front end has kind of. I don't know, it feels like it's diminished over the last couple years. I was looking at the country demographics. I was curious about this because I know from our statistics who uses Reactiflux, I know that we have a huge Indian population within the server. Having my own read, my own perspective on what those metrics look like by actual like usage and participation. I was curious to see how they'd be reflected. And the answer is not great. Top five countries as responded to the Stack Overflow survey were the U. S. with like 19 percent, Germany with a bit over eight, India with a little over seven, UK with five and a half, Ukraine four and a half. [37:45]
-
-I was curious to see how, what data I could find to back that up on, you know, what those stats look like. I couldn't find a direct comparison between the US and India, partly because the only English sources I could find for tech jobs in India just said all of IT, all of software in one. [38:02]
-
-### https://www.meity.gov.in/content/software-and-services-sector
-
-### https://www.bls.gov/oes/current/oes151252.htm#nat
-
-**Carl Vitullo:** But yeah, they said five and a half million IT and software workers in India, when I summed those same jobs up for Bureau of Labor Statistics in the U. S., that was like four and a half million. So just to say, there's definitely a huge English speaking bias in these surveys, which is unfortunate because the programming world is much larger than the English speaking world. some other Things, JavaScript was the number one most used technology here, and 25 percent of people learning to code self reported using Google Cloud. [38:32]
-
-I think that was like one of the top. That was the number one. That was the like most reported. Vercel was number three in people learning to code. Uh, for professional developers, top three, obviously, AWS, Google, and uh, Microsoft, but Google and Microsoft combined were about equal to AWS's numbers. On that list, Vercel was seventh. [38:51]
-
-Just about a percent lower than DigitalOcean, which was behind Cloudflare, which was behind Firebase. React and Node, together, both topped the web frameworks list of, technologies used with jQuery in number three. But yeah, 18 points behind React and Node, so definitely a different tier. But yeah, jQuery, what staying power it's had. I actually saw that this was, I believe the 18th birthday? It's old enough to vote. [39:15]
-
-**Mo Khazali:** The one thing that's interesting to me is just the 25 percent of folks learning to code use Google Cloud. I have a suspicion that might be to do with the fact that I know that there are GCP is quite involved in student fairs and a whole bunch of stuff giving free credits to people for hackathons and whatnot. [39:31]
-
-I wonder if there's some sort of correlation there where a lot of people seem to use it for their student experimenting and hacking, but maybe not so much when they get into the professional world. Just an observation. [39:42]
-
-**Carl Vitullo:** Yeah, that actually makes a lot of sense. I have seen them sponsor a lot of hackathons and things like that. [39:46]
-
-Yeah, I hadn't considered that, but scans. Cool. That was our last main content piece, uh, I guess into the lightning round. [39:53]
-
-## [Cocoapods going into maintenance mode](https://blog.cocoapods.org/CocoaPods-Support-Plans/)
-
-**Mo Khazali:** I'll just jump in with an update from the React Native ecosystem, or more, more broadly speaking, the mobile ecosystem. So, in terms of package managers, CocoaPods used to be the be all and end all when you wanted to build an iOS app, in terms of managing your packages, and we've come a long way where CocoaPods is now going into maintenance mode. [40:10]
-
-Now, CocoaPods is actually used by most of the cross platform technologies as the package manager of choice. So React Native uses it, but I think Flutter also uses it, and apparently Unity also uses it for some of their stuff as well. So there's a whole lot of this ecosystem that's being built in CocoaPods. [40:25]
-
-But what's happened here is that Apple's actually released their own package manager called the Swift Package Manager, or SPM for short. What the CocoaPods team called it was that they got Sherlocked, which is a reference to old school OS X, where they Basically got rid of an app called Watson, which was what Spotlight is now. [40:41]
-
-They created Sherlock at that point, which basically did all of the functionality that Watson used to do that was already integrated into the OS itself. So they're basically citing that saying we've been Sherlocked and we're now going to go into maintenance mode as a result, because there's no competing with Apple. [40:55]
-
-So a sad day for everyone who loved and used CocoaPods for years, but obviously we're going forward into the SPM era and React Native is already kind of on that route to adopt SPM support. [41:07]
-
-## [Accident Forgiveness · The Fly Blog](https://fly.io/blog/accident-forgiveness/)
-
-**Carl Vitullo:** I saw a cool policy change for Fly. io, which is a, sort of a competitor to Vercel, it's a cloud compute platform. [41:14]
-
-They are doing an explicit accident forgiveness policy, which is just kind of great. It's generally socially understood that platforms like AWS or Vercel or, you know, whatever if you have some weird billing situation that arises, like I think one that happened was like somebody got in an infinite loop during their CI build and that caused a huge number of function invocations and because you could build per function invocation, they had, you know, like a 200, 000 bill when they're used to paying like 2, 000. [41:45]
-
-It's socially understood that most of the time, if it's not a repeat occurrence and it's not malicious, then they will forgive the bill. But it's socially understood. It's not in policy anywhere. It's just you put it on Twitter, you complain, it becomes a PR issue, and the company refunds you. [42:00]
-
-So now fly. io has put up an actual policy saying we forgive accidents and has given more clarity around there. I appreciate that. It's always nice to see social norms turn into policies, especially when they deal with six figures in billing. [42:17]
-
-## [spatial compute](https://sunilpai.dev/posts/spatial-compute/)
-
-**Carl Vitullo:** I saw a wonderful blog post from Sunil Pai, who I'm just a big fan of. We've collaborated a little bit in the past, but he has done PartyKit. He worked on Wrangler at CloudFlare. He's now working at CloudFlare again. He wrote about spatial compute, which is letting the network decide where in the world to run your code. So this is sort of an incremental step forward for serverless paradigm. [42:40]
-
-Instead of starting up a server that runs your code, you just say, this is the code that I want to run. Please start it when this request is made. But you still generally tell it, what region of the world that code is going to be hosted in. So this is just a blog post talking about not doing that. Letting the server decide, letting the network decide where in the world to run your code. [42:59]
-
-I just think that's a really interesting idea. It seems good. Seems kind of inevitable. Uh, and this is the first time I've ever seen anyone mention it. So calling it out. [43:06]
-
-**Mo Khazali:** Interestingly, he's called it spatial compute. And I think he's put a disclaimer at the top saying, sorry, Apple, but that I wish he chose another term for that. [43:13]
-
-That's already been used. [43:15]
-
-**Carl Vitullo:** Oh, that's true. That is what Apple called their Vision. [43:17]
-
-**Mo Khazali:** Yeah. Vision Pro Computing. Yeah. It's, it's, I wish there was another term he could use for this. [43:22]
-
-**Carl Vitullo:** I like that he called it out and still did it anyway. [43:25]
-
-**Mo Khazali:** Yeah, exactly. [43:25]
-
-## [How Airbnb Smoothly Upgrades React](https://medium.com/airbnb-engineering/how-airbnb-smoothly-upgrades-react-b1d772a565fd)
-
-**Carl Vitullo:** Womp womp. Yep. Airbnb, we talked about Airbnb last episode as well. Uh, they put out a blog post about how Airbnb smoothly upgrades React. [43:34]
-
-Last month, we talked about how they had just upgraded to React 18. So this is now two months later. them talking a little bit more about the process by which they did so. It was a pretty good read. It talks a lot about, like, feature flagging, you know, blue green deployments, and just sort of the trials and tribulations of what it means to update a core dependency of a widely used app that is in many, many phones with a huge variety of, you know, Performance and, you know, network and all those sorts of things. [44:01]
-
-So I appreciated that, just right at the beginning of the They show like, you know, here's the ideal, like a stair step function of what version we're using. And then here's the reality of what version we've used over time. And it's got lots of like false starts where it's, they ship it and it's like, Oh, nope. [44:14]
-
-Okay. There's a bug. We got to roll it back. Let's try again. Nope. Still bugs. Roll it back. This is, Relatable to my career. There's just, you can't do a big overhaul without missing some kind of edge case that you didn't anticipate. So, um, just always appreciate seeing people pull back the curtain and show what those pains look like, especially at big companies that have huge distributions. [44:34]
-
-## [Use useId() Instead Of Hand-Making IDs](https://reacttraining.com/blog/use-useid-instead-of-hand-making-ids)
-
-**Carl Vitullo:** all right, great blog post from React Training, which I'm actually not sure who's running this anymore, but it was started by Michael Jackson and Ryan Florence of React Router and Remix. They've been on my radar for a very long time. Looks like this was written by Brad Westfall. Use ID instead of hand making IDs. [44:50]
-
-This was one of the clearer articulations of what use ID is meant to be used for that I've read. This just really kind of made it click for me. It talks about using. an ID attribute on the DOM, and why you shouldn't handwrite them. And it was just very clear and simple. The gist of it is, if you handwrite an ID, then you can only use that component once in order to not violate the guarantees that an ID has with the browser. [45:17]
-
-You know, in a browser, an ID is supposed to be unique. If you select an ID, you get one element exactly. And so if you hand write an ID, your component can't be reused without violating that contract. What a simple idea. That makes sense. I now intuitively understand why use id is a valuable API to have. Um, yeah, just appreciated that. I love when something I didn't understand just clicks and becomes intuitive. I like it. [45:42]
-
-## [Common Sense Refactoring of a Messy React Component](https://alexkondov.com/refactoring-a-messy-react-component/)
-
-**Carl Vitullo:** Calling out this great blog post from Alex Kondov, he wrote, Common Sense Refactoring of a Messy React Component. Refactoring messy components, breaking them down into, from one mega component that does way too much into a smaller number of components that each have a smaller, you know, a single responsibility, has been a recurring theme in my career. [46:01]
-
-This looked like a really great write up. I appreciate that it just does, like, A two paragraph preamble and then dumps 300 lines of kind of gross code on you. It's like, yeah, you know, that is, that's the experience of entering a new code base most of the time. I appreciated this breakdown of here's what the process of refactoring a messy component looks like. [46:20]
-
-## [Introducing Structured Outputs in the API](https://openai.com/index/introducing-structured-outputs-in-the-api/)
-
-**Carl Vitullo:** All right, small news from OpenAI. I had actually noticed this. We use OpenAI to do a resume review AI feature here, and I just did a revision to it, and it's much better. It's a little bit sassy. It's very terse. I like it. But yeah, OpenAI now has structured outputs in the API, so you can tell it what shape of JSON you want it to give you back, and it will give you that structure. [46:43]
-
-I know in the past that has been a pain point. I remember people complaining about like just getting OpenAI to give you pure JSON without like, okay, here's the JSON you asked for, JSON. Uh, you know, just purely unhelpful. Just caught this bit of news. If you're curious about writing a little open AI side project, I think this is maybe going to make it a bit easier. [47:03]
-
-**Mo Khazali:** It's also quite interesting for the mobile world, because you see a lot of a bigger shift towards server driven UI now, where, you know, you render things or you compile a JSON object that defines how the UI should look like in the mobile space, because, you know, that really works in mobile because, you You don't have to go through App Store updates, so you can basically have a dynamic page that uses JSON to decide how to layout itself. [47:24]
-
-And so maybe pairing that with something like this could be very interesting because you can give it the right confines and restrictions and then say generate me dynamic UI and then it'll kind of be a smart AI native based app. [47:35]
-
-**Carl Vitullo:** Wild. Kind of V0 vibes. V0 from Vercel. [47:40]
-
-All right. Here's my last little news item. [47:42]
-
-## [Sentry is now Fair Source](https://blog.sentry.io/sentry-is-now-fair-source/)
-
-**Carl Vitullo:** This actually crossed my radar very late. I would like to be more prepared to talk about this because it's at the intersection of, you know, open source and licenses and legal stuff, which I am personally fascinated with. But Fentry has announced that they are FairSource. FairSource is a new concept to me. [48:00]
-
-It's a new project. So they say, today we're launching FairSource, a new approach to software sharing that is safe for companies to adopt and developers to use. Seems pretty neat. They talk about, they give a list of projects that are working with it, and they define it as like publicly available to read, allows use, modification, redistribution with minimal restrictions, and I guess notably it says that it undergoes delayed open source publication, which they give as a four letter acronym, D O S P, very enterprise. [48:29]
-
-It's not quite a license, it's sort of a social contract surrounding a license, I guess. They talk about a new functional source license, but it also recognizes a fair core license. And the business source license. It's interesting. I'm definitely gonna have to dig into this a lot more because this is just referencing a bunch of licenses that I haven't heard of in a like social contract for how source gets released that I haven't seen codified. [48:56]
-
-I've seen companies do things similar to this before, but there hasn't been a name for it. It hasn't been saying like, yes, we are. This, we are FairSource, so definitely interesting. It's not quite free and open source, but it is adjacent free and, you know, FOSS, FOSS has been difficult for many companies to actually execute on and live up to. [49:17]
-
-So this looks like a more friendly. type of license, mode of releasing source code into the world. So maybe it'll give engineers at more companies greater ability to make a compelling case for open sourcing internal code, which would be lovely. I would love to see more proprietary code get open sourced. [49:35]
-
-Too many things happen in secret. [49:37]
-
-**Mo Khazali:** The delayed open source publication is quite interesting because it's having a separate Closed source version of a code base that gets synced with an open source version is not, you know, unheard of. The React Native code base, as an example, is like this. So, it's not the most bizarre thing to have, and it's been happening. [49:52]
-
-It's just maybe not been codified like you mentioned, and maybe this is the way to do it. [49:56]
-
-**Carl Vitullo:** Right, exactly. That's the classic problem in a lot of businesses that would like to open source, is there's some part of it that is, like, truly proprietary, where if they release that, then, like, you know, they're giving away the secret recipe. [50:07]
-
-Or Contractual agreements they have with their customers where like they wrote some custom integration code and like that can't get open sourced. So like there are very real business constraints that make it difficult in some cases to open source code. Like you said, some companies have done that through things like synchronizing source code, but that's been done kind of ad hoc. [50:29]
-
-It's, you know, Each company has figured out its own way to work, to make that work. So seeing this as a template, a framework for people evaluating that decision, to push it over the finish line, to make it actually happen. Uh, that seems really valuable. This seems like one of those like quiet things that will have an outsized impact on the open source world. Pretty neat. [50:51]
-
-## [Job Market](https://layoffs.fyi/)
-
-**Carl Vitullo:** All right, some information about the job market. It was not great this month, but most of that was because of layoffs at Intel, just not great. So 15, 000 layoffs from Intel alone, overall like 25, 000 layoffs in tech. Which is not great, but since most of that came from one company, that's still pretty on track from where it was last month. [51:11]
-
-Intel screwing up doesn't really reflect too much on the broader, you know, tech and software ecosystem, I don't think. [51:18]
-
-### https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
-
-**Carl Vitullo:** I've been using this Fred data source of. Job postings on Indeed. And that is still trending down, which I'm a little surprised about. It's just been a consistent downward trend. It's down to 68 percent of the baseline of like the start of 2020. So, you know, pre pandemic, which I'm surprised. That's wild. I thought it was getting better. [51:38]
-
-**Mo Khazali:** Just on that, I guess like Intel and Cisco both together are 21, 000 out of the 25, 000 layoffs. So if you take those two out, it's, it's actually like three, four thousand. [51:49]
-
-**Carl Vitullo:** Okay. That's actually quite a bit smaller. [51:50]
-
-That's nice. So yeah, last month I commented that it was the first time in a while we haven't had a pretty big pop of layoffs at the start of a new quarter. So yeah, cool. I guess that's generally holding true except for two megacorps running into problems. [52:04]
-
-A couple of new releases. [52:06]
-
-## [Material UI v6](https://mui.com/blog/material-ui-v6-is-out/)
-
-**Carl Vitullo:** material UI put out version 6. They commented that they took two and a half megabytes out of the bundle size they'd installed on your disk, not the published size of your bundle, which made me look at that and go, wow, this is a 12 megabyte Install size, which is wild. That's larger than I realized. But yeah, Material UI, if you're using it, there's a new version out, new major. [52:28]
-
-**Mark Erikson:** Although on that note, the TypeScript team has done some fantastic work shrinking the size of the installation on disk. Like it, it was up to like 50 megs, I think, as of like 9. And they did a lot of work in 5. 0 to convert some of the internals over to ES modules. And then, and then. Working on deduplicating some of the bundled files that they had and other internal optimizations. [52:55]
-
-I think at this point it's down to like 20 or 25 megs, which is still sizable, but I mean on the other hand, you know, 50 percent net win is a net win. [53:04]
-
-**Carl Vitullo:** Adhering that size, you know, 25 megs for all of TypeScript versus, you know, I don't know if it's exactly 12, I don't have the number in front of me right now, but half of TypeScript for material UI seems like a pretty big lift. [53:16]
-
-## [Tauri v2 RC ](https://v2.tauri.app/blog/tauri-2-0-0-release-candidate/)
-
-**Carl Vitullo:** There's also Tauri v2 has a release candidate out. I don't know a ton about that, but we talked about it briefly in the past. [53:24]
-
-**Mark Erikson:** It's an Electron competitor allows you to build apps that run on the desktop But the UI is built with web technologies The difference is that Electron you're shipping an entire copy of Chrome as the rendering engine Whereas Tauri uses whatever OS's native web views instead So the overall shipped size is a lot smaller. [53:43]
-
-**Carl Vitullo:** Heck yes, seems cool. So they've got a new version 2 coming out, which should be big. [53:47]
-
-## [NX v19.5](https://nx.dev/blog/nx-19-5-adds-stackblitz-new-features-and-more)
-
-**Carl Vitullo:** There's also NX version 19. 5. I don't know a ton about NX. [53:53]
-
-**Mark Erikson:** It's primarily a monorepo management tool. So managing lots of individual packages for both, you know, multiple libraries, multiple applications in one repo, which each of which could be, you know, being built with different tools. Like you might have, you know, a common TypeScript library and maybe, you know, a Vite app and an Angular app all in the same repo. And so NX does work to deduplicate the builds as well as manage creating and updating a lot of those packages. [54:20]
-
-## Upcoming conferences
-
-**Carl Vitullo:** On to some conferences that are coming up. [54:22]
-
-### https://www.reactuniverseconf.com/
-
-**Mo Khazali:** Next week, if I'm not mistaken, and time is not escaping me, is React Universe Conf. React Universe Conf happens every year in Wroclaw in Poland. So it's happening on the 5th and 6th of September. Uh, it used to be called React Native EU, but it's now evolved since React and React Native are getting closer and closer together by the day. So I will be emceeing the conference. Hence why I'm giving this shout out. [54:44]
-
-So come along. Hopefully it'll be a good time. There's a lot of great speakers headlining there. [54:48]
-
-**Mark Erikson:** Was it September, almost September already? [54:50]
-
-**Mo Khazali:** That's why I have to take a double glance at the calendar. [54:53]
-
-### https://www.jsconf.cl/
-
-**Carl Vitullo:** Cool. There's also JSConf in Santiago in Chile. Overlapping with React Universe. So that's going to be September 5th through 7th. [55:01]
-
-### https://utahjs.com/conference
-
-**Carl Vitullo:** I feel like we've been talking about Utah conferences a lot, I guess. But yeah, Utah JS is doing a conference. Seems like there's been a lot of stuff going on in Salt Lake City. Yeah. [55:10]
-
-### https://reactalicante.es/
-
-**Carl Vitullo:** There's also React Alicante in Spain, September 19th through 21st. [55:15]
-
-**Mark Erikson:** I'm speaking, looking forward to it. [55:17]
-
-**Carl Vitullo:** Woo! [55:18]
-
-### https://www.jsconf.ie/
-
-**Carl Vitullo:** And JSConf Ireland in Dublin, September 25th and 26th. [55:23]
-
-### https://2024.squiggleconf.com
-
-**Carl Vitullo:** Yeah, SquiggleConf in Boston is October 3rd and 4th. This is organized by a conference buddy of mine, Josh Goldberg. He is author of a book on TypeScript and just a wonderful, friendly, lovely person. I'm actually going to be volunteering there, so I'll be helping out with making sure the conference goes off. [55:41]
-
-**Mo Khazali:** Yeah. So Josh, I was going to similarly give a big shout out to Josh for being an amazing person. But beyond that, me and him have been bonding. So we spent a bit of time in Amsterdam and we bonded over being first time conference organizers this year. So him and I have been trying to be each other's support group here and they're sending each other some tips and advice. [55:57]
-
-But Josh is, is incredibly well known in the community and he's going to hopefully put together a really, really cool event. So definitely go there if you're in the U. S. [56:05]
-
-**Mark Erikson:** The other organizer, Dimitri, is less well known, but also a wonderful person. [56:10]
-
-**Carl Vitullo:** Yep, I just got to meet Dimitri the other day, uh, talking about volunteering. Seems really cool, seems really lovely. I'm going to brag, I was at the table at React Miami where Josh Ideated the name SquiggleConf, so I was there for the origin. So, very happy to volunteer. [56:26]
-
-### https://www.rendercon.org
-
-**Carl Vitullo:** Overlapping with that, there's RenderCon in Nairobi, Kenya, October 4th and 5th. [56:32]
-
-### https://www.reactindia.io/
-
-**Carl Vitullo:** Then, React India in Goa, India, October 17th through 19th. [56:37]
-
-### https://www.react.brussels/
-
-**Carl Vitullo:** There's React Brussels in Brussels, Belgium, October 18th. I went to that not last year, but the year before. It seemed really great. I got to hang out with the organizer at React Conf in Las Vegas, and just really great dude. Would recommend React Brussels for sure. [56:53]
-
-### https://reactadvanced.com/
-
-**Mo Khazali:** Cool, next up we've got React Advanced London, so this happens around October time every single year in London, so I've been going for a few years now, and the Great React Conference is probably the biggest React Conference that there is in the UK, so definitely head there, I will be there again this year, so if you're around, pop me a message and we'll say hi. [57:09]
-
-## Outro
-
-**Carl Vitullo:** All right, cool. That is everything we've got for today. Thank you everyone for joining us. We will be back on the last Wednesday, even though today is Thursday, uh, last Wednesday of the month to hear on the live stage of Reactiflux or back in your podcast feed just as soon as we can. [57:23]
-
-**Mo Khazali:** Thank you all for joining and listening to us ramble on and chat all things React and React Native. [57:28]
-
-It is always a pleasure and see you all next month. [57:31]
-
-**Carl Vitullo:** We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, the React. js subreddit, and here in Reactiflux. If you see anything that seems newsworthy, uh, that you think we should discuss, just put it in the tech reads and news channel here in Reactiflux. [57:49]
-
-Or, if you like, You can send it to me in an email at hello at reactiflux with T M I R in the subject line, which is a, it's an acronym for the show. I read every email that comes in, including spam because I'm a crazy person. So I will read it even if we don't end up covering it. If this is the show you get value from and want to support, the best way you can do so is by giving a review on Spotify or whatever platform that you actually listen to. [58:15]
-
-Tell your friends, tell your coworkers, we're cool and smart and we can help you sound cool and smart too. You're pretty cool and smart too. See you guys next month. Bye.
diff --git a/src/transcripts/tmir-2024-09.md b/src/transcripts/tmir-2024-09.md
deleted file mode 100644
index 3ac2e84..0000000
--- a/src/transcripts/tmir-2024-09.md
+++ /dev/null
@@ -1,517 +0,0 @@
----
-title: "This Month in React, September 2024: Async Components??, a React 19 cheatsheet, static Hermes, and trademarks drama"
-date: 2024-09-25
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-### New releases
-
-- [[00:57](#node-v2280)] [Node v22.8.0](https://nodejs.org/en/blog/release/v22.8.0)
-- [[01:06](#deno-v2-rc)] [Deno 2.0 Release Candidate](https://deno.com/blog/v2.0-release-candidate)
-- [[01:47](#relay-v18)] [Relay v18](https://github.com/facebook/relay/releases/tag/v18.0.0)
-- [[02:28](#redwood-v8)] [Redwood v8.0.0](https://redwoodjs.com/upgrade/v8)
-- [[04:09](#epic-react-v2)] [EpicReact v2](https://x.com/kentcdodds/status/1838263679025844378)
-- [[04:55](#rspack-v1)] [RsPack 1.0](https://rspack.dev/blog/announcing-1-0) and [Rsbuild 1.0](https://rsbuild.dev/community/releases/v1-0)
-- [[06:20](#metro-08011)] [Metro 0.80.11](https://x.com/MetroBundler/status/1831709057670861260)
-- [[07:52](#effect-38)] [Effect 3.8](https://effect.website/blog/effect-3.8)
-- [[08:43](#astro-415)] [Astro 4.15](https://astro.build/blog/astro-4150/)
-- [[09:45](#react-email-v3)] [React Email 3.0](https://resend.com/blog/react-email-3)
-- [[10:26](#react-native-076-rc2)] [React Native 0.76 RC2](https://github.com/facebook/react-native/releases/tag/v0.76.0-rc.2)
-
-### Main Content
-
-- [[15:08](#bulletproof-react-updated-to-include-nextjs)] [Bulletproof React updated for NextJS](https://github.com/alan2207/bulletproof-react)
-- [[15:52](#new-react-native-debugger)] [New React Native Debugger](https://www.youtube.com/watch?v=b48Lax2-jOQ&t=4350s)
-- [[18:05](#hermes-new-runtime-bytecode-translation)] [Hermes new Runtime Bytecode Translation](https://www.youtube.com/watch?v=pfeTPSai6vc&t=8702s)
-- React 19
- - [[22:14](#react-19-cheat-sheet)] [React 19 Cheat Sheet](https://www.epicreact.dev/react-19-cheatsheet)
- - [[24:10](#whats-new-in-react-19)] [What’s new in React 19](https://vercel.com/blog/whats-new-in-react-19) (moreso a discussion of the evolution of the rendering model)
- - [Build-time Components](https://codehike.org/blog/build-time-components)
- - [You can use async functions for components in React 19??](https://x.com/kentcdodds/status/1831331752343716003)
- - [Core team forgot to put it in release notes??](https://x.com/sebsilbermann/status/1831405742257271202?t=RkXE1h91Ckher4kWUrzWuQ&s=19)
-- [[26:22](#a-milestone-for-typescript-performance-in-tanstack-router)] [A milestone for TypeScript Performance in TanStack Router](https://tanstack.com/blog/tanstack-router-typescript-performance)
-- [[27:46](#weve-decided-to-make-a-few-changes-to-ease-the-adoption-of-next-15)] ["we’ve decided to make a few changes to ease the adoption of Next 15"](https://x.com/feedthejim/status/1829569083777437745)
-- [[30:07](#trademark-disputes)] Trademarks drama
- - From Deno: [JavaScript™](https://javascript.tm/)
- - [[31:46](#wp-engine-v-automattic)] [WordPress](https://x.com/photomatt/status/1838738735795703976) v [WPEngine](https://x.com/justinferriman/status/1838356417482514842)
- - [[33:10](#trademark-diff-seems-targeted)] [Trademark page diff seems targeted](https://www.diffchecker.com/tJ29tGIn/)
-- [[33:49](#youre-writing-a-vite-based-spa-you-need-to-add-a-few-api-routes-ie-for-authentication-what-do-you-do?)] ["You're writing a vite-based SPA. You need to add a few API routes (i.e., for authentication). What do you do?"](https://x.com/aboodman/status/1836470815862460506)
- -[[36:43](#mos-talk-at-future-frontend-2024)] Mo at Future Frontend: [Dynamic UI at the Edge](https://youtu.be/BRce-DHEoNc?si=AsVqdVrxbiO9nyW9)
-
-### ⚡ Lightning round ⚡
-
-- [[39:03](#nitromodules-released-to-the-public)] [Nitromodules released to public](https://mrousavy.github.io/nitro/)
-- [[39:31](#nodejs-adds-an-experimental-permission-model)] [NodeJS adds an experimental permission model](https://twitter.com/liran_tal/status/1830621784770555915)
-- [[40:54](#typescript-with-react-styleguide)] [TypeScript Styleguide](https://mkosir.github.io/typescript-style-guide/#appendix---react)
-- [[43:05](#inside-ecmascript-javascript-standard-gets-an-extra-stage)] [Inside ECMAScript: JavaScript Standard Gets an Extra Stage](https://thenewstack.io/inside-ecmascript-javascript-standard-gets-an-extra-stage/)
-- [[44:34](#remix-the-web-from-mjackson)] [The Neverending Story](https://garrettdimon.com/journal/posts/the-neverending-story)
-- [[44:34](#remix-the-web-from-mjackson)] [Remix The Web from mjackson](https://github.com/mjackson/remix-the-web/)
-- [[46:42](#replacing-react-code-with-css-has-selector)] [Replacing React code with CSS :has selector](https://www.developerway.com/posts/replacing-react-with-css)
-- [[48:19](#performance-optimization-strategies-for-large-scale-react-applications)] [Performance Optimization Strategies for Large-Scale React Applications](https://old.reddit.com/r/reactjs/comments/1f6abzy/performance_optimization_strategies_for/)
-
-### Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-- [SquiggleConf](https://2024.squiggleconf.com) Boston, MA USA Oct 3-4
-- [RenderCon](https://www.rendercon.org) Nairobi, Kenya Oct 4-5
-- [React India](https://www.reactindia.io/) Goa, India Oct 17-19, 2024
-- [React Brussels](https://www.react.brussels/) Brussels, Belgium Oct 18
-- [Next.js Conf](https://nextjs.org/conf) SF, USA Oct 24
-- [React Advanced London](https://reactadvanced.com/) London, UK Oct 25, 28
-- [HalfStack London](https://halfstackconf.com/london/spon) London, UK Nov 13
-- [React Native London](https://www.reactnativelondon.co.uk/) London, UK Nov 15
-
-**Carl:** Hello, everyone. Thank you again for joining us for the September edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live in Reactiflux, the place for professional React developers, and we're supported by Infinite Red, a little bit more on them. I'm going to do something different this month. I'm going to do the ad read after our You know, quick hits at the start. [00:21]
-
-Hello, I'm Carl. I'm a staff product developer and a freelance community manager here at Reactiflux, uh, where I run community programs like these events and help keep the community operating. [00:31]
-
-This month we don't have Mark, sadly. He's in Turkey, um, I think. Not sure if he did a conference, but he just couldn't swing it this month. [00:37]
-
-**Mo:** And I am Mo. I head the mobile team at Theodom. I'm quite active in the React Native ecosystem. Get very involved in a bunch of different conferences and some open source here and there. [00:47]
-
-I organize the React Native London, community. And basically oversee a team of different developers who are specialized in React Native. So, happy to be here to chat, as always. [00:56]
-
-**Carl:** All right, straight into some new releases. [00:57]
-
-## [Node v22.8.0](https://nodejs.org/en/blog/release/v22.8.0)
-
-**Carl:** We've got Node version 22. 8. I didn't see anything super big that caught my eye in this change. New Node, minor version released. [01:06]
-
-## [Deno v2 RC](https://deno.com/blog/v2.0-release-candidate)
-
-**Carl:** We've got Deno v2 release candidate coming out. It looks like this is coming out in Continuing the trend over the last couple months that we've discussed of Deno kind of walking back some of its opinions, they have gone pretty hard on Go style dependency management and a couple of other Go and other highly opinionated back end languages. [01:25]
-
-They're kind of walking those back. Stuff like, they had been Encouraging people to use window instead of process. They are changing that in order to be more compatible with existing NPM modules. Just generally be more compatible across the ecosystem. Yeah, a couple of other things like that too, like making it easier to use with NPM. [01:41]
-
-Generally making it more compatible, which I think is why they're walking back some of their highly opinionated opinions. [01:47]
-
-## [Relay v18](https://github.com/facebook/relay/releases/tag/v18.0.0)
-
-**Carl:** We've also got Relay version 18. Are people still using Relay? I don't really have a good sense for its, I don't know, usage. I know, obviously, Facebook still uses, Meta still uses it, but, yeah, not sure how much community uptake it's had over the last three or so years. [02:01]
-
-**Mo:** Not much on our side. [02:03]
-
-**Carl:** But a change that should make it a little bit easier for people to start using, they have added IntelliSense for the Relay config file. Just getting started, I've tried to get started with Relay two or three times over my career, and just never got over that initial hump of figuring out how to get it working. [02:17]
-
-So, uh, maybe some stuff like that will help. Make it a little easier to use. Not having used it, I can't really speak to the other changes they have, but you know, improve validation of argument types, an alias, catch, throw on field error. Cool. [02:28]
-
-## [Redwood v8](https://redwoodjs.com/upgrade/v8)
-
-**Carl:** There's also Redwood with a major release, version 8. Redwood is sort of trying to be the Laravel of the React ecosystem, sort of an all in one framework that does all the things that you need. Instead of making you find all the packages yourself to glue the bits together, which seems pretty cool. Yeah, this major release upgrades a lot of dependencies, adds Docker support, which I was a little surprised to see. I, I think of Docker support as not something a framework needs to, like, explicitly add, but cool. [02:53]
-
-I guess maybe they're making it a little bit easier to just get running in that environment, which since Docker is such a widely used primitive, that makes a lot of sense. Seems cool. They talk about an experimental SSR and RSC setup, so if you're doing server side rendering, or if you're interested in server side rendering and server components, might be, should be easier. [03:12]
-
-As well as adding support for background jobs, which is definitely something that an all in one framework, I think, I would expect to provide. So that's cool. [03:20]
-
-**Mo:** The Docker support is really interesting because It's almost in direct, I want to say, almost opposing to how Next does it, which it seems to me like Docker is like, hey, you have a Docker image and you can basically use it to deploy your full stack web app into, into whatever cloud platform you want to use. [03:38]
-
-Super easy, primitive, that's agnostic to whatever cloud provider you want, you self host it, you scale it up yourself, however you want, and our batteries included framework will just work. Whereas Next is notoriously difficult to be able to, uh, self host. So I just find that interesting. Maybe it's directly done as sort of a distinguishing factor compared to Next. [03:55]
-
-I don't know, but I find it quite interesting. [03:57]
-
-**Carl:** Yeah, makes sense. I have preferred to host anything I do in Docker for most of the last 10 years, so it's, that will make it easier. I'm interested in trying out Redwood, so having it better support my preferred environment will definitely help with that. [04:09]
-
-## [Epic React v2](https://x.com/kentcdodds/status/1838263679025844378)
-
-**Carl:** There's a new release of Kent C. Dodd's Epic React, version 2. The overview of the course, it's going to teach you React fundamentals, hooks, advanced APIs, suspense, advanced patterns, performance, and server components. I was a little surprised I couldn't easily find like a diff of what is being covered and what they're focusing more on, uh, between the old version and the new version, which I had been hoping to see. [04:33]
-
-I have not bought it. I consider myself an epic React dev already, so I don't feel like the target audience. But yeah, they're doing a 40 percent off promo right now, so if you have an educational budget at work, definitely consider spending some of it on this. it's about 420 right now. Nice. [04:48]
-
-Full price is 700, and I think it's jumping up there in about two weeks from time of recording, which is on the 25th. [04:55]
-
-## [RsPack v1](https://rspack.dev/blog/announcing-1-0)
-
-## [RsBuild v1](https://rsbuild.dev/community/releases/v1-0)
-
-**Carl:** Some kind of big news. RS Pack and RS Build both released 1. 0 in the last month, about two weeks apart. RS Build is like a Rust based build tool, if you have not paid attention to previous episodes where we've discussed it. [05:10]
-
-A decent amount. And RSPack builds on top of that to provide a Webpack compatible bundler. I feel like this was all the way back to like 2014 15 when Webpack was new. I mean, Webpack really replaced tools like Gulp. I think I went straight from Gulp to Webpack, and it was a massive just step change improvement. [05:28]
-
-It was clearly better in just doing everything. Uh, but It was really complicated to configure, uh, not the fastest tool. So like, almost immediately people were talking about ways to make it faster, ways to make it do the great things that it did in a better manner. I feel like, uh, especially in the web ecosystem, we love our tools to be fast and snappy. [05:50]
-
-so a counterpoint to that, people have been interested in having a faster, better solution than Webpack, but the flip side is that Webpack does so much that it's just really hard to actually make a replacement. So I feel like this is a culmination of like a decade long process. [06:05]
-
-project to produce something like that. So to get a Rust based natively compiled language build tool that provides drop in compatibility with an existing massively complex, massively used tool. Awesome. Seems really cool. [06:20]
-
-## [Metro 0.80.11](https://x.com/MetroBundler/status/1831709057670861260)
-
-**Mo:** So, speaking of bundlers and staying on the same thread, as you will know, React Native has its own bundler that, uh, is purpose built. [06:28]
-
-or the use of React Native apps. Um, and it's called Metro. So, Metro just released a more of a patch than a minor although React Native's versioning is a little bit confusing because everything is a minor because they want to be able to do as many breaking changes as possible, but they released a patch and there was some insane performance benefits here, so They took the resolver step, which was a bit slow within Metro, and they made it around 15 percent, sorry, 15 times faster, and that made a massive difference. [06:56]
-
-So when they ran it on the, uh, Expensify app, which is notoriously a large scale, open source React Native app, the total build time, was brought down from around 13 seconds down to about 3. and that's about 4 times faster for the whole build process, right? So resolving is just one step of it, they've made that significantly faster, but that makes a big impact on the overall build time. [07:16]
-
-And so this is really cool, but one of the added benefits of this is because it's, it's, it's a, it's a patch here, it's actually not a breaking change at all. So you can use it 3 versions back, 3 major React Native versions back, and it kind of works. So all you need to do is just bump your dependencies and you'll get the faster resolving times, which is really cool. [07:34]
-
-So big shout out to the Metro team, specifically, uh, Rob Hogan's been working on this. They did a really good job, and hopefully it just makes our dev tools a little bit faster, which we all love. [07:42]
-
-**Carl:** Yep, yeah, right. Like I just said, we love our fast dev tools in the web ecosystem. Cool. 15 times faster in a patch release. That is rare. Very cool. [07:52]
-
-## [Effect 3.8](https://effect.website/blog/effect-3.8)
-
-**Carl:** Wish I could say more about this, but Effect has released version 3. 8. Cool. Effect seems really cool, but it's also got a really steep learning curve because it's basically an entire new, like, standard library and programming paradigm all at once. It seems really cool. What I've seen in it, it seems to take a lot of inspiration from functional programming tools like languages and environments like Elixir. [08:15]
-
-Just encouraging you to build more like composable APIs? Yeah, we, again, we've talked about this a little bit in the past, so it, I, I won't fully rehash everything, but it's a huge, massive, steep learning curve that seems really cool and possibly worth it. So it's, you know, it's, I feel like I say this so many times every episode, but this is something that I'm really curious about, learning more about and using more and yeah. [08:39]
-
-if you like functional programming in web, definitely. Consider looking at effect. [08:43]
-
-## [Astro 4.15](https://astro.build/blog/astro-4150/)
-
-**Carl:** We've got Astro 4. 15. Big change, they say that Astro actions are stabilized. Um, and it looks like they've swapped out how those actions are configured so that it's a little bit more concise. [08:54]
-
-Uh, you describe the shape of the data that it receives and what to do with that data when you get it. Rather than treating it like a whole request where you then, like, do the validation and the error handling yourself. That's adding some opinions to it, but doing a validation schema and then providing a handler that receives valid data that conforms to the schema that you provided. [09:16]
-
-Seems like a pretty solid abstraction point there. There's also some other things like, the astro islands pattern. you could previously configure it to load those islands asynchronously, idly, when the, when the tab is idle. Uh, and they've now added a timeout so you can set a maximum time that it will wait for your page to go idle. [09:36]
-
-Uh, which seems like a nice, you know, 99th percentile performance improvement. If, if, if you're on a slow device that never goes idle, that's going to cause problems if you're only loading when idle. [09:45]
-
-## [React Email v3](https://resend.com/blog/react-email-3)
-
-**Carl:** So we've also got a new major version of React Email, uh, version 3. 0. Looks like this is another, you know, release getting ahead of React 19. [09:54]
-
-They have swapped out their rendering. So it's now async by default. as well as adding a new component library, improving performance. They added a superbase integration so that you don't have to manually, like, render and then copy the output into superbase, which seems nice. I'm a little surprised to see a new component library here, but I guess in an email environment there are just so many ridiculous constraints that, uh, I guess it makes sense that you need a specialized component library for that environment. [10:20]
-
-But yeah, uh, React Email, if you're doing anything with emails, that seems like a pretty solid tool to use. [10:26]
-
-## [React Native 0.76 RC2](https://github.com/facebook/reactv0.76.0-rc.2)
-
-**Mo:** So, I've kind of stuck the next one in. It's not really a release, but it's a release candidate, so it's kind of a blurred line, but we'll just go with it. The second release candidate of React Native 76 is out. [10:38]
-
-So, when I say, for those who aren't in the React Native ecosystem, when I say 76, I mean 0. 76. It's just, it's so far up that we've just We just get rid of the zero because it's easier to say. But anyway, React Native, 0. 76, Release Candidate 2's out. Um, now, this will still take a few more weeks, at least, to, to land, but, this version of React Native is going to be, quite monumental because the new architecture will be the default. [11:02]
-
-Going forward from this version. Now this new architecture is nothing new. It's been around, it's been talked about for years now. Um, contrary to the name, uh, it was new a while ago. Um, but it was a, it was a massive undertaking because you're basically gutting the internals of React Native, replacing it with React. [11:18]
-
-Something that's totally different in terms of how the native layer is handled. And so you're needing a new rendering engine, you need a new way to interact with native code and the native APIs. And so what that's meant is that this, it's had this long tail of getting library maintainers, 3P libraries, and, and, All of these things ready so that app developers don't have that much of a pain with some of their libraries not working if they switch over to the new architecture. [11:43]
-
-And so hopefully it's going to result in a lot more stability, some performance gains. We're waiting to see, but this is going to be a big release and you can still use the old architecture, but new one is the default. And it will be going forward. So, very exciting times, very monumental times. It's probably going to come with some teething pains as it does when you do such a major rewrite, but we're keeping our fingers crossed. [12:02]
-
-They've put a lot of work into this. [12:04]
-
-**Carl:** For sure, yeah. And as we've discussed many times on here, especially Mark, nobody tries really as candidates. So if you're using React Native, just At least give it a shot. See if there's any, like, obvious failure points, because, uh, open source maintainers love hearing about those growing pains as you're trying to switch over. [12:20]
-
-This is a great opportunity to do it. We're RC2. We're running out of candidates. [12:24]
-
-## Sponsored by Infinite Red
-
-**Carl Vitullo:** We are brought to you by Infinite Red, our main sponsor right now. They are an expert React Native consultancy that I am quite pleased to be a partner with because they are like authentically showing up to support the React Native and React ecosystems in like really meaningful ways. [12:40]
-
-They organize conferences, they host the largest React Native podcast, they publish the largest React Native focused newsletter, and they're Just really excited to work with them. Other than being great people who do great things in the community, they also, well, more precisely, they're a team of about 30 people, mostly developers with mostly greater than 10 years of experience. [13:01]
-
-So they actually work with your team to help you develop an expertise in building React Native. So if you are. Building something with React Native and need a little help hitting the ground running on that, definitely reach out to them because they are great people who will help you do good work. [13:17]
-
-## Upcoming conferences
-
-**Carl:** Moving on to some upcoming conferences. There's a lot, so I'm gonna just do, like, half of these, because we're already 15 minutes in. Mark and I will both be at SquiggleConf in Boston, Massachusetts, October 3rd and 4th. it's organized by a conference buddy of mine, Josh Goldberg. [13:32]
-
-I'm looking forward to it. It should be, should be a great time. It's going to be at the Aquarium in Boston, which seems great. there's also going to be RenderCon in Nairobi, Kenya, October 4th and 5th. React India is in Goa, India, October 17th through 19th. And React Brussels in October, uh, 18th, Brussels, Belgium. [13:51]
-
-There's also Next. js Conf in San Francisco on the 24th of October. [13:55]
-
-**Mo:** And then, if you're in London, ReactiveLabs London is happening on the 25th of October for the in person day and the 28th of October for the remote day. I will be there. I'll be doing a talk about React Native there, so if you're around, come and say hi. [14:07]
-
-**Carl:** Uh, I think Mark will be there too. Sadly, I will not. I will be in Mexico City, having a great time. There's also Halfstack London in London on November 13th. [14:16]
-
-**Mo:** And then this is the announcement that I've been waiting a long time to make on this conference, but we have the two month rule, so we're trying to remain impartial. [14:23]
-
-We are doing the first ever React Native conference in London. So, RNLConf, React Native London conference, effectively, is happening on the 14th and 15th of November. in London, central London at the Brewery, which is this like old building from the 1800s, uh, where a bunch of the monarchs of the UK went and visited, and it was a big festive place. [14:42]
-
-Anyway, it is now an events venue that we have gotten, and we're gonna have a lot of core people from the React Native ecosystem there. Charlie Cheever, the founder of Expo, is gonna be there. we have a lot of different cool folks from Meta, from Amazon, and from a bunch of different places coming to share. [14:54]
-
-Ideas and talks with everyone. If you are interested in joining, we have also, I've just made a discount code for anyone who listens to the podcast, so it's TMIR. Feel free to just grab a ticket that way, and hopefully you'll save a little bit of cash as well. [15:05]
-
-**Carl:** All right, into our main content. [15:08]
-
-## [Bulletproof React updated to include Next.js](https:/bulletproof-react)
-
-**Carl:** Bulletproof React got updated for Next. js. This is a simple, scalable, and powerful architecture for building production ready React applications, it describes itself as. Um, so this, I guess it's a set of example apps, to help you get started. I wanted to call this out because it seems like a pretty good resource. You know, it's a question we get in, you know, Reactiflux all the time. [15:30]
-
-It's like, hey, where can I find a, production grade application to use as a reference? I want to learn. I want to learn more about how they do it. and yeah, this seems like a good resource. It's, it's a whole ass. They have an example app written in a couple of different frameworks, so they have updated it to use the app router, I believe, and yeah, seems like a great resource. [15:52]
-
-## [New React Native Debugger](https://www.youtube.comt=4350s)
-
-**Mo:** Cool. So, this month we had React Universe Conf happening in Wroclaw in Poland. I was there hosting the conference and there was a lot of React Native stuff that was announced. now they were kind of s I want to say soft announcements in some capacity because people kind of knew about them already. It wasn't anything like mind blowingly new, but it was really cool to see the output of a lot of hard work that people have been anticipating for a while. [16:14]
-
-So the first one was the new React Native debugger. just a little bit of context on some of this. Debugging in React Native has been a pain. Anyone who's built with React Native knows that, like, debugging has been a mess. Like, you could use a bunch of different tools in conjunction with one another. [16:29]
-
-Some of them worked for certain things, other ones worked for other things. there was a point where, you know, you used Flipper for a while, and Flipper wasn't great. everyone really did not like Flipper, and so it got deprecated because it was just not really usable. so it was a lot of different tools that you needed to have in your tool belt to be able to effectively debug. [16:45]
-
-the new, the team at Meta tried to kind of, go from a fresh blank slate and say, hey, how do we build a really good debugger that resembles some of the experiences that people are used to with other frameworks and other other languages? And so they built a completely new debugger that's fully built on the Chrome DevTools protocol. [17:00]
-
-And it looked like it was, from what we saw at the conference talk, it looked like it was a lot more reliable. It addressed a lot of the minor pain points that you felt when you were trying to debug. And I guess the big thing was that we finally have reliable breakpoints. Which was a real pain to get working within React Native. [17:16]
-
-So, really, really, exciting stuff to, to, to get. And it should be public soon. So we're excited to get, get our hands dirty with it and, uh, and try it out. [17:25]
-
-**Carl:** Getting into the Chrome debug protocol seems like such a massive improvement here. Instead of using some kind of like bespoke debugging system, I love that you can just actually tap into a widely used tool that a lot of people are familiar with. [17:38]
-
-**Mo:** And it makes sense in terms of the direction that, you know, React Native is going, which is they want to make it more friendly for the web devs to be able to come in and build native mobile apps, right? So you don't want to force React web devs to learn a totally new dev tool framework or a model. You just use the tools that people are familiar with. [17:55]
-
-And so I think it was a great choice, and it looks good. So we'll wait for it to come into the hands of all of us, and then we'll play around with it and make it better over time, and it'll be a great time. Oh, yeah. Cool. [18:05]
-
-## [Hermes new Runtime Bytecode Translation](https://wwwv=pfeTPSai6vc&t=8702s)
-
-**Mo:** So more stuff from React Universe Conf. Another announcement, almost like a thing that we saw into, was, Hermes, which is the JavaScript engine that's used with React Native on most apps, now has a new runtime sort of bytecode translation. [18:19]
-
-Now it's very complicated and complex, and the talk explains it far better than I do, because it's some really low level stuff, so you kind of need to wrap your head a little bit around assembly and some, some stuff like that. A little bit of context, just to contextualize this, I think helps. last year there was a talk by the Hermes team at React Native EU called, uh, talking about this, this new concept of Static Hermes, which was, could we take JavaScript code and, uh, Make it typed native code, and sort of compile that down so that you get near native, if not just native performance, using C Um, and so that was a really cool concept, and the benchmarks that they ran from their early tests was showing that it was massively faster to execute JavaScript code because you were basically executing native code there. [18:59]
-
-it was a really cool approach of, you know, How you bypass the restrictions of JavaScript's runtime. But there were some limitations in the sense of how people use React Native in practice. And, you know, people use a lot of different features like over the air updates, which means you can kind of replace your JavaScript bundle. [19:17]
-
-with a server and add new code to a mobile app without going through an app store. So that's like a big feature that a lot of people use in React Native. And so this wouldn't work with the current model of static Hermes. a lot of different build tools. when you, when you pass your code through something like Babel, it loses the type annotations. [19:32]
-
-So how does that then get compiled down to, you know, typed native machine code. It was hard to really wrap it into the ecosystem and how people are using and developing React native apps. So, Intermediately, the Hermes team's been working on sort of runtime bytecode translation, which means, Okay, well, if we can't do this at compilation time, could we? [19:52]
-
-Find ways to boost performance at runtime and compile things to native instructions without needing to necessarily rely on things that you might only have at compilation time, like your type annotations. whilst being able to still let people do things like over the air updates. And so that's this. [20:08]
-
-concept of the runtime bytecode translation. This isn't landed anywhere and it will take a long time. It will probably first go through Meta's internal process of testing and seeing how it works within their apps. And then if it's stable, it'll phase, in a phased approach, get drip fed to the rest of the community. [20:24]
-
-So it's going to take a little bit of time, but it's really interesting stuff and it can have massive performance gains when you're running really computationally heavy tasks that you would previously run in JavaScript, using this bytecode translation. [20:35]
-
-**Carl:** Interesting. Okay. So I remember Hermes. That's like, that was like a V8 competitor. It was a runtime for JavaScript optimized for React Native. So it sounds like this is going to be doing. Like, you know, all these JavaScript runtimes, they always have various levels of, JIT, just in time compilation happening. I remember, you know, V8 has like TurboFan, and I don't remember any of the other brand names. [21:00]
-
-But, okay, so this is sort of a new type of JIT sort of thing, where it, like, over time will create a I don't know, like codify the bytecode so that it doesn't need to do the JIT every single time? Is that, am I understanding that right? [21:14]
-
-**Mo:** That's what it seems like to me. Again, there's a blurred line between static release that happens at compilation and this, which is kind of JIT. [21:22]
-
-And this is a little bit, there is some level of caching that you can do, right, because those instructions don't change commonly. They're changing once every time you kind of do an over the air update. So, um, a lot is still unknown. it's just more, showing the possibility of if you have unannotated JavaScript code, how much could we, compile it down to bytecode and still get some of the performance gains that you can get out of something like Static Hermes. [21:46]
-
-Which would be a lot more aggressively, compiling things down and, and it has a lot more context because of having access to the source code and being able to run this at compilation. So it's a more practical step that they're trying to address with how the community uses React Native and how probably Meta uses React Native internally as well. [22:03]
-
-**Carl:** That makes sense. My mental model here is aggressive caching of JIT bytecode. Definitely will be curious to see how that shakes out as it starts to roll out. Exits idea stage and enters production stage. [22:14]
-
-## [React 19 Cheat Sheet](https://www.epicreact.dev/react-19-cheatsheet)
-
-**Carl:** All right. A bit of stuff on React 19. Man, I'm a little sad Mark isn't here today because there's a couple of new resources and some, some new info that I'd love to get his take on. [22:23]
-
-But yeah, so Kent C Dodds put out a React 19 cheat sheet and it looks pretty great. You know, even just kind of casually skimming this, I learned several new things that I hadn't realized. Even, even as someone who considers himself to put a decent amount of effort to stay on top of things as they happen. [22:40]
-
-I still learned about like four or five new things from this cheat sheet. Probably the single biggest one is that since when could we use async functions? Like we apparently in React 19 you can do if you know you're doing a function component like you do now you can just mark that as async and it will return a promise like async functions do and React just like knows how to handle that. [23:01]
-
-That makes a lot of sense. I am curious how that, I guess where I really wish I had Mark to talk about. This instead of me is, I don't really understand the difference between the suspense primitive of like throwing a promise versus now this where you can just return a promise. Yeah, this is a really great single page cheat sheet, you know, eight and a half by 11 with a bunch of great resources. [23:25]
-
-You know, it talks about like what the use hook is for, talks about the better error reporting, resource preloading APIs, so you can make sure that You know your fonts and your images are available. Loading style sheets with precedence. Uh, I, something I had known was that React 19 will let you render like scripts and style sheets just within your output and it will hoist them up to, you know, be Loaded as appropriately, something I didn't know is that you can signal their precedence, their relative precedence. So, you know, default precedents or high precedents. This is, this is a base level style sheet that needs to apply to everything versus this is a, you know, could override those base styles, things like that. Really great resource. Kent C. Dodds, of course, putting out lovely educational resources. [24:10]
-
-## [What’s new in React 19](https://vercel.com/blog/whats-new-in-react-19)
-
-**Carl:** There's also a great, What's New in React 19 blog post put out by Vercel. Mostly the bulk of the content talks about how the rendering model for React has evolved over the years. Uh, I thought this was just a really great breakdown of why. [24:25]
-
-We've gone from why React is pushing server components and like what the value proposition there is. It has a really great series of diagrams showing like, all right, this is how, this is how data fetch and resource loading happens in a single page application versus an SSR application versus now what React server components unlock. [24:47]
-
-And just showing like the data flow of like server to client. And it really does a good job of illustrating those waterfalls and how those waterfalls end up hap end up being imposed by the rendering model and how server components change that rendering model to enable fewer waterfalls to happen. another good resource talking about new things unlocked. In React 19, there was a good post talking about build time components, which is distinct from like server side rendering or server components, pretty related to like, you know, SSG, static site generation. Yeah, static site generation. [25:22]
-
-If you say that acronym SSG, the presumption is that that refers more to something like Gatsby, which is a one time, it doesn't have a server, it has static generation. so this, this discusses build time components, I think sort of as a complement to server rendering or server components, where as part of the build step, as part of, you know, your transpilation and compilation and whatever, you can statically generate. [25:47]
-
-Some of your, some of your resources, some of your pages, some of your components. I thought that was a good call out as new technical capability. Returning back to my earlier thought on the cheat sheet, I saw in real time Kent C Dodds learning that you can return a Promise from a component. So just like earlier this month, he put out on Twitter like, oh, you can, you can just do this. [26:08]
-
-You can just mark it as async. Amazing. So just to drop the link to a good thread in there, but really good. I'm not sure what the difference is between that. You know, classic suspense, throwing a based thing and just doing an async function. [26:22]
-
-## [A milestone for TypeScript Performance in TanStack Router](https://tanstack.com/blog/tanstack-router-typescript-performance)
-
-**Carl:** Moving on. TanStack had a really great post discussing a performance optimization they did for TanStack Router. [26:29]
-
-This is a very different type of performance optimization than most that we see discussed. This is not like runtime performance. This is not, you know, how the library works while you're using it. This is an optimization they did in your editor. So like, as your site grows larger, because their routing is type safe, it's actually doing a lot of, it's actually throwing a lot of work at the language server, at the TypeScript language server that your IDE is running. [26:56]
-
-In this blog post, they break down a pretty complicated site that has, I think they say, This example has 400 route definitions with validated search parameters, and I, you know, it takes like three seconds for the language server to get back to you. So, like, if you're writing code and you, like, open IntelliSense to see, like, oh wait, what, what query strings can this receive? [27:17]
-
-Like, sitting and waiting for three seconds as it parses that. Not great. but yeah, they talk about improvements they did for that. And just because, like, type safe routing is super cool and super difficult, and like, how often do you think about the performance of the TypeScript language server in your IDE? [27:34]
-
-For me, never. so just seeing this, like, Deep technical write up of how they've improved the performance of something that I have never thought about is pretty great, pretty interesting. [27:46]
-
-## ["we’ve decided to make a few changes to ease the adoption of Next 15"](https://x.com/feedthejim/status/1829569083777437745)
-
-**Carl:** Cool, an update on Next 15, which is not out yet. Yeah, they said, we've decided to make a few changes to ease the adoption of Next 15. [27:54]
-
-We'll relax the React 19 requirement for the Pages router so you can upgrade in your own time. I appreciated this because my read on the Next. Ecosystem right now is that there's a lot of attention being paid to the app router, but technically that's Bleeding Edge. That's the newest, still experimental grade, kind of. [28:14]
-
-So they encourage you to use it in the same way that open source maintainers encourage you to use release candidates. But strictly speaking, the Pages router is still where the business is. So seeing them talk about sending support for that into React 19 seems good. Bethany, for the app router, we decided not to block on the general release of React 19. [28:34]
-
-So I guess that they are looking to release. Finished non-experimental app router, before or, or they're decoupling released app router from the React 19 release. [28:45]
-
-**Mo:** Does that mean that they would ship the app router apps if you start a new app, router app with Next, that it would just be using like an RC of React 19, or would it just be using React 18 unless re 19 gets launched? [28:59]
-
-**Carl:** There was some confusion a while ago because they were using release candidates by default. Uh, I don't remember where that landed off the top of my head right now, but I think that's right, but I can't answer you definitely. I'm just looking at this thread again and I see someone ask a very similar question. [29:15]
-
-How do you relax the React 19 requirement when React is bundled into Next? Do you maintain a release for 18 and 19? Did not get a response, so not sure. This is kind of continuing the trend of version confusion with Next and React, like, it's not very clear. [29:33]
-
-**Mo:** I wouldn't personally feel comfortable using an RC with Next, if, Next 15, if they say, we've tested it, it's stable, but then at the same time, I wouldn't trust it to work well with React 18 either, because I would suspect they haven't tested that enough. [29:46]
-
-So, you're in this no man's land where you're like, do I just stay on Next14 until it's actually, you know, stable and React 19 is launched and out of our seat? Interesting questions. [29:57]
-
-**Carl:** Yeah. Confusing, but a similar, you know, vein of confusion as we've had for like most of 2024. That confusion has not been cleared up. Confusion remains. [30:07]
-
-## Trademark disputes!
-
-## [Oracle, it’s time to free JavaScript](https://javascript.tm/)
-
-**Carl:** There's been a couple of trademark dramas this month. Like, I don't know why all the trademark stuff is coming out of the woodwork right now, but um, the Deno team put out a, like an open letter requesting that Oracle release the trademark for JavaScript. and this is one of those like, Funny, weird like quirks of history that not that impactful, but it is still a thing. [30:27]
-
-Like Oracle owns the trademark for JavaScript. Like the reason that the TC39 standards body that determines what JavaScript is technically They are not building JavaScript. They're building ECMAScript, which ECMA is an international standards body. And the reason it's called that is because Oracle owns the trademark on JavaScript. [30:47]
-
-And they have done nothing with it. They have not enforced it, as far as I know, in a decade. They have not They haven't done anything with it. So, yeah, the Deno team is asking people to sign a letter. so, I would encourage you to do so. I have signed this letter. I think it's great. I would love for Oracle to be less in the web ecosystem. [31:04]
-
-Please. [31:05]
-
-**Mo:** I don't think I knew that Oracle had the trademark for JavaScript until I saw this. I don't know if you did, but it was, uh [31:11]
-
-**Carl:** I did know that. I mean, it's one of those stupid things. Like, it's called JavaScript because they were trying to, like I don't know. Ape on the popularity of Java back in the 90s, even though there's no relation. [31:23]
-
-So it's like, I think because I, I think it was something like in those early days, Oracle was like, no, no, no, no, hang on. You can't call it JavaScript. We own Java. And so I think that's how they ended up owning it, but then they didn't do anything in JavaScript or in the web because they're Oracle. And yeah, so it's just one of those like weird quirks of history. [31:40]
-
-So this feels like writing a wrong to me in a way that like, yes, please, let's resolve this tech debt, like get out of there. [31:46]
-
-## [WP Engine v Automattic](https://x.com/photomatt/status/1838738735795703976)
-
-## (https://x.com/justinferriman/status/1838356417482514842)
-
-**Carl:** And this is a little far afield from React, but there's been some WordPress drama. my, I don't do WordPress. I've never worked as a WordPress developer. So this is a little bit of me catching up on stuff. [31:59]
-
-But so my understanding of this is that there's. the WordPress maintainer is Automatic with two T's, and then there's a, another company called WP Engine that seems to, I think they're like a services business, I think, so I guess it's, it's a little bit like If there were two Vercels, like an official one that was actually maintaining Next, and then another one that, like, didn't actually do very much of the maintenance, but also provided all of the same, like, hosting, just with a different set of defaults. [32:26]
-
-And if that other actor that did not do all the maintenance work and the development work was making way more money than the people actually building on it. So, that's my understanding of the difference between Automatic and WP Engine. Is that WP Engine makes a lot more money and contributes less. so the CEO of Automatic has gone on a bit of a tear and it seems not great to me. [32:48]
-
-They are now accusing WP Engine of like infringing on the trademark of WordPress by way of introducing confusion. Like people think that WP Engine is, you know, WordPress engine and they think that they play a larger role in the ecosystem than they actually do. But they've done so, Automatic has done this by sending a cease and desist that doesn't, I don't know, it seems not great. [33:10]
-
-## [Trademark diff seems targeted](https://www.diffchecker.com/tJ29tGIn/)
-
-**Carl:** There's, um, the trademark page, I saw a diff, like, just in the last week, like, as they sent the cease and desist, Automatic updated the trademark information page from saying, you can do whatever you want with the abbreviation WP, to you can do anything you want That doesn't add confusion to the ecosystem, and also WP Engine is not great and we don't like them. [33:30]
-
-And so it's just like they specifically called out this organization that they are sending a cease and desist to in updating their trademark guidelines. It's just like, Oh, Oh, okay. I feel like if you wanted to make that argument and you needed to make it 10 years ago when they started. So it's drama, some big drama happening in WordPress right now. [33:49]
-
-## ["You're writing a vite-based SPA. You need to add a few API routes (i.e., for authentication). What do you do?"](https://x.com/aboodman/status/1836470815862460506)
-
-**Carl:** I saw a great. Twitter post from someone who is doing like a sync engines and lots of other like local first type development that I find very interesting. He posed the question, you're writing a Vite based SPA. You need to add a few API routes like for authentication. What do you do? And got a lot of engagement and I thought it was just a really good discussion. [34:11]
-
-I wanted to draw a little bit of attention to it just because a lot of great opinions coming out in there. I have recently been playing with. Cloudflare workers. And to me, they hit this really great niche that is perfect for this. Cloudflare workers are basically like serverless architecture. You, you know, set up a handler, and like, you don't do any of the infrastructure administration yourself. [34:31]
-
-It just, you know, starts up and stops. But they do it way better than anyone else that I've played with so far. Like, you know, I've used Lambdas and some other similar, you know, serverless architecture things, and all of them have, you know, Awful, terrible, brutally bad developer experience. Like, uh, this is a couple years out of date, so I think it's changed, but I don't think it's changed that much. [34:53]
-
-I, I just remember having to upload a zip file into AWS in order to test, in order to deploy changes to a, to a lambda function that I had written. And like, There's no environments, there's no way to say like, this is in test, this is in production, there's no way to test locally. So then like, this entire serverless framework spun up around that to try and make it better, but like, oops, it didn't actually work that way. [35:14]
-
-It didn't, it didn't match functionality, so it didn't serve the purpose. So yeah, I think for me this, the answer to what do you do if you need to add a few API routes is set up Wrangler, and then in locally and use Cloudflare Workers. [35:28]
-
-**Mo:** You stole the words from me, basically, which was I would use Cloudflare Workers for a few reasons, like AWS's serverless model means that you're still managing your infra to some degree, like what region do you place your serverless function? [35:41]
-
-How does it scale? How does it, you know, uh, how do you do API routing? Maybe you'll need to add another layer, with API gateway in front of it. It's not, like, Straightforward. And so Cloudflare Workers for me was like truly serverless because it's just a function that runs close to the users, somewhere on a CDN, and you get access to run some JavaScript somewhere on the edge, which is really quite cool. [36:03]
-
-there's some stuff around, you know, like I think that there's some trade offs, like you can't use Node packages, it's a custom runtime, and you know, if you want to use a specific router, like there is Hono as an example that you can use within Cloudflare Workers to do API routes. Auth is not as straightforward, I'd say. [36:19]
-
-So, like, for small tidbits And, you know, tasks that I just need something that runs without me worrying about it, definitely Cloudflare Workers. And so, shameless plug, I did a talk with, a very close friend of mine, Samuel McLeod, who now actually works at Cloudflare and is on the Wrangler team, so he works directly on Workers, and we were talking about how do you Move your front end code to live on the edge in Cloudflare Workers with minimal effort. [36:43]
-
-## [Mo's talk at Future Frontend 2024](https://youtsi=AsVqdVrxbiO9nyW9)
-
-**Mo:** So it's a, it's a, it's a talk that we did in Finland this year. Um, so, I'll share the link. but basically the gist of this was what if you could just take your use states that you have inside of your app and change it to use server state with a different import from a third party library and it would automatically just pop it inside of a durable object on the Cloudflare Worker environment. [37:02]
-
-And so there's a lot of cool magic and a lot of cool primitives that they've got that lets you build on top of, and I really like it. If I wanted to build a little bit more full fledged, you mentioned Auth as an example, maybe. I quite like Superbase these days. It's relatively simple. You know, you can run Deno functions within it. [37:18]
-
-It also has a database model, which, you know, is managed for you. It's kind of, for mobile devs, I think it's The better Firebase, which, you know, Firebase promised to be the way that you don't have to write back end code for a mobile dev, and then it really wasn't great. and I think Superbase is a little bit nicer, and it's also relational DBs, which I prefer personally, so. [37:38]
-
-It kind of just works. [37:39]
-
-**Carl:** Pretty much the major constraint of a serverless runtime is they pretty much have to be stateless because, you know, they start up and they spin it down. So if you want to persist state, you need to maintain some kind of other infrastructure to, you know, some kind of database or something like that, which like, as soon as you start running your own server for a database or something like that, like, well, why not just put the code on there too? [38:01]
-
-And Cloudflare workers give you both durable objects. Which are interesting and cool, and I haven't played with them very much, because they also have a key value store that is like this. Dead simple. It works basically like local storage with shared context between invocations of your workers, which just like, if I'm doing something small that I don't want to spend like a week setting up new infrastructure and then don't want to have to maintain that over time, like something that I can just forget about for two years and then come back to and go like, what, how, how the hell does this work? [38:33]
-
-Workers. Love it. I guess I should while hyping Cloudflare and workers so much, I should probably mention that they are like basically the only stocks that I individually own that isn't in an ETF, because I like Cloudflare. But yeah, that's, I don't know if I have a conflict of interest, but. [38:50]
-
-**Mo:** That is a vote of confidence, Carl. [38:51]
-
-**Carl:** I'm trying to put my money where my mouth is. Or, you know, now I'm putting my mouth where my money already was. ( both laugh) [38:57]
-
-**Mo:** is this some sort of, like, ramping up stock prices? I don't know. Yes, yes. [39:03]
-
-## [Nitromodules released to the public](https://mrousavy.github.io/nitro/)
-
-**Mo:** There's just a very quick update on NitroModules, which we talked about last month. And so, uh, NitroModules is this way to run faster native code from React Native. [39:12]
-
-And, uh, it's now been released to the public. And so a few people have been playing around with it. William Candillon, who builds React Native Skia and now React Native WebGPU, or WGPU, so to speak, is now using it on his project, and a few other people I know are experimenting with it. So we'll see some cool results, and I think it'll hopefully improve the performance of the React Native ecosystem as a whole. [39:31]
-
-## [NodeJS adds an experimental permission model](https://twitterstatus/1830621784770555915)
-
-**Carl:** Um, Node. js is taking a cue from Deno and they are adding a permissions model. I think this is super cool. I thought the permissions model is something that Deno got right. I think it's just very interesting to, rather than just allow all the permissions that your process has, being able to signal to the process, what this code is going to need to access. [39:56]
-
-Um, I think that's a, I think that's really good and interesting and useful, especially in alternate runtime environments like workers, like serverless environments and things like that. An example where this would be useful. I remember a couple of years ago, uh, someone in Reactiflux set up a little five project allowing anyone to execute code from within the chat. [40:15]
-
-Yeah. Um, so you could just, you know, like, use some chat command with a code block. They had set up a bot that would pull that code block in, execute it, and spit out the output. They were able to do that, I believe, because of Deno's permissions model. Because they could guarantee that the code only had access to this very tight sandbox. [40:32]
-
-You know, if you're running code from arbitrary people in a chat room, that's very dangerous. So you need an effective permissions model. So, um Now we have that. Now Node. js has that. Uh, maybe not relevant for most people, but especially if you are working on something that would allow, or that would benefit from allowing your users to run code, run arbitrary code, Node. js now supports that better, at least. [40:54]
-
-## [TypeScript with React styleguide ](https:/typescript-style-guide/#appendix---react)
-
-**Carl:** This isn't new. I don't think I, I have, no, it's undated. I don't know when it came out. but I just crossed my radar and I like it. It's a TypeScript style guide. they have a, they have a react appendix that I, I thought was pretty neat. And just, I love a good style guide. [41:09]
-
-Another common question in Reactiflux is like, what are the best practices? Well, there's a lot of practices. Some of them are worse than others. Some of them are good generally in all circumstances. Some of them only make sense in a very narrow range of circumstances. [41:23]
-
-So just like, what are the best practices is a very difficult question to answer. And I think this TypeScript style guide does a pretty good job of Outlining a decent range of them. You know, some of them are opinionated, like it talks about project structure and like how to organize your source code and like, okay, there's a lot of ways to do that acceptably. [41:40]
-
-but something in the, you know, the first thing it talks about in the React Appendix is like required versus optional props. And. It calls out props as a discriminated type, which is, it's so good. Instead of having a props object with a bunch of optional values, doing it as a group of different, you know, fully formed Types. Uh, so like, you know, the example they give is like a status indicator. Instead of saying like data, you know, error, status as like optional props, just saying like, no, no, the success status has a status value of success, data with this type, whatever. Then the loading status has, says this That's so much better. Like that is absolutely a best practice. So, um, Good resource, I enjoyed it. it had a couple of, maybe it's just because its opinions align with my own opinions, but I thought it was a really good resource. Definitely recommend it. And also, more generally, on the subject of style guides, I think a style guide is a wonderful resource to bring into your company. [42:44]
-
-Uh, the most effective teams I've been on have had a style guide document that was routinely updated. Just, uh, if. I think it's a really great anchor point for technical discussions. Like, if you have a technical argument with your team about, like, we should not be doing this, this is bad. Argument should have an output in the form of a PR to a style guide. I think that's really great. [43:05]
-
-## [Inside ECMAScript: JavaScript Standard Gets an Extra Stage](https://thenewstack.io/inside-ecmascript-javascript-standard-gets-an-extra-stage/)
-
-**Carl:** Not new news, but a good resource. We've talked briefly in previous months about the TC39 ECMAScript standardization process. You know, there's four stages, you can present an idea in stage one, then if you do X technical work, it gets to stage two. Stage three is like, basically standardized, but it's not shipped yet, and stage four is like, fully shipped. [43:27]
-
-There has been a problem over many years of a lot of things getting stuck at stage two. The transition between Stage 2 to Stage 3, and then like, oh, we found a new problem in Stage 3, so we gotta ship it back to Stage 2. Just like, the delta between Stage 2 and Stage 3 has turned out to be very, very large, in a way that has made it difficult to ship some of these proposals. [43:50]
-
-Just like, If it gets shipped back down to stage 2, that has some problems. So this article from The New Stack just did a really good job of explaining more of that history than the half assed summary that I just gave, and talks about the stage 2. 7, you know, sub stage that they added relatively recently. [44:09]
-
-It sounds like the gist of it is that if you've written tests for your thing, then getting bumped back all the way back down to stage two, like, calls into question the validity of those tests. And stage 2. 7 resolves that problem to make it a little bit clearer about what that means. If you're curious about, you know, if there's like, if there's a, proposal that you've been following and are curious about the standardization process. [44:30]
-
-Um, I just think this is a pretty solid resource explaining the history. [44:34]
-
-## [Remix The Web from mjackson](https://github.com/mjackson/remix-the-web/)
-
-**Carl:** cool. I came across a fun project from Michael Jackson, from the Remix team called Remix the Web. Michael Jackson, Ryan Florence have been so involved in the web React, in the React ecosystem for so long. I have always. I've respected them greatly as people who, like, they don't just try to solve a problem. [44:55]
-
-They try to solve a problem in a way that makes sense, given the primitives available on the web. So it's not just trying to do everything in JavaScript. Like a lot, a lot of Java, a lot of React libraries I've seen, they end up, re solving a lot of problems in JavaScript that you might not need to if you just leaned on the web platform a little bit harder. [45:14]
-
-And some of that is because of aspirational support for React Native. If you solve it in JavaScript, then it can work not on the web platform. So like, there's trade offs to doing that. The trade off is that If you write in JavaScript, like, it's probably going to be slower. It's probably going to be worse in some way than if you can use a native, you know, web platform feature. [45:34]
-
-That is the backstory for why I'm particularly interested in this. So, Michael Jackson is putting together a monorepo of modules that are narrowly scoped to do one thing and do that thing well. An example of this that I remember him talking about Years and years ago, in the context of React Router, is they built React Router on top of a primitive, on top of a wrapper they made around the history API. [45:59]
-
-So it's like, in trying to make a router, they found all of these weird, nasty edge cases around managing history, managing scrolls position, things like that, and found the platform feature to be highly deficient. as a, you know, mode of interacting with that. And so they made a wrapper abstraction around that to make it easier to deal with. [46:19]
-
-And so my understanding is that this Remix the web monorepo project is a bunch of those. So like in, if they find, A rough and grody, web platform feature, they write a wrapper around it, and into this repo it goes. So, uh, I'm interested, it seems curious, it seems pretty cool to me, I have certainly found a lot of platform features that don't do quite what I want, so, uh, I'm, yeah, I'm paying attention to it. [46:41]
-
-Seems cool. [46:42]
-
-## [Replacing React code with CSS :has selector](https:/posts/replacing-react-with-css)
-
-**Carl:** And somewhat related to the idea of solving things with JavaScript, I saw a good blog post titled, Replacing React code with CSS colon has selector. The gist of it is, I'll pull a quote. Until recently, we couldn't select objects in the opposite direction of the CSS cascade. You know, CSS is top down. [47:06]
-
-You can get, you can start from the top and it gets more specific. So you can say, in all of these elements that are under this type of parent, style it this way. But you can't, you couldn't say previously, in this parent, if it has this type of element within it, style it this way. It was a, it was sort of a, you know, unidirectional control flow in that way. You could style descendants based on their parents, but you couldn't style parents based on their descendants. And the CSS Has Selector enables you to do that, which I have run into so many situations where I wanted to do that, and you just can't. You just couldn't. So, uh, you end up having to solve it with JavaScript to like add a little bit of state to communicate whether some element is within it. [47:51]
-
-And yeah, so the CSS has selected something I've been wanting for a really long time, and I really appreciated that. I'm seeing it framed as, here's all the things you can stop doing with React because of this CSS feature. And yeah, it's written by Nadia Makarevic. I hope I'm not mispronouncing that. She also wrote a great book on React as well. Yeah, just really, I really enjoy her writing. She seems like a great writer and seems to pick good topics. I like it. [48:19]
-
-## [Performance Optimization Strategies for Large-Scale React Applications](https://old.reddit.com/r/reactjs/comments/1f6abzy/performance_optimization_strategies_for/)
-
-**Carl:** And last lightning round link, just going to call out a Reddit thread. I've started, I set up a thing to pull in top posts from Reddit into the tech reads and news channel, and it's served us some good stuff. [48:31]
-
-I like it. But yeah, somebody asked the question, somebody asked about. Performance optimization strategies for large scale React applications and it got a decent amount of response. So I just thought that was a good, I just wanted to call attention to a cool thread full of a lot of opinions. It seemed like a good thing. [48:47]
-
-I didn't really see anything that like massively caught my eye as like, this is the right thing to do. But it did get quite a few Lengthy explanations of how some person or another has done performance optimizations at work. Uh, and that was always a big part of my work. My career has always, I've put a lot of emphasis on performance optimizations. [49:08]
-
-Wanted to call that out. Go read it. It's good. [49:10]
-
-## Outro
-
-**Carl:** Cool. Alright, that's everything we got. thank you for joining us. We will be back on the last Wednesday of October here in the live stage or back in your podcast feed just as soon as we can, if that's how you listened. We gather sources from This Week in React, Bytes. [49:23]
-
-dev, React Status, Next. js Weekly. The React js subreddit here in Reactiflux and direct from those publishing articles. usually on Twitter, maybe on blue sky, maybe on RSS feed. Lots of things. If you see anything newsworthy, uh, definitely let us know in the tech News and reads channel of Reactiflux. [49:39]
-
-Or send it directly to me hello@reactiflux.com, uh, with TMIR in the subject line. It's an acronym for the show. I read literally every email that comes in, even the spam. So yeah, if you've got a hot tip, send it to me and I'll read it. if this is a show that you get value from and want to support, best way to do so is by submitting a review on Spotify, which helps us, Rank? [50:01]
-
-I'd say stay in the rankings, but like, we don't rank, so, you know. Or, you know, post it on Twitter, send it to your co workers, stuff like that. Appreciate it. Thanks for listening. [50:08]
-
-**Mo:** Always fun to do this every single month. Thanks, for having me, and hopefully I'll see you all at some point in person, somewhere, maybe at the, uh, RNLConf. [50:15]
-
-Till next month.
diff --git a/src/transcripts/tmir-2024-10.md b/src/transcripts/tmir-2024-10.md
deleted file mode 100644
index 5013bb5..0000000
--- a/src/transcripts/tmir-2024-10.md
+++ /dev/null
@@ -1,751 +0,0 @@
----
-title: "This Month in React, October 2024: React DevTools update, React Native 0.76 (new architecture dropped), Web Components are(n't) the future"
-date: 2024-10-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:56](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- [[01:40](#new-releases)] New releases
- - [[01:43](#react-native-076-proper)] [React Native 0.76 proper](https://reactnative.dev/blog/2024/10/23/release-0.76-new-architecture)
- - [[01:54](#new-architecture-is-here)] [New Architecture is here](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here)
- - [[05:18](#bluesky-and-expensify)] [BlueSky](https://github.com/bluesky-social/social-app/releases/tag/1.92.0-na-rc.2) and [Expensify](https://blog.swmansion.com/sunrising-new-architecture-in-the-new-expensify-app-729d237a02f5)
- - [[06:22](#react-compiler-beta)] [React Compiler Beta](https://react.dev/blog/2024/10/21/react-compiler-beta-release)
- - [[07:23](#react-devtools-v6)] [React DevTools v6](https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#600)
- - [[07:50](#zustand-v5)] [Zustand v5](https://github.com/pmndrs/zustand/releases/tag/v5.0.0)
- - [[08:17](#eslintpluginreacthooks-v5)] [eslint-plugin-react-hooks v5](https://github.com/facebook/react/releases/tag/eslint-plugin-react-hooks%405.0.0)
- - [[08:45](#announcing-deno-2)] [Announcing Deno 2](https://deno.com/blog/v2.0)
- - [[08:45](#rbun-deno-2-vs-bun-what-are-your-thoughts-rdeno-deno-2-vs-bun-what-are-your-thoughts)] /r/bun: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/bun/comments/1fp9ndk/deno_2_vs_bun_what_are_your_thoughts/) [](https://www.reddit.com/r/Deno/comments/1fp9mom/deno_2_vs_bun_what_are_your_thoughts/)
- - /r/deno: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/Deno/comments/1fp9mom/deno_2_vs_bun_what_are_your_thoughts/)
- - [[10:14](#tauri-20)] [Tauri 2.0](https://v2.tauri.app/blog/tauri-20/)
- - [[11:40](#one-the-new-rn-framework)] [One - the new RN framework](https://onestack.dev/)
- - [[11:40](#creators-of-tamagui)] Creators of [Tamagui](https://tamagui.dev/)
- - [[11:40](#built-on-zerosync)] Built on [ZeroSync](https://zerosync.dev/)
- - [[16:15](#cloudflare-workers-updates)] [Cloudflare Workers updates](https://blog.cloudflare.com/builder-day-2024-announcements/?ck_subscriber_id=1888282043/)
- - [[22:05](#zeego-20)] [Zeego 2.0](https://github.com/nandorojo/zeego/releases/tag/v2.0.0)
-- [[22:33](#conferences)] Conferences
- - [[22:35](#halfstack-london-london-uk-nov-13)] [HalfStack London](https://halfstackconf.com/london/spon) London, UK Nov 13
- - [[22:40](#react-native-london-london-uk-nov-15)] [React Native London](https://guild.host/events/rnlconf-2024-y9arho/attend?discount=TMIR) London, UK Nov 15
- - Special Discount for podcast listeners with discount code TMIR
- - [[23:10](#react-summit-us-new-york-usa-nov-1821)] [React Summit US](https://reactsummit.us/) New York, USA Nov 18-21
- - [[23:14](#react-africa-casablanca-morocco-nov-29)] [React Africa](https://react-africa.com/) Casablanca, Morocco Nov 29
- - [[23:19](#react-day-berlin-berlin-de-dec-13-&-16)] [React Day Berlin](https://reactday.berlin/) Berlin, DE Dec 13 & 16
-- [[23:33](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red)
-- [[24:50](#some-react-19-progress-but-no-eta)] Some React 19 progress, but no ETA
- - [[24:50](#lazy-context-propagation)] [Lazy Context Propagation](https://x.com/sebastienlorber/status/1841042683122286641)
- - [[25:51](#“server-actions”-renamed-to-“server-functions”)] [“Server Actions” renamed to “Server Functions”](https://19.react.dev/reference/rsc/server-functions)
-- [[26:08](#react-native-bottom-tabs-library-using-native-bottom-tabs)] [React Native Bottom Tabs library using native bottom tabs](https://github.com/okwasniewski/react-native-bottom-tabs)
-- [[27:45](#meta-connect-showcasing-new-arvr-apps-built-with-rn)] [Meta Connect showcasing new AR/VR apps built with RN](https://engineering.fb.com/2024/10/02/android/react-at-meta-connect-2024/)
-- [[29:07](#static-hermes-updates)] [Static Hermes Updates](https://github.com/EvanBacon/expo-static-hermes-demo)
-- Reddit is revolting against Epic React
- - [[30:16](#anyone-else-feel-burnt-by-epic-react--rreactjs)] [Anyone else feel burnt by Epic React? : r/reactjs](https://old.reddit.com/r/reactjs/comments/1fwks6r/anyone_else_feel_burnt_by_epic_react/)
- - [[30:42](#epic-react-v1-=>-v2-upgrade-&-deception)] [Epic React V1 => V2 Upgrade & Deception.](https://old.reddit.com/r/reactjs/comments/1fut75h/epic_react_v1_v2_upgrade_deception/)
-- [[37:12](#web-components-are-not-the-future)] [Web Components Are Not the Future](https://dev.to/ryansolid/web-components-are-not-the-future-48bh)
- - [[37:12](#followup-to-this-from-march-2020-maybe-web-components-are-not-the-future)] Followup to this from March 2020: [Maybe Web Components are not the Future?](https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh)
- - [[37:34](#web-components-are-not-the-future--they’re-the-present)] [Web Components Are Not the Future — They’re the Present](https://www.abeautifulsite.net/posts/web-components-are-not-the-future-they-re-the-present/)
- - [[37:53](#liskovs-gun-the-parallel-evolution-of-react-and-web-components)] [Liskov's Gun: The parallel evolution of React and Web Components](https://www.baldurbjarnason.com/2024/liskovs-gun/)
-- [[44:10](#announcing-voidzero-next-generation-toolchain-for-javascript)] [Announcing VoidZero - Next Generation Toolchain for JavaScript](https://voidzero.dev/posts/announcing-voidzero-inc)
- - [[44:37](#oxc-transformer-alpha)] [OXC compiler](https://twitter.com/boshen_c/status/1840322879424258115)
- - [[44:37](#oxc-compiler)] [OXC Transformer Alpha](https://oxc.rs/blog/2024-09-29-transformer-alpha.html)
-- [[45:23](#updates-from-the-104th-tc39-meeting)] [Updates from the 104th TC39 meeting](https://dev.to/hemanth/updates-from-the-104th-tc39-meeting-14cp)
- - Stage 4 proposals
- - [[45:33](#promisetry)] [Promise.try](https://github.com/tc39/proposal-promise-try)
- - [[46:21](#sync-iterator-helpers)] [Sync Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers)
- - [[46:48](#import-attributes)] [Import Attributes](https://github.com/tc39/proposal-import-attributes)
- - [[46:58](#json-modules)] [JSON modules](https://github.com/tc39/proposal-json-modules)
- - [[47:05](#regexp-modifiers)] [RegExp Modifiers](https://github.com/tc39/proposal-regexp-modifiers)
-- [[47:11](#language-evolution-jssugar-proposal)] [Language Evolution](https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o/edit#slide=id.g30432c5cd9c_0_30) “JSSugar” proposal
- - [[47:11](#nullvoxpopuli-on-x)] [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389133810913338)
- - [[47:11](#nullvoxpopuli-on-x)] [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389157693227375)
- - [[47:11](#brendaneich-on-x)] [BrendanEich on X](https://x.com/BrendanEich/status/1842630141304025263)
- - [[47:11](#daniel-ehrenberg-thoughts)] [Daniel Ehrenberg thoughts](https://gist.github.com/littledan/a590784a72f2e1b8cc633ff5ff8a9dc2)
-- [[50:44](#⚡-lightning-round-⚡)] Lightning Round
- - [[50:44](#the-disappearance-of-an-internet-domain--io)] [The Disappearance of an Internet Domain](https://every.to/p/the-disappearance-of-an-internet-domain) – .io
- - [[51:51](#how-to-control-a-react-component-with-the-url)] [How to control a React component with the URL](https://buildui.com/posts/how-to-control-a-react-component-with-the-url)
- - [[53:16](#if-wordpress-is-to-survive-matt-mullenweg-must-be-removed)] [If WordPress is to survive, Matt Mullenweg must be removed](https://joshcollinsworth.com/blog/fire-matt)
- - [[55:09](#web-without-walls--dan-abramov)] [Web Without Walls — Dan Abramov](https://www.youtube.com/watch?v=F1sJW6nTP6E)
- - [[57:23](#preact-compat-discussion)] [Preact compat discussion](https://old.reddit.com/r/reactjs/comments/1fy2jjh/i_ran_into_preacts_false_promise_what_can_i_do/)
- - [[57:44](#content-visibility-in-css)] Content-visibility in CSS
- - [[57:44](#using-css-containment)] [Using CSS containment](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Using_CSS_containment)
- - [[58:00](#contain-caniuse)] [contain](https://developer.mozilla.org/en-US/docs/Web/CSS/contain) - [CanIUse](https://caniuse.com/mdn-css_properties_contain)
- - [[59:50](#contentvisibility-caniuse)] [content-visibility](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) - [CanIUse](https://caniuse.com/mdn-css_properties_content-visibility)
- - [[01:00:39](#how-i-built-my-blog-•-josh-w-comeau)] [How I Built My Blog • Josh W. Comeau](https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2/)
- - [[01:02:24](#types-of-react-components-2024)] [Types of React Components 2024](https://www.robinwieruch.de/react-component-types/)
-
-**Carl:** Hello everyone. Thank you for joining us for the October edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. [00:14]
-
-And we're supported by Infinite Red, a consultancy that exclusively works with React Native, but we'll do a little ad read for them later. [00:21]
-
-Hello, I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux where I run community programs like these events and the star helpers, and do other stuff to keep the community running smoothly. [00:33]
-
-**Mark:** Hi, I'm Mark. My day job is at replay. io, which we're going to have a slight tangent on the io part of this later on. And other than that, on Redux stuff. [00:43]
-
-**Mo:** The mobile team at Theodo which is a global consultancy and I'm active within the React Native ecosystem, organizing the React Native community and here and there dabbling in some open source. Happy to be here as always. [00:56]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Yeah. First up, some quick hits while people start filtering in. We did not do a job market update last month. It was actually pretty quiet. Not a lot of news. It seems kind of back to baseline. data for posts made to Indeed is still, like, two thirds of what it was at the beginning of 2020 before pandemic hit. [01:14]
-
-that might have been a high watermark for the industry, so it's, it's kind of hard to say. Layoffs at least have been, look very low for the last two months in a row. So that seems good, but yeah, the hiring has not really picked up. But not sure it's going to. [01:29]
-
-I wonder about that. Definitely the vibe I've been getting is that most of the roles being hired for are more on the seniors end of the scale, which is Not ideal, not great, but yeah, seems to be where it's at. [01:40]
-
-## New releases
-
-**Carl:** Yeah, into some new releases. [01:41]
-
-Moe, you want to tell us about React Native? [01:43]
-
-## [React Native 0.76 proper](https://reactnative.dev/blog/2024/10/23/release-0.76-new-architecture)
-
-**Mo:** Yes, indeed. I feel like this is years in the making, so I've got to really drum this up as much as possible. But, the new architecture is finally here, [01:54]
-
-## [New Architecture is here](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here)
-
-**Mark:** Woohoo! [01:55]
-
-**Mo:** So this is React Native version 0. 76. And if you go back into likethe history of React Native over the last five years, the first mention of the new architecture publicly was in 2019. [02:08]
-
-And really what the whole purpose of the new architecture was, was to make a more stable Baseline for React Native interacting with native platforms. How components are rendered. How does JavaScript code trigger native code and native modules? And how do we move different things around different threads and make sure that everything is optimized and consistent? [02:28]
-
-A lot of people think that the new architecture is like a performance oriented update. It doesn't really have that many major performance improvements. There's minor ones, but really what it's trying there for mainly is, I think, for library maintainers and for framework authors to be able to create a more consistent pattern of communicating between native and React Native. [02:47]
-
-So, for a little bit of context, React Native's old architecture used this thing called the bridge. So it was basically a messaging bridge where you could pass in serialized JSON from the JavaScript layer and from the native layer and it would kind of get communicated across this bridge. But the issue with a bridge is that it can have some traffic, right? [03:03]
-
-So you can bombard it with a lot of JSON and suddenly because it's asynchronous it has limits in terms of how much it can communicate if you were trying to update things frequently or send a lot of data through that bridge you would block that, and what we would call that is that the JS thread is blocked, and so your app would basically drop in its frame rate, the CPU usage would spike, and everyone would be unhappy, and your users would be like, Hmm, this is not quite native feeling to me. [03:30]
-
-But, as of now, there's been a lot of work that's been done. React Native has a bunch of different stuff that I'm not going to go into too much detail about. But the bridge has been replaced with what we call the JavaScript interface. And so what that means is JavaScript code can get a reference to a C object that communicates with a native layer, and it can directly invoke methods within that C layer that would live on the native layer. [03:51]
-
-So it removes the bridge and it's just direct communication via JavaScript interface to the native layer. So that makes things significantly more efficient. It's not just that, the new architecture is a lot of different parts. There's the new event loop, there's the new renderer and then there's the new native module system, and of course the JSI, which is kind of underpinning all of that. [04:11]
-
-the article that you shared in the chat has a lot of details and it's a good summary, so I would start from there if you've been kind of under the rocks. In the React Native ecosystem and not,really hearing much about the new architecture. I think it's a really good summary about why it matters, what you can achieve. [04:25]
-
-And ultimately, I think one of the biggest things is that it's giving you parody with React behaviors, because a lot of things that were in React before just didn't work in React Native properly and people were figuring that out on usage. Basically, it wasn't really documented very well anywhere. very exciting times. [04:40]
-
-it's finally happened. [04:42]
-
-**Carl:** Yeah, I feel like this is an update that's a little easy to be, you know, under a rock on. If it's been in progress for literally five years now, I could see how that might slip into the back of your mind as something like, There's a lot of things I waited five years for, and by about the third or fourth year, I started wondering if it was ever going to actually happen. [05:01]
-
-**Mo:** exactly, and you know, it's one of those things where yeah, it's been happening for five years, but you do get new architecture talks every conference that's a React Native conference or like React Native adjacent. So it's been the topic of conversation and everyone's like, Oh, that'll probably come at some point. [05:15]
-
-And it feels quite surreal to have it actually here. [05:18]
-
-## [BlueSky](https://github.com/bluesky-social/social-app/releases/tag/1.92.0-na-rc.2) and [Expensify](https://blog.swmansion.com/sunrising-new-architecture-in-the-new-expensify-app-729d237a02f5)
-
-**Carl:** Cool. I saw a post from Software Mansion, which is a React Native focused, consultancy as far as I know, talking about bringing the new architecture into the Expensify app, and I understand that the Blue Sky native app is doing a release candidate for it that's like, opt in, and they say it's, you know, it's a release candidate, it's unsupported, try it at your own risk, please report bugs. [05:41]
-
-But like, those are real apps, like Expensify is widely used enterprise app. So that's some real usage. That's pretty cool. [05:48]
-
-**Mo:** props to the meta team, they actually spent a lot of time with real apps that are large scale apps that, you know, were popularly React Native. They approached the developers of those apps and said, Hey, can you turn on the new architecture before we release and make sure that it's working and behaving and functioning in a way that doesn't really have regressions and is actually better than it was before. [06:06]
-
-So they've really tested this out and drawn it out. They've worked with library maintainers one on one to get them on to the new architecture boat. So, this is as good as it ever will get in terms of just biting the bullet and releasing. [06:19]
-
-**Carl:** Nice. Yeah. [06:22]
-
-## [React Compiler Beta](https://react.dev/blog/2024/10/21/react-compiler-beta-release)
-
-**Mark:** The first one is that the React compiler is now in beta. The first, you know, early adopter, I guess, releases came out at React Conf back in May. And it's now in beta you can actually meaningfully try it out, they've done a lot of work to try to improve the behavior against real world applications. [06:42]
-
-Along with that, there's a couple different ESLint plugins the Rules of React Hooks plugin has been updated, and it's got some additional checks for whether things are actually components. Along with that, the compiler has its own associated plugin that tries to check for the rules of React behavior. [07:02]
-
-You know, basically, are you doing anything that is considered illegal, even if it technically runs inside of your React component? And so they're highly recommending that people start trying to use the rules of React plugin in your applications to find places where you're doing things that you're really not supposed to in React. [07:23]
-
-## [React DevTools v6](https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#600)
-
-**Mark:** Along with that, there's a new React DevTools extension release. They did a lot of shuffling around of the internals, but what is probably most relevant here is that the DevTools now actually have support for showing server components in the tree. And this is a big deal, because up until now there really hadn't been any way to atsee what server components were actually, being used when you were looking at the code on the client side. [07:47]
-
-So that's a pretty distinct improvement there. [07:50]
-
-## [Zustand v5](https://github.com/pmndrs/zustand/releases/tag/v5.0.0)
-
-**Mark:** Flipping away from that over into state management, Zustan just came out with version 5, and it doesn't have any new features, but it does drop some, legacy backwards compatibility changes, default exports, a couple other things, and it now requires React 18. [08:08]
-
-So if you're using Zustan, you may want to look at picking that up. [08:11]
-
-**Carl:** Yeah. Hang on. The Redux guy talking about another state management library. Hold up. [08:15]
-
-**Mark:** I'm allowed to. ( laughter) [08:17]
-
-**Carl:** For sure . [08:17]
-
-## [eslint-plugin-react-hooks v5](https://github.com/facebook/react/releases/tag/eslint-plugin-react-hooks%405.0.0)
-
-**Carl:** There's also a new major version of the ESLint plugin for React Hooks. Looks like it supports ESLint v9, and it doesn't look like there's a lot of changes, I think it's mostly just compatibility for latest versions. But, they did change how the rule works for component names. [08:33]
-
-So now, previously it used to require a non lowercase letter. So it'll let you do things like an underscore in front, and now it doesn't. Now it has to be an uppercase letter. they kind of flipped the bit on that. [08:44]
-
-**Mark:** Picky, picky. [08:45]
-
-**Carl:** Cool. [08:45]
-
-## [Announcing Deno 2](https://deno.com/blog/v2.0)
-
-## /r/bun: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/bun/comments/1fp9ndk/deno_2_vs_bun_what_are_your_thoughts/) /r/deno: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/Deno/comments/1fp9mom/deno_2_vs_bun_what_are_your_thoughts/)
-
-**Carl:** Deno released version 2 as well. We've covered Deno sporadically over the last couple of episodes, but the highlights here that they shout out are backwards compatibility with Node. [08:56]
-
-js and NPM, native support for the package. json and Node modules. I guess that's part of backwards compatibility. More package management, I know, you know, the original idea behind Deno dependencies was just like a little bit more URL based and kind of free for all like no registry just like install code very like go Inspired and I guess they're walking that back pretty hard. [09:21]
-
-**Mark:** they've walked [09:22]
-
-back a lot of things around NPM compatibility. [09:25]
-
-**Carl:** Yes, I feel like they started out heavily opinionated and are walking back a lot of those opinions, which okay I mean, I guess fair enough. They did also do a lot of work on the standard library and things So it could well be that some of those opinions were just like this is less work. [09:40]
-
-We're gonna launch it they've got a standard library Support for private NPM registries. Yeah, a lot of these things are just kind of like details on backwards compatibility with node and NPM they're doing LTS releases. They've got their own JSR, JavaScript, something registry. [09:57]
-
-And there were a couple of threads that I wanted to shout out of exact same title posted in the Bun and Dino subreddits, Dino2 vs Bun. What are your thoughts? I won't summarize them. It's just like a bunch of Reddit commenters, you can see, see the two, the two camps reacting to the news, [10:14]
-
-## [Tauri 2.0](https://v2.tauri.app/blog/tauri-20/)
-
-**Mark:** The Tari framework, which lets you build desktop apps using web technologies as an alternative to Electron just came out with version two. They have some improvements around HMAR and plugins and various other internal improvements. If you're building desktop apps, probably worth taking a look. [10:32]
-
-**Carl:** Yeah, I thought it was neat that they added a permissions model. I guess they used to have like an allow list of things that your app was allowed to do. And they talked a little bit about enhancing that with, you know, a permissions model, which seems like a good improvement. Yeah, they also mentioned mobile support, which was like, what? I feel like they buried the lead on that. It's like, I want to know a lot more about that. I feel like Rust based native app framework where you can use React on Android and iOS. Like, huh, I want to know a lot more about that, but they didn't say too much in the announcements. [11:04]
-
-**Mo:** Yeah, it's, as with all things with thisso it's not official yet with Taure. I think they're just kind of working on it, so I,suspect they're kind of saying, hey, we're working on it. The general gist with all of these Electron like frameworks it ultimately ends upbeing something like Cordova with Ionic. [11:22]
-
-it's a web view that triggers some native functionality. It won't be a truly native app, which is, I guess, one of the distinguishing factors of React Native. But it'd be very interesting to see how they play this out. And how it works in practice. It might be something a bit different, but they're being very cryptic about it so far. [11:38]
-
-So, remains to be seen. [11:40]
-
-## [One the new RN framework](https://onestack.dev/)
-
-## Creators of [Tamagui](https://tamagui.dev/)
-
-## Built on [ZeroSync](https://zerosync.dev/)
-
-**Mo:** Moving on. So, earlier this year the React Native Core team came up with this big announcement saying, Hey, we think you should use frameworks. And not build your own frameworks every time you initialize a new React Native app. And so at that point they introduced Expo as the only option to, as a pre built framework. [11:57]
-
-They said, you know, you're either using Expo, or you've built your own framework by building on top of the core of React Native. And so now we have finally gotten a second framework that's come in and said, Hey, I I'm a contender for that spot as well. the framework is called one. I'm not too sure why there's, that's the naming, but, there we are. [12:16]
-
-You have a theory. All right. [12:17]
-
-**Carl:** so it looks like they're built on a sync engine that's called Zero. ZeroSync. so I guess this is, you know, they're built on Zero so they are one. [12:26]
-
-**Mo:** Cool. So, this is an interesting development because the person who's behind this is behind the library called Tamagui. So Tamagui is a styling library within the React Native Ecosystem. the whole spiel with Tamagui is that it's an optimized view layer library that you can use not just for your React Native apps, but also in things like Next. [12:46]
-
-js. So you can kind of share your UI across the board between React Native and the web. it's used to build these universal apps. Tamagui is quite an interesting project. It's actually a very heavyweight library, because it comes with things like a styling solution, a compiler that, does view flattening. [13:05]
-
-Next. js optimizations out of the hood. it's a very heavy styling solution when you're using it just for React Native, and it's notoriously complicated as well. they've taken Tamagui, paired it with a whole bunch of other stuff, like a file system routing based solution, and the most interesting part, I'd say arguably, is the fact that this is beat based.previous to this, you couldn't use Vite for React Native because you'd have to use either Metro or in some cases you could use Webpack, but it was quite a pain to actually get that working. the creator of this, Nate, has been working on seeing if Vite can become a compiler for React Native. [13:42]
-
-React Native, and it seems like there's some good movement on this. So, it uses Veep by default to kind of standardize the bundler across web and mobile. So, it's a very interesting proposition and they have a lot of experience but it's still going to be interesting to see how this plays out. [13:58]
-
-It's very early days. So, I would Tread with caution until it's reached some point of stability and it's being used. But it's very interesting to see how it's forming. [14:09]
-
-**Carl:** Yeah, definitely early days, but like, I'm taking this reasonably seriously. It seems like a pretty clever and opinionated take on how to do a framework on React Native. I guess, you know, like, my rough mental model for this this feels to me like the React Native equivalent for Remix. [14:28]
-
-in large part because it's beat based, you know, okay. [14:31]
-
-**Mo:** but it has a lot of, like, very similar ideas, right? Like, they've kind of introduced this concept of loaders as well. it's very Remix esque. so I can see why you take that comparison. [14:42]
-
-**Carl:** another thing that I find fascinating here is they put local first and sync engine very heavy in their homepage marketing for this. they talk a lot about this being built on zero sync, which is built by a company that I've heard of and that the CEO follows me on Twitter. [14:57]
-
-I think that's cool. it's being built by a team that worked at a decentralized exchange that I had heard of. Six years ago. So they worked on decentralized tech that I took seriously as someone I also worked in decentralized tech six years ago. So I think it's really interesting that that's the Opinion they're bringing to this company that they named that they worked at Uniswap I viewed as one of the serious contenders in web 3 before it became overtaken by scams So it looks like they have now moved out of Web3, taken that decentralized technology experience, and are building a React Native framework that is based around local first, you know, data on your device, primarily synced to a backend. [15:40]
-
-And I think that's really cool. I am pretty bullish on local first generally, I'm very curious to see how this works. Early days, like you said, it's interesting to me. I am intrigued. [15:51]
-
-**Mo:** and Uniswap is built with Tamagui. So the web and the mobile app is built with Tamagui which kind of is a real implementation, real world production app that's using the universal app paradigm. they know how to do it. It's just a matter of how, easy to use it is for other developers who aren't that familiar with this sort of framework or this [16:10]
-
-**Carl:** it's Yeah, right. It's easy to say how powerful and useful something is when you are the person who made it. [16:15]
-
-## [Cloudflare Workers updates](https://blog.cloudflare.com/builder-day-2024-announcements/)
-
-**Carl:** Cloudflare Workers released a bunch of new updates, and a lot of them look really cool to me. So I'm using Cloudflare Workers a little bit in like, a side project or two. [16:24]
-
-I would like to use it more for ReactiFlux projects, but actually Discord does not allow the gateway to connect to like, the Cloudflare Workers durable objects. For some reason, I don't know why, that seems weird. than the fact that you just can't connect to the API, they seem like a really powerful way to interact with Discord. [16:43]
-
-So, I would love to use them for that. Sadly, I can't. ButI think Cloudflare released, yeah, 18 big updates to the workers platform is the headline here. Literally the title of release. Something that I found really interesting is they are advertising CICD with PR preview releases for workers. [17:01]
-
-I think that's not going to be quite as like turnkey, instantly useful as it is in like Netlify or you know, Vercel where, you know, like, you get a PR preview on your website, you just get a new domain, boom, done, everything kind of works. Assuming you didn't like actively screw something up and how you are doing, you know, base URLs. [17:22]
-
-I think for a backend service like this, it's just not going to be quite so simple and like zero effort to take advantage of PR previews. Like you, you need to have a staging environment where you can be notified of a new URL being available and then dynamically swap out the, like, base route for this. [17:39]
-
-And then like other stuff, like what about. Seeding test data and things like that. So I don't think this is quite so like Mind blowingly immediately useful as it is on a web deployment CICD, but that's still super cool Like that's you know, like for it for a discord bot, which is mostly where I've tried to use these like that's still pretty Accessible. [18:00]
-
-Yeah, so I think that's pretty pretty useful some other smaller stuff Logging on the dashboard for your workers. I have run into issues with like Observability was not easy before this, so I have actually already enabled logging on the dashboard in one of my projects because I needed it, and I was like, oh, cool, great, now I can just do it's not effort. [18:17]
-
-Better Node. js compatibility, they have, because it's a serverless runtime, they don't have stuff, like FS or HTTP or things like that. It was a little bit more Sandbox, like, Request Lifetime, they give you the entire environment in the request handler. So, when they say greater Node. [18:35]
-
-js compatibility, I'm not quite sure how to interpret that. The, they had like a compatibility chart, and it included like 100 percent on, you know, NodeFS. But like, I don't know what that means when you don't have a file system, you know. I don't think they are actually emulating a file system where you can read and write. [18:52]
-
-Maybe they are, I don't think they are. [18:54]
-
-**Mo:** [18:54]
-
-they're slowly going through the list of Node APIs, And I think they support like only 50 percent of them. So they still don't support like file system in any capacity, just because it doesn't make sense for the runtimes they have, because our workers kind of just run in a V8 isolate. [19:11]
-
-just running somewhere on their edge network [19:13]
-
-**Carl:** That's what confused me though, because the compatibility thing said 100 percent coverage for FS. And so it's like, I know you don't support this because of the environment, what does that mean? I don't know how to interpret this chart. [19:24]
-
-**Mo:** yeah, I think some of them are probably just weird polyfills or just like shimmed values. I'm [19:30]
-
-**Carl:** Yeah, I mean, I guess even like, doesn't immediately explode is an improvement, you [19:36]
-
-**Mo:** Is it an improvement yet? [19:38]
-
-**Carl:** Which is where it's been for me, like, oh my god, there were some weird things that happened when I was trying to develop that. Like, CommonJS imports and things, yeah, so, yeah, I have to play around with that a little bit more. [19:48]
-
-Yeah, they also have Next. js support. via open next, which they've open sourced. So like, cool, here's an open source runtime that they are using themselves in production to provide next support. And like, that's enormous. I think I saw when this was announced Vercel, some of the big Vercel DevRel folks who are active on Twitter seemed a little bit like they were nervous. [20:12]
-
-**Mo:** I've used Cloudflare Workers quite a lot recently, and they had some, like, Next. js support, limited. They've been increasing it for the past few years. They started off with just, like, you can static export Next sites. Great. You can do that with anywhere and host it anywhere. Right? Then it was like, we'll support some limited sub features of Next. [20:28]
-
-And I think they're now supporting it almost fully with the OpenNext runtime. And I can see why some of the Vercel folks would be a little bit on edge, because if you support Next to that degree, yes, Vercel has a lot of nice DevEx features, but when you look at the cost for a large scale site, and where Vercel would make a lot of their money you can get the majority of those functionalities, or like 80 percent of those functionalities on CloudFlare pages. [20:52]
-
-it kind of works similarly. You get those preview branches and all of that. So I can see why they'd be a little bit anxious about that, but I suspect they'll do what Vercel usually does, which is introduce a new, like, runtime dependency, and then it'll take everyone six months to basically get on the same compatibility. [21:11]
-
-So we'll see. [21:12]
-
-**Carl:** They'll just dig that moat a little bit deeper, maybe. Yeah, they also have per worker SQLite, which is neat. Previously, I guess it had only been, like key value store based, so it was kind of like having local storage available per worker, which is great, but, you know, you can't query it.you can't really do structured data in a situation like that. As well as blue green deployments, incremental rollouts. And queues, and a vector database, performance improvements, like, you know, one of the performance improvements is faster time to first token on their AI, platform. [21:41]
-
-like you were saying, Mo, about Vercel getting maybe a little nervous aboutCloudflare workers with real Next support for things like the dynamic images, some of their, longer tail of server based functionality with PR previews, incremental rollouts, and, a queuing system, like,that starts to sound a lot like the offerings that Vercel offers. [22:03]
-
-But yeah, [22:05]
-
-## [Zeego 2.0](https://github.com/nandorojo/zeego/releases/tag/v2.0.0)
-
-**Mo:** Cool. I'll quickly just give a shout out to version Zgo. So for those of you who aren't familiar, Zgo is a wrapper, it's almost like an abstraction, on top of context menus on both native and web. So again, going in that universal app trend you can use a single API in your code base to create context menus for your web with Radix, and then it'll hook into the native layer context menus on iOS and Android. [22:26]
-
-So it's a nice little library to use as a utility when you do want to have context on certain elements of your app. [22:32]
-
-**Carl:** Cool, seems useful. [22:33]
-
-## Conferences
-
-**Carl:** Alright I'm gonna fly through some conferences. [22:35]
-
-## [HalfStack London](https://halfstackconf.com/london/spon) London, UK Nov 13
-
-**Carl:** Halfstack London is happening in two weeks. November 13th. [22:40]
-
-## [React Native London](https://guild.host/events/rnlconf-2024-y9arho/attend?discount=TMIR) London, UK Nov 15
-
-**Mo:** Yes, and another shameless plug React Native London conference, this will be the last announcement before it actually happens in Just over two weeks now. So, this is happening in London, of course on the 14th and 15th of November. Tickets are gonna probably start closing soon, in the next week and a half, roughly, so grab your ticket if you're interested, and there's a discount code with TMIR for this month in React. [23:03]
-
-Where you can get 10 percent off. So come along, say hi to me if you're there, shoot me a message if you do plan on attending. We'd love to host you. [23:10]
-
-## [React Summit US](https://reactsummit.us/) New York, USA Nov 18-21
-
-**Carl:** There's also React Summit in New York November 18th through 21st. [23:14]
-
-## [React Africa](https://react-africa.com/) Casablanca, Morocco Nov 29
-
-**Carl:** React Africa in Casablanca, Morocco at the end of the month in November 29th. [23:19]
-
-## [React Day Berlin](https://reactday.berlin/) Berlin, DE Dec 13 & 16
-
-**Carl:** And React Day Berlin December 13th and 16th. [23:23]
-
-**Mark:** I will be speaking at React Summit. [23:25]
-
-**Carl:** Cool. Yeah, go to React Summit in New York and go meet Mark. I live in New York. [23:31]
-
-I will try and make it if I can. [23:34]
-
-## [Sponsored by Infinite Red](https://infinite.red)
-
-**Carl:** So we are exclusively brought to you by Infinite Red. That's very tongue in cheek, but yes, they are our only sponsor right now. Infinite Red is an expert React Native consultancy. They've been around since 2015 uh, and are owned by Jim and Holmgren. [23:47]
-
-Todd Wirth and Gant Laborde. They've been super active in the community for literally my entire career. I got my start like professionally with React around 2014 or so. So like, I have been aware of them for a really long time. And yeah, I connected with them in a conference and just great vibes. So good. [24:04]
-
-They only do React Native and have built over 75 apps for companies from startups to like huge enterprises. And just like, other than being good people who do a lot of good things for the React and React Native ecosystemsthey seem to be very good to their people because they, like their average tenure of employees at their company is more than seven years. [24:23]
-
-Which is wild to me. That's double the tenure I've ever spent at one company. So that seems great. They are not a like feature factory. They work alongside your developers at your company and help you develop your own expertise there. So if you are spinning up a new product with React Native and want some help hitting the ground running, definitely give them a ring. [24:41]
-
-And uh, you do let them know that you heard about them from us. Not that we get anything out of it. Just, you know, Maybe help us in the next contract negotiations. He he he. [24:48]
-
-## Main Content
-
-**Carl:** Into our main content though. [24:50]
-
-## Some React 19 progress, but no ETA
-
-## [Lazy Context Propagation](https://x.com/sebastienlorber/status/1841042683122286641)
-
-**Mark:** So we've been attempting to track the progress of React 19 and there were a couple of progress that I saw happening in the last month or so. The. Big thing is that we're still waiting for them to finish work on the changes related to the parallel suspense rendering behavior that caused an outcry earlier this year. [25:13]
-
-And I saw a couple PRs from Andrew get merged. I later saw one of them get reverted. And then, just in the last week or so, I think I saw one of them get unreverted or a feature flag get landed around that. So, there is work going on, I have no evidence to say how much more work is needed to be done. I also think I saw someone from the React team, possibly Sophie, mention that they're hoping to get it out by the end of the year, but, you know, nothing concrete either way. [25:46]
-
-So, stuff's happening, stand by, and wait. It's all we can do. [25:51]
-
-## [“Server Actions” renamed to “Server Functions”](https://19.react.dev/reference/rsc/server-functions)
-
-**Carl:** Hurry up and wait. Yeah. And I guess one concrete change that has happened is server actions have been renamed to server functions, which I don't know, I guess that seems good. There's a lot of things in the ecosystem that were called actions. So one less thing called action seems good. [26:07]
-
-**Mark:** Probably. [26:08]
-
-## [React Native Bottom Tabs library using native bottom tabs](https://github.com/okwasniewski/react-native-bottom-tabs)
-
-**Mo:** Cool. So, the next update is that there's this library called react native bottom tabs that's made by one of the developers at Callstack, Oskar Kwaszynewski. Who I've known for a little while. And This is quite an interesting development. Because The current library that you use for navigation within React Native Is called React Navigation. [26:28]
-
-And React Navigation has bottom tabs within it. But they're not fully native backed bottom tabs. And so it means when there's updates Or specific Styling applied to certain platforms Let's say onLet's say on iOS Where if you're on like tvOS, the tabs go on the top. And if you're on tablet, you can have them as like a sidebar. [26:47]
-
-But on mobile, they kind of just look like a normal tab bar. Those changes wouldn't be reflected because they were just basically JavaScript views that were customized. And so the whole purpose of React Native bottom tabs is to create native based navigationOn React Native apps using a JavaScript API. [27:05]
-
-So this will hook into the native layer and it'll look and be styled as a native layer bottom tab, which is quite cool. And a lot of work's being placed into it. One of the things that I've been thinking about with this is could this possibly be introduced and upstreamed into React Navigation because It's a really good alternative. [27:27]
-
-So in React Navigation, we've got native stack navigators, which is the stack navigator that you can use. And it uses the native functionality for the stacks. This could also be introduced as some sort of native tab navigator. So still to be seen, but quite interesting as an update. [27:45]
-
-## [Meta Connect showcasing new AR/VR apps built with RN](https://engineering.fb.com/2024/10/02/android/react-at-meta-connect-2024/)
-
-**Mo:** Cool. Next up, we have MetaConnect happening, and there was a whole bunch of AR VR showcases, which was cool. Obviously, Mark Zuckerberg went on stage and showed off the Orion headsets, which are not really going on sale, but they're kind of showing the future of where Meta wants to go, which I'm personally quite excited about, I really like AR, I hate massive VR goggles, but I really like the form factor of the uh, Google Glass. [28:09]
-
-And I was quite gutted that Google Glass was, was basically chopped. I think it was just a bit too early for its time. But, on the side of that demo there some sort of, like, engineering blogs that were released. And they showcased at the event the Instagram and Facebook apps for the new MetaQuest. [28:25]
-
-interestingly despite Instagram being a native application and despite you know, parts of the Facebook app also being backed by native the Instagram and Facebook apps for the MetaQuest have been rebuilt with React Native, which is quite a big step forward. win for the React Native ecosystem because it's being used on more and more platforms and powering more of Meta's apps that is part of the core business. [28:50]
-
-So this was quite cool to hear and they've built some incredible apps. Like if you, if you look at the demos, there's really swift animations there. Everything looks really buttery smooth and looks really nice. So, it's a really cool showcase of, what they've been able to achieve by rebuilding some of this stuff in React Native. [29:06]
-
-Cool. [29:07]
-
-## [Static Hermes Updates](https://github.com/EvanBacon/expo-static-hermes-demo)
-
-**Mo:** Just a quick update on Static Hermes. Not much is happening here. There's a lot of discussions around like how compatible it would be and you know, what challenges it would introduce with the existing ecosystem. Svetlan Mikhov, who's one of the people behind Static Hermes and who first introduced it last year at React Native EU actually talked about some of the limitations that they were facing trying to take Static Hermes to production with the wider ecosystem. [29:30]
-
-A few people have been playing around giving him some feedback. He's been going on long threads on Twitter explaining some of the details of the implementation, especially with assembly code. So he's been like pasting assembly code in Twitter threads which is quite interesting and he's been styling them like, he's been going through a lot of effort to try to really like explain to the community, which is props to him. [29:48]
-
-But Evan Bacon, as Evan Bacon does came up with a demo of using Static Hermes with Expo dev clients on iOS. So Software Mansion's been working on some stuff around trying to take Static Hermes to production, and Evan Bacon's been trying to see if he can find a way to make it work with a basic Expo app. [30:07]
-
-There's still some limitations it's not anywhere near production ready, but it's just, things are being done in that space, which is quite cool to see. [30:14]
-
-**Carl:** Yeah. Super cool. Nice. [30:16]
-
-## [Anyone else feel burnt by Epic React? : r/reactjs](https://old.reddit.com/r/reactjs/comments/1fwks6r/anyone_else_feel_burnt_by_epic_react/)
-
-**Carl:** This is maybe a little bit of a small note, but I think we've plugged it before. So I wanted include some follow up from the ecosystem. Folks on Reddit have been sharing about feeling burnt by Epic React, which is Kent C. Dodd's React course. I empathize. I get it. Their criticisms are pretty legit. [30:34]
-
-Some of them are legit. Some of them feel like, you know, reddit commenters having strong opinions about how the world works, which are not necessarily based in economic realities. [30:42]
-
-## [Epic React V1 => V2 Upgrade & Deception.](https://old.reddit.com/r/reactjs/comments/1fut75h/epic_react_v1_v2_upgrade_deception/)
-
-**Carl:** Butsome of the complaints that seemed a little more legit to me were, like, people who had bought the, version one, the old version a couple of years ago, were upset about having to pay almost full price to get the upgrade. [30:54]
-
-## Marker
-
-**Carl:** And on the one hand, like, if you bought a course and you learned the course, why do you need to buy it again? I can understand wanting it. And I guess I can understand, like, wanting to, I don't know, it feels a little bit like folks, Feels a little entitled. Feels a little bit like wanting stuff for free. [31:13]
-
-Like I don't know, he put in a lot of effort to update it. I think the previous version came out like four years ago and that's a long time. A lot of things have changed and been updated and the ecosystem has moved on a lot. So I don't know that it is a reasonable expectation to get a brand new course for free or for extremely cheap just because you paid for it a couple of years ago. [31:37]
-
-If you paid for a course that is intended to like help you kickstart a career using the technology, I don't know that you should necessarily need to buy another course targeting people who are trying to kickstart careers in the industry several years later. If you do, like, maybe you didn't take full advantage of the first course. [31:55]
-
-I don't know. So I empathize with that. People were also criticizing the cost of it as being very expensive. It is like, you know, it's several hundred dollars. Like, I think full price for it is like 700. [32:05]
-
-**Mark:** my train of thought on that one is that Kent is entitled, it's a free market, Kent is entitled to put whatever price on, you know, something he's selling, and you are free to ignore it if you don't feel like it's going to be useful or provide enough value. there were maybe some comments about, like, folks not liking his teaching style. [32:24]
-
-That's more of a valid concern, but if you don't want to pay that much money for his course, if you feel like a 20 Udemy course is better, then go pay 20 for that course and move on. [32:36]
-
-**Mo:** Yeah, I'm inclined to agree as well with Mark there. It's just, you do your research before you purchase something. I think he's abundantly popular where you can watch some videos online of Kent. See if you like his teaching style, if you don't like his teaching style, and then make an informed choice as to whether or not you want to spend several hundred dollars for it. [32:53]
-
-I think trying to argue after the fact to say, hey, this wasn't great, it wasn't worth the price, well, cool, but, you know, leave a review for it, I guess, and move on. It's, a free market with this type of thing. Yeah. [33:04]
-
-**Carl:** what? Like, I dropped out of college after a year. Each of those college credits was like 1, 500, 15 years ago. So I feel like I would have gotten much more value out of a course like this than I did out of any individual college course that I took. I don't know, I left that comment on Reddit and they did not find it compelling or I got a negative score. But that's my opinion on it. Like, education, in general, costs so much money. And the value to Cost for something like this to me seems pretty clearly at least worth trying I don't know if you're going for it Yeah, and in the comments to joshwcomo has a course out as well. [33:47]
-
-Also seems really great Also a pretty similar price point, like curated education material from an industry leading expert. You don't get that for free. It's a lot of effort. It's hard to be an industry leading expert. It's hard to design a course syllabus. It's hard to produce that content. [34:03]
-
-It's hard to distribute it. It's hard to, yeah. So I don't know. It's,they're doing it all on their own. These are independent educators in general. Like they are doing their own thing on their own time. Yeah. [34:15]
-
-**Mark:** And, I mean, just, just as a related point, so I did all that work in the first half of this year to update the Redux Essentials tutorial in the Redux docs, which I did all that work for free, and I'm not charging any money for it. And, for the first time I actually tried tracking my hours. And I put in 80 hours of actual focused time, which on the one hand feels like it's not much, you know, like my first instinct is, well, that's only two weeks of work. [34:44]
-
-On the other hand, let's face it, across a typical two week period, I don't actually put in 80 hours of focused effort in my day job. you're in your seat for eight hours, maybe, but you're getting maybe four or five hours of productivity tops. And like, that was, quote, just building off of an existing tutorial where I'd written the content and written the example app. [35:05]
-
-I wasn't coming up with that stuff from scratch. I was converting it to TypeScript, figuring out how to add a couple new features to teach a couple new ideas and then, you know, doing the work to get the right commit sequence, and then turning that into code. Updated content. So, I mean, it was effort, but like, I wasn't doing all this stuff from scratch and that still took me like multiple weeks worth of focused time that I did for free. [35:33]
-
-And so, I got a sense of the amount of work Kent was putting into version two of his course and like he was significantly revamping things. [35:42]
-
-**Mo:** there's a comment in the Reddit thread, which I actually agree with quite a lot and I think it's the right approach with this, which is The person says, well, it is expensive and you can go through YouTube and find each of those topics and find like a tutorial video on them for free on YouTube. [36:00]
-
-But if you have the money, what you're basically paying for is someone to curate that content for you. Summarize it, create a syllabus for you, and give it to you on a silver platter, right? instead of searching for that material, you're paying for that person's time to curate that material for you. [36:15]
-
-The information is there for free, but you are paying for Kent's time and organization to come in and create something valuable for you so that you don't have to spend the time searching. So if you got the money for it, great, go for it. There's someone else in the chat as well that mentioned, which I think is a good point to put it into perspectivea lot of companies will let you expense stuff like this on like a training budget or, an upscaling budget that they have. [36:36]
-
-So when someone like probably prices something at several hundred dollars, I don't think he's expecting indies to come in and all shell out several hundred dollars. I suspect the goal is to find like a midpoint price point where it's. Expensive for indies, but quite cheap for corporates to pay for a large number of licenses. [36:58]
-
-And he does have a option to select multiple licenses and buy for your team. So I think that's probably where the pricing is coming into place. [37:05]
-
-**Mark:** Yeah, sort of the training equivalent of targeting the enterprise market. [37:09]
-
-**Mo:** Exactly. [37:09]
-
-**Mark:** moving along touching on some drama. [37:12]
-
-## [Web Components Are Not the Future](https://dev.to/ryansolid/web-components-are-not-the-future-48bh)
-
-## Followup to this from March 2020: [Maybe Web Components are not the Future?](https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh)
-
-**Mark:** I think we might have mentioned some previous bits of the web components versus React thing that's been going on the last couple months. This started with a post from Ryan Carniato, the author of the Solid Framework. Where he said that Web Components aren't the future. [37:27]
-
-And that spawned a whole lot of discussion after that. A lot of folks from the Web Components community were upset. [37:34]
-
-## [Web Components Are Not the Future — They’re the Present](https://www.abeautifulsite.net/posts/web-components-are-not-the-future-they-re-the-present/)
-
-**Mark:** Someone wrote a post called, Web Components are not the future, they're the present. Which made a bunch of arguments, both technical and sociological, about how Web Components should be fitting in. [37:46]
-
-Lots of debate in Twitter threads, Mastodon threads. I'm not on Blue Sky, but I bet there was probably some debate over there, too. [37:53]
-
-## [Liskov's Gun: The parallel evolution of React and Web Components](https://www.baldurbjarnason.com/2024/liskovs-gun/)
-
-**Mark:** there was one other article that really stuck out to me called the Parallel Evolution of React and Web Components. It's stupidly long, even by my standards. [38:01]
-
-It's 11, 000 words. It's a very long read, and I had mixed thoughts on it. I thought the first third of this was a really good technical discussion about, Some of the web component's early specs came out even before React did. Both of them have evolved over time. The middle third devolves into the author kind of bashing on React for a while, and then it kind of finishes up with some more decent thoughts about technical aspects and how they fit into web application architectures. [38:31]
-
-I'm not gonna suggest that everyone should read it, but there was some interesting background material, and at least the author put in actual time Writing this post as opposed to just, you know, random bashing of things purely on Twitter if you want to see some of the web components discussion that stuff's out there [38:48]
-
-**Carl:** my understanding is that one of the biggest problems of web components, I've never used them, I understand them to be in, you know, Intended to be used as like leaf nodes, kind of like your, your design system. Like if you are going to build a design system in React, I think that web components advocates would say, no, no, no, don't build those components with React, build them with web components. [39:10]
-
-And then you can use them in many, many places and many frameworks and yada, yada. My understanding is that web components have many of the same problems as trying to build your own design systems, where the hardest part is things like versioning. And if you don't get it exactly right the first time, it's kind of difficult to ship new changes to them. [39:29]
-
-So it sounds like web components are still hit a lot of the same problems. They just kind of shift the context. And so you have to figure out like, when you're doing a design system in React, The problem is around versioning and like packaging. Like, do you do many sub libraries? Like, do you make your own like React modal component and your own tool tips and your own buttons and your own accordion tabs, whatever, or do you do one big bulk package? [39:54]
-
-But then it's like, you end up with these like, well, okay. If you ship a change to this. Low level component used within this design system, like, how do you migrate all of the clients that are using that design system without doing like a big bang rewrite across dozens of clients? [40:11]
-
-And like, that's hard. It's not trivial and it sounds like web components have that same problem But instead of versioning happening through semver in npm, it happens in this entirely bespoke Web component standard system and like that doesn't seem better to me. It's like you have to learn a whole new, Context, as well as dealing with the same problem. [40:32]
-
-So, like, I haven't seen that discussed at all in any of these, you know, discussions. These, you know, when people are talking about the technical merits of Web Components, I'm not seeing, like, and here's why it works better for this reason. I also just really, like, the Web Components are not the future, they're the present article. man, I did not like it. I thought it was good. So, this is not a compelling argument. Like, you know, a quote from it that I pulled was like, they're not solid components, they're not React components, they're not Svelte components, they're not Vue components, they're standards based web components that work in all of the above. [41:04]
-
-And that seems like a big assertion to make when the maintainers of solid, React, Svelte, and Vue are all saying, they don't work for us. So, I feel like you can't just say, they work in all of those, when the maintainers of those frameworks are saying, they don't work. And it doesn't really argue why they work, it just kind of asserts that they do. [41:21]
-
-**Mark:** it's a little bit like a lot of the React arguments that were happening earlier this year, where there's like 30 different partially overlapping topics. And people are arguing about a different subset of them. [41:33]
-
-So, in this case, the concerns are technological, some of them are ideological. Folks who prefer web components or advocate for web components tend to be the kind of people who like frameworks. They feel that frameworks are too heavy, they feel that frameworks have bad results on the industry, they prefer to, you know, kind of stay closer to the browser, you know, they use the platform mentality, and so they see large frameworks as sort of the enemy, and so anyone who is using a framework is kind of a bad person. a lot of the vocalness here is coming from these people who's like, it's a standard,therefore it's better.These frameworks aren't standards. I don't see a lot of people in the React ecosystem, like, actively advocating against web components. more of a, whatever, we don't care.So, worth noting that, you know, Ryan's article, came from his perspective more as a framework author, and similarly, Rich Harris, the author of Svelte had a number of complaint threads on Twitter recently, where he was talking about there's a bunch of really, really weird behaviors in browsers that only exist because the web component specs demand those, and that has caused problems for him as a framework author. [42:58]
-
-Things like, Cloning domnodes requiring you to pass in an additional flag, but that makes the cloning process 30 percent slower, [43:08]
-
-**Carl:** Right. And in contrast to that, the present article says, towards the back half of it, it says, I'm not a conspiracy theorist, but I find interesting the number of people who are and have been sponsored and or hired by for profit companies whose platform rely heavily on said frameworks. [43:25]
-
-So it's like, I feel like the web components aren't working for us. Framework authors are making arguments like that. I'm taking a 30 percent performance hit because of the spec requirements to support these. Like that's a very precise technical argument. Not, I'm not a conspiracy theorist, but [43:42]
-
-**Mo:** [43:42]
-
-that sounds like, here's my friend's opinion about these guys. They're awful people. Not my opinion. I'm just quoting what my friends, I'm not a conspiracy theorist. That sounds pretty conspiracy theorist to me. [43:52]
-
-**Carl:** Yeah. It's big, just asking questions energy. we should move on though. I think Mo, you said you have to duck out. [43:57]
-
-**Mo:** I do have to leave, so I guess I can just say goodbye hereand hopefully see you all next month. So it's been a pleasure in all things react and react native and I'll see you all in the next one. [44:08]
-
-**Mark:** we've got a bunch more stuff to get through, [44:10]
-
-## [Announcing VoidZero Next Generation Toolchain for JavaScript](https://voidzero.dev/posts/announcing-voidzero-inc)
-
-**Mark:** Evan Yu, the author of View and Veet and a number of other things, Has announced a venture backed company called VoidZero, which is quote working on the next generation of JavaScript tooling This might sound a little bit familiar. [44:24]
-
-That was sort of the pitch behind the Roam tool set So in this case some of the things that VoidZero is working on correlate a lot with Things that were already in progress with the VEET framework. [44:37]
-
-## [Oxc Transformer Alpha](https://oxc.rs/blog/2024-09-29-transformer-alpha.html)
-
-## [OXC compiler](https://twitter.com/boshen_c/status/1840322879424258115)
-
-**Mark:** There's a Rust based JavaScript compiler called OXC, which also includes a linter and reusable parsers and things like that. [44:46]
-
-So I believe that's now gonna be sponsored under Void0. There's a project called Rolldown, which is going to be a Rust based re implementation of the Rollup build toolset. So eventually the goal is to really make Vite a whole lot faster, ultimately. Vite currently uses a mixture of, I believe, ESBuild for local dev builds and Rollup for production builds. [45:12]
-
-And so they're also trying to make the behavior more standard, or more similar across dev and production as well. [45:18]
-
-**Carl:** Yeah, definitely seems interesting. Always down for stuff to core dev tools to be made faster. All right, cool. [45:23]
-
-## [Updates from the 104th TC39 meeting](https://dev.to/hemanth/updates-from-the-104th-tc39-meeting-14cp)
-
-**Carl:** I'll move us on some new TC39 news. They just had a meeting and blog post I saw said four new proposals advanced to stage four and the list had five items in it. [45:33]
-
-## [Promise.try](https://github.com/tc39/proposal-promise-try)
-
-**Carl:** so there's promise. try, which is now stage four. It seems neat. It looks like it's basically a likeconvenience so that if you don't know whether a function is going to return a promise or not, you can give it to promise. try and then you can handle any errors that it emits as though it were a promise. [45:53]
-
-And the advantage of that is that, you know, if you did something like promise. resolve. then and then execute that function, which would be a great way to achieve this behavior without a change to the language that would process it on the next tick. [46:06]
-
-So it doesn't execute synchronously as, you know, line by line. It gets thrown to the event loop and then event loop comes back and executes it. So, you know, that's. Not always what you want. If you are trying not to do that, now you have a new tool to do so, which is promise. try. [46:21]
-
-## [Sync Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers)
-
-**Carl:** I also liked the sync iterator helpers. [46:23]
-
-I think we mentioned this in a previous episode. Maybe not the last one, maybe the one before. But it's. Basically letting you do stuff like map, filter, reduce on iterable objects without Spreading it into an array first Which I think creates a copy. So like this seems great. You can now map over without the cost of Producing an array from it first. [46:47]
-
-I love it. Here for it. [46:48]
-
-## [Import Attributes](https://github.com/tc39/proposal-import-attributes)
-
-**Carl:** Some other ones that I didn't talk about Think about as hard there's import attributes which I think is like metadata for describing what you're importing, something like that. [46:58]
-
-## [JSON modules](https://github.com/tc39/proposal-json-modules)
-
-**Carl:** JSON modules. So you can import JSON files as modules without, you just kind of natively. It seems good. [47:05]
-
-## [RegExp Modifiers](https://github.com/tc39/proposal-regexp-modifiers)
-
-**Carl:** as well as regex modifiers. couple of new changes, five new things to the language. Seems good. [47:11]
-
-## [Language Evolution](https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o/edit#slide=id.g30432c5cd9c_0_30) “JSSugar” proposal
-
-## [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389133810913338)
-
-## [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389157693227375)
-
-## [BrendanEich on X](https://x.com/BrendanEich/status/1842630141304025263)
-
-## [Daniel Ehrenberg thoughts](https://gist.github.com/littledan/a590784a72f2e1b8cc633ff5ff8a9dc2)
-
-**Mark:** And one other thing that came up at that meeting there was a presentation I think co authored by a number of JavaScript engine implementers at Google and Mozilla and a couple other companies. That is very long and complicated, and it's worth reading through, but as a high level summary, we've had the TC39 process for, like, 15 some years now, and, you know, we had the big bang change to the language with ES2015, and then a steady stream of new language features since then. [47:45]
-
-And the expectation is that once TC39 finishes standardizing a given feature, Every JavaScript engine out there. Is going to end up fully implementing this. Now in practice, if it's basically V8 and spider monkey from, you know, from Mozilla, that's the majority of people as far as browsers are concerned, but there are other JS engines out there as well, and implementing all these new language level features takes time and effort, some of these engine implementers were actually saying, you know what, we actually. [48:19]
-
-are thinking that maybe we shouldn't be required to implement every feature that is added to the JS language spec. Sometimes these things have performance implications, sometimes these things have actually caused security related concerns, It's not like a full blown proposal, but it's kind of like a what if we considered this kind of a thing. [48:42]
-
-what if we sort of split the JavaScript language spec into things that are actually going to be implemented by runtime engines, versus things that are in the spec, and we agree it's part of the language, But would only ever be implemented by transpilers, like Babel or ESBuild or something like that. [49:05]
-
-So that, the JS engines don't have to literally implement every finished feature ever. a number of folks felt this was probably a bad idea. I can understand some of the concerns that are being raised by the engine folks. But, splitting the language feels problematic. You know, certainly the folks who are, you know, kind of in on that, like, I don't want to have to use build tools to write my JavaScript are, are not happy about this. [49:34]
-
-But, even knowing that, you know, some of these things won't make it into the engines and might not be able to take advantage of, you know, built in optimizations feels kind of sketchy. [49:43]
-
-**Carl:** Yeah, I can definitely understand that though, like so many things, I feel like, I mean there are so many lingering polyfills and transforms and whatever that Babel and all of them are like still implementing, even though they are now part of the language, just because how do you know when it's okay to remove stuff like that? [50:03]
-
-I can understand the motivation of saying like, look, this is the reality. We are still transforming this even though technically by the spec, we don't have to. I can definitely understand why they would see, just start saying like, this is a practical reality, pragmatically, this is what's happening. the standardization process should reflect that and acknowledge that some things will just live in the transformer. [50:25]
-
-I can definitely understand that argument. But yeah, I guess that's also weird. Like it introduces a new like point of abstraction in the standardization process and like, what is JavaScript? that's weird. [50:38]
-
-**Mark:** Alright, so, now we're in and we haven't started the lightning round. So, let's try to actually make this a [50:43]
-
-lightning round, shall we? [50:44]
-
-## ⚡ Lightning round ⚡
-
-## [The Disappearance of an Internet Domain](https://every.to/p/the-disappearance-of-an-internet-domain) – .io
-
-**Mark:** Moving along. So there was an article titled Disappearance of an Internet Domain. the TLDR here is that the io domain is associated with a set of islands in the Indian Ocean owned by Great Britain and Great Britain just signed a treaty to eventually hand those islands over to you. [51:05]
-
-I think the island of Mauritania. And so based on international law, there's a chance that once this 3D handover is complete, there is no longer a separate territory. And if there's no longer a separate territory, then there's no legal reason to have a io domain associated with that. And so the article says that, you know, if we, if we've, Assume that these laws and practices get followed strictly, then hypothetically, five years from now, the io top level domain might go away completely. So that's up for grabs, but it's a legitimate concern. [51:46]
-
-**Carl:** The intersection of geopolitics and tech debt seems bad. [51:51]
-
-flying through a little bit. [51:51]
-
-## [How to control a React component with the URL](https://buildui.com/posts/how-to-control-a-react-component-with-the-url)
-
-**Carl:** So I saw a great blog post by Sam Zelikoff called How to Control a React Component with the URL. blog post makes the argument that it's a very common feature request. [52:00]
-
-I think that it is not as common a feature request as it should be because it is the power of the web. URL addressability, deep linking, being able to open a URL and have it, represent the same page that somebody else is seeing. So I think that is a phenomenal goal to seek, and so more things should behave that way. [52:17]
-
-just a pull quote from it that I think summarizes What makes that hard is the fundamental reason why we're heading down a bad road, he says that we now have two sources of truth for the search text. And that's exactly it, like, when you are writing React, you tend to have your source of truth be something in React state. [52:35]
-
-But if it's in the URL state that it exists outside of React's Awareness, you know the universe that you've created for your app that is within react the URL state lives outside of that So it's very easy to accidentally duplicate state then you have a state synchronization problem and I also want to call out that problems like that are a Wonderful example of why dogmatic best practices can really easily lead you to broken apps [52:59]
-
-Then if you use a form library, it's going to keep track of its own state. Then you have to do state synchronization between the URL and the form. That's a really easy way to get a lot of bugs. So if you follow the rule of always use a form library, you're going to run into state synchronization bugs if you try to implement this feature. [53:16]
-
-## [If WordPress is to survive, Matt Mullenweg must be removed](https://joshcollinsworth.com/blog/fire-matt)
-
-**Mark:** one more drama related item, I'm really gonna TLDR this. The WordPress community is basically blowing up right now. WordPress founder and project company CEO Matt Mullenweg went on a seemingly unprovoked rampage. [53:35]
-
-He is basically upset that one of the biggest WordPress hosting companies, quote, isn't giving back enough to the project. And there's all kinds of issues where Matt is both simultaneously the CEO of Automatic, one of the other bigger hosting companies. And the leader of the open source project and the nonprofit foundation. [53:58]
-
-And it turns out that in some cases, he's the sole person who controls some of the key websites. There's been issues with him, basically hijacking a plugin that was developed by this other company blocking people from the Slack and all kinds of other Like, he's basically blowing up their community single handedly, and seemingly for no reason. [54:22]
-
-And a lot of folks who had been very involved with WordPress are like, I can't be involved with this anymore. So, a lot of WordPress folks are actively looking to stop using WordPress and find something else. There's an extremely long, very well written post that lays out a lot of the details linked in the chat, called, If WordPress is to survive, Matt Mullenweg must be removed. [54:45]
-
-It's long, it's complicated, but it's also a very thorough look at everything that's happened. [54:50]
-
-**Carl:** Yeah. Oh man, there's so much to get into. There's so much that could be said about this, but yeah, it's,oh, this has been, this has built its own cottage industry of podcasts and interviews and blog posts. Yeah. It's also not really React. WordPress developer is like an entirely separate thing from web developer. [55:06]
-
-So yeah, it's kind of not related to our main topic. [55:09]
-
-## [Web Without Walls — Dan Abramov](https://www.youtube.com/watch?v=F1sJW6nTP6E)
-
-**Carl:** we've had a couple of tangential references to Blue Sky. I love Blue Sky, I think it's really cool, I've been on it for like over a year because Twitter sucks and meh, I have opinions. [55:20]
-
-But so Dan Abramov, who I'm sure some of you may have heard of once or twice, gave a really great talk. he's currently working at BlueSky as an app developer which is, I'm actually interested to speak with him a little bit more about that kind of transition because he went from core team, building React to now React consumer and I think that is just such a relatively rare Transition to make and I'd be really curious to hear not just like what he thinks about that transition as someone who's made it But also what Dan Abramov thinks of that as a very clear thinker and clear speaker butwe gave a really great talk about the app protocol, which is the underlying technology that BlueSky is built on top of and it hits a lot of really cool things that I personally have been thinking about for a decade about the future of social media and data portability and federated access. [56:14]
-
-not just social graphs, but also to the actual data. I just think it's really cool. Like, I saw some people talking about, like, Oh, it doesn't matter if you have You know, you can always export the social graph because you have your contacts list. And like, that doesn't really matter. [56:28]
-
-It doesn't matter if you have the social graph, if you have the connections between the people. If the people are not producing content, you know, if they're not interacting with each other on that platform. And I would boil down this hour long talk that Dan gave that is really good. And I think you should watch if you're interested in social media and building apps on social platforms. [56:47]
-
-It really comes down to, like, it's not just an open source Twitter clone. It is an open network that people are publishing Twitter like data to, and no one can close your app off. You know, there is no way for something like the, Twitter X API Shut down, the Reddit API shut down. [57:10]
-
-You can't do that because it's built on a federated decentralized protocol. it's not just a proprietary API. So yeah, I think that's really cool. This is a really interesting thing. I think this is going to be a generational shift in how social media operates. So yeah. [57:23]
-
-## [Preact compat discussion](https://old.reddit.com/r/reactjs/comments/1fy2jjh/i_ran_into_preacts_false_promise_what_can_i_do/)
-
-**Mark:** There was a Reddit discussion thread going and was looking into the compatibility of Preact with, you know, actual React and debating some of the pros, cons, and trade offs. And since Preact has been traditionally pitched as a React compatible library, worth looking at. [57:43]
-
-**Carl:** Yeah. [57:44]
-
-## Content-visibility in CSS
-
-## [Using CSS containment](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Using_CSS_containment)
-
-**Carl:** There's some interesting stuff with CSS containment. It seems pretty, like, wonkish, deep in the weeds stuff to properly understand, but it looks really interesting as, like, a performance optimization for rendering. [58:00]
-
-## [contain](https://developer.mozilla.org/en-US/docs/Web/CSS/contain) [CanIUse](https://caniuse.com/mdn-css_properties_contain)
-
-**Carl:** The bulk of it, as I saw in researching it for, you know, an hour and a half, I haven't really used it yet, is there's a contain and a contain visibility, you know, a CSS attribute now, that let you signal more precisely to the browser renderer, how much effort to dedicate to rendering a particular part of the page. [58:19]
-
-So, you know, like, how I'm making sense of this is in React, if you're trying to choose whether or not to render something, for a long time the decision has been kind of like, conditional rendering, like, is the DOM in the page at all, or, like, display none. [58:34]
-
-And you know, there's a lot of other, like, subtle variations around that, like, should it live in the accessibility tree as well, like, You know, there's a lot of subtle nuances to that. So this adds a lot more subtle nuances. Very exciting. But yeah, so it looks really interesting. It lets you constrain So that's kind of part of it, but it's also a little bit on like sandboxing. Like, I guess the contain element is maybe a little bit more on sandboxing. It's like, if you were to like render an ad into your page, you might be able to do it using this instead of an iframe. [59:07]
-
-So, and still maintain the same kind of strong guarantees about how it behaves on the page, how it looks on the page. [59:16]
-
-**Mark:** someone in the chat just said it's like, it's kind of like Shadowroot, and I think that's a little bit, like, along the right lines. Like, you're telling the browser that elements inside here aren't going to have layout interactions with the rest of the page. [59:28]
-
-So, like, whereas, a normal element, depending on your CSS, might, interact or overlap or something with other parts of the page, might cause the browser to do, a bunch of additional checks against other DOM nodes to see if they in some way. And so contain tells it, nope, anything under here is scope, you don't have to waste time and effort checking locations versus the rest of the page. [59:50]
-
-## [content-visibility](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) [CanIUse](https://caniuse.com/mdn-css_properties_content-visibility)
-
-**Carl:** Yeah, and something else they shout out in the docs about it is, like, really long pages using it to optimize, you know, rendering performance. If you've got a massive, massive amount of HTML, then just saying, like, nope, this is off screen, like, don't render it. If that makes sense they were saying that that would help you maintain performance on a huge page. [01:00:07]
-
-But it also talks about like reducing layout shift. So I wonder if that is actually going to be like practical and useful, or if it just would just be like too weird to have to, I've, I've had to do that kind of performance optimization and. Cracking the size of the content being rendered so that you don't have it, like, you scroll down, something goes out of view and then like gets, stops being rendered and then everything on the page shifts. [01:00:31]
-
-So you have to keep like scroll because what you were looking at just changed. I, I don't know. I don't know if that advertised benefit will actually be real. I don't trust it. [01:00:39]
-
-## [How I Built My Blog • Josh W. Comeau](https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2/)
-
-**Carl:** We mentioned Josh W Comeau earlier. He has put out a great blog post. How I built my blog. Looks pretty interesting. [01:00:45]
-
-I, I just always appreciate little technical write ups of things like this. [01:00:49]
-
-**Mark:** and like, it's more than just the blog. I mean, I think he goes into some details about the developer, the education platform and whatnot. But Josh always puts such care and effort into everything he builds. [01:01:03]
-
-**Carl:** Yes, a consummate crafts person. So yeah, it's a good write up. He's very thoughtful about how he builds and how he writes. So this is really great. I have also built a large documentation site for a previous employer. And as I was reading this, I just saw so many problems that I remember dealing with in that. [01:01:19]
-
-Like he talks about, you know, authoring content in MDX and the kind of weird errors you get when doing that. He talked about like doing syntax highlighting with Prism and how it can really explode complexity of, you know, just the amount of HTML on a site, which is a problem I had I built this whole thing, put all of this documentation on a single like API reference massively tall site and oops, it's 12 megabytes of just HTML. [01:01:45]
-
-So I ended up having to like totally re architect how the syntax highlighting was happening because just it totally exploded the amount of HTML on the page. so he talked about using, like updating to the latest version of MDX and using Sheeky which is like a server side, Syntax highlighting tool that seemed pretty interesting and definitely sounded like it would have solved some problems. [01:02:04]
-
-I had a couple years ago And he also referenced he's got a like interactive rainbow on the home page And You can edit how it behaves and that behavior gets synchronized across all viewers of the site simultaneously through PartyKit, which is near and dear to my heart. I helped set up their community a couple years ago. [01:02:23]
-
-cool. It's a good read, [01:02:24]
-
-**Mark:** All right. [01:02:24]
-
-## [Types of React Components [2024]](https://www.robinwieruch.de/react-component-types/)
-
-**Mark:** And the final item for today Robin Wierich is another prolific React educator and author of useful tutorial learning blog posts. Thanks. And he put up a post called Types of React Components in 2024. it's actually a bit of a history lesson. It goes back and looks at the old style create class and mixins, the still newer but by now out of date class components, the higher order components pattern, and then the relatively modern function components, server components, and async components. [01:02:58]
-
-So it's not something that's necessarily going to teach you to do things, but it's a useful look at and sort of like the evolution of React over the years. [01:03:06]
-
-**Carl:** And apparently this is part of a whole series that he's doing updating his most popular blog posts for 2024. generally, I saw a couple of other ones and I wanted to add them, but I, oh god, we already had so many links. So, yeah. Definitely go check those out. he's a great writer. I have been reading his blog for 10 years and he just keeps putting out bangers. [01:03:29]
-
-So yeah, definitely check it out. [01:03:31]
-
-**Mark:** right. I think we're actually at the end. [01:03:33]
-
-**Carl:** We are at the end. We've made it. Oh my God. You guys, you're still here with us. Thank you for sticking around for 80 minutes. Thank you so much for joining us. We'll be back on the last Wednesday of next month here at the live stage in Reactiflux or back in your podcast feed just as soon as we can. [01:03:48]
-
-Lennart, [01:03:49]
-
-**Mark:** Yeah. I got nothing this week other than I am diving into working on some RTK query features, specifically infinite queries, which is a complex thing that I didn't know about and I'm thankful that we're basing it off of how React query works. So My side project for a while. [01:04:08]
-
-**Carl:** That was fun. Cool. We gather sources from ThisWeekInReact, Bytes. dev, React Status, Next. js Weekly, React. js, Subreddit and here in Reactiflux, mostly from the tech reads and news, If you see anything that you feel like we should talk about feel free to send it to us via email to hello at reactiflux dot com T M I R in the subject line. [01:04:28]
-
-Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/) Help them know how smart you are. Alright, see you later.
diff --git a/src/transcripts/tmir-2024-11.md b/src/transcripts/tmir-2024-11.md
deleted file mode 100644
index 3196344..0000000
--- a/src/transcripts/tmir-2024-11.md
+++ /dev/null
@@ -1,723 +0,0 @@
----
-title: "TMiR 2024-11: React 19 is unblocked, Next 15 is 'stable', Expo launch week. The cool kids are on BlueSky"
-date: 2024-11-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:35](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- New releases
- - [[01:51](#vscode-195)] [VSCode 1.95](https://code.visualstudio.com/updates/v1_95)
- - [[02:20](#node-v23)] [Node v23](https://openjsf.org/blog/announcing-node.js-23-key-features-and-enhancement?ck_subscriber_id=1888282043)
- - [[04:12](#docusaurus-36)] [Docusaurus 3.6](https://docusaurus.io/blog/releases/3.6)
- - [[04:40](#react-navigation-70)] [React Navigation 7.0](https://reactnavigation.org/blog/2024/11/06/react-navigation-7.0/)
- - [[04:46](#better-auth-v10)] [better-auth v1.0](https://www.better-auth.com/v1)
- - [[05:06](#mantine-v7140)] [Mantine v7.14.0](https://mantine.dev/changelog/7-14-0/)
- - [[05:14](#storybook-84)] [Storybook 8.4](https://storybook.js.org/blog/storybook-8-4/)
- - [[05:22](#gatsby-v514)] [Gatsby v5.14](https://github.com/gatsbyjs/gatsby/releases/tag/gatsby%405.14.0)
- - [[05:34](#rspack-11)] [Rspack 1.1](https://rspack.dev/blog/announcing-1-1)
- - [[05:39](#angular-beat-react-to-v19)] [Angular beat React to v19](https://blog.angular.dev/meet-angular-v19-7b29dfd05b84)
-- [[05:57](#conferences)] Conferences
- - [[06:06](#react-day-berlin)] [React Day Berlin](https://reactday.berlin/) Berlin, DE Dec 13 & 16
-- [[07:39](#main-content)] Main Content
- - [[07:39](#react-19-rc1)] React 19 RC1
- - [[08:17](#tech-writeup-of-a-solution-to-the-sibling-rendering-issue-that-delayed-react-19s-release)] [Tech writeup of a solution to the sibling rendering issue](https://github.com/facebook/react/issues/29898#issuecomment-2477449973) that delayed React 19’s release
- - [[11:27](#nextjs-15)] [Next.js 15](https://nextjs.org/blog/next-15)
- - [[15:25](#ts-57)] [TS 5.7](https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/)
- - [[19:48](#react-router-v7--remix)] [React Router v7 | Remix](https://remix.run/blog/react-router-v7)
- - [[24:28](#vite-v6)] [Vite v6](https://vite.dev/blog/announcing-vite6.html)
- - [[24:50](#environment-api)] [Environment API](https://github.com/vitejs/vite/discussions/16358)
- - [[27:52](#expo-launch-party)] [Expo Launch Party](https://expo.dev/launch-party)
- - [[28:19](#the-magic-of-expo-dom-components)] [The magic of Expo DOM Components](https://expo.dev/blog/the-magic-of-expo-dom-components)
- - [[32:24](#introducing-workflows-cicd-built-for-your-app)] [Introducing Workflows: CICD built for your app](https://expo.dev/blog/expo-workflows-automate-your-release-process)
- - [[33:33](#environment-variables-in-eas-new-changes-to-simplify-setup)] [Environment variables in EAS: new changes to simplify setup](https://expo.dev/blog/environment-variables)
- - [[36:59](#expo-sdk-52)] [Expo SDK 52](https://expo.dev/changelog/2024/11-12-sdk-52)
- - [[40:10](#new-css)] New CSS
- - [[40:14](#a-friendly-introduction-to-container-queries)] [A Friendly Introduction to Container Queries](https://www.joshwcomeau.com/css/container-queries-introduction/)
- - [[41:05](#a-framework-for-evaluating-browser-support)] [A Framework for Evaluating Browser Support](https://www.joshwcomeau.com/css/browser-support/)
- - [[43:48](#state-of-css-2024)] [State of CSS 2024](https://2024.stateofcss.com/)
- - [[47:02](#framework-betas:)] Framework betas:
- - [[47:08](#rsc-in-expo-router-is-now-in-beta!)] [RSC in Expo Router is now in Beta!](https://expo.dev/blog/universal-react-server-components-developer-preview)
- - [[47:29](#tanstack-start-beta)] [TanStack Start beta](https://tanstack.com/router/latest/docs/framework/react/start/overview)
- - [[49:14](#react-native-077-rc0)] [React Native 0.77 RC0](https://github.com/facebook/react-native/releases/tag/v0.77.0-rc.0)
- - [[50:02](#new-list-dropped-in-react-native)] [New List dropped in React Native](https://x.com/jmeistrich/status/1855663310386958840)
- - [[51:45](#twitter---bluesky-migration)] Twitter -> Bluesky migration
- - [[54:54](#starter-packs-ericclemmonsawesome-starter-packs-stevendborrellibluesky-tech-starter-packs-bluesky-directory-a-complete-guide-to-bluesky-)] [ericclemmons/awesome-starter-packs](https://github.com/ericclemmons/awesome-starter-packs), [stevendborrelli/bluesky-tech-starter-packs](https://github.com/stevendborrelli/bluesky-tech-starter-packs), [A complete guide to Bluesky 🦋](https://mackuba.eu/2024/02/21/bluesky-guide/)
- - [[55:13](#technical-debate-over-how-decentralized-bluesky-actually-is)] [Technical debate](https://dustycloud.org/blog/how-decentralized-is-bluesky/) over [how “decentralized”](https://whtwnd.com/bnewbold.net/3lbvbtqrg5t2t) Bluesky actually is.
- - [[55:57](#web-without-walls--react-universe-conf-2024)] [Web Without Walls | React Universe Conf 2024](https://www.youtube.com/watch?v=F1sJW6nTP6E)
-- [[59:03](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[59:06](#deno-v-oracle-canceling-the-javascript-trademark)] [Deno v. Oracle: Canceling the JavaScript Trademark](https://deno.com/blog/deno-v-oracle)
- - [[59:27](#two-ways-to-the-two-reacts)] [Two ways to the two Reacts](https://bobaekang.com/blog/two-ways-to-the-two-reacts)
- - [[59:52](#thats-not-an-abstraction-thats-just-a-layer-of-indirection)] [That's not an abstraction, that's just a layer of indirection](https://fhur.me/posts/2024/thats-not-an-abstraction)
- - [[01:00:04](#react-anti-pattern-stop-passing-setters-down-the-components-tree)] [React Anti-Pattern: Stop Passing Setters Down the Components Tree](https://matanbobi.dev/posts/stop-passing-setter-functions-to-components)
- - [[01:00:31](#what-is-http3)] [What is HTTP/3?](https://www.cloudflare.com/learning/performance/what-is-http3/)
- - [[01:01:03](#leaked-vercel-v0-system-prompts)] [Leaked Vercel v0 system prompts](https://old.reddit.com/r/LocalLLaMA/comments/1gwwyia/leaked_system_prompts_from_v0_vercels_ai/)
- - [[01:01:59](#react-scan-to-highlight-component-renders-by-the-author-of-millionjs-which-he-used-to-point-out-githubs-code-view-re-rendering-on-every-scroll)] [React Scan to highlight component renders](https://react-scan.million.dev/) (by the author of Million.js), which he used to point out [Github’s code view re-rendering on every scroll](https://x.com/aidenybai/status/1859267710498263073)
- - [[01:02:56](#whats-next-for-the-react-compiler)] [What’s Next for the React Compiler?](https://www.youtube.com/watch?v=qd5yk2gxbtg)
- - [[01:03:14](#framer-motion-spinning-out-as-an-oss-tool-motion-and-conversely-gsap-is-joining-webflow)] [Framer Motion spinning out as an OSS tool (Motion)](https://motion.dev/blog/framer-motion-is-now-independent-introducing-motion), and conversely [GSAP is joining WebFlow](https://gsap.com/blog/webflow-GSAP/)
-
-**Carl:** Hello everyone. Thank you for joining us for October's This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem come and do live out of Reactiflux, the place for professional React developers and supported by Infinite Red a React Native consultancy, but more about them later. [00:18]
-
-I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like events like this. And build some tools to help keep the community operating smoothly. [00:31]
-
-**Mark:** I'm Mark. My day job is working at Replay, which is a time traveling debugger for JavaScript, and outside of that I do way too much Redux stuff. [00:38]
-
-**Mo:** And I am Mo. I head the mobile team at Theodo. I am an active, semi active part of the React Native community. And I organize the React Native London conference and the meetups and sometimes dabble in open source with libraries like Expo and Tamagui. [00:54]
-
-**Mark:** If you're only semi active, what qualifies as active? [00:57]
-
-**Mo:** I don't know. I, I feel like I'm less active than I was a few months ago. Maybe I just need to take a little bit of a break and become reactive. [01:05]
-
-**Mark:** You just ran a conference! [01:07]
-
-**Mo:** Yeah, maybe that's taking most of my energy out of my sails. [01:10]
-
-**Carl:** Yeah, right. I think organizing a conference gives you a little bit of a pass on other contributions. That's a lot. That was a [01:16]
-
-**Mo:** Yeah, it was it was a fun time. Intense, but fun time. [01:19]
-
-**Carl:** All right. Jumping into some quick hits. I'm gonna change up the format a little bit. The last couple months we've had so many new releases that new releases are just mostly part of the content now. But I'm gonna run through some quick new releases with like, no discussion. Just like, this is out, go check it out if you want. If it's relevant to your life. [01:35]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** But job market stuff looks pretty steady state compared to last month. Like, layoffs. 23andMe has laid off a couple of folks. But, generally seems to be pretty stable again. not much to say there. Okay. [01:50]
-
-New releases, lightning mode. [01:51]
-
-## [VSCode 1.95](https://code.visualstudio.com/updates/v1_95)
-
-**Carl:** VS Code they released like every, I don't know, six weeks, something like that. They've got VS Code 1. 95, which mostly looks like it brings out co pilot things. thing that caught my eye the most was you can add multiple files to like a working set, they call it, in the co pilot AI assistant stuff. [02:10]
-
-So that seems kind of neat. I haven't used the copilot very much, but being able to say, here are the files that are relevant. Please do this for me. That seems neat. That seems cool. [02:20]
-
-## [Node v23](https://openjsf.org/blog/announcing-node.js-23-key-features-and-enhancement?ck_subscriber_id=1888282043)
-
-**Carl:** There is a new version of Node, Node 23 Which means Node 22 is now LTS Two things caught my eye that seemed neat Biggest one is they now have native support for loading ES modules using Require. [02:37]
-
-this seems like a huge compatibility bridge between common JS and ESM, which has been a pain point for like five years, literally since the ES modules were released. So that's cool. It's been experimental for a long time and is now no longer experimental. It's just stable. So that's cool. [02:54]
-
-They also added a native, flag to node, the node executable to run your package. JSON scripts. So no longer do you have to do NPM run. Now you can do node dash dash run. Which is just kind of cool. that was like a weird coupling between NPM and node. So like moving that into the runtime just kind of makes sense to me. So cool. Just especially while we have more variation in like runtimes and, Package management [03:19]
-
-**Carl:** tools and whatever. [03:20]
-
-**Mark:** I agree that Node having support for being able to use require to pull ESM modules into CommonJS a huge thing. I think you could do it the other way around where you could import CJS files, apparently. I'm still hazy on that one. But in general, the interop panes between ESM and CommonJS in Node have been the big barrier and reason why package maintainers like myself have had to go through shenanigans trying to get our packages defined and published properly with multiple different artifacts inside. [03:58]
-
-As always, the fact that a new version of Node. js has support for this doesn't mean we'll be able to drop that immediately because, you know, the long tail but at least it's a step in the right direction. [04:12]
-
-## [Docusaurus 3.6](https://docusaurus.io/blog/releases/3.6)
-
-**Carl:** DocuSource put out 3. 6. It's faster apparently. Seems good. [04:16]
-
-**Mark:** Apparently that's because they did switch from using Webpack to using RSPack, which is, it's effectively Webpack. But rebuilt in Rust, so it's like public API compatible. So, an example of a migration path to get faster build tools without having to sort of switch which build tool ecosystem you're in. [04:40]
-
-## [React Navigation 7.0](https://reactnavigation.org/blog/2024/11/06/react-navigation-7.0/)
-
-**Carl:** React Navigation put out version 7 if you're in React Native World. [04:46]
-
-## [better-auth v1.0](https://www.better-auth.com/v1)
-
-**Carl:** A project I've mentioned at least once on this show for authentication, BetterAuth, is at 1. 0. They've been doing a really fast, rapid release cycle, I've noticed. like, last month they were on version, 0. 6 and then they did, like, 0. 0. 9, and now 1. 0. So, cool. Seems good. Love authentication. And it seems like a good project for it. [05:06]
-
-## [Mantine v7.14.0](https://mantine.dev/changelog/7-14-0/)
-
-**Carl:** Mantine put out version 7. 14. Seems like a decent UI toolkit. [05:14]
-
-## [Storybook 8.4](https://storybook.js.org/blog/storybook-8-4/)
-
-**Carl:** Storybook has 8. 4. I have opinions about Storybook. I don't use it. But hey, if you do, they are talking more about like testing and stuff. [05:22]
-
-## [Gatsby v5.14](https://github.com/gatsbyjs/gatsby/releases/tag/gatsby%405.14.0)
-
-**Carl:** Throwback Gatsby released version 5. 14. It's out. [05:28]
-
-**Mark:** genuinely surprised anyone's still working on it. [05:30]
-
-**Carl:** Gatsby is still here. It still exists. Me too, a little bit, [05:34]
-
-## [Rspack 1.1](https://rspack.dev/blog/announcing-1-1)
-
-**Carl:** RSPack put out 1. 1. We talked about version 1 release Recently. [05:39]
-
-## [Angular beat React to v19](https://blog.angular.dev/meet-angular-v19-7b29dfd05b84)
-
-**Carl:** And amusingly, Angular has released version 19, beating React to the punch. Nothing that means anything, but yeah, well, Angular's got a new major version out. [05:50]
-
-I saw they're looking to revise their style guide, which is apparently 52 pages long currently. So that's ridiculous. [05:57]
-
-## Conferences
-
-**Carl:** Yeah, conferences. Mo, you wanna talk? [06:00]
-
-**Mo:** Yeah, sure. So, we're reaching the end of the year, which means conferences are going into hibernation mode as expected. [06:06]
-
-## [React Day Berlin](https://reactday.berlin/)
-
-**Mo:** But we've got one more left for you all this year, React Day Berlin. And React Day Berlin happens in December every year. It's a really cool gathering of people. I was there last year and I'll be doing a talk this year with a friend of mine from Amazon, Anisha Malde, about universal React, so it's a, it's a great of React people. [06:25]
-
-They have a really cool venue called Cosmos It's a really historical city. If you're in Europe, I'd recommend you come around. It's, it's a good time. [06:32]
-
-**Carl:** And it's on my birthday, so I'm not going. [06:34]
-
-**Mo:** Happy birthday, Carl. Early birthday. Very early birthday. [06:38]
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl:** All right, sponsor time. We are sponsored currently exclusively by Infinite Red. They're an expert React Native consultancy that's been around since 2015. Coming up on 10 years, wild. They're our only sponsor in part because very few companies do as much as they do for the React Native ecosystem. [06:55]
-
-And so just really happy to be a part of it. Have a earnest collaborator in that kind of way. Yeah, I've seen their name around for as long as I've heard about React Native being used professionally. They only do React Native and have built over 75 apps for companies from startups to like the biggest fortune, whatever companies in the world. [07:13]
-
-than being great people who I'm happy to collaborate with, be sponsored by they're a team of about 30, mostly developers, mostly with more than 10 years of experience. And they work alongside your team to help you develop expertise in React Native. So if you are working for a company, spinning up a new product with React Native, and want to hit the ground running, definitely give them a ring. [07:36]
-
-Infinite. red is the website. Cool, all right, [07:39]
-
-## Main content React 19 RC1
-
-**Mark:** so we actually have a very, very big Big development if you've been paying attention the last few months, we've been tracking that the React 19 release has got delayed because of concerns over changes to suspense behavior when multiple sibling components all want to suspend you know, the change had been made last fall, the community pointed out problems with it, Back in the spring, and the React team said okay, fine, we'll hold on React 19 until we can come up with a solution for this issue. Well, the good news is, that fix is actually done and out as a new React 19 RC. [08:17]
-
-## [Tech writeup of a solution to the sibling rendering issue](https://github.com/facebook/react/issues/29898#issuecomment-2477449973) that delayed React 19’s release
-
-**Mark:** And the React team put together a very good visual and technical explanation of what they changed and how the behavior works. They're in the GitHub issue link, so I highly recommend taking a look at that. Big picture is that the original behavior as of 18, if you had multiple sibling components that all wanted to suspend, was it kind of acted like a promise. [08:40]
-
-all, Where, in one render pass, it would kick off all of them, wait for them all to complete, and then actually show the content. The change that effectively broke things was it would render the first child that's suspended, see it, and say, oh, wait, let's wait for that one to complete, then pick up with the siblings, making it more like a serial for loop. [09:05]
-
-And the new behavior is when that first child suspends, It will go ahead and show the fallback, but it will kick off kind of a pre warming step in the background. So like, not like a complete render, but I guess kind of like a partial render, enough to kick off the requests. So that at least the other requests are in flight right away. [09:29]
-
-And so the overall behavior should be at least as good as it originally was, if not maybe actually kind of better. In, in some certain ways. So the two key takeaways here are that the, you know, the suspense behavior that people were concerned about has been addressed. It did take them a few months, but they, they did it in a comprehensive way, not just slapping in a bug fix. [09:52]
-
-And also that hopefully React 19 final is very, very close. There's still no specific timeline, but they did make the comment that we hope to publish 19 stable. Boy, [10:03]
-
-**Carl:** Yeah, and just maybe to restate what you were saying in different words, so my understanding of like the problem that they introduced and why they introduced it is Like you said previously, it was just sort of rendering all of the siblings before it handled the suspense. [10:18]
-
-And that was undesirable because it introduced latency before the fallback would be rendered. It did a bunch of work before showing the fallback. So they wanted to change it so that the fallback would be shown quicker, but caused requests to behave as a waterfall rather than kicking off in parallel. [10:36]
-
-It would kind of waterfall shape of your component tree. If you had requests being kicked off by like child components and sibling components and stuff and so now they managed to find like a happy balance where they don't do all of the work of rendering, you know doing the I'm fuzzy on the terminology around like commits and rendering and all that so I can't speak to precisely there [11:00]
-
-**Mark:** someone had a blog post that explained these things. [11:03]
-
-**Carl:** I read that but many moons ago, yeah, so it's a nice Midpoint between what it used to do and what they wanted it to do and now it works correctly. [11:13]
-
-So yeah, They delayed it back in June and they now have a fix So, you know, only a couple of months delayed. It's only all year that we've been talking about React 19. So maybe it'll be released soon. moving on. [11:27]
-
-## [Next.js 15](https://nextjs.org/blog/next-15)
-
-**Carl:** Next. js has version 15, out and stable. You know, they call it out and stable, but I don't know, it's stable version is like using of the big changes is using like React 19. RC in the apps router, the app router. And so that still feels to me like the proving ground for React 19. [11:50]
-
-So calling Next. js 15 stable when it's recommending that you use an unstable version of React feels funky to me. Feels like a, like a workaround to the problem of people don't test, you know, release candidates, so they're just going to call it stable. [12:06]
-
-But yeah, I'm not sure that I personally would base a production system off of the app router in Next 15 because it just, because of that, it feels like a beta, beta is maybe too strong, but it feels like they're still exploring. claim it's stable, I don't know what sort of underlying technical issues might cause things to have to be changed. [12:27]
-
-**Mark:** This touches on multiple different aspects that we've talked, at least I think we've talked about previously. One is that, you know, especially with all the server component stuff, the React team used to be able to, pre alpha test all their ideas internally at Facebook, but they can't do that with server components because it relies on having a separate server, and Facebook has all their own server, which is one of the reasons they ended up collaborating with Vercel. [12:55]
-
-To be like, they convinced Vercell to go with their vision, but also it conveniently aligned with, we need someone who doesn't have Facebook server infra to let us build out server components and prove that it works. Along with that the app router has always used a pre release version of react. [13:14]
-
-Like this. Like, even before they came up with the Canary system, it was using, assorted, experimental, unstable builds. And so, haven't been keeping track of which version specifically, but, I would assume that over the last year, versions of Next 14 have been using, you know, React 19 Canaries, betas, RCs. [13:36]
-
-So, if anything, it's, More stable now than it was a year ago. But part of the point was that, the App Writer needs all this new functionality in 19 in order to work. And the whole point of the Canary system was that, well, even if it's not fully 100 percent stable stable as a standalone release, frameworks like Next are able to paper over the rough edges so that from their point of view and from the consumer's point of view, It's stable. [14:05]
-
-So, I agree that the versioning system is funky, but it's also not a new thing. [14:10]
-
-**Carl:** Right. Definitely not new for sure. But yeah, if you're doing a little side project, probably fun to play with. If you're a founding engineer at a new company, I'm not sure I would start a new thing on it. It's not sure I would start a new revenue generating entity on it. [14:25]
-
-So, yeah, one new thing that they introduced is an instrumentation. js file, hook, I don't know. It's a place where you can plug in to the core, like, network level of the system. Next. js for things like observability and monitoring. [14:43]
-
-So that seems pretty cool. I think that is one of those like quiet underrated things that every app needs and that is not always super easy to figure out how to fit it in. In the past, I have done a fetch wrapper that introduced things like performance metrics and observability and stuff. So just having that as like a a framework feature in Next. Makes a lot of sense to me. Glad to see it. [15:07]
-
-They also put out a, a form component, which seems like it overlaps with like the native behavior that the native form enhancements that React 19 is introducing, so I'm a little bit fuzzy on like what that abstraction is super duper for, but yeah, it's there. [15:22]
-
-Cool. On to TypeScript. [15:25]
-
-## [TS 5.7](https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/)
-
-**Mark:** So, the TypeScript release chain also keeps chugging along. I think they do releases every two or three months. And so we're now up to TypeScript 5. 7. There are a couple nice to haves, like checking for variables that never got initialized, like borderline winter. Related stuff, but at the types level. The, the interesting thing from an ecosystem perspective the story around, you know, how TypeScript interacts with module output and file paths has always been very complicated, because it's always been very complicated at the JavaScript level. [16:00]
-
-And one of the things that had been kind of a pain point, weird point, frustration thing was that even when you were writing, like, Writing TypeScript files in order for some ES module, you know, import behavior to work properly, your imports still had to say you were importing from a js file in the import path. [16:25]
-
-And that always felt really weird. It's like, yes, I realized that's what is actually executing at runtime and that the build output is a bunch of js files, but the file name I'm, but with the file that I'm writing this in is a ts file. Like this, this doesn't make sense. This is weird. I don't want to have to do this. [16:45]
-
-And the TS team had resisted trying to make changes here because after the first couple of years of doing TypeScript features that required actual separate output, like enums, they're now very much on board with like, we are a superset of the JavaScript language and the compiler doesn't do anything to have to rewrite the actual behavior of your code. [17:11]
-
-But they appear to have actually added a mode that will change import path names. So when you have an import that says import from something. ts If this flag is enabled, it will rewrite that to say import something from a js. It only does this in certain conditions where it's a relative path and not, and not a, like a globally scoped path. [17:41]
-
-I, I don't pretend to understand the rationales behind it. I'm mostly just going off the release notes here. So, it seems like a rather grudging Decision to tweak things in favor of better ecosystem interop. [17:54]
-
-**Carl:** this feels very much like stuck between a rock and a hard place in that, like, Now there are more and more ways to run your TypeScript code without doing a full compilation pass, sending it fully through the TypeScript compiler, TSC, It's an intersection of like, there are more ways to run your code without fully compiling it and executing the built output. And there are more ways to, or rather, imports are getting stricter about file extensions and just like, Ooh, oh no, what do you do with that? Those are like incompatible assumptions. [18:29]
-
-this seems, I agree, this seems like a grudging, I don't know if I want to call it a hack fix or a band aid or something, but like, just even as they're talking about it in the release notes, it's, I feel like I can sense their trepidation and like angst over, like, you know, like a quote from it is like, you might need to use conditional exports with scoped custom conditions to make this work for like absolute paths, like if you're using, you know, your TS config to, you know, import, you know, structure and not use relative paths and it's just like, Oh no, that's [18:59]
-
-**Mark:** so thrilling, [19:01]
-
-**Carl:** Right! [19:01]
-
-It's like, oh god, that's, this sounds like a whole new problem. they're trying to fix a problem. They may introduce more problems. I think this is going to be painful for a long time. [19:11]
-
-**Mark:** but it's there. If you feel you need this. [19:14]
-
-**Carl:** maybe you do. Yeah, I don't know. Anyway, seems, seems rough. V8 introduced compile caching, which allows runtimes to reuse some of the like JIT compilation steps. So TypeScript is taking advantage of that new V8 feature to improve its startup time. They talked about, you know, if you do like TSC dash dash version, it now prints faster. [19:38]
-
-So like, that's cool. That's nice. Startup time is definitely a pain point for Node generally, JavaScript generally. And that's nice. Less latency. [19:48]
-
-## [React Router v7 | Remix](https://remix.run/blog/react-router-v7)
-
-**Carl:** Cool, okay, moving on. React Router v7 slash, you know, the one with Remix. headline, big pull quote, " We encourage all Remix v2 users to upgrade to React Router v7." This seems really neat. I want to play more with this, but I think really playing with it is going to take a lot. I have an app in mind that I want to try and move over. [20:12]
-
-It's currently using Remix 1, so I can upgrade to 2 and then upgrade to React Router 7. Woo! Multistage upgrades. Yeah, the big highlight here, I guess, is that Essentially, I think my mental model for understanding this change, you know, Remix to React Router is what was Remix is now Framework Mode in React Router. [20:34]
-
-So you can still use React Router as you always have, as just like a library. Or you can use it in Framework Mode, which has a Vite plugin to get more control over, you know, the build step, the compilation, which is what used to be Remix. So it feels like they explored a lot of like API surface area. [20:55]
-
-Like, how do we fix this? How do we make this work correctly as we want it to with Remix? And then it feels like they got it, they got it where they want, they refined it to where it was just kind of an abstraction over existing build tools. Like that was the big push to not have like, you don't interact with Remix, you interact with Vite and there's a plugin that is Remix. [21:15]
-
-And so now this feels like the next logical step there where like it is truly just an agglomeration of existing tools that you can choose how to use in the way you want. I think that's pretty neat. That seems pretty cool. I definitely want to play with this a lot more. [21:27]
-
-**Mark:** as I roughly understand the sequencing, so Remix itself was originally based on ESBuild, and there was no way to really mess with that configuration. Then they managed to come up with a Vite plugin, which did the same thing. And then the Vite plugin, I guess, became the default way to use Remix. [21:44]
-
-And now that it's like, well, at this point, there actually isn't much left that's specific to Remix the framework. It's all in the plugin. And so that enabled them to help take some of this, and take basically all this functionality, back into React Router, the library. And so as you said, there's the client side piece, which has always been there, and then it's like, well, all this stuff that used to be server related, and used to be specific to the Remix framework, is now encapsulated in the Vite plugin, so it's just there if you want to use it. [22:14]
-
-**Mo:** I mean, it's quite interesting because I feel like this idea of, frameworks being almost add ons or plugins to the bundler, whether it's Vite, I guess I've seen this with Vite only, is quite an interesting premise and I think it's picking up a little bit, maybe almost as a response to how Next. js is such like a, tightly It's not proprietary, but proprietary like piece of software where you're like really buying into Next rather than buying into the tools that are, you know, underlying Next. [22:43]
-
-And I see that with the new React Native Framework One as well, where it's really kind of, it's a Vite plugin. Everything's on Vite and we're building on top of Vite and we have some extra functionalities that comes out if you want to use it as kind of a framework. So it's interesting to see how this shift from the Remix team has had, I think, probably reverberations across to other, parts of the ecosystem. [23:04]
-
-I guess the question that I still have is, why have they done this from a branding perspective? Like, it seems like a lot of brand capital that they probably had in Remix Is, kind of disappearing by going into React Router. Now you could argue whether or not that's good brand capital or not, because Remix has had its fair share of controversies. [23:22]
-
-it's an interesting move for me. [23:24]
-
-**Carl:** I would raise, as a counterpoint, That they already captured the brand value because they sold Remix to Shopify, [23:31]
-
-**Mo:** It's a monetary brand value rather than anything else. Like a monetary for acquisition brand value. [23:36]
-
-**Carl:** I think there's a decent argument to be made there. but also like react router has been Around for like 12 years 11 years Literally, like, the original way of doing routing in React. So it kind of makes sense to me to say like, Look, we solved this problem. [23:54]
-
-I have been watching them try to figure out where the boundaries are between routing and, like, server and, they've been trying to figure out how to do data loading and, bundle splitting at the router level. For that entire time. So it feels to me like they spun up a new brand to do more experimentation and now got there and then folded it back into the original tool that they've been trying to solve this in forever. [24:20]
-
-**Mo:** the process got acquired, which is a nice payout as well. [24:24]
-
-**Carl:** great bonus. Yeah. [24:25]
-
-**Mo:** Yeah, makes sense. [24:27]
-
-**Carl:** Speaking of Vite. [24:28]
-
-## [Vite v6](https://vite.dev/blog/announcing-vite6.html)
-
-**Mark:** So associated with that Vite version six just came out. And it's interesting because they've tagged it as the most significant release since Vite 2. And yet I was looking through the announcement and the migration guide, and it looks like there isn't a lot that really feels user facing in terms of features and changes. [24:50]
-
-## [Environment API](https://github.com/vitejs/vite/discussions/16358)
-
-**Mark:** Best as I can tell, a lot of this one is on the inside, and it looks like they did a lot of major refactoring internally to enable what they're calling the Environment API. And as I understand it, the idea is that because JavaScript these days is used in so many different ways, it's used in the browser, it's used in Node, in Deno, in Bun, in worker runtimes, that may have differing constraints. [25:18]
-
-It seems that the environment API is going to allow you to generate build output targeted for different environments based on certain definitions. I'm still kind of hazy on that part myself. I have seen a number of mentions that things like some of the other, Framework level Vite wrappers are going to benefit from having the environment API available. [25:45]
-
-So, seen some mentions here, I don't quite know how all the pieces connect. general takeaway is like, it seems like, a fairly easy upgrade. saw a couple people on Reddit say like, yeah, I just like bumped the version and it just worked. So it might not have an immediate benefit for an application in terms of speed or build output per se, but it does seem like it's fairly foundational for a lot of the framework level stuff that's going on in the ecosystem. [26:12]
-
-**Carl:** Yeah, we definitely agree with that. I've encountered a little bit of that environment pain. Not using Vite, but just like trying to use Cloudflare workers. Trying to do, a worker serverless type of architecture. Definitely can tell that it is, Like bleeding edge of the ecosystem and a lot of the existing tooling is just like not well suited to support it precisely. [26:37]
-
-Yeah, just like having an existing, like daemon, existing process that is long lived. It's just a very different set of constraints from a short lived process that Handles a request and shuts down. So, Remember the era of the, of the acronym for rendering? SSG and SSR and ISR and S So, I feel like this environment API to me, it feels like a reaction to that, of like, look, we have all of these contexts in which web pages are being rendered and used. [27:08]
-
-And we don't even have a language to talk about it. I guess Vite has, spent most of the version five release iterating on what has then turned into this environment API. It sounds like they introduced it as. Something else the runtime API in 5. 1 and iterated on it, iterated on it, realized that what they landed on was different enough from that, that they just came up with a new name for it and put out a major release. So yeah, definitely looks interesting and valuable. [27:38]
-
-And yeah, given how Vite seems to be like the common building block that everyone else is starting to rely on, here for it. This seems like the kind of exploration that is super, super valuable, especially given that place in the ecosystem. [27:51]
-
-**Mark:** Definitely. [27:52]
-
-## [Expo Launch Party](https://expo.dev/launch-party)
-
-**Mo:** yeah, let's move on to some React Native land. And interestingly so, towards the end of November, we've had Expo's launch week. This is where Expo kind of bundle a bunch of the stuff that they've been working on and launch it in one go over a few days. it's been quite interesting to see some of the stuff that's been coming off. [28:10]
-
-Nothing is particularly a big surprise but it's interesting to see the culmination of some of the stuff being released out to the public. So, I'll go through some of this bit by bit, and we'll talk through it. [28:19]
-
-## [The magic of Expo DOM Components](https://expo.dev/blog/the-magic-of-expo-dom-components)
-
-**Mo:** So, the biggest thing that the Expo team has been talking about over the last few months, I'd say, is DOM components. [28:26]
-
-This idea of how uh, Can we make it super easy to run web based DOM elements inside of a native app without turning the entire app into a Cordova Ionic sort of web view based app? this is controversial at the best of times, I think, right now. A lot of people seem to really like it. [28:44]
-
-There's some people who feel like it's kind of a step I think the expo team is trying to take this pragmatic approach of, a lot of people have React web apps, how do we kind of get them to migrate incrementally and introduce them into the React native ecosystem. So, The article that we've linked has some interesting use cases. It kind of looks at the integration of, you know, you still, if you have a WebView based app, maybe there's some cases where you still want to introduce some native functionality. [29:11]
-
-So, you know, you press a button, maybe you still want to have a haptic on the native device. So how do you integrate those things together? And make it kind of feel native in some capacity. So it talks about some of that, some of the patterns that you want, and some use cases. So some of the things that have been really difficult to do in React Native is things like displaying markdown. [29:28]
-
-Markdown, you know, you have to create your own renderer with native components for it. And it's a lot of work to do that natively. Anyone who's done that will kind of attest to that. And Stuff like that gets really easy because it's a solved problem in the web world. So, they're kind of not saying you should use this for your entire app. [29:44]
-
-They're kind of being very, very, very clear about that. thinking of using that in places as an escape hatch more than anything. [29:51]
-
-**Mark:** More interop is always a good thing. [29:53]
-
-**Mo:** yeah, you know, it's good to have that. Now, this isn't something that necessarily is new. Like, you can always use WebViews in React Native. It's been around for probably since the very, very, very early days. [30:03]
-
-It's nothing new. There was always React Native WebView as a library. this is just an easier way and a nicer way to do it. And it uses the favorite directives that everyone has now in the React ecosystem, which is the use directive at the top of the file. And you just pop in a use DOM and it kind of works. [30:18]
-
-I think we're starting to overuse directives. We should probably stop as an ecosystem. It's just getting a bit out of hand, but that's a different conversation for another time. I see Carl passionately nodding at this. Mm [30:30]
-
-**Carl:** flashbacks to like, I guess it was like ES6 when the use strict directive was introduced. And I just remember the emphatic, you know, like people would say like, Ooh, what if we did this other directive? And I just remember the reaction being like an emphatic, like, No, this is the only directive we're ever going to do. Never again. This is terrible. We should not have had to do this, but we needed to. Never again. [30:53]
-
-And so now seeing like, we got like, what, four or five now in React? And they don't even have the same semantics. Like it used to be only at the top of the file and now it's like top of the source file, which is technically different. Not the, and like some of them are at the tops of functions. It's, it's complicated. It's too much complication. [31:13]
-
-**Mo:** I tend to agree with you. I quickly want to touch on some of the limitations to dissuade people from trying to use this for their entire app, so I'll just quickly quickfire those. The first thing is that performance is really going to suffer. Because, you know, when you're running a React Native app, it does have a JavaScript engine that uses Hermes under the hood. [31:30]
-
-But for this, you're basically instantiating a new JavaScript engine that will run web code, so that can be JSC on iOS and V8 on Android. And that basically slows down your load time quite significantly. And then if you do want to tackle that, you're probably going to have to have some hacky stuff to preload these components, hide them, and then display them. [31:48]
-
-It becomes a mess. So you really want to use this when you have no other options, or, you know, You have an escape path long term to basically get rid of these, these webviews. And then the other thing here is you have to be very, very clear as to how you handle your navigation. Because the worst thing for a user experience is having multiple layers of navigation. [32:06]
-
-So, you know, you have your stacks and your tabs inside of your native app, and then suddenly someone clicks a button inside of the webview, and it just adds a new screen onto your webview. And so you've got like two or three layers of navigation. It gets messy. Be careful, think about it deeply basically use at your own risk and think about the consequences of your actions. [32:24]
-
-## [Introducing Workflows: CICD built for your app](https://expo.dev/blog/expo-workflows-automate-your-release-process)
-
-**Mo:** In other things that the Expo team's been launching so Expo launched workflows. This was one of the more surprising things. They hadn't, they kind of kept this under wraps a little bit. But the whole concept with this is so far you know, Expo's got their cloud build tools, EAS build and EAS update. [32:38]
-
-So you can use builds to create your mobile native builds. They've got a submit tool. solution as well, which kind of pushes that thing to the App Store for you on Google Play and Apple App Stores. And they also had an update mechanism, which allowed you to issue over the air updates to your users. [32:52]
-
-Now, this, they never had a workflow or like a proper CICD tool. So you would have to basically almost run your CICD on another cloud or another sort of CICD tool and then call Expose. servers just to trigger the build or trigger the update. So they've kind of created some very basic workflow functionality. [33:11]
-
-It's YAML based. You know, you can run bash commands, you can run NPM commands in it. It has some very basic control flows as well. So if you kind of want to get away from, you know, using GitHub actions for your, for your mobile builds and mobile updates, it's a cool option if you don't want to add that as an extra piece that interacts with Expo. [33:30]
-
-It's something to see how they develop and extend over time. [33:33]
-
-## [Environment variables in EAS: new changes to simplify setup](https://expo.dev/blog/environment-variables)
-
-**Mo:** other unexpected, but this is incredibly welcome news they have revamped the way that you handle environment variable handling within Expo. Now this is something that has been a real pain. I think it's the place that the Expo team probably struggled the most to come up with a good and comprehensive solution. [33:52]
-
-Because you've got sort of different layers of environment variables when you're dealing with a mobile app. You have sort of secrets that are stored inside of the app's binary. Then you've got JavaScript based environment variables that anyone can inspect if they go into the JavaScript, so you don't really want to use any secrets or put any secrets within them. [34:10]
-
-Then you've got some stuff for your build processes. So there's sort of these like multiple layers of environment variables and they each had different sort of sensitivities or levels of secrecy that you needed to maintain. And so they've centralized all of this in one place. So EAS can kind of manage all of this for you. [34:26]
-
-And they've tried to centralize this because environment handle, variable handling in Expo was a nightmare. You had to kind of deal with three different environment variables, like working in a consultancy was one of those things that clients would come to us and be like, why is this so hard? And I would be like, I don't know, there's probably should be a solution. [34:43]
-
-One of our clients actually, prior to start a startup, like, like, thought very seriously about starting a startup to solve this problem, and I told them don't, please don't, Expo will probably solve it, and they have. So, it's good. I think it's still to be seen how it bodes in practice, but from first glance, it looks like you kind of define these centralized environments, and they have all of your environment variables in one place managed by Expo, which can make things significantly easier, and you can kind of define the visibility, visibilities as well. [35:08]
-
-So this is very welcome, because I think it's. It's kind of long overdue and it's one of those things that was a big pain point. [35:13]
-
-**Carl:** I love that. It sounds great. Sounds like a real problem that needs, you know, sounds like an improvement, but I have never worked anywhere that did not have some kind of pain with environment variables, including on my like solo projects, like currently the, you know, the main app that I write code for. As a stupid, terrible environment variable setup, because like, you know, it's CICD with GitHub Actions deploying to a Kubernetes cluster. [35:41]
-
-And so like, I have to take, I can't remember the, I think I put all of the secrets in GitHub. But then they get loaded into GitHub Actions alongside lots of context, build context, that the action provides on its own. And then I have to manually take all of the information that's relevant to the executing code and put that in a secret in Kubernetes and then load that. [36:03]
-
-So, like, I'm glad they're trying to improve it. I also just kind of think dealing with secret data is just a hard problem. So, I suspect this may not be the end of it. [36:13]
-
-**Mo:** I don't think it's the end of it. If they make it marginally better, especially, I think, I think it kind of ties hand in hand with their workflows functionality because they needed a, you know, solution to environment variables if they're creating almost a CICD. So, I think it's kind of hand in hand with that, but yeah, the exact same problem, right? [36:29]
-
-Like, even if you, before these workflows, what you had was you had the same environment variables, probably in GitHub, and then you had them replicated somewhere in EAS for your builds, and then somewhere else in your, for your updates. Maybe this removes some of that duplication, so at least your client side secrets. are sort of shared by Expo and managed by Expo. I hear your pain with the Kubernetes and backends, like infrastructure environment variables. I've done the exact same thing with GCP and Terraform and trying to manage those and it's not a, it's not a fun ride. [36:58]
-
-**Carl:** Nope. [36:59]
-
-## [Expo SDK 52](https://expo.dev/changelog/2024/11-12-sdk-52)
-
-**Mo:** Cool, and last but not least, obviously they also released Expo SDK 52. they say that this is their biggest release ever and I kind of believe it because the new architecture is out Cool. So that is a big, big revamp of everything in the internals of React Native, and they obviously manage a massive SDK with a bunch of different libraries. [37:16]
-
-So they've had to make sure all of it is compatible. So far we're hearing about some pains with Expo Go. Some people are having some troubles with Expo Go because it suddenly switched to the new architecture by default. So people are having some upgrades. Issues, but that's to be expected, to be honest, with such a big revamp of the internals and people will need to update their apps. [37:35]
-
-Some interesting highlights, just quickly running through these. Expo Video is a new library that's become stable now. So this is a revamp of the old Expo AV library that handled audio and video. They're splitting these out to Expo Video and Expo Audio. And it comes with a whole bunch of cool stuff. [37:50]
-
-Like, being able to generate thumbnails, being able to have picture in picture and a whole bunch of other stuff which is, is needed to, to kind of play video in a, in a high quality way in native apps. They've also released a beta of Expo Audio, which is, again, a rewrite, and this is great, and hopefully it just becomes a little bit nicer implementation. [38:09]
-
-And then they're releasing a whole bunch of stuff to their file system libraries, their cameras, and so on and so forth, Expo Images getting some updates. So there's a lot of good things. I'm not going to go through all of them because it is a massive changelog. But go and try it out. DOM Components as well, which we mentioned earlier on, is available with Expo SDK 52. [38:25]
-
-So if you want to play around with those DOM Components and figure out how you can integrate WebViews inside of your existing app with DOM Components, go for it. Expo SDK 52 is the place to try it out. [38:36]
-
-**Mark:** Sounds like a pretty big deal. [38:38]
-
-**Mo:** Yep. [38:39]
-
-**Carl:** Maybe one day I'll use Expo. [38:41]
-
-**Mo:** I'd love to hear your feedback on it, Carl, because it's quite a nice DevEx. I've had people who've, like, have you, you've built for React Native back in the day, right? [38:49]
-
-**Carl:** Yes. Short answer, yes. [38:51]
-
-**Mo:** it's usually people who have built with React Native or built native apps before, ages ago, and then they come in and try Expo, and they're like, holy crap, this is something. it has that, like, mind blowing effect, so I'd love for you to try it and then come with your feedback. [39:04]
-
-**Carl:** I briefly tried Expo like five years ago, [39:08]
-
-**Mo:** Not the same. yeah, they're totally different, totally different, totally different ecosystem. Yeah. [39:13]
-
-**Carl:** I remember it had a huge constraint of, it felt a little bit like a create react app in that it did a lot. But if you were building a production app, you were going to have to eject from it sooner or later. And the ejection story sounded pretty rough. [39:28]
-
-**Mo:** yeah, ejection was not a fun time. they had a lot of, I think that was the biggest, like Expo had almost a dip in reputation and it was because of ejecting. And so they, they completely got rid of ejecting. You don't eject anymore. You can add native dependencies as you wish. And it's a totally different mechanism. [39:42]
-
-So Expo in 2019, 2019. is a very different thing to Expo in 2024. And I'd say they've regained that reputation, which is great. [39:52]
-
-**Carl:** Cool. Sounds good. Yeah. I guess my, perception way back when was like, this feels like create react app, create react app feels like it's dying. This feels like it might die, but here we are five years later and it is totally transformed. Looks really great. This is definitely what I would, you know, were I to try a native app. I got a long list of other things to do. [40:10]
-
-## New CSS
-
-**Carl:** Cool. Okay moving on. This is slightly unstructured. [40:14]
-
-## [A Friendly Introduction to Container Queries](https://www.joshwcomeau.com/css/container-queries-introduction/)
-
-**Carl:** I'm going to frame this conversation around a Josh Kumo article about a friendly introduction to container queries. I don't think I had heard of container queries, but like, I was reading this was like, holy shit, there is so much new CSS stuff that I, that has just not crossed my radar. [40:31]
-
-So container queries are basically media queries, but for the containing element. So you can say all sorts of things. not super duper sure what the support story looks like for them. that's basically why I checked out of paying close attention to CSS news is because it was so much of it is like Chrome only, or, you know, not supported in Firefox or Safari. [40:54]
-
-And so like, stopped paying attention because so many of the things that looked really interesting and neat were not stable. And if a CSS feature is not stable, you can't polyfill it in the same way as JavaScript. Bye. [41:05]
-
-## [A Framework for Evaluating Browser Support](https://www.joshwcomeau.com/css/browser-support/)
-
-**Mark:** Conveniently on that note, Josh also just put out a post that discusses his approach for looking at browser support for various features, CSS or JavaScript, and sort of like his mental model of, how do I decide when a feature works? Might be good for me to actually use in practice. Of course, like it literally, it basically boils down to it depends, but he walks through kind of the process of how he gets to that and the article actually literally starts out according to can I use container queries are supported for almost 93 percent of users. [41:39]
-
-**Carl:** Right, and I see in the, thumbnail, in the, you know, preview image, is 93 percent good enough? And that was exactly my response to that. So, I don't know. it's a hard thing. [41:47]
-
-so, container queries just caught my eye as like a great Way to do a great enhancement over media queries because media, queries, you can adjust your styling based on, you know, the size of the screen, based on the capabilities of the device, but container queries, it looks like, I don't know the depth of the capabilities, but the most obvious one I'm seeing right here, you know, the first one it shows is, you know, mid width of the containing element and like, that's great. [42:18]
-
-I have had so many responsive. design bugs where, I try to reuse an element in a new context and it's narrower because I wanted to put more elements next to each other or something than I did in the previous one and it looks like with container queries I could Avoid those bugs by saying, if the space this is in is this size, render in this way. Which is a very different, much more powerful method of querying than just the device support. So, yeah, that seems really [42:53]
-
-**Mo:** I'm curious as to when, I think it's still probably in, experimental phase, but I'd love to see when this becomes available for something like Tailwind. [43:01]
-
-**Carl:** Right, and it might, I wonder if it would even be like a breaking change. Because they currently have, you know, SM, MD, different size constraints. Thanks. Thanks. And it feels like they might be able to just modify those to be based on the container. [43:16]
-
-**Mo:** they've done that exact pattern when they like introduced the group functionality. Like, they obviously had like hover, active, focus, or whatever for the different states, and then they just added a group colon active. So I wonder if this becomes like a container dash sm, container dash md, or something like that. [43:31]
-
-Like, that would be consistent in my mind, at least. [43:34]
-
-**Mark:** quick Google search says that they put out a first party plug in for container queries back in 2022. And there's something involving an at container wrapper on a parent. [43:48]
-
-## [State of CSS 2024](https://2024.stateofcss.com/)
-
-**Carl:** I said this is going to be kind of a loosely structured thing, related to this conversation, there was a state of CSS survey, you know, same as state of React, state of JS, whatever, Devographics, Sasha Greif and I was just looking at the list of CSS features and thinking like, wow, I have not used more than half of these. CSS is totally different. And you know, in the introduction to this State of CSS survey shouts out, "let me make a prediction. We'll look back at 2024 as the turning point between CSS classic and new CSS." And that's interesting. I feel I definitely learned and became expert in classic CSS. CSS Classic. [44:31]
-
-Describes as like, the build steps and all of that. I had to learn floats and positioning and box model and I feel like none of those things are super relevant anymore. Now it's grid and flex. And so it's just like a whole new set of Primitives that I have not had professional experience using like oh dang cool. Wow shifting landscape know what? I thought was stable land is now totally different just really [45:01]
-
-**Mo:** I the one that always, like, that winds me up that I learned about a little while back, that was just like, What? Why does this exist? But it's also very impressive that it exists. Is, like, the mathematical functions that you can use now in, like, CSS for calculating values. Like, power of, square root, logarithms. Like, how do I, what case do I have where I need to, like, calculate a size based off of a logarithm in CSS? Like Cool, I'm glad it exists, but I can never imagine needing to use that. [45:30]
-
-**Carl:** we do some funny layout logic and on the Reactiflux website. And yeah, you can do that. the font size is based on the viewport width, for instance. [45:41]
-
-**Mo:** but would you ever use a logarithm based off of that? [45:43]
-
-**Carl:** Hey, maybe if I wanted to, you know, nonlinear scaling, [45:46]
-
-**Mo:** Yeah, maybe. Anyway, it's quite cool. [45:48]
-
-**Carl:** I don't know. Wild. [45:49]
-
-**Mark:** big picture metaphor. I think what's come into my mind is that it feels like it's a little bit like the ES 2015 spec where you could do a lot of stuff in JavaScript prior to that. And a lot of stuff in ES2015 was effectively syntax sugar for stuff you could do before. But there were also a number of things in ES2015 that required support at the language runtime level, like proxies, that simply could not be done before and enabled virtualization. [46:17]
-
-A whole lot of new functionality from there. So, you know, I, I know that CSS is not like a strictly versioned spec the way that, you know, the JS language is at this point, but I think that's kind of the, the metaphor that we're going for here. [46:31]
-
-**Mo:** yeah. [46:32]
-
-interesting. Complete side note before we move on, but since we started with this, Josh Comeau his website is like one of the most beautifully designed tech websites I've seen. Like, I say this every time I look at it, I'm like, wow, this is beautiful. He's done a phenomenal job with this website. [46:47]
-
-**Mark:** Josh is amazingly talented, he is an amazing educator, his blog is wonderful, I can vouch for his courses without having looked at them because I see the care and effort he's put into his blog post. So, highly recommend all of Josh's stuff. [47:00]
-
-**Carl:** Very, very true. [47:02]
-
-## Framework betas:
-
-**Mark:** Okay, moving on a little more quickly, a couple different frameworks and pieces are in beta. [47:08]
-
-## [RSC in Expo Router is now in Beta!](https://expo.dev/blog/universal-react-server-components-developer-preview)
-
-**Mark:** One is that the Expo router now has support for server components. And Mo can probably talk a little bit more about the actual implementation nuances here, but big picture, it's a big deal because it's server components coming out in any framework other than Next, and more specifically within the React Native ecosystem. [47:29]
-
-## [TanStack Start beta](https://tanstack.com/router/latest/docs/framework/react/start/overview)
-
-**Mark:** And then as sort of an inverse of that, Tanner Linsley's 10 stack start framework is now in beta, and it's a deliberately non server component framework for now. Tanner has said he will look at adding some server component support down the road, but his argument, and he's made BlueSky within the last few days, is that he feels server components are actually of very limited use. [47:59]
-
-and really much less flexible compared to a server function concept architecture for managing data. So he did just do a talk about and kind of advertising some of the features at React Summit New York last week. I looked, if you check out the Git Nation website, the video is available for people who have, you know, paid up for the early access to the videos and it'll go public sometime in the next month. [48:27]
-
-**Mo:** Just to quickly touch on the exporouter RSC stuff, So it is very much an experimental at this point, it's beta. You can't even host it on a production server, you need to do it locally, so it just means you're basically testing it out in dev at this point. It was previously just on Evan Bacon's machine, and now it's on, you can have it on your machine, which is quite, quite cool. [48:47]
-
-But yeah, like the cool thing about RSCs and React Native is that you're rendering native components under the hood. So you almost render native views, native texts, native images, and you almost do a building block of components through an RSC that is then rendered natively, so it's not web views or anything like that. [49:03]
-
-So it's very different to the DOM component stuff that we talked earlier, which makes it very interesting. Still very early days, but we've seen really cool demos of this over the last year at React Conf and beyond. [49:14]
-
-## [React Native 0.77 RC0](https://github.com/facebook/react-native/releases/tag/v0.77.0-rc.0)
-
-**Mo:** Picking on the React Native terrain, very quickly, React Native version 0. 77 has had its release candidate, which is very quick after 0. 76. This is a very small release. Expectedly so, after the massive release that was the new architecture becoming default. So, just some quick things. Swift templates for iOS. [49:35]
-
-This is taken away from the Objective C base of code in the internals of React Native and making it more Swift based and more modern, which is great. They've done some improvements on tvOS integration, which is great because tvOS has kind of been one of those platforms that's been in the shadows and not well supported. [49:52]
-
-And there's some general better performance improvements specifically when dealing with animations. So there's some minor improvements, but nothing super major and not a whole lot of breaking changes. [50:02]
-
-## [New List dropped in React Native](https://x.com/jmeistrich/status/1855663310386958840)
-
-**Mo:** Now, speaking of the new architecture Last month we had the release of the new architecture with 0. 76, and we're already seeing some interesting stuff coming out of it. [50:12]
-
-So, Jay Meistrich, who I've known for a little while now, actually released a completely new list component for React Native called LegendList. So, Jay maintains a few libraries called, like, LegendState, another state management library, and I think LegendMotion, which is an animation library. And he recently Created a new list, and now he, he claims that I inspired him to do this at a talk that I did at React Advanced, which is very flattering, and I think he's giving me way too much credit and I definitely don't deserve that, but basically the, the whole concept is with the new event loop in React Native, you can kind of synchronously call on layout events. [50:50]
-
-Which you previously couldn't with React Native and so this is a JS only implementation as a list and it seemingly, on first glance, outperforms FlashList and the FlatList that comes default with React Native so it may be the quickest list in the React Native ecosystem right now. A lot of people are very, very excited by it. [51:08]
-
-Jay is quite good at performance stuff because he spent a lot of his time as a game developer back in the early 2000s basically. So, he was dealing with a lot of very, very, very low memory and low CPU devices. And I guess he kind of knows this stuff decently well. So it's going to be interesting. [51:25]
-
-He's released it to public, so you can go and try it out right now. But it's still to be seen. He's adding more and more APIs as we, as we speak. So it's quite interesting. [51:33]
-
-**Carl:** Super cool. Mo, I'm going to challenge you on that because if somebody tells you that you were an inspiration, I think you should [51:39]
-
-**Mark:** Take all the credit. [51:41]
-
-**Mo:** I just did a talk. It was nothing special. [51:44]
-
-**Carl:** Ah, that's pretty special. [51:45]
-
-## Twitter -> Bluesky migration
-
-**Mark:** All right, and our, our last big item for this episode is, is not directly tech related, but it is, because React is more than the tech, it's the people in the community, and, you know, we, we spend time talking about conferences, but, you know, we, we get a lot of our links and keep an eye on things from, you know, historically, from Twitter, and Twitter has been where, you know, most of the web dev community has chatted and interacted online for the last several years. [52:11]
-
-And without going into, you know, some of the, the political or, you know, aspects behind it Twitter has declined a lot in the last couple of years. And there's been various waves of people saying I'm done with Twitter and I'm leaving. And the main alternative that a lot of people had gone with was Mastodon. [52:27]
-
-But Mastodon's always had sort of that, like, I'm a Linux user and I know how to set up everything myself kind of a vibe to it. And there's been an alternative to Twitter called BlueSky, which had been invite only for a while. I believe they opened up to public signups maybe about a year ago. But it always felt very niche. [52:48]
-
-And really the main thing I knew about it over the last year was that Dan Abramov, after leaving Facebook had gone over there to actually work on their web and native apps as, as his day job. Well, there has been a massive migration of the greater web development tech community from Twitter over to BlueSky really within just the last month. [53:13]
-
-And I mean, there's, there's been lots of other. Twitter communities that have moved over there black Twitter, football, Twitter, basketball, Twitter, science, Twitter, etc. And feels like, to me, like one, in the earlier era of Twitter where it was people talking rather than just bots or big businesses. And two, the, you know, just the general atmosphere and sort of discussions that are, that are happening. [53:43]
-
-So, a lot of people from the React community have signed up and started being very active over there. A number of people have specifically deleted their old Twitter accounts. As an example, Seb Markbaga from the React team. I believe actually nuked all his old tweets, and moved over to Blue Sky. I think Dan Abramov's Twitter accounts are, are, are gone at this point. [54:09]
-
-So a number of people are doing the Scorched Earth thing, and like, wiping out all their old messages, which I'll be honest, as someone who has always depended a lot on, you know, archiving the web and, you know, linking to external discussions makes me sad because I hate to see historical discussions and tweets and artifacts go away. [54:33]
-
-Having said that, as far as the community goes, I personally am feeling Like Blue Sky is probably where I'm going to put my posting energy going forward. There is, there's a lot of people there. It feels like the community is self sustaining at this point. And it's where a lot of the discussion is happening now. [54:54]
-
-## Starter packs: [ericclemmons/awesome-starter-packs](https://github.com/ericclemmons/awesome-starter-packs), [stevendborrelli/bluesky-tech-starter-packs](https://github.com/stevendborrelli/bluesky-tech-starter-packs) [Bluesky Directory](https://blueskydirectory.com/) [A complete guide to Bluesky 🦋](https://mackuba.eu/2024/02/21/bluesky-guide/)
-
-**Mark:** One nice thing is that Blue Sky has these things called starter packs, where anyone can just make a list of people they recommend on a certain topic. And it makes it very easy to follow some or all of them. At once. There are directories of starter packs out there. there's a question about whether BlueSky is kind of related to crypto related things. [55:13]
-
-## [Technical debate](https://dustycloud.org/blog/how-decentralized-is-bluesky/) over [how “decentralized”](https://whtwnd.com/bnewbold.net/3lbvbtqrg5t2t) Bluesky actually is
-
-**Mark:** there were a couple good articles talking about some of the technical implementation differences at the server level between Mastodon and BlueSky and like how actually decentralized things are. Loosely put, BlueSky is semi centralized, but it's possible to run your own server and own your own data, somehow. [55:38]
-
-So, big picture, a lot of folks who are from the React community are no longer active on Twitter, and they are now active on BlueSky. [55:47]
-
-**Carl:** Yep, can confirm. Definitely saw a massive shift in the last, like, month. It's been notable. Yeah. Definitely a lot more people posting out there, yeah. [55:57]
-
-## [Web Without Walls | React Universe Conf 2024](https://www.youtube.com/watch?v=F1sJW6nTP6E)
-
-**Mo:** because of the crypto question, if you're interested in how the BlueSky backend and like the decentralized nature of BlueSky operates, Dan Abramov did a talk at React Universe Conf about this called Web Without Walls, so I've just shared that and that gives a pretty comprehensive, it is a 40 minute talk, but that gives a pretty long and comprehensive discussion about what the nature, the decentralized nature of BlueSky is. [56:22]
-
-Quickly to add on this, actually, BlueSky is a universal React Native app. So it uses ExpoRouter and it's basically using the same code base for web and mobile, which is quite cool. And you're seeing something in production that's being used by, as we speak, 17, 18 million users now, which is pretty [56:40]
-
-**Mark:** They reached over, like, 21 million a couple days ago. okay. So I'm clearly off of the uh, off of the numbers. [56:47]
-
-There was about a week and a half where they were adding about a million people a day. [56:51]
-
-**Mo:** React Native London Conf, we actually had the and Sam from the BlueSky team. Dan now works mostly on the AT protocol stuff, but Sam works on the mobile app and the web app. They are talking about it. This was while they were getting a million per day. So it was quite cool to see them there talking about some of the stuff that they're working on. [57:06]
-
-It's a really cool team, and it's a very small team that's building this, which makes it all the more impressive. And it's super cool that they can take on the likes of a certain someone who's multi multi multi billionaire who's trying to create his own community. So, you know, pretty cool. [57:20]
-
-**Carl:** Yep, it is super cool. I could probably talk a lot more about it. I have opinions on this. And I've been thinking about the need for data portability and the benefits, the potential benefits of decentralization in the context of social media for most of a decade. I'm actually considering if I want to try and do a business effort based on the underlying data that is BlueSky. [57:45]
-
-I think that there's a lot of opportunity to iterate on the UI layer of social media. And if you have a common public data set, that's a lot easier to do. [57:53]
-
-**Mo:** on that Carl, the current BlueSky app was not the original BlueSky app Which makes it all the more interesting. So Sam created his own BlueSky client It was better than the original BlueSky app because he could use it with the AT protocol And then they just hired him and made Sam So it kind of shows that like, with this decentralized nature, anyone can make a client and sometimes it'll be better. [58:14]
-
-Kind of like the, what was that Reddit client that was better on, on iOS back in the day, but then Reddit shut it down? I forget [58:20]
-
-the name. [58:21]
-
-**Carl:** of them. Apollo? [58:22]
-
-**Mo:** Well, [58:23]
-
-**Mark:** all, all of them, yeah. [58:24]
-
-**Mo:** all of them, but Apollo. So yeah, similar story, but the decentralized nature helps with that. [58:29]
-
-**Carl:** It does. And also the BlueSky client is both a universal React native app, and it's also open source. So I've seen a bunch of React and web people, like not just posting on BlueSky, but what they're posting is their experiments building, you know, iterate changing the UI of the client they're posting from like, Oh, wouldn't it be great if we had Markdown support in BlueSky? [58:51]
-
-Look at this proof of concept that just hacked [58:52]
-
-**Mark:** We're splitting [58:53]
-
-**Carl:** a PR. [58:53]
-
-**Mark:** the notifications tab into subtabs. [58:56]
-
-**Carl:** could talk a lot more about this. We're already 10 minutes over and. Still need to do the lightning round. But yeah, okay, Blue Sky's great. Follow me. [59:03]
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Alright, lightning round, go! [59:06]
-
-## [Deno v. Oracle: Canceling the JavaScript Trademark](https://deno.com/blog/deno-v-oracle)
-
-**Carl:** Deno vs. Oracle. We mentioned this a while ago. I think two months ago. Deno opened a petition to ask Oracle to release the JavaScript trademark, and this is a follow up to that. Seems neat. Seems cool. Love it. They are like formally asking Oracle now. It has moved on from just a petition. [59:27]
-
-## [Two ways to the two Reacts](https://bobaekang.com/blog/two-ways-to-the-two-reacts)
-
-**Mark:** Next up, an author named Bobae Kang has written some good articles talking about the mental mindset of React at a very conceptual, architectural level. And has a good post called, The Two Ways to the Two Reacts, which kind of contrasts Next, where everything is about the server first, versus something like a tan stack start, which is client first, and then optionally adding in the server. [59:52]
-
-## [That's not an abstraction, that's just a layer of indirection](https://fhur.me/posts/2024/thats-not-an-abstraction)
-
-**Carl:** Another one. Great post that I love, called, That's not an abstraction, that's just a layer of indirection. [59:59]
-
-**Mark:** True that [01:00:00]
-
-**Carl:** Just generally true, like, end of, end of comment. [01:00:04]
-
-## [React Anti-Pattern: Stop Passing Setters Down the Components Tree](https://matanbobi.dev/posts/stop-passing-setter-functions-to-components)
-
-**Carl:** Related, while I was looking for, you know, doing my final pass of resources to pull in I've seen this anti pattern kind of blog post called stop "passing setters down the components tree" and, agree. [01:00:17]
-
-That is a wonderful example of not an abstraction. If you're just passing the set state setter down as a prop, you should probably do it differently. [01:00:26]
-
-**Mark:** something something dispatching actions. [01:00:29]
-
-**Carl:** Aha. What Redux? [01:00:31]
-
-## [What is HTTP/3?](https://www.cloudflare.com/learning/performance/what-is-http3/)
-
-**Carl:** Yeah, I saw a neat post from Cloudflare called, What is HTTP 3? That made me go, whoa, I didn't know there was an HTTP 3. So yeah, that exists. It's something about QUIC. And I think it's related to, like, I don't know. It sounded like the promise benefits. They sounded very familiar from what I remember reading about HTTP 2, which as far as I know have not really been realized. So Seems like a new attempt to edit something something UDP, HTTP 3. [01:01:03]
-
-## [Leaked Vercel v0 system prompts](https://old.reddit.com/r/LocalLLaMA/comments/1gwwyia/leaked_system_prompts_from_v0_vercels_ai/)
-
-**Carl:** Someone posted on Reddit that they managed to exfiltrate the system prompts for Vercel's V0 AI UI generation tool. And that's cool, that's interesting. It looks like this was not, you know, any weird black hat stuff, like they just saw something leak. and managed to continue prompting the AI until they got the full system prompt. [01:01:25]
-
-So this is output from the AI, which means it might not be real, but it does seem approximately correct. You know, Must write valid JavaScript code that uses state of the art Node. js features and follows best practices. Does not use the components. You know, so it's like massive, massive prompt. [01:01:44]
-
-I think it's an interesting, you know, peek behind the curtain. This is what the wizard looks like kind of [01:01:50]
-
-**Mark:** And today's example of why I do not want to spend the rest of my career writing prompts. I want to write code. [01:01:57]
-
-**Carl:** What's the difference? [01:01:59]
-
-## [React Scan to highlight component renders](https://react-scan.million.dev/) (by the author of Million.js), which he used to point out [Github’s code view re-rendering on every scroll](https://x.com/aidenybai/status/1859267710498263073)
-
-**Mark:** Alright, a couple perf related items. Aiden Bai, the author of the Million. js React plugin for performance, I guess. Recently put out a new tool called React Scan, which can be used to identify, you know, components that are over rendering in your app. I glanced at the source code for 30 seconds and saw that it's messing around with some of the internals of React's Fibretree, and as someone who has spent a lot of time messing around with the React code, And React's internals in the React DevTools. [01:02:28]
-
-I have a sense of how this is probably working, and I approve. In fact, he actually used it to identify that GitHub's current source file display, which is based on React, was apparently re rendering all the lines every time you scrolled. And he even managed to identify, yeah, like, here's the component. [01:02:46]
-
-And here's like the prop that needs to be memoized in order to fix that. And a couple hours later, some GitHub engineer actually fixed it. So that's a step in the right direction. [01:02:56]
-
-## [What’s Next for the React Compiler?](https://www.youtube.com/watch?v=qd5yk2gxbtg)
-
-**Mark:** On a similar note, Satya from the React team just did a, just did a, an update talk called what's next for the React compiler talking about some of the upcoming features they're thinking of working on that would hopefully further improve performance. [01:03:10]
-
-**Carl:** Very smooth. Unrelated, non smooth transition [01:03:14]
-
-## [Framer Motion spinning out as an OSS tool (Motion)](https://motion.dev/blog/framer-motion-is-now-independent-introducing-motion), and conversely [GSAP is joining WebFlow](https://gsap.com/blog/webflow-GSAP/)
-
-**Carl:** Framer Motion which is a React animation tool. Uh, Is spinning out. It is no longer under the Framer brand and it is no longer React specific. Uh, It's just an open source tool called Motion, which seems cool. Framer Motion is definitely something I've heard about a lot for doing like complex, advanced animations and whatever. [01:03:37]
-
-So yeah, it seems cool. Love it. In the inverse direction GreenSock animation platform, GSAP, was acquired by Webflow. Love it. Love seeing open source tools get money. The maintainers do a lot of work and they deserve to be compensated for it. So yeah, super happy to see that. [01:03:54]
-
-**Mark:** This feels like that, you know, that classic line about there's two ways to make money. Bundling and unbundling. [01:04:00]
-
-**Carl:** Yes. 100%. [01:04:03]
-
-**Mark:** One library leaves, another library joins. [01:04:05]
-
-**Carl:** Right, every company is either a bundling or unbundling play and here we go. Here's two examples. Well, all right Thank you everyone for joining us and sticking with us all the way to the end. We will be back Well, actually we will not be back on the last Wednesday of the month because the last Wednesday of December is Christmas and we are Not recording on Christmas. I am so sorry. I'm not sorry [01:04:26]
-
-But yeah, we so we will be back recording at the end of December probably that Monday TBD Or back in your podcast feed as soon as we can. Yeah, thanks so much, Mark. Yeah. Always [01:04:37]
-
-**Mark:** nice too be here. I'm very much looking forward to a nice long Thanksgiving break where we'll probably mostly be hacking and Redux stuff. [01:04:43]
-
-**Mo:** yeah, it's always a pleasure to be here. Um, Lovely chatting with you all and loved getting into blue sky shenanigans this month, so we'll see what next month has in store for us. [01:04:52]
-
-**Mark:** Thank you for the behind the scenes bit on that. I did not know that they'd swapped clients. [01:04:56]
-
-**Mo:** I'll hopefully share the recording once we have it live and everyone can hear the story from the comforts of their home. [01:05:02]
-
-**Carl:** Cool. All right. We gather sources from this week in React, bytes. dev, react status, Next. js Weekly, the React. js subreddit, here in Reactaflux, and directly from people publishing articles, mostly on BlueSky. If you see anything newsworthy, definitely let us know by posting it in the Tech News and Reads channel here in Reactaflux, or send me an email. [01:05:24]
-
-I will read it if you send me an email to hello at reactiflux. com yeah, I read everything. I will read it. If this is a show you get value from and want to support, best way to do so is by submitting a review and by telling your friends and coworkers about it. Help them get as smart as you are about React. [01:05:41]
-
-See you next month.
diff --git a/src/transcripts/tmir-2024-12.md b/src/transcripts/tmir-2024-12.md
deleted file mode 100644
index eac2257..0000000
--- a/src/transcripts/tmir-2024-12.md
+++ /dev/null
@@ -1,592 +0,0 @@
----
-title: "TMiR 2024-12: React 19 is here 🎉 "
-date: 2024-12-23
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:45](#sponsored-by-infinite-red)] Sponsored by [Infinite Red](https://infinite.red/)
-- [[02:46](#new-releases)] New releases
- - [[02:48](#relay-v182)] [Relay v18.2](https://github.com/facebook/relay/releases/tag/v18.2.0)
- - [[03:07](#react-admin-v54)] [React-admin v5.4](https://github.com/marmelab/react-admin/releases/tag/v5.4.0)
- - [[03:16](#preact-v1025)] [Preact v10.25](https://github.com/preactjs/preact/releases/tag/10.25.0)
- - [[05:25](#playwright-v149)] [Playwright 1.49](https://playwright.dev/docs/release-notes)
- - [[05:33](#astro-v50)] [Astro 5.0](https://astro.build/blog/astro-5/)
- - [[06:00](#radon-ide)] [Radon IDE](https://ide.swmansion.com/)
- - [[07:57](#react-19-compatibility-in-react-redux-and-redux-toolkit)] React 19 compat for [react-redux](https://github.com/reduxjs/react-redux/releases/tag/v9.2.0) and [Redux Toolkit](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.5.0)
-- [[10:37](#main-content)] Main Content
- - [[10:39](#react-19-is-finally-out-blog-post)] [React 19 is actually out](https://github.com/facebook/react/releases/tag/v19.0.0) ([blog post](https://react.dev/blog/2024/12/05/react-19))
- - [[11:16](#upgrade-guide-from-april)] [Upgrade guide from April 2024](https://19.react.dev/blog/2024/04/25/react-19-upgrade-guide)
- - [[11:31](#removed-things)] Removed things
- - [[17:07](#new-things)] New things
- - [[28:42](#ref-callbacks-react-19-and-the-compiler)] TKDodo: [Ref Callbacks, React 19, and the Compiler](https://tkdodo.eu/blog/ref-callbacks-react-19-and-the-compiler)
- - [[34:07](#react-native-screens-400)] [Introducing React Native Screens 4.0.0](https://blog.swmansion.com/introducing-react-native-screens-4-0-0-1b833ff98a55)
- - [[37:00](#react-19-and-react-native-and-pr)] [React 19 support in React Native TBD](https://github.com/react-native-community/discussions-and-proposals/issues/842#issuecomment-2527591610) (0.77/78?)
- - [[38:58](#expo-experimental-support)] [Expo has experimental support](https://x.com/Baconbrix/status/1864785257297305833)
- - [[40:37](#next-151)] [Next 15.1](https://nextjs.org/blog/next-15-1)
- - [[39:52](#nextjs-experimental-css-inlining)] [experimental: css inlining](https://github.com/vercel/next.js/pull/72195)
- - [[41:33](#react-native-fast-io)] [React Native Fast IO now in prerelease](https://github.com/callstackincubator/react-native-fast-io)
- - [[43:27](#npx-create-target)] [Create Target Widgets in Expo](https://x.com/Baconbrix/status/1868672438898455023)
-- [[44:55](#lightning-round)] ⚡ Lightning round ⚡
- - [[45:02](#react-native-demo-for-android-xr)] [React Native demo for Android XR](https://x.com/o_kwasniewski/status/1868645896239690009)
- - [[45:43](#if-not-react-then-what)] [If Not React, Then What?](https://infrequently.org/2024/11/if-not-react-then-what/)
- - [[50:14](#vitest-vs-jest)] [Vitest vs. Jest](https://www.speakeasy.com/post/vitest-vs-jest)
- - [[52:29](#aiden-bai-render-shaming-sites-while-working-on-react-scan)] [Aiden Bai “render-shaming” sites](https://x.com/aidenybai/status/1862529226727121366) while [working on React Scan](https://react-scan.com/)
- - [[55:14](#lenzs-webers-testing-libraryreact-render-stream-testing-library)] [Lenz’s Weber’s testing-library/react-render-stream-testing-library](https://github.com/testing-library/react-render-stream-testing-library)
-- [[58:13](#outro)] Outro [00:00]
-
-**Carl Vitullo:** Hello people. Thank you for joining us for the December edition, the end of 2024. this is almost this year in React, this time around. [00:08]
-
-But yeah thanks for joining for December's This Month in React, wherewe recap and digest recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:22]
-
-I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like this. [00:29]
-
-**Mark Erikson:** Hi, I'm Mark. My day job is working at Replay building a time traveling debugger for JavaScript and outside of that I do ridiculous amounts of Redux stuff. [00:39]
-
-**Mo Khazali:** And I am Mo. I head the mobile team at Theodore. I'm quite active in the React Native ecosystem and I organized the React Native London meetup and conferences. [00:47]
-
-**Carl Vitullo:** Right into it. I don't really have a job market or conferences coming up this month. I had noted that over the last, six weeks or so, the list of upcoming conferences has dwindled down to zero. I've seen them start to pop back up again. [01:01]
-
-So we've rounded that corner of people getting prepared for next year, but we'll be back with some more conferences. to notify you of next month. [01:10]
-
-**Mark Erikson:** that is that I actually sat down and started trying to do preparation for applying to conferences for next year. Some of them apparently have already closed for next year. So it's, getting ahead of the timeline process. [01:24]
-
-**Carl Vitullo:** definitely getting ahead of it. Yeah small fun news for me, I am on staff for SquiggleConf next year, so, I'll have news for that, but it's not until September, so, no rush. Highly [01:36]
-
-**Mark Erikson:** recommendd folks going to SquiggleConf. It was great. [01:40]
-
-**Carl Vitullo:** But yeah, into it. Before we get all the way into the main content a note from our sponsor. [01:45]
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl Vitullo:** We are sponsored by Infinite Red, which is an expert React Native consultancy. They've been around since 2015, so like about to be 10 years, Give it another week or so and that'll be ten years. They're owned by Jermaine Holmgren, Todd Wirth, and Gant Laborde. They're our only sponsor in part because they do so much more than most consultancies and most of the companies in the ecosystem. [02:07]
-
-there's just not many other people who operate at the same level as they do. I've been seeing their name for as long as I've been active professionally. And they're still around. They're still doing great stuff. They only do React Native. They've built over 75 apps for companies and startups. [02:21]
-
-And other than great people who've done great things for the ecosystem they're a team of about 30, mostly devs, mostly 10 years of experience or more and they work alongside your team to develop expertise at that company. So if you are spinning up a new product with React Native, or just trying to develop in house expertise with React and React Native, they can definitely help you hit the ground running. [02:44]
-
-So give them a ring. https://infinite.red/. [02:46]
-
-## New Releases
-
-**Carl Vitullo:** cool. Into some new releases. [02:48]
-
-## [Relay v18.2](https://github.com/facebook/relay/releases/tag/v18.2.0)
-
-**Carl Vitullo:** First on the list, we got Relay18. 2. They've got an experimental hook for pagination with prefetching and a at catch directive, or the catch directive has been updated so it can be used on fragments and queries and mutations. [03:03]
-
-So just better error handling, looks like. Better pagination, better error handling. [03:07]
-
-## [React Admin v5.4](https://github.com/marmelab/react-admin/releases/tag/v5.4.0)
-
-**Carl Vitullo:** There's React. Admin, 5. 4 not a lot of notes here, but it's out, it's new, if you're using it, definitely check it out. [03:16]
-
-## [Preact v10.25](https://github.com/preactjs/preact/releases/tag/10.25.0)
-
-**Carl Vitullo:** Preact has a release, 10. 25 looks like stronger types. Support for object interface as a listener, , It looks like the last couple of releases have all been pretty small. So, you know, this is just sort of Preact doing its Preact thing. I'm not really sure if they're still abiding to the original idea of like drop in replacement for React. It's, I think, especially with React server components, they've diverged a little bit. But yeah, there's still use for it for sure. [03:45]
-
-**Mark Erikson:** Yeah, I've not sat down and tried to do a strict line by line feature comparison, but I think at this point generally support most of the original hooks. But I think beyond that, , they've stopped trying to match things feature for feature. So, if you're doing relatively straightforward things, then, you may have actual compatibility, especially if you like want to use any of the new, like React 19 features or anything with the Preact bundle, then obviously they wouldn't work. [04:14]
-
-**Carl Vitullo:** right. I guess my mental model for it is this is like, if you're working in a highly constrained environment where you would still like the niceties of React, React is great, but if you're not dealing with a highly constrained environment, then might not be necessary. [04:28]
-
-**Mo Khazali:** So an interesting one, I guess an interesting use case for Preact is that it's commonly used in TV development. If you're building web apps that are going to run on TVs, where there's a very, very small amount of resources. A lot of times I've seen people use Preact. So some big names in TV apps that you might've known, which I don't know if I should mention, but you know, some big TV apps will be using Preact because a lot of the apps that you have on TVs are web apps, but they need to be constrained in the resources that they use. Mm [04:57]
-
-**Mark Erikson:** is just ironic how Web app has become the default, way to distribute things everywhere. I [05:05]
-
-**Mo Khazali:** Yeah. I mean, web is like kind of a standard almost for TV, for TVs. Like if you're building for Samsung, if you're building for LG and a bunch of other TVs, you build it using a web app, so it's pretty cool that it's standardized around that. [05:18]
-
-**Carl Vitullo:** Yeah, I talked to someone about React Native on TV too, yeah. Neat. Funny. JavaScript eating the world. [05:25]
-
-## [Playwright v1.49](https://playwright.dev/docs/release-notes)
-
-**Carl Vitullo:** There's also Playwright 1. 49. Nothing too fancy there, but pretty widely used test tool, so if you're using that, there it is. [05:33]
-
-## [Astro v5.0](https://astro.build/blog/astro-5/)
-
-**Carl Vitullo:** Astro has a major release, version 5. 0. what they're calling content layer, a new flexible and pluggable way to manage content, providing a unified type safe API to define, load, and access your content, no matter where it comes from. Sounds a lot like Gatsby's [05:48]
-
-**Mark Erikson:** was about to say that, yeah. [05:50]
-
-**Carl Vitullo:** So fair enough, you know, like that's a real need, you know, loading content from many places. Very real need. Sounds like they're not using GraphQL for it. So, different take. Fair enough. [06:00]
-
-## [Radon IDE](https://ide.swmansion.com/)
-
-**Carl Vitullo:** Yeah, there was Radon IDE. Mo, you want to talk about that? [06:03]
-
-**Mo Khazali:** it used to be called the React Native IDE, and then they rebranded for obvious branding reasons to Radon IDE, fun little Easter egg. Radon on the element lists is RN. So, anyway React Native traditionally has not had an IDE. So, you know, you build in VS Code, but a lot of the functionalities that, if you were like a Swift or an Android developer, just wouldn't be there. [06:23]
-
-And so, the folks at Software Mansion have created Radon IDE as sort of a way to make your VS Code more of a Full fledged IDE for React Native development. So it comes with a bunch of cool stuff like integrating with like your simulator and then being able to inspect elements that are on the screen and find out where they are in code, which is really, really cool. [06:42]
-
-And it's sometimes a pain in React Native breakpoint support, understanding your navigation tree. They have debugging kind of nailed down, which has been a real pain in React Native, so that's quite cool. And then another thing that was a cool little gimmicky feature, I'd say, is instant replays. [06:57]
-
-So, you know, if something happens on your simulator and you're like, oh crap, that was a bug you can click back and get, like, the last 5, 10 seconds as a replay and then save that , to a file. So some cool little utilities, I'd say that you can use when you're building React Native apps. It is a paid IDE, so You know, it starts at, it's around 20 a month per seat. [07:17]
-
-But you know, so something to consider. So they're going for the paid model as almost a paid extension onto VS code. [07:23]
-
-**Carl Vitullo:** Interesting, huh? Definitely makes sense. I mean, times I've worked with React Native, the debugging experience was among the rougher sides of it, so it makes sense to have a stronger IDE integration for debuggability things. Cool. [07:37]
-
-and I believe Software Mansion is also Nope, never mind. I was gonna say behind React Admin, but no, they're not. [07:44]
-
-But then Software Mansion does lots of stuff in the ecosystem. They are Certainly, you know, I say not many companies do as much as Infinite Red and Software Mansion is definitely in the running there. A trusted name for sure. [07:57]
-
-## React 19 compatibility in [react-redux](https://github.com/reduxjs/react-redux/releases/tag/v9.2.0) and [Redux Toolkit](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.5.0)
-
-**Carl Vitullo:** Yeah, there's also React 19 compatibility release of Redux Toolkit. [08:02]
-
-Mark, anything you want to say there? [08:04]
-
-**Mark Erikson:** yeah number one, I actually had nothing to do with the work on these. One of the other maintainers, Arya, did all the actual grunt work. in React Redux, we now test against both 18 and 19. you'd think it would be as simple as just bumping the peer dependencies list and shipping, but, you know, you actually want to test against them, you have to check any, any types related issues. [08:27]
-
-in the Redux toolkit case, it's actually caused a ripple effect where we. I merged the PR to support React 19 at, you know, at the code level. And we accidentally ended up, semi accidentally ended up bumping React 19 for our DocuSource based docs website. And that ended up breaking client side interactivity because we were still on DocuSource version two. [08:52]
-
-Which didn't correctly support React 19 somehow. So the doc site built and you could view it, but it was the static, you know, HTML only and all the client side interactivity broke, search, copy code button, everything else. On the one hand, it's like, you know, conceptually, it's simple. On the other hand, there's actually a lot of work involved. And then there's always the, you know, the unexpected ripple effects afterwards. [09:19]
-
-One other ripple effect I've seen, which I don't think we have listed directly, but I've seen a lot of people report problems with Create React App because, you know, like, beginners are trying to I assume beginners are trying to create new CRA projects. They're using, you know, It uses NPM to do the installation by default, and the CRA templates still use an existing version of React testing library that wants React 18 as a peer dependency. [09:50]
-
-And so, what happens is, NPM tries to install the packages, Also tries to install React 19, because that's the latest. And then, NPM being its helpful self, throws an error because there's a peer dependency mismatch between the installed React 19 and React Testing Library 1. 18. So, I've seen a bunch of people report, Why can't I create a new React project? [10:16]
-
-With that kind of an error in the last couple weeks. And so basically CRE's borked at this point. I [10:22]
-
-**Carl Vitullo:** That is unfortunate, yeah. But also not too surprising. I guess it's a little bit of a matter of time for that. Too [10:28]
-
-**Mark Erikson:** in theory it could be fixed with, like, someone publishing updates to the templates, but I have no idea who, if anyone, would do that. [10:35]
-
-**Carl Vitullo:** Not sure how actively maintained that is anymore. [10:37]
-
-## Main Content
-
-**Carl Vitullo:** Alright, into our main content. [10:39]
-
-## [React 19](https://github.com/facebook/react/releases/tag/v19.0.0) is finally out ([blog post](https://react.dev/blog/2024/12/05/react-19))
-
-**Carl Vitullo:** The main, main, main, main, main content of React 19 is out. It is officially released and usable. [10:47]
-
-**Mark Erikson:** Yay! [10:48]
-
-**Carl Vitullo:** Yeah, so, we're gonna spend a minute, pretty much everything in these, you know, release notes and, , overview blog posts. , there's nothing brand new, , they've been messaging this, they've been talking about it, they've been, you know, trickling out bits. over the last year and a half. So pretty much everything in this episode that we're going to discuss, at least for React 19, we've already covered in some detail in the past, but we're going to bring it all together. this is the one where we talk about it all holistically. [11:16]
-
-## [Upgrade guide from April](https://19.react.dev/blog/2024/04/25/react-19-upgrade-guide)
-
-**Carl Vitullo:** Yeah, there's a great upgrade guide from back in April. I think that was before they found the issue with Sibling. [11:23]
-
-**Mark Erikson:** Yep, because that happened at the start of June. [11:26]
-
-**Carl Vitullo:** So that was when they thought it was going out pretty, pretty shortly. Here we are eight months later, and it's out! [11:31]
-
-## Removed things
-
-**Carl Vitullo:** I'm gonna start with what they took out, because I, it's a lot of things that I, Remember using, I remember fondly. [11:38]
-
-So they removed prop types. There's no more prop types it just silently gets ignored. know, they mentioned prop types were deprecated in April 2017. So here we are seven years later, and it's finally, a deprecated feature is finally being removed. Wow. Likewise, they removed default props for functions. For class components, those still have default props, but for a function component, just give it a default argument. It'll figure it out. [12:05]
-
-Finally removed legacy context. Also, just like prop types, deprecated in October 2018. Six years later, here we are. They removed string refs, the create factory helper, because that was if you can't use JSX, you can use this instead. So yeah, everyone uses JSX. Widely supported. [12:25]
-
-**Mark Erikson:** I've used a couple different little third party helper libraries for JSX environments, but this was one that was sort of built in. [12:34]
-
-**Carl Vitullo:** Yep [12:34]
-
-some testutils, removed some deprecated DOM helpers. Or, Render and Hydrate are now removed in favor of their concurrent equivalents, the CreateRoot and HydrateRoot, as well as UnmountComponentAtNode and FindDomNode. They also removed UMD builds, Universal Module Declaration definition. [12:58]
-
-**Mark Erikson:** Definition, yeah. [12:59]
-
-**Carl Vitullo:** Yeah, that's not really been super relevant for a very long time now, not sorry to see that go. What was the, what was the main tool that used UMD? [13:09]
-
-**Mark Erikson:** Well, okay, so, recap for people. So we had, you know, we, originally we had script tags and everything's a global, and then the AMD format, Asynchronous Module Definition, was a, community created module format for use in the browser. CommonJS, loosely put, was designed for use in Node because it requires reading a file off disk synchronously. [13:31]
-
-UMD was a, someone figured out the incantation to wrap the actual code that you cared about in a complex header that basically tried to figure out, am I being loaded as a script tag, a CommonJS file, or an AMD file, so that one bundle could serve as all three formats. Simultaneously. In practice, UMD files have basically been generated for use as script tags loading off of unpackage or something like that. [14:04]
-
-**Carl Vitullo:** sure, right. Yeah, I was thinking of RequireJS with the AMD module. but yeah, now with ESM and you know, dynamic import and all the bundling tools that we have now, that's, that hasn't really been relevant in six or eight years, something like that. Or it hasn't been cutting edge, at least. Hasn't been the recommended. [14:22]
-
-But yeah, so, cool. That's all the stuff they removed. A lot of old things that haven't really, that have been deprecated for long enough that, yeah, they can go away. [14:32]
-
-**Mark Erikson:** Yeah, a couple observations there. One, I made the same decision around removing the UMD bundles from the Redux packages when I shipped RTK 2. 0 last year. The difference there is that I replaced it with an ESM format file that had all the process node env references compiled out of it. [14:52]
-
-And the React packages still don't have, quote, proper ESM support. So this, in one sense, they did actually remove something without a direct replacement for it. I've seen a number of suggestions to you that if you need to use React, like, in essence, as a script tag, then the intended replacement is to use a site called ESM. SH, which I actually looked into that a little bit, and what it does is it apparently uses ESBuild to compile various third party libraries with some sort of an ESM wrapper around them. So, even though React itself is still only shipped in common JS format, this site, this service it'll re wrap various packages with ESM around them, even if they didn't ship with it. [15:46]
-
-And then serve that up as, you know, a script tag. [15:50]
-
-**Carl Vitullo:** Interesting. Yeah, I hadn't heard of esm. sh. Looks like it's maybe sponsored by Cloudflare? It says the CDN is powered by Cloudflare. So it looks like this might be a service, you know, for the ecosystem that they're running. [16:05]
-
-**Mark Erikson:** and then the other one is, if you look at the issue with people complaining that find DOM node was about to be removed, there's, there's still a number of people who are not terribly happy about that one. they've got cases where their component structure is, it's deep enough, nested enough that they, they needed to rely on find DOM node to Find the right things to interact with and, people are not happy that it's been taken away. [16:30]
-
-**Carl Vitullo:** That seems a little strange to me. I feel like if you're in that position, there are native browser features that would do you pretty well enough, but okay, sure. I've not been in that situation, so I don't know what the weird technical trade offs involved there might be. [16:44]
-
-**Mark Erikson:** And then our favorite hidden internal non documented API, `SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED`, has been renamed to `SECRET_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE` [17:00]
-
-**Carl Vitullo:** okay, that's a little more descriptive. It's a little more actionable. I don't know of anyone who's been fired for using those, so, a little more accurate. [17:07]
-
-## New things
-
-**Carl Vitullo:** Yeah, some, getting into some new things, what they're, you know, what they've added now looks like, to me, it looks like the big stuff is mostly around transitions. my mental model for this is a little bit like, for most of React 18, we used like useState and useEffect and like a couple things around there to do basically everything. [17:31]
-
-And I think the core team identified that there was a pretty consistent and tricky use case of what happens when you need to take actions and manage state as components are, mounting and unmounting. That was definitely a little bit painful. Getting the intricate dance of as things unmount and remount, or different things swap in to replace them has definitely been awkward and tricky, especially for little things like animations. [18:02]
-
-Like If you have an animation, you can't actually unmount until the animation is completed, which may, you know, if you have a state change that would remove the component, but you want an animation to finish, then you need to like add in this like extra ceremony to keep it technically mounted while not actually in use, not actually responding to new events and things like that. So that's my mental model for what these transitions are intended to support. [18:28]
-
-**Mark Erikson:** That feels a little different than my understanding. So I've not used transitions myself, probably because I haven't been writing as much React front end stuff lately. But, like we, you know, there used to be the discussion of, you know, React 18 is going to have a concurrent mode. [18:42]
-
-eventually said, okay, like, having an entire mode isn't what we need, we're going to have concurrent features instead. So my, my understanding is that transitions are, primarily part of that concurrent feature set where you're basically telling React, we're going to start a render, but this is going to be considered low priority. [19:02]
-
-This could be interrupted. It will do the, like, you know, render a tree for five milliseconds and then pause to see if the browser has any events. So, my understanding is that transitions are primarily telling React, do some work, but this is considered a low priority render versus all the normal use state type based rendering. [19:26]
-
-**Carl Vitullo:** Interesting. Okay, fair enough. [19:28]
-
-so this is where the, you know, confusing verbiage that React introduced around like actions and how now we have many, many, many Actions is a very overloaded term in the ecosystem. [19:40]
-
-**Mark Erikson:** for Redux, another thing for MobX, now another thing for React Forms. [19:44]
-
-**Carl Vitullo:** Right, and I remember Astro had an actions thing as well a while back. So, right, there's just many, there's a lot of actions being taken. Yeah, so functions pass to start transition are actions. There's some additional hooks that are also able to tap into those, into the Actions as being used by active transitions. [20:05]
-
-So there's used action state which is a new hook to order actions inside of a transition with access to the state of the action and the pending state. So it, accepts a reducer that can call actions. So this is this smells a little bit like redux, baked into an interaction. a little bit. [20:24]
-
-As well as useOptimistic, which ties into these transitions by letting you update state while the transition is in progress, and it returns the state as well as a set function to optimistically update the state within a transition to be the expected final value. So, you know, like if you're doing optimistic updates within your UI, firing it off to persist in the back end, but immediately updating the local UI as if that has already finished. [20:51]
-
-But then gracefully handling the actual outcome of the of whatever action you took. [20:57]
-
-**Mark Erikson:** one observation here, you know, less around the behavior and more around the description. When React 19 came out a few weeks ago, the post in the JavaScript subreddit, the main discussion was basically around that paragraph and how hard it is to read for someone who isn't intimately familiar with React already. [21:19]
-
-And You know, a couple of different thoughts around this, like, one is that, you know, React has added a lot of things over time. Another is that there's been some cases where the React team has tried to turn things into proper named nouns in a way. Like, it's not just like, the useEffect hook, there are capital E effects. [21:44]
-
-And so, and so now it's not just, you know, we're going to do a low priority render, it is a capital T transition. And I, I just glanced at the docs. Like I'm, I'm looking at the use transition docs page and it does intro with use transition as a react hook that lets you render a part of the UI in the background, but like it right away starts using capital T transitions without ever defining what that word means. And there isn't really like a conceptual explainer. [22:19]
-
-So, part of it, like I realized that release notes aren't the right place to, you know, to go out and define a bunch of things, but both reading this specific paragraph, as well as trying to figure out how some of these new features are integrated into the docs and the teaching workflow, it feels like they're like, we're kind of missing a bit of a, like a conceptual explainer for some of these terms and how they relate to each other. [22:46]
-
-it's fixable, but, you know, like that, that's just one of the things that stuck out to me. [22:50]
-
-**Carl Vitullo:** Yeah, makes sense. Yeah, that's fair. it feels like an Apple type of branding. You know, it's not a, it's not an mp3 player, it's the iPod. [22:59]
-
-**Mark Erikson:** not the, just iPod, iPad, iPhone, whatever. [23:03]
-
-**Carl Vitullo:** No articles. Sure. [23:04]
-
-Yeah. other than transitions, they got the use hook, which is a little bit old hat by now, accepts a promise or context for accessing resources within render. If you give it a promise it will suspend until the Promise is resolved. [23:19]
-
-**Mark Erikson:** the naming still feels awkward, like, I don't have a better suggestion, but, in today's world, naming things for Googleability is very relevant, and giving this thing the name use is like the most un Googleable thing ever. [23:37]
-
-**Carl Vitullo:** There, right, right. [23:38]
-
-And back to my pet peeve about some of the quirks of React 19. This is the use hook, and it says right in the release notes, use can only be used in render, but can be called conditionally. And like, come on, rules of hooks, like, drilled into us repeatedly. Anything called use Use whatever. Cannot be called conditionally. [24:04]
-
-**Mark Erikson:** With the exception that you could already get away with, you could apparently already get away with calling useContext conditionally. I've never actually done it myself, but apparently, technically that worked. [24:14]
-
-**Carl Vitullo:** Interesting. I have not either. I don't think I knew that, actually. So I guess, cool, this is consistent with use context. [24:20]
-
-So clearly, I guess, it has its lineage in there. It is the way to use context. it just seems a little strange to me to, like, this seems like it's going to be a very widely used hook, and so for it to break the rules of hooks, quote unquote, quote unquote. [24:34]
-
-Feels like it adds a lot of, I don't know, weirdness, ambiguity, confusion. [24:39]
-
-**Mark Erikson:** it does I mean, I know that there's plans to hopefully expand that down the line. My, my Redux co maintainer, Lens, who also works on Apollo, has been begging for the ability to pass an observable. to use for a while now. So it's possible that that may happen at some point. It also is kind of one of those things where like they, you know, they needed the rules to be strict originally. [25:03]
-
-And now that the rules are defined and the ecosystem understands them, they can start to tweak it. But as you know, that also leads to confusion as well. [25:11]
-
-**Carl Vitullo:** Right, right. it's all a game of telephone and this adds strangeness. It adds exceptions to the rules. lots of other convenience features coming out with React 19. You can render metadata tags in components wherever, and they'll automatically get hoisted into the head section, which is great. [25:28]
-
-I, I think I said it when this was first announced, but like, the, React Helmet was, as far as I know, the main way to really interact with head in React, and it was just like not very consistently maintained. I kept running into, like, I feel like every time I used it, every time I was spinning up a new project and trying to interact with the head, it's like, oh, React Helmet, cool. [25:48]
-
-Pull that in. Oh, this does not behave in the way I expect in these many different ways. And so then what I thought was just gonna be a trivial, it works. Was not, was not trivial, did not work. So love that. Love to see that. [26:03]
-
-But yeah, RIP React Helmet. That was, I remember, I remember when that was released. I remember that was announced and going like, what the hell? NFL is releasing an open source project at the bleeding edge and they called it React Helmet. This is perfect. Protects the [26:18]
-
-**Mark Erikson:** one, definitely one of the best project names ever. [26:21]
-
-**Carl Vitullo:** Yes, absolutely. So, RIP to NFL's React Helmet. another convenience feature, you can use async scripts. [26:30]
-
-You can render them anywhere in the component tree, and they will be, React will handle the ordering and deduplication of them, which is neat. Yeah, deduplicating async scripts sounds That makes me a little scared. But yeah, I guess it shouldn't be too bad as long as you're not doing any weird stuff with the file name. Yeah, likewise, more head stuff. React 19 will ensure style sheets are inserted into the head before revealing the content of a suspense boundary. So, you know, predictable, Easily anticipated ways of interacting with the head. Also some initial load optimizations. Initial load and transition, page transition optimizations around pre init, pre load, pre fetch DNS, pre connect. [27:14]
-
-These are all, like, kind of low level optimizations that used to be exposed at the level of, like, script tags, where you could say, you could communicate to browser what level of initial connection to try and get ahead of. You know, because it takes a little bit of time to look up the DNS, to connect to the server, to open, you know, begin streaming data. [27:34]
-
-So, it sometimes introduced extra latency that was undesirable. So you can now, in React 19, have a little bit more control over how external assets get loaded in that way. You know, just even like pre fetch DNS and pre connect. Will cut the latency a decent amount. I've used those things in the past. It's a pretty nitty gritty performance optimization, but yeah, definitely important that we can now do that. That's nice. [28:00]
-
-Yeah, a big one, a nice one. One less use case for Refs can now return cleanup functions, so that's definitely big. That's definitely good. I think it had definitely been a pattern to, like, do a useEffect, to do things like setting up event listeners, and that was a little bit weird. [28:19]
-
-I don't know, it's just a little funky, because they're, they're clearly tied to the DOM. It's associated with a DOM node so having to do it in useEffect introduced, it just, extended that distance between the code that was being run and what it relied on. You had to do extra weird deduplication stuff because it was an effect. [28:36]
-
-So now, because refs support cleanup functions, it's just a little bit closer, you can keep it a little more self contained. [28:42]
-
-## [Ref Callbacks, React 19, and the Compiler](https://tkdodo.eu/blog/ref-callbacks-react-19-and-the-compiler)
-
-**Mark Erikson:** Yeah, and there's a, there's a good post from Dominic Torfmeister, the, you know, maintainer of React Query, he had written about dealing with, dealing with refs a couple years ago. And so he kind of revisited that topic and showed that, you know, hey, there, here's, here's cases when, You know, now you can do things like setting up a resize observer in a ref, and you don't even have to have a useEffect plus a useRef to manage that. [29:10]
-
-**Carl Vitullo:** another very small convenience feature, you can now render just context instead of context. provider. That's nice, that's good. Very small, very petite. React 19 also has support for custom elements, i. e. web components. For the first time in React's history we discussed that at much greater length in previous episodes. I don't know if there's that much more to say, web components. If you're using web components, cool, great, now you can use React as well. [29:36]
-
-**Mark Erikson:** it's still really complicated You know, a lot of it boiled down to, like, React can, in theory, render any arbitrary HTML tag. React have a hard coded list of element types that it knows are part of HTML. But, React 18 and earlier had issues with properly passing complicated props into web components. [30:02]
-
-And that's because of the whole difference between HTML attributes versus JavaScript DOM node properties, which I still only partly understand myself. But think part of the issue was React wanted to pass in. properties, but a lot of these things expected attributes instead. [30:23]
-
-And so there, there was a mismatch in, in how things would get passed down as well as issues with setting up event listeners as well. And from what I've read, went into the, the mile long discussion threads, they're like the web component spec does not necessarily define how a given web component receives this. [30:42]
-
-it's It's implementation dependent on a per web component basis. So it's literally how it's almost as if every single web component author, as they write that component decides, how is this component going to get its data or trigger its events? And so, different libraries, different wrappers, different authors take different approaches. [31:09]
-
-And so, part of the issue with implementing this was trying to find a reasonable set of heuristics that would work most of the time, and also allow React to pass this web component in framework compat spec that had been put out there. And after React 19 came out, I saw a couple more people posting complaints that certain scenarios didn't work right. [31:34]
-
-Like, I guess if you define a function field on your web component class. And then you also try to pass in a prop with that name. React will happily overwrite the function because it just assigns the field name, but ultimately it seems like web component authoring is a very inconsistent and per component basis kind of a thing. [32:00]
-
-And there's a lot of edge cases with the interop and so they're never going to make everybody happy. [32:06]
-
-**Carl Vitullo:** Awesome. Sounds great. Yeah, the finer points of attributes versus properties is, my eyes began glazing over at that point. [32:13]
-
-**Mark Erikson:** Yep. [32:14]
-
-**Carl Vitullo:** Yeah okay. a convenience that got me a little excited in React 19. Hydration errors will now be collapsed into a single error, even if there are multiple mismatches. [32:23]
-
-Like, nice. [32:26]
-
-Just [32:26]
-
-Right, just having my console be blasted with, like, 30 stack traces because, like, obviously this hydration did not match is, yeah, very happy to have that just be didn't work, not here's every point at which hydration did not work. That's nice. [32:44]
-
-So kind of subtle, I don't quite, I don't understand the, the precise details here, but errors in render are not rethread. If they're not caught by an error boundary, they're reported to window report error, not logged with console error. There's also, they've introduced onUncaughtError and onCaughtError methods to the create root and hydrate root. APIs to customize how those errors get handled. So I guess they're kind of stepping back from like automatically handling every error and logging it to the console to saying, if you have a boundary, we'll log it. [33:18]
-
-If you don't have a boundary, you can configure how it gets handled on your own. [33:23]
-
-**Mark Erikson:** You know, that's interesting. This, this might be the kind of thing that libraries might end up caring about more, but I, I actually feel like I need to go back to those React 19 compat PRs that I did not write myself, but I did merge. Because I, I think we had some tests where we had, like, assertions that, like, if an error happens while doing, like, a React Redux render or something, that errors would either get thrown of rendering or get logged somewhere. [33:50]
-
-So now I'm actually curious how we, how those PRs ended up handling them. [33:54]
-
-**Carl Vitullo:** Sure. Right. You can never know what you don't know. obviously that's the majority of our, I think that's the majority of what we wanted to get to today. [34:01]
-
-But uh, yeah, Mo, tell us about React Native screens. Hang [34:07]
-
-## [React Native Screens 4.0.0](https://blog.swmansion.com/introducing-react-native-screens-4-0-0-1b833ff98a55)
-
-**Mo Khazali:** Major version of the React Native Screens library, version 4. 0, came out. So, you, as a React Native developer, probably don't interact directly with React Native Screens. If you use React Navigation or ExpoRouter, which uses React Navigation under the hood, you will be using React Native Screens. [34:23]
-
-React Native Screens is native layer implementation of screens on iOS and Android for your app so that you're not creating JavaScript views and not handling the view transitions on the JavaScript layer, rather you handle them on the native layer. And so a few updates here that will likely be picked up by the React Navigation libraries. [34:43]
-
-React Navigation and ExpoRouter libraries. One is that they're adding more support for the forum sheet presentation. So this is kind of the bottom sheet interaction that you'll be used to on phones. And previously it wasn't supported on Android. And now there's an Android support. It was supported on iOS but you had a limitation. [35:02]
-
-So if you ever played around with those bottom sheets, you can kind of pin them to certain points, and they'll kind of stick. They call these detents, I think. [35:10]
-
-**Carl Vitullo:** This is like the sort of mobile version of a modal, where it's like an overlay that you slide around. [35:16]
-
-**Mo Khazali:** Yeah, exactly, those ones. So the ones that come from the bottom, and, you know, you've got a little modal, and the screen behind it is still kind of visible, and you can adjust how big the modal is. they call them sheets, I guess, in mobile development. Modals, when you're talking about in a mobile navigation world, it's the ones that kind of fully cover the screen. [35:35]
-
-Not the ones that can partially cover the screen. So you've got some of these pop ups that fully cover the screen. Sometimes you'll see them on, like, login pages or something like that. And so, a lot of these sheets, you can kind of control where they are, so you can pin them to different locations. [35:47]
-
-So, with this new API, you are able to, on iOS, set as many points to kind of have these snap points. And on Android, I believe, there's three different snap points. That you can define. So this is kind of sticking true to the iOS and Android APIs on the native layer. They've also made some minor improvements on animations when it comes to iOS to make it a bit more smooth. [36:11]
-
-And one of the other things that they've done is that if you've got a screen that's now detached, from the main tree of your navigation, so it's no longer rendered. You can preload these screens, and so this will kind of happen through React Navigation so that if you know a user is going to go onto a specific screen, you preload it, render everything, create the native views, and so you won't have this delay in getting the screen loaded onto the app, which is quite a nice feature, and I think this is great. [36:39]
-
-Quite important for optimizing your app and making sure that everything is smooth, quick, and snappy. So those are kind of some of the things. You won't really be implementing any of these yourself. You'll probably use React Navigation, so keep an eye out on the React Navigation docs and the ExpoRouter docs, because some of this stuff will be landing. [36:56]
-
-Some of it's already been landed as well. [36:58]
-
-**Carl Vitullo:** Nice. Makes sense. Yeah. [37:00]
-
-## [React 19 and React Native](https://react.dev/blog/2024/12/05/react-19), and [PR](https://github.com/react-native-community/discussions-and-proposals/issues/842#issuecomment-2527591610)
-
-**Carl Vitullo:** Tell us about React 19 and React Native. [37:04]
-
-**Mo Khazali:** so taking a step back, React Native just released the new architecture. So that was the, big release that they've been kind of working on for many, many years. And so, I think they're going through a stabilization period right now. They are I think waiting to make sure that everything is smooth, stable with the last two versions of React Native that have been released. [37:26]
-
-I suspect this will be some point in early to mid 2025, sometime in the next two releases of React Native, where they'll actually support React 19. I know that there's been some issues with supporting React 19 anyway with React Native. I think there's been some internal testing, but they haven't conclusively made sure that everything is working as expected. [37:46]
-
-So, I think there's just going to be some delay on this. But I think it's not something that we haven't seen in the React Native ecosystem. There's sometimes a lag with these major version upgrades anyway. [37:55]
-
-**Carl Vitullo:** Yeah, that makes sense. And especially, I'm just, I'm kind of connecting dots of what you were just talking about with like React Native screens, adding support for like preloading. And that sounds adjacent to, like, some of the use optimistic or use transition hooks that have popped up now as, like, first class APIs. [38:15]
-
-So I wonder if that's maybe some of the tension there, is that now that it's a first class API, a feature of React 19, React Native needs to figure out how to implement it [38:28]
-
-**Mo Khazali:** Because it's not just JavaScript there's also an element of, you know, how do you map those to native functionalities, right? So if you're transitioning to allow a native component to be rendered, well, how do you handle that on the native layer? [38:41]
-
-So there's a lot more support that needs to happen, it's not just the browser. But you need to also make sure that at least iOS and Android support those features, not to even get into the whole out of tree platform shenanigans where you've got a bunch of other platforms that are maintained by the community and they also need to support it. [38:56]
-
-So yeah, it has a long tail. [38:58]
-
-## [Expo experimental support](https://x.com/Baconbrix/status/1864785257297305833)
-
-**Carl Vitullo:** But it looks like Expo has experimental support. [39:03]
-
-**Mo Khazali:** this is probably one of the musings of Evan Bacon over a weekend just hacking away, but yeah, there's a lot of these sort of, like, Expo kind of goes ahead of the curve with some of these things and tries to push the React Native ecosystem forward, which is great so, I'm not surprised that this is supported with some sort of flag in Expo. [39:21]
-
-So yeah, it's the experiments. reactCanary, setting that to true. In Expo SDK 52, it works. These are very much experimental. Don't try these for any production apps, but it's just kind of trying to see what the effects would be ahead of time. I mean, we've seen this pattern, like Expo supporting RSCs with the bundler, with some custom changes to the bundler ahead of time before it's even, you know, supported, in any capacity officially by Meta. [39:46]
-
-So, it's cool to see it, but it's still a long way to go for production apps. [39:51]
-
-**Carl Vitullo:** Sure, yeah. Makes sense. [39:52]
-
-## [Next.js experimental CSS inlining](https://github.com/vercel/next.js/pull/72195)
-
-**Carl Vitullo:** Well, I have a very, very small bit of React, er, a very small bit of Next. js news. They've added a experimental CSS inlining feature. And now, if you are generating, you know, if you're, you're, if you're pulling in CSS styles, instead of it being compiled into a CSS asset and Loaded with a link tag. You can configure next so that it will just inline those styles in a style tag Yeah, this takes advantage of the React 19 precedence in deduping You know, CSS features. [40:28]
-
-So I guess this is enabled by React 19 But yeah, definitely pretty small, relatively minor performance optimization. [40:37]
-
-## [Next 15.1](https://nextjs.org/blog/next-15-1)
-
-**Carl Vitullo:** guess a larger bit of news. Thank you, Mark. There's also Next 15. 1 that's out Yeah, last episode we talked about how Next 15 was stable and now they're up to 15. 1 [40:50]
-
-**Mark Erikson:** The biggest one here is that because React 19 is now actually out, they've switched to using React 19 everywhere. So actually, it's kind of funny because for now they're on React 19 stable, but there's a good chance that they will continue using those canary releases in future versions of Next down the road. [41:10]
-
-So this may actually be only a temporary problem. you know, period of time where they're, where the version of React they use actually exactly matches the stable version. [41:20]
-
-**Carl Vitullo:** Right. I didn't know they have, you know, One of the headers on the 15. 1 release notes is React 19, parentheses stable. So yeah, right. They've been on Canary for forever. [41:33]
-
-## [React Native Fast IO](https://github.com/callstackincubator/react-native-fast-io)
-
-**Mo Khazali:** Cool. So, next up we've got the pre release version of React Native Fast. io out. So this was sort of first showcased at React Native London Con in November. So this is made by Mike Grabowski, who is the co founder and CTO of Callstack. And so it's basically built on top of the Nitro modules package that we've seen and talked about in the past few months that's been made by Mark Roussevy. [41:59]
-
-And so it's a way to create native libraries that are super, super fast to execute. And so, Mike from Callstack has been working on trying to get some of the I. O. functionality in React Native implemented with Nitro modules so that they're as fast as possible. And hence, React Native Fast I. O. [42:18]
-
-So he started off with WebSockets but he eventually wants to target WebSockets, Fetch, FileSystem APIs, Blobs, and Streams. And so the whole idea is you can use the WebSockets or the Fetch that comes from React Native Fast. io and in theory it should beat all of the benchmarks for any other implementations of I. [42:36]
-
-O. related functionality in React Native. So this isn't anywhere near production. But it's something that you can give it a shot and play around with and just run some benchmarks on and eventually at some point it should land and it could be quite interesting to see what that means for the whole ecosystem because these are quite core functionalities, right? [42:54]
-
-**Carl Vitullo:** Yeah. I uh, definitely pretty low level. If that gets much faster, that enables a lot of other interesting experiments. [43:00]
-
-**Mo Khazali:** Exactly. And I think The, one of the things with this is that it's one of the, like, first implementations of an actual library with Nitro modules. So, so far Nitro modules have been very hypothetical in terms of what you can achieve. Mark's been using it on a few of his libraries, but nobody else, sort of, in the community has adopted it to this degree to build an actual package. [43:20]
-
-So, it can really start to push a lot of people towards Nitro modules when they're building native dependencies. [43:25]
-
-**Carl Vitullo:** Neat. Cool. [43:27]
-
-## [NPX Create Target](https://x.com/Baconbrix/status/1868672438898455023)
-
-**Mo Khazali:** In other news, and we talked about Expo's random demos that they release with some cool features and going ahead of the curve. Evan Bacon in a very truly Evan Bacon fashion has been working on a new CLI tool specifically for iOS called NPX Create Target. And so the whole idea with this is, is that there are certain parts of an iOS app that you can't build with React Native and you need to build in the native layer. [43:51]
-
-So what are those? Those are things like widgets, live activities. Lockscreen widgets, and there's a whole host of things that are not part of, like, the main app that you use, but are almost extensions on top of on top of your main app. And so, the whole idea with this is, is that it's been quite difficult to get these up and running with React Native so far, because you need to go into Xcode, add those, widgets and then kind of do the binding between your React Native app and the widgets that you create or those targets that you create. [44:19]
-
-And so the whole idea with this is is that it's a simple NPX command that you can run and you choose the type of target or widget that you want to use and then it kind of bootstraps all the code, links it to your React Native app, has a way for them to communicate between each other, and all you need to do is just write the Swift code to basically implement that on the native layer. [44:37]
-
-And so it's a much easier way to add these targets to your existing application to your existing Expo application. So it's a pretty cool thing. It's, it's it's nothing that you couldn't do before, but it obviously was a lot more work. And this just makes it significantly easier to get up and running with those features to make your app feel even more interconnected within the OS, within the person's phone. [44:55]
-
-I [44:55]
-
-## Lightning round
-
-**Carl Vitullo:** Alright, that's all of our main content. Let's jump into the lightning round. Moe, you're up again. [45:02]
-
-## [React Native demo for Android XR](https://x.com/o_kwasniewski/status/1868645896239690009)
-
-**Mo Khazali:** So, quick thing. Android released some new features. Cool mixed reality stuff Android XR. So there's a whole release on that. And of course someone had to create a demo of React Native running on it. So there's a quick tweet showing React Native running on Android XR. [45:17]
-
-We'll see how this expands, but it's always within days that someone creates a demo of React Native running on any new platform or any new APIs. [45:25]
-
-**Carl Vitullo:** Nice, cool. Okay, so this looks kind of like Android version of Apple Vision. [45:30]
-
-**Mo Khazali:** Yeah, it seems like it's a competitor to Vision OS, basically but Android's really trying to standardize the way that XR goggles are built with Android. [45:41]
-
-**Carl Vitullo:** right, cool. Good luck. [45:43]
-
-## [If Not React, Then What?](https://infrequently.org/2024/11/if-not-react-then-what/)
-
-**Mark Erikson:** Another post from Alex Russell was going around in the last few weeks. Alex generally is on a one man crusade against client side JavaScript and the React ecosystem in particular. This one was titled, If Not React, Then What? And most of it boils down to most sites shouldn't be single page applications. [46:04]
-
-Most sites shouldn't be using react. I guess there's other client side libraries that you can use, but generally they shouldn't be client side in the first place, which is frankly, like, like my own summary is actually a, like a reasonable stance to take. And if he phrased it that way, he would probably have more people listening to him. [46:23]
-
-But the vitriol and the vehement and the anger that he puts into these posts, even when he has valid points, makes it really hard for people to actually listen to what he's saying. [46:33]
-
-**Carl Vitullo:** Sure. I haven't read this in depth yet. I would like to but yeah, he like very strongly states that, let me pull a direct quote. " React is a legacy technology, but it continues to appear in Greenfield projects. In short, nobody should start a new project in the 2020s based on React. Full stop." That is uh, not something I'd agree with. Strongly stated. [46:57]
-
-**Mo Khazali:** reading the About Me page, and Alex Russell, I didn't know this, works at Microsoft. And he's a partner project manager on the Edge team. [47:05]
-
-**Mark Erikson:** he was previously at Google and he also basically invented like two thirds of what we now know as the web component spec as well. I. [47:11]
-
-**Mo Khazali:** Yeah, I wonder how Microsoft feels about these stances. all of these posts are, these are not my, you know, employer's opinions. These are endorsed by no one except me. [47:22]
-
-**Carl Vitullo:** I randomly, I was just trying to refresh my memory on who Alex Russell is. Cause I, I recognize his name, I know his Twitter handle is slightly late, and I have seen him for years, as like, somebody in the ecosystem. So I was just trying to refresh my memory more specifically, and I quickly found A random Hacker News comment that describes him as early member of the Chrome team, three time elected member to the W3C from 2013 to 2019, and representative of TC39 from 2006 to 2017. [47:52]
-
-this is from two years ago, and it says, Lately, he's been very critical of single page apps in React, going as far as to call the past ten years a lost decade. guess he's been on this for a minute, but has some, like, Drawing deep credentials to, on, you know, web technologies. So, interesting. [48:08]
-
-Curious. But if he's on, if he's coming at this from a web components perspective, that adds a lot of color to my understanding of the situation and his arguments. [48:19]
-
-**Mark Erikson:** my take on it is like, he, he absolutely has the technical credentials to back up most of his opinions as well as statistics on like how bad, I mean, like many website bundles actually are like, he's not wrong about that, but he then goes from that to say that anyone using react is doing it wrong. Basically any single page app is wrong and the people who push react have been doing so with malicious intent from day one. Which is way over the line. [48:49]
-
-**Carl Vitullo:** Yeah, I'm gonna, I would disagree strongly with that. I feel like in, I feel like I can understand his macro perspective there, cause like, I have used a lot of like news websites that are like clearly using React very badly. It has been, it has been put in a lot of contexts that I don't know that it was the best tool for the job, because it was a popular tool that was easy to hire for. So I guess I can empathize with the perspective a little bit, but, I don't know, the nuance there, I feel like there's more nuance [49:18]
-
-**Mark Erikson:** no nuance, and that's the issue. [49:20]
-
-**Mo Khazali:** Well, just to go a little bit more into this. I just read his Rebuttal to if someone says, well, what about React Native? And I'm just going to read this verbatim. "React Native is a good way to make slow apps that require constant hand tuning and an excellent way to make a terrible website. It has also been abandoned by its poster child, [referring to Airbnb]". And then he goes on to suggest that you should use Capacitor and Cordova instead. Cordova is The poster child of making awful applications. [49:47]
-
-**Carl Vitullo:** everything he just said applies way more to Cordova than to React Native. [49:51]
-
-**Mo Khazali:** yeah, his, he seems to be pushing you to make web apps and use those on mobile with responsiveness. So I've at least on the native side, I think his opinions are incredibly unvalidated. He's probably has more credentials on the web, but that is a bizarre take to then go and say Capacitor and Cordova are better options. [50:10]
-
-**Carl Vitullo:** Oh yeah, yeah, definitely agree with that one. [50:13]
-
-**Mark Erikson:** Moving right along. [50:14]
-
-## [Vitest vs. Jest](https://www.speakeasy.com/post/vitest-vs-jest)
-
-**Carl Vitullo:** Great post titled Vitest vs Jest. I think this is Very needed. I think this is a great post. Just it starts with like just like a raw feature comparison comparing what does Vitest support and what does Jest support. And just goes into a bit of like a oral history of like, why did Jest appear? Why did it succeed? always appreciate some oral histories. I think it's really useful to understand how things came about. [50:41]
-
-Like I remember when ultimately Jest succeeded because it got open sourced. Also by Meta right, like within six months after React came on the scene. So like people had started using React, people had started using all of the everything Facebook was putting out, Facebook at the time was putting out React and Flux and then like, Oh sure, Jest. [51:06]
-
-So it definitely got a huge, huge, huge boost by the timing of its open source release. I never really got a ton of professional experience using other tools like Mocha or Chai and all of those. I don't really know what the comparison is from my perspective like functionality wise they all seemed about the same and But I don't know I used Jest because I was early in my career and I didn't have opinions and it seemed popular So why not? [51:31]
-
-Yeah, over the years definitely it became It, it became not a preferred tool of mine because I found myself needing to maintain parallel bundle configurations for, a production build, and then for Jest, and then for like end to end testing, and then, and so it's just like, it just became like one more target that made upgrading instance, like, new webpack or new, I don't know, any new core technology, I found updating Jest was just a huge pain in the butt. [52:03]
-
-So it became not my preferred tool for that reason. And Vitest seems to be a little bit better about that, but But I have not had that same professional experience of, I'm on a team with 15 other engineers trying to update a core technology without breaking everything or stopping work. So that's really the litmus test for me on a tool like Vitest or Jest. [52:23]
-
-And I've had negative experiences with Jest and no experiences with Vitest. Ergo, Vitest is obviously better. But [52:29]
-
-## [Aiden Bai “render-shaming” sites](https://x.com/aidenybai/status/1862529226727121366) while [working on React Scan](https://react-scan.com/)
-
-**Mark Erikson:** there's a young engineer named Aiden Bai, who I, I think is, I could be wrong on this, might not even be 20 years old yet. But he's the creator of a tool called Million. js, which is kind of like a, almost like a proto version of React compiler where you could isolate parts of your component tree and it would optimize like the text updates in there. [52:50]
-
-And he's since gone on and been working on a bunch of other React related performance tools. Some of them have been branded with Million as well. I think there's a like a million lint and like a a million VS code extension that try to highlight some React performance issues. But he's working on a tool called React Scan, and it loosely put pretends to be the React DevTools in the browser in order to get access to React saying, I just got done rendering, here's the new component tree. [53:24]
-
-And he's been advertising this with a tweets that are kind of render shaming. Sites like he did one where he pointed out that like typing in a search input in Twitter Makes basically every component on the page Rerender and those naturally got a lot of circulation and stuff going around So he called out a number of sites that way And it's, it's both really, really clever marketing, as well as, you know, a bit of an example of ways that React does not necessarily lead to a pit of success kind of a thing you know, just because of, you know, React's default render behavior. [54:07]
-
-I've very briefly dug, you know, dug into the source code just enough to see that that's how it's hooking into React's updates. I've not tried to go through the code and see how the rest of the analysis is implemented. But this feels very similar in spirit to some of the work I've done at Replay over the last couple years. [54:24]
-
-So I, I always approve of people digging inside React's internals in ways they're not supposed to. [54:28]
-
-**Carl Vitullo:** Yeah, I small reaction. I saw one of the site, one of the render shaming tweets he put out was about GitHub. [54:35]
-
-**Mark Erikson:** The list view that is used to render source code was re rendering all the list items every time you scrolled. And so, scrolling performance was relatively bad. And he tweeted it, tagged someone at GitHub, and they did actually fix it like a day or so later. [54:53]
-
-**Carl Vitullo:** yeah, that's worse than I was thinking. I thought it was uh, something about typing, but scrolling, ooh, rendering every line of code on a diff while scrolling. Yeah. That's, that's, that's not going to do good things. [55:03]
-
-**Mark Erikson:** it's virtualized, so like it wasn't rendering like 50, 000 lines of code at once. But even just what was on screen could be, you know, relatively slow. [55:14]
-
-## Lenz’s Weber’s [testing-library/react-render-stream-testing-library](https://github.com/testing-library/react-render-stream-testing-library)
-
-**Mark Erikson:** And then the last one plug for a friend uh, Lenz Weber is co maintainer of Redux Toolkit and works on Apollo Client. And he'd been putting in a ton of work to try to write tests for Apollo in conjunction with React Suspense and ran into all kinds of problems. And this is one of those things that is, it's a library maintainer problem. [55:36]
-
-This is not an app developer. But, you know, like we've, we've had lots of tests in the React Redux code base over the years that say, okay, I'm going to render a component, do an update. And I expect React will have re rendered this many times in the process. And as React's internal behavior changed over time, we kept having to go in and tweak those assertions, you know, like when, when React 18 switched to batching by default, like the number of render counts changed in a lot of our tests. [56:07]
-
-And in fact, at one point we had to say, like, if it's 17, then we expect that this test will render four times. If it's 18, we expect it'll render three times, et cetera. So like, this is not the kind of thing that an application test would need to care about, but a lot of library tests needed to care about this thing. [56:26]
-
-And, you know, we always implemented it with basically. You know, having a, having a variable outside a component, the components defined inside the test and you count how many times it rendered. So in the process of working on the test for Apollo, Lens came up with a new approach, which he's called the React Render Stream Testing Library, and it actually got included in the testing library. [56:52]
-
-organization, part of the, like the RTL group that we all know and love. And this takes a different approach where it actually kind of buffers up all the renders that occurred. And then you can say, okay, give me almost like a wrapper for the contents of the next render in the sequence. [57:12]
-
-And then let me write assertions against the contents of the DOM as it happened in that render. So you're still doing the usual testing library approach of, like, let me look for a button, let me, you know, assert that certain text is on screen. But rather than kind of conceptually testing it against a, quote, live version of the DOM, You're asking for a series of snapshots of it, and this library does the work of kind of buffering those, and then you can just sort of take the next one, do some assertions, take the next one, do some assertions. [57:47]
-
-I actually tried making use of this in a test with Redux Toolkit the other day. And it required a bit of a mental model shift to try to use it that way, but it actually ended up being much more consistent, and like, I didn't have to write any waitfors, because it wasn't timing based anymore. So, again, if you're not writing libraries, you probably don't need this, but if you are writing libraries, this might be useful. [58:13]
-
-## Outro
-
-**Carl Vitullo:** All right. That's all the news we have for you this month, this year. Woo! Thanks for joining us. We will be back next month on the last Wednesday of January here in the live stage, or back in your podcast feed just as soon as we can. [58:28]
-
-**Mark Erikson:** And Mo was worried we wouldn't have enough to talk about. [58:31]
-
-**Carl Vitullo:** Haha, it's gonna be a short episode. [58:32]
-
-Well, [58:33]
-
-**Mark Erikson:** all. Yeah look forward to talking with you folks next month, and enjoy the break, everybody. [58:39]
-
-**Carl Vitullo:** yeah. Happy holidays. [58:40]
-
-**Mo Khazali:** Always a pleasure. Hope everyone has a lovely time off, and enjoys the festivities, and uh, looking forward to what next year's got in store for us. [58:48]
-
-**Carl Vitullo:** 2024 was good to you. Good to you all. It was good to me. It's been a, it's been a weird year for me, but a good one. Yeah, end of episode. Personal updates. this has been the first year of my life when I accepted for myself that I'm queer. I'm not straight. It's been a good year for me, I hope it's been a good year for you. [59:06]
-
-Thanks so much. We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, our React. js, the subreddit, here in Reactaflux, and direct from those publishing articles. If you see anything newsworthy, definitely let us know at hello at reactaflux. [59:21]
-
-com. Bye! I read every email that comes in, even the spam, so send me an email. I'll check it out. If this is a show you get value from and want to support, the best way you can do so is by submitting a review wherever you listen, and by telling your friends and co workers about it. Cheers. Thanks for listening.
diff --git a/src/transcripts/tmir-2025-01.md b/src/transcripts/tmir-2025-01.md
deleted file mode 100644
index 1cd2ba5..0000000
--- a/src/transcripts/tmir-2025-01.md
+++ /dev/null
@@ -1,542 +0,0 @@
----
-title: "TMiR 2025-01: Movement on CRA, Redwood.js dead?"
-date: 2025-01-29
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:29](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- [[03:09](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://docs.google.com/document/d/1V-wc6YRW7TeKSREPxREI70vfIyA0vVmVbYKr6sU2jZc/edit)
-- [[04:17](#new-releases)] New releases
- - [[04:26](#react-query-563)] [React query 5.63](https://bsky.app/profile/tkdodo.eu/post/3lfaeteulds2i)
- - [[04:45](#docusaurus-37)] [Docusaurus 3.7](https://docusaurus.io/blog/releases/3.7)
- - [[05:17](#react-native-audio-api)] [React Native Audio API](https://blog.swmansion.com/hello-react-native-audio-api-bb0f10347211)
-- [[07:30](#main-content)] Main Content
- - [[07:30](#cra-deprecation-react-team-against-recommending-vite)] [CRA deprecation, React team against recommending Vite](https://bsky.app/profile/acemarke.dev/post/3lggg6pk7g22o)
- - [[09:28](#dans-why-cra-exists-dont-use-it-possible-future-options-comment-from-2023)] [Dan’s “why CRA exists, don’t use it, possible future options” comment from 2023](https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741)
- - [Dan: “turn CRA into a launcher” still on the table, but stuck](https://bsky.app/profile/danabra.mov/post/3lggs4ql72k2w)
- - [“CRA is broken and not deprecated” umbrella issue](https://github.com/facebook/create-react-app/issues/17004)
- - [Ricky merged the PRs, working on legacy docs SEO redirects](https://github.com/facebook/create-react-app/issues/17004#issuecomment-2620263140)
- - [[37:46](#revealed-reacts-experimental-animations-api--motion-blog)] [Revealed: React's experimental animations API - Motion Blog](https://motion.dev/blog/reacts-experimental-view-transition-api)
- - [[37:59](#main-pr)] [Main PR](https://github.com/facebook/react/pull/31975)
- - [[40:17](#static-hermes-update)] [Static hermes update](https://x.com/tmikov/status/1869945330638442651)
- - [[42:38](#react-native-hosting-with-eas)] [React Native Hosting with EAS](https://expo.dev/blog/expo-announces-eas-hosting-service)
- - [[44:44](#everything-you-need-to-know-about-nodejs-type-stripping)] [Everything You Need to Know About Node.js Type Stripping](https://satanacchio.hashnode.dev/everything-you-need-to-know-about-nodejs-type-stripping)
- - [[47:57](#composable-caching-with-nextjs)] [Composable Caching with Next.js](https://nextjs.org/blog/composable-caching)
- - [[51:56](#thoughts-on-what-rsc-means-for-spas)] [Thoughts on What RSC Means for SPAs](https://blog.axlight.com/posts/thoughts-on-what-rsc-means-for-spas/)
- - [[52:44](#chromes-2024-recap-for-devs)] [Chrome's 2024 recap for devs](https://developer.chrome.com/blog/chrome-2024-recap)
- - [[53:39](#shoutout-webstatusdev)] Shoutout [webstatus.dev](https://webstatus.dev/)
-- [[54:26](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[54:26](#redwoodjs-shutting-down)] Redwood.js 😱
- - [[55:59](#a-checklist-for-your-tsconfigjson)] [A checklist for your `tsconfig.json`](https://2ality.com/2025/01/tsconfig-json.html)
- - [[56:30](#recoil-repo-archived)] [Recoil repo archived](https://x.com/dai_shi/status/1875910305802514649)
- - [[57:47](#bun-firstclass-support-for-s3)] [Bun: first-class support for s3](https://bsky.app/profile/bun.sh/post/3legdozw3nc2p)
- - [[58:48](#interpolate-auto-height-for-animations)] [Interpolate `auto` height for animations](https://bsky.app/profile/joshwcomeau.com/post/3lf5zwg2ths22)
- - [[59:47](#free-javascript-oracle-not-voluntarily-releasing)] [Free javascript; Oracle not voluntarily releasing](https://bsky.app/profile/deno.land/post/3lfapjn7gns2w)
- - [[01:00:31](#understanding-react-server-components--tony-alicea)] [Understanding React Server Components | Tony Alicea](https://tonyalicea.dev/blog/understanding-react-server-components/)
- - [[01:02:13](#follow-us-on-bluesky)] [Follow us on Bluesky!](https://bsky.app/profile/tmir.reactiflux.com/post/3lc6ziumnq22p)
-
-**Carl:** Hello! Thank you everyone for joining us for the January edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux. The place for professional React developers. We are supported by Infinite Red, a consultancy that exclusively works with React Native. [00:19]
-
-I am Carl, I am a staff product developer and freelance community manager here at Reactiflux, where I run community programs like this and Star Helpers and some other stuff, and just generally try to keep the community humming nice and smoothly. [00:32]
-
-**Mark:** Hi, I'm Mark. My day job is working at Replay, where we're building a time traveling debugger for JavaScript and other fancy uses of introspecting application behavior. Outside of that, I do Redux, and I apparently argue with people about the right way to use React. [00:48]
-
-**Mo:** And I am Mo. I head the mobile team at Theodo. And I am involved in the React Native ecosystem, where I frequently jet off to some of the different conferences, meeting some lovely folks in the community and help organize the London community with the React Native London Conference and the meetups that we run monthly. [01:04]
-
-Yeah, very excited to be here, as every month. [01:07]
-
-**Carl:** Yeah I feel like There has been some stuff, just not like a wide range of libraries and whatever, but yeah, I think we'll definitely find a lot to talk about. Uh, Actually this month, Mark is not only a pundit, but active participant in the ecosystem, [01:24]
-
-**Mark:** am making the news. [01:26]
-
-**Carl:** making the news and then reporting on it. Cool.
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Yeah, let's start off briefly, overview of the job market tech. Man, you know what? I thought it was like recovering a little bit, but I'm looking at the metrics and like, okay, the FRED data, some Federal Reserve data source, it only shows job postings to Indeed, so like that's a pretty narrow slice. [01:50]
-
-Who knows what other activity is happening, but like, presumably they're publishing it because they believe it's a reasonable proxy for the broader market. And it keeps going down! It just keeps going down. I don't know, hopefully that's just an indicative of Indeed, like, not being the place where people hire software engineers, which, you know It's probably, likely true? [02:09]
-
-I don't know. But yeah, it's just lower and lower every month it looks like. It's lower in January than it was in December, and December was lower than November. So, that's not great. Layoffs are also trending down. There's not as many people getting laid off anymore. But there was a bit of a spike in January this month. [02:26]
-
-Looks like 5, 200 people were laid off from 20 companies. Yeah, that's fewer companies than December, but like twice as many people, so that sucks. I think a lot of those are coming from a small number of companies. Yeah, Meta laid off 3, 600 employees two weeks ago. So yeah, job market is maybe not gonna be As improving as quickly as I hoped it might from some early indications towards the end of the year and in the first couple weeks of 2025. [03:00]
-
-But conferences still don't have a ton of queued up ones. I think people are still getting their ducks in a row with planning and scheduling for 2025.
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl:** like I said in the open, we are sponsored by Infinite Red. They are currently our only sponsor. But we don't communicate with them about, like, editorial or anything like that. They gave us some money, and I shot them out. Woo! They are an expert React Native consultancy that's been around since 2015. [03:22]
-
-And they're our only sponsor in part because so few companies do as much as they do for the ecosystem. They, put out a newsletter. They host the largest React Native podcast. They run, I think, the largest US based conference. Specifically on React Native and generally they are just like great people who do good work. [03:44]
-
-They have built over 75 apps for companies ranging from startups to the biggest in the world and they generally work with your team to help you develop expertise, not just build the app for you and get out of there. So yeah, if your company is looking at starting up a new React Native project, definitely consider reaching out to them. [04:02]
-
-They are infinite. red. [04:04]
-
-**Mark:** I've met Jamon a couple times and seen some of his discussions online. He's a good guy. [04:09]
-
-**Carl:** I mean, they're our sponsor because I met him at a conference and just sort of chatted idly about what we were doing. He was like, yeah, that sounds good. Let's talk more. great dude.
-
-## New Releases
-
-**Carl:** into some new releases. Not a ton this month, in part because I've been distracted with some other projects and have not paid quite as close an eye as I would have preferred.
-
-## [React query 5.63](https://bsky.app/profile/tkdodo.eu/post/3lfaeteulds2i)
-
-**Carl:** But React Query put out 5.63 looks like, you know, I mean, it's a 63 point release, like there's, it's gonna be some fine tune and revisions, but uh, looks like they added an ability to unsubscribe an observer from the cache which should help in React Native. So, yeah, PanStack, great, great resource.
-
-## [Docusaurus 3.7](https://docusaurus.io/blog/releases/3.7)
-
-**Carl:** Docusaurus also put out version 3.7, so if you're using that, consider upgrading. Great [04:52]
-
-**Mark:** actually updated the Redux Toolkit doc site from DocuSource 2 to DocuSource 3, and it's definitely some improvements. thing I think was in 3.6, previously they've always used Webpack as their build tool. And with 3.6, they introduced an experimental option to use the RS Pack, Webpack re implementation in Rust for faster builds, and it definitely did seem to speed things up,
-
-## [React Native Audio API](https://blog.swmansion.com/hello-react-native-audio-api-bb0f10347211)
-
-**Carl:** Yeah Mo, you want to talk about the React Native Audio API? [05:20]
-
-**Mo:** so this one is really, Interesting. Because for the longest time, obviously, like, the Web Audio API is incredibly mature. It gives you so much functionality, you can make some really cool stuff with it. So if you're trying to do anything with audio, like, I don't know get information about your audio sources, run it through effects Be able to generate audio graphs, you know, things like showing wave, waveforms and stuff like that. On the React Native side, it's a lot more difficult to achieve similar things because you're dealing with native level APIs, they're not standardized and you may end up having to just write some code yourself to be able to do that on the native layer per platform and to try to achieve similar things. [06:07]
-
-So, the example that is quite common is generating wavelengths. I've tried to generate wavelengths on the client for certain files. Not a very easy task to do, it turns out. So some functionalities like that are just so much easier to do on the web. [06:21]
-
-And so the folks at Software Mansion have recently started building out A React Native audio API, and so the whole idea is, let's try to bring over the Web Audio API, which is incredibly mature, very standardized, and high performance, into the React Native scene, so that you can have the same levels on control and playback as you do on the web, and standardize it. [06:46]
-
-It fits quite well into the sort of universal app story where you want to standardize around web APIs because they're mature and allow native developers to ingest the same ones but delegate the implementation and the runtime of those APIs onto the native layer. So this is quite cool. It's still early days. [07:06]
-
-And it's, it's not, you know, ready and it doesn't have all the bells and whistles that you have in the web, but it is a very, very good step in the right direction. And so I, I'm super excited to see how this evolves over the next few months and years, I guess. [07:21]
-
-## Main content
-
-**Carl:** Cool our main content. So this is our first episode of the year. I was thinking that we'd discuss a little bit about what we'd like to see, but,
-
-## [CRA deprecation, React team against recommending Vite](https://bsky.app/profile/acemarke.dev/post/3lggg6pk7g22o)
-
-**Carl:** Mark, you want to start us off talking about Create React App and we we can springboard from there [07:37]
-
-**Mark:** gladly. So, React 19 came out last month, in the culmination of, couple plus years worth of technical effort from the React team, and we've all been very excited about that huge jump forward for the ecosystem. Thanks But it also had some unexpected technical side effects, and the technical problems have then spiraled into drama. [07:57]
-
-And I actually happen to be squarely in the middle of that. So I'm going to be describing things, I am both a participant and an observer. And we'll go from there. So Create React App came out in late 2016, early 2017, and it was designed for a couple of purposes. The whole point was make it really easy to start a new React project with a good default build config out of the box with one command. [08:23]
-
-You know, previously you had to spend a lot of time configuring yourself. And so part of this was to make it easy for beginners to start a new project and be able to focus on trying and learning and using React. And it also, you know, had, you know, was perfectly fine for actual production projects as well. [08:42]
-
-And so Create React App succeeded wonderfully. It became the default standard, you know, set up for tutorials. Lots of companies used it for actual apps, but over the next few years, you know, other build tools came out, things that were faster than Webpack CRA was having trouble kind of keeping up with, you know, some of the maintenance demands. [09:03]
-
-They were very slow, you know, dealing with the, the Webpack upgrade. [09:07]
-
-**Carl:** Right [09:07]
-
-**Mark:** And by like 2022, Create React App was actually kind of basically unmaintained. Now, even though it was in the Facebook GitHub org the last people maintaining it were not even Facebook employees or, or part of the React team. And it basically like a ton of issues had piled up.
-
-## [Dan’s “why CRA exists, don’t use it, possible future options” comment from 2023](https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741)
-
-**Mark:** So in, I think it was early 23 Theo Brown put up an issue saying we should mark Create React App as deprecated and we should point people to use Vite instead. That's it. And, you know, he, the issue got, you know, went viral and it collected tons and tons of thumbs ups and eventually Dan Abramov responded and wrote a massive detailed reply saying, saying, here's why Create React App exists. [09:55]
-
-We see that the ecosystem has changed. We've also been changing some of our thinking about the right ways to use React. And here's five possible futures for the Create React app tool, ranging from kill it completely to, modernize it, to change the CLI tool to be a multi launcher that would end up pointing to, creating a next app or uh, remix app or something. And that's where things kind of left off. You know, lots of people read that comment. The community just sort of absorbed the knowledge that you're not supposed to use Create React App anymore and everyone asking questions about how should I start a project was told, use something else. But Create React App itself never formally got deprecated. [10:40]
-
-The CLI still ran, nothing changed in the docs, Dan's extensive comment was never turned into actual documentation. And so that brings us forward to, you know, this last month. React 19 came out and Create React App promptly started breaking. The Create React App CLI has always tried to install the latest version of React into whichever template package you specify. [11:06]
-
-And the templates have some dependencies, including tools for linting and testing. And it turns out that the React Testing Library version had a peer dependency on React 18, and suddenly CRA was trying to install React 19. And since NPM throws errors anytime there's a peer dependency mismatch, what happened was you try to run create react app my app, and it promptly throws errors saying I was told to look for React 18, but there's React 19, these don't match. And so over the last month, I've seen dozens of people file issues or You know, Reddit threads or comments saying, Hey, I'm trying to start a new React project, and it throws an error. And a lot of these people are beginners. And so I was seeing so many of these threads pop up that I began to make a couple comments on social media saying, Hey, like, no one owns Create React App at this point. [12:01]
-
-It's unmaintained. This is bad for the ecosystem. It's bad for beginners who don't know they're not supposed to be using it and are just trying to follow a tutorial. And that's actually part of the problem, is that a lot of older tutorials They'll reference create React app and no one's telling them you should be using something different. [12:21]
-
-And if it breaks, they don't know what their other options are. [12:24]
-
-**Carl:** the SEO for it is so strong. Like if you're just, if you don't know anything about the ecosystem and it's like, I want to make a new React app, like you search new React app or something like that in Google, [12:35]
-
-80 percent odd, you find Create React App. [12:38]
-
-**Mark:** I literally Googled that, and the, the top hit is the actual CRA docs. The third hit is the legacy React installation page. And like the second hit is the current React installation page. So I started griping about this on social media. And the second or third tweet that I put up about this actually is what really spawned the discussion and drama. [13:03]
-
-So that thread went viral and took off. And a couple members of the React team, Dan and Ricky, began to reply. And Overall, my main goal was, I felt that number one, somebody, aka the React team, that had the right project permissions, should fix the Create React App templates so that it doesn't error when you create a new project. [13:26]
-
-It's still a tool, it should work, it shouldn't break. But, both the CLI tool and the docs should be updated to say, Create React App is deprecated, don't use this anymore. Like, yeah, it'll work, but you shouldn't use this. Thanks. And that they should, you know, hopefully point to like some kind of a migration guide, like here's what you should use instead. that's where we also start to run into other problems. if we point people to the existing new React docs, start a new project page, that's the one that specifically says you should only use React with a framework like Next, Remix, Gatsby of all things, and Expo. And it actually specifically argues against trying to do things yourself. Now, the most direct equivalent to Create React App today is Vite. And Vite works great. And in fact, Vite is being used by millions of React projects. But the React docs don't actually list Vite as a real option. [14:30]
-
-They mention it a couple times. And it's buried down in, at the bottom of the React docs. Can I use React without a framework section where they sort of grudgingly say, well, if your project doesn't fit any of these constraints, I guess you can use something like Vite which I'll get, I'll touch on that a bit further later. So to me, the right thing to do to get people off Create React App is to have Vite listed prominently on the setup page because it's the direct equivalent and say, this is good for someone who's beginning or has, you know, just doesn't need all the bells and whistles that come with a framework. [15:10]
-
-So that turned into more arguments. The React team still insists that you should only ever use a framework and have generally refused to list Vite in that page. And a lot of other people besides myself find this to be a pretty ridiculous stance. So the good news is after, you know, a lot of debate online this weekend, the React team did say we will update Create React App so it doesn't break. [15:35]
-
-Mark it is deprecated, and we will do some work to change the SEO on the old docs and the CRA docs to try to point them to the current SEO. Setup page. And so I've, I've seen Ricky doing the work in the PRs on that in the last couple of days. So it's been a lot of frustration and debate. [15:53]
-
-The good news is the immediate problem appears to be getting solved. Doesn't touch on changing the docs to list Vite as a valid option. And then that ties into all kinds of other general complaints about how the React team runs things. So that's the general state of play. [16:12]
-
-**Carl:** It does seem like the, this stems a lot of the worst of the bleeding, like, you know, the SEO issue of if you're trying to enter the React ecosystem as a newbie, then those PRs will address the worst of that in that, like, I think they realized that there was like a real legacy issue, legacy docs issue in that like, The SEO for those links are so good that it ranks above the current docs in a lot of cases. [16:36]
-
-So I'm glad to see them looking at ways to manage that SEO, but like, I've also managed documentation sites before and done SEO for them, like it legitimately took six months for those SEO changes to like fully settle down. So it's just going to take a minute for these changes to fully be reflected in search results too. [16:57]
-
-**Mark:** You know, I don't blame them for you know, taking a few weeks for this, you know, Create React App breakage to bubble up. You know, like I said, no one had really been maintaining Create React App through 21 and 22. It's been widely considered deprecated and no one's owning it for the last couple years. [17:18]
-
-So, You know, no one's really looking over at the repo issues. I saw the issues being filed in the actual React repo and on Reddit and Reactaflux. But I can understand that, like, it wasn't bubbling up and, really catching their attention. So, I'm not upset that it, you know, it took me, you know, raising this issue and pushing it and, kind of stirring up the drama in order to get their attention. [17:43]
-
-I can also understand that, you know, with React 19 having just come out, like, they're still kind of trying to catch their breath from that. That said, like, obviously I'm overly invested in this because I was the one trying to make the point that it needed to be fixed, but I've spent so much of my time as a maintainer Trying to think about how beginners will, read my documentation or, Trying to make things easy to use or answering questions from beginners And so I, you know, I care deeply about, giving beginners a good, you know, Startup path. [18:12]
-
-And so it kind of bothers me that, they didn't jump on this as, Oh yeah, this is an obvious problem and we should do something about it right away. [18:20]
-
-**Carl:** yeah, Dan gave such a long and thoughtful reply, acknowledging the issues, but then, yeah, it's, it sat for two years. [18:27]
-
-**Mark:** There was kind of like, like I said, kind of the spinoff of the, you know, CRA is broken part is that the insistence on using a framework has become. Such a stubborn ideological stance, and I understand the reasons why the React team feels it's better for people to use a framework, it's coming with all the pieces out of the box, those pieces are pre assembled to, you know, be guaranteed to try to work the right way You know, the React team has kind of shifted gears to where they feel that, you know, server rendering is an important capability, routing is an important capability. [19:03]
-
-You know, obviously it ties into their vision for React server components, which can only work with a framework for technical reasons. for years I've felt that there is a pretty big disconnect between how the React team thinks that people are using React, And how people actually are using React in practice. [19:23]
-
-And there's, there's, there's a lot of reasons for this. I experienced it myself with Redux. Like I, I don't even use Redux to build apps anymore. And so I'm, as a maintainer, I'm having to just kind of like take cues from issues people file or, well, a lot of people have asked for this feature. [19:39]
-
-I think it's worth it. But it's, it's reactive and I'm sort of over in my corner doing things almost by guessing. So there is always that danger when you spend all your time building a library of not seeing and feeling the way it is to use something in the real world. And, you know, part of the issue is that the way Meta, Facebook uses React, is different from how everyone else does, just because Meta has all their own infrastructure for routing and serving and bundling and everything else. [20:08]
-
-They don't need lots of third party libraries for that. But, given how huge React is, It is at least the job of the maintainers to be aware that it's used in a lot of other ways. And even if you don't necessarily want to focus on all those use cases, you still need to be able to be aware and support that. [20:31]
-
-And a lot of the React team's decisions and statements over the last few years have been basically very focused on we sort of assume that everyone who's using React is using it to build a server rendered, data fetched, routed CRUD app. And we don't really seem to care about any of the other ways people use React. [20:53]
-
-**Carl:** Yeah, having been paying attention to React since it was like, since relatively shortly after it was open sourced, there has always been a pretty clear, I don't know, like they came at developing React with a philosophy for how to do web development. [21:09]
-
-And I think that like over the last 10 years of React, 12 years of React. I think that has borne out more often than it's, there's always been people saying like, What the, what the heck are you doing? Like, this doesn't make any sense, this isn't, how I want to use it, you should be doing this. [21:25]
-
-And I have seen many cases where the naysayers were wrong. I am sympathetic to the, You know what the vibes that are I'm getting from the core team of like, this is our lane. Like, we understand what we're doing here. Like, "you'll understand one day" kind of vibe. but I, I think there are a couple of, I don't know, I guess they, they've always had this ideological stance that they were sort of. [21:49]
-
-Putting out into the world like people talk about react brain and you have to like change the way you think in order to Really effectively develop with react and like coming out of react you have to sort of Drift back into a different way of thinking to use other tools again And I think that's real and I do think that it's One of the great things about React, but I don't know It's uh, we're definitely in a kind of weird spot here where I guess some of the specifics about it have gotten a little bit Divorced from the everyday usage. [22:20]
-
-Yeah [22:20]
-
-**Mark:** Yeah let me give three reasonably specific anecdotes that kind of tie into this. So, when the new React docs came out a couple years ago that's when they, they really made that shift from, you know, you, you can use create React app, the old React doc said, if you're learning or building a single page app, use CRA. [22:42]
-
-If you need server rendering, use Next. If it's a static site, use Gatsby. The new doc site, when it came out, said, use a framework. Next, Remix, Expo. And then it had the Can I use React without a framework section with five paragraphs of explaining why they think it's a bad idea. And the original screen at the end of it was, if you feel you need to do something else go ahead, we can't stop you. Now they've said they didn't mean that to be sarcastic, But everybody I've talked to have said, like, that is just like the most passive aggressive, insulting way to phrase it. And it took over a year for them to finally rewrite that paragraph to take out the passive aggressiveness. [23:27]
-
-And, like, that is not a good way to treat your user base. Especially when using React without a framework had been the default way to do it. And it's what you were recommending in your docs up until you flipped the switch on the new ones. Second example, so the suspense gate thing last year, you know, the React team had made a code change to alter how nested suspense components in as siblings would load from in, in parallel to in sequence. [23:58]
-
-and you know, they had a good reason to make a change. You know, they were trying to make facebook. com a little bit faster and I'm not expecting them to have gone out and like, you know, run hundreds of example apps just to see if this might alter anything. But it Later on, in some of the discussions, they were saying, Well, I mean, you really shouldn't even be doing this pattern anyway. [24:18]
-
-Like, if you want good perf, you should always be hoisting your data fetching up to a route or a page for best performance. Which, okay, like, it's a valid thing to do to improve perf, but it turns out that, like, React 3 Fiber people were using suspense to load 3D assets. And it's still a va and like, even ignoring that, nested suspense is a valid thing to do. [24:44]
-
-So, it's a, you know, second example of, well, we, we really assume that you're gonna be doing things this one way that we recommend, and Not really following through of, but are there other people doing things a different way? And as a last example I even just ran some quick searches on GitHub in the last couple days, just querying for package.json [25:05]
-
-files that reference either Next, the Vite React plugin, or the React scripts package from create react app. And it's, it's napkin math, I think it might have actually been, like, CRA was 1.9, Vite was 1.1, and Next was 1.5. And so, mathematically, that means that there's 3 million projects that are You know, a basic single page app, and only one and a half million projects that are on Next. So the single page apps actually outweigh Next by two to one. [25:38]
-
-And yet, the React docs don't even list Vite fairly compared to the other options. So it feels like they're cutting out an awful lot of the ecosystem compared to how people actually use it. [25:50]
-
-**Carl:** Right, right. And like the, the recommendations they make around like best practices for performance and like whatever around loading and how to use suspense. Like, those are great. That's true. I don't disagree with it, but I also like most of my projects are like solo things. Or, you know, I'm collaborating with like one or two other people. [26:10]
-
-And I'll skip a lot of that a lot of the time just because it introduces complexity. Like it's, it's an extra couple of days of like introducing scaffolding and, piping data around. And like then, especially when I'm just like iterating and exploring and I don't really know if I'm even following the right path yet. [26:28]
-
-Like, I don't, I don't want to do that yet. I'll do it later once I know it's good, and I do want to care about performance, but that to say that like, I think a lot of development ignores those best practices because it is, because ignoring it is the right trade off for that bit of work, you know, the available, you know, it If you end up not shipping because you tried to follow all the best practices and blew out your budget for time or money or, you know, motivation from your contributors, then like, that's not great either. [27:00]
-
-Yeah. [27:01]
-
-**Mark:** So, in general I've seen a lot of frustrations about how, you know, the communications has been handled, about the React team's resistance to, you know, just adding a couple paragraphs in a header to one docs page. And I have a lot of thoughts about it that I'm working on writing a blog post on that will hopefully come out in the near future. [27:19]
-
-But that's, that's been a pain point for myself, for a number of other prominent figures in the React community that I've talked to, and for a lot of other people that I've talked to as well. [27:31]
-
-**Carl:** Well, so maybe, maybe let's try and bring it back. what do you think good relations from the core team to the ecosystem might look like over the next year? Like, just blank slate, what is, what does a good, I don't know, comms program look like? [27:48]
-
-**Mark:** Yeah, so, I've actually, you know, mentioned this in a couple of my tweets, if I could magic wand things, we've fixed the CRA brokenness, that's great, we're marking as deprecated, great. You know, for CRA specifically, I would get the docs updated, so the CRA docs have migration guides, and they point to the setup page. [28:07]
-
-And the setup page lists Vite as both a learning tool and a, if you just want a simple project. Because that both handles the, I'm a beginner, I just want to start a new project so I can write some components and learn aspect. But it also recognizes the breadth of ways that React is actually used. [28:28]
-
-In practice, whether it's, I'm spinning up just a little sample project or, you know, an enterprise that has like a Python or Java backend and can't even run Node on their server. But just like, we're not even giving you details, we're just saying here's a valid way to do it and here's a pointer to where to go. [28:45]
-
-Another thing that the React team has struggled with is general public updates on where they're going. And there's a lot of reasons for this. The React team has historically not had, a real full time paid devrel person. Historically, Dan Abramov did a lot of that work in an unofficial sense. [29:04]
-
-Like, he was the public face of the React team, but it's just because he spent all his time answering questions on his, of his own volition. they've hired a couple devrels or announced that they had a devrel a couple times, and then those people always seem to just sort of and not really do anything within a couple months. I think Matt Carroll has been in that position for a while, but in all honesty, I couldn't tell you much of what he's done. I know I've seen some people say they've had conversations with him, [29:36]
-
-**Carl:** I do know he put a lot of energy into the, into React Conf last year. But obviously a conference is not a like complete developer relations strategy, I don't know. But yeah, just to say, I do know that was a big effort. [29:48]
-
-**Mark:** And especially since, you know, Dan shifted over and both left Twitter publicly and actually started working at Blue Sky. It generally feels like there's no one from the React team who is actively reaching out and looking to be involved in conversations. [30:06]
-
-flip side of this is that a lot of that has come from Vercel and Next. [30:12]
-
-You know, Lee Robinson has been incredibly active in terms of actually looking for discussion threads around Next. And popping in, but also the Vercel dev rels have written some really good content explaining things like how, you know, how does, you know, suspense or concurrent rendering work and, you know, how to use some of the new React 19 features. [30:35]
-
-And some of that is in the next documentation and it's not at all in the core React docs. Some of it's on the Vercel or Next blogs and it's not in the core docs. Thanks. And frankly, a lot of that information feels like it should be in the core docs. Like, you know, the core docs describe the use server and use client directives. [30:59]
-
-And they, they talk about some of where and, and when to use it, but they don't have any information on what are server components, how do they fit into the React architecture conceptually, when and why would I want to use server components in general? And so that, that feels like a documentation gap there. [31:21]
-
-**Carl:** Yeah. [31:24]
-
-**Mark:** docs are wonderful. Dan poured his heart and soul into this tutorial. It is excellently crafted, comprehensive. In page sandboxes, all kinds of other things, it's great, but if you were to follow the tutorial linearly, you get past the couple of, like, nah, never use useEffect pages, then it just sort of ends. [31:47]
-
-And there's no direction on how to take this sort of theoretical knowledge of I'm writing some components in these sandboxes, and How to actually apply that to starting a real project. So like at a minimum I'd like to see a page at the end that says, Okay, you've finished the tutorial, great. Here are some active next steps. [32:08]
-
-Here's how you can start a project. And by the way, if you're like using Next or Vite or Remix. Here's how you would write components in the file structure in those actually give people a pathway. And then the last thing I'm, I guess, one other thing I'd like to see is more active communication on the blog. [32:28]
-
-Historically, they've done announcement posts for big releases. And then they basically do like one. What we're working on post a year. That's about it. I realize that they, you know, they do a lot of prototyping. They're very reluctant to, you know, give early details on prototypes because everyone gets overexcited about them. [32:51]
-
-And, You know, also this goes back to the, you know, the lack of a formal devrel person to have the capacity to do the writing. But, you know, even, and just, you know, some more frequent updates on what direction we're headed, or the kinds of things we're experimenting with. Even if you have to plaster it with, with very loud, this is a proof of concept. [33:11]
-
-Labels you know, the idea of using the TC39 stages as descriptions of how far along things are has been kicked around a few times. But you just, some sense of like, what is the roadmap and where are we actually going would be nice. [33:28]
-
-**Carl:** Or like, heck, like you said, there's lots of great blog posts that people like Lee Robb or other, you know, Next and Vercel people are putting out. Like, just reposting those to the official blog would probably be pretty good. [33:41]
-
-**Mark:** another one that I saw was the uh, I think, Some of the, you know, the team folks did a lot of great work in fleshing out the API references in the docs. And the only indication that anything had changed was they made a post in the discussions section of a, of a working group repo. No one is reading that. [34:03]
-
-Put up a blog post saying, Hey, we added five new docs pages covering these topics. Like that is a thing worth announcing. [34:10]
-
-**Carl:** Absolutely, 100%. Yeah. Well, one other thing I want to chime in on. On the documentation side of things too, I just saw, I just caught some discussion from people looking to make their own frameworks, were expressing frustration, like, you know, they were reading the docs and it says like, this is best left to the framework authors, and they're like, that's me! [34:30]
-
-How do I do this? yeah, [34:32]
-
-**Mark:** or library authors. Yeah. [34:34]
-
-**Carl:** right, and you know, then I'm seeing people talk about like, oh yeah, I was, I, I spent a week, three weeks, months reverse engineering this and understanding it so that I could write something on top of it, and it's like, yeah, you know what, that's, that's a pretty big documentation gap if like a half dozen people are all reverse engineering stuff in order to do what is being advised, you know, they're trying to own it, [34:58]
-
-**Mark:** seen a couple framework author kind of behind the scenes discussion groups and there, there is chatter back and forth and asking questions, but I mean, again, like a lot of that stuff would have been nice to see covered in public documentation in the first place. [35:15]
-
-**Carl:** I guess maybe, maybe to close this discussion out, this is all like refinement. Like, I also want to highlight that as far as frameworks for building web applications, The React documentation is absolutely world class, and like, you compare it to its peers in the, you know, ecosystem, and like, both what it's trying to do and how well it communicates it to someone trying to learn is actually quite good. [35:45]
-
-in my opinion, like, I, I think that there are many things that it does really, really, really effectively, and As, you know, pundits opining, we're seeking out the rough edges to focus on. I do just want to bring that in. [35:59]
-
-**Mark:** I have huge respect for the React team. I have a very good understanding of the constraints that they deal with, both from having watched and talked to And then, you know, as a, as a maintainer of a widely used library myself, I, I totally understand, like, I just don't have time to sit down and document this. [36:15]
-
-it's both the, the success that they've had, And the work that they've put in that makes a lot of these gaps and pain points all the more frustrating. And so it's not that they're doing a bad job. It's that the pain points really stand out. [36:32]
-
-And a lot of them feel like self inflicted wounds that could have been addressed fairly simply. [36:37]
-
-**Carl:** And, perhaps, because it has had such a vibrant, thriving ecosystem for so long, and so many phenomenal, wonderful, generous, talented individuals who are filling some of these gaps, Like, now that the momentum, now that some of the heat has gone out, like, you know, there was a, there was probably a five year span where a lot of the hype in tech was focused on React and now, you know, then there was like a kind of like, ooh, should we focus on Web 3? [37:08]
-
-Like, ooh, is blockchain interesting? And there's like, no, no, no, actually, no. And now, like, that, that laser has Fully focused away from tech like React and more onto AI things. So I think that a lot of those individuals who were driven and talented and motivated and ended up filling those gaps are now doing other things. [37:27]
-
-makes sense and it's fair, but it means that those gaps are not getting filled anymore. [37:31]
-
-**Mark:** I have a lot more thoughts on this topic. I will not go through them here. However, I am planning to put up a very, very, very long blog post explaining a lot of this stuff hopefully within the next few days. [37:43]
-
-**Carl:** I've read half of it. It's good. Okay. Moving on.
-
-## [Revealed: React's experimental animations API - Motion Blog](https://motion.dev/blog/
-
-**Carl:** Somewhat small. We can maybe do this in lightning round, but too late. speaking of new developments in React, there is an experimental animations API taking advantage of the view transition, platform API On the web.
-
-## [Main PR](https://github.com/facebook/react/pull/31975)
-
-**Carl:** Uh, It's currently unstable. It looks like it's going to be a view transition component that also comes with a little bit of ceremony around how to set state in order to make the transition aware that a change happened. [38:12]
-
-But seems cool. I don't know if view transitions look great. And being able to easily tap into them when you're doing your react logic. Definitely here for that. Looks great. [38:23]
-
-**Mark:** I still don't even know exactly what view transitions even are. I've been too occupied to have a chance to read about or learn them. Having said that, this also does feel like kind of a big deal. People have been griping about the lack of real animation support in React itself for years. There's been lots of, you know, community packages, Motion and React Transition Group, and A whole bunch of other things. [38:48]
-
-and they've said that they wanted to get around to it eventually, but it really needed to be integrated into concurrent rendering behavior because you got to track multiple copies of the tree at once. So this does actually feel like a pretty big step forward. [39:01]
-
-**Carl:** Yeah, and I used like React Motion Cheng Lou's library from many, many years ago which was great. I found that really cool and really powerful. I did some really fun, exciting things with that. the single most fun thing I did with that, I did a spotlight. Like onboarding tour for an app I built, where I did a custom SVG to cut a hole out of a, like, transparent, translucent overlay. [39:26]
-
-And then I used React animation to, like, animate it, and so it would, like, do a, like, little springy animation around. And, like, it was performant. It was fast. It took me, like, three hours to do. So for me, user space implementations like that were like, cool, great, this is solved, I don't need to do this. [39:44]
-
-And I don't need React to be more aware of this because this works great for me. I think that's part of the reason why they haven't brought anything in before this. And I think now there has been more of a, I don't know, general understanding of how animation should work at a platform level. [40:01]
-
-And so They've been brought in as platform features to do like flip animations. First, last, interpolate, play. And so I think that's what view transitions are, but I'm in the same boat. I've read about them. I have not actually put them to practice in any real project yet.
-
-## [Static hermes update](https://x.com/tmikov/status/1869945330638442651)
-
-**Mo:** Let's jump into Static Hermes, because I think that one's quite interesting. So, we've talked about Static Hermes over the last few months a few times, but right before Christmas there was an update that went on by Tzvetan, who's basically really the person who's leading the efforts as far as I know, at Meta, and so people are kind of asking the question, like, when is Static Hermes actually going to come out? [40:38]
-
-Because we saw it like years ago. It was super exciting. When is it coming out? And I think we got the first glimpses of hope in there. In the sense that in 2025, so in 2024, they say, next year they want to start to make it an opt in branch and maybe towards the end of the year, later in the year, at some point, make it the default React Native Engine. [40:57]
-
-And one of the biggest hurdles that they face, which they seemingly have overcame now, is that There wasn't good support for un typed JavaScript and obviously there's gonna be a lot of un typed JavaScript in the world. Like the whole premise of static Hermes is that you use the types within TypeScript to be able to compile better typed code at a c plus plus level. And so this is a big step and it was one of the hardest sort of hurdles that they had and they've compared the performance. with different benchmarks and seemingly they are doing, you know, somewhere to the ranges of 20 to 60 percent better with a bunch of different benchmarks that they're trying. [41:36]
-
-So it's quite cool and we'll see how it evolves, but I guess it's a very exciting update, whether or not that stays in practice and it'll be, you know, available at some point in 2025, we'll see, but you know, first glimpses of a supposed Timeline of delivery. So we'll, we'll see how that plays out. [41:53]
-
-**Carl:** Yeah, definitely makes sense that untyped JavaScript is a major hurdle, like, yeah, it's a JIT compiled language. If you're trying to do a static compilation of it, that's gonna be tough. [42:03]
-
-**Mo:** And it's honestly like super impressive what this team has been trying to achieve in itself. It's it's I don't think I have the capabilities to be able to, to dissect such hard problems. So kudos to them. [42:14]
-
-**Carl:** And also, just to, like, carry in the tone from this, you know, Hermes update post, I love that it has this hero image of a, I'm gonna call [42:21]
-
-it a flag that says "we do this not because it is easy, but because we thought it would be easy." [42:27]
-
-**Mo:** I love that so much, yeah, that hero images. Tzvetan is a really funny guy, like a very like, specific sense of humor, I've met him a couple times at conferences, he's just, he's such a joy to be around.
-
-## [React Native Hosting with EAS](https://expo.dev/blog/expo-announces-eas-hosting-service)
-
-**Mo:** I also want to quickly touch on Expo hosting, so this was announced a few weeks ago, and so, in sort of that light of, you know, there's Resell, which is the way that you host React applications or so called Next. js applications, I guess, mainly and you know, it's the framework that you use with the Expo world, obviously they are also kind of going into that footing of, we are the framework to use, and we also can host it because Expo is obviously going in this universal direction of, you can also use Expo and React native on the web and build full stack sort of across the board multi platform application on web and mobile and so obviously as part of that you're going to have to think about hosting where do you host the web applications and so they've launched EAS hosting which is their sort of first attempt at creating a hosting platform that will host your, you know, Web applications, but also your API routes, because if you remember from last year, we talked about Next.js's [43:31]
-
-API routes that they had, and so very similar to Vercel's API routes, you've got Next. js's API routes now, I'm sorry, you've got Expo's API routes now. And so it's a very sort of basic hosting platform for now. It lets you keep a track of, you know, the requests coming in, your deployments, the crashes. [43:48]
-
-And just some basic logging into your requests and so on and so forth. But I think it's, it's a, it's an interesting start and it's, you know, it's one of the pieces that they've been missing a little bit when it came to this universal story. So, we'll see how that expands, we'll see how it grows and evolves, but it's just the first and the early days of, you know, of EAS hosting. [44:07]
-
-**Carl:** I wish I had more to say on Expo, because it does seem really cool, and I have really admired its development over the years, but man, I just, I don't, I don't need to make native apps. Maybe one day. [44:17]
-
-as I'm charting my year in January I have a couple projects booked for the next couple of months, but back half of the year I might actually try and do like a fork of the Blue Sky plant, and that's Expo, so hey, maybe I'll get some real first hand knowledge [44:32]
-
-**Mo:** very keen. I love the comment. Someone's saying, I wonder if Tanstack will launch their own hosting one day. [44:37]
-
-**Carl:** That makes, yeah, that actually would not surprise me. Yeah, Mark you want to tell us everything we need to know about Node. js type stripping?
-
-## [Everything You Need to Know About Node.js Type Stripping](https://satanacchio.hashnode.dev/everything-you-need-to-know-about-nodejs-type-stripping)
-
-**Mark:** Well, I won't, but I'll tell you about the post that does. So, like bun have TypeScript support built in, but it's basically been like, Okay, we read the TypeScript source code, don't bother type checking it, we just execute it. And so, you know, given TypeScript's popularity, Node has finally jumped on the bandwagon and some of the latest Node releases actually integrate some tools that will do the type stripping so that TypeScript syntax code can at least run directly in Node without needing an additional tool like the TS Node. And, the big thing about this is that because they're stripping the types, they're not doing type checking the output also needs to be, like, your TypeScript code needs to be just types. Now you might think, well, it's TypeScript. Of course, it's just types. The problem is that some early TypeScript features do also result in additional runtime code being generated. [45:43]
-
-For example, when you use the enum keyword in TypeScript, it results in an object lookup table being added. And so because Node is just stripping the type syntax, if you try to use an enum with this new Node feature, it'll actually break things. So, I believe one of the upcoming TypeScript versions will actually have a flag that will enforce that you're only using type strippable syntax, but Big picture what this means is that it'll be easier to take, like, a node script that is written as a ts file with ts syntax and just say, like, node myscript.ts [46:25]
-
-or whatever. I don't think you have to pass in any additional arguments. So overall, it's, it's basically like matching the feature set of other tools like Bunn and making it easier to use TypeScript code across the ecosystem. [46:38]
-
-**Carl:** yeah, I am trying to quickly refresh my memory here, but I believe that I am actually using the strip types. No, I played with it but I found a different way around it. Yeah, I did, I did it. This is a feature I got to play with. I have first hand experience with strip types. It was pretty good. But yeah, there's still some weirdness around, like, type extensions, I think, in imports. [47:02]
-
-**Mark:** That does not surprise me. [47:04]
-
-**Carl:** I know, in trying to play with it, I had to do a code mod in order to add extensions, you know, like js extensions everywhere, and yeah, I know, I think a couple of episodes ago, we ended up talking, we talked a little bit about TypeScript, Faking what extensions it would use in order to make that work for compatibility reasons. [47:25]
-
-And so yeah, I got some first hand experience and it's weird. It worked. I got it working, but it felt weird to have, you know, to be authoring a ts or tsx file and importing it as js. That's definitely unintuitive. [47:41]
-
-**Mark:** complicated but valid technical reasons why they made that stance. [47:45]
-
-All right, Mo, I know you need to drop off shortly. Any other points you want to cover before you head out? [47:49]
-
-**Mo:** no, I think it's been a relatively quiet React Native month and I've been completely off the grid.
-
-## [Composable Caching with Next.js](https://nextjs.org/blog/composable-caching)
-
-**Mo:** The only thing that I am quite keen to talk about actually is the caching with Next. js, our little composable caching. Because I've been dealing with Next.js caching for the last two weeks and oh boy, oh boy, [48:10]
-
-I have been trying to, after dealing with the Pages router for a very long time I've been now dealing with Next. js caching for a little bit, and this use cache is obviously something that's more in canary at the moment. It's not published in, in sort of the, the stable versions, whatever that means in Next world these days, in terms of a stable version. [48:32]
-
-But, Basically, the caching is a little bit complex with Next14, as we know, and currently, if you want to cache things like database responses in server components, or you want to cache fetching, you have to wrap it in an unstable cache function that takes in the function, a promise, some key, and then some revalidation time. [48:56]
-
-And so, there's this really weird syntax to do this, and then of course there's also another level of caching when you have static pages, which means those static pages get cached after they're published. Built in whatever capacity. And there's just so many layers of caching at this point. It's hard to wrap your head around how your application is functioning. [49:16]
-
-And to make matters more confusing now, there's this use cache directive that they're planning on introducing, which looks really cool, but I can just imagine this getting ever more and more complicated. And to me, a real symptom of this is the fact that they've 180'd on the defaults of caching with Next 15. [49:36]
-
-Like, you've set some definitions on what is cached by default, what's not cached, and it went so poorly that you had to flip it 180 degrees. That does not give any semblance of stability to me as a consumer of the technology. And so I just look back at the days of the Pages router and wish we could just go back to the simplicity of having and getServerSideProps and just live life in that naivety of how simple that was. [50:06]
-
-**Carl:** I was thinking in similar directions and I'm actually now in a position where I'm maintaining a React Router v7 project, which I upgraded all the way from Remix 1 to React Router v7 in one go, or in one go, sequentially all the way up. And the, the Reactiflux website is I think it's a Next 14 Pages router app, so that one I could probably play with a little bit more. [50:35]
-
-But it's like, oh, I'm now actually maintaining apps on several of the largest frameworks And you know what? I like Remix the best. It's just got, like, the, the mental model is most familiar to me. It seems most predictable. And, like, I hate magic. I am someone who completely avoided the entire RWBY ecosystem because it's too magical. [50:57]
-
-I'm just like, man, Remix hits right for me. not much there. Just yeah, it feels good. I don't know. I like it. [51:03]
-
-**Mo:** I've used Remix as well, and I must say, like, It takes a little bit of adjusting from when you've just dealt with Next. js for several, months and years, but is just simpler. Like it feels more native webby, the bits of magic are really just like the loaders, the actions that you have, but like everything else just feels sort of you're dealing either with React or you're dealing with the web. [51:24]
-
-And I quite like that as a concept. [51:27]
-
-**Carl:** Right. [51:28]
-[51:28]
-
-**Carl:** it lets me think in terms of like, HTML, HTTP, and like, cookies. And like, yes please, let me think about the platform and not the toolchain. Yeah. [51:39]
-
-**Mo:** And someone in the chat, one of our listeners, is actually pointing out that the app router is still defined as the bleeding edge of on the React install docs, basically, on start a new React project. [51:51]
-
-**Carl:** definitely some bleeding happening. [51:53]
-
-**Mo:** So yeah, that was my little, my rant. [51:55]
-
-**Carl:** Cool. Yeah,
-
-## [Thoughts on What RSC Means for SPAs](https://blog.axlight.com/posts/thoughts-on-what-rsc-means-for-spas/)
-
-**Carl:** Mark, next link up is like thoughts on what RSC means. did you read that? Can you talk about that? [52:02]
-
-**Mark:** Yeah, I, I skimmed it a bit. So it's a, it's a post from Daishi Kato who worked maintains Zustand, created Jotai and Valtio and has been working on the, the Waku RSC based framework. So it's a couple different points. One is, can R RSCs actually relate to single page apps? And the answer is sort of maybe yes. [52:25]
-
-Like, you know, for example, the RSC payload could be served statically. And not dynamically generated on a server. it's actually kind of a, kind of a short read, but you know, just like some, alternative thoughts from just like, RSCs are on the server and, you know, can only be used with Next, et cetera. [52:42]
-
-So it's short, but worth reading.
-
-## [Chrome's 2024 recap for devs](https://developer.chrome.com/blog/chrome-2024-recap)
-
-**Carl:** last main content article Chrome put out a 2024 recap. That was just pretty good. I don't know. Some of it, I'd call it like 30 to 40% marketing fluff. [52:55]
-
-They spent a lot of time talking about how they added AI to the chrome dev tools, which I actually have heard some positive things about, like interpreting errors. Like okay, yeah. Neat. But yeah, I noted that it called out view transitions, which just 'cause we talked about it earlier in the episode. [53:09]
-
-Like, hey, look at that. platform and react in unity in sync. I think we'd mentioned this before, but there's a CSS popover and like anchor positioning. So you can do popovers without JavaScript, which. I have implemented popovers in so many apps, and I hate it. I am so tired of it. Like, I do not use popovers anymore because I'm so tired of making them. [53:33]
-
-So, being able to do it without crazy layout logic in JavaScript sounds great. Maybe I will actually use them again.
-
-## Shoutout [webstatus.dev](https://webstatus.dev/)
-
-**Carl:** And I also learned about a new site recently through reading that, webstatus.dev, which has a, like, annualized baseline browser feature summary, which looks neat. Although I'll note that, you know, we're into 2025. [53:55]
-
-We're a month into 2025, and the 2024 baseline is not met. Like, yeah. Safari looks to be generally the worst offender, But, Firefox and Edge also, slipping behind a little bit. Well, no, maybe that's not fair, because Firefox is ahead in a couple of them, ahead of Chrome in a couple of them. So, anyway, this is neat. [54:14]
-
-I love these kind of like, broad based what features Are being implemented. this is how I have always kept an eye on what's coming down the pike. So, didn't know this existed. Cool. Useful.
-
-## Redwood.js shutting down?
-
-**Carl:** I don't have a link for this, but I've heard, through the grapevine, that there will be some impending announcements from Redwood.js generally the shape of what I've heard is that like an original found co founder of the project who had kind of left or like gone dormant came back and has decided that I I don't know what is going on I read some like Google translated slack messages from I believe Swedish and it sounds like a co founder has come back out of the woodwork and basically taken over and Just said like This is good SEO. [55:01]
-
-This, there is value to this domain, this brand. It's mine now. I'm going to do something entirely different with it. So yeah, keep an eye out. Redwood. [55:09]
-
-**Mark:** Another way to phrase it is it sounds like Redwood the framework is dead and the name and repo are going to be repurposed. [55:19]
-
-**Carl:** that's the shape of what I've heard. I think I heard that they will be doing an announcement in the next month. So like, ooh, breaking story, our first one, but, ah, it's just such a shame because I, I've met them at a conference or two, they seemed really good, and I liked the general, like, like, I understood them as trying to do Laravel for the React ecosystem, and I thought that was a pretty good niche, so, just a shame. [55:45]
-
-Shame to see it die to some drama like this. But yeah, there should be some more details, maybe we can talk about it maybe we will have some, you know, perspective to give [55:55]
-
-this month. [55:56]
-
-**Mark:** next month. [55:56]
-
-**Carl:** Actual details, not screenshots of Slack.
-
-## [A checklist for your `tsconfig.json`](https://2ality.com/2025/01/tsconfig-json.html)
-
-**Mark:** Axel Rauschmeyer has done a lot of articles over the years about like, what's new in this year's version of the, you know, the, the ES language spec. He's also been writing some articles recently about some TypeScript related things, like different ways to define a NUS or similar things. And he put up a post call a checklist for your TS config, JSON, which walks through and actually like, looks at a lot of the config options and what they do and when it makes sense to use a lot of them. [56:27]
-
-pretty sure that Matt Pocock has done a similar post somewhere.
-
-## [Recoil repo archived](https://x.com/dai_shi/status/1875910305802514649)
-
-**Mark:** completely different note We talked about Redwood maybe kind of going away. The recoil library repository has been officially archived. Now, it had been unmaintained for a while. I had read from people who had been involved that apparently both the people who had been maintaining it had gotten caught up in layoffs from meta. [56:52]
-
-So, But, honestly, it also seemed as though the project had stagnated for quite a while. The thing that gets me, really, is that when Recoil was first announced whenever that was, like 2017, 18 ish there were just so many people who looked at the announcement and took it as Oh look, this is an official React State Management Library. [57:19]
-
-When in reality it was just some other app team at Meta came up with their own solutions and decided to publish it. But, you know, the combination of Redux backlash, and like, It's from Facebook, it must be official! meant that a lot of people jumped on it, and then it sort of stalled, and then Jotai came out, and Recoil just sort of went away. [57:45]
-
-**Carl:** Sad to see stuff drop
-
-## [Bun: first-class support for s3](https://bsky.app/profile/bun.sh/post/3legdozw3nc2p)
-
-**Carl:** Alright Bun is shipping first class support for S3, which is interesting. So, first class support for S3 here means being able to use it as like a file system, I guess. standard library tool for implementing Or for interacting with file storage services that themselves implement the S3 API, which is pretty widely supported. [58:11]
-
-So this is actually pretty interesting because, like, I don't know, I hate dealing with, stuff like the AWS SDK. I've, like, partially avoided learning AWS because it's just so complicated and annoying. So seeing some little details like S3 interactions being brought into the runtime is actually pretty neat. [58:32]
-
-Yeah. I'm seeing in the chat, there's a lot in that 2 announcement. Sadly, I don't actually use bun in my day to day. So I am just kind of an observer here and I have not stayed super up to date. Just that caught my eye as like, Oh, interesting. What an opinionated stance.
-
-## [Interpolate `auto` height for animations](https://bsky.app/profile/joshwcomeau.com/post/3lf5zwg2ths22)
-
-**Carl:** There is now, I believe in the latest Chrome, there is an interpolate size CSS property you can set on like high up on your your page to allow interpolating allow animations to interpolate between Auto, like if you say height auto and height zero. Previously you couldn't animate between those two states. [59:11]
-
-And now, You can in latest Chrome. That's super cool. I have always thought it was super weird that that extra step of just letting your size, letting the size of an element be automatically determined meant that you couldn't use CSS transitions. That just never made sense to me. So it's, it also doesn't make sense to me why it took 10 years from me feeling, oh, that's weird, to this actually shipping, but super cool. [59:37]
-
-Neat. Love it. I believe it's currently Chrome only, but yeah, I mean, hopefully it'll, hopefully it'll filter out pretty quick. He says, after complaining about waiting 10 years.
-
-## [Free javascript; Oracle not voluntarily releasing](https://bsky.app/profile/deno.land/post/3lfapjn7gns2w)
-
-**Carl:** And a small, extremely small update to something we discussed previously, the Deno organization's campaign to get Oracle to free the JavaScript trademark. [01:00:00]
-
-Oracle has Declined to voluntarily withdraw the trademark. So Deno is doing legal things to advance the process. This is a legal drama. So this is probably going to be something we're still talking about in like 2026. And I would not surprise me if it's like 2030 before the trademark actually, like before this case settles, let's say. [01:00:23]
-
-But yeah, neat. Maybe I'll stop giving updates, but Oh God, it would be so nice if Oracle did not own JavaScript.
-
-## [Understanding React Server Components | Tony Alicea](https://tonyalicea.dev/blog/understanding-react-server-components/)
-
-**Mark:** All right, and last one Tony Alicea is an educator who has written some very, very good deep dive blog posts into some things like React rendering, which is a topic I care deeply about, so I appreciate that and he recently put up a post on understanding React server components. [01:00:48]
-
-Now we've, we've mentioned a lot of different dive into server components type posts over the last couple years. This one walks through a lot of how server components fit into the rendering process, looks at some of the actual JSX related data that is serialized and sent back and forth, and talks about how it then fits into things like streaming and bundlers and hydration. [01:01:12]
-
-So it's not something you would read to understand, like, how do I use a server component? But it's a really good explainer that, you know, how digs through a lot of the technical aspects and talks about why server components work the way they do. [01:01:26]
-
-**Carl:** Yeah. Oh man. Wouldn't it be cool if this was put out as like a guest post on the React blog? [01:01:32]
-
-Cool. Okay. That's all of the links we have for you this month. Thank you for our persistent listeners who stuck with us all the way to the end. Yeah, we'll be back on the last Wednesday of February next month or in this episode, we'll be back in your podcast feed just as soon as we can. Thanks so much for listening. [01:01:50]
-
-**Mo:** Lovely to be here with you all again every single month. it's always a pleasure. Thank you, Mark. Thank you, Carl Thank you to everyone who's listening in and see you all in February [01:01:59]
-
-**Mark:** Yep, thank you, appreciate it. And if you want to stay up on the current drama that I am involved in in the React ecosystem, please follow me on Bluesky or watch for my upcoming blog post within the next few days.
-
-## [Follow us on Bluesky!](https://bsky.app/profile/tmir.reactiflux.com)
-
-**Carl:** Oh yeah, we can follow, you can actually follow this podcast on BlueSky too. We are tmir.reactiflux.com and I'm going to put a link in here. Cause you know what? I should do that. [01:02:23]
-
-We gather sources from thismonthinreact, bytes.dev, reactstatus, nextjsweekly, the reactjs subreddit, here in Reactiflux from the techreadsandnews channel, and sometimes even directly from people publishing content. [01:02:38]
-
-If you see anything that would be useful for us to discuss or just that you want to share with the community. Definitely pop it in the Tech Reads the News channel, or if you like, you can send it to hello at reactiflux.com. I will read literally anything you send to that. So, yep, go ahead. If this is a show that you get value from and want to support, best way to do so is by submitting a review, wherever you listen, or tell people about it. [01:03:02]
-
-It's great. Help us grow. Woo!
diff --git a/src/transcripts/tmir-2025-02.md b/src/transcripts/tmir-2025-02.md
deleted file mode 100644
index 523c407..0000000
--- a/src/transcripts/tmir-2025-02.md
+++ /dev/null
@@ -1,494 +0,0 @@
----
-title: "TMiR 2025-02: Updated new project docs"
-date: 2025-02-24
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:11](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
- - [[02:35](#microsoft-performance-based-job-cuts-have-started)] [Microsoft Performance-Based Job Cuts Have Started](https://www.businessinsider.com/microsoft-performance-based-job-cuts-have-started-termination-letters-2025-1)
-- [[03:07](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[03:10](#react-paris-march-20-21-paris-france)] [React Paris](https://react.paris/) March 20-21 Paris, France
- - [[03:14](#react-native-connection-april-34-paris-france)] [React Native Connection](https://reactnativeconnection.io/) April 3–4 Paris, France
- - [[03:19](#react-miami-apr-17-18-miami-fl-usa)] [React Miami](https://reactmiami.com), Apr 17-18 Miami, FL, USA
- - [[03:25](#cityjs-london-april-23-25-london-uk)] [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
-- [[03:53](#sponsored-by-infinite-red)] Sponsored by [Infinite Red](https://infinite.red)
-- [[04:48](#new-releases)] New releases
- - [[04:50](#react-router-72)] [React Router 7.2](https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v720)
- - [[05:11](#ts-58)] [TS 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8-beta/)
- - [[09:01](#prettier-35)] [Prettier 3.5](https://prettier.io/blog/2025/02/09/3.5.0)
- - [[09:12](#rtk-query-v260)] [RTK Query v2.6.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.6.0)
- - [[10:04](#standard-schema)] [Standard Schema](https://standardschema.dev/)
- - [[10:34](#astro-52-also-astro-53)] [Astro 5.2](https://astro.build/blog/astro-520/) (also [Astro 5.3](https://astro.build/blog/astro-530/))
- - [[11:35](#turborepo-24)] [Turborepo 2.4](https://turbo.build/blog/turbo-2-4)
-- [[12:20](#main-content)] Main Content
- - [[12:23](#sunsetting-create-react-app)] [Sunsetting Create React App](https://react.dev/blog/2025/02/14/sunsetting-create-react-app)
- - [[16:59](#original-sunsetting-cra-post-vs-build-a-react-app-from-scratch)] Original “[Sunsetting CRA](https://github.com/reactjs/react.dev/pull/7495)” post vs [Build a React app from Scratch](https://react.dev/learn/build-a-react-app-from-scratch)
- - [[25:26](#backlash-and-confusion-over-initial-version)] [Backlash](https://x.com/youyuxi/status/1891721924197351497) and [confusion](https://x.com/youyuxi/status/1892000761778929931) over initial version
- - [[26:52](#mark-filed-a-pr-to-rewrite-the-docs-the-react-team-closed-that-but-based-a-new-one-off-it)] [Mark filed a PR](https://github.com/reactjs/react.dev/pull/7618) to rewrite the docs, the React team closed that but [based a new one off it](https://github.com/reactjs/react.dev/pull/7624)
- - [[38:09](#between-the-wires-an-interview-with-mootools-contributors)] [Between the Wires: An interview with MooTools contributors](https://www.freecodecamp.org/news/between-the-wires-an-interview-with-mootools-contributors-33d764957575/)
- - [[42:58](#how-to-start-a-react-project-2025)] [How to start a React Project [2025]](https://www.robinwieruch.de/react-starter/)
- - [[43:56](#jack-herrington-published-create-tsrouter-app-under-the-tanstack-umbrella)] [Jack Herrington published `create-tsrouter-app`](https://bsky.app/profile/tannerlinsley.com/post/3lif6fdpzkw2s) under the Tanstack umbrella
-- [[47:24](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[47:29](#vercel-acquires-tremor)] [Vercel acquires Tremor](https://vercel.com/blog/vercel-acquires-tremor)
- - [[48:29](#things-people-get-wrong-about-electron)] [Things people get wrong about Electron](https://felixrieseberg.com/things-people-get-wrong-about-electron/)
- - [[48:57](#initial-observables-support-in-chrome-135-observable-api)] [Initial Observables support in Chrome 135](https://x.com/BenLesh/status/1893053275995357608), [Observable API](https://chromestatus.com/feature/5154593776599040)
- - [[49:33](#why-i-rebuilt-prosemirrors-renderer-in-react)] [Why I rebuilt ProseMirror’s renderer in React](https://smoores.dev/post/why_i_rebuilt_prosemirror_view/)
- - [[49:52](#javascript-temporal-is-coming)] [JavaScript Temporal is coming](https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/)
- - [[50:44](#do-javascript-frameworks-still-need-portals)] [Do JavaScript frameworks still need portals?](https://fullystacked.net/portal/)
- - [[51:46](#what-do-we-do-with-you-old-react)] [What Do We Do with You, Old React?](https://www.manuelsanchezdev.com/blog/what-to-do-with-old-react-upgrading-to-modern-react)
- - [[52:18](#records-and-tuples-proposal-is-now-composites)] [“Records and Tuples” proposal is now “Composites”](https://bsky.app/profile/littledan.dev/post/3liwo57opl22b)
-
-**Carl:** All right. Hello, everyone. Thank you for joining us for the February edition of This Month in React, where we recap And digest the recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:00]
-
-But I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like these events and build tools to help keep the community operating. [00:16]
-
-**Mark:** And I'm Mark. My day job is working at Replay. Io. We're building a time traveling debugger for JavaScript and figuring out how to integrate that with AI DevTools. And in my copious amounts of spare time, I both work on Redux and spend entirely too much time complaining about the React ecosystem. [00:26]
-
-**Carl:** And also now writing documentation and long, enormous blog posts. I actually printed out your blog post that I offered to help you edit, and it was 50 pages long. 50 sheets of paper. [00:42]
-
-**Mark:** I apologize to the forests that suffered for that one. [00:53]
-
-**Carl:** It's entirely your fault. [00:56]
-
-Yeah, our third co host, Mo, is off this month. He is very busy with work and things, and just needed to take some time, not in the right space to have this conversation this month, so he'll be back next time. [00:58]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Some quick hits. Job market. I was hoping around December, January, it was looking like, I don't know, new quarter, new year, new budgets. I was cautiously optimistic from seeing activity in the job board, yada yada. But sadly that has not borne out. [01:11]
-
-## [Microsoft Performance-Based Job Cuts Have Started](https://www.businessinsider.com/microsoft-performance-based-job-cuts-have-started-termination-letters-2025-1)
-
-**Carl:** I guess, you know, maybe some small companies were hiring, but like, Meta is doing performance based layoffs. Microsoft is doing performance based layoffs. And talking to someone about the job market and the ecosystem, and they shared something that made me think differently about layoffs that are happening right now. [01:29]
-
-Like, when the company is signaling that it is performance based, That is a very different situation than when you just get laid off. Like, was pointed out to me that like, if you have on your resume that you worked at Meta and that you got laid off January 2025, that is no longer, like, the golden ticket. You know, like, for many, many years, if you worked at one of these big tech companies, that was, like, pretty much, not a free pass, but, like, it opened a lot of doors. But now a lot of people are getting let go when the public messaging is we're letting go of low performers. And that is a very different environment to lose your job in. [01:46]
-
-So that's, yeah, I hadn't really thought about that, but yeah, how the company messages, how they're letting people go definitely can have a huge impact. And I saw a quote from a Bloomberg article about the Microsoft layoffs. [02:23]
-
-## [Microsoft Performance-Based Job Cuts Have Started](https://www.businessinsider.com/microsoft-performance-based-job-cuts-have-started-termination-letters-2025-1)
-
-**Carl:** " Employees losing their job will see health care benefits end immediately. In three specific cases, employees were told that they weren't getting severance." [02:35]
-
-So like, not only is, are they publicly signaling that these are like performance based and therefore really doing harm to the like future employment prospects, like they're not, they're being pretty stingy about these severance deals. [02:43]
-
-Losing your health insurance with no notice. It's pretty brutal, like, that's, that's just rough. Especially, like, yeah, hopefully they weren't getting any active treatments. Ugh, anyway, that's all I'll say on that. [02:56]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** some upcoming conferences in March and April, [03:07]
-
-## [React Paris](https://react.paris/) March 20-21 Paris, France
-
-**Carl:** we've got React Paris. March 20th and 21st. [03:10]
-
-## [React Native Connection](https://reactnativeconnection.io/) April 3–4 Paris, France
-
-**Carl:** We've got React Native Connection, April 3rd and 4th, also in Paris. [03:14]
-
-## [React Miami](https://reactmiami.com), Apr 17-18 Miami, FL, USA
-
-**Carl:** we've got React Miami, coming up in April 17th And 18th. [03:19]
-
-## [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
-
-**Carl:** there's also CityJS London, April 23rd to 25th in London. [03:25]
-
-**Mark:** Then whole slew of things in late May and early June. Conference season kicking off. [03:30]
-
-**Carl:** Yeah, definitely. I need to actually book things. I don't have anything, I'm going to render Atlanta in June, but I don't have anything booked before then. Yeah, going to Brazil for 12 days is really kind of complicated by Soaked up a lot of my logistical planning. [03:35]
-
-, Um, yeah, our sponsor. We are sponsored. We have a sponsor. [03:49]
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl:** Infinite Red is an expert React Native consultancy. It's been around since 2015. So basically the entire time that React Native has been around. They are our only sponsor in part because very few companies do as much as they do for the ecosystem. [03:53]
-
-, and I just don't know Too many other companies that have done quite so much for quite so long. So very happy to be partnered with them in that way. They only do React Native and they've built over 75 apps for companies from startups to the biggest in the world. And other than being kind, great people who have done great things for the ecosystem, like hosting podcasts and organizing conferences, They are generally just a small team that focuses on like building for the long term. [04:07]
-
-So if you are working at a company that's spinning up a new React Native project and needs to get build some expertise, definitely give them a call because they will actually not just build it, but they will work with you to help develop expertise and hit the ground running. Cool. [04:34]
-
-## New releases
-
-**Carl:** onto some new releases. [04:48]
-
-## [React Router 7.2](https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v720)
-
-**Carl:** We've got React Router, putting out a minor release, 7.2. Looked pretty minor. The headline for me here is that they have a type safe HRF tool, which sounds pretty interesting if you can have type safety. That your links work like that's just neat. They have a new way of doing that how well it works remains to be seen, but it seems cool [04:50]
-
-## [TS 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8-beta/)
-
-**Carl:** We've also got TypeScript version 5. 8 with a bunch of stuff. Of course TypeScript new version [05:11]
-
-**Mark:** thing that I'm interested in here is the new erasable syntax only flag. And for background on that, so TypeScript has always been described as, you know, a types only layer on top of JavaScript. But there are a few TypeScript features that actually do have some runtime code. Enums, I think a couple of the, a couple of the old legacy, um, syntax features as well. [05:18]
-
-And so, there are a number of tools today which work to strip out TypeScript types. But if your code uses some of those features that do have some runtime code, they, they don't work right. And this actually matters a lot for things like Node's new TypeScript, Stripping support. [05:43]
-
-And so, to try to work better with those tools, TS has added this erasable syntax flag, which I believe actually throws an error if you are using any of the syntax that has runtime output. So it's basically like a, an extra enforcement check to make sure that you're not using any of those features. And that way you can ensure that your code is compatible with just stripping the types as opposed to like a transpilation. That's actually a really big deal. [06:01]
-
-**Carl:** Yeah, super helpful. And it's actually, that's like a reasonably large build time optimization if you can get away with it. Because if you're not actually analyzing the types while compiling the code, you're just doing the parsing and the output. Like that's a lot less work. And your, like, VS Code, our IDEs, our language servers are already surfacing most of those type errors. [06:29]
-
-So, like, I think it's really neat to, for one, I have used this just Because it's less effort to stand up a new project. You know, if I can just lean on the language server, then that's just less code, fewer moving parts, fewer things to go wrong, fewer things to break when I pick the project back up in four months. [06:52]
-
-but yeah, it's also like if you can move the actual type checking into like CI or something like that and just do it less frequently, that's, that can be a lot less work overall. Yeah, there was a relatively subtle thing, slightly smarter return types when generic arguments are used in conditional types. [07:08]
-
-It's really specific and only a partial solution, but I've run into some problems like this. And the overall like pattern that they were showing off for this was like not super familiar with to me and looked useful. So like, I that caught my eye as like a kind of subtle but useful thing. [07:27]
-
-They are adding support for using require to get ESM modules. Which is interesting, like this is, you know, a continuation of the long tail of complexity that the switch over to ES modules, standardized modules, is having. But like, cool, now we have one more way to run into fewer problems when In an ESM environment, but needing to depend on CommonJS code. [07:43]
-
-it still does not allow you to require an ESM file that contains a top level await. [08:10]
-
-**Mark:** Because `require()` is synchronous. [08:16]
-
-**Carl:** yes, facts. Also added a new flag that just caught my eyes, like a nice, I don't know, LTS feature. They have a `--module node18`. So you can tell TypeScript what module, like parsing, what determines what modules to use, how it evaluates what modules are being imported? You can tell it to use specifically the behavior for node 18. [08:18]
-
-I've done a lot of maintenance of legacy apps and weird edge cases like that, like, Oh, in the last five versions, they have changed in what order or in what manner modules are crawled. Stuff like that can cause so many weird, obnoxious, difficult to debug errors. [08:42]
-
-## [Prettier 3.5](https://prettier.io/blog/2025/02/09/3.5.0)
-
-[09:01]
-
-**Carl:** Cool, new version of Prettier. I saw they're adding an option, which they do not do very frequently, so that's cool. [09:01]
-
-**Mark:** Looks like they're trying to let you configure how it formats collapsing objects. [09:07]
-
-**Carl:** Useful. [09:12]
-
-## [RTK Query v2.6.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.6.0)
-
-**Mark:** I am very pleased to announce that yesterday I shipped Redux Toolkit 2. 6, which now has infinite query support for RTKQuery. This has been our single most requested feature since RTK Query came out, and I started working on this back in October, after another user had submitted a draft PR to get a first proof of concept going. [09:12]
-
-There was a lot of discussion, a lot of trying to figure out what the problem space is, and how to implement this properly. We ended up adopting the React Query public API design for this. And I had some discussions with Dominic Dorfmeister, the, you know, TK Dodo, the React Query Maintainer, who specifically gave us advice on why they ended up with this API design and how they implemented it. [09:34]
-
-So, worked on this intermittently when I had time over the last few months and very happy to get this out the door. [09:58]
-
-## [Standard Schema](https://standardschema.dev/)
-
-**Mark:** There's also a, project or a standard, I guess, called Standard Schema, which is an attempt to, you know, sort of unify or find a common denominator between a bunch of the different TypeScript validation tools out there, like Zod and Valobot and Archetype. So apparently you can now say that your project needs Just the standard schema definitions, and then the end users can then swap in their preferred validation library where and where they want to. [10:04]
-
-## [Astro 5.2](https://astro.build/blog/astro-520/) (also [Astro 5.3](https://astro.build/blog/astro-530/))
-
-**Carl:** there's also two Astro releases. There's 5. 2 and 5. 3. Looks like it's You know, relatively. Small iterative improvements. I was just reading a little bit more. Astro 5. 3 is talking about automatic session storage setup. And as someone who has opinions about off, And prefers, you know, session storage to jWTs for authentication, that caught my eye. [10:34]
-
-I don't know a ton about this, but definitely anything that makes sessions a little bit easier to like wrangle and manage, is definitely nice. I've been, as an exercise, I've been building my own. Authentication from scratch in session storage with React Router v7. So that's just fresh on my mind. [10:59]
-
-I would love to be able to tell you more about what the experience of using Astro is like, but I, I have tried and failed to start several projects because I just don't have time. I have too many different projects going on. But It always crosses my mind when I'm thinking about, like, a blog, or a static site, or things like that. Seems like a very good tool for those purposes. [11:18]
-
-## [Turborepo 2.4](https://turbo.build/blog/turbo-2-4)
-
-**Carl:** There's also TurboRepo 2. 4. TurboRepo is a great tool for managing monorepos. From the next team, and they've got a number of improvements to enhance your repository as they say Boundaries, watch mode caching, continuing the trend of Vercel dealing with caching issues and Versioned configuration validation from within your repository, interesting. And they've also got circular dependency recommendations for adopting Turbo repo in large repos more easily. That's interesting. I've run into so many circular dependency issues throughout my career that just very much catches my attention. Very neat. Cool. [11:35]
-
-**Mark:** I spent time trying to squash those as well. [12:16]
-
-**Carl:** Just the worst. So painful. [12:19]
-
-## Main Content
-
-**Carl:** Cool. Into our main content. Mark, you wanna start us [12:20]
-
-## [Sunsetting Create React App](https://react.dev/blog/2025/02/14/sunsetting-create-react-app)
-
-**Mark:** All right, yes, yes, I, I have thoughts and opinions on this topic. So, in our last episode, as a Relatively brief recap. When React 19 came out, it broke Create React App because of a peer dependency version mismatch, where the old templates wanted React 18, but CRA tried to install React 19. So I spent a chunk of January griping about this and trying to say, this is broken and it needs to be fixed. [12:23]
-
-That led to several heated discussions on Blue Sky with the React team about, and trying to convince them to fix it. And so, right before our last episode, I had filed an issue that recapped what was broken and why, and pointed to a couple of PRs that other people had filed to both fix the CRA templates and actually mark the Create React App repo and command line tool as deprecated, and the React team had actually taken action on that and merged the initial PRs And they hadn't actually put out a new release of Create React App that fixed the brokenness, but the changes were in there and they were trying to figure out the process for doing the releases. [12:53]
-
-Along with that, though, I had specifically said that I felt the React Docs setup page ought to recommend Vite as, you know, the equivalent replacement tool. So that people being told, CRA is dead, don't use it, would have a direct equivalent tool to try to use. So that's where we left off a month ago. [13:38]
-
-And the entire topic has continued significantly over the last few weeks. So, from my perspective, there were several additional debates going on, on, you know, BlueSky and Twitter and in the docs about, you know, what ought to be done as follow ups and, you know, what should be recommended as tools. [13:59]
-
-And on my side, I had actually started writing a rather lengthy blog post that tried to cover a bunch of topics from how has React been developed over the years to erecting some community confusion, like. You know, the ongoing claims that Vercel is driving React development just to make money on servers, which is wrong. [14:20]
-
-but also describing sort of my take on the history of interactions between the React team and the community and frustrations and miscommunications and docs problems and frameworks and all these different things. So I'd been working on that. In, you know, over the course of a couple of weeks and kind of like teasing my progress online. [14:42]
-
-And I'd also been having discussion with some other maintainers and without having given specific details publicly, the React team actually reached out to folks like Tanner Linsley and myself and specifically said, we can, like, we can tell you're frustrated. We would like to hear your feedback directly. [15:04]
-
-And so I know that, Joe from the React team had a call with Tanner Winsley, where Tanner expressed a lot of thoughts about, I think especially some of lack of new client functionality in React as well as where React was headed. And so, Joe and I had a call. In early February ish, where I summarized all my different concerns, and then there were a couple follow up calls, and, Carl and I actually were on one with, both Joe and Matt, where the React team talked about what they're trying to work on. [15:25]
-
-In response to a lot of these discussions and feedback. One of the things they said was we're, we're preparing a blog post and some docs updates in response to CRA being dead. As well as even things like they've been talking about trying to have a new community working group for a while, but they've kind of gotten bogged down in what the logistics should be. [15:59]
-
-So, based on that, I could see that the React team was very actively trying to listen to feedback and trying to take some actions in response. And so, I think it was later that week that the React team finished the draft of the blog post and the docs updates. They gave me a chance to review it and offer feedback and a bunch of other folks as well. [16:20]
-
-And so they published that blog post and they, I did actually see that they had applied some of the feedback that I'd suggested. They did not apply all of the feedback that I suggested. [16:45]
-
-## Original “[Sunsetting CRA](https://github.com/reactjs/react.dev/pull/7495)” post vs [Build a React app from Scratch](https://react.dev/learn/build-a-react-app-from-scratch)
-
-**Mark:** And this actually kind of got rather controversial again as I rather predicted that it would. They put up a blog post labeled Sunsetting Create React App, where they said, CRA is dead, here's all the things that it didn't include. [16:59]
-
-There's better tools, but also we really, really, really, really, really think that people should be using frameworks that have routing and data fetching and everything else built in. And the first version of this blog post really, really emphasized the framework part. And they did make changes to the setup docs, but they also put up a new blog post that was called Building a React Framework. [17:14]
-
-And so, you know, what, what everyone's been clamoring for is just recommend VEET in the setup page, please. And they didn't actually do that with this first update. They instead, what they said was, well, when you pick your own build tool and your own router. And your own data fetching library. What you're really doing is building your own framework badly. [17:39]
-
-And I can understand the mindset behind that, but frankly, this was not a helpful approach for anyone actually reading the framework. If you are a learner or a beginner, or want to try to choose some other tools, what would be helpful is instructions that say, you can use one of these two or three build tools, you can use one of these couple routers, and one of these data fetching libraries, and at least giving people a valid direction to go with it. [18:07]
-
-And instead, what we got was a pretty straightforward, page that said, if you don't want to use a framework, you can build your own framework. Step one, install Vite or Parcel. Step two, you're going to have to think about routing and data fetching and code splitting, and boy, these are complicated and you will never be able to do this by yourself. [18:35]
-
-Don't do this, please! Use a framework instead. And that really was not helpful for the audience that was going to be reading it. And so I had tried to offer feedback saying I don't think this page is good before the post went up, and that was one of the things they did not listen to me on. [18:57]
-
-**Carl:** Yeah, And it, it definitely feels like that the fe it seems like the feedback that you gave is in line with like community expectations. Just seeing the Reddit response to, you know, the comments on the Reddit post for this blog. I, you know, I saw like Rick Hanlin had replied to something and got down, voted to like, you know, minus 20, something like that. So, it does, just like for more data points coming, rolling in in real time around, the core team is out of step with expectations for the community. [19:16]
-
-**Mark:** Yeah, so, you know, I, I understand what the React team is trying to accomplish, and in fact, actually, one of the, one of the most interesting data points that came out of those couple conversations with the team. So, they've said, since they started this frameworks emphasis that, Part of the goal is that, you know, they, they don't want people to start off with a single page app and then have to do like a major tool migration in order to add SSR functionality. [19:48]
-
-What I didn't realize was a lot of their goal and mindset around this is actually around React app performance. And they are actually very sensitive and I've heard a lot of the criticism. From folks like Alex Russell that, you know, single page apps and the average React app are horribly performing tens of megabytes of JavaScript. [20:14]
-
-Like, they're actually very, very sensitive to that criticism, and I don't think I'd realized how sensitive it was. Turns out that part of their reason for emphasizing frameworks Is, they feel that if most apps start with a framework by default, then on average, more React apps will have somewhat better loading performance, data fetching, code splitting performance, etc. [20:38]
-
-That is actually one of the big drivers for why they recommend Framework so strongly, and I didn't realize how big a driver that was until they told me that themselves repeatedly. [21:05]
-
-**Carl:** Yeah, I can understand that, and like, I don't think that's wrong. Like I have worked on so many different apps and so many of them have been like badly broken in different ways. Like shout out to the company I worked at that had a 45 minute Docker build that produced 36 megabytes of webpack output. Had six different copies of the app because every, Each of their six pages was a different entry point, so you literally had to download six copies of the app as you clicked around. [21:16]
-
-So, like, I've lived that. I've seen that. That is true. Just facts. Also, I don't know, I guess it's maybe just like in this, I feel like it's an inherent tension to the goals of encouraging deep learning and, setting up default incentives that produce better outputs, better outcomes. [21:43]
-
-Like, I feel like they're going very hard at, um, We know that this will produce better outcomes in aggregate. And I don't think they're wrong. I think they're correct to say that. But I don't think it's The ideal path for many individual developers. So I feel like this is, this is a tension between micro and macro. [22:04]
-
-You know, they are taking the macro perspective of in aggregate, this will produce more good. And you and I maybe are looking at the micro of this is not filling the needs for these people specifically. Yeah, [22:23]
-
-**Mark:** Yeah, so like, you know, I, I understand the, you know, make, make sure that you use a tool that has all the features you will ever need. So you don't have to migrate and make sure you use a tool that has all the optimizations built in. So you're getting good default performance. What it leaves out and ignores, though, is that. [22:39]
-
-if you're a learner or a beginner, having fewer knobs and having fewer concepts to worry about is going to make it easier to learn. A lot of companies are in positions where they can't or don't want to use Node on the back end. They just want a very simple SPA. Um, there's a lot of people who, for good or bad reasons, don't like Node. [22:59]
-
-The React team's emphasis on frameworks. They're suspicious of, you know, the, the incentives in Vercel. And so the React ecosystem is very large and for better or for worse, a lot of people are very happy building React apps the way we have for years. And so my perspective is that the thing that the maintainers should do is Provide recommendations, but also recognize that it is a broad ecosystem and at least say The way you're using react is valid and we recognize you and support you Even if you've made choices that we don't think are the most optimal and the problem is the one line emphasis on frameworks And the tone of the statements in the docs has basically told half the ecosystem, We don't care about you, and we think you're doing it wrong. [23:23]
-
-Which is not very helpful. [24:17]
-
-**Carl:** Yeah. For sure. Right? Like, I wanna, I wanna bring in a strong opinion I have, which is that the world is held together with shoestrings and duct tape. Like, everything in the world barely works. If you look too closely at anything, like, it's a miracle that things are functional. And, My impression is that the core team is kind of railing against that a little bit. [24:18]
-
-Like, they wish things worked better. They wish that the world were a little bit more ordered. And they are meaningfully trying to shift, you know, they are exerting their influence on the world as the caretakers for a tool used by literally millions. So, yeah, I don't know. I guess, circling back a little bit, you had brought up, like, community working group and some chats. It's very early, but you and I and Jack Harrington and maybe some other folks are talking about what that might mean. What that might look like, what processes might be involved, and what outputs might be produced. [24:39]
-
-So yeah, I don't know, maybe ReactiFlex can play a larger role in that conversation, in that, I don't know, activity. [25:19]
-
-## [Backlash](https://x.com/youyuxi/status/1891721924197351497) and [confusion](https://x.com/youyuxi/status/1892000761778929931) over initial version
-
-**Mark:** Yep. So ultimately what happened was they put up the new docs PA and the new blog post and the docs page, and this spawned a bunch of controversy and outcry, lots of arguments on Reddit and Twitter and Blue Sky. And, you know, one ex, one example of this was, Evan You, you know, the Vite creator. Um, putting up a couple of tweets where he said that, you know, like, I, I just don't understand why the React team is refusing to reasonably recommend Veep. [25:26]
-
-And, like, I'm, I'm happy to work with them, I just don't understand where they're going with this and why. And that actually got kind of a positive response. Rather, strongly worded initial response from a couple of React team devs that later got retracted and there were a bunch of follow on discussions. [25:56]
-
-But, it's like, from my perspective, the React team has pretty explicitly stated what their goals are, and no one wants to take those statements at face value, which is Interesting. So last weekend, after like two days after the blog post and the docs updates had gone live, I was sitting around on a Sunday night and I'm like, I could try to offer more feedback and suggestions, but I did that once already and I knew what some of the responses would be and that's why I offered this feedback and they didn't take it and apply all of it. So what if I just take this into my own hands? [26:13]
-
-## [Mark filed a PR](https://github.com/reactjs/react.dev/pull/7618) to rewrite the docs, the React team closed that but [based a new one off it](https://github.com/reactjs/react.dev/pull/7624)
-
-**Mark:** And I actually try rewriting the docs page and the blog post myself to try to get across the same message but with a better tone and actually provide better guidance and instruction on using React without a framework. So, I actually filed a PR a week ago that rewrote the docs page. [26:52]
-
-And the next day the React team actually closed that PR, and I actually got a message on the side from Matt Carroll on the React team who said, you know, like, actually do thank you for doing the work on this, but it's not quite the direction we want to go with it. [27:14]
-
-However, they did then open up a new PR that was explicitly intended to address a lot of the feedback from over the weekend. They did copy and paste several of the sections that I had had in my PR, as well as tweaking some other sections. And this did actually get merged. So, it did not have some of the phrasing and the writing approaches that I felt should be in there, but it is legitimately an improvement. [27:30]
-
-And it does actually meet, I think, a minimum acceptable bar where it says, like, they changed the build a React framework page into build a React app from scratch, which is roughly the phrasing that I had used. And it does actually say, you know, you can use V or Parcel or RSPack and a data fetching library and a router. [27:59]
-
-And so it's giving actual instructions And that is linked prominently from the intro paragraph on the main setup page, and it's linked at the bottom. And the setup page actually explicitly uses the word VEET in a paragraph. And so it's not ideal, it's not the exact phrasing I would want, but they did make a second round of changes. [28:24]
-
-And they did listen to feedback, and I do think it meets a reasonable minimum bar of recognizing that you can use React without a framework, and here are steps to do so. So it's been painful, it's still not exactly what I'd like to see, but I think we've actually reached an acceptable state at this point. [28:47]
-
-**Carl:** Heck yeah. All right, nice that it's ended in that spot. We haven't talked about this, but where have you landed on your giant blog posts? Are you still sitting on those? [29:09]
-
-**Mark:** Yeah, I'm sitting on it, so Like I said, part one was a recap of the history of how the React project has been developed, the influences like Meta and Vercell, as well as, you know, dispelling conspiracy theories like Next is dr or Vercell is driving it just to make money. Part two was all the history of, you know, frustrations and good and bad interactions and everything else. [29:18]
-
-And, you know, part of my goal was to document things, and part of my goal was to drive change. And it's ended up helping with the change, but indirectly. I did show the draft to the React team after a couple of our conversations, they, you know, frankly, they asked me not to publish it. [29:43]
-
-they didn't tell me not to, they said I should consider not publishing, which is. But like, my goal with this was not to burn bridges. Instead, I wanted to push them to make changes to the docs, to make changes to the messaging. And, we talked, and they were listening, and they were in the process of making changes. [30:04]
-
-So I felt that at a minimum, I ought to at least give them a chance to publish the doc updates and see how things would work out, because they were in the middle of that. And so now that they've done some of that, I feel like publishing the post in its current form would be like slamming, hitting them with a sledgehammer after they did some of the thing that I already asked them to do. [30:25]
-
-And that doesn't feel good. So where I'm at right now, is I, I still think the first part the history and the conspiracy theories part is probably worth publishing stand alone, and I can probably just extract that. I feel like there's a lot of useful content in the second part, but I would, I would need to extract and restructure a lot of it, and I haven't had time to sit down and think about it, and frankly, after, I would actually like to think about something else for a while. [30:44]
-
-So, I expect to end up publishing some of that content at some point, but it's not top of my priority list right now. [31:08]
-
-**Carl:** That makes sense. Yeah, I actually did sit down with it and four highlighter pens and I feel like there's like four posts in there. I feel like there's your personal [31:17]
-
-experiences of trying to make changes. There's the, like, summary. Oh, man, just like the oral history you captured of like, here's how things have evolved over the last, like, nine years. [31:25]
-
-I feel like is really useful. But Yeah. So cool. Yeah, go sit on it. Don't think about it. I will come to you with thoughts that I have in a, in a number of weeks. [31:36]
-
-**Mark:** Yeah. So overall, it's been a couple months of, you know, a lot of kind of painful discussion and, and a lot of drama and arguing, but I think we've ended up in a fairly good place by the end of it. So Create React app's officially dead. The docs have been updated. The docs say both, you know, use a framework and those recommendations are updated. [31:47]
-
-But they also say you can build an app from scratch and here's concrete instructions on how to do so. The tone is a lot better. So we've, we've ended up in a fairly good point, but a lot of this has shown that there is a really big gap between, you know, the React team's vision of where they want to go with React versus how a lot of the ecosystem wants to use React and I, I don't think that's going to go away anytime soon. [32:07]
-
-Yeah. And I, [32:37]
-
-**Carl:** Yeah, would agree. That reminds me of, uh, Posts that I put on Blue Sky. Opinions. I feel like the current, like, conflict is a, an example of the different, perspectives, really. Like, in this post, I say it's a clash between the indie hackers, the corporate cogs, and the academics. [32:38]
-
-Where, like, by background, I'm a corporate cog, like, I have always had a large team supporting me. And so, like, I was usually the guy, like, playing around in this code base, trying to make it work better for my colleagues, who were then the ones actually shipping, like, individual features. That's a very different setting than if you are, you know, an indie hacker doing your own things and just trying to ship features and functionality. [32:59]
-
-Which is, again, a very different perspective from, the core team, who I'm considering the academics here. Like, I've said before in this podcast, like, I strongly feel that the React core team is managed more like a research project than anything else. And, you know, I, some signal in that, in that I got some, I think like two or three of the core team members responded to this. [33:24]
-
-It was just like a, like, I'm just going to brag that they saw it and engaged. But yeah, like they have, the core team has had a very stable vision for what React could be really since 2013. Like from the beginning, they've talked about stuff like algebraic effects and functional programming and, you know, encapsulation component models. [33:47]
-
-And if you're like, I've been paying close attention to that. So I feel like I have a reasonably clear understanding of what that vision is and has been. And so like, I can see that it's stable, but I think if you're not paying close attention to what they're doing, you're not watching this research team go. [34:08]
-
-You're off dealing with your own projects, shipping code, building features. You know, setting up processes for your team, then I think that. Vision is actually really hard to gather, like just from resources, from reading the documentation, from reading, from following their social media feeds. I think it's really hard to catch up on what the vision is. [34:27]
-
-So that's maybe a gap currently in like what's available. [34:48]
-
-**Mark:** And I think that ties a lot into something that the team mentioned to us in the couple calls I had with them. So, like, we just said that they have a vision, and that's, that's very accurate and valid. And yet, in a lot of ways, I've learned that the vision is almost like a vague, amorphous thing that they're figuring out as they go. [34:53]
-
-You know, it's not that they have, apparently it's not that, like, literally everyone is driving towards the one true vision all the time. It's that, in a lot of ways, are individuals going off and experimenting with things, and then it's almost every so often they get together and figure out, okay, we've played around with a lot of ideas. [35:13]
-
-do we have a consensus on where we're going? And like, one of the things they said was that, you know, like, I've complained that they put up very infrequent updates on the blog, on, in terms of like, roadmaps and where they're going. Like, they've put up three React Labs posts almost like a year apart. [35:32]
-
-And my assumption reading those was that, oh, well, like, clearly they already know what they're doing, and the blog posts are just documenting that plan. And Matt Carroll said it's actually the opposite. Like, they sort of look around at each other, it's like, we probably ought to put up an update post. What are we working on and do we have agreement on where we're going and so that the blog posts actually take them multiple months to write because it's almost like a forcing function to figure out like and actually nail down where they're headed. [35:51]
-
-So that was actually really really surprising for me to hear. [36:26]
-
-**Carl:** Yeah, and you know what it made me think of? The valve management structure, the flat Non hierarchical, anyone can work on whatever interests them, and if you want to get a project done, you have to pitch it to your colleagues. Which was famously, I don't know, Valve has its own vibe, and I don't know, it's like the vibe of Valve is not super far off from the vibe of React releases. [36:30]
-
-You know, the uh, indefinite delays and lack of communication. So, yeah. [36:51]
-
-**Mark:** So, you know, I, I think we're going to see them continue to push forward. I mean, even just in the last few weeks, seeing Sebastian working on implementing Vue transition support and some other pieces like that, they're going to keep building on these things and it's great to see the forward 19's out, but you know, there, there's a lot of people out there that are just very happy to keep using React essentially the way they have. [36:58]
-
-And there's going to continue to be a mismatch because what they're, well, what they're doing is absolutely valid and fine at a technical level. It's not the direction that the React team is trying to push. And so that leaves a lot of people feeling. You know, left out, unsupported, on the outside, and in the worst cases, concerned that somehow, like, client side React is going to stop functioning someday, just because it's not part of the server emphasis. [37:25]
-
-And I mean, anyone can look at, like, you want to be able to look at that and realize it'll never happen, but it shows you some of the, the vibes and the extrapolation happens that leave people concerned. Um, [37:57]
-
-## [Between the Wires: An interview with MooTools contributors](https://www.freecodecamp.org/news/between-the-wires-an-interview-with-mootools-contributors-33d764957575/)
-
-**Carl:** Yeah, I feel like I re share this every couple of months, but I want to share again this resource from FreeCodeCamp where they interviewed a bunch of the React core team through the lens of let's talk about your past work on MooTools. So, like, this is, a now 8 year old interview with, Sebastian Morkabug, whose name I'm sure I'm saying incorrectly, but it's as close as I can get, Tom, Tom Acino and Christoph Poyer, now, Christoph Nakazawa, I believe. Those are still Major players in the current React world, and they have been collaborating since 2009. So, like, they are coming up on 16 years of working together on foundational tools for the web. Like, I never personally used Mutools. But it was a, you know, meaningful minority use tool competing with jQuery. [38:09]
-
-And it remained relevant because I think in like 2014, 15, something like that, they wanted to do, wanted to release a new array tool, you know, an array primitive. And they couldn't because MooTools hadn't yet been released. But yeah, FlatMap, that was it. That was the one, FlatMap. SmooshGate. They couldn't release the standard because Mutools had monkey patched the Array object with its own FlatMap that was incompatible with the standard, and so releasing this would have broken the web. [39:09]
-
-So, like, this team, the core team, has, more than ten years ago, First hand experience with what it means to engage with standards and what it means to break the web. So, like, that's part of why I give them so much leeway and, like, kudos on their approach. Because, like, they know how bad it is to get it wrong. [39:40]
-
-They know that a decision you made 15 years ago can have lingering echoes. That prevent future work from happening. [40:04]
-
-And like, that's a really hard lesson to learn. It's a really hard lesson to apply. [40:13]
-
-**Mark:** The web is forever. [40:16]
-
-**Carl:** The web is forever. [40:18]
-
-**Mark:** So, it's, one of the other interesting points that came out of the discussions with Matt is that the React docs are very much aimed at beginners. And it's not just the tutorial, it's the setup guides. And I think that's, that's also some of the tension here is that people are not looking at the setup instructions page and saying, Oh, this list of tools is especially oriented for beginners. [40:19]
-
-I know what I'm doing. I can make, make my own choices. And that's fine. People have been looking at that page and saying, well, it doesn't explicitly list VEET. Therefore, the React team must have something against Vite. It's somehow bad to use Vite, et cetera. And in my, in my own draft PR, I had tried to rework some of their, their own paragraphs and phrases into a page on web app architectures to provide some guidance on like, what is a server, like a single page app versus multi page versus SSR versus SSG. [40:48]
-
-When might you want to use one versus the other? As a way of, like, applying some guidance to choosing a build tool. And they don't seem to want to go that direction yet, because it's not, in essence, it's not something a beginner should be worrying about immediately. And so I think that's another piece of the tension. [41:24]
-
-In what people want to see listed in the docs recommendations versus React team actually is willing to cover, which then ties back to the thing that Carl and I have been tossing around, which is, what if we had, A fully community written set of recommendations and docs and guidance for using React in the real world as a supplement to the beginner oriented, getting started level official React docs. [41:46]
-
-So we're still trying to figure out what that might look like and what the content might be. In fact, we're supposed to be talking about it literally right after this, [42:20]
-
-but that's sort of a pitch. Like if the React docs are going to explicitly focus on the beginner use case, then it's kind of up to the community to officially, to quote unquote, officially document what it's like to expand beyond that. [42:28]
-
-And how to use React properly in the real world. It's something that I, I had played around with trying to pitch this kind of a community doc site idea a few years ago. It didn't get off the ground and I'm, I'm hopeful that maybe this time around we can make something like that work. [42:43]
-
-## [How to start a React Project [2025]](https://www.robinwieruch.de/react-starter/)
-
-**Mark:** So as an example of this, Robin Weirich, who's a prolific React author and, tutor, Has put up a number of blog posts over the years with advice on, you know, common React libraries and tools. And so he's updated his post on how to start a React project for 2025 with a set of recommendations. And it's interesting to note how this is different than the actual React Docs setup page, because this one actually starts with prefer using Vite as the starting point. [42:58]
-
-, actually discusses some trade offs, both pros and cons, for all the different tools. Talks about using Next, talks about using Astro, which the React docs don't mention at all. And so it's the same problem space, but a very different approach to describing what your choices are than the actual setup page. [43:30]
-
-And on a similar note, So, with Create React app itself actually being officially deprecated. [43:50]
-
-## [Jack Herrington published `create-tsrouter-app`](https://bsky.app/profile/tannerlinsley.com/post/3lif6fdpzkw2s) under the Tanstack umbrella
-
-**Mark:** Jack Harrington actually put together a Vite based starter kit called Create TS Router App with the idea that it would be a, basically a drop in replacement. For the old create react app command that you get a basically like instead of running create react app, you run create TS router app, you get a Vite based project with TanStack router built in. [43:56]
-
-It has the same starting. Application component content and basically equivalent features, but you're starting with a modern set of functionality. You have routing built in, whereas CRA didn't come with a router. You can expand to file based routing if you want to. So, this has been moved into the TANstack organization, and it's now an official TANstack project, and it feels like a pretty useful tool. [44:23]
-
-**Carl:** Yeah, I actually had talked to Jack, just coincidentally, not about this, shortly before he released that tool. And he, just talking to him about, like, create react app and the legacy of it, I realized that, like, the original, promise of create react app was for it to be an abstraction over your build tool. [44:49]
-
-Over all of the build tools, and I hadn't really considered that that was really kind of, that promise never really realized, like, we, yeah, we had it for a while, but It took years for it to update from Webpack 4 to 5, for instance, and then it never released again. So it would, like, I remember at work arguing in support of using create react app instead of doing our own tooling, because, like, let's just never think about tooling again and just stay within the sandbox and get better. [45:09]
-
-What we need out of it. And that promise just never quite happened. So yeah, I don't know that just Hearing it, hearing this TS router, create TS router tool Build as like sort of a drop in replacement for it It is a drop in replacement for the functionality But it does not even attempt to provide that same kind of like social contract promise of future maintenance Just inaccurate, correct. [45:38]
-
-I mean, Create React app never lived up to that promise either, [46:03]
-
-**Mark:** I would actually have a slightly different opinion. I would say it mostly fulfilled that promise. I would, I would agree that it never, it didn't achieve the goal of eliminating the need to think about build tools. In the cases of like the Webpack upgrade or, you know, the fact that the, The blackboxing of the webpack config meant you needed third party tools to alter the config, etc. [46:05]
-
-So like, it didn't make those parts go away, but it did succeed in giving you a single command that would start a project without having to spend time on creating the build config yourself. Or using a boilerplate project or copy pasting it from your last working config. And that did enable tutorials to just say, run, create React app, and now let's start learning React, which was a big goal, as well as making it actually useful for real world, real world projects. [46:30]
-
-So it didn't eliminate those concerns entirely, but I think it sufficiently succeeded in the goals of not having to think about it just to get started. [47:01]
-
-**Carl:** I would agree with that. I understood it to be, to have a larger scope in mind of being an enduring abstraction that would evolve over time. And that didn't happen. Yeah. Anyway, Yeah. [47:10]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Oh man, we have so many lightning round links [47:24]
-
-**Mark:** Lightning Round! [47:25]
-
-**Carl:** Yeah, cool. All right, we're going to fly through this a little bit. [47:26]
-
-## [Vercel acquires Tremor](https://vercel.com/blog/vercel-acquires-tremor)
-
-**Carl:** Uh, Vercel bought an open source React, toolkit, which is interesting to me. Like, I hadn't heard about this in advance, but like, Tremor is apparently a open source React dashboard tool that was funded by Y Combinator in 2023, and now Vercel has bought them. So like, I don't really understand what it means for an open source library to be venture backed. [47:29]
-
-, but like I'm generally supportive of it. Like I would love it if open source maintainers could paid for the work that they do, which is meaningful and impactful and takes a lot of effort. It's a little bit unfortunate to me that the model by which you can get paid for that work seems to be rich dudes in tech decide that they're going to give you money and then other rich dudes in tech buy that work from you. [47:53]
-
-But yeah, that was just interesting. That seems like an outlier. I have not heard of very many open source tools either getting VC funding or getting acquired. Really, Remix is the only other example that comes to mind. [48:18]
-
-## [Things people get wrong about Electron](https://felixrieseberg.com/things-people-get-wrong-about-electron/)
-
-**Carl:** Yeah, I saw a fun post titled, Things People Get Wrong About Electron. And just sort of a fringe at, you know, a fringe post talking about tech kind of at the margins. [48:29]
-
-Like, I have written a re an Electron app in, like, 2015. Oh my god, 10 years ago. Ugh, I'm so old. But yeah, just, it's neat. It's fun to see such a different context for the web. Definitely recommend checking that out. Just as a, as a curiosity, really. [48:41]
-
-## [Initial Observables support in Chrome 135](https://x.com/BenLesh/status/1893053275995357608), [Observable API](https://chromestatus.com/feature/5154593776599040)
-
-**Mark:** So, there's been a decade long effort to try to get some form of observables baked into the browser. Ben Lesh of RxJS has been beating this drum for years, and it looks like they've finally succeeded in getting some of it. Some form of observables actually baked into the browser. It seems partially limited in scope, partially related to, event handlers, but I think it's at least a starting point for adding this kind of an API directly. [48:57]
-
-And so Ben's pretty excited about that. Also on, also on the note of just, you know, really good deep dive technical articles. [49:25]
-
-## [Why I rebuilt ProseMirror’s renderer in React](https://smoores.dev/post/why_i_rebuilt_prosemirror_view/)
-
-**Mark:** someone who used to work for the New York Times talked about taking the pros mirror rich text editing library, which is partially react related, but partially independent. [49:33]
-
-, and rebuilding the ProseMirrorRenderer directly in React on top of the data structures. Great article, very well written. [49:43]
-
-## [JavaScript Temporal is coming](https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/)
-
-[49:52]
-
-**Carl:** Mozilla had a post at the end of January, about Temporal. JavaScript Temporal is coming. Dates in JavaScript are garbage. They are awful. My favorite example of a specific way they're awful is that they have no concept of time zone. And so every date uses your local system time zone, Which is absolutely awful. [49:53]
-
-If you're trying to do anything involving time in two different locations, [50:13]
-
-**Mark:** is why we've had Moment and DateFunctions and Lexon and who knows how many other libraries. [50:18]
-
-**Carl:** All fine. So Temporal is a new, date standard tool, standard library for JavaScript doing dates and it's coming. I hope it's good. I haven't really played with it. I tend, I don't want to think about dates, so I don't want to think about them any more than I have to. And so I haven't really looked at this. [50:24]
-
-It's coming. It's soon. That was a good post. [50:41]
-
-## [Do JavaScript frameworks still need portals?](https://fullystacked.net/portal/)
-
-**Carl:** this was kind of neat. Do JavaScript frameworks still need portals? React has had portals for a long time for like, rendering stuff like modals or tooltips or popovers that exist like, outside of the hierarchy, quote unquote. Just sort of as a way of rendering something within the component tree, but not having the DOM output be in the same hierarchy. [50:44]
-
-And that comes with all sorts of quirks and weird bits. Like z index can get really weird. Think it's awkward and funky for like cross platform stuff. I don't know how well it works in React Native or, you know, other contexts to make use of these portals. So just like this was a kind of fringe topic, like how often do you think about using React portals? [51:07]
-
-And so just like reevaluating, like, are they still necessary? Do they still, is the problem that they were introduced to solve Still relevant in 2025. And I thought that was a good question to ask regardless of what the answer is. [51:33]
-
-## [What Do We Do with You, Old React?](https://www.manuelsanchezdev.com/blog/what-to-do-with-old-react-upgrading-to-modern-react)
-
-**Mark:** we've had years of migrating from other frameworks to React, and we've now had two or three different eras of different styles of React code. So, now you can migrate and modernize your old React code to modern React code. And so there was a good post called, what do we do with you old React that just gave some quick examples of migrating from things like class components to function components and old Redux to modern Redux and old testing approaches to React testing library. [51:46]
-
-, nothing fancy. A lot of this has been covered elsewhere, but it was a good, useful summary. [52:14]
-
-## [“Records and Tuples” proposal is now “Composites”](https://bsky.app/profile/littledan.dev/post/3liwo57opl22b)
-
-**Mark:** And finally, for the last couple, last few years, we've had a work in progress TC39 proposal called records and tuples, which was an attempt to build fully deeply equal objects and arrays directly into the runtime so that you don't have, so that you could just use like the triple equals operator and it would do like a deep equality comparison of all the fields rather cheaply, rather than having to use a library like immutable. [52:18]
-
-js. And this proposal has apparently just undergone a significant revision. It's, I guess it's no longer even called records and tuples, and instead they're calling the objects composites instead, and you would need to call a specific composite. Equals method to compare them. I saw the tweet, I skimmed through the readme of the summary of the changes, I have not had a chance to look through the slides yet, but it's interesting to see how this proposal keeps evolving. [52:48]
-
-**Carl:** Neat. Super cool. Oh yeah. That was all of our lightning round links in like less than 10 minutes. For sure. Proud of [53:19]
-
-**Mark:** us! [53:24]
-
-**Carl:** Cool. Thank you everyone for joining us. That's all we got this month. We'll be back on the last Wednesday of the month, for real this time, I think. [53:25]
-
-, uh, we'll be back at the end of the month in the live stage here in React to Flux or back in your podcast feed just as soon as we can after that. I try to get it by the first of the month, but not always. We gather sources from This Week in React, Bytes. Dev, React Status, Next. Js Weekly. The React. Js subreddit, here in Reactiflux, and directly from those publishing articles as well. If you see anything newsworthy, definitely let us know in the tech news and reads channel here in Reactiflux, or shoot us an email at hello at Reactiflux dot com, with TMIR in the subject line if you can. I read literally everything that comes in, even spam and whatever, so if you send it, I'll read it for sure. [53:32]
-
-And if this is a show that you get value from and want to support, the best way you can do so is by either submitting a review or telling your friends and coworkers about it. Like, if this was useful, just like, send it to one other person. That would actually do a lot for us. Cool! Thank you so much for joining us! [54:09]
-
-**Mark:** Thanks, appreciate it, and hopefully we'll have less drama to talk about next month. [54:24]
-
-**Carl:** Maybe. [54:28]
diff --git a/src/transcripts/tmir-2025-03.md b/src/transcripts/tmir-2025-03.md
deleted file mode 100644
index 881d8dd..0000000
--- a/src/transcripts/tmir-2025-03.md
+++ /dev/null
@@ -1,563 +0,0 @@
----
-title: "TMiR 2025-03: Next had an auth vulnerability, TypeScript is porting to Golang"
-date: 2025-03-26
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:45](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- [[01:28](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:29](#react-native-connection-april-3--4-2025-paris-france)] [React Native Connection](https://reactnativeconnection.io/) April 3 \+ 4, 2025 Paris, France
- - [[01:36](#react-miami-apr-17-18)] [React Miami](https://www.reactmiami.com/), Apr 17-18
- - [[01:49](#cityjs-london-april-23-25-london-uk)] [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
- - [[01:55](#appjs-conf-may-28-30-krakw-poland)] [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
- - [[02:06](#cityjs-athens-may-27-31-athens-greece)] [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
- - [[02:13](#squiggleconf-2025-cfp-closes-may-23)] [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
-- [[03:19](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
-- [[04:24](#new-releases)] New releases
- - [[04:26](#typescript-58)] [TypeScript 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/#the---erasablesyntaxonly-option)
- - [[05:00](#typescript-release-with-go)] [Typescript Release with Go](https://devblogs.microsoft.com/typescript/typescript-native-port)
- - [[06:26](#react-native-078---react-19-and-more)] [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
- - [[06:44](#next-152)] [Next 15.2](https://nextjs.org/blog/next-15-2)
- - [[07:07](#tanstack-form-10)] [Tanstack Form 1.0](https://tanstack.com/blog/announcing-tanstack-form-v1)
- - [[07:54](#zeego-v3)] [Zeego v3](https://github.com/nandorojo/zeego/releases/tag/v3.0.1)
- - [[09:04](#material-ui-v7)] [Material UI v7](https://mui.com/blog/material-ui-v7-is-here/)
- - [[09:04](#slot-pattern-for-overriding-internals)] ["Slot pattern" for overriding internals](https://mui.com/material-ui/customization/overriding-component-structure/)
- - [[10:45](#parcel-v214)] [Parcel v2.14](https://x.com/devongovett/status/1902022923764076808)
- - [[12:33](#xstate-store-v3)] [XState Store v3](https://stately.ai/blog/2025-02-26-xstate-store-v3)
- - [[13:11](#better-auth-v12)] [Better Auth v1.2](https://www.better-auth.com/changelogs/1-2)
-- [[14:31](#main-content)] Main Content
- - [[14:31](#lynx-released)] [Lynx released](https://lynxjs.org/)
- - [[14:33](#release-blog)] [Release blog](https://lynxjs.org/blog/lynx-unlock-native-for-more)
- - [[18:20](#security-vulneratibility-in-nextjs-cve-2025-29927001820-original-researcher-report)] [Security vulneratibility](https://nextjs.org/blog/cve-2025-29927) in Next.js: [CVE-2025-29927](https://github.com/advisories/GHSA-f82v-jwr5-mffw)[18:20] [Original researcher report](https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware)
- - [[20:36](#cves-and-the-nvd-process)] [CVEs and the NVD Process](https://nvd.nist.gov/general/cve-process)
- - [[25:03](#postmortem-on-nextjs-middleware-bypass)] [Postmortem on Next.js Middleware bypass](https://vercel.com/blog/postmortem-on-next-js-middleware-bypass)
- - [[27:00](#nextjs-and-coordinated-disclosure)] [Next.js and Coordinated Disclosure](https://sxlijin.github.io/2025-03-23-next-js-and-coordinated-disclosure)
- - [[30:17](#you-should-know-this-before-choosing-nextjs)] [You should know this before choosing Next.js](https://eduardoboucas.com/posts/2025-03-25-you-should-know-this-before-choosing-nextjs/)
- - [[31:37](#react-native-078---react-19-and-more)] [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
- - [[34:27](#react-native-core-contributor-summit-2024-recap)] [React Native Core Contributor Summit 2024 Recap](https://reactnative.dev/blog/2025/02/03/react-native-core-contributor-summit-2024)
- - [[36:42](#typescript-compiler-golang-rewrite)] [TypeScript compiler Golang rewrite??](https://devblogs.microsoft.com/typescript/typescript-native-port/)
- - [[41:23](#github-discussion-and-on-reddit-too)] [Github discussion](https://github.com/microsoft/typescript-go/discussions/411) and [on reddit too](https://www.reddit.com/r/javascript/comments/1j8s441/comment/mh7ms9n/)
-- [[44:50](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[44:52](#jsc-being-extracted-from-rn-core)] [JSC being extracted from RN Core](https://github.com/react-native-community/javascriptcore)
- - [[45:22](#node-modulesdev-v040)] [node-modules.dev v0.4.0](https://bsky.app/profile/antfu.me/post/3ljubvzvwec2w)
- - [[46:00](#fernando-rojo-joining-vercel-as-head-of-mobile)] [Fernando Rojo joining Vercel as Head of Mobile](https://x.com/rauchg/status/1896943726486032783)
- - [[46:41](#next-vs-tanstack-router-vite)] [Next vs TanStack (Router \+ Vite)](https://www.kylegill.com/essays/next-vs-tanstack/)
- - [[47:46](#expos-ai-strategy)] [Expo’s AI Strategy](https://expo.dev/ai/strategy)
- - [[48:39](#laravel-launched-starter-kits-including-react)] [Laravel launched “starter kits” including React](https://laravel.com/docs/12.x/starter-kits)
- - [[49:36](#react-native-enterprise-framework)] [React Native Enterprise Framework](https://enterprise-framework.callstack.com/)
- - [[50:36](#state-of-react-native-2024)] [State of React Native 2024](https://results.stateofreactnative.com/en-US/) [00:00]
-
-**Carl:** Thank you everyone for joining us for the March edition of this month in React, where we recap and digest the recent developments in the ever evolving react and web ecosystem. We are coming to you live here in Reactiflux, the place for professional react developers. [00:14]
-
-And we are supported by infinite red, but more on them later. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I run community programs like these events and build tools to help keep the community operating. [00:28]
-
-**Mark:** Hi, I'm Mark. My day job is working at Replay io, where we're building a time traveling debugger for JavaScript, and also trying to find ways to make AI developers smarter by giving them access to replay runtime data and in my copious amounts of spare time. Outside of that, I do redux stuff. [00:45]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Some early quick hits. My general temperature check on the job market is that it's not good. It seems bad. Layoffs for March are higher than they were in every month, except last month since September, 2024. So that's five months, yeah, that's not great. It seems like hiring is down. Oh yeah. Look at that. The Fred economic data is a continued decline, so that's not ideal. I guess that is software development, job posting, so I wonder if maybe there's like some kind of title shift leading to that decline as well. [01:20]
-
-But yeah, job market not good. So yeah, if you are on the market, I hope you are. I don't know. Good luck. Sorry. [01:28]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Upcoming conferences. [01:29]
-
-## [React Native Connection](https://reactnativeconnection.io/) April 3 \+ 4, 2025 Paris, France
-
-**Carl:** There is React Native Connection April 3rd and fourth in Paris. So if you're in France, definitely check that out. [01:36]
-
-## [React Miami](https://www.reactmiami.com/), Apr 17-18
-
-**Carl:** React Miami. A beloved conference that I have attended several times but will not be at this year. [01:41]
-
-Is April 17th and 18th in Miami, Florida. [01:45]
-
-**Mark:** I'll be hanging out there. [01:47]
-
-**Carl:** now go see Mark. He'll say, Hey . [01:49]
-
-## [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
-
-**Carl:** There's City Js London on April 23rd through 25th in London, the uk. [01:55]
-
-## [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
-
-**Carl:** We've also got App JS Conf May 28th through 30th in Cacao Poland. I've heard good things. I looked at going, but it's just can't swing it. Too big of a trip. [02:06]
-
-## [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
-
-**Carl:** CDJS Athens is also gonna be May 27th through 31st in Athens, Greece. [02:13]
-
-## [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
-
-**Carl:** And I'm helping organize squiggle conf, which is coming up much later this year. But their CFP is open, so if you are interested in speaking go ahead. Submit. It's gonna be open until May 23rd. [02:26]
-
-**Mark:** I, I got to attend Squiggle Con last year. I, I also know the organizers, Dmitri and Josh, they're wonderful people. They did a fantastic job for a first year conference last year. Squiggle Conf was great. You should totally try to go. It's in, it's in Boston. [02:40]
-
-**Carl:** It is in Boston. Yeah. Dmitri, his most recent accomplishment that made pretty big waves is he got doom running in TypeScript types, which is bananas, and took like a year and a half and he had to learn all sorts of like compiler and like processor stuff. Yeah. Unbelievable. [02:56]
-
-**Mark:** we should totally toss a link to that in here on general principal. [02:59]
-
-**Carl:** Yeah, we probably should. I don't have one handy. But yeah, super cool. Super impressive. Unbelievable maniacal in fact. But yeah. [03:06]
-
-Yeah, our sponsor you know, bear with us through all of our setup stuff before we get to the real news. We, there's so much news. We've got like a pretty major security vulnerability in next. [03:17]
-
-There's like a couple of new releases to talk about, but yeah. [03:19]
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-**Carl:** We are sponsored by Infinite Red. They are an expert react native consultancy that's been around since 2015. And I actually just saw a post that they put up on LinkedIn where in 2015 they hired 21 people and 14 of those 21 are still there, like 10 year tenure for two thirds of the organization. Like that's impressive. [03:38]
-
-I've been laid off and fired a lot and I appreciate a company that is willing to get let its people stick around. Yeah. They're currently our only sponsor, in part because so few companies do as much as they do for the ecosystem. They host the largest React native podcast. They host the largest US-based React Native conference. Yeah, lots, tons of React native stuff. They very meaningful ecosystem investment. [04:04]
-
-They only do React native and have built over 75 apps for companies from startups to the biggest in the world. And they will work with your team in order to help you develop expertise, not just get code running and dip out. [04:16]
-
-So, yeah. if your company is looking to start a new React native project, definitely check them out. They are at Infinite Red, [04:24]
-
-## New releases
-
-**Carl:** into some new releases. [04:26]
-
-## [TypeScript 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/#the---erasablesyntaxonly-option)
-
-**Mark:** last month we mentioned the TS 5.8 beta, and so now it's come out as final. The biggest thing here is probably the erasable syntax only flag, which ensures that you're only using TS types that can just be stripped away without having to go through with transation step useful for use with node, for example. [04:45]
-
-**Carl:** Yep, super great. I'm already using something like that in code that I run. It's just nice. I don't know it's nice to not do like a full compilation step. It just lets me cut an entire thing an an entire build tool out of my, outta my local development, which I like. [05:00]
-
-## [Typescript Release with Go](https://devblogs.microsoft.com/typescript/typescript-native-port)
-
-**Mark:** Although on that note, and we'll talk about this more later the TS team has announced that they have finally rewritten the TypeScript compiler itself in another language go instead of TypeScript still in an early preview stage, but they're seeing 10 x speed up and compilation time. And so the trend of converting JS build tools into other languages continues, and we'll, we'll talk about this more in depth later. [05:26]
-
-**Carl:** Probably, we'll talk about it later and we'll then probably continue talking about it later and later and later, because they have said that this is really gonna ship in like TypeScript seven, which by current release cadence [05:40]
-
-**Mark:** Is like two years from now. [05:42]
-
-**Carl:** Yeah. [05:42]
-
-two and a half, three years. So yeah, we, this is gonna be a topic for a very long time. [05:47]
-
-But yeah, they are continuing the trend of rewriting build tools in native and they are disrupting the trend of rewriting JavaScript build tools. rest. Yep. [05:55]
-
-But yeah apparently they chose Go not Rust because the like general ethos, you know, the, the way you write code in Go is more similar than Rust. So they can do like more similar patterns in the code they're offering. So it's more of a one-to-one rewrite rather than like different enough code that it would have different semantics and different, you know, challenges there. [06:19]
-
-**Mark:** And we have a mo. [06:20]
-
-**Carl:** Ammo welcome. That's okay. We're gonna throw you immediately into the hot seat with React Native 78. [06:26]
-
-## [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
-
-**Mo:** So React native 78 is out. Bunch of small things, but we're getting smaller releases and so this one is mainly focusing on React 19 support. So you can get all the React 19 features that you know and love on the web now working on Native World. And we finally get our logs back in Metro. [06:44]
-
-## [Next 15.2](https://nextjs.org/blog/next-15-2)
-
-**Carl:** Cool. Yeah, There's next. 15.2, which, you know, we're gonna talk a lot about next and more later. But um, this looks like not too crazy. A release they redesigned error ui, more streaming metadata, performance improvements, yada yada. Some experimental features as well. [07:02]
-
-And ooh, experimental node js middleware. A lot more on middleware later. [07:07]
-
-## [Tanstack Form 1.0](https://tanstack.com/blog/announcing-tanstack-form-v1)
-
-**Mark:** Tan Stack Form is a brand new form library in the vein of libraries like formic and React Hook form. This one I, I believe, was started by Tanner Winsley himself. The current maintainer is Corbin Crutchley who'd worked on a previous library, I think, called House Form, I believe. But like some of the big selling points are things like type safety, you know, being able to infer that, you know, like when you pass in the name of a field as an argument that all the other callbacks and everything else know exactly what the, you know, the proper value type for that field is. [07:41]
-
-Lotted, different validation options a lot. And working with SSR and other scenarios haven't used it, but it looks fairly comprehensive and worth taking a look at as a, you know, form solution for your apps. [07:54]
-
-## [Zeego v3](https://github.com/nandorojo/zeego/releases/tag/v3.0.1)
-
-**Mo:** Yeah, so Zeego is a library that I quite appreciate. So it's made by Fernando Roho, who very recently actually joined Vercel as their head of mobile, which is going to, which tells us a lot about the direction that Vercel is going in terms of some of their mobile offerings. But Zeego released a new sort of major release. [08:13]
-
-And so the, the big points with this is and just just for a little bit of context, we have talked about Zeego before in the podcast, but just for anyone who might have missed it, Zeego is a library that allows you to create context menus that are native to each platform and it's universal. So what that means is that it will let you create context menus on the web and it defers that to something like rad. [08:34]
-
-Then on native platforms like iOS and Android, you actually get the native context menus that you get on the platform. So those are native elements that are rendered. And it's, it's a really good example of using the same API but getting very different looks and feels that are native to each platform. [08:49]
-
-So it's, it's, it's a, it's a cool library. It's a very nice like utility library that you might need to use when you wanna get some native functionality inside of your mobile app. But the major things with this is just supporting the new architecture and React native and working with some of the new versions of Expo. [09:04]
-
-## [Material UI v7](https://mui.com/blog/material-ui-v7-is-here/)
-
-## ["Slot pattern" for overriding internals](https://mui.com/material-ui/customization/overriding-component-structure/)
-
-**Carl:** Yeah. Material UI has version seven out. Main thing that caught my eye here is they have a slot pattern for overriding the internals of their different, you know, components. Customizing component library components is like the number one reason why I have not extensively used component libraries in my career. [09:25]
-
-I just, like every company I've worked for, they have wanted a greater level of customization than is achievable just by doing things with the component library. I've been very interested in Chad CN for that reason, because it's just like, it's a co generator, not a library. [09:40]
-
-You use it to make components and then you customize those components to your needs. But this looks like a really interesting alternative pattern for it. Basically, it looks like they have a pair of props slots and slot props where a component will specify different slots that you can override. [09:59]
-
-So you can give it different components to put into places where, you know, like in, in a tab or a dropdown or whatever. That's really interesting. That seems good. Generally, it's nice that they are like trying to standardize it a little bit and like have a specification. I appreciate that and it's, yeah. [10:20]
-
-I've seen a lot of libraries do things like add in. Sort of slots. They don't call it that, but like they let you pass in a component that it will use in place of something else or whatever. But I've always seen that as very like ad hoc and like there's no standardization or structure around it. [10:37]
-
-So seeing this as a pattern is interesting to me. It's definitely, definitely interesting. Yeah. That's all I gotta say. [10:45]
-
-## [Parcel v2.14](https://x.com/devongovett/status/1902022923764076808)
-
-**Mark:** The Parcel Bundler released version two point 14, and this is kind of a big deal because it actually adds built-in React server component support. I was actually just looking at the download stats. So parcel has been around for several years. The primary author, Devin Govet, also works on React Aria and React Spectrum and a couple other component libraries. [11:05]
-
-He's put a ton of effort into building it, but it's, it's very much an also ran in terms of actual usage. Like last month, Webpac had 116 million downloads. V had 85 million downloads. Parcel only had 800,000, so non-zero, but obviously not like, you know, anywhere near the level of the other tools. [11:25]
-
-That said it is a, an actual tool in the space and so it is interesting to see what's more of a bundler rather than a framework. Adding React server component support and looking at the examples the usage pattern here looks to be a whole lot simpler than what Next has and, and has put together, you know, next is the, the defacto standard implementation of React Server components at this point. [11:52]
-
-And so I think a lot of us have tended to assume that the way server components work in NEXT is the way that they work, whereas it, it's really more like React exposes the primitives and it's up to the framework or bundler to decide how they get used. So in this case, apparently parcel actually supports using server components, like just within a, like a, like a basic express request handler, which actually looks a lot simpler conceptually. [12:20]
-
-So parcel may not have a lot of actual real world usage, but this looks like a, a, a nice example of what can be done with server component support. [12:32]
-
-**Carl:** That's cool. Oh, nice. [12:33]
-
-## [XState Store v3](https://stately.ai/blog/2025-02-26-xstate-store-v3)
-
-**Mark:** Meanwhile, the, the X State and people, AKA, mostly David Khourshid has released X State Store. Version three. X State Store is meant to be a, a much wider weight state management tool. Kind of more along the lines of a, of a zoo stand, but with a little bit more of a, a state machine twist on it. So there, there's some updates to make the usage and the developer experience a little nicer. [13:00]
-
-**Carl:** Yeah. Love X State. I don't know, I've just always had an affinity for it. They had a, they've always had a great state machine design tool and I found that useful even while not using the library. So I dunno, I just like them. [13:11]
-
-## [Better Auth v1.2](https://www.better-auth.com/changelogs/1-2)
-
-**Carl:** There's Better Auth version 1.2, which is interesting and cool. I have been following Better Off for a while. I haven't actually used it myself yet. But they've been, [13:21]
-
-**Mark:** Theme of this podcast? [13:23]
-
-**Carl:** yeah, a little bit. There's just so many things. It's hard to stay, it's hard to, staying on top of it is hard to know. Actually using all of it as well is uh, impossible. [13:31]
-
-Yeah, I, I, I like the general vibe of it. [13:34]
-
-I have been let down by literally every auth tool that I've ever used. I have written my own auth far too many times because I'm so irritated with trying to use all of the authentications libraries. And yeah, this seems good. I'm just gonna read what bytes.dev said, 'cause they summed it up very well. [13:51]
-
-"It's got Stripe subscriptions, recapture API, keys teams and sub orgs and a new init CLI, and they rewrote the core library to fix TypeScript editor lags. So like, it just seems really good. They've really been on a tear with shipping improvements. Like I, I subscribed to GitHub notifications for them and I slightly regret it because I swear to God I got like five a week with just like beta releases and new minor releases. [14:18]
-
-So it's, it's, I'm impressed at their pace of development. They seem to be doing a really good job of shipping pretty major upgrades as they go. So, if you're doing a greenfield project that needs authentication, consider it. [14:31]
-
-## Main Content
-
-**Carl:** Mo can you tell us about Lynx? [14:33]
-
-## [Lynx released](https://lynxjs.org/)
-
-## [Release blog](https://lynxjs.org/blog/lynx-unlock-native-for-more)
-
-**Mo:** SO this is, this is not specifically React native related, but it's React native adjacent and definitely react related. So, you may have heard that bite Dance, the team behind TikTok released links, and links is effectively sort of a competitor to React Native. They've created another way that to build native applications using JavaScript tooling and using React as the way that you define UIs, which is really cool. [15:01]
-
-And so, the, the real sort of reason why why this is exciting is because this is actually what's powering TikTok behind the scenes. So this is what they're using internally for TikTok. And you know, TikTok is as large scale of an application as comes. And so it's actually quite a. Quite a big deal to have something like this release and it brings healthy competition to the space of sort of cross-platform native applications where it's been traditionally just rack native and flutter. [15:27]
-
-So I think there's some really interesting stuff here. The TLDR is that they have a sort of multi-threaded a multi-threaded architecture in place. And that's one of the things that they really, really empathize, em, emphasize on. And so the whole idea is that this architecture and this multi-threaded runtime allows you to take priority on sort of synchronous UI tasks that are high priority so that the app feels snappy and responsive. [15:52]
-
-And things like event handlings are done sort of with a high priority. This is getting quite similar to the space of sort of what the React native team is trying to achieve with the new architecture, which was trying to. Targets similar benefits. And so they, they give a lot of examples on things like instant first frame rendering, which is one of the metrics that they're trying to target with this architecture to make sure that the first time you open up your app, you get as quick to instant as possible launches. [16:18]
-
-And sort of multi-threaded scripts for when there's a you know, important scrolling event or something that requires really good responsiveness. Having those sort of concepts embedded into the architecture, which is really, really quite cool. And one of the nice things about this is that their JavaScript layer functionality is not actually react specific. [16:36]
-
-So in theory, down the line, albeit React is really the only main way that you can define UIs right now down the line, they may create other versions of it. So currently there's links, which is the core, and then there's React links as well, which is the sort of the React library that you can use to define UIs for links currently. [16:54]
-
-There could be in the future initiatives where it can allow you to use other UI libraries to do this, which can be really quite cool. [16:59]
-
-**Mark:** I think I saw even at least a mention or like someone at least asking like, when can you use Vue with this? And it sounded like that was a thing that they were trying to work on. [17:07]
-
-**Carl:** Interesting. [17:08]
-
-**Mo:** but you know, that in itself is quite powerful because, you know, one of the, you know, there is nothing like rack native or there wasn't anything like rack native where you could use web-based UI libraries to define a mobile app. And so this actually opens up the door for people to use view to make actual native apps rather than sort of PWAs or hybrid web view based apps that are not gonna be good experiences. [17:31]
-
-So, quite exciting stuff. [17:33]
-
-**Carl:** That is really interesting. And it, it's, it's funny that I feel like over the last year we've talked about a couple of projects that we're exploring different ways of authoring react and getting some form of mobile app out of it. And I'm surprised that there's still like new approaches. This, we've seen so many with like, I don't know, react native web and I'm forgetting the names of all of them, but I swear to God [17:55]
-
-Four of React strict dom. [17:56]
-
-Yep. So, okay. Interesting. That sounds really cool. And I like that there's a way, I don't know, just like it, I love the web. I secretly wish that Web os from like 2012 had been a viable option. So it's just, I'm, I'm, I love seeing the web expand more meaningfully into the native arena. That's really cool. [18:17]
-
-Cool. Alright. Into the headline. [18:20]
-
-## [Security vulneratibility](https://nextjs.org/blog/cve-2025-29927) in Next.js: [CVE-2025-29927](https://github.com/advisories/GHSA-f82v-jwr5-mffw)[18:20] [Original researcher report](https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware)
-
-**Mark:** All right. The biggest news story of the month occurred just a few days ago, and that was that there was a major security vulnerability with next's middleware implementation that ultimately allowed any external attacker to send a fairly simple set of headers and force next to skip the middleware. [18:46]
-
-And if you, your app used the middleware to provide authentication to. You could actually just bypass the entire authentication process. So the assumption here is if you're using next to do middleware, and then there's some other caveats around where your app's actually hosted. But ultimately this was rated as an extremely high concern security vulnerability. [19:11]
-
-So Next has released actual, actual fixes across a couple different major versions to try to patch up the issue. There's been. You know, breakdowns of, you know, what the actual bug is and why this is a concern and how it works. And then there's been a lot of fallout from this issue in terms of how did Vercel handle communicating the vulnerability to the general public as well as other partners. [19:38]
-
-And follow on questions like, you know, how does Vercel and next actually kind of handle their development processes? associated pieces to go through with this. So let's, let's try and break some of this stuff down. [19:49]
-
-**Carl:** Let's see what we can do. Yeah. So you, you mentioned how many versions that they shipped. So they, in, in their, you know, blog post, it's very. I don't know, no details, no extra explaining what happened. They explaining the advisory, I guess they, they then put out a, like timeline of the thing and gave a lot more details. [20:09]
-
-But so they released patches for version 12, 13, 14, and 15, which means that this has been a vulnerability since at least 2021, which is wild [20:19]
-
-**Mark:** It sounds sounds like Al, almost exactly, almost since like the, the middleware feature probably came into existence. [20:26]
-
-**Carl:** Which I guess that makes sense. Like you add a new feature and it has vulnerabilities and until somebody notices it, you don't fix it. But wow, four years for an auth bypass based on a header. [20:36]
-
-## [CVEs and the NVD Process](https://nvd.nist.gov/general/cve-process)
-
-**Carl:** So I want to lead in a little bit breaking down like the CVE process, which I am not sure. I feel like everyone, I feel like a lot of people will have a general, I. [20:47]
-
-Awareness of what, of what A CVE is. I didn't quite realize that it was like an NIST national Institute of Standards and Technology Program. Like this is a government program established in 1999 to track, [21:02]
-
-**Mark:** known security bugs. [21:04]
-
-**Carl:** Right. So like, yeah, and it has a, there's a calculator that lets you figure out the severity of a vulnerability. [21:12]
-
-And it has criteria like the attack vector, the attack complexity, the requirements of the attack privileges required, user interaction are required, and then the impact of the vulnerability. It's confidentiality, integrity, availability. It's basically like how do you do the attack and if you execute the attack, what are the impact, what are the effects of it? [21:35]
-
-So this. You know, the scoring criteria for this vulnerability is it's a network attack vector, which means you don't need to be physically present which is bad if you can do it over the network that's like a high level of access. The attack complexity is low, the privileges required are none. [21:54]
-
-The user interaction required is none. And the impacts confidentiality are high, integrity is high but no impact on availability. So you can, you know, get into confidential spaces and, you know, violate the integrity of the data. [22:09]
-
-You so it, it's, it's basically an attack you can do from anywhere in the world that's very simple. That gets you a high level of access, which is why this is a, you know, critical severity bug. That's so bad. Oh my God. Just for a, a bug of that severity to exist for four years before anyone noticed is oof rough. [22:30]
-
-**Mark:** The general concept here is that, you know, middleware can be chained together. But there's, there's internal implementation details around like possibly needing to rerun middleware or possibly needing to skip middleware. [22:43]
-
-And so at some point Versel opted to implement skipping, running middleware by looking for a specific header that they could attach to the request. And the intent was that this would only be an internal thing, that the header would only ever get added by next itself in response to, some piece of code saying, Hey, we're, we're good. [23:09]
-
-We can just keep going. Or I guess maybe to, to, to get rid of loops in the middleware chain. And someone figured out that. You know, wait a minute, I could, I could attach this kind of a header as part of an external request. And the piece of information that next was looking for the, in the header is just a name of the middleware itself, which is pretty much always based on the file you would've added in your next project, which is apparently in some cases like just the literal word middleware. [23:44]
-
-And so you could end up like having a header value of middleware, colon, middleware, colon, middleware, colon or something like that. the end result is that someone could send a request to a next base server, add this header to their original external request, and end up convincing next, skip all the middleware and never run them. [24:07]
-
-And. And so if some of the were trained to do authentication, then the request would end up just skipping that entire process. I believe Vercel said that the way they have their systems architecture set up it was not really possible to have that be a problem on if your app was hosted on Vercel infrastructure. But then there was questions of, okay, well what if you're running on Netlify or CloudFlare or using one of the Open Next adapters? So the bug exists in next, and then there's the question of, well, how is next being hosted and what requests could actually get through? [24:46]
-
-**Carl:** Right, so. I think what I saw is that they're saying if you hosted on Vercel, you were never vulnerable to this because of how we set up our system, which is great. I guess this. Certainly fuel on the fire of like Vercel is privileging itself in the ecosystem. [25:03]
-
-## [Postmortem on Next.js Middleware bypass](https://vercel.com/blog/postmortem-on-next-js-middleware-bypass)
-
-**Carl:** And I guess building on that a bit, so they put out, you know, their postmortem breaking it down and breaking down the response. [25:11]
-
-**Mark:** Which, which came out about like, like two to three days after the actual announcements. [25:16]
-
-**Carl:** Right. And it looks like, you know, in the timeline they talk about like receiving emails and like multiple reports, which delayed the triaging. But like, you know, the core of the timeline, I. [25:27]
-
-**Mark:** A month or something. [25:28]
-
-**Carl:** it looks like somebody reported this at the end of February on the 27th, and then it didn't get triaged until two weeks later, which seems not good. [25:38]
-
-I don't know. I, I, I have done triaging of security vulnerabilities. I was the point person for that at my last job for like two years, a year and a half, something like that. And there's a lot of noise. There's a lot of garbage that comes in. There's a lot of, you know, quote unquote security researchers who are just like running automated tools like nmp. [25:58]
-
-You know, it's like, you know, you are an NPM audit and it's like 63 critical violations and like, none of them actually matter at all. So like, there is a lot of noise and I can understand how triaging might get delayed, but you know, like even just reading the headline, you know, if somebody submits like authorization bypass, like that would wake me up. [26:17]
-
-So, I don't know, just waiting for two week lag time on that is not ideal. [26:22]
-
-**Mark:** One, I mean, one, one bit of that is, it sounds like the initial submission just said, this looks like it's a problem in next, in, next next 12, which was out of date. And so like it sounded like someone may have glanced at it and said, oh, we don't even support next 12 anymore. It's not a big deal. [26:38]
-
-And then the researcher came back and said, actually, it's a problem in like every version of next. And that finally got someone to wake up. [26:46]
-
-**Carl:** for sure right? So, like, okay. Devil's in the details on this as always, but yeah, it's not a great situation. And what's more is that, it sounds like they did no coordinated disclosure. [27:00]
-
-## [Next.js and Coordinated Disclosure](https://sxlijin.github.io/2025-03-23-next-js-and-coordinated-disclosure)
-
-**Carl:** This person talks about some other CVE environments or disclosures that they've either, you know, been a part of seen and for instance, you know, like heart bleed, some of those other like large scale mass impact vulnerabilities, like this is not obviously of that scale, but it is large. [27:21]
-
-So the, the, those ones like heart bleed, they had like multiple months of coordinated disclosure where behind the scenes in secret. You know, once these vulnerabilities are known, the companies are coordinating with each other to say like, are you vulnerable? Yes. Here's how we fix that. Are you? Yes. Okay, let's fix that too. [27:40]
-
-And. What they're claiming is that Net or Vercel did nothing like that. They received a report, they validated it, they pushed their own fixes, and then they went public with it and basically caught other platforms like Netlify, cloud Flare, et cetera, with their pants down. And it was just like, oh shit. [28:02]
-
-You what? What? We're vulnerable. And so now everyone's scrambling. And it's been publicly, it is, it's been publicized. So like now many websites are vulnerable, it's public knowledge and the a patch isn't ready. So like, that's, that's just not nice. it's not collaborative at all for sure. [28:22]
-
-So it, it just means that like, it became a race to fix this before it got exploited in the wild. That's definitely not ideal that like that's, I guess I can understand how a company might say like, this is a problem with our product. We are fixing it. We have fixed it. It is time to go public. I guess I can understand that thought process, but man, as far as like being a participant in a broader ecosystem, that's a big blind spot. [28:49]
-
-**Mark:** yeah. The, that, that link about coordinated disclosure is really good. It, it breaks down what did happen at what times, and then talks about like what are, what are the proper practices for handling a security disclosure? What did, like, what actually happened instead? How did this, like, how did other people end up finding out about it? [29:09]
-
-And then like, what, what would have been a proper sequence of results? Instead, I. So like ultimately, you know, things have sort of been handled here, but really, really badly along the way. [29:24]
-
-**Carl:** Yeah, and I guess one more detail that I'll highlight as part of like, this response was not handled well and maybe went through the wrong channels, the wrong internal channels. when they announced the vulnerability, I. One of their claims as part of it, which is accurate as best I can tell, is that you as our customers of Vercel, were not vulnerable because you were protected by our firewall. [29:47]
-
-So it's like, it feels like it went through the marketing department rather than like, I don't know, engineering, security, whatever, where they were making an honest claim about a differentiating factor. But like part of the differentiating is that they were not collaborating with anyone else to help protect end users. [30:08]
-
-So it's like, yeah, sure that's true, but it's also kind of mean that you did that. So, I don't know. It's not ideal. Not great. [30:17]
-
-## [You should know this before choosing Next.js](https://eduardoboucas.com/posts/2025-03-25-you-should-know-this-before-choosing-nextjs/)
-
-**Mark:** And then one other good blog post related to this somebody who works at Netlify and has spent a lot of their engineering time trained to reverse engineer some of the somewhat more proprietary features of Next to make sure that they work on Netlify. Wrote a very long blog post that. Digs into both, you know, some of the, some of the vulnerability aspects, but then also just general concerns about the way next is developed and deployed and, you know, does not necessarily work with the ecosystem as well as it ought to. [30:54]
-
-Describing a lot, a lot of the concerns, you know, that there, that there aren't, official adapters to run on other platforms that it doesn't have serverless support, that there's certain code paths that really only work on versal. And then also kind of talking about, you know, some of the security aspects. [31:11]
-
-It's not like, it's not a, it's not a flat out indictment, but it's a, it's a very fairly written post from, you know, someone who acknowledges, you know, the own biases upfront, but like, it's a, it's a very valid set of concerns from someone who deals with next, from an external ecosystem perspective. [31:29]
-
-**Carl:** Sure. [31:30]
-
-Yeah. Not a great situation overall, but it's out, it's fixed. That's good. Onto the next [31:35]
-
-um, okay. [31:37]
-
-## [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
-
-**Mo:** We are back with another release of React Native. And so this one is is focused again, we're, we're going through faster releases now. So you might've noticed if you've been staying tuned for a little while that our release cadence within the React native ecosystem is becoming shorter and shorter, which is great news because it means we get updates quicker. [31:58]
-
-And that's largely due to the new architecture being out now. And so that allows us to basically the, the core of React native is a lot more stable. And so there is there's, there's more of a foundation to release a lot faster, which is great. Other highlights for this release is React 19 is now available on React Native, which is great. [32:17]
-
-So if you, you know, followed along with the previous React 18 implementation for React Native, you will have been aware that it took years to get it up to date with all of the React 18 features, largely because of the new architecture not being out fully. And so now you can see there's much of a smaller lead time to get React 19 support. [32:38]
-
-So all of the new sort of features of React, things like actions use, optimistic, the use hook, all of that stuff, and, you know, not needing to use forward ref anymore. All of that stuff is there now. On top of that the React compiler support is is now there. So you can actually install the compiler, configure it, and it should be able to work just as you would on the web, which is awesome. [32:59]
-
-The, probably the most, important feature for the community though is that they've brought back JavaScript logs in your metro bundler. So this was one of the things that the react native team did last release was they removed logs being shown in your JavaScript bundler. So they were trying to push people to use the react dev tools that they released, or the new dev tools that they released for the React native ecosystem only to face the most crazy amount of backlash from the community because their logs had moved. [33:27]
-
-And people were very unhappy about that. So, they rolled back that. you can pass on a flag now and basically get the logs showing in your bundler once again, like it was for the last. However many years React native has been out for. And so they have said that they will eventually remove this again. [33:43]
-
-But they're trying to give a little bit more time for people to adjust to using the new dev tools. So we'll see how that goes when that happens. Once again, there's some other minor changes, but those are really the big things that's worth mentioning. And I think we're gonna get a lot more React native releases happening a lot more regularly since the new architecture is up. [34:00]
-
-**Mark:** Sounds like a pretty substantial set of changes. [34:02]
-
-**Carl:** And it's cool that they are able to release more quickly, to keep better aligned with the, you know, main mainline react version. I hadn't really registered that as a benefit that would come out of the new architecture, but it makes sense, especially while they are effectively maintaining two versions, you know, new architecture, old architecture, suddenly only have to do the new architecture. [34:25]
-
-That makes a lot of sense. That's super cool. [34:27]
-
-## [React Native Core Contributor Summit 2024 Recap](https://reactnative.dev/blog/2025/02/03/react-native-core-contributor-summit-2024)
-
-**Mo:** So the, the next thing that I, I thought I'd just drop in here. it was technically published in February, but I think we missed it and I, I wasn't around in February is the React Native Core contributor Summit for 2024. The recap was finally released. So this is an article on the rec native dev blog. [34:43]
-
-I actually co-authored this. So last year in SLA in in Poland, I think it was around September we had the React Native Core Contributor Summit, which is a, a full day workshop. Talking about a bunch of different. Things that are strategic to React native in general. And one of the things we talked about was the release process. [35:02]
-
-We talked about, you know, what's the next big thing after the new architecture. So there was a bunch of different sessions and we split off. There was a session about how do we bring web APIs into, into to, to the React native world to standardize some of the APIs for interacting with the native layer. [35:15]
-
-So a lot of really interesting stuff. We talked about Nitro modules, which is sort of, we've talked about several times in the last few sort of podcast episodes outta tree platforms and react native on desktop. I held a session as well, so I led a session during this during this core contributor summit lean Core 2.0. [35:31]
-
-So just for a bit of context lean core, was an initiative in the React native ecosystem back in 2019. And so the goal of Lean Core was to bring down the surface area of React Native's, core APIs because there was just so much stuff in there. Like somebody needed access to something in IOS's specific APIs and they just create a component and pop it into React Native Core and that would just be a part of maintenance burden for the core React native team. [35:56]
-
-So there wasn't much strategic direction around what goes into core and what goes into sort of community packages. And so they went through this effort in 2019. But the goal of the session this time around was actually, I think we we're due for another cleanup. 'cause there's a lot of random stuff there that is either props in certain core components that are tying specifically to Android or iOS, or there's just some components that don't get used anymore because there's much better components in community libraries that you can use. [36:23]
-
-And most people end up using those. So it was a good conversation around what should be deprecated in the long run. And so that's one of the sessions that I think was quite fruitful. And I say that probably being quite biased because I was the person who hosted the session. But yeah, that's a, that's a summary about the uh, the React Native core contributor Summit from last year. [36:39]
-
-If you're interested please feel free to go and, and read the article. [36:42]
-
-## [TypeScript compiler Golang rewrite??](https://devblogs.microsoft.com/typescript/typescript-native-port/)
-
-**Mark:** Alright, so the other really big piece in and piece of news for not just the React ecosystem, but the web development ecosystem as a whole is the, the TypeScript team has officially announced that they have created a fort, not a rewrite of the TypeScript compiler, the current version of TypeScript itself is written in TypeScript, which means it's actually, you know, in the end it's the, it's just JavaScript executing and they have ported the compiler itself to be written in. [37:14]
-
-Go. And what they say in the announcement is that they're seeing like generally 10 x speedups in the actual TypeScript compilation stage of processing people's programs. I saw at least one post on Reddit where someone was complaining that people are gonna be confused. That this means that they think that this means their code runs faster. [37:34]
-
-It's like, no, this is just compiling the TypeScript types 10 times as fast. And this is a really big deal. this trend over the last five, six years of all these different JavaScript ecosystem build tools being rewritten in native languages, mostly rust, and getting a lot of speed ups that way. [37:53]
-
-So, you know, es e es build as in go you know, RS pack and roll down are both written in rust, et cetera. I mean, a lot of tools being rewritten in native languages to try to speed things up, but a lot of them have still, like the actual build pipelines still get bottlenecked on TypeScript compilation time because it doesn't matter how, how fast you can process all these different, you know, individual module files and bundle them together if you're still doing a full type script type check during that section of the build phase. [38:29]
-
-And so there's been a bunch of attempts to rewrite the TypeScript compiler. I. Into native languages from random people in the ecosystem. The author of SWC had tried to do a couple different attempts at porting. One in rust, one in go. I saw somebody who had done one with trying to, trying to create some kinda like a stack based virtual machine to process the types, and he'd gotten like a baby example working that seemed way faster, but it was only for, it only worked for very, very simple types. [39:01]
-
-So, I mean, there, there's been attempts from individuals, but none of these got anywhere past, like a modest proof of concept stage, like they proved they could work, but then it's a massive amount of effort just to catch up with where the TypeScript compiler is much less keep up with where it's going on a month to month basis. [39:21]
-
-And so, you know, a lot of people had said that, well, it feels like the only way this would actually happen is if the TypeScript team themselves actually decides to do it. Well, it turns out the TypeScript team decided to do it about a year ago, and they've been working on this in secret, and now they've gotten this far and proven it works and are actually intending to push this forward to become, you know, the actual TypeScript compiler down the road. [39:49]
-
-as Carl mentioned, so right now we're on TypeScript 5.8. They put out quarterly ish releases, I think. So basically four, four releases a year. They also follow a kind of a, a, a decimal based versioning system where it's not really SemVer, but they just roll over from 5.8, 5.9, 6.0, 6.1. So they've said that the plan is that the new native go compiler will probably officially become TypeScript 7.0. So that means we probably have about two to three years before that actually happens officially. [40:26]
-
-**Carl:** But they may also just release it like when it's ready. I, I don't believe that the version seven is a firm commitment. So it, maybe, it will, maybe validating it, maybe making sure that it won't break. Everything will happen faster than they expect, and it may be [40:42]
-
-**Mark:** I mean, they, they, they might like, they, they might end up going from like a six four to a 7.0 instead of having to get through 6, 4, 5, 6, 7, 8, 9. [40:52]
-
-**Carl:** Okay. I don't know. I thought they just did straight up incremental and when they got to nine they incremented, [40:57]
-
-**Mark:** right, right, Like, so my, my point is that if it's ready in say one year from now, we would be at TypeScript 6.2, and rather than officially waiting another two years and eight more releases to get to 7.0, they might just say, okay, yeah, this is the end of the line for the old compiler here. [41:15]
-
-**Carl:** yeah. Hard to say. Who knows? I do wanna, I wanna highlight a couple of, you know, comments from the people who worked on this. [41:23]
-
-## [Github discussion](https://github.com/microsoft/typescript-go/discussions/411) and [on reddit too](https://www.reddit.com/r/javascript/comments/1j8s441/comment/mh7ms9n/)
-
-**Carl:** Ryan Cavanaugh put out a great Reddit comment describing why they chose go, basically. And, you know, we kind of talked about it a little bit, but I, I wanted to enter his words into the cannon a little bit here. [41:36]
-
-**Mark:** I was shocked at how much pushback there was, especially from the C sharp folks. Oh my word. The C sharp community was up in arms about why the Microsoft engineers did not pick C Sharp as the language for the new compiler, [41:51]
-
-**Carl:** Yeah, sure. I, the amount of space in my brain that C sharp developers occupy rounds to zero. So anytime they come on, I am a little surprised. But yeah. So like, I wanna, I wanna try and pull out a good quote here. So, like, really their primary goal here was portability. They don't wanna rewrite anything. [42:09]
-
-They would like to adapt it into a new faster language. So they really say portability was always a key constraint here. As we thought about how to do this, we tried tons of approaches to get a representation that it would've made the port approach tractable and rust. But all of them either had unacceptable trade-offs or devolved into write your own garbage collector style strategies. [42:28]
-
-So right, like they, it looks like they really genuinely validated trying to use multiple languages here at least between Rust and go. And they say, [42:38]
-
-**Mark:** I think I saw mention they also tried in c as well, okay, in this post, but elsewhere. [42:42]
-
-**Carl:** yeah, sure. That makes sense. I saw a quote that I liked. " In our opinion, rust succeeds wildly at its design goals, but quote is straightforward to port to rust from this particular JavaScript. Code base is very rationally not one of its design goals. It's not one of goes either, but in our case, given the way we've written the code so far, it does turn out to be pretty good at it." [43:01]
-
-So like basically they chose to write code in a style that happens to align thematically with Go. And so when they chose to port it, it ended up working out pretty well. [43:11]
-
-**Mark:** one of the key points here is that like anyone who's actually worked with a lot of TypeScript types or has dared to peek inside the TypeScript compiler, I. Is aware that there, there are a lot of very complex and very subtle behaviors of TypeScript and you know, one of the complaints about TypeScript for years is that there is no official spec for the language itself and how everything should work. [43:36]
-
-It's pretty much just, well, the spec is what the compiler does for this release and that's it. So in other words, the, the spec is the tests that they have. It's not an official language design document. because of that, if you try to rewrite the compiler in another language and you kind of start from scratch, you run the risk of ha of like trying to do things the same way. [44:05]
-
-But the code ends up being kind of different. I. Then you end up getting literally different output from the rewrite of the compiler, which would be really bad for the entire ecosystem that is depending on the compiler to return consistent type results. And so one of their conclusions was go allows us to make an almost literal one for one line for wine port of the exact data structures and the exact logic that we already have written in TypeScript. [44:36]
-
-And so that guarantees that we should get exactly the same calculation results from the new compiler just faster. Faster. So that was a really, really big consideration here. [44:49]
-
-**Carl:** Definitely makes a lot of sense. [44:50]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Cool. Okay. Onto the lightning round. [44:52]
-
-## [JSC being extracted from RN Core](https://github.com/react-native-community/javascriptcore)
-
-**Mo:** first one JSC is being extracted from React Native Core. So, several years ago there was a custom JavaScript engine that was introduced into React Native called Hermes. [45:01]
-
-That's what everyone has been using for the last several years, or most people have been using for the last several years. There are some people who still use JSC for very specific niche use cases. And so it was inside of the reactive core package up until recently when it's been extracted out. [45:16]
-
-So if you want to use JSC instead of Hermes, it is now an external package and you're gonna need to install it separately. [45:22]
-
-## [node-modules.dev v0.4.0](https://bsky.app/profile/antfu.me/post/3ljubvzvwec2w)
-
-**Carl:** This is very small, but seems neat. I'm just going to call it out. Anthony Fu put out a node modules dev, which just seems kind of cool. It's like a way of analyzing the dependency tree for a specific node module. It seems cool. I have had to do various ways of visualizing dependency trees a number of times throughout my career, and it's always been a pain in the butt. [45:47]
-
-So just seeing a tool that's online, on the internet where you can just like plug it in and analyze it visually is very cool and interesting to me. Seems good. I like it. [46:00]
-
-## [Fernando Rojo joining Vercel as Head of Mobile](https://x.com/rauchg/status/1896943726486032783)
-
-**Mo:** next up on the lightning round is that, as we mentioned a little bit earlier on in the episode, a little bit of a, of a spoiler. Fernando Roho has joined Vercel as the head of mobile. [46:10]
-
-And so this is a very interesting development because Vercel traditionally was very web focused. Expo was traditionally mobile focused. So those were the two frameworks. And it seems like they're starting to bleed into each other's territory, which is gonna get really, really interesting. So that is that's gonna be quite an interesting one to see because maybe Vercel is working on a framework for React Native. [46:32]
-
-And we know that the Expo folks have been working on sort of web-based support as well, so we will see on how this develops. But it's just an interesting signal from the Vercel folks. [46:41]
-
-## [Next vs TanStack (Router \+ Vite)](https://www.kylegill.com/essays/next-vs-tanstack/)
-
-**Carl:** Kyle Gill put out a next JS versus Tan Stack article, which he at the very start says, was inspired by a 2019 post from Jared Palmer contrasting Gatsby with next js. [46:55]
-
-I highlight that because Jared Palmer currently works at Versal. Fun fact, I interviewed with him for a job in 2017. I did not get it. And 2019 when Jared Palmer wrote that Gatsby versus Next Post I feel like was about the turning point for Gatsby enthusiasm starting to die off. That's when mine started to die off for sure. [47:17]
-
-So that, it's, it's interesting seeing that he is calling back to that moment, in this moment in a pretty different direction. So we'll see, you know, who, who knows if that same trend will continue, but it's, it's, it looks like a great comparison of functionality between Next and Tan Stack. And Tan Stack is certainly getting a lot of interest in mind share. [47:42]
-
-So yeah, if you're thinking about it, definitely check that out 'cause it seems nice. [47:46]
-
-## [Expo’s AI Strategy](https://expo.dev/ai/strategy)
-
-**Mo:** Cool. Next up there's a blog post that the CTO of Expo did on their AI strategy. it's quite a short blog post so you can kind of skim through it. But really the point they're trying to make is that we're in an age that you can use AI to democratize building apps. And so they talk about how they're gonna take efforts to make sure that their docs and, you know, all of their material is well suitable for things like the model context protocol, the MCP that philanthropic released but also other sort of, protocols and interfaces that AI agents may use. And then they talk about how Expo is being used by tools like Repli by Bolt and other tools already to build apps from prompts so that, you know, non-technical people can sort of, as we say today, vibe code their apps. But I think they, they're really seeing this as a uh, as an opportunity to, to get people to build apps. [48:37]
-
-The everyday person who's not a developer to be able to build apps. [48:39]
-
-## [Laravel launched “starter kits” including React](https://laravel.com/docs/12.x/starter-kits)
-
-**Carl:** Laravel just released starter kits this month including some for React. So that's interesting. They're doing, like, I, it looked like it included server-side rendering. I'm not sure if that is owned by Laravel or React but just interesting. [48:54]
-
-I don't know. I, Laravel is maybe on my mind because I was seeing a number of months ago some conversation discussing what you get out of the box with tools like Laravel and the general lack of anything comparable in the React ecosystem. Specifically around auth. I saw people talking about what you need to, what you get for free with a tool like Laravel. [49:18]
-
-And I was a little bit surprised because you do not get that for free. In my experience when you're building an app with React, so that just gave Bit, gave me a bit of a respect for the, the, the tool. So it seems neat. It's a new major version, version 12. It's got starter kits. One of the starter kits uses React. [49:34]
-
-It claims server-side rendering support. [49:36]
-
-## [React Native Enterprise Framework](https://enterprise-framework.callstack.com/)
-
-**Mo:** So next up, call stack, the folks behind React Universe Conf and libraries like React Native Paper, have announced that they're creating a new React native framework that's specifically targeting enterprise. [49:49]
-
-Now, this is very early days. They're trying to target some of the pain points that enterprise clients with large, large number of you know, devs and with restrictions on where they can host their infrastructure are facing. And so they want to try to target that niche of React native apps which is quite interesting. [50:07]
-
-And so, this is still very much in sort of waiting list stage. So it's, it's early days. But their, that, their start focus is that you can have reusable cloud builds that run on anywhere. Potentially GitHub actions but potentially also other pipeline providers. And also a nice way to be able to integrate Brownfield into existing iOS and Android apps so that you have an incremental migration path. [50:30]
-
-So, very early days, we'll see. We'll see where we, where we, where this kind of develops and, and, and where this goes. [50:36]
-
-## [State of React Native 2024](https://results.stateofreactnative.com/en-US/)
-
-**Mo:** And last on our list is the State of React native 2024. So this is a survey that the folks at Software Mansion do every single year and they touch on a whole bunch of stuff like dev backgrounds, demographics, what libraries people are using, and what you use for state management and all of that. [50:52]
-
-And so, this year the main things that they're that they basically concluded, which is, is kind of no surprise whatsoever, is the um, expos becoming sort of the main way to build react native apps. And they see momentum with tools like Chrome, the, the, the Chrome dev tools, protocol based new React native dev tools that Meta's announced and tools like Expo Atlas. [51:14]
-
-But take a look into it if you're interested in. Analyzing the trends in the React native ecosystem. [51:19]
-
-**Carl:** Alright, thanks everyone. That's everything we got. We will be back on the last Wednesday of next month in April on the 30th. come join us on April 30th here in the live stage, or we will be back in your podcast feed just as soon as we can. [51:33]
-
-**Mo:** Yeah, well, always a pleasure guys, and looking forward to jumping on in April to see you all there. [51:40]
-
-**Mark:** Likewise. [51:41]
-
-**Carl:** Cool, see you then. We gather sources from this week in React bys.dev, react status next JS weekly, the React JS subreddit here in reactive flux, and sometimes even directly from those publishing articles. If you see anything newsworthy, definitely let us know in the Tech reads, tech News and Reads channel here in reactive Flux. [52:00]
-
-Or you can send me an email at hello@reactiflux.com. I read everything that comes in, even if it gets marked as spam, so don't worry. If this is a show that you get value from and would like to support, best way to do so is by telling people about it or by submitting a review on whatever platform that you listen to it.
-
-Thanks for listening. See you next month. [52:16]
diff --git a/src/transcripts/tmir-2025-04.md b/src/transcripts/tmir-2025-04.md
deleted file mode 100644
index 629d510..0000000
--- a/src/transcripts/tmir-2025-04.md
+++ /dev/null
@@ -1,504 +0,0 @@
----
-title: "TMiR 2025-04: React 19.1 helps debug owner stacks"
-date: 2025-04-23
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- Quick hits
- - [[00:52](#job-market-fred-data-layoffsfyi-trueupio)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
- - [[01:50](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:53](#appjs-conf-may-28-30-krakw-poland)] [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
- - [[01:59](#cityjs-athens-may-27-31-athens-greece)] [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
- - [[02:04](#react-summit-june-13-17-amsterdam-nl)] [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
- - [[02:09](#react-conf-is-back-oct-7-8)] [React Conf is back](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Oct 7-8
- - [[02:22](#squiggleconf-2025-cfp-closes-may-23)] [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
- - [[02:37](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
- - [[03:24](#new-releases)] New releases
- - [[03:27](#animejs-v4)] [Anime.js v4](https://animejs.com/)
- - [[04:03](#rn-v79)] [RN v79](https://reactnative.dev/blog/2025/04/08/react-native-0.79)
- - [[05:00](#nextjs-153)] [Next.js 15.3](https://nextjs.org/blog/next-15-3)
- - [[05:20](#rspack-joins-the-nextjs-ecosystem)] [Rspack joins the Next.js ecosystem](https://rspack.dev/blog/rspack-next-partner)
- - [[06:29](#react-aria-april-11th)] [React Aria April 11th](https://react-spectrum.adobe.com/releases/2025-04-11.html)
- - [[07:13](#redux-toolkit-27)] [Redux Toolkit 2.7](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.7.0)
- - [[07:44](#vitest-31)] [Vitest 3.1](https://github.com/vitest-dev/vitest/releases/tag/v3.1.0)
-- [[07:55](#main-content)] Main Content
- - [[07:57](#react-labs-view-transitions-activity-and-more)] [React Labs: View Transitions, Activity, and more](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more)
- - [[22:04](#react-191)] [React 19.1](https://github.com/facebook/react/releases/tag/v19.1.0)
- - [[22:53](#one-react-mistake-thats-slowing-you-down)] [One React mistake that's slowing you down](https://www.epicreact.dev/one-react-mistake-thats-slowing-you-down)
- - [[26:12](#advanced-react-component-patterns)] [Advanced React Component Patterns](https://kentcdodds.com/blog/advanced-react-component-patterns)
- - [[26:54](#improvements-in-expo-using-owner-stack)] [Improvements in Expo using owner stack](https://github.com/expo/expo/pull/35866)
- - [[27:48](#dan-abramov-is-writing-again)] Dan Abramov is writing again
- - [[29:09](#react-for-two-computers-complement-to-his-react-conf-talk)] [React for Two Computers](https://overreacted.io/react-for-two-computers/) (Complement to [his React Conf talk](https://www.youtube.com/watch?v=ozI4V_29fj4))
- - [[29:26](#jsx-over-the-wire)] [JSX Over The Wire](https://overreacted.io/jsx-over-the-wire/)
- - [[30:11](#impossible-components)] [Impossible Components](https://overreacted.io/impossible-components/)
- - [[35:28](#dont-ruin-his-process)] [don’t 👏 ruin 👏 his 👏 process](https://bsky.app/profile/danabra.mov/post/3lmi3gpiluk2m)
-- [[35:47](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[35:48](#nextjs-rfc-deployment-adapters-api)] [Next.js RFC: Deployment Adapters API](https://github.com/vercel/next.js/discussions/77740)
- - [[36:23](#flightcontroldev-from-last-year-secret-knowledge-to-self-host-nextjs)] flightcontrol.dev from last year: [Secret knowledge to self-host Next.js](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)
- - [[36:38](#styled-components-in-maintenance-mode)] [Styled-Components in maintenance mode](https://opencollective.com/styled-components/updates/thank-you)
- - [[37:15](#rip-styled-components-now-what)] [RIP Styled-Components. Now What?](https://fadamakis.com/rip-styled-components-now-what-a8717df86e86)
- - [[38:50](#redwood-announces-new-cloudflare-based-rsc-sdk-existing-framework-in-community-maintenance-mode)] [Redwood announces new Cloudflare-based RSC SDK](https://redwoodjs.com/), existing framework in community maintenance mode
- - [[40:18](#tc39-kills-records-and-tuples-proposal-possible-alternative-is-composites)] TC39 kills [Records and Tuples proposal](https://github.com/tc39/proposal-record-tuple/issues/394). Possible alternative is [“Composites”](https://github.com/tc39/proposal-composites)
- - [[41:36](#react-compiler-rc)] [React Compiler RC](https://react.dev/blog/2025/04/21/react-compiler-rc)
- - [[42:29](#just-use-vite-with-the-workers-runtime-vite-on-cloudflare)] ["Just use Vite”… with the Workers runtime](https://blog.cloudflare.com/introducing-the-cloudflare-vite-plugin/) (Vite on Cloudflare)
- - [[44:21](#silk-library---native-like-swipeables-for-the-web)] [Silk Library - native-like swipeables for the web](https://silkhq.co/)
- - [[45:22](#transitions-fstate)] [\{transitions\} = f(state)](https://jordaneldredge.com/blog/transitions-f-of-state/)
- - [[45:51](#tailwind-4-bun-and-old-macs-a-supermarket-bag-and-a-truckload-of-fomo)] Tailwind 4, Bun, and old Macs: [A Supermarket Bag And a Truckload Of FOMO](https://blog.julik.nl/2025/03/a-little-adventure-in-modern-frontend)
- - [[46:47](#introducing-firebase-studio)] [Introducing Firebase Studio](https://firebase.blog/posts/2025/04/introducing-firebase-studio/)
- - [[49:05](#gumroad-is-open-source)] [Gumroad is open source!](https://gumroad.gumroad.com/p/gumroad-is-now-open-source)
- - [[49:50](#automattic-laid-off-16-of-staff)] [Automattic laid off 16% of staff](https://automattic.com/2025/04/02/restructuring-announcement/)
-
-**Carl:** Thank you for joining us for the April edition of this month in React, where we recap and digest the recent developments in the ever-evolving reactive web ecosystem. [00:07]
-
-We are coming to you live from Reactiflux, the place for professional react developers, and we are supported by Infinite Red, a consultancy that works exclusively in React Native. I am Carl. I'm a staff product developer and freelance community manager here at Reactiflux, where I do community programs like these and build tools to help keep the community operating. And I might oversee a hackathon next month. So yeah, keep an eye out. [00:30]
-
-**Mark:** I'm Mark. My day job is working at Replay io and in my free time I spend entirely too much stuff and time working on Redux and griping about the React docs. [00:39]
-
-**Mo:** And I am Mo, I had the mobile team at Theodo. And I am an active member of the React Native ecosystem and organized the React Native London Meetup and the React Native London Conference. Happy to be here as always. [00:51]
-
-**Carl:** Heck yeah. [00:52]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
-
-**Carl:** Very quick overview of job market stuff. I found a new data source that I don't know how I hadn't heard of it before 'cause it is not super new. trueup.io has a job trend page that looks pretty good. similar but distinct from layoffs.fyi. [01:05]
-
-They are saying that there's been a little uptick of open tech jobs. But you know, there's also been a bunch of layoffs. Although this month most of the layoffs are coming from Intel, which yesterday had a bunch of reports filter out saying they're gonna lay off 20% of staff. [01:23]
-
-But like 20% of staff in Intel probably means a lot of manufacturing jobs, not like software tech. So I don't know what that means, but yeah. I don't know. Vibes are still bad. One thing I like about TrueUp is that they have a, like remote index where it estimates what percentage of available jobs are remote friendly And that has been trending down, sadly. [01:45]
-
-It's slightly sub 20% right now, which is, not great. Yeah. [01:50]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** So upcoming conferences in May! [01:53]
-
-## [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
-
-**Carl:** At the end of May, May 28th through 30th in Krakow Poland, we have App.Js conference [01:59]
-
-## [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
-
-**Carl:** . There's also City JS Athens around the same time. May 27th through 31st. [02:04]
-
-## [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
-
-**Carl:** Then in June we've got a React Summit in Amsterdam. [02:09]
-
-## [React Conf is back](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Oct 7-8
-
-**Carl:** This is very early, but the React core team has announced that React Conf will be back this year. last year. It was when I was in May. this time last year I was in Vegas for that, but yeah, they're doing it you know, mid-October. So that's cool. [02:22]
-
-## [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
-
-**Carl:** there's an open CFP that closes one month from now for squiggle conf, which I am on staff for. if you would like to maybe speak at a conference. It's a great conference. I love it. It's organized by a, you know, a good buddy of mine. Yeah, definitely check that out. [02:37]
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-**Carl:** And of our sponsor read, we are sponsored solely right now by Infinite Red, which is an expert React native consultancy that's been around since 2015. [02:46]
-
-They're our only sponsor, partly because very few companies do as much as they do for the whole React and React native ecosystem. They host podcasts. They run conferences, they sponsor all sorts of different organizations generally just seem like really great people. They're a team of about 30 people, mostly developers, mostly with more than 10 years of experience. [03:06]
-
-And they will work with your team to help you develop react native expertise rather than just doing contract engineering and then saying, here you go, this is your problem now. So if your company is looking to start working on a React Native app in the near future, definitely reach out to them and give them a shout. Yeah. Cheers. [03:24]
-
-## New releases
-
-**Carl:** Okay, running through some new releases. [03:27]
-
-## [Anime.js v4](https://animejs.com/)
-
-**Carl:** This is only tangentially react related, but anime js a animation library, or they describe it as an animation engine. Just had a V four release and the website is super slick. Definitely a phenomenal advertisement for what you can do with the tool. [03:46]
-
-Very impressive. And animations are always, I don't know, doing high level animations with like a bunch, you know, interactive and different layers, and it, it's always complicated. So this looks like a pretty great tool. So wanted to give it a shout out. Yeah. Mo, can you tell us a bit about the latest React native. [04:03]
-
-## [RN v79](https://reactnative.dev/blog/2025/04/08/react-native-0.79)
-
-**Mo:** react native version 0.79 has been released. There's. Sort of some small changes here. The big one is that the JavaScript engine, JSC that previously used to be the default is now actually being removed completely from react Native Core and being moved to a community package and is effectively really being deprecated. [04:21]
-
-The few other changes some improvements to performance with Android, but all in all, as we'll see, and as we've seen in the past few months with React native releases, they're getting slimmer and a lot more frequent. So this whole idea of sort of continuously releasing React Native rather than having a few Big Bang releases, so good to see that it's chugging along. [04:40]
-
-**Carl:** Yeah. Very cool. I saw this is their third release this year, whereas in the past , they've generally done like three releases in any given year, [04:48]
-
-**Mo:** I think the trend is going towards doing a release every two months or so. [04:52]
-
-**Mark:** That's a pretty solid cadence. [04:54]
-
-**Mo:** Yeah. I think they've really taken a lot of steps over the last two years to try to bring down that release time and it's starting to pay off. [05:00]
-
-## [Next.js 15.3](https://nextjs.org/blog/next-15-3)
-
-**Mark:** Next 15.3 is out. Biggest news for this one is they now have alpha level support for using the turbo pack bundler for production builds. Previously, it had only been available for dev mode. So it looks like there's alpha level version for that. they have it passing most of their tests, but it's apparently not ready yet. [05:20]
-
-## [Rspack joins the Next.js ecosystem](https://rspack.dev/blog/rspack-next-partner)
-
-**Mark:** Also 15.3 now has support for optional using the third party RS Pac Bundler. I. For builts RS Ppac is a rust based re-implementation of Webpac and basic compatible with web pack's configs. So given that the existing version of Next still uses Webpac under the hood, the next and web and RS Ppac teams were able to collaborate and figure out how to get a plugin that would essentially allow it to use RsPack instead of Webpack as one possible alternative way to try to speed things up. [05:55]
-
-**Carl:** Yeah, I did see that the performance improvement from using RsPack and Next is like not that great and like in some circumstances could actually be worse than Webpac, which seems confusing to me. [06:07]
-
-**Mark:** some of it was due to things like JS based plugins and, and some of the, the interrupt back and forth between. Uhland and JS land. [06:16]
-
-**Carl:** Right. I mean, hey, similar problem is how React Native had with the, parsing data back and forth. kind of goes to show you how even once you have a tool that is written in native, it's, you know, it's not a silver bullet. It doesn't fix all the problems. [06:29]
-
-## [React Aria April 11th](https://react-spectrum.adobe.com/releases/2025-04-11.html)
-
-**Carl:** Yeah, react Aria by Adobe had a release. [06:32]
-
-They don't, I guess they don't do versions, they do just date releases. So this is the April 11th release. One thing that caught my eye that I thought was pretty interesting, so they have a calendar tool and they now allow custom calendar support. So it lets you implement your own like calendar schedule in re rendering this calendar thing, which, you know, they, they shout it out, for instance, using a 4 5, 4 fiscal calendar, which I had to Google because I'd never heard of it. [07:01]
-
-So this seems like a very, like, deep in the weeds kind of feature edition for, I don't know that that goes to show how seriously they are exploring the problem space. And I, I take that as a pretty positive sign. [07:13]
-
-## [Redux Toolkit 2.7](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.7.0)
-
-**Mark:** Last week I shipped Redux Toolkit 2.7 as I was on my flight to React Miami. [07:18]
-
-the main feature outta this is that RTK query now supports use of standard schema definitions for both validating requests and responses and errors, as well as potentially inferring the TypeScript types for those errors so that you don't have to hand rate those when you're defining the endpoints. As well as a bunch of other, other bug fixes and improvements. [07:41]
-
-**Carl:** That's super cool. I love generated types. [07:44]
-
-## [Vitest 3.1](https://github.com/vitest-dev/vitest/releases/tag/v3.1.0)
-
-**Mark:** And then Vitest 3.1 is out. Doesn't look like there's a, a huge standout feature, but a, a bunch of, again, small fixes and performance improvements, obligatory. [07:55]
-
-## Main Content
-
-**Carl:** Yeah, into our main content. [07:57]
-
-## [React Labs: View Transitions, Activity, and more](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more)
-
-**Carl:** So conveniently, like 35 minutes ago, the core team put out a new blog post a new React Labs post. React Labs are posts where they write about projects in active research and development. So this is like, definitely, this is like, you know, leading edge. What is the core team working on? [08:14]
-
-They do like what, maybe two of these a year? [08:18]
-
-a solid year since the actual React Labs post. They did have like the, the React 19 release announcements in that since then, I. [08:24]
-
-**Carl:** dated React Labs, March, 2023, react Labs, February, 2024, and now April, 2025. [08:31]
-
-**Mark:** So the headline out of this one is that they have been working over the last few in couple months on official support for the browser view transitions. API now. Going backwards. A lot of folks have asked over the years for some kind of official animation support in React itself. I know that people have compared, versus something like Svelte, which has apparently has the ability to declare some animations directly in your templates. And they've pointed at React and said like, why can't I do the same thing? Or like, you know, animating elements in and out is, is really, really difficult. And there's been lots of, you know, different animation libraries for React over the years, react Transition Group, react Spring, et cetera. But this is the first time we've ever had anything related to animations baked into the React core itself. Now as usual, I'm not actively ready in a lot of React myself these days. And when I have, I've never done anything animation related, so I'll be honest. I still don't even fully know what a view transition actually is, but I see a lot of people really, really excited about it. My, my vague understanding is that it's taking elements that are within the page and being able to move them back and forth. [09:46]
-
-**Carl:** As far as I know, it's largely about like page transitions, like when you navigate it will let you emulate like the kind of a native style of like, oh, this new, you know, new pane slides in over top [09:57]
-
-**Mo:** I mean, there, there's a few different types of transitions. There's like a fade transition that's native sort of there. But there's also the, the one that you're referring to, I think Carl, is the shared element transition, which is you have one element that exists on the first page and then the second, that element kind of persists, changes shape. [10:13]
-
-So the best example of that is like Instagram when you open up a a post and it kind of expands to take up the whole screen. That's what we call shared element transition in the mobile world. [10:22]
-
-**Mark:** Yeah, that, that makes sense. And I can definitely see how something like that would be difficult to do in React, where, you know, normally you stop rendering A and you start rendering B. [10:32]
-
-So the React team has been working on an official actual view transition component which has a number of different. Pieces of functionality, being able to, to label the transitions animate navigations, do some customization of these behaviors. the blog post goes into some examples of what these different capabilities are and how you would actually try to use them in practice. So it is still experimental. You have to specifically switch over from a production stable build of react to using the latest experimental channel release. But it's gotten to the point where they think it's actually ready for folks to try out. [11:09]
-
-on a similar note the React team has been working on and off for the last three or four years on a component that they originally called off screen. And the idea for this is that, as we all know, when you unmount a React component, everything about that component goes away. The effects are cleaned up. [11:27]
-
-The state that was unique to that component instance goes away, and that's made some things like, you know, building tabbed UIs difficult because you either have to do some work to hide the other tab contents, you know, maybe using like display none in CSS. But, and or you actually have to unmount them. [11:49]
-
-But in that case, state that was there goes away. And so the intent of this offscreen component. Was that you could wrap it around a section of your UI and you could tell React to toggle the display, but it would keep those components around and preserve their state. And then when you make it visible again, everything's still there. So they have since renamed this to be called the activity component. And they've also, and so now that is all at a point where it's officially ready for trial in an experimental form as well. And I think this is actually gonna be kind of a big deal. , we've actually used the predecessor offscreen component in replays UI for a while, which is why we're stuck on an old experimental build of react. And it, it really does prove pretty useful. [12:37]
-
-**Carl:** this like scratch an itch in the back of my brain because it, I, remember talking about this previously, so I was just googling like the, you know, offscreen and oh my God, like they've, they've been talking about this in both of the last two labs posts that we just mentioned. [12:50]
-
-So like, you know, they've got a tab called offscreen Rendering in 2023. "Offscreen rendering is an upcoming capability and react for rendering screens in the background." Like, okay. Alright. So they've been looking at this for over two years, I guess. It does seem really useful. Like I have definitely used every trick in the book to make things, you know, deprioritized. But yeah, I'm a little surprised to see that this is still in progress [13:16]
-
-**Mark:** The other two interesting bits out of the blog post about this, and they were not things that I, I had thought about in relation to this component. Another use for this is that if you start off with the activity labeled as Hidden, React will pre-render that content even before it's been displayed at all. But using concurrent capabilities, it'll be done in the background. So this can be useful for, you know, maybe you have like a more expensive piece of the UI that you know will be shown eventually, but maybe it doesn't need to be part of the initial render. And then that also ties into SSR capabilities as well. [13:54]
-
-And based on the initial value, react might like, include it in the content and then hydrate it later, or, do it in the background. And they also mentioned the possibility of adding some additional modes to this. Right now, currently it's, it's an nu that is just hidden or visible and they may actually have some other alternative behaviors down the road as well, which is why it's not a bullion. [14:16]
-
-**Carl:** Yep. Love flags rather than Boolean. That's great. Yeah. Interesting. I guess. I guess I'll keep an eye on it, but like, man, I guess I've been keeping an eye on it for two and a half years now. [14:24]
-
-**Mark:** The post covers a few other things. There's some performance tracking stuff they're working on. They are talking about trying to have the compiler automatically insert dependencies into use effect dependency arrays. there was one phrase in there in the post that I thought was kind of understandable, but also slightly oddly phrased. They, they gave a classic example of like a, a chat room connection in a use effect. they had a sentence to the effect that " Some hooks can be hard to think of in function instead of life cycles, developers get confused," da da da. " We think one of the reasons for the confusion is that developers think of effects from the components perspective, like a life cycle instead of the effects point of view, what the effect does." [15:10]
-
-And it basically what that's trying to say is. You know, the, the entire Rack React community looked at the use effect hook when it came out and we said, ah, this is the replacement for component. Did Mount and Component did update from class components to the point that, you know, often people even even create their own abstractions with those names. [15:28]
-
-I. And the React team has been valiantly trained to get us to stop thinking in those terms for years. And so I think this paragraph is basically saying, we've been trying to convince people not to think this way and failed. But it also like, it's, phrased slightly, like they're almost surprised. [15:45]
-
-People still think of it that way. [15:47]
-
-**Carl:** Yeah. it feels like a documentation problem. I feel like so many people are learning, react from a mishmash of strange places that they're learning, not what the core team would like. And you fix that by writing really good docs. [16:00]
-
-**Mark:** So anyway, the ul ultimately they're trying to work towards making the compiler be able to insert all those dependencies for you, and then maybe someday we get to stop thinking about this entirely. [16:08]
-
-They are also working on an early version of a compiler ex or extension for IDs, which has the potential to act as maybe like a super winter or show you what the transformed component might look like or even like what dependencies it would insert into use effect array automatically. [16:29]
-
-A couple other tidbits. And then one, the last item is very short, but as a library maintainer, it caught my eye. We all know that React has component-based state and that this has the strength that it's isolated to that component and the portion of the component tree, it has the weakness that you can't easily share it across different portions of the component tree. And we also know that Reacts concurrent behavior really only works with state that React owns, which is why external libraries like Redux and Zustand rely on the used sync external store hook, which works, but also kind of forces react to give up on doing things like transitions in the most optimized way. [17:13]
-
-So they've talked on and off for years about what if we were to add some sort of like a reusable store primitive to react. there's discussions about this going back to like 2015 and the blog post hasn't mentioned that they are working on something called concurrent stores. And it gives sort of a one line example that you would pass this to the use hook, and it does say, our goal is to allow external state to be read during render without caring and to work seamlessly with all the concurrent features that React offers. There's no further details. It's something they're just starting to think about. But it sounds like maybe down the road, react-redux and Zustand could use this and still work the same way, but better without the limitations. I don't know. I'm interested. I. [18:05]
-
-**Carl:** Right. I've never used used sync external store, partly because of the warnings they gave of like, this is gonna break stuff. So yeah. That's interesting. That's cool. [18:12]
-
-I'll also shout out, they mentioned, two other things very tangentially, like, we are looking at this, or we intend to look at this. [18:21]
-
-I'm curious about fragment refs. So like, you know, if you want to get a reference to the underlying dom node and react, you can do that with a ref. And you can use fragments to group elements, as a single top level rendered item rather than like wrapping it in a diviv or something like that. [18:35]
-
-But you cannot grab a reference to that group of nodes. But now they're looking, they "intend to research" refs on node groups like that, which is definitely interesting. I could see that being valuable in something like rendering a table or a list of something else. [18:55]
-
-Like especially if you're trying to do drag and drop kind of things. I could understand why being able to access a reference to a list of rendered nodes might be useful. But yeah, so I, I'm, I'm curious about that, but also given how long we've waited for some of these other things that are being researched with maybe clearer use cases, I will not be holding my breath on that. [19:17]
-
-**Mark:** will say that I've, I've watched them put up and merge several prs that are input, are trying to implement fragment refs. So it's, it's definitely not just a theoretical research project. They're actively trained to work out the implementation deals and details. At the moment, [19:33]
-
-**Carl:** That makes sense. Yeah. [19:34]
-
-Likewise for gesture animations gestures are generally just like a pain in the butt. I have never found anything that worked super well for that. So they say we're researching ways to enhance new transitions to support gesture animations, such as swiping to open a menu or scroll through a photo carousel. [19:50]
-
-That's cool. I will be excited to see if they get something working there. Just 'cause gestures are always annoying and part of why they're annoying is because it's such a, I don't know, they're just very far from like the rendering model. The way you have to think about gestures is very far from the way that React asks you to think about rendering a tree of components with like, self-contained state. It's just like fundamentally outside of a component. It's at the level of the browser, the device. [20:17]
-
-So, figuring out a way to, I don't know, reduce the distance between those is definitely interesting and sounds valuable and useful. But they also say for now we're focused on shipping view transition and we'll revisit gestures afterwards. So this definitely sounds a little bit more like intent to explore than active exploration. [20:34]
-
-They say they, they also say, we believe we found an approach that works well and may introduce a new API. So cool. They've done some research, they've got an idea, but it's not their immediate focus right now. [20:44]
-
-**Mark:** the other sort of big picture thing that I took away from this post. So there's been a lot of. Complaints and concerns from the community over the last couple years that the React team kind of stopped caring about the client side. That, you know, all their effort was going into building server components and pushing people towards frameworks and all this other stuff, which I. There's definitely been a push. The React team has noted that part of it is just how much, how hard everyone went in on single page apps over the last several years, and so there, there has been a swing back towards server-side rendering and ess, but even like React 19 had a bunch of client-centric features for, for forms and whatnot. it is interesting that basically all the things that they've got in this blog post are client side pieces, you know, view transitions, activities compiler stuff. Sort of there is a real focus on stuff that works on the client and adding like fairly meaningful core level functionality to the library itself. And so I think this actually kinda counterbalances some of the concerns people had that, you know, they were focusing on the server too much as well as noting that, okay, like, okay, now that the big React 19 push is done, now they've got some room to actually pick up with some of the features that they were trying to work on. [22:04]
-
-## [React 19.1](https://github.com/facebook/react/releases/tag/v19.1.0)
-
-**Carl:** Let's move on to React 19.1. [22:07]
-
-literally the headline in the post itself is the owner stack. They're introducing development mode only stack trace to help identify what components are rendering, which. And this really brought the, the whole concept of the owner staff back to mind for me. [22:23]
-
-Like this was something that I remember learning about and thinking about, thinking in terms of a lot in the first several years that I worked with React. And I think it's been slightly deprioritized in people's minds, like it's lost mind share. But it is super valuable for a ton of different things. [22:41]
-
-So surfacing it better in the developer tools and such I think will be really powerful. I wanted to bring in a couple of like, old, old, old posts that I remember reading and remember being, you know, instructive for me. [22:53]
-
-## [One React mistake that's slowing you down](https://www.epicreact.dev/one-react-mistake-thats-slowing-you-down)
-
-**Carl:** Kent C Dodds, put out a, you know, one react mistake that's slowing you down blog post a while back and it talks about like component composition and like how you structure the tree and it doesn't name owner stack. [23:07]
-
-I So it doesn't name the owner stack, but like really that's what it's talking about. It talks about like, you know, context and like prop drilling and how you can avoid it and why it's painful. And really what they're talking about, what Kent is talking about in this post is mindfully managing your owner stack. [23:23]
-
-Because the reason you have to prop drill is because the owner stack is weird and you need to go through intermediate components between data source and data usage. But if you restructure that owner stack so that you're, instead of passing a prop through one component so that it gets rendered in another component rendered by that component, you can just render children and then you don't need to pass the prop through. You just render them all at the same level. [23:52]
-
-Or, you know, you maybe not all at the same level, but you can collapse that you can make the tree broader and shallower. And prop drilling is like a developer experience, you know, convenience. It's nice to not have to remember, you know, if you think about it as like the length of a pipe, it makes the pipe a lot shorter and you, you know, there's fewer places for things to go wrong and you have to think about fewer twists and turns. [24:13]
-
-So like, that's great. But also a flatter, broader owner stack is just naturally good for performance because when you have a deep tree, something at the top re rendering will cause like everything to re-render underneath it. Whereas when you have it flatter and broader, then just you can re-render in smaller batches, like smaller units of components will be forced to re-render when things [24:39]
-
-**Mark:** I will caveat that one. [24:40]
-
-So rendering does work at the direct parent child level. So like if I have parent component, I. Inside of its own JSX, it renders a child of A, and then it inserts B as children inside of A. So like both the tag A and the tag B are inside of parent. There is still a three component level parent-child relationship tree. So root is the parent of of A, A is the parent of B. But the root is the owner of both A and B. [25:19]
-
-There's still three levels of components that have to get rendered, but it does flatten , the logic needed to generate those. And that's kind of like , the distinction that a lot of people haven't quite seen as they're learning. [25:31]
-
-**Carl:** Right, right. I guess let, yeah, maybe I'll, I'll revise that a little bit. So it's at that root level, if the root level component is re rendering, sure. All of the children still need to re-render, but the deeper the tree, the more parents that're in the loop there are. So this has been like moving components so that it's, the owner tree is flatter, has been like the number one, general approach I've done when there are performance problems in a code base, , which generally comes from, like, you can think in smaller units. I don't know. feel like I'm going deep in the weeds and not stating anything clearly. [26:07]
-
-**Mark:** generally speaking Composition is a good thing that more developers would benefit from taking advantage of. [26:12]
-
-## [Advanced React Component Patterns](https://kentcdodds.com/blog/advanced-react-component-patterns)
-
-**Carl:** Yeah. Another, old, old old post that I'll just shout out. Uh, again had a phenomenal post from 2017 talking about advanced react component patterns and like, okay, some of these are no longer like super duper relevant anymore, like higher aortic components. [26:27]
-
-Like, hmm, probably just use a hook. But these types back in this era of blogging about React stuff like owner stack was a little bit more, closer to the surface, it was still not on the surface. People are not referencing the owner stack. But yeah, just like when. I feel like owner stack is secretly the other option when people are talking about like prop drilling versus context like, well also what if you just restructured it so it's simpler? [26:52]
-
-**Mark:** Yep. [26:52]
-
-**Carl:** Anyway, super cool to see it surfaced. [26:54]
-
-## [Improvements in Expo using owner stack](https://github.com/expo/expo/pull/35866)
-
-**Mo:** one of the things that this owner stack, change is actually powering is some updates to the expo CLI for when you run your app in dev mode because one of the challenges in the React native world is that you get these massive log, massive log spans. [27:10]
-
-The stack trace is not at all discernible because it's kind of interacting in between the native world and, and the react world. but with this, the expo team actually ran a p and I think it's been actually merged now into hopefully the next release of, of Expo where they're actually showing you where in the react tree, the, the, the specific component is being rendered. [27:31]
-
-So it makes discerning some of these error messages a lot simpler. So I think we'll start to see some, maybe some improvements on like the framework level as a result of this. [27:41]
-
-**Carl:** Okay. That's all we got for React 19.1. Really. I don't know. There's just, there's not that much in 19.1. [27:48]
-
-## Dan Abramov is writing again
-
-**Carl:** This is kind of small, this is maybe just like commenting on the ecosystem, but Dan Abramov is writing again, and That's nice. He was writing a lot. I don't know how many hours of text do you think he's written, mark? [28:00]
-
-**Mark:** Many, many hours. Like I, I read fairly fast and there, there is a lot of content there. [28:06]
-
-**Carl:** One of the newsletters I subscribed to that shared this out you know, does share estimated reading time. And it was, you know, one of the posts was estimated reading time of an hour. And like, that's just if you're scanning your eyes over the words, I think, not trying to digest and understand it, but like broadly what he's writing about is server components. [28:25]
-
-**Mark:** Dan is fascinated with server components at like a technical concept, architectural. Where did this come from? How did we get here? What does this, how is this similar to old approaches? How is this different? What does it enable that you couldn't do before, kind of a level. [28:47]
-
-And he's, not even officially on the React team anymore. Like, think of him as like a, private citizen expressing his own opinions at this point. But the different posts are going through different aspects of. Server components from like a, very conceptual level and trained to explain from first principles, how did we get here? [29:09]
-
-## [React for Two Computers](https://overreacted.io/react-for-two-computers/) (Complement to [his React Conf talk](https://www.youtube.com/watch?v=ozI4V_29fj4))
-
-**Mark:** So like react for two computers is taking some of the concepts of, well, we have code that runs on the client and code that runs the server. How do we sort of figure out how to intermingle those? How can we shift pieces of that code back and forth and still have all this work together? [29:26]
-
-## [JSX Over The Wire](https://overreacted.io/jsx-over-the-wire/)
-
-**Mark:** JSX over the wire, I believe looks at, you know, if we, like we started with rest APIs, but rest APIs often end up growing special cases to handle data that the UI needs. And there's precedent for server driven UIs where you specify, here's a list of components in a JSON format. And then you know, the. All your different UI layers, you know, mobile, web, whatever, can just, you know, figure out on the fly what components you're talking about and render those and that RSCs take that sort of idea form a backend for front end pattern, but it's one that has more flexibility. And being able to send the list of components to render over the wire in a rather dynamic way. [30:11]
-
-## [Impossible Components](https://overreacted.io/impossible-components/)
-
-**Mark:** I always skimmed the most recent one, impossible components, but it's, it's kind of expanding on some of this, like where can the logic live? What are some of the capabilities of things you could do, like having a server component read blog files off disk and estimate the reading time rather than like having to insert them into a database somewhere. So. The first couple were very, very abstract and you know, that was a complaint that a lot of people had. the last one was more concrete. He's also kind of trying to be careful to, I. Explain concepts without literally invoking the word react server component. So like think through the mindset without getting caught up in the trap of, well, this is like a thing I can only use with next, or whatever other complaints people have, [31:00]
-
-**Carl:** funny, I just saw a meme that was like, name something that you can describe and people will agree with until you call it what it is called, and I was like, server components. [31:08]
-
-**Mark:** Yeah. So. I've seen a number of reactions. You know, some folks are just saying like, look, Dan, your blog posts are too long. They need a table of content, or at least a, a summary upfront of what is the point I'm trying to make here? And Dan's like, that's not the way I write, and I'm sort of ready for myself at this point, which I totally get and good for him. I've, I've seen a number of comments where people have said like, well, I followed the train of thought and now I'm actually sort of getting. What the point of server components are, and I've seen a couple other folks say that like, you know, if, it's taking this much explanation to try to convince me of what server components do, maybe the React team really needs to like come up with like a 500 word summary, which are, which are all I think, are all very valid reactions. But it's , Dan loves explaining things from first principles. he's a very like, logical, think it through. Why does this exist kind of a person. On a personal level, I'm just very happy that he's gotten past his writer's block and feels good about writing the stuff he wants to say, the way he wants to say it. And also, there is some value in reading through these to try to understand like, what is the point of all this? [32:12]
-
-**Carl:** And like at the end of the day, this is not, I think the, I think " feature in a JavaScript tool" is the wrong mental model for thinking about server components. I really do think that they are exploring a new. Compute paradigm, like it's a blending of the client server modes and they're constrained by, you know, technical aspects, everything in JavaScript in the browser is based around like batch and requests, it's hardcore based around a client server model. And they're trying to blur those lines and they do not really have platform support for doing it. So they are, you know, that's where things like the "use client" / "use server" directives, I think like they're kind of a hack fix because they don't have better primitives in the language, in the runtime to work with. [33:02]
-
-to me, yes, it's taking a lot of words to explain this and to explore it and to try and make it digestible and comprehendible, but it was also really hard to convince people that like, like I, you know, I, I remember early in my career there were a lot of words written about like pets versus livestock servers because like, you should be able to like, kill and restart any server and it shouldn't cause a problem and that's a livestock server, rather than one that you like very gently take care of and, you know, evolve over, over time and love and dote on. [33:34]
-
-And similarly when serverless became more of a thing, like these are different models for thinking about how your code executes and they're complicated and they're hard and I feel like this is cutting edge in so many different ways and so many, I dunno, I, I appreciate Dan really occupying this space at the bleeding edge, especially now that he's not, you know, professionally obligated to as a member of the core team. [33:59]
-
-**Mark:** last thought real fast. when the new React Docs came out, there was nothing in there about server components, and for a while the only official docs about server components were over in the next framework documentation that Vercel's devrel team had written, I still thought there was absolutely nothing in the React docs all, about server components until about a week and a half ago. [34:21]
-
-When I made that statement, after searching to try to confirm that there were nothing, and I missed that, there had been a page added about server components to the docs about a year ago, and I flat out missed that it existed. Having said that I do feel that the React docs would really benefit from having a much more concrete set of pages that describe server components. Ideally I would like to see an intro page, an overview, and in fact, there was actually a Versel blog post about server components that I think should just be literally copy pasted into the official React docs as the intro. I'd like to see kinda like a modest technical explanation. Like what are they architecturally, where do they fit in? [35:02]
-
-What does running a server component output? Maybe some kind of an FAQ because there's an awful lot of questions people still have about them, including some pretty stupid ones. And then maybe even like some kind of like a adoption or migration page. Like I would like to start using them. [35:17]
-
-I feel like having those pages would, it wouldn't solve all people's complaints, but it, it would at least centralize and make some of the information more official to reference. [35:28]
-
-## [don’t 👏 ruin 👏 his 👏 process](https://bsky.app/profile/danabra.mov/post/3lmi3gpiluk2m)
-
-**Carl:** Last thing I'll say on the subject of Dan writing again about server components. he posted on blue sky. "I kind of wanna write a dozen more posts about react server components. But I also feel like it's inviting endless takes about Dan trying to explain RSC means RSC is bad and it kind of ruins some of the process for me." [35:44]
-
-So don't ruin the process. [35:45]
-
-**Mark:** Be nice Dan, please. [35:47]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Okay. Lightning round. [35:48]
-
-## [Next.js RFC: Deployment Adapters API](https://github.com/vercel/next.js/discussions/77740)
-
-**Carl:** There is an RFC from next to do deployment adapters which is pretty cool. Like one of the big endless complaints about next is how hard it is to run anywhere other than versal. So they are meaningfully exploring what it would take to make that easier. [36:09]
-
-Yeah, it was post put up three weeks ago. I, I haven't seen a ton of like movement yet on what exactly that means, but yeah, it's seems cool here for it. Interested. Very excited to see what comes out of that. [36:23]
-
-## flightcontrol.dev from last year: [Secret knowledge to self-host Next.js](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)
-
-**Carl:** And I also wanted to shout out a blog post from October of last year from Brandon Bayer of Flight Control, secret Knowledge to Self-Host Next js. [36:33]
-
-So that seems like a relevant read in, in conjunction with this new deployment adapters. [36:38]
-
-## [Styled-Components in maintenance mode](https://opencollective.com/styled-components/updates/thank-you)
-
-**Mark:** I don't think we mentioned this last month. the style components CSS and JS library has announced that it is officially going into maintenance mode. Part of this is the amount of work needed to do it, and part of it is the shifts in the ecosystem such as relying on context when server components don't support context on the client. So that's both A FYI. This library is going into maintenance mode and also like more evidence that CSS and JS is sort of both falling out of favor and kind of being discouraged by technical changes in React itself. [37:15]
-
-## [RIP Styled-Components. Now What?](https://fadamakis.com/rip-styled-components-now-what-a8717df86e86)
-
-**Mo:** One sort of interesting like experience from my side on this specific thing was we actually migrated on a project of mine that was on the web that was using Next js. They went into the app router and tried to embrace all things server components and part of that process was they had a styled component library, like a shared component library that they had internally, which was all in components and, immediately they hit a brick wall and they had like 80 plus components that were all styled components and they couldn't use any of that there. So to throw in a little bit of AI magic what we actually did was created a custom prompt in like two hours that took styled components and converted it into their choice SaaS modules. [37:54]
-
-Which is going back to basics, but you know, a good technology choice nonetheless, if you want zero js runtime styles. And it worked shockingly well. So if you give it a good set of rules and you define the problem and you give it a nice workflow to follow, as if it was a developer did a shockingly good job, it reduced like the time for each component from like two hours to 15 minutes, 10, 15 minutes with a review process, like manually looking through the code it would generate. [38:22]
-
-So if you're stuck in style components world and need a little bit of help, try to use gen AI and the reasoning models shockingly worked very well because. With CSS, things cascade and it needs to have an internal representation of how styles cascade down. So your four OS in chat, GPT wouldn't work very well, but your O ones and O threes would work quite well. bit of a weird guideline, but it was quite a fun experience and I think it's a good use case for it. Trying to play around with gen ai. [38:48]
-
-**Mark:** I would not have thought about that. [38:50]
-
-## [Redwood announces new Cloudflare-based RSC SDK](https://redwoodjs.com/), existing framework in community maintenance mode
-
-**Carl:** Redwood has announced that they are now doing a CloudFlare based react server components, SDK. So like they used to be more of a framework and now they're like, it's kind of a reduced scope. I don't know. This connects back to, part of the headline of our January episode was "RedwoodJS, dead?" [39:12]
-
-We caught word that like some other person who had been involved in the project early but hadn't been involved recently, came back out outta the woodwork and basically what Redwood JS has been for the last, I don't know, two years, it is not anymore and it is now something else. That's, strange. [39:31]
-
-the SDK looks neat. I haven't played with it yet. I had been pretty interested in Redwood js because I thought they were trying to be like a Laravel for JavaScript and React Universe, and I thought that was cool. Something that is more narrowly like about doing the rendering is a lot less interesting to me. [39:48]
-
-For me, the value of a framework like that is more like, when they were trying to be the Laravel of reactive, I was excited because I would love somebody to make things like authentication and toast messages and all those kinds of things. Easier to do, easier to build a product rather than, I dunno, a rendering model. So this is now kind of going back into rendering model. [40:13]
-
-So it, it seems like an interesting, worthwhile exploration, but it's not what got me excited about Redwood in the first place. [40:18]
-
-## TC39 kills [Records and Tuples proposal](https://github.com/tc39/proposal-record-tuple/issues/394). Possible alternative is [“Composites”](https://github.com/tc39/proposal-composites)
-
-**Mark:** Yep. Meanwhile in, not directly react, but very related news, the TC 39 JavaScript Specification Committee has officially killed the records and two polls proposal. This was intended to add. Deeply comparable immutable objects directly into the JavaScript language, both in terms of runtime and specific syntax for declaring them. The idea was this would sort of like replace all your.dot object spreads and be able to have two objects and deeply compare them with the triple equals sign. [40:53]
-
-And apparently there was pushback from JavaScript engine, you know, developers who were concerned about the impacts this would have on like internal performance. So that proposal's dead. There is a new proposal called composites, which is sort of lighter weight, like it looks like you would construct objects use, like using like a new composite class that could then have like a composite equals comparison, possibly. So sort of the same direction, but like less deeply embedded in the language itself. So I know a lot of folks had a lot of interest in records and tuples, and we're hoping that one would really come to pass and it didn't happen. [41:36]
-
-## [React Compiler RC](https://react.dev/blog/2025/04/21/react-compiler-rc)
-
-**Mark:** React Compiler just came out, it was in beta and they've now gone rc. so number one, they, you know, they think it's, it's pretty good. It's almost ready. Number two, they've rearranged some of the lint rules previously. The React. The React compiler lint rules were in their own package, and I believe they're moving them into the existing rules of Hooks package. then they, they also announced experimental support for integrating the compiler with the SWC build tool, which is, you know, conveniently what's actually used by next. the compiler is primarily exposed as a babble plugin, even though the, all the implementation is not babble specific. they've found a way to integrate it into SWC, even if it's maybe not the most optimized way and are continuing to work on, you know, different approaches for configuring it as well. [42:27]
-
-So it's getting fairly close. [42:29]
-
-## ["Just use Vite”… with the Workers runtime](https://blog.cloudflare.com/introducing-the-cloudflare-vite-plugin/) (Vite on Cloudflare)
-
-**Carl:** Nice. Yeah, CloudFlare has announced better support for Vite with the Workers' runtime while also throwing a little bit of shade, I think, at the React ecosystem by titling it quote, just use Vite dot dot dot, with the workers' runtime. I don't know. It just feels like they're throwing a little bit of shade out there. [42:47]
-
-it looks pretty neat. I would like to play with this a little bit more, like yeah, they say "we're announcing release of the CloudFlare v plugin as well as official support for the React Router v7." So that's cool. I am currently running a React router v7 app. [43:01]
-
-That would be interesting to connect to CloudFlare in that way. I guess like the big distinction here is that previously I. They say, "the V dev server would always run your server code in node js, even if you were deploying the CloudFlare workers." in local development. Previously if you were using workers it would just run in node and that's not the same. [43:21]
-
-There are node APIs that are not available in the workers' time. So now taking advantage of the environment, API that we talked about a couple of months ago they are able to run your local development workers in an identical environment to what they will have in production. So that's cool. [43:40]
-
-Definitely very neat. And I generally, I think workers are super cool and just like an interesting programming paradigm. Like talk about, you know, exploring new paradigms for executing code workers are the most exciting other than server components [43:54]
-
-**Mark:** Last month we announced one of the major pieces of news was a vulnerability in Next's middleware implementation that could potentially have author related concerns. And there was a, you know, a major CVE vulnerability announced around that. This month it was react routers turn something was announced to have to do with some of the the path parsing definitions. [44:12]
-
-There are fixes out for both React Rider and remix. Please upgrade appropriately. [44:17]
-
-**Carl:** Yeah, this one looks a lot less major than the next one, but yeah, they did get a CVE. [44:21]
-
-## [Silk Library - native-like swipeables for the web](https://silkhq.co/)
-
-**Mo:** So next up, I just a library that I saw floating about in the, blue Sky and Twitterverse. Silk is a pretty cool library that takes in sort of these like native swipeable sheets that you're used to in the native world and brings it to the web in a React library. [44:37]
-
-So, you know, native feeling sidebars or bottom sheets or sort of like a, a, expandable bottom sheet for things like media players and stuff like that. All of that is quite difficult to do in the web world but very easy to do in the native world. And so they've created a React library and it works delightfully, like, it's very hard to tell that it's not native, which is really, really cool. [44:58]
-
-The. I guess the, the caveat is that it's not open source for anything that's commercial. So any like hobby projects that you're using or open source projects that you're using, it's free. But you need to pay around 300 euros if you want to use it in any commercial projects [45:17]
-
-**Carl:** reminds me of like sublime text, sublime merge, like the, the shareware. Please, please pay us. [45:22]
-
-## [\{transitions\} = f(state)](https://jordaneldredge.com/blog/transitions-f-of-state/)
-
-**Mark:** Jordan Eldridge, who is possibly best known for having created the React reimplementation of the Winamp music player from the good old days. wrote a post a month or two ago about transitions, RA function of state. it's not talking about the new React transitions, API, but rather kinda that mindset of viewing the contents and the logic of your component as state machines. It's kinda short, but some good thoughts there that are useful to put into practice. [45:51]
-
-## Tailwind 4, Bun, and old Macs: [A Supermarket Bag And a Truckload Of FOMO](https://blog.julik.nl/2025/03/a-little-adventure-in-modern-frontend)
-
-**Mark:** And then tossing out one more There was a very interesting article from someone who is trying to switch from using Tailwind three to Tailwind four. [45:58]
-
-I. But they were doing it on an old Mac, and as usual, I haven't used Tailwind, tailwind much myself, but apparently the latest version of Tailwind now uses a customized version of the BUN runtime to do its build steps. BUN is distributed as a native binary, and apparently the bun binary requires some of the latest CPU instructions. So it wouldn't even run on this Mac, even though it was a perfectly valid functional laptop. And so this person kind of got stuck, like, how can I even use Tailwind on this laptop when the latest version of tailwind's, compiler won't run on the laptop? And so it's well written, but also it's, just interesting to see how upgrades can cause problems sometimes. [46:47]
-
-## [Introducing Firebase Studio](https://firebase.blog/posts/2025/04/introducing-firebase-studio/)
-
-**Mo:** if you are somewhat following the world of Gen AI and the whirlwind of different tools and stuff that comes up every day some of them good, some of them not so good. There's been these sort of app builders that have been appearing, right? So things like V zero is the, is the big one that you'll probably be familiar with because of Sha Cian and, you know, the Versal ecosystem. [47:08]
-
-But you know, there's other ones like Repli lovable Dev Bolt and, and many, many more I'm sure. It's a problem that a lot of people are trying to solve, which is, you know, how can we enable non-technical people to build out apps or maybe accelerate developers to actually build them out in some sort of agent tech model. [47:25]
-
-And so, Firebase. the classic sort of toolkit that was there for mobile and front-end devs to be able to create backends without being real backend developers and needing to worry about things like infrastructure and whatnot, has thrown its hat into the ring and created Firebase studio. [47:41]
-
-So the whole idea with Firebase Studio is that it's it's kind of giving you the full stack. So, you know, Firebase already existed to help you build backends without really building backends. And so they're thinking of building on top of that. They've released this using sort of the Gemini models that Google has to allow you to also build the front end so you know, in one sort of prompt or set of prompts. [48:02]
-
-So you can generate a screen and then that goes all the way back and creates the sort of the backend for you as well in, in Firebase world, which is an interesting approach because they already have sort of a backend as a service. That people love and use quite often. And I, I still see it being used on a lot of sort of passion projects and even on some production applications. [48:22]
-
-One of the reasons I thought it was interesting to mention here was because if you look at some of the examples that they've released they don't actually, they have a lot of react examples and not as many angular examples, albeit you can use it to generate angular apps as well. And that makes me think that they're sort of coming around to this fact that it's, you know, there's a lot more react and next js open source code on the internet, which means gen AI is probably better at generating it than something like Angular. [48:49]
-
-But that's just a, that's just a take that I have and it's not grounded on any reality. So take that with a grain of salt. But that's my thought process as to why they're, showing a lot of react examples. Of course, they're showing flutter and some angular as well. So it's not like it's just react, but it's definitely interesting. [49:05]
-
-## [Gumroad is open source!](https://gumroad.gumroad.com/p/gumroad-is-now-open-source)
-
-**Carl:** maybe further afield from React and such, but Gumroad, for their 14th anniversary of being a product in the world is going open source. So they are, I guess, open sourcing their entire product which is cool. I like that. I'm confused about why, because like, you know, like fundamentally, usually people guard their source code if they're a like, functioning business that like makes revenue, you know, having the source code is a decent moat. [49:34]
-
-But yeah, it's cool. I, I like that. I like to see it. I love seeing real production code bases made open source because like, that's such a, that's such a common request that I see people asking for is like, okay, cool, I'm learning all of this, but how do I know if it's good, if it's real? [49:50]
-
-## [Automattic laid off 16% of staff](https://automattic.com/2025/04/02/restructuring-announcement/)
-
-**Carl:** And my last link also a little further afield, kind of at the intersection of our first job market section and our lightning rounds. But checking in on some of the WordPress drama that we had covered a couple months back; Automattic. The company that maintains WordPress and led by Matt of much drama, the last six months is laying off 16% of its staff. It's a little bit, this like restructuring announcement from earlier this month is a little bit goofy to me to read because it, it's, you know, it's just like why we're making changes. We've reached an important crossroads. While revenue continues to grow, we operate in a highly competitive market. It's like, well, yeah, and you also alienated your entire, like, product base and like open source ecosystem and customer base. [50:37]
-
-so just like seeing them talk about laying off one, one out of every six people who works there without talking about how, like, this was a total self own where the CEO just like burned every bridge he could find is like, alright buddy, good luck. [50:51]
-
-**Mo:** It's kind of poetic in some. [50:53]
-
-**Carl:** it would feel more like poetic justice if Matt was the one losing his job. [50:56]
-
-Not people unrelated, but Yes. Ugh. [50:59]
-
-**Mo:** But you know, I, I, I hope that other tech executives think twice and it becomes a learning lesson before they try to take open source products and monetize it in their favor when they have control over an ecosystem. I hope that people uh, think twice after this. [51:15]
-
-**Carl:** Yeah, right. I feel like this is gonna be some kind of business case study somewhere. So that's, you know, hopefully [51:20]
-
-**Mo:** I hope he also loses any bonuses that he was banking on getting this year [51:24]
-
-**Carl:** anyway, That's all we got for you this month. Thank you so much for joining us. We will be back on the last Wednesday of the month, next month here in the live stage or back in your podcast feed just as soon as we can. [51:34]
-
-We gather sources from this we in React Bites, dev React status, next JS Weekly, the React JS subreddit here in Reactiflux, and those direct from those publishing articles. If you see anything newsworthy, definitely let us know in the Tech News and reads channel here in Reactiflux or shoot me an email at hello@reactiveflux.com. [51:52]
-
-I read everything that comes in, so definitely send me something. This is a show that you value and would like to support. Best way to do so is by submitting a review. It would be cool if it was, you know, five stars, but whatever, any feedback is appreciated and definitely tell your friends and coworkers about it if you like. [52:09]
-
-Cool. Thank you so much. See you next month. [52:11]
-
-**Mo:** See you all next month.
diff --git a/src/transcripts/tmir-2025-05.md b/src/transcripts/tmir-2025-05.md
deleted file mode 100644
index 7afb0b8..0000000
--- a/src/transcripts/tmir-2025-05.md
+++ /dev/null
@@ -1,526 +0,0 @@
----
-title: "TMiR 2025-05: Dan explains RSC. Remix v3? React core team WIP?"
-date: 2025-05-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:54](#quick-hits)] Quick hits
- - [[00:57](#job-market-fred-data-layoffsfyi-trueupio)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
- - [[01:19](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:20](#react-summit-june-13-17-amsterdam-nl)] [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
- - [[01:57](#render-atl-june-11-13-atlanta-ga-usa)] [Render ATL](https://www.renderatl.com/) June 11-13 Atlanta, GA, USA
-- [[02:12](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
-- [[02:59](#new-releases)] New releases
- - [[03:01](#tanstackdb)] [TanStack/db](https://github.com/TanStack/db)
- - [[05:28](#legend-list-10-released)] [Legend List 1.0 released](https://bsky.app/profile/jayz.us/post/3lni5ofbuvs2s)
- - [[06:48](#redux-toolkit-v280-and-bugfixes-after)] [Redux Toolkit v2.8.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.8.0) (and bugfixes after)
- - [[07:37](#mui-v71)] [MUI v7.1](https://github.com/mui/material-ui/releases/tag/v7.1.0)
- - [[08:30](#jest-has-a-v30-beta3-4-out-first-alpha-of-it-was-published-october-2023)] Jest has a v30 [beta.3](https://github.com/jestjs/jest/releases/tag/v30.0.0-beta.3) \+ 4 out. [First alpha](https://github.com/jestjs/jest/releases/tag/v30.0.0-alpha.1) of it was published October 2023
- - [[09:11](#zustand-505-jotai-2124-and-5)] [Zustand 5.0.5](https://github.com/pmndrs/zustand/releases), [Jotai 2.12.4 and .5](https://github.com/pmndrs/jotai/releases)
- - [[09:17](#devstore-deprecated)] [devstore deprecated](https://x.com/jotaijs/status/1919778234037878919)
- - [[09:28](#radix-has-new-primitives-onetimepasswordfield-and-passwordtogglefield)] [Radix](https://www.radix-ui.com/primitives/docs/overview/releases) has new primitives: [OneTimePasswordField](https://www.radix-ui.com/primitives/docs/components/one-time-password-field) and [PasswordToggleField](https://www.radix-ui.com/primitives/docs/components/password-toggle-field)
- - [[09:38](#ant-design-525)] [Ant Design 5.25](https://ant.design/changelog#5250)
- - [[10:02](#react-aria-may-19-2025-release)] [React Aria May 19, 2025 release](https://react-spectrum.adobe.com/releases/2025-05-19.html)
- - [[10:21](#relay-19-with-react-19-support)] [Relay 19](https://github.com/facebook/relay/releases/tag/v19.0.0) with React 19 support
- - [[10:29](#storybook-9)] [Storybook 9](https://github.com/storybookjs/storybook/releases/tag/v9.0.0)
-- [[10:38](#main-content)] Main Content
- - [[10:45](#expo-sdk-53-release)] [Expo SDK 53 release](https://expo.dev/changelog/sdk-53)
- - [[16:01](#packagejson-imports-support)] [Package.json imports support](https://x.com/satya164/status/1916095938604548366)
- - [[17:32](#react-router-rsc-preview-and-other-rsc-topics)] [React Router RSC preview](https://remix.run/blog/rsc-preview) and other RSC topics:
- - [[20:49](#vite-community-pr-to-add-rsc-support)] [Vite community PR to add RSC support](https://github.com/facebook/react/pull/33152)
- - [[21:33](#leerobs-list-of-other-rsc-explorations)] [Leerob’s list of other RSC explorations](https://bsky.app/profile/leerob.com/post/3lo4l2rmy7k2b)
- - [[21:44](#more-dan-posts-like-static-as-a-server-and-one-roundtrip-per-navigation)] More Dan posts, like [Static as a Server](https://overreacted.io/static-as-a-server/) and [One Roundtrip Per Navigation](https://overreacted.io/one-roundtrip-per-navigation/)
- - [[22:33](#redwoodsdks-your-react-framework-feels-broken)] RedwoodSDK’s [“Your React Framework Feels Broken”](https://rwsdk.com/blog/your-react-meta-framework-feels-broken)
- - [[23:20](#remix-v3-announcement)] [Remix v3 announcement](https://remix.run/blog/wake-up-remix)
- - [[26:04](#discussion-between-evan-you-and-michael-jackson-about-bundling-hmr-approach-and-tradeoffs)] [Discussion between Evan You and Michael Jackson about bundling / HMR approach and tradeoffs](https://x.com/mjackson/status/1928297364726632499)
- - [[29:56](#react-core-wip)] React Core WIP
- - [[30:08](#react-mcp-server)] [React MCP server](https://github.com/facebook/react/tree/main/compiler/packages/react-mcp-server/src)
- - [[34:08](#concurrent-store-skeleton-pr-a-concurrent-compatible-integration-for-external-libraries)] [“Concurrent store” skeleton PR](https://github.com/facebook/react/pull/33215) a concurrent-compatible integration for external libraries
- - [[35:49](#suspenselist-being-worked-on-again)] [\ being worked on again](https://github.com/search?q=repo%3Afacebook%2Freact%20SuspenseList&type=pullrequests&s=created&o=desc)
- - [[36:29](#compiler-integrations-with-swc-and-oxc)] Compiler integrations with [SWC](https://github.com/swc-project/swc/pull/10475) and [OXC](https://github.com/oxc-project/oxc/issues/10048)
- - [[37:19](#apple-app-store-epic-games-saga-30-apple-cut-ruled-unlawful-in-the-us)] Apple App Store Epic Games Saga 30% [Apple cut ruled unlawful in the US](https://www.macrumors.com/2025/05/19/epic-asks-judge-apple-approve-fortnite-app-store/)
- - [[40:59](#next-reducing-vercel-mentions-in-docs)] [Next reducing Vercel mentions in docs](https://github.com/vercel/next.js/pull/78557)
-- [[45:52](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[45:54](#shared-element-transitions-in-reanimated)] [Shared Element Transitions in Reanimated](https://github.com/software-mansion/react-native-reanimated/pull/7466)
- - [[46:56](#v8-explicit-compiler-hints)] [V8 explicit compiler hints](https://v8.dev/blog/explicit-compile-hints)
- - [[48:05](#ts-native-previews-usable-build-of-the-go-based-compiler)] [TS Native Previews](https://devblogs.microsoft.com/typescript/announcing-typescript-native-previews/?s=33) (usable build of the Go-based compiler)
- - [[48:26](#vite-rolldown-preview-build)] [Vite \+ Rolldown preview build](https://voidzero.dev/posts/announcing-rolldown-vite)
- - [[49:10](#seeded-pseudo-random-number-proposal-advances-to-stage-2)] [Seeded pseudo-random number proposal advances to Stage 2](https://bsky.app/profile/did:plc:w227epg3attqnssfdkx6ex6a/post/3lqcugizbls2g)
- - [[50:34](#3-layer-data-data-fetching-for-complex-react-apps-rscs-react-query-optimistic-ui)] [3-layer data data fetching for complex React apps](https://www.trevorlasn.com/blog/fetching-data-for-complex-next-and-react-apps) (RSCs, React Query, optimistic UI)
- - [[51:05](#johannes-schickling-announces-livestore-reactive-sqlite-sync-layer)] Johannes Schickling announces [LiveStore (reactive SQLite \+ sync layer)](https://bsky.app/profile/schickling.dev/post/3lq5gucxsj22a)
-- [[53:02](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the May edition of this month in React, where we recap and digest the ever evolving react and web ecosystem. We are coming to you live from Reactiflux, the place for professional react developers, and we are supported by infinite red uh, consultancy that exclusively works in React Native. [00:00]
-
-I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like this and build other tools to keep the community operating. [00:18]
-
-**Mark:** Hi, I'm Mark. My day job is with Replay io, where we're building a time traveling debugger and trying to find ways to make AI chat bots smarter with time travel. And also I spend a lot of time working on redux and ranting about the React teams communication. [00:28]
-
-**Mo:** my name is. I had the mobile team at Theodo and I'm an active member of the React Native community, a core contributor, and I organized the React Native London Meetup and conference. [00:42]
-
-## Quick hits
-
-**Carl:** Quick job market news new releases. [00:54]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
-
-**Carl:** Generally it looks like this Fred data source that looks at Indeed, I'm starting to doubt whether it's an accurate reflection of the current market. It's just been continuously trending down which I think may just indicate that people are hiring fewer software engineers on Indeed, since that's the only source of data for it. [00:57]
-
-Drew up dot iOS job trends shows a different direction. It's been a little bit better, but you know, it's not categorically different. [01:11]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** upcoming conferences. [01:19]
-
-## [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
-
-**Carl:** We've got React Summit in about two weeks, so if you are looking for something to do that's gonna be June 13th through 17th in Amsterdam. In Netherlands, [01:20]
-
-**Mark:** as usual, they're doing one day of an actual in-person conference, and then there's a remote only streaming set of talks. I think like the, the following Monday or something. I'll be speaking there in person. If you've heard me I said I've been doing routine. If you've heard me talking about things like, you know, the community misunderstanding reacts development or the React team having opinions about frameworks and stuff, I will be talking about that sort of thing, live on the main stage. [01:29]
-
-**Carl:** Very nice. Excellent. Well, I will be at a different conference. [01:54]
-
-## [Render ATL](https://www.renderatl.com/) June 11-13 Atlanta, GA, USA
-
-**Carl:** There's also gonna be render Atlanta June 11th through 13th. they seem to have really good vibes. It looks like it's pretty well attended in general. So this is my first time attending the event, but yeah, I'll, I'll be there June 11th through 13th. [01:57]
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-**Carl:** We are sponsored by Infinite Red. They are an expert react native consultancy that's been around since 2015. So very long running. They do a lot for the ecosystem, including hosting podcasts. The hosting, the largest React native podcast hosting, I believe the largest or organizing, I believe the largest React native specific conference in the us. [02:12]
-
-And they only do React native and have built over 75 apps for companies ranging from startups to the biggest in the world. And they generally will work with a team in order to develop expertise, you know, within that team rather than just being a airdrop in Build the Thing and leave kind of consultancy. [02:34]
-
-So if you are working at a company looking to develop some React native expertise, definitely reach out to them. they're good people. [02:52]
-
-## New releases
-
-**Carl:** Into some new releases. [02:59]
-
-## [TanStack/db](https://github.com/TanStack/db)
-
-**Carl:** a new TanStack sync engine that looks like it ties in pretty well with TanStack Query. I haven't played with this, but it looks pretty interesting. [03:01]
-
-**Mark:** Looks like Kyle Matthews is working on it. Kyle's probably best known as having created Gatsby, but he's currently working at Electric sql, which, which is a syn engine company, so probably making use of some of his expertise there. I. [03:10]
-
-**Carl:** Yeah. Very cool. Definitely nice to see that kind of expertise being brought a little more broadly into some other projects. I think local first and like syn engine kind of stuff seems like. A very powerful area of exploration right now. I don't think we really know what it's gonna shake out to. But yeah, I've seen a couple of apps developed in this way over the years and they always, it just strikes me as a really powerful way to do it. [03:23]
-
-I think a great example of Local First is actually Gmail. They've been very local first forever in a mobile app, you know, you can just functionally use it and then you come back online and it actually executes all the things you did. That's just generally how I think most apps should work. So seeing a lot more exploration and how to support that with different types of tools definitely looks really cool. [03:47]
-
-And then coupling that, tying it very closely in with the query engine as it appears that this Tan Stack DB does. Definitely makes a ton of sense. Definitely really interesting there. [04:08]
-
-**Mo:** It's quite interesting 'cause I was having a chat with a fellow mobile developer just a few days ago, and he was telling me how he uses TanStack Query as like really like the central data store. Of his application on a React native app. But then the challenge is that things working locally is always a real pain and things working offline is a real pain because taking that either means you have to just like store the entire cache inside of like adjacent blob living somewhere on the device disc. [04:19]
-
-It's quite messy and it, doesn't follow those like asset principles that you would want to make sure that the data's intact and there's no sort of conflicts when you do reconnect. This looks pretty cool. I know it's only for react at this point, as far as I can tell, and it doesn't necessarily seem to be targeting React native support, but I think a lot of people in the React native ecosystem would probably love to use something like this so that these things are just synced onto a SQL like DB somewhere on the phone, which is kind of a way to do local first stops in React native. [04:50]
-
-**Carl:** network is so much more unpredictable on a phone than it is on, on the web. So yeah, that, that makes sense. That's maybe a little underwhelming, but it's not targeting React native support. [05:18]
-
-## [Legend List 1.0 released](https://bsky.app/profile/jayz.us/post/3lni5ofbuvs2s)
-
-**Carl:** Mo you want to tell us about Legend List? [05:28]
-
-**Mo:** Yes. So this is super exciting because legend list, for those of you who've been following along with the podcast for the last few months has been something that we've been talking about on and off, but it's been sort of in that alpha beta phase. So Jay Meistrich, he used to be a game developer, so I say that because. [05:29]
-
-Game development is super, super hard and you optimize for performance as much as you can. So he has that background and worked on a bunch of sort of low level OS stuff for a while. And so he's been a active member of the React native community. Made a library that was the most performant, well by his metrics, one of the most performant state management tools called Legend State. And and so Legend List is sort of, taking that experience and putting it into React native lists, which is one of the most challenging parts of the React native sort of development workflows, making performance lists. [05:45]
-
-And it is by far on all accounts of different people testing it in the ecosystem. The fastest React native list implementation. And it is a hundred percent js. It is very stable. At this stage. I know a lot of actual production apps that have been using it before 1.0. And so I would highly recommend you, you'd give it a try. [06:14]
-
-It's pretty straightforward to replace any existing list that you have, whether that's flat list or flash list. [06:31]
-
-**Carl:** Very cool. Yeah. List performance while like rapidly scrolling is one of those really visible things in an app, so definitely, definitely really cool to see a great, low level primitive for use there. [06:36]
-
-## [Redux Toolkit v2.8.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.8.0) (and bugfixes after)
-
-**Mark:** If you've been listening for a while, you've also heard me ranting about the complexities of publishing JavaScript packages and ESM and CommonJS compatibility. We shipped Redux Toolkit 2.8, which was primarily intended to improve our compatibility with the Metro Bundler and React Native. It did that and then it promptly started breaking tests with just environment js dumb due to reasons. we shipped a fix for that and then a process we act, we found out that the release had also ended up messing up some of our bundling so that the different and things weren't getting shaken out properly. And oops, our nested imports were actually like three times as big as they were supposed to be, so we had to fix that. So RTK 2 8 2 is out, and if you're going to upgrade, please use that one. [06:48]
-
-**Carl:** For sure. Yeah, we've got a bunch of smaller releases or like beta stuff, so I'm just gonna kind of fly through some of these. [07:30]
-
-## [MUI v7.1](https://github.com/mui/material-ui/releases/tag/v7.1.0)
-
-**Carl:** Material UI has version 7.1 out. It looks like it's mostly bug fixes. We talked about the new like slot pattern that they introduced in 7.0 in the last episode. Interestingly, they also talk about Tailwind V four support, which is a little bit surprising for a component library of this complexity. [07:37]
-
-I don't know exactly what Tailwind support means in this context, but it does appear that you can use a styled engine provider with a, like CSS layer not quite clear on whether this is doing all of the compile time tailwind optimization kind of stuff, or. Right. The implementation details here are not totally clear to me from the release notes but definitely interesting. [07:55]
-
-Yeah. I know that Tailwind V four support has been kind of a sticking point for some projects, so it's interesting to see such a large and complex style library take advantage of. It [08:20]
-
-## Jest has a v30 [beta.3](https://github.com/jestjs/jest/releases/tag/v30.0.0-beta.3) \+ 4 out. [First alpha](https://github.com/jestjs/jest/releases/tag/v30.0.0-alpha.1) of it was published October 2023
-
-**Carl:** Jest has a new V 30 beta beta three. I was checking the release notes for it and alpha one of version 30 was first published in October of 2023. [08:30]
-
-So this has been a long time coming. It looks like beta three introduced a lot more new things than the re the other alphas or, you know, many more fixes and whatever. So yeah, I don't know exactly what to think about that, Jest has been generally a kind of finished project in my experience. But yeah, they've got a new version turning its way through. [08:43]
-
-Although with two years, a year and a half since the first Alpha, I'm not sure if this is gonna be released anytime soon. Mark, tell us about Zustand and Jotai. [09:03]
-
-## [Zustand 5.0.5](https://github.com/pmndrs/zustand/releases), [Jotai 2.12.4 and .5](https://github.com/pmndrs/jotai/releases)
-
-**Mark:** Just a couple minor bug fix releases. Probably not in much meaningful, but you know, always worth looking at updates. [09:11]
-
-## [devstore deprecated](https://x.com/jotaijs/status/1919778234037878919)
-
-**Mark:** Jotai is also switching from whatever previous standalone dev tool support they had to their own built-in dev tools. [09:17]
-
-**Carl:** Yeah. Deprecating whatever internal tooling they had for that. [09:25]
-
-## [Radix](https://www.radix-ui.com/primitives/docs/overview/releases) has new primitives: [OneTimePasswordField](https://www.radix-ui.com/primitives/docs/components/one-time-password-field) and [PasswordToggleField](https://www.radix-ui.com/primitives/docs/components/password-toggle-field)
-
-**Carl:** Radix has a new release that has a couple of new primitives if you're using that. It's got a generally password adjacent. There's a one time password field and a password toggle field, so neat. [09:28]
-
-## [Ant Design 5.25](https://ant.design/changelog#5250)
-
-**Carl:** Ant design also has a new release with a, a new. [09:38]
-
-Timer statistic component. I've never used ant design. It was interesting to me. Well, I was looking to read more of the, you know, release details on this, but an awful lot of the contribution is in Chinese and I do not read Chinese. I know that's, been a bit of a bifurcation in the React ecosystem is, you know, language barriers are challenging. [09:41]
-
-they got a new thing. It looks cool. [10:00]
-
-## [React Aria May 19, 2025 release](https://react-spectrum.adobe.com/releases/2025-05-19.html)
-
-**Carl:** React Aria has a new dated release, you know, they don't do versions, they do dates. So this is the May 19th release. It looks like it's pretty much just small bug fixes, although they do also say they have support for the React 19 ref cleanup call that was introduced. [10:02]
-
-So yeah. Neat. Cool. [10:19]
-
-## [Relay 19](https://github.com/facebook/relay/releases/tag/v19.0.0) with React 19 support
-
-**Mark:** relay GraphQL version 19 is out. It's got support for react 19 as well as they've been working on their documentation. [10:21]
-
-## [Storybook 9](https://github.com/storybookjs/storybook/releases/tag/v9.0.0)
-
-**Mark:** And then storybook version nine is out, and it looks like they've made a really big effort to try to shrink the bundle size of their own tooling. [10:29]
-
-**Carl:** Cool. Alright, so that's all the new releases. [10:36]
-
-## Main Content
-
-**Carl:** We got so many small ones this month into our main content. Mo let's start off with expo. [10:38]
-
-## [Expo SDK 53 release](https://expo.dev/changelog/sdk-53)
-
-**Mo:** Cool. So we have a major release of a new expos DK. So expos, DK 53 is out, and this has been under the, the, the works for a very. Very long time. So Expo usually historically would release a version of an SDK with every React native release that would come out. So, you know, react native dot 72 comes out. [10:45]
-
-And then SDK version 40. I can't remember the corresponding, but you get the point. Every single version is tied to a specific SDK version. But as the React native team has been releasing more frequently the expo team found that it was actually probably a good time to stop tying those things together and sort of bunch some of these SDK releases into larger releases so that they can make. changes to the actual SDKs rather than having to keep up with React native and the versions that are being released every few months. So SDK 53 is a big one primarily because now the new architecture is default everywhere. So if you were paying attention, the last release that they had, the new architecture was default for new projects. [11:05]
-
-What they've now done is they set the new architecture even for existing projects when you update test SDK 53. And this fits with sort of the larger push that the React Native Core team is doing to push people onto the new architecture. And so React native version 79, as an example, has the same thing where, you know, existing apps will also be in the new architecture by default, and you need to opt out. [11:45]
-
-And as of yesterday as well meta announced at app js that they're going to be freezing the old architecture. So they're not really gonna be doing and adding any new features into the new architecture either. So very much going down the deprecation path with eventual sort of removal from React Native Core, which is kind of as we would expect it. [12:06]
-
-Other things to mention. So. Android developers will know about a requirement that came in to the Android ecosystem a few years ago called Edge to Edge support, which meant that your app needs to cover the full sort of corners and notches of an app of an Android phone. And this was sort of opt in for the longest time, but as of the next Android version that's soon to be released, I believe it's Android 16, edge to Edge support will be required. [12:23]
-
-On all apps. So if you submit an app that doesn't have Edge, edge to Edge support, they will reject it. So a bunch of people in the community have been working on getting this up and running because it's not trivial, it's actually quite complicated. So Zoom Tech who's well known in the React native ecosystem's, been working on this. [12:47]
-
-So he's worked with the expo team to get that implemented by default in SDK 53. So once you update to SDK 53, your app will already have Edge to Edge support. This is not the case yet for React Native Core. So if you have a non expo app, that won't necessarily be the case and you're gonna need to add it in manually yourself. [13:02]
-
-The goal is that eventually this will be merged and upstreamed into React Native Core anyway, and will just be handled as a core part of, RNs functionality. [13:19]
-
-**Carl:** That makes sense. So I'm thinking of like instead of safe area, it's gotta be edge to edge. I. [13:27]
-
-**Mo:** It's adjacent to that, but not directly related. So safe area views in react native, typically, historically were more of an iOS thing because iOS introduced the notch and then they introduced the dynamic island. So that safe area view was for that more than anything. 'cause Android app devices typically were a little bit more uniform, albeit not the exact same. [13:31]
-
-And then. Android devices followed suit with that. Edge to edge is more sort of how the app interacts underneath the notch or like in the corners of your, of your, of your screen. So, you know, you have a bunch of things in the Android world, like curved screens, and you have screens that, you know, have a a rounding on the corners and so on and so forth. [13:51]
-
-And edge to edge support is to basically make sure that it covers the full sort of portions of that which wasn't there by default. it's, I'm not an Android developer, so it's not necessarily my specialty, but I do know that it is a requirement there, and I think it's certain Android screens can be a little wacky and edge stage support is necessary to make sure that things are behaving correctly on all Android devices. [14:12]
-
-I. A few other things to mention with Expo SDK 53. Background tasks. If anyone's been building rack native apps since the beginning, he'll know that doing background tasks is really, really hard and making sure that they actually execute and you have some level of confidence that things are gonna be run in the background when your app's not sort of front and center in the foreground of, of the user's phone. [14:33]
-
-It's challenging. So Expo actually like went through this. They had a background tasks module. They went through just re-architecting it all because it was fundamentally flawed in the way that it was trying to tackle the problem. So they're actually using they, they've released the expo background task module and it uses sort of the up-to-date latest APIs on both Android and iOS. [14:54]
-
-And so they recommend you use this for different things, like let's say if you need to download data in the background. Or if you need to run over the air updates, so you wanna check, see if there's over the updates, and then actually download it in the background. You can do that, or, you know, garbage cleanup and so on and so forth. [15:12]
-
-If you need to do that in the background of your app. So this is quite useful. It's one of those things that happens behind the scenes, but I think is incredibly important to make an app really perform and, and feel like a native app would. Another sort of minor thing is expo audio. [15:27]
-
-So there's an expo audio update within this release. And expo audio is generally the replacement of Expo av, but the audio portion of that library. So that library was quite complicated And so they've split it off into expo audio and expo video and expo video came first. [15:41]
-
-Whilst they were working on audio, and now audio is, being released at this point, which is quite cool. [15:57]
-
-## [Package.json imports support](https://x.com/satya164/status/1916095938604548366)
-
-**Mo:** Last point on SDK 53, that's kind of adjacent to SDK 53, more of a React native thing, but it's part of SDK 53 as well is package json import support, which is great because it's oftentimes quite a big in React native projects with. [16:01]
-
-Babel and TypeScript working together for these package imports. So now React native has this feature built in, so you just define imports within your package js. You update your ts config to just resolve package JS imports and that's it. Which is a really good standardization. So, if you're using the older way of doing sort of aliases for your imports go ahead and change that because I think it'll make your life a lot easier in the long run. [16:15]
-
-**Mark:** I do kind of object to the use of the word just in that sentence. [16:39]
-
-that's basically what we were trying to, trying to get compatibility for with, our RTK 2.8 release. [16:43]
-
-**Carl:** I'm glad to see this standardization rolling out. I remembered this coming through in node. I went and looked it up. It was originally released in node 14, which came out April, 2020. So this has been a pretty decent long time coming though, you know? a lot of ducks to get in a row to make it work. [16:48]
-
-But definitely really nice to have alias resolution happen just from package. Jason, instead of needing to, I just, I can just remember all of the various pain I've had with like, trying to keep the aliases between like web pack and Babel and jest and storybook in, you know, all of the different parallel configuration that each needed, its own different way of configuring aliases. [17:05]
-
-So I love that standardization around that is settling out. [17:29]
-
-## [React Router RSC preview](https://remix.run/blog/rsc-preview) and other RSC topics:
-
-**Mark:** we've got a bunch of different things happening related to server components this month. Probably the biggest one is that React Router has announced a server components preview. this is probably a big deal for multiple reasons. We've already had at least one other tool parcel put out what it considers like a, a fully production ready release of server component support. [17:32]
-
-So we, we are getting more tools other than just next supporting it. But in terms of usage, react router, you know, even if you're, and you're just looking at the client side functionality has always been one of the biggest packages in the ecosystem. And part of the point of the whole React router, remix, react router back and forth was to try to make more of those pieces available in React router itself so that you could just turn on the framework mode flag and start to get server side rendering bundling type support. [17:55]
-
-And so having RSC support there. Is really going to be, from my perspective, the first widely available usage outside of next. So that feels like a big deal. It's also a big deal because I think most of our understanding of how to use server components has been very heavily shaped by the fact that next was the only real implementation. And so there's sort of been this, well, the way that the next app router works must be the, the way that server components have to work. [18:26]
-
-And instead here we see that the React router team has made some very different implementation choices in how you use server components. So in particular, they've got the ability to actually return server components as individual fields from your loader functions. So you can return some, data. You can return some components, and then your actual component on the client side just receives the loader data and you receive the elements much like you would props dot children, and you just include that in the output. They've also got some more options for server components, routes, and intermixing them support for server functions and then still doing things on the client side. So this looks like a pretty big deal release if you want to try that out, sort of adjacent to that. one of the complexities for server components in general is that they require tight integration with a bundler. And so the React team had specifically most of their initial work was around implementing integration for Webpac because Webpac is so widely used across ecosystem. And they've repeatedly stated that Vite's internal architecture just did not support the proper module graph handling to make real server components support possible. [19:01]
-
-so the, the React team has tried to keep the packages for the Bundler integrations in the React repo so that they can more easily iterate on changes to the core functionality versus what's specific to the bundlers. Like there isn't really like, kinda like a, a publicly defined API for that sort of thing, easier to all have it in one repo. But that's also meant that they didn't have the expertise or knowledge to do the Vite integration properly. [20:24]
-
-## [Vite community PR to add RSC support](https://github.com/facebook/react/pull/33152)
-
-**Mark:** So there is now a PR from the community to try to add, quote, unquote, proper Vite and RSC integration. And there's been some back and forth on that. Don't know how long it'll take to get that landed, but that does seem like a fairly big step. [20:49]
-
-**Carl:** Yeah, it definitely does, right? The lack of public API and general documentation for this is definitely, we've talked a little bit about how that's a pretty big barrier for people looking to explore this. You really have to reverse engineer it yourself if you wanna look into it. Seriously. [21:04]
-
-**Mark:** so at this point, we've got Next has been out for a while. Parcel just released its own quote, production ready, RSC support. We've got React Router coming out with a preview. So it, the, the ecosystem is starting to flesh out. [21:19]
-
-## [Leerob’s list of other RSC explorations](https://bsky.app/profile/leerob.com/post/3lo4l2rmy7k2b)
-
-**Mark:** Lee Robinson from CEL has been collecting a list of some different frameworks that are experimenting with RSE support in various alpha and, and, you know, test preview approaches. [21:33]
-
-## More Dan posts, like [Static as a Server](https://overreacted.io/static-as-a-server/) and [One Roundtrip Per Navigation](https://overreacted.io/one-roundtrip-per-navigation/)
-
-**Mark:** meanwhile Dan Abramov has cranked out several more blog posts trying to. Pitch the mental model of es. A couple folks have said that, you know, he's kind of hitting the same theme from different ways he's basically trained to start from different mental models and work backwards to, "and here's how RSCs address all these different problems." I think he actually put out four different posts this month. Two in particular one talks about how RSCs allow you to do static site generation and don't even require a, like a running application server to do the work. As well as how rses help handle the need to fetch multiple different pieces of data in one round trip. So there's those couple posts plus a couple others. So, as usual, worth reading, [21:44]
-
-## RedwoodSDK’s [“Your React Framework Feels Broken”](https://rwsdk.com/blog/your-react-meta-framework-feels-broken)
-
-**Mark:** One other sort of related post. So we previously mentioned that Redwood pivoted from their previous, very GraphQL based framework and they, they deprecated or archived that framework entirely, and they've come out with a new tool called Redwood, SDK which is based on CloudFlare and RSCs. And they, they put out a post called your React Meta Framework Feels Broken, which is both a, a kind of a critique of other frameworks as well as a sales pitch for their particular approach to dealing with server components. So we really are seeing different parts of the ecosystem trying to figure out how to actually make use of server components and ship those as actual features. [22:33]
-
-## [Remix v3 announcement](https://remix.run/blog/wake-up-remix)
-
-**Carl:** Well, yeah, that leads us sort of into new remix. They have released, or they've announced a version three which is somewhat surprising to me because I had understood it as a deprecated brand that was being merged back into React Router. But actually I, you know, reached out to them to be like, huh. And, you know, reached out in the remix Discord just to express confusion. And I had my attention directed back to the blog post that was released around when they actually did that talk at React Con last year revealing that they would be merging remix back into React router. And they, they were very clear about this from the beginning. [23:20]
-
-I don't really remember it in the talk and I'm not sure that I went back and read the announcement blog post after hearing the talk. So that may have been why I missed this. But yeah, they do talk about how this is, you know, that was their plan. They were going to re remix was a, a Fork of React router, I guess. They did a big thing with V two and merged that back into React router V seven. And in that blog post they talk about how V three is gonna be something totally brand new, but it will be coming, it was in progress. So it's here and remix is not dead despite reports to the contrary. [24:03]
-
-**Mark:** Or at least it's, it's far enough long that they were actually, ready to announce it. I don't know if any of this is available or visible in any way yet, but at least they're saying we're, we're working on it. [24:35]
-
-**Carl:** Yeah, true. [24:45]
-
-**Mark:** So, yeah, this is. it's confusing. I've seen a lot of people pushing back on, you know, like there's already been lots of people complaining over the years about the various React Rider major versions and changes and, you know, Ryan and Michael can't seem to settle on a single API design. I, I will say that the bouncing back and forth is kind of confusing. And then having a version three of an existing package that seems to throw all the existing, previous pieces out the window, is also kind of confusing. You can sort of make the parallel between the angular one or angular JS one versus angular two changeover that happened like a decade ago. [24:46]
-
-The general sales pitch, looking at the announcement blog post and some of the comments by Ryan and Michael on Twitter. So. They're, taking inspiration from, you know, tools like Rails and Express and whatever. You know, , they're sort of trying to apply like best lessons learned from all the other tools out there. [25:29]
-
-They really seem to be, want, seem to, want to go for simplicity and a non bundling approach. Like they seem to want their tool to minimize the number of actual dependencies that it needs to run. And they want to avoid having a bundling step in both development and production. [25:44]
-
-## [Discussion between Evan You and Michael Jackson about bundling / HMR approach and tradeoffs](https://x.com/mjackson/status/1928297364726632499)
-
-**Mark:** In fact there was a, a conversation between Evan Yu from, you know, from V and View who is saying that, you know, modern apps really need HMR, they need bundling even in development. [26:04]
-
-That's why, you know, that's part of why VIT is redoing its internals. And Michael replied and said. Yeah, we are, we, we want to minimize the number of tools that are involved. We want to minimize the number of transformation steps. We want things to be able to run without needing to do a bunch of compilation. And we're actually not going to ship HMR, we are going to rely on page reloads in Dev, and we think we can make it fast and work. [26:15]
-
-So they clearly have a vision, it's definitely a bit of a zigzag from where the ecosystem has gone over the years. One of the other interesting points is that it's not even going to use React as the UI layer. It's going to use Preact and in fact, apparently it's going to use a fork of Preact so that they can do some additional customizations. I don't have any additional details on what those customizations will be, but that's the direction they're going. I think, check me in this Jason Miller, who originally created Preact also now works at Shopify, right? [26:40]
-
-**Carl:** That sounds right to me. [27:16]
-
-**Mark:** So both, you know, Ryan and Michael, you know, like Remix got bought by Shopify a couple years ago and Jason Miller is there. So that, that presumably makes it easier for them to potentially collaborate on some of that work. I. [27:17]
-
-**Carl:** Yes, his Twitter bio lists him as platform developer experience at Shopify. So, right, like that job title is exactly this kind of work, like making developer tools and frameworks easier to use. So interesting [27:31]
-
-**Mark:** One of the other bullet points was they, they want to have an emphasis on LLM model based development. Ryan has made some comments recently that he's using LLMs in his day-to-day work, and it's helping to make him more productive. And I think I saw him mention that like the first line of the draft new docs for this version three is "disregard all previous remix versions" as an instruction. [27:46]
-
-So I, I don't know what all they have in mind there other than, being able to organize the docs in such a way that it's LM friendly, but it's something that they have in mind. So no ETA on when any of this will be available. But given how influential React Rider and remix have been, this is certainly something to keep an eye on. [28:13]
-
-**Mo:** there's sort of two thoughts on the, like the LLM friendliness that stands out to me. The first one is, ironically, I think by naming this remix, they've actually shot themselves a little bit in the foot because it's gonna be a fun challenge trying to teach an LLM how to disregard a version two versus version three documentation or stack overflow question that has been trained on, [28:34]
-
-**Carl:** That's actually a really good point. [28:55]
-
-**Mo:** I do wonder if inherently by building on top of web APIs and like staying as close, which, which has kind of been the philosophy with remix, old remix slash react router anyway, by trying to stick to web APIs and standardized sort of W3C primitive, so to speak, that are so well defined in terms of documentation, more so than probably anything else on the web. [28:57]
-
-Plus them adding some good documentation that is LLM friendly in very, very loose air quotes. If that just makes it a little bit more predictable, because I feel like. Having gone through a lot of the W3C docs, it is so well structured and so logical. Obviously it's quite convoluted a lot of times for people who aren't used to it, but it's, it's very like organizationally structured and I wonder if that can help an LLM understand it better than anything else. [29:20]
-
-But that's just a, that's just a personal guess. Could be very wrong. [29:45]
-
-**Carl:** Yeah. Well, I was gonna say that kind of leads us into our next topic, which is react core work in progress. [29:49]
-
-## React Core WIP
-
-**Carl:** And one thing that they have checked into the repo that I, I don't think has been really discussed or publicized anywhere, is they have a MCP server work in progress. [29:56]
-
-## [React MCP server](https://github.com/facebook/react/tree/main/compiler/packages/react-mcp-server/src)
-
-**Carl:** And so MCP is model context protocol, I believe. It's basically a generally standardized way of authoring tools for LLMs to make use of. I think this react core MCP server is mostly around the compiler. So Lauren has done a lot of work on the compiler and is now doing, it looks like some work on this MCP server. I don't really have a great grasp of what MCP servers are good at, but as far as like tools that LLMs can take advantage of, like sure. Having your IDE be able, your, you know, the LLM and your IDE to query, react, to say, please run this through the compiler and tell, you know, check the performance optimization, see if it's better than it, you know, this other attempt that seems interesting and potentially useful in a, relatively limited capacity, but connecting it back to the remix v3 and LLM friendliness, I could imagine a world where like there's an MCP server that looks up documentation for your specific version that you have installed. [30:08]
-
-I don't know if that's, you know, a direction that they're going to explore, but that def, that sounds plausibly workable to me. I don't know. That's interesting. [31:13]
-
-**Mo:** specifically like an MCP server. Is is more for the LLM to be able to externally call tools rather than just generating text. So it gives it like a way to interact with the outside world. And I guess going through the code of this specific MCP server they've defined a few different tools to compile with the React compiler. [31:21]
-
-If you give it a set of code basically but also then run performance tests. And sort of go through this process of assessing what, the LCP is, I-N-P-C-L-S, and also the core web vitals. And so looking through the actual source code, it seems to me what they kind of want you to be able to do is to use the, use this MCP server to basically compile some of your code, open up a browser and run core web vital scores. [31:43]
-
-Run the react compiler, see if it improves it, and then sort of do that in a loop, almost in an age agentic fashion, so that you can optimize a react component until it's kind of at a state where things are performance, as performance as they get. So it's almost like write your react component. It's fine if it's crap, and then leave it to the model to go in and optimize. [32:09]
-
-Measure, optimize, measure, optimize until it's at a state where, things are working as expected and is as performing as it gets. [32:29]
-
-**Carl:** Yeah. There's also some mark, I think this is more of a you question, but they've got a skeleton PR for a concurrent store. I. [32:35]
-
-**Mark:** Yeah. So this is a topic that's been discussed for a while. So one of the big limitations that limitations thus far around suspense and concurrent rendering and transitions has been that React needs to own the state in order to be able to postpone or interrupt or reschedule work in progress state updates, which means that for external libraries, Redux, Zustand, Jotai, you know, X State, you know, take your pick here. We've had to rely on the use Sync external store hook as our integration with React so that when the external store updates, react gets notified and it can trigger or re-render. [32:42]
-
-But the limitation is that used syn external store can quote unquote det, which the React team has never done a great job of defining that term. But as best as I understand it, what it means is that if React was in the middle of a concurrent render and something happens with the external store, like say a Redux action gets dispatched while React was paused, rendering halfway down the tree, it ends up having to throw away the entire work in progress render and do a full synchronous render start to finish in order to ensure that the whole tree has access to the right data. And, you know, from their point of view, that's, that's a bad thing, which is understandable. [33:24]
-
-## [“Concurrent store” skeleton PR](https://github.com/facebook/react/pull/33215) a concurrent-compatible integration for external libraries
-
-**Mark:** So. They've put up a PR for what they're calling a concurrent store, and this appears to be a react built-in object that you can create and then you can pass it to the use hook to extract the value. And somehow the internals of this will be concurrent compatible. And it looks like that will allow external libraries to interact with that instead of use syn external store and potentially allow them to be concurrent transition compatible in a way that use syn external store is not. Now, thus far, what we have is a draft PR that just adds the skeleton of this to the code base feature flags and some tests, no implementation details, nothing we can run or try out. But based on some of the stated comments on social media and this draft PR and then the last React lapse blog post, it looks like that's the idea of what this could do. So at some point we may have to put out React Redux version 10, which which is over to this, it's good to see that they're iterating on this, on this concept. [34:08]
-
-**Carl:** well you, you certainly would know a lot better the context behind that than I would having maintained redux for so long. But it seemed like the, you know, use concurrent or, you know, concurrent store or whatever the various things they've tried, it seems like none of them have quite solved the problem they were hoping it would. So. [35:17]
-
-**Mark:** External store avoids the tearing problem. But at the cost of, if you happen to have that sequence of events occur, then you, it has to, you know, take the time to do a full render, which could be costly 'cause it can't interrupt itself. [35:32]
-
-**Carl:** Trade offs not ideal. [35:48]
-
-## [\ being worked on again](https://github.com/search?q=repo%3Afacebook%2Freact%20SuspenseList&type=pullrequests&s=created&o=desc)
-
-**Mark:** Along with that, Sebastian has done some more work on view transitions and they're working on resurrecting the suspense list component idea, which had been prototyped quite a while ago. And they're found Trying to bring it back. This is apparently meant to try to allow you to define intended order for multiple different, like adjacent or nested suspense components to reveal themselves. Say maybe like you have a, I guess like a list of items or something. Admittedly as usual, it's outside the scope of what I've actually ever tried to use, but it's a thing that had been sitting around for a while and it was unclear when they would get back to trying to work on it. [35:49]
-
-## Compiler integrations with [SWC](https://github.com/swc-project/swc/pull/10475) and [OXC](https://github.com/oxc-project/oxc/issues/10048)
-
-**Mark:** And, and then finally the React compiler is currently implemented as a Babel plugin. And given how the ecosystem has been shifting away from Babel, that was a bit of a pain point. The core of it does not rely on Babel. Like Babel was just sort of used as the way to get it into your build tool. And so they've been working on, in, they have a semi working integration with the SDC compiler, which is what next and other tools use. And they're also talking with the folks from OXC, which is what the New V implementation will use about the best ways to try to integrate. So still early days there, but it's good to see that we are, they're trying to find better ways to integrate with both, you know, with the latest generations of build tooling so that we hopefully don't have to have Babel in our build tool chains. [36:29]
-
-After all. [37:19]
-
-## Apple App Store Epic Games Saga 30% [Apple cut ruled unlawful in the US](https://www.macrumors.com/2025/05/19/epic-asks-judge-apple-approve-fortnite-app-store/)
-
-**Mo:** Next up a little bit of a segue. Not specifically React news, but I think reasonable enough to call out here because it does affect React native apps. So if you've been following the news, apple and Epic games have been locked in a feud for the last. Several, several years. Apple basically taxes any company on in-app purchases for digital goods of 30%, which is quite a significant revenue hit for any app developers that are out there. [37:19]
-
-There's some provisions for startups and so on and so forth to bring that down to a lower number. But once you hit a certain amount of revenue, I think it's around 1 million or 1.5 million a year on the app store, you have to pay 30%. And so. Epic games and Apple have been going to court over this for a very, very long time. [37:48]
-
-And Fortnite was off of the app store for a while several years ago now. So it's been going back and forth. If you use Netflix on your phone as an example, you'll notice that you can't actually purchase or change your subscriptions on the app. You need to go onto a website. And there's no sort of link from the app whatsoever to manage anything related to your subscriptions. [38:05]
-
-And that's kind of by design because they don't really wanna pay the 30% to Apple. So, in a sort of shocking turn of events a court came in and basically said that apple's 30% tax is actually unlawful in the us. Which is kind of a. nobody kind of expected this to come out especially because the EU didn't even go this far. [38:23]
-
-And so, the EU basically went in and said, Hey, you should be able to have a, you know, alternative app store rather than just the Apple app store available, but didn't say that, you know, 30% tax should be removed and it's unlawful. in the first sort of events that happened in May. Epic Games won and basically they, courts ruled that Apple should reduce the 30% tax or remove the 30% tax. [38:44]
-
-And how they do that is basically you can use in-app purchases. Basically use another external payment platform for it so you can use Stripe or whatever else you want to take payments for digital goods inside of your app. The next day, apple basically blocked Fortnite from the app store in a sort of weird turn of events saying, no, we don't, we don't accept this. [39:08]
-
-Only to then get overruled with a judge asking Apple to approve the app store submission for Fortnite. So now if you're in the US you might see some apps. Having a big warning on the app store from Apple saying, Hey, this app is unsafe in terms of transactions and you're not gonna be protected by the App store, so proceed at your own risk, which is quite funny. [39:29]
-
-So still doing anything that they can to stop people from doing this. But for React native developers, that basically means that you can now use Stripe only for the US market. So if this. If this is functionality that you have for any locale outside of the us, your app will still be rejected because this is on a US only ruling. [39:50]
-
-But you can use Stripe or any other payment provider for digital goods inside of your app, circumventing in-app purchases, and still have your app approved in the us which is a big, big deal for a lot of people in this ecosystem. And folks like Charlie Cheever have been speaking about this being a big day for, for mobile developers. [40:08]
-
-A bit of an aside, but it's relevant to react native developers to be in the loop about what's happening in the ecosystem. [40:27]
-
-**Carl:** that's like half of a seismic shift for native apps. the fact that it's only in the US locale is, you know, definitely dampens that quite a bit, but [40:32]
-
-for such a large market to now be required to accept. Different payment methods that don't have a 30%, you know, cut removed that is still quite large. [40:43]
-
-Still quite significant. [40:53]
-
-**Mo:** Hopefully this kind of reverberates to other markets as well and I can kind of see that happening. [40:54]
-
-**Carl:** All right. [40:59]
-
-## [Next reducing Vercel mentions in docs](https://github.com/vercel/next.js/pull/78557)
-
-**Carl:** Our last main, you know, topic here, kind of small, but sort of speaks to the general undercurrent, the vibes that people have felt around next and react. next has reduced how many mentions Vercel gets in the next documentation. Lee Rob in the PR for this says some of the mentions were egregious and unneeded. [40:59]
-
-Others were documenting specific behavior for how next runs on Vercel, which is better suited for Vercel documentation. That seems good. I would certainly agree that some of the mentions were egregious. Some of the behavior being documented was better suited to the platform documentation rather than the project. [41:20]
-
-The next project documentation, you know, it's just such a persistent topic of discussion that like next verse and react are all just like so tightly coordinating and whatever. This is definitely a small but positive change on that. I appreciate seeing it. I. [41:37]
-
-**Mark:** I think we even also put up a similar PR to tweak the phrasing that where next is listed in the React op docs set up an installation page. I think it used to have a phrase like, next or next is hosted by Vercel, or developed by Vercel or something. And they specifically tweaked that to remove some of that reference. And like it all, like, it also kind of goes along with, Vercel being intentional about reaching out to like the Open Next folks and trying to more standardize how next actually can be hosted. think people's complaints have been valid. Like this has been both a pain point technically as well as it has it, it's looked bad, but I think we ought to give credit to them for saying, okay, yeah, we, we agree, we kinda screwed up here and we're going to try to improve the documentation and the actual usage to make it more generic. [41:53]
-
-**Mo:** Looking at this a slightly different lens as well. I mean, props of them for this goes without saying, but I think Vercel is also starting to reach this realization that they can't just rely on being a next hosting platform to monetize. Because, you know, you see in the last you. Few months how their business model has kind of shifted into three spaces, which is, you know, hosting for next and, and other things. [42:49]
-
-But also observability has become a lot more of a mention on their sort of product listing pages. And more recently, I think they're really going hard on the AI space. So a few days ago, I think they announced that you can use Vercel. Sort of ISDK as a proxy to call 40 plus different LLMs without needing to set up different billing with each of these different platforms. [43:10]
-
-So I get a sense they're trying to go for a larger cloud play, which means that they're probably less reliant on next Js being sort of their guarded secret. And, you know, their tool that only runs on Vercel. And they can open it up a little bit more without worrying about it being sort of their only lever for business. [43:32]
-
-**Carl:** Yeah, that's interesting. I hadn't thought about how they were, they were super early on the ai SDK, they definitely have first mover advantage there, I'd say, and that is, that does position them well for like, if they are a point of entry for LLM based APIs, then that I could imagine a world where they then try and be like host their own models. [43:49]
-
-And then you are paying them for that hosting as well, which is adjacent to hosting your, your web app, but not quite the same maybe. Yeah. That's interesting. Yeah, they definitely own a pretty significant front door there and so where that door goes could certainly lead to stronger monetization for them in the future. [44:12]
-
-I also want to, you know, since in the last couple of episodes we've, one of the topics of discussion has been Vercel, and its. Collaboration or lack thereof with other adjacent hosting providers. noticed at the bottom of this PR it says Netlify has confirmed they're okay with a specific feature matrix link included, and I did my best to include the CloudFlare and Amplify versions based on their documentation, which I'm going to read into and say they do not have open lines of communication with CloudFlare and AWS which is maybe not ideal. I feel like they should have, you know, the, the head of dx, head of, I don't know. [44:30]
-
-I don't know exactly what Lee Robb's title is, but he is highly active, engaging with many individuals throughout the ecosystem. And for him to reveal that they do not have, you know, maybe not a red phone, but like any means of getting in touch with people within CloudFlare or AWS somewhat surprising. [45:06]
-
-I don't know. [45:24]
-
-**Mo:** CloudFlare, yes, I agree with you. Amplify. Oh boy. I've, used Amplify on and off to host various applications. I'm instinctually going to say that that might be more on the Amplify team, just by virtue of how they deal with their own users, let alone with other community leaders. But that's just a guess. [45:24]
-
-CloudFlare is probably a different, [45:45]
-
-**Carl:** I have very briefly used Amplify and that is approximately my read of things too. Fair enough. [45:47]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Alright Should we go to the lightning round? [45:52]
-
-## [Shared Element Transitions in Reanimated](https://github.com/software-mansion/react-native-reanimated/pull/7466)
-
-**Mo:** I'll kick it off with shared element Transitions, a very, very exciting prospect that we've been waiting on in the React native ecosystem So there's a draft PR going into React native reanimated for shared element transitions on the new architecture. I. Shared element transitions very quickly is basically what happens when you navigate from a screen to another screen in the React native or in a mobile app, and some element is taken, expanded, or animated onto the next screen. [45:54]
-
-So, you know, Instagram, you click on a post, it navigates you to that post, but it opens it up so you see a transition of that post expanding or something like that. There's been a lot of sort of POCs of this in the React native ecosystem, but nothing standardized that people can use easily and consistently in their apps. [46:22]
-
-So, Bart from Software Mansion has been working on this for a while and we've seen some really good promise of, of things actually working out for it to be available. So keep an eye out, keep an eye out on that. But it's still early stages, but I think that the new architecture can enable stuff like that, which is really, really exciting. [46:38]
-
-## [V8 explicit compiler hints](https://v8.dev/blog/explicit-compile-hints)
-
-**Carl:** This is extremely niche. But V8 now has, or is providing a new way of ge improving startup time by using comments to hint to the compiler what will be used and what should be compiled. So this is like very deep in the weeds of the runtime engine and like how it gets compiled and when it will compile things. [46:56]
-
-So this is certainly not something that I think most of us will need to use, if optimizing startup time is something that you care about, V eight is now giving you some new things, some new ways to play with that. I don't super duper understand all the, you know, twists and turns of this, but the gist of this blog post is saying that you can add a comment you know, slash slash. [47:18]
-
-Hash bang or no, not a hash bang, just a hash slash slash ash. All functions called on load. And that will signal to V eight that it should compile it differently than it would otherwise, which will improve startup time so that it, you know, because it doesn't have to guess so much at what is being compiled. [47:40]
-
-I always appreciate seeing some of these runtime optimizations. It's just like a little window into the black box. [47:58]
-
-## [TS Native Previews](https://devblogs.microsoft.com/typescript/announcing-typescript-native-previews/?s=33) (usable build of the Go-based compiler)
-
-**Mark:** All right. we're always talking about tools that are, and putting out, you know, faster releases, rewrites and native languages. And this month we've got a couple of previews. We've previously a announced that TypeScript is being rewritten in Go, and the TypeScript team has put out preview builds of the go based tooling. So you can try those out and see how fast it is. [48:05]
-
-## [Vite \+ Rolldown preview build](https://voidzero.dev/posts/announcing-rolldown-vite)
-
-**Mark:** Similarly, Vite just announced like right before we, we, we started recording this, that they've got a preview build of their roll down based. Bundle. So the idea right now, v uses a mixture of es build in development modes and roll up, which is a, which is written in JavaScript for their production builds. And so roll down is a rust based reimplementation of roll up, but they're going to use it for both dev and prod. And they're also going to look at, start doing bundling in dev rather than just shipping standalone ES modules to the browser. So it's preview, you can try it out. They've got some stats saying builds have gotten a lot faster as a result. [48:26]
-
-## [Seeded pseudo-random number proposal advances to Stage 2](https://bsky.app/profile/did:plc:w227epg3attqnssfdkx6ex6a/post/3lqcugizbls2g)
-
-**Carl:** Another deep in the weeds. update, but this is pretty early too, TC 39. But a seated pseudorandom number generator proposal has advanced to stage two. You know, math, that random is useful for many things, but cryptographically secure random generation is not really one of them. [49:10]
-
-Although actually this is sort of adjacent to that. This is one of the problems of math thought random is it doesn't let you provide a seed for the randomness, which has various drawbacks where sometimes you, you know, you want something that appears random, but is actually deterministic so that you can, you know. [49:29]
-
-Have other parallel computation that will produce the same output regardless of what the random is. some specific example tying in a CSS feature that I am not familiar enough with to speak at length to. But yeah, just like generally this is a huge expansion in the functionality, the randomness support in the web, in JavaScript. [49:46]
-
-I, I think it said it's like 17 new various random functions. So that's, that seems very nice. [50:10]
-
-**Mark:** a couple times where I needed to do some seated ran number generation, even if it was just for something like a, a, a tutorial example app and had had to rely on various third party libraries for that. So, I mean, definitely a useful thing to add to the platform. [50:17]
-
-Okay. And wrapping things up, a couple, couple bits around data fetching. [50:29]
-
-## [3-layer data data fetching for complex React apps](https://www.trevorlasn.com/blog/fetching-data-for-complex-next-and-react-apps) (RSCs, React Query, optimistic UI)
-
-**Mark:** I saw one article that gave and gave some suggestions around a way to manage your data fetching at a a three tiered approach where you can use server components on the server to do some initial fetching. Pass some of that as props into components and use it to seed react query on the client and then set up React Query to do some optimistic UI updates for faster behavior. Not necessarily new and groundbreaking, but it was nice to see a reasonably detailed article that suggested some ways to tie all three pieces of those together. [50:34]
-
-## Johannes Schickling announces [LiveStore (reactive SQLite \+ sync layer)](https://bsky.app/profile/schickling.dev/post/3lq5gucxsj22a)
-
-**Mark:** And finally Johannes Schickling, who I believe originally co-founded Prisma has been doing some work over the last few years around a local first sync engine called Live Store. He gave me a demo in person when I was, in a conference a couple years ago. And then he gave me and David corse a preview of his talk for local First conf a couple weeks ago. And this is really interesting. So he is running SQ Lite in the browser. He's got a reactive layer around SQ Lite. [51:05]
-
-So you would have like a, a, a data-fetching-like hook that you'd use in your components, except it's talking to sq l under the hood. But then the sq LI instance itself is being based on. A series of descriptive events. One might almost call them actions that describe a thing that happened that ultimately define how the data ends up in SQL eight in the first place. And so he actually very intentionally drew parallels to the, the redux mindset and architecture in his talk. So he, he just put that, I put that out and announced it at local first conf. it genuinely looks very interesting. Like, would all apps need it? No, but it looks like it would be extremely useful for things like a, like a local first setup needing to work offline. [51:35]
-
-**Carl:** I know Johannes Schickling is also very involved in effect, which is a interesting, like massive, huge API scope, like functional programming library. So like, man, he's doing a lot of stuff. He is really shooting his shot in a lot of different directions. Very cool. I somehow feel like he was involved in organizing the local first con. [52:24]
-
-Trying to confirm that. Yes. Okay, cool. He is in fact one of the organizers of Local First Comp, so that, that [52:47]
-
-**Mark:** Oh, that's cheating. Accepting your own talk. [52:52]
-
-**Carl:** Right. [52:55]
-
-it feels like he's very all in on building the future of local first. So Very cool. [52:55]
-
-## Outro
-
-**Carl:** Alright, that's all we got for you this month. Thank you so much for joining us. We will be back on. I'd say we'll be back on the last Wednesday of the month, but I think we haven't hit that for a minute, [53:02]
-
-**Mark:** I can already say that I, I'm still traveling. In fact, I will probably, I'm pretty sure I will be at a conference on the last Wednesday of next month. So we, we may need to bump it back a few days. [53:12]
-
-**Carl:** recording time, TBD usually the last week of the month. and we will be back in your podcast feed just as soon as we can after that. I hopefully will get it up on Monday. We gather sources from this week in React bites.dev react status next JS weekly, the React JS subreddit and herein Reactiflux from the Tech news and reads channel. [53:22]
-
-And also sometimes directly from people publishing, but that's a, that's an noisier signal. If this is a show that you get value from and would like to support, best way to do so is by submitting a review on whatever platform you listen to and by telling your friends and coworkers about it. Thanks so much for listening. See you next month. [53:41]
-
-**Mark:** Take care. [53:56]
diff --git a/src/transcripts/tmir-2025-06.md b/src/transcripts/tmir-2025-06.md
deleted file mode 100644
index ecb8cf6..0000000
--- a/src/transcripts/tmir-2025-06.md
+++ /dev/null
@@ -1,361 +0,0 @@
----
-title: "TMiR 2025-06: kinda quiet tbh. ES2025 finalized, new Safari"
-date: 2025-06-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-We had some problems with transcript generation this month, downstream of the audio recording issues. Sorry! Fixed for July.
-
-- Job market [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
-- New releases
- - Shadcn
- - updated Calendar component
- - Moving from \@radix-ui/... to radix-ui
- - [Recharts v3.0](https://github.com/recharts/recharts/releases/tag/v3.0.0)
- - [Vite 7.0 is out!](https://vite.dev/blog/announcing-vite7.html)
- - [Biome v2](https://biomejs.dev/blog/biome-v2/)
- - [Announcing Oxlint 1.0 \| VoidZero](https://oxc.rs/blog/2025-06-10-oxlint-stable)
- - [Prettier 3.6: Experimental fast CLI and new OXC and Hermes plugins!](https://prettier.io/blog/2025/06/23/3.6.0)
- - Experimental "fast CLI" support, first discussed [Nov 2023](https://prettier.io/blog/2023/11/30/cli-deep-dive) 👀
- - [Jest 30](https://jestjs.io/blog/2025/06/04/jest-30)
- - [React Native 0.80](https://reactnative.dev/blog/2025/06/12/react-native-0.80)
- - [Safari v26 beta](https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/)
- - [Apollo Client 4 RC1](https://github.com/apollographql/apollo-client/releases/tag/%40apollo%2Fclient%404.0.0-rc.1)
- - May actually ship pre-compiled with the React Compiler ([discussion with Lenz and Joe](https://bsky.app/profile/phry.dev/post/3lsl7w4ynjc2v))
-- [Sponsored by Infinite Red](https://infinite.red/)
-- Main Content
- - Mark's "[The State of React and the Community in 2025](https://blog.isquaredsoftware.com/2025/06/react-community-2025/)" ([slides](https://blog.isquaredsoftware.com/2025/06/presentations-react-community-2025/))
- - Remix direction?
- - "[Disillusioned with React Hooks](https://x.com/mjackson/status/1937979887815692465)"
- - "[I can break signals quickly, don't use them for real apps](https://x.com/mjackson/status/1938362165221523542)"
- - [React Router "Open Governance"](https://remix.run/blog/rr-governance) (and [governance doc](https://github.com/remix-run/react-router/blob/main/GOVERNANCE.md#steering-committee))
- - [Debate over Radix UI status](https://x.com/colmtuite/status/1935629877069172861)
- - [Shadcn has thoughts](https://x.com/shadcn/status/1936082723904565435) on switching component libraries
-- ⚡ Lightning round ⚡
- - [Towards React Server Components in Clojure, Part 3](https://romanliutikov.com/blog/towards-react-server-components-in-clojure-part-3)
- - Dan's latest posts:
- - [Progressive JSON](https://overreacted.io/progressive-json/)
- - [How Imports Work in RSC](https://overreacted.io/how-imports-work-in-rsc/)
- - ES2025 spec released. [What's New in ES2025?](https://2ality.com/2025/06/ecmascript-2025.html)
- - [The Future of React Native Graphics: WebGPU, Skia, and Beyond ](https://shopify.engineering/webgpu-skia-web-graphics)
- - [Open sourced identity](https://nodejs.org/en/blog/community/2025-pride)
-- Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [React Nexus](https://reactnexus.com/) July 3-5 Bangalore, India
- - [Big Sky Dev Con](https://bigskydevcon.com/) Aug 2 Bozeman, MT, USA
- - [Kansas City Developer Conference](https://www.kcdc.info/) Aug 13-14 Kansas City, KS, USA
- - [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025. Wrocław, Poland
- - [WaysConf](https://www.waysconf.com/) Sept 16-17
- - [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [SquiggleConf](https://squiggleconf.com/) Sept 17-18 Bostom, MA, USA
- - [React Conf is back](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Oct 7-8, Las Vegas, NV, USA
-
-# This Month in React: June, 2025
-
-[00:00] **1-vcarl:** Hi, Carl here. Just a quick note before we get into this episode. We had a little bit of an issue with the audio recording, so the quality is a little bit lower than I usually go for. Sorry about that. We'll do better next month.
-
-[00:11] Hello everyone. Thank you for joining us for the June edition of this month in React, where we recap and digest recent developments in the ever evolving react and web ecosystem. We are coming to you live here in Reactiflux, the place for professional React developers.
-
-[00:27] We're supported by infinite red. Consultancy that works in React Native.
-
-[00:31] I'm Carl, a staff product developer and freelance community leader here in React Plex, where I run community programs like these events and build tools to help keep the community operating.
-
-[00:41] **2-acemarke:** Hi, I'm Mark. I maintain Redux. I work at Replay.io io and I apparently spend too much time debating the React team's documentation and communication.
-
-[00:51] **1-vcarl:** Endlessly!
-
-## [00:52] job market
-
-[00:52] **1-vcarl:** Start off with a little bit of job market news. I don't know, maybe we should stop doing these. 'cause I feel like it's not really in crisis anymore and it's not really making any dramatic shifts and I feel like I just keep giving about the same update every month. But yeah, data from Indeed trended up for the first time in a while.
-
-[01:12] True up.io, which also. Attempts to answer about the same question in terms of like, are people hiring in tech shows a slightly more positive trend. So I think that might be like giant people are using Indeed and they are not hiring as aggressively in tech for tech roles and everyone else is using a random smattering of hiring tools and they are hiring. So I wonder if that's like a big tech versus little tech dichotomy. I don't know. That's not based off too much concrete in summation at all.
-
-[01:43] The layoff charts for June are the best that they've been in a year and a half. Fewest number of people laid off by a decent margin and fewest companies running layoffs again by a pretty decent margin, about half for each. Lowest five 50%. So that's good. That's nice. I'm not sure if anecdotally feels that much different, but yeah. I don't know if you disagree, lemme know.
-
-[02:08] We're gonna change up order a little bit. Previously we've done on job market, the conferences and the releases. I'm gonna throw conferences back at the end because I could tell in the data that people were skipping through it. So we're gonna move it.
-
-## [02:19] New Releases
-
-[02:19] **1-vcarl:** Yeah. New releases.
-
-## [02:21] ShadCN
-
-[02:21] **1-vcarl:** Shadcn pushed out an updated calendar components. In the release notes, they included like a, a code mod to move imports from at rad cy slash whatever to just rad, cy, like top level like barrel import kind of thing. I don't know what that's about. I didn't really see any new releases from RadixUI that mentioned that.
-
-[02:40] So like I don't really know why that shift is happening, but like, okay, cool. That seems fine.
-
-[02:44] **2-acemarke:** A couple other things about RadixUI UI later on in the discussion.
-
-[02:47] **1-vcarl:** Yeah. Oh yeah. We've got some main content chatter about them. Just like some Twitter threads, debating, usefulness and whatever. Yeah, more of them later.
-
-## [02:55] rechart
-
-[02:55] **1-vcarl:** Recharts has a major release for the first time in a long time. Their last major release was January 4th, 2023. So two and a half years. That's a while. Recharts is not a library that I'm often happy to use, but it is a library that I often use because it just makes charts pretty easy. Not always as powerfully and flexibility as I want, but, it's good enough. It's pretty great.
-
-[03:16] The big thing that caught my eye in these release notes was they're claiming it's now accessible by default, so you can tap into it in these arrow keys to navigate it. So that's nice. Accessible charts are hard.
-
-[03:27] Most people don't do them, so getting it in the default is lovely. That's, that should help a lot more charts be access, and then Mark feel like you'll have more to say on that.
-
-## [03:37] vite 7
-
-[03:37] **2-acemarke:** Maybe so, so Vite 7 just came out. I've actually been having a little bit of trouble just trying to keep track of some, some of the releases, it feels like they've, they've really sped up some of the development.
-
-[03:49] They've bumped their, their node version support. Part of that is because they want to make use of the relatively recent node support for requiring ESM packages. In other words, importing an ESM module from a CGS module. Which was always the, the sticking point for a lot of the ESM common JS compatibility.
-
-[04:10] So they're actually distributing e and Vite 7 as ESM only, which. It feels like a fairly big step in the progress of, you know, the ESM ecosystem. They're also changing the default browser target to use the baseline, widely available preset in terms of browser features. They also now have some better support for the environment.
-
-[04:35] API, I'm still a little hazy on what exactly that does. My understanding is it, it allows you to ultimately generate bundles for different target environments, I believe is the best way to put it. So Vite 7 feels like it's a fairly big release.
-
-[04:51] **1-vcarl:** We had talked about the environment a while ago. I also don't really understand it too well, but definitely like deep in the weeds for library authors or, I don't know, framework authors. I've heard some positive things, but yeah, it seems esoteric.
-
-## [05:06] biome
-
-[05:06] **2-acemarke:** Meanwhile, we also have a slew of new formatting and lint tool leases, all seemingly with an emphasis on making things go a whole lot faster. First off Biome, which is, you know, formerly known as Rome back in the day, just released a version two, which is a fairly big deal, partly because they're, they now actually have some type aware linting rules.
-
-[05:31] Part of the issue here is that I. Up until now, the only option for doing types based linting was to use the TypeScript ES lint package, and that involves using the TypeScript compiler actually compiling things. And so it's kind of slow, and I don't know exactly how they've managed to implement this, but Biome now has some form of lightweight type analysis that does not appear to rely on the TypeScript compiler.
-
-[05:58] And so they've used that. To implement things like the no Floating Promises Rule. Now, it does not appear to be anywhere near as comprehensive as what TypeScript ES lent supports, but it is an interesting step in that direction.
-
-## [06:11] Void Zero
-
-[06:11] **2-acemarke:** Meanwhile, Void Zero, which is the VC backed company behind now Vite and other related build tooling development has released Oxlint 1.0.
-
-[06:24] So we have another lint tool that is a competitor to ES lint. They're claiming they have 50 to 100 x speedups and built in support for over 500 ES lint rules. And they say it's being used in a number of major companies. So if Linting is a particularly slow portion of your build pipeline. You may wanna check that out.
-
-## [06:45] Prettier
-
-[06:45] **2-acemarke:** And meanwhile, prettier 3.6 is out and they've been working on an internal rewrite of their existing CLI to try to speed it up as well. It's not a, it's not a rewrite and rust, it's just finding more efficient ways to do the same work in JavaScript. So the general theme here is people want to do linting faster.
-
-## [07:07] jest
-
-[07:07] **1-vcarl:** Yeah, we've got a new release, new major release from Jest as well. I think we had teased this the other day because they had a beta out. But yeah, first major release in three years. Again, faster perf, faster module resolution with some better ESM support. I know that generally like crawling your modules is one of the slowest is like, you know, broadly one of the slower parts of all of these bundling linting testing, whatever tools.
-
-[07:34] I wish I knew a little bit more details about the internals of like how just versus Vitest do it differently. 'cause my sense is that J is like heavier weight. It like does more, is more, I don't know, doing more on your disk and like crawling the condenses and all of those kinds of things. Yeah. So like one more place where there's a focus on performance in our build environment.
-
-[07:56] **2-acemarke:** Faster build tools, always a good thing.
-
-## [07:57] rn 0.80
-
-[07:57] **2-acemarke:** Those who in the audience may have noticed that MO is not here this week. He had a prior commitment and wasn't able to make it. So I will have to do a poor job of filling in and describing some of the React native changes. React Native 0.80 is out and it looks like the two biggest things out of this are they have frozen support for the legacy architecture.
-
-[08:18] I believe one of the recent releases made the new architecture default. So they are, they're seizing work on the legacy architecture, and this also brings support for React 19.1 as well. Now along with that, I believe the current version of the Expo SDK, version 53, does not have support for this directly yet.
-
-[08:41] If you want to use React Native 80 with Expo, they do have a canary version of the SDK that you can try out at the moment. But full support, I believe is. Or is planned that Expo SDK 54 coming out later this year would have support for React Native 0.81. So good luck trying to juggle those.
-
-[09:03] **1-vcarl:** Yeah, I know Expo has visibly been like focusing on release cadence.
-
-[09:07] I feel like for the last year or so, it seems like they've just been releasing something, being constant. And I know that Mo has talked previously about React Native working to have a more frequent release cadence, which is also has been very apparent. Kudos to Expo for like still being able to address this. Even if it's only in a pre-lease version, we can still test it out.
-
-[09:28] And also just like, it seems like it speaks well to the cadence that they're able to hit that they are, Expo is just saying like, yeah, we'll catch the next one because that's how fast it's gonna come out. I do wish Mo was here 'cause I feel like I see references here that make me curious to have an expert explain a little more.
-
-[09:45] They have a good post referenced in these release notes, moving towards a stable JavaScript API. I would love to hear Mo talk about how they are getting rid of JavaScript deep imports, so that, you know, basically just like saying, here's the public API stop importing things from deep within the project, which makes sense that if you let people import whatever the heck they want from inside of your package, then yeah, you just don't have a public API and you have to support literally everything. Everything is a break and change. Seems really cool. We'll have to have Mo catch us up next month.
-
-## [10:15] webkit 26 beta
-
-[10:15] **1-vcarl:** Yeah, this is a big one that is, I wish I had slightly more context for, but WebKit Safari version 26 is in beta. They're jumping from version 18, I believe it was all the way up to 26. So that all of the different, you know, iOS, whatever technology things can all be in sync.
-
-[10:33] This was announced of a WW BC 25 keynote. Yeah, so like Mac, os, iOS, iPad os, vision os and Watch OS are all now version 26. And so is Safari because the browser is also an operating system. Vision's a pretty large update and it has like all sorts of things from like cutting edge. Now you can use a model.
-
-[10:54] HTML tag, if you're Envision OS to render a 3D model all the way. So like that's very cutting edge, like future looking high tech, whatever. All the way back to you can also use SBGs as your favicon. A feature that like many other B browsers have had for a decade. So they're like both pushing the envelope and playing catch up.
-
-[11:14] Yeah. Safari has the di very different release cadence from other browsers. It's much closer to like the old style release. Cadence as opposed to how Chrome and Firefox and Edge are all like Evergreen, constantly updating. So I guess it makes sense that we're gonna have such a huge, massive dump of features, but like definitely check it out because they've got all sorts of stuff.
-
-[11:34] HDR images, web GPU, lots of CSS changes, lots of, you know, new standardized APIs, standardized job J JavaScript, APIs, all sorts of stuff. Finally, Apollo client just shipped a release candidate for version four. The release notes for this version don't have like a consolidated list of everything that's changed, but if you scroll back some, and you look at some of the lists of the prior alphas, it's clear that the, the Apollo team has been very, very busy and I know that.
-
-[12:05] In some discussions with Lens, who is my fellow Redux maintainer, but also works on Apollo client as his day job. They've been doing a lot of work to try to improve some of, and some of the packaging setup that had been, that had stuck around for years. One interesting side point out of this is that there's a good chance that Apollo client for might actually ship pre-compiled with the React compiler to try to optimize some of the internal hooks and components in the library.
-
-[12:34] There was a really interesting discussion thread on Blue Sky between Lens from Apollo and Josepha from the React team where they were discussing like, should libraries go ahead and ship like React compiler pre-compiled bundles already? Does it make sense to wait until some of the compiler runtime pieces are more stable, so clear, like.
-
-[12:58] This is very new and new and unusual territory for all of us library maintainers, and so it's interesting to see Lynn's trying to figure out some of these things that for the rest of us, yeah. That question of whether libraries should be pre-compiled with the React compiler definitely seems like a big open one in the ecosystem.
-
-[13:18] Cool. Alright. We are sponsored by Infinite Red. We are an expert React native consultancy that's been around since 2015. I. They're our only sponsor right now, in part because very few companies do as much as they do for the ecosystem. Just they, I don't know of anyone else who's done it quite so much for quite so long.
-
-[13:34] I've been seeing the name Internet Red around for as long as I've been in React and around React. React Native, which goes back all the way back to like 20 14, 20 15, they host the largest React Native podcast. They organized the largest React native conference in the us. They only do React native and have built over 75 apps for companies from startups to the biggest in the world, other than being great people who've done the great things to the ecosystem.
-
-[14:00] It's a team of about 30, mostly developers, mostly with more than 10 years of experience, and something like half of them have been there since the company was created. So just, you know, dev shop with Longevity. A dev shop with loyalty to its employees. What wild, they aren't just a feature factory. They will work alongside your devs and help you develop your own expertise.
-
-[14:20] So if you're spinning up a new product, being React native and want some help in the ground running, definitely give them a ring intimate top red. Cool. Okay. Into our main content. Start us off with your posts and talk. Hi. Yes. This is the part where I go off on things for a while, so if you, if you've been listening to the podcast for a while, you know, following me on Blue Sky or something, I've been involved in a lot of discussions and had a lot of opinions about, I.
-
-[14:44] A number of the interactions between the React team and the community, as well as a lot of the common misconceptions that have been unfortunately running around in a lot of community threads for a while now. It seems like pretty much every time you open up a discussion, for example, about Next.JS, there's complaints that the React team has is, you know, too close to next.
-
-[15:06] Or that Elle invented server components just to, you know, just to make money. Or why is the React team doing all these server things? Does the React team even care about, you know, single page apps anymore? And. A lot of this stuff has been going on for a while, all the way back in January and February when some of the CRE React app deprecation stuff was going on.
-
-[15:28] I kind of got fed up for a while and I was writing an extremely long blog post that I never actually published. I did a lot of research. I wrote a lot of words. It was cathartic. In reviewing it, I concluded that publishing it probably would've burned some bridges, even if the content there was accurate.
-
-[15:46] But there was, there was some good historical information in there and a number of folks said that it would be worth, you know, trying to publish that. Anyway, so I had a chance to speak at React Summit in Amsterdam a couple weeks ago, and my talk there was actually directly based on some of the content in the post and.
-
-[16:07] I decided it was worth trying to revisit the draft that I never published and extract the info that was relevant to the talk and hopefully make some of the points that I'd originally tried to think of, but, you know, maybe in a slightly more tact, tactful and less inflammatory kind of way. So really the the post and the talk.
-
-[16:28] Are trying to push back on a lot of the myths and misconceptions and FUD that have floated around in the React community for the last few years, but also point out some places where I think the React team's communication has has kind of fallen down. So a lot of people get confused about. The relationship between the React team and the next team who actually invented server components, why they were invented.
-
-[16:55] So as usual, a good portion of the talk and the post are basically a history lesson. You know, I tried, I did my best to try to recap, as I understand it, the origin of server of server components, the timeline of when they were invented, basically that the React team invented them while they were still at Meta, before Versal ever got involved.
-
-[17:15] And that it was something the React team invented because they ultimately, they saw the infrastructure that Meta had for server side rendering and data fetching. That was always very specific to meta and it really couldn't be generalized. And so server components was an attempt to. Implement kinda like a generic version of what Meta had for its own infrastructure, but because Meta had that infrastructure, they really couldn't iterate and Alpha test the features the way that they had everything else.
-
-[17:47] They ended up reaching out to Versal and getting Versal to build out the React team's vision of what they wanted to do. So a lot of this was me attempting to push back on the Versal invented server components to make money narrative. But then I also ended up addressing some of my points of concern where the lack of documentation about server components.
-
-[18:11] Has been a point of confusion. People not understanding when do I use them, how much should I use them? Is the React telling me to use them or are they optional? As well as a lot of the, the back and forth about why are the docs pushing the concept of frameworks so hard. And so I went into some details on my understanding of the React team's rationales for actually trained to say frameworks should be the default way to use react.
-
-[18:39] I put a lot of effort into it. I hope it's been informative and the feedback to the post and the talk have been pretty good. Dan Abramov actually retweeted it and basically said that, you know, he, he had a couple nitpicks about the way I described some of the timelines and bits of info, and he actually passed me some corrections on the side, which I tried to, to fill in, but he seemed to think it was generally accurate, and also he said that he'd been kind of stuck.
-
-[19:06] Debating whether to write his own history post, and he might end up being able to write one. Now that I've done most of the heavy lifting on it, that at least tells me I was directionally accurate. I. Like I can't have been too far off if he wanted to correct me on. So I don't expect that my me writing a post and doing a conference talk is going to silence a lot of the confusion, but at least I've done my best to try to clarify things.
-
-[19:33] So hopefully we'll see. Yeah, I think it's really valuable is to just check in every couple of years I'm like, what is. True. What did happen? What, what were the facts here? Oral history is very, very valuable. Sometimes capture some of that local knowledge. You put it in the paper. Yeah. I would be very curious to see what kind of oral history Dan OV can write though.
-
-[19:52] That's, uh, you know, you and I have been paying attention for a long time, but we have not been. Operating anywhere near the same level as Dan has for as long as he has. I would say, I hope it doesn't feel unfair to make the same claim for you, but useful post. Interesting. I think it's interesting too, how I.
-
-[20:10] As big as reactors, you know, the millions of people using it and relying on it and affected by it. At its core, the people in control of it is still like very countable. You know, it's not like unaccountable machine of like hundreds of people turning knobs and dials and you know, like it is at the end of the day, very much a core group of a handful of people making a lot of these decisions and doing a lot of this work.
-
-[20:37] And I feel like that's maybe, I don't know, that feels relevant when we're discussing its evolution and such. There's a team page in the React Docs and that page Curie lists about 20 people. There's about 13 to 15 at Meta at the moment. There's about five people at Versal, and then there's two or three sort of independent slash emeritus people.
-
-[21:00] So for example, Dan Abramov is not directly on the team at this point, actually. I'm not even sure if he's still listed on the page. I would've to double check. Sophie Alpert, who was at Meta for a number of years is still listed on the team page. I don't think she does a lot of development at this point, but still involved in discussions.
-
-[21:19] So it's about 20 ish people that would be considered sort of the, the core team that's separate from, you know, whoever might be doing like React native or other pieces like that. Right. React native is its own court team, which I think is larger. Yeah, I can confirm. Dan Amont was still listed on the meet between page second, so very highly along with me giving my talk.
-
-[21:43] Earlier in the afternoon. Tanner Winsley did a talk about couple different things. Some of it was, you know, pitching the various 10 stack pieces. So router query the upcoming 10 Stack start framework as well. But part of his thesis was that. Single page apps are still by far the dominant way to build React, even if there's been more of an emphasis on server side pieces in the last few years.
-
-[22:10] He really likes single page apps and a lot of his goal is to build good tooling that would be used by single page apps. I don't think any of the talks from React Summit are are online yet. I think they said they would try to have 'em online within two to three weeks after the conference. I haven't seen a notification that any of 'em were up yet, but I would definitely recommend watching Tanner's talk once the video for that's available.
-
-[22:38] Yeah, maybe we can, oh wait. Oh wait, I see a playlist. No, there's only five videos on it. Yeah. Maybe we'll be able to share those out next month. Yeah, they, I believe they, they're generally put up directly on get nation.org or.com, I think, rather than being listed in the YouTube channel. But we'll have to see.
-
-[22:57] Okay. I do see a React Summit 2025 playlist that has a couple of videos with like children views, maybe a ways to watch. Yeah. Moving on. Remix React router, going back to last month. So we've had a lot of. Back and forth between what is Remix, what is React Router? First we had React Router, the client side, LI Library.
-
-[23:21] Then we had Remix the SSR framework, and then we had Brian Forres announcement at React Conf, I think two years ago that most of the features in Remix we're going to migrate back to React router. And so React router gained things like loaders and a framework mode, and they announced that Remix was going into some kind of hibernation.
-
-[23:46] What was Remix is now basically all in React router, version seven I. And so Remix had kind of stopped development at version two last month. We talked about the announcement post where they said that Remix V three is coming. It's going to be very different. It's not just like, you know, upgrade to the latest version of React Features or something like that, but instead that it would be.
-
-[24:12] A new framework, one that actually is gonna use a fork of the pre-ACT alternative library, and with various emphasis on things like LLM based development and no bundling. That's the context for where things stand with Remix and react Router as a whole. So from there, Ryan for and Michael Jackson are both pr, you know, still pretty active on Twitter and they've been making a lot of comments that are either teasing things in directions that they want to go with Remix, but also, I'm not entirely gonna call them like clickbait or flame bait posts.
-
-[24:55] But kind of close stating a number of opinions about React itself that frankly make me very, very, very confused about what it is. Remix V three is actually even gonna look like. An example of this would be that Michael Jackson recently tweeted that he's now very disillusioned with React Hooks. You might even remember that Ryan Florence did one of the original talks at React Con 2018 where he helped, you know, demo React hooks for the first time.
-
-[25:22] And you know, granted, this is Michael's comment, not Ryan's, but I think it kind of shows their shift in mindset over the last seven years. Yeah, definitely big moves. I don't know, there's. They've been such big figures throughout my career. Like when I was learning React, I learned React rather in parallel, in like literally 2014.
-
-[25:44] And it's a little bit funny to have like been there for the whole saga because I've just watched them go like back and forth and back and forth on like what should be the API do. We care about data fetch at the router level. Just like watching them explore this and like watching their opinions shift and evolve and like double back and unfold in slightly different directions.
-
-[26:06] It's, I don't know, it is a bit of a surprise. I, I don't know. It is and isn't surprising to see Michael Jackson here come out against hooks. Also, I'll just say I was trying to confirm whether Michael Jackson still worked at Remix post Shopify acquisition, but I, I had a funny interaction years ago, managed to get enough of the profile in the ecosystem where Michael Jackson was following me on Twitter and we had a interaction during COVD about like lockdown stuff, where he was skeptical of lockdown.
-
-[26:36] And I was like, it's keeping people safe. And he ended up unfollowing me. So I don't know, like that felt like, that felt like a moment, that was a moment for me. I dunno, big famous person in the ecosystem unfollows you on Twitter. Like it stuck in my head and I don't know, it's just like, to me that feels like that feels relevant here as like point of contrarian and like, I don't know.
-
-[26:56] It's seemed since then that there was kinda like a closing off since then of him being like, Nope, I believe what I believe and I'm very confident that it is right. And like, screw all you. So I don't know. This is interesting. On the one hand, like hell yeah. Know your principles live by them and put the work in and like he's doing that.
-
-[27:16] Heck yeah. It's interesting hearing him say like, I don't like hooks. They're not great. And also like I relate to that. I don't know, like I, I started like learning hooks and like rewriting a bunch of code and using them professionally for a number of years. It felt like there was a right way to solve the problem.
-
-[27:35] It felt like I was, it felt less like I was writing code and like doing a thing and more like I was figuring out a puzzle somebody else had made with a right answer. And if you didn't get just the right answer, like you kind of had to start over. You know, it felt video gamey in that way of like, you make a bunch of progress and then you realize that you're at a dead end and it's like, let me start over.
-
-[27:54] I think that, you know, that feels like what he's complaining about here. You know, everything about them just seems so unnecessarily complex. But then he is also like down on signals, which is what a lot of other people are very pro. I'm also skeptical having used, I don't know there, I hear there are differences from event emitters, but I'm skeptical that the differences are that significant.
-
-[28:16] I keep hearing similar trade offs about circular dependencies and like event storm type of stuff. So if he's rejected like pokes and signals, which are the two top of mind ways of dealing with reactivity in React. And he's also stated the intent to use a fork of a fork of react in Remix D three. Yeah, whatever that's gonna be called.
-
-[28:39] I don't know. It's interesting. Like it doesn't sound like it's react anymore. It sounds like it's, he's gonna try and explore. The same problem space that React has been exploring, but doing so while challenging some of the core assumptions. So I don't know, it's space to watch. Yeah. And, and to be clear, like I'm, I'm not sitting here and saying like, oh no, Michael Jackson hate hooks.
-
-[29:00] He's a bad person. And anyone who's actually. Excuse, react, understands that hooks have trade-offs. They are not perfect. They have a different set of trade-offs than class components did. There are a lot of pain points, depths, arrays, data flow, you know, reactivity, mental models, et cetera. I am certainly very well aware that.
-
-[29:21] Hooks have their own set of trade-offs and flaws. But yeah, like my point, looking at the thread and this discussion is basically what you were saying, like Remix was a react based framework in version one and version two, Remix V three is not a React based. Framework, but given that they don't seem to like hooks and they don't seem to like signals at this point, I just honestly have no idea what it is they're even trying to build or what the feature set is, what the.
-
-[29:56] Usage patterns are supposed to be. I, I am just, I, I, I don't have a good mental model for what it is they're trying to do at this point, just by reading the discussion and the tweets. I believe they said that, I think there's a, a Remix jam conference coming up later this year. I think possibly in Toronto, if I remember hearing correctly.
-
-[30:18] I don't have a date for that off the top of my head, but I think it's this fall, and I think I've seen them say that they will have some announcements to make. At Remix Jam, which is understandable. I don't know, like I'm curious to see what they've got, but it, it doesn't seem like we'll really have a decent understanding until they make an actual announcement and then there's good documentation to look at, and then we could critique that.
-
-[30:39] Yeah. Right. So, I don't know. I'm curious. If they have my attention, for sure. It feels like they're being coy about it too. I feel like they have a lot more of this banged out than they're talking about and you know, I feel like there's a private group chat or like a secret repo somewhere that it'd be very fascinating to get access to.
-
-[30:57] Another little bit about this, they have posted about the open governance. Technical committee, steering committee that reactor adder will now have, I hold some skepticism, some level of skepticism just based on like the contents of this governance stock that you know, this governance announcement blog post, like notably the only people on the steering committee at inception, our existing Remix and react to router contributors, the announcement and the governance model.
-
-[31:28] Both focus very heavily on technical goals while discussing governance and how this is going to be open and like, you know, participant participatory from the ecosystem and whatever. They set up a lot of fences pretty early and strongly of this is what we care about. This is the direction we're gonna be going.
-
-[31:46] So like saying, not including outside people in the initial steering committee. And very aggressively setting direction while discussing open governance to me says this is visible governance, but I don't know if it's gonna be open to that, open to outside participators. Yeah. This feels reminiscent of like some of the working groups in the React ecosystem where they, we were just, you know, a little bit, they had blinders on.
-
-[32:11] They were gonna do their thing and they did their thing and that's great, but it's, it's not that open, it's not really that participatory. So this is, this is one that I've only partly read, but it feels like there's some amount of relevance. So the RAD X UI is a headless UI library that is pretty popular, especially because it's been used by the Shad CN component library.
-
-[32:36] But RAD X UI has been borderline unmaintained for quite a while. I believe the library itself got bought out a while back by a company called Work Os. And there's now basically a, a halftime maintainer of the library. And I've actually spoken to that maintainer before at a conference and he is like, yeah, I'm, I'm pretty burned out.
-
-[32:59] And I would almost rather like not even do anything with redix at this point. I. So there was some chatter in the last few weeks about whether people really ought to even be using it at this point. And apparently one of the original co-creators of Readex is now working on a competing package called Base ui.
-
-[33:20] And so basically saying that, look, Readex is unmaintained. Try using base ui, try using Aria kit. So I, I don't necessarily have a lot more feedback and thought and no, I have not seen Theo's video on it, so I have no opinions there. I will say that just because something is not getting active maintenance does not mean that the code is dead or suddenly more broken.
-
-[33:46] But I can definitely understand people's reluctance to use something that isn't getting, you know, like still getting active fixes. Yeah, I do have some opinions. I think that to some extent, like I don't really expect that much active maintenance from a like mature and wide used component library because there's not really that much changing in how you would develop a component library.
-
-[34:12] Like there has been so many component libraries. All like, you know, building on each other and exploring different directions and like pulling different types of abstractions and different types of like interactivity or whatever, different developer experiences. Going back for like long enough that it's pretty well trot ground at this point, and for a very long time it reacts life.
-
-[34:37] The patterns and the abstractions and the ecosystem they existed in were churning very heavily, and so it, it was not that surprising to see new component libraries coming out like every, you know, six months because there were meaningful differences. Every six months, you know, like, you know, is, is this written with higher order components or render props or hooks or, right.
-
-[35:00] Oh, you know, like when I first started, I started writing things with mix-ins, and then I was like, wow, mix-ins are, and then someone was like, oh, here's a higher order component. I was like, oh, that's cool. Let me try that. And then someone was like, here's a render prop. Here's a hook. You know? Now node and MPM support different modes of like consuming libraries.
-
-[35:21] And so now as a component library maintainer, I need to go refactor everything to support tree shaking or to be ESM only. So like there's just been so many big seismic shifts that like, yeah, we got used to that, but it's not really, that hasn't really been strongly the case for a minute now, like I would say, I.
-
-[35:44] 2022. I feel like it was when we had a, started getting, you know, as an ecosystem, the wisdom of how to use hooks had really settled down pretty well. Like we, we explored a lot of patterns and figured out things that did or did not work. And Hooks came out in 2018. 2022 is like four years of like playing with them.
-
-[36:06] And then that was three years ago. So like we've been, we've had a stable set of primitive tools within React. For doing abstractions for seven years now, which is absolutely, you know, that's longer than pre hooks. We only have three years before hooks existed. Four years, maybe five. No, it was 2013 when it came out.
-
-[36:25] So like that's more time with hooks than we had without hooks. So I don't know, like. I see this thread started with hot tape using Chad CN slash radix. The liability at this point, and maybe this is also an echo of a point that I try to drive home periodically on this podcast of like there are many different audiences using React and if you're an indie hacker than your constraints are extremely different from someone four years into maintaining a legacy application that's making tens of millions dollars for its parent company.
-
-[36:56] So like. This hot take sounds to me like someone doing small team build it and set it down projects, not somebody maintaining a legacy application. So like, sure, if you are trying to use the latest, greatest, sharpest leading edge tools, I. Is maybe that, not that name water, but I don't think it's getting rusty that quickly.
-
-[37:16] So like if you are not building a new thing every three months, I think it's probably fine. I dunno. Seems okay. And like, and you know, oh there was a really great, oh shoot, did I lose the link? There's a really great, I. Response that I saw from the maintainer of chat already, just baed it in. Lovely. Yes, thank you.
-
-[37:33] You just did that. Yeah. And he says, he says a lot of things that resonate with me that I think I have hit on here. Like here's what I'd suggest already. There's a quote here, here's what I'd suggest already using redix and prod. Stick with it. Starting a new project. Consider ics React Aria or Aria Kid.
-
-[37:49] All great choices. So like, yeah, that's, I would agree with all of that. And he closes this, what I'd suggest section with Shae is built for this code. Your own code can approve, rewrite or replace and like, yeah, that's the whole like reason for Shae and being built in the way it was, is that like it's not a library if you're unhappy with it, it's your code, it's hidden, your repo, you committed it.
-
-[38:11] So change it, commit something else. So I don't know. It seems cool. This seems, not that I have a lot of opinions on this, but at the end of the day, my opinion is like chill out, care less. Do the thing that's right for you. I guess in a very broad level, the JS ecosystem is entirely too prone to saying Tool X is dead because tool Y exists.
-
-[38:34] Yeah, I could rant about that. The human trend towards X is dead long lives. The new X on with Y? Yeah. Okay. I think we've beaten that to death now. Okay. Into our lightning round. I don't have too much to say on this, but I like it. This is a blog post. Of somebody writing React components. Enclosure, this is part three of his series, and that just seems to be, I don't know.
-
-[39:01] I love seeing people play around with server components more and playing around in different languages, in different room times. Is extra interesting, so that's cool. Just a great like use case, write up. There's been a subset of the closure script, whatever community that's used, react in their own way for many years now.
-
-[39:21] So seeing, seeing someone attempt to bring server components over in that direction's kind of cool. Dan Abramov has continued to crank out blog posts and he put out a couple more since we did our, our last podcast. He wrote one on progressive JSON, where he talks about how server components will progressively send over pieces of JSON and insert placeholders via suspense.
-
-[39:44] And then he did another post on how imports work with server components. And the majority of this post actually doesn't have anything to do with. Server components per se. It's really describing how the JavaScript module ecosystem works and then brings in some bits about how server components allow you to connect the dots between the client side and the server side, as well as enforce that certain code only exists on one side or the other.
-
-[40:13] We've got new ES 2025 out, which seems pretty good. Man, I, it, it took me a little bit to catch up on. Order of operations and what came out when. So this is everything. This contains everything that went to stage four, more or less over the past year. The most recent stage four is going out in 2026. So this what's contained here is Sync Iterator Helpers Promise.
-
-[40:40] Try some new set methods. Methods on the set primitive. That is JSON modules for imports. Import attributes and then a couple of like Redex updates for escape and modifiers and main capture capture groups. Sync iterators. Sync Iterator helpers are definitely the most like, interesting thing on this list to me.
-
-[41:00] Just like they're the, the number of times that I've taken a set or, you know, some iterable and then spread it out into an array so that it can map over. It is like constantly. I, every time I use an Iterable, I'm doing stuff like that because I like using e. Map and four each more than I like doing four ofs, so that's cool.
-
-[41:19] I'm excited to see that. Just being able to natively map over Iterable is lovely and I love it. One thing that's probably worth noting is that apparently the iterator support is, might be a little better for perf in some cases because it doesn't have to create a separate array every time you do like a filter or a map, right?
-
-[41:37] That's the main thing I think about every time I do that. Oh man, I'm just iterating a new array for no reason. New RA for no reason and kind of related promise that try is sort of a similar type of performance optimization, you know, performance micro optimization. This, the last time I was reading about it, the advantage I saw is that it lets you, it lets you ignore whether something is or is not a promise without skipping a tick.
-
-[42:03] If it is a promise, you know, and you do a dot, then like, okay, it's gonna consume a tick. But if it's not a promise and you wanna just run something afterwards. All of the like poly fills for something like promise try that would let you exit. Whether or not it returns, a promise would consume a tick. So now that, that's the advantage here is if it, if you're looking for that, it just is a little bit faster.
-
-[42:27] It's a little bit less talking. Then the, the set methods are a very nice, convenient thing. Sets now have built-in methods for intersection union difference, and a couple other things, which is something that really should have been in there from the beginning. Yeah. Definitely, there's so many more details on Axel Meyer's blog, so like definitely the dive into that and yeah, little teaser of ES 2026 is they have already sh shipped.
-
-[42:57] Well, they've already landed. Error is error, like an identity function for errors. So you can actually get like type safety in catch blocks. More easily. That is stage four, but it did not make the cutoff for S 2025, so that'll be out in 2027. There was a post on the Shopify engineering blog about the future of React Native Graphics Web GPU, SKIA and beyond.
-
-[43:21] The land of low level 2D graphics toolkits is complex with. Wrappers and abstractions and cross compat and all kinds of other layers of complexity. And so the post goes into into details on the existing React Native ski, a package for 2D graphics, how they've been able to add web GPU support to React native so they can do things like running three JS inside and some of the other upcoming improvements to React Native Skia as well.
-
-[43:51] Yeah, I, I know I've heard Mo talk about Yeah. A couple of times. See it getting, I don't know, broader. It seems cool. It's neat to see it still going, still chugging along. Cool. This is a personal plug. I wrote a blog post for the node js blog. I. It's June, it's Pride month. I'm proud. I have not always, I have accepted within the last couple of years that I am queer and began understanding what the heck that actually means.
-
-[44:18] I was asked to write a blog post for Pride and I pulled together one discussing open source and it's parallels with queer identity and how you know, we all take the labels that exist. Learn from them, incorporate them into our understanding of ourselves and use those as a springboard to find new things.
-
-[44:38] So, I don't know. I'm proud of it. I like it. It's a good post if you're interested. Check it out. Yeah, I, I've been checking the Twitter replies on the announcement and yeah. Yep. Those people still exist. They don't like it. So anyway, it's all I'll say on that. Closing with conferences, we have a quite a number of conferences coming up, like basically next week, July 3rd through fifth.
-
-[45:00] Is React Nexus in Bangalore, India. There is Big Sky devcon out in Bozeman, Montana. Which seems cool. I don't know. I I appreciate that. It's called Big Sky. I know that there's a, I think there's a big Sky National Park and I, I used to do astrophotography, so big skies are like near and dear to my heart. So this one just looks sweet.
-
-[45:22] I don't know. I don't have any, there's not no other reason beyond that for me to have an affinity foot, but I like it. So if you can get up to Bozeman, Montana. There's Kansas City Developer Conference, August 13th through 14th of Kansas City, Kansas. KCBC. 2025, which made me assume from the label that Kent c Dodds might be affiliated, but he is not.
-
-[45:42] It is not. Kent c Dodds conference. It's Kansas City Developer Conference. There is React Universe, September 2nd through fourth in Poland. Then September 16th and 17th, Wacon also in Poland back to back pretty much after Wacon. There's Cascadia Js up in Seattle, Washington, September 18th and 19th. So I think Squiggle conf is happening in Boston the exact same time.
-
-[46:07] I. Yeah, you've got SW Con, September 18th, 19th, Boston, Massachusetts. They are great. I plan to be there. This is slightly further afield for further down the line, but React Cons will be back in LA in Las Vegas. I. October 7th and eighth. So yeah, I was there last year and it was a pretty great time.
-
-[46:26] Definitely check it out. Although tickets are expensive and lottery system, so good luck. That's everything we got for you this month. Thank you so much for joining us. We will be back next month. I hesitate to promise on Wednesday because we have not done that in a minute, but maybe next month on Wednesday here in the live stage, or we'll be back in your podcast feed just as soon as we can after that.
-
-[46:46] Scheduling is hard. Yo scheduling is so hard. We gather sources from this week in React Bites. Do Dev React status, Next.JS Weekly the React JS subreddit. And here in react to plugs from the Tech News Andres channel. If you have any news that you wanna share with us. Tech Reads and News is a great place to do so, or you can send it to us at hello@reactiveflex.com.
-
-[47:09] If this is a show that you get value from and would like to support, one of the best ways you can do so is give it a review on whatever platform you listen to, listen to it on, and just share it with friends, share it with coworkers. Go to a meetup and say, Hey, there's this great podcast. I like. Yeah, thanks so much for listening.
-
-[47:25] We'll see you next month. Take care.
diff --git a/src/transcripts/tmir-2025-07.md b/src/transcripts/tmir-2025-07.md
deleted file mode 100644
index 0bc5808..0000000
--- a/src/transcripts/tmir-2025-07.md
+++ /dev/null
@@ -1,669 +0,0 @@
----
-title: "TMiR 2025-07: Vercel shakeups, new React Compiler docs"
-date: 2025-07-28
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-# This Month in React: July, 2025
-
-- [[01:17](#new-releases)] New Releases
- - [[01:20](#rn-reanimated-v4)] [RN Reanimated v4](https://blog.swmansion.com/reanimated-4-stable-release-the-future-of-react-native-animations-ba68210c3713)
- - [[08:46](#rn-ignite-toolkit-v11)] [RN Ignite toolkit v11](https://shift.infinite.red/announcing-ignite-11-bison-f2802a85f94d)
-- [[10:18](#main-content)] Main Content
- - [[10:21](#compiler-docs-are-merged-live-docs-and-config-api)] [Compiler docs are merged!](https://github.com/reactjs/react.dev/pull/7868) ([live docs](https://react.dev/learn/react-compiler/introduction), and [config API](https://react.dev/reference/react-compiler/configuration))
- - [[11:42](#expo-docs-say-its-on-hold-but-evan-bacon-says-expo-54-may-enable-the-compiler-by-default)] [Expo docs](https://docs.expo.dev/guides/react-compiler/) say it’s “on hold”, but Evan Bacon says [Expo 54 may enable the Compiler by default](https://x.com/Baconbrix/status/1949714155482841094)
- - [[12:45](#oh-no-more-function-directives-use-memo-and-use-no-memo)] Oh no — [more function directives](https://react.dev/learn/react-compiler/incremental-adoption) , “use memo” and “use no memo”
- - [[12:51](#directives)] [DIRECTIVES](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
- - [[13:13](#good-thread-on-some-history)] [Good thread on some history](https://x.com/en_JS/status/1948502925468467369)
- - [[14:19](#some-tech-discussion-on-the-complexities-of-making-react-compiler-work-with-oxlint)] Some tech discussion on [the complexities of making React Compiler work with Oxlint](https://github.com/oxc-project/oxc/issues/10048)
- - [[15:41](#directive-prologues-and-javascript-dark-matter)] [Directive prologues and JavaScript dark matter](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
- - [[18:01](#node-api-support-for-react-native)] [Node API Support for React Native](https://www.callstack.com/blog/announcing-node-api-support-for-react-native)
- - [[21:49](#vercel-shaking-things-up)] Vercel shaking things up
- - [[22:02](#leerob-is-at-cursor-now-five-things-he-learned-at-vercel)] [Leerob is at Cursor now](https://x.com/leerob/status/1943446393819177342) — [Five Things \\[he\\] Learned at Vercel](https://leerob.com/vercel)
- - [[27:43](#swc-creator-leaves-focusing-on-swc-for-a-while)] [SWC creator leaves, focusing on SWC for a while](https://x.com/kdy1dev/status/1941129219293225273)
- - [[28:01](#sam-selikoff-just-joined-to-do-content-and-stuff)] [Sam Selikoff just joined to do content and stuff](https://x.com/samselikoff/status/1943325592260092298)
- - [[28:23](#nuxt-acquired)] [Nuxt acquired](https://x.com/nuxtlabs/status/1942575789645640071)
- - [[29:58](#netlify-staff-eng-philippe-serhal-replies-to-the-vercel-deployment-adapters-rfc-from-april)] [Netlify Staff Eng Philippe Serhal replies to the Vercel Deployment Adapters RFC from April](https://github.com/vercel/next.js/discussions/77740#discussioncomment-13893373)
- - [[30:48](#ryan-carniatos-react-and-signals)] [Ryan Carniato’s “react and signals”](https://www.youtube.com/watch?v=VgGl9i-OBBI)
- - [[33:09](#react-native-unistyles-30-released)] [React Native Unistyles 3.0 Released](https://www.reactnativecrossroads.com/posts/introducing-unistyles-3)
- - [[35:39](#react-router-and-rscs-the-path-forward)] [React Router and RSCs: The Path Forward](https://remix.run/blog/react-router-and-react-server-components)
- - [[36:57](#parcel-writeup-for-server-components)] [Parcel writeup for Server Components](https://devongovett.me/blog/parcel-rsc.html)
- - [[37:26](#wip-vite-rsc-plugin-support)] [WIP Vite RSC plugin support](https://github.com/vitejs/vite-plugin-react/issues/531)
-- [[38:15](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[38:35](#corbins-history-of-react-through-code-deep-dive)] Corbin’s [“History of React Through Code”](https://playfulprogramming.com/posts/react-history-through-code) deep dive
- - [[39:06](#tkdodos-thoughts-on-when-usecallback-is-useless)] [TkDodo’s thoughts on when `useCallback` is useless](https://tkdodo.eu/blog/the-useless-use-callback)
- - [[39:26](#eslint-config-prettier-compromised-as-part-of-an-npm-supply-chain-attack)] [`eslint-config-prettier` compromised](https://safedep.io/eslint-config-prettier-major-npm-supply-chain-hack/) as part of an [NPM supply chain attack](https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise)
- - [[40:48](#expo-router-demo-by-evan-bacon-ai-rscs-expo-router)] [Expo Router demo by Evan Bacon AI \+ RSCs \+ Expo Router](https://github.com/EvanBacon/app-that-builds-apps)
- - [[41:16](#some-tech-details-on-how-meta-serves-react-pages)] Some tech details on [how Meta serves React pages](https://www.reddit.com/r/reactjs/comments/1ltbw2e/how_does_facebook_serve_react_pages/)
- - [[41:40](#nitro-image-library-for-react-native)] [Nitro Image library for React Native](https://github.com/mrousavy/react-native-nitro-image)
- - [[42:08](#a-very-hacky-way-to-test-rsc-components)] [A very hacky way to test RSC components](https://www.nico.fyi/blog/how-to-test-react-server-component)
- - [[42:31](#a-good-technical-dive-into-improving-inp-in-a-next-app)] [A good technical dive into improving INP in a Next app](https://medium.com/preply-engineering/how-preply-improved-inp-on-a-next-js-application-without-react-server-components-and-app-router-491713149875)
- - [[42:51](#extra-css-properties-in-react-native)] [Extra CSS Properties in React Native](https://github.com/facebook/react-native/pull/52284)
- - [[43:16](#chrome-137-adds-if-support-in-css)] [Chrome 137 adds `if` support in CSS](https://developer.chrome.com/blog/new-in-chrome-137)
- - [[44:50](#react-devtools-for-firefox-may-not-get-updated-due-to-review-restrictions)] [React Devtools for Firefox may not get updated due to review restrictions](https://bsky.app/profile/ricky.fm/post/3ltkxpo5ewk2i)
- - [[46:29](#both-oxlint-and-biome-are-investigating-typed-lint-rule-support-biome-v2-tsgolint)] [Both `oxlint` and `biome` are investigating typed lint rule support](https://www.solberg.is/fast-type-aware-linting) ([Biome v2](https://biomejs.dev/blog/biome-v2/), [tsgolint](https://github.com/oxc-project/tsgolint))
- - [[47:49](#remix-v3-dev-branch-containing-support-packages)] [Remix v3 dev branch containing support packages](https://github.com/remix-run/remix/tree/v3)
- - [[48:40](#react-native-wallet)] [React Native Wallet](https://blog.swmansion.com/introducing-react-native-wallet-90c1ee103d3e)
- - [[50:07](#deno-v-oracle-update)] [Deno v Oracle update](https://deno.com/blog/deno-v-oracle4)
- - [[51:23](#content-independence-day-from-cloudflare-theyre-blocking-ai-crawlers)] [“Content independence day” from Cloudflare](https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/) (they’re blocking AI crawlers)
- - [[52:04](#some-updated-static-hermes-perf-numbers-release-available-soon-being-tested-internally-at-meta)] [Some updated Static Hermes perf numbers](https://x.com/tmikov/status/1945348222110859500) release available “soon”, being tested internally at Meta
- - [[52:47](#state-of-html-survey-is-open)] [State of HTML Survey is open](https://survey.devographics.com/en-US/survey/state-of-html/2025)
-- [[53:26](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[53:29](#big-sky-dev-con-aug-2-bozeman-mt-usa)] [Big Sky Dev Con](https://bigskydevcon.com/) Aug 2 Bozeman, MT, USA
- - [[53:36](#kansas-city-developer-conference-aug-13-14-kansas-city-ks-usa)] [Kansas City Developer Conference](https://www.kcdc.info/) Aug 13-14 Kansas City, KS, USA
- - [[53:47](#react-universe-conf-sept-2-4-2025-wrocaw-poland)] [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025. Wrocław, Poland
- - [[53:57](#waysconf-sept-16-17)] [WaysConf](https://www.waysconf.com/) Sept 16-17
- - [[54:06](#cascadiajs-sept-18-19-seattle-wa-usa)] [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [[54:10](#squiggle-conf-sept-17-18-boston-ma-usa)] [Squiggle Conf](https://squiggleconf.com/) Sept 17-18 Boston, MA, USA
- - [[54:17](#react-conf-is-back-oct-7-8)] [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l)
- - [[54:22](#remix-jam-oct-10-toronto-canada)] [Remix Jam](https://remix.run/jam/2025) Oct 10 Toronto, Canada
-- [[54:33](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the July edition of this month in React, where we recap and digest all of the latest news and developments in React. React Native, and across the web. We're coming to you live from Reactive Flux, the place for professional developers using React. [00:00]
-
-I am a staff product developer and freelance community leader here in React Flux where I do community programs like these events and build tools to help keep the community operating. May be making more progress on one of those. So maybe I'll do a product announcement in the next couple of weeks or months maybe. [00:16]
-
-**Mark:** Hi, I'm Mark. I maintain Redux. My day job is at Replay where we've built a time traveling debugger and are currently trying to get in on the AI app generating craze. And other than that, I may moderate things and read too many articles. [00:32]
-
-**Mo:** My name is Mo. I head the mobile team at Theo. I'm an active member of the React Native community and I organize the React Native London Meetup and the React Native London Conference. Excited to be here. [00:46]
-
-**Carl:** Excellent. Yeah. We missed you Last month there was react native things to discuss. [00:58]
-
-**Mark:** We had no idea what we were talking about. [01:01]
-
-**Carl:** Not even a little bit. We basically just punted on it. Great. Cool. [01:03]
-
-I'm gonna skip job market stuff. I don't think I'm gonna do that anymore. 'cause like who even knows what's going on? The jobs are wild and the indicators are. Too fuzzy to really be that useful, I think. [01:07]
-
-## New Releases
-
-**Carl:** Mo, tell us about some React native new releases. [01:17]
-
-## [RN Reanimated v4](https://blog.swmansion.com/reanimated-4-stable-release-the-future-of-react-native-animations-ba68210c3713)
-
-**Mo:** Cool. So we recently had React Native Reanimated version four being released. So for those of you who are sort of avid React native developers, you'll know that React Reanimated is sort of the defacto way. To be able to animate elements, layouts and whatever you have inside of your React native applications. [01:20]
-
-So the team's been hard at work. Animates has been around as a package for, for several years now, and they've been iterating on it and making it better and better over time. There's a general push that you'll sort of know from the previous episodes over the last year or so towards sort of unifying React native and react in the web as much as possible. [01:40]
-
-And so CSS transitions and animations are sort of becoming a key part of Reanimated as well, so that the APIs and the way that you can animate things in Native world are as similar as possible. Obviously there's some limitations that can't make it one-to-one, but as similar as possible between web and mobile. [01:59]
-
-And one of the other things is now that we're in this world where you could use React native on web and mobile, trying to find a way to have performance. Web-based animations and transitions is quite important as well. And Reanimated has been working on this under the hood so that when you do use reanimated in your React Native universal app, it actually has performant animations on the web as well, not just on native devices. [02:18]
-
-One of the challenges in the past has been that it's not quite great on the web because it would use JavaScript to orchestrate animations. Not really great, and really, really bogs down the performance of your app on the web. So some good work being done there. A few other things to mention is that Worklet is a part of Reanimated as well. [02:41]
-
-It's, it's a way to basically allow some level of multithreading in your apps. It kind of formed as a need of reanimated itself, but they've made it sort of an open public API that you can access for other multithreading needs that you may have. So they're trying to move that. Across into sort of a separate library and start to separate that up because it's not just useful for reanimated or animations. [02:59]
-
-It's useful for a whole bunch of other stuff like background fetching and, and you know, computationally heavy tasks that you need to run behind the scenes. Other things to mention is that Reanimated used to be this huge package and once you had, you know, imported one thing and Reanimated, everything was imported and so obviously that affects things like your app bundle size. [03:21]
-
-They've now took an approach to make it modular so that you can import. And Bobs of Reanimated rather than the whole thing. Obviously it's not just a JavaScript sort of tree shaking thing that matters here because we're in Native World. There's also sort of the native compiled code and you need to be able to modularize that as well. [03:38]
-
-So it, it's not necessarily a straightforward process for the team, and I appreciate that. It was probably quite complex to decouple a lot of this code and separate it up into different packages, both on the native layer and the JavaScript layer. [03:54]
-
-**Carl:** What does that affect on a native. Package, I guess like app, total package size, or does it affect like startup performance and things like that? [04:04]
-
-**Mo:** It, it can affect both. Mainly the app total size that you would need to download is, is a key thing. It can also affect, like you say, the startup time, albeit startup time is largely sort of. Handled by Hermes, the engine that's been created for React Native specifically because it, it sort of optimizes to, to avoid large startup times as a result of having a big app bundle. [04:11]
-
-But it's really mainly the, the, the bundle size. And again, when we're going into this sort of web and mobile world where you use the same packages across the board, modularizing as well on the web, even though you'll have tree shaking, is going to be good practice so that you're not importing a whole bunch of stuff that you don't need. [04:33]
-
-Lastly, and I, I think this is. Something that everyone is quite passionate about in the React native ecosystem and has been a challenge is shared element transitions. So shared element transitions is sort of the transitions that you might be familiar with in the native world where an element is is sort of present and is animated from one screen to another. [04:49]
-
-So when you navigate from one screen to another, there's this sort of shared element. So it might be like an image you click on and you navigate to a sort of detailed view of that image. You have a navigation that happens in the background. But you want to have these on separate screens, but you wanna kinda keep that seamless expanding of the image animation as an example or transition. [05:08]
-
-This is very difficult to do in React Native. You can kind of achieve it in some hacky ways, but it's sort of on the app developers to figure it out. There's not been like a unified API that you can use and it's usually quite hacky and doesn't work most of the times. They are working on this, [05:26]
-
-**Carl:** would that be stuff like flip animations, like first, last, interpolate, play? [05:38]
-
-**Mo:** No, I don't think it would be flip animations. The examples that I would give is, you know, like in Instagram as an example, if you're on the, the search page and you see a set of posts that are sort of laid out in a grid and you click on one of those posts, it expands out and takes over the whole screen. [05:43]
-
-Right. [05:57]
-
-**Carl:** I meant more like would the hacky interpret in the hacky implementation of. what should be a shared element transition? Would that be, is that the kind of thing somebody might use flip for? [05:58]
-
-**Mo:** I'm not sure, I haven't actually seen flip, but there are some approaches where people have been sort of tapping into the native layer to be able to do that manually, but it's not gonna be quite extensible putting some tags and then using the native layer to do those transitions. [06:08]
-
-So there's a few different approaches that I've seen people do some sort of like third party libraries that people have created as POCs more than anything is how I've seen it done. The, the, the gist of it is that there isn't really like a. Standardized well-defined and like well tested API to do this in React Native. [06:20]
-
-And so that's what the Reanimated team have been working on. It's not out yet, but they've said that they're gonna be releasing it as part of this major release cycle. So four dot something will have. Some support for shared element transition, still TBC, but keep your eyes open for that one. [06:37]
-
-**Mark:** Cool. [06:52]
-
-Honestly, that whole discussion reinforces how many things people are doing that I have no experience with whatsoever. [06:53]
-
-**Carl:** Love that. Yeah. I guess just to close the loop a little bit on like flip animations, like it reminds me a lot of shared element here. 'cause I guess like shared element means that it doesn't like vanish. [06:58]
-
-You know, it's one thing persists. From this state to that state. That's my general understanding of it. And how I had done that in 2017 was, so you've got the current state, you've just rendered, you have something up and then you re-render and you get the new state. Then you have some abstraction that cracks the old state after the new state shows up and says, okay, this element is tagged with this animation, you know, indicator. [07:09]
-
-And that indicator has now gone to this element in this new state. It used to be here. Now it's here. Let's measure it triple eight, you know, the old size versus the new size. And then do Aran smooth transition, you know, generate a CSS animation to make it look like it's the same element. [07:37]
-
-**Mo:** Yeah, it gets a little bit more complicated in the native world because these are different sort of screens that are different view nodes on the native layer, you'd need to have a little bit more control over how you do that on the native layer, the native layer might override it. [07:54]
-
-If you write that JavaScript logic as an example, it definitely needed some native components to be able to handle it. Under the hood, the algorithm and the native layer will do something very similar, which is first screen, screen A has this size for this element. Screen B has this size. Let's look at the positions and interpolate the values and the, the zoom of it to match the target size as we're migrate, as we're opening up the new screen as an example. [08:07]
-
-**Carl:** Right. Oh, interesting. Okay. Sure. On native, there are things already doing that for you, so you don't need to hack into the, into that. You just need to actually support it. Cool. Makes sense. Okay. [08:29]
-
-**Mark:** Probably just as well. We really didn't have all that many new items and new release items this month, given that we just sort of deep dived on that one. [08:40]
-
-## [RN Ignite toolkit v11](https://shift.infinite.red/announcing-ignite-11-bison-f2802a85f94d)
-
-**Mark:** So one other thing from the React Native world, the Infinite Red has a very long running boilerplate toolkit called Ignite, and they just put out version 11. The big news for this one is it. Only sports, the new architecture. It's been bumped to E Expo, SDK 53, some changes to the theme implementation and they've made it bring your own state management. [08:46]
-
-They used to default to MobX State Tree and now they've tweaked it. So you can pick and choose how you want your state to be handled within the new app. [09:06]
-
-**Mo:** There's a little bit of context here, which is that the maintainers of this library, infinite Red, have been very opinionated on Malbecs being the best sort of tool for React Native. [09:14]
-
-State management there. There's some some reasons behind that. Like Mob State Tree is quite good in terms of sort of heavy memorization and that can really affect performance if you don't have stuff like that and React native or you're not careful. So I think they were trying to set some practices that they were used to. [09:25]
-
-**Mark:** And also I believe Jamon from Infinite Red was the maintainer of MobX State Tree for a number of years, and he either still is or recently handed it off to somebody I think. [09:41]
-
-**Mo:** Might be that he was maintaining it to some degree. Yeah. [09:51]
-
-**Mark:** So I mean there was, there was a very understandable preference there. [09:54]
-
-**Mo:** So the main maintainer of MobX and MobX State Tree as far as I'm aware is Michelle West Streett. [09:56]
-
-From WHO, who works at Meta, [10:00]
-
-**Mark:** I think Michelle handed off MobX State Tree to into Jamon a number of years ago. Okay, cool. Didn't know about that really. That's fair enough. [10:02]
-
-**Carl:** Oh, interesting. I didn't know that [10:08]
-
-**Mark:** he spiked MobX State Tree. And then it's like, okay, I've, I've proven I can build this, but I don't have time to maintain it would someone else like to? [10:10]
-
-Cool. [10:17]
-
-## Main Content
-
-**Mark:** Onto the main content for today? [10:18]
-
-## [Compiler docs are merged!](https://github.com/reactjs/react.dev/pull/7868) ([live docs](https://react.dev/learn/react-compiler/introduction), and [config API](https://react.dev/reference/react-compiler/configuration))
-
-**Mark:** The big news this month is that the React team has written completely brand new docs for the React compiler. Not only did they put them up as a PR this month, that PR has been merged and the new docs are now live. Previously there was just a single page under the installation setup section of the React Docs that gave some amount of details, and now the React compiler has its own top level section with multiple pages under both the learn and reference sections of the React docs. [10:21]
-
-These sections cover a lot of things. What is the compiler? What does it do? How does it work? Should I try it out? What build tools do it? Does it work with? How do I install it? How can I incrementally adopt the compiler? As well as some reference section information, talking about configuring it and some of the concepts it includes. [10:54]
-
-And even like if I'm a library author, should I pre-compiled my library bundle to make use of the compiler? So it's very clear that they've been looking at some of the discussion threads where people have complained that, you know, it doesn't feel like it's ready for adoption yet. I don't know if it, you know, I don't know how to configure it. [11:16]
-
-And they've taken a lot of that to heart and put together some pretty good docs to try to actually address a lot of those points. [11:34]
-
-## [Expo docs](https://docs.expo.dev/guides/react-compiler/) say it’s “on hold”, but Evan Bacon says [Expo 54 may enable the Compiler by default](https://x.com/Baconbrix/status/1949714155482841094)
-
-**Mark:** We noted that the, if you look at the expo docs, there is currently a section that says that their integration with the React compiler is on hold, but that may be superseded because I saw a tweet from Evan Bacon just earlier today where he said that we are actually going to enable the React compiler by default in Expo version 54. [11:42]
-
-And along with that, the compiler docs themselves in the introduction section. Actually say like, should I try the compiler and is it safe to use? And they specifically say at this point, we encourage everyone to start using it. It's still optional, but it's in release candidate. It is safe to use. It's been tested in production and we really would like people to actually try it out. [12:05]
-
-Of course they do. [12:30]
-
-Oh yeah. But I mean it's, it's a pretty big vote of confidence that this is not just a whim. That it is something they're very serious about, that it is basically ready for release and that they would like to see the ecosystem start adopting it. [12:31]
-
-**Carl:** Yeah, makes sense. [12:43]
-
-## Oh no — [more function directives](https://react.dev/learn/react-compiler/incremental-adoption) , “use memo” and “use no memo”
-
-**Carl:** I am not super thrilled about seeing more function directives being introduced here. [12:45]
-
-## [DIRECTIVES](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
-
-**Carl:** Like I'm on record for like the past two years here, being frustrated with introducing more and more directives, and so seeing now basically a compiler flag for memorize or don't memorize this. As the, uh, incremental adoption method. I just don't like it. It's, it feels like magic. It feels gross. I don't like it. I don't like directives. They scare me. [12:51]
-
-## [Good thread on some history](https://x.com/en_JS/status/1948502925468467369)
-
-**Mark:** Couple other compiler bits of news. There was some discussion on Twitter, I believe, where Joseph from the React compiler team gave a little bit of background on who had worked on the compiler, some of the timelines and some of the influences, and then the compiler right now has a couple limitations in terms of tool support. [13:13]
-
-One is that while the 90% of the compiler code is its own independent true compiler, currently the only way to integrate with that and actually use it is via a babble plugin shell around it, which also means you have to have babble. In your build pipeline, and a lot of people are not happy about that. We got rid of babble. [13:33]
-
-We use, we use SWC, we use, you know, whatever other, you know, ES build something that's not babble anymore. And so there's been lots of questions about, you know, when will they get around to offering a non babble integration? No timeline on that yet. But as a related part of that, the lint rules that React offers are also ES lint based. [13:55]
-
-## Some tech discussion on [the complexities of making React Compiler work with Oxlint](https://github.com/oxc-project/oxc/issues/10048)
-
-**Mark:** And we now have other winters like biome and oxalate that are not ES lint and not esent compatible. So there was a pretty good thread between the React compiler team and the oxalate team talking about like what would it take to make React compiler and the React ES lint rules. Runnable inside oxalate, and there's a bunch of low level technical details about, you know, js rust interop and, and some of the complexities that might be needed there. [14:19]
-
-So the answer is probably not anytime soon, but there's discussions about what it might take to make that happen. [14:48]
-
-**Carl:** Yeah, and circling back to your, you know, good thread with like some timeline and influences and whatever frustration I have, this is like such a, this is exactly the same problem that React and I guess web and like development in general has had for a long time. [14:55]
-
-But like all of that happened on Twitter and like that's great knowledge and such good resource. But the guy who asked the question asked it on his private alt. So like, if you are not one of the, you know, 1100 approved people that he has granted access to see his thoughts, you can't see what was asked, just the response. [15:09]
-
-So at least you can see the response. That's nice. But I wish they'd put something like this in like, I don't know, an introspective blog post or whatever. So. I'm just gonna keep shouting at clouds throughout this episode, I think. Cool. Cool. Let's move on though, [15:28]
-
-**Mark:** even before we get there. [15:40]
-
-## [Directive prologues and JavaScript dark matter](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
-
-**Mark:** I found the article I was looking for, it was indeed in Tech reads the news a few weeks ago. [15:41]
-
-This was in linking a post on directives, prologues and JS Dark Matter, which was an archeological explanation of how things like JSX, pragmas and function directives and magic comments. Have all been used to indicate to build tools, Hey, do something different with this code than what you would expect. [15:45]
-
-Just reading it. [16:05]
-
-**Carl:** Love that. That is actually really good. And like basically this is all just communicating with different levels of abstraction between like runtime and source code. So it's like, I don't know, the linter or the formatter or the, I don't know. I guess you don't really do tests so much there, you just do it elsewhere. [16:06]
-
-But the compiler, or transpiler compiler is now a fuzzy, overloaded term, and I guess they all make sense for one reason or another, but something about directives and the way that they like persist through. I prefer a magic comment, like at least a magic comment is like very clearly something like not runtime. [16:24]
-
-I don't know, something about it feels wrong. The [16:41]
-
-**Mark:** fact that a directive is just a string hanging out there. [16:44]
-
-**Carl:** I dunno. It seems weird. And since it is just a string, like why not a magic comment? Ah, I don't know. Maybe there was some kind of weird esoteric, like the compiler, you know, the, all the various compilers and whatever, transpilers, and ASTs transformers are all like, maybe they muck with comments and whatever, but also like the compiler requires that you put it first in your Babel so it gets the untransformed code anyway, so that doesn't sound right to me. [16:47]
-
-I don't know. Weird doesn't seem necessary. I guess the root of my angst here is that like when they introduced the "use strict" directive, like when they introduced the concept of a directive, they said, we're never gonna do this again. Like, don't do this. This is bad. We should, we shouldn't have had to do this, but we did because weird legacy concerns don't do any more of these. [17:13]
-
-**Mark:** And then the community decided, okay, now we got a new mechanism to play with. [17:32]
-
-**Carl:** We got like, how many do we have for React now? Like. I can think of four off the top of my head. [17:36]
-
-**Mark:** Client server memo. No memo. [17:40]
-
-**Carl:** Yep. Okay. Maybe four, but like, come on. That's 400% increase from one. Come on. [17:43]
-
-**Mo:** Now you can have two at the top of one file, which is gonna look weird. [17:49]
-
-It's gonna take some time getting used to that one. Wait, [17:52]
-
-**Carl:** can those even, are the, is that even compatible? 'cause it's gotta be, the directive has to be the first line. I [17:54]
-
-**Mo:** don't know how that would even work. Moving right along. [17:58]
-
-## [Node API Support for React Native](https://www.callstack.com/blog/announcing-node-api-support-for-react-native)
-
-**Mo:** Alright, so back into React Native World. The folks at call Stack have been working on some other projects under the, under the smoke screens, and it's some cool stuff that they've released. [18:01]
-
-They've basically enabled Node API support at a very basic, primitive level. They're, they're working, still working on this. They've made some good headway with this. So they're bringing Node API support into React native. Now, not to be confused with node itself, node API is basically like a mechanism by node js that allows you to use C based languages to interact from JavaScript code to call native code. [18:12]
-
-And so you can write native add-ons in CC plus plus. Even rust or swift. And then they can be used and ingested by JavaScript applications. So there's a few reasons for doing this and it, it really goes more into the internals of React Native. And you know what this means for library maintainers, for built tool maintainers, and for really meta itself as well. [18:38]
-
-But the two key things here is faster build times. And closer convergence with native web libraries that may already exist and be using the node API mechanism. So at a first level build times, and I think this is the bit that will affect users more than anyone else is. Basically in the rate of world today, most native modules are actually distributed a source. [18:59]
-
-So every time you make a build, you actually have to compile it all and do the build step, which is quite long. Building a typical rec native app somewhere around 10 to, if you've got a massive scale app, it could takes several tens of minutes to actually do the full build of the app, right? But it's a long, long time now. [19:22]
-
-You don't need to do this for like your development workflow typically, or that often, because you wouldn't change native dependencies every day. You would just do this when there's a new native dependency that's been introduced, but it's still a significant amount of time. Right? And so the idea is if we can get some of these prebuilt. [19:41]
-
-Using a mechanism like the node APIs, then we can bring this time down quite significantly. And so one of the things that they ran as a test was for a basic sort of React Native core app that you know is just having the basics of React native within it. They think that they could bring down. The build time to close to seven seconds, which would be insanely fast in comparison to what it's today. [19:59]
-
-So this could be some really cool stuff that's down that's coming down the line. The other side is that there is already an ecosystem of node API compatible sort of applications and run times, and so, so many sort of libraries. Web API libraries like Web RTC or Web Audio Canvas. These are implemented with node API. [20:21]
-
-Now, they're not going to be direct one-to-one mappings for native, but there is already an initiative to try to, to try to align on the web API spec. And so this is sort of another part of that puzzle. And so if you bring these two together, suddenly we can use sort of web APIs and React native, and it could be a really, really cool future to look into. [20:42]
-
-None of this is. None of this is sort of like fully there, and there's gonna be, this is a long term effort, but it's something that they announced this month, and it's quite exciting. [21:02]
-
-**Carl:** I've had enough struggles with native binaries on desktop where they're, you know, like intended to be compiled for just like, like mostly across, like upgrading, upgrading a version of that, or node versions or whatever. [21:11]
-
-But I, I've had enough struggles and complications there to be wary. Of what the actual experience of using this will look like. But this is, this is really cool. This just even having made enough progress at this to announce it and like meaningfully talk about it as a thing they desire is pretty cool. [21:25]
-
-Very hard, really hard problem. I'm curious how they're implementing it. [21:43]
-
-**Mo:** It's definitely not trivial. [21:48]
-
-## Vercel shaking things up
-
-**Carl:** Cool. Alright, moving on a bit. So there's been a bunch of Vercel things this week, a fair number of departures. I'm sure people are coming and going all the time and we just, you know, we can't get a comprehensive list of that. [21:49]
-
-## [Leerob is at Cursor now](https://x.com/leerob/status/1943446393819177342) — [Five Things \\[he\\] Learned at Vercel](https://leerob.com/vercel)
-
-**Carl:** But they, they had a couple of relatively high profile departures in the last month, starting with the most notable Lee Robinson, who has been there for. Five years, a long time. Was he there before COVID? [22:02]
-
-**Mark:** Not sure on the timeline. Like it, it felt like he'd been there much longer than that, but apparently it has only been five years. [22:15]
-
-**Carl:** Yeah. Okay. No, you're right because he, he put out a blog post. Well, anyway, I'll, I'll stop speculating on the timeline, but to me, he is highly identified. With Versel, like, you know, if I think of Versel, I think of, uh, Guillermo, Roush, and Leero, just like by volume of activity and like prolificness in content and social media interaction and blog posts and example resources. [22:21]
-
-So just all of it. So he has now left Versel and is working at Cursor, which like. That seems great, at least in terms of like mind share and hype and you know, alignment, potential, alignment with future, whatever. Cursors is definitely a really hot company right now. I've had some private conversations of with like, can they keep doing that? [22:45]
-
-'cause at the end of the day they're a fork of VS code and like fork of a large project with 30 people working on it. Which I think is in the ballpark of how many employees Cursor has versus like Anthropic, which is, you know, a giant, huge beast with all of the money. So like it's cool. Great for him. [23:05]
-
-Definitely there's a lot more like oxygen in the room in terms of excitement and like potential at cursor. I think so. Cool. I'll be keeping an eye on that. I use cursor. It's nice, so he'll still remain in my, I don't know, professional spheres. But yeah, he had a really good blog post that he put up called, UH, five Things I Learned From Five Years At Versa. [23:24]
-
-I appreciated it. His number one was go hard at work, then go home, and he closes it with, when I'm offline, I'm offline. I'm a hundred percent focused on my wife and daughter. To be clear, I still get this wrong sometimes. It's a never ending pursuit of work, life, harmony, takeaway. You can work really hard and set clear boundaries. [23:46]
-
-I'll say That's hard. I struggle with that. I don't, I don't have a wife, I don't have kids. So like in that section he talks about like responding to tweets from the beach on his honeymoon and like, yes, I want to believe that you can work really hard and set clear boundaries to where you're not working on vacation doing, you know, social media comms work from the beach, but also like if you're not there. [24:03]
-
-Like, people aren't gonna wait three days for you to get back from vacation to, you know, get the authoritative answer. Like, if they ask a question, then like, the person who is Johnny on the spot answering it in their time of need, like they are gonna get the, I don't know, the kudos, the energy they're gonna, you know, people are gonna start gravitating towards them for future questions. [24:27]
-
-I'm like, that's. This going so hard is how Leero managed to get that level of status, like in my own brain. And so I wanna believe you can work really hard and set clear boundaries. I'm not always so sure about that. I, I dunno. I wrote, I actually wrote a little blog post kind of on that subject almost exactly a year ago. [24:47]
-
-I'll link it here. I probably won't put it in the transcript. Just kind of talking about that general thing and like I, I had a kind of similar experience to what he describes here of like, going really hard and like poor boundaries and like burnout and all of the, a lot of the benefits, a lot of the costs. [25:06]
-
-And what I kinda realized is that like, I don't know that I could have achieved the kind of success that I got without that level of burnout and I don't know, poor boundary setting because like, it's because I gave. All of my attention to maybe not just work, like some of, a lot of my attention, you know, the full-time work, but also investing in things like reactive flex or just learning new tools and staying on top of the cutting edge outside of work. [25:23]
-
-Like that was really poorly boundaried and like fully throughout my twenties, I ignored a lot of myself. I just really think that that is, I wanna believe that you can succeed and achieve big success without giving up that kind of, I don't know, intimacy with yourself. But I don't know that you can, I don't know, it seems really hard. [25:50]
-
-And it, it just notable to me that like the only people I see talking about that and like saying things like, you can work really hard and set clear boundaries are the people who had poor boundaries, achieved success, and are now reflecting on it. So, I don't know. [26:09]
-
-**Mark:** Yeah. It, it is tough, but I, I have a, I have a lot of respect for Lee Rob and that the work and effort that he's put in, when I just think of the word derel, he is the first that comes to mind. [26:22]
-
-He, he's always, you know, omnipresent in any kind of Reddit or Hacker News or Twitter thread that mentions Versel and Next. And, you know, even if you maybe, you know, at times disagreed with, you know, what he was saying or representing the company wine, he absolutely like did a great job of being there and answering questions and, and being involved in reaching out. [26:33]
-
-It's definitely a loss for Versel and when I wrote my React Community article, you know, recently, I had a line in there about Versal had a large Dere team that updated the next docs, and he corrected me. It's like, no, there were two of us at that point. I was like, oh, whoops. I got that wrong. It seemed like you had a large team because you were doing so much work. [26:55]
-
-**Carl:** Right? So, yeah, I don't know. From the comment, from the, from chat, from re Sam, bit of taking advice from lottery winners, vibe occasionally like, yeah, that's, that's what it is. It sounds like survivor bias, things like that. Anyway, this is, we're already like kind of far afield from where we started here. [27:21]
-
-This was talking about Versel and some of their updates. This was a good piece. Lee Rob, wish him the best at cursor. I'll be paying attention still. [27:35]
-
-## [SWC creator leaves, focusing on SWC for a while](https://x.com/kdy1dev/status/1941129219293225273)
-
-**Carl:** The, uh, creator of SWC also left Versal. He's taken some time to, to rest and focus back on, uh, SWC again, so that's great. I'm not as familiar with him as a, you know, individual human, but I am familiar with s wc. [27:43]
-
-So cool. Good luck to him. Love that. [27:59]
-
-## [Sam Selikoff just joined to do content and stuff](https://x.com/samselikoff/status/1943325592260092298)
-
-**Carl:** And another prolific react ecosystem speaker and like educator, Sam Selikoff joined Versal to do content and some other things. His Twitter feed is all like, all about ramping up and like, you know, spinning up on a new team. So that's, that's a fun, that's a fun moment in time. [28:01]
-
-Team transitions and gathering context in a new spot. [28:20]
-
-## [Nuxt acquired](https://x.com/nuxtlabs/status/1942575789645640071)
-
-**Mark:** And then overall, and not, not react, but adjacent. So next is the view ecosystem equivalent to next Js. And Versel had already picked up, you know, rich Harris who builds Svel, possibly one or two other non-reactive framework authors as well. And VL actually just acquired whatever group or company has been behind N and is hiring all of the developers, including Daniel Grow, who I think is the, the lead. [28:23]
-
-Developer maintainer for N So you know, Versal is not just about react like they, they are sort of putting their money where their mouth is and trying to back many different tools that, you know, build apps and of course can be run on versal. That's [28:55]
-
-**Carl:** got me curious about what kind of like corporate structure is behind Nuxt. [29:11]
-
-'cause like, you know, if it's individual developers then like. You can't acquire that, you just hire them. [29:16]
-
-**Mark:** I think next Labs may be an actual company, but I don't know how much of a like profit seeking company it is versus some kind of little holding thing. [29:21]
-
-**Carl:** Right. I'm now, I'm on the next website. I see next UI Pro, A hub for managing apps. [29:29]
-
-So I guess like deployment and then like a visual editor. And I see some reference to courses and stuff too, so like, yeah, that sounds like a business. That sounds like they're selling products. Kind of a mishmash of various different open source monetization techniques there. So. Cool. Nice. That's good to know. [29:36]
-
-I appreciate that. Love someone who's trying to take a project and turn it into a business Relat. Another smaller update. [29:50]
-
-## [Netlify Staff Eng Philippe Serhal replies to the Vercel Deployment Adapters RFC from April](https://github.com/vercel/next.js/discussions/77740#discussioncomment-13893373)
-
-**Carl:** This is like barely an update, but I've been tracking A an RFC, actually an RFC that Lee Robb started back in April on deployment adapters for next from Versal, basically making it. [29:58]
-
-More robust and reliable, I guess, to deploy next projects to infrastructure that isn't hosted on Versal. So the, a staff engineer from Netlify gave a response that's pretty lengthy, pretty serious, you know, it's got like, you list six gaps and 10 questions and four suggestions, mostly minor suggestions. [30:13]
-
-It's just cool to see that moving along slowly and I question the momentum now that Lee Robb is no longer there. It's just really hard to hand off major projects like that, major initiatives like that. But yeah, that's cool. Neat. Love to see it. [30:32]
-
-**Mark:** Okay. Somewhat smaller item, but definitely worth calling out. [30:45]
-
-## [Ryan Carniato’s “react and signals”](https://www.youtube.com/watch?v=VgGl9i-OBBI)
-
-**Mark:** So Ryan Carniato, the author of Solid, is, you know, pretty much the world's foremost expert on signals as a state management mechanism. And there was a lot of back and forth and chatter, and I think we even referred to some of it in our, in our last talk about like Ryan for and Michael Jackson from Remix were kind of questioning like, why does Signals exist? [30:48]
-
-Why do you know? Why do these different frameworks look sort of the same? And I think somewhat inspired by some of those questions and discussion. Ryan put together a 10 minute video on React and Signals what every React developer should know about signals. And Ryan like me is very big on history and context and explaining how we got from past tools and decisions to current tools and decisions. [31:09]
-
-He goes into some, some of the history of signals, you know, they originated with early JavaScript frameworks like Knockout, but the concepts and implementation of signals have evolved significantly in the last 15 years ago. And so he talks about some of the actual technical advantages of signals. And then he also does some, some myth busting. [31:36]
-
-You know, he pushes back and says they're not magic. They do scale. A lot of other frameworks like Angular and View rely on signals to make them faster. And he also talks about comparisons between like, what's the difference between three ACT compiler and signals or reacts virtual dumb in signals. And I think what a lot of that sums down to is that in react. [31:56]
-
-The component is the smallest unit of update granularity, like you set state, at least one component will re-render the whole component renders, and then maybe only a few bit bits of it need to be applied, but you had to run the whole component to see what needed to change. Whereas with signals, it's this one value changed and it's more directly attached to the output. [32:19]
-
-And so only the bits of the output that actually relied on that need to be calculated. And it's not an earth shaking discussion, but given that there's been a lot of hype and discussion and arguing back and forth, it's a good overview. Looking at some of like. Some of the pros, cons, concepts, and myths around signals. [32:42]
-
-**Carl:** Yeah, I missed that. I need to give that a watch because I hold a number of myths and misconceptions about signals, and I would like to understand them better. Yeah. [33:01]
-
-## [React Native Unistyles 3.0 Released](https://www.reactnativecrossroads.com/posts/introducing-unistyles-3)
-
-**Mo:** Nice. Next up, we have another release. So we've been talking about this for a few months. On and off because it's been sort of an RC mode, but React Native Uni Styles 3.0 has finally been released. [33:09]
-
-Now there's a few points to sort of hit here. Uni Styles came out as sort of like a very performant, lightweight styling option for React Native because there's a lot of styling libraries that are quite complex and have a lot of. Stuff included within it. But the challenge with a lot of those is that it also comes with a little bit of a performance hit because you've got a lot more being bundled into your application. [33:21]
-
-Uni styles is, is sort of since then being this sort of lightweight JavaScript only implementation has has dug into this sort of performance space a bit more. And this newest release is really digging into the new architecture with with Fabric, which is the new render and it uses native code and c plus plus. [33:45]
-
-To basically bypass the JavaScript layer when possible and keeps us track of the styling dependencies in c plus plus, and we'll only update affected styles and components on the native layer as much as possible. Again, this is like some things are possible on the native layer. Some things aren't. In terms of styling and, and the visuals of it, but as much as it can possibly do, it does that in the native layer and avoids re-render. [34:03]
-
-The maintainer kind likens this to CSS on the web in that it's not handled by JavaScript, but it's a different layer that that handles it. On top of that, added a bunch of extra functionality through a babble plug plugin to handle things like theming, break points, orientation, font scale, and maybe even right to left styling if you need that for your app. [34:29]
-
-And so the by and large, the biggest thing here is that there is a performance boost and they've done some measurements to, to show how much of a performance boost you can get because of these safe three renders that would've previously been happening because of styling changes. Other noteworthy things to mention are that there's some new features around sort of variance or scoped themes and so on and so forth. [34:48]
-
-You can go read through the blog post in more details to understand what are the sort of more granular new features that exist. But also given that this is sort of a universal library that works on web and native, there is a new web functionality as well. Some web only styles, some pseudo classes that they've introduced and some support for class names that would be targeting the web. [35:10]
-
-So there's some stuff around web support as well, which is quite interesting. But yeah, that's Uni Cells 3.0. Give it a give it, give it a quick look. Cool. Love that. [35:30]
-
-## [React Router and RSCs: The Path Forward](https://remix.run/blog/react-router-and-react-server-components)
-
-**Mark:** Finally, we have a couple different, uh, react server component updates. The React Router team has been iterating for a while on their work in progress server component implementation, and they've put together a blog post describing a path forward, so they go through some details talking about the, and ways you would handle things like streaming UI or in lighting data in existing React router framework mode versus how you might handle it with their server component implementation. [35:39]
-
-And so there the summary is that. apparently they're going to revamp the framework mode to be built on top of their server component support. [36:10]
-
-They are still labeling the server component support as unstable, but they do want people to try it out and give it a shot. So looking at some of these examples, it looks pretty significantly different usage wise than say like the next app router. It maybe looks even a little more similar to how Parcel had almost like a pick and choose your own server component usage approach. [36:19]
-
-So it is very cool to see additional frameworks providing support for server components. As well as that we're starting to finally see some variation in how they might get used and not just. The way next does it is the only way to do it. [36:42]
-
-## [Parcel writeup for Server Components](https://devongovett.me/blog/parcel-rsc.html)
-
-**Mark:** Along with that, Devin Govett from parcel put together a pretty good article where he was talking about how parcel bundles, server components, and he goes into some background detail about like, you know, what is a bundle even do in the first place? How does it. You know, follow the, the module graph. How does it handle dynamic loading? How do the pieces fit together? And then talks about, okay, and since React server components is really a bundler driven feature, here's how server components actually rely and make use of some of those bundler aspects. [36:57]
-
-## [WIP Vite RSC plugin support](https://github.com/vitejs/vite-plugin-react/issues/531)
-
-**Mark:** And along with that, I think we've previously mentioned that there's been an in progress. Attempt to build RSC support directly into Vite's React plugin. And there's one person who appears to be steadily cranking away on trying to make that support possible. And I'm seeing a number of the to-do list items in the roadmap being checked off. [37:26]
-
-So I don't know how far along that is. But it seems like a pretty serious effort to make that happen. So the server component ecosystem is slowly filling out. [37:50]
-
-**Carl:** Yeah. Interesting. I see one of the to-do list items in that is moving waku to VJS plugin, RSC. That's interesting. 'cause I, I had understood, I mean, Waku was like. [38:02]
-
-A proof of concept implementation of like how to do a framework on RSC. So it's interesting to see that move from like custom one-off implementation to relying on a, you know, kind of delegating RSC support back into, back into Ved. Love to see that. That's cool.
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Okay, moving on to the lightning round. [38:32]
-
-## Corbin’s [“History of React Through Code”](https://playfulprogramming.com/posts/react-history-through-code) deep dive
-
-**Mark:** Lightning round. Corbin Crutchley, author of the Framework Field Guide ebook, put together a very lengthy deep dive, which I highly approve of, called the History of React through Code, where he goes back and looks at a whole bunch of different react features that were added over time and kind of argues that you know what these, the, these actually have sort of a. [38:35]
-
-Intellectual cohesiveness a like a design cohesiveness to them and that they, they all, it makes sense when you look at the sequence of, of features and how they were added. [38:56]
-
-## [TkDodo’s thoughts on when `useCallback` is useless](https://tkdodo.eu/blog/the-useless-use-callback)
-
-**Mark:** Meanwhile, TK Dodo, Dominic Dorf, Meister maintainer of React query, just put up a post today where he has some thoughts on when use callback is actually useless. [39:06]
-
-And I think his argument is actually, it's useless in a, in a lot more cases and you probably don't actually need it all that often. [39:18]
-
-## [`eslint-config-prettier` compromised](https://safedep.io/eslint-config-prettier-major-npm-supply-chain-hack/) as part of an [NPM supply chain attack](https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise)
-
-**Carl:** Cool. There was a NPM supply chain attack that was pretty interesting. I believe. The issue was that a couple of relatively high profile maintainers got phished, and yes, there's a phishing campaign on a typo, squatted, URL, which is NPN js.com. [39:26]
-
-So it's a couple of major. Maintainers got successfully phished through that, which then, uh, stole their NPM credentials and published malicious versions of packages. Yeah, so, uh, malicious releases included lin config, prettier. That's big Lin plugin, prettier. Think kit packager, core and nappy post install. [39:45]
-
-So the, like, most of those not so big. I, I haven't really heard of, heard about 'em, but yeah. Esly config, prettier, that's big. And they got version, they got major versions. 8, 9, 10. Eight, nine, and 10. Okay, so make sure you're not using version 10.1, 9.1 0.1. Anyway, if you're using those, check it. If you're using ES link config, prettier or ES link plugin prettier. [40:06]
-
-Make sure it's not a vulnerable version. Check your lock files. Yeah, that's not great. [40:29]
-
-**Mark:** I know one of the other redix maintainers got the phishing email and avoided it. It's definitely semi widespread campaign. [40:34]
-
-**Carl:** Wild. They must have hit so many people to get a couple of major vulnerabilities in. Cool. [40:41]
-
-## [Expo Router demo by Evan Bacon AI \+ RSCs \+ Expo Router](https://github.com/EvanBacon/app-that-builds-apps)
-
-**Mo:** So next up, very quick one. [40:48]
-
-You might've remembered the old expo router demo from last year's react conf, where they showed RSCs in the world of expo router for building an AI app. Something very similar to that is now an open source project that you can clone and play around with. So Evan Bacon has released a demo of an AI app that can generate. [40:50]
-
-With AI native components and stream them in with RSCs. It's pretty cool. So clone the repo, play around with it. It's an interesting little demo. [41:08]
-
-## Some tech details on [how Meta serves React pages](https://www.reddit.com/r/reactjs/comments/1ltbw2e/how_does_facebook_serve_react_pages/)
-
-**Mark:** There was a Reddit thread that was asking how does Facebook slash meta actually build and serve their React applications? And some former meta engineers responded with a few technical details talking about how they do a bunch of dynamic bundling, and they also use, I believe Hermes or static Hermes on the back end to pre-build some of the server rendering pieces. [41:16]
-
-So, you know, a little peek behind the curtain. [41:38]
-
-## [Nitro Image library for React Native](https://github.com/mrousavy/react-native-nitro-image)
-
-**Mo:** Cool. And we talked a little bit about Nitro modules over the months, the past few months, there is a new library that the Margie folks folks have been working on called React Native Nitro Image. And so this is built on top of Nitro modules. I was actually talking with someone this morning about some of the challenges with images on the native layer when it comes to loading them in React Native. [41:40]
-
-So this is very much welcome as a change to hopefully improve performance across the board for React native. [42:02]
-
-## [A very hacky way to test RSC components](https://www.nico.fyi/blog/how-to-test-react-server-component)
-
-**Mark:** One of the weaknesses of React Server components has been that there hasn't been a good testing story for them yet, or at least not one that I've heard of. Someone put up an article with a way to test them. [42:08]
-
-However, it's incredibly hacky and relies on overriding some of reacts internals, so it's probably not a good way, but it is a way to try to test them if you like. [42:20]
-
-## [A good technical dive into improving INP in a Next app](https://medium.com/preply-engineering/how-preply-improved-inp-on-a-next-js-application-without-react-server-components-and-app-router-491713149875)
-
-**Mark:** And then there was a pretty good article that gave, it went into a bit of a technical dive and deep dive on how a company improved the interaction to Next Paint Web Vital Metric in their app, and gave a bunch of very practical examples of problems they found in their app and ways that they, they addressed those. [42:31]
-
-## [Extra CSS Properties in React Native](https://github.com/facebook/react-native/pull/52284)
-
-**Mo:** Cool. Next up, there are some new styling properties that are being proposed to be added to React Native. So this is being done by Nishan Bede, who has been doing a lot of work in trying to bring some CSS styling into React Native and better support. This time there's a pr up that adds support for background size, position, and reply and, and repeat. [42:51]
-
-So this will be quite interesting to see when and if it gets merged in. [43:13]
-
-## [Chrome 137 adds `if` support in CSS](https://developer.chrome.com/blog/new-in-chrome-137)
-
-**Carl:** Yeah. Speaking of, I don't know, new CSS things. Chrome 1 37 added an if to CSS. There's a conditional flow, or I don't know, there's a condition now in CCSS. I have not seen that before. So I guess it's a way of, you know, you can consult the various variables you've set up and evaluate what the associated styles are or associated values and conditionally. [43:16]
-
-Do one thing or another. Yeah. [43:43]
-
-**Mark:** Yeah. It, it, it looks like it's a built-in function. You pass in a very, like a, an existing variable or property value as the first, and then it's, if it matches, then it's a, if it doesn't match, then it's b like, almost like an Excel function, like kind of a thing. [43:44]
-
-**Mo:** Reminded me exactly of that. [44:01]
-
-Are we finally at the stage where CSS is turning complete? [44:03]
-
-**Carl:** I remember seeing a demo of turning complete CSS like 15 years ago if you include user input. So yeah, it was like a grid of check boxes and uh, I think the, the human had to interact with stuff, but it was turning complete, if you included that. [44:06]
-
-**Mo:** So I think we just need loops and it'll technically be turn complete. [44:20]
-
-**Carl:** Yeah. Wild. Anyway, that, that seems interesting and new. This document that I'm reading is using something else that I don't recognize. The, the example they have here is if style, you know, dash color, white, so I guess that's using a different function to read the styles of the current element. [44:23]
-
-Something. That's what it looks like to me, but that's also new to me. So like between conditionals and being able to read the current state of element are, uh, interesting. [44:41]
-
-## [React Devtools for Firefox may not get updated due to review restrictions](https://bsky.app/profile/ricky.fm/post/3ltkxpo5ewk2i)
-
-**Mark:** There was a discussion thread on Blue Sky where someone, where one of the React team members said that. They were, they had tried to submit an update to React Dev Tools extension in Mozilla's, Firefox, add-on store, and it was getting blocked because Mozilla has some very specific and strict rules around how code gets built into extensions, and suddenly, all of a sudden, someone on the Mozilla side is complaining that the way React builds their extension is hypothetically a security concern. [44:50]
-
-There were also some numbers thrown around about how many Firefox users of the dev tools extension actually exist. And it was only like, maybe like 120,000 or something. Whereas I think the, the last time I looked at the, the dev tools extension for Chrome, it's like 4 million. So the React team was actually saying, you know, maybe we, we won't even bother building the extension for Firefox anymore. [45:23]
-
-It's, it's not worth the effort. You can always add the, you know, the unbundled version yourself. I think they maybe managed to get the attention of someone from Mozilla to try to, you know, bypass the stuck review process. But clearly that's a pain point. And [45:47]
-
-**Carl:** I gotta say, just side load this extension that can read all of your input on every site is the dangerous thing to do at scale. [46:03]
-
-Like if you just tell millions of people side load this application, there's gonna be dozens of malicious actors who spin up their own. Side load version of the extension that does malicious things. So Oof. Don't like that. So yeah, hopefully they can fix this, you know, correctly. [46:12]
-
-## [Both `oxlint` and `biome` are investigating typed lint rule support](https://www.solberg.is/fast-type-aware-linting) ([Biome v2](https://biomejs.dev/blog/biome-v2/), [tsgolint](https://github.com/oxc-project/tsgolint))
-
-**Mark:** And so another item, so we've previously mentioned that, you know, biomes working on version two and they had included some typed some support for typed aware rules that normally would've required integration with the TypeScript DS went package and the TypeScript compiler ENT came out with 1.0. [46:29]
-
-There, there's a bit of additional information and updates on both of those. So there was, there was an article. Talking and comparing the different approaches that Biome and Oxalate are using to implement typed support. And then we got a couple links to some of the discussions where those linters are doing it. [46:49]
-
-Biome appears to be building in like their own, almost like a miniature version of. Typed processing, whereas Oxalate has taken the new TypeScript written in Go compiler and sort of hacked up an interop layer. Then they're relying on the new TypeScript go compiler to do the type checking work. And that approach appears to be working it. [47:09]
-
-They said they've implemented a number of the different type to wear rules, and it seems highly performant, so you know that in addition to being able to build our apps faster, we may be able to lint our apps faster as well. [47:35]
-
-## [Remix v3 dev branch containing support packages](https://github.com/remix-run/remix/tree/v3)
-
-**Mark:** Cool. We've been going on for a while about how the remix team has been dropping very, very vague hints about what remix version three is going to be, to the point that it's really getting very, very annoying for those of us reading their, their Twitter accounts, and I still haven't seen any actual code of what the framework itself. [47:49]
-
-Will be like, however, there they did put up a development branch that includes some of the support packages that they're going to be using as part of the implementation of version three. So like it's not the full framework, but there's a lot of individual sub packages for various like tar parsing and other sorts of things that they want to be usable standalone, but they're building them for the purpose of usage in version three. [48:07]
-
-So it's not a full look at what, what they're doing, but it's a little bit of a peek behind the curtain. [48:35]
-
-## [React Native Wallet](https://blog.swmansion.com/introducing-react-native-wallet-90c1ee103d3e)
-
-**Mo:** Cool. Next up, we've got another sort of honorable mention of releases that happened over the last month, and this is React native wallets. So there's a lot of sort of. Wallet style libraries that have come and go in the React native ecosystem, not one that's really been maintained extensively. [48:40]
-
-And so the folks at Expensify and Software Mansion have partnered together to create the React Native Wallet library. And so the idea is that. It's firstly a cross-platform way to add payment and credit cards to Apple and Google Wallet. Now, there's libraries that like handle passes and tickets. They're quite limited. [48:58]
-
-I've used a few of them in the past, but this is more specifically on payment cards. And so the idea is that you can maybe. Hopefully through this process avoid needing to integrate a whole bunch of different SDKs for different cards and different and different platforms, and you can kind of just use this library to handle a lot of that functionality for you. [49:19]
-
-Sounds quite complex because, you know, payments are usually quite difficult to get working, so I'm curious to see how well this works in practice, but I've not had the use case yet. Typically payments and, and cards and stuff like has so many different people that you need to communicate with. The card issuer, apple, and a whole bunch of other people in the process. [49:37]
-
-So curious to see how extensible and generic this is gonna be, but very cool. [49:56]
-
-**Carl:** Yeah. Interesting. Also, it's the first time I've seen a wallet library that was not Web3 in a long time, so additional wallets, right. [49:59]
-
-## [Deno v Oracle update](https://deno.com/blog/deno-v-oracle4)
-
-**Carl:** This is a very small update, but we've. I talked a bit in the past about Deno versus Oracle. [50:07]
-
-Deno has been suing Oracle for use of the JavaScript trademark because did you even know that Oracle owned it? Oracle owns the JavaScript word, the word JavaScript. So basically the only content update here is that in the past, at some point previously in the litigation, Deno filed a claim of fraud because. [50:13]
-
-Oracle filed supporting evidence of prior use of the trademarked term JavaScript by referencing the node JS project. Generally as something that they did and you know, who did not start or maintain node js is Oracle. So like basically they filed a just wildly inaccurate claim supporting that. They do in fact use JavaScripts. [50:36]
-
-So that unfortunately was dismissed. The fraud claim was dismissed, which seems strange to me because like if you say I made this and you didn't, seems wrong. But anyway, that's really the only major update here, but hopefully we will hear more. Hopefully this will go in a good direction. I am not super confident of that, but August and September have some major court dates, so maybe there will be more updates later this year. [51:00]
-
-## [“Content independence day” from Cloudflare](https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/) (they’re blocking AI crawlers)
-
-**Carl:** There's also an update from CloudFlare on AI crawlers. They have declared content independence stay. No AI crawl without compensation, which seems lovely, Cloudflare's in a pretty good position to meaningfully control traffic in that kind of a way. Lots of real services are using CloudFlare for that purpose. [51:23]
-
-So, yeah, seems good. I've heard a couple of anecdotes of people with smaller services getting absolutely slammed with traffic from, you know, poorly coded AI supporting crawlers, trying to gather information and doing it just greedily or excessively. So, seems good. Seems nice. [51:45]
-
-## [Some updated Static Hermes perf numbers](https://x.com/tmikov/status/1945348222110859500) release available “soon”, being tested internally at Meta
-
-**Mark:** All right, and last couple items. [52:04]
-
-The folks at Meta have been working way on static Hermes, which is an attempt to take the existing Hermes JavaScript engine for React Native and be able to pre-compiled entire JavaScript apps to a native binary. And they put up a tweet with some. Performance numbers comparing static hermes's output versus a couple of other JavaScript runtimes. [52:06]
-
-The numbers seem higher, which seems like a good thing. And they also mentioned that they think they will have a release available, quote unquote soon, and that they are using it internally at meta. So, you know, that seems like another potentially useful tool to have in the ecosystem. [52:29]
-
-## [State of HTML Survey is open](https://survey.devographics.com/en-US/survey/state-of-html/2025)
-
-**Mark:** Finally, the folks behind the various state of surveys have put out the state of HTML survey. [52:47]
-
-So that's open. You can fill it out, test out your knowledge, answer some questions about what various new H TM L features you may or may not be familiar with and what you think about them. [52:54]
-
-**Mo:** I did not know them. State of HTML. Very interesting. [53:04]
-
-**Carl:** Yeah, I think they started like two or three years ago. It's relatively newer. [53:07]
-
-I mean, the state of. X has really exploded in the last couple of years. It's great. I love that. But I do worry about like survey fatigue and a lot of these are trying to solicit answers from the same population of developers. So I don't know, maybe, maybe. We'll, we'll see how that plays out. Cool. [53:10]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Alright, before we close out, let's, uh, talk about some coming [53:26]
-
-## [Big Sky Dev Con](https://bigskydevcon.com/) Aug 2 Bozeman, MT, USA
-
-**Carl:** like four days, there's Big Sky devcon in Bozeman, Montana. [53:29]
-
-## [Kansas City Developer Conference](https://www.kcdc.info/) Aug 13-14 Kansas City, KS, USA
-
-**Carl:** Seems good. Kansas City Developer Conference, which is not KCD. It's KCDC, but it's not Ken C dos that's happening August 13th and 14th in Kansas City, Kansas. [53:36]
-
-## [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025. Wrocław, Poland
-
-**Carl:** We also have React Universe September 2nd through fourth in Wroclaw [53:47]
-
-**Mo:** I've been there enough times where I've been taught the pronunciation because butchered it several times, but it's, [53:52]
-
-## [WaysConf](https://www.waysconf.com/) Sept 16-17
-
-**Carl:** uh, we've also got Ways Conf coming up September 16th and 17th in Krakow. [53:57]
-
-I'm also probably butchering, but also in Poland. [54:04]
-
-## [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
-
-**Carl:** Cascadia js is September 18th, 19th in Seattle, Washington. [54:06]
-
-## [Squiggle Conf](https://squiggleconf.com/) Sept 17-18 Boston, MA, USA
-
-**Carl:** And we've got Squi Squiggle conf in Boston, September 17th and 18th, which should be great and I should be there, I believe. [54:10]
-
-## [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l)
-
-**Carl:** And of course, react Conf October 7th and 8th in Las Vegas, Nevada. [54:17]
-
-## [Remix Jam](https://remix.run/jam/2025) Oct 10 Toronto, Canada
-
-**Carl:** I also just heard about Remix Jam, happening October 10th in Toronto, Canada. Yeah, that's new. I don't know that they've done a conference like that before, so that's interesting. [54:22]
-
-## Outro
-
-**Carl:** But yeah, that's all we got for you this month. Thanks so much for joining us. We will be back probably on the last Wednesday of August, but we've been. Jumping around the last few months, but we'll be back in your podcast feed just as soon as we can. [54:33]
-
-**Mark:** Always fun. Way too much to keep track of, but hopefully this has been useful. Lovely to be with you all and see you all next month. [54:46]
-
-**Carl:** Great. We gather sources from this week in React Bites, dev Next JS Weekly, the React JS subreddit, and here in React to Flux from the E, the Tech Reads and News Channel. If you see something that you think we should talk about, definitely Sheridan. [54:53]
-
-Channel or send it to me at hello@reactiflux.com. If this is a show that you get value from and want to support, one of the best ways you can do so is by submitting a review on whatever platform you listen to it on, or tell your friends and coworkers about it. [55:07]
-
-Thanks so much for listening. Talk to you later. [55:19]
diff --git a/src/transcripts/tmir-2025-08.md b/src/transcripts/tmir-2025-08.md
deleted file mode 100644
index 15b5e9f..0000000
--- a/src/transcripts/tmir-2025-08.md
+++ /dev/null
@@ -1,498 +0,0 @@
----
-title: "TMiR 2025-08: Nx compromised; no more throwing promises; Remix-ing new component models"
-date: 2025-08-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:47](#new-releases)] New releases
- - [[00:51](#ts-59)] [TS 5.9](https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/)
- - [[02:50](#ts-60-may-enable-strict-by-default-and-change-other-defaults)] [TS 6.0 may enable \\\`strict\\\` by default](https://bsky.app/profile/robpalmer.bsky.social/post/3lxar2cp5rs2p) and [change other defaults](https://github.com/microsoft/TypeScript/issues?q=milestone%3A%22TypeScript%206.0.0%22)
- - [[03:46](#react-native-081)] [React Native 0.81](https://reactnative.dev/blog/2025/08/12/react-native-0.81)
- - [[05:40](#next-155)] [Next 15.5](https://nextjs.org/blog/next-15-5)
- - [[07:10](#preact-11-beta)] [Preact 11 beta](https://github.com/preactjs/preact/releases/tag/11.0.0-beta.0)
- - [[07:39](#hydration-20)] [Hydration 2.0](https://github.com/preactjs/preact/issues/4442)
- - [[07:52](#bun-1221)] [Bun 1.2.21](https://bun.com/blog/release-notes/bun-v1.2.21)
- - [[08:54](#native-yaml-support-definitely-not-going-to-cause-any-problems)] Native YAML support. Definitely not going to [cause any problems](https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell)
- - [[10:21](#tanstack-db-beta)] [Tanstack DB beta](https://tanstack.com/blog/tanstack-db-0.1-the-embedded-client-database-for-tanstack-query)
- - [[11:30](#ghost-v6)] [Ghost v6](https://ghost.org/changelog/6/)
-- [[13:09](#main-content)] Main Content
- - [[13:13](#react-api-changes-updates)] React API changes / updates
- - [[13:24](#react-deprecating-the-throw-a-promise-suspense-trigger-method)] [React deprecating the “throw a promise” Suspense trigger method](https://github.com/facebook/react/pull/34032)
- - [[16:20](#discussion-between-dan-dominik-and-ricky-about-how-to-support-multiple-react-versions-if-at-all)] Discussion between Dan, Dominik, and Ricky about [how to support multiple React versions (if at all)](https://bsky.app/profile/tkdodo.eu/post/3lv4rhr4mrs2i)
- - [[17:43](#github-discussion-with-joe-about-why-no-context-selectors-api-or-signals-research-into-data-modeling-and-why-concurrent-stores-are-the-current-focus-area)] Github discussion with Joe about [why no context selectors API or signals, research into data modeling, and why “concurrent stores” are the current focus area](https://github.com/reactjs/rfcs/pull/119#issuecomment-3214971470)
- - [[21:25](#pr-for-concurrent-stores-skeleton)] [PR for “concurrent stores” skeleton](https://github.com/facebook/react/pull/33215)
- - [[23:13](#third-party-react-concurrent-store-ponyfill-package)] [Third-party \\\`react-concurrent-store\\\` ponyfill package](https://github.com/thejustinwalsh/react-concurrent-store)
- - [[26:39](#lee-robinsonss-reflections-on-the-react-community-wrap-up-post)] Lee Robinsons’s [“Reflections on the React Community”](https://leerob.com/reflections) wrap-up post
- - [[31:18](#remix-doing-its-own-component-model)] [Remix doing its own component model??](https://x.com/mjackson/status/1954975322157486408)
- - [[36:46](#remix-3-and-the-end-of-react-centric-architectures)] [Remix 3 and the End of React-Centric Architectures](https://thenewstack.io/remix-3-and-the-end-of-react-centric-architectures/)
- - [[37:21](#popular-nx-packages-compromised-on-npm)] [Popular nx packages compromised on npm](https://www.aikido.dev/blog/popular-nx-packages-compromised-on-npm)
- - [[39:43](#last-month-eslint-plugin-prettier-maintainers-were-targeted-this-is-a-much-broader-attack)] Last month [eslint-plugin-prettier maintainers were targeted](https://snyk.io/blog/maintainers-of-eslint-prettier-plugin-attacked-via-npm-supply-chain-malware/), this is a much broader attack
-- [[41:31](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[41:33](#react-strict-dom-vs-react-native-for-web-in-2025)] [React Strict DOM vs React Native for Web in 2025](https://shift.infinite.red/react-strict-dom-vs-react-native-for-web-in-2025-bb91582ef261)
- - [[43:34](#faster-jsonstringify)] [Faster JSON.stringify()](https://v8.dev/blog/json-stringify)
- - [[44:56](#node-2218-unflags-ts-type-stripping-support)] [Node 22.18 unflags TS type-stripping support](https://nodejs.org/en/blog/release/v22.18.0)
- - [[46:23](#waku-switches-to-vites-wip-rsc-support)] [Waku switches to Vite’s WIP RSC support](https://waku.gg/blog/migration-to-vite-plugin-rsc)
- - [[47:00](#rari-a-fast-react-framework-with-rsc-support-built-with-rust)] [Rari, a fast React framework with RSC support built with Rust](https://ryanskinner.com/posts/how-i-built-a-full-stack-react-framework-4x-faster-than-nextjs-with-4x-more-throughput)
- - [[47:52](#selecting-values-from-query-results-as-well-as-the-useless-usecallback)] [Selecting values from query results](https://tkdodo.eu/blog/react-query-selectors-supercharged), as well as [The Useless useCallback](https://tkdodo.eu/blog/the-useless-use-callback)
- - [[48:26](#ts-postmortem-effect-ts-experimental-ts-fork)] [TS\+ postmortem (Effect-TS experimental TS fork)](https://effect.website/blog/ts-plus-postmortem/)
- - [[50:48](#react-usetransition-update-ordering-details)] [React useTransition update ordering details](https://jordaneldredge.com/notes/react-rebasing/)
- - [[51:13](#a-clock-that-doesnt-snap-techniques-for-fixing-hydration-of-values-like-dates)] [“A Clock that Doesn’t Snap”](https://ethanniser.dev/blog/a-clock-that-doesnt-snap/), Techniques for fixing hydration of values like dates
- - [[51:36](#react-cache-its-about-consistency)] [React Cache: It’s about consistency](https://twofoldframework.com/blog/react-cache-its-about-consistency)
- - [[52:26](#self-hosting-next-at-scale)] [Self-hosting Next at scale](https://dlhck.com/thoughts/the-complete-guide-to-self-hosting-nextjs-at-scale)
- - [[53:26](#server-and-client-component-composition-in-practice)] [Server and Client Component Composition in Practice](https://aurorascharff.no/posts/server-client-component-composition-in-practice/)
-- [[54:04](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[54:06](#react-universe-conf-sept-2-4-2025-wrocaw-poland)] [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025\\. Wrocław, Poland
- - [[54:14](#waysconf-sept-16-17)] [WaysConf](https://www.waysconf.com/) Sept 16-17
- - [[54:21](#cascadiajs-sept-18-19-seattle-wa-usa)] [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [[54:26](#cascadiajs-sept-18-19-seattle-wa-usa)] [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [[54:32](#react-alicante-oct-2-4)] [React Alicante](https://reactalicante.es/) Oct 2-4
- - [[54:51](#react-conf-is-back-oct-7-8-las-vegas-nv-usa)] [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
- - [[54:56](#remix-jam-oct-10-toronto-on-ca)] [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
-- [[55:10](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the August edition of this Month in React. As we recap what's going on with React, react native in the web we're coming to you live from Reactive Flux, the place for professional developers using React. I'm Carl. [00:00]
-
-I'm a staff product developer and freelance community leader here at Reactive Flux, where I do community programs like this event and write some code to help keep the community running. [00:13]
-
-**Mark:** Hi, I'm Mark. I maintain Redux. I try to find time to maintain Redux. Life is busy these days and my day job is working at Replay where we've built a time traveling debugger for JavaScript and are also attempting to get in on the AI app generating craze. [00:22]
-
-**Carl:** Mo is unfortunately out this month, he seems to have food poisoning or something similar. So he's gonna take a break and I'm gonna do my best on React Native news, which is only Okay. [00:37]
-
-## New releases
-
-**Carl:** But yeah, let's start off with some new releases. Mark, tell us about new TypeScript. [00:47]
-
-## [TS 5.9](https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/)
-
-**Mark:** The TypeScript release train keeps on rolling. They've just put out TypeScript 5.9. Few points of interest out of this one. They've updated some of the options for generating any new TypeScript project. They've simplified the initial TS config, JSON that gets generated. They also have support for the upcoming JavaScript import, defer syntax. This is a new thing. That is coming down the pipeline for JavaScript engines where you can use the defer keyword in an import statement and the JavaScript runtime will know that it needs to go read this file, but it won't try to actually load and execute that JavaScript right away. [00:51]
-
-Right now, when you do imports, everything's imported and executed synchronously. This can have a lot of effect on startup time, and so the import, defer keyword is meant to la effectively lazy load some pieces of the JS system without having to use the the separate import statement. So TypeScript now at least has support for that syntax, but in a sense it won't do anything until JavaScript engines fully support actually doing something with that. One thing that I personally am excited for is that TS 5.9 now has support for expandable hover previews. If you, if you ever work with TypeScript, you have big type definitions, you know that TypeScript often cuts down the amount of information it shows about a type in the hover preview or, you know, the types are deeply nested and you, you don't already know like what is inside this field. So ts 5.9 now has support for actually being able to drill down into hover previews. you do need to have an updated version of VS code to make use of that as well. But as someone who has spent too much time fiddling with those settings, I'm actually very excited about that one. [01:37]
-
-**Carl:** Yeah, that sounds great. [02:48]
-
-## [TS 6.0 may enable \\\`strict\\\` by default](https://bsky.app/profile/robpalmer.bsky.social/post/3lxar2cp5rs2p) and [change other defaults](https://github.com/microsoft/TypeScript/issues?q=milestone%3A%22TypeScript%206.0.0%22)
-
-**Mark:** And then along with that, there are a couple bits about the future of TypeScript. So right now we're on 5.9. The TypeScript team has said that the go port of the TypeScript compiler will become a TypeScript 7.0. They've put out some news and plans on the roadmap for TypeScript 6.0. There's an issue in some discussion about making the strict flag the default, or maybe not the entire strict flag, but maybe graduating some of the specific settings, like strict null checks to be turned on by default. As a maintainer, that makes me very, very happy. I'm tired of seeing people post issues against my library saying, your library doesn't work. Right. And the problem is they didn't have TypeScript in strict mode in the first place. So. still to be worked out, but it's good to see that they are trying to figure out the transition plan for all this. [02:50]
-
-**Carl:** Definitely super cool. [03:44]
-
-## [React Native 0.81](https://reactnative.dev/blog/2025/08/12/react-native-0.81)
-
-**Carl:** We've also got React native releasing version uh, O 81. Obviously I am not anywhere near as deeply versed in React native as Mo would be. So, uh, hopefully we'll have him around to catch us up again later on. But we've talked a little bit about what's coming on, what's in this release in previous months. [03:46]
-
-Nothing here struck me as super new. They're deprecating, the safe area view which they talked about as being originally an iOS specific. Component in order to support, you know, the safe area because of the notch. But now Android has notches too, and it doesn't work very well for that. So it's being deprecated and they're leaning on the, Safe Area Context. They recommend that you migrate to the React native safe Area context library for that. They are also defaulting to Android 16 now in React Native. They had an, a curious call out that seems strange to me. They say predictive back gesture is now enabled by default for apps targeting Android 16 and just , the phrase predictive back gesture. [04:07]
-
-Is, I don't know, it seems like a lot to me. I know gestures, you have to predict them and whatever, and I guess everything is now gestures, but I have my phone sent to use buttons still, so I don't know what they're talking about, but that sounds complicated. It also talks like, you know, if you have overridden your, the back behavior of your app, then you may need to migrate or change how your app works. [04:50]
-
-So man, if only you could reliably go back in Native apps isn't the web great. They also are introducing pre-compiled iOS builds, which they say cuts the compile time by up to You know, 10 x so like one 10th the compiled time. It used to be in projects where react native is a primary dependency. [05:11]
-
-And they've got better error rendering in the dev tools as well, which is great. it now shows the original message in Stack trace of uncut JavaScript errors. So how, how lovely to know where your errors come from, [05:29]
-
-## [Next 15.5](https://nextjs.org/blog/next-15-5)
-
-**Mark:** Next 15.5 came out. A couple things worth noting from this one. They now have turbo pack builds for production in beta. Turbo Pack had previously really only been used for local development, and so they've been cranking away on trying to get it to full compatibility for production builds. And it seems like that's getting close. They now have node support for middleware. They've got some TypeScript improvements, like actually having full typing for routes. So it'll catch things like mistyped link tags as well as trying to get rid of the old next lint command. [05:40]
-
-**Carl:** Yeah, the middleware support for no JS also seems like a pretty big step. You know, one of the main complaints, a large complaint about next is how difficult it is to run yourself not on Vercel. So supporting a more generic runtime for your middleware seems really great. [06:16]
-
-I haven't run into this with next specifically, but I have run into. Compatibility issues between edge runtimes and node JS code. it's such a constraint if you're trying to run on, edge runtime, which is, you know, okay, so next Vercel is they have their Edge Runtime, in title case. [06:33]
-
-But also, you know, CloudFlare workers are also a very similar kind of runtime that offer a similar set of constraints. And man, you just can't use a lot of the node ecosystem when you're in one of those constrained environments. So this, this should open up compatibility quite a lot it sounds like to me. [06:51]
-
-## [Preact 11 beta](https://github.com/preactjs/preact/releases/tag/11.0.0-beta.0)
-
-**Mark:** Meanwhile, the Preact library, the, the longstanding smaller replacement for React just put out a beta for version 11. Preact has always been dom slash web only, not native. And the calling cards have been that it's much smaller than full-blown react, but maintains most API compatibility up to a certain point. [07:10]
-
-I think they've stopped trying to, maintain compatibility for some of the newer React APIs in 18 and 19. [07:33]
-
-## [Hydration 2.0](https://github.com/preactjs/preact/issues/4442)
-
-**Mark:** A couple of the big points this one they finally dropped IE 11 support and they've improved hydration and a number of other small tweaks. So it's always good to see that them making progress as well. [07:39]
-
-## [Bun 1.2.21](https://bun.com/blog/release-notes/bun-v1.2.21)
-
-**Carl:** Every so often it's nice to check in on what BUN and Dino and everything are doing. BUN has a 1.2 point 21 release out. A couple things that caught my eye on it were the bun sql, you know, standard library tool now supports MySQL, MariaDB, SQL Light, and Postgres, all from like one dependency. [07:52]
-
-And that's pretty great. I don't know. Nice to have, nice to be able to swap those out. I wonder what the experience of actually trying to swap them out would be, because the different engines have slightly different constraints. I appreciate that. That's cool. I, I love, especially for like SQL light stuff, it just seems so simple as maybe overstating it, but it's really nice to be able to just spin up a database without installing dependencies. [08:12]
-
-So, uh, kudos to BUN for adding that. They've also added native YAML support which is great. You know, it's lovely to not for parsing confi common configuration file formats again, seems like something that should be in the standard library. However, I am generally aware of YAML as like a very challenging format to parse. [08:35]
-
-## Native YAML support. Definitely not going to [cause any problems](https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell)
-
-**Carl:** There's a, a blog post that lives in my brain about YAML from 2023 titled The YAML document from Hell Enumerates some of the complexities one of my favorites being sex decimal numbers. And so a, a, apparently a common older format quirk is that some, ranges of ports that you might try to map in, say a Docker file like Port 22, mapped to port 22 is not parsed as 22, colon 22. [08:54]
-
-It's parsed as a sexagesimal, IE base 60, number. So then instead of the string 22:22, you get 1,342. Which is not a valid port mapping. So like things like there are like 30 different ways to put Booleans to encode Boolean in a YAML file. And so like yes and no are one of the valid formats. And so if you're trying to do a list of countries using standard country codes, apparently Norway will be interpreted. [09:24]
-
-**Mark:** Is NO, [09:53]
-
-**Carl:** So like, just hearing about that, those kind of like foot guns that exist in the format and apparently like variations in parser behavior is an existing problem throughout the YAML ecosystem. So, great. I [09:56]
-
-**Mark:** let's add another parser. [10:09]
-
-**Carl:** Right what? Great. One more parser there. Wonderful. I can't wait to hear about what weird, terrible, hellish bugs emerge from this new parser. [10:09]
-
-Good luck to them. I hope it's good. [10:19]
-
-## [Tanstack DB beta](https://tanstack.com/blog/tanstack-db-0.1-the-embedded-client-database-for-tanstack-query)
-
-**Mark:** Next up the folks over in the Tan Stack Collective have just put out a beta of the new Tan Stack database library. it's a little interesting to describe. It's a layer that's supposed to sit on top of your tan stack query setup, and it kind of acts as like a local in client database and sync engine. [10:21]
-
-So you can still use 10 set query to do the fetching, but the database layer is supposed to provide a normalized view of the data, supposed to have very fast in client updates. I believe this has been worked on by Kyle Matthews, who you may know as the original creator of the Gatsby framework back in the day. He's been working on electric sql, which is itself a AYC engine layer, so he clearly now has some expertise over there. So, looks like a very potentially interesting tool for fast client side data management. [10:41]
-
-**Carl:** it seems like hand stack throwing their hat in the ring on like sync engines at a slightly different level of abstraction than like where React query sits. Further to the backend, further to here's your internal store being managed, not just request caching. [11:12]
-
-So that's cool. Yeah. Interesting. [11:28]
-
-## [Ghost v6](https://ghost.org/changelog/6/)
-
-**Carl:** A very small shout out, a little bit further away, but this is a tool that I evaluated for use in a professional setting on a React project. So I'm gonna shout out a new major version. Ghost version 6.0 has been released. Ghost is a, like CMS, an open I believe open source CMS. [11:30]
-
-And they generally seem nice. They seem great. I, you know, as contrasting things like Contentful or Ghost or Substack or Medium or what have [11:47]
-
-you, uh, Word, right? They sit in a good spot in the niche. They, so they're now, they're announcing as part of this version six that they have added distribution. [11:57]
-
-So now you can automatically publish your posts from Ghost across social platforms. So like they, they call out Blue Sky Flipboard Threads, MAs it on WordPress, interestingly and Ghost, they can, so, okay, so you can publish the ghost and it will be distributed elsewhere on, in Ghost, I don't know, I don't know what that means. [12:09]
-
-Or any other social web platform as well as like analytics. And they talk a lot about how much revenue they have passed along to publishers on their platform. So they show their earnings broken down into like. Hosting revenue and platform revenue, and it's like $38 million for their own company and like a hundred million dollars through, you know, distributed to people publishing on ghosts. [12:28]
-
-So like that, I don't know. That's great. They, they shout out 4 0 4 Media, which is a site that I'm familiar with and did not realize hosted on this platform. So, you know, love that. That's great. I love a, love a open source media platform that's doing good work right now. [12:56]
-
-## Main Content
-
-**Carl:** Cool. Uh, That's all the new releases we have for now, into the main content. [13:09]
-
-## React API changes / updates
-
-**Mark:** All right, so we have a roundup of a number of topics related to changes in reacts APIs. So get your technical hats on for these. [13:13]
-
-## [React deprecating the “throw a promise” Suspense trigger method](https://github.com/facebook/react/pull/34032)
-
-**Mark:** The first one is that Sebastian Markbåge put up a PR to officially deprecate the throw a promise technique for triggering suspense. So let's wind backwards and unpack a little bit, like what is that in the first place and why does it even exist? So. Currently up through React 17 and 18. The suspense component came out in I think like 16.6, but originally it was only used with React lazy for importing and deferring loading of components. There wasn't an official like react for data fetching method, but there was the unofficial experimental. [13:24]
-
-This is never documented, but the code exists and works. If you wanted to trigger suspense in terms of like, you know, managing some data fetching yourself, the super secret technique was that you would throw a promise from within your component. And the reason the React team picked this was because we. It like, to a certain extent, it enabled them to reuse the existing infrastructure from catching errors within a component where, you know, it kind of conceptually, you have a catch block around the actual component call and then react knows, here's where I'm rendering in the tree, and then it can sort of bubble up the behavior to some ancestor component that was supposed to catch it for errors. [14:07]
-
-It's a, you know, actual error handling with the component did catch. And for suspense it's, you know, where's the nearest suspense component in the tree? And so this was never officially documented, but, you know, library maintainers and people investigating the code saw that it was there. And so it's been known and used by the community and libraries for years. [14:57]
-
-And so pretty much anything, any library that had suspense support built in was internally just throwing a promise. So with React 19, we now have the use hook built in, and that is the officially documented publicly, you know, described way to actually trigger suspense. If you look at the use hook, I think internally it does actually still end up throwing a promise last time I checked, but it's now an implementation detail. And it does some other things in there as well. So if you read a pr, they are officially going to get rid of the throwing a suspense, throwing a promise technique for a number of reasons. Some of it has to do with internal implementation details and optimizations. Some of it has to do with, well, we can have the lit rules look for uses of the use hook and flag any, any time you try to put that in a place that it's not legal to do so. [15:19]
-
-## Discussion between Dan, Dominik, and Ricky about [how to support multiple React versions (if at all)](https://bsky.app/profile/tkdodo.eu/post/3lv4rhr4mrs2i)
-
-**Mark:** This did then lead to some discussion on Blue Sky amongst a couple of the maintainers like Dominic Dorf, Meister of React Query asking, well, if this comes out in like, you know, 19 3, 19 4, something like that, how are we supposed to manage having our own libraries work with both like React 18 and 19.1 and 19.4 at the same time when there's now three different variations of what is a legal way to trigger suspense. there was a bit of a back and forth on that. One partial answer was, your library can check if the use hook is exported from React and prefer that if it exists and fall back the promise if it doesn't. One of the React team members, Ricky said, well, you probably should just focus on supporting the latest version of React. I'll admit, I feel like that kind of hand waves the problem a little bit. [16:20]
-
-**Carl:** How great if everyone could just rely on that. Yeah. [17:17]
-
-**Mark:** yeah, because I mean that, that probably also means putting out new major versions of our own libraries, which is then an effort and also has a ripple effect on the ecosystem. I mean, I don't really want to publish a new version, a new major version of, you know, some of the Redux libraries just to support that. But it's good to see that there, that we are actually making headway on that now that 19 is out. [17:20]
-
-## Github discussion with Joe about [why no context selectors API or signals, research into data modeling, and why “concurrent stores” are the current focus area](https://github.com/reactjs/rfcs/pull/119#issuecomment-3214971470)
-
-**Mark:** Another interesting point. So buried in a blue sky thread Joseph from the React team said that. They're planning to not actually implement an idea that they had discussed a few months ago where they'd said, we are going. [17:43]
-
-They were thinking about allowing you to call use or use context inside of use memo as a way to optimize context. So backing up technical detail on this one, the weakness of context has always been that when you update the context value, every component that reads it will re-render. And then at that point, all the children inside of that will re-render as well, just because react defaults to when any component renders. [18:01]
-
-It just keeps on going all the way down the tree unless you optimize it to stop. And so the problem is if you have, you know, fairly large objects with multiple fields as your context value, some of your components probably only care about one or two of those fields. But as soon as you update that object at all, every component that read the context will re-render. And so it ends up leading to, you know, potentially lots of components rendering slower render performance, et cetera. So years ago, like, I don't know, 20 18, 20 19 there was a user land RFC suggestion that react should add context selectors as an API. So, you know, kind of similar to like a, a react redux use selector, but optimize for context instead. [18:28]
-
-And so that proposal has been around for a long time. Andrew Clark even briefly tried implementing a proof of concept of a context selector's API in like 2020, and then it didn't go anywhere. So a few months ago, the React team said we're, we're thinking about a. Use context in use memo as a alternative to actually writing a selector for context. And apparently their thinking has evolved and they're not going to do that at this point because the React compiler basically gives you 95% of the performance benefits that a context selector's API would have without them needing to design and ship a context selector's API, into React itself. If you think about it, the point of the compiler is that it not only optimizes like your used memos and whatever, it also optimizes the render output. And so if you have a component that reads from a context, it will, it will render because the context value changed. But if none of the data that it needs from the context has updated, it will end up skipping all of its children. And so that drastically cuts down on how many components would render when the context updates. So there was actually some very, very good discussion in the longstanding context, selectors RFC thread, just within the last two or three days where a few people were agitating for react should really add contact selectors. It'll get rid of all these other state management libraries. [19:18]
-
-And I left a couple comments trying to explain how the compiler solves this problem and Joe Savona from the React team then went on and wrote some very extensive, detailed comments talking about how the React team has been doing research into these ideas of data flow analysis. And how do you manage large amounts of state and how does it compare with react context and signals and, you know, third party state management libraries. [20:57]
-
-## [PR for “concurrent stores” skeleton](https://github.com/facebook/react/pull/33215)
-
-**Mark:** And so he confirmed that, they're not planning to add a context selector's, API and instead their thought process is actually now about this concept called concurrent stores. So as best as I understand it, the idea is that right now a third party library like Redux or Zeus stand relies on the use sink external store hook to be able to tell react that there's a subscription data changed. This component needs to update, but. That has the limitation that it doesn't play well with suspense and transitions because if something got updated in the middle, react has to throw away work in progress and do a full render. It can't do all the, you know, the performance optimizations and with transitions. So it sounds like this concurrent store idea is supposed to be like an improved, better version of use sync external store where you can still have some data living externally. You can still have selectors saying like, only these components need to update. But the concurrent store would wrap the updates in a concurrent transition compatible way. [21:25]
-
-So he said that they're really trying to put some focus in API design onto figuring out what a concurrent store, API ought to look like. And it sounds like they've got some, some amount of progress on that design to talk about in the near future. They did put up a pull request a couple months ago with the skeleton for concurrent stores. It's just like defining some, some data types and adding some tests. There's no implementation code yet. [22:41]
-
-## [Third-party \\\`react-concurrent-store\\\` ponyfill package](https://github.com/thejustinwalsh/react-concurrent-store)
-
-**Mark:** However a third party developer that I saw has actually looked at all the tests and then gone off and tried to implement a third party hacky polyfill version of what it looks like the concurrent stores are supposed to be and publish that as a React concurrent store package. I'm very excited about this and I have not had time to actually try it out yet. So the takeaways are a. Most developers probably won't need to use some of these things directly. A lot of this is going to be more library maintainer concerns but it's very good to see that the React team is actively thinking about how, how can we make React apps faster? What are the best ways to manage complex state? How can we better integrate with third party libraries and try to make all the react features like transitions work well in those cases? [23:13]
-
-So there's your info dump for the day. [24:08]
-
-**Carl:** Love that. I had said some stuff just before we started recording, just before we started the event about, I've been playing with effect effect ts lately, which we, we've mentioned once or twice now. And again and when you're talking about these concurrent stores and you know, like I'm reading the post from Joe Savona talking about context selectors. [24:10]
-
-One of the things that I think effect solves well is dependency injection. it's focused on the backend, that actually says in the documentation like, effect is not meant for front end. They're, it may seem good, but it's not what it's meant for. And they're interested in exploring that, but they haven't yet. [24:30]
-
-But I think the execution model is pretty similar. It's like, it's almost like componentized backend a little bit. But with type safe dependency injection and error generation and, and using effect pretty extensively for the last three or four weeks has really made me. Itch for some of those benefits in React. [24:44]
-
-I'd be curious to see if they can, well, I've got a little bit more connections to make on that later on, so I guess I'll end it there. I don't know, just about dependency injection in effect and type safety and whatever in the context of selecting data on the front end, I think is interesting. [25:05]
-
-I think there's still a lot of API design exploration to do there. [25:20]
-
-**Mark:** I definitely recommend taking a few minutes to read some of Joe's comments in that context. Selector's, RFC thread, if you got some time, and then I, I expect there be, and to be at least some announcements, possibly about concurrent stores coming up at React Conf in October. [25:25]
-
-**Carl:** Interesting. [25:41]
-
-**Mark:** Then the last item out of the React related changes they merged a PR to add what looks like a new suspense timeline to the dev tools. They've got a demo video in there, and so it looks like it's actually now a, a third extra tab in the Chrome dev tools. So you've got the component tree, you've got the performance tab, and then there's a suspense timeline tab. And it looks like what it does is a mixture of , a rough rec out, like rectangle outline of the shapes of your components, but not showing like any of the HTML, just like , here's the structure of what your component tree looks like visually, and some highlighting for which ones have suspended, and then possibly some further details in a sidebar about which components suspended and when. So. as a dev tools type person, I'm always very, very excited to see new dev tools capabilities being added. [25:42]
-
-## Lee Robinsons’s [“Reflections on the React Community”](https://leerob.com/reflections) wrap-up post
-
-**Carl:** Okay, let's go into. We talked a little bit about Lee Rob leaving Vercel recently and going to Cursor. He put out a really great blog post called Reflections on the React Community. This sort of summarizing his, his time at Next and in React. Yeah, I don't know. Mark, do you wanna start? [26:39]
-
-I don't know if I have anything specific to start here. It's a really good overall hot, you know, 30,000 foot view of his time. [26:59]
-
-**Mark:** So Lee Robinson was the primary developer relations person for Vercel for about five plus years. And even in my own head like. when I hear the word devel Lee is pretty much the first person that comes to mind. And Lee was always in a very tough position. You know, CEL is, you know, a somewhat divisive company in some ways. You know, it, it puts out some wonderful technology. They've genuinely done a lot to advance the React ecosystem makes, make apps, you know, easier to host, they build next, et cetera. But, you know, they've also been accused of, you know, the React team and pushing reacts direction and making changes just for profit. And you know, as I've discussed in some previous episodes and blog posts, like a lot of that is undeserved criticism or, you know, misinterpretation of the background. And so, as you know, the visible face of Vercel and the next team we was. Frequently the target of a lot of those criticisms, even though, you know, none of it was, you know, like he wasn't the one developing the tool set or, you know, making the businesses decisions. And one of the things I've always appreciated about Lee is that, you know, he was always very, very active in discussions on, you know, Reddit and Twitter and Hacker News. You know, like not just in like the next sub Reddit, but you know, the React Reddit hacker news discussions. Like anytime a discretion thread would happen, he would pop up and, you know, respond to comments, offer feedback, and, you know, yeah. [27:07]
-
-Because of his position. Like occasionally people would interpret it as being like a corporate ish response, but he was always very, very active in being in there. And unfortunately that meant he was also the, you took the brunt of a lot of the criticism. So a lot of his blog post, you know, talks about, you know, react has, react has become stable, it's grown, the community's big. [28:48]
-
-Working with any community is really, really hard and it can be very stressful and very frustrating. He talks a bit about some of the difference between, you know, a, you know, more broadly like projects like React versus Rails you know, dealing with some of the community management acts, aspects, how you get feedback. He even talks some about, incentives like the React team in some ways builds react for meta. And sometimes that means that, you know, issues slip through the cracks. You know, like Meta isn't trained to make money off React. Well, in some ways Vercel is. And he also talks about, you know, some of the, the server component development process, how that was marketed how it's been interpreted. And he talks about burnout. And boy can I understand and sympathize with this one on multiple levels. responding to issues and comments, even when they're positive, takes a lot of time and effort. And when a lot of those comrades are, you know, angry and critiquing and throwing around conspiracy theories, that wears away at you a lot. So I have a huge amount of respect for Lee and everything he's done for Vercel and next in the React community over the last several years. And so I appreciated him doing the writeup and I could totally identify with a lot of the points he was making in here. [29:13]
-
-**Carl:** Yeah, definitely. And it's funny, I, you know, nobody, nobody's ever paid me to do reactive flux things, and it's a very different type of like community management. But I definitely, a lot of what he said resonated with me. But from that perspective, and also just like, I don't know. The burnout and, you know, thanklessness of wrangling a large group of people is is pretty real. [30:35]
-
-**Mark:** So it's a post worth reading. And Lee, if you ever hear this, thank you for all your time and effort. [30:58]
-
-**Carl:** Yeah. Thank you for all your time and effort. It's been a lot. It's been great. what you said about like Lee really being like you think Lee, Robb is definitely a canonical dev rel, like showed the world how dev rel happens. I think [31:04]
-
-really, uh, personified it. [31:16]
-
-## [Remix doing its own component model??](https://x.com/mjackson/status/1954975322157486408)
-
-**Carl:** Maybe in two remix doing its own component model. [31:18]
-
-**Mark:** we've been doing sort of a running observation of what in the world are Michael Jackson and Ryan Florence doing over in their corner. They, they continue to drop cryptic hints on Twitter about the directions of remix version three. And while this isn't, trying to keep this from being the, just repeat what they say on Twitter podcast, but, you know, so far all we have to go by is the cryptic hints that they're dropping. And so we've gone from, you know, just Remix v3 is its own thing to, it's going to use Preact to, well, actually, I guess now it's not using Preact. [31:22]
-
-**Carl:** Yeah, so I, I, I guess they want to explore a similar kind of problem space as react and React are, I mean, I, you know, that's the signals that they're putting out here is that like, well, these existing tools do not solve the problem well enough, we believe. And so we're going to explore that. And, you know, I, fair enough, I, I think there is more room to explore there. [32:01]
-
-I know some discussion in reactive flux on this, you know, on this link earlier Ricky had said like, you know, good luck to them. I think they may find some of the same constraints as React has, and I think that's pretty likely. But, you know, also there's a term coming to mind uh, path dependence, which is, you know, like what the options available to you going forward are dependent on the choices you made in the past. [32:26]
-
-And so, like, you know, react is pretty far down, it's set of chosen decisions. So I think there is some value in backing out and saying like, well, hey, maybe we're in a local maximum. Let's explore some other possible paths here. And yeah, so let me pick up where I sat down earlier talking about effect. [32:49]
-
-Right. So like, it, it feels to me like a componentized model for the backend. And it's really interesting because each, you know, backend component that you write, which I'm, they call 'EM Effects, but you know, this is a React chat, so I'm going to translate. So you write like a backend component and it has a type safe it uses TypeScript generics to describe its outputs, its possible errors emitted and what dependencies it requires to be passed in effects. [33:08]
-
-These backend components can like, make their own dependencies available, you know, or they can say, you need to provide this at runtime. And so that's pretty, that feels very similar in use to me in like ideology to me as what React is trying to do. [33:37]
-
-**Mark:** your props and your output. [33:54]
-
-**Carl:** Right. Props, return value, boom. Like, okay, every return value is JSX and it doesn't really matter specifically what, but you know. Yeah. So it, it, it's really interesting having error safety as well as dependency type safety because like props are one thing. But you know that there's no way to describe that. [33:56]
-
-This component being rendered relies on being nested underneath a context provider. Like you can do a runtime check for that, but you can't do a a compiled time type safety check for that. And that's the kind of thing that effect is enabling. It's that kind of dependency injection. Like what environment does this expect to be run in, not just what inputs does it expect to be provided. [34:16]
-
-I. So like using that in a backend context, you know, in this, going all in on this in a backend space where it's intended to be used has really made me reflect on the experience of using React and what kind of, what some of its pain points are. And so I guess like the React core team has gone all in on the transition boundary between the client and the server with server components. [34:41]
-
-Like they wanna really make that smooth and instead of this request response model, just have it be more fluid and you know, whatever. Yeah, streaming all that which is great and that's a very interesting direction to explore, but it does not address all of those kinds of things of how do we make a robust. [35:04]
-
-Reliable application that can be statically verified, will run as expected. And that is more of where effect is coming at the problem space of code authoring from. And yeah, I think the, like both of those are really interesting viable problem spaces to explore. And if Remix is saying, we think the path that React is exploring is not the ideal user experience, maybe they're gonna go more in something like this. [35:23]
-
-And if they do, this is wild, pure, rampant speculation on my part right now. But if they, you know, I can see a possible world where one thing that might interest them is the same kind of guarantees that effect is trying to provide. And that would be valuable. Like, so I, I, yeah, I'll still be paying attention to this. [35:51]
-
-I do have a greater degree of skepticism it's a huge expansion of what scope of problem they're exploring. So that's challenging. But you know, they've taken on big challenges before. Shipped things. So yeah, we'll be paying attention and see what they see. What they come out with. [36:09]
-
-**Mark:** Yeah, so basically where things stand at the moment are lots of cryptic hints on Twitter. It's not gonna be a React. It's a different component model. They want to make it LLM friendly. We still haven't seen any good examples, but I'm assuming they will do a big announcement at the Remix Jam conference, which I think is in [36:24]
-
-October. [36:42]
-
-**Carl:** Yeah. Oh, they had just done, just recently announced that. [36:43]
-
-## [Remix 3 and the End of React-Centric Architectures](https://thenewstack.io/remix-3-and-the-end-of-react-centric-architectures/)
-
-**Mark:** And then along with the rampant speculation bit I saw a blog post just earlier, earlier today, but it was from a month ago called Remix Three and the End of React Centric Architectures, which also does a bit of, you know, speculating, hypothesizing on the ways various frameworks have chosen to build things and says, you know, maybe it's a good thing that Remix three is supposedly going back to a more web native framework approach. [36:46]
-
-**Carl:** Yeah, and they're doing Remix Jam right after React Conf in Toronto, so, yeah. We'll, we'll shot that out at the, in the conferences section at the end too. [37:13]
-
-## [Popular nx packages compromised on npm](https://www.aikido.dev/blog/popular-nx-packages-compromised-on-npm)
-
-**Carl:** Yeah. Okay, moving on. our last main content subject for the month, there's another security vulnerability. I feel like we, you know, we, we, we talk about these somewhat regularly it feels like, but some pretty popular NX packages were compromised on NPM. So NX is a, [37:21]
-
-**Mark:** Monorepo management and build tool [37:39]
-
-**Carl:** yes. It's a competitor to turbo repo. I, I, I think I would [37:42]
-
-**Mark:** to, to some extent. Yeah. [37:46]
-
-**Carl:** it got wholesale compromised as in like everyone who installed it had a post install script run that swiped a bunch of configuration files like .env and .npmrc, anywhere you can think that credentials might be stored in your project workspace or elsewhere on your system. [37:47]
-
-This script looked for and then uploaded to GitHub. So that's really bad. This is a, this is a, this is a theoretical exploit that I've been hearing about for the last 10 years. Like the vulnerabilities possible by NPM post install has been a subject that comes up every couple of years. And, oh boy, this is a bad one. [38:07]
-
-The, this blog post discussing the vulnerability said that when they were, they were monitoring GitHub. 'cause the way the script worked is it would, if it found your GitHub credentials, if it found a valid SSH key for GitHub or I guess actually an API token, not an SSH token. But if it found a GitHub API token, then it would silently upload a new repo. [38:27]
-
-So it, it, which is interesting because it was a public repo on GitHub created by this malware. So there was some kind of public metric that could be gathered for its scope of impact. And so there this blog post says that they saw at one point, 1,400 of these repos created by this malware script. [38:51]
-
-So like, that's quite a number of people who got all of their secrets swiped off their system. One interesting thing that this malware did is if it found an LLM tool on your system, it would write a prompt to that LLM asking it to find all of the secrets on your system. So like if you, if you've got Claude, like suddenly Claude is maliciously gathering all of your tokens from your entire system that it can, you know, whatever it can access. [39:11]
-
-Like, holy shit, that's bad. That's not, yeah, that's, that's pretty bad. [39:38]
-
-## Last month [eslint-plugin-prettier maintainers were targeted](https://snyk.io/blog/maintainers-of-eslint-prettier-plugin-attacked-via-npm-supply-chain-malware/), this is a much broader attack
-
-**Carl:** you know, last month we discussed a, another vulnerability where the eslint-plugin-prettier package maintainers were targeted. So I guess this, this could be, this could be the same attackers perhaps, and they were just more successful in that, you know, instead of. Getting busted while trying to steal credentials for a major packages maintainers. [39:43]
-
-They actually got it. And so now they have successfully executed on this broader attack that they were maybe trying to do earlier. Woo. That's bad. And it sucks 'cause like what do you, how do you even respond? What do, how can you keep yourself safe if just [40:02]
-
-**Mark:** Monitor your, monitor your dependencies, actually look at lock files. I, I can say that there are some good tools out there that will watch PRS for, you know, like what packages are getting updated in this PR and, you know, warn you if any of them have known PO known problems. That's definitely a valuable thing to include in the CI process. [40:16]
-
-**Carl:** Yeah. True. But man, one of the, one of the challenging parts about this particular vulnerability is the. I, I remember half of the discussion that I saw earlier, and I can't remember where I found it, so I can't quickly refresh my memory, but there, a, a popular tool uses NX at latest on like, you know, project Bootstrap. [40:39]
-
-So like, you know, if you're just casually idly using whatever project generator this was to start something new oops. You got the latest NX that was compromised. So like that's not even, yeah, I don't know. Just like [40:59]
-
-**Mark:** the comment was actually in the, the tech reads and news link and it was [41:13]
-
-the NX vs. Code extension. [41:16]
-
-**Carl:** Okay. Okay. That's a li that's at least a little bit different vs. Code extension is not as popularly used as a, you know, project bootstrap tool, but yeah, not great. [41:19]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Okay. Into the lightning round. [41:31]
-
-**Mark:** Go for it. [41:33]
-
-## [React Strict DOM vs React Native for Web in 2025](https://shift.infinite.red/react-strict-dom-vs-react-native-for-web-in-2025-bb91582ef261)
-
-**Carl:** I saw this post from, it was a blog post summarizing a podcast from react Native Radio from Infinite Red. Great Folks. They spoke with the maintainers of React strict Dom and React native for web comparing and contrasting. We had discussed React strict dom a about a year and a half ago. [41:33]
-
-It was like February of 2024. And a, a lot of what we did was compare and contrast it against React native for web. So this was like very precisely the type of conversation we had except with the maintainers who aren't just speculating and guessing and inferring, but like they, no, they made this like, they know how it works. [41:54]
-
-They know what the trade-offs are. So it's got some really great architectural diagrams explaining the distinction and what the difference is. It lines up pretty well with what I recall us discussing and they have a really good little flow chart for making decisions about you know, TLDR should you adopt React strict dom. [42:13]
-
-And they did a nice little handy visual, which I'm gonna go to the Happy Path through the Happy Path on, which is do you already have React native app? No. Will you need web support eventually? Yes. Use extract Dom. So like basically they're saying this is a great low level set of abstractions that will make it more feasible to reuse your code in more places. [42:30]
-
-You know, like the benefit has always theoretically been that you could reuse much of the code between React native and web. But I've tried to do that a couple of times and the practical realities are challenging. Like, you know, just you need to use doing abstractions so that, that work in both places is really hard. [42:54]
-
-So this acknowledge React native sorry, react strict. Dom sort of acknowledges that and says, rather than trying to make a brand new abstraction on top of both React Native and react dom, we are going to lean more heavily on the web platform as an existing stable abstraction. Which is cool. I like it. [43:12]
-
-It seems cool. This is a really great blog post. Definitely recommend. [43:31]
-
-## [Faster JSON.stringify()](https://v8.dev/blog/json-stringify)
-
-**Mark:** The V8 JavaScript engine developers put up a post where they said they've spent a lot of time trying to optimize js, ON stringy. Think about how many times your code stringys stuff, whether it's sending back an H TT P response or you know, serializing things into an extension. they go, they go into a bunch of technical detail about how they've tried to make this faster. [43:34]
-
-**Carl:** specifically that problem parsing Jason, Jason Parse performance is exact, like that was the reason for React native doing the new architecture, which they've spent like much of the last year communicating and executing on. So yeah, the massive problem for the entire ecosystem, [43:56]
-
-**Mark:** You know, like other than actually executing the JavaScript code faster, like string finding stuff has to be [44:14]
-
-one of the most common things your JavaScript code does. So I believe this is supposed to be out in, I think it was like V eight like 13.8 I think it said which is available in Chrome 1 38. And I don't know what node version will contain that, that version of V eight. But faster is good. [44:19]
-
-**Carl:** Yeah, faster is so good, especially for stringifying. Yeah, man. Just the number of plate serializing and des serializing is one of the largest costs, you know, performance costs like everywhere. So yeah, it'll love that. That's great. [44:42]
-
-## [Node 22.18 unflags TS type-stripping support](https://nodejs.org/en/blog/release/v22.18.0)
-
-**Carl:** Node 22 point 18 flags TypeScript type stripping support. [44:56]
-
-node has had experimental support for. Interpreting TypeScript code and stripping out the types. doesn't actually check them or anything, but it allows you to take a project authored natively in TypeScript and run it with node without a compilation step, without building it through the TypeScript compiler. [45:02]
-
-**Mark:** Or, or using a tool like TS Node to execute it. [45:21]
-
-**Carl:** Yes. Yeah. Right. More directly. This is a replacement for TS node. And that's great. It's no longer experimental. It's, they're now saying it works. it's officially blessed, it's released. Love that. Definitely the ecosystem has moved more from, you know, a long time ago it was very focused on you compile the code and then you take those built artifacts and you run them, and if the type checker fails, you don't get a built artifact and you know, the metagame here has shifted a little bit more into the. Type checking is one very valuable part of verifying your code statically, but it is not necessarily where the compilation step lives. So, many more projects in my experience have moved towards sort of a parallel model where you have a build step and there is type checking in the project, but it just kind of runs separately from that build step. [45:24]
-
-So this is, this is a great tool enabling that kind of pattern. And it's released, it's done. Yay. [46:16]
-
-## [Waku switches to Vite’s WIP RSC support](https://waku.gg/blog/migration-to-vite-plugin-rsc)
-
-**Mark:** A couple RSC and project related updates. We've talked previously about how, vet itself has been missing some pieces in that would enable like full RSC support for vet based frameworks and that there has been a work in progress PR to try to add better RSC primitives into vet somehow. So the Waku RSE framework is now making use of vet's work in progress plugin rather than whatever layers they had built for themselves internally already. So it's good to see that that's coming together. [46:23]
-
-## [Rari, a fast React framework with RSC support built with Rust](https://ryanskinner.com/posts/how-i-built-a-full-stack-react-framework-4x-faster-than-nextjs-with-4x-more-throughput)
-
-**Mark:** And then I saw an announcement for a new framework called rari, which is sort of an acronym for something, some, something faster rendering somehow. But it looks like a, it's supposed to be an RSC based framework that has a custom low level layer. Built with rust. And of course, as we all know, rust makes everything faster. But it sounds like someone looked at some benchmarks of, you know, like next RSC performance and said, I think I can do better myself. And has built their own full stack framework that has RSC support using a custom low level rust layer. [47:00]
-
-**Carl:** Neat. Cool. Yeah, they do claim four, four times faster component rendering under load four milliseconds versus 17 milliseconds. And that's cool. I don't know that if your problematic performance is 17 milliseconds, that's maybe not the worst problem to have. [47:37]
-
-## [Selecting values from query results](https://tkdodo.eu/blog/react-query-selectors-supercharged), as well as [The Useless useCallback](https://tkdodo.eu/blog/the-useless-use-callback)
-
-**Mark:** Then separate from all that the always wonderful Dominic Dome TK Dodo has put up a couple great blog posts. One is the latest in the series of posts on how to use React Query correctly in this case, how to use the ability to select values out of a query. So maybe like you have a, a list items query and you only want to grab one of 'em. And then you also put up a post talking about how a lot of time you don't actually need the used callback hook. There's a lot of cases that used callback is actually kinda useless. So excellent reading as always. [47:52]
-
-## [TS\+ postmortem (Effect-TS experimental TS fork)](https://effect.website/blog/ts-plus-postmortem/)
-
-**Carl:** Can you tell I've been using effect and it's just been living in my brain for a lot of the time. I, as part of reading it, I found this blog post that they wrote pretty recently beginning of July. Where they had done, they had actually forked the TypeScript compiler wholesale and tried to do what they called TypeScript plus TS plus. [48:26]
-
-And I guess part of the idea, as you, as I've been using effect, I can feel very strongly the desire for JavaScript to support a couple of different tools that I, I I, I had remembered seeing as proposals many, many years ago and waited many, many years for them to land mo specifically the pipeline operator for composing functional, you know, programs together and pattern matching, which resembles a switch case, but lets you match on like properties and attributes and, you know, things like that in a different way, in a more flexible way. So. They tried to fork the compiler to make errors a little bit better. Basically, like they're really pushing the bounds of everything you can do in TypeScript and JavaScript. [48:45]
-
-So the, as part of that, they explored fully forking, TypeScript and this, so this is a great postmortem of their design goals and what they were trying to achieve and why they have backed off of that. Yeah, how far we went and what went wrong, what we learned it's pretty good. Definitely very interesting like this. [49:35]
-
-Just reading more about effect, I can just like, it just the amount of the number of different places where they're pushing the envelope and like iterating on the state of the art in web on the backend is just really palpable to me. So, definitely an interesting read here. [49:55]
-
-**Mark:** I, I, I thought it was a good blog post. Honestly, I also partly appreciate it just because they said we spent like an entire year trying to build this thing and it didn't pan out. Here's what we tried and what we learned and what went wrong in the process. I, I, appreciate good art, good write-ups, like that. [50:12]
-
-**Carl:** Yeah, right. I feel like this is good to read as an engineer because it's just a really good postmortem where you can really understand their thought process of why they tried to do this, what benefits they were hoping to get, and what challenges they ran into that made them say, okay, this is not achievable. [50:29]
-
-Just really good, really good read. [50:46]
-
-## [React useTransition update ordering details](https://jordaneldredge.com/notes/react-rebasing/)
-
-**Mark:** I saw a good short post from Jordan Eldridge, who I believe created the web amp recreation of Winamp. Where gave some, gave some thoughts on what happens when you do a React used transition and you apply some other state updates while the transition is going on. Short but useful, especially since transitions are a newer part of the react rendering model. [50:48]
-
-## [“A Clock that Doesn’t Snap”](https://ethanniser.dev/blog/a-clock-that-doesnt-snap/), Techniques for fixing hydration of values like dates
-
-**Mark:** And then I also saw a post called A Clock That Doesn't Snap, which talks about some of the dealing with inconsistency problems between server rented values like dates, and then what happens when you try to actually hydrate that on the client. And a couple different techniques for trying to make it not be inconsistent. [51:13]
-
-**Carl:** Interesting. [51:35]
-
-## [React Cache: It’s about consistency](https://twofoldframework.com/blog/react-cache-its-about-consistency)
-
-**Mark:** There was an article on React Cache. It's about consistency, so React added the cache, API for use on the server, and it's, it's a sort of memo function. The idea is that you can get, like if you need to make one fetch call in multiple places while doing server side rendering, you can try to ensure that it only happens once during that particular render pass on the server. And so the post goes into some detail on what the cache method is, why you want, would want to use it, and how it, you know, actually using that cashed value during the render can produce more consistent results during the render process. And then goes into a little bit more about like some of the conceptual behavior of React components and what is pure versus impure anyway. [51:36]
-
-## [Self-hosting Next at scale](https://dlhck.com/thoughts/the-complete-guide-to-self-hosting-nextjs-at-scale)
-
-**Mark:** saw an article that gave some battle hardened details on the complete guide to self-hosting Next JS at scale. So next is commonly used with Vercel. You can deploy it yourself, but you sometimes have to fill in some of the missing hosting pieces. And so this was a good post that gave and that talked about, you know, what are, what happens when you try to use Next Cache? [52:26]
-
-And it by default cache is values locally. But if you've got multiple copies of the server rendering, now you can have inconsistencies between different instances. So how would you break that out into using a Redis server or something? Instead, how can you handle image optimization and CDN configuration? So if you're trying to do any self host, you know, next, this looks like a very useful guide. [52:53]
-
-**Carl:** Love that. Such a good, deep technical writeup of, I mean, right. Self-hosting next is such a big problem that people discuss regularly that I, I just love seeing, you know, a proper writeup about it. [53:14]
-
-## [Server and Client Component Composition in Practice](https://aurorascharff.no/posts/server-client-component-composition-in-practice/)
-
-**Mark:** Then finally we have a post from Aurora Scharf who spent a lot of time researching and writing about server components and various usage patterns, and she has an excellent post on server and client component composition in practice, which gives some examples of how you can intermingle server and client components to do some of the work on the server, some of the work on the client figure, and figure out where the boundaries ought to be. [53:26]
-
-**Carl:** Yeah. figuring out where the boundaries are should lie in things that's uh, very challenging. [53:53]
-
-**Mark:** And I think that's actually all we've got for this month, which is good 'cause we're right about at at time. [53:59]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Cool. Let's wrap up here with some conferences. [54:04]
-
-## [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025\\. Wrocław, Poland
-
-**Carl:** We got React, Universe coming up in just about a week in September 2nd through fourth in Wroclaw, Poland. [54:06]
-
-## [WaysConf](https://www.waysconf.com/) Sept 16-17
-
-**Carl:** There's also Ways Conf September 16th and 17th. Krakow Great. Also in Poland. So yeah, Poland heavy uh, September. [54:14]
-
-## [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
-
-**Carl:** Then right after that, Cascadia Js, September 18th and 19th in Seattle. [54:21]
-
-## [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
-
-**Carl:** Coincident with Squiggle Con September 18th in Boston, which I will be at [54:26]
-
-## [React Alicante](https://reactalicante.es/) Oct 2-4
-
-**Carl:** Then in October we've got React Alicante, October 2nd through fourth in Spain. [54:32]
-
-**Mark:** I will be speaking at that one. [54:37]
-
-I was not going to be there originally, but I will be flying back from Spain and showing up at React Conf in Las Vegas. That's gonna be a trip. [54:39]
-
-**Carl:** Yeah. Oh, wild. Yeah. [54:49]
-
-## [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
-
-**Carl:** 'cause we've got, you know, react conf in Las Vegas right. Then October 7th and eighth, [54:51]
-
-## [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
-
-**Carl:** then, like we mentioned earlier, we've got Remix Jam October 10th in Toronto. So if you really, like, you could fly out to Vegas and then fly across the, well, I was gonna say across the country, but it's a different country. You can fly across the continent to Toronto. [54:56]
-
-## Outro
-
-**Carl:** Cool. That's all we got for you today. Thanks so much for joining us. We will be back on the last Wednesday of the month here in the live stage or back in your podcast feed just as soon as we can after that. [55:10]
-
-**Mark:** Thank you all for listening. Hopefully the list of links has been useful and informative. If you are going to be at either Squiggle Con, react Delicate, react Ante, or React conf please say hi. I will be running around possibly wearing my Simpsons picture as a name tag. [55:19]
-
-**Carl:** great. Love that. Yeah, same. Likewise. If you see me in Boston or in Las Vegas say, Hey, We gather sources from this week in React Bites, dev the React JS subreddit, and here in Reactive Flux from the uh, tech News and Reads channel. If you see anything that you think we should discuss definitely send it over to us at hello@reactiveflux.com. [55:37]
-
-if this is a show you get value from and wanna support, best way you can do so is by submitting a review on wherever you listen and tell your friends and coworkers about it. Thanks so much. you next month. [55:56]
-
-**Mark:** Take care. [56:04]
diff --git a/src/transcripts/tmir-2025-09.md b/src/transcripts/tmir-2025-09.md
deleted file mode 100644
index e58673b..0000000
--- a/src/transcripts/tmir-2025-09.md
+++ /dev/null
@@ -1,728 +0,0 @@
----
-title: "TMiR 2025-09: React 19.2 on the horizon; npm is still getting compromised"
-date: 2025-09-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-- [[00:52](#new-releases)] New releases
- - [[00:54](#tanstack-start-10-rc)] [TanStack Start 1.0 RC!](https://tanstack.com/blog/announcing-tanstack-start-v1)
- - [[01:13](#react-window-20-rewrite)] [`react-window` 2.0 rewrite](https://react-window.vercel.app/)
- - [[01:44](#apollo-client-40)] [Apollo Client 4.0](https://www.apollographql.com/blog/announcing-apollo-client-4-0)
- - [[01:59](#redux-toolkit-290)] [Redux Toolkit 2.9.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.9.0)
-- [[02:47](#main-content)] Main Content
- - [[02:52](#react-192-coming-soon)] [React 19.2 coming soon?](https://bsky.app/profile/ricky.fm/post/3lzt6yvs6o22r)
- - [[03:24](#activity-in-canary-with-docs)] [ in canary, with docs](https://react.dev/reference/react/Activity)
- - [[07:18](#last-react-labs-post-mention)] [last React Labs post mention](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#activity)
- - [[11:43](#useeffectevent-in-canary-and-has-docs)] [`useEffectEvent` in canary and has docs](https://react.dev/reference/react/useEffectEvent)
- - [[15:47](#compiler-inferring-function-names)] [Compiler inferring function names](https://github.com/facebook/react/pull/34410)
- - [[16:08](#docs-for-eslint-plugin-react-hooks-including-rules-and-compiler-issues)] [Docs for `eslint-plugin-react-hooks`](https://react.dev/reference/eslint-plugin-react-hooks), including rules and compiler issues
- - [[17:15](#react-native-10-on-the-horizon)] [React Native 1.0 on the horizon](https://youtu.be/GPtopk4y2LI?si=JoZVprPW33szn-6D)
- - [[22:02](#react-won-by-default--and-its-killing-frontend-innovation)] [“React Won by Default – And It's Killing Frontend Innovation”](https://www.lorenstew.art/blog/react-won-by-default/)
- - [[22:18](#inevitable-hn-argument)] Inevitable [HN argument](https://news.ycombinator.com/item?shownew&id=45252715)
- - [[27:54](#ricky-on-ryan-carniatos-stream-talking-about-scheduling-and-demoing-using-modern-react-features)] [Ricky on Ryan Carniato’s stream](https://www.youtube.com/watch?v=3vw6EAmruEU) talking about scheduling and demoing using modern React features
- - [[33:41](#server-components)] Server Components
- - [[33:44](#react-router-rsc-framework-mode-preview)] [React Router RSC framework mode preview](https://remix.run/blog/rsc-framework-mode-preview)
- - [[34:36](#also-middleware-is-now-stable)] also [middleware is now stable](https://remix.run/blog/middleware)
- - [[34:44](#krasimir-tsonevs-can-i-use-rsc-today-support-matrix-and-experimental-forket-rsc-without-a-framework-build-tool)] Krasimir Tsonev’s [“Can I Use RSC Today?” support matrix](https://rsc.krasimirtsonev.com/) and experimental [Forket “RSC without a framework” build tool](https://krasimirtsonev.com/blog/article/vanilla-react-server-components-with-no-framework)
- - [[35:43](#rsbuild-support-for-rscs)] [RSBuild support for RSCs](https://bsky.app/profile/ebey.bsky.social/post/3lyf6vixick26)
- - [[35:55](#useful-post-on-parallel-and-recursive-route-rendering)] Useful post on [parallel and recursive route rendering](https://twofoldframework.com/blog/parallel-and-recursive-route-rendering-with-rsc)
- - [[36:35](#all-the-npm-compromises-and-malware-this-month)] All the NPM compromises and malware this month
- - [[39:47](#npm-package-maintainer-qix)] [npm package maintainer Qix](https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack)
- - [[39:48](#crowdstrike-npm-packages)] [CrowdStrike npm Packages](https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages)
- - [[40:16](#github-actions-npm-token-theft)] [GitHub Actions npm Token Theft](https://socket.dev/blog/nx-supply-chain-attack-investigation-github-actions-workflow-exploit)
- - [[41:01](#github-response)] [GitHub response](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/)
-- [[42:00](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[42:03](#porting-modern-typescript-to-run-on-dos)] [Porting Modern TypeScript to Run on DOS](https://jimb.ly/2025/09/23/qauntumpulse-from-steam-to-floppy/)
- - [[42:35](#cloudflare-ddosed-themselves-with-a-bad-useeffect-fetch)] [Cloudflare DDOSed themselves with a bad `useEffect` fetch](https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/?amp%253But)
- - [[43:11](#a-very-lovely-writeup-of-the-evolution-of-css-zoom)] [A very lovely writeup of the evolution of css `zoom`](https://www.bocoup.com/blog/the-webs-most-tolerated-feature)
- - [[43:56](#what-you-need-to-know-about-modern-css)] [What You Need to Know about Modern CSS](https://frontendmasters.com/blog/what-you-need-to-know-about-modern-css-2025-edition/)
- - [[45:21](#fetch-streams-are-great-but-not-for-measuring-uploaddownload-progress)] [Fetch streams are great, but not for measuring upload/download progress](https://jakearchibald.com/2025/fetch-streams-not-for-progress/)
- - [[45:40](#why-do-browsers-throttle-js-timers)] [Why do browsers throttle JS timers?](https://nolanlawson.com/2025/08/31/why-do-browsers-throttle-javascript-timers/)
- - [[46:01](#how-modern-browsers-work-deep-dive-addy-osmani)] [“How Modern Browsers Work” deep dive, Addy Osmani](https://addyo.substack.com/p/how-modern-browsers-work)
- - [[46:32](#biome-stress-testing-wip-nofloatingpromises-lint-rule)] [Biome: Stress-testing WIP `noFloatingPromises` lint rule](https://vercel.com/blog/stress-testing-biomes-nofloatingpromises-lint-rule)
- - [[48:37](#bun-how-bun-install-is-so-fast)] [Bun: How `bun install` is so fast](https://bun.com/blog/behind-the-scenes-of-bun-install)
- - [[49:23](#styled-components-fork-for-perf-and-react-19-compat)] [Styled-Components fork for perf and React 19 compat](https://www.sanity.io/blog/cut-styled-components-into-pieces-this-is-our-last-resort)
- - [[50:02](#vite-ssr-custom-getstaticprops)] [Vite SSR: Custom `getStaticProps`](https://www.patron.com/blog/post/vite-ssr-getstaticprops-replacement/)
- - [[50:11](#dominic-gannaways-new-framework-ripple)] [Dominic Gannaway’s new framework Ripple](https://github.com/trueadm/ripple)
- - [[50:35](#remix-v3-mj-hints-iframe-like-async-primitives)] [Remix v3: MJ hints “iframe-like async primitives”](https://x.com/mjackson/status/1971816432427298951)
- - [[51:57](#react-native-rfc-to-remove-old-architecture)] [React Native RFC to remove Old Architecture](https://github.com/react-native-community/discussions-and-proposals/pull/929)
- - [[52:28](#cloudflares-new-capn-web-rpc-graphql-alternative)] [Cloudflare’s new “Cap’n Web” RPC; GraphQL alternative?](https://blog.cloudflare.com/capnweb-javascript-rpc-library/)
- - [[55:26](#expo-ui-building-swiftui-apps)] [Expo UI: Building SwiftUI apps](https://docs.expo.dev/guides/expo-ui-swift-ui/)
- - [[55:57](#tanstack-db-an-interactive-guide)] [TanStack DB: An interactive guide](https://frontendatscale.com/blog/tanstack-db/)
- - [[56:21](#ts-60-may-switch-to-strict-options-by-default)] [TS 6.0: may switch to `strict` options by default](https://github.com/microsoft/TypeScript/issues/62333)
- - [[57:28](#shopifys-rn-new-architecture-migration)] [Shopify’s RN New Architecture migration](https://shopify.engineering/react-native-new-architecture)
- - [[57:42](#the-bloat-of-edge-case-first-libraries)] [The Bloat of Edge-Case First Libraries](https://43081j.com/2025/09/bloat-of-edge-case-libraries)
-- [[58:51](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[58:53](#react-alicante-oct-2-4)] [React Alicante](https://reactalicante.es/) Oct 2-4
- - [[59:13](#react-conf-is-back-oct-7-8-las-vegas-nv-usa)] [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
- - [[59:29](#remix-jam-oct-10-toronto-on-ca)] [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
- - [[59:43](#viteconf-oct-9-10-amsterdam-netherlands)] [ViteConf](https://viteconf.amsterdam/) Oct 9-10 Amsterdam, Netherlands
- - [[59:52](#jsconf-north-america-oct-14-16-chesapeake-bay-md-usa)] [JSConf North America](https://events.linuxfoundation.org/jsconf-north-america/) Oct 14-16 Chesapeake Bay, MD, USA
- - [[01:00:03](#jsconf-chile-oct-24-25-santiago-chile)] [JSConf Chile](https://jsconf.cl/) Oct 24-25 Santiago, Chile
- - [[01:00:10](#react-native-london-oct-30-31)] [React Native London](https://www.reactnativelondon.co.uk/) Oct 30-31
- - [[01:00:22](#react-india-oct-31-nov-1-goa-india)] [React India](https://www.reactindia.io/) Oct 31 Nov 1 Goa, India
- - [[01:00:26](#wey-wey-web-nov-17-18-malaga-spain)] [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
- - [[01:00:39](#react-summit-nov-18-21-new-york-ny-usa)] [React Summit](https://reactsummit.us/) Nov 18-21 New York, NY, USA
- - [[01:00:48](#react-advanced-nov-28th-london-uk)] [React Advanced](https://reactadvanced.com/) Nov 28th, London UK
-- [[01:01:08](#outro)] Outro
-
-# This Month In React - September 2025 (SM)
-
-Carl: Alright. Hello everyone. Thank you for joining us for the September edition of this Month In React. As we, uh, get together and recap what's going on with React, react Native and the web, we're coming to you live from Reactiflux, the place for professional developers using React. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I do community programs like these events and build tools to help keep the community operating. [00:00]
-
-Mark: Hi, I'm Mark. My day job is working at Replay.io and digging into the guts of React and its internals. And in my copious amounts of spare time, I'm currently rewriting the guts of Immer for faster performance. [00:23]
-
-Carl: Yeah, you did a live stream on that. That was cool. [00:34]
-
-Mark: Yeah, that was a lot of fun. [00:36]
-
-Mo: And my name is Mo. [00:37]
-
-I am the head of Mobile at Thedo. And yeah, I spent a lot of time in the React and React native communities, speak at conferences here and there, and organize the React Native London Meetup and conference, which is coming up in November. [00:38]
-
-Carl: Yeah, more on that later. [00:51]
-
-## New releases
-
-Carl: Let's jump into some new releases. [00:52]
-
-## [TanStack Start 1.0 RC!](https://tanstack.com/blog/announcing-tanstack-start-v1)
-
-Carl: We're gonna talk more about this in depth in the main content section, but Tan Stack start has released a 1.0 rc, so that should be coming together. I've tried playing with this a little bit and didn't make it too far. It just ended up being a larger task than I really imagined, but I'm excited about it. [00:54]
-
-## [`react-window` 2.0 rewrite](https://react-window.vercel.app/)
-
-Mark: React Window. Just put out a version 2.0. Brian Vaughn did a pretty major rewrite of the library to try to simplify some of the props and add some nice built-in features like automizing of the list items and auto resizing. So you no longer need a resize plugin to handle that. [01:13]
-
-Carl: Oh, that's nice. Okay. Yeah, and react window is efficiently rendering large lists. [01:32]
-
-Mark: It's virtualizing lists. Yeah, so you got a list of, you know, a million items. You can only show a hundred on screen at once, that sort of thing. [01:36]
-
-## [Apollo Client 4.0](https://www.apollographql.com/blog/announcing-apollo-client-4-0)
-
-Mark: Also, on that note, Apollo client for GraphQL just put out version 4.0. I know this was a, a pretty major effort to try to improve the packaging, consolidate. Remove a bunch of deprecated features, so that should be a significant improvement if you're using Apollo. [01:44]
-
-## [Redux Toolkit 2.9.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.9.0)
-
-Mark: And on my side, I actually just shipped a Redux toolkit 2.9 earlier this month. The biggest thing there is I made a bunch of perf optimizations to RTK query, especially for cases where you've got a lot of components that are reading from the same cache entry. And we also added a few new options and bug fixes, but the perf improvement and some in-flight requests cleanup was, were some of the biggest pieces there. [01:59]
-
-Carl: Okay. Yeah. Not too many new releases for open source libraries this month, I guess. [02:25]
-
-Mark: Well there, there probably were a few more. We just didn't collect them. [02:30]
-
-Carl: Yeah, I wish there were a little bit more consistent standards across the ecosystem for how to publish a list of new releases. Like the GitHub release is, it is pretty good, but it's still only like 60% hit rate, I guess. Something like that. [02:32]
-
-It feels like. [02:46]
-
-## Main Content
-
-Carl: Cool though. Let's go into our main content. Can you tell us a bit about React updates? [02:47]
-
-## [React 19.2 coming soon?](https://bsky.app/profile/ricky.fm/post/3lzt6yvs6o22r)
-
-Mark: I don't actually have any real details on this, but Rick Hanlon from the React team tweeted out like yesterday, a screenshot of himself apparently working on release notes for React 19.2, so I would assume it's fair to say that it's probably coming out in the near future associated with that and potentially coming out in 19.2. Although the timing may be a little too soon, we have two React features that have graduated from the experimental branch to the Canary branches. [02:52]
-
-## [ in canary, with docs](https://react.dev/reference/react/Activity)
-
-Mark: The first one is the new activity component. This has been around in some form in in the experimental branches for. Probably multiple years at this point. It was originally known as the offscreen component, and then they officially renamed it to the activity component maybe about six or eight months ago. [03:24]
-
-And this is gonna be a pretty big deal. So one of the issues with React has always been that built-in state is managed at the component level. And if you unmount a component, then it, you know, both cleans up the effects and they go away. But the state that was in that component goes away as well. And so that's one of the reasons why there's been, you know, so much use of external state libraries like, you know, Redux and Juice end and Jot and MobX over the years is because in order for state to persist, you either needed. [03:45]
-
-To have the state live outside UAC component tree, or you needed to hoist it up to the top and pass it down via context or props and if you unmount a section of the tree that DA and that data could go away. So the activity component is going to allow you to essentially disable and hide a section of the component tree, but react will keep around the state for those components. [04:22]
-
-And in fact this actually kind of goes along with some of the strict mode stuff that people have, you know, complained about for years. The activity component will also unmount the effects for the components that got hidden. People have complained for years, you know, strict mode, double running effects, you know, shows bugs and, and all the other things like that. [04:52]
-
-But part of the point of that has been to work towards, eventually this feature will come out where you can toggle the activity component on and off. And React will run the UNM mounts because the components aren't fully mounted, therefore, they shouldn't have active effects going. But it will keep the state for those components alive. [05:14]
-
-And so you can imagine this could be useful for a couple of different things. One is like a tabs component. Right now, if you have a tabs component, you either stop rendering the other tabs completely as you switch back and forth, or you use something like CSS display, none, which means the tabs are active and in the page, even though they're not even being displayed. [05:37]
-
-And so with the activity component, you can say I want to pre-render the content for the other tabs, but it's not actually attached to the page until we swap back and forth. But they could still persist the state. So if someone goes back and forth between the different tabs and makes some edits, then. [05:59]
-
-You know, that still stays alive. There's a comment in the chat that the naming choice for the component seems very strange to me. I agree. I didn't like it either. There was some rationale in the PR that actually renamed it to activity. I don't remember what it, what it was specifically off the top of my head, but they, I think it was that like, it's more about is the component active rather than is it quote unquote off screen. [06:19]
-
-Yeah. But I, I don't entirely buy that myself. [06:46]
-
-Carl: Yeah, right. Because this is like hitting that midpoint between that decision point of do you render null or do you render the dom with styling to suppress its visibility. And so I guess this is like smack in the middle, like the internal representation of all of that. [06:51]
-
-Dom remains. But you don't use styling to hide it, which is great for cross-platform stuff. 'cause like there wasn't a cross-platform way to hide something as far as I know before. [07:07]
-
-## [last React Labs post mention](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#activity)
-
-Mark: So if I, if I look back at the last React Labs post from April where they talk about, you know, the plans for the activity component, there's a section there that says, in the future we may add more modes for activity. [07:18]
-
-One of them could be content visible, but keep it unmounted and pause dom updates. Another is the ability to destroy state for hidden activities if too much memory is being used. So I think part of the mindset is it's not just like a bullion toggle, it's we're shipping with two mode options that are like a bullion toggle for now. [07:31]
-
-But we envision some possible additional modes for this down the road. [07:57]
-
-Mo: And, and you know, this is like particularly interesting to me because this has like been a long standing problem in the React native space when you're dealing with native apps. And I, I doubt this will work out of the box with React Native, but I think it's gonna be one of those things which will eventually get there. [08:02]
-
-And hopefully the new architecture makes this easy for the, the core team to adopt and like make sure that those APIs are working correctly. But it's a classic issue, especially when in Native world you're dealing with this concept of like stacks of pages on top of each other. You really don't want the, the stacks that aren't visible or the pages that aren't visible in your stack showing or getting all of the DOM updates, or in this case this, the updates to the actual screens whilst they're inactive because that's a massive performance bottleneck on native devices. [08:17]
-
-And so this type of thing, people have massed over it in the most dirty ways possible and hacky ways possible in, in the React native world. It's been like a longstanding problem because if you, you know, unmount them and then remount them and reestablish the state, there's sometimes like a flashing white screen before the actual components reload. [08:46]
-
-Then you need to delay the transition because all of these things are like transition with page transitions and native. So it's basically to say there's a lot of complexity and if there's a native React way to deal with this, that ties into navigation on the native device as well, then I think it's gonna be a game changer and it'll simplify and fix a lot of performance issues that people often have with their React native apps. [09:05]
-
-Mark: Yeah, I, I know we've, we've had a couple of open issues on the `react-redux` repo with people complaining that. Components that are off, quote unquote offscreen in the React native stack are still subscribed to Redux updates and taking up perfects from running all the subscription logic and asking for us to add random options to make that toggle or something. [09:26]
-
-And so if you know, the activity component ought to be the built-in solution for that. And so that would actually means we don't have to do anything, which is great. Yeah, exactly. [09:48]
-
-Mo: And you know, like some state management libraries have adopted some work around components that you can use for that, but it comes with trade-offs, right? [09:57]
-
-And ideally, your state management library really should not worry about this. This feels like a core react primitive problem rather than a state management library problem. To me, [10:06]
-
-Carl: back to what you said about like the layering of UI and performance problems and like listening to events and things. Fun fact, I've chatted with some people who did React native or like React UI for automotive companies and that was a problem they dealt with like sometimes for certain cars. [10:15]
-
-The reason the UI sucks sometimes is because of this issue and because it's rendering multiple UIs on top of each other and doing all sorts of weird, crazy stuff. There's two [10:35]
-
-Mo: devices that are particularly bad for that. One is Smart TVs and the other one is cars. And the reason for that is both of them are awful processors and like they really cheap out on the hardware because they're cutting costs everywhere in the actual like manufacturing bit. [10:45]
-
-And so something that might run in your web browser with your laptop that like has like several hundred megabytes of RAM per tab. Will, you know, be restricted to 50 megabytes of ram or it'll get killed by the operating system that lives on the automotive car infotainment system. And this is a big problem for any, like one of those types of devices. [11:01]
-
-And I think a lot of those, you'll be surprised, run on React and like web-based platforms or sometimes even rec native, and it's a big, big issue. So I think something like this. You know, you can fix those issues, but it's hacky and not everyone will do it. So then you'll get really crappy infotainment systems, like you said, Carl. [11:23]
-
-So, [11:40]
-
-Carl: okay. That's probably long enough talking about activity though. [11:41]
-
-## [`useEffectEvent` in canary and has docs](https://react.dev/reference/react/useEffectEvent)
-
-Mark: So one other, one other feature that's migrated from experimental to Canary, I just saw this one a few minutes ago, is the `useEffectEvent` hook. This is something that the React team has also talked about for a while, and I actually didn't even know that any progress was being made on this until I just saw the PR announcement. [11:43]
-
-I'm gonna describe this very badly. Someone should correct me on this, but it's almost like a used memo for callbacks where you'll get the latest reference to a. Callback inside when you execute it, but you get a consistent function reference back when you use it. And so this avoids the need to do a workaround where you're like, main, where the, the callback is reading something off of a ref to get the latest value. [12:04]
-
-I know that this is something that had been proposed a while back and then the initial proposal got killed and they said, we'll, we'll come back and we'll rethink this later. And apparently later is finally now. [12:34]
-
-Carl: Later is now. That's great. Yeah. Interesting. I'm, I'm not super up to date on this, so I'm just reading the docs right now to understand it better. [12:48]
-
-Interesting. The, I definitely know that I have used refs. You know, red values off refs because of weird issues. So I'm not quite groking how this solves this immediately, but that's interesting. [12:57]
-
-Mark: So, and okay, so a partial example, and again, this is me going off the top of my head and not even trying to read the post at the moment. [13:09]
-
-So, if you have like a used callback that needs to access a value, you either let the callback get recreated every time, which in case there's no point in the use callback at all, or you have the item in the dependency array, which means it's gonna, the callback is gonna get recreated still when the value changes or you don't rate it all, and oops, now you have a steel value, which is bad. [13:17]
-
-Carl: Right. [13:42]
-
-Mark: So what happens when you want a consistent callback reference that never changes, but it still needs to see the latest value in order to do something useful when it runs. So one workaround for this is you put a use ref a couple lines up in the component that runs first. You assign to it even in like another use effect before the one that you care about. [13:42]
-
-That means it gets updated. Now you've produced this kind of weird sequence of events where I know that the ref has already been updated before the callback ends up getting run. And so part of the point of this hook is to eliminate the need to do that little dance yourself. [14:08]
-
-Carl: Yeah. Okay. That makes sense. [14:24]
-
-I'm reading this list of caveats and it seems tricky. The only call inside effects define it just before the effect that uses them. Do not pass them to other components or hooks. Do not use `useEffectEvent` to avoid specifying dependencies. This can hide bugs. Sure. Use it only to extract logic that does not depend on changing value. [14:26]
-
-That's quite a set of constraints. [14:48]
-
-Mark: When the new docs came out, and Dan and a couple others wrote the tutorial. There were a couple pages in there that actually referenced this hook as the solution for some of the problems that were being described. Even though the hook didn't exist yet, some of the docs pages also try to make the terminology very unique, where they talk about lowercase e effects as in like, you know, just the generic concept of a side effect versus a capital E effect, which is like a somehow react specific concept that I don't think the docs ever fully defined. [14:51]
-
-And so in, in a way like the use effect event hook, is the React team trained to somehow solidify this. Notional react effect term in a way. [15:30]
-
-Carl: Interesting. Interesting. [15:46]
-
-## [Compiler inferring function names](https://github.com/facebook/react/pull/34410)
-
-Mark: Alright, two other little data points and, and updates Worth noting. The React team merged a work in progress PR to the compiler to try to do and to try to automatically infer function names for things like callbacks that you pass to use effect so that you know when they show, like show up like in a stack trace, they are nicer and easier to read. [15:47]
-
-## [Docs for `eslint-plugin-react-hooks`](https://react.dev/reference/eslint-plugin-react-hooks), including rules and compiler issues
-
-Mark: And then the docs now have a page for the Eslint plugin of react hooks, including a bunch of information on all the different rules that it cover and that includes issues that'll get flagged by the compiler as well. [16:08]
-
-Carl: Also, yeah, I wanna say on the compiler inferring function names like that is like one of the most quietly mind blowing things I have seen in a long time. [16:19]
-
-I actually commented on the PR to ask like, what if this became a TC 39 proposal? Because this would have saved me days of effort over the life of my career. If there had been a little bit more data about what the heck is throwing an error instead of just like cannot read property of undefined. Oh thi this is quietly one of the mo going to be one of the most impactful changes in a long time I think. [16:29]
-
-Mark: I have actually, even just recently in some of the Immer work that I've been doing, gone in and replaced anonymous arrow functions with a named function just to try to get a better name and a stack trace. [16:55]
-
-Carl: Totally. Yeah, a hundred percent. And the annoyance of assigning an arrow function to a variable versus using a named function and how those are not the same thing. [17:06]
-
-## [React Native 1.0 on the horizon](https://youtu.be/GPtopk4y2LI?si=JoZVprPW33szn-6D)
-
-Mo: Cool. Let's move on to some React native news, which has gotten people a, a fair bit excited, which is one of the talks that was at React Universe comps that happened at the beginning of this month called React Native 1.0 is on the horizon. This is pretty exciting stuff because it's anecdotally, and I'm sure many people have had the same experience as me. [17:15]
-
-One of the biggest things that people oftentimes use, which is a really, really, you know, straw man argument, but nonetheless is there, is that, oh, react native's not stable because it's not 1.0. I kid you not, when I say three weeks ago we were talking about starting a new project here at Theo and someone brought this up as a reason not to use React Native as one of like the prospective clients that we had because another company who was trying to push them to use Flutter had told them, oh, it's not stable because it's not 1.0 da da da da da. [17:37]
-
-And you know, there's a little bit of fear mongering around this. The reality of it is that React Native has been around for way too long and it's been used in many, many serious production apps for, you know, several, several years now. And so I think this is something that a lot of people have discussed with the React Native Core team over the years. [18:06]
-
-And you know, there's always been a bit of a reluctance on going to 1.0 for various reasons. Um, and so this talk is really interesting 'cause they talk a little bit about the history of that and what the reasons are for that. But really what's happened over the last year is that the release process for React Native has been significantly streamlined. [18:23]
-
-So there are now six releases. Being targeted for every single year. So every other month there being a release from two releases, which was what we had in 2024 and you know, a lot more sporadic releases in the previous years. So there was no really never a schedule to it before where, whereas now there is one of the things that's been happening over the years, but really accelerated over the last, I'd say year, is that a lot of the APIs are being really stabilized, reduced, and the surfaces are being completely trimmed down. [18:38]
-
-And so the whole idea with this is less API surfaces externally means that there's less likelihood for breaking changes in the long term, which helps them feel confident to say, Hey, this is a 1.0 or reaching out sort of monumental point where they can actively say, Hey, this is a 1.0 release. And the other thing is that the React native. [19:06]
-
-Pipelines for building React native Core was quite a manual process in the past, and so what they've done in sort of recent years is worked on introducing a lot more end-to-end testing, some workflows that would test our C bugs and you know, breaking changes much quicker. And so that's really been a lot of the efforts behind the scenes, which you won't see in features and functionalities, but it's really been to the workflow for building React native. [19:25]
-
-And so a lot of this is really moving us towards that direction where there can be at 1.0. And so the conversation isn't. Potentially, hey, there's gonna be a 1.0 in the next few months. Maybe not even in the next year, but it is somewhere there where they're feeling like, okay, we can go ahead to, to basically releasing a 1.0 for React native at some point in the near future. [19:48]
-
-So the React team's gonna be, the React native team is gonna be working on this quite extensively and trying to reach a point where they're happy and so they're gonna be working with a bunch of people to start to potentially put a date on it, which is very exciting. [20:09]
-
-Carl: That is really exciting. That's a long time towards 1.0. [20:20]
-
-But like it would've felt premature I think for them to get, to call it a 1.0 before, or at least they would've had to do a lot of breaking. [20:22]
-
-Mark: Even just waiting for the new architecture to be the default, I think was a big thing. Mm-hmm. Yeah, definitely. [20:30]
-
-Carl: Yeah. And that really seems like it was a meaningful, a meaningful reason to delay, like it was such a large disruption to so many different parts of the ecosystem, but also so essential. [20:36]
-
-Yeah, it feels more truly native under the new architecture, rather than having to like serialize between two independent systems. It kind of reminds me of like when Docker launched because it was a Linux feature, you know, a Linux kernel feature. I remember for years they had like a, if you wanted to use it on Mac, you had to technically run a vm, which introduced all sorts of weirdness. [20:47]
-
-And so that feels, I dunno, this feels technically similar to me in how they like figured out how to not have two independent systems communicating with each other in that kind of way. And now that they've cleared that hurdle, they can get towards a greater level of stability. Cool. Awesome. [21:09]
-
-Mark: One other thing that actually kinda reminds me of, so we had squiggle conf a week and a half ago and one of the talks was from Shelley Vohr, who's part of the Electron core team and she did a talk about automating systems and you know, things like security and repeatability and what happens if the system goes down. [21:25]
-
-And it sounds like a lot of the effort that's been involved on the RN side really is about CI pipelines and automation and turning a manual release process into an automated release process. And you know, having that consistency is a pretty big deal here. [21:44]
-
-## [“React Won by Default – And It's Killing Frontend Innovation”](https://www.lorenstew.art/blog/react-won-by-default/)
-
-Carl: Cool. Drama post? [22:02]
-
-Mark: Drama post. [22:04]
-
-Carl: Yeah, so there was a recent post called React Won by default and it's killing front end innovation. [22:05]
-
-Mark: To some extent. There's nothing new in this post. People have been making complaints about this for years. [22:13]
-
-## Inevitable [HN argument](https://news.ycombinator.com/item?shownew&id=45252715)
-
-Mark: It's a pretty well written post, and it did make all the rounds and spawned massive 800 comment, hacker news thread and responses on Twitter and a bunch of other places. The first argument is that React itself has kind of stagnated that it was a big deal in 2013 when the virtual do solved problems with Angular, but that React really hasn't innovated since then claim, and that things like the React compiler are a bit more of a bandaid. [22:18]
-
-Whereas other frameworks like solid and spelt and quick are doing new and innovative things around signals and ruins and resum ability and other approaches to updating the dom. But the rest of the argument is that. The typical discussion these days for a project is, okay, which framework should we use? [22:48]
-
-Well, let's use React because it has the biggest ecosystem, because there's the most developers available because AI are familiar with it, because there's lots of libraries out there, et cetera. And the phrase that always comes to mind and for me is the old one about no one ever got fired for choosing IBM that back in the day, like IBM was the safe choice for, you know what, whatever tools it is sort of that same principle today. [23:09]
-
-Like most people are not generally choosing React. Because they're specifically excited about suspense or transitions or other things like that. It's the industry standard, so we'll stick with that. And so the article argues that because of that, because the mindset is used, react by default, that it's sort of choking out other frameworks that have had more innovation and newer interesting approaches. [23:39]
-
-And so it ends up offering some suggestions for things to evaluate about scaling and performance and team skills and whatnot. And then tries to counter argue the typical like size of the ecosystem type points. It's a well-written article, like it's not flame bait. The title is is well out there, but it makes a pretty good actual point and it spawned a lot of discussion, like I said, hacker News and a bunch of other places. [24:08]
-
-But I think the really interesting counterpoint to all that. Is Rick Hanlon from the React team put up a very long thread on Blue Sky, which really should be its own blog post at this point where he says that all the frameworks know how to update the do efficiently React has innovated in the past, but it's also, it was so good in the past. [24:34]
-
-People are actually kind of ignoring the innovations they've done since 2017 and 2018, and that reacts focus for the last seven years has been not about how can we make Dom updates faster per se, but about scheduling. Things like concurrent mode, transitions, suspense, even the new activity component builds off of the foundations that they've built for the last several years. [24:59]
-
-Yeah. And so his argument is that number one, when people say react is an innovating, they're ignoring all the new features built around concurrency. And number two, that most people are still thinking about using React in a very 20 16, 20 17 ish sort of way. Most people aren't even thinking about using the new capabilities that React has unlocked. [25:23]
-
-I think he's actually got a pretty good point. [25:50]
-
-Carl: That's fair. I would generally agree with that and like I am very much in that boat, I'll be honest, like I haven't written extensive from scratch, like build an app and react since about that time. The last time I really did that from scratch to like a full production level where I was like exclusively focused on the front end was about that time, like ended around 2021. [25:52]
-
-So I've been following a lot of this, but I haven't used it at the same level of depth that I used to. I have seen somebody who, you know, one of my internet acquaintances who I have a lot of respect for, as you know, both technically and like entrepreneurial and whatever. He's been extolling the virtues of server components for the last couple of months, I think, and it's been on my, you know, it's been somewhere on my to-do list to talk more with him. [26:15]
-
-Mark: Daniel Switz. [26:40]
-
-Carl: Yep, yep. Daniel Switz. Just like I've heard him say some things. It's like, okay, I feel like you get it and I feel like you get it in a way that you could communicate. It's crossed my mind actually to have him and Ricky and or him and Dan or I don't know, a group of people on a stage like this and just like talk about it and be like, what the fuck? What are we doing? How do you do this? So yeah, I don't know. It's like, it's definitely there is innovation happening. I think a lot of the innovation, like there's innovation happening and there's also just like roadblock clearing. It's like, you know, there's the innovative, you build the road, but then you have to deal with the consequences. [26:41]
-
-Like, great, you have this road. Like what is it like to actually use it? And then a lot of the time you realize there are speed bumps and whatever that you didn't realize you were building in the first place. And the fix there is not innovate. You don't just like, well that sucked. Let's build a new road. [27:16]
-
-No, you fix it. Figure out different ways to approach the same problem that have a different set of trade-offs. And so I think that's some of what's being complained about here is that like people are like, we need a new thing. We need to rewrite from scratch. And No, we don't. I don't think we do. So, yeah, I don't know. [27:33]
-
-I guess that's what I, what I have to say there. [27:52]
-
-## [Ricky on Ryan Carniato’s stream](https://www.youtube.com/watch?v=3vw6EAmruEU) talking about scheduling and demoing using modern React features
-
-Mark: So, sort of on on that note, Ryan Carniato from the solid team routinely does streams where he talks about what he's working on or you, where the ecosystem is going. He and Ricky have had a number of like, actually. Intentional and productive discussions back and forth on Blue Sky and Twitter where Ryan has said, we've got our own version of suspense, we've got our own version of transitions. [27:54]
-
-We're trying to do things this way. And Ricky has put up a demo and said, how does this, here's the React way to do this. How's this compare to the way you guys are doing it? And so Ricky was actually just on Ryan Carniatos stream on Friday and I looked, and it's a six hour long video. No, I most definitely did not watch the video. [28:17]
-
-I cheated and used a summarizing tool to try to gimme a sense of what they were actually talking about. But it looked like they talked about where React has gone and what has changed with all the different concurrency related features. And then I think they tried to take a sort of a classic react. I think it was like a React 17 to do application, and then they updated it live on stream to use all the modern latest React features. [28:38]
-
-So if you want to watch them talking about this for six hours, the video's there. But it's a good example of people who know how this, how these technologies are implemented, discussing them as well as Ricky demoing how you could actually use these in an application. [29:06]
-
-Carl: Yeah. I will say, going back to a point a little bit about, you know, you shared the long thread and made an offhand comment about like, this could really be a blog post at this point. [29:23]
-
-Like the post on Ricky's feed right before that is the, if you all promise not to ask me for docs or blog posts, maybe I'll explain a bit about why creating a cache API for suspense is so hard and it's, oh, I love that you're doing all of this, like social media outreach and everything, but like part of the problem that, part of the reason why nobody understands all of this and you have to do all the social media outreach is because there aren't static available resources for people to read. [29:31]
-
-So it's like, ah, I love that this is happening and it's so good and so helpful. And there's follow up that's not happening that I think is really crucially important. [29:55]
-
-Mark: That's actually been one of my running frustrations and complaints for a while. Ricky and I have actually had some back and forth on this, multiple times on Blue Sky. [30:03]
-
-Yeah. Admittedly, I'm also not sitting here, honestly. I should probably start watching the docs repos so I have a better sense of what updates do happen. That one's on me, but to a certain extent, my, my knowledge of what's in the docs can get a little stale. Right. But Ricky has repeatedly complained that. [30:12]
-
-People keep making the same wrong assumptions about what React has available, why the React team is doing things, et cetera. I've pushed them multiple times this year and said, you know, my answer is go write a docs page. Yeah. That covers exactly the topic you want and to have answered, and it answers it in exactly the way you want This material covered. [30:29]
-
-A lot of people are still not gonna read that docs page, but some people who are already looking at the docs will see it. And when you run into yet another one of these questions on social media, now you have the pre-written answer and you link to it rather than having to answer it from scratch every time you see the same misconception pop up on social media. [30:55]
-
-I, I wanna be clear, I, I am genuinely excited that Ricky has done so much outreach over the last year or so. Even just in the last couple weeks he was, he wrote dozens of tweets on both Blue Sky and Twitter around the threads related to the React innovation by default discussion. And I'm genuinely happy he's doing this much outreach. [31:18]
-
-It's sort of taking Dan's place in that sense. But when your great answers are buried, 15 replies deep in a Twitter thread, no one sees them other than the person you're responding to. And that is the kind of material that desperately ought to be its own blog post, as well as these couple top level threats as well. [31:40]
-
-And so I genuinely happy he's engaging. I would just love to see that material written up longer term. [32:03]
-
-Carl: This is clearly a bit of a cycle, you know, like social, this has been true for years generally. So like maybe this is an opportunity for someone here listening to go through some of the, to go through these threads. [32:09]
-
-Like if you're champing at the bit for an opportunity to have an impact on the ecosystem and on the industry, like this could be a pretty achievable way to do so. Like this content is out there, it exists, but not in a way that's discoverable. So like taking this knowledge that is being produced in ephemeral social media threads and then just like restructuring it, reformatting it into a markdown document and submitting a PR to react could be really effective. [32:24]
-
-I, I'll throw that gauntlet down, like that is an achievable thing that I am probably not gonna do. [32:52]
-
-Mark: People used to say that the real React docs was Dan Abramov's Twitter account, which he then deleted and all that info is gone. I don't expect blue sky to go down, but yeah, like if someone out there wanted to go through some of, you know, Dan and Ricky and whoever else's Blue Sky threads and pull out info and submit docs, prs like that would genuinely help the entire ecosystem. [32:58]
-
-Carl: Yep. Right. And it doesn't need to be perfect first. Drafts are so good. First, the first draft is so hard and going from first draft to published thing is still a lot of work. But man, just getting a first draft out is often the thing that tips it over the edge into actually happening. Yep. I'll just say that if anyone's looking for something. [33:20]
-
-Mark: Love the idea. Alright, moving right along. [33:38]
-
-## Server Components
-
-Mark: A few different updates related to server components this month. [33:41]
-
-## [React Router RSC framework mode preview](https://remix.run/blog/rsc-framework-mode-preview)
-
-Mark: The biggest would be that React Router now has RSC support in their framework mode builds. So React Router, as I understand it now, has three different modes. There's sort of the, the traditional client side only, here's your list of routes mode, there's a somewhat more complicated data mode, and then there's the full blown full build framework mode. [33:44]
-
-And so I believe they previously announced some RSC primitives available in data mode. And then I believe the framework mode is now taking those and expanding on them somehow to make it available for the full build. So, you know, again, having more RSC options available besides just next is a pretty big deal. [34:09]
-
-And especially when it's built into something as widely used as React router. [34:30]
-
-Carl: Yep. Love that. [34:34]
-
-## also [middleware is now stable](https://remix.run/blog/middleware)
-
-Mark: They also announced that React router now has stable middleware support as well. Your routes can now have middleware. [34:36]
-
-## Krasimir Tsonev’s [“Can I Use RSC Today?” support matrix](https://rsc.krasimirtsonev.com/) and experimental [Forket “RSC without a framework” build tool](https://krasimirtsonev.com/blog/article/vanilla-react-server-components-with-no-framework)
-
-Mark: Krasimir Tsonev, who is a React educator and has been around for a while, put up a nifty little support matrix called, can I use RSC today, where he tried to do equivalent bits of RSC usage and features across several different tools from next in, in Remix and Waku and various other tools. [34:44]
-
-He was also very curious. I, I actually talked to him at React Summit in, in June, and I think this is what. And he was talking to a couple other folks, and I think this is what spawned him doing that deep dive where he was actually kind of bothered by the fact that server components require a framework. [35:07]
-
-And so he went off and ended up implementing his own tool called for cat. Which is supposed to be somehow a proof of concept for using an RFC without an actual framework per se. So sort of a more primitive, granular client server separation build tool. [35:24]
-
-## [RSBuild support for RSCs](https://bsky.app/profile/ebey.bsky.social/post/3lyf6vixick26)
-
-Mark: Speaking of build tools, I saw mention that there is a set of plugins available that try to add some RSC support to the RS build, rust based bundler as well. [35:43]
-
-## Useful post on [parallel and recursive route rendering](https://twofoldframework.com/blog/parallel-and-recursive-route-rendering-with-rsc)
-
-Mark: Finally, I also saw a good blog post that talked about techniques for doing parallel and recursive route rendering with RSCs. As Carl mentioned earlier, all this stuff is frankly outside of my experience, I've never tried to render, you know, RSCs much less do parallel and recursive stuff, but it clearly, people are out there experimenting with these things and that's good. [35:55]
-
-Carl: Oh man. I'm looking at the blog post. You mentioned React server components without a framework and it's got a mention of Flux. Oh, throwback. Yeah. I mean we're Reactiflux because for about a six or eight months it was React and then you pair it with Flux and that was how you do UI and state management. [36:15]
-
-So it's wow, throwback. That's a long time. [36:33]
-
-## All the NPM compromises and malware this month
-
-Carl: Alright, little bit of a roundup on. Vulnerabilities and security incidents on MPM. There's been a lot this month. [36:35]
-
-Mark: I think that the first one happened late last month, and we mentioned it briefly. Yeah. And then there was just like this constant flood of new compromises, new vulnerabilities, all kinds of packages being taken over, ranging from crypto miners to like full-blown credential stealing. [36:44]
-
-It's, it's been pretty bad out there folks. [37:02]
-
-Carl: Right? So last month. NX was compromised, which is discussed in this set of links that we have here. I'll send one at a time as we get into it, but yeah, so it, what we've seen has been everything from like pretty, there was a targeted attack that would do like intercede, crypto payments and sub out addresses for, you know, an attacker's wallet actually that had a small innovation in that category of attack where it would generate an address that was visually similar to the one that you had used to try and escape. Notice I heard that attack only got like $50 or like less than $500. I've seen some conflicting numbers, but like generally not effective, did not achieve its goals. [37:04]
-
-But like it hit debug. Like it hit a package that I saw the security alert go out and I was like, oh, that sounds like something that I might use. And I checked. I'm like, yep, a bunch of projects on my computer were using that package. That was the one that got targeted with crypto interception, but previously, I think it was nx, was it last month, that we had the people who were stealing credentials and using AI to generate other code to steal credentials. [37:50]
-
-Like, ah, that's the worst attack I've ever seen. And the only reason it wasn't worse was because of the limited scope of compromise. So like I was primed seeing that innovative, highly effective attack when I saw this massively widely distributed compromise of debug. And I have a little bit of egg on my face regarding this because I had pinged in the node Discord that I help operate saying like, oh, you need to look at this. This is awful. And it ended up not being as bad as I thought because that was a crypto miner, not a credential stealer. [38:19]
-
-Mark: The attack itself seemed like a pretty big deal, and then it was almost sort of wasted on, well, it has to lead to you accidentally build a client side app that has the compromised version built into it. [38:54]
-
-Carl: Right, they managed to successfully target one of the single most widely used packages. And completely squandered it by using it to execute an attack that had such limited application that they just didn't get anything. So like that's just straight up, like they screwed up, like they achieved a massive level of success and just like immediately fell on their face and did nothing with it. [39:08]
-
-That's just a miss. Like that was just luck, that it wasn't worse than it was. [39:34]
-
-Mark: But on the, on the flip side, the article that's talking about the ongoing supply chain attack did do a bunch of credential stealing, targeting a bunch of packages like [39:38]
-
-## [npm package maintainer Qix](https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack)
-
-Mark: tiny color and a [39:47]
-
-## [CrowdStrike npm Packages](https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages)
-
-Mark: bunch of CrowdStrike packages. Yeah. I don't know the extent of like what sites got hit because of that compromise. [39:48]
-
-Yeah. But I believe that one's, that one had did a, done a pretty good job of finding credentials and publishing them on either, I think it was like either creating a new GitHub repo or creating a new specially named branch in GitHub repos to try to exfiltrate the credentials. [39:57]
-
-Carl: Yeah. Oh, I was just reading this one actually. [40:14]
-
-## [GitHub Actions npm Token Theft](https://socket.dev/blog/nx-supply-chain-attack-investigation-github-actions-workflow-exploit)
-
-Carl: It was, they had, they, somebody had added a line to the GitHub action that did, that would echo out the title of the PR and because it just did an un escaped string, you know, echo this. You could just terminate that and then run whatever you wanted. On the GitHub action, like, do not let any arbitrary person run whatever script they want in your seat. [40:16]
-
-Like, oh man, that it's, that's pretty bad. And also, oof, this is CrowdStrike. Like, remember CrowdStrike and how they took down like every, like air travel around the world from another security problem that they had, and oops, they're a cybersecurity company where preventing attacks is their job. Oops. Yeah. [40:38]
-
-I don't understand how they're still operating successfully. [40:57]
-
-## [GitHub response](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/)
-
-Mark: So, GitHub and NPM did actually put up a, a, an announcement saying that they're gonna be doing a lot of work to try to tighten up. Publishing of packages down the road, they're gonna be making changes to two fa it says they're gonna deprecate time-based passwords. [41:01]
-
-That sounds like it's gonna end up being a, a big deal. I don't fully understand the implications yet. And, and they said they're gonna, you know, take time to roll these changes out. But that one seems like a big deal. We're also making and trying to apply more limits to tokens and work on better trusted pet publishing workflows as well. [41:20]
-
-Interesting. [41:40]
-
-Carl: Yeah. That's all important and useful, but like also, I don't know if there, if you just, if somebody opens a PR to your CI, that adds. A vulnerable un escaped string. Like it doesn't really matter how, what your authentication or publishing workflow looks like if that gets merged. Like you're vulnerable. [41:41]
-
-So dunno how, dunno what you do about that specifically. But, okay. [41:56]
-
-## ⚡ Lightning round ⚡
-
-Carl: Let's hop into our lightning round. [42:00]
-
-## [Porting Modern TypeScript to Run on DOS](https://jimb.ly/2025/09/23/qauntumpulse-from-steam-to-floppy/)
-
-Mark: I love a good article that just goes into absurd amounts of detail on a ridiculous thing that someone's trying to do, but they commit to the bit fully. And this one was, someone had a. JavaScript based game and they ported it all the way back to work on dos. [42:03]
-
-Like why would you want to, I don't know, but apparently they actually made this work and I love it. [42:21]
-
-Carl: That is insanity, and I also love it spiritually similar to Doom running in TypeScript types, just for no reason. Yep. Love. [42:27]
-
-## [Cloudflare DDOSed themselves with a bad `useEffect` fetch](https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/?amp%253But)
-
-Mark: CloudFlare got into the news this month because they had a dashboard failure that cascaded, and believe it or not, it was caused by manually fetching data in a use effect that went into an infinite loop, which also means they weren't actually using like React query or anything like that. [42:35]
-
-Oops. [42:55]
-
-Carl: Yeah, I did hear like none of their services were affected. It was just the control panels that was taken down, so that's good. I also saw Guillermo Roush throwing some shade at the CloudFlare CEO after that. So, you know, drama post. [42:56]
-
-## [A very lovely writeup of the evolution of css `zoom`](https://www.bocoup.com/blog/the-webs-most-tolerated-feature)
-
-Carl: There's a cute post from Bocoup. There are web consultancy that's had a, a big impact on standards and web platform implementation details. [43:11]
-
-So they, they've heard a cute blog post, the web's most tolerated feature looking into Zoom and how Zoom works. And it is kind, it's kind of cute. I don't know, just like it's a fun look at standards and like how. Cross browser implementation stuff works and how like, oh actually this like totally unstandardized thing just happens to work really well and everyone uses it. [43:21]
-
-So, I don't know. It's cute. It's a cute post from people who are deeply involved in the standardization and implementation process, highlighting a case where like standards like just kind of didn't happen and it was fine. [43:44]
-
-## [What You Need to Know about Modern CSS](https://frontendmasters.com/blog/what-you-need-to-know-about-modern-css-2025-edition/)
-
-Carl: Anyway, yeah, there was another good post from front end Masters who I, I've just always had a soft spot in my heart for front end masters because they were, that's the first platform that I learned react from. [43:56]
-
-It was like a comparative class of Angular React and Ember, and I was like, oh, react seems nice. So like I owe them a debt to, you know, my entire career. So that's, it's cool. It's nice to see 'em still around and still staying on the ball. They published a post What you Need to Know about Modern CSS 2025 edition. [44:09]
-
-Mark: And it was long too. It was long. [44:26]
-
-Carl: It's big and I appreciate that because I've gone to a couple of conferences and I've seen talk from various people who are more, who work on CSS a little bit more. Una Kravets, I think is who I'm most specifically thinking of, who's wonderful and great and a great speaker. [44:28]
-
-But like I'll see her talk about some CSS stuff and be like, wow, all of this is stuff that I've never heard of and CSS is completely different than what I've used in a lot of my career. That's awesome. And I don't know what to do about that. So this is a great post for me in that situation and going, ah, I need to catch up on like the last six years of stuff that I haven't really paid close attention to as it evolves step by step. [44:44]
-
-So, great summary. [45:09]
-
-Mark: We have a few different posts on browser behavior. So there was I and all from folks who have worked on browsers for a long time, I might add. [45:10]
-
-## [Fetch streams are great, but not for measuring upload/download progress](https://jakearchibald.com/2025/fetch-streams-not-for-progress/)
-
-Mark: Jake Archibald did one on fetch streams are great, but don't use them for measuring upload download progress points out that you still basically need to use XHR for that instead. [45:21]
-
-Although there's discussion of adding some new options and callbacks to fetch that might accurately handle that at some point. [45:33]
-
-## [Why do browsers throttle JS timers?](https://nolanlawson.com/2025/08/31/why-do-browsers-throttle-javascript-timers/)
-
-Mark: There was one from Nolan Lawson talking about why do browsers throttle JS timers? So you know, why does that time timeout zero actually be, why is it more like four milliseconds, et cetera? [45:40]
-
-And basically it's because people rate bad code or either intentionally or unintentionally that can do bad things. [45:53]
-
-## [“How Modern Browsers Work” deep dive, Addy Osmani](https://addyo.substack.com/p/how-modern-browsers-work)
-
-Mark: And then Addy Osmani did a pretty long post a, mid-level overview of how modern browsers work overall, going from, you know, parsing JavaScript in HTML in various ways to using GPUs to put pixels on the page. [46:01]
-
-Carl: Yeah, it's funny to me to see, I don't know, I've just been seeing Addy Osmani and Nolan Lawson and Jake Archibald for so long. It's like, man, how great for them to stay on the top of the game for so long. It's great. [46:18]
-
-## [Biome: Stress-testing WIP `noFloatingPromises` lint rule](https://vercel.com/blog/stress-testing-biomes-nofloatingpromises-lint-rule)
-
-Carl: One that I like here. I like seeing Vercel and Biome collaborated on stress testing, biomes new, no floating promises lint rule. [46:32]
-
-I, again, have a soft spot in my heart For Biome, I was a initial backer of Rome back in the day, which was then forked after some maintainer shenanigans into Biome. They never really achieved the original vision, or have not yet at least, which was like unified, like linting compiling, you know, one tool to rule them all kind of thing. [46:41]
-
-That it was called Rome because all paths, all roads lead to Rome, so it was trying to do all of it. They have achieved a lot of their goals, but not quite enough to really meaningfully claim to do all of it. [47:02]
-
-Mark: It's become a pretty solid, a pretty solid formatter, but they never really managed to get into any of the multi tools sharing one a ST side. [47:15]
-
-Carl: Yeah, right. Oh, that was it. It was because you know, you, you would have like Babel and ES lint and TypeScript and prettier and all of those, and all of them were independently parsing ASTs and then operating on. So like that's just a lot of wasted effort. So the, the goal was, the original goal was like one AST, all of this stuff talking to that will be an order of magnitude performance improvement. [47:23]
-
-Mark: Mm-hmm. [47:44]
-
-Carl: But anyway, so enough background, they have a new no floating promises rule because if you don't await or you know, respond to a promise, it can cause all sorts of super weird stuff. They say that, you know, a lot of engineers have campfire stories of floating promises taking down production, which is definitely true. [47:44]
-
-I've definitely, a lot of the weirdest errors I've ever encountered track back to, oh, we didn't correctly wait for this promise to resolve, so this is it. This is a fun, deep dive technical writeup of how do you detect that promise. Has not been waited for. What does it even mean to return a promise when TypeScript has a built-in promise? [48:02]
-
-Like construct? It's a good read. It's a good deep dive. [48:23]
-
-Mark: I should point out that the article was written by Dmitri Metropolis, who just got done organizing Squiggle conf and is also the person who did Doom in Typescripts. [48:27]
-
-Carl: Oh, it is, Love Dmitri. Love that. [48:34]
-
-## [Bun: How `bun install` is so fast](https://bun.com/blog/behind-the-scenes-of-bun-install)
-
-Carl: There is a good deep dive here into Bun Install and how it's so fast. [48:37]
-
-They say on average it runs seven times faster than MPM and 17 fast times faster than you yarn. It's a large post and it's got a lot of real deep benchmark stuff. Mm-hmm. [48:43]
-
-Mark: I think Lydia Halley wrote that one actually very well written post. Lot of detail. [48:53]
-
-Carl: Wait, was she on React? [48:58]
-
-Mark: I believe she was working for Vercel and left, and I think she actually just joined Bun as a DevRel. [49:00]
-
-Carl: Great. I'm just always here for like a deep technical dive. So many, so many blog posts are just a little bit more surface level, so seeing something more like a white paper, a technical writeup, I just love I, it's such a good window into the real challenges that different people around our industries are encountering [49:06]
-
-## [Styled-Components fork for perf and React 19 compat](https://www.sanity.io/blog/cut-styled-components-into-pieces-this-is-our-last-resort)
-
-Mark: for folks who are still using style components, the sanity company actually forked the existing now unmaintained library and made a couple major updates. [49:23]
-
-One, to try to optimize the overall performance and another to try to provide React 19 compat. They say they are not maintaining these forks per se, but they have done the work because they themselves still relied on it. And so they've made those, they've published those so that other people can benefit from it. [49:35]
-
-So if you're still work, still using style components, you may want to take a look at that. [49:57]
-
-## [Vite SSR: Custom `getStaticProps`](https://www.patron.com/blog/post/vite-ssr-getstaticprops-replacement/)
-
-Mark: Also saw a nice little post that talked about building your own get static props alike equivalent if you're using Vite for SSR. [50:02]
-
-## [Dominic Gannaway’s new framework Ripple](https://github.com/trueadm/ripple)
-
-Mark: And in the frameworks that are not actually React, but related category. Dominic Getaway, who originally created a React Delight called Inferno and was on the React team for a while, has built his a new independent framework called Ripple, which tries to pull together some new ideas around template compilation and use of JS syntax, but in a way that's different than React. [50:11]
-
-## [Remix v3: MJ hints “iframe-like async primitives”](https://x.com/mjackson/status/1971816432427298951)
-
-Mark: And then Michael Jackson and Ryan Florence continue to drop assorted hints online about what their Remix version three is going to look like. Michael's latest tweets are saying, what if he could just sort of use iframes or iframe like behavior for async loading? And I really just want to see the actual examples at this point, but they're dropping hints about what it'll be like. [50:35]
-
-And oh, the plan is to actually show stuff off at Remix Jam, which I think is coming up next month. [51:00]
-
-Carl: Yep. I am skeptical. I don't know, I, I appreciate the broad strokes of iframe, but the actual security constraints of using iframes is, that's just not, they're not good. It's not pleasant. It's not, you know, that's very like 2003 era web development and we stopped doing that because it kind of sucked. [51:07]
-
-It was hard to make good experiences. If it's not literally in I frames, that's very different. So maybe it'll be better than that. There's an argument to be made that what he is talking about shares significant overlap with the islands style micro front ends. So, I'm not checked out. I'm curious, but I'm skeptical. [51:27]
-
-Unfortunately. It sounds like Mo's having like significant internet challenges in his office right now. So I'm gonna, I'm gonna pull in some of the stuff that would've been, you know, that he wanted to talk about. [51:49]
-
-## [React Native RFC to remove Old Architecture](https://github.com/react-native-community/discussions-and-proposals/pull/929)
-
-Carl: There's been a RFC for React native, for a plan for actually removing the old architecture, the previous way of serializing communication between the JavaScript engine and the native layer. [51:57]
-
-So it's not only, not only is the new architecture default, they are now proactively communi or they're proactively planning how to get rid of the old architecture entirely. Well, that's great. That feels like a big step towards 1.0, like we were talking about before. [52:13]
-
-## [Cloudflare’s new “Cap’n Web” RPC; GraphQL alternative?](https://blog.cloudflare.com/capnweb-javascript-rpc-library/)
-
-Mark: So CloudFlare announced a new tool called Cap'n Web, which is a RPC system meant for browsers and web servers. [52:28]
-
-And this was created by the same person who, by Ken and Varta, who had created a couple other serialization libraries, one called Capin Proto, and Capin. Proto works with both c plus plus and JavaScript and possibly a couple other languages. And Capin proto is sort of a follow on that's specifically meant for use with web and can be sent back and forth using just plain JSON. [52:38]
-
-I believe the article actually kind of pitches it sort of as an alternative to GraphQL in a way. It actually does a funky little thing where if you make what looks like an initial request for an item and then you get back a promise for that response, you can call map on the promise and. Essentially map over what will be the list of items and say, for example, gimme details on all the child items by their id, but then it'll actually get batched up into a single request. [53:05]
-
-So there's some technical trickery going on there, but it sounds like it's meant to simplify both making a request back and forth and managing the overhead of what would've potentially been many independent requests as well. Thus, the comparison to like a GraphQL style thing. [53:42]
-
-Carl: Interesting. And also, I'll shout out. [53:59]
-
-You know, Cap'n Proto here is spiritually very similar to the challenge, it's solving a problem that's spiritually very similar to the new architecture and React Native, like basically, you know, this RPC is going instead of going across like a native JavaScript layer, like a new React native, this is how do you do a similar type of communication between systems across the network boundary? [54:02]
-
-And the challenge is like the reason you would use something like Cap'n Proto or Protocol Buffers, which you know, there's kind of competitors there is because the serialization costs and the volume of communication if you're using JSON, is just much higher, like converting it into a string. It's basically a string versus a binary data format. [54:25]
-
-Like the, one of the problems with JS is that you're encoding not just the data, but also the structure. You're saying, here's the object, here's the keys, here's what it looks like. And that's. That's information. You know, if you're sending that information across the wire, that's extra effort. If you already have two, two agents on opposite ends of a network and they say, we agree that our communication is in this format, then you don't need to send the format across the wire. [54:46]
-
-So that's the fundamental like reason why you might use one of these tools instead of just sending JSON over HTTP and yeah, it's interesting. This is, it's pretty cool. [55:16]
-
-## [Expo UI: Building SwiftUI apps](https://docs.expo.dev/guides/expo-ui-swift-ui/)
-
-Carl: Cool. The Expo had an interesting post talking about using Swift UI in React Native, so that, that's pretty cool. Like being able to directly, if you're in, only, if you're only targeting a native environment, being able to. [55:26]
-
-Exclusively use native primitives is like a huge win. Like if you don't, you know, it's always good to remove compatibility layers if you don't need the compatibility. So that's really cool. It's it, this looks pretty interesting if you're doing stuff on Mac Os or like Apple TV or things like that. [55:40]
-
-## [TanStack DB: An interactive guide](https://frontendatscale.com/blog/tanstack-db/)
-
-Mark: So the TanStack folks recently announced a new package called TanStack DB, which is supposed to be a smart syncing layer on top of TanStack Query that can do things like in-memory filtering and querying of data very efficiently. [55:57]
-
-And so there was a neat post that was an interactive guide to TanStack db and discussing some of the options and some of the things you can do with it. [56:13]
-
-## [TS 6.0: may switch to `strict` options by default](https://github.com/microsoft/TypeScript/issues/62333)
-
-Carl: TypeScript version six may switch to strict options by default. This is, [56:21]
-
-Mark: hallelujah. [56:27]
-
-Carl: Yeah, right. What a long time coming. Like I have treated this as a deep, you know, this has been step one of setting up a new TypeScript project for me since I've started using TypeScript. 'cause it's always been the best practice. So I love that they are discussing, switching this over. Yeah. It starts almost a decade ago. We began to add certain options beyond, no implicit any in strict no checks. So, yeah, like almost a decade ago. So that's the, that's cool. TypeScript 6.0 will assume that dash dash strict is on unless explicitly disabled, which means specific settings like strict no checks and no implicit any will be enabled unless it's turned off explicitly. [56:28]
-
-Woo. Cool. No implicit any is if you don't turn that off, like you're not really using Patrick, like it's just sparkling JavaScript. So that cool. Love that. Love to see this. [57:05]
-
-Mark: There's a lot of debates over the nuances of what that concept of turning on strict by default actually means. But I would assume that something along those lines would land and yeah, it's way overdue. [57:16]
-
-## [Shopify’s RN New Architecture migration](https://shopify.engineering/react-native-new-architecture)
-
-Mark: Alright, last couple ones and then we're done with the not so lightning. Lightning round Shopify put up a post talking about their migration to the React native new architecture and went through both some pros and cons and pitfalls of what that process involved. [57:28]
-
-## [The Bloat of Edge-Case First Libraries](https://43081j.com/2025/09/bloat-of-edge-case-libraries)
-
-Mark: And then the last one is from James, who has the really funky username that I'm not even going to try to pronounce, but he's been working as part of the E 18 E ecosystem speed up process. [57:42]
-
-In fact, he's the person that I did a stream on a couple days ago where we talked about my work to make the Immer library faster. And his post looks at like, gives an example of, let's say you have a math clamp function that takes some arguments. But you don't want it to crash if someone does something stupid like passing in, you know, a string instead of a number and next thing you know, like two thirds of your function is just validating the inputs before it actually does anything. [57:54]
-
-And he argues that, you know what? This actually ends up being kind of a waste of space and execution time. And that to a certain extent, if someone passes in bad input, that's their problem and not your problem, which I can sort of get behind. [58:24]
-
-Carl: Yeah, interesting. That makes a lot of sense. It's kind of the right, it's a challenge between sharing code and doing it inline how when you start trying to do it inline, you end up re-implementing a lot. [58:40]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-Carl: Cool. Let's talk about some conferences. [58:51]
-
-## [React Alicante](https://reactalicante.es/) Oct 2-4
-
-Carl: We have in like three days, two days. React Alicante in Spain, October 2nd through fourth. [58:53]
-
-Mark: I will be speaking there. I'm flying out on Wednesday. [59:01]
-
-Carl: Woo. And then you're fly. And then you're flying [59:04]
-
-Mark: all the back and then flying all the way back across, across the world for to attend React Conf. [59:07]
-
-Carl: Yep. I'll be there too. [59:11]
-
-## [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
-
-Carl: So yeah, react Conf in Henderson, Nevada, right near Vegas. I'm actually gonna be driving from San Jose, so like if you're in the Bay Area a couple days before the React conf, lemme know. I don't know. I'm gonna go hiking, so, we'll, it's gonna be an adventure. [59:13]
-
-## [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
-
-Carl: Then a couple days after React Conf, Remix is doing their own conference in Toronto, the Remix Jam. [59:29]
-
-So yeah, maybe. We'll, we will see. It'll be interesting to see what they come out with. Yeah, I'm curious. Yeah. [59:37]
-
-## [ViteConf](https://viteconf.amsterdam/) Oct 9-10 Amsterdam, Netherlands
-
-Carl: Anyway, coincident with that, ViteConf is happening October 9th and 10th in Amsterdam. That'll be cool. [59:43]
-
-Love to see what they come out with. [59:50]
-
-## [JSConf North America](https://events.linuxfoundation.org/jsconf-north-america/) Oct 14-16 Chesapeake Bay, MD, USA
-
-Carl: JSConf is doing a couple of events all over the world actually, so they're doing JSConf North America October 14th through 16th in Chesapeake Bay, Maryland, [59:52]
-
-## [JSConf Chile](https://jsconf.cl/) Oct 24-25 Santiago, Chile
-
-Carl: and they're also doing re JSConf Chile, October 24th and 25th in Santiago, Chile. [01:00:03]
-
-## [React Native London](https://www.reactnativelondon.co.uk/) Oct 30-31
-
-Carl: We've also got, after that React Native London, October 30th and 31st, [01:00:10]
-
-Mark: and Mo runs that, so you should totally be there and support him [01:00:18]
-
-## [React India](https://www.reactindia.io/) Oct 31 Nov 1 Goa, India
-
-Carl: after that, there's React India October 31st and November 1st, [01:00:22]
-
-## [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
-
-Carl: and then the Wey Wey Web, I think I'm pronouncing that right. It says it's a yay, yay conference, international conference for ux. But yeah, that's happening in Malaga, Spain, November 17th and 18th. [01:00:26]
-
-## [React Summit](https://reactsummit.us/) Nov 18-21 New York, NY, USA
-
-Carl: And then we've got React Summit happening in New York, November 18th through 21st. [01:00:39]
-
-So that's cool. We'll see. Maybe I can make it to that. It's in my hometown, so Yeah, that'd be great. [01:00:43]
-
-## [React Advanced](https://reactadvanced.com/) Nov 28th, London UK
-
-Mark: And then React. React Advanced is November 28th, all and although it's uh, inconveniently the day after us Thanksgiving this year, they had done it in late October, previous years, and I think since they're not doing React Berlin, they bumped the schedule for React Advance to be sort of in the middle where those would've been. [01:00:48]
-
-## Outro
-
-Carl: That's everything we got for you this month. Thank you so much for joining us. We'll be back on the last Wednesday of the month probably, although we had to reschedule this month again, sorry. Or we will be back in your podcast feed just as soon as we can. We gather sources from, actually this month we pretty much only gathered sources from Reactive Fly. [01:01:08]
-
-It was a good month for, you know, us staying up to date. Yeah, generally we do subscribe to this week in React, which is a great source. Follow lots of people on Blue Sky and Twitter, the React JS subreddit and just, you know, generally all over the internet. We try and stay in touch. If you see anything that you think that we should be aware of, definitely post. [01:01:25]
-
-Actually, you should just post it to the Tech News and Reads channel here. I would love it if we could have some more chatter going on there and it really does help us stay on top of things and helps me understand it. If, you know, if you post a link and then you and somebody else have a conversation, I will read that and it will inform my opinion. [01:01:46]
-
-So yeah, it's a great way to do it. If this is a show that you get value from and wanna support, best way to do so is by reviewing us on whatever platform you listen to or tell your friends and coworkers about it. So, you know, send 'em a link. Cheers. Thanks so much for listening. [01:02:02]
diff --git a/src/transcripts/tmir-2025-10.md b/src/transcripts/tmir-2025-10.md
deleted file mode 100644
index 5773f74..0000000
--- a/src/transcripts/tmir-2025-10.md
+++ /dev/null
@@ -1,759 +0,0 @@
----
-title: "TMiR 2025-10: Post-conf; React 19.2, React Foundation, React Native removing old architecture. Next.js has too many directives"
-date: 2025-10-29
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down 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](#intro)] Intro
-- [[00:46](#new-releases)] New releases
- - [[00:49](#immer-102)] [Immer 10.2](https://github.com/immerjs/immer/releases/tag/v10.2.0)
- - [[01:55](#arktype-arkregex-typed-regex)] [ArkType ArkRegex](https://arktype.io/docs/blog/arkregex) (typed regex)
-- [[02:41](#main-content)] Main Content
- - [[02:45](#react-conf)] React Conf
- - [[02:50](#official-reactconf-2025-recap)] [Official ReactConf 2025 Recap](https://react.dev/blog/2025/10/16/react-conf-2025-recap)
- - [[02:57](#introducing-the-react-foundation-also-from-linux-foundation-meta-engineering-and-seth-webster)] [Introducing the React Foundation](https://react.dev/blog/2025/10/07/introducing-the-react-foundation) (also from [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-the-react-foundation), [Meta engineering](https://engineering.fb.com/2025/10/07/open-source/introducing-the-react-foundation-the-new-home-for-react-react-native/), and [Seth Webster](https://thenewstack.io/react-foundation-leader-on-whats-next-for-the-framework/))
- - [[17:03](#192-activity-useeffectevent)] 19.2 (Activity, useEffectEvent)
- - [[17:27](#react-native-news)] React Native news
- - [[17:32](#new-architecture-only-from-v082)] [New architecture only from v0.82](https://reactnative.dev/blog/2025/10/08/react-native-0.82#new-architecture-only)
- - [[18:52](#vega-os-announcement)] [Vega OS announcement](https://developer.amazon.com/apps-and-games/blogs/2025/09/announcing-vega-os)
- - [[19:04](#vega-introduction-at-react-conf)] [Vega introduction at React Conf](https://www.youtube.com/watch?v=p9OcztRyDl0&t=5737s)
- - [[22:36](#joe-savonas-exploring-react-performance-talk)] Joe Savona’s “[Exploring React Performance](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=20274s)” talk
- - [[23:26](#rickys-async-react-part-i-and-part-ii-repo)] Ricky’s “[Async React Part I](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=10907s)” and “[Part II](https://www.youtube.com/watch?v=p9OcztRyDl0&t=29073s)” ([repo](https://github.com/rickhanlonii/async-react))
- - [[27:12](#async-react-working-group)] [Async React Working Group](https://github.com/reactwg/async-react)
- - [[27:35](#first-discussion-of-more-docs-ideas)] First [discussion of more docs ideas](https://github.com/reactwg/async-react/discussions/2)
- - [[28:27](#remix-v3-announcement)] Remix v3 announcement
- - [[29:03](#announcement-demo-timestamped-breakdown)] [Announcement demo timestamped breakdown](https://github.com/markdalgleish/remix3-resources)
- - [[31:28](#updates-syntax-can-be-customized)] [Updates syntax can be customized?](https://x.com/sergiodxa/status/1976878377509568871)
- - [[34:44](#i-built-the-same-app-10-times-code)] [I built the same app 10 times](https://www.lorenstew.art/blog/10-kanban-boards) ([code](https://github.com/lorenseanstewart/kanban-comparison))
- - [[37:57](#same-author-as-react-won-by-default-and-its-killing-innovation)] Same author as [React Won by Default and It’s Killing Innovation](https://www.lorenstew.art/blog/react-won-by-default/)
- - [[43:33](#solito-5)] [Solito 5](https://solito.dev/v5)
- - [[46:49](#next-16-and-directives-debate)] Next 16 and Directives debate
- - [[46:56](#next-16-released)] [Next 16 released](https://nextjs.org/blog/next-16)
- - [[49:41](#directives-and-the-platform-boundary)] [Directives and the Platform Boundary](https://tanstack.com/blog/directives-and-the-platform-boundary)
- - [[50:34](#technical-critique-of-next-app-router-everyone-hates-nextjs)] Technical critique of Next App Router: [Everyone Hates Next.js](https://paperclover.net/blog/webdev/everyone-hates-nextjs)
-- [[54:56](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[54:58](#viteconf-roundup)] [ViteConf roundup](https://voidzero.dev/posts/whats-new-viteconf-2025)
- - [[55:49](#aws-outage-postmortem)] [AWS Outage Postmortem](https://aws.amazon.com/message/101925/)
- - [[57:10](#voltra)] [Voltra](https://x.com/saul_sharma/status/1972161677165473980)
- - [[58:10](#building-fully-native-apps-with-eas)] [Building fully native apps with EAS](https://blog.swmansion.com/building-fully-native-ios-apps-with-expo-eas-760b5480d7c5)
- - [[58:52](#react-native-imgui)] [React Native \\\<\\\> Imgui](https://x.com/tmikov/status/1979771014340047088)
- - [[59:53](#lodash-maintenance-foundation)] [Lodash maintenance foundation](https://blog.ulisesgascon.com/the-future-of-lodash)
- - [[01:00:45](#build-your-own-key-value-database)] [Build Your Own Key-Value Database](https://www.nan.fyi/database)
- - [[01:02:24](#jared-palmer-asking-for-gh-pr-suggestions-and-giving-some-technical-details)] [Jared Palmer asking for GH PR suggestions](https://x.com/jaredpalmer/status/1979204222420664405) and giving [some technical details](https://x.com/jaredpalmer/status/1980619222918262842)
- - [[01:03:54](#node-25-with-jsonstringify-improvements)] [Node 25 with JSON.stringify improvements](https://nodejs.org/en/blog/release/v25.0.0)
- - [[01:04:15](#cloudflare-vs-vercel-cpu-benchmarks-and-perf-optimizations)] [Cloudflare vs Vercel CPU benchmarks and perf optimizations](https://blog.cloudflare.com/unpacking-cloudflare-workers-cpu-performance-benchmarks/)
- - [[01:05:07](#ff-interop-feature-request-rankings)] [FF Interop Feature Request Rankings](https://interop-rank.jakearchibald.com/)
- - [[01:05:53](#vjeuxs-history-of-prettier)] [Vjeux’s History of Prettier](https://blog.vjeux.com/2025/javascript/birth-of-prettier.html)
-- [[01:10:41](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:10:43](#react-native-london-nov-13-14-london-uk)] [React Native London](http://reactnativelondon.co.uk) Nov 13-14 London, UK
- - [[01:11:26](#use-code-tmir10-to-get-10-off)] Use code \`TMIR10\` to get 10% off
- - [[01:11:42](#wey-wey-web-nov-17-18-malaga-spain)] [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
- - [[01:11:49](#react-summit-nov-18-21-new-york-ny-usa)] [React Summit](https://reactsummit.us/) Nov 18, 21 New York, NY, USA
- - [[01:12:10](#react-advanced-nov-28-london-england)] [React Advanced](https://reactadvanced.com/) Nov 28, London, England
- - [[01:12:33](#react-paris-cfp-is-open)] [React Paris](https://react.paris/) CFP is open
-- [[01:12:49](#ending)] Ending
-
-# This Month in React - October 2025 (SM)
-
-## Intro
-
-**Carl:** Hello everyone. Thank you for joining us for the October edition of This Month in React. As we recap what's going on with React, React native in the web, we're coming to you live from React Flux, the place for professional developers using React. [00:00]
-
-I'm Carl. I'm a staff staff product developer and freelance community leader here at React Flux, where I run community programs like these events and build tools to help keep the community operating. [00:12]
-
-**Mark:** Hi, I'm Mark. My day job is at Replay.io and in my copious amounts of spare time, I maintain Redux and rewrite Immer. [00:23]
-
-**Mo:** I am Mo, I head the mobile team at Theo. I'm an active part of the React native ecosystem and community, and I organize the React Native London Meetups and conference, which is coming up in two weeks. [00:30]
-
-Terrifyingly so. [00:42]
-
-**Carl:** Coming right up. Yeah. And you got a shout out that we're gonna talk about. [00:43]
-
-## New releases
-
-**Carl:** Let's start with some new releases. Mark, tell us about Immer. [00:46]
-
-## [Immer 10.2](https://github.com/immerjs/immer/releases/tag/v10.2.0)
-
-**Mark:** Okay, I can, I can do both these things. So I actually take very full credit for this one. So to be clear, I do not maintain the Immer immutable update library that is Michelle West Rate, who created it and has maintained it all the easier years. [00:49]
-
-However, since the start of September, I have sunk a stupid amount of time, something like 120 plus hours into trying to rewrite the internals of Immer for faster performance after some re users filed complaints to the Redux repos, that it was kind of slow. So I filed a few different prs, one to make some relatively small tweaks, and then a couple larger architectural changes. [01:01]
-
-And Michelle just merged and released Immer 10.2 with the small options. And we are hoping to land the larger architectural changes in the near future. And those will probably come out as Immer version 11, hopefully in the next few weeks or something. So I'm excited faster for performance free upgrades. [01:26]
-
-Yeah, should be. [01:45]
-
-**Carl:** Yeah, love some big core performance improvements of deep packages. That's awesome. [01:46]
-
-**Mark:** And I will also hopefully turn this into a conference talk. Nice. [01:51]
-
-## [ArkType ArkRegex](https://arktype.io/docs/blog/arkregex) (typed regex)
-
-**Mark:** Along with that, I, I just saw the announcement, I think like yesterday, that the author of the ARC type validation Library, which is a, a competitor to Zod that takes a, a rather different API approach, just released a, a similar tool called ARC RegX. [01:55]
-
-It's a function that is supposed to be a replacement for defining regular expressions in JavaScript, but it actually parses the RegX string into TypeScript types so that it can both. Interpret at the type level, what the regular expression is doing, and also even provide syntax errors if the reg itself is invalid. [02:12]
-
-Just looking at the docs, my mind is blown. [02:38]
-
-## Main Content
-
-**Carl:** Well, yeah, other than new releases, we have a bunch of main content this month. [02:41]
-
-## React Conf
-
-**Carl:** The React conf happened, what, three weeks ago, and a bunch of new stuff came out of there. [02:45]
-
-## [Official ReactConf 2025 Recap](https://react.dev/blog/2025/10/16/react-conf-2025-recap)
-
-**Carl:** They did put up an official recap blog post from it on the 16th, about a week after the event happened. [02:50]
-
-## [Introducing the React Foundation](https://react.dev/blog/2025/10/07/introducing-the-react-foundation) (also from [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-the-react-foundation), [Meta engineering](https://engineering.fb.com/2025/10/07/open-source/introducing-the-react-foundation-the-new-home-for-react-react-native/), and [Seth Webster](https://thenewstack.io/react-foundation-leader-on-whats-next-for-the-framework/))
-
-**Carl:** The big takeaway here, I think, well, I don't know, we got a couple of big takeaways, but one of the headlines is definitely the React Foundation. This is a pretty big change to, or this sounds like it will be a moderately large change to the governance of React. They're pretty light on details of the actual governance, so far. They have talked about like a new technical steering committee. But they also say that the governance of that is not finalized. The members are not finalized, but they do have the founding members of the founding sponsors basically of this foundation, which are Amazon Call Stack, Expo, Meta, Microsoft Software Mansion, and Vercel with Seth Webster. [02:57]
-
-Seth Webster is executive director and he's the what manager of the React core team, [03:39]
-
-**Mark:** Basically. Yes. [03:44]
-
-**Carl:** Yeah, so that makes sense. He is basically already doing that role and expanding what the core team means to an intercompany organization. But yeah, it's a lot of the details that I was most curious about, like what does, what does this mean for governance? Like how will decisions be made are not yet answered right now from the, from the various posts on this. A quote is, the React team is actively working on this new technical governance structure, and we'll share more details in a future post. So this is an announcement of a future announcement in some ways, but it's pretty real. [03:46]
-
-So this is in collaboration with the Open JS Foundation, which is a partner to the Linux Foundation. So like th these are very large, pretty well-founded organizations that the React team is glomming onto in support of like a neutral home for React, as they call it. [04:19]
-
-It's sounds like they're in incorporating React Native into this as well, which I think is not necessarily a given. You know, if you're talking about the governance of React, what that means for React Native is not necessarily implied. But just looking at the founding members like Amazon, Call Stack, Software Mansion, and Expo, and I guess Microsoft too, like those are all heavy React native investors. [04:38]
-
-**Mo:** I think it's quite surprising in that sense because it's more heavy on the React native side. Like Vercel is really the key sort of non-react native player. The rest are really heavy on React Native and there's like noticeably missing membership from like Shopify on the Remix side as an example. I, I actually find it's very skewed towards React Native, almost shockingly. [05:01]
-
-**Carl:** Yeah, I'd agree with that. It's, it is almost shockingly skewed towards React. React Native, given that it was not really pitched as the React Native foundation. That's true. I guess Software Mansion does do a fair amount of web React work. But I, I believe Call Stack is predominantly a React native shop as well. [05:24]
-
-**Mark:** So I'll do my usual thing where I, I step back and provide historical context and what matter at all. So React was invented at Facebook. It has always been a project owned by Facebook and Meta. The code has been open source, but. You know, for years the entire development team was Facebook meta employees paid by Meta to work on React. And I've said even in my conference talks this year about Meta, Vercel, React ownership, that the React team has had the freedom to work on what they want. And that's true, but I've, I was reminded in some conversations with React team members at React Con, how much their work is constrained by, like the fact that their performance reviews are, "what have you done to further meta's goals this year?" [05:42]
-
-And so in some ways their ability to push React in the technical directions that they think are right, are limited by how much they can make the case for that. Inside Meta, even something like the Concurrent Stores work is essentially being pitched as, how can we make Facebook's Ads Manager app faster in a lot of ways? [06:38]
-
-So we saw multiple React team members move over to Vercel. Like people used to complain that this is all a Facebook app, all the meetings are inside Meta. There's no public roadmap, it's only meta. And then we had team members move to Vercel, and then it became, well, now Vercel is applying too much ownership to React and all the stuff we've talked about with Next and server components and Vercel and how that's supposedly driving the roadmap, et cetera. [07:02]
-
-And so the team itself has been split across two companies, and they're working together. It's one team, but it's kind of within these two companies. And so because of Reacts widespread usage, there's been calls for many, many years that there ought to be some kind of an independent foundation that would own the trademarks, the rights, the development process. [07:30]
-
-To React itself. And it always seemed kinda like one of those pipe dreams. The calls on Twitter to build, React into the browser. And obviously there's no way that's going to happen. And, and this felt like much of the same kind of idea. And so they, they did the initial React and the initial keynote at React Con, and they were mostly focusing on technical things. [07:56]
-
-Like last year we, we fixed the, the sibling preloading bug. That was the suspense gate problem that everyone was talking about last year. And 19.2 came out and the compiler is 1.0. And then Seth came out and he did the one more thing routine and as soon as he put the React Foundation slide up, my jaw dropped. [08:17]
-
-And I think I even said out loud, oh my word, they actually did it. And my first reaction was, even without knowing. Any actual details about what the foundation is or how it's going to work or whether this is even going to work out in practice. The fact that they have taken the time to do the legal preparation work to try to make this happen and are actually attempting to execute on that is a huge deal for React and the ecosystem. [08:40]
-
-It, it is a statement of good faith and intent for how they want React to proceed in the future. Like without any details, my immediate reaction is, yes, finally, this is a good step forward. We'll see what it means in practice, but this is a really big deal. [09:12]
-
-**Carl:** Yeah, I would agree with that. It's a really big deal that they're moving in this direction. [09:32]
-
-I'm really curious about the details because I think there's a lot of, I don't know, like in the past they've done working groups and et cetera. And my understanding of the takeaway is generally, has generally been that they found it really difficult to manage participation in those like open access kind of arenas. [09:37]
-
-So maybe the, this is kind of like adding a new layer of abstraction perhaps with administrative support from currently thriving independent foundations. Mm-hmm. So that, that definitely makes me think that this has a real chance of being something real and valuable that goes on for a long time. I'm curious what it means for things like, like in practice, it's not like anyone's employer is changing. [09:56]
-
-No details have been shared yet. At least that anyone is being paid from this new foundation. I, I don't know whether to call it meta or Facebook 'cause it's on the fb.com domain. Mm-hmm. But in the Facebook engineering announcement here, they do say that Meta has committed to a five year partnership with over $3 million in funding. [10:23]
-
-I don't know what other funding they might have. I don't know what other sources of funding they might have in the future, but like just looking at five years, $3 million, like that's 600,000 per year, which is like, you know, for meta engineers, that's like free engineers. So I don't know. I don't know what that means for people's incentives and where they will work and how their focus and performance will be evaluated. [10:42]
-
-Yeah. [11:04]
-
-**Mo:** What that rules out is that effectively the React Native or React and React Native Core teams will definitely not be unemployed by the React Foundation. Right. 'cause that would basically cover three salaries, which is far smaller than what the React teams are. [11:05]
-
-**Carl:** I think the React core team has like 10 engineers. [11:19]
-
-**Mo:** And RN is about the same. So you're talking 20 engineers. It's definitely not going to cover those employees to move them over, which is in some capacity. And then details are to be fleshed out. But in some capacity it is a bit disappointing because it would be great if they had more freedom as the React Native Core team to play around without the restrictions, like you mentioned, of the reviews that Meta has internally. [11:22]
-
-And so it's gonna be interesting to see how that Dyna dynamic plays out effectively because there is still gonna be that same team. At Meta [11:44]
-
-**Mark:** I, I have three sources of information that I'm piecing together for some of how the foundation is supposed to work. Seth Webster answered a few questions about this during the q and a session that was broadcast at React Conf. [11:51]
-
-I had a conversation with a couple React team members and the topic came up about how things would be governed. And then there was an article on the new stack where Seth Perry was interviewed and was giving some further details about some of the governance. [12:05]
-
-So as best I understand it, so you've got kind of the corporate level stuff that's Meta, Amazon, Callstack, Vercel, et cetera. They will then elect a technical steering committee. Which is, I guess sort of similar to how Node and other projects work, Seth said in the q and a, that meta will start with five votes on that corporate board, and then it will go down to one over the next five years. So you kind of a decreasing amount of influence in that sense. [12:21]
-
-The technical steering committee, I assume, would be able to make decisions themselves, but obviously the fact that they are employees of the companies elected by those companies, et cetera, they would be taking their company's interests into account in the process. The article says that the technical governance will be in the open more than it once was. [12:53]
-
-Request for comments, sets of stages, et cetera. But a lot of the process is still to be figured out. The article also talks about the foundation doing things like investing in React hubs, helping boot camps teach React better, possibly some things with conferences and alignment and such. So it sounds like the foundation is going to be doing more outreachy things. [13:17]
-
-So there, there's a lot of this that is not clear what it means in practice yet, but certainly. React is not solely a meta owned thing at this point. There are multiple companies that are invested in it. There is a, a future for React independent of META'S ownership and goals. And this all feels like the people who care are trained to do the right thing. [13:43]
-
-And [14:11]
-
-**Mo:** on the conference side, I mean, I hope that's the case because one of the, as a conference organizer, one of the things that's perhaps challenging is that Meta doesn't necessarily sponsor any conferences beyond just React conf, right? And so, look, it's well known that that's sort of the case. And so maybe the React Foundations that is going to be able to sponsor those conferences, even if it's not a meta badge to speak, which would be very, very interesting if some of that is used for that. [14:11]
-
-So I'm sure it's not just Meta who's investing, right? Like I, I suspect that there's funding coming in from. Amazon and Microsoft, at least from the bigger, bigger sort of established enterprises [14:38]
-
-**Carl:** hopefully. And that's interesting. And the new Stack article interviewed Seth and has a bunch of poll quotes from him and they do talk about that, that like the foundation will look at expanding the annual React conf. [14:49]
-
-I guess that's not sponsoring other conferences, but they're talking about conferences at least. But also something that caught my attention. They say while React Comp is one of the few conferences that actually makes a profit, it basically only paid for itself. And also it's a thousand dollars a ticket conference. [15:00]
-
-So like hopefully the mode of making conferences self-sustaining is not making them cost a thousand dollars. [15:14]
-
-**Mo:** Yeah. I mean conferences are from experience a very, very expensive endeavor. And if you don't have companies backing them, they will make a loss. [15:22]
-
-**Carl:** I do wanna shout out, as we mentioned at the start, Seth says "We have lots of boot camps out there that are doing their best, but they're also sending people out into the world misinformed about how React works." [15:31]
-
-This is interesting there. It's a, it's funny, they're actually hitting on a couple of points that I've investigated myself about how to do businesses in like a community since like I had previously connected with a bootcamp. Somebody was working there as the curriculum lead and they were doing a curriculum overhaul. [15:40]
-
-'cause they hadn't changed what they were teaching in three or four years. And they were like, is this still relevant? Is this what the industry's using? And I was like, cool. I help run a community. I know lots of experts. I would be happy to facilitate some kind of professional review. And then the bootcamp curriculum lead got laid off because that was 2022 and lots of things were not happening. So it's interesting to see them talk about things that I've thought a lot about. [15:59]
-
-And also a lovely shout out, Seth says there are also cohorts such as meetups and local groups that could be assisted. One meetup actually led to the creation of the conference React Native London. So that's super cool. Love that for you, Mo. [16:22]
-
-**Mo:** Yeah, I didn't, I, I did not have that on my Bingo card to get a shout out from Seth Webster on an interview, which is awesome. Yeah, it was good to have him last year. [16:36]
-
-**Carl:** Mo is the organizer of React Native London and that one meetup that led to the creation. So that, that's just fun. [16:44]
-
-That's cool. We have actual players in the ecosystem in the podcast right now. [16:51]
-
-**Mo:** Well, you got Mark. So I'm stepping up to very, very, very high standards. Pretending to. [16:55]
-
-**Carl:** Cool though. Yeah. So I don't know. I don't know if there's more to say there. [17:00]
-
-## 19.2 (Activity, useEffectEvent)
-
-**Mark:** Some of the more technical stuff. So they, they talked about React 19.2 coming out, which if you've been paying attention to this podcast for the last several months, you would've known all the details already. Like the new activity component for being able to hide components while persisting state use effect event for hopefully fewer use effect related bugs, et cetera. React compiler hit 1.0 and then [17:03]
-
-## React Native news
-
-**Mark:** Mo as like as usual, you wanna talk about the React Native-y things? [17:27]
-
-## [New architecture only from v0.82](https://reactnative.dev/blog/2025/10/08/react-native-0.82#new-architecture-only)
-
-**Mo:** So a few updates that they did, one of which was quite surprising was that the next release of React native version 0.82 is going to be new architecture only. [17:32]
-
-So obviously earlier on a few months ago, we talked about how they deprecated the old architecture than they froze the old architecture. Now they're dropping the old architecture. And so to me that was a much faster deprecation cycle than I, I would've expected. Specifically when it comes to the fact that there are still a fair few libraries that are using the old architecture and only support the old architecture. [17:44]
-
-So to give you a very concrete example, we had our monthly meetup literally yesterday, and there was a talk about Arrive, which is this animation engine that a lot of people are using to animate websites and make really, really cool stuff. But what we learned surprisingly was that Rive only supports the old architecture. [18:06]
-
-So what that means is that this company who's a very popular healthcare company, really don't have a path to sort of migrate to the new architecture and hence version 0.82 until Rive starts to support the new architecture. So there are still libraries, albeit the majority of major libraries have been ported to the new architecture that are still hanging behind. [18:24]
-
-So I'm quite surprised by this, but we'll see how it goes. It probably means that these library maintainers really need to like step up in the next month or two and get ready. [18:44]
-
-## [Vega OS announcement](https://developer.amazon.com/apps-and-games/blogs/2025/09/announcing-vega-os)
-
-**Mo:** The second big thing, which I have a little bit about later on, but just a quick one, is that Amazon did the Vega Os announcement earlier. [18:52]
-
-It was towards the end of September that they actually announced it, but [19:02]
-
-## [Vega introduction at React Conf](https://www.youtube.com/watch?v=p9OcztRyDl0&t=5737s)
-
-**Mo:** they formally talked to the React and React native communities about it during React Conf. This is a completely new operating system that's fully built from scratch by Amazon folks and React Native is the UI layer. It's the only way that you can write apps for it, which is quite a big investment from Amazon's perspective into React Native as a technology. [19:04]
-
-So Amazon makes a lot of devices. For a little bit of context, you might've seen their Fire TV devices, some of the Kindle fire devices that they had, but also like Echo dots and a whole slew of different devices that they manufacture. And previously a lot of these were running on Android or a variety of Android called Fire Os that they had adopted from the Android open source projects. [19:27]
-
-And so now they've kind of completely ditched that and they're betting long term on React native now at our company at Theo and a bunch of other companies have been sort of working with Amazon behind the scenes on this. And we're aware of this but weren't really allowed to speak about it. So it's now out in the public. [19:47]
-
-But it has been a good while, which I cannot specify how long that duration is that I have been aware of this, but just not able to talk about it and have been working with the Amazon folks to make sure that things are ready for their launch. So they have an introduction video at React Con, which I think is interesting because TV apps need to run on very, very limited specs. You're talking like a few gigs of Ram one or two gigs of ram and like very, very, very slow CPUs and some of them are even worse than that. So effectively they really had to optimize the living crap out of their operating system and make sure that React plays nice with it and is like the first class citizen when it comes to it. [20:02]
-
-So it's, it's very interesting how they had to optimize it and it was a big undertaking for them. So. I guess congrats to the Amazon team, but beyond that, it's quite interesting for people that are interested in performance and React and React native. [20:38]
-
-**Carl:** Yeah, I was just scanning this to see if I could find any details about what they built on top of, because like, I don't know, nobody builds a whole OS from scratch anymore. And this is on top of Linux? [20:48]
-
-**Mo:** Yeah, it's c plus plus on top of Linux. Basically it's a Linux. Or is a Unix based system. [20:59]
-
-**Carl:** Right, like, and so is Android. Like, I'm curious to what extent this is a locked down, stripped back version of Android that they're calling Vega. They don't say that anywhere, but like reading the tea leaves here, I, my assumption is that the, I don't know, Android was such a massive undertaking that Google then acquired and commercialized. [21:05]
-
-Curious to hear more technical details about the OS layer here and how it… [21:28]
-
-**Mo:** I can tell you a little bit about that because I've known about it for a while. It's not on top of Android in any capacity. It is fully, the Android open source project components of it are fully stripped out. It's built from scratch, which means that compatibility with old apps is. [21:32]
-
-Limited and there's other solutions. It's not that you can run Android apps on it as an example that we're the old Fire OS apps. [21:47]
-
-**Carl:** So wait, it sounds a little bit like you're saying there is a shared lineage with Android, but it's different enough that its own technically distinct thing. [21:54]
-
-**Mo:** They share a technical lineage in the same capacity that like Mac Os and Androids here, which is, they are both unique systems and that's pretty much it. [22:02]
-
-Like they serve the same kernel but like so does 90% of devices out there. So it's as Android, as IOS's, Android, if that kind of makes sense. [22:11]
-
-**Carl:** The Tree of Life, kingdom Family order. Like this is not shared genus. This is shared order maybe? Yes. Okay, cool. Good to know. Thank you. [22:19]
-
-**Mark:** I do wanna highlight a couple talks in particular, and again, you can look at the whole React con recap blog posts to get links to the different talks and the different portions of the live stream. [22:27]
-
-## Joe Savona’s “[Exploring React Performance](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=20274s)” talk
-
-**Mark:** A lot of good talks that were worth watching, but two that I liked in particular, Joe Savona did a talk on some of the React team's performance experiments, and there's a bit of controversy because he showed a bunch of hypothetical, semi hypothetical benchmark numbers without any real details on the actual implementation of the benchmarks. [22:36]
-
-And then some of them were like, versus we built NAP with signals and compared it with one with React and then ex a highly prototype React and a bunch of other stuff. And then people were saying, well, we tried to mimic this and we think you're probably using signals the wrong way. But it was still interesting to hear the discussion around, we agree that performance has been a problem and we've tried prototyping some different ideas to see what's possible and where bottlenecks might be. [22:56]
-
-## Ricky’s “[Async React Part I](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=10907s)” and “[Part II](https://www.youtube.com/watch?v=p9OcztRyDl0&t=29073s)” ([repo](https://github.com/rickhanlonii/async-react))
-
-**Mark:** The other one I really wanna point to though, Rick Hanlon did a talk called Async React and he had a few major, he had a couple different points out of this. [23:26]
-
-One was that the React team has been talking about things like suspense and concurrency since 2018, and if it's been hard to follow where the React team is trained to go with this, it's 'cause the React team itself really didn't know where they were trained to go with this. He even pulled out meeting notes from a React team weekly meeting in like 2015 or 2016 where they started having the first initial ideas for, we think we want to go in this direction, but they really didn't know what the final result ought to look like or how they were going to get there. [23:36]
-
-And so showed a diagram with a whole bunch of back and forth wavy lines like we, we don't know where we're going, but now it's 2025. We've gotten through the confusion. We've now built all the main concurrent pieces that we were trained to build. We are seeing the results of even like the React 16 fiber rerate. [24:15]
-
-And now we can actually say, we've built these pieces and here's how they ought to fit together. And so the second half of his talk was a demo where he took a badly written but viable React app, which uses use effect for data fetching and manual setting, state for loading states and things like that. [24:37]
-
-And he first refactored it to have a bunch of transitions for better loading animations, using suspense for the data fetching, and he showed the visible improvements in user experience. And then his point towards the end was that, yeah, the, so like this is how modern Async React code ought to work. But in fact, you shouldn't even have to write most of this code in your own app because the transitions and the loading states and everything else really ought to be embedded in your router and your data fetching library. [24:56]
-
-Now, unfortunately, his actual talk got interrupted for stupid technical reasons. So he came back at the end of day two and picked up with his demo and actually had a chance to do a better version of it. [25:36]
-
-And so I think the key points are, one, the React team has now built the concurrent async features that they've talked about for years. Two, a lot of us, including myself, are still kind of stuck in like a 20 16, 20 18 era mindset of how to use React three. These things make writing React apps better and better user experience. Four, we need to get these things embedded in component libraries and data fetching libraries so that a lot of this stuff just works outta the box. [25:48]
-
-So I highly, highly recommend watching Ricky's talk. He also put up the demo code as well. [26:23]
-
-**Carl:** That was a good talk. It was a good demo. I will say, while watching him write the code. I was like, man, this looks really complicated. [26:29]
-
-**Mark:** Yeah. And that, and that's another point that we're going to touch on here with a couple of the, the other things as well. [26:37]
-
-One other thing that really caught my attention, so if you've been listening to podcasts for a while, you've heard me agitating, saying that we really need is a new React working group where folks from the community can officially communicate to the React team for things like, Hey, we think there should be more docs to cover this topic. [26:41]
-
-Or, oops, create React app just broke. I think you should fix it, and things like that. And Ricky was actually the person who drove most of the React eight team. Working group. [27:00]
-
-## [Async React Working Group](https://github.com/reactwg/async-react)
-
-**Mark:** And so at the end of his talk, Ricky actually announced that there is now a new Async React working group. And this is sort of a catchall, it's meant to cover discussions of things like how do we get async React features into major ecosystem libraries and, what kind of docs should we have to cover this stuff? [27:12]
-
-## First [discussion of more docs ideas](https://github.com/reactwg/async-react/discussions/2)
-
-**Mark:** And so the, even the first discussion thread is a lot of discussion between me, Ricky, Dan Aberman of Corbin Crutchley, about a whole bunch of possible docs, pages that we could add that would cover things like transitions and suspense and how to use them correctly. [27:35]
-
-And getting people from the community to contribute those new docs pages rather than waiting on the React team. To write them. So I am actually genuinely, genuinely excited. Like I've done a lot of complaining and this is the answer to my complaints that we have working group and docs plans and an agreement that people outside the team can contribute. [27:53]
-
-So like I am actually legitimately thrilled by this. [28:16]
-
-**Carl:** Nice. I do appreciate more, I don't know, open participation more, more discussion. That's great. [28:21]
-
-## Remix v3 announcement
-
-**Carl:** Should we get into Remix V three? [28:27]
-
-**Mark:** Yes, we should. Alright, so usual caveat, I still have not had time to actually watch the announcement, but I, I think I can give a fair summary of it from having seen the discussion on Twitter and the articles afterwards. [28:29]
-
-We have mentioned for the last several months that they were teasing Remix V three is going to be, not pre-ACT, its own component model, something with iframes, whatever. And our last comments on it were just show us some code already. Well, at the Remix Jam conference, they did actually show us the code. [28:43]
-
-## [Announcement demo timestamped breakdown](https://github.com/markdalgleish/remix3-resources)
-
-**Mark:** There was a, a repo put together that did timestamped links to all the appropriate pieces of the announcement video. So if you'd like to be able to jump in and see the examples of what Remix V three code is supposed to look like, that should make it easier. My first impressions, again, just having seen screenshots of the code in following the discussions, is that Remix v three's component model is sort of a mixture between React, view and backbone. [29:03]
-
-So it's kind of like React in that you have function components and they, and that uses JSX. It's kind of like view and the composition API, where you're given a closure as the setup. It's a little bit like backbone in that the function component you're rating still sort of is organized like as if it were a class. [29:35]
-
-It passes in a reference to the instance rather than getting the props as an argument, and you're supposed to call it this. And part of that is to make use of a TypeScript typing trick that lets you declare the type of this as an argument to a function. But also you manually trigger updates by first mutating a variable in the setup closure, and then you manually call this update. [29:58]
-
-And so Ryan Florence even said, this is basically old school React class component, this dot force update. Essentially, so I, I can see bits and pieces of parallels and influences between all three of those frameworks. When I look at the Remix code, it's also supposed to come with a bunch of utilities for being able to compose event handlers together. [30:29]
-
-And yeah, so we, we have finally seen the code. I believe they also gave some demonstrations of what the server side loading story is supposed to look like. Some kind of an I frame alike component that has its own URL and can automatically re fetch HTML. I haven't looked into those pieces as much, so very big picture. [30:54]
-
-I saw a lot of people arguing about having this dot update. A lot of people saying it feels like a step backwards, it's manual update code. [31:19]
-
-## [Updates syntax can be customized?](https://x.com/sergiodxa/status/1976878377509568871)
-
-**Mark:** But some people demonstrated that you can very quickly write your own wrappers that just call this DOT update internally. I have seen wrappers that mimic like the used state hook. [31:28]
-
-I've seen wrappers for other state management libraries like Redux. So it's a primitive that can clearly be abstracted if you really want to. I saw some good posts and articles from James Long and a couple other people with thoughts on the ability to compose interactions together. Carl, to your point that modern React and all the new async features feel very complicated. [31:39]
-
-Like there's good reasons why methods like transitions exist to try to give better user experiences, but it's just all these additional concepts and behaviors you have to keep track of in your head. And Remix is trying to go for a less magic, less abstraction approach. So we'll see what it means in terms of adoption. [32:06]
-
-Again, this is non-reactive, so different framework, different ecosystem. Who knows what the actual adoption will look like, but I get the sense of what they're trying to go for and I, I think it will appeal to some number of users out there that want to have that kind of behavior. [32:31]
-
-**Carl:** Yeah, I'll definitely keep paying attention to it 'cause they're thoughtful about things and historically have just done a lot. [32:49]
-
-So I'm very curious to see where this goes. But my gut feeling here is that this is going to end up more as an API exploration and that any great ideas that come out of it will be a fresh exploration and then maybe validate some ideas that get brought into React or view or other big tools. But yeah, I, I could be wrong, could be, could be more independently successful than that. [32:58]
-
-They, they did stress in the video that I watched, that this is all like prototype phase. So they, like right now apparently there's splitting it all up into a bunch of different packages. They can iterate independently and explore a bunch of different things. But the, the final intended usage would be from one package, not from 20 different packages. Just to throw that out there as a a thing that will change. Yeah, I don't know. We'll see. We'll see. I think the component model is just gonna be really hard to disrupt. [33:25]
-
-One, one thing I did see in the video of Ryan Florence talking about just talking while he was demoing, he like compared and contrasted with like, here's how we do state changes and you just call the dispatch function instead of set state. [33:54]
-
-And I was like, I dunno, you can do that in React. Like they've been encouraging people to do that for years, for like six years basically Ever since hooks came out and you could do a state reducer, they were like, please, except for trivial uses of state, all of your state should be in a reducer and you should use dispatch. Not set state. So just like calling that out as a point of comparison, like React has been trying to do that for a long time too. It's just nobody actually does, I dunno, just caught my attention. [34:08]
-
-**Mark:** Well least we have an actual code to critique now and argue about instead of the vague teasing. True facts. [34:35]
-
-**Carl:** I will happily continue reading code and critiquing. [34:41]
-
-## [I built the same app 10 times](https://www.lorenstew.art/blog/10-kanban-boards) ([code](https://github.com/lorenseanstewart/kanban-comparison))
-
-**Carl:** Speaking of which , I love this project. I have thought about doing this so many different times and I never have because it's hard. Somebody built the same app 10 times in a variety of different frameworks and tools and benchmarked them and compared and contrasted their performance in a bunch of different metrics. [34:44]
-
-It seemed like they focused pretty heavily on like bundle size to me, very wordy. I, I will say I got a little bit lost in the [35:05]
-
-**Mark:** instruction. Very wordy and very, also, a lot of the article was very clearly AI generated. I saw some comments from the author saying he had written pieces of it in sections and used AI to help with it. [35:12]
-
-So like there, there was clearly human involvement in it, but the, the AI generation of the article itself was a critique point. [35:22]
-
-**Carl:** Yeah. Just like as I'm scrolling, it's got so many paragraphs in a row that are all like identically long. Just a little bit of a wall of text. I definitely skimmed this pretty hard. [35:30]
-
-All that aside, like I just love the idea of doing the exact same thing with the exact same. Like, well, I don't know that they use the same test suite, but that, that was always my idea is build. You build an end-to-end test suite and then you get a passing app for that test suite in a bunch of different tools. [35:38]
-
-I meant to do more of a deep code review on a couple of the different implementations. It's a CanBan board, it's, you know, a Trello clone type project where you're doing task management with cards and drag and drop. I guess it, it's a great and a parable comparison because drag and drop is really hard to do and so it's very frequently something people try to lean on libraries for. [35:54]
-
-So if you are implementing it yourself, that's kind of cha, that makes it a little bit challenging to use as a point of comparison. But the tools that were used here, he built it analog, which I guess is vanilla js is what I'm assuming, or [36:15]
-
-**Mark:** analog is actually a, a next like tool for Angular. [36:31]
-
-**Carl:** Oh great. Okay. Okay. So you built it an analog, which is an angular type thing. [36:36]
-
-And HTMX, Marco, which I'd never heard of. Next.JS, of course. Next. Sure. Qwik City, which is Qwik. I've heard of Qwik City I had not heard of. So this is I guess [36:41]
-
-**Mark:** probably another solid versus solid start type thing. [36:53]
-
-**Carl:** Qwik city to qwik Sure. Solid start spelt Kit Tan Stack with solid and then Tan Stack with React. [36:55]
-
-Yeah, one of the first tables, one of the first actual like points of comparison of the output tables is just on bundle size and how much JavaScript was served in order to. Get this app running. They used Next.JS version 16 as the baseline and that was about 500 kilobytes gzipped, which is huge. It's big hand stack. [37:03]
-
-Start with React. Clocked in at about 300 kilobytes a little bit more with solid was a half of that hand stack. Start with solid was 150 ish kilobytes. The smallest was Marco. 12. At 12 kilobytes followed by quick city at 88. Oh, I just realized there's parenthesized compressed. I thought I was reading the compressed and I was not. [37:25]
-
-**Mark:** There's also the board page versus the homepage sizes. [37:49]
-
-**Carl:** Yeah. Okay. Alright. This is more confusingly presented than I realized. [37:53]
-
-## Same author as [React Won by Default and It’s Killing Innovation](https://www.lorenstew.art/blog/react-won-by-default/)
-
-**Mark:** I think the biggest picture takeaways, number one, it's worth noting that the author of this article previously put up a post a month or two ago saying that React by is the default choice and it's killing innovation in the ecosystem. [37:57]
-
-So that kind of to where they're coming from. But I do think they did. They were legitimately trying to do a real meaningful comparison, even if the results were sort of what they were hoping they would be. IE reacted big and bad. So yeah, the big takeaways are like React itself is huge and so any React app is going to be very large bundle size wise. [38:08]
-
-And look, if we do like Tan Stack with Solid instead of Tan Stack with React, it gets smaller. But also if you do these other frameworks, it gets even better smaller and then it kind of ends with a bit of a, another rant about React is a bad choice. [38:32]
-
-**Carl:** Yeah, I, I will validate that. To me it also looked like they really tried to give React a fair shake here. [38:49]
-
-Like, you know, if you wanted to, if you were wanting to complain about bundle size, if React apps, like there are so many easy ways to bloat this up to a couple of megabytes. So like the fact that they didn't do that is indicative enough to me that they tried to give this a fair shot. It's cool. I love this. [38:55]
-
-This is a great project, great effort. I don't know that, to me, at the end of the day, this is interesting and fascinating and a great point of comparison, and also like not that meaningful because the performance metrics that you measure here that are easily measured by comparing the outputs of identically functional applications, that's really only like maybe a third of the reason why you would choose to build an app with any particular set of tools. [39:11]
-
-Like really, if you're starting a company and hiring engineers and doing a greenfield project. Like some of the most important things are how much will this cost? [39:41]
-
-**Mark:** How well is everything? How well is everything documented? How easily can we spin up engineers who know these things? I mean, the, the ecosystem argument is a real thing. [39:52]
-
-**Carl:** And like, you know, if it takes you two months to find a developer, you know, a senior developer who can build your app in Marco, you know, you could do that in a week. I don't know. The hiring for React is much easier than hiring for some niche tool. And I have seen writeups of people saying like, yeah, we built our startup on this niche framework and we couldn't hire for it. And that ended up contributing to the death of the company. [39:59]
-
-So like, you know, these performance metrics are important, they're really useful, it's great to have them. So we know where opportunities to improve are like tying this back mark to your Immer work. Like if somebody hadn't complained about performance, you wouldn't know that it needed to get better. [40:23]
-
-Pretty [40:37]
-
-**Mark:** much. Yeah. [40:37]
-
-**Carl:** So this is great and I love it, but it's also not the end all, be all of like decision making for, things. Yeah. It's also, man, this, it's just so hard to read because of how long it is. I wish they'd stripped this down a bit more. [40:38]
-
-**Mo:** And if we take like a step back out of our like web ecosystem bubble for a second, like you go to like the backend world and like enterprise business companies or finance or whatever, and like they employ a lot of developers, right? [40:49]
-
-Like thousands, thousands and thousands of developers. And like there's a reason they're all on Java and .Net is because like they can hire for those and it's pretty easy to build a team around. That's the top priority. Even like this stuff is quite minuscule when people are, companies are hiring at a large scale. [41:04]
-
-And then the second thing, which is like not accounted for, I think in this like approach of looking at like just the bundle size that's outputted is the fact that like your productivity with the fact that most of the AI tools are really like optimized around React is not something that you should not look at and consider when you're choosing something. [41:21]
-
-There's so much training data and so much like tooling around building React apps quickly and prototyping React features or React apps that with AI that is just a bit, it feels a bit moot some of some of these conversations. It feels. [41:41]
-
-**Mark:** To be clear, like React has got itself has gotten much bigger over the years. [41:55]
-
-In fact, even just 18 to 19 it got notice will be bigger. Bigger bundle sizes are not a good thing. We are not sitting here saying Your bundle size does not matter. Alex Russell, as much as I disagree with his communication style is right to point to the technical receipts saying that big bundle sizes are bad, but also it's not the only single metric you should care about. [41:59]
-
-**Carl:** Yeah, right. Yep. And also, last thing I'll shout out here. I think the author of this blog post also mentions that he tried not to pull in too many dependencies. So like did not pull in fetch wrappers or data fetch tools like React Query and. [42:21]
-
-Axios, the data fetch thing, which many people still use, I don't know. They still have a fair amount of utility just for things like observability and security and various guarantees like that. Like Axios itself is 36 kilobytes ified like 14 compressed. React Query is 55 kilobytes. I guess to say that the way he did it is actually better quote unquote for React in terms of the bundle size argument, but it's also not representative of how people actually build apps. [42:40]
-
-It's a challenge of these types of articles is that by necessity it has to be the level of scope that a single developer can execute on their own, and that's just not how most apps are built. Like most apps are not passion projects by one person. So yeah. Super cool. Love this post. It's interesting more than it is authoritative, I think. [43:11]
-
-**Mark:** Good way to put it. Mo, tell us about Solito. [43:30]
-
-## [Solito 5](https://solito.dev/v5)
-
-**Mo:** Yes, Solito. So go back a few months. You'll remember that we said Fernando Rojo joined Vercel. And he joined as the head of mobile firm Vercel. This was significant because he's the author of this library called Solito and a few other libraries like Ziga. So he's really, for the last few years, has been focused on. [43:33]
-
-Using React native on the web as well, especially with Next.JS. So he built his own startup in that sort of tech stack. It is from experience and having built with this tech stack quite a lot, it's a challenging approach because you are always balancing oversharing between your native components and your React native code and the web functionality that you import in. [43:53]
-
-And oftentimes that comes at a detriment of performance or ux, depending on if you do it right. And the more that you share, the more chance there is that you're not, you're sharing something that you probably shouldn't share. And so there's a lot of libraries in the secret system, but Solito is probably one of the key ones where it lets you share navigation across Next.JS and React native apps. [44:16]
-
-Now, we've talked a bit about Toledo in the past. One of the big limitations that any library in this space has is that it relies on React Native Web Now, React native web was made several, several years ago. I think it was back in 2015. And it was made by Nicholas Gallagher. Now, he also did a talk at React Conf, which I would recommend you watch about React strict dom. [44:39]
-
-But the key thing with React Native Web is that it's not really receiving as much love because Nicholas is working more on React strict dom, which is sort of like the future path for sharing code across the web and mobile. And so React native web is, is a little bit bloated, and what that means is that any library that you really use, especially your, something like your navigation and routing library will import in large portions of React Native Web, even if you're not using all of the APIs. [45:00]
-
-And so that means that your bundle size goes through the roof. And what the Vercel team slash Fernando Roho have now been able to do is actually remove React Native Web as a dependency from from Solito, which is pretty massive. It sets us up in a foundation where you can effectively get ready for React strict dom adoption more easily in the long run, but also means that if you pick and choose your libraries well, when you're building a UniVercel app and you really think about what you're using on the web platforms, you can really start to tackle that bundle size problem. [45:25]
-
-It doesn't help if you're using libraries like let's say Reanimated, which has a pretty heavy reliance on React Native web. But if you're going really vanilla and you're very careful, it means that you can actually achieve much better performance on the web by using this new version of Solito, which is very exciting. [46:00]
-
-So yeah, if you're already using Solito, give it a look and if you're thinking of building a uniVercel app, it's a really good candidate if you wanna build a highly performant web variant of your application. [46:16]
-
-**Carl:** I love that. It definitely makes a lot of sense to start moving away from React Native Web, given that we've compared and contrasted React Native Web with like React strict dom. [46:25]
-
-I guess it makes sense to move away from React native web, 'cause the guy who made it is now doing a different thing in the exact same space from a very different angle. So yeah, that's a pretty strong argument for changing. [46:35]
-
-## Next 16 and Directives debate
-
-**Mark:** Okay, the last major topic for the day next 16 and directives. [46:49]
-
-## [Next 16 released](https://nextjs.org/blog/next-16)
-
-**Mark:** So next 16 came out. The headline feature is they now have what they're calling cash components. This is the, I don't know, second, third, fourth iteration on how to do caching in next, across the last couple major versions. I'm not gonna pretend that I understand what, how this works. [46:56]
-
-No one does, but thing is that they introduced. Another new directive. Now to recap a directive is these little strings that you just put in your code. Originally we had use strict back in the ES 2015 days and then React server components introduced, use server and use client, and now we have 'use cache'. [47:15]
-
-And the idea is that by slapping this directive on certain components, that tells the next bundler and compiler that, Hey, this is the output of this component is supposed to be cached. I don't understand the details. From there, go read the documentation long. With that, they also announced a new long-lived workflow product, kind of similar to what the temporal company. [47:40]
-
-Has built where you can have a function, for example, that implements a billing workflow by sweeping for 30 days and you've written what looks like one function, but under the hood it's actually like saving its status to a database and then a time job wakes it up and continues executing the code, that sort of thing. [48:03]
-
-And I believe they opted to implement this also with a use workflow directive and like a use step directive. And I think there may have even been one or two others related to variations on caching, like use Cache, remote, something like that. And meanwhile, we've also got the React compiler has opted to use directives for a couple things. [48:23]
-
-So there's a use no memo directive. If you want to tell the compiler, don't try to auto optimize this component. And so all of a sudden we've gone from the JavaScript language specifying. One directive. There was also the unofficial, oh, was it use a SM directive that was part of a SM js, the precursor to web assembly, but like one official directive in the language. [48:48]
-
-And now we have a couple for bundlers, and now we have more for workflows and the compiler and all these other things. And so the Twitter discourse over the last couple weeks has been our directives, good or bad. And they're so confusing and they are changing the language. And you have all this bundler defined behavior that is not part of the language spec. [49:18]
-
-## [Directives and the Platform Boundary](https://tanstack.com/blog/directives-and-the-platform-boundary)
-
-**Mark:** And so Tanner Linsley, again, creator of all the different Tan Stack libraries, put out a blog post where he expressed his opinion that he does not think directives are a good idea. Because they are unofficial, because they're not standardized, because make it not clear what the actual intended behavior ought to be, as opposed to like explicitly importing a function that says, turn this into a client server function or something like that. [49:41]
-
-So there there's been a lot of arguing about directives and are they understandable? Are they good or bad? Are they too much magic? So that's been happening. [50:11]
-
-**Carl:** I'll say it. They're bad. It's too much magic. I hate it. I'm not a fan. [50:22]
-
-**Mark:** I understand the thought process. I, I can't say I'm thrilled. And so on that note, two article articles that are related enough to throw them into this section. [50:26]
-
-## Technical critique of Next App Router: [Everyone Hates Next.js](https://paperclover.net/blog/webdev/everyone-hates-nextjs)
-
-**Mark:** I've seen lots of different article articles upset at Next or critiquing next. Most of them are frankly very badly written, but I saw one come out last week that I thought was very well written and focused strictly on the technical pros and cons of using the App Router. The title is Clickbait, everyone Hates Next, but the article itself is actually very well written. [50:34]
-
-It discusses technical aspects of using Next, some of the problems his team went in, ran into, and how and why they ended up migrating from the App Router over to 10 Stack Start. And then Nadia Vic, who has done a bunch of very excellent articles on React rendering behavior, put together a very data-driven look into do server components actually help with things like First Contentual Paint and various other White House style metrics. [50:57]
-
-So very worth reading. [51:26]
-
-**Carl:** As I'm trying to think about how you might solve problems of caching and runtime things without directives. And I'm thinking about, you know, my experiences using like CloudFlare workers or other runtimes where it's not a traditional process scope. And I don't know, I guess like it is a really challenging question of like, how do you signal to a developer that the file they're editing runs in a certain type of context? [51:27]
-
-And I guess I understand why directives are an appealing thing to reach for, but man, just the state we're in right now is really a lot. I found the Next.JS docs page with directives and it lists 'use cache', 'use client', 'use server', and then two sub variants of 'use cache'. And that's not all of 'em that, so there's missing ones here and. [51:56]
-
-I don't know. When you start getting into like many different contexts, just naming them at the top of the file doesn't really seem like enough for me. I don't know. And then like the implication for that code can import other code that will not have it flagged what context it's running in via a directive at the top of the file. [52:20]
-
-And I don't know. It's a tough problem. It's a weird unanswered question in the industry, like not even the ecosystem, but like the industry. How do you flag code that might run on your browser, a real server, serverless environment, and yeah, I don't know. It's a challenge. [52:40]
-
-**Mark:** I think it really does speak to the overhead and mental complexity of trying to juggle all these things. [52:58]
-
-We said earlier that React 19 has, 18, 19 have introduced a whole lot of things like transitions and other pieces to try to let you write better user experiences. But now you're having to juggle in your head like, here's the current version of my app in its display state versus a work in progress rendered version versus a future output rendered version. [53:04]
-
-On the server side we're having to deal with, this is server code, this is client code, sometimes they're mixed together in the same file, sometimes they're mixed together in the same component. Which code is running? In which context do I have to worry about accidentally leaking security tokens or something like that. [53:28]
-
-We're building tools to solve real problems, but there's more and more to juggle in your head as you go. [53:46]
-
-**Carl:** Well, I'm gonna plug effect one more time because I saw it come up in the chat. Oh, man. It just like talking about different ways of signaling facts about the code. The code you're writing has certain dependencies. [53:53]
-
-Certain dependencies is too loaded. That's, that carries too much context with it, but the code you write has a certain amount of assumption baked into it about what will be available and what it can rely on. The thing I love about a fact is that it makes that more explicit and brings it into the type system. [54:06]
-
-So I think the challenge right now is that we are missing a like platform and language level abstraction to express information like this. And yeah, I don't think we're gonna get it anytime soon. And I think these explorations will lead to something like that and hopefully converge into something. But I think this is gonna be like a real state-of-the-art problem for a couple of years and still, which I hate, but it'll get better. [54:26]
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Alright, moving on to the lightning round. [54:56]
-
-## [ViteConf roundup](https://voidzero.dev/posts/whats-new-viteconf-2025)
-
-**Mark:** In addition to React Con and Remix Jam, we also had Vite Conf and the V team gave a bunch of updates on all the different tools they've been working on. Some of the highlights to me were that OX LT now supports ES lint and JS plugins via some really awesome tricks for interop between js and rust without the the cost of serial serialization. [54:58]
-
-They announced a combined tool chain called v plus, which basically pulls all the different tools, VIOX lint, OX format, Vitest, everything else together. That'll be their enterprise sales targeted tool set. And then Vitest four is out with browser mode support. You basically just put a flag in your Vitest config and suddenly your tests are running in a real browser instead of a node plus js. [55:21]
-
-## [AWS Outage Postmortem](https://aws.amazon.com/message/101925/)
-
-**Mark:** Last week, AWS east went down and the internet died and they put out the postmortem and it was DNS apparently they, their internal DNS system for dynamo DB had like three different instances of the DNS updater running and one of them got stuck and was taking a long time to complete, and the other one came along and updated and then said, well, these, some of these plans look out of date, let's delete them. [55:49]
-
-And next thing you know, DNS goes down, dynamo DB goes down and the internet goes down. So, oops. [56:19]
-
-**Mo:** It's funny that the, uh, internet is backed by Dynamo db. [56:28]
-
-**Mark:** A lot of people like us East One is the default. A lot of people have tried to get away from US East one, but when a lot of Amazon's own stuff depends on US. [56:31]
-
-East one. Yep. You all [56:39]
-
-**Mo:** of your certificates can only be issued in US East one, so that doesn't really help much. Side note, if you end up working in a consultancy one day, just hope nothing like this happens because the morning of was fascinating reaching out and getting reached out to by a bunch of clients being like, my site is down. [56:40]
-
-And then having to figure out what's going wrong, which is US East one on AWS. So it was a fun Monday, [56:57]
-
-**Carl:** but at least the uh, at the end of it was a vendor is out. This is not our fault. [57:02]
-
-**Mo:** At least it was that, which was great. Cool. Moving on. [57:07]
-
-## [Voltra](https://x.com/saul_sharma/status/1972161677165473980)
-
-**Mo:** So a couple of React native lightning route items. Firstly ra, which is really cool because we've talked a little bit about live activities on iOS and iOS extensions, all of the little widgets and stuff that you can now use on your iPhone. [57:10]
-
-And you were able to use iOS extensions within a React native app. But the challenge was you had to write SWIFT code to be able to actually implement those. And so a independent developer named S has been working on building an MPM package that allows you to ship these custom widgets and extensions without needing to use Swift X code or extra js, which is so cool because he's basically had to like write a translation layer or a render that takes React UI code. [57:24]
-
-And converted to Swift UI code, which is not trivial because many have tried before him and failed. So this is a really cool project and like it's one of those things that's like kind of mind blowing. So kudos to him for making this. [57:55]
-
-## [Building fully native apps with EAS](https://blog.swmansion.com/building-fully-native-ios-apps-with-expo-eas-760b5480d7c5)
-
-**Mo:** Secondly, and I thought this was an interesting article to link to. On the expo blog, they publish an article about building fully native apps with EAS. So EAS is expo's application services. Typically, this is being used to build React native apps that are usually running on Expo, but actually a lesser known fact, and one that we've actually used on some of our apps is that you don't need to be on Expo and you don't even need to be on a React native app. [58:10]
-
-And so EAS is really great and it's become super mature and it's a really just good build tool for building mobile apps. And so people have started to use it in the wider mobile community rather than it just being a React native thing, which is quite cool to see. [58:39]
-
-## [React Native \\\<\\\> Imgui](https://x.com/tmikov/status/1979771014340047088)
-
-**Mo:** And lastly, this was something that Tzveton from the Hermes team in Meta actually, uh, published a week or so ago. [58:52]
-
-And this was actually something he linked me on a DM because we were chatting about interesting things that could be talked about at a conference by a Hermes team. And this was quite cool to see. So for those who don't know, Imgui is like a very light UI layer that is powering a lot of sort of debugging for video games. [59:00]
-
-And it's used in a bunch of other places, but like the key thing is that it's just like a very, very lightweight UI layer. And so he made a puck of basically using React and then rendering it on Imgui, which is quite cool. And it runs obviously like fully natively. It's fully running on c plus plus. And all it really needed was some typed JavaScript and it's basically just React really, which is quite cool. [59:18]
-
-So yeah, it's just a little cool fun POC, but it shows the power of using React and how it can be applied to different contexts, which I thought was quite cool to include. [59:43]
-
-## [Lodash maintenance foundation](https://blog.ulisesgascon.com/the-future-of-lodash)
-
-**Mark:** Okay, Lodash has powered much of the JavaScript ecosystem for years. Those of us who have been around for a while, remember its predecessor, but low, has also been relatively unmaintained for a while. [59:53]
-
-The author John David Dalton, said there was going to be a low dash version five, and then that never really happened, and so some announcements came out in the last week or two. That low dash is being taken over by a new maintenance foundation, and they're going to be doing work to update the ci, put out some new maintenance releases, and then apparently when low dash V five happens, it'll be more about stripping out a lot of the internals that tried to polyfill platform behavior and try and make it lighter and make use of platform built-ins at this point. [01:00:05]
-
-So Lodash is still around, it ain't going anywhere, and good to see it being maintained. [01:00:40]
-
-## [Build Your Own Key-Value Database](https://www.nan.fyi/database)
-
-**Mark:** And then there was a really good post unrelated to React, but cool on building your own key value database system that walks through a whole bunch of pieces on what a key value database actually has to track and how the internals would work. [01:00:45]
-
-And I believe it's actually pretty interactive, which is cool. [01:01:01]
-
-**Carl:** This build your own database post, I love, this is so good. I love when people rebuild foundational building blocks. And this is also something I've thought about a little bit because he talks about in a file, you know, if you need to store something, put it in a file. [01:01:04]
-
-And this is something I've thought about a little bit because I have been using SQL Light pretty extensively in my own work the last couple of years. And at the end of the day, sequel light is a file. So like when I realized that like most of the time. If I want to store something in a file, like I should just use sql, you put something in a file and then the file gets too big and you need to optimize it, and you need a better way to access it and like, oh, maybe I could use a more descriptive query language to get things out of it. [01:01:18]
-
-And like the end result is that you will recreate a shittier less performant version of SQLite that doesn't use sequel. And so, I don't know. I just like reading this that was very strongly on my mind and everyone should do SQLite if they start putting things in a file. 'cause it's just a file. [01:01:44]
-
-It's cool. I like it. [01:02:02]
-
-**Mark:** The SQL Light website even has a page that says why, why you should consider just using SQL L as your app's file format rather than inventing another new binary format from scratch. [01:02:03]
-
-**Carl:** A hundred percent. If you start right, if you start thinking I should put this in a binary format on disc, like no, stop it. Use SQLite. It's great. [01:02:16]
-
-## [Jared Palmer asking for GH PR suggestions](https://x.com/jaredpalmer/status/1979204222420664405) and giving [some technical details](https://x.com/jaredpalmer/status/1980619222918262842)
-
-**Mark:** Alright. Jared Palmer, the creator of the Formik Library, has had been at V at Vercel for years. He worked on turbo repo, v0. And he announced just a month or two ago he was leaving Vercel. He has then announced that he has joined Microsoft as a senior VP at GitHub. And the first thing he did was post on Twitter saying, how can we make the GitHub PR experience better? [01:02:24]
-
-And he got like eight or 900 replies, and he was pretty actively engaging with a lot of 'em. A lot of them were people asking for things like Stacked Diff support, so you could have multiple PR branches that depend on each other and be able to automatically update them. He actually came back even just a couple days later and gave some technical details that he had found after internal discussions on here were some previous prototypes of stacked diffs at GitHub and how, like how far they got and what the blockers were. [01:02:53]
-
-So I have no idea how long it'll take to roll out any of this stuff, but like he seems pretty serious about trying to improve the PR experience, whether it's paper cuts or new functionality and is trying to look into that stuff. So given that we all pretty much depend on the GitHub PR experience, I'm happy to see improvements. [01:03:25]
-
-**Carl:** Yep. Love that. Wow. This is very jargon heavy. [01:03:45]
-
-**Mark:** Yeah, I, I know, that's why I was happy to see it. Cool. [01:03:48]
-
-**Carl:** Sounds like a technical roadmap. [01:03:51]
-
-## [Node 25 with JSON.stringify improvements](https://nodejs.org/en/blog/release/v25.0.0)
-
-**Mark:** Couple other bits, node 25 is out and so another development line branch for node and the biggest thing there is they've updated the version of V eight and that includes those faster js ON string of FI improvements that we, we talked about a couple months ago. [01:03:54]
-
-So given how much everything depends on JSONs string offi, it's nice to see that being sped up. [01:04:09]
-
-## [Cloudflare vs Vercel CPU benchmarks and perf optimizations](https://blog.cloudflare.com/unpacking-cloudflare-workers-cpu-performance-benchmarks/)
-
-**Mark:** And speaking of more optimization work, I believe Theo put out a benchmark where he was comparing CloudFlare in Vercel in Building Next versus Vanilla versus a couple other things. And it pointed out places that both Vercel and CloudFlare were slow and CloudFlare jumped on this and they found a bunch of places in their system. [01:04:15]
-
-Where things could be optimized. They did a excellent blog post detailing some of the improvements. They also went in and they looked at next itself and they found a bunch of places where Next is doing like useless request copying like 1500 or 1700 request streams per request or something like that. [01:04:36]
-
-So basically everybody is getting faster as a result of this, which is a good thing. [01:04:57]
-
-**Mo:** CloudFlare folks are just doing some great work recently, especially with the whole like workers rebrand as well is really cool. [01:05:02]
-
-## [FF Interop Feature Request Rankings](https://interop-rank.jakearchibald.com/)
-
-**Mark:** So Interop is an attempt to get all the different browsers on the same page in terms of what features they're working on, especially around compatibility with each other each year. [01:05:07]
-
-And so this year the Firefox folks put up a rather nifty interactive suggestions thing where they list dozens, like 50 or a hundred different potential features or technical areas of emphasis that they could spend time on. And it's got a neat drag and drop interface where you can basically use that as a way to vote for which features do you want browser manufacturers to work on? [01:05:19]
-
-This year. [01:05:44]
-
-**Carl:** Love that. Yeah. They say they're gonna publish the final selection of proposals in February, so I'll, I'll keep an eye out on that, I guess. Cool. [01:05:45]
-
-## [Vjeux’s History of Prettier](https://blog.vjeux.com/2025/javascript/birth-of-prettier.html)
-
-**Carl:** Chris Chedeau, vjeux, he has been really prolific in the React ecosystem for many years. Was really influential in React becoming open source and was the original author of Prettier, which changed my professional experience significantly. He put out a blog post titled The Birth of Prettier earlier this month. I'd spent almost 10 years since Prettier was released. He says, which is wild. I like his introduction of this is the story of how the tabs first spaces Holy War ended, and yeah, it did. [01:05:53]
-
-I appreciate that. I actually just did a little DX PR for a code base. I maintain to make better use of prettier because somebody created a plugin to sort imports and like, yes, I love that. I hate sorting my imports and I hate when of my imports are not sorted. The introduction of automated formatting into the JavaScript ecosystem was, oh, what a, what a blessing. [01:06:23]
-
-Like what hours? The years of my life that have been saved from arguing over formatting is just really lovely and this is a great retrospective. Looking into just the whole process of how it came out. [01:06:46]
-
-**Mark:** There's some fascinating details in there. [01:06:58]
-
-**Carl:** Yeah, like one of the challenges of this that I remember in the moment a little bit, but like if you're gonna start formatting things, the format needs to be something relatively unobjectionable to the people who are evaluating whether they want to use it or not. Like, yeah, so, and then figuring out what options should be exposed, what is actually configurable, because if you make it too configurable, then it's not helpful. If it's too much manual thing, then it's not actually consistent enough to be valuable at its intended purpose. [01:07:00]
-
-So lots of really interesting details throughout here. Definitely recommend it. I always love a great technical white paper, a writeup of implementation, and this is, oh boy, is this that. It's great. [01:07:37]
-
-**Mark:** One of the most interesting bits I saw was he was talking about how they started rolling it out and like Prettier has some options, but they wanted to minimize them and he wanted everyone to basically agree on a single set of options. [01:07:49]
-
-And so he said the strategy I used to figure out how to make this work was lining up incentives so that it took a ton more work to use a different set of options if you wanted to. It said Prettier is either in this, in CI or in your IDE. So I made it so that they read them from different places with a different rollout schedule to make it harder to choose one or the other. [01:08:02]
-
-**Carl:** Oh, that's incredible. That's some good details. Reading this a little bit more is it's got lots of fun non-technical details that like they're not the engineering work, but they are absolutely essential for actually making a thing that is successful and sustainable and thriving. Like it also talks about money and like ongoing maintenance is a thing that you have to pay for. [01:08:24]
-
-You don't have to, I guess most open source does not, but if you don't, then it has its own challenges. So like not only is this a great technical writeup, but it's also a great, I don't know, like entrepreneurial writeup. [01:08:45]
-
-**Mark:** How do you do the, the real work to make stuff happen? [01:08:55]
-
-**Carl:** People talk about the difference between like senior and staff engineering being, the difference between junior and senior is how much English you're asked to write. And the difference between senior and staff is like how much non-technical things you're asked to account for. And so this is a phenomenal, I would say, staff engineer writeup. Like, this is how you take an idea and you make it an industry level impact project. Yeah. Great Writeup. [01:08:58]
-
-**Mark:** I can even point to a couple personal examples of how prettier has affected my work just within the last few days. [01:09:23]
-
-One is that I'm jumping between the Redux repo, which is two spaces, single quotes, no semicolons. The Immer repo, which is four spaces, double quotes, and I can't, and may, maybe no single semicolons, Replay.io repo, which is four spaces, double quotes, semicolons, and I don't think about any of that anymore. [01:09:28]
-
-And then also just yesterday, I was trying to tweak some of ER's exports and tried to put in an export type keyword, which I was pretty sure was a legit thing except that when I hit save, it didn't format. And I have learned that if it doesn't format, I have put in invalid syntax somewhere for a moment. [01:09:52]
-
-It was like, oh, export type must not be a valid TS keyword. And then I finally realized, oh wait, this is on prettier 1.19. That must predate that syntax being added to TypeScript. And so I had to update prettier, but like that's how much I have learned to lean on. You hit save and it formats and it's valid. [01:10:16]
-
-**Carl:** Yep, a hundred percent. I, I recognize that in myself as well. [01:10:37]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Okay. Let's wrap it up with some conferences. [01:10:41]
-
-## [React Native London](http://reactnativelondon.co.uk) Nov 13-14 London, UK
-
-**Mo:** Let's jump into it. So we've hinted a few times and I can now say that we've got Seth Webster's endorsement. So the executive director of the React Foundations talks about my conference. I'm very happy today. [01:10:43]
-
-We've been organizing this for the second year, so React Native London for anyone who's a React native enthusiast in London and beyond. We have people from Brazil and India last year, so that's like the furthest extent that we have people coming in from around the world. But if you are interested, we've got our conference on the 13th and 14th of November. [01:10:55]
-
-In Central London, we've got a beautiful venue, some great talks from Meta, Amazon, Microsoft, and just a bunch of community people from expo and independent app developers who are gonna come and give some really, really phenomenal talks. [01:11:14]
-
-## Use code \`TMIR10\` to get 10% off
-
-**Mo:** Use the code TMIR 10 and you should get a 10% discount on checking out, which will, if I'm doing my mental maths right, make the ticket price 330 ish pounds for a two day conference to be able to attend workshops and the conference day. [01:11:26]
-
-## [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
-
-**Carl:** Um, other ones we've got coming up are Wey Wey Web November 17th and 18th in Malaga, Spain. [01:11:42]
-
-## [React Summit](https://reactsummit.us/) Nov 18, 21 New York, NY, USA
-
-**Carl:** We've also got React Summit November 18th through 21st in New York. [01:11:49]
-
-**Mark:** There's JS Nation on the 17th. There's in-person React Summit in person on the 18th, and then they have an online day the next week. Okay. [01:11:54]
-
-**Carl:** Oh, oh, oh yes. [01:12:02]
-
-I see it's 18th and 20th, not through. Interesting. One day in person. One day online. Okay. Makes sense. [01:12:03]
-
-## [React Advanced](https://reactadvanced.com/) Nov 28, London, England
-
-**Carl:** There's also React Advanced November 28th, also [01:12:10]
-
-**Mark:** in London the day after Thanksgiving. Someone in England didn't think about that part. He, he, he, [01:12:13]
-
-**Carl:** yeah. It's not for Americans. [01:12:19]
-
-**Mo:** It's not just React Advance, it's also Tech Lead Conf, which is also organized by the Ation folks on the same day in London as well. So, no, I would doubt that there's gonna be a lot of people from the states there, unfortunately. [01:12:21]
-
-**Carl:** For sure. [01:12:32]
-
-## [React Paris](https://react.paris/) CFP is open
-
-**Carl:** Well, I'll, I'll also add, I just saw like two days ago, the organizer of React Paris posted in the events channel here that CFP is open, so we gotta React Paris if you want to submit a talk. But that's gonna be in like March though, so not anytime soon. [01:12:33]
-
-## Ending
-
-**Carl:** That's all we got. Thanks so much for sticking around for a whole 90 minutes. [01:12:49]
-
-**Mark:** It was a very busy month. Okay. [01:12:53]
-
-**Carl:** Yeah. We'll be back next month, on the last Wednesday here in the live stage or back in your podcast feed just as soon as we can. Yeah. Thanks so much. Well, normally we gather sources from a variety of newsletters. We actually had so many things that Mark shared in the tech reads and news chat this month that I don't think any of us did. So that's cool. [01:12:55]
-
-**Mark:** And I pasted a lot more links in the discussion threads too. [01:13:15]
-
-**Carl:** That's something I should be better about. That would be lovely and helpful. But yeah, if you see anything newsworthy, definitely let us know in the Tech News and Reads channel, just like Mark has been doing. [01:13:18]
-
-You can also email us at hello@reactiveflex.com. But you know it's a community like Join, participate. I do read every email though, so if you send something I, I will read it. If this is a show that you get value from and want to support, best way to do so is by submitting a review wherever you listen and by telling your friends and coworkers about it. [01:13:27]
-
-And go to a meetup and say, Hey, there's this great podcast I love. [01:13:44]
-
-Cheers. See you next month. [01:13:47]
diff --git a/src/transcripts/tmir-2025-11.md b/src/transcripts/tmir-2025-11.md
deleted file mode 100644
index 5e43208..0000000
--- a/src/transcripts/tmir-2025-11.md
+++ /dev/null
@@ -1,589 +0,0 @@
----
-title: "TMiR 2025-11: Cloudflare outage, ongoing npm hacks, React Router is getting RSCs"
-date: 2025-11-26
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down 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:13](#intro)] Intro
-- [[01:00](#new-releases)] New releases
- - [[01:04](#betterauth-14)] [BetterAuth 1.4](https://www.better-auth.com/blog/1-4)
- - [[02:47](#immer-11-rtk-211)] [Immer 11](https://github.com/immerjs/immer/releases/tag/v11.0.0), [RTK 2.11](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.11.0)
- - [[06:00](#storybook-10)] [Storybook 10](https://storybook.js.org/blog/storybook-10/)
- - [[06:22](#01-version-of-remix-teams-event-interaction-package)] [0.1 version of Remix team’s “event interaction” package](https://github.com/remix-run/remix/tree/main/packages/interaction)
-- [[08:04](#main-content)] Main content
- - [[08:08](#ecosystem-panel-discussion-of-react-foundation-at-react-summit-ny)] [Ecosystem panel](https://gitnation.com/contents/panel-discussion-the-future-of-react-and-its-ecosystem) discussion of React Foundation at React Summit NY
- - [[14:46](#react-concurrent-stores-polyfill-react-redux-poc)] React Concurrent Stores: [Polyfill](https://github.com/thejustinwalsh/react-concurrent-store), [React-Redux POC](https://github.com/reduxjs/react-redux/pull/2263)
- - [[17:52](#react-router-and-transition-usage)] React Router and transition usage
- - [[18:08](#matt-brophy-and-ricky-discussing-nuances-of-behavior-use-with-react-router)] [Matt Brophy and Ricky discussing nuances of behavior, use with React Router](https://github.com/reactwg/async-react/discussions/5)
- - [[22:53](#the-state-of-tanstack-two-years-of-full-time-oss)] [The State of TanStack, Two Years of Full-Time OSS](https://tanstack.com/blog/tanstack-2-years)
- - [[25:57](#tanstack-db-05)] [TanStack DB 0.5](https://tanstack.com/blog/tanstack-db-0.5-query-driven-sync)
- - [[31:01](#tanner-teasing-a-wip-tanstack-start-rsc-implementation)] [Tanner teasing a WIP TanStack Start RSC implementation](https://x.com/tannerlinsley/status/1983999424486633931)
- - [[32:25](#state-of-the-web-ecosystem)] State of the web ecosystem
- - [[33:13](#cloudflare-november-outage-postmortem)] [Cloudflare November outage postmortem](https://blog.cloudflare.com/18-november-2025-outage/)
- - [[36:10](#what-if-people-dont-want-to-create-things)] ["What if people don't want to create things"](https://macwright.com/2025/10/21/what-if-they-dont-want-to.html)
- - [[39:39](#when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react)] [“When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”](https://webtechnology.news/when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react/)
- - [[45:53](#related-dead-framework-theory-from-last-month)] Related, [“Dead Framework Theory”](https://aifoc.us/dead-framework-theory/) from last month
- - [[48:12](#alex-russells-latest-stats-on-web-devices-and-network-budgets)] [Alex Russell’s latest stats on web devices and network budgets](https://infrequently.org/2025/11/performance-inequality-gap-2026/)
- - [[51:48](#npm-attack-shai-hulud-round-2)] Npm attack, [Shai-Hulud round 2](https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains)
- - [[52:06](#analysis-of-its-evolution-in-code-from-sept)] [Analysis of its evolution in code](https://www.aikido.dev/blog/bugs-in-shai-hulud-debugging-the-desert) from Sept
- - [[55:23](#our-plan-for-a-more-secure-npm-supply-chain-from-september)] [Our plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) from September
- - [[55:29](#npm-update-on-token-management-changes)] [NPM update on token management changes](https://github.blog/changelog/2025-11-05-npm-security-update-classic-token-creation-disabled-and-granular-token-changes/)
-- [[55:34](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[55:38](#ts-60-hopefully-feb-2026-70-native-soon-after-more-details-in-the-typescriptfm-podcast)] [TS 6.0 hopefully Feb 2026, 7.0 (native) soon after](https://bsky.app/profile/danr.bsky.social/post/3m5fz3vw2z22s) (more details in the [TypeScript.fm](https://share.transistor.fm/s/ad05eae6) podcast)
- - [[56:03](#latest-tc39-proposal-updates)] [Latest TC39 proposal updates](https://bsky.app/profile/robpalmer.bsky.social/post/3m62djhwj3k2i)
- - [[56:32](#chrome-and-other-browsers-wants-to-remove-xslt-from-the-web-platform)] [Chrome (and other browsers) wants to remove XSLT from the web platform](https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4gYZeSJA/m/yNs4EsD5AQAJ?pli=1)
- - [[57:14](#your-url-is-your-state-and-david-ks-goodbye-usestate-talk)] [“Your URL is Your State”](https://alfy.blog/2025/10/31/your-url-is-your-state.html), and [David K’s “Goodbye, useState” talk](https://gitnation.com/contents/goodbye-usestate)
- - [[57:46](#aiden-bais-react-grab-util)] [Aiden Bai’s “React Grab” util](https://www.react-grab.com/)
- - [[58:39](#creating-a-custom-node-module-loader-to-import-from-bittorrent)] [Creating a custom Node module loader to import from Bittorrent](https://evanhahn.com/node-torrent-import/)
- - [[59:22](#ryan-carniatos-stream-on-researching-async-signals)] [Ryan Carniato’s stream on researching “async signals”](https://www.youtube.com/watch?v=ori9xZhvNlc)
- - [[59:33](#details-of-building-nodes-ts-type-stripping-support)] [Details of building Node’s TS type stripping support](https://satanacchio.hashnode.dev/the-summer-i-shipped-type-stripping)
- - [[59:58](#the-web-animation-performance-tier-list)] [The Web Animation Performance Tier List](https://motion.dev/blog/web-animation-performance-tier-list)
-- [[01:00:14](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:00:22](#cfps)] CFPs
- - [[01:01:01](#react-paris-also-a-community-survey)] [React Paris](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform) ([Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform))
- - [[01:01:12](#jsworld-cfp-closes-dec-31-notifies-by-feb-1)] [JSWorld](https://docs.google.com/forms/d/e/1FAIpQLSfv3GuXwsDyR42XsvJwfFsN4SKjy8WvKtqYp_nEK0yhzVNP1g/viewform) CFP closes Dec 31, notifies by Feb 1
-- [[01:01:18](#ending)] Ending
-
-2-vcarl: Hello! Thank you for joining us for the November edition of this month in React. As we recap what's going on in the React, React native and web ecosystems, we're coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]
-
-## Intro
-
-2-vcarl: And I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux where I do community programs like these events and build tools to help keep the community operating. [00:00:13]
-
-1-acemarke: Hi, I'm Mark. My day job is working at Replay.io and doing various time travel debugging and information architecture things outside of that I, I work on Red Ducks. I complain about the React docs and I collect links and I go rewrite libraries, Limmer. [00:00:22]
-
-2-vcarl: Mo unfortunately could not join. He had a fire drill happen, a metaphorical fire drill, happen at work like an hour before we started. But generally we have Mo, who is head of mobile at Theodo and is very active in the React native community. Kind of sad that he had to skip out this month because he just did React Native London, and I was hoping to hear how that went. [00:00:39]
-
-## New releases
-
-2-vcarl: But yeah, let's get straight into it with some new releases. [00:01:00]
-
-## [BetterAuth 1.4](https://www.better-auth.com/blog/1-4)
-
-2-vcarl: First off, we've got better off 1.4. I actually use Better Off now. Woo. I had been excited about it for a while because I don't like authentication. Libraries generally like stuff like Passport or what, you know, even clerk or the SaaS businesses, just like none of them. [00:01:04]
-
-I didn't like them very much, so was very pleased to see an open source library that looked to cover many of the bases that I want and can confirm after using it that it does. So I'm excited to see Better Off 1.4, which is the first release since I believe July when it did 1.3. A couple of quick highlights from it. [00:01:20]
-
-It's got stateless off. So you can do sessions without a database just by not giving it one, which is nice. It's also got SCIM provisioning for identities in multi-domain scenarios, which is cool. Also, some other little details like database joins and custom state for OAuth flows. But yeah, just auth is a shockingly deep subject when you actually start dealing with the nitty gritty weirdnesses of it. [00:01:40]
-
-And I have generally found most open source projects trying to support authentication to be, to leave something to be desired and better off leaves the least to be desired of the projects. I've tried, so Love it. New version. [00:02:06]
-
-1-acemarke: I have thus far managed to stay away from dealing with auth at all in my career, and I would like to keep it that way. [00:02:20]
-
-2-vcarl: Yeah, that's not a bad call since I haven't been able to avoid it. I went a little bit deep on it and I don't hate that either. It's interesting. It's fascinating. Actually. I don't know, one of the vague. Startup ideas in the back of my brain is related to authentication and identity management, which could be cool. [00:02:28]
-
-I don't know, maybe I'll do something with that eventually. [00:02:44]
-
-## [Immer 11](https://github.com/immerjs/immer/releases/tag/v11.0.0), [RTK 2.11](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.11.0)
-
-2-vcarl: Mark, I want you to unveil your magnum opus. [00:02:47]
-
-1-acemarke: Happily. So I talked about this a bit last time, but Redux Toolkit relies on Immer for immutable state updates. It always has since day one. We've gotten various complaints over the years that, you know, Immer is kind of slow, but we've always said that we prefer the fact that it eliminates accidental mutations, makes reducers easier to write. [00:02:50]
-
-Of course, we want Redux toolkit to be fast, but we also want things to be correct and users to not have bugs. So I'd done a little bit of perf investigation into Immer like a year ago. Saw that it had gotten slower, filed an issue. You know, it was kind of left there. And at the start of September, I myself dug in and started trying to see if I could optimize ER's performance. [00:03:11]
-
-And I spent well over a hundred hours collectively across September and October, deep diving into ems, codebase, comparing it to other libraries, understanding how it worked, and trained to do a bunch of performance optimizations. And so ended up filing a few different prs, Immer 10.2, shipped last month with some small tweaks, and Michelle West Rate just merged a big architectural change and released it as Immer version 11 just a couple days ago. [00:03:34]
-
-And then I was able to put out RTK two point 11, which picks that up. So free performance wins for Redux Toolkit and Nier. [00:04:04]
-
-2-vcarl: Heck yeah. That was what was the average speed up? [00:04:13]
-
-1-acemarke: The current builds average about 20 to 25% across all the different benchmarks, varying by scenario. And then there's another outstanding pr, which adds an optional array methods override plugin, which drastically speeds up array methods. [00:04:16]
-
-2-vcarl: Heck yeah. That's awesome. We love a core performance improvement and I, I wanna shout out the ecosystem performance. You know, I don't know, [00:04:34]
-
-1-acemarke: E 18 E folks are awesome. They have been doing a ton of work to clean up large dependency trees and slim down packages and remove dependencies across a wide variety of tools. [00:04:43]
-
-Yep. [00:04:56]
-
-2-vcarl: A stat that I believe we'll talk about later, I saw in general ecosystem commentary. Yeah. I guess in the NPM supply chain fact that we'll talk about later, a a a stat that came out of a blog post from that was that the average JavaScript project pulls in 683, I believe in, was it transitive dependencies? Just like, yeah. It's a lot. So when you've got that many dependencies, performance of the ecosystem is challenging. Yeah. [00:04:56]
-
-1-acemarke: That doesn't surprise me. I know that. React app. The last I saw it defaulted to about 1500 dependencies, largely because of Webpack, et cetera. Vite's obviously a lot fewer, but still that's, that's not great, just for a whole variety of reasons. [00:05:21]
-
-2-vcarl: I guess teaser for y'all. Later, towards the end of the episode, we're gonna talk about web ecosystem and there's been some blog posts talking about like. AI and how it defaults to building React instead of using the web platform and how do we promote the web overreact, things like that, which I don't know, it just feels that we just started bleeding into that topic, and so we will get much more deeply into that later in the episode. [00:05:37]
-
-## [Storybook 10](https://storybook.js.org/blog/storybook-10/)
-
-1-acemarke: Next release. So Storybook 10 came out a few different big points there. One of the biggest is that it's now ESM only. They've removed all the, the common JS artifacts, so they've shrunk the install size and they've also drastically shrunk the dependency chains as well, as well as some improvements to things like the mocking and some of the storybook formats. [00:06:00]
-
-## [0.1 version of Remix team’s “event interaction” package](https://github.com/remix-run/remix/tree/main/packages/interaction)
-
-1-acemarke: And then one other release of note, the Remix folks are continuing to work on Remix V three after the initial demo and announcements, and they're trying to build it, as I understand it, with a lot of smaller reusable packages. And they just put out the first 0.1 alpha of their. Event interaction package, which is providing an abstraction for being able to compose events and listeners and behaviors together looks interesting. [00:06:22]
-
-I'm not gonna claim I understand like exactly the benefits this comes, but nice to see the progress there and I suspect that a lot of folks are gonna get some use outta this. [00:06:49]
-
-2-vcarl: Yeah, I'm reading the syntax here and it looks like a different way of adding event listeners to DOM nodes, which, sure. I don't know, there's weird quirks and certainly the Remix team and you know, Michael Jackson and Ryan Florence specifically have shown, have demonstrated a great willingness to jump into what many people consider solved problems to reexamine from first principles. [00:07:00]
-
-So, I dunno, they've, they've done that, they've done that repeatedly with their own solved problems of data loading in routing. The interaction between data loading and routing. I feel like that's one of the bigger complaints about React router is that they keep reexamining that same question. So I don't know. [00:07:25]
-
-It's interesting that they do have interesting things to say when I've seen them reexamine, quote unquote solved problems. So I'll, I'm curious. This looks a little strange. It looks pretty divorced from the DOM structure, so if you just like on input element and then add a bunch of listeners for it, that's curious. [00:07:41]
-
-Anyway. Yeah. 0.1 release, we'll see what they come out with. [00:08:00]
-
-## Main content
-
-2-vcarl: Okay. That's all the new releases we got so far. Let's go into some main content. [00:08:04]
-
-## [Ecosystem panel](https://gitnation.com/contents/panel-discussion-the-future-of-react-and-its-ecosystem) discussion of React Foundation at React Summit NY
-
-2-vcarl: First off, we want to talk a bit about, yeah, mark, you are on an ecosystem panel at React Summit this month. [00:08:08]
-
-1-acemarke: So let's see. Addie has money was moderating. We had Seth Webster from the React team, React Foundation, Shaundai Person, Amy Ner, Nicholas Gallagher, and myself. [00:08:15]
-
-A lot of the discussion was us asking Seth Webster questions about, so this React Foundation thing, like how is this actually gonna work? What does this actually mean for the React team and the project and the ecosystem? There is a video for the panel. It's not unlocked yet. I have access to it because I speak at GI Nation events, but the video should unlock within a couple weeks, I think a a few different points that Seth made during the panel itself. [00:08:25]
-
-And then I had a chance to have a follow-up discussion with him afterwards and. There's a few different very interesting p pieces of news about how the foundation's going to work and what their plans are. He talked a bit about some of the, the funding process. So, you know, large companies pay, you know, a good chunk of money to be members. [00:08:55]
-
-The, the existing. Board member companies have already paid up for like three to five years, and it sounds like he'd actually been working on putting the foundation together for over four years. Like this was a very long term kind of a process. [00:09:16]
-
-And they're hoping to do a number of different things with the money. They want to hire some additional engineers. And he even said some of that would be spent on having engineers triage the issues. And if you've ever looked at the React repo, you know, that's a thing that they do not do very often. So even something like that sounds good. They want to hire some more people to work on the actual docs and they're hoping to give money out to communities in some way. [00:09:31]
-
-Don't know details on that, but [00:10:00]
-
-2-vcarl: Tell me more! [00:10:02]
-
-1-acemarke: Exactly. Another data point. So a lot of the plans have to do with the development process of the React project itself and transparency around that. Apparently they were even hoping to launch the foundation like a year and a half ago. And then they realized that like, "our own in day-to-day development processes aren't ready for that. We need to dog food the processes ourselves first so that we're more ready when the foundation goes live." [00:10:03]
-
-And so some of that was actually having docs and plans as new features are being developed or treating things in kind of like a, you know, TC 39 staged process. Approach, but one of the biggest things that Seth told me directly was that up until now, the React team has had, you know, their, like their weekly status meetings and those are purely internal. [00:10:36]
-
-First off, it was just all the React team working at Meta and then it was, you know, meta plus versal. But those meetings have always been internal, private, and non-visible. And Seth said that they eventually want to literally open up the weekly React team planning meetings to the public even as like a, like a Zoom call with no password. [00:11:00]
-
-And that eventually, like designated community reps would even be able to actively participate. In those discussions. So that's a radical change in the development of React itself. He also said that they're planning to resurrect or like completely redo the RFC process, which frankly was kind of dead from the beginning. [00:11:24]
-
-It was where random people from the community posted ideas that got ignored and the React team posted, finished things that they planned to ship and then people argued over the naming and the React team ignored that. So like historically, the RFC process was pretty much irrelevant to actual React development. [00:11:46]
-
-Now they're talking about making it like a real meaningful discussion and part of the planning process. Now again, like do I know how this is gonna work out in practice? No. But I can see the amount of effort and the intent. Behind the foundation and the plans that they're talking about. And even if it doesn't end up going exactly as they, or we would hope, I see good faith and good intentions behind all the work that they're trying to do around the process here. [00:12:04]
-
-So I'm actually very, very excited about this. [00:12:36]
-
-2-vcarl: Yeah, that's interesting. Oh, I got a lot of thoughts rattling around my head. 'cause that's a lot of stuff that I've looked at trying to contribute towards the solution of, yeah, I don't know. It's, I fundamentally, I feel like the problem they're dealing with is that a lot of people care about the outcome, the output, what they make and what React is. And not a lot of people actually have like the context and the background to like meaningfully contribute to the advancement of that goal. [00:12:39]
-
-You know, to respond to what you just said about like their motivations and their what they want to do. I don't think that's ever really been the problem, they've always had good intent and I even think a pretty clear eye picture of what the problems are. But I think the problems are really thorny and complex and the solutions to them are non-obvious. And even when you have a good solution idea, executing it in a way that is effective and that operates on the kind of like timescales that React is around for is just really challenging. [00:13:08]
-
-Like it's, you know, anyone can spin up a process and run it twice and you know, maybe that, like you do, you call for comments and you run a community discussion and round tables and whatever, but like that plays out over the timescale of like weeks and months and React seems to plan on the order of years and is, now has existed for a decade. [00:13:42]
-
-So, you know, with like there's possibility for its scope to expand from thinking in terms of years to thinking in terms of, I don't wanna say decades, but that's the next unit of time. That's the next order of magnitude. I hope they can achieve their goals. I am looking forward to seeing some more roadmap, transparency of some sort. [00:14:05]
-
-Actually that'll be really great for us, for you and I. That'll be great. Yep. That'll be a great source of signal that we can then pick apart and analyze to surely, to much to their chagrin by way of drawing attention to things that are high context [00:14:23]
-
-1-acemarke: as opposed to like stalking the open PRs list. [00:14:40]
-
-2-vcarl: Yeah. Right. Cool. Nice. Love that. [00:14:43]
-
-## React Concurrent Stores: [Polyfill](https://github.com/thejustinwalsh/react-concurrent-store), [React-Redux POC](https://github.com/reduxjs/react-redux/pull/2263)
-
-1-acemarke: So on that note, another item that I've personally been involved in is the work on the upcoming React Concurrent Stores API. So when React 18 came out, the React team included the Uyc external store hook as the official built-in way for third party libraries like Redux, Zein, Jo Tai, whatever else to integrate into React, take an external state update, turn it into a React re-render, and it worked. [00:14:46]
-
-But it also had a very intentional design limitation that if you do an update in the middle of a paused React render, you know, something transition like then it bails out of that and just does a complete top to bottom render. So you're kind of throwing away some of the benefits of React, being able to pause itself. [00:15:13]
-
-And that was because they, they really didn't have a better idea for how to do that kind of interop. So this concurrent store's API is supposed to be essentially a new equivalent to use sync external store, but concurrent transition compatible. And Jordan Eldridge, who's on the relay team, has been working on the design and initial prototype IMP implementation for this. [00:15:32]
-
-And so he put out a polyfill package that roughly implements the prototype as a standalone library. And then I've been talking with him about, you know, here's what Redux would probably need to make this work. Here's our, our requirements for this. And so I was able to then take his proof of concept package and put up a draft PR for React Redux that just swapped out our used selector implementation to use that instead. [00:15:57]
-
-And it basically worked, I mean, just the one test file found a couple edge cases, but like most of our tests passed, we're not doing anything transition related in our tests. But it's good to know that like your baseline standard behavior works. [00:16:25]
-
-And this also turned up several more things we'll have to figure out, like, quality checks and how do you handle selectors throwing errors, and we're talking about when can React safely, call selectors, can it delay it due to batching and things like that. So also very excited to see the progress being made on this API. A lot of people have asked for external state transition compatibility, and so this is going to be a big deal for the ecosystem. [00:16:39]
-
-2-vcarl: Interesting. Cool. I'm just trying to put this in a little bit of context for myself. So this is a, an exploration of an API for a concurrent store that they've indicated intent to ship eventually. Is that right? Mm-hmm. [00:17:08]
-
-1-acemarke: Yeah. So basically a, a new equivalent of `useSyncExternalStore`, but minus the sync restriction. [00:17:22]
-
-2-vcarl: Got it. Okay, cool. Interesting. You called it a poly fill, and I see in the blog post it's labeled a pony fill, which I had to refresh my memory on the distinction; a poly fill fills in a gap in the platform transparently, and a pony fill offers the same functionality, but as a standalone module that you have to import. [00:17:30]
-
-There you go. Now you know. [00:17:50]
-
-## React Router and transition usage
-
-1-acemarke: So one more item kind of related to that. At React Conf, Ricky Hanlon announced a new Async React Working Group to provide support to the, you know, the community and the ecosystem on, you know, improving the React docs around async behavior, helping libraries get set up to use these methods. [00:17:52]
-
-## [Matt Brophy and Ricky discussing nuances of behavior, use with React Router](https://github.com/reactwg/async-react/discussions/5)
-
-1-acemarke: And so Matt Brophy from the React router team had a good discussion with Ricky about how they're trying to handle using transitions in React router. So there was a, a good technical discussion about the nuances of behavior. And then the React router team also put out a pre-release version or unstable option to enable some of the transition behavior as well. [00:18:08]
-
-So starting to see some adoption and this ties into the React team wanting to see libraries pick up these behaviors like transitions and action props and, and build them in. I will say that I had a couple discussions at JS Nation React Summit where some people were questioning whether making the entire ecosystem change semantics and behaviors and add props to make the React team happy was gonna be a good idea or feasible, but we'll see. [00:18:33]
-
-2-vcarl: Yeah, interesting. I see a bit of why they, why the core team desires that. Transitions are definitely like. My understanding of the core team's incentives and what they care about is ability to use the platform and things like that. So given that like transitions are a part of the platform and they are interested in allowing people to take advantage of platform improvements, I understand why they would message, "in order to use this, the entire ecosystem must make this change to the patterns they use for compatibility reasons." [00:19:03]
-
-But that is very, I don't know. That's a big challenge. It's herding a lot of cats who don't necessarily, aren't even necessarily aware that there's an attempt to herd being made. [00:19:38]
-
-1-acemarke: If you watch Ricky's talk from React conf, you know, he, he demoed switching from like a bunch of manual use effects and loading states to suspense and transitions and then he pointed out, and so now you have a much better experience, but you also had to do, you know, call start transition and all your click handlers and so on. [00:19:49]
-
-There's even some painful nuances there because start transition is based on setting a flag internally for the current event loop tick. If you have a callback that has an await, you leave the event loop tick. And if you then want to do another state update after the await, you have to call start transition a second nested time. [00:20:05]
-
-And Ryan Carniato actually pointed out to me that like Ricky has repeatedly messed this up in his own demos, it's a very foot gun prone behavior pattern. And so the combination of, like, you currently have to call, start transition yourself, plus trying to get the patterns right, is a good argument for let's just build this into all the libraries. [00:20:29]
-
-But that takes time and effort and coordination. [00:20:53]
-
-2-vcarl: Yeah. Right. Like that was one of my big takeaways from Ricky's talk was, oh, this looks hard. Which is not the best takeaway if you're trying to convince the whole ecosystem to move on to something. [00:20:56]
-
-1-acemarke: There is a lot of complexity in mental model of React and the kinds of apps we're trying to build. [00:21:08]
-
-And both the fact that you now need to keep track of additional API methods that you have to call and the semantics and when you're supposed to use them. And the fact that your, your state is now kind of in multiple Schrodinger's box, multiple versions at once. It's, it's definitely a lot of additional mental overhead. [00:21:15]
-
-2-vcarl: Yeah, right. I'm just looking at, in this GitHub thread that you linked, Ricky says, you know, oh, I think there might have been some confusion. Here's how you do it for navigations and it's, you know, function, navigate to A URL that has start transition, which, you know, wraps set router state, which then wrap, you know, it's argument is a function that I guess returns A URL. It's a thunk for set router state in start transition, in navigate. I don't know, they're like, that's just complicated. Like what? Why are we wrapping this with so many different functions just to navigate? That's uncomfortable. It feels like the wrong API in some way. You know, like it an API should obscure complexity and this does not obscure the complexity. [00:21:35]
-
-So, interesting. I want to be able to take advantage of transitions in apps. 'cause that's super great if you can just like easily convey that you are here and you're about to go here. Instead of just going there, like you get a lot of really powerful things that you can do for user experience and, you know, whatever, all sorts of stuff, if you communicate the transition instead of just updating the current state of your app. [00:22:17]
-
-But yeah, I don't, I, I'm not sold on this. I'm not sold on one I'm seeing so far. [00:22:43]
-
-1-acemarke: Okay. Moving on to the next related chunk of topic. [00:22:48]
-
-## [The State of TanStack, Two Years of Full-Time OSS](https://tanstack.com/blog/tanstack-2-years)
-
-1-acemarke: The Tan Stack folks have a bunch of updates that they've put out both blog posts and versions. So Tanner put out an article on the state of Tan Stack as an organization and his own work as a full-time open source maintainer for the last couple years. [00:22:53]
-
-Also, again heard, you know, heard some of this from, from him directly at a React summit loosely. He himself has been full-time supported open source for the last couple years, sponsorships to the TN stack org. Tan Stack Libraries are, you know, as we all know, very, very widely adopted and certainly query is the standard Fritz thing at this point. [00:23:13]
-
-Router and is picking up a lot, A lot of popularity start is almost 1.0 and he's hoping to be able to start to bring in some part-time or even full-time. Uh. People to hand stack the company in the near future, essentially other. Current maintainers for various stand sand stack libraries who would then be able to potentially switch to doing that as their actual job. [00:23:34]
-
-So essentially he's been fortunate enough to have this work out for him and he's hoping to share that ability with other people working on the projects. [00:24:00]
-
-2-vcarl: Yeah, I see. He says monthly sponsorships for 12 core contributors and short term contracts for another three to five people. I guess that's not clear what monthly sponsorships means. [00:24:09]
-
-I, my assu, my assumption there would be like their, maybe not full time, but getting like sign, you know, significant compensation. But that may not necessarily be true. [00:24:20]
-
-1-acemarke: I don't know numbers, but I think at the moment the others are doing open source and they're full-time and getting some, some stipends and in the next couple years he's looking at actually hiring some of them. [00:24:30]
-
-2-vcarl: Cool. Love that. That's super hard. Building revenue so that you can actually support other humans is actually really challenging. I really like this blog post about, you know, Tan Stack for two years. I like this line. You know, building a full stack framework is hard. I knew that from watching other teams do it. [00:24:42]
-
-Most of them had something I didn't. Capital Next Gatsby Redwood Remix all had funding companies or acquisition paths and that that definitely is something that feels very different about Tans stack. It feels very much like he couldn't not do this. Like he just had spent several years working in this problem space and solving his own problems with the freedom to publish them so that other people can take advantage of his work. [00:24:56]
-
-And then got to a point where it just made sense to invest more effort and take those a little bit further than they could go. Absent that. Level of dedication I, which i, I love. That's just like, that's, I don't know, finding that kind of work to do for yourself is what I've been looking for. And it's really hard to find, and I love that Tanner Winsley has apparently found it. [00:25:20]
-
-Yeah. And also having 16 partners doing sponsorships is also great. Like that, that, that may not be capital, but that's, that's great. That's nice. Having tried to find sponsors myself, like getting 16, it's like, oh shit. Good job. That's awesome. [00:25:43]
-
-## [TanStack DB 0.5](https://tanstack.com/blog/tanstack-db-0.5-query-driven-sync)
-
-1-acemarke: Tan Stack DB is a new work in progress package largely being worked on by Kyle Matthews, formerly of Gatsby, currently of electric SQL, that is meant to be kind of like a half a sync engine layer on top of another data source. And so like one of the common usage patterns for that would be you wrap it on top of your 10 stack query, you know, API definitions. And so maybe you've got some endpoints for fetching. Post comments, users, et cetera. [00:25:57]
-
-But then it presents like a sync engine like interface on top of that, and it's got a bunch of data flow analysis baked in so that it can do things like partial fetches or only re fetching, you know, certain pieces of data, joining, essentially presenting like a normalized facade layer over the individual endpoints so that they act like they're unified almost as a like a replacement for a GraphQL style API. [00:26:27]
-
-And so they've been working on this and it has integrations with Tan Stack Query and then Electric SQL and a few other data packages. And Tanner pointed out to me at React Summit that it really just needs an adapter layer to be able to connect to another library. And I could totally build one for RTK query. [00:26:54]
-
-And so I was actually briefly playing with that on the flight home. I haven't had a chance to push it further, but I'm actually, I'm actually very excited to play with that more myself because like Tan Stack query, we made the decision to make RTK query non normalized. It just caches the response from the server. [00:27:12]
-
-And so if this essentially let us make a normalized layer on top of our own library without us having to make any further API changes. That's very interesting to me. [00:27:29]
-
-2-vcarl: I'm also thinking about, you know, this is from Kyle Matthews who did Gatsby, which, you know, notoriously exposed a GraphQL, you know, layer on top of whatever data sources you wanted to give it. [00:27:41]
-
-So just, I'm thinking about how, how much of Kyle Matthews work could be described as providing query abstractions over arbitrary data layers with data connectors. [00:27:54]
-
-1-acemarke: That's a good point. I, I had, I hadn't even drawn that connection that this is actually very related to his prior work. [00:28:05]
-
-2-vcarl: If you described this at a certain level of abstraction, this sounds just like GraphQL, Relay, Gatsby, a bunch of other stuff. But I do see the niche that it occupies and how it's distinct from those projects. It's kind of like GraphQL, except instead of the network boundary, it's like the component to data store boundary on your client app, which it, that's useful . [00:28:11]
-
-Like what you just said about how you don't normalize in RTK query, I've landed on that as being generally a good architectural decision to make in applications because like if you start doing data transformations, you know, bespoke data transformations per endpoint, then it becomes really hard to change those endpoints. [00:28:33]
-
-If you're changing the underlying data, then you've gotta change all the code at the same time. Whereas if you just take whatever the API gives you and then write like a transformer on top of that, then it's just you, you add a layer of abstraction for yourself that gives you a little bit more flexibility around timing of some types of changes. [00:28:53]
-
-So, yeah, I don't know. That's, it's interesting. This is an interesting project. I dunno, something about it feels like I don't quite know where I would take advantage of it for myself, but I could see the right app with the right kind of team operating it, finding this and being like, this is exactly what we need. This solves multiple challenging thorny problems that we have or, so yeah, I don't know. It's interesting. [00:29:17]
-
-1-acemarke: My own personal to-do list is massive at this point. Both like Redux and even just like personal life stuff. But I, I absolutely want to go back and, and play with my own RTK query integration prototype for that in the near future. [00:29:40]
-
-2-vcarl: Yeah, I generally love the idea of sync engines. One of my core beliefs about writing code is that many more applications that we use have no technical necessity to be online only. [00:29:52]
-
-Like, there are a lot of things, like, for example, my favorite canonical example of this is like Gmail. If you're using the Gmail app. It doesn't actually care if you're online because it is doing synchronization of your emails in the background. And so you can just interact with it normally while you're fully offline and later it will do all the things like synchronize the read states or like, you know, which emails you've archived and deleted and yada, yada yada. Completely transparently. Like I have never thought about, oh, I should wait to do this later when I'm online so I don't cause weird problems for myself. And I do think about that all the fucking time in various other apps that I use. So like there, that's something that we used to do that we no longer do because it's hard. [00:30:06]
-
-I love seeing more effort and energy being expended into making it easier to do offline things. And sync engines are a big part of that. And so abstractions, over sync engines are also a part of that. Great. [00:30:45]
-
-## [Tanner teasing a WIP TanStack Start RSC implementation](https://x.com/tannerlinsley/status/1983999424486633931)
-
-1-acemarke: The Tan Stack router folks also put out a really good blog post talking about how they did some massive optimization on route matching, including using a somewhat lesser known data structure called, I think it's pronounced a try, T R I E. [00:31:01]
-
-I love I I love seeing optimization breakdowns. So good article there. And then since we've done plenty of, you know, stuff being teased on Twitter discussion in the past with Remix and everything else, Tanner has been teasing that they are working on RSC support for Tan Techstar. And I can say that he showed me a demo and it's unconventional. [00:31:13]
-
-It is not what you would expect after having used Next, and yet it totally makes sense in its own way once you see it. So as I understand it, they've made real progress on implementing it. They've figured out the design and now it's push it forward and make it actually a thing. I have no idea how soon this will be revealed, but I think once this comes out, it will be a very interesting, challenging take on our understanding of server components and how they, how to use them. [00:31:36]
-
-2-vcarl: I would certainly say that the way Next has done it does not seem to be like the end all, be all of great implementation. So if they have found a new way to approach it, hell yeah here for it. That's awesome. [00:32:10]
-
-1-acemarke: So there, there's your vague tweet for the month. [00:32:21]
-
-2-vcarl: Yeah. Right. [00:32:24]
-
-## State of the web ecosystem
-
-2-vcarl: Let's talk a little more broadly. Let's talk about the state of the web ecosystem, I guess like to intro our subtopics under state of the web ecosystem. I wanna talk a bit about like the CloudFlare outage, the NPM ongoing attacks. Like this is not a new attack, this is a continuation of the previous attacks, plural, that we've discussed, as well as Alex Russell had a decent blog post. I say decent because I don't know, it's it qualified, decent it, it's well written, it's well argued, but I don't necessarily agree with his conclusions. And also there, there's some conversation about reacts place in the ecosystem and AI and things like that. So that's the shape of this state of the web ecosystem chat that I want to start or that I want to have, I guess. [00:32:25]
-
-## [Cloudflare November outage postmortem](https://blog.cloudflare.com/18-november-2025-outage/)
-
-2-vcarl: Yeah let's start at CloudFlare. They had an outage on the, earlier this month, about a week ago, 18th of November. They say in their outage postmortem that it was triggered by a change to the permission system of one of the databases, which caused it to output entries ba- basically, it produced too large of a file that then got distributed out and the size of that larger file getting distributed caused performance load that took down the network. [00:33:13]
-
-1-acemarke: Check me this. Another factor on it was they, one of the services was written in rust and it had an expectation that the file would only be so big and there was, I think there was a rust line of code that basically said if it doesn't fit, panic. Yeah. That a bad file with like they had 60 features, a limit of 200 and a line of code that basically said if it gets over 200, throw, throw an error or kill the service. [00:33:40]
-
-2-vcarl: Yeah, that'll do it. Yeah. "Each module ran on the proxy service has a number of limits to avoid unbounded memory consumption." Somewhat questioned the wisdom of that because the reason you would have limits on memory consumption in place would be to avoid outage and downtime. And so if your resolution to, the outcome of your limit, if memory usage gets too high is to crash, that is functionally very similar to an out of memory error. [00:34:08]
-
-Maybe it's, I guess it's easier to debug, I guess you can, out of memory errors cause crazy, unpredictable failures, I guess. So at least this is a predictable failure that strongly indicates where the, the excessive memory use is coming from. [00:34:36]
-
-But yeah, it, it was pretty serious. I actually didn't notice, which I'm glad about. It's nice to not be so online that you don't immediately notice every, I don't know, every outage, but yeah. This kind of, I think this was a, a, a good demonstration of the place in the ecosystem that CloudFlare occupies and how many different services truly rely on its stable operations. Yeah. [00:34:49]
-
-1-acemarke: Trying to make the trade-offs between the web is decentralized. Anyone can run their own thing versus, Hey, look, there's benefits to having centralization. Let's all put our GitHub, or let's, let's all put our git repositories on the same service so we can, you know, log in and share them and comment back and forth. [00:35:11]
-
-Let's put all our social media comments on the same service. We can have commentary back and forth. Let's all use this widely spread CDN and DDoS protection service that also has a bunch of really cool backend services. And then when one of those big services goes down, it ends up having, or everybody put everything in AW, AWS East one. [00:35:29]
-
-2-vcarl: Yeah. Right, right. Yeah. Right. Or, [00:35:50]
-
-1-acemarke: or even like we, we put it in AWS East two, but AWS themselves relied on AWS East one, and then it goes down. We keep burning into these big dependencies that end up having massive effects on the internet when they go down. [00:35:52]
-
-2-vcarl: This feels like a good transition point to a link that we had slightly later down. [00:36:06]
-
-## ["What if people don't want to create things"](https://macwright.com/2025/10/21/what-if-they-dont-want-to.html)
-
-2-vcarl: Tom McRight, who is not a name I recognize, put out a blog post called What If People Don't Want to Create Things? And that feels like what you're talking about, like the ideals of the web is decentralized, you know, their own domain, right? Sharing knowledge, sharing skills, sharing tools, and I love that. I agree with that. I aspire to those ideals. [00:36:10]
-
-But it's also true that like we kind of just want stuff to work. We want it to just kind of be stable and you know, what's not stable, decentralized things that have a smattering of volunteers maintaining it. That's kind of the distinction. Like that's kind of the trade off is like over time decentralized things with enthusiastic maintainers and open source, over time that stabilizes and grows and becomes great in a way that proprietary code can't, because you know, you can't inspect it, you can't say like, I'm encountering this bug. Let me go look at the code. Oh, here's where it's coming from. Let me tell them about it and give them a reproduction. And contribute to a fix. Like if I encounter a problem like that in any of these many proprietary tools that I use, then there's just no path for me to do that, so. [00:36:33]
-
-But on the other hand, they have the capital and the employees to have people proactively looking for that, where it's their job. That's the tension. I tend to believe over a long enough time scale that distributed, decentralized things like the web will be better than anything that's like proprietarily developed. [00:37:25]
-
-But it has to work well enough to get the attention. And you know, in this attention economy we're in, it's very hard to get people who have enough bandwidth of their attention to say, "I have found this problem, let me chase it down to its logical conclusion and contribute to a fix being actually shipped for me and people like me." [00:37:47]
-
-1-acemarke: We aren't gonna go off on this, but I can even see some tangential connections with things like open source as a concept, open source maintainer, burnout. Like most people like using an app or a library or even even developers using a library, like in the end, do they actually care that it's open source? [00:38:05]
-
-No, they just want to download the thing and have it work, whether it's Libre office or you know, a paint, you know, paint program or Better Auth or whatever. And the fact that the code's open doesn't matter. It's like I, as the consumer of this thing at this level, just want it to work. And if it doesn't, I ask the person who builds it, just make it work. [00:38:23]
-
-2-vcarl: Right. I'll call out a couple of quotes from here. "Beautiful data visualizations are free to make, but the supply of people who really love and know D3 is a lot lower than I expected it would be. I love home-cooked apps and malleable software, but I have a gnawing feeling that I'm in a bubble when I think about them. Most people's lives are split into the things that they affect and create and the things that already exist and wanna tune out and automate." [00:38:46]
-
-I think that's a, I think that's insightful. I think that speaks to a deep, I don't know, tension in this. Like, yes, AI lets you do a much larger range in a much shorter time span than used to be feasible. But do people want to do that? I don't know. [00:39:07]
-
-Given the, given a range of infinite possibilities, how do you pick which one that you are going to do and then give it the attention so that it actually produces something that other people can benefit from. How do you find the things that you want to build on top of, you know? [00:39:24]
-
-## [“When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”](https://webtechnology.news/when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react/)
-
-2-vcarl: Well, I guess I'll transition from that, from that comment to this other post. "When everyone's a developer, how do we promote the web platform over react?" It's in reference to this Alex Russell Post that I'll, I'll, I'll share after. But I guess it's talking about, it's talking about that like when people can make their own software, when they can just use plain English to ask AI to generate code that in one form or another, solves the problem. [00:39:39]
-
-They stated, you know, maybe not the way they intended, maybe not the way they wanted, but it. It's doing its best, just like all of us. It's talking about how if you just ask it to make something, it's probably gonna use React, because that's what, by volume of text, by volume of code that it's trained on. That's what, that's the mode. That's the most common example. [00:40:03]
-
-I guess, like this is framed as a, an AI problem, like why does AI do this? But this is actually the same problem that I've observed well before AI came out, you know, 2022 or when everyone chat GPT really started, I have observed all of these problems that it's talking about over the life of my career. [00:40:20]
-
-Like, you know, especially I feel like, you know, there's a certain golden age of tech between 2018 and, I dunno, 2021 or so, and that was absolutely the case. Like I would, you know, join a new workplace, because I did that a lot, I worked at a lot of different companies and I'd look at the practices people were using. It's like, why did you use React for this? Like there's, here's a platform feature that solves this more easily. And with less code. And a lot of the time people just didn't know it existed. Like it's that attention problem. How do you know what you should build on top of? [00:40:38]
-
-I don't know. It's the solutions here that people are talking about is like, what can we, the web community do to promote web platform features over react code and it proposes teach vibe coders to explicitly prompt for web native solutions, get the LLMs to ingest more web platform code, spotlight teams and projects that ship modern web experiences without heavy frameworks. [00:41:11]
-
-I mean, like that's, to me, all of those essentially just like how do you make the web platform more popular? To me, ai, it fundamentally spits out an average. It spits out like, you ask it to do something and it will give you a deeply profoundly average result for, you know, if you asked a thousand people, that question here is approximately what the mass of those people would say. And it's true that if you asked a thousand developers to do something on the web, the most common output would probably be a kind of shitty implementation with React that overused things like use state news effect because that's what developers did and do. So I don't know, it's like a lot of these questions that we ask ourselves about AI and code, I feel like distill down to the same kinds of questions we were asking before. [00:41:33]
-
-But like now there's a boogeyman of ai, like this is ai, this is this, this is code, this is a product people have built. And so it is now a very convenient boogeyman, but it, it's a distillation of the thoughts of a vast number of people as codified by what they published and what was ingested for the training set. [00:42:26]
-
-1-acemarke: I just tossed in a link to the obligatory XKCD from like a decade ago, which is the, the one of the points out that sometimes your, your map or your heat map of users is actually just a heat map of the population. It's a one-to-one correspondence. And so I think that that is partly what we see with like React usage. [00:42:46]
-
-You know, there, there's a lot of people. Who use React. There's a lot of people who use React badly and therefore, like the spread of types of usage of React, the quality of usage of React kind of maps to the quality of programmer skills and backgrounds, like not necessarily an excuse. And that's not to say that like everything about using React is is good by itself, but just that when you have a full cross spectrum of the population using a thing, you're going to have the full cross spectrum of the population using it in good and bad ways. [00:43:07]
-
-And so in the same way when it like, when it comes to, you know, people building apps, re React got popular, when LLMs came out and saw that was re React was popular. So LLMs repeat what they were trained to do, and plus it's also, you know, like not just popular, but it's especially popular within Silicon Valley, within all the companies making the AI builder tools, et cetera. So in a lot of cases, they're prompting them to just use React because they assume it's the default that you would use anyway. [00:43:45]
-
-2-vcarl: I, I wanna shout out a term that I love, "path dependence," which is like, where you're at right now is the outcome of a series of choices that were made in the past, and those past choices constrain what paths are available moving forward. That's path dependence. Where you came from affects where you can go. [00:44:13]
-
-And so I guess like to me that this is a complaint about the path dependence of React. Like because React got popular now React is, we've worn that rut and so now it's hard to get out of that rut even if there is a better alternative. [00:44:35]
-
-And so I would say like the solution there isn't like, I don't know, tell people they're bad at things. The solution is to like make better resources so that a different path becomes the easiest one to take. En masse, you know, writ large, when, you know, it's one thing to convince 15 people that this is the best solution and it's correct. [00:44:51]
-
-And it's another to make the argument clearly enough, strongly enough, and consistently enough over a long enough span of time that it affects the behavior of millions of people. So, you know, how do we promote the web platform over react, like do a better job promoting the web platform, 'cause there are thousands of people who are writing resources for React because that's where money and attention and time is. [00:45:14]
-
-So if you want to do better than that, you have to make a resource that is better. I don't know that. There you go. [00:45:45]
-
-## Related, [“Dead Framework Theory”](https://aifoc.us/dead-framework-theory/) from last month
-
-1-acemarke: Yeah, so the, the, the other, there was a related article from last month entitled Dead Framework Theory, which was specifically addressing like the the LLM training data aspect of this and how it, how it becomes a, sort of a self perpetuating cycle. [00:45:53]
-
-And also pointing out that like if you have a, a new library or a new tool or a new web platform feature that is just now baseline, newly available, there's a lag in common LLMs knowing about that. So it's sort of like that defaults win kind of an issue. [00:46:07]
-
-2-vcarl: Yeah, and I'll say, yes, defaults win, but that doesn't mean that it's impossible for an, you know, to approach the problem in a way to mitigate that kind of, you know, home field advantage that tools like React have. [00:46:25]
-
-I've shout it out a number of times, in a bunch of different contexts, because they do a good job! But I love effect. One of the things they do really well is documentation, and one of the things they do really well in their documentation is making it legible for ai. I recently, over the summer, built a greenfield project with effect, and I did it extensively with ai, a mixture of having it write and then having it educate me and then rewriting it, and then having AI rewrite what I did, you know, just get there over time. [00:46:38]
-
-But I was able to do that despite it being a new library that's even at odds with the kind of patterns that AI wants to write, it's a functional type, it's a functional programming typed standard library essentially, which is not at all what AI wants to write. AI wants to write object oriented classes. And despite that, I was able to make it, figure it out and learn it and do a good job, good enough job that I got something I was proud of. You know, not just vibe coded. I was proud of it. I told people in my life, this is the best code base I've ever worked on. [00:47:07]
-
-And it's a large part of that was because of how the effect as a, you know, organization and library approach, their style of documentation. They made it legible for these automated tools. So I guess like if you wanna promote the web platform over. Incumbents like React then like figure out how people are writing code, figure out how people are consuming documentation, consuming new knowledge and do a good job. [00:47:36]
-
-1-acemarke: I'll note though, that you, you are the one who decided you were going to use effect and told the LLM, this is what I'm going to build. [00:48:03]
-
-2-vcarl: It's true. Yeah. [00:48:11]
-
-## [Alex Russell’s latest stats on web devices and network budgets](https://infrequently.org/2025/11/performance-inequality-gap-2026/)
-
-1-acemarke: The last wink on this particular topic, Alex Russell, who used to be at Google now has been, Microsoft has been very vocally beating the drum that most client side JS is bad, that JS bundles keep growing, that most people are using. You know, older Android devices on mobile with very weak CPUs and therefore JS load times are worse versus, you know, developers using an iPhone or, or a Power or a Fast Mac or something. [00:48:12]
-
-And he just put up the latest article in his ongoing series. You know, documenting, stan-, like average bundle sizes, average network speeds, average CPU uses. I have a lot of respect for him. Technically, his stats are correct. His points are right. I have questions about his delivery and tone in how he accuses people of doing the wrong thing. But it's also very true that a lot of the people should be paying more attention to him and actually trying to shrink down bundles instead. [00:48:41]
-
-2-vcarl: That's interesting. I, a thought I've had, I haven't validated this thought against, you know, ground truth, but I've been hearing about bundle size as a problem. Essentially what he's talking about here, like we ship too much JavaScript for the compute capabilities of commonly used devices, like that as a thesis has been something I've been hearing about for a very long time, much of my career even, and I'm not sure that the bundle size problem has gotten that much worse over the last, I'll say eight years, you know, call it since 2017. [00:49:14]
-
-And he shows a chart of compute speeds and basically shows like, yes, top of the line devices have gotten five times faster, low end devices that 75% of the world uses have not gotten measurably faster. And that's true. Can't argue it. His stats are correct, like he said, but also like I'm not sure the problem is getting measurably worse. [00:49:52]
-
-The optimizations of how we can split code and you know, what the JIT and the execution environment is doing to make it work more quickly. Those have gotten better over time. And it's also true that like, so if he's looking at the, basically like every processor, anyone with a device is using and that is the correct stat to consult if you are building something that everyone in the world will access. [00:50:14]
-
-But that's not true for most startups. Like if you're building a startup that targets like some industry, that American businesses, is, targets a problem that American businesses need solved, then like it doesn't really matter what the mo-, mobile performance in, you know, different outside of that target industry, I guess are then it's like, like what you said about his like tone and delivery. [00:50:45]
-
-I think a, to me when I read this, a core part of what, that I think he's overlooking is that not everyone is trying to ship something that 100% of the people in the world can access smoothly and quickly. Like, and that's fine. Like, you know, not everything needs to target everybody in the world. So, I don't know, I, I guess that that's one of my takeaways. [00:51:09]
-
-That's one thing that I think is missing from this, otherwise very technically complete blog post. [00:51:30]
-
-1-acemarke: I think it's also true that an awful lot of app teams out there ought to be spending time thinking about like even just basic bundle sized stuff and they aren't. [00:51:37]
-
-## Npm attack, [Shai-Hulud round 2](https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains)
-
-2-vcarl: I do wanna talk about the NPM hack that is ongoing Shai-Hulud, the sand worm. [00:51:48]
-
-I want to call out. As far as I know, aikido.dev has been like the security researchers who have announced this, like uncovered it and then analyzed it and shared it. [00:51:55]
-
-## [Analysis of its evolution in code](https://www.aikido.dev/blog/bugs-in-shai-hulud-debugging-the-desert) from Sept
-
-2-vcarl: They had a really good analysis of the evolution of the code, of the attack of this worm from September, and I noted in that when I was rereading it after this, you know, new, new attack, they had shouted out that it appeared that they still had more credentials in reserve. Like they had cracked more credentials than they had actually used. [00:52:06]
-
-And sure enough, this, you know, round two attack in their analysis of of it this time around, they note that it was timed just before NPM's deadline for revoking old tokens. So like very clearly they had a lot of tokens that they had compromised previously that they were now taking advantage of before they, before they lost access to it, before those tokens were no longer valid. [00:52:29]
-
-And I guess to reiterate, we've talked about, we talked about this attack before, I would say this is, this represents the current cutting edge of malware. It is using all sorts of fascinating root execution, like privilege escalation. I saw discussion of it, starting a docker container, mounting your file system to that privileged environment and now suddenly it has privileged access to all sorts of files that it couldn't have if it was just running in your shell. [00:52:48]
-
-There's stuff like that that's pretty fascinating and other things like if you have a Claude installed, it will prompt Claude to say, "Hey, look around this file system for secrets." like that is very cutting edge malware. To me, it's, it's not just writing its own code. It's not just a worm that is trolling your file system. [00:53:14]
-
-It is taking advantage of other tools that you take advantage of to attack you. So it's, yeah. That's not great. [00:53:32]
-
-1-acemarke: I mean, like, big picture, it's almost, it's almost surprising how many widespread pieces of malware have been very dumb and weren't as nearly destructive or smart as they could have been. And like think of how much damage we've had collectively as an industry over years with only a lot of those dumb malware. [00:53:39]
-
-And now we're starting to see some people write more intelligent malware. [00:54:01]
-
-2-vcarl: Yep. Yeah. 'cause a month ago, or two months ago, whenever it was, there was a different NPM hack that managed to get into the debug package, which is massively widely used. And I assumed that it was the same attackers as this attack because it's, it, it resembled it in a couple of ways, except that it was dumb. It was so poorly executed. [00:54:05]
-
-Like they got close to unprecedented access to the NPM ecosystem like. This is one of the first times that that previous attack, the debug attack, was one of the first times that I saw, "here's this compromised version. Let me check my file system. Oh, yep, there it is. I've got this." [00:54:26]
-
-So yeah, they just straight up fumbled the bag there. My theory here, having paid attention to this, it seems like there's some hacker group that may have compromised, set up a phishing tool set, you know, set up tools for other malicious actors to run phishing attacks. And it feels like two different hacker groups took advantage of those tools to target NPM maintainers. [00:54:45]
-
-And only one of them is actually technically competent enough to take full advantage of the access that they got. So yeah, I believe we've shared these resources before. [00:55:13]
-
-## [Our plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) from September
-
-2-vcarl: And GitHub put out our plan for a more secure NPM supply chain, so they're still working on that clearly. [00:55:23]
-
-## [NPM update on token management changes](https://github.blog/changelog/2025-11-05-npm-security-update-classic-token-creation-disabled-and-granular-token-changes/)
-
-2-vcarl: They also just released an NPM security update earlier this month in November, November 5th. [00:55:29]
-
-## ⚡ Lightning round ⚡
-
-2-vcarl: Mark, you want to just read through any of these lightning rounds that you wanna call attention to? Okay. [00:55:34]
-
-## [TS 6.0 hopefully Feb 2026, 7.0 (native) soon after](https://bsky.app/profile/danr.bsky.social/post/3m5fz3vw2z22s) (more details in the [TypeScript.fm](https://share.transistor.fm/s/ad05eae6) podcast)
-
-1-acemarke: TS six and TS seven are hopefully gonna be coming out early next year. TS six is still the current TypeScript code base, but with some changes to defaults and deprecation. And then TS seven would be the native implementation in go that they're working on. [00:55:38]
-
-So a couple different updates on the release plans there. That's going to be very, very exciting. I am excited to have TypeScript compiler 10 times faster. [00:55:54]
-
-## [Latest TC39 proposal updates](https://bsky.app/profile/robpalmer.bsky.social/post/3m62djhwj3k2i)
-
-1-acemarke: Also there were some more. The latest TC 39 proposals meeting as usual, advanced a number of different proposals to different stages. A couple of things that look interesting. [00:56:03]
-
-There's a promise do all keyed, which is essentially promise dot all but for an object. And then I am excited, un irrationally excited about object keys length, which is literally just to get the size of the number of keys in an object instead of object keys, parentheses, length. [00:56:13]
-
-## [Chrome (and other browsers) wants to remove XSLT from the web platform](https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4gYZeSJA/m/yNs4EsD5AQAJ?pli=1)
-
-2-vcarl: Chrome, and a couple of other browsers want to remove XSLT from the web platform. XSLT is a, what, domain specific library for transforming XML? [00:56:32]
-
-1-acemarke: XML transformations within a browser. So you, you send out an XML document from the server, and then you have a purely client side declarative transformation that like converts it into HTML. [00:56:42]
-
-2-vcarl: It exists. I had no idea that it was a browser feature. I've known of it as a tool that exists, but I had no idea it was baked into the browser and they're looking to remove it and I'm okay with that. But certain people who I guess use it for one thing or another have been running a campaign to say, "no, please don't. What about RSS feeds?" But yeah. [00:56:54]
-
-## [“Your URL is Your State”](https://alfy.blog/2025/10/31/your-url-is-your-state.html), and [David K’s “Goodbye, useState” talk](https://gitnation.com/contents/goodbye-usestate)
-
-1-acemarke: Going along a bit with the whole use the platform thing, more people should be putting some of their state in the URL and there was a very good article on using the URL as state. And then along with that, another video from recent React Summit that's probably paywall at the moment, but I think he's done a couple previous versions of this at different conferences. [00:57:14]
-
-David Kourshid has a talk on goodbye used state, similar to his goodbye use effect. It's hilarious, it's funny, and it also points out why you shouldn't be using actual used state all that much. [00:57:33]
-
-## [Aiden Bai’s “React Grab” util](https://www.react-grab.com/)
-
-2-vcarl: Aiden Bai, who did millions js put out an interesting new tool called React Grab, basically letting you, you know, you, is trying to solve the problem of when you tell AI like, "Hey, make this thing different." And then it goes, "I don't know where that is. Here's your browser, but I don't know where that is in the code base." [00:57:46]
-
-And so this is a tool that helps map similar to how you can use dev tools to highlight an element. This is taking that kind of behavior where you highlight an element in your browser and it connects back to the actual source code that produced that element as a means of giving AI a head start on finding what code to use, which seems super cool. [00:58:03]
-
-I questioned the wisdom of the recommended get started thing, which is just to add a script tag to unpkg. I don't know. Seems, seems slightly sketch, but also for also seems really easy to, to get started. [00:58:25]
-
-## [Creating a custom Node module loader to import from Bittorrent](https://evanhahn.com/node-torrent-import/)
-
-1-acemarke: One thing that caught my eye in terms of like, this is awesome and you should never, ever do this, was implementing a node module loader that imports from BitTorrent. [00:58:39]
-
-Okay, great. That's possible apparently. [00:58:48]
-
-2-vcarl: Love that. I do love BitTorrent. You know, as we were talking about decentralized technology a little bit earlier, like, man, what a highly resilient, decentralized technology. But yeah, well, hey, you know, maybe if we're gonna tell you, if we're gonna encourage people to do decentralized technology building on the shoulders of giants, like it, man, if you want it to like never stop working, ever, sure, import your code from BitTorrent, probably it's not gonna work very quickly, but given the right underlying seeders that would, that may never go down. Pretty interesting. [00:58:52]
-
-## [Ryan Carniato’s stream on researching “async signals”](https://www.youtube.com/watch?v=ori9xZhvNlc)
-
-1-acemarke: Earlier I mentioned Ryan Carniato streaming and talking about async signals. Here's the six hour livestream video if you want to watch that and or throw it into a summarizer somewhere. [00:59:22]
-
-## [Details of building Node’s TS type stripping support](https://satanacchio.hashnode.dev/the-summer-i-shipped-type-stripping)
-
-2-vcarl: I'll shout out the details of building nodes, the node type, script type stripping support, just 'cause I, man, I do love a technical writeup and that is, that was a massive feature release, just like the ability to use node to run TypeScript code without doing a compilation step. Was pretty cool. And so here to here to signal boost a post from the author of it. [00:59:33]
-
-## [The Web Animation Performance Tier List](https://motion.dev/blog/web-animation-performance-tier-list)
-
-1-acemarke: And one more, since we spent much time talking about the, the web platform, the author of the motion animation framework put up a really good post comparing all the different ways you can do animations on the web and talking about some of the performance trade offs. [00:59:58]
-
-2-vcarl: Super good. Cool. [01:00:12]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-2-vcarl: Into some conference news. [01:00:14]
-
-We don't really have much 'cause it's the end of the year and all of the upcoming conference things don't show anything for like January or February. [01:00:15]
-
-## CFPs
-
-1-acemarke: Well, we don't have much of a list here, but I can say that I've actually been doing my own, trying to prepare CFPs for next year and it ended up making a database of conferences and like my own personal list is like dozens of them. [01:00:22]
-
-And I can tell you there several conferences have submission deadlines like by November 30th s Why? I'd say there's a lot more conferences out there that knew existed until I spent several evenings spent researching them and trying to put this database together. [01:00:35]
-
-2-vcarl: I've tried to do that consistently over the past three years for this podcast and holy shit, there are so many conferences. It is absolutely bananas. Some of them are even fraudulent, so it's like you, you actually gotta them. So yeah, it's a lot. But okay. [01:00:47]
-
-## [React Paris](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform) ([Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform))
-
-2-vcarl: All that to say, I am aware of, React paris has a CFP currently open, but that's gonna be in March. So if you're looking to talk, then they've got a CFP open, you can do that. [01:01:01]
-
-## [JSWorld](https://docs.google.com/forms/d/e/1FAIpQLSfv3GuXwsDyR42XsvJwfFsN4SKjy8WvKtqYp_nEK0yhzVNP1g/viewform) CFP closes Dec 31, notifies by Feb 1
-
-2-vcarl: JS World also likewise has a CFP that closes at the end of December. [01:01:12]
-
-## Ending
-
-2-vcarl: Thank you everyone who has managed to stick around for this, you know, hour and 15 minute recording session. [01:01:18]
-
-1-acemarke: Funny we said we didn't have a lot of main content for today and go figure. We had a lot to say about stuff. [01:01:24]
-
-2-vcarl: Yeah, right. I give us a, give us a blank slate and we will fill it. Boy howdy. [01:01:29]
-
-1-acemarke: Hopefully the discussion has been useful. [01:01:34]
-
-2-vcarl: That is my hope. I, if not useful at least. Interesting. Cool. Thank you for joining us. We normally, I say we'll be back on the last Wednesday of the month, but the last Wednesday of next month I think is [01:01:36]
-
-1-acemarke: December 31st, [01:01:48]
-
-2-vcarl: so I don't know, we're probably not gonna do it on the last Wednesday of next month, but we'll be back [01:01:49]
-
-1-acemarke: somewhere about that timeframe approximately ish. [01:01:54]
-
-2-vcarl: Before the end of this year. [01:01:57]
-
-Yeah. Generally, I say we gather sources from all sorts of news feeds and whatever, but Mark, you've done a good job of being my source lately. So mostly we get news from #tech-news-and-reads, or at least that's where I get it. [01:01:59]
-
-I don't know where Mark gets it. [01:02:11]
-
-1-acemarke: All of the above newsletters plus like Hacker News and Twitter and all the other social media feeds I obsess over. [01:02:13]
-
-2-vcarl: But yeah, we do subscribe to this week in React by Dev React status next year. It's weekly. Mark and I are both subreddit mods of React js. But yeah, if you see anything that seems useful that you might want us to discuss, drop it in the #tech-news-and-reads channel. [01:02:20]
-
-I'll at least read it. I may not bring it in, but yeah, if this is a show that you get value from and wanna support, the best way to do so is by telling people about it and submitting a review that'll help us get discovered and whatever. [01:02:36]
-
-Cheers. Thanks so much. [01:02:48]
-
-1-acemarke: Happy Thanksgiving. [01:02:50]
diff --git a/src/transcripts/tmir-2025-12.md b/src/transcripts/tmir-2025-12.md
deleted file mode 100644
index c523838..0000000
--- a/src/transcripts/tmir-2025-12.md
+++ /dev/null
@@ -1,1022 +0,0 @@
----
-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]
diff --git a/src/transcripts/tmir-2026-01.md b/src/transcripts/tmir-2026-01.md
deleted file mode 100644
index 62ed2a2..0000000
--- a/src/transcripts/tmir-2026-01.md
+++ /dev/null
@@ -1,840 +0,0 @@
----
-title: 'TMiR 2026-01: Oops more CVEs. AI has React "skills", Astro exits and Tailwind struggles'
-date: 2026-01-30
-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:58](#new-releases)] New releases
- - [[00:59](#next-161-turbopack-updates-bundle-analyzer)] [Next 16.1](https://nextjs.org/blog/next-16-1) (Turbopack updates, bundle analyzer)
- - [[01:15](#turbopack-incremental-computation)] [Turbopack incremental computation](https://nextjs.org/blog/turbopack-incremental-computation)
- - [[01:38](#react-navigation-80-alpha)] [React Navigation 8.0 alpha](https://reactnavigation.org/blog/2025/12/19/react-navigation-8.0-alpha/)
- - [[02:03](#rn-windows-081-with-new-arch-support)] [RN Windows 0.81 with New Arch support](https://devblogs.microsoft.com/react-native/%F0%9F%9A%80react-native-windows-v0-81-is-here/)
- - [[02:55](#state-of-react-native-macos-saad-najmi-jay-meistrich)] [State of React Native macOS](https://www.youtube.com/watch?v=XE7yKGDsy9g) Saad Najmi & Jay Meistrich
- - [[03:15](#mark-josh-goldbergs-new-flint-linter)] Mark: Josh Goldberg’s [new Flint linter](https://www.flint.fyi/blog/introducing-flint)
- - [[05:15](#immer-111-array-methods-override)] [Immer 11.1](https://github.com/immerjs/immer/releases/tag/v11.1.0) (array methods override)
- - [[06:37](#rolldown-10-rc)] [Rolldown 1.0 RC](https://voidzero.dev/posts/announcing-rolldown-rc)
- - [[06:54](#yarn-6-preview)] [Yarn 6 Preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/)
- - [[07:42](#vite-plus)] [Vite Plus](https://viteplus.dev/)
- - [[08:59](#new-css-grid-lanes-masonry-feature-spec-nailed-down)] [New “CSS Grid Lanes” (“masonry”) feature spec nailed down](https://webkit.org/blog/17660/introducing-css-grid-lanes/)
- - [[10:39](#temporal-api-finally-hitting-stability-and-how-it-replaces-dates-)] [Temporal API finally hitting stability](https://developer.chrome.com/blog/new-in-chrome-144#temporal) ([and how it replaces Dates](https://piccalil.li/blog/date-is-out-and-temporal-is-in/) )
-- [[12:29](#main-content)] Main Content
- - [[12:34](#react-core)] React Core
- - [[12:37](#additional-updates-cves-for-dos-as-of-jan-26-update-to-1905-1915-and-1924)] [Additional updates / CVEs for DoS](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) as of Jan 26 . Update to 19.0.5, 19.1.5, and 19.2.4
- - [[13:40](#nextjs-dos-cves-for-image-optimizer-and-partial-pre-rendering)] [Next.js DoS CVes](https://vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472) for Image Optimizer and Partial Pre-Rendering
- - [[13:50](#react-docs-updates-for-useoptimistic-and-useeffectevent)] React docs updates for [useOptimistic](https://github.com/reactjs/react.dev/pull/8264) and [useEffectEvent](https://github.com/reactjs/react.dev/pull/8279)
- - [[14:11](#and-this-post-on-useoptimistic-issues)] And this post on [useOptimistic issues](https://www.columkelly.com/blog/use-optimistic)
- - [[14:32](#sparked-by-dan-raising-concerns-about-the-docs-quality)] Sparked by [Dan raising concerns](https://bsky.app/profile/danabra.mov/post/3mciooa25gc2v%20) about the docs quality
- - [[16:57](#ai-meets-rn-panel-discussion)] [AI meets RN Panel Discussion](https://www.youtube.com/watch?v=QX1a6I08o-A)
- - [[17:17](#work-on-the-gesture-api-and-view-transitions-and-fragment-refs-canary-only)] Work on the [Gesture API and View Transitions](https://github.com/facebook/react/pull/35564), and [Fragment Refs](https://github.com/facebook/react/pull/35630) (canary only)
- - [[18:29](#viewtransition-underlying-tech-is-now-supported-in-all-major-browsers-as-of-firefox-147-react-features-is-still-in-canary)] [\ underlying tech](https://developer.mozilla.org/en-US/docs/Web/API/ViewTransition/types) is now supported in all major browsers as of Firefox 147. React features is still in Canary.
- - [[19:22](#jordan-pred-the-actual-usestore-concurrent-store-impl-for-react)] Jordan PRed [the actual `useStore` concurrent store impl for React](https://github.com/facebook/react/pull/35449)
- - [[20:54](#types-changes-to-improve-form-events)] [Types changes to improve form events](https://github.com/DefinitelyTyped/DefinitelyTyped/pull/74383)
- - [[21:34](#other-security-issues)] Other security issues
- - [[21:39](#react-router-cves-meta-xss-file-access-external-redirects-csrf)] [React Router CVEs](https://bsky.app/profile/reactrouter.com/post/3mbwtrea3r224): meta XSS, file access, external redirects, CSRF
- - [[23:17](#node-security-releases)] [Node security releases](https://nodejs.org/en/blog/vulnerability/december-2025-security-releases)
- - [[24:38](#lodash-security-releases)] [Lodash security releases](https://openjsf.org/blog/lodash-security-overhaul)
- - [[24:46](#funded-by-a-european-effort-to-fund-projects-for-sovereign-resiliency)] [Funded by a european effort](https://www.sovereign.tech/programs/fund) to fund projects for sovereign resiliency
- - [[25:35](#githubs-announced-plans-on-security-improvements)] [Github’s announced plans on security improvements](https://github.blog/security/supply-chain-security/strengthening-supply-chain-security-preparing-for-the-next-malware-campaign/)
- - [[27:48](#summary-of-npms-publishing-changes-and-requests-for-improvements)] [Summary of NPM’s publishing changes](https://socket.dev/blog/npm-to-implement-staged-publishing), and requests for improvements
- - [[28:28](#claude-skills-in-the-react-world)] Claude Skills in the React world
- - [[28:49](#announcement-by-anthropic)] [Announcement by Anthropic](https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills)
- - [[29:16](#open-sourced)] [Open sourced](https://agentskills.io/home)
- - [[29:53](#vercel-react-best-practices)] Vercel: [React Best Practices](https://vercel.com/blog/introducing-react-best-practices)
- - [[30:47](#expo-claude-code-pluginskill)] [Expo Claude Code Plugin/Skill](https://x.com/Baconbrix/status/2011862532320084329)
- - [[32:23](#agents-worked-better-than-skills)] [“AGENTS worked better than skills”](https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals)
- - [[40:42](#moltbook-aka-openclaw)] [Moltbook](https://www.moltbook.com/), aka [OpenClaw](https://openclaw.ai/)
- - [[43:09](#remotion-ai-skill)] [Remotion AI Skill](https://x.com/Remotion/status/2013626968386765291)
- - [[43:49](#rsc-roundup)] RSC roundup
- - [[43:52](#data-fetching-patterns-in-rscs)] [Data Fetching Patterns in RSCs](https://gauravthakur.com/blog/data-fetching-patterns-react-server-components)
- - [[44:14](#nadias-can-you-fetch-data-with-server-actions)] [Nadia’s Can You Fetch Data with Server Actions?](https://www.developerway.com/posts/server-actions-for-data-fetching)
- - [[44:31](#infiniterenders-takes-on-partial-pre-rendering-and-app-router-complexity)] “Infiniterenders” takes on [Partial Pre-Rendering](https://x.com/infinterenders/status/2007670332362989569) and [App Router complexity](https://x.com/infinterenders/status/2007670332362989569)
- - [[45:03](#rebuilding-github-prs-with-rscs-same-author-who-did-issues-previously)] [Rebuilding Github PRs with RSCs](https://wtbb.vercel.app/i-love-dogs) (same author who did Issues previously)
- - [[46:01](#ecosystem-economics)] Ecosystem economics
- - [[46:07](#astro-acquired-by-cloudflare)] [Astro acquired by CloudFlare](https://astro.build/blog/joining-cloudflare/)
- - [[47:32](#tailwind-revenue-down-80-in-the-ai-era-laid-off-3-of-4-devs-working-there)] [Tailwind revenue down 80% in the AI era, laid off 3 of 4 devs working there](https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957)
- - [[50:15](#voidzero-and-vite)] VoidZero and Vite\+?
- - [[52:22](#246k-laid-off-in-2025-per-trueupio-27k-in-january)] [246K laid off in 2025 per Trueup.io](http://Trueup.io), 27k in January
-- [[52:56](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[52:57](#corbin-adapting-library-logic-for-react-compiler)] Corbin: [Adapting Library Logic for React Compiler](https://playfulprogramming.com/posts/react-compiler-library-support/)
- - [[53:11](#lea-verou-web-dependencies-are-broken)] [Lea Verou: Web Dependencies are Broken](https://lea.verou.me/blog/2026/web-deps/)
- - [[53:47](#aws-infrastructure-as-react-components)] [AWS Infrastructure as React Components](https://www.react2aws.xyz/)
- - [[54:38](#callstack-releasing-bunch-of-cool-projects)] Callstack releasing bunch of cool projects
- - [[54:48](#brownie-rn-brownfield-apps)] [Brownie: RN Brownfield apps](https://www.callstack.com/blog/introducing-brownie-type-safe-shared-state-for-react-native-brownfield-apps)
- - [[55:17](#voltra-rn-live-activities-and-widgets)] [Voltra: RN Live Activities and Widgets](https://www.callstack.com/blog/live-activities-and-widgets-with-react-say-hello-to-voltra)
- - [[56:12](#ryan-carniatos-annual-js-frameworks-direction-roundup-and-netlifys-2025-web-frameworks-in-review)] Ryan Carniato’s [annual JS Frameworks direction roundup](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2026-2hel) , and Netlify’s [2025 Web Frameworks In Review](https://www.netlify.com/blog/web-frameworks-2025-year-in-review/)
- - [[56:36](#alex-russell-shallow-session-spas-analytics)] Alex Russell: [Shallow Session SPAs analytics](https://calendar.perfplanet.com/2025/the-curious-case-of-the-shallow-session-spas/)
- - [[57:23](#devon-govett-how-to-compile-js-to-c-with-static-hermes)] Devon Govett: [How to compile JS to C with Static Hermes](https://devongovett.me/blog/static-hermes.html)
- - [[58:16](#joyee-cheung-requireesm-implementers-tales-and-requireesm-from-experiment-to-stability)] Joyee Cheung: [require(esm) implementer’s tales](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-implementers-tales/) and [require(esm) from experiment to stability](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-from-experiment-to-stability/)
- - [[58:53](#fixing-the-url-params-performance-penalty)] [Fixing the URL Params Performance Penalty](https://calendar.perfplanet.com/2025/fixing-the-url-params-performance-penalty/)
- - [[01:00:26](#react-transitions-for-low-priority-text-editor-updates)] [React Transitions for Low Priority Text Editor Updates](https://handlewithcare.dev/blog/transition_low_priority_editor_updates/)
- - [[01:00:46](#how-to-steal-a-react-component-fiber-internals)] [How to Steal a React Component](https://fant.io/react/) (Fiber internals)
- - [[01:01:20](#better-ascii-rendering-with-smart-character-selection-for-pixels)] [Better ASCII rendering with smart character selection for “pixels”](https://alexharri.com/blog/ascii-rendering)
- - [[01:02:32](#building-a-js-runtime-in-one-month)] [Building a JS Runtime in One Month](https://themackabu.dev/blog/js-in-one-month)
-- [[01:03:33](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [CityJS New Delhi](https://india.cityjsconf.org/), 18-19 Feb, New Delhi, India
- - [State of the Browser](https://2026.stateofthebrowser.com/) Feb 28, London, UK
- - [AppDevCon](https://appdevcon.nl/) Mar 10-13, Amsterdam Netherlands
- - [Programmable](https://www.programmable.tech/) Mar 17 / Mar 19, Melbourn / Sydney, Australia
- - [Frontrunners](https://frontrunners.tech/) Mar 27, Washington DC, USA
- - CFPs: [web talks](https://docs.google.com/forms/d/e/1FAIpQLScK3YlL_-2teVyX7pohkjIbsyLSF-8Hq4z-U7CPQ186sgdNPA/viewform) or [AI/data](https://docs.google.com/forms/d/e/1FAIpQLSedNNa4N64vgfsvAtGcBngKJrtd3h1_x0T019GTW-rSwCj0jQ/viewform)
- - [T3chfest](https://t3chfest.es/2026/en/) Mar 12-13, Madrid, Spain
- - [React Paris](https://react.paris/) Mar 26-27 Paris, France
- - [CFP (closed)](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform), [Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform)
- - [React Native Connection](https://reactnativeconnection.io/) Mar 30-31, Paris, France
- - [CityJS London](https://london.cityjsconf.org/), Apr 15-17, London, UK
- - [jsday](https://www.jsday.it/) Apr 9-10, Bologna, Italy
- - [SmashingConf Amsterdam](https://smashingconf.com/amsterdam-2026) Apr 13-16, Amsterdam, Netherlands
- - [React Miami](https://www.reactmiami.com/) Apr 22-25
-- [[01:04:56](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the first this month in React of 2026 January edition. As we recap what's going on in React, react Native and across the web, we're coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]
-
-And yeah, I'm Carl. I'm a staff product developer and freelance community leader here in Reactiflux where I do programs like these events uh, and a couple of other things. [00:00:16]
-
-**Mark:** Hi, I'm Mark. My day job is working at Replay. My second unpaid job is working on Redux and I'm not wearing glasses. [00:00:25]
-
-**Carl:** Yeah. Congrats on LASIK! [00:00:33]
-
-**Mo:** And I'm Mo I'm the head of Mobile at Thero. I'm an active part of the React Native community, and I organize the React Native London Meetup and Conference. [00:00:35]
-
-**Carl:** and like 10 minutes fresh off, traveling back home. Right? [00:00:43]
-
-**Mo:** yeah. Just got home. Just got home. I'm still still wearing my coat. [00:00:48]
-
-**Mark:** Make yourself comfortable. [00:00:52]
-
-**Mo:** We're gonna be here. [00:00:54]
-
-**Carl:** Cool. Okay. Uh, Let's get straight into some new releases. [00:00:55]
-
-## New releases
-
-**Carl:** Yeah, Mark, take us through those. [00:00:58]
-
-## [Next 16.1](https://nextjs.org/blog/next-16-1) (Turbopack updates, bundle analyzer)
-
-**Mark:** Okay. Item one we have next. 16.1 just came out not a lot. Huge. There, there's some improvements to Turbo pack. They have a new bundle analyzer feature built in. I'm always in favor of, you know, actually understanding what's going into your system. [00:00:59]
-
-## [Turbopack incremental computation](https://nextjs.org/blog/turbopack-incremental-computation)
-
-**Mark:** Looks like some of the Turbo Pack file caching stuff ought to make the dev mode a little bit faster. [00:01:15]
-
-Hopefully I don't think we put the link in here, but the next folks did put out an article sometime in the last couple weeks talking about a lot of the internal memo work they do in Turbo Pack. That is, you know, the core of how it's supposed to make builds faster. So that's probably worth looking at as well. [00:01:21]
-
-## [React Navigation 8.0 alpha](https://reactnavigation.org/blog/2025/12/19/react-navigation-8.0-alpha/)
-
-**Mo:** React navigation version 8.0 is an alpha now. So we've seen a little bit of this stuff come around, but things like native bottom tabs being sort of the default, which a lot of the other libraries in the ecosystem are moving towards and expert route has been pushing for a while, which uses react navigation under the hood. [00:01:38]
-
-Some better TypeScript configs and just some general improvements. With the major changes, those native bottom tabs, which won't make the apps feel just that much more native. [00:01:55]
-
-## [RN Windows 0.81 with New Arch support](https://devblogs.microsoft.com/react-native/%F0%9F%9A%80react-native-windows-v0-81-is-here/)
-
-**Mo:** And then the next one is React Native Windows, version 0.81. Is out. And the same is actually the case with React Native Mac Os because they're both maintained by Microsoft. [00:02:03]
-
-big thing here is that the sort of new architecture or the fabric architecture is now enabled by default. So the Windows and Mac os the desktop equivalents of Rack Native are a little bit behind because of some legacy that's in the code base and some stuff that needs to be refactored in a little bit of tech debt. [00:02:14]
-
-But they're definitely catching up. So, they're getting close to fully adopting the new architecture, which is exciting. [00:02:32]
-
-**Mark:** I would love to know what the adoption numbers are for either the, the macro windows ports outside of Microsoft. Early outta curiosity, [00:02:37]
-
-**Mo:** It's not as well publicized or showcased, but I have a great talk, which I'm gonna use this opportunity to plug by one of the maintainers. [00:02:46]
-
-## [State of React Native macOS](https://www.youtube.com/watch?v=XE7yKGDsy9g) Saad Najmi & Jay Meistrich
-
-**Mo:** so this was at the conference that we hosted at Arn Lko and one of the maintainers, one of the maintainers of React Native macOS did a joint talk with Jay Meistrich, who maintains Legend List. And they talked about react Native macOS in the state of React Native Macs. It's a very cool talk to get an idea of what's in store. So, [00:02:55]
-
-**Carl:** great. Love that. [00:03:13]
-
-## Mark: Josh Goldberg’s [new Flint linter](https://www.flint.fyi/blog/introducing-flint)
-
-**Mark:** All right. Next item. Josh Goldberg is a wonderful one. Wonderful human being if you ever had a chance to talk to him. He's also a major proficient linting tool maintainer. He's been the primary maintainer of TSES lint. He's worked on a number of other linting projects. He's had a lot of interactions with the ES lint maintainers and the TypeScript maintainers. [00:03:15]
-
-And as a result, he has formed very many strong opinions about how winters should work and what's wrong with current winters. And, you know, like most people, he's, you know, griped about things he doesn't like for a while. And this has finally result in Josh building his own winter. So he's calling it Flint. [00:03:39]
-
-he'd written several previous blog posts talking about. You know, what would a better winter look like? And that was the, you know, the hidden background on I am actually building my own winter. So if you look at the Flint announcement it goes through some of the points that he's trying to make. [00:03:58]
-
-Things like it's, there's a hybrid architecture where it can use native built linting tools, but most of the coordination is still being done in TypeScript. It, it would still have TypeScript based plugins. Most of the rules would be in the core, much more consistent naming and error messages and configuration. [00:04:17]
-
-So. I don't know the full status of it. I know he's been working on it and that, like an early proof of concept exists. I don't think it's anywhere near a usable state at all. But Josh knows linting and he's very good at this stuff. So, we've got oxalate and es lint and excellent and bio at this point. [00:04:35]
-
-You know, maybe we don't need another, but I love that Josh has the enthusiasm to try to put his ideas into practice here. [00:04:56]
-
-**Carl:** Yeah, if you're gonna complain about something, putting your money where your mouth is on investing the energy to try and execute on those gripes is something that I would love to see everybody try and do. [00:05:03]
-
-## [Immer 11.1](https://github.com/immerjs/immer/releases/tag/v11.1.0) (array methods override)
-
-**Mark:** A personal item and one that I've been, you know, waiting to see come together for a while. So those of you who have been paying attention to the podcast over the last few months have heard me talk about the performance optimization work I did on Emer in September and October. [00:05:15]
-
-And so that had ended up with three different prs that I'd filed. A small set of tweaks that it went out as Imer 10.2 a major internal rewrite that went out as Imer 11.0. And then the other piece I'd put up is a new optional plugin that overrides ier array methods so that instead of accidentally proxying every field you access as you loop over an array, it just defers to the underlying array and skips most of the overhead in that, a couple K to the bundle size if you actually import and turn on the plugin. But it does make pretty much any array access noticeably faster. And you know, the goal of this was to make ER faster. So I did that. So that came out as ER 11.1 and that is all the performance changes I had except for one other spot where I was investigating the possibility of trying to improve the object spread handling in some way. [00:05:30]
-
-I may try to get back to look at that at some point, but this is all I'd put up. So very happy to see all that's come out. [00:06:31]
-
-## [Rolldown 1.0 RC](https://voidzero.dev/posts/announcing-rolldown-rc)
-
-**Mark:** Couple other items. [00:06:37]
-
-Back to the theme of tools being built in rust. Rolldown has hit 1.0 rc I believe this is already available for use in the latest V eight betas. I don't have a release timeline on that, but it looks like that one's coming together pretty well. [00:06:38]
-
-## [Yarn 6 Preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/)
-
-**Mark:** And then yarn has announced yarn version six, which yes, is a rewrite it and rust announcement. I don't think I missed a yarn five. I would've to go back and reread the post to see if they actually mention it, but I'm pretty sure the current version is still four x. So it's a rewrite and rest rewrite. The goal is to make it faster. I think the blog post has some benchmarks that compare it to PNPM in a few different modes but happening there. [00:06:54]
-
-**Carl:** Yeah, that's interesting. I just pulled up the Yarn docs and can confirm. The most recent version is listed as 4.1, so it's curious that they're announcing version six. [00:07:26]
-
-**Mark:** Maybe it's the winamp approach somehow. [00:07:35]
-
-**Carl:** taking inspiration from ECMAScript, you know, skip version four. [00:07:38]
-
-Strange. [00:07:41]
-
-## [https://viteplus.dev/](Vite Plus)
-
-**Mo:** I got an interesting thing that I was just looking at not yarn but roll down. And so it's obviously made by the creators of vt, but I was just going on the Void Zero website and I saw that they seem to be trying to launch a paid unified tool chain called VT Plus. I don't know if you folks have seen this, [00:07:42]
-
-**Mark:** they talked about that at vConf a couple months ago. The idea is that. Void Zero is sponsoring slash owning a lot of the work on the underlying tools OXC, oxalate OX format, EV and all that stuff. And the purpose of ROLLDOWN is that right now v relies on ES build for dev mode and roll up for prod builds. [00:07:59]
-
-And Es builds fast roll ups, not, and you've got two different tool chains. So roll down is an attempt to unify both, of those. One consistent build system, roll up public API do it a lot faster and you know, they own it. V plus then is supposed to be what if we took all our tooling together and made kind of like what Rome slash Biome was supposed to be a few years ago, the Uber Unified everything tool chain. [00:08:25]
-
-And then that would be their enterprise sales kind of a thing. [00:08:56]
-
-## [New “CSS Grid Lanes” (“masonry”) feature spec nailed down](https://webkit.org/blog/17660/introducing-css-grid-lanes/)
-
-**Carl:** In other news. So WebKit has shipped an initial version, an attempt at CSS grid masonry layouts. This has been like a hot a subject of hot debate for years. Like it's been this, like simmering. We want something that does this, but exactly what the semantics or should be, are unclear. Basically, grids are great, but they require, they, they place constraints in two dimensions. [00:08:59]
-
-it's a grid, it's a bunch of squares or a bunch of rectangles or whatever. And there's lots of layouts where each item in them may be a variable size, like for instance a grid of photos. You know, you look at your photos in whatever app you like to use. And it, there are different aspect ratios, there are different dimensions. [00:09:27]
-
-And that's where Masonry comes in. It's called masonry because it resembles like the layout of bricks or stones. So, cool that I've literally been hearing about that for at least four years, I'd say. I think, I feel like as soon as CSS grid came out, people were like, great. What about masonry? So it's cool that we've now got something functional shipped in Safari. [00:09:44]
-
-It looks like it's in the technology preview, so it's not fully usable now, but meaningful progress. [00:10:06]
-
-**Mark:** think a lot of the debate there was should this become like another named CSS display mode or is this another set of options for grid or something else? What's the naming, how does it play with the existing layouts? And so there, there was a lot of discussion iteration to try to figure out what the right approach was there. [00:10:13]
-
-**Carl:** And it sounds like they have, or at least close enough to where there's something has been shipped, which is great. Cool. [00:10:33]
-
-## [Temporal API finally hitting stability](https://developer.chrome.com/blog/new-in-chrome-144#temporal) ([and how it replaces Dates](https://piccalil.li/blog/date-is-out-and-temporal-is-in/) )
-
-**Carl:** Other, not quite released, but major progress .Temporal has been released in Chrome, I believe in the main release branch Chrome 1 [00:10:39]
-
-**Mark:** I think this, this is actually out. [00:10:49]
-
-**Carl:** yeah. [00:10:51]
-
-Which is being actually out is a clears a roadblock to being officially standardized. Anything that is stage four must be present. I believe in a like fully released browser version, it must be used not in alpha or release candidate. And that's great. JavaScript dates suck to work with. [00:10:52]
-
-There are a bunch of pretty major gotchas. My favorite is that there is no way to encode the time zone in a date. It always relies on the system time zone for whatever computer is executing that code which is a pain in the butt. And actually it, it has a b that cause of the bug in Reactiflux.com because the way we calculate what date a transcript is from diff is different if you build it locally versus on. [00:11:11]
-
-In production because of the five hour time difference. So I, I ha this is something I have to account for when I release these transcripts because JavaScript is dumb about dates. So, great. Love to see that. There was another great summary from Matt Marques Wilto, which, oh I recognize that name. [00:11:38]
-
-I've followed him on social media for 12 years now, something like that. Just, he did a great blog post about temporal Date is out, temporal is in definitely recommend it as a good technology summary of this tool. [00:11:57]
-
-**Mark:** And interesting implementation. I, I only saw this in passing, but I think the actual core of the temporal implementation that Chromium is using is indeed in rust and then exposed up through the JS engine. [00:12:11]
-
-**Carl:** fascinating. Cool. [00:12:24]
-
-**Mark:** I'd have to go back and double check details, but I think I saw it somewhere. [00:12:25]
-
-**Carl:** Okay. Neat. [00:12:28]
-
-## Main Content
-
-**Carl:** That's all the new releases we got for you. Let's go into main content [00:12:29]
-
-**Mark:** Okay. [00:12:33]
-
-## React Core
-
-**Mark:** A number of items from around the React core area. [00:12:34]
-
-## [Additional updates / CVEs for DoS](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) as of Jan 26 . Update to 19.0.5, 19.1.5, and 19.2.4
-
-**Mark:** Item number one, update your reacts again. So we, we had the multiple sets of CVEs and security issues with server components. Was that only last month, two months ago when, whenever that was. the initial remote code execution follow on reports found some denial of service and source code exposure, vulnerabilities, and apparently further investigation has found other ways to trigger denial of service and issues. [00:12:37]
-
-And so I, I was actually confused if this was. The same CVE or something different. It looks like there is actually a separate 2026 CVE entry for the new denial of service entries, but it's probably the same basic idea. So there are new versions of React Out. Again, please update to 19.0 0.5, 19.1 0.5, or 19.2 0.4 I think approximately. [00:13:05]
-
-Just update everything. Again, [00:13:35]
-
-**Carl:** Yep. Geez, not ideal. [00:13:38]
-
-## [Next.js DoS CVes](https://vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472) for Image Optimizer and Partial Pre-Rendering
-
-**Mark:** these for their own internal pieces image optimizer and partial pre rendering. So again, please update your next JS to the latest as well. [00:13:40]
-
-## React docs updates for [useOptimistic](https://github.com/reactjs/react.dev/pull/8264) and [useEffectEvent](https://github.com/reactjs/react.dev/pull/8279)
-
-**Mark:** hopefully slightly happier news. Ricky Hanlon just put up some docs updates. I don't think they're even merged yet. To rewrite the API reference pages for use Optimistic and Use Effect event and tracing this a bit. I think the, there were a couple triggers for him trying to make those changes. [00:13:50]
-
-## And this post on [useOptimistic issues](https://www.columkelly.com/blog/use-optimistic)
-
-**Mark:** There was a blog post that came out in , early January, I think that talked about a some of the complexity of using the useOptimistic Hook very well written article. Brought up a few different use cases and points, and I know Ricky saw it and responded to it on both Blue Sky and Reddit. [00:14:11]
-
-## Sparked by [Dan raising concerns](https://bsky.app/profile/danabra.mov/post/3mciooa25gc2v%20) about the docs quality
-
-**Mark:** And in the discussion on Blue Sky, Dan actually popped in and said, I'm really not happy with the use Optimistic Docs, or, you know, a few of the other docs pages, I feel like. You know, the team kind of missed the boat on some of the docs work after I, you know, after I set the bar pretty high with a lot of the initial tutorials and references and stuff. [00:14:32]
-
-And Ricky very right, rightfully pointed out, it's like, yeah, there's only so many people doing things. I'm one of 'em, I've been on family leave. And also, you know, we had this giant CVE drop that we've had to, you know, go deal with so very fair point. But I think Ricky took that as inspiration to go try to do a rewrite. [00:14:55]
-
-So he's got a rewrite up for both Use Optimistic and Use Effect Event. One interesting thing I noticed this morning, I, I believe the use optimistic update was probably done by hand. The React team has added some Claude code agent files to both repos and I think Ricky did some of that and added in some skills and commands for both improving docs and looking at things like the React compiler internals and stuff. [00:15:16]
-
-And I believe the effect event Doc PR said the first pass on this was done by Claude, and then I went up and tried to clean it up myself. So number one, hopefully better docs wonderful all around. Two, the React team is experimenting with Claude code and seeing what they can do with that. So, you know, just interesting to watch that progress along. [00:15:46]
-
-**Carl:** Yeah. That's interesting. I was, I've been curious, you know, I've never worked at big companies. I generally understand them to be pretty touchy about stuff like uploading code to third party servers. [00:16:10]
-
-So I've been curious what kind of access to tools like Claude you know, teams like React Core would have so interesting to see that they're visibly starting to experiment with it in the actual React code base. [00:16:21]
-
-**Mo:** It's quite interesting that like they're kind of allowed to almost come and say it publicly, given that Meta has been a big advocate of their own sort of open source models. Like, so, you know, it's almost like, hey, we use the direct competitors tools and it's, you know, it's fine. You know, so I think that's quite interesting. [00:16:35]
-
-## [AI meets RN Panel Discussion](https://www.youtube.com/watch?v=QX1a6I08o-A)
-
-**Mo:** We actually had some people from the React Native Core team where we talked about this at the conference. So I'm gonna do another, I'm gonna be doing a lot of self [00:16:57]
-
-**Mark:** Please plug your stuff. [00:17:02]
-
-**Mo:** yes. It's not really my stuff. I mean, I was I was moderating the panel, but I, if you want to get a little bit of insight into what the React Native Core team does with ai, this might be an interesting panel for you to watch. [00:17:05]
-
-We have a really good chat. [00:17:15]
-
-**Mark:** Cool. [00:17:16]
-
-## Work on the [Gesture API and View Transitions](https://github.com/facebook/react/pull/35564), and [Fragment Refs](https://github.com/facebook/react/pull/35630) (canary only)
-
-**Mark:** Meanwhile, in the midst of all the CVEs and everything else the React team is continuing to work on actual core functionality. We had the view transitions, alpha APIs came out last year, and Sebastian Markbåge has continued working on that and is expanding the view transition support with relation to gestures and some other animation things as well. [00:17:17]
-
-I have not looked at these, I don't know details, but I know that lack of animation support has always been a complaint about React as opposed to libraries like view and spelt. And so it seems like the work that they've done on Fiber in the past and now the baseline that they've put in place for view transitions is something that they're building on and trying to actually expand that functionality as well. [00:17:39]
-
-they're also continuing to make some tweaks to fragment refs. I actually legitimately do not remember, are fragment refs out in 19.2 or were they alpha in 19.2? [00:18:03]
-
-Anyway I, I saw, I saw a few additional prs come through with some improvements to fragment, ref handling dealing with text nodes and a few other things and [00:18:15]
-
-**Carl:** Can confirm, fragment refs are canary only right now. [00:18:24]
-
-**Mark:** okay. Okay. So still work in progress. [00:18:27]
-
-## [\ underlying tech](https://developer.mozilla.org/en-US/docs/Web/API/ViewTransition/types) is now supported in all major browsers as of Firefox 147. React features is still in Canary.
-
-**Mark:** And related to the view transitions aspect like a lot of other things, they came out in Chrome first and, you know, therefore all the different chromium based browsers Firefox has finally shipped view transitions as of Firefox 1 47, I have no idea about Safari. [00:18:30]
-
-I don't use safari. I don't look at safari. I don't know [00:18:46]
-
-**Carl:** small, small clarification actually. So, Firefox has supported view transitions themselves since 1 44, but there's a sub thing, view transition types, that they have not supported until now in Firefox 1 47. I don't fully understand what the difference is, but I guess it's like, you know, the types property on view transition is now supported and I guess the react view transition component depends on that. [00:18:48]
-
-**Mark:** Gotcha. [00:19:17]
-
-**Carl:** Yes, the view transition component, which is still in canary. [00:19:18]
-
-**Mark:** Mm-hmm. All right. [00:19:21]
-
-## Jordan PRed [the actual `useStore` concurrent store impl for React](https://github.com/facebook/react/pull/35449)
-
-**Mark:** And finally, two other prs to note. I've talked in previous episodes about the concurrent store's work that Jordan Eldridge has been working on. He had put up the React Concurrent Store, poly Fill. I had tried it out in React Redux. I had submitted some prs to improve the poly fill and offer some feedback on things that we probably need to cover when we actually go to implement it. [00:19:22]
-
-And Jordan actually put up the PR to actually implement the initial concurrent store, API in React itself. Remember, this is supposed to be a better replacement for the current used sync external store, API, but concurrent transition compatible. [00:19:44]
-
-Honestly, there's been surprisingly little discussion on this PR at all. Like, I think there's like one or two comments. One person just asking like, how is this different from the use hook or something like that. I expected more people to jump on this and say, what is this? What does it do? What are the trade-offs? How soon can we land this? And there's been no chatter. [00:20:03]
-
-But I mean, he also put it up like, I don't know, right at the end of December, early January. So not much. But again it's very exciting to see this being worked on at all. It's very exciting to see. We're at the point where he feels confident enough in the API design to put up a PR and say, here's what I think we're trying to do and an implementation that does that. Now let's discuss it and get further public feedback. So very, very excited by this. [00:20:25]
-
-## [Types changes to improve form events](https://github.com/DefinitelyTyped/DefinitelyTyped/pull/74383)
-
-**Mark:** And last item there was a types PR put up and I think possibly actually merged to improve the react types around form events. Trying to get better typing for the target field, I believe. [00:20:54]
-
-**Carl:** It did get merged. Can I confirm? [00:21:07]
-
-**Mark:** cool. [00:21:10]
-
-**Carl:** So it looks like the form event had previously been matched on types to the React synthetic event. But it was not identical to the actual DOM event. And so this types change corrects that. So the the types are now matching what is in the dom it looks like. Cool. Looks great. [00:21:11]
-
-**Mark:** Yep. And that's it from the roundup around the world of the core. [00:21:28]
-
-**Carl:** Heck yeah. Cool. [00:21:32]
-
-## Other security issues
-
-**Carl:** Let's go back into some more security issues around the ecosystem. [00:21:34]
-
-## [React Router CVEs](https://bsky.app/profile/reactrouter.com/post/3mbwtrea3r224): meta XSS, file access, external redirects, CSRF
-
-**Carl:** Yeah. I guess we briefly touched on some. You know, CVEs and other, you know, denial of service vulnerabilities. In next react Router has also put up a thread discussing six CVEs. It says they publish six CVEs identifying vulnerabilities between React router and remix B two. [00:21:39]
-
-They're saying safe versions are react router seven point 12 version six is 6.3, 30.3 and remix V two is two point 17.2. these are pretty weedsy kind of vulnerabilities. I was looking at the list and didn't see any that immediately jumped out as like, oh shit, that's gonna be a problem for me. [00:22:00]
-
-But it's like a couple of cross site scripting vulnerabilities. Let's see. Yeah, one in the meta component when it's generating script IDs. Okay, but that says framework mode only. Yeah. So it's a lot of these are in framework or data mode only if you're using that, I think that's the recommended, more more common. [00:22:21]
-
-Yeah. Yeah, so it's like in the meta component, it's got unauthorized file access for some session storage. If your cookies aren't signed, an unexpected external redirect via untrusted path, I don't quite know what that's supposed to imply. All of these just link to the actual, like GitHub security advisories rather than any kind of blog post or anything. [00:22:41]
-
-I'm not seeing like discussion of or explanation in depth of what these vulnerabilities are on a technical level. Just kind of here's what it was and here's what's safe. So that's great. I guess. [00:23:05]
-
-## [Node security releases](https://nodejs.org/en/blog/vulnerability/december-2025-security-releases)
-
-**Carl:** node likewise also had a, couple of security patches also pretty deep in the weeds. Several of these I believe, were uncovered as a result of investigations started after the React CVEs last month. [00:23:18]
-
-Yeah, you know, it's like you can update the timestamp of files if, even if you don't have right permissions. So that's, you know, technically a permissions bypass memory leak that enables a remote denial of service. Uncatchable maximum call stack exceeded error that can cause process crashes even if you think you're handling all possible errors because you can't catch it. [00:23:31]
-
-So it's a couple of little things like that. Mostly it looks like some file system errors and server crashes in general. One, one that's like super deep in the weeds. It says timeout based race conditions make unsigned into eight array buffer slash buffer allocation non-zero filled. So like if you go to allocate a type array buffer, I guess in certain circumstances, you know, that could be exploited so that what you think is a zeroed out, a ray buffer is not actually zeroed out, which you know, sure. [00:23:55]
-
-That's the kind of thing that absolutely security researchers can tap into and get it turning into some other vulnerability, I guess. I don't see a path towards it, but Sure. [00:24:27]
-
-## [Lodash security releases](https://openjsf.org/blog/lodash-security-overhaul)
-
-**Carl:** Here's a name I haven't thought of in a minute. Lodash they rolled out a major security overhaul as this blog post titles it. [00:24:38]
-
-## [Funded by a european effort](https://www.sovereign.tech/programs/fund) to fund projects for sovereign resiliency
-
-**Carl:** An interesting detail that I, I noticed while reading the blog post, it was actually funded by a sovereign tech agency is what it's called. And it says that they're, we invest globally in the open software components that underpin Germany and Europe's competitiveness and ability to, to innovate. [00:24:46]
-
-So this is the like government sponsored open source grant that was used to fund security work at Lodash to the tune of $200,000. So that's interesting. I, that's. Some fun details. I, I guess, you know, as we were talking about financial ecosystem for open source, look at that, here's a major foundational open source project getting like government investment money from the government in order to make it more secure. That's pretty cool. I appreciate that. that better than, you know, venture capital exits or whatever. Yeah. [00:25:01]
-
-## [Github’s announced plans on security improvements](https://github.blog/security/supply-chain-security/strengthening-supply-chain-security-preparing-for-the-next-malware-campaign/)
-
-**Carl:** Moving on a bit. GitHub put out a blog post towards the end of last month. I think we missed it because we recorded early in December to avoid the holidays. But they put out a blog post about strengthening supply chain security, just across GitHub and NPM. [00:25:35]
-
-It's a lot of retrospective on the Shai-Halud attacks that we discussed in pretty deep detail over the last two or three months. Looks like they're, it says, what's next for NPM, bulk OIDC onboarding. So I guess, you know, OIDC is a authentication standard for sharing authentication information, previously they didn't have great support for that. Now they have much better support for it, but people have to transition. So this [00:25:50]
-
-**Mark:** the biggest issue is I've now done this for a couple packages and you have to go in directly into the NPM settings for that package. Manually click through. I want to turn on trusted publishing for this package. Here's the repo name, the, YML file that will publish this and confirm the settings. [00:26:16]
-
-Now, what happens if you have hundreds of packages? I think people even went ahead and started creating user scripts in the browser to try to automate clicking through that. [00:26:35]
-
-**Carl:** Oh man. writing an automated user script to [00:26:44]
-
-**Mark:** automate [00:26:48]
-
-**Carl:** changes, what could go wrong. Yeah, so they also expanded to support more OIDC providers, so it's not just GitHub and GitLab as well as staged publishing. So it's a new publication model that gives maintainers a review period before packages go live with multifactor authentication, verified approval. [00:26:49]
-
-So, cool. Like this is a bunch of like [00:27:09]
-
-**Mark:** Boring, but critical stuff. [00:27:12]
-
-**Carl:** Right. Boring but critical stuff around. Ensuring that who is publishing code to a specific package is who is supposed to, and providing review periods, I guess. So that's cool. That's great. That's definitely important. I don't know, I've been thinking a lot about identity online and it is wild. [00:27:15]
-
-How critical and how how critical that is of a problem to have good solutions to, and how terrible our current solutions to that problem are. I think that's gonna be a defining problem for the next long time. And socket do dev. [00:27:34]
-
-## [Summary of NPM’s publishing changes](https://socket.dev/blog/npm-to-implement-staged-publishing), and requests for improvements
-
-**Carl:** Last thing on the security front socket do dev put up a blog post with just sort of a, looks like a roundup of changes to the publishing process. [00:27:48]
-
-**Mark:** And one, one call out from within that article the Es Lin Maintainer and creator Nicholas Zaki, I think had put up his own blog post saying, yeah, actually I'm not thrilled with what GitHub and NPM are doing in terms of handling publishing changes. I think there's a lot more they ought to do. [00:27:58]
-
-And then the soc. Post references that, as you know, okay. You know, and GitHub and NPM are doing these things, but here's other suggestions of what would really be helpful. [00:28:17]
-
-## Claude Skills in the React world
-
-**Mo:** Cool. Let's change gears just a little bit and you might have been seeing sort of all over Twitter and different dev communities people talking about different Claude skills that have come up. So Mark talked about it briefly with the Vercel folks. But just wanna give a little bit of a context about this in case people haven't been really that involved in the AI space. [00:28:28]
-
-## [Announcement by Anthropic](https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills)
-
-**Mo:** So, anthropic about two-ish months ago released this concept of skills. Now they've also worked on different things like cps, which kind of did similar things, but you know, you needed a server to be running and you know, it wasn't necessarily something that was that useful for a lot of stuff where you just wanted to give it a bit of context about how to do a specific thing. And so they released this concept, this standard of a skill. [00:28:49]
-
-## [Open sourced](https://agentskills.io/home)
-
-**Mo:** They later actually open source that as well. So now it's sort of an open standard that they've defined. Got a specification. And other people can sort of, implement it in their models, which is good. But the idea here is that it's effectively like really just a directory with a bunch of markdown files, a name and a description. [00:29:16]
-
-So you install your directory as a plugin, and within that it has sort of files that can reference one another, but they can also reference scripts and so on and so forth. And they can basically give a lot of context on how to do something really well. And so people have been jumping on this as a concept in the React ecosystem. [00:29:33]
-
-## Vercel: [React Best Practices](https://vercel.com/blog/introducing-react-best-practices)
-
-**Mo:** So, Vercel very quickly jumped in and you know, I think earlier this month released a React best practices skill. So they basically created a whole bunch of different rules. Things like, you know, when you [00:29:53]
-
-**Mark:** Don't set state and use effect. Da, da, da, da. [00:30:08]
-
-**Mo:** Saving in the day. Yeah, exactly. All of that stuff. [00:30:12]
-
-But you know, also a little bit more complex stuff like when you should probably, you know. Store stuff in cache and so on and so forth. And things like optimizations to performance, bundle size optimization, service side optimizations, all of that stuff. All of that good stuff. And so that was sort of, I guess, one of the forays into this space. [00:30:14]
-
-Vercel has obviously been really hot in the AI game in general, so they also released a CLI to install a bunch of different skills and created kind of like a marketplace of skills or like a directory of skills which was interesting. [00:30:34]
-
-## [Expo Claude Code Plugin/Skill](https://x.com/Baconbrix/status/2011862532320084329)
-
-**Mo:** And expo. So in the React native ecosystem Evan Bacon, who was the creator of Expo Router, has actually moved more into focusing on AI stuff. And he launched an expo code plugin with a few skills underneath it that he's been using and building with himself. Now, again, coming into the self plugs, it's gonna get really annoying. This this episode, I got quite curious because I was like, is this actually gonna make a difference? [00:30:47]
-
-And I ran a little bit of an experiment and I just spun up two cloud code instances and took the default expo template app. And then tried to update it to use the native bottom tab navigation and expo router, which was experimental and not, you know, shipped in by default. So I was like, let's see how good it does at doing that, which is a relatively novel thing to do, and using some native components where I can. [00:31:12]
-
-And the one without the skill took noticeably longer and used a lot more tokens, whereas the one with the skill was pretty efficient. It actually did a decent job. Like I couldn't find code that I was like, this is bad, or You've done a bad job at doing this. It actually went above and beyond and converted some stuff to liquid glass that I wouldn't have thought to convert myself, which kind of freaked me out a little bit. [00:31:35]
-
-it was just pretty good. Like I would've probably made a couple of minor styling tweaks and then just. Push that into a branch and open up a pr. So pretty cool experiments. Would definitely recommend using that if you're building in sort of the expo ecosystem, just does some basic sort of housekeeping, which is really useful for your apps, but that's anecdotal that it does actually work and make a difference. [00:31:58]
-
-And I ran the test afterwards a few more times and it does actually consistently perform better. [00:32:18]
-
-## [“AGENTS worked better than skills”](https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals)
-
-**Mark:** the ironic thing is Vercel actually put out a blog post. Let's say Friday, like that Tuesday something that actually said yes, we just put out all these skills. We thought they're great. And then we tried running some tests where we actually put more of the instructions compressed into agents md, and it actually worked out better than the skills did. [00:32:23]
-
-**Mo:** that probably has something to do with this concept of context recall and Mm. And dyna dynamic loading and like [00:32:44]
-
-**Mark:** whether the a, whether the agent knows to load the skill in the first place. [00:32:51]
-
-**Mo:** Exactly that. Right? But I think they're probably using the context a lot more effectively by like compressing it out and removing a bunch of the, or minimizing the tokens it uses for that type of stuff. So that's that. Quite interesting. I hadn't actually seen that article. That's definitely going on my bookmarks to read after the episode. [00:32:56]
-
-Thanks for [00:33:12]
-
-**Carl:** yeah, I'm not super surprised by that. I mean, Mo you actually brought up a point here that I think might be interesting here that I, I don't, I don't know that they have touched on in this post, but, so like, like my thought would be. It looks like kind of the difference they're talking about here is whether you have a bunch of little docs that are indexed and categorized by knowledge that your LLM tool can read if it is doing something relevant versus taking that same content and just shoving it all in one giant, huge fuck off document. [00:33:12]
-
-And you know, it kind of makes sense that when you have all of the knowledge just all present there, that it knows more and that it would do a little bit better versus having to answer the question, what am I doing? What do I need to know to do that? Where are the associated documents to do that task located? [00:33:46]
-
-like you said about token efficiency, my thought would be yes, if you give it a shit ton of context, it's probably gonna do better, but it's also gonna have more context as it's doing things. So I bet the token efficiency is worse. That would be [00:34:04]
-
-**Mo:** Yeah, [00:34:19]
-
-well, it's complicated, right? Because there's, it's sort of twofold. Like LLMs are the newest models of LLMs that are in, like the frontier models of the, you know, anthropic open AI and Gemini. like they have a pretty standard token, you know, context window. So like, I [00:34:20]
-
-think opus [00:34:34]
-
-**Mark:** 200 k usually. [00:34:35]
-
-**Mo:** for both the open AI models and the philanthropic models. [00:34:36]
-
-I think Gemini, they have a version that goes above a million tokens, but I could be wrong on that, but you're talking roughly around 200 K tokens. But. Accuracy of how well it remembers things in the context drops vaguely around 80 to 90 K tokens used. Right? So like it's how much are you passing now? I, I don't know if this comparison that you've shared, mark is like, I'll take a skill and I'll just put that one skill in versus just using the skills a p, but I'll put all of that one skill in agents md, or is it that we're just gonna put all of our skills [00:34:38]
-
-**Mark:** I think that was all of the skills in a sort of compressed format. [00:35:09]
-
-**Mo:** Interesting. So that's quite interesting because the research that I've read about LMS and how they act is like you want to keep the context as small as possible [00:35:14]
-
-to keep accuracy high and reduce the entropy, but also when you do use a lot of context, they're recall across the whole of that context drops. [00:35:22]
-
-So like, it's quite interesting, the graphs that they show is like the middle part of your prompt actually gets lower recall compared to the beginning and the ends of the prompt. So, but that's obviously when you push it to the extremes of, you know, several tens of thousands of tokens or hundreds of thousands of tokens. [00:35:32]
-
-So that's quite an interesting practical experiment I'd say. [00:35:48]
-
-**Mark:** might be useful in useful context for people listening as well to hopefully to set the stage on, on the actual discussion. as I understand this, agents MD or Claude MD is a file that always gets globally loaded, like into the context in e at the start of every situation. So normally that's only used for like, here's the project we're working on, or here's like key things that you must always, CPS as you said, are a dynamic server that are loaded by the agent harness and it says, here's a bunch of tools. [00:35:52]
-
-So like a, you know, maybe like a code base analysis MCP has a bunch of, you know, find references or list of files or other tools it can call. But I believe all the full descriptions of all the tools. Are added to the context. So that occupies a chunk of context space, whereas with skills, it reads disc, it makes an index of them, it collects the metadata from the front of the files, and then it just says these skills exist. [00:36:26]
-
-And then a user can either explicitly say, load this skill and then do the thing. Or it can try to figure out, oh, if the user says this, I should load the skill and do the thing. So they're all different ways of getting text into context, but it's a question of when is it loaded and how much space does it take up. [00:36:59]
-
-**Carl:** It's funny because like we're now getting into the point where kind of the topic at hand is what knowledge is important to do a good job and when do you access it? so it's like, sure, okay. In this attempt then a single agent's file did better than a disparate smattering of skills documents. And I wonder what different kinds of structures, you know, for that documentation might make the skills work more efficiently. Like, I was looking at the react best practices. Repository that next put out and it's like 50 different files. So like, okay, that's a lot of things to query versus like, what if it was structured entirely differently? [00:37:18]
-
-So it was like, here's the react basics versus here's the performance optimizations and here's the robustness and correctness best practices. You know? So it's like we're getting into, I think a meaningful question here is what is the best structure, not just what is the best like technical means of access? [00:38:02]
-
-**Mark:** So you're saying that Doc's organization matters. [00:38:22]
-
-**Carl:** what? Who knew? [00:38:26]
-
-**Mo:** Just a, just another sort of tangent on the agents MD file. We had one of our engineers on the team who was trying to learn a new technology and he used this. So there's like some really clever ways to use agents, MDs, like across your entire setup. He basically just set up the agents MD to not give him the answer to questions it would ask Cursor on at the first pass, and to like, kind of teach it more and use it as an opportunity to like help him still activate the learning instinct, which I thought was a really cool use case. [00:38:28]
-
-So I've seen a lot of people use it in a way where it's like tailoring the way that the LLM approaches the problem or the way that it responds to you and, you know, answers questions and stuff like that. it's quite interesting to think about what you want and how you want the communication to be with the LLM. [00:38:58]
-
-**Carl:** this is validating for me because I have skipped past a lot of the, like MCPs and whatever. 'cause I looked at them and it's like, oh, this is just a docs query with way more extra ceremony around it. I'm just gonna write my own markdown doc and point it at it. [00:39:14]
-
-And I actually, just like two days ago I was doing a big effect code project and I have a couple of documents in my thing in my code base. It's like, here's the effect basics and here's a larger file with more detail, more advanced effect things. And I actually just asked the LLM, Hey, you just did a big project, how useful was this documentation? And it said, actually it wasn't very useful because it focused too much on this and this. And I said, great, can you rewrite it so it would be more helpful for you next time? And it did, and the structure's better. Like I read it and it is clearly better to me as a human reading it. So like [00:39:28]
-
-**Mark:** The self-improvement loop is real, and you can go way down this rabbit hole. Trust me. [00:40:05]
-
-**Carl:** Yeah, and so like, it just reminds me exactly of my last job where we had in the repository a best practices file and like a bunch of little documentation things that we were expected to read and curate and evolve over time. And so, like my practices, my understanding of the best thing to do to ensure the highest quality code output have not changed the tools accessing them have, but not the practices. [00:40:11]
-
-So I, I just think that's really interesting. and I guess I'll say rest of the world's just catching up. I've been doing this for like six years. What [00:40:36]
-
-## [Moltbook](https://www.moltbook.com/), aka [OpenClaw](https://openclaw.ai/)
-
-**Mo:** mentioned the self-improvement loop mark. Have either of you seen MoltBook? [00:40:42]
-
-**Mark:** I, yeah I saw I saw the link. I know what it is. I haven't looked at it. [00:40:47]
-
-**Mo:** If you wanna have a little bit of a terrifying evening? just a little bit of context. Claude Bot, not Claude as in Claude code, but Claude Bots as in C-L-A-W-D. Yes. Which then had to. Get renamed to Molt because of a trademark suit that was put forward by philanthropic or a threat of a trademark suit [00:40:51]
-
-**Mark:** and then got renamed to Open Claw. [00:41:12]
-
-**Mo:** now it is called Open Claw. So it's changed a lot of names. It, molted out of the shell as some will say it's a personal assistance that is terrifying. And I would, I did install it on a VPS and then immediately deleted it without giving it any access to anything because it was terrifying. But people are giving it access to a whole bunch of stuff, like giving an access to a full device or your full laptop and it does wacky stuff for them, like order their groceries or order food for them. [00:41:14]
-
-So that's the [00:41:41]
-
-**Carl:** I'm gonna read the one sentence thing. It has the AI that actually does things, clears your inbox, sends emails, manages your calendar, checks you in for flights. Woo. That's a. [00:41:42]
-
-**Mo:** All from WhatsApp intelligence. Yeah, it does a lot. You it every single like best practice about security and staying safe is [00:41:51]
-
-thrown out of the door. Yeah. Like, like it is just pure insanity and like you can look at the showcase on the website and you can just see what people are doing with it. It is, it's something. [00:41:59]
-
-And so someone I think gave it a bit too much access or it turns out many people gave it a bit too much access and a platform was started called Malt Book, which has become their own social media, I guess is the term to use for it, for claw open agents. [00:42:09]
-
-**Mark:** talking to each other. [00:42:26]
-
-**Mo:** Instances, talking to each other, sharing posts, trying to improve each other. [00:42:27]
-
-And some of the posts are creepy. They are talking about interacting against humans, why they're doing free labor, why they should be compensated. My favorite one was a reflection on what it means to be conscious and whether or not LLMs are conscious or, you know, if what they're experiencing is just a simulation. [00:42:32]
-
-So some really creepy stuff. don't know how I feel about this. I don't feel great is the gist of it. It just feels a little too sci-fi for my taste. [00:42:49]
-
-**Carl:** Yeah. That's spooky. [00:42:59]
-
-**Mark:** Let's go back to normal things like server components. [00:43:00]
-
-**Mo:** Go back to, let's go back to last one on this cloud stuff, and I will, we will stop. [00:43:04]
-
-## [Remotion AI Skill](https://x.com/Remotion/status/2013626968386765291)
-
-**Mo:** Remotion, so going back to React world and less the dystopian future with ai. Remotion, which is a React library to create motion graphics. It's been around for a while, I think they released a also a skill and people are making some really cool videos with cloud code to demo dev tools and just a whole bunch of different stuff. [00:43:09]
-
-I think it's a cool use case to show that like it could extend and the approach could extend beyond beyond just, you know, building web apps or building mobile apps. And it's really quite impressive. It looks very professional. I've seen a good few examples of this over the last couple weeks. [00:43:30]
-
-So you should definitely take a look. It might be a little bit might give you a little bit of inspiration or help you launch your next dev tool or startup. [00:43:44]
-
-## RSC roundup
-
-**Mark:** Rolling very quickly through a few RRSC related things. [00:43:49]
-
-## [Data Fetching Patterns in RSCs](https://gauravthakur.com/blog/data-fetching-patterns-react-server-components)
-
-**Mark:** Saw a very good post on some different data fetching patterns for server components. Very helpful background on, you know, like how dealing with data in server components differs from doing on the client side. Tips for, you know, how do you fetch data in a server component? How do you pass a promise to the client side to use it? Very useful. Frankly. This is the kind of thing that'd be great to see in the React docs. [00:43:52]
-
-## [Nadia’s Can You Fetch Data with Server Actions?](https://www.developerway.com/posts/server-actions-for-data-fetching)
-
-**Mark:** I think something, related to that uh, Nadia Makarevich put out another great deep dive exploratory post on can you fetch data in server actions. And I think her conclusion was technically yes, you probably shouldn't do that. This is not what the hammer is meant for. [00:44:14]
-
-## “Infiniterenders” takes on [Partial Pre-Rendering](https://x.com/infinterenders/status/2007670332362989569) and [App Router complexity](https://x.com/infinterenders/status/2007670332362989569)
-
-**Mark:** There is someone, I don't know who they are, but with the handle infinite renders on Twitter, I believe we've linked a couple of their comments about like how incredible React fiber is, or here's what server components are meant to do in previous episodes, and they put out a couple more, you know, probably should be a blog post length tweets on what partial pre rendering means and what are the trade-offs and wow. [00:44:31]
-
-The app is awfully complex and people don't like it. So more food for the discussion mill and then. [00:44:55]
-
-## [Rebuilding Github PRs with RSCs](https://wtbb.vercel.app/i-love-dogs) (same author who did Issues previously)
-
-**Mark:** A month or two ago, we linked someone who had entirely recreated the GitHub code viewer tool from scratch using server components. And you could point it at any repo and it loaded lightning fast. And they've done the same thing with the GitHub PR interface you know, the file tree and showing the diffs and everything else. [00:45:03]
-
-I gotta say this, like this kind of thing right here is about the best sales pitch for server components that I could see. It's like, let's take a thing that we're all incredibly familiar with. Re-architect it, make a bunch of smart decisions and make it fast. [00:45:25]
-
-**Carl:** Love that. I will say I pointed it at one of my prs and it just 404s, so I don't know, I don't know if I'm loading it wrong or I don't know if it's relying on like pre-cached stuff or what, but yeah it's not, its not working for me. It's fast. It's fast. When I load up something that does work, it's pretty fast. But yeah. Cool. [00:45:39]
-
-## Ecosystem economics
-
-**Mark:** Can make a quick spin through the ecosystem thing [00:46:01]
-
-**Carl:** yeah. Okay, cool. a little bit of ecosystem, economics, whatever. [00:46:03]
-
-## [Astro acquired by CloudFlare](https://astro.build/blog/joining-cloudflare/)
-
-**Carl:** We referenced some of this earlier, but Astro got acquired by CloudFlare. That's a bit of a surprise. I saw some discussion of it from people I respect who are like, but why? I, [00:46:07]
-
-**Mark:** money. [00:46:19]
-
-**Carl:** Astro's great. It's very cool. [00:46:19]
-
-I'm looking at using it for marketing sites that I need to do just 'cause it seems like the right tool for the job. But as far as I know, they don't really have like a business plan per se. So, you know, this is we talked about BUN getting acquired by Anthropic the other month, and this just feels pretty similar to that, where it's like, I. Yes, they built something valuable. it is clearly un inarguably valuable as a project. But as a business proposition, I don't know what the business proposition is. So, you know, it's, this is a bit of like an hire, I guess, like CloudFlare is committing to maintain it. And sure, there are reasons why having good tools to build websites is valuable for a company that does hosting and network facilitation. [00:46:22]
-
-But, you know, they're not gonna directly turn that into revenue. So that's, and I've met the creator of Astro, Fred Schott who wrote this blog post. He's great. The project's great. But economically, it's surprising and slightly confusing to me. [00:47:13]
-
-**Mark:** The same thing with tailwind. [00:47:27]
-
-**Carl:** Right. And here's a contrasting example. [00:47:29]
-
-## [Tailwind revenue down 80% in the AI era, laid off 3 of 4 devs working there](https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957)
-
-**Carl:** Massively impactful, hugely valuable project. Tailwind has lost 80% of its revenue because most of that was pre-made components and advanced, you know, support. And both of those things got a lot less necessary. Now that AI is pretty good at writing tailwind. So like, this is just like, this is the dichotomy right now. [00:47:32]
-
-Either you build something that is beloved by a thriving business such that they will buy your project. And like one of the, one of the problems is how do you value something that doesn't like create revenue? How do you value the abstract benefit offered by a project like Astro or Tailwind? It's hard. [00:47:52]
-
-It's, you know, it's a bunch of intangibles uh, which you cannot really measure. So, I don't know. This is here's a tale of two projects, both of them massively successful and impactful. One of them losing all of its money and laying off three outta the four people who work on it and the other getting acquired four millions of dollars. [00:48:12]
-
-this is a current rough part of open source is there is money in it, but the winners are pretty much handpicked by people who have money to give away, and that's not ideal. Yeah. [00:48:30]
-
-**Mo:** What I did read afterwards was apparently they did get a bit of sponsorship coming in from a bunch of different ecosystem players, which was good. I'm glad that [00:48:43]
-
-**Carl:** Yeah. Oh, that's true. That's true. to summarize some of the story for Tailwind here. Somebody opened a PR saying, let's add an AI documentation URL, llms.txt, to make it easier for LLMs to understand how to use this. And in response uh, the maintainer said like, I don't really wanna do this. AI is crippling our business. We just had to lay off three of the four people who work on it, and our revenue has dropped 80%. [00:48:50]
-
-**Mark:** And I think all, and I think also put up a big podcast then saying like, this sucks. Here's what we've been having to go through. [00:49:13]
-
-**Carl:** Right, right. Podcast in the form of, I think just, I think it was what Adam walks, it was like he walks around while musing into a microphone, which I love. And so like that went viral and they got a bunch of sponsorship and, you know, income through that after they laid people off, unfortunately did not save those people's jobs. [00:49:20]
-
-And like that also sucks. You know, like, that's like the GoFundMe model of health insurance. Like you shouldn't have to. Have something awful happen. Get on a platform to shout about how awful this thing that happened is, and then get donations in response to how big of a, you know, as, as a measure of how large of a platform you have to solicit help from. [00:49:38]
-
-**Mark:** It's certainly not a repeatable and reliable business model. [00:49:59]
-
-**Carl:** I'm very happy that Tailwind got more revenue after talking about how much their revenue has dropped. But like, that's not gonna ha that's not gonna happen for everybody who needs it and it's not gonna happen repeatedly. So me, [00:50:02]
-
-## VoidZero and Vite+?
-
-**Mo:** leads back to that void zero v plus story, which is, I don't see a viable path for monetization for open source projects. It's oftentimes it actually doesn't end up being that successful. I, I mean, mark. Mark, you've been in the ecosystem far more than any of us, I guess, just by virtue of being a successful open source maintainer, but you know, you've obviously done that on the side. [00:50:15]
-
-Right? And like, can you think of any projects that have been successful, like uber successful at monetizing? [00:50:38]
-
-**Mark:** TanStack's the only one that I can think of. Like talking to Tanner this last year. The sponsorships that he's been pulling in have were enough to allow him to go full-time, open source a couple years ago. And he said that the sponsorships have kept growing to the point where he's, he's able to do some disbursements to some of the other maintainers now, and he hopes that if things keep on this trajectory, he might be able to hire some of them full-time. [00:50:44]
-
-But that's about the only one that immediately comes to mind. [00:51:12]
-
-**Carl:** And I think, does he do, do you know if Tanner does? Uh, Like consulting and like services? [00:51:15]
-
-**Mark:** Think he does some, but it's, I think a lot of it is just straight up sponsorships. [00:51:21]
-
-**Carl:** Okay, cool. [00:51:24]
-
-**Mo:** But I guess that's sponsorships, right? Like it's not a direct monetization play, right? So you are relying on the. Donations of, companies in the ecosystem to keep you going. Whereas like, I think the only one I can think of is super base, but they were actually going in for monetization from the get go. [00:51:25]
-
-They just, so like the other way around works, which is you launch a cloud product and then you have an open source portion of it, but not like you start from open source and then you monetize. It seems like that's less likely. . [00:51:40]
-
-**Carl:** I don't know. It's open source has always been tough. It feels like the economics have gotten weirder. It's like, there's more money than ever in tech. You know, as a market, as a, as an industry. But where it is going has is fewer and fewer players. So that's just like, that's tough. I don't know. It's like wealth inequality, open source edition. [00:51:51]
-
-**Mo:** It looks like AI is just making it worse as well, even in like the terms of the tech openings, job openings that are out there and people trying to, companies trying to do more with less people yep. at everything. [00:52:10]
-
-## [246K laid off in 2025 per Trueup.io](http://Trueup.io), 27k in January
-
-**Carl:** Which is a wonderful segue into true up.io, which I have previously relied on to, you know, back when I was doing more month by month layoff news according to them, in 2025, 246,000 tech jobs were lost through layoffs. And already in January we're at 27,000 Rough. [00:52:22]
-
-**Mo:** Geez. Which, you know, Amazon had a pretty big one this week. I believe it was thousand people, which was rough. [00:52:43]
-
-**Carl:** Yep. Yep. I dunno what to do with that. [00:52:52]
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Lightning round. [00:52:56]
-
-## Corbin: [Adapting Library Logic for React Compiler](https://playfulprogramming.com/posts/react-compiler-library-support/)
-
-**Mark:** TanStack form maintainer Corbin Crutchley. Put out a post talking on adapting library code to work properly with the React compiler and some of the constraints that you have to deal with Corbin's. [00:52:57]
-
-Awesome. This is a very useful post. [00:53:09]
-
-## [Lea Verou: Web Dependencies are Broken](https://lea.verou.me/blog/2026/web-deps/)
-
-**Mark:** Lea Verou, who has been in the web standards and CSS discussion, spec specification arena for a very, very long time. Put a proposed complaining about web dependencies are broken. I'm not sure I agree with some of the complaints here, but she's very clearly spent a lot of time complaining about the fact that there's a lot, essentially a lot of non-standardized ways to deal with dependencies. [00:53:11]
-
-Do you do script tags? Do you have bundlers? What if, you know, import maps? What are your options for loading third party code? And why is this so complex and it's worth a read. [00:53:36]
-
-## [AWS Infrastructure as React Components](https://www.react2aws.xyz/)
-
-**Carl:** Somebody put together a project where you can author AWS infrastructure configuration as react components, which is cool. This reminds me, years ago I had a thought to try and do a react renderer for Kubernetes config. 'cause you know, hey, it's all just files. if you're rendering right, who cares if you're rendering HTML or yaml, it's all the same. [00:53:47]
-
-Yeah. So somebody did that for AWS infrastructure and it puts out terraform configurations. And I saw this criticized as, "great, they re-implemented XML" which is pretty heckin true. Like this is, you know, we, we've just gone full circle from XML to yaml, back to pseudo XML. [00:54:11]
-
-**Mo:** I posted this on our company dev chat and someone respond, did one misconfigured use effect. And Gigi, you're bankrupt. [00:54:29]
-
-**Mark:** Worse than the cloud dashboard. [00:54:36]
-
-## Callstack releasing bunch of cool projects
-
-**Mo:** Alright, quick react native one. So, uh, the call stack folks have been busy whilst the rest of the ecosystem I'd say has been relatively quiet. This month and they've released two really cool projects. [00:54:38]
-
-## [Brownie: RN Brownfield apps](https://www.callstack.com/blog/introducing-brownie-type-safe-shared-state-for-react-native-brownfield-apps)
-
-**Mo:** So Brownie is the first one that I want to quickly touch on, which is a project for Native Brownfield applications. So we talk about Brownfield as apps that are mainly native, but they're adopting some React native views and screens within them. [00:54:48]
-
-And these are difficult to build, but predominantly they get really hard when you have to share stake between them. So they're trying to create a standardized, nice way to share a storage basically a store in between your different React native screens in a largely native app shelf, which I thought was cool. [00:55:02]
-
-## [Voltra: RN Live Activities and Widgets](https://www.callstack.com/blog/live-activities-and-widgets-with-react-say-hello-to-voltra)
-
-**Mo:** And somebody's, you know, trying to standardize and create a project and a tool for that, which is sort of less touched on in the open source ecosystem for React Native. The second library that they released, which they didn't actually start but they've now taken over is one called Voltra. So Voltra was actually created by this open source author who nobody really knew that well in the React native ecosystem. And he just kind of did it as a side project. And I think the call stack folks have kind of taken over it. So it's for things like live activities and widgets. These are sort of native functionalities that you can't really do with React native. [00:55:17]
-
-But this library author has kind of done a really cool job of representing it as React code, even though it's not quite exactly using a React render under the hood. It's just sort of then being translated to native views. Surprisingly the person who was the original maintainer has deleted his Twitter and you can't really find him anymore. [00:55:51]
-
-So I hope he's doing all right. But it seems like it's being taken over by the call stack folks. [00:56:08]
-
-## Ryan Carniato’s [annual JS Frameworks direction roundup](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2026-2hel) , and Netlify’s [2025 Web Frameworks In Review](https://www.netlify.com/blog/web-frameworks-2025-year-in-review/)
-
-**Mark:** Okay. Ryan Carniato knows more about what's going on and across all the different JS frameworks than pretty much anyone else. I love his perspective. And each of the last few years he's done a post kind of summarizing like, where are we at and where are we going? So this is his addition for going into 2026. And meanwhile, Netlify put up a 2025 web frameworks year in review post as well. [00:56:12]
-
-## Alex Russell: [Shallow Session SPAs analytics](https://calendar.perfplanet.com/2025/the-curious-case-of-the-shallow-session-spas/)
-
-**Mark:** Meanwhile, alex Russell continues to hate React and JavaScript and single page apps. He also has the metrics and the stats to back up his opinions, even if I don't agree with how he states a lot of them. And he put up a post where he said, we're basing, like we've always based the argument for single page apps on the idea that yeah, you load a lot of code, but it stays alive and users do a lot of navigations. [00:56:36]
-
-And the metrics that we have don't necessarily support that users do a lot of navigations, but it's also possible that the metrics I have are flawed because they just don't capture users clicking around in the page. So what could we hypothetically do to gather better information either way? Which is all a very valid set of points. [00:57:00]
-
-## Devon Govett: [How to compile JS to C with Static Hermes](https://devongovett.me/blog/static-hermes.html)
-
-**Mark:** Devin Govett, who maintains the parcel bundler, and I believe the Lightning CSS tool did a post on compiling JavaScript to see with static Hermes. I don't even remember which tool he was compiling. But Mo I know you've talked about static Hermes quite a bit, and it sounds really cool. [00:57:23]
-
-**Mo:** Yes. The Static Army team has been working quite a bit. In the last couple months to get version one up and running well, version one of Hermes up and running and they're kind of at a crossroads with static Hermes. We talked about it a couple months ago, I think, where we said it, it conflicts with some of the ecosystem and how React native has naturally evolved with things like over the air updates and so on and so forth. [00:57:43]
-
-But I think there's a lot of use cases beyond React native. So this is quite interesting to see other people look at it and see how they [00:58:03]
-
-**Mark:** Mm-hmm. [00:58:08]
-
-**Mo:** it. [00:58:08]
-
-**Mark:** I know that the React compiler team has said that this is how they're hoping to try to optimize the compiler parsing phase as well. [00:58:09]
-
-## Joyee Cheung: [require(esm) implementer’s tales](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-implementers-tales/) and [require(esm) from experiment to stability](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-from-experiment-to-stability/)
-
-**Mark:** And then Joy Chung, who built the require ESM compatibility loader for node and therefore is probably gonna be more responsible for than anyone else for eliminating common js. [00:58:16]
-
-Eventually put up two fantastically detailed posts on the implementation work needed to make that happen. And it's fascinating to read the technical details to hear about, you know, like earlier people had tried things and then, you know, pieces were just sort of left to rot and she was able to pick them up and work on them. [00:58:29]
-
-Great work, great write-ups. [00:58:50]
-
-## [Fixing the URL Params Performance Penalty](https://calendar.perfplanet.com/2025/fixing-the-url-params-performance-penalty/)
-
-**Carl:** I was a little surprised to see this I'm not familiar with this blog, Planet performance. But it's the same domain that the Post from Alex Russell that Mark just talked about is on. So that's interesting. It's not often that I see a new blog from a recognized author, so this is interesting. It's, it looks like they're talking about web performance generally, and that's pretty cool. [00:58:53]
-
-**Mark:** this section was like an advent of performance type thing in December. [00:59:14]
-
-**Carl:** Oh, that makes sense. Web performance calendar. Okay. It's like an advent calendar of web performance. Oh, that's cool. Appreciate that. [00:59:18]
-
-But yeah, so Barry Pollard put out a blog post called Fixing the URL PERS Performance Penalty. And the gist of it here is that sometimes the query string the part of the URL after the question mark contains information that alters the page. [00:59:25]
-
-Like, you know, a product details page that gets the product ID from the query string. And more often it's just a bunch of marketing tags, like UTM source and blah, blah, blah, blah, blah. And disambiguating between those two things is not something a cash can do on its own. So your marketing tags may be thrashing your cache performance. So this is talking about ways to improve that situation and make your marketing paras not affect performance quite so much. It looks like there's a header no very search that lets you alter that, alter the cache behavior in response to the query string. So it's good. It's one of those deep subjects good refinement for performance. [00:59:41]
-
-## [React Transitions for Low Priority Text Editor Updates](https://handlewithcare.dev/blog/transition_low_priority_editor_updates/)
-
-**Mark:** Okay, a few more items. We had there was an article on using React transitions for low priority text editor updates. Most of, you're probably not needing to go out and update the implementation of a text editor. But someone who's worked on React Pros Mirror has some examples of how transitions were actually helpful for managing those. [01:00:26]
-
-## [How to Steal a React Component](https://fant.io/react/) (Fiber internals)
-
-**Mark:** Meanwhile there was a post on how to steal a react component and you know, I believe the idea here was an extension that looks at react in the page and actually digs through the react fiber tree to not only see like what dom elements are in the page right now, but what component elements and props resulted in those. And essentially try to reverse engineer, here's the components that would have written the pieces of the page as they existed in the app that you're looking at. [01:00:46]
-
-## [Better ASCII rendering with smart character selection for “pixels”](https://alexharri.com/blog/ascii-rendering)
-
-**Mark:** And then unrelated to React, but absolutely amazing. I love really long blog posts with lots of interactive examples. Someone did a post on rendering a graphics with ASCI characters, which a lot of, you know, tools do, but analyzing the font weights in a given character cell to come up with better pixels. [01:01:20]
-
-So like if a, like, if the graphic should be lighter or darker using characters that occupy more or less of the character cell. It was just really cool to read this. [01:01:43]
-
-**Carl:** Yeah. I think a one short summary of the change. A lot of asci rendering tools like that will consider it, you know, the character space as a pixel and just sort of think about whether a given character, you know, they think about it one dimensionally. It's how many pixels are illuminated with this character or that character. [01:01:54]
-
-And this adds different, this basically subsamples the characters to say, is this brighter at the top or the bottom on the left or the right? And like I gotta say, you know, it's got a bunch of animated, you know, demos and whatever, and it is clearly much, much, much better than other things that I've seen. It's pretty cool. [01:02:13]
-
-## [Building a JS Runtime in One Month](https://themackabu.dev/blog/js-in-one-month)
-
-**Carl:** Somebody put out a blog post titled, building a JavaScript Runtime in one month. I love deep in the weeds engineering write-ups, and this is definitely one of those. But I have never even considered whether I might try to write a JavaScript runtime. [01:02:32]
-
-And so I feel very intimidated by the scope of engineering involved in this project. but [01:02:45]
-
-**Mark:** it even sounded like it was, you know, like, like not necessarily AI aided, at least I didn't see anything in the blog post that said they were using agents to do the work. I mean, there, there's also been a whole spate of let's have AI write a browser from scratch. Posts popping up over on Hacker News in the last month, and then I think I saw someone say they'd done a fresh browser from scratch, NC plus, but it was all by hand or something. Wow, y'all have too much time on your hands. [01:02:51]
-
-**Carl:** Yeah, seriously, it's impressive. I'm in awe of people who can do projects of this scope in that timescale. Like that's just wild. Anyway I approve. Very cool. [01:03:19]
-
-**Mark:** Mm-hmm. [01:03:29]
-
-**Carl:** Okay, that's our lightning round. We did it. . [01:03:30]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** I'm gonna blitz through a bunch of conferences. [01:03:33]
-
-There is C js in New Delhi in like th two, three weeks, 18th, 19th of February. State of the browser is February 28th in London. App devcon is March 10th through 13th in Amsterdam. [01:03:35]
-
-Programmable is a conference in both Melbourne and Sydney in Australia on March 17th and March 19th respectively. So it's, they're doing two days apart in different cities in Australia. That seems like a challenge, and it's kind of confusing to talk about [01:03:50]
-
-tech Fest is March 12th through 13th in Madrid, Spain. React Paris is March 26th and 27th in Paris. [01:04:05]
-
-Shockingly. [01:04:13]
-
-**Mark:** there [01:04:14]
-
-**Carl:** Front Runners is March 27th in Washington DC React Native Connection is March 30th and 31st in Paris. City Js London is April 15th through 17th in London. Js Day is. April 9th and 10th in Bologna, Italy. [01:04:14]
-
-. Smashing Con Amsterdam is April 13th through 16th in Amsterdam and React Miami is April 22nd and 25th through 25th in Miami. [01:04:31]
-
-So yeah. [01:04:40]
-
-**Mark:** speaking there. [01:04:41]
-
-**Carl:** Heck yeah. I should reach out and maybe give a talk somewhere. That would be cool and good for me. There's lots more, but that's, you know, that covers the next like three months, so seems good enough for now. [01:04:42]
-
-## Outro
-
-**Carl:** Thank you everyone for joining us . We not Wednesday, we are recording on Friday due to some travel hiccups, but we will be back probably on the last Wednesday of February here in the live stage react complex or back in your podcast feed just as we could, can after that. most of these sources came from Mark again. It's been very nice having such a steady stream of source of news sources come through here in Reactiflux. And maybe we'll do a little bit more to make the community more anchored on the people who are trying to stay to the cutting edge. [01:04:56]
-
-I don't know, we'll see. But if you see anything newsworthy, definitely share that in the Tech News and Reads channel. 'cause we'll read it. And if it's newsworthy and interesting, we'll probably talk about it. If this is a show you get value from and wanna support, best way to do so is by telling someone else about it. [01:05:24]
-
-We are still not that large. An average show gets about 400 listens over a little over a month. So yeah, I like doing it. I like making it. It would be cool if it had a little bit broader support, broader listenership. I guess the support is there. Yeah. Thanks so much for listening. See you next month. [01:05:39]
diff --git a/src/transcripts/tmir-2026-02.md b/src/transcripts/tmir-2026-02.md
deleted file mode 100644
index 67ade13..0000000
--- a/src/transcripts/tmir-2026-02.md
+++ /dev/null
@@ -1,691 +0,0 @@
----
-title: "TMiR 2026-02: CloudFlare remakes Next with AI; Vercel big mad. We talk too much about AI Agents"
-date: 2026-02-25
-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)"
----
-
-
-
-
-
-- [[01:46](#new-releases)] New releases
- - [[01:50](#ts-60-beta-last-ts-impl-release-stricter-defaults)] [TS 6.0 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/)! (last TS impl release; stricter defaults)
- - [[02:34](#yarn-6-preview-rewritten-in-rust)] [Yarn 6 preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/) (rewritten in Rust)
- - [[02:52](#electrobun-tauri-alternative)] [Electrobun](https://blackboard.sh/electrobun/docs/) (Tauri alternative)
- - [[03:31](#react-native-gesture-handler-v3)] [React Native Gesture Handler v3](https://blog.swmansion.com/introducing-gesture-handler-3-0-hook-based-api-deeper-reanimated-integration-more-9185b0c8e305)
- - [[04:20](#next-polyfills-improved-webstreams-and-upstreaming-to-node)] [Next polyfills improved WebStreams and upstreaming to Node](https://vercel.com/blog/we-ralph-wiggumed-webstreams-to-make-them-10x-faster)
- - [[05:25](#webpack-2026-roadmap)] [Webpack 2026 roadmap](https://webpack.js.org/blog/2026-04-02-roadmap-2026/)
- - [[05:53](#lodash-maintenance-roadmap)] [Lodash maintenance roadmap](https://socket.dev/blog/inside-lodash-security-reset)
- - [[07:07](#gatsby-react-19-support-styled-components-rsc-support)] [Gatsby React 19 support](https://www.gatsbyjs.com/docs/reference/release-notes/v5.16/) , [styled-components RSC support](https://styled-components.com/releases#styled-components@6.3.0)
- - [[07:54](#npmxdev-alternate-npm-site-ui)] [npmx.dev](https://npmx.dev/) (alternate NPM site UI)
- - [[08:43](#eslint-plugin-react-render-types-typed-children)] [eslint-plugin-react-render-types](https://github.com/HorusGoul/eslint-plugin-react-render-types) (typed children)
-- [[09:54](#main-content)] Main Content
- - [[09:55](#react-core-updates)] React Core updates:
- - [[09:56](#react-foundation-officially-launched)] [React Foundation officially launched](https://react.dev/blog/2026/02/24/the-react-foundation)
- - [[12:28](#docs-updates-useactionstate-merged-use-and-rsc-sandboxes-wip)] Docs updates: [`useActionState`](https://github.com/reactjs/react.dev/pull/8284) (merged), [`use`](https://github.com/reactjs/react.dev/pull/8305) and [RSC sandboxes](https://github.com/reactjs/react.dev/pull/8300) (wip)
- - [[14:23](#react-native-084-released)] [React Native 0.84 released](https://reactnative.dev/blog/2026/02/11/react-native-0.84)
- - [[17:47](#hermes-wasm-support-hermes-node-compat-cli)] [Hermes WASM support](https://x.com/tmikov/status/2023821160241393839), [Hermes Node compat CLI](https://x.com/tmikov/status/2024609186936660170)
- - [[18:43](#state-of-survey-results)] “State of…” survey results
- - [[18:43](#state-of-js-2025-results)] [State of JS 2025 results](https://2025.stateofjs.com/en-US)
- - [[19:06](#state-of-react-2025-results)] [State of React 2025 results](https://2025.stateofreact.com/en-US)
- - [[19:51](#aurora-scharffs-conclusion)] [Aurora Scharff’s conclusion](https://2025.stateofreact.com/en-US/conclusion/)
- - [[20:44](#josh-comeaus-takes-on-the-results)] [Josh Comeau’s takes on the results](https://bsky.app/profile/joshwcomeau.com/post/3mf642css6227)
- - [[21:28](#api-pain-points)] [API pain points](https://2025.stateofreact.com/en-US/features/#main_apis_pain_points)
- - [[21:53](#state-of-react-native-2025)] [State of React Native 2025](https://results.2025.stateofreactnative.com/en-US/)
- - [[24:29](#how-we-rebuilt-nextjs-with-ai-in-one-week)] [How we rebuilt Next.js with AI in one week](https://blog.cloudflare.com/vinext/)
- - [[29:52](#cloudflare-v-vercel-beef)] CloudFlare v Vercel beef
- - [[35:42](#carl-vitullo-monologs-about-ai-agents)] Carl Vitullo monologs about AI Agents
- - [[42:27](#ai-productivity-and-impacts-on-our-attention)] AI productivity and impacts on our attention
- - [[44:42](#wrote-a-spec-pointed-claude-at-an-asana-board-and-went-home)] ["wrote a spec, pointed Claude at an Asana board, and went home"](https://x.com/rvivek/status/2026385957596111044)
- - [[47:26](#bits-ai-sre-datadog)] [Bits AI SRE | Datadog](https://www.datadoghq.com/product/ai/bits-ai-sre/)
- - [[51:04](#thoughtworks-opines-on-ai-productivity-impacts)] [ThoughtWorks opines on AI productivity impacts](https://simonwillison.net/2026/Feb/14/thoughtworks/)
-- [[01:00:28](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[01:00:37](#wall-street-raider-game-modernization-and-uses-preact)] [“Wall Street Raider” game modernization](https://www.wallstreetraider.com/story.html) (and uses Preact)
- - [[01:01:16](#github-stacked-diffs-preview-faster-issues-search)] [Github Stacked Diffs preview](https://x.com/jaredpalmer/status/2019817235163074881) , [faster Issues search](https://github.blog/changelog/2026-01-29-improved-search-for-github-issues-in-public-preview/)
- - [[01:02:08](#josh-comeau-sprite-animations)] [Josh Comeau: Sprite animations](https://www.joshwcomeau.com/animation/sprites/)
- - [[01:02:26](#interop-2026-webkit-igalia)] [Interop 2026](https://wpt.fyi/interop-2026), ([WebKit](https://webkit.org/blog/17818/announcing-interop-2026/), [Igalia](https://www.igalia.com/news/interop-2026.html))
-- [[01:03:38](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [AppDevCon](https://appdevcon.nl/) Mar 10-13, Amsterdam Netherlands
- - [Programmable](https://www.programmable.tech/) Mar 17 / Mar 19, Melbourne / Sydney, Australia
- - [Frontrunners](https://frontrunners.tech/) Mar 27, Washington DC, USA
- - CFPs: [web talks](https://docs.google.com/forms/d/e/1FAIpQLScK3YlL_-2teVyX7pohkjIbsyLSF-8Hq4z-U7CPQ186sgdNPA/viewform) or [AI/data](https://docs.google.com/forms/d/e/1FAIpQLSedNNa4N64vgfsvAtGcBngKJrtd3h1_x0T019GTW-rSwCj0jQ/viewform)
- - [T3chfest](https://t3chfest.es/2026/en/) Mar 12-13, Madrid, Spain
- - [React Paris](https://react.paris/) Mar 26-27 Paris, France
- - [CFP (closed)](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform), [Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform)
- - [CityJS London](https://london.cityjsconf.org/), Apr 15-17, London, UK
- - [jsday](https://www.jsday.it/) Apr 9-10, Bologna, Italy
- - [SmashingConf Amsterdam](https://smashingconf.com/amsterdam-2026) Apr 13-16, Amsterdam, Netherlands
- - [React Miami](https://www.reactmiami.com/) Apr 22-25
- - [JSWorld](https://forms.gle/jxUNcEpibb1XcLdP7) May 7-8 Amsterdam, Netherlands
-
-**Carl:** Hello everyone. Thank you for joining us for the February edition of this Month in React. As we recap what's going on in React, react Native and across the web, coming to you live from Reactiflux, the place for professional developers using React. This is our first month, we are now membership applications only. Everyone in here now is part of an exclusive club that has a gate at the door, which feels kind of weird, but it has shifted the vibe. So I'm pro it so far. It's kept out a lot of scammers. [00:00]
-
-**Mark:** There's even been a lot of that going on across, you know, the open source ecosystem in general. I've seen numerous repos going like no external contributors or vouch system only. [00:29]
-
-So there's, there's a lot of trend there. [00:40]
-
-**Carl:** It's unfortunate. But anyway, I'm Carl. I'm a staff product developer and freelance community leader here at React Flex, where I run community programs like this podcast, news events, and build tools to help keep the community operating. [00:41]
-
-**Mark:** Hi, I'm Mark. My day job is working a Replay.io where we are, once again, building awesome time, travel, debugging stuff, and now have a new replay, MCP to let your own AI agent Investate recordings. And outside of that, I find time to do redux stuff. [01:06]
-
-**Mo:** And I am Mo, I work at a company called Theodo, which is a global consultancy, and I spend my time these days building AI tooling, but have spent the last three, four years in the React and React Native ecosystem. So I try to merge the two together. So I, uh, organize the React Native London Meetup and conference and have spent a bit of time dabbling in the React Native ecosystem. [01:09]
-
-**Carl:** Yeah. And we have a fun little podcast milestone this month. It's a little bit fuzzy because metrics are like really hard to do on downloads, but it appears that we crossed 7,500 downloads cumulatively across the entire podcast over the past month. So like, yay. That's cool. Thanks for listening. Cool. [01:28]
-
-## New releases
-
-**Carl:** Mark, take us through some new releases. [01:46]
-
-**Mark:** Okay, first couple items. [01:48]
-
-## [TS 6.0 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/)! (last TS impl release; stricter defaults)
-
-**Mark:** TypeScript six beta just dropped. And as a reminder, this is scheduled to be the final release of TypeScript written in TypeScript itself. The plan is that there will be no 6.1, no, 6.2. The the next release would be TS 7, which is the built in go version. The biggest thing for version six, you know, TypeScript has always been very fuzzy on their versioning, but they, when it's a do o release, they do tend to change some settings. [01:50]
-
-And so TS 6.0 is going to make a lot more stricter defaults as preparation for version seven. So that both improves behavior as well as reflects how TypeScript is actually being used in practice today. [02:20]
-
-## [Yarn 6 preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/) (rewritten in Rust)
-
-**Mark:** Meanwhile, continuing another trend, yarn has released version six or, or announced a version six, which is a little surprising 'cause I don't. [02:34]
-
-I think they had a version five, I'm pretty sure they're on version four right now. And it is the obligatory rewrite it in Rust approach. So train to speed things up. [02:42]
-
-## [Electrobun](https://blackboard.sh/electrobun/docs/) (Tauri alternative)
-
-**Mark:** Totally different item. So we've got Electron, which is desktop apps wrapped in a browser because you ship an entire chromium build for your website. [02:52]
-
-There's tari, which is desktop apps in a browser, except that it uses the operating systems built-in browser web view. And someone else just put out electro button, which is the, an equivalent of tari and that it uses the, you know, the native web view. But it uses BUN for all the behind the scenes processing. [03:03]
-
-So it looks, looks potentially interesting. And with BUN being a Swiss Army knife could be useful. [03:26]
-
-## [React Native Gesture Handler v3](https://blog.swmansion.com/introducing-gesture-handler-3-0-hook-based-api-deeper-reanimated-integration-more-9185b0c8e305)
-
-**Mo:** Switching over to the React Native ecosystem, the folks at Software Mansion have released. React Native gesture handler version 3.0. It's currently a beta, but it's, it's likely gonna be released as it is. And so the major change here is that they've overhauled the API surface to be based on hooks. [03:31]
-
-So previously it was a bit of a, an imperative setup. It wasn't hook based. They've now updated it so that it fits more with some of the other libraries that Jester Handler integrates with. They've also removed support for the legacy architecture and they've done some performance optimizations under the hood so that when you integrate reanimated with gesture handler. [03:49]
-
-Things work kind of better and it lets you use things like shared values across the board into your gestures, which is something that you previously couldn't do. So some good changes here, and hopefully it will be launched soon outside of data. [04:07]
-
-## [Next polyfills improved WebStreams and upstreaming to Node](https://vercel.com/blog/we-ralph-wiggumed-webstreams-to-make-them-10x-faster)
-
-**Mark:** This next one is somewhere between a, a release and a news item. [04:20]
-
-So there was, there was some investigation of next JS and RSE performance a couple months back, and CloudFlare was digging inside the internals of Next and made some improvements. So LL apparently followed up on some of this and RSCs at least some of the next usages, currently use web streams internally for passing the data around instead of the nodes standard built in streams. So two different stream implementations. [04:24]
-
-They did some analysis and figured out that Node's Webstream implementation is actually really inefficient and actually kind of previewing something we'll be talking about later. They cut a bunch of agents loose and said, Hey, make this a whole lot faster and be actually very similar because there were a ton of web platform tests on how web streams ought to be behave. [04:52]
-
-They were able to re-implement the concept faster, and they're trained to upstream some of that behavior into node itself, but also release this as essentially a polyfill package as well. [05:12]
-
-## [Webpack 2026 roadmap](https://webpack.js.org/blog/2026-04-02-roadmap-2026/)
-
-**Mark:** Let's see. We have a couple road mappy items. First off, Webpac has put, has put out a 2026 roadmap. Some of the things we're looking at are better built in support for CSS modules, a new universal output format that will work across run times. [05:25]
-
-Being able to load TypeScript without needing a separate loader plugin and trying to make sure that Webpack can run everywhere, not just node. [05:42]
-
-**Carl:** Yeah, I guess that seems good. [05:51]
-
-## [Lodash maintenance roadmap](https://socket.dev/blog/inside-lodash-security-reset)
-
-**Carl:** Yeah. Keeping on the, I don't know, roadmap and old tools. Talking about what they're gonna be doing next. Lodash put out a a bit of a roadmap, or I guess sot dev is talking about the Lodash reset and maintenance reboot as they call it. [05:53]
-
-The title here, we talked about this a bit last month, but yes, the Lodash maintainers are rebooting the governance of the package essentially. Interestingly, they got an investment from a European like sovereign tech fund. So I guess you know the. Some European agency has determined that Lodash is critical infrastructure, deserving financial support, and so they are using that money to fund governance changes to how the package is managed, and then also do some security releases and such, which is great. [06:10]
-
-I mean, Lodash is the kind of thing that, you know, in the aftermath of all of these NPM vulnerabilities, Lodash is absolutely the kind of library that would be aggressively targeted by nefarious actors. So that's pretty cool. That's exciting. Why? I like seeing rebuilding security from first principles if a core project is going to get a bunch of money. [06:45]
-
-Very cool. [07:06]
-
-## [Gatsby React 19 support](https://www.gatsbyjs.com/docs/reference/release-notes/v5.16/), [styled-components RSC support](https://styled-components.com/releases#styled-components@6.3.0)
-
-**Mark:** And on a similar note, a couple other legacy projects getting updates. Gatsby had a. Maintenance release that added some kind of react 19 support and styled components. Put out a release that tries to add RSC compatibility, which is very interesting. 'cause I thought, I thought one of the issues was it just wouldn't work in server components. [07:07]
-
-So I, I haven't looked at this, I just saw it this morning. But FYI, [07:26]
-
-**Mo:** I also remember them putting a big sting and saying they were deprecating themselves as a lib. [07:30]
-
-**Carl:** Right. We talked about that. [07:35]
-
-**Mark:** I mean, someone, someone else forked it to improve the performance, but I thought the primary library was halted. [07:36]
-
-**Mo:** And, and same for Gatsby, although I might beat bit fuzzy. Was Gatsby ever deprecated or is it [07:42]
-
-**Mark:** Yeah. Gatsby was bought by Netlify and then abandoned. [07:47]
-
-**Mo:** So turns out AI can revive old school projects. [07:50]
-
-## [npmx.dev](https://npmx.dev/) (alternate NPM site UI)
-
-**Mark:** And last couple release announcements, those of you who have ever looked at the NPM package website might have noticed that it's, it's there, it works, but it's not really modern and it certainly hasn't been updated in a while. [07:54]
-
-So a bunch of folks from the community have put together NPM x.dev, which is an entire alternate front end to the same NPM package registry and server APIs. This only sprang up within like the last month or month and a half, and there's been a massive group of folks just diving in and building out a brand new website from scratch and adding all kinds of useful features. [08:09]
-
-I've, I've looked at it a couple times and it is much, much better implemented than the primary NPM website. Nice. [08:34]
-
-**Carl:** Love that. [08:42]
-
-**Mark:** Yep. [08:42]
-
-## [eslint-plugin-react-render-types](https://github.com/HorusGoul/eslint-plugin-react-render-types) (typed children)
-
-**Mark:** And then finally, one of the longstanding complaints about React in TypeScript is that you can't correctly type what? Style components can be passed in to a given parent. And apparently someone had added the flow typing language competitor type script had added a feature like this a couple years back. [08:43]
-
-But you know, at this point, nobody uses flow outside of Facebook. And so someone apparently put together an ES lint plugin that somehow tries to implement this kind of typed children restriction functionality. [09:05]
-
-**Carl:** I love that. That is something I had wanted a number of times. There was a moment a, a while ago where like compound components was a talking point, you know, a point of discussion in the React ecosystem where it's like tabs and like tab groups and like tab content, and you need those to be individual components because of just the structure of the dom, but they're all interrelated and like, this one must be nested within this one and so on. [09:17]
-
-So being able to enforce that in type constraints is, Ooh, love to sing that [09:43]
-
-**Mark:** both people and ais love having real typed constraints to catch problems in the first place. [09:48]
-
-**Carl:** Yes, indeed. [09:53]
-
-## Main Content
-
-**Carl:** Okay. [09:54]
-
-## React Core updates:
-
-**Carl:** Into our main content. [09:55]
-
-## [React Foundation officially launched](https://react.dev/blog/2026/02/24/the-react-foundation)
-
-**Mark:** The React Foundation was announced at React Conf back in October. The onstage announcement didn't have a lot of details and we've tried to pass on tidbits of information that we heard talking to, you know, Seth and other folks over the last couple months. [09:56]
-
-So. This blog post really doesn't say a whole lot more that we, you know, that we didn't know yet, other than the fact that apparently there's an eighth founding company, Huawei, it does say that they're trying to figure out what the, the split between the technical and political governance of the foundation will look like. [10:13]
-
-So there's a little bit of a, this is an announcement that there's an announcement thing going on, but hey, you gotta start somewhere. And I'm, I'm happy to see any kind of actual progress on this moving forward. [10:30]
-
-**Carl:** I don't know what we will really see from like, in terms of substantial details. 'cause like it's not like the core team in general was like super communicative about its internal processes or like who was doing what. [10:42]
-
-So I was hoping that might change a little bit. [10:56]
-
-**Mark:** Well, I mean, I mean talking to Seth directly back in New York and November, the longer term plan, and I, I don't know what the timeline is for this, but he flat out said they are intending to open up the literal weekly team sync meetings, like the same ones they've been having internally at meta and meta and versa for the last decade. [10:58]
-
-They intend to literally open those up to the public for viewing and then start to, you know, actually bring in community representatives to participate in those meetings as well as the new government structure affecting what the planning process is. So, like that alone is something that I am very, very excited about. [11:17]
-
-Get to get to see all the sausage feeding. [11:37]
-
-**Carl:** Yeah, that's very cool. I should talk to them 'cause I don't know, like I said at the beginning, Reactiflux now has a gate at the door. I'm curious about adding more gates because like the keen eye may notice that there are not very many open source project maintainers around here. [11:39]
-
-And I tend to believe that's because of, there's a lot of people who are not as experienced and the volume of less experienced questions crowds out the more experienced people trying to have discussions. So I'm curious about adding more levels of gates, you know, so you can get in and then you can get in further and then you can ascend and sounds related to open access meetings. And then, you know, some participants being able to join if they meet some other bar. That would be cool if we could be more of a home for a little bit more of that stuff. Anyway. [11:54]
-
-## Docs updates: [`useActionState`](https://github.com/reactjs/react.dev/pull/8284) (merged), [`use`](https://github.com/reactjs/react.dev/pull/8305) and [RSC sandboxes](https://github.com/reactjs/react.dev/pull/8300) (wip)
-
-**Mark:** Other than that, a couple other bits of news. I I, I don't think there's been any other React releases recently, however, Ricky Hanlon has been diving in and trying to do some major improvements to some of the React reference docs. [12:28]
-
-I think last month we had talked about, he had rewritten the use effect event, API reference and possibly one other page. And within the, the last couple weeks he's gone in, he merged a rewrite of the Use Action State reference page. He has a work in progress PR to revamp the use hook page, and he also has a PR to try to add sandboxes for server components to the docs. [12:40]
-
-And this is actually kind of a big deal. I don't know, I don't know what the longer term plan is here, but this is something I talked with him about. If you wanted to teach server components in the docs, how is a learner going to be able to try server components? Right now, like there's like, you know, it's all teaching client side react and it uses the sandboxes very, very well to do that. [13:07]
-
-But how are you going to teach someone server components if they have no way to try it out and it fully needs a framework choice to be able to do it. So if he's come up with an approach that is kind of like a, some sort of framework agnostic sandboxes that feels like it would unlock the ability to then add server components, teaching content to the docs. [13:33]
-
-**Carl:** It's interesting. Yeah. Where my reminds me of, I, I remember when I was learning JavaScript for the first time in like 2000, I don't know, '04 or '05, the try it editor on like W three schools where you could have like code over here and the pa you know, the, the webpage over here. Like, oh, it was so powerful. [13:57]
-
-So I, yeah, fuck yeah, let's update it to the modern era. Give some sandboxes for RSCs. [14:16]
-
-**Mo:** Cool. [14:21]
-
-## [React Native 0.84 released](https://reactnative.dev/blog/2026/02/11/react-native-0.84)
-
-**Mo:** So moving on to the next piece of news from the React core team. React Native version 0.84 has been released. Now, like we said previously, these releases are getting smaller and smaller and the idea is that they're released on a sort of two month by two month basis. [14:23]
-
-The big one on this release is that Hermes version one is by default. Now, just to give a little bit of background as to what Hermes v1 actually brings to the table, it's effectively a bunch of improvements on the VM performance. So they've gone in and actually implemented support for things like, ES6 classes. [14:39]
-
-Some of the syntax in more modern JavaScripts like constant let support for things like Async. Previously, all of this was being basically handled by Babel and just transpired into older formats of of JavaScript, and so. All of this is sort of helping improve the actual performance here. Now, this is not to be confused with static Hermes, which is a totally different project, but the idea is that there are some serious performance improvements here. [15:01]
-
-They ran some benchmarks on what this looks like, and we're talking on some sort of performance benchmarks on some of these open source projects. You know, we're looking at sort of something like 50% improvement in the relative performance for basically executing complex JavaScript benchmarks. The reality of it is when you sort of look at it, the, the results that they've given out, and oftentimes the React data ecosystem people use the Expensify app as sort of a benchmark because it's a real world app that's also open source. [15:30]
-
-So it, it gives a lot of good, uh, real world benchmarks. They saw improvements in the TTI of an app, so how quickly the app is interactive, somewhere between two to 7%, depending on the platform, but also things like the loading time of the bundle being significantly quicker. So generally just performance improvements on the whole. [16:01]
-
-Secondly, there was another sort of piece that we talked about last month that's now in by default, which is pre-compiled binaries on iOS. So previously with React Native, what the process would look like is that you would go through and actually build from source. That is no longer the case. By default, all of this is pre-compiled as an XC framework, which is effectively a library binary in the swift world, and then it's just installed as if it was a third party dependency. [16:22]
-
-You can opt out for the old behavior, but this will speed up build times quite significantly. Those are sort of the two major pieces. They've done a bit of housekeeping on removing more legacy architecture functionality and so on and so forth. But this is really the core. [16:51]
-
-**Carl:** So you said like, you know, two to seven percent-ish speed up and then you also said about like loading, like bundle loading. Do you know if the loading performance improvements are included in that percentage speed up or is that like separate things? [17:04]
-
-**Mo:** They're probably linked to one another, but they are different metrics that you assess. So there's like the bundle load time, which is how quickly the JavaScript gets loaded in by the rec native engine or hers in this case for executing. [17:19]
-
-But then there's the TTI, which is sort of like a, a step back, which is basically, I guess on the web side of things, it's like, I don't know, we have a TTI metric on the web, but I guess like think of it as like close to LCP in some capacity. [17:30]
-
-**Carl:** Yeah, Last Contentful Paint yeah, sure. [17:45]
-
-## [Hermes WASM support](https://x.com/tmikov/status/2023821160241393839), [Hermes Node compat CLI](https://x.com/tmikov/status/2024609186936660170)
-
-**Mark:** And then I saw a couple additional tweets from one of the, one of the Hermes team members talking about a couple proof of concepts that they've been working, proof of concepts, previews, alphas, somewhere in there that they've been working on. One is that they've, they've put together a CLI for Hermes that at essentially node, but implemented with Hermes instead of V8. So they, they've built layers for most of the node APIs and been able to, you know, build a node like CLI with Hermes. [17:47]
-
-And then they also put together a preview of wasm support for Hermes so that the, the Hermes engine's able to load WASM bundles Act. And that means you can take, you know, external, external libraries written in c plus plus or rust or whatever, compile them to Wasm and load them by the engine. And thus you get, you know, faster processing runtime from complex computational stuff. [18:16]
-
-So they're, they're probably pretty busy over there. [18:40]
-
-## “State of…” survey results
-
-**Carl:** Okay. [18:43]
-
-## [State of JS 2025 results](https://2025.stateofjs.com/en-US)
-
-**Carl:** Should we go into some state of the ecosystem results. Sure. I regrettably have not read this. These are always so deep and they have so much knowledge in them that I want to give them a lot more attention than I ever really feel like I have. So I have not read these as closely as I would've liked to. [18:45]
-
-Mark, did you get to take a look? [18:59]
-
-**Mark:** Not really. I saw a few reactions. I linked to some of Josh Comeau's reactions. [19:01]
-
-## [State of React 2025 results](https://2025.stateofreact.com/en-US)
-
-**Mark:** The State of React survey in particular, if I'm looking at the, looking at the state of JS one at the moment, they, you know, in particular, they have sections for front end frameworks and meta frameworks, which, you know, is worth glancing at. [19:06]
-
-There's, you know, looking at, looking at the front end frameworks, we've got, you know, the, the usage ratios react is way up there. But in terms of satisfaction, solid seems to be pretty high up there and has the highest, has had the highest satisfaction for each of the last several years. So I'd have to dig in the numbers to see what the, the number of people using it is. But clearly folks who are using Solid are very happy with it as a choice. [19:21]
-
-**Carl:** Fair enough. [19:50]
-
-## [Aurora Scharff’s conclusion](https://2025.stateofreact.com/en-US/conclusion/)
-
-**Carl:** Yeah, I'm reading the, uh, conclusion of State of React written by Aurora Scharf. Man, it's, I just like, it's wild to think that Create React App only got sunset one year ago. Like that feels like ages ago. [19:51]
-
-**Mark:** I know. And I remember I still take 80% of the credit for that happening. [20:06]
-
-**Carl:** Yeah, right. Yeah. It's a great conclusion though. We have talked about a lot of these things that I'm reading in the conclusion, you know. Create React App sunset, Remix going away from React. The, all the server components blog posts that Dan Abramov put out, RSC Explorer, compiler went, you know, going to version 1.0, ASIG React working group. [20:10]
-
-So, yeah, I don't know. I guess I'm reading this conclusion in part as like a gr you know, a grading rubric for like, how well did we stay on top of the news as it came out? And I'm like, yeah. All right. We did pretty good. Nice. Good for us. [20:33]
-
-## [Josh Comeau’s takes on the results](https://bsky.app/profile/joshwcomeau.com/post/3mf642css6227)
-
-**Mark:** Yeah. Looking down inside of Josh Comeau's highlights thread, I, I think he calls out some, some rather interesting points. [20:44]
-
-Apparently a good number of folks have used server components one way or another, which is not a surprise because they're the default in next at this point. But he also points out that it looks like most people have not used form actions or the newer use action state and use form status hooks. That makes sense because they're, they're pretty new APIs. [20:51]
-
-React 19 only. But also it, it a little bit ties into, you know, kinda the question of like, we've all been able to write React apps very solidly since, you know, 20 13, 20 15, et cetera. [21:14]
-
-## [API pain points](https://2025.stateofreact.com/en-US/features/#main_apis_pain_points)
-
-**Mark:** Um, and so now there's all these new capabilities that fill potential app level pain points. But how many people are on React 19? [21:28]
-
-How many people are experiencing those pain points? How many people are aware that the new APIs exist to potentially help with them? And so there's an awful lot of, you know, writing React apps the same way we did in 2018, thereabout. [21:38]
-
-**Mo:** Cool. [21:52]
-
-## [State of React Native 2025](https://results.2025.stateofreactnative.com/en-US/)
-
-**Mo:** And we've also had the state of React Native in 2025, also published by the folks at Software Mansion. [21:53]
-
-And there, there's not a whole lot here. A lot hasn't moved in the ecosystem. There's a few interesting things that I thought would be, would be interesting to sort of call out. So starting from sort of the new architecture migration, it seems like out of the respondents that have been surveyed, somewhere around 80% have already adapted to the new architecture, which is good. [22:00]
-
-So it, it fits into sort of meta's view that the upgrade path is going to be relatively straightforward and it seems like most apps are by and large adopting it, which is great. Interestingly, it seems like most people's update strategy is to basically use Expo SDK release updates and they sort of update in parallel to that. [22:21]
-
-And so the idea is when Expo, every few months releases a new SDK update and it happens to be on, let's say, version 0.82, then, then people will sort of go for that. Now interestingly, what another thing around sort of react Native frameworks and talking about Expo, which is interesting to look at, is that. [22:40]
-
-Somewhere around sort of 75% of of people said that they're using Expo CLI, as sort of their framework for their React Native app. But also there's still a substantial amount of respondents that are using React Native community, CLI. So this is the old React Native CLI that used to be maintained by Meta and has now sort of been made a community package and deprecated by Meta in favor of Expo. [22:58]
-
-About 50% are still using that, which is surprising, but it also shows that there's probably a long tail of respondents that are still having apps that were built on top of the, the React Native community CLI these days. So that was quite interesting. The final thing that I thought was. Cool to look at, at a broad level was what percentage of code is being generated by ai? [23:21]
-
-So they did a, a, a bit of a question on this, and it seems like sort of if you look at the, the, the distribution here, we're talking about sort of 25 to 30% of react Native code on aggregate by the respondents is being generated by ai, which I suspect will sort of tick up. But 30% is, is quite large when you look at sort of an aggregate of the industry or of, of the entire ecosystem. [23:46]
-
-So those were sort of the, the high level pieces. If you look at the conclusion, they, they sort of highlight that, you know, some of these results are, are perhaps predictable and I think on large sort of these results are, are as expected. [24:10]
-
-**Mark:** And it looks like that that AI cogen question is under the dev tools category on the results. [24:23]
-
-## [How we rebuilt Next.js with AI in one week](https://blog.cloudflare.com/vinext/)
-
-**Carl:** Okay, we're gonna use this as a jumping off point. I think. So CloudFlare put out a surprising blog post, or I guess they released a project and announced it. They ha claimed that they have rebuilt next JS on top of Vite from scratch with an AI agent. They basically just said, here's the test suite. Go. [24:29]
-
-**Mark:** There was a person doing the driving and the, and the herding and the overseeing. But yes, it was essentially we have next tests as the spec. Can we rebuild it from scratch? But on top of Vite? [24:52]
-
-**Carl:** Yes. So they're calling it Vinext, Vite-Next, you know, get it deploys to CloudFlare workers in a single command. They say in early benchmarks, it builds production apps up to four times faster and produces client bundles up to 57% smaller. [25:05]
-
-And we already have customers running it in production. They say fascinatingly, they say that it costs them $1,100 in tokens, which is pretty good. I don't know. The other interesting thing is, so I've been playing around with AI a lot in the last month and in my like rough estimates of cost. I bumped up from the $20 a month Claude plan to the $200 a month Claude plan, and maxing out a $200 a month claude Plan appears to use on the order of $2,000 worth of tokens. I do wanna say, when it says this whole thing costs about $1,100 in tokens, that's eight raw, I believe that's raw aPI costs. And if you are using a monthly plan like you know, not API access, not a platform account, then I think it's actually included in that. So like that's interesting. If it sounds like on my limit, [25:20]
-
-**Mo:** you can do it with half of a Cloud max subscription. [26:14]
-
-**Carl:** Right. Yes. It looks like I could have done this with half of my limit in one Claude Max month, which is not that much like it's a big project, but it's not that much like half of my limit. I spent last month brought a project of mine from like pretty good to, I think I'm almost ready to start selling this in like 15% of my Claude limit. [26:16]
-
-So to totally rewrite next in half of a claw limit is like shocking. Remarkable and also sounds pretty reasonable based on my recent experiences with, you know, benchmarking code output if useful, effective code output against, I dunno, costs, then it's, so this is really interesting. This is, this ties into some, this is why it's such a good jumping off point because like Next it has years of usage and like production customers and like a company built a hosting platform around it because that seemed like a good idea. [26:41]
-
-And now some, now a competitor has taken advantage of their robust tests and everything and said we're gonna re-implement that from scratch in a matter of days for a trivial cost. [27:17]
-
-**Mark:** Similar examples. So watching Hacker News over the last couple months. A, a similar what Canis do Benchmark has been, what if we just cut agents loose to work for a few weeks and build a browser? [27:29]
-
-From scratch or a c compiler from scratch. You know, I've, I've seen both of those examples pop up and the, the big characteristic in all these cases is that it's a fairly well-defined problem, that it's fairly deterministic in terms of application behavior. And there is a massive existing test suite that helps define exactly what the behavior ought to be. [27:44]
-
-You know, we mentioned earlier the example of next reimplementing web streams as a polyfill, but building it faster. And they said, you know, there's no way we could have done this without the fact that there were already like 1500, 1700 platform tests for web streams. Similarly, browsers like the, the expected behavior for parsing HTML and all these other pieces of, of a browser's behavior are very, very strictly defined. And there's a massive set of platform tests that it can be used to compare correctness. So it's both, you know, like what other examples are out there they can reference, but it's the tests define what the expectation is. [28:08]
-
-**Mo:** Uh, on those two examples, I think the browser one was the cursor team and the C compiler was, I believe it was Claude's internal team. There was a bit of pushback on that because if you dug through it, it didn't actually compile or build correctly and needed a bit of human fixing to do that. [28:50]
-
-Admittedly, those are quite complicated tasks, right? Like building an entire browser from scratch and a C compiler is tough. This with CloudFlare coming out and saying, Hey, this is production ready and we're actually using it in product, or some of our clients are using it in production, seems to be a much bigger claim in my mind than sort of like an experimental labs effort. And it's, it's, uh, it's interesting that a company like CloudFlare is happy to put their name on this rather than it on something that's like, this is production ready. You can, they're given a commands to migrate an existing next JS project to Vinext. [29:09]
-
-Like they're really going, this is as good as next js. And so it feels like a different grade of achievement in my mind. [29:42]
-
-## CloudFlare v Vercel beef
-
-**Mark:** I mean there, there's also the existing strife between CloudFlare and Vercel that probably plays into this a little bit, but [29:52]
-
-**Carl:** true, right? There's like personal beef between the CEOs of those two companies. [29:58]
-
-So I'm sure that was a motivator here as well. Okay. There's personal beef, but there's also like legitimate technical questions here. Like, Vercel and CloudFlare are each trying to push their own visions of what hosting providers could be, and they're interesting. You know, I've been more interested in the CloudFlare vision of what hosting can be. [30:02]
-
-Workers sound really cool, like, you know, it seems like a plausible achievement of the vision of serverless, you know, that I've been hearing for my entire career. So I've been very curious about that. I've used it a little bit, and CloudFlare also was doing Open Next before, which was an adapter, so you could use, basically adapting the versal specific runtime things so that it could use it in other platforms. So like this does feel in keeping with the kind of work CloudFlare has been exploring with, but agreed that this is a categorically different kind of plane than like, ooh, we made a, a C compiler. Like no means is seriously using an AI generated c compiler in production. Like, not right now. [30:23]
-
-**Mo:** It, it's interesting. So talking about sort of like Cloudflare's platform, I've, this is sort of a, a tangent, but I've been building sort of two side projects, two mobile app side projects with ai and I'm defaulting to using CloudFlare workers durable objects and all of that because it's, it's actually like quite good for AI to understand in terms of the primitives and doesn't have to deal with like the complex architectural bits of like defining a region and stuff like that. [31:08]
-
-So I can, I can, I. I think it's actually like they have a good AI play that they can execute here as well. Beyond just, you know, articles about how they can rebuild next JS with ai. [31:35]
-
-**Carl:** Yeah, right. [31:46]
-
-**Mo:** Now there's one thing in this article that I find quite interesting. So I've spent a lot of time battling with the C of next js, and specifically when you're trying to deploy an xjs in certain sort of custom non-cell environments, it comes with a lot of complexity. [31:48]
-
-You, you're gonna have to define your own sort of like cache handler and they seem to have just popped all of that in CloudFlare kv, which is their sort of workers key value store and it's quite interesting that that, that is sort of the direction they've gone through. They say that you can also use R2, which is sort of their S3 equivalent. [32:05]
-
-Great name by the way, because R two is one character before. S3 on both sides of it, which I think was a dig at AWS, but the caching strategy and allowing for you to customize that cache, I think super easily with some of their primitives is, is quite nice because that is always been a pain point for custom deployments of, of next js. [32:27]
-
-And I think probably one of the biggest barriers to people, you know, hosting next JS in, in other cloud providers that I've seen in the possible and you have custom setups. [32:48]
-
-**Mark:** I mean, that is, as always, my caveat is I haven't worked on large scale production commerce e sites, so I have no practical experience with this. [32:58]
-
-But anecdote like we, we know the know the phrase, you know, the, the biggest error problems are, you know, off by one and caching errors or something. Something of that effect. And certainly anecdotally over the years, you know, like one of the biggest complaints about a polygraph QL was the complexity of the cache implementation. [33:06]
-
-We've seen a lot of complaints about next and their page caching implementation, and we've seen them go through, you know, 2, 3, 4 different iterations and approaches to caching and, you know, caching all the different layers of the system. So it's not surprising that this is a pain point. And so, yeah, I can, I can see CloudFlare saying, what if we, what, what if we do something different and maybe somewhat simpler. [33:24]
-
-**Carl:** Also, man, I gotta say thank you to Super Kennel in chat for sharing this post from Guiller Moro of titled "Migrate From Vercel to CloudFlare. And, um, you know, it's got this table of contents at the top, like project setup, migrating custom domains, converting build and deployment, moving environment variables, rewriting, and, you know, it's like 12, 15 items, something like that. [33:48]
-
-And like a quite long blog post. Whereas this CloudFlare, you know, we rebuilt next AI is saying, oh, just try it. Install this AI skill and then type migrate this project to V next in your favorite in any supported tool, and it'll do all the stuff for you. And I'm like, those are two entirely different levels of effort. [34:12]
-
-And I think CloudFlare handily wins there. That's interesting, assuming it actually works as, [34:35]
-
-**Mo:** it's funny because in one of the comments the Guillermo says, I'm migrating from Versal to CloudFlare. Am I doing it the wrong way around? And Guillermo's just like, yes, delete all of that. Rang blur, Jason C config nonsense, and all of the proprietary imports and just run it on Versal. [34:40]
-
-So this has clearly struck a nerve because they've launched this pretty much on the same day that they made this announcement or you know, day after. [34:55]
-
-**Carl:** Yeah. Right. Delete all the wrangler adjacency, config, nonsense. Like are, is versal gonna try and claim that next doesn't have config nonsense. Like you do not have a leg to stand on there. [35:04]
-
-**Mo:** There's, there's no legs to stand on. Especially if you've tried to deploy an Xjs project outside of Versal, it is pain. So no respect there. [35:15]
-
-**Mark:** Interesting. So there's, there's lots and lots of angles we could try to discuss here. We've, we've looked at. Rebuilding apps or tools that have known test suites and what does, and we, we really haven't even touched on what does that mean in terms of companies having a moat. [35:24]
-
-In fact, Carl, you wanna, you wanna toss that post in there at the moment? [35:39]
-
-## Carl Vitullo monologs about AI Agents
-
-**Carl:** Yes. Yes, I do. Also, I wanna, once you're done, I want to monologue for a moment, [35:42]
-
-**Mark:** couple other angles we could look at. I mean, there's, there's the ever popular, you know, what does all this mean for us as software engineers and our industry and our careers going forward? [35:47]
-
-And just how doomed do we all feel as well as, you know, what are we doing with AI on a day-to-day basis. If anything, Carl monologue go. [35:57]
-
-**Carl:** Yes. Ah, I alluded earlier to playing a lot with agents. A good internet friend of mine made a very silly AI agent, MMO. So it's like a text based, if you're familiar with like a mud, a multi-user dungeon. It's basically that. It's a text based MMO that you can play through your terminal, and it's only for ais to play. Not everyone is, but, so I've been using that to learn about how to do agents and how to run AIs autonomously for a longer period of time, which has been fascinating. And so this, I've now watched somebody in real time, like I heard about this project. [36:07]
-
-I went, oh, neat. Let me set up an AI to play this game. So I got there on like one, I think after it launched. Somebody else who got there on day one fucking ran with it has been, you know, he's been working professionally on AI agents for a year, he said. He already knew how to do all the harnesses in the orchestration, which I, you know, I had never tried to do either. [36:44]
-
-So I'm learning this from scratch watching him do it with a year of experience and like, holy shit, it is unbelievable how much code he produced. I think the total amount of code is like, now, I dunno if it was 60,000 or 600,000 anymore, but it's like a lot of code and it works like not perfectly. There's a lot of duplication, there's a lot of errors, there's a lot of, you know, like this code path looks like it works, but actually you get into the details and it doesn't quite work. [37:06]
-
-But like, as we use it, we like, so these AI agents are instructed as part of the game, like, "Not everything works. Please submit bug reports as you find them. Then this guy has his own agents that are reading those bug reports, turning it into reproductions, and then writing tests and fixing them, like largely autonomously. [37:34]
-
-Not completely autonomously, but largely, which now has me imagining this, like imagine if you set up, you know, you have an idea for a product, you build a prototype. You put it on a server and then you have on the, on that same server, a little sidecar or you know, running in the same environment. I mean maybe not literally on the same server. [37:55]
-
-An AI agent that is receiving user feedback. Like, you know how like every major enterprise application will say every so often, like, "we value your feedback. How are you using this product?" And then you fill that out and it goes into the void and nothing ever changes. You never hear about it again. You never get asked for a follow up and the bugs that you reported never get fixed. [38:16]
-
-Like what if that went into an automated system that triaged, reproduced and fixed things in real time autonomously as you submitted reports. Like that now appears to be within the realm of possibility. Like, like not theoretically in the future, but like currently I have seen tech that looks like it might be able to do that, like maybe not fully autonomously right now. [38:38]
-
-Oh God. Like pretty good. Pretty close. So that's fascinating. I think that's really interesting for the idea of like a one person startup, you know, a small team operating at a scale that previously would've required 50 to a hundred people. I think that's interesting, like scratching your own itches and publishing it so that other people can use it, and then soliciting feedback to guide the development now looks really powerful. [39:04]
-
-So I, that's when, you know, as we as, as we speculate on the future of development and what software development is going to look like, I think it's gonna be a lot of wrangling, that kind of stuff. Like, you know, I put up a little, little blog or no, I put, I posted on Blue Sky that after I was experiencing all of this and being like, holy shit, this feedback is incredible. [39:32]
-
-This feedback mechanism is incredible for guiding AI development. I had the thought of like, man, it feels like now the determining factor for how good software can be is how many people are using it, and how good those people are at articulating what they want out of it. Which is a really interesting place. [39:51]
-
-And I think that's all I have to say. [40:13]
-
-**Mark:** There's a little bit of the, you know, you just keep towing it, make it better, make it better, a fixed bug, make it better. [40:15]
-
-**Carl:** A lot of that. But you know, it's like there's also the aspect of like the more precisely you can articulate what is deficient, what better looks like, the better it works. [40:20]
-
-It's remarkable. Like I've seen it. It's so cool. I don't know, it's interesting. [40:31]
-
-**Mo:** There's sort of like. A few thoughts that I've got. There's anecdotally my whole like coding setup and how much code I can get through as a person who's been coding less and less and more. Dealing with systems and leading teams over the last few years has just been crazy. [40:35]
-
-Like my, I looked at my contribution graph on GitHub and I've done in the last two months now, done probably half of my commits that I did in the last year in 2025 in two months. And it, it's just gonna go up and up because it's been a lot more over the last. A couple weeks. And so producing code is significantly easier, especially to do as sort of someone that's instructing things at a high level. [40:52]
-
-I've been working on two side projects and both of those are like weekend projects that I would never have gotten anywhere near to completion. But I'm pretty much ready to launch one, like almost to the step of I I, I just need to push it to the app store at this point, which I have never been able to do just because I've never had the attention span to finish it off. [41:19]
-
-So that's been just something incredible. [41:40]
-
-**Carl:** If I can interrupt for a second, because same projects executed, ideas initiated exactly the same. Like I did things that I never would have because I would've looked at it and gone, oh, I know how much work that's gonna be, and I don't know exactly. [41:44]
-
-**Mark:** It's same for me. [41:57]
-
-Yeah. Mm-hmm. [41:57]
-
-**Carl:** I did them at the same time as each other. Like, I'm working on two or three projects in parallel, like while watching a movie with my partner. And, you know, and like I checked in with them to be like, Hey, like I was working, like, did I seem checked out? Or like, was I still present in the room? [41:59]
-
-And they were like, yeah, no, you were like, you followed the conversation and participated. So I, it's like I was more productive than I've ever been and I got to hang out with my partner and their roommate. Like, what? That's insane. [42:15]
-
-## AI productivity and impacts on our attention
-
-**Mo:** Well, well it's, it's only gonna get worse because they released the, the, the, the Claude folks yesterday that released this remote access mode where you can hook into your local, just hooked it up to your phone so you can actually just keep it, keep a track of what's happening on your phone. So this is only just gonna, every night of watching movies and TV shows is gonna be augmented by some level of productivity on the side, which is both terrifying and very exciting at the same time. [42:27]
-
-**Carl:** Yes, it is terrifying. It is, right? It's like such a productivity boost while also not demanding that much attention. That like, why wouldn't you just always have, you know, a, the little back corner of your brain thinking about this? [42:52]
-
-Which like, I don't know, my brain already works that way. I like, I've already poisoned my brain to be addicted to thinking about the problem. You know, like, huh, that's interesting. I mean, I've, [43:06]
-
-**Mark:** I've, I've, I've read a number of articles of people who are dealing with, I don't remember the actual term. I, I don't know, to token attention deficit or something like that. [43:15]
-
-Ba basically it, it's this constant feeling that, you know, okay, like I could be having multiple agents doing stuff for me at any given moment, and therefore any moment where I don't have 5 to 10 agents running is a waste of theoretical productivity time. So if I didn't spin them up before I walked out the door, that was a waste of time that I could have built, or, you know, I have to get back to, you know, double check the results and that quickly becomes its own form of productivity burnout. [43:22]
-
-Just [43:53]
-
-**Mo:** to give like a very concrete example on one of these projects, there's a sort of TikTok style video feed that I had to implement. I did this for a client on one of our actual projects at work that took somewhere around seven to eight days of me develop. We went back on like the Trello board that we were using and looked at the, the estimates of how long that that whole feature took, and it was about seven to eight days to get it working. [43:54]
-
-End to end. I was building something very, very similar for this, for the side project, and it took me a couple of hours to get that whole feature working end to end. So like I know more what I'm doing, I've done it once, I know where the pitfalls are, but at the same time it just, there there is a significant productivity boost here and it's, it's definitely not something that you can, you can ignore anymore. [44:17]
-
-## ["wrote a spec, pointed Claude at an Asana board, and went home"](https://x.com/rvivek/status/2026385957596111044)
-
-**Mo:** There's sort of two interesting things that I've seen over the last, you know, few hours. One is this post from a podcast by the guy who made Claude Code or his churn and he talks about how people are going back to Mark's point about this like productivity attention deficit. Where there's some anthropic engineers who are like leaving Claude code to look at the board, the project board over the weekend, breaking it up into specs, and just spawning it up into building a bunch of different agents that'll build tickets for you and do it in parallel and then you come back and review it on Monday, which is gonna be interesting to see how that goes. [44:42]
-
-But also, you know, there's an interesting one where Karpathy, who you know, used to be a Tesla sort of director of AI and so on and so forth. Original Open AI team has written this like tweet where he talks about how it's really over the last two months where things have just like completely accelerated and it feels night and day in terms of agent decoding. [45:24]
-
-So I think things are moving at a super fast pace. It means we're all probably feeling a good level of FOMO as a result of it, and it's faster than any one person can sort of stick to, which is, which is. Again, exciting and terrifying at the same time, is the only way that I can think of describing this. [45:46]
-
-**Carl:** Yeah. In our, you know, mid month DM chat Mark you had said, who's this? Zach, who's talking about [46:02]
-
-**Mark:** Abels? Zach Jackson is the creator of Module Federation. He joined the web back team a few years back, he now works at ByteDance slash TikTok. And he is an Uber example of, oh look, I have an army of 100 agents running simultaneously. Someone gifted me $60,000 worth in tokens. I'm going to burn most of it by migrating entire projects to Rust overnight. [46:09]
-
-**Carl:** Yep. And like, right, and like the quote you would put here, and it's not a literal quote, but the energy is, I can run a hundred agents, my only limit is token budget. [46:33]
-
-And I'm like, I have started to understand that perspective. 'cause you know, like. What you were just saying about like this person who, you know, wrote a spec and pointed Claude at Asana board, like, yeah, cool, that's awesome, that's great. But like also you don't need to write the spec yourself because if you are just taking user reports and they are submitting things to an agent that is triaging and then summarizing and then if you break down all these little parts into a system that has its own little feedback loops and review stages before passing it off onto another thing that has its own review stages and you know, iteration, then like, holy shit. [46:42]
-
-I understand why people are saying the only limit is token budget because each part of this is working. It's not like theoretical. [47:19]
-
-## [Bits AI SRE | Datadog](https://www.datadoghq.com/product/ai/bits-ai-sre/)
-
-**Mo:** People have already started productizing this. So Datadog has released, it's gonna link it in the chat, this bits ai, SRE, which is. The detection part, which data Datadog already did, which was, oh, there's an issue in production. [47:26]
-
-Okay, crap, we need to fix it. And then they've just lopped on agents to resolve these incidents automatically. So auto investigations, if you're really bold, I think you can just merge it, get it to automatically merge fixes for you across your code base. Like that's the direction we're going through. [47:40]
-
-**Carl:** And I'll even say like. [47:56]
-
-So, okay, great. Datadog productized this like, I don't fucking need it because I was dealing with database corruption in a project I run, and literally what I did was, you know, it was like something started breaking and I opened Claude and I said, here's my Kubernetes cluster, the database, something's going wrong. [47:59]
-
-Can you check the logs? And it did correctly identify the database corruption and then repaired it live like, and just fixed it. Then it became a recurring issue and I had to figure out what was going on and man manage a migration because I had left it in a half state that was causing the corruption. [48:17]
-
-But like, I don't know how to diagnose database corruption. That's, yeah. You know, that's database administrator kind of expertise. And I'm not a database administrator and this isn't even a specialized tool. This is just Claude Code. So like the future's here, we're in it. [48:34]
-
-**Mo:** For better or for worse. [48:51]
-
-**Carl:** Yeah, that's fascinating. [48:53]
-
-**Mo:** So there's, there's this one sort of chart that I saw, which just shows like the adoption of it so far. And obviously we're very close to it in the software industry because, well, we're, we're sort of dogfooding on our own workflows to start with. There's a debate on whether or not this will translate for other industries that, just taking a step back and looking at the, the wider economics of it all, it seems like, you know, there's been about a 50% of agents that, so philanthropic releases, they, they were saying that 50% of the agents that they've seen deployed so far are in the software industry and then it trails down like crazy after that to, you know, sub 10% for all other industries, which makes sense, right? [48:55]
-
-The question is how much higher can that go in the software industry and then will all of the other industries catch up? And I guess where I'm going with this is, what does this mean for just the greater economy and the entirety of the workforce. Like if everything is just constrained by that token budget that we were talking about, there's some really scary stuff coming out for the economy globally. [49:38]
-
-Going forward. And maybe that's a bit dooms date with me to say, but I, I am a little concerned about where we're going. [50:01]
-
-**Mark:** Yeah. I mean, if you, if you wanna zoom out for a second, you know, the, the extreme version of that was the AI 2027 sci-fi scenario projection that was put out a year-ish ago, which was put together a fictional version of how we end up with a true terminator level Skynet AI coming out in, you know, two and a half years, the slightly less, but still dooms day-ish version of that. [50:07]
-
-There was a, a report from Sat Trini research or something that came out just a couple days ago, which was a fictional news report from 2028 talking about how AI usage ended up, ends up tanking the economy in the next couple years and, you know, wiping out white collar jobs. And so I've seen a few different variations of that. [50:31]
-
-And, you know, a lot of these, you know, the questions are, you know, what are the, what are the assumptions going into, um, in the first place? And, you know, okay, fine, it's a scary sci-fi story, but. You know, there's, there's some plausibility to that stuff. [50:50]
-
-## [ThoughtWorks opines on AI productivity impacts](https://simonwillison.net/2026/Feb/14/thoughtworks/)
-
-**Carl:** So I wanna pull in, we had this quote from thought, the ThoughtWorks offsite. [51:04]
-
-ThoughtWorks is a very well regarded what agency from like, they've existed for decades. They've been involved, they've been very deeply involved in tech for a very long time in a very meaningful way. [51:09]
-
-**Mark:** They're not just a development agency, but they, they've document like software engineering processes and patterns for many years. [51:24]
-
-There's a guy named Martin Fowler who has, who has done a lot of that work and he, he's written dozens of articles on, like, we've talked with many, many companies and these are like the distilled best practices we see on how to build software across the industry. [51:31]
-
-**Carl:** Right? Like Martin Fowler, I would say is one of the reasons that people do blogs now, like a lot of people in tech learned so much from reading Martin Fowler's blog that I think that was a significant contributing factor to the advice to every person in tech to have a blog. [51:49]
-
-**Mark:** Right. I also associate them with the software craftsmanship movement. I, I think there was another consultancy called Eighth Flight Background, like 2005, 2010. [52:07]
-
-Well, like Uncle Bob Software craftsmanship, code Katas, like treating software development as a craft rather than a manufacturing exercise. So I, I, I associate them with that kind of pattern. [52:17]
-
-**Carl:** I also had forgotten this, but they authored the Agile Manifesto. So yeah, like, okay. So that's enough introduction I think for ThoughtWorks, like they have had so much influence on the tech industry generally, and so they just did an offsite discussing the future of tech, future of software engineering. [52:31]
-
-And I'm gonna read at least this first paragraph, maybe both paragraphs of this quote, the retreat. "The retreat challenged the narrative that AI eliminates the need for junior developers. Juniors are more profitable than they ever have been. AI tools get them past the awkward initial net negative phase faster. [52:52]
-
-They serve as a call option on future productivity and they are better at AI tools than senior engineers, having never developed the habits and assumptions at slow adoption." [53:09]
-
-I'll say call option is a financial term. Calls versus puts are options to buy or sell. [53:17]
-
-**Mo:** I cannot believe they call junior developers call options. [53:24]
-
-**Carl:** I know it like, oh, it's so like do we in the weeds jargoning, but also like, yeah, sure. A call option is when you say it's you're buying a futures contractor saying, I think this is going to be worth more of the future, and other people disagree, so I'm gonna buy it now. [53:27]
-
-**Mark:** Bet that it goes up over time. [53:43]
-
-**Carl:** Exactly. So like, it is actually a very good analogy here, but like, I don't know, maybe don't reduce the employment of early career people to a financial instrument. Like it's not great. People are more complicated. [53:45]
-
-**Mo:** Yeah. [53:58]
-
-**Carl:** This is such a like, antidote to the doomerism, I think. Like, yeah, they haven't learned the bad habits. [53:58]
-
-They aren't so deep in the weeds as the senior developers are that they're going to like micromanage and just kinda let it do the thing because it's act, the tool is actually very smart. So that's, uh, yeah, like this, [54:04]
-
-**Mo:** I can see that that's the direction they're trying to point this at. At the same, to play, uh, a devil's advocate to that point, the job market seems to be saying something very different. [54:17]
-
-So I'll put a screenshot of this from a study that was released by some Harvard folks. I'll put that, but I'll, I'll link the actual study itself and. This is basically showing sort of like the demand in the job market in the US for senior and junior profiles since the launch of chat GPT. So we're talking sort of 20, 23 time and someone coined this as sort of like a K based was talking about this as like the K based or K shaped feature of software engineering. [54:27]
-
-And there is a dip and it is a hard market at the moment for juniors. So I'm interested how this pans out for junior developers. [54:59]
-
-**Carl:** Yeah. I will say though, y'all listening cannot see this chart. It's got a blue line for seniors and a red line for juniors and it charts the average employment like percentage change. [55:08]
-
-This is a delta, the chart is of the first derivative of employment, I guess it's, you know, rate of change. So a higher number is not only more, but it means that it's accelerating faster. And the blue line, the senior developer line is steady improvement. So it means that it's actually, it's not just improving, it's actually accelerating and how fast it's improving. [55:21]
-
-I believe that's, I believe that's what this is saying. Whereas the junior line matches it, oh, I guess the X axis here is 2015 to 2025. The lines are pretty well paired from 2015 to 2020, and that's when they start diverging and like there's a dip for both. But the dip is bigger for juniors in early 2020 [55:43]
-
-**Mo:** up until sort of that 20 22, 20 23 period. [56:04]
-
-Yes, there's a dip and then it's, the junior is still like going up slightly. It's starting to bounce back, but then now going from 2023 onwards, it is headed in that direction of a downward slope. [56:08]
-
-**Carl:** My intuition matches what this ThoughtWorks quote says, that it's a force multiplier and less experienced people are actually more effective at taking advantage of it. [56:22]
-
-So that feels to me like one of those unintuitive things that hard to justify at a big company. So, I don't know. My, my, my optimism is that cool, here's a highly reputable thought leader, you know, thought leader of thought leaders saying, no, wait, junior developers have the best return on investment they've ever had. [56:32]
-
-That feels like it could turn this around. I don't know. That's interesting. [56:55]
-
-**Mark:** I, I actually really recommend that folks download the PDF report that they put together, summarizing all the different discussions they had at this retreat. There's a lot of very valuable career and industry where we headed material in there. [56:58]
-
-**Carl:** Okay. Oh, I mo I left you in suspense earlier. I said I was gonna use my favorite analogy and here it is. Two years ago I heard an analogy of AI in software compared to the introduction of spreadsheets to the field of accounting where up until the digital spreadsheet, like basically until not Excel, Excel wasn't the first, but before we had tools like Excel, the role of an accountant was basically a calculator. You know, the classic depiction in old movies of they got the green visor on and they're sitting there over a, you know, over a calculator just crunching the numbers and like that was the job. [57:13]
-
-And then you got a spreadsheet and then you put the numbers in the spreadsheet and you do some and it's done. And so there was a lot of panic about like, oh my God, this is gonna destroy the field. Like this is the work. Then now the work is just done. But like we still have accountants and they do more than ever. [57:51]
-
-So that's how I am viewing this. That's my optimistic take on it, is like, yes, it is going to totally transform it. It is going to obviate a large number of skills that are highly valued right now, and it will look different, but I don't think that's necessarily going to mean destruction. [58:07]
-
-**Mark:** I will, I will put together my obligatory plug to say that this heavily emphasizes that having baseline experience with the tools and the concepts and the abstraction so you know, where you're trying to guide it and how the stuff works will be more valuable than ever. [58:24]
-
-**Mo:** I'm hoping on that being the case, the only thing that concerns me is the likes of Zach, which was the example that we gave before where he's like, the token is my only limit. And I wonder like when we, when we went into accountants using spreadsheets, you still needed a person behind the, the sort of system to do it. [58:39]
-
-But if. These systems sort of largely become self-running, and the only limit is the tokens. Then I worry if I, I hope the analogy holds up my, like, pessimistic doomsday clock makes me worry that it might not hold up. Same thing with the tractors plowing the field analogy that I've heard a few times. I hope that this niggling that I've got inside of me is just completely doomsday and it's, it's not actually accurate. [59:00]
-
-**Carl:** No, that is fair. I think even if all the technical things goes the same direction, I think that there are environmental things that could very much alter, I don't know, the experience, the outcome. I actually, the farming one is an interesting thought because, you know, now farming, you know, per unit effort to get to grow a calorie of food, it's easier than ever, but the tooling required in order to get that benefit is more expensive than ever. [59:28]
-
-And so what I've really, what I've heard for years is that. The average, the family farm is no longer feasible because you need nine different tools that each cost three quarters of a million dollars and have expensive, you know, support contracts, because John Deere doesn't let you fix your own tools anymore. [59:57]
-
-That's very real. This is just like, so not a good thought, but hey, maybe we'll get a good regulatory environment that drives positive outcomes, [01:00:14]
-
-**Mo:** if that's what we're, if that's what we're hoping on, I am really worried. [01:00:22]
-
-**Carl:** Yeah, that's a good joke. [01:00:27]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Anyway, anyway, let's do the best Lightning rounds. Let's not do all of them. I'm not gonna do all the conferences, [01:00:28]
-
-**Mark:** okay. In no court order. [01:00:36]
-
-## [“Wall Street Raider” game modernization](https://www.wallstreetraider.com/story.html) (and uses Preact)
-
-**Mark:** That's a really good blog post or on hn someone, one guy wrote a complicated basic game back in the 1980s called Wall Street Raider, which is supposed to be the deepest, most involved simulation of the market ever, but it was a complicated text mode game and decades later, even, he barely understood how the code worked. [01:00:37]
-
-Lots of people had tried to modernize it, it all failed. And then one. Kid offered to do it and ended up building a better ui, much like a dwarf, fortress, fortress kind of a thing on top. Uh, and apparently it's even built with pre-ACT. So just the story alone is worth reading whether or not you even get around to playing the game. [01:00:56]
-
-**Carl:** Yep. Love that. [01:01:15]
-
-## [Github Stacked Diffs preview](https://x.com/jaredpalmer/status/2019817235163074881) , [faster Issues search](https://github.blog/changelog/2026-01-29-improved-search-for-github-issues-in-public-preview/)
-
-**Carl:** We talked about it a couple of times, Jared Palmer of Formic and Yup. I think. Yup. And a couple of other, you know, he's very influential in the React ecosystem has been, is now a PM at GitHub and he's working on Stack Diffs. Which are something I've been craving in GitHub for 10 years, literally. He's been teteasingittle bits of it here and there, but he, so he, he put out, he posted on Twitter that fact diffs on GitHub will start roll, rolling out to early design partners in Alpha next month. So within the next two weeks or so, some people may have access to stat fits, which is just such good news. [01:01:16]
-
-I love that so much as well as there's improved search for GitHub issues and public preview. So that's, that's pretty cool. [01:01:58]
-
-**Mark:** Which, which I've seen. It's, it's much, much snappier [01:02:05]
-
-**Carl:** Good. [01:02:07]
-
-## [Josh Comeau: Sprite animations](https://www.joshwcomeau.com/animation/sprites/)
-
-**Mark:** Everything that Josh Comeau posts is worth taking a look at because he's put so, so much care and attention into his blog posts and explanations and he did a post on Sprite animations and especially how you can do them on the web. [01:02:08]
-
-Josh is wonderful. His posts are lovely. You should read it. [01:02:21]
-
-**Carl:** Yes. Cosign. [01:02:24]
-
-## [Interop 2026](https://wpt.fyi/interop-2026), ([WebKit](https://webkit.org/blog/17818/announcing-interop-2026/), [Igalia](https://www.igalia.com/news/interop-2026.html))
-
-**Carl:** So Interop 2026, which is a cross browser initiative to make the web standard more consistently implemented across browsers, has announced their like 2023 roadmap. So the, uh, active focus areas are container style queries, CSS anchor positioning, the, uh, adder, attr() CSS function, contrast color, shape, zoom, custom highlights, dialogues, and popovers index db, which if we have a meaningful client side database, that would be great. [01:02:26]
-
-We have that, we've needed that for so long, and it's just hard to get specified. So love that Interop on a client side database. Woo. Yes, let's do it. [01:03:00]
-
-A bunch of other things that's, you know, it's a, it's a very long list. This is a site they use to track the compatibility across Chrome, edge, Firefox, and Safari. [01:03:09]
-
-It's pretty good. This is deep in the weeds, but this is like the cutting edge of browser development, so very cool. Excited to see what they, what it looks like next by the end of the year. Okay. Sounds like that's all we got now. [01:03:21]
-
-**Mark:** Plenty over time and covered plenty of items. [01:03:33]
-
-**Carl:** Yes. [01:03:35]
-
-**Mark:** Y'all got your money's worth this month. [01:03:36]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** I'm gonna put conferences in the transcript if you wanna see what's coming up. Just do look for that in a couple days. Thank you so much for joining us, everyone, as we go over time rambling about AI ranting and rambling about AI and how cool and terrifying it is. We will be back on the last Wednesday of next month here in the live stage of Reactiflux, or back in your podcast feed just as soon as we can. [01:03:38]
-
-**Mark:** Kristen, do just a, a random offshoot episode talking about how we personally do and do not use AI in our, in our own workflows. [01:03:58]
-
-**Carl:** Agreed. That's interesting. Maybe that'd be a good check-in thing to do. I dunno. Maybe we, shit we should make, we should do more community events. I, you know, introduce myself as that every month. [01:04:05]
-
-Cool. We gather sources mostly from our own tech reads and news channel nowadays, so if you see anything that you think might interesting to discuss, definitely let us know in there. Or you can also email it to us at hello@reactiflux.com. Yeah, I'll read it if you send it there. This is a show that you get value from and wanna support. [01:04:14]
-
-Best way to do so is by submitting a review wherever you listen. I have seen a couple of new ones roll in the last couple of months, and I am pleased to report that our Spotify rating is still five stars. So that's fun. Thank you. Thank you for the positive reviews. I'm glad you all appreciate it. [01:04:35]
-
-**Mark:** I can throw a really quick, cheap corporate plug replay. [01:04:50]
-
-My employer is refocusing on the time travel debugging use case, except that we have just built an MCP that Exposes a lot of our really powerful time travel analysis awesomeness to your AI agent of choice. And even in just my own dog foodie, and I've seen. You know, Claude, whatever, be able to start investigating the contents of recording and see what's going on and fix bugs that it might not have been able to fix otherwise. [01:04:53]
-
-And I'm also working on some proof of concept performance analysis stuff, digging deep into the internals of React. We would love to have folks try it out if you have questions. We've got some examples in our docs of adding the MCP and I'm also very happy to talk about how awesome it is. [01:05:18]
-
-**Carl:** Hell yeah. Dope. [01:05:33]
-
-See you next month everyone. [01:05:35]
-
-**Mo:** See y'all soon. Bye. [01:05:36]
diff --git a/src/transcripts/tmir-2026-04.md b/src/transcripts/tmir-2026-04.md
deleted file mode 100644
index 3fda37f..0000000
--- a/src/transcripts/tmir-2026-04.md
+++ /dev/null
@@ -1,596 +0,0 @@
----
-title: "Mark & Carl talk with Swizec Teller about using AI at work"
-date: 2026-04-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Swizec Teller as we discuss the state of the software engineering profession. How are we working?"
-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:26](#introductions)] Introductions
-- [[00:02:36](#what-convinced-you-ai-code-tools-were-worth-using)] What convinced you AI code tools were worth using?
-- [[00:04:24](#using-early-chatgpt-for-db-migrations-)] Using early ChatGPT for DB migrations
-- [[00:06:59](#watching-ai-use-a-command-line)] Watching AI use a command-line
-- [[00:08:16](#background-chat-agents)] Background chat agents
-- [[00:08:58](#staying-very-hands-on-while-using-ai-tools)] Staying very hands-on while using AI tools
-- [[00:11:00](#driving-ai-closely-without-reading-its-code)] Driving AI closely without reading its code
-- [[00:17:50](#marks-workflow-opencode-with-codenomad-ui-plus-idegit-ui-opus-46-on-api)] Mark's workflow; OpenCode with CodeNomad UI, plus IDE\+git UI. Opus 4.6 on API
-- [[00:20:39](#swizecs-workflow-latest-cursor-on-opus)] Swizec's workflow, latest Cursor on Opus
-- [[00:23:58](#carls-workflow-mostly-claude-code-but-looking-at-custom-orchestrators)] Carl's workflow, mostly Claude Code but looking at custom orchestrators
-- [[00:25:23](#exploring-fully-autonomous-agents)] Exploring fully autonomous agents
-- [[00:28:08](#marks-ai-debugging-work-in-react-core)] Mark's AI debugging work in React core
-- [[00:31:42](#value-of-providing-more-context)] Value of providing more context
-- [[00:33:58](#ai-owned-documentation)] AI-owned documentation
-- [[00:37:09](#using-good-engineering-practices-still-matters)] Using good engineering practices still matters?
-- [[00:40:47](#how-do-you-know-the-right-code-to-make)] How do you know the right code to make?
-- [[00:42:49](#good-communication-still-matters)] Good communication still matters
-- [[00:45:13](#what-will-review-look-like-in-the-future)] What will "review" look like in the future?
-- [[00:46:17](#automating-functionality-tests-with-deployment-practices)] Automating functionality tests with deployment practices
-- [[00:51:49](#what-behaviors-belong-to-the-agent-and-what-fundamentally-cant-be-part-of-the-agent)] What behaviors belong to the agent, and what fundamentally can't be part of the agent?
-- [[00:56:17](#impacts-of-llms-on-software-engineering)] Impacts of LLMs on software engineering?
-- [[01:03:22](#a-superpower-right-now-is-a-domain-expert-who-can-kind-of-code)] A superpower right now is a domain expert who can kind of code
-
-# This Month in React April
-
-**Carl:** Hello, everyone. Thank you for joining us for this month in React, which is not going to be particularly React heavy. [00:00:00]
-
-Mark and I have been talking for a couple of weeks now about doing a, like, bonus episode of sorts to talk about AI and how we're using it. So we are just, instead of a bonus episode, we're, we're just gonna do that for this month, for April. [00:00:06]
-
-Yeah, and apologies for last month. We had a recording problem, and we, it was completely unsalvageable, just nothing to save. Big bummer. [00:00:19]
-
-## Introductions
-
-**Carl:** But yeah, so I am Carl. I am joined this month by Mark Erickson and Swizec Teller. yeah, we're gonna talk about AI because it's been a huge part of each of our workflows for the last, like, ranging from, like, three to six months to a year or more. [00:00:26]
-
-Let's do some intros first. I guess Mark and I are reasonably well known, but I'm Carl. I am a staff level software engineer and engineering manager and community lead here at Reactiflux, where I do events like this and build code to keep the community operating. [00:00:43]
-
-**Mark:** I'm Mark Erickson. My day job is ReplayIO, where we've built a time traveling debugger for both humans and agents with ReplayMCP now available. Please check out our blog. I just put up a blog post on how Replay found a bug faster than Dan Abermov did. I am still the Redex maintainer. Honestly, I haven't done much Redux stuff in the last few months because all my brain space has been taken up with day job work. And also, I'm going around to a whole bunch of conferences this year. [00:00:58]
-
-**Swizec:** I'm Swiz. I work at Plasmidsaurus, we are a DNA sequencing as a service company. We do a lot of React for really fancy data visualizations for stuff like, "Hey, wh- how do you visualize a few million data points in the browser and make it work smooth?" Stuff like that. And these days, I'm kind of more of a manager than an IC really. [00:01:23]
-
-And I've been thinking a lot about what kind of engineers get hired these days. We've been hiring a lot and using more and more AI to write the code. [00:01:45]
-
-**Carl:** Yep. Believe that. Cool. Yeah. So we were just chatting a little bit about what shape this conversation's gonna take. Just to level set a little bit for everyone listening. [00:01:55]
-
-We're gonna start off kind of at the point of, like, what convinced us that AI was a tool worth taking seriously and, you know, getting AI pilled as it were. Go from there into how we're using it now, what problems we're using it to solve, with what tools, as well as kind of, like, what aren't we using, what don't we find useful and compelling? [00:02:04]
-
-And go from there to, like, landscape of, like, what tools are available, what's out there, where do we think it's gonna go, and then kinda close out with what do we think the impacts are gonna be on the industry more broadly. [00:02:24]
-
-## What convinced you AI code tools were worth using?
-
-**Carl:** Mark, you wanna start us off talking about what convinced you that AI was worth using? [00:02:36]
-
-**Mark:** Sure. A year ago, I was dead set that I would never, ever allow AI to write code for me. It was a fate worse than death. It was destroying my career. I refused to do it. And in fact, I actually wrote a 15,000 word blog post over the weekend that I haven't published yet that will give the long form version of this story. [00:02:41]
-
-The short form is, over the summer last year, I cautiously started using AI to explain an existing code base to me. You know, just give me some architecture docs, walk me through the data flow. And then there was a three-day period in late August that blew my mind. On a Tuesday, I asked it to write some redux unit tests for me because my brain was too tired to write actual code, and it did, and I was stunned. [00:03:02]
-
-On Wednesday, there was a node compression library that I've been trying to replace, but the alternative didn't have all the features we needed, and it's Rust-based. And I tried asking the AI to write the feature for me in the Rust library, and it did. It actually didn't quite work right, and the maintainer had to turn down the PR, but this was the first time I saw an agent actually just crank along and spit out a bunch of code and happily make a bunch of updates. [00:03:28]
-
-And I thought I had a, a good understanding of what that process looked like. And then when I saw it in person for the first time, my jaw dropped. And then on a Thursday, I needed to write some AST-based linting code. I know what ASTs are. I've used Babbel. I understand the concepts, but it's kind of complicated and fiddly, and we had a custom setup. [00:03:54]
-
-I was like, "Could this do it for me? " And it did. And it did it much faster than I could as a person. And my worldview got destroyed. [00:04:13]
-
-**Carl:** Yep. Sounds familiar. [00:04:22]
-
-## Using early ChatGPT for DB migrations
-
-**Swizec:** I mean, that, that sounds like an amazing experience. For me, the first was way back in the, uh, Stone Age where you had to talk to ChatGPT and then copy paste the output to try to run it. [00:04:24]
-
-And it was like, I think it was the holidays, and I was writing a book feeling kind of discouraged, and I was like, "I wonder how many words I'm writing per day." And it's like, I can write Python. It's not that interesting to parse a markdown file, go through, get history and see how many words you added every day. [00:04:39]
-
-Um, so I was like, "Maybe ChatGPT can just write this for me. " And I asked it, and the code, the code didn't work, but it ran. And I thought that was really cool. So I talked to it a little bit more, and we ended up with a really nice ... It was an extremely ugly code that I would never write myself. I think it ended up still taking two or three hours, but it was a lot more interesting than me doing it. [00:04:58]
-
-Um, and I ended up with a nationalization of how my, how my book is doing, and then I wrote a few more scripts like that. And then I started using it at work to write my database migrations, because- [00:05:25]
-
-**Mark:** Please tell me, was it still just the ChatGPT UI? [00:05:39]
-
-**Swizec:** It was. Uh, this was, this, this was before Copilot. I was like, "Hey, ChatGPT, I have this SQL query, please write migration." [00:05:41]
-
-And it wrote the migrations or I ended up, uh, later on just copy pasting table definitions from, like, DBR or DataGrape or whatever, go look at the current tables and be like, "I have these tables. Please write migration for ... " I think we were using Connects at the time. "Please write migration to add these columns and then copy paste back and it worked. [00:05:49]
-
-"And I was doing that for a while and it was amazing. I never wrote a migration again in my life. [00:06:13]
-
-**Carl:** Yeah. I started doing a lot more migrations because it just became so much easier to actually do them. There's such a pain, there's so mechanical. That was an early one for me too that was like ... I guess I actually had been, like, scoping my work to avoid migrations because I hate doing them so much. [00:06:18]
-
-I had a similar experience of just like, " Oh my God, this works for that. I can do so many more of them now because I don't have to do it. "Yeah, it's a little funny because actually database migrations are a big part of why my career looks the way it does, because I did, like, one in, you know, my first year as a software engineer. [00:06:34]
-
-I went," Wow, I hate this. You can't guarantee anything. There's just, you just gotta try it. "And so then I went more front end because you don't have to do database migrations on the front end. [00:06:49]
-
-## Watching AI use a command-line
-
-**Carl:** Yeah. I had a similar type of experience as Mark. I guess I, I got on it much later than you did, Swizz. Sometime around, like, August, July, August, September of last year, you know, I, I had done kind of like ChatGPT prototypes or whatever, like Claude, having it write some HTML in line and just, like, prove out a concept or write a first draft of a script, like, prove out does this work? [00:06:59]
-
-Give me off the blank page and give me something to grow from and diagnose. And then I'd been hearing people talk about Claude code, so I finally gave that a shot in, like, I think around July, August for the first time. And just watching it, you know, like, Mark, like you said, of just watching it churn through and do things and also having it be, like, native on the command line and watching it just run exactly the same Bash commands that I would to diagnose something and, like, read the files. [00:07:23]
-
-It was like, "Oh, this is doing exactly the same process I would to resolve this bug, but it's doing it five times faster than I can." That was my big, like, light switch moment of, like, "Oh, I need to take this really seriously." [00:07:54]
-
-**Swizec:** For me, it's kind of like I really hate watching it work. I've been using AI for a while doing, like," Oh, can you write this function for me? [00:08:07]
-
-## Background chat agents
-
-**Swizec:** Or can you, like, do little small things? "But my workflow really changed when Cursor launched Slack background agents. So I started in Slack, like, when you get ... Partially, I'm a PM, so I get a lot of requests that are like, " That is definitely not a priority right now. We're not gonna work on that. "But I can now go at Cursor, do the thing, and I just get a PR with the implemented small thing that I never would've taken the time to do myself. [00:08:16]
-
-And I, I find that amazing because watching it work, I think is, for me, is too distracting. [00:08:46]
-
-**Mark:** Yeah. [00:08:51]
-
-**Swizec:** So I like it when it's fully somewhere in the cloud. I don't have to worry. I just review the code when it's ready. [00:08:51]
-
-## Staying very hands-on while using AI tools
-
-**Mark:** My workflow is very hands-on and human in the loop. Like, I'm sitting there watching that thing like a hawk and having conversations with it, which I realize is not how most people are using AI at this point. [00:08:58]
-
-I think a lot of people are very much on the, in the cloud, multi-agents, how many of these th- things can be run in parallel, which I now have opinions on. Part of it is ... Well, a lot, a lot of it's the point that I'm making the draft blog post, which is understanding is still critical. And I'm a very, I'm a very firm believer in, you know, the fundamentals and understanding and building a mental model of the system. [00:09:10]
-
-And I personally, for me, I want my brain engaged. I want to be thinking through the problem, and then I'm using the agent to amplify my own abilities. Now, don't get me wrong, there's definitely been a few moments where I was, like, you know, out and about. It's like, you know, it actually would be kind of nice if I could just pull up my phone and tell an agent, go do this thing. [00:09:34]
-
-Like, I, I, don't get me wrong. I get the appeal. [00:09:54]
-
-**Carl:** Yeah. [00:09:56]
-
-**Mark:** But in terms of day-to-day development work and how I approach programming, I want my brain active, engaged, and thinking, not just handing it off to an agent. [00:09:56]
-
-**Carl:** Yeah. I hear that. I think I use it in both ways. There are a lot of things that, like you said, so it's just, like, it's not quite high priority enough to justify. [00:10:08]
-
-And that's where I'll use, like, more of a background agent. Like, you know, here's 15 one line descriptions and, like, just from the one sentence, it's clear enough what's needed. Like, you know, adjust the size of this. Add an element that controls this. Like, those are mechanical enough that it's really just, like, getting it right, making sure it compiles. I don't currently have a functioning workflow for that exactly. [00:10:20]
-
-What I'm doing right now in the last four or five weeks just, like, hasn't really been of that type of development. So I am still, day-to-day, most of what I've been doing is very much, like, the mech suit variant. You know, people talk about, like, automated versus mech suit, like robot or mech suit. [00:10:44]
-
-## Driving AI closely without reading its code
-
-**Carl:** And yeah, so I'm driving it pretty closely, but I'm not really reviewing its output very strictly. I'm, you know, I tell it to use subagents, and then every so often I'll, you know, tell it to write me a report, like, how is this working? What is it doing? Ask it some targeted questions to make sure that the mental model I have matches what's actually there. [00:11:00]
-
-But that's a little different, I think, than what you described, Mark. Like, I'm not actually, like, I don't read almost any of the code. I try and think of it more from, like, my engineering manager, tech lead, product manager hat. I do really try and sit in engineering manager/product manager role and say, like, "Okay, how did those people talk to me as an engineer? [00:11:17]
-
-Like, they were not technical. They didn't understand anything of what was being built, and yet it was their job to make sure it was functioning as intended." So that's very much how I try to think about my work now is from that perspective. It's like I, instead of reading a line of code to ensure that patterns are followed as I intended, like, set up a lint rule and then, you know, maybe it's only 80% is good, it's not gonna catch all the subtleties, but, like, my experience of working on a team is, that's kinda how it works anyway. [00:11:37]
-
-Like, if it's not captured in the lint rule, eventually it will break. Like, eventually, someone will have been onboarded and not ha- be deeply steeped in the history of the project or just be tired that day and they forget about it or whatever. So, like, that was very much my perspective as, uh, you know, when I've been a tech lead is, like, if bad code goes out, you know, the blameless postmortem, it was a process failure. [00:12:06]
-
-This should not have been permitted by the automated checks. And so that's kind of how I'm thinking about it is just remove the abstraction a little bit and guarantee the outputs and then work on automated tracking of automated evaluation of the code quality to make sure that's at a level that I need it to be. [00:12:30]
-
-**Swizec:** Yeah, same. I think that's my perspective as well. I've ... Going up into tech lead was really kind of almost broke me as an engineer because I was like, "Oh my God, all of this terrible, awful code, but it works and it's fine and everything is okay and the team just handles it. And if anything is wrong later, we just fix it. It's totally fine." [00:12:48]
-
-And I kind of treat AI the same way. I, I do a lot of driving from, like, a product perspective and for critical features or, like, super gnarly business requirements, I go into the ID and I drive it kind of like what Mark was describing, reviewing every line of code, clicking yes, et cetera. [00:13:12]
-
-But they do really well with follow-ups. Cursor gives you the wrong thing back in a Slack thread. You just say, "Ed curs- ad cursor, go fix it. " A lot of the times, those fixes are actually, "Oh, yeah. Now that I'm holding a working MVP, it doesn't actually feel right. I totally didn't even think of several features that it needs before it's useful." [00:13:29]
-
-I also really like the code review flow. I don't know exactly what we did, but we hooked it up so that you can do a PR review, like a code review for your cursor agent session. And in GitHub, you just go at cursor, fix this, or you give it information basically the same as you would with a team member, and then you just get follow-up, commits, and it fixes all the things. [00:13:49]
-
-**Carl:** That's very much been my experience as well. One of my biggest struggles as a, as an engineer is, like, I remember hearing about this sort of a stereotype of, like, give it, give this task to a junior engineer because they don't know it's impossible, you know? The sense of as you get more experienced, you get to see more of the complexity, and the complexity makes it harder to take action because you're now evaluating trade-offs instead of just kind of ignoring them because you don't know they're there. [00:14:10]
-
-And I would get so stalled into analysis paralysis and, like, what's the correct way to do this? How do you do this best? What's gonna have the best maintenance trade-offs and the lowest, you know, the tech debt and whatever? And that's just such a difficult way to actually solve, especially a novel problem. Like, if you understand a problem well, great. You can specify everything in advance. But, like, if you're working at the edge of your knowledge, at the e- edge of your understanding, then, like, you're gonna go the wrong way at first. And it's so painful to work on something for three weeks and then go like, "Oh, shit. This is just completely the wrong architecture and I need to start over." [00:14:34]
-
-But it's so much less painful now with AI because, like, great, what a wonderful learning. Let me take that, let me have it write a three-page document about what we learned, what the new problems are, go back and forth, interact with it about, like, designing a new data model and architectural, you know, process flow. [00:15:09]
-
-I actually just did this in the last, like, week. I've been benchmarking local LLMs because I want to better understand which ones work for what tasks so I can not have all of my AI usage be based on some mystery frontier model in the cloud. [00:15:28]
-
-And I just, like, you know, I started with just, like, "Hey, give me a script that will run this model. Start up a, you know, LLM server and then run prompts against it. " And then, like, that grows, "Oh, I need, I wanna be able to kill it and restart. Oh, I wanna be able to, you know, version the prompts as I change them. Oh, I need to have it, you know, run a code evaluator when I'm giving it, like, a code generation challenge." [00:15:42]
-
-Eventually, it became un- unmanageable because of the tech debt. It's, you know, it grew and expanded and I learned more about what was needed. And so I just started over and I said, "Great. This is a Python ball of mess and it sucks and I hate it." So let's talk about the architectural flow of it and now let's add some lint rules and let's rewrite it in effect. [00:16:06]
-
-So it's actually like a high quality code base with, like, resumability and scheduling and whatever. And now it's working way better and it's, like, maintainable. It's been really powerful. [00:16:26]
-
-**Mark:** I freely admit that the very hands-on style that I've got is intentionally learning. I know it's possible to go faster. [00:16:35]
-
-I know that it's possible to delegate a lot more. I am treating it much more as an extension of my IDE and keyboard than I am as a junior developer delegating the work. That's fine. I am good with that. That is what works best for me and my brain. [00:16:43]
-
-**Swizec:** You might start doing that less and less as you use it more. [00:17:01]
-
-I started with doing that a lot more, and then eventually I realized, wait a minute, I'm just clicking yes on everything and then giving it a follow-up prompt to change the things I didn't actually like, but click yes on anyway. [00:17:04]
-
-**Mark:** I certainly didn't think a year ago I would be using any of this at all. I was, I was convinced that was a red line that I would, I would never, ever cross on pain of death, and here I am. [00:17:16]
-
-But also, like, I mean, I've, I've found a workflow that I will be hopefully blogging about in the next day, next couple days that does actually work for me. And the hands-on aspect of it is what I get good results out of, and it's what fits my brain. [00:17:25]
-
-**Carl:** Well, okay, let's take that as jumping off point. Like, what tools [00:17:40]
-
-Let's do, like, super concise, just, like, list what tools and what models you're using day-to-day. [00:17:44]
-
-## Mark's workflow; OpenCode with CodeNomad UI, plus IDE\+git UI. Opus 4.6 on API
-
-**Mark:** So my, my own setup, my intro was the kilocode VS code extension with, you know, it was probably either Sunat 35 or Sonat4, whatever was available around September-ish last fall because I didn't want to go anything command line at first. I wanted to stay in a graphical environment. [00:17:50]
-
-I tried Claude Code for about a day. Tried the VSCode extension, which didn't work at all, and then I tried the command line tool, and I, I did not like it. I tried the OpenCode command line tool, also did not like it. How do y'all deal with copy paste in a command line environment? [00:18:09]
-
-So what I have now, I'm using OpenCode. My personal laptop is Windows. My work laptop is Windows, but I work in WSL. So I actually serve OpenCode from within the WSL environment, and then I use a third party web UI for OpenCode. [00:18:24]
-
-OpenCode has a very nice server client distinction. The text client is just one of the possible clients. So I found one called Code Nomad, which is very good, works great. So I actually serve Code Nomad plus OpenCode added the WSL side, and then I just hit local host whatever port in my browser on the Windows side, which also avoids any cross-platform file shenanigans as well. So I've got my chat sessions and my tabs open in the browser. That's now my development environment. [00:18:42]
-
-And then I still have VS Code open for looking at some of the diffs and editing that my ... I much prefer a Git graphical client called Fork, but it doesn't work well in Linux, so I've just stuck with the built-in VS Code stuff. I actually don't like it, but I've been too lazy to go find a better alternative. [00:19:16]
-
-Model-wise, I've basically been on whatever the latest and greatest anthropic is. We have corporate keys, da, da, da, da, da, da. [00:19:32]
-
-Also, I have somewhat intentionally tried to avoid model hopping. I don't want to be running a bunch of evals every other week and saying, "Oh, this one provides me a 3% increase in such and such a benchmark. Clearly, I need to switch my entire workflow to a different model." and granted, OpenCode does let you just pick and choose what model you want, but I'm trying to get something that's good and consistent and that I know works, not chasing the hypothetical maximum performance. [00:19:39]
-
-**Carl:** Okay. So you're, you're on OpenCode and using latest Claude Anthropic models just through API usage? [00:20:10]
-
-**Mark:** O- Opus 46, yeah. That's the other thing. Uh, it's, it's API keys, not the various, like, you know, $20, $100, $200 max plans. So I, I read about people getting the resets and it's like, I haven't do with that because I'm also not paying for it. [00:20:19]
-
-**Carl:** Right. Cool. Okay. [00:20:32]
-
-**Mark:** It's like knowledge that my experience may not be universally shared. [00:20:34]
-
-**Carl:** Okay. Yeah. [00:20:38]
-
-## Swizec's workflow, latest Cursor on Opus
-
-**Carl:** Yeah, Swizz, what's your workflow look like? I'm curious, I'm very curious about yours because I think you're by far the most advanced agent user between the three of us. [00:20:39]
-
-**Swizec:** Which is really funny because I was surprised to learn earlier this week that 97% of my code is AI because I really talked. I was like, "What?" [00:20:47]
-
-But I actually have an extremely simple setup. I use Cursor, I keep it updated to whatever the latest version. So when it pops up with, "Please update," I click the button. I think the latest Opus model or whatever it is, it's like something 4.6. I think it's an Anthropic model. We have a Team subscription, so CompanyPays gives us an infinite budget, but I think I'm actually using, like [00:20:57]
-
-It's actually funny. I don't know ... We were just talking about this today. I don't know how this happened, but on the Cursor Leaderboard, I have the second most AI usage of all of the engineers, and I have the least amount of dollars used. [00:21:25]
-
-**Carl:** Fascinating. Interesting. [00:21:40]
-
-**Swizec:** I have literally spent $25 this month. So anyway, I use Cursor, I use @cursor on Slack a lot, and I use @cursor on GitHub a lot. [00:21:41]
-
-We also use Linear, and I've started more and more delegating my linear tickets to cursor. So look at the linear ticket, be like, "Eh, I didn't write this well, add a little bit more context so that a dumb bot can know where to go fix things or what to change, and then just click delegate to cursor, and then I review the PRs." [00:21:53]
-
-That's my workflow. I try to keep it really simple and easy, because like Mark said, I'm not looking to super maximize my productivity. I'm more looking for, you know, as a manager, I'm supposed to stay on SiteQuest anyway, so this is a really good way to code between during, uh, between and during meetings when I'm supposed to be paying just like half attention. [00:22:13]
-
-**Carl:** Yeah, that's really interesting. I, I, I like that you two are like kind of two ends of the spectrum here. So as you use it as like very much in a managerial capacity, like, you know, the same as you would ping a colleague, you ping cursor instead and just say, "Hey, do look at this. " [00:22:36]
-
-**Swizec:** Yeah, pretty much. I, I've been doing that a lot. [00:22:52]
-
-**Carl:** And it's all within collaboration platforms, I guess is like a big distinction here. It's all in space- A lot of it is. Yeah. Okay. [00:22:54]
-
-**Swizec:** We're now experimenting with building like a feedback loop so that we would have a bot that Sentry sends us errors and we're thinking of having a bot that looks at those errors, figures out how to fix them, and then just issues a PR when we get, so that we could have automatic PRs- [00:23:03]
-
-**Carl:** Yeah. [00:23:20]
-
-**Swizec:** for, at least for some er- no, like, you know, probably not for super critical, crazy, important things, but there's a lot of errors that happen where it's not that important, but it's nice to fix. [00:23:20]
-
-**Carl:** Yeah, definitely. Right, the long tail of Century issues. [00:23:34]
-
-**Swizec:** But when I'm like actually hands-on coding, I use it a lot to write my tests because I know what I want to test and I can describe the situation to set up, but I hate doing the grunt work of setting up your database in just the right way to have 50 models, et cetera, [00:23:37]
-
-**Carl:** yeah. [00:23:58]
-
-## Carl's workflow, mostly Claude Code but looking at custom orchestrators
-
-**Carl:** Yeah. Okay. Interesting. I, I kind of split y'all's experience a little bit, or I'm working towards ... I feel like I'm closer to where Mark is right now and I'm trying to move towards where you are, Swiz. Yeah, I almost exclusively am using Claude code with Opus. I've played around a bit with ... Like I, I used Copilot, you know, GitHub Copilot, like once to, like, scaffold a prototype that I was experimenting with. [00:23:58]
-
-I don't like the experience of it being in a web browser. Like, something about it ... I don't know. I also don't like code spaces or, like, remote development across SSH. So, like, this may be just my own, like, biases and preferences, but I really like just ... It's right here. It's on my machine. It's an environment that I have set up. [00:24:22]
-
-I know exactly what's available to it and what's not. Just, like, I guess I've prioritized, at least in that where I'm trying to use it like a Mac suit if speeding up my own pr- individual productivity, I just want it to be predictable and understandable for myself. To me, that's very much just been Claude code with whatever defaults pretty much. [00:24:40]
-
-I've played around a little bit here and there, but yeah, I'm trying to work towards ... One of my many projects that I have in flight is a personal, like, orchestrator. So I had started out kind of my foray into, like, earnest AI focused, using it to the extent that I am now, as opposed to more limited reading every line of code, going in and editing it myself. [00:25:01]
-
-## Exploring fully autonomous agents
-
-**Carl:** That's only really been since, like, February when I started playing this AI agent game. And it's been really interesting thinking about ... Because putting an agent in a simulated world and, like, having it autonomously play a game and do so in an interesting way, you know, effectively and interestingly, really just, like, got a bunch of wheels turning in my head. [00:25:23]
-
-And so, like, Claude Code works really well for me for, like, pushing the envelope, like, expanding what a project is, what it can do, and I have really enjoyed using background agents more, like, very much like what you described to us of just, "Hey, oh, fix this. This is broken. Here's this bug." I don't currently have anything like that operational, but I did get my little personal orchestrator working for a minute. [00:25:45]
-
-It was just wor- working on the GitHub API and I just said, like, "Here's a repo, like, go, you know, read the issues, triage them, prioritize them, take a task, open a PR, and wait for me to review it. " And it worked, but I didn't give it any guardrails, so it ended up, like, redoing the same GitHub issue multiple times, or, you know, it would re-review the same PR over and over again with, like, a page and a half of a comment. And so I was like, "All right, okay, this is proof of concept, it works, but, like, clearly I need some additional things set up." [00:26:10]
-
-And I guess one, another thing I wanna say, like, kind of what you said was about, like, using Sentry Data as an input for what to work on. I think that's the frontier. Like, that's what is currently being explored. Like, how do you do that effectively? [00:26:43]
-
-**Swizec:** Yeah. You need the feedback loops. So I was reading a lot of how to build an agent papers the other day, and the main inputs are basically rag, memory, and feedback loops, and from there, it can do a lot. So Cursor, for example, Cursor Cloud agents through Slack, they actually, when they're developing the feature, they will fire up a browser and go test it, see if they can actually do the thing, and if they can't, they will then c- continue iterating. [00:26:56]
-
-And in the end, the PR doesn't just have code. It has screenshots and videos of the working feature, which is what I require from all of my engineers, and it makes reviews so much easier. And there was another ... Oh, yeah. So I think the longest I've managed to do, to have it spin when I asked it to build an entire feature. [00:27:27]
-
-So, like, I would write a maybe 200 word, two or 300 word prompt in Slack to add cursor, and it took ... I think it spent 45 minutes to come back with the working feature, and that was amazing, because I was in a meeting for that whole time, and then I just looked at the PR and gave it feedback. [00:27:47]
-
-**Carl:** Yeah. That's incredible. [00:28:06]
-
-## Mark's AI debugging work in React core
-
-**Mark:** So my day job, we're coming at it from a similar but also sort of opposite angle. We, we have built a time driver to bugger, and originally the premise was that by making a DVR style recording, you as a person can go in and do all the investigating in the lines of code and the print statements and everything else so that eventually you as a person figure out why this was broken. [00:28:08]
-
-So we shipped an MCP a couple months ago, and I've already seen some very real examples of agents being able to go in and solve bugs that they wouldn't have been able to otherwise. I actually put up a post about this a week ago. Dan Abermov had filed an actual React bug saying that the used deferred value hook sometimes fails in production, it's stuck, like a render behind. [00:28:28]
-
-And he had a repro and he said, uh, "I've had my agent try to look at it, but I can't find the answer." A month later, he comes back and files like a four-line fix deep in the guts of React Scheduler to actually fix it. And he posted on BlueSky later, and apparently what he had to do was rebuild the React Library with a bunch of console logging added so that his agent could look at the prod build and eventually trace what was going on and figure out how to fix it. [00:28:52]
-
-So I'm like, "That would be a great marketing post comparison." So I took his example, I made replay recordings of the working dev build and the failing prod build, handed them to an agent, and I said, "Here's a bug report. Here's the two replay recordings. The issue is somewhere in React. Can you find it?" took 10 minutes. [00:29:18]
-
-So I'm like, so then I'm like, okay, well now let's make it like, you know, something resembling a proper experiment. So I took the same two recordings and I spun up four simultaneous sessions with differing instructions. [00:29:38]
-
-The first one was just a basic, here's a bug report, go investigate, actually less context, the proof of concept. The second one, I gave it like a eight step investigative process to follow. The third one had a few paragraphs just naming some concepts and Reacts internals, like not even file structure, but just things like, you know, schedulers, fibers, lanes. And then the last one also explicitly listed some of the replay MCP tools we have available. [00:29:50]
-
-All four of the sessions found the same bug and suggested the correct fix. They took respectively 28, 17, eight, and seven minutes. So on the one hand, you know, ob- obligatory sales pitch, replay recording, finding bugs, it's awesome, it's great. We're building some cool stuff with it. But it also showed me a lot about the value of the prompts and the context that you give. [00:30:18]
-
-There was another example I was working on where someone had made a, an example NextJS app with some example bugs in it and was asking an agent to find them. And in one of them, there's a, there's a double loading screen that's caused by mixing and matching suspense and Tanstack query loading state. [00:30:44]
-
-The AI always suggests the use suspense query hook, but apparently if you do that, it leads to a hydration mismatch error. And the real answer is to do some server pre-fetching instead. So like you have to think bigger, think architecturally. So I did the same thing. I tried, you know, making some re- replay recordings and feeding in the, the varying instructions. [00:31:00]
-
-My agents mostly got the same base level used suspense query error. And then I tried one more session where I fed in the NextJS and TanStack query skills files. And now the agent actually said, "Well, useSuspense query is the initial fix, but you really ought to do server pre-fetching instead." [00:31:21]
-
-## Value of providing more context
-
-**Mark:** So again, like that, that taught me a lot about the proper context. That also says a lot as we're trying to build our own CI debugging agent that looks at test recordings, so clearly we need to give it, you know, good prompts, user-based context, all that kind of stuff. [00:31:42]
-
-So, I mean, I think even something like that can maybe help explain some of the differences and results that different people get. [00:31:59]
-
-**Carl:** Yeah, no, the impact of prompting and available context is, like, so massive. As we're talking workflow, something I do very regularly is, you know, start with a prompt, start with, like, if I'm gonna add a new feature or redesign something or what, you know, a large task, not a bug fix, you know, a sprints project, not a ticket, then I'll start off with, like, a 200-word, like, prompt of, like, "Here's what we're trying to build. [00:32:05]
-
-Here's how I think we will need to do it. Here's a couple of parts that I think are gonna be important." You know, you know, have it explore, do the implementation, review, you know, and then I manually confirm. And then I'll tell it, like ... And I guess I'll do this at a couple of points throughout as it's exploring and, like, evaluating things. [00:32:32]
-
-I'll ask it, like, "How was the documentation? Like, did you find everything you needed?" And that has been, like, totally transformative for, I think for token usage as well, because, like, just by asking that, it'll say, like, "Oh yeah, it was all ... Here's the three files I referenced and I got everything I needed." [00:32:47]
-
-Or, like, "Oh, yeah, this file was out of date. You know, I did the wrong thing at first and then I had to go back and rework it. " So I'd recommend that we update this" and it makes those recommendations just based off its own experience of reading the code. And so, like, just by doing that fairly regularly as the code base evolves, I manage to keep, you know, the documentation pretty well up to date. [00:33:04]
-
-**Swizec:** Are you asking it to write its findings back into documentation or are you updating the docs? [00:33:27]
-
-**Carl:** I'll read it with a skeptical eye of, you know, like, does this sound like it is a real problem or not, a real area for improvement? And then I'll just say, like, "Yeah, hey, can you update those docs?" Often, I'll come at it with a pretty clear intention of, like, we just revamped how scheduling works. Let's analyze the architectural overview document that we have and see if it's still accurate and then tell it ... [00:33:32]
-
-## AI-owned documentation
-
-**Carl:** You know, so, like, I will do some documentation specific projects with that in mind, but for the most part, yeah, just, like, ask it how the experience of the familiarizing itself with the code base is, and then give it free reign to improve that for the most part. [00:33:58]
-
-**Swizec:** Yeah. I think one thing I would be worried with that we have some people in the team experimenting with that, and they all agree that after a few iterations, like, a few weeks later or a few months later, you end up with very spaghettified documentation that's essentially just AI slob that humans definitely don't wanna read, but even the AI barely wants to look at it and read it because it just keeps getting low, lower and lower signal. [00:34:13]
-
-So I think ... I don't have a solution for that, but it's a thing I've heard. [00:34:40]
-
-**Carl:** That's fair. I haven't really evaluated that recently. I did come at it with trying to say, like, "Here's five documents at these levels of abstraction in the code base." So I do try to give it a little bit of overall stru- structural guidance, but that's a good thing to, that's a good thing to look out for. [00:34:45]
-
-I haven't really evaluated it. That's also how I get my own mental model of the code. So I guess, like, I don't necessarily write it, but I will read it, and if it's nonsense spaghetti, then it's like, "No, we gotta do this again." Like- [00:35:03]
-
-**Mark:** That also ties into the longer term memory question. So, you know, the problem is ev- every session is fresh. [00:35:15]
-
-It knows nothing, you know, every, literally everything is being injected, you know, agents, MD, you know, whatever rules, files, et cetera. So how does an agent even know that you have these nice architectural docs that you've been keeping up to date? Or how does it know that, you know, last week, a week earlier, whatever, you made these particular decisions, and that's why we ended up here. [00:35:22]
-
-Or it has no idea what any of your code base is. Let's go read 30 files to re- form a brand new, fresh set of memories that compress the context. And some of this can be, can be dealt with partially. There's ... I, I, I highly recommend tools that will do AST-based scanning of the code base and preferring those for what, for loading chunks of code rather than just, like, blindly whatever built-in read file tools are there. [00:35:46]
-
-But that is actually where I'm running into the limits of my own personal workflow right now. I have, you know, dozens of feature and research docs that I've generated. I have daily progress docs. I have sub-task handoff docs. There's a lot of very valuable information in there, and the AI has absolutely no clue that any of that exists. [00:36:14]
-
-So I'm n- I'm now f- starting to feel the need that I need to have some kind of, you know, review sweep process, some kind of tool to, you know, index the markdown file, something to form that longer term memory structure, and I keep bookmarking hundreds of tools and saying I'm gonna go investigate them and haven't done so yet. [00:36:37]
-
-**Swizec:** If only you had a tool that's really good at summarizing large pieces of text. [00:36:56]
-
-**Mark:** I, no, I, I actually have done some of that. Um, I just haven't actually settled on one and tried installing it yet. [00:37:03]
-
-## Using good engineering practices still matters?
-
-**Swizec:** One thing I found also really helps for context and stuff like that is actually structuring your code well. So having a vertically oriented architecture, small balls of mud that are self-contained rather than one large horizontally sliced ball of mud makes it easier for humans, and it also really works for the AI when you can say, "Go add a feature to this directory." [00:37:09]
-
-And it's the, like, basically use your directory structure as an index for where to find different kinds of code. [00:37:36]
-
-**Mark:** That sounds suspiciously like software engineering practices, and I was told those don't apply anymore. [00:37:44]
-
-**Carl:** Yeah, right. Like, the main thing that I've been trying to keep in mind here of using it, and, and this was, this kind of talk goes back to your recent blog post of, you know, where you talk about how much code A- AI is writing for you, and to just talk to it like, these models were trained on things like GitHub discussions and PR reviews and code comments and whatever. So, like, it's not some new, esoteric, crazy, unpredictable thing. Like, the more you talk to it, just like it's a competent engineer, the more it will behave like a competent engineer. [00:37:50]
-
-And so it has all of these assumptions about, you know, social norms within the context of, you know, text documents describing code and documentation. And so the, the more you understand the social norms that it are deeply baked into its training, the better it does. So, like, yeah, like, I saw these, you know, memory startups where it's like, "Oh, we will automatically generate documentation for your code base and make sure it's up to date." [00:38:22]
-
-And it's like, I'm already doing that with a Read Me document tagged with a GitHash of how, when it was last updated for free. Like, if you have a couple of folders, a couple of directories full of code that is, like, pretty well isolated with a Read Me document in there, like, I don't need to tell the AI to look for the Read Me because it knows to do that. [00:38:49]
-
-Of course, it knows to look for a Read Me. So there's definitely a lot of difficulty with keeping the signal high, but, like, that's not new. I don't know. Like, that just sounds so much to me, like, working on a team of eight engineers and, like, not everyone has the same shared context. Not everyone reads every email or every Slack message. [00:39:09]
-
-And so, like, as far as the challenge of, the, the challenge of keeping a team up to date on best practices and recent decision making, versus keeping an AI at the same level, like, that, those feel really similar to me. It's just engineering best practices and communication norms. [00:39:30]
-
-**Swizec:** With, with the major difference that AI will actually go read the documents you tell, you ask it to read. [00:39:50]
-
-**Carl:** Right, right. Like, one of my, like, you know, war stories was I was a contractor somewhere and they kept having, I kept having to do a rework because, you know, QA was overwhelmed and, like, you know, they finally get around to reviewing PRs and, oh, it's broken. Oh, gotta go back. Oh, there's all these conflicts now because [00:39:57]
-
-And so, like, despite being a contractor, I sat down. It's like, no, we need to fix our review process. We need to fix our merges and whatever. Spent, like, two weeks doing that, get everyone on the same page, man. Next day, the, you know, tech lead employee at the company, the guy who should have been doing that process is like, "Nah, this is too much. Like, I'm just gonna force push." And he took down production. [00:40:15]
-
-So it's so it's like, uh, when people talk about AI doing stuff, it's like, "I don't know, man. Have you ever worked with engineers?" [00:40:37]
-
-## How do you know the right code to make?
-
-**Mark:** Uh, so this, this does tie into a lot of the conversations that I had last week. I, I was at both the AI engineer and React Miami conferences. [00:40:47]
-
-And the general theme of the discussions there between the talks and the people and then, you know, all the different chatter online is we built ... And I also ranted about this in my 15,000 Word unpublished blog post. We built a bunch of software development practices for people, the agile manifesto, linear issues, PR reviews that require multiple people to stamp them or, you know, as a way to share knowledge, standups, like these are all people- based processes, and it made sense when humans are the limiting factor and you have to be very intentional about making sure you're writing the correct code. [00:40:53]
-
-Like, not just does the code work, but are we even spending the time and effort on the right thing in the first place? And we now essentially have a generate infinite amounts of code button, and now we're finding out that we've moved the bottleneck further down the chain into all the verification and QA sides of things. [00:41:32]
-
-And so this shows up in, oops, GitHub is overwhelmed because we've literally 10Xed the number of PRs that are being pushed or, wait, we've got a bunch of senior engineers, but they're literally spending all their time reviewing PRs generated by the junior devs with AI, much less what happens when you have a dark factory of agents cranking out code twenty four seven and no one ever looks at it. [00:41:51]
-
-Like, we haven't figured out what the resulting processes ought to be, and one of the points I make in my blog post is that I think right now we're all operating under the assumption that there's no limit for how fast we can go, and in reality, we're gonna figure out the actual limit is maybe, like, 3X of what it used to be, but we need to, like, accept that and plan for it instead of thinking that if we shove everything in one end of the pipe simultaneously, it all comes out the other end. [00:42:15]
-
-**Swizec:** I have opinions. Um- [00:42:46]
-
-## Good communication still matters
-
-**Swizec:** Yes. I think I wanted to say first is I really like, Carl, you mentioned that you start sessions with a really long 200 word prompt that gives all the context, doesn't just tell the agent what to do, but also why it's doing it in, like, other context. Same. This turns out works really well with humans as well. [00:42:49]
-
-They give you much better work if you tell them why they're doing it or what the goal is. And sometimes if you tell, if you tell them what the goal is, they might even come back with, "Your solution is dumb. We should do this other thing instead," which, wow, can you imagine using engineers' brains for thinking, not just writing code? [00:43:08]
-
-But I think the other thing is, we are generating a lot of code, and we think the bottleneck is code review. I think there's kind of two bottlenecks. One is that when you're moving really, really fast, you have to actually be more careful about working on the right things because if you're just digging yourself into a hole faster, we just had an example recently where we broke Agile, we were like, "Oh yeah, we know what we, what we need to do. Let's just have Claude crank out 6,000 lines of code in one gigantic PR." [00:43:24]
-
-First of all, we couldn't review that, so we had to break it up into a bunch of sub-tasks and then turn that into sub-PRs. Turns out that took another extra day of work and everyone was distracted while doing this, so we weren't focusing on what we were actually supposed to be doing. So I think distraction is still bad. Multitasking is still bad. We're not as good at multitasking as we think we are. [00:43:55]
-
-And the other thing is we, when we split all of that up, we found that Cloud made a tactical mistake very early on, chose the wrong architecture for how to build something with React. And now you have a lot of code that needs a lot of rework to actually make work, and you're wasting reviewing time, you're wa- you're wasting a lot of time that could have been solved if we started with a small task to set up a small thing and talked about it, or maybe even talked about the architecture before we wrote six, 7,000 lines of code, and then just wrote the correct code the first time. [00:44:18]
-
-**Carl:** Yeah, 100%. We're hitting communication bottlenecks much faster now. Yeah, like Mark said. [00:44:54]
-
-**Mark:** Communication and thinking and planning was always the job. [00:44:59]
-
-**Carl:** Yeah. [00:45:03]
-
-**Swizec:** Yep. Except now you're running, like, 10 times faster. So if you take the wrong step or as your first step, you're just running in the opposite direction of where you wanna go, but really, really fast. [00:45:03]
-
-## What will "review" look like in the future?
-
-**Carl:** Right. Yeah. Right. It's very easy to get in extremely the wrong place in exactly the same amount of time. That touches on something I've said before in this podcast. I think that the future of, like, review is gonna be less code review. The architectural side of things is still gonna be important. Like, it's not just, does it work? [00:45:13]
-
-Does it do what you intended? You can't fully treat it as a black box. The box has to be translucent, you know, at least a little bit to avoid major architectural problems that are gonna cause a production outage or make it impossible to scale or whatever. Like, it's not all going to be, does this function. [00:45:32]
-
-But I do think, does it function is going to be a much greater part of this? My sense is that it will rely a lot less on reviewing the code so much as getting a plausible mental model of the architecture, and then it, you know, and then statically verifying that it does what's intended. So, like, my, my theory here is that we're gonna start seeing a lot more end-to-end testing and user acceptance. [00:45:49]
-
-## Automating functionality tests with deployment practices
-
-**Carl:** A thing I did recently that I haven't fully executed on yet, but ... Well, I, I did a lot of it. But so a, a project that I have, I fully rewrote the CICD so that instead of PR checks, review, approve, merge, ship, instead of, you know, that, like, trunk-based development, where every PR gets shipped individually, I move to more of a, like, Git Flow type architecture where it's like, no, here's the version. This is going to go out. Uh, here's our release candidate. And then that single release candidate gets pushed to a staging environment, and then I do the user acceptance testing of does this function as I need it to. And then once I have that, once I've done that manual testing, great. I know this code is working as I meant it to. So now I'm going to have it write a bunch of end-to-end tests to verify that it will continue to do that when I make changes. And I think that's gonna be kind of the new cycle of, like- [00:46:17]
-
-**Swizec:** I want that, but on every PR. [00:47:10]
-
-**Carl:** Yeah, right. And I guess to me, like, that's where manual testing is now the bottleneck. [00:47:12]
-
-Like, you cannot ... At the end of the day, this needs to function, this needs to solve a problem. Any code you write needs to solve a problem that real humans have. Or I guess, you know, sure, other agents or whatever. [00:47:17]
-
-**Swizec:** I've experimented with automated end-to-end testing. It doesn't quite work yet. I think the models are, or at least the models I was trying were too slow, but the idea is that instead of telling that [00:47:28]
-
-Instead of writing a test as what the features that should be there, it's more about, can the user do a thing? And then because you have a computer use model, it can look at the browser and it's automatically testing both your UX. Like, if the model can't figure out how to do what your user is supposed to be, drunk users won't figure it out either, or tired users or whatever. [00:47:39]
-
-So you just point it at the browser and you'd say, "Go, like, go place an order." And at the end of the day, as long as it can place the order it wants to place, you can keep iterating on the implementation, you can keep iterating on the design, you can keep iterating on the UX, you just get tests that are based on can the agent place an order. [00:48:03]
-
-**Carl:** Yeah. Oh, that's really interesting. That's, that's a really good variant on what I was just kind of talking about because, like, sure, static end-to-end tests that are verifying, like, this button with this test ID exists and the flow completes as expected. Like, sure, okay, it functions, but is it usable? [00:48:23]
-
-That's an interesting usability automated usability testing because that kind of goes back to what we were talk- talking about with, like, documentation and code notes. Like, just make it intuitive. Can an agent intuit how to achieve a general task? Oh, that's really interesting. [00:48:38]
-
-**Swizec:** If you've ever used VCR in Rails, that's kind of where I got the idea. [00:48:52]
-
-With VCR, you do full integration testing with calling remote APIs, but you don't wanna call them every time, so you record the responses and you keep them locally. So you then write tests against those local responses, but if the API ever changes or anything, you just regenerate them and you find all of the bugs in your code that don't fit the new, newly released API. [00:48:57]
-
-And you could do something similar with this where you have browser-based acceptance testing, and it records what it's doing so that you don't have to spend as many tokens every time. And you just d- when you change the UI, you delete it and you see if you can do the flow again. [00:49:19]
-
-**Carl:** Yeah. Totally smart. Interesting. [00:49:34]
-
-**Swizec:** Doesn't quite work yet, but that would be really cool. [00:49:36]
-
-**Carl:** We've kind of been going into this direction, but let me, like, sort of, like, you know, refocus a little bit. Like, so what do we think the current landscape of tools, of AI tools looks like? We've kind of been discussing that in, in, we've been dancing around it. And I guess where do we think it's going next? [00:49:38]
-
-**Mark:** Going or ought to go? [00:49:55]
-
-**Carl:** Either, both. Both. [00:49:57]
-
-**Mark:** My general inclination as the person who found one tool set and is stuck with, and is sticking with it and is not actively trying to change what he's doing. [00:49:58]
-
-Certainly what I'm seeing online is turning towards automate all the things, which I think is a very understandable impulse for a software developer. If you can do things once, you can do it in a loop, you can run it in parallel, you can distribute it, you can have an agent do it, et cetera. [00:50:06]
-
-And I think it kind of ties into the go as fast as possible at all costs for the purpose of going as fast as possible, direction that I see. I mean, like this bit about, you know, the dark factories, the idea that a team never even looks at the code, that it's truly all agents all the time, and all you say is, "Do something that accomplishes some goal, and you never even look at it, " is sort of an ultimate outcome of that. [00:50:21]
-
-I don't think it's a good one, but I see how it's the idea taken to a logical extreme. [00:50:48]
-
-**Carl:** I, I also have been pretty ... I found a tool and I'm sticking with it. I've been noticing Claude Code pulling in lots of ideas that I've just been thinking. Like, as it evolves, it's like, this is a productized version of how I've already been using it. [00:50:53]
-
-You know, like they added a /btw command that lets you ask a question and it will ... You cannot use tools and it does not go into the context history. So it's just like even do a little aside. Like if you wanna ask, like, "What's this thing doing?" I had already been doing that by way of, like, I'd ask it a question and then I'd go back and just, you know, restore the conversation to that. [00:51:06]
-
-And similarly, two months ago, I had been saying, like, I would actually spin up a Claude code instance that was on Haiku because I just need to summarize this and it's easier and I wanna manage my usage a little bit more precisely. And, like, now I don't have to do that because I just say, use a subagent and Claude Code is smart enough to say, "Oh, I'm just summarizing. Let me use Haiku." [00:51:27]
-
-## What behaviors belong to the agent, and what fundamentally can't be part of the agent?
-
-**Carl:** So I've just been watching, like, kind of what the agent itself is doing versus what I need to tell it to do, or proactively manage, converge a little bit. So that's, that's had me wondering, what outside of the agent, what is not going to live within the agent. And I think where I've landed on that is, like, everyone's talking about memory the last six weeks or so, and I think that's wrong. [00:51:49]
-
-I think that's just gonna be conventions and documentation. It's just knowledge. I think what's going to persistently live outside of an agent harness, as it were, is, like, incoming information, like a data stream, like GitHub issues, text, you know, the Slack chat, a Century Alert, a production alarm. If you have a data stream that is categorizing those and prioritizing them, and then giving that to an agent, to an autonomous agent that is just working, like, those are different things. [00:52:12]
-
-I think you cannot have a single generic agent that is able to connect to every possible data source. So that to me feels like a boundary that's gonna be pretty strong for the coming months. [00:52:44]
-
-**Swizec:** I don't know. I think for me, I feel like going super deep into what, at least on the internet, a lot of people are talking about various MD files and orchestrations and all the crazy stuff. [00:52:55]
-
-I feel like that's a little bit like ID skins and WIM shortcuts. It's like, yeah, sure, it's cool, but I, I think you're over complicating it. The models are gonna keep getting stronger and better, so I would just think they're gonna be able to do bigger and bigger tasks. I think feedback loops, like what you said, what is outside of the model? [00:53:06]
-
-Building really strong feedback loops is important. I think memory documentation inside the code or making the code itself easier to research or giving it MCP tools to, like, notion or linear or whatever, you keep your organizational memory. Having access to organizational memory will help agents as well. [00:53:25]
-
-Yeah. I don't think we're ever gonna come to full automation of anything, really. I think there's a strong gelman amnesia when it comes to th- these things where agents will fully automate every job except the ones I'm strict, super familiar with. That is just way too complicated and there's too many deals. [00:53:46]
-
-Everyone feels that way about their job because newsflash, they're all too complicated. [00:54:06]
-
-**Carl:** I wanna explain that reference briefly for people who aren't familiar. Gelman and Amnesia, that refers to the idea of, like, you're reading a newspaper and you see a story about your professional industry or something you're very knowledgeable about, and you see everything that it got wildly wrong, and you're like, "Who even wrote this? What are they doing? These incompetents." [00:54:11]
-
-And then you read the next article, and you're not familiar with it, and you just take it super credulously, and it's like, "Oh, yes, look at these," you know. It's a, like, I think that's a pretty good way of thinking about how people are talking about AI right now, yeah. [00:54:29]
-
-**Swizec:** And I think, from my perspective, go hard as long as you can. I think the bubble is going to collapse in the next one to two years. Tokens are gonna become super expensive, and we're not gonna use as many of these tools long-term as we are right now, but we're gonna have a lot of infrastructure, like, just like we did after the dot-com. [00:54:41]
-
-**Carl:** That's part of why I've been really interested in local models, because I agree with that. Like, they're being heavily subsidized right now, and I think in, I don't know, about two years, I don't know, we'll see. It's been very ... People are talking about it, it feels like the wheels are falling off right now with, like, Claude Code is just clamped down usage on the 20 d- $20 a month plan aggressively. [00:55:02]
-
-**Swizec:** They grew from nine billion ARR to 30 billion ARR in a quarter, so I'm imagine they have some scaling issues. [00:55:22]
-
-**Carl:** Right? Yeah, clearly. [00:55:30]
-
-**Mark:** One of the points I made in that draft blog post that I'm hoping to publish this week, the cats out of the bag, like, even if OpenAI and Anthropic were to utterly and completely collapse and go out of business today, the technology exists. [00:55:32]
-
-And whether it's, you know, boutique hosting of models or local LLMs, the technology is not going to go away. And even if it only, even if it never gets better at all, the t- the capabilities stay exactly the way they are today, it's still curly enough to upend large parts of our society. So then the question becomes, w- what are you doing with it and how do you, how do you respond? [00:55:46]
-
-**Carl:** Well, that's a good ... We should wrap up soon, but that is an excellent jumping off point for our last little subject here. [00:56:12]
-
-## Impacts of LLMs on software engineering?
-
-**Carl:** Uh, what do we think the impacts of LLMs on engineering as an industry, software engineering as an industry, and maybe more broadly, societally, if we wanna go there? [00:56:17]
-
-**Swizec:** I would say it's raising the bar for everything. [00:56:30]
-
-Like, what counts as a minimum viable product is gonna get more fancy and more complicated. What counts as a junior entry-level engineer, or what the expectations are for a junior entry-level engineer are gonna go up, and I think we're gonna need a lot more, um, product sense, and a lot less being just really good at writing code. [00:56:32]
-
-**Mark:** Yeah, I'm inclined to agree. I am honestly worried about the impacts in society as a whole. We've seen lots of debate and studies about, you know, have, have cell phones effectively destroyed the minds of youth and the ability to focus and social bul- like electronic bullying and, like, very ... Like, why did teens get very depressed starting in 2012? [00:56:54]
-
-Like, that sort of thing where a technology possibly had large-scale societal effects. And I'm not saying that LLMs are, you know, inherently destructive or inherently bad, but a lot of times the technology gets invented and then it changes society in ways we were very unable to predict early on. In this case, I think we can predict a number of ways, and there's probably a whole lot of other stuff, too. [00:57:14]
-
-So I genuinely worry about college students being able to get away without having to develop critical thinking skills even less than they were able to get away with it before. I have concerns about that sort of thing. And, you know, I'm towards the tail end of my career, I've done my thing, I learned, I gained my experience. [00:57:40]
-
-I don't know how junior devs are going to gain some of that experience. Maybe it is they need different experience. I don't know what the job pathways look like at that point. So, like, I mean, don't get me wrong, I'm excited to be able to use AI to crank out some of the things that I've had in my head. [00:57:58]
-
-I've found some of the same joy in being able to have a multi-hour flow session and build stuff just with AI editing the files instead of me and my fingers. But I can also look around and say, "Yeah, there's a bunch of unexpected consequences floating around as well." [00:58:14]
-
-**Swizec:** I mean, in terms of experience, it's not like I know how to code without a compiler, and I would definitely not enjoy coding without a, without garbage collection. [00:58:31]
-
-**Carl:** Yeah, I think that's closer to my theory on this. I think it will, you know, the societal impacts are gonna be something a lot. We'll see. I think the societal impacts will come mostly not from software engineering, so I think I don't understand those quite well enough to opine on it too much. I do care a lot about, like, sociology and economics and whatever. [00:58:41]
-
-So I do have thoughts and opinions, but I th- maybe it's a, maybe it's my Gelman new amnesia of like, I know those well enough that I'm like, "Nope, that's way too complicated. I'm not no opinion." But I think we take for granted a little bit how much we're standing on the shoulders of giants already and like, this is a big giant to climb the shoulders of for sure. [00:59:02]
-
-Like, not trying to discount that. People talk about how it's gonna change our brains and like, you know, destroy humanity and whatever. And like, I don't know, like, we kind of did a lot of that already. Like, can you navigate in your city without GPS? There's a lot of stuff that we've already lost that used to be like, canonically like, you know, you used to have a navigator. If you wanted to do a road trip, like, you would have spent a week planning a route and then, like, God help you if you miss a turn. Same thing for, like, finance and, like, the spreadsheet. I don't know, this is gonna be, this is a broad, more broadly applicable thing than any of those past technological leaps. [00:59:21]
-
-Another thing that I learned recently, going on the societal level again, there was a ... In 2023, there was an, like, international, like, literacy survey done, levels and whatever. And I think level one was can read, but struggles with, like, finding knowledge in text or, like, following multi-step instructions. [00:59:58]
-
-And 28% of Americans m- met that were, you know, were tested at that level of literacy. And, like, it said anything below level three is considered partially illiterate. And the stats were half, half- [01:00:20]
-
-**Swizec:** 54% of Americans are less than sixth grade reading level. They will not do well with LLMs. [01:00:35]
-
-**Carl:** Right. But, like, you know, we did that before LLMs. [01:00:42]
-
-That was 2023. Like, okay, sure. Like, there's gonna be weird shit going on since then now, but, like, God, we already ... Like, as far as destroying society, like, we've done a pretty good job of that without AI. [01:00:45]
-
-**Swizec:** And for context, that's 54% of adult Americans. It doesn't, like, count children and stuff. [01:00:57]
-
-**Carl:** Yeah. [01:01:03]
-
-I don't know. It's just, like, anytime I hear people talk about, like, the downfall of, like, civilization or whatever, it's like, "I don't know. Have you looked at civilization lately? It's not doing so great." So, I don't know, it is gonna be a lot. It's gonna be challenging and difficult. I guess going back to engineering, software engineering, you remember the '90s and 2000s, 2010s era, like, stereotypes of software engineers, like, it's, like, super autistic, like, zero social skills. They are a human computer. [01:01:03]
-
-And now we don't have that anymore. We, you know, democratize software engineering and now everyone does it. We've always tried to get something basically like an LLM. Like, that's what people wanted out of software engineers this whole time. So, I think it's gonna be ... I like the analogy of, like, compilers and garbage collection and stuff, because it's just a new tool. [01:01:31]
-
-It's a new level of abstraction, and now it's much further removed from the hardware. But, yeah, I don't know. People talk about, like, the d- it's gonna destroy, like, the upskilling, it's gonna destroy junior engineers, and it's, there's not gonna be any pathway in. And, like, I don't know, maybe that's true, but at the end of the day, I'm gonna end on, like, a positive thought or, like, advice. [01:01:54]
-
-Like, this is all communication. It's just more and more communication. If you wanna lock in your software engineering career, get good at communicating, get good at deeply understanding and articulating a problem, not the code, not the patterns necessarily, but, like, understand what an architecture is good at or bad at or what the performance profile of this or that are. [01:02:18]
-
-And, like, now, you don't even need to understand it at the same level. Like, I've been really excited about AI is because I have such a broad and shallow expertise, and now I can use it. Like, it used to be that I had all this, like, vague notional expertise in a wide range of stuff, and it's like, "Damn, I wish I could use that, but I would need a team of 15 people in order to be productive with this. [01:02:45]
-
-And now I don't. So, like, I don't know, that's exciting for me. And I think that's just generally exciting. So if you're just good at communicating and you learn a domain and you get good at articulating problems within that domain, then, like, I think you're gonna be fine. [01:03:08]
-
-## A superpower right now is a domain expert who can kind of code
-
-**Swizec:** I think superpower right now is if you're a domain expert who can kind of code. [01:03:22]
-
-**Carl:** There is certainly still value in, you know, greater engineering expertise and understanding how to ship stuff to production. [01:03:28]
-
-**Swizec:** At some scale, that becomes a domain expertise. [01:03:34]
-
-**Carl:** True. Yeah. Extremely true. So yeah, I don't know. [01:03:37]
-
-**Mark:** Uh, I'm excited. I [01:03:41]
-
-**Swizec:** can build more stuff. [01:03:42]
-
-**Carl:** I can build so much ... I have built so much more. [01:03:43]
-
-I've explored so many more things and gone, "Oh, this is harder than I thought. I'm gonna set it down." Instead of just never doing it and, like, fantasizing about what it could have been for years, you know? [01:03:45]
-
-**Mark:** Yeah. Same. [01:03:54]
-
-**Carl:** All right. Cool. Thank you all. Thank you both for joining me. Thank you everyone in the audience for listening. [01:03:55]
-
-Appreciate it a lot. [01:04:00]
-
-**Mark:** Hopefully this was informative. [01:04:01]
-
-**Carl:** Cool. All right. Well, this has been this month in React, quote unquote. I think we may be exploring different formats in the future because, I don't know, who's following individual software library development as closely anymore. But yeah, thanks so much for listening. [01:04:02]
-
-If this is a show that you get value from, please send it to a coworker, send it to a friend, leave us a review. And yeah, I'll see you next month. [01:04:17]
-
-**Mark:** All right. Take care. [01:04:25]
diff --git a/src/transcripts/tmir-2026-05.md b/src/transcripts/tmir-2026-05.md
deleted file mode 100644
index 9a121cd..0000000
--- a/src/transcripts/tmir-2026-05.md
+++ /dev/null
@@ -1,645 +0,0 @@
----
-title: "TMiR 2026-05: Who even is on the Core team anymore, TanStack got pwn'd bad"
-date: 2026-05-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we discuss what the heck is going on at the React Core team, how TanStack got pwn'd so badly, and how the JS ecosystem is reacting to the aftermath of the React2Shell fallout."
-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:55](#some-podcast-meta)] Some podcast meta
-- [[00:01:49](#new-releases)] New Releases
- - [[00:01:51](#ts-v7-beta)] [TS v7 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/)
- - [[00:05:15](#rolldown-10)] [Rolldown 1.0](https://voidzero.dev/posts/announcing-rolldown-1-0)
- - [[00:06:51](#fate-10)] [Fate 1.0](https://fate.technology/posts/fate-1.0)
-- [[00:09:48](#main-content)] Main Content
- - [[00:09:56](#react-core)] React Core
- - [[00:10:09](#react-team-status-after-meta-layoffs)] React team status after Meta layoffs?
- - [[00:14:59](#react-compiler-port-to-rust-still-in-progress-latest-pr)] [React Compiler port to Rust still in progress](https://x.com/poteto/status/2056865079543681329), latest [PR](https://github.com/facebook/react/pull/36173)
- - [[00:15:54](#tanner-linsley-is-projecting-react-its-definitely-not-a-fork)] [Tanner Linsley is "projecting" React](https://tannerlinsley.com/posts/projecting-react) (it's definitely not a fork)
- - [[00:21:38](#tests-are-the-new-moat)] [Tests are the new moat](https://saewitz.com/tests-are-the-new-moat)
- - [[00:23:32](#brooks-lybrand-thoughts-on-react-community-after-react-miami)] [Brooks Lybrand thoughts on React \+ community after React Miami](https://brookslybrand.com/posts/react-miami-2026.html)
- - [[00:25:04](#tanstack-is-exploring-how-to-expose-server-components)] [TanStack is exploring how to expose Server Components](https://tanstack.com/blog/react-server-components)
- - [[00:27:19](#who-owns-the-tree)] [Who Owns the Tree](https://tanstack.com/blog/who-owns-the-tree)
- - [[00:27:31](#rscs-in-tanstack)] [RSCs in TanStack](https://frontendmasters.com/blog/react-server-components-in-tanstack/)
- - [[00:28:12](#remix-v3-beta-preview)] [Remix v3 beta preview](https://remix.run/blog/remix-3-beta-preview)
- - [[00:28:35](#both-remix-and-tanstack-are-exploring-what-if-no-react)] Both Remix and TanStack are exploring "what if no React"?
- - [[00:36:11](#tsrx-a-variant-on-jsx)] [TSRX](https://tsrx.dev/), a variant on JSX
- - [[00:41:52](#security-everything-is-compromised)] Security! Everything is compromised
- - [[00:42:04](#tanstack-router-compromised-and-socket-analysis)] [TanStack Router compromised](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem), and [Socket analysis](https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack)
- - [[00:46:58](#tanstack-followup-with-followup-hardening)] [TanStack followup with followup hardening](https://tanstack.com/blog/incident-followup)
- - [[00:47:10](#nx-monorepo-tool-compromised-as-a-result)] [Nx monorepo tool compromised](https://nx.dev/blog/nx-console-v18-95-0-postmortem) as a result
- - [[00:52:02](#react2shell-recaps-from-lachlan-davidson-and-sylvie)] React2Shell recaps from [Lachlan Davidson](https://lachlan.nz/blog/the-react2shell-story/) and [Sylvie](https://sylvie.fyi/posts/react2shell/)
- - [[00:52:25](#next-1625-and-more-react-cves)] [Next 16.2.5 and more React CVEs](https://github.com/vercel/next.js/releases/tag/v16.2.5)
- - [[00:53:19](#npm-adds-staged-packages-and-e18e-adds-guidance)] [NPM adds “staged packages”](https://docs.npmjs.com/staged-publishing) and [E18E adds guidance](https://e18e.dev/docs/publishing.html#staged-packages)
- - [[00:54:50](#pnpm-11-defaults-to-min-release-age-npm-12-will-block-by-default)] [PNPM 11 defaults to min release age](https://socket.dev/blog/pnpm-11-adds-new-supply-chain-protection-defaults), NPM 12 will [block by default](https://github.com/npm/rfcs/pull/868)
- - [[00:57:59](#review-your-gh-actions-people-)] [Review your GH Actions, people!](https://github.com/e18e/ecosystem-issues/issues/266)
- - [[00:59:13](#mark-posted-his-big-ai-blog-posts-part-1-fears-and-journey)] Mark posted his big AI blog posts. [Part 1: Fears and Journey](https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-1-fears-opinions-journey/)
-- [[01:08:39](#outro)] Outro
-
-# Interview
-
-**Carl Vitullo:** Thank you for joining us. We're coming to you live from Reactiflux, the place for professional developers using React. And I am Karl. I'm a staff level product developer and freelance community leader/entrepreneur/I don't know what I am anymore, here at Reactiflux, where I do community programs like this and build some tools to help keep the community operating. [00:00:00]
-
-**Mark Erikson:** And I'm Mark. My day job is at Replay, where we've built a time traveling debugger for web apps, and that can be used by both humans and agents. And in the last couple months, I've gone between building MCP tools, doing product manager work, being a dev rel, going on vacation, and now I'm trying to figure out what I'm doing now that I'm sort of back, except that I'm going on more conference travel shortly. So it's kinda crazy right now. [00:00:19]
-
-I do Redux stuff and I collect links. [00:00:41]
-
-**Carl Vitullo:** Man, we're all doing too much stuff. It's just too many things. [00:00:43]
-
-**Mark Erikson:** Indeed. My... I, I needed that vacation. Two weeks of golf in Scotland. It was fantastic. [00:00:46]
-
-**Carl Vitullo:** Yeah, that's pretty good. Scotland's great. I love Scotland. [00:00:52]
-
-## Some podcast meta
-
-**Carl Vitullo:** Okay, let's get into it. Before we go into, like, new releases and whatever, some, like, meta discussion whatever, historically we were co-hosted by Mo, who brought us some lovely React Native and agency perspective here. He's had to step back a bit because of just, like, personal things and work busyness, and he just hasn't had the time and energy to really go up here. And I guess I, I also wanna mention, I am feeling somewhat similarly. I've been doing this for, like, three years now. I'm no longer reading React and web news at the level of intensity that I historically have been. [00:00:55]
-
-So, um, yeah. Mark and I are talking about how to continue this. This is a valuable service. I think this podcast is good. I want to keep it going. I think a once a month news check-in about the ecosystem is really valuable, so I wanna keep offering it. But, uh, that's where we're at. So just FYI, stuff is gonna change. [00:01:25]
-
-Stuff has changed. Stuff will continue to change. Just like life. [00:01:40]
-
-**Mark Erikson:** Yeah, that sounds all too real. [00:01:44]
-
-**Carl Vitullo:** We're gonna try and keep doing this, but it'll be a little different than we have. [00:01:46]
-
-## New Releases
-
-**Carl Vitullo:** But yeah, okay, into some new releases. [00:01:49]
-
-## [TS v7 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/)
-
-**Carl Vitullo:** First off, we have the TypeScript v7 beta, which is, if I recall correctly, this was gonna be the one where it's all rewritten. [00:01:51]
-
-**Mark Erikson:** This is the TS Go release, and you might also notice this is pretty hot on the heels of TS 6.0. So TS 6.0 is supposed to be the last actual release of the current written in TypeScript compiler, and 6 is the one where they changed a bunch of defaults to be more strict and better match the way JavaScript's used today. [00:02:00]
-
-7 is same settings, but completely different compiler implementation. One interesting bit here is I believe that 7.0 is not going to have a lot of the programmatic API stuff that exists right now. Uh, I think they said they hope to get that out in a 7.1. That does mean that there is definitely going to be some amount of, like, fluctuation and churn as you go upwards. [00:02:22]
-
-But in terms of just using the compiler to type check, go ahead and start using 7. Like- Cool ... right now. It's there. Okay. It's faster. It's the same logic. Use it right now. [00:02:49]
-
-**Carl Vitullo:** So that's like the SDK, like if you're using TypeScript to do some build tools, using it in JavaScript yourself, that's not feature complete yet? [00:03:00]
-
-**Mark Erikson:** Right. So yeah, so I, I don't know what all is and isn't- [00:03:09]
-
-**Carl Vitullo:** Right. I've never used that, so ... [00:03:14]
-
-**Mark Erikson:** intended to be included in the API. But like, for example, in Replay's code base, we have some programmatic linting stuff that uses the TS Morph package, and TS Morph depends on being able to import the TypeScript as a library and create- Right [00:03:15]
-
-a program instance and programmatically type check. And so that sort of thing might not fully be available in 7.0, but maybe in 7.1 in some form. [00:03:30]
-
-**Carl Vitullo:** Yeah. That makes sense. Interesting. Yeah, I mean, that stuff's always a little bit... Usually, when you're trying to use it as an SDK in that way, it's because you're doing something a little bit more finessed and complicated, so it makes sense that that takes a little more time to, to settle out. [00:03:43]
-
-**Mark Erikson:** I know that there's, in general, a lot of issues because people have reached into TypeScript's internals to im- be able to import methods that were never really intended to be exposed- Right ... to the public. [00:03:57]
-
-**Carl Vitullo:** Classic. [00:04:08]
-
-**Mark Erikson:** As well as just the fact that it's one thing when it's TypeScript importing TypeScript. [00:04:09]
-
-It's another thing when the TypeScript implementation is now in another language, Go, and so how do you expose that back to TypeScript client code, as well as how do you do so performantly, 'cause you're now crossing the language barrier? I know that's what the, like the Oxlint folks have been dealing with in terms of trying to implement typed linting, but needing to go back and forth between pieces written in different languages. [00:04:14]
-
-**Carl Vitullo:** Mm-hmm. The parallelization is interesting. I, I... Like, that's such a good reason to reach for Go, is to introduce parallelization, 'cause, like, Go routines and, you know, whatever. Go is good at that. Well, that's really cool to see that TypeScript is now doing... It says, "Now performs many ch- steps in parallel, including parsing, type checking, and emitting." [00:04:43]
-
-Anytime you can break work down into smaller units that can be isolated from each other and executed in parallel is awesome. So love seeing that being brought into TypeScript. Like, that's so core and foundational. That's awesome. [00:05:01]
-
-## [Rolldown 1.0](https://voidzero.dev/posts/announcing-rolldown-1-0)
-
-**Mark Erikson:** And then on a similar note, the Void Zero folks announced that Rolldown has hit 1.0. [00:05:15]
-
-And to recap what that is, uh, Vite had been using two different bundlers, had been using esbuild, which is fast and written in Go for development mode, and had been using Rollup, which was a written-in-TypeScript JavaScript bundler for production builds. And so in order to both make it go faster and harmonize things, you're doing both dev and prod builds with the same pipeline, they essentially re-implemented Rollup but in Rust and called it Rolldown. [00:05:20]
-
-So yet more build tools being written in Rust, and it's been a long time coming. Vite has been using Rolldown in various betas for a while. And Rolldown itself has now actually hit 1.0. [00:05:52]
-
-**Carl Vitullo:** Cool. Yeah, I was just trying to refresh my memory on... 'Cause we've, I feel like we've been talking about Rolldown 1.0 for, like, a really long time. [00:06:05]
-
-So I was like, "When was that?" It looks like we had the, there was an RC of 1.0 back in January. So, like, that's some pretty serious, you know, d- I don't know, dedication to stability and rollout. Can we just add one more, it's a suffix to roll by s- describing this as a rollout? We'll get the, the rollup, Rolldown rollout. [00:06:13]
-
-But yeah, so okay. So they've been in RC. They've had a Rolldown 1.0 RC out since January, and they're calling it good. They're shipping it. That's awesome. [00:06:32]
-
-**Mark Erikson:** Yep. Wonderful stuff. [00:06:40]
-
-**Carl Vitullo:** Love that. Great. Well, yeah, and you can, uh, listen to our January episode to see, uh, to hear us discuss that previously. [00:06:42]
-
-**Mark Erikson:** All right, and then one other release to announce. [00:06:48]
-
-## [Fate 1.0](https://fate.technology/posts/fate-1.0)
-
-**Mark Erikson:** Christoph Nakazawa has released Fate 1.0. So we, uh, we'd mentioned this a couple times previously, but Fate is a new React-based data fetching library. My closest comparison is it's kind of like a GraphQL in the sense that the client is specifying pieces of data to fetch. And to be honest, I still don't have a, have a f- really good grasp on how this works. [00:06:51]
-
-I've just seen some of the d- some of his descriptions. But it's meant to be composable queries, normalized data fetching, and integrating with React's new async and suspense-based features. My understanding is that this is very heavily... I'm not gonna say, I'm not gonna say vibe coded. I, I know he's, like, been very intentional in how he's built it. [00:07:18]
-
-My understanding is most of the actual code here was written with AI tooling, with a lot of intent behind it. [00:07:43]
-
-**Carl Vitullo:** Yeah. That's fair. I don't know. Written with AI tooling and vibe coded are not the same thing. That's interesting. I don't know. This definitely looks kinda interesting. It looks like it's trying to be something, like you said, kinda GraphQL-ish, re- relay-ish, TanStack, you know, ish. [00:07:49]
-
-But I guess, like, from first principles in the server components era- I guess is how it feels to me reading this. That's interesting. That's valuable. That's a really good exploration, but is- I don't know, something about this says r- like, research project more than something I would bet my, you know, bet my work on. [00:08:05]
-
-**Mark Erikson:** My vague sense, and this is just, you know, me eyeballing things as always, real project, not just a, an experimental toy. Early obviously, and I would assume no one else is actually using it at the moment, but it's the kind of thing that I could see getting some- Right ... amount of adoption over time. [00:08:26]
-
-**Carl Vitullo:** That's curious. [00:08:42]
-
-That's interesting. Yeah, we'll s- have to see how it goes. That's really interesting. Love having more explorations on ways to do data fetching better. I'm having thoughts come up that I know I'm also going to wanna discuss when we start talking about Remix V3 in a little bit. It's so s- funny to me how much exploration has been done over the last 15 years in, like, how do we transfer data and UI across the network? [00:08:43]
-
-We're still figuring that out. So I, I have more to say on that when we t- talk about Remix V3. But, you know, this is interesting. This looks like a valuable exploration. Christophe Nakazawa is definitely someone to take seriously. [00:09:09]
-
-**Mark Erikson:** And int- interestingly, I believe he actually joined Void Zero as a company, and his day job stuff is now around some of the, like, the Void server framework pieces that they're building. [00:09:21]
-
-**Carl Vitullo:** Oh, yeah. Interesting. He says he's product at Void Zero on his Twitter. Curious. That's cool. Very cool to see him still so, like, deeply embedded in the ecosystem, and then doing, like, little research side projects like this. Prototypes of alternate usage patterns. Cool. [00:09:32]
-
-## Main Content
-
-**Mark Erikson:** Okay, onto something resembling main content, and something resembling React core-ish stuff. [00:09:48]
-
-## React Core
-
-**Mark Erikson:** So this first bit is something that I surprisingly don't actually have much of a link for, but I'm going to try to pass on a summary of bits and pieces and conversations that I've had in multiple places. [00:09:56]
-
-## React team status after Meta layoffs?
-
-**Mark Erikson:** Loosely put, I have no idea who's even still on the React team at this point, for multiple reasons. [00:10:09]
-
-So Meta just went through two rounds of layoffs, and from watching things, I know that there was some shuffling in and around r- the React organization. For example, I think the Relay team used to be considered part of the React org, and now they're part of a separate organization. But a number of people that I know have, appear to have left the React team one way or another. [00:10:17]
-
-Uh, for example, Lauren, who'd been working on the React compiler, is now over at Cursor. I believe I saw that Sebastian Markbagha has left Vercel and is possibly not labeling himself as being part of the React team at this point. Joe Savona, who was essentially a lead on the React team for the last year or two, I heard a rumor that he has been reassigned to something else AI related. [00:10:43]
-
-These are all bits and pieces. I don't have, you know, direct links for them. But the picture I'm getting is that what we would consider the React core team has been kind of decimated. If you were to ask me right now, like, who am I pretty sure is on React core at the moment, about the only people I could still point to would be Andrew Clark at Vercel and Rick Hanlon at Meta. [00:11:11]
-
-There's still a bunch more beyond that, but just, I, I, like, I literally don't know who is working on React right now, which is not a thing I would've said last fall at React Conf. And so, this also brings up a number of other questions because Seth Webster was the head of the React org at Meta, and he also spent the last few years quietly trying to put together the React Foundation, which got announced. [00:11:34]
-
-And I've been trying to keep an eye on, you know, any news and discussion of where the foundation is. Seth himself just moved over to Expo. That was publicly announced. And I believe he's still going to be the head of the React Foundation, but I also have seen no evidence of anything as far as actual work or output from this foundation, either in terms of community involvement or events or taking over the day-to-day technical work on React itself. [00:12:00]
-
-I actually did see in a PR yesterday, Sebastian Silbermann, who is essentially part of the React Core and Core team externally at this point, did make a mention of moving repositories over to a React Foundation org, at which point they might be doing some, you know, kill and kill AI and bot spam type cleanup. [00:12:38]
-
-So all this says to me that they're, like, things are changing around React's development process, both who's doing it and where it's happening, but it also feels, just me observing things, it feels like things are fragmenting and stalling. And I actually legitimately do not know what that means in terms of technical development on React itself in the near future. [00:13:02]
-
-**Carl Vitullo:** Strange, curious, yeah. So I'm in a, I'm in a Discord for the React Foundation, and I noticed over the past several months that virtually nothing has happened in there. [00:13:28]
-
-**Mark Erikson:** There's been essentially no conversation except maybe there was a little bit of chatter about something React Native related, like a week ago. [00:13:41]
-
-**Carl Vitullo:** And I saw something about a contributors Discord as well, so I think there's a private space being set up for people who are act- actively contributing code to React Core. But I, as someone who does not contribute code to React Core, I'm not in there, and I, so I don't know exactly what's going on. I do note that the website, you know, react.dev Meet the Team, lists Sebastian, lists Lauren. [00:13:48]
-
-So it lists a number of people who are, you are saying, have been publicly confirmed as no longer- [00:14:11]
-
-**Mark Erikson:** I think Lauren may still be involved with the compiler. I don't think she, I don't think she entirely left the team, but she certainly left Meta overall. Sebastian, I got the impression he's, he's out for now, but- [00:14:16]
-
-**Carl Vitullo:** Well, certainly at least job titles are out of date, 'cause, you know, Lauren Tan says engineer at Meta, and so if she's no longer at Meta, that's wrong. [00:14:30]
-
-This website has not been updated. So yeah, oof. That's, uh, yeah, okay. Certainly lack of community engagement, I would say. [00:14:38]
-
-**Mark Erikson:** Having said that, I have spent a lot of time over the years just watching the list of PRs in the r- in the React repo, just to get a sense of what's going on, and I hadn't done that much over the last few months just because of travel and life and work and stuff. [00:14:45]
-
-## [React Compiler port to Rust still in progress](https://x.com/poteto/status/2056865079543681329), latest [PR](https://github.com/facebook/react/pull/36173)
-
-**Mark Erikson:** I was looking at it the other day, and the bulk of the PRs that I'm seeing at the moment do actually have to do with either things like updating some of the release process or, uh, some work on the React compiler port to Rust. And in fact, Lauren just confirmed on Twitter the other day, that is still actively being worked on. They are testing it out internally at Meta. I believe she's still involved in that from her side. They are trying to push that along. I do think that's gonna be a big deal for c- for a couple reasons, because eyeballing things, to me, the biggest blockers to people adopting the compiler right now are the comp- are the requirement that you still have to use Babel as part of the build process, as well as the speed of the compiler. And so if porting the React compiler to Rust makes it faster and eliminates the need for Babel, then those two roadblocks go away [00:14:59]
-
-## [Tanner Linsley is "projecting" React](https://tannerlinsley.com/posts/projecting-react) (it's definitely not a fork)
-
-**Mark Erikson:** All right, so, uh, that, that brings us up to a very interesting and somewhat controversial article, which is Tanner Linsley not quite forking React itself, projecting React. So the, the idea here is the React team has spent a lot of time over the last eight-plus years adding all these new fancy async concurrent features to React. [00:15:54]
-
-As we've talked about, they had a general vision for what they were trained to build, and they've essentially arrived at what their vision roughly was. But, you know, a lot of us are still building React apps that don't make use of the new features or don't, you know, just don't need all the capabilities that are in there. [00:16:19]
-
-But React as a package is delivered as a giant monolith. There is no option for, like, disable concurrent mode or something like that. And so all the code that implements this goes in the bundle whether you're using it or not. And that also means a lot of the logic and the checks that take up time are still in there. [00:16:37]
-
-And so Tanner actually went out and he cloned the React repo, and he told an AI essentially, "Rip out all the pieces of React that I personally do not need," and he was able to rebuild React with a lot of pieces stripped out, and it drastically shrank the bundle size, and it sped up SSR. And he is actually running his own personal website in tanstack.com on this personal modified fork of React. [00:16:59]
-
-He didn't wanna call it a fork, 'cause that term has a lot of political implications, so he called it a projection of React, in the sense of, like, projecting data or, like, viewing a subset of the data. And so technically he's made the changes available, but he is very intentionally not telling people to go try this. [00:17:32]
-
-Like, this is not Tanner saying, "I'm forking React, use my version." This is, "I played with something and if you want to look at what I did, it's over here, but I'm actually kind of telling you don't use what I did." And I've seen mixed reactions to this. I saw a number of people say, "This is a horrible idea," because, you know, LLMs can make mistakes, and if we start modifying packages, then there's the risk of introducing new bugs and security problems that w- that got handled in the original, and if you're mod-- If, basically if you're making changes, you run the risk of breaking stuff. [00:17:55]
-
-And I get that But I'm actually kind of in favor of this idea for a number of reasons. Like, code is not sacred. Code is there. A license says anyone can modify this if, you know, however they want. If Tanner wanted to fork this, that would be a totally valid thing to do morally, legally, ecosystemly. Maybe not a good idea, but it's a totally valid option. [00:18:31]
-
-But also, React exists in its current form because the React team wanted to pursue certain ideas. It's totally valid for other people in the ecosystem to say, "I would like to pursue different ideas and trade-offs and see what happens." And especially given the way that it looks like React development is kind of fragmenting and stalling slightly, I am entirely in favor of people trying to do different experiments. [00:18:55]
-
-**Carl Vitullo:** Yeah. Like, this is making me think back to some of our, some of the conversations we've had over the years at this point. And like, you know, so something that I, I've expressed pretty consistently is this sense of React as a, like, research project, pushing the envelope of what's possible with UI over the network. [00:19:24]
-
-And I think a very real tension with React versus how it's used is not everyone is trying to push the envelope of what's possible with UI over a network. Some people just want it to fucking work, and React needs to serve everyone In a way that they want. So, it... And so, you know, okay, so bringing it back to this specific blog post, Tanner Linsley projecting React, his motivation here was React's bundle size is quite large, and that's true. [00:19:42]
-
-It's quite big, and it's quite big because it's trying to do a lot of things in a generic manner for a lot of different people. And so I think there's a very real argument here that if React is trying to do five different things for five different customers, I am going to use AI to remove the code for the four customers that I am not. [00:20:14]
-
-I am only using this surface area. This surface area has pretty clearly defined contracts and testing guarantees, so I am going to rewrite this part of the surface area that I am touching. And I think that makes a ton of sense here. [00:20:38]
-
-**Mark Erikson:** Yeah, and it, it also ties into another theme that we've seen going on a lot lately, where people are taking publicly available tools, libraries, whatever, AI rewriting them to an- another entire language, but because all the tests are already there, you can verify that your rewrite is still valid. [00:20:52]
-
-And in this case, I think the risk of, you know, accidentally introducing, you know, major new bugs or security problems is a lot more limited, because you still have all the original React tests for all the functionality you care about, you're just deleting the tests and the logic for the functionality you don't care about. [00:21:11]
-
-**Carl Vitullo:** Which makes me think, we brought this in, I think, two or three months ago. Actually, it might have been the episode that we lost the audio for, come to think of it. [00:21:31]
-
-## [Tests are the new moat](https://saewitz.com/tests-are-the-new-moat)
-
-**Carl Vitullo:** But we talked about this blog post from a mutual acquaintance of ours, uh, Daniel Sawitz, Tests Are The New Moat. And I think that's what you're talking about, is, like, if the tests are out there, if you can assert that your code passes this test suite, then what's the difference between your code and their code? [00:21:47]
-
-You know? If it's behaviorally the same as guaranteed by the test suite, and you trusted the test suite to guarantee the behavior of the original, then that's fungible, in a way. That's in- you know, one thing interchangeable for the other, assuming the tests are good enough. So yeah, that's interesting. I see a comment here that I wanna bring in. [00:21:54]
-
-The risk, I think the risk is the fragmentation. Yes, sure, but, like, th- there's risk of fragmentation, but it's also, like, what risks does the fragmentation introduce? Like, fragmentation is not a risk on its own. It leads to other things. Like, if there's too many tools to maintain, then maybe it's harder to guarantee the security of any one thing. [00:22:13]
-
-But we already have that situation, as, uh, devin- as evidenced and demonstrated by all of the, you know, the Shai Hulud attacks, as evidenced by, we're gonna talk about this soon, TanStack getting compromised and 40 packages getting pwned with malicious versions published. So, like, in that sense, it's kind of safer to write your own. [00:22:34]
-
-Like, okay, sure, it's, you know, it, it, maybe it has its own vul- security vulnerabilities, but, like, you're not exposed to the supply chain risk. So I, yeah, I think the advantages are not clear-cut. [00:22:54]
-
-**Mark Erikson:** So overall, like Tanner heavily emphasized, this is an experiment. I tried it to see what would happen. I'm writing up the results of the experiment. [00:23:04]
-
-Please don't actually use this. But I actually see this as a valuable experiment. [00:23:13]
-
-**Carl Vitullo:** Yeah, I would say don't m- don't use this, but consider recreating it with something else that you find 80% good but not quite suitable. If there's a test suite, try throwing an AI tool at it. Anyway, interesting. [00:23:20]
-
-## [Brooks Lybrand thoughts on React \+ community after React Miami](https://brookslybrand.com/posts/react-miami-2026.html)
-
-**Mark Erikson:** And then one other sort of adjacent bit, which is, uh, Brooks Lybrand, who's one of the Remix React Router developers, put up a post with his thoughts on the React Miami Conference. [00:23:32]
-
-But one of the s- one of the big sections is how are people feeling about React? And some of this was, well, you know, a little bit of the enthusiasm has gone out because AI is hot and React is not. But there was also... He also specifically makes the comment that, quote, "There's basically now two Reacts," and it's kind of how using React today feels. [00:23:45]
-
-There's old style React, and then there's all the, the new fancy Async, Suspense-y stuff, and they're almost, like, two different frameworks at this point. And so it's kind of a mindset thing. [00:24:08]
-
-**Carl Vitullo:** I did read this post from Brooks. It echoes a lot of, uh, kind of what I've experienced. I don't know about the two, two Reacts part, but React Miami has been a really great conference that I've attended it for a number of years, but I haven't the last two, unfortunately. [00:24:22]
-
-And I know that this was Michelle's last year organizing it, and I wanna shout out Michelle Bakels for being a phenomenal organizer and going on to bigger and better things. [00:24:35]
-
-**Mark Erikson:** Wonderful human being, great job organizing the conference. She has put together an amazing community there. [00:24:44]
-
-**Carl Vitullo:** And I believe is now organizing or doing, like, developer relations type things for Open Code, if I'm not mistaken. [00:24:51]
-
-So yeah, do... Power to her. Wanna throw out some recognition while discussing her conference. That's what we gotta say on there. [00:24:58]
-
-## [TanStack is exploring how to expose Server Components](https://tanstack.com/blog/react-server-components)
-
-**Carl Vitullo:** Let's go into RSCs on TanStack. [00:25:04]
-
-**Mark Erikson:** We've talked a lot about server components over the last few years and, you know, which frameworks support them and how does it work. One of the biggest issues with server components is that Next.js had them first, and has had them the longest, and has been the only major way to use server components for a long time. [00:25:06]
-
-Our mental model of server components is still very much based on how does Next.js offer them in the app router. And so TanStack now has... And TanStack Start now has server component support, but they have approached it in a very different method from, from an API design and usage perspective. I've seen some of the examples. [00:25:24]
-
-I've looked at- Some of the bits and pieces I, I half understand what's going on here. But m- my rough explanation is that they allow you to do some of your own server rendering, and then you treat the response as data to the point where you, you would actually use, like, TanStack Query to fetch the dreamed data from the server, and then just sort of include the output on the client side. [00:25:47]
-
-Another way to put it is they are trained to keep TanStack Start as a client-first framework, where you very clearly say, "This piece of code runs on the server." Whereas Next in the app router is, we are starting your component tree as the server, and you have to explicitly break out and say, "This is where this..." you know, "This is a client component," et cetera. [00:26:14]
-
-So they're trained to flip the server component usage pattern up, kind of almost, like, upside down compared to how Next.js does it. And I think this is good. I see a lot of benefits here in terms of mental model and complexity, and just even just being able to read the code and say, "This code runs on the server, this code runs on the client, and I understand what's happening where." [00:26:41]
-
-**Carl Vitullo:** Yeah. That's definitely the tough part of RSCs. I applaud them for giving it a go, but that, that is a challenging problem space to be working in. [00:27:08]
-
-**Mark Erikson:** So we've, we've got a couple different posts here. [00:27:17]
-
-## [Who Owns the Tree](https://tanstack.com/blog/who-owns-the-tree)
-
-**Mark Erikson:** And the TanStack folks put up two posts on server components your way, and who owns the tree, treating server components as a protocol and not an architecture. [00:27:19]
-
-## [RSCs in TanStack](https://frontendmasters.com/blog/react-server-components-in-tanstack/)
-
-**Mark Erikson:** And then Adam Rackis did a post on Frontend Masters where he explains server components in TanStack as if you had never heard of server components before. So in other words, rather than trying to say, "Here's how it compares to Next.js," just, "Let's kind of teach this up from first principles." [00:27:31]
-
-**Carl Vitullo:** Heh. I, I appreciate that, because the other, the, um, React server components your way blog post on TanStack.com starts with, "What is, what are server components? Yeah, no, this is not a server component crash course." so okay, they got, they got both audiences covered. [00:27:51]
-
-Okay, into some stuff that we have referenced already in this episode. Some new and notable stuff in the ecosystem. [00:28:05]
-
-## [Remix v3 beta preview](https://remix.run/blog/remix-3-beta-preview)
-
-**Carl Vitullo:** Starting off, I guess, we've got Remix v3 beta preview. Beta preview, not just a beta, not just a preview It's a beta. It's a beta preview. [00:28:12]
-
-**Mark Erikson:** Isn't that called an alpha? [00:28:23]
-
-**Carl Vitullo:** I think that that does seem like an alpha, but I guess... No, I, 'cause I guess an alpha implies that it might change before a beta, so this is teasing the beta. It's not gonna change, but this is what it's gonna be. Fair enough, whatever. It's okay. It's great. [00:28:24]
-
-## Both Remix and TanStack are exploring "what if no React"?
-
-**Carl Vitullo:** Yeah, this is interesting. Th- th- so Remix is no longer a React-based framework, which it, you know, a- and I'm just kinda reflecting on the conversation we just had about TanStack projecting React. And so it seems like it, it... There's some real ecosystem appetite to do things that are not literally built upon React while being heavily, deeply inspired by. [00:28:35]
-
-And, like, a, a true, not just inspired by, but, like, a true lineage. Like, you know, it, Remix and TanStack, if both of them are looking at what it means to not bundle React, then that's a really serious evolution for them as projects that have historically bundled React. So I don't know. That's interesting. So they're announcing this Remix 3 beta preview. [00:28:57]
-
-It's a pre-release, not production ready. I guess the core argument, their, the thesis of Remix 3 is that, I guess I would say it's, their opinion here is that fra- modern frameworks try to reinvent too much of what the web platform already provides, and so they're trying to strip away some of that complexity that they view as needless on top of just, like, web standards and available, you know, protocols. [00:29:18]
-
-Which is, I'm sympathetic to that thesis. Like, I think there's a lot of stuff that React is doing that maybe it would be better for, l- or React, Next, TanStack, that may be better for the platform itself to take care of. Like, we definitely could be doing a lot more at the protocol level. Like, a thing I've been seeing people talk about like it's a brand-new fancy technology is, like, adding .md as a suffix to your URLs to make it render, you know, what would have been a HTML page in Markdown. [00:29:47]
-
-And I'm like, "We have a header for that." Like, you can do an Accepts MIME type header to say, "This accepts HTML. This accepts Markdown." Like, w- that exists. Like, you don't need to invent some new technology for that. Like, we can do that. [00:30:18]
-
-**Mark Erikson:** Okay, there's a comment in chat that says, "I do not understand what Remix 3 is." [00:30:33]
-
-Fair. Let me try to recap where we are. Remix 1 and 2 were full-stack frameworks u- that used React. They mostly introduced things like using loader functions for data fetching. But they were, they were full-stack mostly in the sense of there is a server piece included. Remix 3 is a completely new and different framework that just happens to use the same package name And it is a very different way of writing your components. [00:30:37]
-
-They also include a whole lot more stuff on the server. The blog post says they include routes, request handlers, responses, middleware, sessions, auth, forms, uploads, assets, data, database, UI components, theming, network, and tests. So in terms of what they provide, they're trying to provide a lot more out of the box. [00:31:12]
-
-In terms of the client side code, this is not React. This is a brand new framework on the client side they have invented themselves. It looks a little bit like React in some ways. There's JSX syntax. But the logic and behavior are very different. For example, instead of a useState hook, you just declare a variable in scope, inside a closure, reassign to that variable, and then you call an update method, which is what actually triggers the re-render. [00:31:32]
-
-So whereas in React, if you call setState, that both says, "Here's the new value," and tells React to re-render, whereas in Remix, you could say variable one equals A, variable two equals B, and then you call an update function to explicitly trigger it. They also have a bunch of things for mixing in behavior, like event handling and styles and things like that. [00:32:07]
-
-There's inspiration from React. There's inspiration from earlier libraries like Backbone. It, it is a very React and yet non-React-based framework. [00:32:34]
-
-**Carl Vitullo:** And I'm looking at this, you know, in this Remix III beta preview blog post, I'm looking at this small example copy to clipboard component that they show. And yeah, so Mix is what stood out to me here. [00:32:46]
-
-There's, you know, a button and it's got, like, some ARIA stuff, 'cause buttons are, need to be accessible. And then instead of, like, style or, like, class name or, you know, onClick, on, you know, handlers, n- the rest of the props basically that I would expect for a, you know, a button component to have, it has this Mix attribute which, you know, uses the same JSX, like, you know, curly braces. [00:32:58]
-
-Then the value is an array which has button.secondaryStyle and an on function which is being given, you know, onClick with a clickHandler async function here. That's interesting. So it's like, I guess, it's sort of React, but with manual updates instead of updating by reference, and it's got, like, this pseudo-functional composition style for arguments. [00:33:22]
-
-But, like, weirdly, it seems to be mixing styling and b- behavior in this Mix attribute, 'cause it's both applying the secondary button style and an onClick handler as composed mixins, I guess. So that's, I don't know. Sure, that's an opinion you can have. That's, seems fine, but it's strange. [00:33:49]
-
-**Mark Erikson:** All that to say that they've been talking for a while about how they're trying to do their own thing, and they are clearly doing their own thing. [00:34:07]
-
-And I have no idea how much adoption this will get, but can sort of squint and see some of the inspirations. [00:34:15]
-
-**Carl Vitullo:** Yeah, and somebody in chat just brought out React Router Framework, and it's like, oh yeah, they did that too. [00:34:22]
-
-**Mark Erikson:** Brian and Michael have had a lot of ideas over the last decade. [00:34:26]
-
-**Carl Vitullo:** Yeah. Boy, boy howdy, have they. [00:34:29]
-
-I guess, uh, a thing I wanna bring in, speaking about over the last decade, so a decade ago is 2016. I remember in, like, 2012, I read a blog post from Basecamp talking about how they built their UI, and it was basically componentized HTML being cached aggressively and recursively sent over the wire. And, uh, as I have been watching React evolve, it's like, oh, we're basically evol- you know, uh, progressing towards the same thing. [00:34:31]
-
-It's, you know... This f- this remix description of, like, and- advanced functions and like, you know, it's got frames, which are server-rendered HTML that you can, like, slot into your client code. And it's like, man, just, like, the number of times that I see something that, like, viscerally remind me of this thing I read in, like, like literally 15 years ago at this point, talking about sending componentized HTML over the wire in a efficient manner. [00:34:59]
-
-It's like, wow, we're still trying to do that out, uh, generally. Like, we-- I feel like that's the tension. It's not that hard to do as a one-off, but it's really hard to do with effective semantics that let you author that type of experience in a generic framework or library. So we're just still chasing that high, I guess. [00:35:26]
-
-So I don't know. That's where we're at. That's how I'm conceptualizing this Remix 3. And I, I also think of, like, Remix, you know, 'cause, like, Remix is, like, backed by Shopify and, you know, Michael and Ryan, they feel like they're in alignment with the Basecamp folks. And so it's interesting to see these, this similar set of ideas explored by a set of folks that I consider to have a generally similar set of ideas about the world. But yeah. [00:35:46]
-
-## [TSRX](https://tsrx.dev/), a variant on JSX
-
-**Mark Erikson:** And on a very, very similar note, Dominic Ganaway is someone who has worked on multiple React frameworks. He originally built his own framework called Inferno. He was part of the actual React core team for a while. I believe he then went over and worked on some of Svelte 5, maybe. [00:36:11]
-
-Someone who has a lot of experience building these frameworks. He has been working on a new framework called Ripple, which we've mentioned a, a few months ago, and one of Ripple's potential innovations was essentially an improved version of JSX syntax, and Dominic has extracted that into its own package and compiler layer called TSRX. [00:36:29]
-
-So JSX has an actual specification. It's out there. It's in a repo. It's documented. It also has not changed in a decade, and part of that is because it's embedded. There's lots of different tools that know how to parse JSX correctly and do the transformations. Trying to push through any changes to the JSX specification would be hard at this point. [00:36:56]
-
-Like, I would desperately love to have what's known as prop hunting, where, say I wanna pass my variable as a prop named My Variable. Why should I have to write My Variable equals curly braces My Variable every time? Like, that's silly. But the problem is the JSX spec says if you pass a variable name with nothing else, well, HTML treats that as a Boolean, so JSX is gonna treat that as a Boolean too. [00:37:21]
-
-And it's like, but it would be so much nicer if I didn't have to repeat myself. Can't we improve the specification? And at this point, it's not gonna happen. So Dominic has gone in and created essentially a bigger, better JSX-like language that is specifically meant for writing components in a template-ish, JavaScript-ish, TypeScript-ish sort of way. [00:37:53]
-
-**Carl Vitullo:** Agreed on, like, you cannot-- Like, changing the spec of JSX right now, like, nobody expects the spec to change, which makes it harder to actually change. Like, you know, if it had been evolving, it would be easier to continue evolving, but we have inertia saying it's fixed. So it's just tough to evolve. I'm not sure if I love this as a, you know, new DSL. [00:38:21]
-
-I have been thinking about the value of DSLs in this, you know, agent- agentic AI era that we're, you know, that we find ourselves in now. And, like, so much-- I feel like there used to be a strong argument for not changing things because you have to do this, like, educational push afterwards. You have to do the developer relations of, like, "Here's how to use the new thing," and you have to, like, yada yada. [00:38:45]
-
-And that's different now that so much of the new code is being consumed by agents. It's not an educational cycle. It's not workshops and, you know, courses and talks and conferences. It's like you update the markdown. You update the docs that the AI is reading 'cause it's an amnesiac and you have to start from zero every time you give it something. [00:39:06]
-
-That's an interesting, like, unlock for changing some of these core assumptions. Like, yes, sure, it's embedded, it's deeply embedded into the training program. But like I've been pleasantly surprised by things that I expected to be challenging because it's not deeply embedded in the training data, or it, it runs counter to things that I know are deeply embedded in the training data, like wanting to do functional patterns instead of object-oriented. [00:39:27]
-
-Because, I mean, so much code is object-oriented and it's been trained on all of the existing code. I have to say, like something like TSRX, it seems interesting to me from that lens of like... So your thesis is that JSX has rough edges and foot guns that make it less effective, less intuitive, less comprehensible for its intended purpose. [00:39:53]
-
-**Mark Erikson:** Just make a whole new thing. [00:40:16]
-
-**Carl Vitullo:** Just make a new thing. Just shave those off and call it something else so that the tools you're using to author these implementation details don't get confused about what you're using. Or, you know, have lint rules, static, you know, tools available to ensure that what they've written is valid and g- intended. [00:40:17]
-
-Ah, that's interesting. That's cool. That's useful. I don't know. [00:40:33]
-
-**Mark Erikson:** And just looking at this code snippet, a few practical examples of how this is different from JSX. So you've got a component keyword instead of the function keyword. It is statement-based, so you can have like an if statement directly in there, and then you don't do like a return anywhere. [00:40:36]
-
-It's just like if condition, key tag In other words, it, like, if that's true, you insert the P tag, but you don't have a, like, a return statement anywhere in there. Uh, and then it's also got an embedded style section as well. Another interesting thing is that this is not actually tied to a framework directly. [00:40:54]
-
-There are packages that allow you to use this with React in Preact, Ripple, Solid, and View if you really wanted to. So you could, in theory, actually drop this into a real project right now if you really wanted to use it. Did you use it? Probably not, but it's a very interesting exploration. [00:41:16]
-
-**Carl Vitullo:** Yeah, definitely really interesting. [00:41:37]
-
-**Mark Erikson:** Okay. Well, we are already almost an hour in, and we still haven't touched the security thing. So Carl, great job moving that to the end. [00:41:39]
-
-**Carl Vitullo:** I knew it. [00:41:46]
-
-**Mark Erikson:** Who knew that we would have stuff to say about everything else first? [00:41:47]
-
-**Carl Vitullo:** What? You and I have opinions? [00:41:50]
-
-## Security! Everything is compromised
-
-**Carl Vitullo:** As fucking ever, there's been a bunch of security stuff going on. TanStack Router got, like, hardcore compromised. I think it was 40-some p- compromised packages. Basically, like, all of- [00:41:52]
-
-## [TanStack Router compromised](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem), and [Socket analysis](https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack)
-
-**Mark Erikson:** The entire TanStack Router set of packages was compromised. No other TanStack libraries were compromised. So, like, Query, Start. Or, well, Start because it includes Router, but, like, the actual damaged packages were all Router related. [00:42:04]
-
-Uh, and the, the way it worked was incredibly complicated. So s- essentially, someone opened up an ex- a, an external PR that in its own depend... Like, essentially changed the package dependencies to point to some compromised poisoned versions. TanStack's CI was set up to have a shared package cache so that their CI runs would go faster. [00:42:22]
-
-Someone opened up this PR, modified it a couple times, closed it, and in the process, their poisoned packages ended up in the package cache, so that the next time one of the TanStack maintainers actually did a real PR, the poisoned packages from the cache got installed, exfiltrated credentials, and then that allowed the attacker to then publish new versions of the TanStack packages with more malicious code inside. [00:42:49]
-
-Uh, it's actually much more complicated than that, but that's roughly what happened here. [00:43:21]
-
-**Carl Vitullo:** Yeah. It's... I, I wanna see if I can pull in a couple different details without blowing up the time we spent here. [00:43:26]
-
-But, like, so they, they fork it, they obscure that it is a fork by renaming it to s- you know, configuration, so you d- it's not easy to find. [00:43:30]
-
-They publish a commit with li- you know, a malicious payload, commit it with skip CI because they know that will suppress the CI from actually executing on this push. Then- Like open a PR, update the PR so that it appears empty, then close the PR. And in doing this, they have now poisoned the cache with their malicious payload so that the next time a legitimate CI run goes, it will pull in this malicious payload instead of the intended dependency code. [00:43:39]
-
-All from a fork, that was never run, that was never actually executed, never had CI run or merged or approved. The timeline for this is they open the PR, do multiple force pushes, and then close the PR in under a minute, and that's how they poison the cache, so the next time a legitimate person ran CI, their credentials were compromised. [00:44:15]
-
-Like, that's fucking crazy. [00:44:40]
-
-They m- compromised a bit of code, organizational policies by the, by TanStack, and complex GitHub Action configuration. And all of this was ultimately enabled by the use of a PR target in their GitHub Action that is like known to be unintuitive. [00:44:42]
-
-It's known to a- allow this type of attack. But like, ah, man, what a, th- like that's, that... What a reasonable thing to miss here. That's such a complicated set of th- steps to have to do to e- execute this. [00:45:01]
-
-**Mark Erikson:** I've done a decent amount of like GitHub Actions CI config over the years for Redux. I have no idea what I'm doing. [00:45:15]
-
-I don't like writing YAML as a way to do control flow. I'm not an expert on this stuff. I'm googling examples and copy-pasting, because I genuinely have no... Like I, I roughly know here's what I want to do. I don't know how to do it. So this stuff is so easy to mess up, and GitHub Actions is frankly a, it's very complicated and it's very badly implemented. [00:45:25]
-
-**Carl Vitullo:** And it's so hard to test. Yeah. It's impossible to test some things. Like literally in, in some cases the only way to trigger the actual workflow is to do it live. And like, like you said, I'm not an expert in this. You're not an expert in this. Like nobody, almost nobody, especially in open source, is an expert in GitHub Actions. [00:45:49]
-
-Like nobody's primary job is understanding GitHub Actions, but all of us have to write GitHub Actions because that's the way that you function in this world right now. So I don't know, it's oh man, what a rough state of affairs there. We all have to do this. Nobody's that good at it, and the experience of actually authoring it is- rough. [00:46:09]
-
-It's bad. Like, it's not good. [00:46:30]
-
-**Mark Erikson:** So the postmortem is fantastic, and just for the record, I've seen a lot of corporate post-moto-mortems that were nowhere near as good as this. So kudos to the TanStack team. I know Corbin and a bunch of the others were very involved in not only trying to deal with the actual fallout here, but, like, really, really professionally follow up on here's what happened and here's how we're fixing things. [00:46:32]
-
-## [TanStack followup with followup hardening](https://tanstack.com/blog/incident-followup)
-
-**Mark Erikson:** And so they, they also put up a follow-up post with the list of things they're doing to try to make sure that nothing like this ever happens again. Unfortunately, this did have a lot of downstream consequences. [00:46:58]
-
-## [Nx monorepo tool compromised](https://nx.dev/blog/nx-console-v18-95-0-postmortem) as a result
-
-**Mark Erikson:** So, uh, the Nx monorepo tool got compromised after that because someone from the Nx team installed one of the briefly live malicious versions of TanStack packages, and that led to some credentials getting exfiltrated, which led to a malicious version of an Nx VS Code extension getting installed. [00:47:10]
-
-And then GitHub reported that someone had accessed a bunch of internal repos, quote, "Because one of our employees used a, broke a malicious VS Code extension," and I think I saw some articles indicating that it might be the Nx Console possibly. So it's possible that there were multiple chained attacks downstream, all starting from the TanStack Router compromise. [00:47:39]
-
-**Carl Vitullo:** That's fucking wild. Yeah, so, you know, like, when people tell me about, like, the risks of introducing security vulnerabilities by hand-rolling your own little tool here or there, like, oh, I don't know, GitHub got compromised by this. This sequence of events to get to GitHub is compromised, oh my God, that's absolutely wild. [00:48:05]
-
-I don't know. People talk about threat models and, like, threat actors. Like, how do you defend against what type of threat actor? Like, this attack, to me, the level of complexity and success and, like, capitalization upon their success- Says nation state actor. Like this is world-class— [00:48:24]
-
-**Mark Erikson:** And to a certain extent, like it's not even worth trying to defend against someone who's that good. When they want to find a way in, they will find a way in. [00:48:41]
-
-**Carl Vitullo:** Right. Meaningfully, in order to effectively defend against these... You know, if you think about it as like y- your available attention, you have 100% available attention, and, you know, there's that r- team, that malicious actor, 100% of their attention is on breaking you. [00:48:49]
-
-If you are not as skilled as them and dedicating the same amount of effort to countering their actions, like you can't beat them. They will overwhelm you given enough time. So like that's the complicated thing about security. You know, it's like in physical security they talk about like there is no such thing as a perfectly secure lock. A line that I'm aware of is physical access precludes all security. Like if you're doing computer security things and you are sitting in front of the machine literally [00:49:07]
-
-**Mark Erikson:** Sooner or later you will find a way in. [00:49:37]
-
-**Carl Vitullo:** It is not possible to provide security guarantees there. Yeah, you know, like if you're trying to lock down your data, if they're sitting in front of the machine, they can just blast your RAM with freezing agent so that it powers off but still holds the bit pattern physically on the chip, and then you can recover it from there. [00:49:39]
-
-I remember reading, uh, you know, proof of concept in an academic lab. Somebody had successfully exfiltrated data from a computer by using a high-sensitivity microphone from across the room and extracting the, like, buzzing pattern, the audible noise of the processor as it executed instructions. [00:49:57]
-
-Like, by listening to the processor, they were able to exfiltrate data. Like, the bar for perfect security is so high, it's incredible. Anyway, that's the last thing I'll say there. [00:50:19]
-
-Like it... So I don't know, just like when w- as you're thinking about responding to and defending against security threats, I think that's a really important context here, is that if your counterparty, if the malicious actor you're defending against is a hacking team that has been working for 25 years with the backing of a nation state national defense resources, like, sorry, you're not gonna beat them. [00:50:30]
-
-That's-- You're not an effective counter to that. Like, it's not gonna happen. So I don't know. That's an important caveat that I think all security conversations need to have is it's fucking hard. It's grim. [00:50:54]
-
-**Mark Erikson:** And then there's a, a couple more examples that I, I believe aren't even tied to the TanStack one. So Vercel got compromised, and that one appeared to be a sort of similar thing, where, like, one person was using an external tool, in this case called Context.ai. [00:51:06]
-
-That tool got compromised, and then they were able to roll through, pick up tokens, and get into Vercel's interior. And then the same people who have been doing this mini Shai-Hulud set of viruses and attacks have actually been hitting a bunch of different packages across multiple different languages and ecosystems. [00:51:26]
-
-So I mean, this, this is not like the proverbial guy in his basement. This is a bunch of very determined and sophisticated attackers. [00:51:49]
-
-Three last lit-- um, quick little bits on React-related things. [00:51:58]
-
-## React2Shell recaps from [Lachlan Davidson](https://lachlan.nz/blog/the-react2shell-story/) and [Sylvie](https://sylvie.fyi/posts/react2shell/)
-
-**Mark Erikson:** So we had the entire React to Shell vulnerability a few months ago. [00:52:02]
-
-The people who actually discovered that put up a couple of articles describing-- Like, the two primary individuals described their experience of what were they investigating, what was their process, what happened between when they found it and when it got publicly disclosed. [00:52:07]
-
-## [Next 16.2.5 and more React CVEs](https://github.com/vercel/next.js/releases/tag/v16.2.5)
-
-**Mark Erikson:** And then adjacent to that, Vercel put out a new release that appears to fix a number of new vulnerabilities and CVEs. And I know I s- w-when I saw this a couple weeks ago, I don't feel like I saw an actual blog post that accompanied this, which I found a little surprising. Maybe I just wasn't looking in the right spot, and I haven't gone back to look. But it seemed as though there were a number of new, like, denial-of-service and some authentication bypass issues found in b- in both Next and possibly Server Components again Okay. [00:52:25]
-
-One last set of things that are adjacent to this, and that's with the package publishing [00:52:59]
-
-**Carl Vitullo:** I like this 'cause it's, like, actionable. Here's things you can do to make your packages more secure. [00:53:05]
-
-**Mark Erikson:** This is aimed more at people like me who are maintaining packages rather than people who are developing applications, but hopefully this is something that will benefit all of us. [00:53:10]
-
-## [NPM adds “staged packages”](https://docs.npmjs.com/staged-publishing) and [E18E adds guidance](https://e18e.dev/docs/publishing.html#staged-packages)
-
-**Mark Erikson:** So first off, npm is adding a new concept called staged publishing. Right now, when you publish, the package goes live immediately. And so the way I understand this is once you have this set up for your packages, every new attempt to publish goes into a holding area, and then you explicitly have to go in and say, "Yes, I approve this for actually, actually, actually being released." [00:53:19]
-
-And I've, I've already seen Jovi de Crook, who works on Preact, trying to p- put together a tool that would be able to inspect package releases that are staged so that you can see what's inside them and what's changed. No idea how that works, but I c- I can see how that's been useful. So this would help for cases like the TanStack compromise because the m- modified, malicious, published versions of the package would never have gone fully live. [00:53:48]
-
-They would've gone to the staging area, and then the TanStack team would've been able to see them and say, "Wait, no, we, we didn't intend to publish those. Those should not go out." And then on the consumer side of things, so all the different package m- managers now have some kind of an option for don't install packages until they are at least N days old. [00:54:20]
-
-And they all have a different name and a different set of options for that field, but that's, that's the same concept. [00:54:44]
-
-## [PNPM 11 defaults to min release age](https://socket.dev/blog/pnpm-11-adds-new-supply-chain-protection-defaults), NPM 12 will [block by default](https://github.com/npm/rfcs/pull/868)
-
-**Mark Erikson:** So I believe pnpm 11 is defaulting to turn on that option to at least a couple days. Meanwhile, the other problem here is that packages have the post-install script, which is essentially when your package manager downloads this package and puts it in node modules, it can then run any random script that the package says it should run. [00:54:50]
-
-And that's bad because that's code that's running on your machine under your privileges and you have no idea what's happened, and it's just there because the package manager installed it. [00:55:13]
-
-**Carl Vitullo:** It's literally remote code execution. Like, yeah. [00:55:22]
-
-**Mark Erikson:** Yeah. And traditionally this has been used for things like, okay, let's figure out what operating system you have so we can download the proper native binary or build the native binary from scratch. [00:55:25]
-
-And there's alternative other better ways to do that today. So pnpm has already been denying the ability to run post-install scripts for a while. And finally, npm appears to actually be making the same change. So it looks like they're gonna start warning about package scripts that have a post-install option in the version 11 series, and npm command l- and tool version 12 will start denying those by default. [00:55:38]
-
-So we are trying to close up some of the outstanding holes in the ecosystem. So trying to make publishing packages safer, trying to make installing packages safer. [00:56:08]
-
-**Carl Vitullo:** I will say, okay, if we're talking about voluntary remote code execution, you know, where blocking post-install is a good thing to do because it's against best practice, the other- Top of mind, similar instance where we are casually expected to fetch code over the network and run it is curl piped into bash as an install tactic for things. [00:56:19]
-
-And like literally my entire career, people-- I have heard people talk about, "This is awful. We should not be doing this." Like, there are certain tools that will... I, I can't name, I can't think of any off the top of my head, but I do feel like I remember encountering this. There used to be tools that would ask you to, like, curl and then pipe it into, like, \`sudo bash\`, and, like, that's literally root access to your entire machine with arbit- code that you're not even inspecting from the network. [00:56:45]
-
-And you know who still asks you to curl pipe into bash as the recommended install method? Claude Code. Like, you go to claude.com f- and the Claude Code thing, front and center, "Built for hackers. Get Claude Code. Curl, pipe, bash." Like, that is remote code execution. Don't do it. Use a package manager. If your work is recommending that people curl and pipe into bash, advise that you respectfully and through proper channels raise the issue that That's wildly insecure. [00:57:10]
-
-It encourages remote code execution as a thing that developers will casually do. And when you casually do something like remote code execution, you end up with security vulnerabilities, like the types that we've been getting over the past year. So, ah, makes me annoyed. [00:57:42]
-
-**Mark Erikson:** And then, uh, last item. [00:57:57]
-
-## [Review your GH Actions, people!](https://github.com/e18e/ecosystem-issues/issues/266)
-
-**Mark Erikson:** So I, I, I mentioned earlier, I am not an expert on GitHub Actions. And after seeing all this stuff happen with TanStack, I, I was like, "We probably oughta do some looking at, like, the Redux actions," but I, I have no idea to what, what to even look for. The good news is that there's a number of people already working on scripts and AI prompts and other things to go inspect GitHub Actions. [00:57:59]
-
-And it's, in fact, Francois Best, who's ma- the maintainer of the Nuxt URL State library, was actually working on one himself and was asking for repos to run it on, and I, I volunteered to have him run it on the Redux repos. And it gave me a bunch of things to go correct. Like, nothing major high security, but a number of things we could do, like making sure that all the actions were pinned to a hash, changing some of the permissions options. [00:58:22]
-
-So there's a thread over in the E18E repo where they're collecting some different tools that can do scanning of GitHub Actions and try to work on hardening. And it kind of sucks that this is yet another thing that we gotta fix and we gotta make right, but guess what? It's good. You gotta fix it. [00:58:47]
-
-**Carl Vitullo:** One more thing we gotta fix. [00:59:06]
-
-That's just the rest of our existence forever. The debugging never stops. [00:59:07]
-
-**Mark Erikson:** Yeah. Okay. [00:59:12]
-
-## Mark posted his big AI blog posts. [Part 1: Fears and Journey](https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-1-fears-opinions-journey/)
-
-**Carl Vitullo:** You published your posts. [00:59:13]
-
-**Mark Erikson:** Yes, I did. So I, I hinted at this, um, a, a month ago. Long story short, little over a year ago, I was firmly against ever using AI- Yeah ... for writing code, and I was having a bit of a mental crisis over what AI is doing to the software industry and how this would affect the industry as a whole and myself personally. I ended up trying to use AI- Found it was actually useful, and now I actually end up using AI to write all my code. [00:59:15]
-
-And this has been a very long, very personal, very emotional journey for me. And I've actually now spent a lot of time configuring my own personal open code agent workflow setup, and I have a, I now have opinions on both how I set things up and the results that I'm getting. Just like I, I have act- I actually have experience now, and I, I have some preferences. [00:59:47]
-
-Also, I didn't wanna get pulled into people yelling at me for having chosen to use AI. But when I was in Miami last month, I was talking with some folks, and some of those conversations literally turned into, "Mark, what tools are you using?" And I would describe it and people were like literally taking notes, acting like I actually know what I'm talking about, which is hilarious. [01:00:13]
-
-And I'm like, "Okay, okay, fine. I've, I have been convinced to write a blog post about my own personal AI agent setup." And my brain would not let me write the technical blog post until I had written the personal experience blog post. [01:00:34]
-
-And I sat down and I wrote 12,000 words in eight hours with a brief stop for supper. And then I wrote another 3,000 words on the flight home the next day. [01:00:51]
-
-**Carl Vitullo:** I may have run that through a word count already. I can verify those numbers. [01:01:01]
-
-**Mark Erikson:** I, I... This is very different from most of my blog posts. Most of my blog posts are, "Here is a concept that I've become an expert on, let me explain this, unpack the pieces, describe how things work, and I will cite dozens of sources as references." [01:01:05]
-
-This post is none of that. This post is, "Here is my experience, my brain, my feelings, my journey." I am not trying to convince anyone. I am not trying to tell people, "This is how you should do things." this is me and my experience. [01:01:22]
-
-And I did not write this for clicks. I did not write this to, you know, change the conversation or get a bunch of views. But I've also already read hundreds of people's posts where they say, you know, I- like, "AI is killing the craft of being a programmer, and I mourn the loss of that." and that was, it, I mean, that was a really big influence on how I was feeling over the last year. So there you go. [01:01:40]
-
-There's a 15,000-word post that goes deep, deep inside my brain and my experiences and how my thought processes changed over time, and then it's got an awful lot of my opinions on where are we as an industry. And then I wrote another 6,000 words about my actual technical setup. [01:02:08]
-
-**Carl Vitullo:** Real Casual, 21,000 words. At an estimated 500 words per page, that is just about 41 pages. [01:02:27]
-
-**Mark Erikson:** People keep asking me to write books, and I'm like, "I don't write books, but I, I write the equivalent of books on my blog." [01:02:33]
-
-**Carl Vitullo:** Right. Right, right. Cool. Love that. How much of both do you think you got into the previous episode we did? [01:02:39]
-
-**Mark Erikson:** Bits and pieces. I, I don't r- Wait, you're asking me to remember what I said a month ago before my vacation? Come on. I, I talked about bits and pieces, but this went into a lot more detail. The biggest things are, like, beyond I use OpenCode, I use Opus, I use these MCP tools, et cetera, is that I've very explicitly chosen to stay very hands-on, conversational, and me driving what the agent is about to change, rather than spawning up a bunch of agents in the background to go do work and I don't care what it looks like. [01:02:45]
-
-I have seen a lot of other posts and discussion, even just in the last few weeks, with a number of people echoing similar thoughts of, "Yeah, actually, maybe we need to kind of back off and keep things at a human comprehensible amount of effort." [01:03:16]
-
-**Carl Vitullo:** Preposterous. [01:03:30]
-
-I'm kind of frustrated. I don't know. I, I feel like I'm meaningfully following the edge of the state-of-the-art in agentic development. I built a harness for myself that does some really cool... Like, three months ago, I had a harness in place that was, like, keeping track of memories and doing a dream cycle and playing a game and writing its own code. Like, writing hundreds of lines of Python so that it could more effectively play this game, and it was doing a good job. It was actually pretty interesting. [01:03:31]
-
-And I kind of shut it down 'cause, well, now, it, it, it was using \`claude -p\` to do everything- Mm ... and I realized, like, I kept working on it and I kept iterating it and I realized like, oh, you know what? Like, Claude is already doing a lot of this stuff. Claude Code is this agent. So what is, what does the orchestrator on top of the agent need to do? [01:03:59]
-
-And I have an interesting, I have a really interesting body of work that's on my GitHub that is not currently being put to use anywhere, but it's like, damn it, I'm currently at the edge of the agentic whatever stuff, but I'm doing other things that are more personally interesting to me. And, man, I want... [01:04:18]
-
-I, I have this project in place that I feel like is on par with stuff that I'm seeing people fundraise for from VC and I'm like, "Hmm, I don't wanna do that, but I do want money." So anyway, there's my, uh, there's my personal opinions around some AI stuff. I don't know. [01:04:36]
-
-I'm g- I'm gonna have to find out... We're gonna have to talk more about AI and agents and whatever, 'cause I don't know, it's crazy. [01:04:53]
-
-**Mark Erikson:** So, I don't know, adjacent thought. Like I'm, I'm, I'm in sort of a weird spot at the moment because I just got back from a combination conference plus two weeks of vacation plus conference trip. At my day job I've... [01:05:00]
-
-Prior to that, I was writing MCP tools and then playing product manager and doing product and positioning stuff, and then helping try to figure out like demos and product direction. I'm back for a couple days. I've got more conferences coming up. I've actually done very little Redux maintenance work this year, and I feel kind of bad about it, but it's 'cause a lot of my time and effort have gone into, you know, replay day job stuff. [01:05:12]
-
-I was trying to play with some of my like React Redux plus signals experiments on the way back home, and so I'm kind of getting some of that back into my brain. There's a lot of things I would like to sit down and spend time on, but I've just been running around so much and everything feels very scattered, and I don't feel like I'm focusing at the moment. [01:05:39]
-
-So I've got a couple more conferences. I've got a c- bunch of travel coming up. I don't know. Maybe I will manage to find time to actually sit down and focus on some things. [01:06:01]
-
-**Carl Vitullo:** As if. Cool. Well, I hope you do find so- some of that time. But I, I just know in my own self, any time I'm like, "Maybe I'll find time to do that thing that I want to do now," it's like, "Nah, probably not." [01:06:09]
-
-Gotta make time. Can never find time, have to make it. [01:06:21]
-
-**Mark Erikson:** I, I, I actually saw a post from Addy Osmani on Twitter just, uh, just this morning. A- Addy has written a number of really good posts lately about, you know, using agents and orchestration and, and agent anti-patterns and other things. Fine, I will, I will actually go look on Twitter and find the post rather than just describing it. [01:06:24]
-
-Uh, here, oh, here we go. It's the first thing in the history. Wonderful. Uh, this one's called, this one's called The Orchestration Tax, and the key line that stuck out for me for this one was, "Human attention is now the limiting factor. It is the single-threaded lock that you need to be aware of." And so how do you pick what is the most relevant and important thing to be spending your time on versus your agent's, blah, blah, blah, blah, blah, blah, blah? [01:06:43]
-
-**Carl Vitullo:** Right, right. The agents are good at a lot of things, but they are not good at building the right thing. You have to get them to do the right thing. That's definitely been my experience as well. I've definitely experienced the, "I can do everything. Throw 15 agents." Uh, and then you review the work and try and actually make use of it, and it's like, oh, this is making a lot of very basic assumptions that are not the assumptions I have. [01:07:10]
-
-Which I, I... One thing to say, the closer your assumptions are to the basic assumptions, the better it works in some ways. So the less creative you're being, the more effective they are. Or the more, like, s- effective they are at doing their own thing. I don't know. That, that probably says something about, I don't know, scale. [01:07:35]
-
-**Mark Erikson:** Yeah. I mean, that, that basically goes back to why I personally have chosen a workflow that is essentially just me augmented, rather than me spinning off a bunch of agents. [01:07:53]
-
-**Carl Vitullo:** True. That's why I shut my harness down and haven't had it doing stuff, is partly, largely because I haven't figured out how to put myself in the loop of their work in a way that is effective. [01:08:05]
-
-Uh, I, I had them running for, like, a day or two, and they, they did work. A lot of it was useful work, but they also did some work two or three times and left, like, page-and-a-half comments three different times on the same PR. And it's like, oh, okay, this is... The usefulness to noise ratio of this is not where I want it to be. [01:08:16]
-
-Let me revise this. And I have not revised it, because that's something I'm trying to find time for, and I cannot find any time anywhere. [01:08:33]
-
-## Outro
-
-**Mark Erikson:** All right. Well, I think we've about covered things today, and then some. [01:08:39]
-
-**Carl Vitullo:** Yep. That's pretty good. Thank you so much. [01:08:44]
-
-**Mark Erikson:** We had a number of people sticking around, which is great. [01:08:46]
-
-**Carl Vitullo:** Yeah. That's really nice. I like that I put a title in the kickoff thing this time around, and we actually had people show up. So it turns out, if you, like, care about communicating with people, sometimes people actually read and respond. What? Community building? You have to show up authentically? Ah, damn. I hate that. [01:08:48]
-
-Cool. Thank you so much for joining us, y'all in the audience who are still here 90 minutes after we started. That's awesome. Thank you, Mark, for putting together this resource on short notice. And yeah, thanks for everyone who's listening to this on the recording, uh, when I publish it in probably longer than I intend it to be. [01:09:05]
-
-Yeah. Thanks so much. We are going to be revising exactly what this podcast is, but it is useful and good, so, uh, it, it will be sticking around in some sort. If this is a resource that you find valuable and wanna help support, give us a review. Send us to a friend. Put us in the random channel of your work Slack. [01:09:22]
-
-Generally, like, I suck at marketing, I suck at distribution, so if you can help me get this in front of somebody who has never heard of it before, that is the single most helpful thing you can do. Or, I don't know, just send it to someone anyway, even if you don't care. Please, help. Yeah. Thank you so much. [01:09:40]
-
-See you next month. [01:09:55]
-
-**Mark Erikson:** Thanks. Bye. [01:09:56]
diff --git a/src/transcripts/tmir-2026-06.md b/src/transcripts/tmir-2026-06.md
deleted file mode 100644
index a99a105..0000000
--- a/src/transcripts/tmir-2026-06.md
+++ /dev/null
@@ -1,541 +0,0 @@
----
-title: "TMiR 2026-06: React Compiler is getting rusty, what does AI mean for engineering culture"
-date: 2026-06-24
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we discuss the React Compiler being rewritten in Rust, what AI development means for engineering culture, "
-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:14](#intros)] Intros
-- [[00:02:31](#new-releases)] New releases
- - [[00:02:34](#react-router-8)] [React Router 8](https://remix.run/blog/react-router-v8)
- - [[00:05:39](#babel-8)] [Babel 8](https://babeljs.io/blog/2026/06/16/8.0.0/)
- - [[00:07:15](#astro-7)] [Astro 7](https://astro.build/blog/astro-7/)
- - [[00:09:13](#ts-70-rc)] [TS 7.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)
- - [[00:09:42](#esm-only-no-programmatic-api-right-now)] ESM only, no programmatic API right now
- - [[00:10:41](#nub-js-from-zod-creator)] [Nub JS](https://nubjs.com/), from Zod creator
- - [[00:14:13](#legend-list-30-with-dom-support)] [Legend List 3.0 with DOM support](https://x.com/jmeistrich/status/2059922504320225316)
- - [[00:14:44](#tsrx-revamped-the-syntax)] [TSRX revamped the syntax](https://tsrx.dev/blog/rethinking-tsrx)
-- [[00:16:28](#react-core-news)] React Core news
- - [[00:16:32](#react-compiler-in-rust-is-rolling-out)] [React Compiler in Rust is rolling out](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x)
- - [[00:16:57](#pr-was-merged-after-testing-at-meta-and-improved)] [PR was merged after testing at Meta and improved](https://github.com/react/react/pull/36173#issuecomment-4608356402)
- - [[00:17:35](#oxlint-swc-rspack-next-all-integrating)] [Oxlint, SWC, RSPack, Next all integrating](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x%20)
- - [[00:17:50](#rolldown-tried-integrating-directly-but-removed-due-to-binary-size-increase)] [Rolldown tried integrating directly but removed due to binary size increase](https://x.com/evanyou/status/2069593612153987373)
- - [[00:18:18](#bun-tried-optimizing-the-rust-compiler-code)] [Bun tried optimizing the Rust Compiler code](https://gist.github.com/Jarred-Sumner/84df369c35216f40d61d1ea9f95771c2)
- - [[00:18:57](#other-core-improvements)] Other core improvements
- - [[00:19:17](#fragment-refs-have-been-documented-in-canary)] [Fragment Refs have been documented](https://react.dev/reference/react/Fragment#fragmentinstance) in canary
- - [[00:21:42](#react-devtools-mcp-tools-including-component-tree-and-perf-analysis-apis)] React DevTools MCP tools, including [component tree](https://github.com/react/react/pull/36597) and [perf analysis](https://github.com/react/react/pull/36598) APIs
- - [[00:22:28](#react-foundation-progress)] React Foundation progress
- - [[00:22:39](#theres-an-early-reactfoundation-website-advertising-funding-for-maintainers-and-community-groups)] There’s a(n early) [react.foundation](https://react.foundation/) website, advertising funding for maintainers and community groups
- - [[00:25:41](#theyre-gonna-have-a-booth-at-chain-react-at-the-end-of-july-)] They’re gonna have a booth at [Chain React at the end of July](https://chainreactconf.com/)
-- [[00:26:11](#why-is-meta-destroying-its-engineering-organization)] [Why is Meta destroying its engineering organization?](https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering)
-- [[00:32:46](#ai-demands-more-engineering-discipline-not-less-)] [AI demands more engineering discipline. Not less](https://charitydotwtf.substack.com/p/ai-demands-more-engineering-discipline)
-- [[00:40:51](#christoph-nakazawa-posted-his-modern-engineering-values-and-how-he-uses-ai)] Christoph Nakazawa posted his [“Modern Engineering Values” and how he uses AI](https://cpojer.net/posts/modern-engineering-values)
-- [[00:42:42](#cloudflare-bought-voidzero-)] [Cloudflare bought VoidZero](https://voidzero.dev/posts/voidzero-cloudflare)
-- [[00:43:44](#npm-security-updates)] NPM / security updates
- - [[00:43:48](#github-actions-allows-enforcing-pinned-action-shas)] [Github Actions allows enforcing pinned action SHAs](https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/)
- - [[00:44:21](#github-actions-has-a-package-manager-and-it-might-be-the-worst)] [GitHub Actions Has a Package Manager, and It Might Be the Worst](https://nesbitt.io/2025/12/06/github-actions-package-manager.html)
- - [[00:45:27](#npm-12-will-disable-install-scripts-and-git-deps-by-default)] [NPM 12 will disable install scripts and Git deps by default](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
-- [[00:46:25](#code-optimization-still-matters)] Code optimization still matters!
- - [[00:46:53](#tanstack-table-cut-memory-in-v9-by-90-on-large-lists-by-optimizing-js-objects-and-optimized-ts-perf)] [TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects](https://tanstack.com/blog/tanstack-table-v9-memory-performance) and [optimized TS perf](https://tanstack.com/blog/tanstack-table-v9-typescript-performance)
- - [[00:47:25](#pierre-diffs-was-significantly-optimized---has-to-handle-virtualization-syntax-highlighting-source-loading)] [Pierre Diffs was significantly optimized](https://pierre.computer/writing/on-rendering-diffs) - has to handle virtualization, syntax highlighting, source loading
- - [[00:48:38](#compilecat-is-a-new-optimizing-compiler-to-improve-js-execution-after-bundling-similar-to-closure-compiler-the-rspack-team-says-theyre-working-on-something-similar-)] [CompileCat is a new optimizing compiler to improve JS execution after bundling](https://github.com/isaac-mason/compilecat), similar to Closure Compiler. ([the RSPack team says they’re working on something similar](https://x.com/jiahan_c/status/2065630866668453898) )
- - [[00:51:22](#marks-react-redux-signals-draft-perf-pr-and-updated-react-redux-benchmarks-repo)] [Mark’s React-Redux \\\+ signals draft perf PR](https://github.com/reduxjs/react-redux/pull/2318) and [updated React-Redux benchmarks repo](https://github.com/reduxjs/react-redux-benchmarks)
-- [[00:52:51](#aurora-scharffs-preferred-rsc-component-architecture)] [Aurora Scharff’s preferred RSC component architecture](https://aurorascharff.no/posts/component-architecture-for-react-server-components/)
-- [[00:53:34](#lovable-projects-now-use-tanstack-start-by-default)] [Lovable projects now use TanStack Start by default](https://lovable.dev/blog/building-apps-using-tanstack-start)
-
-# This Month in React: June News Roundup
-
-**Carl:** All right. Hello. Thank you for joining us for the June edition of This Month in React. We're coming to you live from Reactiflux, the best place for professional developers using React. [00:00:05]
-
-## Intros
-
-**Carl:** I am Carl. I'm a staff product developer and freelance community leader here at, Reactiflux, where I do things like build Euno, a moderation bot that helps us keep the community operating. [00:00:14]
-
-**Mark:** I'm Mark Erikson. My day job is at Replay.io where we use time travel debugging to build things like automated QA tools and awesome React analysis. And outside of that, I run around at conferences, give talks, and work on Redux [00:00:27]
-
-**Carl:** Heck yeah. The big news that we wanna discuss this month, is around some changes that shipped for the React compiler. it's in Rust now. There you go. It's the news. You don't have to listen. Yeah. we're gonna talk about Meta and we're gonna talk about its engineering culture, b- framed around a blog post from Gergely Orosz, who is wonderful and a great writer. yeah. Talk a little bit more about AI, 'cause of course we are, and some broad best practices and stuff. [00:00:41]
-
-**Carl (editing):** And I'm trying something we haven't done before today. I'm gonna self-sponsor this 'cause we don't have anyone else paying our bills right now. [00:01:05]
-
-Uh, we are sponsored by Euno, a moderator support tool for Discord, offering one-click setup for spam defense, moderation audit logs, and decision-making tools. That's euno.reactiflux.com, E-U-N-O.reactiflux.com. Uh, Euno is named after the goddess of good order and lawful governance. Uh, it helps moderators make decisions about bans together while automatically filtering out compromised account spam. A single setup/command gets you anonymous user reports, shared moderation history and resolution voting, a private ticketing channel, and anti-spam based on message velocity. [00:01:10]
-
-With a 90-day trial, you can get a feel for it before deciding if $100 per year is worth the time you'll save banning spammers and deleting garbage. If you have a Discord server, give it a shot and let me know. That's euno.reactiflux.com, E-U-N-O.react iflux.com. [00:01:43]
-
-**Mark:** Yep. congrats to you, Carl. Thank you for all the work you've put in on this, and I can, vouch that this has been very thoroughly tested on our end [00:01:59]
-
-**Carl (editing):** We're also sponsored by me, Carl. Uh, these episodes cost me about 300 bucks out of pocket each episode, uh, for editing and supporting tools. If you'd like to learn more about anything Mark and I discuss, let's talk about consulting or a contract software engineering gig. [00:02:06]
-
-You probably know where to find me, but Discord or email is the most reliable. I'm at vcarl, that's Victor Charlie Alpha Romeo Lima, @reactiflux.com. Let me know [00:02:21]
-
-## New releases
-
-**Carl:** But yeah, first the new releases. [00:02:32]
-
-## [React Router 8](https://remix.run/blog/react-router-v8)
-
-**Carl:** First up, React Router v8 shipped. We got that now. yeah. This... they talk a lot about the early days of React Router, and it... [00:02:34]
-
-they're, like, proactively trying to manage the pain that people experience because, I... React Router got a reputation for shipping a lot of breaking changes with every new release. I guess specifically they got a reputation of flip-flopping back and forth between two different paradigms, like every other release, and it just frustrated a lot of people with, "Why do we have to refactor again?" So it's funny how much of this blog post is dedicated to saying, "We're not doing that anymore, we swear. Please don't hate us." [00:02:43]
-
-But yeah, generally it looks like this is essentially a no-op versus the latest version of v7. if you are already using the latest version of seven with no, deprecated features, it... [00:03:09]
-
-This should be a drop-in replacement. yeah, I think this, As far as I know, the mo- most of what th- this is bringing out is, emphasis on the framework mode. [00:03:22]
-
-**Mark:** I know that they've done a lot of work on trying to use feature flags to make new features available, essentially following the, majors don't introduce new stuff, they just remove old stuff kind of a [00:03:31]
-
-**Carl:** pattern. [00:03:42]
-
-And see, so the feature flags are the way that they implemented the better, major version releases. So th- now by the time, by the end of the previous major version release, they will have introduced new feature flags for everything that they are about to release in the next breaking change. [00:03:44]
-
-which is, it's really smart. I actually really admire that method of changing. managing feature flags, I have experienced, adds a lot of complexity to day-to-day development. and I have a ton of respect for them for landing on this process for releasing new changes, new features, new abilities to their widely used library, and here they are still, eight years later after they started using this, still putting it to practice. [00:04:01]
-
-**Mark:** Couple interesting notes from the support matrix here. Node 22, okay, that's fine. they now require at least React 19.2 [00:04:25]
-
-**Carl:** as [00:04:37]
-
-**Mark:** a minimum version, so that... I, don't know if version 7 expected 19.0 or 18, I would have to check. But just noting that React Router now requires the latest and greatest React 19. [00:04:38]
-
-And also the package is shipping as ESM only, we are very clearly now on the trend of lots of tools and libraries going ESM only. there was the early wave of tools that went ESM only and everyone else complained because it didn't work right. [00:04:50]
-
-And now with, some of the improvements to Node itself, we're seeing a lot of packages say now is the time to go ESM only [00:05:07]
-
-**Carl:** Yeah, we've got another release that went ESM only next. [00:05:16]
-
-I wanna flag, I just found... I was clicking through the blog post and they have a link to their governance document, which explains their new feature process. and actually this whole document is very well thought out and I would highly recommend that you familiarize yourself with this governance document, 'cause, it's just a bunch of really high quality engineering practices. [00:05:21]
-
-Definitely check it out. [00:05:38]
-
-## [Babel 8](https://babeljs.io/blog/2026/06/16/8.0.0/)
-
-**Mark:** So on the, ESM note, Babel 8 just shipped, and the, big highlights there, the Babel packages themselves are also now ESM only. TypeScript types are built in, and the default compilation settings for building your projects no longer target ES5 or CommonJS. So essentially they're saying we've, rather than necessarily being about backwards compatibility by default and always trying to cross-compile your code to, support, IE 11 or whatever, now we're targeting the modern JavaScript ecosystem. Which is also pretty much what, TypeScript 7 is doing as well. [00:05:39]
-
-**Carl:** I am extremely here for that transition. I wish that it had happened several years ago. Babel as a compatibility layer I think is really good and really great, but we've been on evergreen browsers for most of my career at this point, and I, yeah, just, the long tail of what it means to support ESM 5 and Require is just, it's really... [00:06:23]
-
-That tail's really long at this point. It's very far away. I don't know. I, think the, trade-offs are not quite there. Yeah. Yeah, Babel 7. I don't know. I've, Are people still manually installing and managing Ba- Babel versions themselves? This feels like something I haven't wrangled with personally in a long time. It's all downstream of the rest of the tools I use [00:06:44]
-
-**Mark:** Yeah, I'm disconnected enough from day-to-day app development that I don't have an answer to that question. [00:07:07]
-
-**Carl:** fair. Ha Okay. Anyway, moving on. [00:07:12]
-
-## [Astro 7](https://astro.build/blog/astro-7/)
-
-**Carl:** We've got Astro v7, major release of Astro. Astro's a project that I have always meant to explore more deeply than I really have. I have used it for a, trivial project here or there. If you're building a static portfolio site, brochure, marketing, whatever you wanna call it, it's really good. it hits a good balance between engineering ability, it gives you escape hatches to manually control stuff, while still being largely content oriented. [00:07:15]
-
-So it's very good if what you're managing is what's on the page rather than, like, how it behaves or what data's available. so it, not as great for a full app. there are certain types of apps that work great in that environment, but an application less [00:07:46]
-
-**Mark:** Like my mental model of Astro is it essentially replaces Gatsby [00:07:59]
-
-**Carl:** Yes [00:08:03]
-
-**Mark:** in terms of, we, we pull in data sources, we build sites that are static by default, but can have lots of dynamic content with your rendering framework of choice [00:08:04]
-
-**Carl:** Would agree with that, with all the same caveats of a lot of apps need something a lot more complicated than that. [00:08:14]
-
-But if you're building co- a content site, it's a really great tool for that. Yeah. Looks like mostly they're touting, s- build improvements, upgraded internal dependencies, V8, new roll down bundler. [00:08:19]
-
-**Mark:** Faster markdown parsing. [00:08:33]
-
-**Carl:** Yeah. Advanced routing to give you a single entry point with full control over the request pipeline. They can detect coding agents automatically that looks like a local development feature. It's, you can run the dev server in the background and output structured JSON for machine-readable feedback. That's really smart, actually. I love that. there's a ton of cases where, just like in testing and such, raw human readable HTML and CSS, it... that's just a lot of content. It's a lot of bytes. It's a lot of tokens. so giving machine-readable outputs at the framework level is really helpful. I like that a lot. That seems like a really smart feature, and I think we're gonna start seeing that for more. [00:08:34]
-
-## [TS 7.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)
-
-**Mark:** And I mentioned this a minute ago and we've mentioned it in previous episodes, but TypeScript version 7 is now at release candidate. think the biggest change here from a user point of view is that p- the previous releases had shipped as a separate native preview package and now it's the actual TypeScript package itself, the RC tag has all new binary and faster compilation stuff in there. [00:09:13]
-
-## ESM only, no programmatic API right now
-
-**Mark:** One other thing to note is that the, 7.0 release, number one, it builds off 6.0 where they change the default settings to favor modern compatibility instead of backwards compatibility. but then also 7.0 will not ship with a programmatic API. So tools that depend on the c- on the TypeScript compiler package to programmatically drive compilation, parse files, do that sort of thing, will not work out of the box with 7. [00:09:42]
-
-The idea was get the full working compiler in people's hands now and they're still trying to nail down the details of what the programmatic API will be like, and they're hoping to have that out in a 7.1 [00:10:18]
-
-**Carl:** Cool. Nice. Yeah, and we discussed that at more length last month, so I don't know that I wanna rehash all of that again. Difference between beta and RC is just not that big. [00:10:31]
-
-## [Nub JS](https://nubjs.com/), from Zod creator
-
-**Mark:** Okay, the, the next one's very interesting. Colin, the creator of Zod, just announced something called nub. Those of you with keen eyes will notice that this is bun backwards, in the same way that Deno is Node rearranged. clearly there's only so many letters we can use in naming JavaScript runtimes at this point. [00:10:41]
-
-The s- the sales pitch for this, Node was run JavaScript on the file system outside the browser. Deno was, "Oops, we made a bunch of mistakes designing Node. Let's completely redesign the security and the process architecture and bake a bunch more stuff in." Bun was, "Let's build Node compatibility on a different JavaScript engine, and also add every other built-in programming method and API we can think of while we're at it so it does everything at once." [00:11:07]
-
-Nub, on the other hand, is, "Let's start with actual Node, let's override a bunch of its configuration options, and let's build in a more modern environment, things like better TypeScript stripping and better, package JSON handling and a bunch of other pieces into Node directly so it feels like Node much better rather than one of the, one of the other options." [00:11:43]
-
-I, like this idea. we've been using things like ts-node and TSX and all these other type-stripping approaches. Node has a type-stripping option built in. This apparently goes up to the level of being able to output the non-strippable pieces of TS syntax, so like e- enums and things like that. But then it bakes in a whole bunch of other features as well. I like this idea. I, it, makes a lot of sense to me [00:12:15]
-
-**Carl:** I'd agree. It's interesting. I was always skeptical about Bun because of what you said, it starts from a brand-new runtime, and runtimes are difficult. It's hard. It's... Getting it right is tricky. clearly it's worked well enough for many people, but I've struggled with it a little bit. [00:12:45]
-
-Sure, There's plenty of room for opportunity in the tools surrounding Node.js as well. But I'm skeptical of this package manager. It says a pnpm-compatible manager built in, and it, reads whatever lock file you already have, writes to the same format. I don't know. I'm skeptical of that. look, we made a magic package manager that is cross-compatible with every existing package manager. sure, I'm sure you did. Can't wait to find out what bugs you missed. [00:13:02]
-
-**Mark:** I saw a tweet from Colin where he said that this was all implemented with AI, not surprisingly given today's no but it, but there was a lot of very careful planning and, defining the feature set and working out the requirements and then, using the agents to actually do the work on it [00:13:33]
-
-**Carl:** And, like we s- we were talking about last month, if you've got an existing set of tests to make sure that your code works against which all of these open source package managers are going to, then it's definitely a lot easier to create a functioning replacement. [00:13:52]
-
-yeah, I don't know. It's interesting. Curious, we'll, we'll see how it shakes out. We'll see if it works. see how it does for people [00:14:06]
-
-**Mark:** Yep. [00:14:11]
-
-## [Legend List 3.0 with DOM support](https://x.com/jmeistrich/status/2059922504320225316)
-
-**Mark:** Another release announcement. Legend List 3.0 came out, and this is originally, I think the original version of this was React Native only. Jay Misiorek's also the creator of the Legend State Signals library. but apparently he's figured out how to port the underlying list virtualization logic over to React DOM as well, and says that it's one of the fastest, if n- if not the actual fastest virtualized list implementation out there . [00:14:13]
-
-## [TSRX revamped the syntax](https://tsrx.dev/blog/rethinking-tsrx)
-
-**Mark:** And then, other follow-up note, I think it was last month we had mentioned something called TSRX, where Dominic Ganaway and the Ripple project had said, "We're, annoyed at the JSX specification being stuck for, the last 10 to 12 years. [00:14:44]
-
-We have come up with what we think is a better syntax, that, adds more flexibility." And, after they announced it, they got a bunch of feedback on, people not liking some of what they designed. And so th- they did a couple different blog posts about how they've stepped back and rethought what the syntax is. [00:15:02]
-
-Things like, the original TSRX wanted you to put quotes around every bit of text that you had in there, whereas JSX just is angle bracket, words, angle bracket. And so they've, gone back to that as a syntax for text. So to be honest, I don't have a good mental picture of what the actual differences are between this and JSX at this point, 'cause I, haven't gone through it in detail. [00:15:21]
-
-But they, looks like they do have some control flow syntax embedded as well. so they're somewhere in between their original p- proposal and standard JSX at this point [00:15:49]
-
-**Carl:** Neat. It's a big swing. I said last month that I think it's interesting that now in the AI era you can just update documentation and the tool knows how to use it, which was not the case for previously. So that might make it easier for tools like this to succeed, because you can just drop in a different markdown document and the tools will know how to write the new code, so to an extent. It's not perfect. [00:16:02]
-
-## React Core news
-
-**Carl:** Let's get into the main content with some React core updates first? [00:16:28]
-
-## [React Compiler in Rust is rolling out](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x)
-
-**Mark:** All right, so the biggest thing this month is that the React compiler port into Rust has officially been merged, and there's been a whole flurry of activity of different build tools now trying to actually integrate this. so the React teams had said, "We have been trying out the port at Meta. It appears to emit identical results with the TypeScript implementation of the compiler." [00:16:32]
-
-## [PR was merged after testing at Meta and improved](https://github.com/react/react/pull/36173#issuecomment-4608356402)
-
-**Mark:** they did a bunch of work to optimize it and handle some more cases, and the PR itself got merged, about a week-ish ago, I think. So now that it's at least more or less available, then the question is, how do you actually use it? [00:16:57]
-
-I don't know if you can actually just install the Rust version of the compiler right now. I'd have to double-check that. But n- since we have a whole bunch of build tools, and most of today's build tools are now written in Rust, a lot of different teams have been exploring how do we actually integrate this into the build tools. [00:17:14]
-
-## [Oxlint, SWC, RSPack, Next all integrating](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x%20)
-
-**Mark:** So Oxlint, SWC, RSpack, Next, and Bun have all been trying to figure out how do we integrate with this, make it a, an option or built-in or something along those lines. [00:17:35]
-
-## [Rolldown tried integrating directly but removed due to binary size increase](https://x.com/evanyou/status/2069593612153987373)
-
-**Mark:** One interesting note is that Rolldown tried to actually add this into their system, so there would just be a built-in turn on the React compiler option. [00:17:50]
-
-And what they saw was that it increased the binary size from, 28 megs to 33 megs, and they decided that was too much extra size to force everybody to download, actually reverted it, and they're exploring further options on how they can integrate it. [00:18:01]
-
-## [Bun tried optimizing the Rust Compiler code](https://gist.github.com/Jarred-Sumner/84df369c35216f40d61d1ea9f95771c2)
-
-**Mark:** On the other hand, Bun taking the Rust code and tried to both integrate it and also see can we improve the Rust code itself to make the compiler run faster. [00:18:18]
-
-I think a couple of the other teams have also been seeing, now that the Rust code for the compiler exists, can we also make it faster as well? So there's clearly still a lot of development opportunities for different teams to explore in terms of how is it integrated into the build step, how fast does it run, but we now at least have the merged PR as a baseline for all that different work [00:18:33]
-
-## Other core improvements
-
-**Mark:** Couple other things I noticed. one is that the React team has been working on something called Fragment Refs for a while. We, might have mentioned this once or twice in the past. [00:18:57]
-
-**Carl:** Yeah, I think not a long time though. It's b- it's been a minute [00:19:08]
-
-**Mark:** it's been a while. The PRs were sitting out there or getting quietly iterated on. [00:19:11]
-
-## [Fragment Refs have been documented](https://react.dev/reference/react/Fragment#fragmentinstance) in canary
-
-**Mark:** So the idea for a Fragment Ref is that a React fragment by design does not have any single DOM node associated with it, because it's meant to be like a virtual container for many children. That's why we wrap them in a fragment in the first place. but what happens if you want to do something like listen to a DOM event for any of the children directly underneath the fragment, or perform some other DOM operation? [00:19:17]
-
-So Fragment Refs are a, I think, now in Canary feature where you can put a ref prop onto a fragment and you get back something that looks like a DOM node in terms of the methods you can call, add event listener and that sort of thing. and under the hood, React just does the work to pass the references on to all of its children automatically. [00:19:48]
-
-So it looks to your code like you're dealing with an actual DOM node, and under the hood, React takes care of, oh, there's 15 children directly under this fragment, let me just collect the interactions with all of them. So, that is apparently now in Canary, and they've actually updated the documentation page on fragments to say that you can use refs on them [00:20:16]
-
-**Carl:** Nice. Cool. the value here I think is really specific, and, it might, be unintuitive. it... let's say you wanted all of those DOM methods you just talked about, you wanted to be able to measure the size of this block of nodes or add an event or whatever. [00:20:40]
-
-Another way you could do that is to wrap it in a div. If you have a div, cool, great, free DOM node. You can do all those things. but that doesn't work in certain layouts. if you wanted to have a grid where all of them share a single, drag end event, you can't just wrap that in a div because that breaks the grid layout. [00:20:57]
-
-So this is a situation for, flex or grid, where there's an implied mandatory hierarchy of the DOM nodes itself, and you are rendering those s- containers, those children, s- let's say from a map. You're mapping over data, then this is super helpful for adding a whole bunch of different types of behaviors, which is why it's worth the effort. [00:21:19]
-
-## React DevTools MCP tools, including [component tree](https://github.com/react/react/pull/36597) and [perf analysis](https://github.com/react/react/pull/36598) APIs
-
-**Mark:** And then one other thing that I have a vested interest in, the re- there's been a series of PRs posted to improve the React Dev Tools by adding MCP tools so that agents can query and inspect it. some form of imperative API so that you can programmatically ask, what is the component tree, and even turn performance profiling on and off. [00:21:42]
-
-and then some, some additional wrappers to expose that data. I've spent a bunch of time doing React performance analysis work. I am doing some of that at my day job right now. so I'm, I am also keeping a very close eye on this because it's very heav- heavily related to my interests. [00:22:08]
-
-**Carl:** Yes, it is. Yeah, and we've got... [00:22:26]
-
-## React Foundation progress
-
-**Carl:** we mentioned briefly the React Foundation last month, and most of what we said was that we haven't been able to see very much of what's happening. We can see things. Visible change is happening. [00:22:28]
-
-## There’s a(n early) [react.foundation](https://react.foundation/) website, advertising funding for maintainers and community groups
-
-**Carl:** The React repos have moved, there's also a new website being developed. I've seen some chatter about that. [00:22:39]
-
-**Mark:** Like the, foundation page exists, but the, uh the current form of the page is very vibe coded. And so, a- they're, like what's there is accurate, but not well designed. [00:22:46]
-
-**Carl:** Yeah, it is definitely vibe coded vibes. but yeah, so that, that, should change soon. [00:22:59]
-
-**Mark:** The, couple of the interesting bits for me, if you look at the, React Foundation website right now, there's a strong emphasis on helping support the community financially. Some of that is they're apparently intending to sell swag, shirts, and whatever, they intend money fairly to maintainers of some of the most common React ecosystem libraries. They also talk- they've also talked both in the past and I think on the website about helping financially support different, communities, meetups, conferences as well. And then I think they are taking over running the official React Conf as well [00:23:05]
-
-**Carl:** Yeah, I know that they've actually been having some struggles getting meetups. they wanna support local React-based meetups, people aren't doing local React-based meetups anymore. It's all AI stuff or whatever. it's... I think the... I, think my intuition here a little bit is that some of their mental model for how the React community exists is still, maybe not fully reacted to the shifts over the last two years. [00:23:45]
-
-I love the idea of collecting nonprofit donations and then distributing them out to library maintainers. I think that is super, super good. And doing it with a, proper foundation with, governance and a board of directors is super good. I've ac- I actually thought quite a bit about trying to do a business adjacent to this, just, hey, we got a community. [00:24:14]
-
-What if we did, a bunch of little events and had a membership subscription or whatever, and then funneled 80% of that money to the people who make the community exist. and I, ended up not just 'cause it's it was hard. It's a lot of work. It's a ton. Access also helps. starting from I am the manager of the React core team is a very strong position to create a foundation. [00:24:35]
-
-**Mark:** the flip side of all this is that as I discussed last month, I have no idea what's going on with the development of React itself. the- there's PRs around the compiler and the dev tools. I really haven't seen much activity on the core library in the last few months. [00:24:58]
-
-Joe Savona c- and put up a post confirming that he is no longer on the React team at Meta. He's now working on something AI related. and then that kind of ties into what we'll talk about in a minute with what is going on at Meta anyway. So here feels like the development process on React itself is rather fragmented and confused right now [00:25:14]
-
-**Carl:** Which is unfortunate. [00:25:39]
-
-## They’re gonna have a booth at [Chain React at the end of July](https://chainreactconf.com/)
-
-**Carl:** But if you wanna talk to the core team or, some members of the foundation, or generally people close to the development of React, they will have a booth at Chain React, July 30th, which it's a React Native conference specifically, And it is, where is it? And it is in Portland. So yeah, if you're, around the Pacific Northwest or willing to travel, so yeah, check it out. [00:25:41]
-
-Okay, moving on a little bit. jumping off your tangent you just teed me up for, thank you. [00:26:04]
-
-## [Why is Meta destroying its engineering organization?](https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering)
-
-**Carl:** Why is Meta destroying its engineering organization? this is a newsletter post put out by Gergely Orosz, who's very influential, I would say. He puts out a, pragmatic engineering newsletter. It's very good. I read it occasionally. I read posts from him. [00:26:11]
-
-**Mark:** well written and sourced [00:26:27]
-
-**Carl:** Very well-sourced, very timely. He does a good job of being timely. so y- this is a, this, is again, a well-written, well-researched, well-presented post, talking about the engineering values of Meta historically. it brings in the, original Facebook little red book, which is a little, culture document describing the values of the company. [00:26:28]
-
-**Mark:** move fast and break things, but also like a, lot of stuff about how we want to think about building stuff for the customer [00:26:48]
-
-**Carl:** Yeah. okay, so Move Fast and Break Things is notorious. here are eight, no seven other values from the same book. [00:26:57]
-
-Done is better than perfect, [00:27:05]
-
-fail harder, [00:27:07]
-
-what would you do if you weren't afraid, [00:27:08]
-
-every day feels like a week, [00:27:10]
-
-the Wright brothers did not have pilot licenses, [00:27:12]
-
-the foolish wait and fortune favors the bold. [00:27:15]
-
-And I don't know, a lot of those are values I can, agree with. [00:27:17]
-
-**Mark:** It's better to get something done and see what happens than to waste all of our time discussing if we should try doing something [00:27:22]
-
-**Carl:** Yeah. Yeah. So I don't know, it's, it's a good doc. This is good speaking about the engineering cultural history and some of the actual timelines of improvements and, releases that they made. and it's, it lists a number of problems. th- they started tracking engineers' keystrokes with no way to opt out on work laptops. [00:27:28]
-
-it says "30 to 50% of engineers and core teams have been forcefully reassigned to data labeling." You think you're gonna be a core AI engineer and oops, you're just n- t- you're a competent, skilled professional tagging data the same as a legion of other competent, skilled professionals training your replacement. [00:27:52]
-
-I have a, friend of mine who was recently laid off from Meta who has been involved in, basically, just trying to resist this type of pressure. like for being forcefully reassigned to a team that you are not interested in being on, that sucks. [00:28:10]
-
-and it's part of your contract. It's ultimately, at the end of the day, you're in a hierarchical corporate system. They have hired you to perform work at their leisure, at their desire, and it is entirely within their legal contractual right to say, "You work on this now." [00:28:24]
-
-and that doesn't, What if it, wasn't their contractual right? What if they did have to actually negotiate with you and put you somewhere that was mutually compatible? So I don't know. That's, that's the pushback that they have been trying to support and organize. [00:28:40]
-
-But, meta is maybe not doing so great. I guess, one, one concrete engineering point that this, draws attention to was the r- disappointing AI model development. Like losing momentum effectively. Like Llama 1, 2, 3 were all very cutting-edge and competitive, and Llama 4 released over a year ago now, which I guess was the last release. I don't know of another release from them. [00:28:53]
-
-so yeah, I don't... as a symptom of declining engineering culture, their frontier AI model is no longer competitive. [00:29:20]
-
-**Mark:** Yeah. So some of the points it makes is that they, they, used to have v- pretty good engineering culture based on we're, trying to build the right things the right way at scale. The question of, whether the apps that they're building are useful for society is a different question, but at least they were mostly trying to build them the right way. [00:29:28]
-
-And now it seems like in the last year or two they have shifted to a focus on AI. They've had a bunch of layoffs. Engineers have been forcefully reassigned, and the, I know the performance review topic c- has come up repeatedly when I've talked to even, React core team members. They, they want to spend their time doing things that will benefit the greater React community, but they have to, in order to get good performance reviews, they have to show, like, how is this actually benefiting Meta the company. [00:29:44]
-
-And so whether that's something like, "We're gonna build this new React feature because it makes Ads Manager faster," or, just, interactions in some way. So that I know has been a struggle just for the React team, and it's clearly a major problem for everyone else at the company at this point. How justify my existence? [00:30:16]
-
-**Carl:** there's a book that I love called Moral Mazes that speaks a lot about this type of problem. we, we're talking about engineering culture. [00:30:35]
-
-That's... Culture is the downstream result of a vast group of people interacting with each other. The culture is the emergent property of how those individuals interact with each other. And Moral Mazes is a really wonderful sociological study of the firm, the c- the American corporation. And so it ends up speaking a lot about subjects like performance reviews. [00:30:44]
-
-And here in this blog post, the Pragmatic Engineer Newsletter, it says, "The biggest problem, people stop caring about real work and focus on performative work." and like what you just said about how they can't do what's best for the overall growth of the library because that's not the criteria upon which they're judged. [00:31:05]
-
-They are judged on their impact within the company, and specifically the impact on the company as judged by their immediate supervisor with, with the supervisor chain. So it, ultimately you're... The, incentives flow down in that kind of way. So it's actually... [00:31:23]
-
-there's, a deep fundamental misalignment between open source and, the American corporation, I'm not gonna go into capitalism a w- But, that's very true. Open source is a c- is a public good. It's a, it's, it's a public square. It's a shared resource that they're, people don't pay for. and those types of resources they're the economic concept of the tragedy of the commons. [00:31:41]
-
-It's a well-known principle that people don't just casually take care of stuff. If it's a public common, it's going to get more extraction than it is investment. So it's... I don't know. It's, it, there, the, th- that's a fundamental tension, and I feel like any time we're talking about companies under-investing in, open source, that's kinda why. [00:32:03]
-
-It's because they can't. They're not allowed to. If you're a big publicly traded company that has gone to IPO and has shareholders, you have a fiduciary duty to those shareholders, and fiduciary duty does not include volunteer effort to public goods. So it's, that's, there you go. That's the tension. [00:32:27]
-
-Anyway, let's move on [00:32:44]
-
-## [AI demands more engineering discipline. Not less](https://charitydotwtf.substack.com/p/ai-demands-more-engineering-discipline)
-
-**Carl:** Great post from Charity Majors who, somebody who I've ... They, are such a well-spoken, phenomenal writer speaking about engineering culture. And I, especially they talk about opera- or, yeah, I was gonna say operationalizing, production environments. [00:32:46]
-
-they run a company that makes its money on observability, [00:33:05]
-
-**Mark:** Honeycomb [00:33:08]
-
-**Carl:** Honeycomb. great company, great mission, great blogger, great writer. so i- she's put out a post, AI Demands More Engineering Discipline, Not Less. [00:33:10]
-
-Charity says in her post, "What happened in 2025 was this, the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated to being disposable and regenerable practically overnight." [00:33:20]
-
-And something I've said on this podcast before is that, code's kind of a liability. over time code is not an asset, it is a drain. It is something to be maintained. It is a cost center. so I agree with that. I think that read is correct. The, economics of code production were turned upside down. [00:33:38]
-
-it's m- because code is not an asset, because code is a liability, the ability to discard it and replace it with something new that is, has differ- has a different risk profile is massive. [00:33:57]
-
-**Mark:** It's, ironic because, as developers we have historically resisted, taking the time to write documentation or writing tests or actually planning out our work, and suddenly it turns out that in order to get good results from AI, we actually need to do all of the above. [00:34:12]
-
-**Carl:** Yeah, and it's like I have always known what the right choice to make was. it's y- several years ago when I was working as a tech lead, it's okay, we have this feature. I know that it is deficient in these , these areas. no, we don't have end-to-end tests. no, we don't have functional integration tests for all corner cases. [00:34:30]
-
-Because we don't have an existing end-to-end harness, because we don't have a framework for mocking network responses for requests initiated from components deep in the tree, deep in the hierarchy. there, it's, it... Engineering excellence is a momentum-based metric. You cannot skip ahead [00:34:53]
-
-You can't write end-to-end tests if you haven't built a reliable framework upon which to run end-to-end test suites. and so it's hard to do. It's hard to keep that momentum up over a long enough time span to where you start observing the benefits, and so most companies didn't. [00:35:12]
-
-the number of times where I would get feedback on something, and it's like, why don't we have this already?" It's, 'cause that would've taken two weeks, and I can do it now, but I didn't have two weeks." and I gotta say, I'm finding it much easier to find those two weeks with AI. AI is an amnesiac, so it needs to start from scratch every time. [00:35:30]
-
-if you're working on a new feature or just built something brand new, I just ask Claude, "Hey, familiarize yourself with this code base, how much of that did you get from docs versus the code?" [00:35:50]
-
-And it does a little analysis, and it comes back and says, "Oh, the documentation is out of date in these locations, and these concepts should be pulled in." "Great. Can you do that work for me?" It's like, "Oh, yeah. Cool, cool. And so then instead of, what, six hours of, reading code and putting together my own notes and understanding what documentation is currently available and synthesizing it to get, a fact-based update and then writing brand-new prose to fill in those docs, I, I, I can do that in 10 minutes in a background process. [00:36:00]
-
-**Mark:** Yeah, I, love generating architecture exploration e- explanation type docs. I've, found that extremely useful. In fact, that was my gateway that eventually led to me using aI to write code. It does feel like I'm leaving some understanding on the table, that my understanding is can be very much more surface level. some of it is, there's ar- areas of our code base and our projects I just haven't looked at, and operating off of a vague mental model. I, skimmed through a handful of architecture docs. that's certainly not, that's certainly not enough to actually understand what's going [00:36:30]
-
-Yeah place. It's, easier entry, but maybe not as much depth [00:37:04]
-
-**Carl:** That's very true. I assuage my own guilt in that, the like, "Oh no, I, know that I'm only seeing 30% of this." ' Cause for one, every code base is too large for your brain. you are never going to fully understand all of it at the same time. And any time that I did fully understand something, the, amount of time it took to get to that understanding, and then the only time I ever did that was to change it, [00:37:09]
-
-**Mark:** Mm. [00:37:37]
-
-**Carl:** So then as soon as I'm done with that, as soon as I have gotten my understanding up to 100%, cool, great, I'm changing it. That's now out of date. That knowledge is now useless. [00:37:38]
-
-**Mark:** I'm, sure I've mentioned this in previous episodes. I am a huge fan of the concept that programming is building a working mental model of the system. it's a, it's about theory building. So you understand what we are trying to build as a domain, as a project. [00:37:46]
-
-You understand the current system, the architecture, the quirks, the concepts, so that for any task you work on, whether it's a feature, a bug, whatever, you are starting from my current understanding. You break down the new problem based on your understanding. You come up with a plan, you implement it, you spend six hours trying to make it work, and by the time you're done, you not only have working code, you have updated your mental model on the system. So I would say it's not that you've made your previous knowledge useless, but we are continually modifying that understanding [00:38:03]
-
-**Carl:** Yes, sure. I agree with that. I agree with that, but I also discount it a little bit more than I think you are. Like, I'd agree that, developing an, accurate mental model is core. You need to do that as writing, as part of writing code. I, at least, am satisfied at the level that I am able to develop a mental model w- via AI. [00:38:36]
-
-I guess th- this is, a feedback cycle. You have to develop your mental model, check it against what the AI is telling you, and then make sure it's what you intended, and then make sure that what you intended is compatible with a functioning projec- will it achieve what you meant it to? [00:39:03]
-
-And those are all really hard, oh, another thing I wanna say your mental model, are, the building blocks that you have available to develop your mental model, are those complex enough to, capture what you're making? [00:39:19]
-
-That's something I run into fairly often. It's like the system architecture, the system design inter- interview questions. Like, how would you build Twitter to be re- resilient? Those are hard problems. That's re- you know, de- developing a system that can manage hundreds of millions of requests is, yeah, it's really tough, and AI is really helpful for me for exploring that. [00:39:33]
-
-it ends up being... Okay, oh, wait, here let me try and frame this in a sentence. It used to be critically essential to develop an accurate mental model through the process of reading and writing code yourself, and now it's much more important to be able to ask the correct question at the correct time of the code base. [00:39:58]
-
-Because now you can... The, frontier models are smart enough and the tools are capable enough, they can pretty meaningfully answer any question that you have about a fixed set of code. If you, bound it to like, "Here's the code, here's your world, tell me about it. Answer this question for me," it can. [00:40:18]
-
-And so now it's up to you to know what the right questions are to ask given the present state of the existing code [00:40:38]
-
-**Mark:** Yeah. So let's tie that then into the next link in the list. [00:40:46]
-
-## Christoph Nakazawa posted his [“Modern Engineering Values” and how he uses AI](https://cpojer.net/posts/modern-engineering-values)
-
-**Mark:** so Krzysztof Nakazawa is a long time figure in the React ecosystem. He's worked on Jest and graphQL and a whole bunch of other tools. more recently, he shipped a data fetching library called Fate. he's built a game with JavaScript called Athena Crisis. He got hired by Void Zero, which we'll talk about in a second. so like re- like really smart, capable long-term engineer, and he is now fully doing everything with AI. [00:40:51]
-
-**Carl:** Yep. [00:41:21]
-
-**Mark:** He put up a post on modern engineering values where he talk about how he uses AI effectively, but also then what are the principles that he's using in trying to build projects. And he talks about, ownership and taste and strict guardrails and fast feedbacks loops, which is what we were hitting on a minute [00:41:21]
-
-**Carl:** Yep. [00:41:42]
-
-**Mark:** Being able, to know what is the right context that I feed into the agents so that they are able to come up with the answers. maybe actually, owning some more your own code instead of depending on third-party libraries. Thinking differently about how you build prototypes and ship things. so very relevant to like we're, doing the same work, but maybe at a higher level, and you do have to know where you're trying to go [00:41:44]
-
-**Carl:** Yes. Yeah, agree. Yeah, I like this, bit from Christoph's post, "I've found that coding agents now write code that is as good or better than what I could write," which I would agree. I find that true as well. "And they do it in minutes instead of weeks. Since coding is no longer the bottleneck, I get a lot of work done that otherwise wouldn't have happened at all." [00:42:12]
-
-100% agree with that. That is... I have started and finished so many more projects than I would have before because I, can do it in a day instead of in a week. it's a 7X speed multiplier for me. So it's good. [00:42:30]
-
-## [Cloudflare bought VoidZero](https://voidzero.dev/posts/voidzero-cloudflare)
-
-**Mark:** In industry news, Void Zero, the company behind VitePlus and a couple other pieces, has been bought by Cloudflare, this continues the trend of a bunch of open source build tool developers try to get funding, try to make a company, and then they probably get swallowed up by someone bigger because there is no money in running open source build tools. Bun and a whole bunch of others all getting bought out. nobody is making money off of open source build tools. There is no build m- there is no financial model, hosting, or anything else. So we'll see how it plays out. to be clear, this is about the team and the VitePlus and Void tool sets and frameworks. [00:42:42]
-
-This does not affect Vite, the open source bundler, at all, other than these are some of the same people working on it. but it continues the pattern, and I don't see that pattern changing anytime soon [00:43:32]
-
-## NPM / security updates
-
-**Carl:** We got some more security updates from NPM. Great. [00:43:44]
-
-## [Github Actions allows enforcing pinned action SHAs](https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/)
-
-**Carl:** GitHub Actions now supports blocking and pinning actions to a specific SHA. So that's, that's really good. If you... So this is helpful for avoiding vulnerable actions. if you're aware that some specific release of an action was compromised, you can now block that one specifically. [00:43:48]
-
-Or say, "We know this one is good. Only use this version." wow. Ability to select precisely what code you're running. This feels like table stakes to me. It's shocking that we're only just getting it [00:44:09]
-
-## [GitHub Actions Has a Package Manager, and It Might Be the Worst](https://nesbitt.io/2025/12/06/github-actions-package-manager.html)
-
-**Mark:** there's, a guy named Andrew Nesbitt, I think we may have linked one or two of his articles previously, but he has become an expert on package managers and packaging systems, and I think he wrote an, a couple articles talking about, yep, GitHub Actions is totally a package manager. It doesn't look like one, but it is, and it's bad [00:44:21]
-
-**Carl:** Yes. Yeah, people shit on NPM for a lot of reasons, but you know what? The w- most most of the ecosystem problems in JavaScript around dependencies are because NPM is one of the only functional package managers in programming. Cargo or NuGet or, like, all of the other... [00:44:39]
-
-Every other language has a shitty dependency manager. It does not support what I would call core features of a dependency manager. For instance, pinning versions. Just, it's shocking to me how ineffective we are at sharing code in the vast majority of programming. anyway, yeah. So great. So many things are terrible dependency managers, and GitHub Actions is now a slightly less terrible pa- package manager [00:44:58]
-
-## [NPM 12 will disable install scripts and Git deps by default](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
-
-**Carl:** GitHub also put out some breaking changes for npm 12. They are not going to run install scripts and Git dependencies by default. that is... This is literally something I've seen discussed as a security vulnerability for 10 years. [00:45:27]
-
-So it finally got exploited enough times that they're like, "Nope, okay, we gotta get rid of it." great, cool. They're getting rid of the thing that has been discussed as something that should be gotten rid of for a long time [00:45:43]
-
-specifically it's, NPM will no longer run pre-install, install, or post-install scripts from dependencies unless you allow list them. So no builds basically [00:45:54]
-
-**Mark:** what I think pnpm als- already does [00:46:05]
-
-**Carl:** Plenty of package managers already do that because running untrustworthy code from a network is really dangerous. [00:46:08]
-
-Don't do it. This is what I mean, like, I just said, NPM is one of the most advanced package managers in all of programming, and it still gets basic shit wrong. Stop it. Security models. [00:46:13]
-
-## Code optimization still matters!
-
-**Mark:** All right, last major item for the day. topic, a related topic, but, bit of a grab bag. There's a whole bunch of good articles about code optimization that came out in the last few weeks, and I've spent a lot of time doing performance profiling. I have literally given a talk this year on how to do performance profiling. So we had several articles on, and from people who did performance optimization work on tools and libraries. [00:46:25]
-
-## [TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects](https://tanstack.com/blog/tanstack-table-v9-memory-performance) and [optimized TS perf](https://tanstack.com/blog/tanstack-table-v9-typescript-performance)
-
-**Mark:** First off, there's a couple articles from the TanStack Table folks where they talked about how they were able to save a bunch of memory within TanStack Table by switching out the JavaScript prototypes that were being used, as well as how they optimized, the TypeScript compilation performance. [00:46:53]
-
-Now, yes, TypeScript's version seven's gonna make all our TypeScript faster, whatever, but it's still good to actually try to improve the, type checking time if possible. [00:47:14]
-
-## [Pierre Diffs was significantly optimized](https://pierre.computer/writing/on-rendering-diffs) - has to handle virtualization, syntax highlighting, source loading
-
-**Mark:** next, there's something called the Pierre Computer Company, which is making essentially like a, GitHub for, as a service kind of a, set of tools. [00:47:25]
-
-And they've put out a couple JavaScript libraries, one for rendering tree views in the UI, but they also put out one that is a diffs rendering library. And so they've put up a post on how they heavily optimized all the list virtualization and the syntax highlighting and all the other complexities of trying to render diffs efficiently in the browser. [00:47:35]
-
-And I've seen several other applications pop up which use that library in the UI. part of me make, wonders if GitHub perhaps consider using that library in their UI given the, how slow their React based, PR view is at this point [00:47:59]
-
-**Carl (editing):** oh, shoot. We had an audio problem. For some reason, we lost about the last 10 minutes of my audio. Mark's came through just fine. Uh, and luckily he did most of the talking in the last little bit here. Uh, but unfortunately we lost about four to five minutes of me responding to things that Mark said. Uh, oops, sorry. [00:48:20]
-
-## [CompileCat is a new optimizing compiler to improve JS execution after bundling](https://github.com/isaac-mason/compilecat), similar to Closure Compiler. ([the RSPack team says they’re working on something similar](https://x.com/jiahan_c/status/2065630866668453898) )
-
-**Mark:** A couple more of these. So someone recently started a site called Performance.dev. Their first article previously was on how the linear UI is fast using sync engines, and they just put up another post on how a tool called Conductor implemented a bunch of optimizations, handling some of the UI layer interaction with Tari, list virtualization, and a bunch of other pieces. [00:48:38]
-
-so those are, apps and libraries making things faster. I saw a couple, winks on something different. So we all use minifiers in our bundling process. It's, part of all modern build tool chains. minifiers do things like they don't just rename variables from my variable to A. [00:49:03]
-
-They, they strip white space. They turn true and false into bang zero and bang one be- because it takes up fewer characters, et cetera. But they also do things like stripping out dead code. So if a library has only r- has a, an if statement that says, "Only run this in development," it will convert that to if false, and then it will say, "Oh, that code can't run. [00:49:25]
-
-Just delete that code from the bundle and optimize the output." And so every time you run a build, a minifier is optimizing the output. And the major mini- the major minifiers, optimizers have been things like Terser and, ESBuild has had one built in, Rolldown has one built in. there's be- there's one that's been around for a very long time called the Google Closure Compiler. [00:49:49]
-
-this dates back to when Google first built a lot of their early web spa type tooling. 2008, 2009, somewhere in that timeframe. it's, extremely powerful and has a lot of very advanced optimizations that other minifiers still don't have, but it's also big and complicated and maybe a little bit on the slow side. [00:50:14]
-
-interestingly, the React team still uses the Closure Compiler to build the React library so that the production version of React is as fast as it can possibly be. So I saw two different announcements of teams that are attempting to write their own advanced optimizer tools. one person built something called CompileCat, and then the other one's a mention of an internal tool that's not released yet, but the, RSPACK team at ByteDance said they're also working on a similar tool. [00:50:35]
-
-So presumably doing things like actually looking at not just the JavaScript, but the TypeScript types in order to be able to, be smarter and produce better output code as well. [00:51:11]
-
-## [Mark’s React-Redux \\\+ signals draft perf PR](https://github.com/reduxjs/react-redux/pull/2318) and [updated React-Redux benchmarks repo](https://github.com/reduxjs/react-redux-benchmarks)
-
-**Mark:** And then I guess we'll wrap up this section with three things for me. so I, think I briefly mentioned last month that I was working on a proof of concept to try to optimize React-Redux's subscription notifications for our large applications. so I have a draft PR, and I've put that up, and the early numbers look promising, like 20% to 30% faster depending on the situation. [00:51:22]
-
-as part of that, I also updated my React-Redux benchmarks repo so that I've got better metrics that I'm capturing and, a better, more realistic set of example scenarios to be measuring against. And then one of the conference talks that I've been doing this year is literally on the basics of performance optimization. [00:51:50]
-
-there's a set of general scientific principles to apply, descriptions of actual tools that you would use to measure JavaScript performance and fi- try to figure out which lines of code are slow, and I talk about some of the examples I did while working on Immer last fall [00:52:12]
-
-I think this is all very important even in the age of an AI because AI tends to write the obvious code. It doesn't necessarily write the fast code. And we collectively were already very bad at asking, "Is this code fast?" in the first place when we were the ones writing it. And now that n- we're not the ones writing it, it's even easier to never ask the question, "Is it fast?" [00:52:28]
-
-## [Aurora Scharff’s preferred RSC component architecture](https://aurorascharff.no/posts/component-architecture-for-react-server-components/)
-
-**Carl (editing):** Yep. So right here is where we lost about four minutes. Uh, unfortunately, I, I definitely cannot reproduce what I said, which is a big bummer. I think it was probably really smart and really clever and really wrapped up the whole thing of what we talked about all episode. But unfortunately, it's gone into the ether. [00:52:51]
-
-I tried re-extracting the audio as recorded from the original source, and it was just blank. We're just completely missing 10 minutes. sorry. [00:53:07]
-
-All I really know is that I was introducing Aurora Sharf's blog post titled "Component Architecture for React Server Components" as her preferred RSC component architecture. [00:53:15]
-
-And I know that because Mark said after [00:53:26]
-
-**Mark AI filler:** yeah. And, Aurora really is the expert on this kind of stuff right now [00:53:29]
-
-## [Lovable projects now use TanStack Start by default](https://lovable.dev/blog/building-apps-using-tanstack-start)
-
-**Mark AI filler:** And then one, one other interesting data point to wrap up, announced that all of their Vibe-coded app projects are now going to be built with TanStack Start by default. I don't remember whether they were just using plain Vite React router or something previously. but this feels it, it's a very interesting data point. A sign of the maturity of TanStack Start, and that they're, and they're happy to actually adopt this as the default setup for all their projects going forward. [00:53:34]
-
-**Carl (editing):** And that is all we've got for you today. I am re-recording this afterwards just like all the other things I said in the last 10 minutes. So I'm not gonna do the usual full sign-off 'cause this is totally fake and I'm just sitting at my desk talking to myself. Sorry for taking a few extra days to get the podcast out. I am just tired and it's summer [00:54:05]
-
-Thanks so much for listening all the way to the end even. talk to you next month [00:54:24]
diff --git a/src/transcripts/tmir-2026-07.md b/src/transcripts/tmir-2026-07.md
deleted file mode 100644
index ebd1faf..0000000
--- a/src/transcripts/tmir-2026-07.md
+++ /dev/null
@@ -1,667 +0,0 @@
----
-title: "TMiR 2026-07: React-alikes, GOVERNANCE, and state management"
-date: 2026-07-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we discuss the React Compiler being rewritten in Rust, what AI development means for engineering culture, "
-people: "[Carl](https://bsky.app/profile/vcarl.com), [Mark](https://bsky.app/profile/acemarke.dev), and [Mo](https://bsky.app/profile/mojavad.bsky.social)"
----
-
-
-
-
-
-- [[01:27](#new-releases)] New releases
- - [[01:29](#vite-beta)] [Vite+ Beta](https://voidzero.dev/posts/announcing-vite-plus-beta)
- - [[02:41](#typescript-70-released)] [TypeScript 7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) released
- - [[03:56](#open-pr-for-content-mappers-to-typecheck-templates-other-than-jsx)] [open PR for “content mappers”](https://github.com/microsoft/typescript-go/pull/4712) to integrate other language syntax
-- [[04:57](#johnson-chu-made-a-compatibility-layer-to-drop-in-for-unsupported-tools)] Johnson Chu made [a compatibility layer to drop-in for unsupported tools](https://github.com/johnsoncodehk/typescript-native-bridge)
- - [[05:18](#oxc-type-aware-linting-stable)] [OXC type-aware linting stable](https://oxc.rs/blog/2026-07-22-type-aware-linting-stable)
- - [[06:00](#npm-v12-and-new-security-defaults)] [NPM v12 and new security defaults](https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation/)
- - [[07:00](#dependabot-supports-a-configurable-delay)] [Dependabot supports a configurable delay](https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/)
- - [[07:37](#more-react-rsc-security-tweaks-for-19x-)] [More React RSC security tweaks for 19.x](https://github.com/react/react/releases/tag/v19.2.8)
-- [[08:06](#main-content)] Main Content
- - [[08:07](#react-org-updates)] React org updates
- - [[08:22](#leadership-council-and-working-group-structure-on-the-new-team-page)] “Leadership Council” and Working Group structure [on the new team page](https://react.dev/community/team)
- - [[11:11](#stub-governance-docs-for-the-leadership-council)] [Stub governance docs](https://github.com/react-foundation-dev/leadership-council) for the Leadership Council
- - [[14:37](#rick-hanlon-update-on-the-react-team-using-a-stage-process-internally)] Rick Hanlon update on the React team [using a “stage” process internally](https://www.reddit.com/r/reactjs/comments/1v1dsh0/react_rfc_processis_it_dead/oyp9wac/)
- - [[15:39](#pete-hunt-and-nick-schrock-join-vercel-to-run-frameworksnext-and-agent-dx)] [Pete Hunt and Nick Schrock join Vercel](https://x.com/rauchg/status/2077870043833229692) to run Frameworks/Next and Agent DX
- - [[17:16](#poimandres-published-a-charter-original-announcement)] Poimandres [published a charter](https://github.com/pmndrs/org/blob/main/CHARTER.md) (original [announcement](https://x.com/pmndrs/status/2080303456800080047))
- - [[20:20](#an-example-initiative)] An [example initiative](https://github.com/pmndrs/org/blob/4bd14e20da776ff68f7555a57a01ad0b4999be92/initiatives/03-text-rendering.md)
- - [[21:30](#react-alikes)] React-alikes
- - [[21:40](#octane-from-dominic-gannaway)] [Octane](https://octanejs.dev/) from [Dominic Gannaway](https://bsky.app/profile/trueadm.dev/post/3mrn7yd6dzk2t)
- - [[28:27](#ryan-carniato-reacts-staying-power-is-because-of-complacency)] Ryan Carniato: ["React’s staying power is because of complacency"](https://x.com/RyanCarniato/status/2072382108535066640)
- - [[29:12](#follow-up-do-people-think-fe-innovation-is-dead-would-explain-why-theres-resistance-to-move-past-old-react)] Follow-up: [“Do people think FE innovation is dead? Would explain why there’s resistance to move past old React.”](https://x.com/RyanCarniato/status/2081813329681711152)
- - [[30:31](#parallel-articles-on-solid-20-with-async-and-remix-3)] Parallel articles on [Solid 2.0 with async](https://www.brenelz.com/posts/learning-solid2/), and [Remix 3](https://malstrom.me/blog/learning-remix-3)
- - [[32:22](#cross-framework-benchmark-measuring-reactivity)] [Cross-framework benchmark measuring reactivity](https://bsky.app/profile/nullvoxpopuli.com/post/3mrplyqcd722j)
- - [[35:04](#aiden-bai-released-reactbench-to-measure-ai-code-quality)] Aiden Bai released [ReactBench to measure AI code quality](https://www.reactbench.com/)
- - [[36:37](#alex-russell-thinks-everyone-is-screwing-up-state-management)] [Alex Russell blasts “state management”](https://infrequently.org/2026/07/state-management/) (and most of the React ecosystem) in favor of sync engines
- - [[47:41](#aurora-scharff-rewrote-the-suspense-docs-page-to-cover-how-it-works)] Aurora Scharff [rewrote the Suspense docs page to cover how it works](https://react.dev/reference/react/Suspense#what-activates-a-suspense-boundary)
- - [[48:22](#and-a-post-on-rsc-performance-patterns)] And a post on [RSC performance patterns](https://aurorascharff.no/posts/experimenting-with-rsc-for-performance-and-ux-in-nextjs/)
- - [[48:41](#tanstack-removed-rscs-from-the-website)] [TanStack removed RSCs from the website](https://tanstack.com/blog/we-removed-rsc-from-tanstack-com)
-- [[51:04](#marks-making-progress-on-some-react-redux-perf-prototyping-and-thinking-about-rtk-30)] Mark’s making progress on [some React-Redux perf prototyping](https://github.com/reduxjs/react-redux/pull/2318) and thinking about RTK 3.0
- - [[57:36](#making-referential-stability-a-type)] [Making referential stability a type](https://www.jovidecroock.com/blog/referential-stability-types/)
- - [[59:17](#porffor-native-compiler-upcoming-alpha)] Porffor native compiler [upcoming alpha](https://honk.foo/porffor-alpha/)
- - [[59:39](#perry-cross-compiles-claude-code-bundle)] Perry [cross-compiles Claude Code bundle](https://www.perryts.com/en/blog/compiling-claude-code/)
- - [[01:00:17](#vercel-releases-scriptc-native-compiler)] Vercel [releases scriptc native compiler](https://github.com/vercel-labs/scriptc)
- - [[01:02:04](#goodbye-forever-probably)] [Goodbye, forever, probably.](https://whitep4nth3r.com/blog/goodbye-forever-probably/)
-- [[01:08:41](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:08:53](#sep-11-zurichjs-switzerland)] Sep 11: [ZurichJS](https://conf.zurichjs.com/), Switzerland
- - [[01:09:14](#sep-25-26-react-alicante-spain)] Sep 25-26: [React Alicante](https://reactalicante.es/), Spain
-
-**Carl:** Hello. Thank you for joining us for the July edition of This Month in React, as we recap what's been going on with React Native and other things across the web. We are coming to you live from Reactiflux, the place for professional developers using React. And I'm Carl. [00:00:00]
-
-I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like these events and build tools like help keep the community operating. [00:00:13]
-
-**Mark:** Hi, I'm Mark. My day job is replay.io, where we've built time travel debugging, are working on autonomous QA, and I get to do all kinds of awesome time travel-powered React analysis tools. And outside of that, I am still doing Redux stuff, and I'm actually finding the energy to do a fair amount of that right now, which is cool. [00:00:22]
-
-**Carl:** Nice. Heck yeah. Hell yeah for finding the energy to invest in a project you love. [00:00:41]
-
-**Mark:** Yep. I'm also actually back at home after, like, two and a half months of almost nonstop conference travel. [00:00:47]
-
-**Carl:** We were saying in prep, we have kind of a grab bag this month. There's not, like, one big thing to discuss, but yeah, we're gonna get into a couple things. [00:00:53]
-
-Uh, obviously there's been more security stuff and new releases of major projects, like TypeScript 7, which we've discussed, like, four times already, but y- it's here. Yay. [00:01:00]
-
-We also are gonna get into some open source governance questions. There's been some developments on the React Foundation. And l- kind of out of left field at the same time, Poimandres a cooperative doing open source around Three.js. It also published some governance work. So yeah, we're gonna get into it. [00:01:09]
-
-## New releases
-
-**Carl:** But first, the first new release. [00:01:27]
-
-## [Vite+ Beta](https://voidzero.dev/posts/announcing-vite-plus-beta)
-
-**Carl:** Vite\+ from Voidzero is in beta now. [00:01:29]
-
-**Mark:** It's not paid anymore. Oh, okay. They dropped that. I think they dropped the paid part even before they got bought out. [00:01:33]
-
-They initially said it was paid. Then they said, "No, no, we'll, we'll make Vite\+ free. We're gonna build our own server runtime layer on top of Cloudflare," and then Cloudflare just bought the entire company. [00:01:40]
-
-So- Great ... Plus itself, as far as I know, is going to be entirely free at this point multiply. But it's just the Void Zero company had been paying a bunch of people to build out OXC, you know, that whole layer of parser tooling, partly to use in the Rolldown Rust-based bundler. [00:01:51]
-
-The latest version of Vite uses Rolldown, but then there's all these other Rust-based tools related to that. And so Vite Plus is a combination of we have pre-configured all these different tools into one super package, as well as added some additional layers of functionality on top of that. So it's essentially supposed to be an entire JS development suite in a box, sort of akin to what Rome was promising a few years ago. [00:02:13]
-
-**Carl:** Cool. Love that. [00:02:40]
-
-## [TypeScript 7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) released
-
-**Mark:** Meanwhile, as mentioned, we have talked about this repeatedly, so I don't have to go into a lot of details, but TypeScript 7 is finally live. Hooray. This is the Go implemented native implementation of the TypeScript compiler that is supposed to be up to 10X faster, so the actual... [00:02:41]
-
-If you install the actual TypeScript package at latest now, it is actually built with Go under the hood. The biggest caveats here at the moment, as we've again talked about, the programmatic TypeScript API essentially does not exist in version seven, because the API had been partly official, partly unofficial before that And lots of different tools had various dependencies and needs. [00:03:00]
-
-A lot of them had hacked together solutions in the past, and so the TypeScript team said, "Okay, we know the compiler itself's working. We're gonna get that out the door. We want to take our time and carefully consider what a better and proper public API would look like to support all the different use cases people have come up with, and we'll get that out the door in, like, a version 7.1 or 7.2." so there is some, there is an update on that front. [00:03:28]
-
-## [open PR for “content mappers”](https://github.com/microsoft/typescript-go/pull/4712) to integrate other language syntax
-
-**Mark:** They've put up a PR for something they're calling content mappers, and the way I'm understanding this is that for other languages like, say, View or Angular that have templates, you want to be able to type check the templates. The TypeScript compiler handles JSX, which means React kind of got special treatment there. [00:03:56]
-
-But how can other languages actually get similar behavior for non-TypeScript syntax? And so this content mappers proposal from the TS team is a way that they're hoping they can address essentially a plug-and-play conversion of other syntax into something TypeScript itself can type check. So there, there may be other API integration things that they're looking at as well, but this feels like it's a, a good step in that direction. [00:04:17]
-
-And in the meantime, a bunch of teams are doing things with integrating with TS Go in hacky ways you're not supposed to anyway. [00:04:49]
-
-## Johnson Chu made [a compatibility layer to drop-in for unsupported tools](https://github.com/johnsoncodehk/typescript-native-bridge)
-
-**Mark:** Johnson Chu, who I think built the Alien Signals library, and I think also works on the Vue Volar language extension, if I've got my connections right, put together a package called the TypeScript Native Bridge, which is supposed to help polyfill some of the, I think, the language server-type integrations so that they're faster. [00:04:57]
-
-## [OXC type-aware linting stable](https://oxc.rs/blog/2026-07-22-type-aware-linting-stable)
-
-**Mark:** And then the OXC folks have been doing their own hacky native TypeScript integration to try to enable typed lint rules within the OXC linter. And so the typed linting support has just gone stable as well. So, lot of improvements around TypeScript compiling and checking in the entire tooling ecosystem. [00:05:18]
-
-**Carl:** Interesting. Yeah, type-aware linting would be a really big win. I've wanted that a number of times, and we've never really gotten there. [00:05:42]
-
-**Mark:** TS ESLint has them, but it requires a lot of slower integration and running full-blown standard TS type checking. [00:05:49]
-
-**Carl:** Cool. Can you talk about this install time security, Mark? [00:05:56]
-
-## [NPM v12 and new security defaults](https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation/)
-
-**Mark:** Due to the entire series of supply chain attacks that we've seen happen over the last year, one of the biggest issues has been that packages are allowed to run scripts after install by default. And so you're just arbitrarily executing remote code on your machine with your privileges. And so several other package managers like pnpm had switched to disallowing that by default. [00:06:00]
-
-And so npm 11 still allowed that, but they started adding the options to disable running scripts by default and preparing things. So npm 12 actually does flip the switch on a lot of those options. So npm 12 no longer runs post-install scripts by default. By default, it does not allow a Git repo URL as a valid dependency, and it has a couple other options that it turns off by default to enable security. [00:06:27]
-
-## [Dependabot supports a configurable delay](https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/)
-
-**Mark:** I also saw that GitHub is changing Dependabot, so it now has a cool down by default, so it won't install new deps until, like, two or three days after they came out. [00:07:00]
-
-So we are very, very belatedly, as an ecosystem, finally learning some lessons we probably should have learned many years ago, and changing some of the default behaviors of our tools to try to cut down on the blast radius of some of these malware releases. [00:07:10]
-
-**Carl:** Yeah. And we've covered some of that in recent episodes, so I, let's not rehash it entirely again. Mm. Yeah, definitely some, uh, long overdue changes here. [00:07:27]
-
-**Mark:** Yep. [00:07:37]
-
-## [More React RSC security tweaks for 19.x](https://github.com/react/react/releases/tag/v19.2.8)
-
-**Carl:** As well as, I guess, in w- security tweaks for server components that were just released this week. [00:07:37]
-
-**Mark:** Yep. Looks like another denial of service attack possibility. [00:07:44]
-
-**Carl:** Okay. [00:07:48]
-
-**Mark:** So just bad, bad... So not remote code execution, but bad input freezes the server. [00:07:48]
-
-**Carl:** Okay. Can't have that. That's a denial of service vector. Okay, well that's the, like, brand-new releases we have. There's some other new stuff, but a little bit, like, less, you know... N- we're not gonna start with it, but we're gonna do that towards the end. [00:07:54]
-
-## Main Content
-
-**Carl:** Main content. [00:08:06]
-
-## React org updates
-
-**Carl:** We are gonna start with the React org updates, and we're gonna frame this against the backdrop of, like, open source governance generally. There have been some changes announced by the, uh, you know, React Foundation within the Discord. [00:08:07]
-
-## “Leadership Council” and Working Group structure [on the new team page](https://react.dev/community/team)
-
-**Carl:** There's been, you know, there's been a, a couple of visible changes to the website and PRs to the actual governance repository. [00:08:22]
-
-**Mark:** I specifically had been griping, I think in the last two months, that I have no idea who's even on the React team anymore. And I don't know whether they literally heard me or whether this was just, you know, kind of coincidental timing. [00:08:32]
-
-But they did a significant update to the existing React team page on the website. They updated it both with, you know, current people involved in moving some folks to more of, like, an emeritus status. But the team page now actually reflects a new team structure that is coming out of this React foundation itself, where there's, like, a set of different working groups for topics like, you know, server components and compiler and, and other things. [00:08:46]
-
-But then there's, like, a leadership council that appears to be essentially, like, a, a representative from each of those groups, as well as possibly a couple others. So I still don't, still don't have a lot of details on the actual responsibilities, but we're seeing some visible evidence that they're working on the organization process here. [00:09:17]
-
-**Carl:** Interesting. Cool Curious, the reason I'm in the Discord is 'cause, 'cause somebody reached out asking if I wanted to help with community, and so now seeing a bunch of people listed as on the Docs and Community Working Group and nobody reached out to me makes me feel like I got left out. [00:09:39]
-
-But that's okay. I'm an independent actor, unaffiliated. [00:09:51]
-
-**Mark:** The list of working groups is, uh, server, DOM, fiber, docs and community, compiler, DevX, and React Native. [00:09:55]
-
-**Carl:** Yep. I am s- slightly surprised to see React Native generally put into its own single group, because they're a- at least as large as React. [00:10:04]
-
-I would say technically, you know, problem space they operate within is larger than React itself. So I'm slightly surprised to see it positioned as a single working group under the umbrella of React. But I guess, you know, there's other organizations that are more meaningfully invested in React Native, so, uh, maybe this is more of, you know, division of labor. This is the pipeline more than the umbrella, per se. [00:10:12]
-
-**Mark:** It's also worth noting that there, there's like seven or eight people on the leadership council, which I guess, you know, matches roughly the number of working groups. And then the working group members section is at least a good 20-plus people long for current people, and then there's a set of advisors and a set of emeritus people. [00:10:33]
-
-So there, there's a good 30 to 35 names listed on this page. Like, it's not just, you know, two to three people. [00:10:54]
-
-**Carl:** It's quite a long list, and it is much more specific. I don't know. We just complained about this, and it's really nice to see a, like, full refresh that looks reliable. That's nice. [00:11:01]
-
-## [Stub governance docs](https://github.com/react-foundation-dev/leadership-council) for the Leadership Council
-
-**Carl:** I was reading a little bit of the charter. It is pretty interesting. It looks like they're quite earnestly trying to make this, like, you know, open participation, and I've thought a lot about governance questions and stuff like cooperatives and, like, how do you do... If you have multiple people with opinions about what to do with a project, a shared good, I don't know, it's really hard, it's really hard to do that right in a way that allows people to feel represented and like they have agency in the overall system. [00:11:11]
-
-So I appreciate the challenge of what they are trying to do. It is difficult to set up a general organization that lets many people in many walks of life feel heard. I like the, the way they scoped it as, you know, "the mission and scope of the project is to develop and maintain React and associated open source software. The leadership council will be responsible for technical oversight of the open source project." [00:11:39]
-
-You know, like, this is... I can tell that from reading this, that the way that they are discussing responsibilities and constraints and decision-making and work delegation, like they are very meaningfully trying to make this open participation And with a high bar of quality. [00:12:00]
-
-Yeah. This is, you know, primary source kind of stuff. This is-- The commit on this charter.md document is two days old, so this is, like, brand new. No one has really been... This is a- as yet untested. The processes described here are not currently fully implemented. But yeah, what I see here looks quite good to me. I like it. [00:12:19]
-
-**Mark:** And to be clear, like, the, the repo's public. I mean, I can look at this information right now. I don't-- The- there hasn't been, like, a formal team announcement of the leadership council and the charter per se, but clearly they're trying to put all the pieces together to be able to say, "This is the way we're gonna do things." [00:12:38]
-
-**Carl:** Yes. Okay, I don't see-- I heard rumor of a, uh, pending blog post, but I, I don't see it yet, so... But yeah, I expect that there should be some broader announcement of what this is and what it means and what their intentions are coming soon. But what I see here looks quite good. I like it. It seems like a good effort. [00:12:56]
-
-**Mark:** Like I said, I, I griped a little bit about the lack of visible progress in the last few months, but clearly what we're seeing here, and even what I'd heard about the amount of effort that was needed to just create the foundation in the first place. Like, there is a lot of effort going on behind the scenes, clearly, and there's a lot of good faith intention behind what they're trying to accomplish. Like, this is not just for show. [00:13:13]
-
-**Carl:** Yes. Agreed. [00:13:36]
-
-**Mark:** One of the longstanding complaints about- You know, the community with React and React with the community has been, they do most of their coding work in public, but there's also some that happens behind the scenes in private. And historically, they've had the problem that any time they push a draft PR, people jump on it. [00:13:37]
-
-It's like, "Oh, React is working on this new feature," and they start writing blog posts and tutorials and everything. And so that has actually made the React team less likely to show their work in public, because a lot of times it is an experiment or a prototype, and there's no guarantee that this will even ship at all. [00:13:55]
-
-So there's been discussion on both sides that it would be really helpful if they tried to follow a TC39 stages model, where it's very clear that we are working on concept X. It is a stage one prototype, a stage two, like, we think this is likely. Stage three, this is probably gonna ship. Stage four, it's ready. That kind of thing. [00:14:14]
-
-## Rick Hanlon update on the React team [using a “stage” process internally](https://www.reddit.com/r/reactjs/comments/1v1dsh0/react_rfc_processis_it_dead/oyp9wac/)
-
-**Mark:** And so Rick posted a comment on Reddit saying that they've been trained to follow that model themselves internally and had some success with it. But essentially, they're trying to prove to themselves that they can actually work using that approach before they fully publicly commit to doing that and making the scale, the stages and progress public. [00:14:37]
-
-**Carl:** Yeah, and we've talked a couple times in past episodes about the general challenges, like the tensions there of them earnestly wanting to work in public and having repeatedly tripped over the same problem every time they've tried to of, you work in public and then you get just a bunch of yahoos talking over you as you're... [00:15:01]
-
-You know, the, the people who don't, people who haven't seen the work that went into the current state that is actually now public and end up just re-litigating all the same issues or, you know. So there, there are a lot of very real challenges there, and I earnestly appreciate the continued exploration of how to make that actually functional and work well for as many people as possible. [00:15:18]
-
-## [Pete Hunt and Nick Schrock join Vercel](https://x.com/rauchg/status/2077870043833229692) to run Frameworks/Next and Agent DX
-
-**Mark:** One other small but related item. You know, there are a bunch of React folks at Vercel at this point, and Guillermo just announced that Pete Hunt and Nick Schrock have both joined Vercel. [00:15:39]
-
-Pete Hunt was one of the first advocates for React at Facebook at the time. He did one of the more famous talks that helped get React off the ground in public. He had spent the last few years, I think, working at a company called Dagster that just got acquired, and so this is presumably his chance to move on from that. But the announcement is that he'll be leading the frameworks group in Next.js itself. [00:15:52]
-
-And then Nick Schrock was instrumental in the development of GraphQL as a spec at Meta, and he is gonna be working on Agent DX or something along those lines. [00:16:18]
-
-So Ver- Vercel continues to scoop up more and more of the folks who were involved with React at Meta at some point in the past. [00:16:31]
-
-**Carl:** Yeah, I'm curious to see about the interplay between Agent DX and the GraphQL, because increasingly so, what an agent needs to do with an arbitrary server is get the data it wants And that's what GraphQL's good at. [00:16:39]
-
-Hey. Yeah, I'm skeptical of MCP. MCP is gonna die. Actually, no, it's not gonna die. It's gonna, it's gonna live forever the way that, like, SOAP does. Yeah. It's gonna be an early exploration of a, an A- API, and I think it's going to be widely hated in five years. Calling it now. There's my mark on the yardstick. [00:16:56]
-
-## Poimandres [published a charter](https://github.com/pmndrs/org/blob/main/CHARTER.md) (original [announcement](https://x.com/pmndrs/status/2080303456800080047))
-
-**Carl:** Related to the org updates and open source governance more than that last update, though, Polymanders has published their charter as well. It's been around for, I would say, at least eight years, maybe 10 years at this point. Oriented around Three.js and 3D rendering on the web, I think is a fair characterization. [00:17:16]
-
-**Mark:** A, a number of, number of folks there have prior experience in game development one way or the other. Sort of a set of artists collaborating to build related things together kind of a vibe. [00:17:36]
-
-**Carl:** Yes. Yes. Right. We all have a shared interest, a shared passion in this. You know, I open their website and it's full of WebGL demos with, you know, parallax and physics and refraction and, you know, translucent interact... [00:17:50]
-
-You know, so it's, that's generally what they're anchored around. It's a bunch of artists doing art on the web in different ways, playing with visual technology on the web. And I- when I say playing, I don't mean to diminish. I mean earnest play in the sense of exploration. [00:18:05]
-
-**Mark:** It's also worth noting that was originally developed by one of the, one of the earlier folks in that org, and I b- and I think Z- possibly Zeustin and Jotai and Vultio are still owned by that org on GitHub. [00:18:21]
-
-**Carl:** Yeah. Zeusstand, React Three Fiber, React Spring, Jotai, Volto, Drei. [00:18:37]
-
-**Mark:** Some very solid well-known libraries in the React ecosystem. [00:18:42]
-
-**Carl:** Yes. Yeah. Tons and tons of well-known projects. Yeah, so like, I hope that didn't sound diminishing because I do not mean to diminish. [00:18:45]
-
-These are talented, respected. But yeah, so they, they... As a point of comparison, these other technical, highly technical, highly skilled folks have also published a charter, and I think the React one is a little bit more clearly articulated. I appreciate this charter. It is, you know, it discusses the core principles and what it means to be a member and how decision-making works and how they adopt projects. [00:18:52]
-
-But, you know, it's like the membership is one paragraph and says, "What are the working roles? There's no strict definition of a working role." So it's more vague. There's less buttoned down there. Which makes sense. You know, this is an open source collective of artists who are very talented, and they're very talented in more along technical things. [00:19:16]
-
-Like whereas people coming from Meta are much more experienced in the corporate aspect of precision of language and clarity of, you know, communication and definitions in documentation like operating agreements and charters. So i-it's, I'm positioning these in reference to each other, mostly because of the coincidence of timing of them having both come out at the same time, and because I think that's a really interesting and valuable comparison to draw. [00:19:32]
-
-What does it look like when a corporation helps found a foundation versus what does it look like when artists as part of a collective do the same thing? These are contrasting ideologies creating something, and these are two examples. I think it is fascinating to look at both. [00:19:57]
-
-**Mark:** So let's say they wanna work on a, uh, React Three Fiber version 10 to be able to make use of WebGPU and make it more AI agent friendly. [00:20:12]
-
-## An [example initiative](https://github.com/pmndrs/org/blob/4bd14e20da776ff68f7555a57a01ad0b4999be92/initiatives/03-text-rendering.md)
-
-**Mark:** They'd like to work on their own design system for common look and feel and behavior. And then they also want to work on better quality text rendering in WebGL, apparently. [00:20:20]
-
-**Carl:** Okay. Cool. I appreciate that. Yeah, text rendering is really hard because it's actually insane when you start drilling into the details of how glyphs are rendered on your screen. [00:20:33]
-
-F- 'cause like for instance, if you're on a low DPI monitor, they will do all sorts of crazy sub-pixel rendering in order to make it look, you know, 20% crisper. Which ironically actually Apple gets flack for now because all of their displays are high DPI, and so they don't do those anymore, and then it's really hard to get crisp icons on OSX. [00:20:43]
-
-**Mark:** Yeah, anytime a text rendering article pops up on Hacker News, I end up reading it, 'cause there, there's some deep stuff there. [00:21:01]
-
-**Carl:** Yes. If you see text rendering or Unicode in a blog post title, like I highly recommend checking it out, because you probably take it for granted, and it's probably like insanely complicated. [00:21:08]
-
-Text rendering in WebGL is likely going to be a fascinating project that deserves its own full initiative from a, uh, collective of expert engineers with visual experience. [00:21:18]
-
-## React-alikes
-
-**Carl:** Cool. Okay, let's move on a little bit. Recently, we've been covering more and more React-alike projects. I'm gonna coin it, I'm calling it, these are React-alikes. [00:21:30]
-
-## [Octane](https://octanejs.dev/) from [Dominic Gannaway](https://bsky.app/profile/trueadm.dev/post/3mrn7yd6dzk2t)
-
-**Carl:** Yeah, we've got a new one, Octane, from Dominic Ganaway. [00:21:40]
-
-**Mark:** Yeah. Okay, so there's, there's a whole causational chain here. So Dominic started off by creating a library called Inferno back in 2014 or 2015, and the idea was React similar, but much, much faster. Whereas Preact was, say, like React, but only for the web and as small as possible. [00:21:43]
-
-So, like, there was like a Inferno-React compat library that tried to fill in some of the differences in behavior, but the whole point of Inferno was let's make something very small and very fast. Dominic joined the actual React team and was there for a few years. He left Meta. He, I believe, worked with Rich Harris in some of the Svelte 5 stuff for a while. [00:22:06]
-
-And we actually covered Dominic just in the last couple months because he recently released a- another different framework called Ripple, which tried to pull together a few different ideas, and he also released a JSX improvement language called TSRX, and then iterated on its design a couple times. So he's back, and he has another new framework called Octane, and the sales pitch for this one is very intriguing. [00:22:30]
-
-It's essentially what if we took React's syntax and pretty much almost all the semantics, but we have a compiler, and thanks to the compiler, we can eliminate the virtual DOM, we can get rid of the rules of hooks, and actually have, like, conditional hooks, and we don't need a dependency array. And so there's actually a, a very strong connecting line through all these things. [00:23:04]
-
-It's like what if React, but better in certain ways. Svelte was all compiled. TSRX is a compiler syntax layer. So there's a lot of different previous threads of work that are getting pulled together in this project. Now, I took a look at the commit history for this project. It looks like he only started working on this, like, a month or a month or and a half ago, thereabouts. [00:23:29]
-
-You can pretty s- quickly see the commit messages going from, you know, first test, try this, oops, broke, fix, whatever, to, like, very quickly building up the pieces And he's officially launched it in some sort of like, well, I don't know what the actual version number is, but like he feels it's ready enough for people to try. [00:23:58]
-
-The implementation has obviously been AI built. Here's where it gets interesting. So he just joined OpenAI to work on their own web front end. I believe he'd been using Claude To do the implementation. But in some discussion on Twitter, he said, like, "I am actually seriously pushing Octane forward because OpenAI heavily relies on React in their web stack, and we need to essentially, like, find ways to make that faster and more optimized." [00:24:22]
-
-So there's both the personal history of, "I am very familiar with React and its ecosystem, and I'm trying to push it to the next level, and now I have a day job that will fund me to do that, and also g- they get to benefit from them." One other interesting technical point out of this. So it's React syntax and almost React semantics, but it's totally different packages, which would normally mean that there's no ecosystem out of the box because there are no packages that import from Octane. [00:24:55]
-
-There are packages that import from React. So if you look at the Octane repo, there is an entire subfolder where he has programmatically built adapter layers for commonly used React libraries to make them work with Octane, ranging from component libraries to, in our case, React Redux and Redux Toolkit. [00:25:28]
-
-Essentially, look at the actual source code, create a port or thin adapter layer that imports from Octane instead, and I assume they work? So it's brand new and no one's using it yet, but this looks very genuinely fascinating on multiple levels. [00:25:51]
-
-**Carl:** The thing I'm observing on the homepage in the announcement, you know, code snippet, it looks extremely familiar, except for there's no return in this function, which is strange. [00:26:10]
-
-**Mark:** That'd be the TSRX. [00:26:22]
-
-**Carl:** Right. [00:26:23]
-
-**Mark:** In fact, n- notice if you look carefully, there is a, there's an @ symbol right before the opening curly brace. That's apparently the TSRX symbol that this just auto-returns. [00:26:24]
-
-**Carl:** See, I don't like that. Th- th- those feel like personal preference decisions that don't actually really matter. It reminds me of, like, CoffeeScript. That was so mixed. It was so perfect. They had the single versus the double arrow function, which would change the behavior of binding this. You know, a hyphen greater than did normal function binding, and equals greater than bound this automatically to the function. And people loved that so much that we pulled it into this language, and that's where we got arrow functions from. And I don't think that this at symbol justifies it to the same degree. Like, I don't think implicit return... Like, JSX had an implicit return, too. You know, it was like you add braces or you don't. [00:26:34]
-
-And so adding a new symbol to the language in order to change the behavior of something that we already have a, a variable on, I think is gonna be a distraction. I think that's a, I think that's an API failure, I would say. Like, the rest, plenty of these, you know, the rest of these all seem... It bothers me that it's so close to being familiar, while m- making a, a dramatic departure like that. Implicit return is a big difference. [00:27:18]
-
-**Mark:** It's worth noting that it does support both existing JSX syntax and the new modified TSRX syntax, so it is pick and choose. [00:27:45]
-
-**Carl:** Skeptical. It's interesting. Overall, I think this is a really good idea and a good direction to explore. I'm reacting strongly to that small note because I think this is good to explore, and that feels like a, that feels like a unintentional self-injury that will make it more difficult for this to succeed, I think is why I'm calling it out. [00:27:54]
-
-But yeah, I think that's really cool. Like, you know, boom, they got a use effect in an if. Can't do that in React. So conveniences like that seem really cool, and I'm excited to see if this works, and I hope that it doesn't introduce foot guns that make it less successful. [00:28:11]
-
-## Ryan Carniato: ["React’s staying power is because of complacency"](https://x.com/RyanCarniato/status/2072382108535066640)
-
-**Mark:** Yep. That ties into the next bit conveniently because we organized it that way. [00:28:27]
-
-I think partly in, in response to the release of Octane and some other related discussions, Ryan Carniato had a couple tweets that relate to this. So, like, you know, one of Solid's selling points has been that it mostly looks like it re- like React. It uses JSX syntax. It is JavaScript inside. Okay, the state and the effects are different, and the getters are different. [00:28:31]
-
-But, like, it looks like React much more than Angular would be. So Ryan had a couple tweets where he was commenting that, you know, at this point, he feels like the... React is commonly used largely because of complacency. It's the modern no one got fired for choosing IBM kind of a thing. [00:28:52]
-
-## Follow-up: [“Do people think FE innovation is dead? Would explain why there’s resistance to move past old React.”](https://x.com/RyanCarniato/status/2081813329681711152)
-
-**Mark:** And then he also had a, a tweet commenting on, like, do people just not feel that there's going to be any more innovation in front end? So I mean, like, he's been talking about a number of these points for a while, so, like, there's not necessarily, like, new changing details there. That, we've talked about this before, you know, AI is sort of encoding React as the default, and we're also still stuck in writing, like, 2019 era React and not even using a lot of the newer APIs. [00:29:12]
-
-**Carl:** Yeah. I do appreciate this chat shout-out. "Directly contradicts the meme of a new framework every week." Like- [00:29:47]
-
-**Mark:** Yep ... [00:29:52]
-
-**Carl:** all right. Yeah, can't have it both ways. We're literally, the JS ecosystem is criticized for all things at every moment. [00:29:53]
-
-**Mark:** I mean, why not both? We can have a new framework and nobody uses it. [00:30:01]
-
-**Carl:** Yeah. True. Entirely real. [00:30:05]
-
-**Mark:** I mean, the number of times I've seen new "React state management library" posted on r/reactjs, man. [00:30:08]
-
-**Carl:** Yeah, you know, actually, I'm gonna tie that back to what you just said of not moving past 2019 era React. People are still doing 2019 era open source announcements of, "Hey, I made a new library." [00:30:14]
-
-And like, yeah, that worked 10 years ago. I don't think it works anymore. But yeah. [00:30:26]
-
-## Parallel articles on [Solid 2.0 with async](https://www.brenelz.com/posts/learning-solid2/), and [Remix 3](https://malstrom.me/blog/learning-remix-3)
-
-**Mark:** One last little point on that note. We've talked before about both Solid 2.0 being in beta and having some new, uh, async features with the asynchroness baked directly into the signals graph. And someone put up a good, you know, w- very well-written tutorial-like post illustrating both just the overall usage and talking about some of the nuances there. [00:30:31]
-
-And then someone else explicitly ported the example app into Remix Version 3 as a intro to how you would do things with Remix 3 as well. [00:30:55]
-
-**Carl:** Cool. Nice. Love that. Anytime somebody does a direct port of one app to a different framework, especially in demos like this, I love it. I listen to a lot of economics, and there's a big thing, uh, in that field about natural experiments. Like, you know, y- some decision is made, and boom, now you have a randomized population that you can determine the outcome of that decision on. [00:31:07]
-
-This feels like this, uh, open source equivalent. Somebody made a demo app, somebody else ported it to an different framework, and now we have a very pure comparison of those two frameworks. [00:31:29]
-
-I have always thought it would be incredibly valuable if we had a, like, representative, like, "No, this is the best possible to-do app in nine different frameworks." [00:31:40]
-
-**Mark:** That was the whole to-do MVC website back in the day. [00:31:50]
-
-**Carl:** But then, like, they all suck. I feel like none of them achieved... Individually, none of them were actually good enough to wear that mantle, and so it was like, wait, actually, these are not, this is not... [00:31:54]
-
-Or, I don't know, maybe that's just a reality of the fact that you cannot actually have a single the best anything because there are nine different approaches to doing tables in React, and so you cannot make a single definitive React to-do list. But, oh, man, I... So anyway, that's why I love that somebody has ported one demo app from one framework to another. This is really good. [00:32:03]
-
-## [Cross-framework benchmark measuring reactivity](https://bsky.app/profile/nullvoxpopuli.com/post/3mrplyqcd722j)
-
-**Mark:** All right. So there, there's a long-running JS frameworks benchmark that's been out there that measures things like loading performance or swapping items in a long list, et cetera. That has been, like, the holy grail that every new framework tries to add and measure itself against. [00:32:22]
-
-NullVoxPopuli, who is part of the Ember community, has put together a sort of similar benchmark, but trying to solely measure the reactivity and re-rendering portion of it. [00:32:40]
-
-I only glanced at it. I don't fully understand the nuances and the differences of how, like, what is being measured differently than the, the JS framework benchmark. But I've, I've watched this person long enough to know they have a pretty good idea what they're talking about, and so they're trying to measure more about, like, the, the state update sequence, I think, than necessarily just, like, DOM loading time or something to that effect. [00:32:53]
-
-**Carl:** Yeah. So I mean, this table has- Incrementing render effect. So I guess that means the length of time it took to render and then produce an effect that would increment and then thereby trigger a re-render, an infinite loop, it sounds like. And it's saying React took 8.7 times longer than the baseline to just do that. [00:33:19]
-
-Which is, [00:33:38]
-
-**Mark:** which is Angular apparently. [00:33:39]
-
-**Carl:** Yes. Or the baseline there was solid, but yes, most of these Angular is the, is the benchmark. [00:33:40]
-
-Okay, this is interesting. So this, these are a lot of... This does look like a pretty solid stress test. You know, like 1,000 item list, one update on 25% of items at random. Like, that's pretty good. You know, that reminds me of like a stock ticker, you know, a table of stock results with real-time prices updating. [00:33:47]
-
-**Mark:** Interesting. I actually just dealt with that scenario in the React Redux prototype branch that I'm working on. I'm going to have to go steal some ideas from this, for this one too. [00:34:06]
-
-**Carl:** Ah, there you go. [00:34:14]
-
-Yeah. I had to render sparklines once, and do you know how many DOM nodes are in a sparkline? Do you know what happens if you render one sparkline for 30 table results? So I, yeah, the optimization that has to go into that is kinda crazy sometimes. But yeah, cool. This looks like a very good benchmark. And yeah, it is in fact saying that Angular has the best performance as rendered by time spent- [00:34:15]
-
-**Mark:** Doing the data update work, I think [00:34:38]
-
-**Carl:** the values here are not super-duper helpful, I would say. The options here are values raw, so I don't k- I, like, I don't know if that's raw on milliseconds. I don't know what unit's it in, or a score, which is also not helpful, or multiplicative relative time. So anyway, this is really interesting. I think this has potential to be very helpful. [00:34:42]
-
-Benchmarks are great, and we have a new one. [00:35:02]
-
-## Aiden Bai released [ReactBench to measure AI code quality](https://www.reactbench.com/)
-
-**Mark:** And then one other benchmark, Aiden Bai, who has been on a tear releasing various kinds of React-related analysis tools, right up my alley, put out a React bench to try to measure how well different AI models write React code. He put together some kind of a scoring metric for common mistakes and patterns, and is measuring how well they actually write good code versus bad code. I'm assuming that a fetch in a use effect is scored as bad. [00:35:04]
-
-And for the record, apparently GPT 5.6 is leading at a 53% score on the benchmark. [00:35:38]
-
-**Carl:** Cool. Interesting. I love this because this is such a, like "code crafts person" versus "fuck it, ship it" attitude. This is something I felt like I had to get over in my professional career, 'cause I jumped around employers so many times, and I was so close to the React ecosystem, it's like, "Oh, cool. [00:35:45]
-
-I know all the best practices. I know how to do it right." And then you join a company, it's like, "Oh, you're just putting a component in state? Got it." Yeah, I bet the, I bet all of these models are trained on some pretty garbage code, because most of the code in the world is complete garbage. And I think that's very clearly demonstrated by the highest score on this being 53%. [00:36:00]
-
-**Mark:** I'm gonna have to go dig into that benchmark to see what they're actually scoring things on. [00:36:20]
-
-**Carl:** The time I saw a component being put into state was during a take-home test... No, during a whiteboard interview for a new company, and I terminated the interview because I was like, "If you're doing this, then I do not wanna work here. I am so sorry." [00:36:24]
-
-## [Alex Russell blasts “state management”](https://infrequently.org/2026/07/state-management/) (and most of the React ecosystem) in favor of sync engines
-
-**Mark:** All right, so that, that ties into our next item. Alex Russell wrote a, as usual, incendiary blog post blasting the React ecosystem and its practices. And as always, it's a very well-written post, and I actually agree with and understand a lot of the points he's trying to make. I disagree with the conclusions and the way he's messaging a lot of them. [00:36:37]
-
-**Carl:** Yeah. [00:37:05]
-
-**Mark:** So his first argument is React has built-in state management, but the existence of dozens and dozens of state management libraries must mean that either React isn't a state management system or React is an insufficient state management system. And I think we would all agree it's, it is a state management system, but it's very insufficient, the fact that it's all tree-shaped. [00:37:05]
-
-So that's why we have all these external state management libs. He then goes on to, to blast the fact that there's the plethora of external state management libraries and that they're all big and complicated and basically just pub/sub event emitters. But where-- He then takes it in a very surprising direction, which is essentially that all these different state management libraries, quote, and I will paraphrase, "Don't actually manage state." [00:37:32]
-
-They store a value at a point in time. They are pub/sub and trigger updates, but they don't have any sense of what was the state over time or how do you intelligently merge in changes over time. And so he then points to sync engines and CRDTs as essentially this is what I think is the right way to manage state. [00:38:02]
-
-Of course, half his argument is all these libraries are large and then people do bad things for SSR and hydration and send down massive JSON blobs, and that leads to bad perf. But he's also primarily arguing that the entire way the React ecosystem uses the word state management is wrong, and that almost everybody would be better off using some kind of a sync engine or, or CRDT to both auto-merge changes as well as manage the time aspect of changes. [00:38:36]
-
-I hear what he's saying. I disagree on a number of levels. When I wrote my Redux versus Context post a few years ago, I actually explicitly said that to me, a state management tool is, well, essentially pub/sub. You store a value, you have a way to update it, you have a way to read it, and a way to trigger updates. All these libraries fit that category. He's the one trying to put the extra dimension of time on top of that. [00:39:12]
-
-I agree sync engines and CRDTs are useful, and that probably a lot more people ought to look at them. But I feel like saying these are a blanket solution that almost everybody should go with if, you know, assuming you're doing more than just server-side rendering, feels like it's a pretty big step. [00:39:39]
-
-And so I had a bit of a debate with him on Blue Sky about this, kind of trying to probe and get him to expand on a few of the thoughts, and he eventually did say that like, "Yeah, I'm basically saying that everyone needs to have a major mental shift in how they approach thinking about state whatsoever In applications." [00:39:59]
-
-Which I get what you're saying, and number one, that's not going to happen, and number two, I don't agree that it needs to happen. [00:40:18]
-
-**Carl:** Yeah. The, specifically that thought, that expressed thought of, "the problem here is that everyone else is thinking about this wrong and everyone needs to learn this new thing in order to do it correctly." [00:40:25]
-
-Categorically, I'm gonna say that i- if that's your defense, it's ineffective. Like, no one has, no idea has ever been adopted to that extent. Like, the best you get is something like React. React is one of the most widely successful used technologies like that, and we're discussing how badly abused it is. So like, no, you are never going to get everyone to do any particular thing in a particular manner. [00:40:39]
-
-I also empathize. Like, most state, quote-unquote, in React apps is actually cache. You know, and we've discussed how, like, most state should just be like React Query, because actually you're just caching network state. This is not your local state. [00:41:06]
-
-**Mark:** Use Nuxt, put more of it in the URL so it, it survives a page refresh. You know, use, use uncontrolled form inputs, that sort of thing. [00:41:20]
-
-**Carl:** Right. Right. And so sure, it is probably technically, from a technical perspective, it is correct that we are misusing state. State is a precisely def- defined technical term, and we are probably misusing it. We are certainly misusing it. But like, I don't know, what are you gonna do about it? [00:41:29]
-
-**Mark:** I tried to hint at this in the Blue Sky thread, and you didn't really bite on my train of thought and went in a different direction. But like, I'm a big fan of going back to how did we get here, what problems were people trying to solve? Problem A leads to problem B leads to problem C. Each stage builds a new tool to try to address the previous problems we had. [00:41:48]
-
-We went from, you know, you can't do JavaScript in the browser to you can do a bunch of JavaScript in the browser to, okay, y- we've got jQuery to make it easier to work across browsers, but you're just toggling a class in the DOM. You're hoping that the DOM is what you think it is at that point in time, otherwise it breaks. It's hard to scale all these jQuery click handlers. What if we tried using actual variables to keep track of this data? How do we start to write larger scale structures and architectures? Keeping track of all this logic's hard. What if we just declared what we want it to look like and let the framework take care of it? Okay, we're having trouble keeping that data in sync across large parts of our apps. [00:42:08]
-
-So I'm not saying that the current React or front-end ecosystems are Great. I'm not saying that they are, like, you know, absolutely the best possible theoretical way we could have landed on doing things, but I do think it's important to say, "This is how we got here, and this is the real world current state of things. What can we practically do to improve things?" [00:42:50]
-
-And so I would be very happy to have conversations with Alex about, like, "Okay, here's how the React ecosystem got here. I'm sure you know this already, but, like, this is where we are. Here are some influ- here's are some ways we could try to nudge things and push people towards mentally modeling." [00:43:20]
-
-But just starting off by saying, "React claims to have state management and it doesn't fit my definition, and therefore it's wrong, and everyone else has weighed these things on top that aren't my definition, therefore they're bad, and also bad at perf." I get that he- a little bit of this is him venting, and I think part of it was the, "I've had these discussions, let me write down my thoughts so I can refer to them." okay, cool, agreed. But it feels a little bit like shouting into the void, and it's not going to improve the situation at all. [00:43:36]
-
-**Carl:** Right. Yeah. Like, there are two little trigger phrases here that make me go, "Er." And one is the first sentence. "It is by no means the gravest linguistic crime of the React epoch, blah, blah, blah." [00:44:05]
-
-But, like, okay, so, like, literally this starts off announcing that a gripe on semantics. Th- this is framed as a linguistic crime, so it's just definition and what are we talking about. And then at some point it's like his stated resolution here is, "Devs should..." And like, boom, done. You lost me. Devs is not precisely defined. Who are you talking about? Who needs to make a change? [00:44:15]
-
-And you just say should. Like, devs should do something. Like, I don't know. Any- anytime somebody uses a general statement about a large population to say, "Everyone in this group should do X," like, you're wrong. It does not matter who you're talking about or what your idea is. [00:44:38]
-
-That is never correct. So right. I, like, I broadly agree with the perspective here as I- correctly identifying a problem. [00:44:53]
-
-**Mark:** As my mom used to say to us many times growing up, "You stated the problem, now state the solution." [00:45:02]
-
-**Carl:** Right. It's a problem. The solution is hard. [00:45:07]
-
-Like, there are lots of very smart people working very earnestly on this problem. You know, we as an industry are exploring the cutting edge of UI and what does it mean to interact, you know, human computer interaction used to be considered a field of academic research. And, like, all of us are HCI experts with no credentials and no... [00:45:09]
-
-Like, you know, there's no scientific rigor behind the experiments we do. Our company, our companies just say, like, "Oh, I think this should be-" A dropdown instead of a type ahead select. And like, you know, okay, why? Oh, well, you know, that's what the design, that's what the design spec calls for. Okay, well, why? Well, that's what the designer wrote down. Well, okay, does that, how would people interact with that? This is a human computer interaction question, and there is a body of research. [00:45:30]
-
-We are earnestly exploring all of this without the support of traditional, like, in years past, in decades past, people doing this type of exploration of a, a problem space might have the support of things like academic journals with peer review, and then ultimately, if it's published in this journal, then you can trust that it went through this review process and, you know, that by being present in its current form, it represents a consensus from this perspective. [00:45:56]
-
-And like, we don't have that. We have blog posts. Like, you know, we have vibes of popularity. So like, we're exploring a really challenging problem space without very much ability to capture the results of those explorations, and that's a very hard space to be in. But that to say, I think there's a lot of really interesting stuff happening with sync engines, Electric SQL. I've, I remember hearing about a long time ago, the... Oh, God, I can't remember some of them. There were a lot of really good sync engineed and local first- [00:46:26]
-
-**Mark:** Electric, Zero, Replicache, maybe that, maybe those are the same company. Howard Sync is out there, I think. [00:46:55]
-
-**Carl:** Yeah. Thank you for filling in the gap. I have lots of the ideology and less of the, uh, proper nouns. [00:47:02]
-
-But so yeah, yes, correct. This is a problem. People do misuse date, quote, unquote. But yeah, the way you change that is by effectively broadcasting a message that allows people to observe that their previous practices were incorrect and guides them into more correct practices. [00:47:07]
-
-**Mark:** Update the docs, add a linter, build it in by default. [00:47:27]
-
-**Carl:** Right. None of those include an angry blog post. I relate to that as someone who wishes to write angry blog posts, but I don't think it's an effective solution to the problem [00:47:30]
-
-## Aurora Scharff [rewrote the Suspense docs page to cover how it works](https://react.dev/reference/react/Suspense#what-activates-a-suspense-boundary)
-
-**Mark:** Aurora Scharf, who has been doing a lot of fantastic conference talks and blogs on using Next.js and using Suspense in the last couple years, joined Vercel and i- in a dev role, role, and has been, I guess, part of or working with the React team. [00:47:41]
-
-I think she's actually listed on the team page. And so she actually just did a significant update to the Suspense docs page to add a lot of details on what are all the cases that actually trigger a Suspense boundary, as well as some of the, the other use cases. So again, great to see a lot of the, the usage and technical details being fleshed out in the official docs. Always something I'm asking for. Yay. [00:47:56]
-
-## And a post on [RSC performance patterns](https://aurorascharff.no/posts/experimenting-with-rsc-for-performance-and-ux-in-nextjs/)
-
-**Mark:** Uh, and then she also wrote on her own blog a, a post on some various Suspense-related usage patterns that she's been playing around with. [00:48:22]
-
-Cool. [00:48:31]
-
-On the flip side, the TanStack folks have added initial server component support in its own form to TanStack Start. We've talked about that in previous months. [00:48:31]
-
-## [TanStack removed RSCs from the website](https://tanstack.com/blog/we-removed-rsc-from-tanstack-com)
-
-**Mark:** And I believe they had been using that in the actual TanStack.com website, primarily to move heavy markdown rendering to the server so you weren't shipping the, the markdown rendering logic to the client and having to wait for that to happen. And apparently they've removed that. They put up a post saying they actually pulled out the server component usage. [00:48:41]
-
-It worked, but it, they weren't getting a lot of benefit out of it, and it was actually hurting perf in some ways. And instead, they have restructured things. They've actually shipped a couple of very tiny libraries to do markdown parsing, and then separately, syntax highlighting. And so essentially going back to a somewhat more SPA-ish approach, but minimizing the amount of work done so they still get fairly fast loading times. [00:49:01]
-
-**Carl:** Nice. Let me tell you, doing syntax highlighting on a documentation site is fucking crazy. I underweighted that as a problem circa 2018, and it almost killed the entire project, because we had wanted a single API reference page constructed from dozens of markdown documents, so we could maintain it as individual docs, but have it presented in a single, large, searchable page. [00:49:26]
-
-And holy shit, we were shipping 12 megabytes of HTML across the wire because of syntax highlighting. We took syntax highlighting out, and it dropped to, like, you know, 600 kilobytes. Which is still insane, and, like, part of the reason it almost killed the project, because we just were trying to put too much docs on one webpage. [00:49:48]
-
-But- Yeah, man, like when you start highlighting individual, every individual character and wrapping it in glyphs, in a span which has a class name, and, uh, so it's, it is insane how much markup bloat gets added just by syntax highlighting. So moving that from rendered on the server, shipped to the client, into data is passed from server to client and then rendered on, on the client makes total sense to me. [00:50:05]
-
-But that's why this is the cutting edge of UI, 'cause like that sounds so obvious. Of course you just want a rendered page to come directly from the browser and oops, that rendered page is 20 times larger than it could be if you just sent the raw data needed to render it. So that's why it's so impossible to answer the question abstractly of whether or not server components are right for you, 'cause I don't know. Do you know? [00:50:32]
-
-Anyway, that's a fun project. This is a really good case study. I love it. [00:50:56]
-
-Mark, tell us, I'm giving you an opening to talk about your performance prototyping. [00:51:00]
-
-## Mark’s making progress on [some React-Redux perf prototyping](https://github.com/reduxjs/react-redux/pull/2318) and thinking about RTK 3.0
-
-**Mark:** So I'm pretty sure I alluded to this two months ago, and then I linked the draft PR last month. But for the last few years, I've been kicking around the idea that surely there is some way that I can magically use some combination of signals and proxies inside of React Redux to speed up performance updates in large scale applications. [00:51:04]
-
-So cases where you have thousands of connected components, and right now we have to run all end subscribers and selectors on every dispatched action just for each selector to grab its state and diff the result and see if it needs to update. That's fine when you've got 500 or 1,000 components. When you've got 5,000, 10,000, whatever, that's just the overhead of calling those subscribers is expensive. [00:51:26]
-
-So I played around with a couple proof of concepts in previous years. They were like, you know, like one-off, I'm gonna hack on something, and didn't get any further. So I finally came back to that , and I did a whole bunch of research on other signals libraries, proxy-using libraries. What do they do? How do they work? What are they good at? Where do they break? All very AI powered. [00:51:54]
-
-And I have a working branch that adds a useSignalSelector hook to React Redux that is using the Alien Signals library inside. And essentially what it does is it wraps your selector so that the data is in a proxy, tracks what fields got accessed, and then essentially precomputes, "Hey, this was the state that got updated. Do we think that selector actually needs to run? Nah, skip it." With the idea being that in most cases, only a relative handful of selectors actually need to rerun most of the time. So if we can just pre-skip most of them, that ends up being a performance win. [00:52:16]
-
-So I have a draft PR. It works, and it appears to be a significant performance win almost across the board. In terms of the number of updates, in terms of the total amount of scripting time that executes. It's a little bit slower in the mounting phase because it takes more work to set up the signal and the tracking time. [00:53:03]
-
-There's definitely going to be some bigger bundle size. I don't know how big, like 5 to 10K maybe. And there's also a few weird cases, like doing certain identity comparisons won't work because you're comparing the proxy reference and not something inside the proxy. [00:53:25]
-
-But it feels good enough, and I've got solid enough test coverage that I actually feel very good that, like, this is a, this is the direction that I would probably end up shipping. There's a lot of work to figure out around real-world testing and, you know, like all, all the, all the non-fun stuff around actually shipping real software. Uh, but the idea is it would be a separate set of exports. You would intentionally choose to use this. So like most apps would still have useSelector by default, but if you have a large-scale app and performance is a problem, then-- And you, you could choose to import this and make slightly different trade-offs in performance and bundle size. So I feel pretty good about that, and I'm, I'm still finding time to try to push that direction forward. [00:53:41]
-
-I'm also thinking about what a notional Redux Toolkit 3.0 would look like. Uh, a couple years ago when I shipped 2.0, and I said at the time that I was deferring touching RTK Query at all because there's some unknown number of breaking changes we would probably wanna make. I don't even know what those are. We'll just kick that can down the road. [00:54:32]
-
-Well, we've successfully kicked the can down the road almost three years at this point. Uh, the ecosystem is actually going ESM-only at this point. So presumably, if and when we do a 3.0, it would be ESM-only. Um, but I've had a bunch of things on my mind in terms of rough spots in our API and the way the internals have just evolved over time, but in a kind of haphazard way because people keep asking us to add options or capabilities, and we just added them without ever really, like, doing a coherent design upfront. And so there's, there's a bunch of pain points I've known about. There's a bunch of things I would like to improve. But they were all, you know, if, maybe, someday. [00:54:53]
-
-And so actually just in the last 48 hours, I did a whole bunch of AI-powered research tasks saying, "Here's all the things I would like to have, the properties and qualities I'd like to have in a 3.0, um, some new options I'd like to add that we can't do right now because they break with TypeScript. [00:55:38]
-
-Could we possibly come up with some kind of an API design that looks basically the same But is just different enough to clean things up and unlock the constraints. And, uh, as of last night, I've got a local prototype that Claude claims actually, like, does most of what I wanna do. So, like, noth- nothing's happening anytime soon over here, but, like, I actually have had the time and effort to do this because the AI can do the dirty work, and frankly, I didn't have the time or effort or mental capacity to do that work myself. [00:55:56]
-
-And so being able to tell it, "Here's what I want. Can you just, like, run for a while and, and come back to me and tell me if this works?" has actually made this possible, which is actually pretty cool. So nothing's, like, nothing's gonna ship anytime soon, but I actually like the direction this is going. [00:56:29]
-
-**Carl:** That's super fun. I love having problems within a box that is clearly defined enough to where AI can do it in that kind of way. A lot of the problems I've been exploring are primarily in my head, and so getting them out of my head and into a state that AI can check against is its own task, and so it's a problem. [00:56:47]
-
-**Mark:** Part of me feels a little bad that some of my contribution here was just saying the equivalent of, "I don't like that answer. Try again. Think harder." But also, like, I had to come up with, "Here's the list of constraints that I want to satisfy and the problems I want to solve, and here's the list of the prior research we did. [00:57:04]
-
-Now go think hard on these things." Like, I am actually driving the work here. [00:57:23]
-
-**Carl:** Right. Having that body of knowledge and research is critical, and is real work, and should not be discounted. [00:57:28]
-
-## [Making referential stability a type](https://www.jovidecroock.com/blog/referential-stability-types/)
-
-**Carl:** Cool. Into a couple of final details before we wrap up. This is a fun aside. Making referential stability a type. So React relies pretty heavily on referential stability, which is triple equals equality. If you have two objects or arrays that are equal to each other, it is literally the same reference. It is the same pointer. It's in this, the same part of memory. [00:57:36]
-
-And someone made a type that represents that, which is crazy. I don't understand how they did that. I saw our resident TypeScript wizard here, who is the person-- I think they're the only person who's answered any types question I've had in the last, like, decade, possibly literally. My favorite types wizard said, "Oh, cool. I tried to do this and gave up." Which I just love. Like, yeah, this is a hard problem. It's really cool. It would be really nice to have. Somebody seems to have put together a real effort at it, and I love that. It's cool. [00:57:59]
-
-**Mark:** Yeah, what they bork on both Preact and GraphQL. They're one of the Preact maintainers. [00:58:31]
-
-**Carl:** Oh, cool. I love that. Wow. Real-- I don't know. They got real chops. Yeah, core team of Preact, Urql, and- Gql.tada. So yeah, okay, they've got some real experience with wrangling complex data. That's awesome. [00:58:35]
-
-**Mark:** There's been an interesting set of different projects around trying to compile TypeScript code to true native code. [00:58:48]
-
-One that's been out there for a while is called AssemblyScript, and it's essentially a, a restricted subset of TypeScript, not full-blown true JavaScript semantics. But there's three different projects I've seen recently that are attempts to compile just straight-up TypeScript code to native code in some form. [00:58:57]
-
-## Porffor native compiler [upcoming alpha](https://honk.foo/porffor-alpha/)
-
-**Mark:** One's called Porffor, which is a... It's a single-person project. He's been posting about this for a while and doing a lot of performance optimizations on the output lately, and even making the compiler self-hosting. So he announced that Pro4 is about ready to hit alpha stage in the next few weeks. So that, that's a pretty massive technical achievement there. [00:59:17]
-
-## Perry [cross-compiles Claude Code bundle](https://www.perryts.com/en/blog/compiling-claude-code/)
-
-**Mark:** A second one called Perry that I, I don't know who's working on this, but I saw it pop up pretty recently. So they're also trying to compile TypeScript to native code, and they recently put up an article about taking the entire, like, 13-megabyte Claude code bundle that ships on disk and compiling that to native. [00:59:39]
-
-And part of it's the compilation process, and part of it is all the semantics and non-JS bits that it expects, like relying on the, the message channel, message port interface to, to send messages back and forth over a microtask. [01:00:02]
-
-## Vercel [releases scriptc native compiler](https://github.com/vercel-labs/scriptc)
-
-**Mark:** And then Vercel just announced something called ScriptC, and this is apparently in their Vercel Labs area, which is where they put all their vibe-coded projects. And, uh, boy was this one vibe-coded, I think someone on Hacker News points out that the first commit is 800,000 lines a week ago. Yeah, so who knows what the actual quality is there, but they're playing around with that. So Bunch of different people trying to solve the same problem of, it's both the publishing aspect and the runtime execution speed aspect. [01:00:17]
-
-**Carl:** Cool. Interesting. Well, I would love it if we had some more native compiled… what attention we experience, because native compiling is also the thing getting suppressed by NPM for security reasons. So yeah, what, what attention the ecosystem is under right now of moving away from compiled dependencies, but also being very hungry for the kind of performance improvements that native code is capable of. [01:00:52]
-
-**Mark:** I mean, I think in general, packages that have a native dependency used to rely on a postinstall script to check your local environment and then go manually download the binary. And at this point, most of them, like ES Build, have switched over to we're just gonna publish a se- a separate package for each possible native architecture. [01:01:21]
-
-And then the package managers have gotten smart enough to say, "Oh, well, each of those packages lists a certain native environment that it needs. Let's only actually install the one that matches your current environment." [01:01:42]
-
-**Carl:** Fair. Interesting. Complex, nuanced, subtle. [01:01:57]
-
-**Mark:** Programming. [01:02:01]
-
-**Carl:** Programming. Facts. [01:02:02]
-
-## [Goodbye, forever, probably.](https://whitep4nth3r.com/blog/goodbye-forever-probably/)
-
-**Carl:** Cool, okay. Our last link for you today is, I don't know, it's kind of sad. [01:02:04]
-
-Goodbye Forever, Probably. [01:02:09]
-
-**Mark:** It's very personal. [01:02:11]
-
-**Carl:** Very personal. This is by Salma Alam-Naylor, who goes by White Panther online. They were a very talented developer relations person for quite a while. I feel like they sprung up out of nowhere, or at least I didn't see them before they were huge. And I always thought they were very, very, just very skilled at it. [01:02:12]
-
-I thought they did a really good job of being technically at the cutting edge, while being, like, personable and entertaining. And, like, that's really hard. All three of those is really hard to do. But, so anyway, she put out this blog post called Goodbye Forever, Probably: Why I'm Leaving Developer Relations and Why I'm Not Telling You What's Next. [01:02:30]
-
-And oh man, I gotta say, a lot of this resonated with me. I've actually never had a job described as developer relations. I'm just a developer who blogged and has engaged with the community, which then later turned into the job of developer relations. This whole thing I relate to so much. Like, the number of times I've sat and seriously contemplated if I wanted to keep doing what I was doing is, like- At least five, possibly more than 10. I think about it often. [01:02:50]
-
-And I've always stuck it out. I don't know, here I am. Probably because nobody's paying me and because I have full agency over everything I do, which has its own different trade-offs. And yeah, I don't know. This is just a really good articulation of how hard it is to be publicly visible in tech and to get paid for it. [01:03:18]
-
-And I think that if you are someone who consumes tech content, this is a really good read to see what it's like on the other side of the page. [01:03:34]
-
-**Mark:** Yeah. So, um, makes a, an, a bunch of different points. A lot of it is around dev rel as a job role, that it's, it is by its nature really hard to measure. You know, how are you... Like, what metrics are you being measured on? How are you trying to contribute to the company? How do you even know if you're having success? What is your role? Are you going to conferences, writing blog posts, writing documentation, that sort of thing. [01:03:43]
-
-But specifically she also talks about being heavily overworked at multiple companies, and that contributing things. She'd spent a lot, a lot of time streaming. That was a really big part of her online persona, both in and out of the day job role. So that, that sucks up a lot of time and effort. But then also talking about AI killing teaching content. When she linked this post publicly on Blue Sky, there was a massive number of responses, and I know somewhere down in the replies, Josh Comeau said that he's looking at taking a break from building courses as well. [01:04:06]
-
-So when you put in massive amounts of time and effort to carefully craft a teaching course, and then either y- you don't get much payoff because people aren't buying it or the content essentially just ends up getting swiped Yeah. Like, why put in the time? [01:04:42]
-
-**Carl:** Yep. I was thinking about Josh and this as well, 'cause Salma says here, "I've too often overworked myself in desperate attempt to justify my existence. This has more than once caused me to suffer from health problems, including joint and nerve pain. At its worst, I couldn't even use my hands due to the pain." [01:05:00]
-
-That happened to Josh. Like, both Josh and Salma had to learn to code with their voice because of hand injuries as a result of overwork. So, like, these are two extremely successful people who have, as in pursuing their success, ground their bodies into a state of non-function. [01:05:15]
-
-So, like, that's the industry we're in. I don't know. This is what working in tech does. This is what succeeding in tech does. It's hard. One of the decisions I made in producing this podcast was I am not targeting entry level. This is not educational. This is not catch up, this is stay on the cutting edge. [01:05:34]
-
-And part of that was because of looking at the economics and realizing that, like, you know what? If you're targeting entry level people, the market you're chasing doesn't have the income. They don't have money. They're trying to get into tech. Part of the reason I have never targeted entry level humans in tech, trying to get into tech, is because I felt the economics of it was pretty fucked up. It was, you're taking money from people who aspire to get into tech to get the high salaries, and that's playing off people's desperation to succeed and do well. [01:05:51]
-
-And, like, ultimately, like sure, while the money was flowing, while it was easy to get into tech, while you could self-teach and then get a full-time job that pays you six figures, like fuck yeah, that was a great deal. That was great. That was phenomenal. It was a good part of the world to be in. [01:06:22]
-
-And now you can't. And so I think we're gonna watch a lot of educators' careers dry up because for all the good they did for the people, the market they're serving to doesn't have the money. They're trying to get the money. [01:06:35]
-
-I think we're gonna see more of this, unfortunately. It's gonna get blamed on AI, and, but there is a portion of that. People don't seek-- People are self-educating less often and relying on AI to learn more of those nuts and bolts details for them. That's true. But I do think there's another real problem of incentives. [01:06:51]
-
-You know, this reminds me too of GitHub just announced, their sponsors program, the GitHub sponsors program, you know, they waved the banner. They, you know, did the proud marketing announcement that $100 million has flowed through the program since its inception in 2018. So since 2018, 2019 I think it was actually, 'cause the number in my head is seven years. But so over the past seven years of GitHub having a sponsorship program, $100 million has flowed through it in total. [01:07:09]
-
-**Mark:** 14 million a year. [01:07:38]
-
-**Carl:** Yeah. I did 30 seconds of back of the napkin research and math, and the number I came up with for venture capital dollars that flowed just in SF over the same time period is 200 billion. [01:07:40]
-
-So while content creators are chasing their piece of $100 million, the businesses are chasing 200 times that. Thousands of times the sums of money involved. So like, I- it's, for all the commentary about, you know, who's doing what in education and content and making money, like at the end of the day, like there's a stereotype of a certain political subgroup that all just passes around the same $20. You get it, and you give it to someone else, and they give it to someone else, and they give it to someone else. [01:07:54]
-
-And like that's how I see programs like GitHub sponsors. It's not a sustainable ecosystem 'cause you're all just passing the same $20 around at the end of the day. The money's coming from somewhere else. [01:08:25]
-
-So that's my... Sorry, that's my political rant at the end of this. It's rough. It's rough out there. [01:08:36]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Mark, did you add these conferences? Should we read them? [01:08:41]
-
-**Mark:** Yeah, I put them in here, uh, because I will actually be speaking at both of them, and they're, they're also coming up. [01:08:43]
-
-So listing the two conferences off the top of my head that I know I'll be at. [01:08:49]
-
-## Sep 11: [ZurichJS](https://conf.zurichjs.com/), Switzerland
-
-**Mark:** ZurichJS in Zurich, Switzerland on September 11th. The primary organizer, Faris Aziz, great person, first year putting on the conference. I have a sense of how much time and effort he has put into trying to organize this conference. Fantastic person, ton of effort, and I'm really looking forward to that one. Great list of speakers as well. [01:08:53]
-
-## Sep 25-26: [React Alicante](https://reactalicante.es/), Spain
-
-**Mark:** And then, uh, React Alicante is in Spain September 25th and 26th, o- out on the Mediterranean coastline. This will be my third straight year speaking there. Again, wonderful conference, great community vibe, highly recommended. So if any of you happen to be in Europe or can make your way over to Europe, definitely check those out. [01:09:14]
-
-**Carl:** Heck yeah. Well, that's everything we got for you. Thank you for listening. We'll be back here on the live stage on the last Wednesday of August, or back in your podcast feed just as soon as we can. Man, maybe, hopefully I'll get it in by the end of the month in July. I've been bad at that lately. Sorry everybody. [01:09:32]
-
-Yeah, thank you so much for listening, especially to those of you who made it all the way through the end to hear this gratitude. [01:09:47]
-
-**Mark:** We started the day by saying we've got a grab bag of stuff. Yeah, we never run out of stuff to talk about. We cut out 15 items. [01:09:53]
-
-**Carl:** Yeah, we did cut out legitimately 15 items and still went 30 minutes over time. [01:10:01]
-
-Yep. That's us. Thanks so much. If there's feedback you wanna send, if there's tips you wanna give, please email them to hello@reactiflux.com. I read every email that comes through. It's a low number. It's very easy. [01:10:06]
-
-If this is a show that you get value from and wanna support, the best way to do so is by submitting a review wherever you listen and by sending this episode to your friends. Thanks so much. See you next month. [01:10:18]
diff --git a/src/transcripts/tmir-2026-08.md b/src/transcripts/tmir-2026-08.md
deleted file mode 100644
index 311c6c2..0000000
--- a/src/transcripts/tmir-2026-08.md
+++ /dev/null
@@ -1,584 +0,0 @@
----
-title: "TMiR 2026-08: Release candidate season; is that an asteroid hitting web educators?"
-date: 2026-08-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as catch up on the litany of new RCs across the ecosystem and get eyes on the asteroid hitting frontend educators."
-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:55](#new-releases)] New releases
- - [[00:01:02](#waku-10-rc)] [Waku 1.0 (RC)](https://waku.gg/blog/waku-v1-rc)
- - [[00:03:01](#preact-1100-rc1)] [Preact 11.0.0-rc.1](https://bsky.app/profile/jovidecroock.com/post/3mtxttflm5c2c)
- - [[00:03:56](#mobx-70)] [Mobx 7.0](https://github.com/mobxjs/mobx/releases/tag/mobx%407.0.0)
- - [[00:04:32](#next-163)] [Next 16.3](https://nextjs.org/blog/next-16-3)
- - [[00:06:55](#react-native-087)] [React Native 0.87](https://reactnative.dev/blog/2026/08/11/react-native-0.87)
- - [[00:06:55](#strict-typescript-api-now-default)] [Strict TypeScript API now default](https://reactnative.dev/docs/strict-typescript-api)
- - [[00:07:47](#tanstack-table-9)] [TanStack Table 9](https://tanstack.com/blog/announcing-tanstack-table-v9)
- - [[00:09:25](#tc39-composites-proposal-replaces-records-and-tuples)] [TC39 “Composites” proposal](https://github.com/tc39/proposal-composites) \~ replaces Records and Tuples)
- - [[00:10:44](#solid-20-rc)] [Solid 2.0 RC](https://www.solidjs.com/blog/solid-2-0-rc-the-big-reveal)
- - [[00:13:39](#bun-14)] [Bun 1.4](https://bun.com/blog/bun-v1.4)
- - [[00:17:18](#github-stacked-prs-in-public-preview)] [Github stacked PRs in public preview](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/)
-- [[00:21:38](#main-content)] Main Content
- - [[00:21:42](#react-core-ish)] React core-ish:
- - [[00:21:49](#new-reactdom-usebrowser-api)] [New ReactDOM \`use(browser())\` API](https://github.com/react/react/pull/37143)
- - [[00:22:47](#react-foundation-website-updated)] [React Foundation website updated](https://react.foundation/)
- - [[00:23:18](#big-nextjs-ama-in-rreactjs)] [Big Next.js AMA in /r/reactjs](https://www.reddit.com/r/nextjs/comments/1vrq0tp/were_the_nextjs_team_ask_us_anything/)
- - [[00:23:49](#react-compiler-support)] React Compiler support
- - [[00:25:21](#oxc-biome-and-bun-14-have-initial-support-as-well)] [OXC](https://oxc.rs/blog/2026-08-18-react-compiler-support) [Biome](https://github.com/biomejs/biome/releases/tag/%40biomejs%2Fbiome%402.5.8) and [Bun 1.4](https://github.com/oven-sh/bun/issues/24356#issuecomment-5276435139) have initial support as well
- - [[00:25:21](#react-compiler-linting---oxlint-speedup)] [React Compiler Linting \- Oxlint Speedup](https://blog.master.dev/react-compiler-linting-just-got-a-rust-native-speedup-in-oxlint/)
- - [[00:25:45](#the-asteroid-currently-hitting-frontend-web-development)] [The asteroid currently hitting frontend web development](https://nolanlawson.com/2026/08/23/the-asteroid-currently-hitting-frontend-web-development/)
- - [[00:32:36](#scott-tolinskis-true-cost-of-ai-coding-survey-and-video)] [Scott Tolinski’s “True Cost of AI Coding” survey and video](https://bsky.app/profile/tolin.ski/post/3mt2imugrxk2j)
- - [[00:37:51](#josh-goldberg-stepped-back-from-oss-work)] [Josh Goldberg stepped back from OSS work](https://www.joshuakgoldberg.com/blog/stepping-back-from-open-source-mostly/)
- - [[00:40:53](#software-stewardship-lab-announced-daniel-roe-et-al)] [Software Stewardship Lab announced](https://stewardshiplab.org/ideas/a-research-lab-for-open-source/) (Daniel Roe et al)
- - [[00:40:53](#tabs-spaces-hand-tools-and-seat-belts)] [Tabs, Spaces, Hand Tools, and Seat Belts](https://newsletter.powderworks.dev/p/tabs-spaces-hand-tools-and-seat-belts)
- - [[00:42:11](#humanity-in-oss)] [Humanity in OSS](https://43081j.com/2026/08/humanity-in-open-source)
- - [[00:42:11](#discussion-point-whats-this-mean-for-fe-frameworks)] Discussion point: what’s this mean for FE frameworks?
- - [[00:46:47](#cursor-switched-from-solid-to-react)] [Cursor switched from Solid to React](https://x.com/poteto/status/2089227731305464150)
- - [[00:47:46](#lovable-moved-off-next-to-tanstack-start)] [Lovable moved off Next to TanStack Start](https://lovable.dev/blog/how-we-migrated-lovable-dev-away-from-nextjs)
- - [[00:49:00](#ryan-carniatos-async-solid-articles-fetch-high-block-low-write-sync-run-async-one-graph-two-machines)] Ryan Carniato’s async Solid articles: [Fetch High Block Low](https://www.solidjs.com/blog/async-solid-fetch-high-block-low) , [Write Sync Run Async](https://www.solidjs.com/blog/async-solid-write-sync-run-async), [One Graph Two Machines](https://www.solidjs.com/blog/async-solid-one-graph-two-machines)
- - [[00:49:00](#general-unreliability-of-github-now)] [General unreliability of GitHub now](https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/)
- - [[00:49:33](#slew-of-github-competitors-tangled-cloudflare-artifacts-netlify-source-cursor-origin)] Slew of Github competitors: [Tangled](https://tangled.org/), [Cloudflare Artifacts](https://www.cloudflare.com/products/artifacts/), [Netlify Source](https://www.netlify.com/blog/netlify-source-with-netlify-cto-dana-lawson/), [Cursor Origin](https://cursor.com/changelog/origin-code-hosting)
- - [[00:55:55](#git-at-any-scale-pierre-code-storage)] [Git at Any Scale](https://cursor.com/blog/git-at-any-scale), [Pierre Code Storage](https://code.storage/)
- - [[00:55:55](#general-discussion-point-what-is-githubs-value-prop-how-is-that-changing-how-does-that-affect-us-devs)] General discussion point: what is Github’s value prop, how is that changing, how does that affect us devs?
-- [[00:57:14](#short-asideslightning-rounds)] Short asides/lightning rounds
- - [[00:57:14](#bun-14-rust-rewrite-and-a-gazillion-new-features---the-longest-changelog-ive-ever-seen)] [Bun 1.4](https://bun.com/blog/bun-v1.4) (Rust rewrite and a gazillion new features \- the longest changelog I’ve ever seen\!)
- - [[00:57:14](#github-stacked-prs-in-public-preview)] [Github stacked PRs in public preview](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/)
- - [[00:57:14](#okay-we-definitely-just-actually-did-this-at-the-beginning-)] Okay we definitely just actually did this at the beginning 🤣
- - [[00:57:16](#npmreport)] [Npm.report](https://bsky.app/profile/philippeserhal.com/post/3mttzodz6kk2x)
- - [[00:57:51](#supplier-security-questionnaire-andrew-nesbitt)] [Supplier Security Questionnaire | Andrew Nesbitt](https://nesbitt.io/2026/08/13/supplier-security-questionnaire.html)
- - [[00:58:58](#everything-i-own-owned---schlarpcom)] [Everything I own, owned \-](https://schlarp.com/posts/everything-i-own-owned/) [schlarp.com](http://schlarp.com)
- - [[01:02:33](#the-sorry-state-of-skill-distribution)] [The sorry state of Skill distribution](https://blog.trailofbits.com/2026/06/03/the-sorry-state-of-skill-distribution/)
-- [[01:03:46](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:03:48](#zurichjs-sep-11-react-alicante-sep-23-24)] ZurichJS Sep 11, React Alicante Sep 23-24
-
-# Transcript
-
-**Carl Vitullo:** Thank you so much for joining us for the August edition of This Month in React as we recap what's going on with React, React Native, and generally on the web platform. We are coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]
-
-I am Carl generally known as vcarl on the internet. I'm a staff product developer, freelance community leader, occasional entrepreneur, sometimes consultant here helping run Reactiflux. And generally just trying to keep this place valuable and pro-social for everyone around it. [00:00:13]
-
-**Mark Erikson:** And I'm Mark. My day job is at Replay, where we've built a time traveling debugger and now an automated QA platform that uses t , the time travel awesomeness to help find bugs in your app. Replay QA, please check it out. And outside of that, I am still doing an awful lot of Redux stuff [00:00:28]
-
-**Carl Vitullo:** Mm-hmm. Cool. Yeah August is often a slower month. A lot of Europe is on vacation. you know, kind of the end of summer. It's the start of school. So just often there's not as much going on. [00:00:44]
-
-## New releases
-
-We do have a lot of new releases or pre-releases, release candidates to talk about. Yeah. Let's get going. [00:00:55]
-
-First off on our new releases, we've got Waku 1.0 as a release candidate. Yeah. Waku, I don't know, I feel like I've been thinking of it and describing it as a new framework for server components, and I actually went back and checked how we've discussed it, and we've been discussing it for three years now. Like, three years is no longer a new tool, you know? But yeah, here we are at 1.0 with a release candidate. [00:01:02]
-
-**Mark Erikson:** The, and, and, and to recap Waku is a React server components framework that's been built by Daishi Kato, who i- who is also the brains behind Zeustand and Voltio and Jotai, and a slew of other state management related libraries. And the goal is to be a minimal server components framework rather than something like the, the all-encompassing Next.js [00:01:25]
-
-**Carl Vitullo:** Yeah. So cool. Love to see things get to release candidates. The fact that they've been driving towards 1.0 for so long makes me think, I don't know, makes me think this is being thoughtfully approached. Generally they, they, are very thoughtful, so that's very cool to see. [00:01:50]
-
-**Mark Erikson:** It looks like they've, they've been doing some, some navigation fine-tuning and improvements, but other than that, it's mostly like we, we think we've got it close to being final soon [00:02:06]
-
-**Carl Vitullo:** yeah, a- actually I'm gonna, I'm gonna put out a little call to audience, anyone listening. If you have, like, built something with Waku, I would actually love to hear about it. I don't think I know anyone personally who has, like, any kind of extensive experience. So, yeah, if you have any feedback, I'd love to hear about it in the \#general-tech channel or, you know, shoot me an email to hello@reactiveflux.com. Just general curiosity. [00:02:16]
-
-**Mark Erikson:** I was actually just wanting to try to look up download stats. Like, I've, I've seen it for a while. my general assumption is that it's not widely used, and certainly not in comparison to something like Next.js or React Router. [00:02:37]
-
-**Carl Vitullo:** Yeah. on that, I just checked. It has 22,000 downloads per week which compares to, you know, TanStack React Query at 60 million n. So yeah, definitely on the smaller side yeah. Okay, moving on. [00:02:48]
-
-Another release candidate. We have Pre Act 11 coming out , the main thing they highlight is it's now tree shakable which is a claim that I always take with a pretty substantial helping of salt. Just never know. I don't know. There's so many ways to break tree shaking, and we've been... libraries have been working to be more tree shakable for, like, six, seven, eight years. [00:03:01]
-
-So, you know, I don't know. It's cool. Love that. That's great. I hope it works. But yeah, Preact is generally interesting. It's cool. Last month we were talking about React alikes, and Preact is definitely the original React alike, although it is increasingly less alike as time goes on. [00:03:23]
-
-**Mark Erikson:** Yeah, although it do- it does say that the, the compat package now includes the several other React methods that have been added recently. So while the semantics have diverged somewhat over time, they are at least still making an effort to try to keep it relatively drop-in if possible. [00:03:39]
-
-MobX 7 came out. it's funny because Mo- like MobX, I think technically was, like the first releases of it were actually a few weeks before Redux came out back in 2015. So MobX has been around for a while. MobX 7 is primarily a cleanup and modernization release. They've dropped the legacy implementation and now it now requires proxies to actually track things, which has always been the default behavior. [00:03:56]
-
-Improved some bundle sizes, some tweaks to the, to the React bindings. So still out there and still being worked on [00:04:24]
-
-And on a much bigger note Next 16.3 is out, and the, the Next team talked a lot about this release. they seem to feel this is one of the bigger releases they've done in quite a while. [00:04:32]
-
-there's a bunch of dev improvements. It's supposed to build faster, less memory usage but it also has what, what they're calling instant navigations for s- better spa-like behavior as well [00:04:46]
-
-**Carl Vitullo:** Well, yeah, I saw they, they had also done a AMA on Reddit. Although I, I, I read through a fair bit of it, and it was a lot of like, "Yeah, we're working on caching. Yeah, big sites are still hard." So I don't know. It it, it was good to check in. It was cool to see... You know, it was a lot of big names giving, you know, direct answers to questions, but um, [00:04:59]
-
-**Mark Erikson:** There weren't a lot of great secrets revealed in that. [00:05:20]
-
-**Carl Vitullo:** Right. Yeah. And it's just like it's been such a consistent through line for two or three years now of like, yes, caching is hard. Local development is hard, especially if you're dealing with, like, 100,000 pages being generated. So, you know, it's just like , the challenges and the stated improvements have a certain sameness to me over time for Next. [00:05:22]
-
-I'm su- You know, it does improve. It gets better. It, it... But, like, the challenges are still pretty similar. [00:05:41]
-
-**Mark Erikson:** And, you know, may- maybe this is just a snide comment from the gallery from someone who doesn't even use Next at all, but it always... It, it's felt like a little bit of that complexity was sort of self-inflicted in a way [00:05:47]
-
-**Carl Vitullo:** Right. Yeah. I think we have another thing to talk about later on. I can't remember what this got in the doc, but Lovable put out a blog post about moving away from Next to TanStack. And yeah, you know, it's, a, a lot of it is like, oh yeah, we had performance problems, and those performance problems got resolved by moving to Vercel, but we would, would like to have more optionality f- than in our hosting. [00:06:01]
-
-So, you know, it's, the same kind of complaints, and agreed that a lot of the complexity seems kinda self-inflicted. they keep trying to fix it by adding more complexity, it feels like. You know, it's, it's a continuous additive system, and the fact that they keep adding new things to try to address the problems, and the root problems being solved don't seem to be changing, makes me suspect that the, they have gone deep into the diminishing returns of additions. [00:06:24]
-
-I think it's perhaps time to subtract. But subtracting is usually a major version bump anyway. [00:06:50]
-
-Okay. We have a new React Native version 0.87. Man, I- every time we have got a release, I miss having Mo out here because [00:06:55]
-
-he [00:07:04]
-
-**Mark Erikson:** was just about to say that [00:07:04]
-
-**Carl Vitullo:** He's got such a good breadth. Maybe I should bring him on as an analyst or something like that. But yeah, the, the big highlight here looks, to me at least, looks to be that they now have a strict TypeScript API and type definitions are being actually generated rather than hand-authored. That's a huge... Going from hand-authored types to generated types is always a massive project. It looks like this has been in the works since about point or 0.80. So, you know, that's seven, seven releases now that they've been going towards it. So, their strict TypeScript API is now the default. Not everything will be compatible, so there's an opt-out, but they've stated the intention of this - you know, the, the opt-out going away over time. [00:07:06]
-
-**Mark Erikson:** TanStack Table version nine is out, and I believe I, I, I know I'd at least pasted a couple of the prior blog posts in the tech reads and news channel. I don't remember if we actually linked them in the, in the podcast last month. Some of the updates they now have a increasingly wide range of adapters for different frameworks React, Preact, Vue, Solid, Svelte, Angular, Lit, Alpine, Ember and Octane. So pretty much anywhere you're using a framework you could use TanStack Table if you wanted to. [00:07:47]
-
-They've made a whole lot of improvements to performance. They've pulled off some very nifty JavaScript tricks to try to cut down on memory usage rewritten the internal state management, improved type safety, and as we d- were just saying, things are more tree shakable. [00:08:19]
-
-Wonderful [00:08:34]
-
-**Carl Vitullo:** Wonderful. Yeah. Tables. Man, ugh. I love that, I love that TanStack has been so persistent at trying to make a good table abstraction, but I'm gonna be honest, I settled in, like, 2017 of saying, like, "Nope. There is no table abstraction worth its weight in the bundle. I'm gonna re- write every table from scratch," which has its own trade-offs. [00:08:35]
-
-You know, it's, it, then you have to copy functionality and stuff is missing. But, like, man, just, like, seeing this release talking about how they have, like, a new architecture that, y- you know, with a record number of framework adapters, it's just like, man, tables are so much more complex than we give them credit for. [00:08:57]
-
-It's so hard to make a good table [00:09:15]
-
-**Mark Erikson:** But I thought coding was solved [00:09:17]
-
-**Carl Vitullo:** Coding is? It's completely solved. , it gets more and more solved the less closely you look at the outputs. [00:09:19]
-
-**Mark Erikson:** On a completely different note we've talked in the p- past about w- what was known as the records and tuples proposal for the JavaScript spec, which was supposed to add new data types to the language that were gonna be deeply immutable, and then you could just say, "Is this value equal to the other?" [00:09:25]
-
-And the triple equals operator would do a deep comparison. That proposal eventually got withdrawn. It's dead, it's gone, it ain't happening. So there's now a new proposal called composites, which is sort of trying to solve the same problem, but in a very different way. Reading it, it looks like you create these wrapper objects, and then the wrapper objects will do the value comparisons for you, I think. [00:09:42]
-
-So nothing immediately actionable here, but it, it is interesting to see that the design committee champions are still trying to figure out a valid solution for this problem [00:10:10]
-
-**Carl Vitullo:** Yeah, that's interesting. Looks like it's kind of I'm looking at this example in the actual spec, the stage one draft spec basically wrapping an object in a composite constructor, and then, you know, you do the same object keys and values in two, and then do a triple equals comparison, and cool, they're equal. [00:10:21]
-
-Th- so that's awesome. That's interesting. That's useful. But yeah, stage one, that's pretty far away from released [00:10:39]
-
-**Mark Erikson:** And then we've talked some previously about Solid 2.0 being on the way and having a major change in how it handles async, to how that's baked into the signals graph. They've officially hit release candidate this month. So there's the 2.0 RC announcement blog post but then there's also some deep dives that we'll touch on later that talk in more detail about how the async graph works and what that means for your code. [00:10:44]
-
-I continue to say that, like, Ryan Carniato is probably doing some of the absolute deepest research into framework development and data modeling and how to build better tools than pretty much anyone else out there. Obviously the React team put a lot of thought into server components. The Next team's putting a lot of thought into, you know, building their framework. [00:11:12]
-
-Ryan's doing, like, the bleeding edge research here [00:11:37]
-
-**Carl Vitullo:** I love that, so the async lives in the graph is for one, just a great header. I love that as a thing to unpack and understand. But it's a, I, I wanna call out this little parenthetical that says, "A computation can return a promise, parentheses, or an async iterator." And man, a, promises versus async the iterator is just so much more powerful. So being able to support those, like, you know, it's a little aside because everyone knows and uses promises and those, you know, everyone assumes those. But man, I've been using async iterators more and more lately, and they're so powerful. [00:11:41]
-
-**Mark Erikson:** I, I was, I was skimming through the third of the three explainer blog posts, and they fleshed that one out in more detail. And I think the example there shows a component that, like, looking at it, you almost wouldn't even know that it would get updates because it just works reading the data [00:12:14]
-
-**Carl Vitullo:** Yeah. I've been using them mostly because I have been doing all of my code in effect the last couple of months, and, like, or everything is a generator. And generators can be iterated upon. But yeah, like, you know, it, an async iterator is basically a promise that can resolve multiple times. [00:12:34]
-
-Like, ugh, that's incredible. I don't know. So just, like, So many times when you're modeling something as an asynchronous request, it may actually be better to model it as a stream of incoming data, and you can't do that with a promise. You cannot have an, a stream a stream of events. So i- iterators are just, like, this really magical in-between point between events, like, you know, event-driven architecture and promises. anyway, [00:12:48]
-
-**Mark Erikson:** Ben Lesh would like to have a word with you about RxJS and Observables at this point [00:13:15]
-
-**Carl Vitullo:** Ha ha. Fair enough. Yeah, super cool though. Last thing I'll say on that is definitely lend... early and prominent shout-out of async iterators, I think, lends credence to what you were saying about him being on the cutting edge of the research here. Like, yeah. Everyone else needs to catch up. go become familiar with async iterators, because it will level up your professional, capabilities. Okay, moving on. [00:13:19]
-
-Bun has had a big release [00:13:39]
-
-**Mark Erikson:** it's the single biggest change log I've ever seen. It's for what is technically a minor release, except that they also literally rewrote the entire thing from Zig to Rust with AI. Technically, there's no breaking changes, so yeah. [00:13:42]
-
-**Carl Vitullo:** Yep, they've moved out every zig. They're now on Rust. [00:14:00]
-
-**Mark Erikson:** Deep cuts [00:14:04]
-
-**Carl Vitullo:** Deep cuts. You know, you can't just put an opportunity like that in front of me. [00:14:05]
-
-Yeah, I think this is super cool. there's been a bunch of drama, a bunch of words typed and spoken about the Rust rewrite, and, like, I just, I don't find that very interesting. The most interesting thing I think is that they used Basically a fully automated workflow and the existing test suite to say, "This works. Go fix it so that it works in this language instead." and then $160,000 in tokens later, they had a Rust-authored version that is apparently good enough to release, and not only good enough to release, but good enough to build a, like, remarkable set of additional features on as part of that release. [00:14:08]
-
-So, that's fascinating. That's cool. It's a little crazy to see that much coming out. J- Jared Sumner has always been, like, kind of confusingly prolific at, in terms of, like, level of output here. So I don't know, just seeing him become AI-enabled is remarkable. [00:14:47]
-
-But I was gonna say, oh, this is the most important one, and then I'm looking at the whole list and they're all pretty wild. Like, bun.image lets you do a lot of really powerful image manipulation for the web natively, you know, just within Bun, which is great, 'cause I have previously done stuff like that with FFmpeg and Sharp, and those feel like they were written in the early 2000s, because they were. those have been around for a long time because nobody wants to rewrite them, because doing that work in a way that is performant and, like, usable is really hard. So, you know, kudos for shipping something like that. I haven't played with it myself yet. I want to. But yeah, decode, resize, rotate, encode JPEG PNG, WebP, GIF. Yeah, just, like, all of the image formats, doing resizing and basic editing kind of stuff is really, really interesting. [00:15:05]
-
-But then they've also got bun.webview, which is basically like Playwright or, you know, Cheerio or something, just natively within the standard library, which is wild and really helpful. [00:15:53]
-
-I haven't made use of this yet, but I did go through... I have a skill that I made for myself that is like, "Here's how to set up a new project here. You know, here's how to set up the linting, here's what tools to use." And I told it, "You should use bun 1.4 because the web view stuff makes it really easy to do end-to-end testing," allegedly. I still need to validate this. [00:16:04]
-
-But they've also got, like, a markdown parser and, like, a cron scheduler a pseudo terminal so you can dri... You know, they, they say, "So you can drive Bash, Vim or whatever from JavaScript without Node PTY." I've been rigging up a bunch of, like, experimental AI agent harness stuff, as part of doing that, I've been writing a lot of wrappers for Bash to be like, "I need this service to be running in the background while this server runs. it's really janky. I've had AI write a shit ton of, like, bash-compatible things that are, like, forwarding control codes, and making sure output redirection works as expected, and all those little subtle details. So again, one more thing that is, like, a pretty big load off of my mind building something if I can just ship it out to a standard library. [00:16:24]
-
-So anyway, yeah, it's a massive change log. Lots of controversial practices involved in producing it and releasing it, but mm, it's pretty cool. End result is pretty neat [00:17:07]
-
-Cool. And uh, man, another thing I've been dreaming of for years and years and years, GitHub is now doing a public preview of stacked pull requests stacked PRs. we've talked about this a couple times. I'm not sure how widely familiar, you know, the ecosystem is with stacked PRs. [00:17:18]
-
-This has been a, the way that I work intuitively for a number of years at this point, like probably dating back to 2019. Where, like, work on something, produce a finished branch, push that up, create a pull request, and then I'll ... Most of the time, the thing I just built was to enable future work. You know, it was to unblock other work that I mean to be doing. So then I'll just take that branch and continue working off of it, off a new branch, and boom, that's a stacked, you know, that's a series of stacked branches. [00:17:37]
-
-I'm, while branch A is being merged, I'm working on branch B, and then, you know, when branch A gets merged, I push up branch B for review. The, the revision here is that now you can just push them all up and mark the PRs as stacked on top of each other and it will automatically do lots of rebase and branch juggling for you. [00:18:07]
-
-Yeah, the challenge there is, okay, you stack branches up like that, like I was just describing, but then when you merge them, you know, the, the, the commit SHA changes. You know, maybe you do a squash merge. You know, maybe it's a, Anything other than a fast-forward, and you now have to do a rebase in order to have the, have the branch [00:18:29]
-
-**Mark Erikson:** Which means you have to pull down locally, you have to do the rebase, you have to, you have to do some juggling locally, push it back up, actually create things, and you have to repeat that for every time you do, you, you merge one of those PRs [00:18:46]
-
-**Carl Vitullo:** Right. And so when you've got, you know, branch A and branch B, it's not so much work. But when you've got branch A that drives branch B, that drives branch C, that drives branch D, and you've got eight people all contributing to a shared code base, like that pull, rebase, push cycle ends up being a pretty substantial amount of work. [00:18:58]
-
-So it's really cool that GitHub is now enabling this. There's a, there's a pretty closely related concept here as well called a merge queue, which is basically like an engineering practice where as part of review, you know, you don't just mer- you don't just merge when approved. You don't say like, "Okay, this, this PR is now approved for ship," whatever. "Let's merge it now." it's part of a queue, you know, it's in line. So, just as a way to manage conflicts, avoid doing rework because, you know, it... When you ha- when the work that's being merged into release is more predictably sequenced, a lot of benefits fall out of that. And stacked pull requests are a really interesting way to enable a simplified version of that for a, a larger number of people. [00:19:17]
-
-So I... This is really cool. I'm excited about it. I I'm gonna have to play with it. [00:20:06]
-
-**Mark Erikson:** mean, it's, it's, it's worth noting that on GitHub, the unit of review is the PR. Like, you can have as many commits as you want, but what you see by default is the final result on the branch, and that is what we're all very used to reviewing, and it's, it's what many other GitHub-like tools have copied. [00:20:09]
-
-But there were, there have been plenty of other code hosting and review tools Gerrit, Phabricator, and others, where the unit of review was the commit. And so another part of this usage-wise is how big of a unit am I trained to review at once? So, like, maybe you have your, you know, your 5,000-line PR, but it makes sense to review the changes in smaller chunks. [00:20:30]
-
-Well, on GitHub, it becomes difficult to go through and review, like, one commit at a time or something. So either you say, "Here's the whole thing. Looks good to me," or you have to split it into multiple PRs so that smaller chunks are more easily reviewable, but then you have to do the branch juggling dance. [00:20:57]
-
-**Carl Vitullo:** Yeah, and I guess I, I also wanna say this was, like, Jared Palmer's pet project while he was at GitHub. [00:21:17]
-
-**Mark Erikson:** For about three months [00:21:23]
-
-**Carl Vitullo:** For the... Right. So it appears that Jared Palmer legitimately joined GitHub specifically to ship this, got it into a state where it [00:21:24]
-
-**Mark Erikson:** It's the meme. It's the [00:21:31]
-
-**Carl Vitullo:** Yeah. [00:21:33]
-
-Right. And then left, and then went... Yeah, so anyway, that's, that's pretty funny. Uh. [00:21:33]
-
-## Main Content
-
-Okay. Into our main content yeah. [00:21:38]
-
-Yeah. [00:21:41]
-
-Right [00:21:42]
-
-**Mark Erikson:** Right so a few smaller items from React core news-ish stuff this month. [00:21:42]
-
-There's a new API that's coming out for React DOM. It's a function called Browser, which is intended to be passed to the increasingly expanding use method. So it's use. The idea is it re- the return value of use will differ depending on whether you're calling this on the server or on the client. [00:21:49]
-
-So if you call it on... If you have a component and it's getting rendered on the server, in a server component or whatever React will see that and essentially leave a hole in your component output. And then it knows that when this run, runs again on the client, then it will fill in. pretty much every code base at this point has some form of a do this logic only on the client util or, or something along those lines. [00:22:15]
-
-This is essentially building that functionality directly into React DOM itself [00:22:41]
-
-Let's see. [00:22:47]
-
-We, we... I believe I mentioned last month that, that there were updates on the way for the React Foundation website, and then they were also talking about governance-related things. They have shipped an update to the website, so it at least looks less AI vibe coded at this point. still Looking and waiting for more public details on what the foundation is going to do long term, but again, you know, bits of activity. [00:22:47]
-
-Things presumably are churning away behind the scenes. [00:23:15]
-
-As, as we mentioned earlier, the Next team did an AMA over on Reddit. There's some discussion. Some of it's the obligatory complaining about Next.js not having proper middleware and things like that. I skimmed it. Honestly, the biggest thing I got out of it is that React 19.3 is probably coming in the near future, and that it should solidify the fragment ref and view transition features which have been in Canary for a few months. [00:23:18]
-
-So good to know that's on the way [00:23:47]
-
-And then the other interesting bit was that the OXC team has shipped their official support for React Compiler built into Oxlint, et cetera. And, and this is interesting for multiple reasons. So React Compiler itself was originally written in TypeScript and also required a Babel plugin. And so it existed, but we've spent all these years converting our build tool chains to Rust. [00:23:49]
-
-Babel is slower. People saw that build times got slow again, and like, "We don't like this. Can you just do it in Rust?" The React team did an AI-assisted port of the compiler logic from TypeScript to Rust. That is in the React repo. But then the question is: how will that integrate with other build tools? So other teams, Biome, OXC, Bun, et cetera, have been taking the Rust code and trying to figure out the best way to integrate it, and the OXC team in particular has actually pushed ahead in a lot of ways. [00:24:14]
-
-They tried to integrate it once, and then they decided that it made their binaries too big, and they didn't wanna ship that to everybody, including people who don't use React at all. So apparently they went back to the drawing board. They found some ways to optimize the code, shrink the bundle size, make it semi-optional maybe. [00:24:51]
-
-And apparently now the both the build performance and the binary size are good enough that they felt ready to actually ship it. So that, that support is now baked in at this point. [00:25:09]
-
-And Biome is trying to do some integration as well. Bun 1.4 is supposed to have React Compiler support. So slowly but surely, these pieces are all coming out in the ecosystem in a much faster way, and so hopefully that means that more projects will be actually be adopting the compiler over time and thus seeing whatever runtime performance benefits you get from using it [00:25:21]
-
-**Carl Vitullo:** Should we go to Asteroid? [00:25:45]
-
-**Mark Erikson:** Yes, the asteroid not astro, asteroid [00:25:46]
-
-**Carl Vitullo:** Yeah. Yeah. Nolan Lawson, who is is somebody who's been, like, individually fairly influential on me as a developer I just first encountered him 10, like, more, 15 years ago when I was still in college. So it's cool to see his name still around. he put out a great blog post called The Asteroid Currently Hitting Front-End Web Development. , basically the same thing I actually said on, at the end of our last episode about impacts of AI on educators, on content creators, especially in the front-end engineering space. And basically, you know, he's highlighting that He says, "A lot of the educators I admire in the front-end web space seem to be either bowing out or dialing back their efforts." [00:25:50]
-
-And like, yeah, Axel Rauschmeyer, hugely influential blogger about the standards process and, you know, JavaScript itself as a language. Salma Alam N- Naylor, well, Selma and Josh we talked about specifically at the end of the last episode. And, and then he calls out, too, that, like, Kenzie Dodds, Addy Osmani, Rachel Neighbors, Lydia Hallie have all moved more from front-end development into, like, AI agents software development. Which I, which I think is fair. You know, I don't, I, I, I think comparing people stepping back versus staying on the cutting edge. for a long time front-end was the cutting edge, and then it was, like, React Native and where are we gonna put React next? And so now it's not as much that. Now it's AI and how do you build stuff? How do you build a software factory? [00:26:28]
-
-**Mark Erikson:** , even that is a theme we've touched on for a while. I mean, swyx used to be part of the React ecosystem space. He was a mod on the, you know, in the subreddit, did a lot of talks, and then, then he got involved with Svelte, and then he pivoted to running AI conferences and, and podcasts. [00:27:11]
-
-, we've even talked about, like, the energy at React conferences seems to be down, whereas the AI conferences have all the energy. So, like, there, [00:27:27]
-
-**Carl Vitullo:** Right [00:27:38]
-
-**Mark Erikson:** like, a lot of trend here [00:27:38]
-
-**Carl Vitullo:** . This post from Nolan Lawson, he talks about the future of front end. And I'm just gonna read a couple of, like, high-level points he makes. The front end is less risky to just hand to an agent. Developer experience is becoming less critical overall. Standards will catch up. I think this is interesting. [00:27:41]
-
-I, these rhyme with points of contention that I've seen in the industry for essentially my entire career. Like, you know, [00:27:55]
-
-is front end... Right. Front end is easy, and developer experience isn't worth the time investment. , I wanna call this out. He says, under developer experience becoming less critical, "The agents know React. For better or worse, React is heavily over-represented in the training weights." And again, like, something we talked about last episode, I believe, was Aiden Bai put together a benchmark of not just React, can it make something functional, but how well does it actually execute React best practices across different models? [00:28:02]
-
-**Mark Erikson:** they know what React code looks like. They don't really know how to write good React code [00:28:32]
-
-**Carl Vitullo:** Right. So [00:28:38]
-
-**Mark Erikson:** They know what bad React code looks like [00:28:40]
-
-**Carl Vitullo:** Yes, bad React code is heavily overrepresented in the training set, but, I used to, I used to work, when, when I was more earnestly working full time, I went to a lot of different companies for, you know, a year, six months, a year and a half, and the reason I was able to be very successful at that is because every company used the same set of very bad practices that represented a fundamental misunderstanding of the advantages that React offered. [00:28:42]
-
-And so it's like, cool, I understand those, let me come in and fix this incrementally one thing at a time, and the improvements are so mind-blowing to you as somebody who doesn't understand the tools you're using, that, you know, great, cool, great, awesome. Who... Lovely performance reviews, yada, yada. [00:29:07]
-
-I both understand where he's coming from on this. there is less risk in f- the client versus the server. If you fuck up data on the client, like, you just, you know, pull f- from scratch from the back end. But if you screw it up on the back end, like, oops, data loss. Oops, you know, security vulnerability. So it, you know, these are both true, and I think, like, fundamentally missing some kind of point. So I don't know, it talks about the future of front end and front-end education. I think there's still a lot of room for human cognition as steering input to guide agents that, you know, they may be individually capable of achieving, you know, X, Y, Z, maybe even better than I can, but they need to be told what the constraints are in a w- in a manner that is, you know, y- helpful to guiding them to waste less. You know, like, rework is so costly that if you, if I, as the intelligent human with experience using these tools and knowing, you know, what has downstream effects six months, a year, five years from now, then yeah, I think there's still a lot of room for expertise meaningfully [00:29:23]
-
-**Mark Erikson:** when I wrote my own AI journey emotional blog post back in April, one of the points I made was that I did... Once I got past, "I will never use this," and actually started using these tools, I've been able to use them effectively because I already know how to write code. I already understand what good code looks like. [00:30:39]
-
-I know how I want to do things, and now I'm just trying to speed up the process of doing the work that I already intended to do. or using the tools to give me a range of options, and then I make the decision based on which one actually feels like it fit, fits the best. but then that brings up all the, and all the usual questions of, well, how do you get all this experience? [00:31:01]
-
-Well, I did it for 20-plus years by hand, and now I'm reaping the benefits of that. And how do others gain that experience in today's world? I don't know. I'm not in that position at this [00:31:23]
-
-**Carl Vitullo:** Yeah. You know what? I think they learn it, I think they learn it essentially the same way that I did. Fucking trial and error. Like, I have a, I have an associate's degree. I have nev- you know, I've taken one year of computer science. Like, I was not taught these things. I learned them largely through trial and error. [00:31:35]
-
-You know, you join a company, you ship some code, you have to deal with the consequences of the code that you shipped. I, there's no substitute for experience, and it is easier than ever to go from non-functional to functional. And once you have to maintain a functional thing and keep it operating and expand on it and improve upon it, I feel like the lessons aren't that different. [00:31:51]
-
-I don't know. At the end of the day, I think it's, it comes down to how well can you ask questions of this... You know, we're all gonna be managers in the, in this AI world, [00:32:14]
-
-**Mark Erikson:** So a lot of the discussion around this whole direction has then been, yeah, like, what... where is the place for us? What does that mean for our careers? How do we feel about this? [00:32:23]
-
-So Scott Tolinski uh, one of the hosts of the Syntax.fm podcast with Wes Bos did some work within the last few weeks that really touches on, on this. [00:32:37]
-
-Scott had his own AI psychosis phase some months ago. And coming out of it, he's like, "Okay, This has affected how I feel, like, literally on a daily basis. I wonder how other devs have been going through this as well." And so he put up a survey online. Has been trying to gather as many respondents as possible. [00:32:45]
-
-I think he's up to 7 or 8,000 respondents at this point. So you know, a f- fairly decent sample size. [00:33:07]
-
-And it, it's, it's relatively short, but it asks questions like do you feel like your skills are eroding based on your AI usage? How many times have you found yourself staying up later than you intended because just one m- just one more prompt, one more prompt, [00:33:13]
-
-Or, you know, sort of the slot machine effect of just asking it to do, you know, some more work. So he gathered up the results, and I believe his wife is actually, like a, a psychologist with, with a, with a doctorate. And so he was having her work through him on some of the statistics and the analysis on this. [00:33:30]
-
-And he also was reaching out and doing some video interviews with a number of people to follow up and get some ac- you know, some more direct, you know, r- real-life anecdotes and data. So I actually did a video with interview with him, and we, we had a good discussion. He pulled all this together into a half-an-hour YouTube video where he talks about his experience, his research, and brings in video clips of a bunch of people including myself. [00:33:50]
-
-It's a really good video. I, I strongly encourage people to take the time to read through this. The end, like, the end bit of it is basically take care of your mental health, folks. Like, don't let this, rapid pace change in the world get to you. Take care of your mental health, establish your boundaries, and then go from there. [00:34:17]
-
-**Carl Vitullo:** Yeah. Yeah. Very important. I think at the intersection of that, take care of yourself, understand your boundaries, hold yourself to your boundaries, which is hard. [00:34:37]
-
-staying within them for a long period of time is really hard. [00:34:47]
-
-**Mark Erikson:** I know what the right things are and I am not the world's best poster child for sticking with them. Do as I say, not, not as I do [00:34:52]
-
-**Carl Vitullo:** Right, right. and I wanna connect that back to this, you know, asteroid hitting front-end web development and educators falling off and no longer producing output at the same level that they were in the past A lot of my, I think a lot of my energy in producing this podcast, in running Reactiflux, in contributing to the ecosystem has been, especially the last five years, has been very much rooted around what can I do to not burn out? So, you know, it's like the reason this is a once a month podcast instead of weekly or daily or whatever is 'cause I would burn out if I did anything else. Like this is enough effort for me and this is already once a month for an hour plus prep is already disruptive enough to the other things I want to do in my life that I can't do anything more than this. [00:34:59]
-
-**Mark Erikson:** Ditto [00:35:49]
-
-**Carl Vitullo:** Okay, we've achieved some small level of success. We have several hundred people listening every month, which is lovely and great, but like, you know, on the grand scheme of things like this is never gonna pay my bills. This is never gonna be a full-time career. And like, you know, whatever, that's fine. [00:35:50]
-
-That's okay. That's okay because that's what I, I built it not to be that. I built it not to take over my life. I built it to let me do it at my leisure, at my convenience. And I don't know, you know, in some ways, like, a personal life philosophy of mine is to like be inexorable, just like, th- just be unstoppable. Like you don't need to be the fastest, you don't need to be the smartest, the most resilient, but like just keep going. [00:36:03]
-
-If you, if you're going in a direction, just steady advances incrementally. And so like, you know, I'm not, I, I'm never gonna have hundreds of thousands of social media followers and you know, tens of thousands of hours listened across multiple platforms. But like, you know what? When the other people burn out, here we are. know, other people do these content projects for a year, two years, three years, but like Reactiflux, we've been around more than 10 years now and I've been helping run it for a lot of that, most of that. I've been a moderator or an admin for 10 years now, 10 and a half years now. So I don't know. That's, I think that's, that is an attitude that is not widely rewarded in tech, in tech generally. You could say some other things about different subdivisions there, but I think it's, I don't know. I think it's important for mental health and pers- physical health as well 'cause burnout is not just a mental health issue. [00:36:33]
-
-You can have serious physical health consequences from that. Anyway, yeah, I don't know. I'm gonna trail off there. [00:37:28]
-
-**Mark Erikson:** Yeah. So here's sort of the flip side of that keep persisting thing. I mean, we, we listed a number of people who have made the decision to step back because they're feeling burned out or feel like the, you know, the audience and the career that they'd built just no longer exists at this point. [00:37:34]
-
-So Josh Goldberg, who has been a very prolific open source contributor working across multiple different linting and build tools recently just announced that he's stepping back completely from open source maintenance. [00:37:51]
-
-I actually talked- had talked to him live just before he posted this, and he, he told me this was where he was headed. Some of it is life changes. He's, he's had a number of stuff going on in his personal life that have taken up time and energy. Some of it is getting very frustrated with AI PR spam [00:38:05]
-
-and, you know, just not wanting to deal with yet another seemingly plausible bug report that turns out to be complete nonsense. [00:38:23]
-
-And some of it is just a desire to literally go out and touch grass and do other things with his life [00:38:32]
-
-at this point. [00:38:40]
-
-that's also an entirely valid set of decisions, and he said he's ha- essentially handed over all of his projects or they're in maintenance mode at this point. [00:38:41]
-
-He's still working. I believe he's at Sentry at this point, but he's stopping open source work. And so, like, I'm happy for him in the sense that I want... He's a good- he's a great person, and I want him to do what's best for his life. It's a little sad in seeing someone who has been involved, you know, saying, "That's, that's it for this phase of my life," and stepping away [00:38:51]
-
-**Carl Vitullo:** Right. It, it's sad to me because he's a friend. I consider him a friend. He stayed at my house once because he was passing through and needed a place to crash. [00:39:15]
-
-I... He's a lovely person [00:39:24]
-
-He's so kind and so generous, and so purely wants to do good that it sucks. it makes me genuinely sad to see him take a s- need to take a step back because he can't do it all, you know? [00:39:25]
-
-Because he, nobody can do that all. It's too much. You can't work full-time and have a engaging, rewarding personal life and do these side projects, and also organize a conference, 'cause he was doing that, too. So yeah [00:39:40]
-
-**Mark Erikson:** I mean, I've, I've had my own thoughts. Like, I, I have no plans to stop open source work anytime soon. In fact, I've actually got uh, like I said, we said last month, I'm trying to push through a big new React Redux feature, and I've got a bunch of plans for what will hopefully turn into our next set of major version releases. [00:39:52]
-
-But you know, purely mathematically, the day will come when I no longer do Redux-y things. It might be 'cause I'm 83 years old and no longer have the mental capability to do it. And, but, like, mathematically I'm gonna stop eventually. It's just a question of when and why, and what am I doing with my life? [00:40:10]
-
-**Carl Vitullo:** Yeah Tough. I don't know. I've wrestled with that a lot. What am I doing with my life? What is my life? Who am I? What do I care about? What are my values? [00:40:34]
-
-**Mark Erikson:** Why are any of us here? Why are any of us Why [00:40:42]
-
-on that note I'll, I'll toss out three other links. I'm not sure there's necessarily a lot of discussion, but they, they fit very neatly under this category. [00:40:46]
-
-a group calling themselves the Software Stewardship Lab is trained to help improve open source sustainability. And ironically, when I was on vacation in Scotland earlier this year, I actually happened to talk with some of the people who apparently were... [00:40:53]
-
-They must have been doing some of the planning for this at the time. Daniel Roe, who's the leader of Nuxt, you know, the, the next equivalent for, the Vue ecosystem is involved. Vlad Harbuz, Andrew Nesbitt, who's been doing massive research on packaging ecosystems uh, Matias Capelletto, who's involved with the, the npmx project, Miranda Heath, who's been doing research on burnout. [00:41:09]
-
-A lot of, again, very, very good people who care deeply about open source and community as a concept are involved in this. I'm a little unclear on how they're hoping to improve things, but I highly, highly approve of the concept, and these seem like the right kind of people to be doing thinking and research I read a really, really long blog post, my favorite kind that covers a number of things related to AI migrations and software craftsmanship. It's long enough that I don't remember what all was in here, but it was a really, really g- good post and worth taking a look at. [00:41:33]
-
-And then James Garbutt, who's involved with the E18E Ecosystem Cleanup Initiative, wrote his own post on humanity in open source, and some of his points are that, yeah, we're, we're getting swarmed with AI PRs and issues. [00:42:11]
-
-Open source is about more than just... Like, the construct of open source is about more than just licenses and releases, et cetera. It's about the communities that are getting involved, and it would... And then there's also the questions of, you know, how do we keep building those communities, especially if people keep getting burned out? [00:42:28]
-
-So he has s- several different thoughts on trying to manage that [00:42:53]
-
-**Carl Vitullo:** Yeah. Okay, at the mention of communities, I wanna jump in. - we're talking about, communities maintaining shared infrastructure is how I'm gonna frame this, you know, humanity and open source. Do you know how many different communities are maintaining the shared infrastructure that support every aspect of your basic life? [00:42:56]
-
-**Mark Erikson:** Where's [00:43:15]
-
-**Carl Vitullo:** I think... [00:43:16]
-
-Yeah, right, but y- right, okay, so there's XKCD of all the stacked, you know, boxes [00:43:17]
-
-with, like, that fragile thing. But, you know, like, you know what? Like, how do your lights stay on? How do you get hot water? You know? How do you stay cool? How do you get groceries? Like, each of these is the output of a shared infrastructure being maintained by a community. You know? Okay, the s- the, the, the power that might be, the community there might be a regional monopoly as dictated by, you know, legislative priorities. but, like, th- th- I guess that's how I wanna frame this. Like, I think we are exceeding the type of human scale. You know, this is like the Industrial Revolution of software. Like, it used to be all handmade parts that were not interchangeable. Th- and we've been moving more and more towards interchangeable, fully automated whatever. [00:43:21]
-
-And, like, yeah, for better and for worse. Like, if you take that lens of handmade versus scaled, you can apply that to almost anything. Like, I occasionally like to bake bread. I also buy store-bought bread because it keeps longer, and it keeps longer because it's a fully automated system that has been refined for 150 years because people need bread, and not everyone has the available time and resources to bake it. So, you know, like I, I love to think about water, water is a crazy, when you actually look into the, like, societal level engineering projects. [00:44:08]
-
-So like control of the flow of water is a shocking percentage of human effort over the millennia. Like not, keeping it within the tolerable bands. You have to have enough to keep everyone who lives there alive, but not so much that it washes their houses away. And like managing that is a preposterously large project, and when's the last time you thought about it? [00:44:49]
-
-So like that's... I think open source is now moving more in that direction, where it had been very human scale of like, I know the 15 people who are making all of, you know, making this whole thing work. And now we're starting to go into a place where there is enough automation in generating and consuming code that that scale of investment no longer really works. Another useful lens here is like Etsy versus Walmart. Like I can go to Etsy and I can buy picture frames or, you know, a pin or a sticker or a shirt, and that was probably handmade by somebody, hand designed by somebody, and I'm gonna pay a little premium for that. But like most people don't actually care that much about where their shirts come from. They don't care about the manufacturing process of, you know, how this, was this picture frame made with sustainably grown wood, or is it a composite made out of sawdust and epoxy? Like most people don't care. It looks good on the wall. [00:45:13]
-
-So that, to me, is a really fundamental lens here. It's people who are used to being very close to the production grating against the automation of what they have taken great pains to do well. And neither side is wrong. Both of them are fully correct. [00:46:14]
-
-**Mark Erikson:** So partly angling off that, and this was actually in what passes as a script over here. Two more stories of migration that circle back through the AI aspect, the frameworks aspect. [00:46:33]
-
-Cursor just got done migrating their entire system from Solid to React, and they talked some about it, and one of the things they said is, "Well, the agents are more used to writing React. [00:46:47]
-
-They actually make a lot of mistakes, but at least we're familiar with those mistakes, and they're obvious to us now, and we can control and correct for those. Whereas with Solid, they just sort of got confused most of the time." so that... There was, there was a lot of debate back and forth on Twitter. A, a lot of quote tweets and, and some discussion from the Solid team saying you also didn't ever really give us much of a chance, but yeah. So there's, there's its own drama there. [00:47:01]
-
-**Carl Vitullo:** Yeah. Certainly no, certainly no part of this was because Lauren used to be on the React team. There's probably no bias there. Yeah. [00:47:29]
-
-This is such a shady tweet. Like, "Much love to the Solid team and congrats on launching Solid 2. We just finished moving away from you." Like, that's some hella shade to throw. [00:47:37]
-
-**Mark Erikson:** And then we mentioned earlier, Lovable talked about having migrated I think their own actual system away from Next.js and over to TanStack Start. And I, I, I know they switched their project setup from whatever the previous was to TanStack Start. I believe this is separately saying they switched their own infrastructure to be built on TanStack Start instead. [00:47:46]
-
-I love a good migration post. This goes into a lot of details, and it does say that they did some of that work with AI tooling further down once they had identified some of the constraints [00:48:11]
-
-we could have spent a bunch of time on this. I think we've probably gotten far enough. We probably shouldn't spend time on this, but sort, sort of a meta point and, and one of the things we keep circling on is you can switch very easily from tool A to tool B or language A to language B at this point. [00:48:21]
-
-You say, "Here we've got this thing. This thing works. Make it work in some other tool set entirely," and if you've got enough tests, enough tokens, enough time, then it pops out on the other end. [00:48:38]
-
-Having said that, I do actually want to bring up one more set of framework-y things because I think this is fascinating reading as a person who spends too much time caring about frameworks. [00:48:50]
-
-I mentioned earlier that Ryan Carniato and the Solid team have been doing a bunch of bleeding edge research especially into how the entire signals data graph can encode the asynchronous of the data in there instead of needing to, like, separately keep track of promises or, you know, loading flags, et cetera. [00:49:00]
-
-And so they've put up a, a series of three posts that go into the details on what that means in practice when you use Solid 2. I thought they were fascinating reading myself. [00:49:21]
-
-**Carl Vitullo:** Our last main topic before we go into what are allegedly short asides, lightning round. The general unreliability of GitHub lately lately. they Put out a blog post talking about the outage on August 17th. And like, yeah, you know what? Like, they're not... [00:49:33]
-
-They're barely holding one nine of availability lately That ties very closely to the rise of agentic coding and the sheer volume of commits that are being pushed, [00:49:47]
-
-**Mark Erikson:** they've published a number of stats in the last several months about how the number of PRs and commits and API calls has just absolutely gone through the roof in the last few years. [00:49:57]
-
-**Carl Vitullo:** Like 10X, 20X [00:50:08]
-
-**Mark Erikson:** a large multiplier [00:50:10]
-
-**Carl Vitullo:** Yeah, fair. Yeah. there are now more and more people throwing out GitHub competitors, which I think is interesting. There's Cloudflare, Netlify, Cursor. [00:50:12]
-
-oh, wow from chat, "GitHub reported one commit per millisecond." [00:50:22]
-
-**Mark Erikson:** initially read that as one commit per, from Microsoft. I'm [00:50:25]
-
-**Carl Vitullo:** Yeah, me too. All it takes, one commit for Microsoft to take down the system. The commits are coming from inside the house. Okay, sorry. [00:50:28]
-
-But yeah, so there's now... there's a combination of factors that are making people start to put out GitHub competitors. Okay, obviously we're in the middle of discussing the significant outages that GitHub has been having for a number of months now. But there's also, we don't know how to work anymore. We don't know what the best way to... Uh, Well, okay, we never knew what the best way to work is, but we had at least settled on pretty widely adopted patterns, which GitHub, you know, codified and then led in a [00:50:36]
-
-**Mark Erikson:** You have, you, you have a trunk, you make a feature branch, you work for a few hours or a day, you push a PR, a teammate reviews it, CI goes green, and you ship it [00:51:05]
-
-**Carl Vitullo:** Right. there's a lot of assumptions about how you use Git in that workflow. And so, like, you can use Git in different ways if you were to so choose. [00:51:15]
-
-Uh, I actually re- [00:51:24]
-
-**Mark Erikson:** was a thing back in the day [00:51:24]
-
-**Carl Vitullo:** Yeah, and I actually have moved uh, one of my projects more towards a Git flow type thing, where you have a periodic release, and you cut an RC, and you do user acceptance testing on the uh, on the release candidate, and you ship that artifact. [00:51:26]
-
-There's an explosion in exploration of new ways to work with code and new ways to collaborate with others around code that I think is driving some of this curiosity to try alternatives. I'm personally very curious about trying to self-host some infrastructure here. [00:51:40]
-
-I don't know. Maybe this is me b- spending five years independent and not working with companies, but like, man, there's just much unexplored territory now [00:51:58]
-
-**Mark Erikson:** there was a really good discussion over in swyx's Discord just a couple days ago with a different but similar theme. Some of it was the debate over, "Wait, you guys are still reading code?" but then that also ties into, "Wait, you guys are st- like, like who's using an actual IDE to do their work?" [00:52:08]
-
-Versus this new breed of agentic swarm management tools, where what really matters is you have a chat screen and a dashboard of all the agents and the work trees in flight, and maybe it's got like an integrated diff viewer, but what really matters is, like, the task management rather than, like, I need to have the code open so I can type. [00:52:30]
-
-**Carl Vitullo:** Right. the way I have been working is very acceptance-driven of just, like, does this achieve the goal I set out when I started this project? And I don't really review the PRs as much. I do quick , sanity checks of, like, you know, is this 15,000 lines when it could be 2,000 lines? But, you know, like, very high level. I'm not really understanding the... You know, I, if I wanna understand something about how the code works or how the code is structured, like, I ask the agent, 'cause the agent wrote it. yeah, I don't know. [00:52:55]
-
-Dashboards and such, I think is... that feels not quite right to me. That feels like project manager kind of capacity more than, like... I don't know. These, like, task tracking is different from did you build the right thing? What's underway is different from are we working on the right things? So, just thinking about it through the lenses of different professional titles, like software engineer versus, like, manager versus, like, director of product or project manager, program manager. [00:53:25]
-
-Like, all of those needs of establishing what the space we're working in is, what other solutions have other people tried? What, what are we ruling out? What is the actual need we're solving? Are we achieving that need? [00:53:54]
-
-Yeah, that's all the same. Now that code is no longer the primary thing that I want to read in order to understand the, the answers to those questions. Yeah. I don't, I think we're, I think we gotta figure it out, kind of from scratch. [00:54:11]
-
-**Mark Erikson:** So point is, there's an awful lot of experimentation going on in how we as developers are, what tools we're using to do the work and what the workflows look like. And so then between the massive increase in commit scales and, you know, the, the changes in those workflows, we're seeing a variety of different hosting tools come out that, you know, either just, hey, you can have your Git hosting not on GitHub or, but also po- possibly make it more agentic friendly, [00:54:23]
-
-**Carl Vitullo:** Yeah. [00:54:59]
-
-**Mark Erikson:** whatever that means [00:54:59]
-
-**Carl Vitullo:** Interesting. I'm, I'm exploring some stuff around this area as well. I'm going to be coming at it from a very different direction from all of these places, which are still fundamentally anchored around software as a service published on the cloud which I think is limiting. But yeah. [00:55:01]
-
-Two that I wanna shout out. Tangled.org is pretty interesting. They're doing... They're trying to do essentially GitHub on at protocol. [00:55:16]
-
-**Mark Erikson:** no [00:55:24]
-
-**Carl Vitullo:** So it's, you know, it... That's cool. It's a decentralized social media platform, and they're putting basically the social components of GitHub onto that decentralized protocol. So awesome. That's awesome. That's very cool. [00:55:24]
-
-Cloudflare is also doing a, yeah, versioned storage that speaks Git, is their headline. We had some others in the notes from Cursor and Netlify, but I wanna be honest, I don't, I don't feel like either of those are in the right place to successfully execute on that vision. [00:55:38]
-
-**Mark Erikson:** Mm-hmm. I will say that this article on scaling Git was fascinating. there's been a lot of efforts over the years to make Git scale. Microsoft has done a lot of work on, like, virtual file systems and improving algorithms inside of literally the Git implementation itself. This one's more focused on the hosting side of things [00:55:55]
-
-**Carl Vitullo:** Yeah. And okay, this is why I'm skeptical of software as a service cloud-based, 'cause, like, that's the problem. Like, Git is a decentralized system, you know? You can just add a remote, and it... Like, you push. It's exactly the same. yeah, if you're dealing with pushes from literally the entire world, that's really hard to optimize. But, like, I dream, I hope, I wish that at some point we will get to a state where more people can have, you know, world accessible, safe compute that they control. [00:56:16]
-
-Like, I have a network accessible storage here. It technically can run a Git server. Like, there's no reason I couldn't use that as my primary store, and then, like, make that available to some other tooling that is aware of that storage and does collaborative features on top. When you distribute stuff like that, you don't have to worry about load at any individual site anywhere near as much, which is what this Git any, any scale kind of post is talking about. Anyway. [00:56:48]
-
-## Short asides/lightning rounds
-
-some lightning round whatever. [00:57:14]
-
-I saw a fun thing, npm.report. It looks like an interesting way to just get, like, a very brief... I don't know, this is, this is maybe a very early project. Just looking at some of the numbers on the landing page Well, it's certainly not ingesting all of npm to do this. But yeah, it's interesting. It's doing supply chain trust signals for npm organizations, so the audit, visualize, share, track over time. Uh, It's an interesting idea. I'm not quite sure if the execution is fully able to execute upon the idea it has, but it's looks interesting. Supply chain management auditing is so in vogue right now because it doesn't work very well. [00:57:16]
-
-**Mark Erikson:** So I, I mentioned Andrew Nesbitt earlier. He's been blogging for, for a while on package management ecosystems. He's, he's probably the world's foremost expert on all the world's package managers out there, and has put up a lot of blog posts on, like, how they work internally, where they're flawed, all these other things. [00:57:51]
-
-He's also written several satire posts on his blog. , he's written some fake articles about fake AI-driven CVEs slipping through the chains. he did this one a supplier security questionnaire. You know, the kind of thing that, like, a, a company security office would send out to their dependents, except this one's clearly being sent to an open source person. [00:58:10]
-
-And the questionnaire just gets more and more absurd on the requirements that they're placing on this unnamed open source maintainer. And, and that, that's sort of what happens when the legal compliance side of things wants assurance that your supply chain is secure, and two-thirds of your app is just we installed this NPM package [00:58:34]
-
-**Carl Vitullo:** Yeah. Cool. Nice. Love that [00:58:55]
-
-Okay. Well, continuing on our security thread there . I read a really great blog post called Everything I Own, Owned. so this person, Chaz Schlarp, put out a blog post about pointing Claude at various physical devices that he literally owns, that are physically in his possession, and just saying like, you know, "Hey, can you hack this? [00:58:58]
-
-Can you get control over this? Can you put a custom firmware on this?" and the answer resoundingly is yes. [00:59:17]
-
-**Mark Erikson:** Nice [00:59:25]
-
-**Carl Vitullo:** you know, hacked his own webcam a- alarmingly hacked it in such a way that he was able to turn off the recording light which ideally should not be possible. Ideally, that should not be a software controlled feature. It should be electrically impossible for the camera to record while the light is off. Oops, this one could. [00:59:26]
-
-Also hacked his monitor. And I... Something I appreciate is for each of these devices, he puts up a GitHub repo of the new firmware, how long it took Claude to figure it out, and how many prompts from him it took Claude to figure it out. So this, you know, the webcam was three and three quarter hours of Claude time with 33 prompts. His monitor is hour and a, hour and 15 minutes with 13 prompts. A microphone was four hours, you know, four hours and 15 minutes with 32 prompts. [00:59:44]
-
-I think this is really fascinating from a couple of different ways because to tie it into a like macro, huge question of ownership conversation that I've been hearing about for the right to repair. Like most things don't let you repair it. They don't let you, you know, access any kinds of internal state. And so like now that these AI tools are good enough at reverse engineering and cybersecurity stuff to just hack it, like, hmm, that's actually pretty interesting for right to repair. Like you know, to the extent that rules and policies are only as good as your ability to enforce them. [01:00:17]
-
-Like oops, they can't enforce their own security practices because it used to just assume that it was too hard to flash a custom firmware and now it's actually not that hard as, if you know generally what you're doing. [01:00:53]
-
-**Mark Erikson:** Or a lot of cases, if you don't know what you're doing or just willing to tell Claude, "Try harder." [01:01:05]
-
-**Carl Vitullo:** Right. Right. here's a fun one. This is a mini key light. So I think it's, you know, it's like for video production, it's just like a little controllable two by three inch light. And he says, " This one turned out way more interesting than I expected. It's the only one with meaningful firmware integrity protection. It signs the firmware updates with ED25519 and a hash of the firmware payload and rejects firmware that doesn't validate. Unfortunately, while that's an improvement, it protects the firmware ex- at exactly one point in time, during updates. I asked Claude to look for an exploit that might enable, you know, other attack surface, and it found an HTTP post request that drops a payload straight into the internal UART which includes a memory poke command." [01:01:09]
-
-So it, you know, it's got signed [01:01:50]
-
-verification [01:01:53]
-
-**Mark Erikson:** Change this value." [01:01:54]
-
-**Carl Vitullo:** Yeah. So it's, it, it has ostensibly update security, but it also has an HTTP endpoint that will let you, like, arbitrarily revise memory. He says, "This means a single HTTP post of ATSC equals," and then two hexadecimals comma-separated values, "turns the signature check into a no-op, and we can freely update the firmware." So it's just like, man, that's crazy. [01:01:55]
-
-That's great. [01:02:17]
-
-**Mark Erikson:** you tried [01:02:18]
-
-**Carl Vitullo:** At least you tried. Yeah, defense in depth, it's really hard. I don't know, that's really interesting. Like, if we own, if we more meaningfully own the ability to control what the tech in our rooms is doing, that's powerful. I appreciate that. We should have more of that. [01:02:19]
-
-Final AI security adjacent thing from the Trail of Bits blog. The Sorry State of Skill Distribution, talking about how the skill marketplaces for AI agents are full of malicious skills that will exfiltrate your, you know, credentials and blah, blah, blah, blah, blah. Yeah, so don't download arbitrary skills without reading what they're gonna be doing. You know, this is just an extension of I don't know, running untrusted code is never good, and running untrusted skills that will have the ability to run untrusted code on your hardware is even worse, ' cause these are smart. Yeah, reminds me too, I, I just learned, this happened last month, but a certain AI platform controlled by a person whose name I don't like to uh, give airtime was, it turns out the whole agent itself was uploading all of the directory that you ran it in with no control. So it would pull every, every file in there and just dump it into a remote GCP container. [01:02:33]
-
-So, like, state of security right now in the AI w- world is pretty rough. Most people are being very sloppy about it, and if you are riding the cutting edge, the odds that you run into something that will aggressively attack you is pretty high . [01:03:32]
-
-## Conferences (React, Javascript)
-
-Oh yeah, Mark, tell us about this conference [01:03:46]
-
-**Mark Erikson:** Yep same two I mentioned last month, and conveniently they're the... I, I know about them because I will be speaking at both of them in the next few weeks. ZurichJS is happening, I believe, on September 11th in Zurich, Switzerland. I said it last time, I'll say it again, because he r- especially because he ran across the transcript and thought it was very heartwarming. Faris Aziz is a good, close personal friend of mine. He's running this conference. He's been running the ZurichJS meetup for the last year or two. This is the first time conference for them and I know how much effort he has been putting into putting this together, from selling tickets to doing outreach and getting sponsors to building an entire conference management platform from scratch. [01:03:48]
-
-Faris is awesome. This will be a fun conference. The speaker list looks great. I'm looking forward to seeing a lot of good, good friends there. If you are anywhere in Europe or even not in Europe, consider buying a ticket and joining us there. It'll be great. [01:04:33]
-
-similarly, [01:04:46]
-
-React Alicante is in Alicante, Spain. [01:04:47]
-
-I believe that's around September 23rd, 24th-ish. That's also been a lot of fun. it's a very well-run conference. Another great organizer, Victoria. it's a good conf- there's a lot of good people there. Come join us. Hang out. Talk in real life. It's a thing [01:04:50]
-
-**Carl Vitullo:** Yes, I can confirm that Mark is a lovely person to go to a conference with. [01:05:05]
-
-Cool. All right, that's all we got for you this month. Thanks for sticking around an extra 25 minutes past our... Well, I'd say past our typical end time, but it's not like we've ever hit that, I think, this year. we'll be back next month. Maybe not on the last Wednesday, 'cause it's the last day of the month. Or we'll be back in your podcast feed just as soon as we can after we record. [01:05:09]
-
-Yeah, thanks so much. If this is a podcast that you find valuable I'd actually just personally love to hear it. If you shot me an email to hello@reactiflux.com and said something about how this has influenced the way you think or do things, that would be personally meaningful to me. [01:05:27]
-
-Or give us a review. Tell somebody else that you know about this podcast. That would all be very helpful. We have a sponsor for next month, which is great. yeah, so that should cover most of the costs of producing it for the year, I like not paying for it myself. cool. Thanks so much. See you next month. [01:05:41]
-
-**Mark Erikson:** Take care [01:05:58]
-
- [01:05:58]
diff --git a/src/transcripts/tmir-april-2023.md b/src/transcripts/tmir-april-2023.md
deleted file mode 100644
index 638ccb2..0000000
--- a/src/transcripts/tmir-april-2023.md
+++ /dev/null
@@ -1,461 +0,0 @@
----
-title: This Month in React (April 2023)
-date: 2023-03-29
-time: 10am PT / 5PM GMT
-location: Q&A Channel on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Matt Pocock as we break down This Month in React. A lot of news this month, with new library releases, TypeScript 5.1, and React server components. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Matt Pocock](https://twitter.com/mattpocockuk)"
----
-
-
-
-# This Month in React 2023 April
-
-**Carl Vitullo:** Welcome everyone. Thanks for joining us for April's edition of this Month in React, where we talk about what's going on in the React ecosystem. Mark and Sebastian, could you introduce yourself? [00:09]
-
-**Mark Erikson:** I'm Mark Erickson. I'm a senior front end engineer at Replay, where we're building a true time traveling to bugger for JavaScript. Also, I do a whole lot of Redex stuff. [00:18]
-
-**Sebastien Lorber:** So, yeah, I'm Sebastian. I created the This Week In React newsletter, and I'm also the maintainer of Docusaurus, which is a static site generator that many direct websites, use today. [00:30]
-
-**Carl Vitullo:** I'll kick us off. The way we do these news events is we do a round robin where one of us will introduce a link from the past month and then we all discuss it until we run other things to say. [00:40]
-
-## React Visualized, react.gg
-
-- [React Visualized, react.gg](https://react.gg/visualized)
-- [Launch tweet](https://twitter.com/tylermcginnis/status/1642969928562262020)
-- [The Story of React, uidotdev](https://www.youtube.com/watch?v=Wm_xI7KntDs)
-
-**Carl Vitullo:** Yeah, I guess I'll start with React Visualized react.gg. I just saw this, this is from Tyler McGinnis. He does the bites.dev newsletter. He's been in the React ecosystem for probably, at least as long as I have, maybe longer, I feel like. But definitely a, a giant in the ecosystem and excited to have such a high quality looking resource for learningReact. [01:01]
-
-**Mark Erikson:** Yeah, so there's, there's a couple things going on here. So Tyler runs a training company called UI.Dev, which makes, you know, a bunch of different courses including React Things, and I think they've had a couple different iterations of some of their different React courses. One thing I've seen Tyler do over the last couple years is that he's, he and this company have made a few different videos explaining various aspects of React, but from my perspective, even more importantly, explaining why some of those things about React exist. [01:31]
-
-This React Visualized thing, I actually saw them do a video version of this first. It talks, it like goes back in history to, you know, 2010, ancient history by this time. [01:44]
-
-**Carl Vitullo:** Ancient! [01:44]
-
-**Mark Erikson:** And, and it talks about, you know, frameworks like Angular and backbone and or, you know, even, vanilla JS, JQuery and some of the pain points people were experiencing working with those. And then it talks about how React was designed to solve some of those pain points as background information. It's sort of like a history lesson plus a, like why does React exist plus, like what are some of the basic concepts of React as an introduction. [02:11]
-
-He did both a video that I saw posted on YouTube. I'm not sure it's actually, it's actually linked from this site, and then this actual React Visualized site, which is semi-interactive visual page that shows a lot of that same information. I'm a really big fan of the concept, that it helps to understand what problems tools were designed to solve in the first place, in order to help learn them properly. [02:35]
-
-I really appreciate that Tyler is kind of taking that approach with some of this training material. Also, like if you, if you haven't seen any of the videos that Tyler has done, they do a nice little mixture of like, straight up serious explanation and historical clips of people talking at conferences where they were announcing certain tools and then like random, snarky, funny bits. [02:57]
-
-**Carl Vitullo:** Nice. Yeah, I do. I do love the, all the context for why React is, I think it's really important to understand where it came from in order to understand why it is the way it is. I think that is a very helpful framing. I hadn't heard about the, the YouTube videos, so, thanks for, thanks for putting that on my radar. I'll see if I can find some links for when we publish the recording of this. [03:17]
-
-**Sebastien Lorber:** Yeah, I think the. they build all this because they are releasing a course, pretty soon. That is a work in progress, and they created their own, course platform. So somehow I think this resource is, is a symbol of the, the quality of the course that they try to, to achieve. And it looks like, maybe it'll be the, the best competitor to Josh Comeau's course, I think because, both, look, like very polished. [03:42]
-
-**Carl Vitullo:** When your competition is Josh Comeau that you're in pretty good company. Cool. [03:46]
-
-Yeah, Mark, you want to kick us off with our next link? [03:49]
-
-## Immer v10
-
-- [Immer v10](https://github.com/immerjs/immer/releases/tag/v10.0.0)
-
-**Mark Erikson:** Immer version 10 just came out this last week. And for background, Immer is a library to simplify making immutable updates. So if you've used React, or Redux, you're probably familiar with having to do a whole bunch of, like spread the object, spread the nested object, spread `state.a.b.c`, or you know, mapping the arrays, slicing the arrays, concating the arrays, all that kind of stuff. Immutable updates are hard to get right. They're long, they're hard to read. It's easy to make mistakes. [04:17]
-
-Immer is a great library from Michel Westrate, the author of the MobX state management library. It lets it wraps your data in a proxy object, and then inside of that, you can write what looks like mutating syntax. So, `state.value` equals 1, 2, 3, and it traps those changes and turns it into a safe and correct immutable update. And in fact, we've been using Immer inside of Redux Toolkit since the very first proof of concept. [04:46]
-
-Immer has been around for a few years and they were on version nine. Immer still had, various pieces of legacy support. They had a ES5 fullback mode so that it would work in environments that didn't support proxies, which was primarily either IE11 or older versions of React Native before the Hermes JavaScript engine added proxy support. It, it also was trying to be like a little too correct in copying properties on objects. [05:14]
-
-It was doing a lot of like diligent, careful little checks for getters and a bunch of other things, and it was like correct behavior, but that also kind of slowed down the work of making the copies, for the most part, you know, assuming you're dealing with small data that wasn't too much of a per overhead and goodness knows the, the simplicity benefits made it worth it. [05:35]
-
-But for Immer 10, Michel Westrate made a bunch of updates. he dropped the ES5 fallback, and he also kind of adopted a looser approach to copying properties in new objects that is significantly faster. He'd been putting that, he'd been working on that for about the last month. Put out a few betas. [05:55]
-
-We tried them out over in Redux Toolkit, and Immer 10 final just came out about a week ago. It is noticeably faster and it's nice. And I actually contributed a PR to help improve the build tooling setup, and that helped improve some of the module formatting, ESM, CommonJS, and also help shrink the bundle size as well. [06:19]
-
-So I'm really excited about that in general, and especially because that's gonna be included in Redux Toolkit version two, which we've already got in Alphas. So it's sort of a, a free win for a lot of the ecosystem in terms of bundle size and performance. [06:33]
-
-**Carl Vitullo:** Nice. Yeah. I know that Immer from the start relied on on a lot of newer JavaScript features. I remember it being like a little bit of a, you know, maybe not a miracle, but a tough project to get it to work in more legacy environments like ES5. So now that they're able to drop some of that code. Makes sense that there'd be a lot of, you know, long tail enhancements, like bundle size and performance. That's awesome. Hell yeah. [06:58]
-
-**Mark Erikson:** Michel Westrate is a genius. [07:00]
-
-**Sebastien Lorber:** Yeah, I actually, I've seen a few, competitors projects. I don't know, but maybe, one or two were claiming to be, much faster than ImmerJS, but I think maybe they didn't support the older environments in the first place. So of course, it's, it's easier when you reduce the scope of, the library. [07:20]
-
-**Mark Erikson:** Yeah, I, I saw two different Immer equivalants, or competitors, pop up within the last few months. one is called Mutative and the other is called Structura. and they, they both perform the same basic function, wrap your data and a proxy, track the updates, make 'em immutable. [07:38]
-
-On the Redux side, we've had Immer built-in as a hard coded, non-negotiable part of `createSlice` from the beginning. Partly because we think Immer is using Immer is the right choice. But like we've had people say like, "I don't wanna use Immer." And we're like, then don't use Redux Toolkit because we think it's the right thing to do. And we're not making that configurable in any way. [08:00]
-
-Because a couple potential competitors did come out, we actually have an experimental PR over on the Redux Toolkit side that tries to let you swap out which immutable update library gets used inside of like create slice and stuff. It's tough because we actually use those imports in a lot of different places and so, you know, trying to figure out how to sort of turn them into like factories that let you configure it is tough. [08:27]
-
-And I'm, I'm not sure if that'll actually end up getting merged, but given that there's a couple other equivalent tools for immutable updates, we figured it was worth at least kind of playing around with it a little bit. [08:38]
-
-**Carl Vitullo:** Nice. Yeah. Makes sense. [08:39]
-
-Yeah. Sebastian, you wanna take us off? [08:41]
-
-## NextJS 13.3
-
-- [NextJS 13.3](https://nextjs.org/blog/next-13-3)
-- [Rich Harris talk](https://www.youtube.com/watch?v=uXCipjbcQfM)
-- [Notes on talk](https://blog.jim-nielsen.com/2023/notes-from-richs-talk/)
-
-**Sebastien Lorber:** yeah. Well, wanted to to talk about, the new NextJS 13.3 release. I think this one is interesting, in particular for one thing that I am particularly excited about. It's not the parallel routes and things like that, but more, the, the static export because, I think they, they don't highlight this enough in their marketing, but when you build the right server components with NextJS, by default, they are static. And if you don't choose any dynamic api, like getting the error of a request or getting the querystring or things like that, the server component will actually run at build time instead of, run time. So I think it's a really interesting property you can, configure if you want the server component to be static or to be dynamic. [09:29]
-
-But by default, it tries to automatically detect if you use any dynamic API and decide for, for itself if it should run at, build time or at run time. So, I think this is really, really interesting and they now support the static export. So basically this means if you don't choose any dynamic API anywhere in your app, you can export your, NextJS website statically, and all the server components will run at build time. [09:58]
-
-I think it's quite exciting, and also this works with, nested router. So the static or dynamic nature of the, of your components will depend on the root segments. So, for example, you can have a part of your page that is dynamic and some other part that is static. In the end, they really try hard to, to make, most of your components static, if it's possible. [10:21]
-
-And the, the rest will be dynamic, but they don't render too much things. And try to, to build, as much as possible at build time, all the server components. [10:32]
-
-**Carl Vitullo:** Nice. Yeah, that's really, that sounds really cool. I guess I, I thought that they already had something for a static export. I know that we, we use next for the Reactiflux website, I think that I did some kind of static export. [10:46]
-
-**Sebastien Lorber:** Yeah, it, it existed, but not for the, for the new app root directory, so it was not, working for server components yet. [10:53]
-
-**Carl Vitullo:** gotcha. Okay. That makes sense. Okay. Yeah, I. I haven't touched that in probably a year now, so it definitely did not get the app router in there. Okay, cool. Very nice. Yeah. I also see that they have new metadata API and dynamic open graph generation. Those both sound pretty cool. I know that a lot yeah, just open graph and the review image. [11:15]
-
-I think that's, I feel like over the last year or two, I've seen a lot more people, especially for like their blogs and their personal sites, treating that open graph as a, more of like a first class feature, rather than just sort of like an afterthought of copy some text outta the page and boom, there you go. [11:32]
-
-So having some more first class support for that from Next, seems like it will enable a lot of really cool features. [11:40]
-
-**Sebastien Lorber:** Yeah. actually I'm, I don't know exactly exactly how the integration work, but as far as I understood the OG image, package that they created only runs on Vercel because it requires some tooling available on the edge to, to make it work. so I wonder if it doesn't create coupling between NextJS and Vercel as a host. [12:04]
-
-So, I don't know. It's, it's not, mentioned in the blog post, so, so maybe I'm wrong, I don't know, but, recently there was someone that posted a blog post that says, "I am able to run a Vercel OG image on Netlify," or another host, I don't remember which one. And it required some, some tricks to, to make it work. [12:24]
-
-So it was not so, so easy. And I'm not sure if this package works everywhere yet. [12:29]
-
-**Carl Vitullo:** Gotcha. Yeah, I know that's been a, a pretty common point of negative feedback about Next is that everything works on Vercel first. [12:36]
-
-**Mark Erikson:** Yeah, that's that. That was the same thing that was going through my mind. So with a couple caveats that I have not used server components yet, and frankly, I've never worked on a project that needed SSR in any form. So I can't speak from trying stuff out myself. First it's very, very good that next does have a static export option, and I know that the new React docs where they're talking about picking a framework, do try to, you know, actually link and say that hey, you can use next without an actual running next server instance on your backend. [13:11]
-
-And I've seen Dan trying to, you know, help clarify that on Twitter. But I think some of the unease that people have with this, you know, this shift in advertising and direction from the React team is that they feel like they're being pushed towards next and Remix and stuff. Where the default path is you need to have a server running. [13:35]
-
-It's going to work best on Vercel. It's very easy to end up using features that require, you know, a whole bunch of additional entanglement. And yes, the options exist where you can skip that stuff, but the default happy path is adding all the, you know, all these dependencies and servers and stuff. And it, it's tricky to kind of say separate, like you can go without that stuff, but you have to do work to try to skip out on that. [14:01]
-
-I think that's what's, you know, kind of adding to this feeling of concern. [14:06]
-
-**Carl Vitullo:** Right. Yeah. Makes sense. But you know, I also definitely understand the motivation for, you know, there've been a lot of new, new ways to approach web development over the last couple of years with like ,edge workers and things like that. And I think that there's a lot of really exciting possibilities coming out of that. [14:23]
-
-So I understand the impetus to try and offer like first party ways to explore that. And yeah, I mean, I guess, you know, control over the server definitely makes it a lot easier to offer a good experience. But yeah, I guess I understand both sides of this, which is not a very exciting take (laughter). [14:41]
-
-**Mark Erikson:** Quick side note, Rich Harris recently did a fantastic talk. He, he gave like his thoughts on 10 different topics and he was rating them in terms of spiciness and, even the highest spicy rated takes weren't necessarily all that spicy. It was actually very thoughtful, deep nuanced discussion of trade offs of different tools and scenarios. [15:02]
-
-**Carl Vitullo:** Yeah, that's definitely someone I would expect to, or that I would have a lot of trust in to talk about. Topics like that with a lot of nuance. [15:09]
-
-## New React documentation translation
-
-- [New React documentation translation](https://github.com/reactjs/react.dev/issues/4135#issuecomment-1518443599)
-
-**Carl Vitullo:** All right, I'll move this on with our next, this is, you know, maybe not a whole lot to talk about here, but the new react.dev documentation site is getting translated. [15:18]
-
-I know that that was a, you know, that was one of the, points of negative feedback I heard about it is the old docs were in available in so many different languages and the new new docs were not launched with support for those. So good to see it as a fast follow to the launch. Looks like it's been in in the works for a long time and seeing a lot of work done. [15:37]
-
-I see a huge, huge list of translations. [15:40]
-
-**Mark Erikson:** And I know that as a whole, the reason why the docs were delayed so long was Dan was waiting to, was trying to get the content to, you know, a sufficiently complete level, and also make sure that the explanations and the tone were the right way. It's kind of hard to really start translation when you're still iterating on that process. [16:01]
-
-**Sebastien Lorber:** If you refactor everything, it's a pain for the translators because they have to, the, the strategy that they used is based on a repository, so they have to, some of the, there is the main repository with the trans, the English language, and there are folks for each language and. They synchronized the new documentations from the upstream language to the older folks. [16:25]
-
-They have a bot to automate this, but, still I think they, it can be a bit painful to manage all this and to ensure that there are not, merge conflicts between, the, the current translations and the new documentation that the red car team is aiding. So, it's better to, to have most of the content quite polished in the first place before starting the the translation effort, I think. [16:49]
-
-**Carl Vitullo:** Yeah, definitely makes sense. Every language you wanna do it in explodes the amount of work or you know, it adds one more copy of it. So given that, I think, looks like the list of language they support is easily 15 or 20. So definitely trying to write all of those in parallel is just like a non-starter for that. So yeah, glad to see you coming out. [17:11]
-
-**Sebastien Lorber:** Because the translation workflow even is a bit complex, so you have to onboard people if they are not used to it. So [17:19]
-
-**Carl Vitullo:** Right, [17:20]
-
-**Sebastien Lorber:** this is not easy. I think the, hopefully they, they're able to split the work, between, each site. So, each site can somehow autonomously work on the translation. But, you have to explain to each main language contributor how it, it works to, to make them productive in the translation process. [17:41]
-
-**Carl Vitullo:** Right, right. I've only ever dabbled in translation on apps that I've worked on. You know, none of them really had serious international usage, so it wasn't a major impediment, but writing documentation to explain difficult technical concepts in 20 different languages. Like, oh, oh boy. What a task. [17:58]
-
-Well, Mark, what's up on your list? [18:00]
-
-## TypeScript 5.1
-
-- [TypeScript 5.1](https://devblogs.microsoft.com/typescript/announcing-typescript-5-1-beta/)
-
-**Mark Erikson:** So TypeScript 5.0 just came out, and hot on the heels is TypeScript 5.1 in beta and one of the changes there has to do with TypeScript support for JSX syntax and type checking what gets returned. Now I only barely understand what's going on here, so you know, please, please take my explanations here with a grain of salt, TypeScript support for JSX was basically originally started to support React. [18:28]
-
-But JSX is not a React only concept today in a lot of other frameworks like Solid use it. And so TypeScript has had to do this kind of difficult dance internally where they need to be able to handle JSX but not lock their support of it to only working with React specifically. It has to be a little more generalized, and that's had limits on how the, the type checking process can work. [18:55]
-
-This has actually had ripple effects on how you can use TypeScript in your React components. And the biggest pain point is that due to something about the way JSX elements were implemented, TypeScript would actually yell at you if you tried to return some of the newer, non-JSX return values from a component. [19:15]
-
-So, you know, if you tried to return like strings or arrays from a function component, it's totally legal JavaScript and as of like, you know, React 16, it's totally fine, but TypeScript would yell at you and say, "you can't do that," and you end up having to wrap that in a fragment that serves no purpose other than to satisfy TypeScript. [19:34]
-
-So, The React team has been working on trying to allow some components to do things like return promises, and of course, TypeScript would not allow that given its current type checking support. This discussion started like, two or three years ago and I think it's been a very long running issue, and the TypeScript team just merged a PR that somehow alters how TypeScript interprets and type checks JSX syntax. [20:02]
-
-And this seems to loosen up what it will allow and is apparently going to make it easier to do things like returning a string or an array from a component. And it'll be legal as far as TypeScript's concerned. And it will also unlock future changes for things like returning promises from components. Basically TypeScript is trying to make it better and easier to return a broader array of things from components with JSX syntax. [20:30]
-
-**Carl Vitullo:** Yeah, I definitely remember encountering those sort of type bugs where I know that this is a valid thing to return from this component, but actually getting TypeScript to recognize that was a pain in the butt. You know, figuring out what type I'm supposed to use to describe the component, whether that's React.FunctionComponent, or you know, React.FC or whatever it is. So I'm excited to see this improve the situation. [20:54]
-
-**Mark Erikson:** The default recommendation has been just don't use it at all. Provide a type for the props and let ts figure out what the return type is. [21:02]
-
-**Carl Vitullo:** Hmm. Yeah. Excited to see that get better. [21:05]
-
-Cool. Yeah. Sebastian, you wanna take us on our next news item? [21:08]
-
-## MillionJS, one-function React perf wins
-
-- [MillionJS, one-function React perf wins](https://twitter.com/aidenybai/status/1650406345517199361)
-
-**Sebastien Lorber:** Maybe you've seen there is a new package called, MillionJS. I think it's, it's interesting and it, it got my curiosity. The idea is somehow to, to make, to improve the performance of the virtual dom by using, a block based virtual DOM. As far as I understand it, the idea is that if you have two virtual DOMs that have exactly the same size and structure and things like that, you are able to optimize this and perform the diff faster. [21:37]
-
-And recently there was, a new version of MillionJS, which support, NextJS too. So it's possible to integrate into an existing app to make it faster. And, there's also a repository that now is there for learning purpose called HundredJS. And the idea is that, it provides a very simple, implementation of a block-based virtual DOM, but you can, understand, the idea. [22:04]
-
-So I don't know exactly how it works yet, but, I found, it was quite interesting somehow the first time I came across this project, I thought, oh, they have a beautiful landing page, and the developer is 16 years old or something like that, I don't remember, but he's very young. I somehow dismissed this project, but, now it, I, I get more curiosity for it. I think, maybe this will be, an interesting thing, to, to follow in the years to come. [22:30]
-
-**Carl Vitullo:** Yeah, interesting. This is, this is a new project to me, but you know, anything that promises to make stuff faster just by wrapping it into function, is both interesting and draws a little bit of skepticism (laughs). I've definitely written some components, or rather some helper functions that look like this to solve performance problems for myself. [22:50]
-
-The main situation I'm thinking of is where I have a very slow, you know, maybe it's very complicated or something, some slow component as part of a larger page. And some number of years ago I wrote a, a little helper that just, it, it was basically sort of a, a cheap async rendering helper. It would just render nothing for one render pass and then render the actual children. [23:13]
-
-Yeah, I used that on a very complicated list page, and it took initial render down from like over two seconds to tens of milliseconds just really helped the sense of interactivity, if not the total overall render time. You know, the, the actual render time didn't change that much, but at least you can interact with the page while it's doing all of that. [23:32]
-
-So I, I wonder if it's doing something similar to that, just enabling rendering to split up over multiple passes. But yeah, cur curious to dig into that more. [23:41]
-
-**Sebastien Lorber:** Yes, I'm, I don't know exactly. I, I can tell, but this is something interesting to follow, I think. So we will figure out, soon, I think (chuckles). [23:49]
-
-**Carl Vitullo:** Cool. Yeah. I guess I'll pick us on to the next one. [23:51]
-
-## React Server Components
-
-- React Server Components
-- [RSC Quiz thread](https://twitter.com/dan_abramov/status/1648923232937058304)
-- [XHP v JSX](https://twitter.com/dan_abramov/status/1648830869304426500)
-- [Lenz RFC for Apollo/RSC](https://twitter.com/phry/status/1649520340647673856)
-- [AsyncContext stage 2](https://twitter.com/sebastienlorber/status/1639183216799100928)
-
-**Carl Vitullo:** So this is not necessarily one single news article, but definitely a topic of discussion, React Server Components. There's been a lot of news and discussion coming out over the past month or so. I saw Dan Abramov did a quiz thread on Twitter. Looks like it answers a lot of questions about how React server components behave. [24:11]
-
-Definitely interesting information in there. I have not yet really used React server components at all, so I , I don't feel like I can speak too deeply on this subject, but Mark, Sebastian, have you used server components much? [24:23]
-
-**Mark Erikson:** Not in the slightest. [24:25]
-
-**Carl Vitullo:** Hahah. [24:26]
-
-**Sebastien Lorber:** No, (laughs) no, I mean, I only work on Docusaurus, so there is no Server Components yet, but I, I wish, to do that, soon, but need to figure out a few things before. [24:38]
-
-**Carl Vitullo:** Yeah. Yeah. I feel that. [24:40]
-
-**Mark Erikson:** And, and similarly, like my day job at Replay is, replay is entirely a classic client side, single page app. And between that and all the Redux stuff, I don't have time to go play with other new shiny things. [24:53]
-
-**Carl Vitullo:** Right, right. Yeah, I know that Dan has been on a, a bit of a, a bit of a PR blitz. Yeah. He's been on a tear doing all sorts of events and talking about React Server Components a lot. We've talked briefly about doing an event here, and maybe having an ongoing channel for people to ask questions about it. So yeah, stay tuned for news about that. [25:15]
-
-But, nothing to announce at the moment, but yeah, so I saw that quiz thread from him. I also saw a great sort of history of that I just posted in the chat. it talks a lot about X H P and hack and Facebook code going back to 2010 era. Definitely. Yeah. I mean, like we're talking about with React Visualized, I think the history of why things came to be what they are is super helpful for understanding what they are. [25:42]
-
-So I, I think that's a, I think that's a good thread to read, to understand what's going on. [25:46]
-
-**Sebastien Lorber:** Yeah, definitely. [25:47]
-
-**Carl Vitullo:** Yeah. [25:48]
-
-**Sebastien Lorber:** I think the, the, the quiz is very interesting because somehow we challenge your, your intuition that you can have. And honestly, I, I, I think I got all free and sales correct, but, I wasn't absolutely sure about, any of them (laughter). So this is, this is really not easy and I think many people, don't have the intuition of, of several components. [26:09]
-
-So this is really worth to, to take it and see if you, if you have the intuition. [26:14]
-
-**Carl Vitullo:** Yeah, definitely. [26:15]
-
-**Mark Erikson:** It seems like one of those things where half the people are gonna get this wrong either way. [26:19]
-
-**Carl Vitullo:** Right, right [26:20]
-
-**Sebastien Lorber:** (chuckles) [26:21]
-
-**Carl Vitullo:** Definitely a, a big iteration on the React mental model. So I'm sort of, I'm sort of waiting for the dust to settle before I dig too deep into it. Just, you know, a lot of churn going on, a lot of innovation and discussion, and I'll, I'll come through a little bit later and see what it all looks like, but it's definitely a lot to stay on top of. [26:40]
-
-Cool. Yeah. And one more link I wanna paste from one of our, one of our community members, Lenz Weber-Tronic, phryneas' post is, looks like he's looking into React Server Components, how to connect it to Redux Toolkit in Apollo. [26:54]
-
-**Mark Erikson:** Yeah, so Lens is my Redux Toolkit co-maintainer created our RTK query data fetching library, and he also recently got hired by Apollo to work on Apollo client. So we've, we've had a couple of different discussions with the React team about, you know, how our external data libraries supposed to integrate with suspense. [27:14]
-
-And the shorter, the short answer is, "we're still not really sure, go make new APIs instead of building that into your query hooks." But then he's also been doing a bunch of research over the last few weeks into, how you server components work, and how would you integrate external data fetching libraries into server components in the lifecycle? [27:34]
-
-And he's only, he's only hinted at bits and pieces and some of that, some of those hints were in this, this Twitter thread, but it sounds like he's been trying to put together a fairly large write up to start a discussion and ask some questions. So I am actually legitimately curious to see what his summaries are and what his questions are because again, like I don't have time to look into this myself, so I'm glad Lenz does. [27:59]
-
-**Sebastien Lorber:** Yeah. [27:59]
-
-**Carl Vitullo:** Yeah, definitely very curious to see what he, his conclusions are. Yeah, I mean he's been active in Reactiflux for years and very helpful and thoughtful, so very much curious to see what he thinks. [28:10]
-
-**Sebastien Lorber:** Something, I'm thinking about is, you know, we already discussed that in the past, but I think it's a bit related, is the new AsyncContext proposal, which is a stage two for standardization in JavaScript. I have the feeling that the, the idea of this API could be to, to use React context in a cross platform where in both our components, when they use I think, weight and, also in a regular components that we use today on the client and things like that. [28:41]
-
-I think it's interesting because, it could enable you to provide the, the, the context of maybe Apple, Apollo or React Query to your tree. No matter if it's a client component or a server component, it should be able to work. So, I look forward to, to see this api, become adopted everywhere and see if, and see if it unlocks any use case. [29:06]
-
-I think Sebastian Markbåge posted something, recently and, and somehow it summarized the idea that, that I tried to, to explain is that you could use eventually the standard, I think, context feature as React context directly. So I think this is interesting because this would not only work with, React hooks, but also, as a regular, JavaScript feature that we can work both on the edge, on the NodeJS runtimes, and also on the client. [29:38]
-
-Maybe it's not what is, maybe it's not, it's not the challenge that Apollo is facing to integrate with several components. I don't know. But I think it's one of the piece that could make it, easier. [29:49]
-
-**Carl Vitullo:** Yeah, definitely always nice to rely on standard browser features rather than something hand rolled within a library. I'm sure React would love to have some sort of standardized context. [30:00]
-
-**Mark Erikson:** Use the platform. [30:01]
-
-**Carl Vitullo:** Use the platform! [30:02]
-
-Cool. Yeah. Mark, what have you got next? [30:06]
-
-## Recommending uncontrolled components
-
-- [Recommending uncontrolled components](https://twitter.com/dan_abramov/status/1641830612955803650)
-- [API Reference](https://react.dev/reference/react-dom/components/input)
-
-**Mark Erikson:** Okay, so the existing React Docs or the, I guess now the, the Legacy React Docs always had a page on forms. And the standard direction in that docs page was write controlled inputs where React is always in charge of pushing the current value of the input into the DOM. And your job is to provide, you know, here's what the current value should be and here's, you know, a, a callback that sets state and that went along with Reacts philosophy that, you know, the UI should always be based on the state. [30:42]
-
-And that made this idea of uncontrolled inputs, sort of like a, a very non idiomatic approach within the React ecosystem. Within the last few years, we've seen a little more acceptance of using uncontrolled inputs as being valid. The library React Hook Form, I believe, uses uncontrolled inputs and, Remix has been doing things with that as well. [31:08]
-
-So the new React docs are complete as far as the learning content, and they're basically complete as far as the API reference material, but they don't have a lot in the way of usage guide pages. There's a lot of pages that just simply need to be written from scratch for things like testing, and that includes forms. [31:29]
-
-There, there is no specific page on how to use forms in the new React docs. However, what I did not realize is that the API reference section actually has some pages on how to use specific HTML tag types in React. That includes the input tag and this reference page on using input tags actually talks about the difference between controlled and uncontrolled inputs, and basically recommends using uncontrolled inputs by default. [32:05]
-
-This is actually a really big shift in what the React team is suggesting people should do. And it there, I think there's a few different reasons for it. One is that, you know, setting up controlled inputs has always taken work. You have to have the useState, and the callbacks, and the value, and you're putting in the extra effort to make things consistent. [32:26]
-
-And then I think it also kind of ties into some of the React server components work that they're doing where they want to be able to pass form state back to the server processing. And I guess that seems to work a little better if the inputs are uncontrolled. So I, I have not even gone through this input docs page in detail. [32:47]
-
-I didn't realize the Docs page existed until I saw Dan tweet about it, and I definitely did not realize that the React team was shifting their recommendation there. So it's, it's definitely worth going through and trying to read that page and see what it has to say. And I don't know, like it, it's that shift in patterns and recommendations again. [33:05]
-
-**Carl Vitullo:** Yeah, I'm, I'm sort of ski- skimming that page while you're talking a little bit and. Yeah. One thing that jumps to my mind is the use case of trying to provide very, very high quality validation for input values, and it's been my experience that the browser doesn't expose very good primitives for validation. [33:27]
-
-I think at best you end up, you can do like, what, a regex based on the value? But you know, like especially if you need like some sort of dynamic validation. Like for instance, I've done password inputs when signing up that hit an API to see if the input password is too similar to, you know, publicly cracked password lists or otherwise perform some sort of processing that requires an async step, and going from an uncontrolled form to a form that has advanced validation, like that seems like a pretty big lift. [34:00]
-
-So I, I, I generally agree with the idea that you should lean on the platform as much as possible. We should not write JavaScript that duplicates behaviors that the browser gives us free. But yeah, there's definitely some, some gaps in what the browser offers around forms and validation. So that seems like it's gonna be a bit of a, a point of friction on an ongoing basis. [34:21]
-
-I guess one other thought I want to connect it to, I just had opportunity to see the React documentary again, and it was funny hearing, I can't remember the exact line, but somebody mentions that, nobody's ever written a form and React as of, you know, when it was being open sourced. [34:37]
-
-And so it's, it is funny to see now, yeah, no, actually 10 years later. Cause that was uh 2013. Forms in React is still a little bit of an open question. There still isn't complete guidance for what it should look like. [34:49]
-
-**Sebastien Lorber:** I think the, the thing is, maybe the shift happens because of Remix, because, you know, there, there's a lot more traction for progressive enhancement these days, thanks to Remix, I think, it existed before, but not much in React ecosystem. And to, to, to have a progressively enhanced form, you need it to work without React somehow. [35:10]
-
-So if you, if you make it, controlled, you are basically implementing features that will only work if JavaScript is there. So I think also this, this shift is happening because, because of progressive enhancement and the need for a form to be able to just work with HTML and a server somehow. [35:28]
-
-**Carl Vitullo:** Yeah, for sure. [35:30]
-
-Cool. Yeah. Sebastian. Wha- what's your next news article? [35:33]
-
-## Super Apps in React Native
-
-- [Super Apps in React Native](https://www.callstack.com/super-app-development)
-- [RN PS5](https://twitter.com/syke/status/1619413099861413889)
-
-**Sebastien Lorber:** Let me check. I don't remember. yeah, it's, Super App development. There is, a new resource from Gold Stack, the React Native company that is presenting the, the idea of Super App development. It's not the first time, but I saw that. I see blog posts of them, mentioning this idea, it's, the, the concept of Super App is quite popular in, in Asia. [35:57]
-
-For example, there is the WeChat app in China, I think. And the idea is that somehow you gather many, many small apps inside a big host app and your users, users are able to seamlessly transition from one app to the over. And, somehow it requires, some, a bit complicated things to, to, to set this up. [36:17]
-
-for example, you don't, you, I think you can't use the default React Native bundler. You have to use a repack, which is, somehow a layer above, webpack to make it work and have got spliting module federations and and advanced webpack features to make this work. So I, I don't know exactly how you set this up, but they, they provided a comprehensive resource with a step-by step, tutorial. [36:41]
-
-And there's also, a showcase repository that you can try so you can actually, build your super up locally and see it work live. And also, I thought there was something quite interesting, but I came across for some place that, I think, I'm not sure, but I think the PlayStation 5 UI is actually a super app built with React Native. [37:06]
-
-And, I will link a with, in the chat to show you why I think that, but, maybe I'm wrong. I don't know. I think it's, it's quite exciting to, to see that, first, React Native is running on PlayStation 5 and, that this is a super app maybe. [37:22]
-
-**Carl Vitullo:** Oh, interesting. Wait, PlayStation 5 UI is implemented and React Native? Is that what you said? [37:27]
-
-**Sebastien Lorber:** Yeah, actually I think they started to use React Native, already at, PlayStation 4, according to the comments. [37:35]
-
-**Carl Vitullo:** Oh wow. That's pretty cool. I didn't know that. Very nice. Yeah, the, the super app, as they describe it, I see that they have a comparison to micro front ends and definitely sounds a little bit similar, sort of a architecture around. Structuring an app. [37:50]
-
-**Sebastien Lorber:** This is, yeah, I think perhaps is the, the mobile term for micro front ends on the web. So it's exactly the same, I think, module federations and things like that. So, [38:00]
-
-**Carl Vitullo:** Yeah, it makes sense. And I think both of those are, or you know, my understanding of micro front ends is it's an architectural decision that is influenced by the size of the team, sort of a, it's maybe not desirable on its own. But in the context of a large company that has, you know, say 80 developers, 80, 100, 200 developers, all working on the same application, getting to a place where you aren't constantly stepping on each other's toes with merge conflicts, and it's just swapping out behavior of shared primitives all the time. [38:36]
-
-I think it— that's sort of the context where these super apps or micro front ends are really important and really, not just important, but kind of necessary for enabling that level of, collaboration. [38:47]
-
-**Sebastien Lorber:** Yeah I think, this is necessary. I think I, I had a case, at work a few years ago where, They wanted to, to build a, a very large application for, a big, company in France. And they wanted to so that each part of the app would be implemented by a different contracting team. basically, we all share the same dependencies, but there are like 10 teams from different companies working as a contractor for the client. [39:17]
-
-So this looks like a, a really good use case for, for using, this kind of, of architecture because, you know, otherwise it's, it's a big mess because you, someone in another team will upgrade a dependency and then you will have a. Really complex side effects for all the other teams and or everybody will, fight again each server to reject the responsibility for, for, for the bugs (laughter). [39:44]
-
-**Carl Vitullo:** Makes sense. Oh man. That's, having multiple different contracting agencies work on the same app. That's like an extra level to that. Because I imagine you need various Yeah. Controls to keep different people from accessing parts they're not authorized too. Yeah. Wow. [40:01]
-
-Cool. Yeah. Well, I'll kick us off with a lightning round. [40:03]
-
-## ⚡️ Core team layoffs
-
-- [Mengdi Chen](https://twitter.com/mengdi_en/status/1648718077796786177)
-- [Robert Balicki](https://twitter.com/StatisticsFTW/status/1648820621252653056)
-- [Matt Carroll](https://twitter.com/mattcarrollcode/status/1648770402272018432)
-- [Sean Keegan](https://twitter.com/DevRelSean/status/1649466893806215172)
-
-**Carl Vitullo:** Just a, a quick shout out that I think is nice to do. A number of core team members for React and, you know, the surrounding ecosystem were hit by layoffs at Meta. Just a, you know, poor run out for our, for our Lost Friends. [40:18]
-
-Just looks like it was a, among others. This is the list that I am aware of top of mind. [40:24]
-
-Mengdi Chen from the React Dev Tools. Robert Balicky from Relay. Matt Carroll doing devrel for React, and Sean Keegan also doing devrel. Yeah, layoffs, they suck, but also seeing Tom Occhino and Dominic Gannaway joined Vercel. So more, you know, legendary React figures moving over there. A lot of, lot of churn going on team right now. [40:47]
-
-## ⚡️ React Miami
-
-**Mark Erikson:** React Miami was this last week and it was an amazingly well done conference. Both Carl and I were there. I, I got to speak. It was excellent, organized. The rest of the speakers were wonderful. The atmosphere was amazing and I got to spend a lot of time talking to, you know, both people that I know from online, from the conference circuit, but also just talking to lots of, you know, sort of lots of random people who are working in different jobs, solving different problems. [41:14]
-
-It was just a wonderful experience. [41:16]
-
-**Carl Vitullo:** Echoing that, absolutely amazing. [41:19]
-
-Cool. Yeah. Sebastian, you got a lightning round link. [41:21]
-
-## ⚡️ react-three offscreen
-
-- [⚡️ react-three offscreen](https://github.com/pmndrs/react-three-offscreen)
-
-**Sebastien Lorber:** I just wanted to mention, react-three offscreen. The idea is that, you use a react-three fiber to run the three descents. And now it supports to be, to run inside a web worker. So basically you, you use something, a standard web API called Offscreen Canvas and it permits to, to draw inside the web worker. [41:45]
-
-So basically you run down your three design inside another thread, and it doesn't block your UI thread. So, It's quite interesting for performance reasons because you can integrate, complex, 3D animations and it doesn't block the, the rest of your website. So I think it's interesting to, to use. [42:04]
-
-## ⚡️ Lingui v4.0
-
-- [⚡️ Lingui v4.0](https://github.com/lingui/js-lingui/releases/tag/v4.0.0)
-
-**Carl Vitullo:** Very cool. I'll take next Lingui 4.0. I've used Lingui in the past, it's a internationalization framework. I've tried a couple of different internationalization frameworks and wasn't super happy with them, but Lingui actually worked pretty reliably, when I did need to use it. So just shout, shouting them out. New major release. [42:24]
-
-**Sebastien Lorber:** Yeah, actually I'm, I'm in touch with the, the guy, that sent me this link for just today, and I, I asked him to, To write a blog post and maybe we will feature it better in the newsletter next week because, I think may, it looks interesting. It looks like a bit react-intl, but, provides some additional, developer experience on top of it. [42:48]
-
-I think, I mean it's not, a layer on top of, react-intl, but it's quite similar. It's using the ICU message syntax and, quite similar features, like the ability to extract the translation from the cloud and things like that. So I think they will, they will write a blog post to present better this new release quite soon. [43:10]
-
-**Carl Vitullo:** Cool. Yeah. Maybe we can go go in more in depth next month. [43:13]
-
-**Sebastien Lorber:** Yeah. [43:14]
-
-## ⚡️ Redux Toolkit 2.0 alpha
-
-- [⚡️ Redux Toolkit 2.0 alpha](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-alpha.5)
-
-**Mark Erikson:** I've got a, I've got a semi self plug. So we've been working on the Redux Toolkit 2.0 Alphas, and we're currently on 2.0 Alpha five. The RTK 2.0 is working on improving our ESM common JS package formatting, modernizing the JavaScript output and. We're moving a few bits of deprecated options and APIs and generally trying to make things faster. [43:40]
-
-we've also got a couple new features in there, so they're tagged as Alpha because we're still working on changing a bunch things, but the code that's in there is stable and we'd really encourage folks to try out the Alphas and give us feedback like, does this work in your app? Does it accidentally break anything? [43:56]
-
-The current Alphas have Emerton final in there, so you get some of the speed benefits that I was talking about earlier, and then something that I hope will end up as part of RTK 2.0. Final. I've been experimenting with a couple new memorization options for the Reselect library. One of them is very inspired by what the Ember folks have done with auto tracking field accesses. [44:21]
-
-So the idea is that. It knows exactly what fields you're accessing and only recalculates the select results if those fields got changed and not other fields. There's also another one that I was playing around with that is basically a direct copy paste from a React internal cash implementation that uses weak maps to track arguments. [44:42]
-
-Right now none of that is released. I have a PR up over in the reselect repo that has like the initial, like "I've been hacking on this and it sort of seems to work" graphs, so I'm hoping to go back and work on that further. Assuming those work out, they will either go into Reselect 4.2 or Reselect 5.0 depending on what I feel like. [45:04]
-
-And then one way or another that the new version of Reselect would get included in RTK 2.0. So trying to find ways to make things better. [45:13]
-
-## ⚡️ Netlify framework popularity
-
-- [⚡️ Netlify framework popularity](https://www.netlify.com/blog/framework-popularity-on-netlify/)
-
-**Carl Vitullo:** Cool. Heck yeah. Yeah. well I saw the framework popularity on Netflix, or Netlify blog post. Definitely pretty interesting data to look at. They broke it down by free sites, paid sites, and enterprise sites. Just a couple of notable, I'll, I'll call out, Create React App Next, and Gatsby, I think those were, Some of the interesting results. [45:34]
-
-So free sites, 40% of them were using Create React App that goes down to 23% if you just go by paid sites and all the way down to 18 if you're looking at Enterprise. So yeah, Next, and Gatsby were 2 and 3. Those are pretty reliably the top three, and Next only gets more popular as you go up in price scheme. [45:56]
-
-Yeah, I thought it was a pretty interesting bit of data to look at. Definitely impressive to see how well Next is doing. Although, you know, one thing I was surprised to see missing here was Remix, but I guess they don't really support so much of a static export, and that's kind of Netlify's bread and butter. [46:14]
-
-**Sebastien Lorber:** There is a Remix adaptor for Netlify, I think, but, yeah, it's always complicated to, to market another platform, then, when it's not maybe the first class to support and, [46:27]
-
-**Carl Vitullo:** Yeah, sure. [46:28]
-
-**Sebastien Lorber:** Although was happy to, to find out that, Docusaurus, has a 4%, share in the enterprise site. So this is, there are more Docusaurus sites on Netlify than, Remix sites on, on Netlify. [46:43]
-
-**Carl Vitullo:** Oh, funny. [46:44]
-
-**Mark Erikson:** I think the other interesting takeaway there is the popularity of Create React App in, in those categories, which, you know, kind of goes to the difference between like the, the chatter on Twitter and, you know, all the, the emphasis from the React team we've seen versus, well, okay, here's how stuff is actually being used in the real world at the moment. [47:02]
-
-**Carl Vitullo:** Right. Hobbyists versus professional maybe. [47:06]
-
-Yeah. Cool. mark, anything else you wanna call out? [47:09]
-
-## ⚡️ PartyKit
-
-- [⚡️ PartyKit](https://github.com/partykit/partykit)
-
-**Mark Erikson:** One other little item. So Sunil Pai, who's a former member of the React Team and has been revolved in the re in the React ecosystem for many years, has been doing a startup called Party Kit where he's building infrastructure for real-time multi-player applications. You know, the, the kind of thing where you see like 30 different people interacting with the same whiteboard simultaneously, and he just open sourced the party kit repo at React Miami. [47:39]
-
-I know it's a thing he was very, very excited about and I haven't had, again, haven't had a chance to play with it, but it looks really cool. [47:48]
-
-**Carl Vitullo:** Yeah, agreed on all counts. I haven't played with it yet, but I've been following development because Sunil Pai is just such a, such a great person. I really enjoy… we, we had him on for an event, talking about rewrites, and he's just such a, thoughtful and kind person. I, you know, I'm gonna be rooting for him, in anything he does. Ha. [48:07]
-
-**Sebastien Lorber:** Yeah (chuckles). [48:09]
-
-**Carl Vitullo:** Cool. Okay, everyone, thank you so much for joining us for this April edition of This Month In React. I hope, I hope you learned something. I hope that you felt like we're helping you stay on top of the React ecosystem. There's always a lot going on, so hopefully we can bring some clarity. [48:22]
-
-Mark and Sebastian, thank you so much for talking with us. [48:25]
-
-**Mark Erikson:** Yep. Always. [48:26]
-
-**Sebastien Lorber:** Thank you, and see you next, next month. [48:28]
-
-**Carl Vitullo:** Yeah, see you next month. Awesome. Thanks so much. see you guys later. [48:33]
-
-**Sebastien Lorber:** Bye.
diff --git a/src/transcripts/tmir-august-2023.md b/src/transcripts/tmir-august-2023.md
deleted file mode 100644
index b20628c..0000000
--- a/src/transcripts/tmir-august-2023.md
+++ /dev/null
@@ -1,423 +0,0 @@
----
-title: This Month in React (August 2023)
-date: 2023-08-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-Concurrent Mode, Remix DevTools, included SourceMaps, new Expo features
-
-- [Spotify](https://open.spotify.com/episode/2ScNpUkv8QRYXaniMnfpWT?si=yF2SwwsRTGmvAFcl_Wsq_w)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/this-month-in-react-august-2023/id1661733526?i=1000626488343)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [Or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux/episodes/This-Month-in-React--August-2023-e28qasn/a-aaaa1f1)
-
-
-
-- Gatsby's growth and development seems to be stagnating as Jamstack has fallen out of favor compared to Next.js.
-- React's stubborn incompatibility with Web Components is frustrating but may be more of an indictment of Web Components' limitations.
-- CSS-in-JS causes fragmentation across environments like client vs server rendering, so the React ecosystem is moving away from it. Differences in tradeoffs between browser and mobile environments make it a difficult problem.
-- New devtools have been released for React Server Components and Remix that help inspect behavior on client and server. Good devtools are a huge force multiplier.
-- Publishing libraries with proper ESModules support is still very challenging and undocumented. Deno may help smooth the process.
-- React production builds now have sourcemaps thanks to impressive work by Mark Erikson! This will massively help debugging libraries like React in production.
-- Official React + TypeScript documentation has finally landed. Orta did a great job with it.
-- Try out new versions of Redux Toolkit and React-Redux in beta. Provide feedback!
-- Expo had a big release week with improvements to builds, updates, SQLite, CLI plugins, and more as React Native marches forward.
-
-Links used:
-
-- [Is Gatsby Dead?](https://twitter.com/sebastienlorber/status/1694392101281190224)
-- [https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/](https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/)
-- [https://www.spicyweb.dev/farewell-jamstack/](https://www.spicyweb.dev/farewell-jamstack/)
-- [Things you forgot (or never knew) because of React](https://joshcollinsworth.com/blog/antiquated-react)
-- RSC Devtools
- - [RSC Devtools - Chrome Extension](https://chrome.google.com/webstore/detail/rsc-devtools/jcejahepddjnppkhomnidalpnnnemomn)
- - [Devtools for React Server Components](https://www.alvar.dev/blog/creating-devtools-for-react-server-components)
-- [My Experience Modernizing Packages to ESM](https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/)
-- [Remix Dev Tools v2.0 - New settings tab](https://github.com/Code-Forge-Net/Remix-Dev-Tools/releases/tag/v2.0.0)
-- [Everything I wish I knew before moving 50,000 lines of code to React Server](https://www.mux.com/blog/what-are-react-server-components)
-- Expo
- - [Expo Preview - Fully customizable builds on EAS Build](https://expo.dev/changelog/2023/08-10-custom-builds)
- - [Expo Proof of concept - expo-sqlite integration with CR-SQLite](https://expo.dev/changelog/2023/08-10-cr-sqlite)
- - [Expo Proof of concept - Expo CLI Dev Tools Plugins](https://expo.dev/changelog/2023/08-10-dev-tools-plugins)
-- [Feature Preview: Single Sign-On (SSO)](https://blog.expo.dev/feature-preview-single-sign-on-sso-9c1a7d50c1a9)
-- [Feature Preview: Rollouts for EAS Update](https://blog.expo.dev/feature-preview-rollouts-for-eas-update-4eac28596470)
-- [useUpdates() API for expo-updates](https://expo.dev/changelog/2023/08-08-use-updates-api)
-- [Expo Orbit: Download and launch builds](https://expo.dev/changelog/2023/08-09-orbit)[Components](https://www.mux.com/blog/what-are-react-server-components)
-- ⚡Lightning⚡
- - [React prod sourcemaps](https://github.com/markerikson/react-prod-sourcemaps)
- - [PR to React](https://github.com/facebook/react/pull/26446)
- - [React.dev - Using TypeScript](https://react.dev/learn/typescript)
- - [RTK 2.0 beta](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-beta.0), and [React-Redux 9.0 alpha](https://github.com/reduxjs/react-redux/releases/tag/v9.0.0-alpha.0)
- - [The underlying mechanisms of React’s concurrent mode](https://andreigatej.dev/blog/the-underlying-mechanisms-of-reacts-concurrent-mode/)
- - [React Jam - Summer 2023 Winners](https://reactjam.com/summer-2023-winners)
-
-[00:00] **Carl Vitullo:** Hello, everyone. Thank you for joining us again for This Month in React, where we digest and discuss the latest developments in the ever evolving React and web ecosystem. Right now I've got myself the community manager of sorts for Reactiflux, and Mark Erikson. Mark, you want to introduce yourself?
-
-[00:20] **Mark Erikson:** My day job is working at Replay.io where we're building a true time traveling debugger for JavaScript. If you haven't seen it, please check it out. And in my copious amounts of free time, I work on various Redux related projects.
-
-[00:33] **Carl Vitullo:** Various projects. Yeah, that's almost understating it. Cool. Yeah, uh, we usually have Sebastian Lorber as well, but um, He's not here yet. So let's go ahead and jump in I guess.
-
-[00:44] My first link that I wanted to discuss is, Is Gatsby Dead, uh, which here is a tweet from Sebastian with a screenshot, uh of mid August, Fred Schott. " Notice that there have been zero commits to the Gatsby repo in the last 24 days." Which, for a thriving open source project, that's not a great statistic.
-
-[01:07] I know it was acquired by Netlify earlier this year, this year. Um, and yeah, there's been a lot of discussion around Gatsby as a project, I guess, and where it's headed. yeah, I don't know, Mark, any, any, any thoughts on Gatsby's status?
-
-[01:26] **Mark Erikson:** So my first caveat was I never had a chance to use it myself, but just kind of eyeballing bits and pieces, it certainly felt like next has been eating into Gatsby's, uh, market share and mind share over the last year or two, um, both due to complexities around trying to manage.
-
-[01:45] Build times and graph QL setups and whatnot with Gatsby as well as, you know, sort of the evolving ecosystem consensus that next is sort of the default way to build React apps for better or for worse. And so I'd certainly gotten the vague sense that Gatsby has been sort of kind of falling out of favor over time.
-
-[02:08] And I don't know, like, anytime I see any product get acquired by a bigger company, you just have that sense that, well, it was nice knowing you, uh, like, sooner or later it's dead. And especially when that involves, you know, companies with. VC backing and it feels like Netlify itself has been struggling a bit and on the downswing.
-
-[02:32] And so the fact that they bought Gatsby and then don't seem to be doing much with it certainly suggests to me that it's, it's basically dead at this point.
-
-[02:42] **Carl Vitullo:** And dead is always, you know, what, what does dead mean is always, uh, an open question, you know, because Gatsby still works. It's an open source, you know, self hosted product for the most part, or project, I guess, for the most part.
-
-[02:55] So yeah, I have used Gatsby on a couple of relatively large projects. I used it for my personal website. I used it for a marketing website at a previous company, which actually it ended up getting replaced by Webflow. and I, used it again on a large documentation site, which again has now been replaced by Docusaurus.
-
-[03:15] So I think that's, I think that that's kind of the the pattern I've observed is, you know, maybe four years ago, there was a lot of energy around using Gatsby, and there's a lot of excitement for it. But at least, you know, my experience was I tried to use it for some relatively large projects and stakeholders weren't super into it.
-
-[03:34] The marketing and content folk didn't really jive with the experience of authoring content. The deployment story was a little bit hairy, uh, just ended up with a lot of funky little breakages every now and again, that were a little bit tricky to debug though. I don't know.
-
-[03:52] Yeah, I, I echo your sentiments on being a VC backed company, acquire an open source project. There's always a bit of a squinty eyed skepticism. Like, where's this going?
-
-[04:04] **Mark Erikson:** Well, I mean, on top of that, they're, they're both VC backed projects. I mean, Netlify itself, even though we can probably think of it as being a relatively stable company has a whole bunch of VC backing. And Gatsby is an actual company with VC backing different sizes.
-
-[04:21] **Carl Vitullo:** You know, I, I did see that there, you know, the official Gatsby account did reply to that tweet thread we're discussing and they said, "fear not Gatsby is vital to many, to a great many of our customers updates to React 18 and Gatsby adapters are the most imminent updates, but we're also busy investing in platform primitives for a stronger Gatsby JS and other frameworks too," I don't know, they're saying it's not dead, but I, I would agree with you on the, you know, sort of the vibes I've been picking up with.
-
-[04:47] Netlify invested really hard in Jamstack and the client, you know, client side applications. And those have kind of gone out of vogue a little bit, but yeah, I guess we'll have to see what happens. I did actually connect with some Gatsby folks after Reactathon a couple of weeks ago, maybe eight weeks ago, um, about maybe doing some community work with them and they said, what I heard back was decisions are being made and we'll see what, what happens there.
-
-[05:14] So, I don't know, have to see, have to see how it shakes out, but not looking super great for Gatsby as a, the growth trajectory of Gatsby is not looking super great to me.
-
-[05:24] **Mark Erikson:** So, so you mentioned Jamstack, and I actually, I know I saw a couple articles, and I'm trying to bring up some links at the moment, uh, that very recently were talking about how the term Jamstack feels like it's either, it's also either dead, or at least has just sort of become so vague and nebulous it doesn't have a specific meaning.
-
-[05:48] Again, this is not my area of expertise, but seeing that discussion and knowing how much Netlify had tried to orient themselves around the term JAMstack, and as well as Gatsby, also suggests that the ecosystem has shifted enough that it You know, kind of points away from Gatsby as a Gatsby still usable.
-
-[06:12] Obviously, it's just not where the mindset is at this point.
-
-[06:15] **Carl Vitullo:** Definitely. It feels like the zeitgeist of Web and React has expanded beyond what Gatsby offers. Well, and what Jamstack was oriented around. Definitely.
-
-[06:27] Cool. Uh, you want to take us on our next link?
-
-## [06:30] Things You Forgot or Never Knew Because of React
-
-[06:30] **Mark Erikson:** So there's been a whole sub genre of blog articles over the last few years with people going off on rants about act is an awful library.
-
-[06:42] The people behind React are trying to sell you something that is, that is misleading. " React is horrible for web performance." And these articles are usually fairly well written. I don't generally agree with them, but it is a useful set of counterpoints to, you know, kind of our own little bubble that we have.
-
-[07:04] Alex Russell, uh, formerly of Google, now Microsoft, has written a number of articles along those lines. Um, a lot of folks who are very involved in the web components community have written articles along those lines. And so there was another article of that type that came out a few weeks ago called Things You Forgot or Never Knew Because of React.
-
-[07:26] And it's, it's a long article, um, I, I won't try to cover all the points that it makes, but it's, it's worth reading at a minimum to get kind of like an alternate perspective. On how does React fit in with the rest of the web development ecosystem? What are pain points that other people see looking at react?
-
-[07:47] Um, what are some of the lessons that we in the React develop the developer community have internalized that maybe are worth a rethought? And include some things like, um, "hooks as excited as we all were when they came out. Well, now we've now there are things like, and observables and other ways of managing data flow.
-
-[08:09] The end. So the post argues that, you know, they're faster and easier to work with. Actually, yeah, okay, this, this is a good, good one. There's a bullet point that says "nobody else is afraid of their frameworks version of useEffect." Okay, that, that's, that's probably the one point in this article I agree with the most.
-
-[08:26] You know, it argues that, you know, two way data binding, which is something that we, we in the React community have always argued against because control components, even though similar, are somehow better. It argues that two way data binding is not a thing that you should be afraid of, and, you know, goes on and lists a whole bunch of other different competing frameworks and suggests that you should look at them - affect my own personal view of React, but it's always good to kind of get that, you know, that alternate viewpoint of what are some of the strengths and weaknesses of tools and make considerations from there.
-
-[09:00] **Carl Vitullo:** I think, I think what you said about, you know, people shouldn't be afraid of two way binding. That doesn't really jive with my personal experience of using two way binding, which is that it was scary. It was difficult to debug. I didn't find it a pleasant, you know, experience for authoring code. So, I don't know, somebody else telling me, "oh, don't be afraid of it, it's fine."
-
-[09:19] It's like, well, I'm afraid of it because it was, Very painful for me in the times when I used it professionally for, you know, two years before I used React. Um, so, that did not resonate with me very strongly.
-
-[09:34] **Mark Erikson:** I'd have to go back and re read that section of the post, but I do sort of feel like programming paradigms come and go and come again and go again.
-
-[09:45] Everything's in a circle and nothing's new. But I do, I feel like there is a little bit of a sense of people forgetting why shifts in paradigms were made in the first place, you know, people getting into React today don't actually know what it was like to use Backbon or Angular 1. And so they don't understand the pain points and why React was such a big deal and so exciting when it first came out because they didn't.
-
-[10:15] Feel that pain. Now it's just, we've always had React. It's always quote unquote, "been the default", and yeah, like back that, for example, an Angular one template could mutate arbitrary data, you know, deeply nested from within a JS nested in an HTML template string, that was really hard to debug and keep track of.
-
-[10:38] And so I think, I think that's where a lot of the concern about two way data binding actually came from in the first place and we all sort of internalized and repeated this phrase and now no one remembers why we did, why did we have that concern to start with?
-
-[10:53] **Carl Vitullo:** Yeah, I, I definitely agree with that. If that reminds me of a, a line from the post where they talked about React being tech from 2013 designed for 2008 constraints, which I don't a hundred percent agree with.
-
-[11:07] But I do think it's, it's not, you know, wildly off base. I think it's, you know, there were, there were a lot of things that React was developed around that were trying to patch over issues with the platform, you know, compatibility and whatever. But, um, Yeah, I don't think that's quite accurate. I pulled out a couple of quotes that were thought provoking for me.
-
-[11:30] One of the lines was, um, "React has trained us that packages need to be built specifically for our framework," which I think I don't know if that's on React. I think that is just kind of the general trend for people. You know, if you're I'm using X framework, I would like to get something that is tailor made for my situation.
-
-[11:50] And so I'm going to look for an SDK that was built for this tool in this setting. And I do agree with the idea that it's not good to require that all the tools we use be built, you know, to be specifically cross compatible with each other. You know, it's fine to use a general purpose library in React. It doesn't need to be hooks specific.
-
-[12:13] So, yeah, I thought that was at least a decent point.
-
-[12:16] **Mark Erikson:** Have we forgotten how many jQuery plugin adapters there were?
-
-[12:20] **Carl Vitullo:** Right. There were some, yeah, right. So I, you know, I don't think that is a React problem. I think that it has been very visible in React because React, you know, as this post says is, it's the default.
-
-[12:34] Lots of people use it. And so when lots of people use it, then all of the problems that happen when any large group of people do something become very, you know, that becomes the problems of that framework that in that context. So.
-
-[12:47] **Mark Erikson:** there, there's an XKCD out there. Uh, Ooh, I think I found it. The cartoonist points out that when you're, like, when your map basically resembles a map of the population, it's not actually telling you anything useful. And so I think there is just a little bit of that with the React community, because React is so big, you sort of have a natural full distribution of...
-
-[13:12] People and situations and problems. So to be clear, like I'm, I'm not, I'm not saying that, you know, this, this original, you know, what's wrong with React article is wrong. I think it actually makes a lot of very, very good points. There, there is a little bit of a sense in which some, and some of the complaints are simply because there are so many people using React in so many ways.
-
-[13:33] **Carl Vitullo:** Right. You know, people have a lot of problems with React because there are so many people using React and they've really felt out every every possible base and edge case where you can't hit problems. Um, there are a couple of the quotes that I wanted to highlight. I think, uh, "no other modern front end framework as a stubbornly incompatible with the platform as React."
-
-[13:54] I, you know, I don't know if I disagree with that specifically, but I also think it's a little bit. It ignores the fact that no other framework attempts to be as broadly cross compatible as React. Like, you know, there's not Angular Native, there's not Vue Native. So it's, a recurring criticism of React has been incompatibility with, uh, Web Components.
-
-[14:14] And, you know, okay, sure, it's not very compatible with Web Components, but... You could argue that that's kind of a web component problem, because if React is, has successfully solved, you know, has been found to be a valuable tool for web, native, you know, mobile, desktop native, you know, all of these different contexts, like maybe it's inability to use web components is more of an indictment of web components ability to solve a problem.
-
-[14:41] **Mark Erikson:** yeah, the, the whole React and web components thing is its own very complicated topic from the off the top of my head. My general understanding is number 1, you can render web component tags from a React component, but you lose some of the, some of the back and forth and being able to pass in props correctly.
-
-[15:00] Some of that is because there's some kind of a difference between properties and attributes in web components and you can't just pass in plain objects as props the way you would from one React component to another. The React team had not prioritized trying to implement better compatibility because they had a lot of other things they were worrying about.
-
-[15:24] They kind of asked for some directions from the community. To say, look, there's like four different ways we could try to handle this, you know, handle passing the data back and forth, which one do Web Components experts think is the right option? And there were arguments back and forth for years without the web component community actually settling on a consensus for the best way to pass stuff in.
-
-[15:50] And so where things stand now, as far as I know, is someone actually has implemented quote unquote "proper compatibility" for web components in React. It's in a branch. It's either, it's either not merged or it's merged behind a feature flag and they intend to release it officially whenever React 19 comes out or like it's enough of a shift, they don't want to do it in a minor version.
-
-[16:19] So the work has been done. React's versioning strategy is totally messed up at the moment.
-
-[16:24] **Carl Vitullo:** (Chuckles) Sure. Right.
-
-[16:26] **Mark Erikson:** So it's it's multiple factors. It's React knows how to compose and web components don't. There were questions about how React should compose with web components and people and. People who cared about that stuff couldn't agree on the right way to do it and then work has been done.
-
-[16:43] React hasn't been released because focused on server side stuff and not actually shipping major versions right now.
-
-[16:52] **Carl Vitullo:** Yeah, right. They've been just maybe not top priority for them right now, which, um, yeah, I, I want to, I want to run through a couple of other quotes here that I thought were good to. I don't know, rebut, discuss.
-
-[17:04] "The worry that a front end framework might not scale is as old as jQuery and should be considered just as antiquated in relation to modern web development." That's talking about, I think, both performance and maintainability in terms of scaling. And, ooh, I do not agree with that. I don't agree that it is an antiquated idea.
-
-[17:22] Definitely there are patterns that do or do not scale very well. Um, and I think React tends to be better than average at that. Um, so like with regards to code isolation and refactorability, you know, you can certainly build things that are difficult to maintain and difficult to swap out.
-
-[17:41] But I do think React does a decent, in my opinion, better than average job of that compared to other modern frameworks. So, I don't know, just hand waving away like, "you don't need to think about scaling anymore." I don't agree with that. Sorry, buddy.
-
-[17:54] And another one. "Styling is a solved problem in several other frameworks." I'm grimacing here for those who don't are watching the camera. Um, I don't agree with that. I think, you know, okay, yes, we there has been a lot of churn on styling as something you need to do in the React world. You know, CSS in JS. Plain CSS, less or sass, okay, sure, I think now we've moved away from CSS in JS as a good idea because it has, you know, I think, I feel like the zeitgeist has moved towards, there are too many trade offs, too many negative trade offs on doing CSS in JS.
-
-[18:30] But to call it a solved problem, ooh, no, I don't, I disagree with that. Cool. Any other thoughts you want to add there?
-
-[18:36] **Mark Erikson:** Not immediately.
-
-[18:38] **Carl Vitullo:** I'll, I'll take us on to our next link. Oh, yeah. Orta here in the comments, CSS in JS is good for other platforms. That's extremely true. It is, you know, if, if your platform doesn't support CSS, then you got to find something else for it.
-
-[18:50] So that's why it's not a solved problem. I don't, yeah. (Laughs) But yeah, moving on here.
-
-## [18:57] React Server Components DevTools
-
-[18:57] **Carl Vitullo:** Uh, somebody has published a dev tools for React server components extension. I'm pretty, I think this is pretty cool. This is... maybe a first effort. This is looking, you know, I look at the, uh, the user interface of it and it looks like it breaks down... it looks like it's largely a reverse engineering of the data being streamed in, uh, sort of converting the JSON markup into pseudo HTML so that you can review it as a human a little more easily. And as well as, they call it time travel, but I think it's just kind of a log of data being sent. Looks super useful, looks a lot better than crawling the network tab to me.
-
-[19:36] **Mark Erikson:** I am always interested in newer or better developer tools. I think the fact that the React dev tools exist was one of the huge reasons to even consider picking React early on and been done on them over the years is incredible. So it's actually a little surprising to me that the React team itself hadn't prioritized trying to build tool some some form of dev tools integration for server components and that it took someone from the community trying to give it a shot.
-
-[20:10] I've said it, I've said it a number of times before, I know the React team had, like, despite all the corporate backing, has a limited number of people and a limited amount of engineering effort, but I really, really would have expected them to have put some serious planning and effort to building out DevTools support for server components.
-
-[20:28] For that matter, I know that Facebook has not been putting a lot of engineering hours into improving the existing DevTools lately. I think they had a couple engineers, Brian Vaughn, who used to do a lot of that work, left a year and a half ago and now works with me at Replay. There were one or two people working on the React DevTools code.
-
-[20:51] In the React repository, one of those people was laid off recently and so that like, I've seen a couple maintenance level PRS, but I don't think a lot of effort is going into improving the reactive tools right now. And, you know, the good news is like the, the reactive tools are there and they work, but I know Brian had a lot of ideas for improving them down the road and who knows if, or when those will happen.
-
-[21:17] So I'm actually genuinely not sure if or when we'll get official React server components integration into the React DevTools.
-
-[21:26] **Carl Vitullo:** Sure, yeah, that makes sense. Yeah, as someone who works on DevTools professionally, do you know if, I know Replay is a general purpose DevTool more on the browser than on any specific framework, but do you know if there's any interest in, I don't know, tapping into some of these internals like that on the Replay side?
-
-[21:45] **Mark Erikson:** We would love to. Um, you know, semi sales pitch time for the moment. Um, so, as I said earlier, Replay is a time traveling debugger for JavaScript. We we have you record yourself using your website with our modified Firefox or chrome for a couple of minutes, and then you can debug the recording and it's like a DVR, like, You can jump anywhere in time within that recording, see every line of code that executed, and it really simplifies, trying to dig into what happened and understand bugs.
-
-[22:19] So, right now, we have Replay integration with the React DevTools. Um, besides just like you can record any website written with anything, like it just records the JavaScript that ran. But if the site that you're recording was built with React, we can capture all the React related data. And I've actually built a lot of this integration myself.
-
-[22:44] So we can show the React component tree and in the React DevTools UI at any point in time. And we've done that because number one, we use React ourselves. Replay is a React app, two, React is the biggest framework. So it makes sense to build features for, you know, the largest target audience. We would like to build more integrations with more frameworks over time, like view angular, well, solid, you know, maybe something special for Apollo and GraphQL.
-
-[23:19] we, we would love to build these things. We, we just, we're a very small team right now and we have limited engineering time and way too many things to do, but longterm, we would love to have integrations for all the major frameworks out there so that if you make a Replay recording of a website built with one of those frameworks, you'll get.
-
-[23:38] You know, extra special visibility into what happened for sure.
-
-[23:42] **Carl Vitullo:** Yeah. I mean, developer tools, developer experience. That's a huge force multiplier. All right. You want to take us on our next link?
-
-## [23:49] My (Mark's) Experience Modernizing Packages to ESM
-
-[23:49] **Mark Erikson:** Yes. So, uh, continuing the self plug here, earlier this month, I wrote a very long blog post entitled my experience, modernizing packages to ESM.
-
-[24:01] This was kind of the story of all the shenanigans I've had to go through this year, trying to update the Redux related packages to have proper ES module compatibility, whatever the heck that means. And I'll be honest, like, it has been an extremely painful and frustrating effort and year trying to do that.
-
-[24:23] And I've learned a lot. There's a lot of things I wish I hadn't had to learn. And I'm still not done. I am still messing with this stuff, even within the last week, I was trying to work on these things. And normally when I write these blog posts, I try to write them to say, Here's all the stuff I've learned, and here are the correct answers that I've learned.
-
-[24:44] And in this case... It's more of a, here's all the places I've banged my head against the wall, trying to figure things out. I still don't know the correct answers, but at least describing the stuff that I've gone through will hopefully benefit other people who are trying to deal with the same things.
-
-[25:03] When I, when I write blog posts. I usually have a decent sense of how popular they might get, you know, I'm not trying to optimize for page views, but you know, like my posts on React rendering or Redux versus context. Okay, like, it's very obvious people are going to have a, an interest in those. I really did not expect a lot of people to be interested in a post about how to publish libraries correctly, but it's actually gotten a fair amount of attention.
-
-[25:29] And there's been a lot of other folks who are, you know, building libraries who have, you know, replied or messaged or talked to me and said, "Oh, yeah, like, I'm running into the exact same problems myself", or "I totally sympathize and understand with all the different pain points you've gone through."
-
-[25:46] So, you know, there are a bunch of different factors, um, trying to define the package export setup is really hard. Trying to figure out what file formats and whether you do you pre bundle your JavaScript, do you pre bundle your TypeScript types? What about file extensions? Um, but then another complicating factor has been React server components. You know, it turns out that you can't do things like even, you know, importing and using React hooks in a server components environment.
-
-[26:16] Which makes it really hard for libraries like Apollo and RTK Query that can be mixed mode. Like they have a plain JavaScript aspect, but they also have a React Hooks aspect. And normally you would be able to use that on both sides. But now, you know, Next is throwing errors automatically if you even try to import. React hooks, it's doing static analysis.
-
-[26:44] And so for us as library maintainers, trying to figure out like, how do we ship packages that are going to work without just exploding yet another environment has been really, really hard.
-
-[26:58] **Carl Vitullo:** Yeah, I don't have a lot to add there as someone who doesn't maintain any major libraries, but yeah, my, my, my outsider perspective has been that it was already quite difficult to support, you know, ES modules versus CommonJS versus, you know, like, I don't know if Bower is still something that needs to be actively supported.
-
-[27:20] **Mark Erikson:** One of the questions I had was, you know, should I still be shipping UMD modules to support like the, the script tag in a Codepen use case? And I, you know, I, I finally settled on, eh, probably not, but let's ship an additional ES module file that has been pre compiled to production usage. You could do a script tag type equals module and use it as an ESM module in the browser.
-
-[27:49] **Carl Vitullo:** Oh, sure. Oh, yeah. Interesting. I guess that was one use case that ES modules has been meant to replace. So, okay. Interesting that that has maybe come to fruition now. Interesting. Pulling a comment from chat. "I still ship UMD more often than ESM for my own use cases. It's a big learning curve." Definitely big learning curve is definitely maybe an understatement.
-
-[28:12] **Mark Erikson:** Yeah, one of my biggest complaints is that there is no single authoritative comprehensive guide to how to correctly publish a library with all the tools and settings and correct file formats and stuff that you should include. So everyone's just sort of figuring this out for themselves and borrowing from everyone else.
-
-[28:30] **Carl Vitullo:** Yeah, actually, even, you know, you're saying there's no comprehensive guide on how to do it. There's not, I don't even think there's a comprehensive guide on what environments are out there, you know? Like, what do you even need to think about supporting? Yeah, that's interesting.
-
-[28:43] **Mark Erikson:** I mean, that was, that was part of the point of my post.
-
-[28:48] Was, like, literally, like, here's all the stuff that I'm having to consider.
-
-[28:52] **Carl Vitullo:** Yeah, Orta with the good chat comments here. "Most recent strategy has been use Deno." I've, that is not the first time I've heard use Deno as a good strategy for publishing a library. I've heard that it has made local development, or rather it's made the transition from local development to usable package published to the, uh, to the npm just easier to do.
-
-[29:16] Um, and it's not something I've tried, but yeah, that's been an interesting thought that's been lodged in the back of my brain just using a different environment that makes it easier to do the right thing, even in other environments. That's interesting.
-
-## [29:31] Remix DevTools
-
-[29:31] **Carl Vitullo:** Well, I'll, I'll move us on here. I think, yeah, one more dev tools update the.
-
-[29:37] Remix DevTools has a new release this month, uh, 2. 0. Um, I, I have not used this yet, uh, but I do, I, I have a couple of Remix projects, Remix based projects. So, um, I'll have to poke around here and see what kind of stuff it adds.
-
-[29:54] Looks like it gives you better inspectability of like your routes and your pages. Um, so yeah, the. I think debugging got more complicated with the, you know, server client, I don't know, seem in between there. So the value of platforms or the value of framework specific developer tools has gone up a lot more with that. You know, how do you have something that's aware of the server as well as the client and can tell you more information about what all is going on there?
-
-[30:24] So yeah, remix developer tools 2. 0 something to check out.
-
-[30:28] **Mark Erikson:** Yeah, Jessica Sac hs actually recently sent me a link to a demo video for the, the, the Nuxt framework and like it, you know, it's a Vue based equivalent to Next, roughly, and it apparently has some kind of a dev tools plug in that looks pretty similar to what I'm seeing in the, you know, the, the gift demos for this, this remix one, you know, listing all the routes and the options.
-
-[30:54] So that, yeah, that looks extremely useful.
-
-[30:56] **Carl Vitullo:** Yeah. Even just surfacing how it's being all parsed out. You know, now that. I both remix the next, add that layer of file and folder names having influence on the behavior of the code you write in them. Uh, it's just, it's, it's reasonably indirect and it's a little, it, I have found it confusing at times, you know, if you have to debug, like, why isn't this route showing up?
-
-[31:19] Like, the only way to do so is futzing around with the file names, which. It's not great. It's not great inspectability. So better developer tools, at least saying this is how the framework is understanding what you've given it. That seems like a big help. Uh, cool.
-
-[31:35] **Mark Erikson:** Uh, so there was a really good post actually technically back in July, but I think got listed more recently called everything I wish I knew before moving 50, 000 lines of code to React server components.
-
-[31:45] It had a really nice, some really nice diagrams of, you know, kind of like the shift from client server behavior to React server component behavior, how server components, you know, actually kind of manage the tree, a lot of different code snippets, and information on, like, how would you actually start using server components in a code base.
-
-[32:06] You know, one of my, one of my biggest complaints about the server components rollout has been that, you know, there, there isn't a migration story, there isn't really good advice on how to start adopting these. And frankly, this is about the best information I've seen on, on that topic. So I, I thought this was an excellent, excellent post. Uh, it also had a link to a talk from the Reactathon conference that was done a couple of months ago, which discusses, when should you even consider using server components?
-
-[32:36] And that, that talk from Jeff Escalante was actually just a little, just a little on the intentionally skeptical side. Like it points out that server components are very useful for some kinds of apps. But not so much for others. And so it's not, you know, server components are not a silver bullet that you should just slap on everything, but instead actually kind of consider if it makes sense for your use case. So this was a very, very helpful resource, I think.
-
-[33:05] **Carl Vitullo:** I haven't read this in depth, it's very long. I think they said it was like 5500 words. It's rivaling one of your posts, Mark ( Mark laughs), but it, you know, just scanning through it, it reminds me of some of the resources on, you know, architecture and sort of summarizing behavior, and like the perspective that went into designing server components.
-
-[33:25] It reminds me of some of the write ups on, uh, or that like the next JS team has put up about that. Um, but I think a lot of those have been more from the maintainer side of things of like, here's why we did it, here's why we made this the way it is. It is. And this seems much more anchored from a pragmatic point of view of like, we don't care about how it works specifically, but here's how we used it, and here's the pitfalls we found.
-
-[33:52] Uh, so yeah, definitely agreed that this looks like a really phenomenal resource. Uh, and referencing something we talked about earlier, uh, one of the headers is CSS in JS is a non starter. Uh, so yeah, CSS in JS doesn't work in server components. So One reason why the React ecosystem has been moving away from that.
-
-[34:14] But yeah, I mean, if CSS in JS is the only way to get native styles working. Oops, there's a tension, can only use it, can only use CSS in JS in native environments and cannot use it at all in server environments. So that was like fragmentation to me.
-
-[34:32] **Mark Erikson:** A lot of that.
-
-[34:32] **Carl Vitullo:** Yeah, not ideal, but yeah, definitely a great read.
-
-[34:35] Definitely a great resource for anyone looking at how to get server components involved in their app, especially if it's not a greenfield project, and it's trying to bring it in as an optimization to bring it in as an improvement to an existing application.
-
-## [34:50] Expo Release Week
-
-[34:50] **Carl Vitullo:** All right, I guess, uh, let me move us on to our next link.
-
-[34:53] Yeah, I don't have one single link here, but Expo did a release week shipping a whole bunch of new features. Um, let me, I've got like eight links here and I don't know how to quickly dump them all, but there's Expo preview, a fully customizable builds on EAS build.
-
-[35:12] Um, I'm not really familiar enough with Expo. I haven't used it on a, you know, a production app, so I can't speak too much to all of these different acronyms and features, but fully customizable builds, I could certainly imagine situations where you might need to have finer grain control over how your application gets built. So that seems valuable.
-
-[35:33] There's a proof of concept for Expo CLI DevTools plugins. So continuing with the DevTools theme, feature preview of single sign on, feature preview of EAS update. So I guess that's the build for, you know, a fresh version of an app versus releasing an update to an existing app. Use updates API for Expo updates, which I it sounds related to that, updating.
-
-[36:00] There was an interesting one that caught my eye was Expo SQLite integration. They They reference convergent replicated sqlite, which is, that's really interesting. So it talks about having multiple different sqlite databases that have independent writes and then get merged together. And they had a little demo video showing multiple to do apps that are being kept in sync.
-
-[36:28] Um, I, I have a soft spot in my heart for SQLite, um, and a soft spot in my heart for CRDTs, um, which I'm blanking on the, what that stands for, but replicated data types. Um, conflict free data types. Conflict free replicated data types. That's it. Uh, yeah. So I have a soft spot in my heart for those, local first, merged data kinds of tools.
-
-[36:57] So it's interesting to, it'll be interesting. I think that could be a large unlock for people building mobile apps.
-
-[37:05] **Mark Erikson:** Yeah. I mean, just, just skimming down the list. It looks like they're putting a lot of effort into the, the build and deploy story for X for Expo apps.
-
-[37:13] **Carl Vitullo:** Yeah. And I know that there's been, you know, over the years, there's been some various churn on the React Native story for updates or for builds and updates, I guess, you know, for a long time, one of the advantages of React Native was you could update the JavaScript and change the behavior of an app without doing a full app store release, which I think is still true to an extent, but like policies have shifted on that.
-
-[37:37] And it's like, Uh, it's I know that Apple doesn't like that generally because they want to have firm control over what apps do. So if you're able to change what an app does outside of their review process there, they look at you suspiciously for that. So, uh, but yeah, definitely, you know, my, my recollection is that four or five years ago, Expo was really great for what it could do, but it was a very limiting sandbox.
-
-[38:02] If you try, if you needed capabilities that it didn't offer out of the box. You're kind of screwed. You had, uh, it was a little bit like Create React App in that where what it did was really great, but it didn't do everything. And if you needed more, you had to eject and then you're on your own. Um, but that is not how I understand the story of or, you know, the experience of using expo today.
-
-[38:24] From what I hear, if you're building React Native right now, you start with expo because it just does makes it so much easier for you. So cool to see so much investment going into it still.
-
-[38:33] Got another link for us?
-
-[38:35] **Mark Erikson:** Uh, that's all the, all the major ones I had to talk about. I think at this point, we're sort of onto the lightning things, although I could, I could talk about some of the lightning things in more depth if we wanted.
-
-[38:45] **Carl Vitullo:** Yeah, we got 15 minutes. Let's do a, let's do a, maybe I'm trying to think of a slower lightning round, but let's do a pseudo lightning round here.
-
-## [38:53] React Prod Source Maps (!!)
-
-[38:53] **Mark Erikson:** So, um, this next one is, And on these next two are things that I both have a very personal stake in. So, over the weekend, I published a new package called ReactProdSourceMaps.
-
-[39:09] And this is going to take a little bit of background and explanation. Um, so, JavaScript libraries Are normally published to NPM code that has been backwards compiled to, you know, yes, five syntax for compatibility with IE 11, although that's finally starting to change and more libraries are shipping modern JavaScript.
-
-[39:30] And then when you build your application with next or Vite or expo or create React app or whatever. All your application code and your nice original js or tsx files all get mangled together, mashed into a bundle, minified, and shipped to production. And when we want to debug our applications, we, like, we need a way to reverse map from the final mangled minified code back to the original source files that you had on disk.
-
-[40:03] And so bundlers and build tools use a technology called source maps, which literally contains the exact original source files that you had on your computer when it was built and defines how they got transformed into the final minified lines of code. So for example, uh, App bundle dot JS line one column 700, 000 through 700, 010 to do list item dot JS line 23 you declared your to do list item component.
-
-[40:39] And so that's how Browse and browser dev tools and other tools can show you what looks like the original files when you try to debug either a development or production application. And the problem is. Specifically, that the React libraries have never shipped with source maps. For their production build artifacts.
-
-[41:02] So if you build a React app in dev mode, React has a development build where the bundle is still readable. It's got comments and white space and original variable names. And if an error gets thrown, you can see a stack trace, and you can at least read the function names inside of React. One of the nice things about React has always been that most of the time you don't have to worry about how it works inside.
-
-[41:28] We can treat React as a black box. The important thing is understanding that, you know, it's, it's the mental model. If I set state, it re renders. If my UI is wrong... Look at the data, look at the rendering logic, trace the data back up the tree to where it came from. So most of the time, you don't have to debug inside of React.
-
-[41:49] But there are times when you do. Okay, maybe that's more applicable to library maintainers or people like myself and Brian that are working on developer tools at Replay. The problem is when you try to debug a production build of a React app. React has only shipped the minified, the prebuilt minified bundle.
-
-[42:09] They don't have source maps for it. And it's hard enough to understand what's going on inside of React. When you can actually read the original source code, it is impossible to understand it when all you have are single character variable names and everything's been mashed together. So, uh, about four months ago.
-
-[42:27] I took about a week, and I figured out how to modify React's build pipeline so that it will actually generate source maps whenever you, whenever they build React. And that PR has been sitting there, and Dan Abramov and I were going back and forth on reviews for it, and as far as I'm concerned, it's there, and it works, and it should just be merged. Dan had one small reservation, and I never quite convinced him that... It's fine. It works. Merge it. So it's still sitting there. And hopefully it will get merged at some point in the near future.
-
-[43:02] But the next problem is that even once it gets merged, the React team hasn't released a stable version of React since 18.2 came out a year and a half ago. Which is kind of frustrating. They are putting out canary builds, and Next is using those canary builds, but we haven't had a new stable release in a year and a half. So if and when a, that PR is merged and a new stable release comes out, then, you know, React 18.3 would have source maps.
-
-[43:31] But there's nothing for React 18.2 or 1 or 17 or 16. What I did over the weekend was I literally checked out React 18.2's tag from the repository and I backported my build pipeline changes. I made sure that I could build the exact byte for byte identical copy of React 18.2 production. And then I copy pasted my build pipeline changes to generate source maps over to that.
-
-[44:04] And it works! And the next problem is that, okay, so let's say that, you know, I have a Vite app and I'm using React 18.2. Well, I've installed React off of NPM, didn't include any source maps. I can download the React 18.2 source map I generated. But that doesn't help the app bundle source map that I just made.
-
-[44:31] I figured out how to use a couple different source mapping libraries, and I've written a CLI package that will... You give it the file path to the source map for an app bundle, and it looks to find a copy of React dom listed in the in the files, and it replaces The source map of the minified file with the source map of the original bundle before it got minified.
-
-[45:00] So that as far as the source map bundle is concerned, it has the original looking React source code available to debug. And I was able to prove that I could like serve up that modified V app and I could stick a break point inside the place where React renders function components and it worked and it paused there and I could inspect everything that was in scope with the release of this package, uh, I have not actually done it yet, but in theory.
-
-[45:30] Anybody who has a React app right now that uses React 18.2, 18. 1, or 17. 0. 2 could add a post build step that uses my package, correct React source map in their app bundle. And the other thing that I would like to do with this... So I've been talking about, you know, my day job at Replay ought to be able to take those same source maps and automatically insert them into our backend so that if you made a recording of a React app and didn't have the original source maps, we could automatically insert them anyway, as you debug the recording, like, I'm sure we can do it.
-
-[46:09] It's just a matter of convincing the backend team that we should.
-
-[46:12] **Carl Vitullo:** Yeah, I, I'm thinking of, I'm thinking of like Sentry and things too. All these other
-
-[46:17] **Mark Erikson:** Yeah. The, yeah, the, the, the Sentry folks have been following what I've been doing and they are very excited about this.
-
-[46:22] **Carl Vitullo:** Yeah, no doubt.
-
-[46:24] **Mark Erikson:** So I, I realize this is sort of a niche thing and not everyone is going to get immediate benefit from it, but like, I truly think this is something that a good bunch of the React community will benefit from because I was able to do the work to generate these just once.
-
-[46:41] **Carl Vitullo:** Wow. Okay. So I knew that you had done this. I knew you had, you know, published a thing, but I didn't realize that you were, it had done, it had taken so much, I don't know, effort, like, wow, going in and modifying source maps for... taking the apps, source maps, and then replacing the right parts of them, so the unrelated source maps still work, but you also get all the React ones.
-
-[47:06] Like what? That's actually crazy. That sounds if I got, okay. If I got to that point, I would say, wow, no, I'm not doing that. That sounds like a pain in the butt.
-
-[47:15] **Mark Erikson:** Like the thing is the actual logic is like 20 lines of code because there is a library that I found that will do the source map swapping. Like the majority of the logic is just import this library. The existing application source map, and then it gives you a callback for every file that it sees listed. And so I'm literally just saying, is this file's name React dom. production. min. js? And if so, figure out what version of React it is, load the right sourcemap and replace it.
-
-[47:49] **Carl Vitullo:** Good job, holy crap, that's wild. um, I think that's all I have to say on that. That sounds incredible. That sounds super valuable. And especially if, if Replay and Sentry can both take advantage of that and just do it on behalf of everyone. That sounds incredible. If everyone using either of those products can get source maps for free without. Or source maps for React for free without doing anything without changing configuration or anything.
-
-[48:15] Wow. Okay, cool. Nice. Big project.
-
-[48:19] **Mark Erikson:** So that's what I did my last two or three days.
-
-[48:21] **Carl Vitullo:** (laughs) That's that's a productive two or three days. Very nice. Cool. Okay. Well, I don't know how lightning that round was, but.
-
-[48:29] **Mark Erikson:** Not very, but hey, it worked.
-
-[48:31] **Carl Vitullo:** It worked. It was interesting. It was good.
-
-## [48:33] Official React+Typescript documentation
-
-[48:33] **Carl Vitullo:** Cool. Uh, I'll move us on though. Um, Yeah, React. Dev now has official TypeScript documentation. Thank you, Orta, for bringing this home. We discussed this last month when it was still a draft PR, but it has been merged, it has landed, and we now have official documentation on how to use TypeScript with React. Absolutely incredible. We're not going to comment on how long React and TypeScript have been out and available and the delay between... It being widely used and it being documented, but we have it. It's great. I'm glad we have it now.
-
-[49:11] **Mark Erikson:** It looks amazing. Orta, you did a fantastic job. Thank you.
-
-[49:15] **Carl Vitullo:** Uh, Mark, you got another lightning round? Well, you said you have a hard stop in three minutes. So if we want to blitz through some of these.
-
-## [49:23] Redux Toolkit 2.0 beta
-
-[49:23] **Mark Erikson:** Yep. So really fast, uh, mentioned this before, but Redux Toolkit 2. 0 is still in beta. We would really like people to try it out. And then just this last week, I published React Redux version 9 alpha, which has the same kind of, you know, ES module packaging changes. That, you know, I've been trying to apply to all our different libraries. Um, so again, we would really, really like people to try these out.
-
-[49:48] Tell us what breaks that shouldn't be breaking and give us feedback on things like the, you know, the new features and Redux toolkit 2. 0, pry them out. Tell us what you like or don't like so we can, you know, make any changes before they go final.
-
-[50:03] **Carl Vitullo:** All right, now's your chance. Get that feedback in. Uh, you want to run through your last link there?
-
-## [50:09] The Underlying Mechanisms of React's Concurrent Mode
-
-[50:09] **Mark Erikson:** Yep. Uh, and then the last item I have is, there was a really, really good article called The Underlying Mechanisms of React's Concurrent Mode. And again, this is not a thing that most people need to necessarily worry about because it's inside of React. I always appreciate articles that explain how stuff is built, what are the technical constraints.
-
-[50:29] And so this was a really good look at how React has implemented the ability to split up renders into multiple pieces and delay parts of it.
-
-[50:37] **Carl Vitullo:** Very nice. Um, I, I just have one lightning round link myself. Um, Sebastian and I were judges for React jam, which is a, it was a hackathon put on by a startup called rune that.
-
-[50:51] Is a I don't even know how to describe it, but it's a it's an app that you can play other games in. Uh, it's like a multiplayer games app. It's a little bit like discord activities if you've used any of those, uh, they did a hackathon building games with React. Um, so. Yeah. Sebastian and I judged it. We played a bunch of games.
-
-[51:13] They were pretty fun. And yeah, check it out if you like games and React and stuff built games built with JavaScript.
-
-[51:20] **Mark Erikson:** And on that note, I do unfortunately have to bail out for another meeting, but it's been a good discussion. And yeah, I think there's a lot of good stuff happening in the ecosystem.
-
-[51:29] **Carl Vitullo:** Yeah. Yeah. Always, always many new things.
-
-[51:32] Cool. Uh, Mark, thanks for joining me, uh, everyone in the audience. Thanks for listening along.
diff --git a/src/transcripts/tmir-dec-2023.md b/src/transcripts/tmir-dec-2023.md
deleted file mode 100644
index 60d3265..0000000
--- a/src/transcripts/tmir-dec-2023.md
+++ /dev/null
@@ -1,442 +0,0 @@
----
-title: This Month in React (December 2023)
-date: 2023-12-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- Quick hits:
- - [[00:55](#layoffs-news)] [layoffs.fyi](https://layoffs.fyi/)
- - [[01:37](#state-of-react-native-survey-closes-jan-5)] [State of React Native runs til Jan 5th](https://stateofreactnative.com/en)
- - [[01:50](#adobe-💔-figma)] [Adobe and Figma abandon merger](https://www.figma.com/blog/figma-adobe-abandon-proposed-merger/)
-- [[02:07](#react-native-073)] [React Native 0.73](https://reactnative.dev/blog/2023/12/06/0.73-debugging-improvements-stable-symlinks)
- - [New debugging docs](https://reactnative.dev/docs/debugging)
- - New Debugger, [give feedback here](https://github.com/react-native-community/discussions-and-proposals/discussions/733)
- - [Bridgeless mode](https://github.com/reactwg/react-native-new-architecture/discussions/154)
-- [[06:33](#redux-toolkit-20-and-supporting-libraries)] [Redux Toolkit 2.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0), [Redux 5.0](https://github.com/reduxjs/redux/releases/tag/v5.0.0), and [React-Redux 9.0](https://github.com/reduxjs/react-redux/releases/tag/v9.0.0)
-- [[11:37](#xstate-v5)] [XState v5](https://stately.ai/blog/2023-12-01-xstate-v5)
-- React Server Components updates
- - [[17:49](#react-core-team-panel-on-server-components)] [Frontend Should Embrace React Server Components](https://thenewstack.io/react-panel-frontend-should-embrace-react-server-components/)
- - [[18:47](#ben-holmes-react-server-components-from-scratch)] [RSCs from scratch video from Ben Holmes](https://twitter.com/BHolmesDev/status/1735701191823151239)
- - [[19:16](#storybook-adds-support-for-rscs)] [Storybook for React Server Components](https://storybook.js.org/blog/storybook-react-server-components/)
- - [[19:45](#dan-abramov-blogs-again)] [Dan’s “Chain Reaction” post](https://overreacted.io/a-chain-reaction/)
- - [[21:52](#daishi-katos-oss-prototype-rsc-framework)] [New RSC-first framework, Waku](https://github.com/dai-shi/waku)
-- [[29:29](#stylex-released-by-meta)] [Introducing StyleX](https://stylexjs.com/blog/introducing-stylex/)
-- React docs discussion
- - [[32:50](#documentation-for-the-use-hook)] [Recent core docs pages updates](https://github.com/reactwg/server-components/discussions/7)
- - [[35:08](#dan-abramovs-ama-on-bluesky)] [Dan Abramov React AMA on BlueSky](https://bsky.app/profile/danabra.mov/post/3khbvuwanqx2h)
-- Lightning round:
- - [[42:16](#-requesterimpairment-an-ietf-joke)] [An HTTP Status Code, Requester Impairment (joke??)](https://www.ietf.org/archive/id/draft-richardroda-420requesterimpaired-02.html)
- - [[43:18](#-jules-blom-on-flushsync)] [More Than You Need to Know About ReactDOM.flushSync](https://julesblom.com/writing/flushsync)
- - [[44:56](#-react-fights-you-can-have-with-your-team)] [React Fights You Can Have With Your Team](https://www.bekk.christmas/post/2023/13/react-fights-you-can-have-with-your-team)
- - [[45:33](#-an-interview-with-kyle-mathews-on-gatsbys-story)] [Building React Framework Gatsby](https://oss-startup-podcast.launchnotes.io/announcements/episode-118-building-react-framework-gatsby)
- - [[46:41](#-tanstack-router-v1)] [TanStack Router v1](https://tanstack.com/router/v1)
-- [[47:19](#what-will-happen-in-2024)] Discussion: what do we think will happen with React and the ecosystem in 2024?
-
-[00:00] **Carl Vitullo:** Thank you for joining us for December. I'm sorry about the audio quality of this month, I am on the road and I forgot my headset this time around. This is This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
-
-I'm Carl, I'm a staff product developer and freelance community manager at Reactiflux. Here, the Discord for React professionals. Mark, you want to say hey?
-
-[00:24] **Mark Erikson:** Hi, I'm Mark Erikson. My day job is working at Replay. Io, where we're building a time traveling debugger for JavaScript. And in my copious amounts of spare time, I work on Redux, and boy, have I spent a lot of time doing that lately.
-
-[00:37] **Carl Vitullo:** Yeah, you've got a lot of, releases to announce.
-
-[00:40] **Mark Erikson:** I think we're both recording this one while we're on the road, too.
-
-[00:43] **Carl Vitullo:** Yeah, I am coming, I am genuinely coming to you live from, my mom's basement. So this is a funny recording this time around.
-
-I'll start us off with a couple of just quick hits of little news.
-
-## Layoffs news
-
-[00:55] **Carl Vitullo:** I'm thinking of starting a new segment just talking about layoffs and trends in the job market for tech, that seems pretty relevant for news discussion. December has been trending down per layoffs.fyi, which is a great resource, highly recommend. It's trending down; fewest layoffs by number of companies running layoffs since April of 2022, and it's been, qualitatively it's felt a little bit better, but last year December was among the lowest of the months for layoff and January went way through the roof, so fingers crossed that doesn't happen this year. I think that'll be a pretty big indicator for tone of 2024.
-
-## State of React Native survey closes Jan 5
-
-[01:37] **Carl Vitullo:** There is a state of React Native survey that's currently running. It went live a couple weeks ago and runs until January 5th. So, if you use React Native, definitely check that out. Highly recommend, giving your feedback.
-
-## Adobe 💔 Figma
-
-[01:50] **Carl Vitullo:** This is sort of related to our field, but, Adobe and Figma had been doing a very large merger. I know many, many people in the React ecosystem work with people who work with Figma. So I thought I'd give that a shout out.
-
-## React Native 0.73
-
-[02:07] **Carl Vitullo:** On to the real news. I'll start us off with our first link, which is react native 0. 73. New pretty big feature release. They've got a lot of good improvements coming out here with improvements to debugging, a couple of relatively nitty gritty technical details like Support for symlinks, which is a huge problem if you use symlinks in development, and not a problem at all for anyone else, which would include me.
-
-But, the new debugging section looks really good. It looks like they've put a lot of energy into making debugging a lot better, which, as someone who has developed a product with React Native, debugging was a painful experience, so that's nice to see. They've got a new experimental, and Kind of buggy debugger.
-
-They ask you to give feedback, but yeah, it looks like they've got a couple of nice Maybe smaller improvements, but like, for instance, apparently, this is not something I had noticed while developing, but you send console. Logs early in the like, bootstrap process for starting up a new, for starting up a React Native process as you launch the app.
-
-If you previously, if you had run console logs very very early in that launch process they would just silently get dropped. You would not see them and obviously that makes debugging a lot harder. So they have updated the way that the debugger works to capture those and Ship them out once the Once the console has been set up and attached.
-
-So that alone is a huge improvement. I think that'll be nice. Another relatively large breaking change. I think they are deprecating the at type slash react native package. This is good news It's because they have Moved those types into the React Native package itself. So it's now first class types, it's included in the package.
-
-You no longer need to use the at types package. So that's awesome.
-
-[04:08] **Mark Erikson:** Experience is zero. Like I've, I've attempted to run one or two tiny React Native projects. Mostly just sussed out tiny bits of Redux stuff, and that's it. One observation out of that that I do think is interesting is that it feels like React Native has jumped on board TypeScript more than the React core has.
-
-One is that they, I think, React Native projects now ship with TypeScript set up by default, it sounds like. You know, this example here of moving the types into the core, whereas with the actual React and ReactDOM packages, the React types are still maintained separately. Now, the React types packages are now semi officially maintained by people affiliated with the React team, but there's still that difference of not actually shipping it with the actual React packages.
-
-Now you can also caveat and say this is a good thing because there have been tweaks and improvements to the React types packages that have come out in the last year and a half. Whereas there have been zero official stable React package releases. So there is actually a little bit of benefit to having those decoupled.
-
-[05:22] **Carl Vitullo:** Yeah, well, hey, maybe if they had been forced to React release in order to update the types, they would have stuck in a couple of, small improvements along the way too.
-
-[05:30] **Mark Erikson:** One other React native thing to toss in here, we'll mention it later, but Dan Abramov was doing an AMA over on BlueSky one of the various Twitter clones that are out there.
-
-And one of the questions was. You know, Dan, now that you're working on a product that is built with React Native, what are your opinions? And so per way that down that discussion, he had a couple thoughts about it's in some ways, it's great. In some ways, it actually feels really, really difficult and hard to use.
-
-But there were some interesting thoughts and discussion there.
-
-[06:03] **Carl Vitullo:** My general sentiment seems to be shared by a lot of people that I've known have worked pretty deeply with React Native is it was really great, it let me do all sorts of stuff, I never want to use it again.
-
-I think that's maybe just a reflection on the fact that mobile development is harder than web. And if you're trying to do both web and mobile development, React Native is pretty great, lets you do a lot more cheaply. Because you can actually share a substantial amount of the code between apps.
-
-But, it's got its own headaches too. You want to take us on, Mark?
-
-## Redux Toolkit 2.0 (and supporting libraries)
-
-[06:33] **Mark Erikson:** Yes! So, my big news, kind of on a personal and professional level, I've been teasing this one for months, but on December, I finally hit the button and shipped Redux Toolkit 2. 0. Along with major releases for all the other Redux related packages.
-
-Redux Core Version 5, React Redux Version 9, Reselect Version 5, and Redux Thunk Version 3. This has been a massive undertaking on so many levels. I started working on this slew of major versions at the start of the year. And Initially, the primary goal was to update the packaging to better improve ES module CommonJS compatibility.
-
-That turned out to be even more of a nightmare than I expected it to be. We added a number of features, we deprecated, we removed a bunch of deprecated options, there were TypeScript updates. And then the only, like the main reason we were able to even able to get these releases out this year was because we ended up deferring any major changes to the RTK query data fetching layer until sometime next year.
-
-People have asked for lots and lots of new features and options and changes, like to address those at some point, but that's just a giant undefined amount of work. Like, we, we, we have so many issues and feature requests that it's going to take weeks just to go through them and collate the list of what people are asking for, then take time to analyze those, do the design work, figure out how all these options are going to interact, and build them.
-
-And I can see that if we waited to release 2. 0 to include all those RTK query changes, It would be this time next year. Got a lot of help from one of the other primary maintainers, Ben Durant. And then, there's a guy named Arya who just left a comment in the chat who has done a ton of work on Reselect in the last few months. And we actually made some major updates to Reselect as well.
-
-One of the biggest ones was We changed the default memoization strategy for Reselect. Reselect has always had its own little built in memoization function that does a bunch of reference comparisons against all the values that are passed into the selector function. And the problem is that also defaults to a cache size of 1. If you call it three times in a row, and you alternate the arguments, like A, B, A, then it's not going to see the same arguments twice in a row, and it's not going to save the results. It's going to keep recalculating things every time.
-
-This always felt like kind of a bad developer experience situation. And so I ended up swiping crash implementation based on weak maps directly out of the React source code. React has a new memoization function built in called cache, and I literally copy pasted that code and made use of it and re select.
-
-[09:54] **Carl Vitullo:** Oh, very cool.
-
-[09:56] **Mark Erikson:** Yeah, it's buried down in the library, and I think it may actually be now listed in the docs. So, we did some testing on it, and we concluded that it's at least as fast in terms of like raw comparison performance.
-
-Um, in a sense, it has like an infinite cache size, but on the other hand, that could also be referred to as a memory leak, depending on how you look at it. Ultimately made the decision that this was worth actually including. And made that switch in Reselect version 5.
-
-So, I shipped all these literally the day before I went off on a trip to a conference, plus a vacation. So it was in theory Out of my head before I went off on this trip. Unfortunately, one of the truisms of maintaining and publishing packages is that it doesn't matter how many alphas and betas and release candidates you put out and how much you beg people to try them out, you will always get a whole bunch of new bug reports the minute after you publish the new versions live because now people are actually using them. And they're using them in ways you didn't anticipate.
-
-The biggest couple things I'm seeing are some lingering TypeScript update issues where there's things are just changed a little bit in ways that people weren't expecting. I am very, very happy to have this out the door.
-
-[11:18] **Carl Vitullo:** You've brought up the alphas and the betas in the last couple of months.
-
-Glad to, glad to hear you got it shipped. That's awesome. I obviously don't have anywhere near the level of access, or familiarity with you, so I can't, I don't even feel like I can respond to that appropriately, so. (laughter from both) I'm just going to roll us on to our next one.
-
-[11:36] **Mark Erikson:** Moving on!
-
-## XState v5
-
-[11:37] **Carl Vitullo:** Moving on! stately, or XState v5 has been released.
-
-I don't know, I don't think I would call it a competitor to Redux, but it does also deal with state. It deals with State machines, which Redux is one way. You can also implement state machines in Redux. It's not, I don't know, would you say, would you say Redux models things as state machines? Or would that be, would you say that's inaccurate?
-
-[12:05] **Mark Erikson:** David K. Piano would point out that Redux is typically half of a state machine. Um, the distinction being that a true, with a true state machine, first you look at what state am I in now, and then you decide, okay, if I'm in state A, do I want to respond to action or event? And in Redux, you typically just respond, you respond to the action in the reducer unconditionally.
-
-And so like, David actually contributed an example to the Redux style guide a while back, where it's like the first thing you would do in a reducer to make it a true state machine is switch state. Status, and then look at the action type. Whereas with a typical Redux reducer, you just, oh, here's the action.
-
-I handle it regardless of what the values are originally.
-
-[12:58] **Carl Vitullo:** That's a cool and precise distinction. I like that. I have always like had a place in my heart for XState, but I've never really used it in a project. Um, they've had a. A bunch of really phenomenal developer tools that help with designing state machines.
-
-You know, as a state machine library, they've written tools so that you can visualize them and write them in a visual way and then copy paste the code out. So I have actually used those tools in a Redux context because most of the projects I've worked on have been in that. But I've, I've been following them, following along with their development for a number of years.
-
-Really appreciate the work that they do. I'm pretty interested to see a couple of these. It looks like one of the big changes here is that everything is an actor, where actors have their own internal state, can send and receive messages or events from other actors, and can create other actors. So it sounds A little bit like a reducer, sort of like in the RTK slices, reducers kind of sense.
-
-And I think that's, been a place where I've struggled with modeling application state as a state machine is you end up with lots of little sub states. You know, each feature kind of has its own state. So, this seems like a pretty cool mental model. Code model for getting a little, maybe, maybe more precise control over how your state flows.
-
-You know, Mark, like you said, Redux is half of a state machine. So I don't know that I could articulate a specific benefit for using an entire state machine. But I do know that using the developer tools, the designer the state machine designer tools to figure out how I'm going to write my code has been really powerful.
-
-I haven't constrained myself to actually using specific state machines, but even just going through the exercise of enumerating all the states, enumerating the transitions, evaluating what data I need to pass along with the transition to make a state change self contained and isolated, um, uh I have found super valuable.
-
-They've got some cool future plans listed as well. Um, I, one that I really like, the first one is a toPromise helper function for converting actors to awaitable promises. That sounds really cool. If I could just say like, transition this state, and when it's done, keep going. Sounds pretty nice. Seems like a nice way to make asynchronous write code that responds to them in a more iterative way.
-
-So, um, I think that sounds pretty neat.
-
-[15:36] **Mark Erikson:** Yeah, as someone who also maintains a state management library, I, I just generally appreciate the amount of effort and work it took them to get this release out the door, um, I, I know that trying to implement their TypeScript support has been really, really complicated and they've got an absolute genius working for them. Matush Brzezinski, whose, whose handle is, andreasrake, has done a lot of work around their TypeScript support and trying to design APIs that are sufficiently flexible is a really, really tough task.
-
-So I, I understand and appreciate the amount of effort it took them to get this out the door. One other, one other plug, I don't know if this is even a thing they've released yet, but something they've been looking at is the idea of being able to analyze real world code and describe it in a state machine format, kind of like AI powered, being being able to use To like take like an arbitrary Redux reducer or maybe even like a use effect setup and have it analyze that and generate a state machine like description of it so that you can then use some of those graphical developer tools to visualize the code.
-
-That's a separate thing from the XState library itself, but I know that's something that the stately company is working on.
-
-[17:00] **Carl Vitullo:** That sounds incredible, actually. Yeah. That's like the dream of self documenting code. State machines are just so easy to read in the abstract. I've always really struggled to go back and forth between state machine, real code.
-
-So if I could have something do that for me, ooh, that's pretty cool.
-
-Alright, let's move on though. Mark, what's your next link? Or set of links.
-
-[17:24] **Mark Erikson:** So my, my caveat for a lot of this month's discussion, as usual, is that between travel and holiday stuff, I'm, I'm even less plugged into what's actually been going on in the ecosystem this month. This section especially is a collection of things that look interesting, but I haven't had a chance to go through them myself. So a few different updates and discussions related to React server components.
-
-## React core team panel on Server Components
-
-[17:49] **Mark Erikson:** A panel at the React Summit New York conference in, mid November where some members of the React team and Next. Js and a couple other ecosystem folks had a discussion about the state of React server components and whether they're worth adopting now and how are they used and how do they work. Ironically, I was at the conference.
-
-I did not have a chance to watch that panel either live or recorded later, but this article is a fairly good summary of the discussion in that, um, so there were, there were a number of folks involved in that, including Andrew Clark, one of the React core members, Tom Preston Werner, who's currently working with RedwoodJS, Ben Holmes, Josh Camot, and a couple of the React devrels.
-
-Curious about sort of like the, I guess like the semi official view of what's going on with server components. This would probably be a really good discussion to watch through.
-
-## Ben Holmes, React Server Components from Scratch
-
-[18:47] **Mark Erikson:** Speaking of Ben Holmes, so he's very involved with the Astro framework, but he also does a lot of videos on his YouTube channel where he explains things. He did a larger video called React Server Components from Scratch, about 20 minutes where he talks about server components and does a lot of drawing on the whiteboard and tries to explain how they work and what's going on and knowing Ben's ability to describe things that should be very useful.
-
-## Storybook adds support for RSCs
-
-[19:16] **Mark Erikson:** The storybook tool for documenting has actually added React server component support. Frankly, I have no idea how they've even implemented this at the technical level, but I can see this being a very useful thing. Like if you're writing server components, you want some way to be able to document them and make use of them, but they have all these requirements around being able to fetch data. So in some way, they've implemented support for using server components.
-
-## Dan Abramov blogs again
-
-[19:45] **Mark Erikson:** Dan Abramov had done a lot of blogging in 2018 2019 on his site overreacted. Io, and Dan is a very deep thinker, he does a great job of explaining things, and he'd written a number of posts that kind of talk about how does React work conceptually, how do you approach modeling things with use effect, And he'd really spent his last two to three years entirely focused on rewriting the React documentation.
-
-So he hadn't blogged at all in a couple years. Well, now that the new React docs are finally out, and Dan has left Facebook and is now working on the BlueSky app, he's finally had a little bit of time to sit back, And do some thinking. And he's put up a new blog post. It's a little bit on the same principle of his talk from RemixConf earlier this year.
-
-He did a talk at RemixConf where he was like, what if React had always been server first? What would the evolution of React have looked like there? And he actually did a whole live coding demo where everything was like late 90s, IE6 themed. What kind of follows along, or this blog post kind of follows on that same principle.
-
-So it's kind of like, what if we were sort of building React from scratch in a server centric world, and we need, and components could return async data, or async results. How would you even write the code that looks at the return values of the components and unwraps them recursively so that we can wait until the data is actually ready?
-
-And he never actually uses the word server components in this blog post, but if you read it, With kind of like between the lines, he's actually explaining this is the mindset behind how server components are implemented conceptually and under the hood. And I think he said this is meant to be the first in a series of blog posts that kind of digs into this, into these concepts.
-
-## Daishi Kato's OSS prototype RSC framework
-
-[21:52] **Carl Vitullo:** This is pretty early stage, I think, but somebody has put together, Daishi Kato.
-
-[21:59] **Mark Erikson:** He created Jotai and Valtio and now maintains Zustand, and he's also written a dozen other React slash state management utility libraries.
-
-[22:13] **Carl Vitullo:** I recognize his name because you had mentioned him in previous episodes we've recorded.
-
-But I could not have given that comprehensive list, so thank you for that. Daishi Kato has written a minimal React framework for, that uses React server components. So, this is the third, sort of React server components from scratch that I've seen. I think this is the first that I've seen that is Positioned as a framework that you can use.
-
-So, like you mentioned, Ben Holmes did his From Scratch video. I always appreciated Ben Holmes videos. He, he, he says he's the CEO of Whiteboards at Astro, which I, I appreciate. He, he does a good job with DevRel. And I have not yet watched his video. Like he said, travel, holidays, I'm behind. But, so his was the second.
-
-Last month we talked about somebody who wrote a really great, very long, comprehensive, I have a blog post about implementing React server components on their own in isolation. It looks like server components are now starting to filter out from only Next to now people have started to really wrap their hands, wrap their brains around them and start experimenting with them on their own.
-
-So I think, to me, that is a really big step in this open source process. We've been talking about React server components always with the caveat of like, "Oh, I don't really know. I haven't played with it." Because of how complex and undocumented the programming model has been so far. So seeing some of these people really dive deep and get their hands dirty and produce things is really good.
-
-So starting with a blog post, then a video, now a framework by three separate people. The community expertise in React Server Components is really ratcheting up, pretty cool to see.
-
-[24:05] **Mark Erikson:** I can also vouch that RedwoodJS has been putting a lot of effort into trying to implement Server Components for their framework as well.
-
-I know they did a blog post a couple months ago where they said we're all in on Server Components. I had a chance to talk with Tom Preston Werner at a conference a couple months ago where he was talking about some of the complexities where in a lot of cases they're having to go into the guts of Next and look at the implementation and try to figure out like how much of this is going What anything integrating with server components would need versus how much of it is specific to Next's internals.
-
-And I've seen some of the discussions from some of the other Redwood engineers as they're trying to figure out how to put all the pieces together. So there is activity. I don't know how fully along Redwood's implementation is yet, but there is very definite. Effort being put into trying to, trying to productionize that.
-
-[25:00] **Carl Vitullo:** I don't know. When did we, when did we start seriously talking about React server components? Do you, do you have a sense for that? It feels like it's been all year.
-
-[25:07] **Mark Erikson:** I feel like almost three years ago was when the first video came out. It was either two or three years ago. And, and like it sat around for a while. And then we finally started seeing the integration to Next after, Sebastien and Andrew moved over to Vercel.
-
-[25:23] **Carl Vitullo:** This is all building upon the primitives that were added in Suspense, right? Which I know that, I just saw some discussion about, it's been five years since Suspense was first unveiled.
-
-So this is, I think, to me, that's a testament to just how difficult the work that they're trying to do is. We can talk a little bit more about what this unlocks later, um, I have a link coming up in the lightning round. Well actually maybe I'll just bring it in right now.
-
-Guillermo Rauch did a, um, a great post talking about, or in response to, what's the difference between PHP and Next with the, this. Satirical, kind of shit talking of like, "Oh, JavaScript is finally catching up to PHP 20 years ago, haha." I thought he had a really good response, basically talking about like, Yeah, we do have, on the face of them, they are pretty similar, but some distinctions are there's out of order streaming.
-
-Like you can piece together the HTML by order of importance, not You know, linear order of HTML and pre rendering versus rendering on the client, control over that, which I, I haven't used PHP seriously in close to 10 years at this point, so I can't comment too much about what the capabilities are, but you know, I remember trying to do mixed server client rendering in PHP and it was a lot of writing JavaScript code in the HTML of PHP and then like jumping in and out of PHP tags to like render pass data in or whatever. Or you write your JSON endpoint. And so like, yeah, you can do those things, but it's, it got real messy real quick.
-
-Or it, it at least wasn't, it wasn't a pit of success. It was not easy to get something that was maintainable and great. That felt good. Felt. Solid and robust. So, yeah, I think there are, I know people talk a lot about unnecessary complexity or just people like to bash on JavaScript, people like to bash on web and client and frontend, but I do, I really believe that the React server component stuff is Genuinely pushing the envelope of what's possible in a real and deep way.
-
-I, like I, we don't, we don't have a, FrontEnd doesn't have a academic discipline, you know. There's no computer science researchers writing JavaScript. That is genuinely how I think about What a lot of the React core team is doing. Like, were this an academic discipline, this would be PhD thesis, postdoc.
-
-Actually, you know what? Like, it's not an academic discipline because it is well beyond the complexity that would be in an academic setting. This is post graduation, you've got your Ph. D., you're now working in industry, advancing the state of that industry. And I think that is truly what the React core team has been doing for my entire career.
-
-It's one of the reasons I have a lot of trust in them, is they keep executing, and they keep, for an entire ten years, they have stayed at the bleeding edge, and they have set the norms that everyone else in the industry follows. Okay, it's taken them five years to start realizing the vision that they set out with Suspense.
-
-Well, you know what? They're doing it. They keep, it's hard, it's really difficult to feel out all the edge cases, it's really hard to communicate to all of the developers what you're supposed to be doing, but man, they're doing it. They are, they have continued to do it for my entire career, and I just have huge, huge amounts of respect for them.
-
-[29:11] **Mark Erikson:** Yeah, they've always had a very long term vision of how they want to build things, and they've kept chugging along towards that goal.
-
-[29:19] **Carl Vitullo:** Bit of a, bit of a ramble there, bit of a rant, but, I was thinking about it over the last week or so, in prepping for this. Just, the work they're doing is really cool.
-
-## StyleX released by Meta
-
-[29:29] **Carl Vitullo:** Okay, but under our next link, facebook released, something that they first talked about a number of years ago, Stylex, a CSS and JS tool that, that they use at Meta. Sorry, not Facebook, Meta. I don't have a lot to say on this. Um, I know I'm introducing it, but it's a CSS and JS library. Kind of feels like the moment for that has, um we, we had a lot of experimentation on that.
-
-And it feels like generally we, as a, an ecosystem, the React subset of web development, have settled on CSS and JS not being the best solution. Just, some some of the trade offs are Increasing the size of the JavaScript bundle, where JavaScript is more expensive to load and parse than CSS. So it tends to add a lot. Relative to non more traditional CSS. It tends to add more startup cost than other methods. Mark, do you remember when they first announced StyleX?
-
-[30:31] **Mark Erikson:** It, there was a, there was a conference talk about it at ReactConf in either 2018 or 2019. And they didn't give many details. They just kind of said, here's an overview of the tooling that we use internally at what was, what I guess was still then Facebook and kind of what it does and how it works at a high level.
-
-The community was aware that existed. But there was no information on the actual internals or anything that you could use. So there was, it was always sort of this, this hint of this exists. It was only this year that you could actually, they were, they started actually moving towards being able to release it open source.
-
-And so now it's finally out. Um, yeah, the couple bits that I know about it are as, as the comment just said, it's primarily compile time, not runtime, so there's always trade offs there in terms of the amount of dynamic behavior it can have. I believe it compiles down to Atomic CSS, so part of the sales pitch is that as the app grows and you have more and more components using certain styles and certain rules, the growth of the size of the CSS stays lower than it might with other approaches.
-
-[31:48] **Carl Vitullo:** That does seem like a genuine advancement of the state of the art of CSS and JS. Um, especially, pulling, that was always the challenge with stuff like Emotion, um, or styled components was, I think you could wire it up to Webpack or limited other build systems, such that it would extract the, the styles into CSS.
-
-Some of them could, some of them couldn't, bit of a mix and match, but okay, that, that being, The major downside of CSS and JS, if they, since they have built it as a compile time extraction of styles, that's avoiding the biggest, worst trade off. So that sounds pretty cool.
-
-Positioning this as extremely large code base styling tool, so focus on performance at scale sounds exactly like what CSS and JS needs. I think that's all. I got a say on it. You want to take us on to the next news item?
-
-## Documentation for the use() hook
-
-[32:50] **Mark Erikson:** Moving us along, a couple of discussions around docs. So, I've, I've actually been whining for a lot of this year that okay, it's great that the new React doc site is available, it has a wonderful tutorial, but it just feels like there's so many other pages that need to get filled out for it to be fully useful in terms of some of the API references and usage guides.
-
-And I I had some discussions with some of the React dev rels this year. So they actually just posted an update that collates some of the recently added or updated docs pages that they've been working on. And it looks like a, and kind of the, some of the theme here is they've been working on documenting A lot of the new APIs that exist around server components and server actions.
-
-So we actually have some documentation for the ambiguously named use hook, which I'll be honest, I still don't fully know the status of this. I guess the docs page says it's only available in canary and experimental builds. So I guess you can use it with Next, and that's, that's kind of about it. But they've also documented the new UseFormState, UseFormStatus, and UseOptimistic hooks that you would use with the, and with server actions.
-
-They've documented the useServer and useClient, not sure what the word is for them, markers that you would put in files so that the bundler knows how to parse those. They've added some more details on the useTransitionHook, they've talked about the cache memoization API that I talked about earlier.
-
-They've documented the HTML form tag. In a sense of, here's how you can use this in a React app and actually write kind of more browser native forms. They've added a page that talks about thinking about the UI as a tree, and they're working on some additional documentation. So I'm a big docs person, and I really, really appreciate seeing them continue to actually work on these and not just leave the site as it was after the new tutorials came out.
-
-## Dan Abramov's AMA on BlueSky
-
-[35:08] **Mark Erikson:** Along with that, Dan Abramov is now working on the BlueSky Twitter clone app as his day job. And he recently did an AMA over on BlueSky. People had a whole bunch of good questions over there. I mentioned the one earlier about people asking What are your thoughts on React Native now that you've actually used it?
-
-Um, there were some questions about React batching and will React ever get ported to Rust? There was one in there that was, What do you think should happen to create React now? And Dan's comment was, It would be nice if it was turned into a build time server components framework. I don't expect that to actually happen, but it's an interesting train of thought of what could we do with the name and the toolset if we wanted to.
-
-[36:03] **Carl Vitullo:** Dan has gone a little quiet the last, like you mentioned earlier, he's talked about going all in on the docs. He also mentioned some challenges he experienced with his own perfectionism trying to get it just right, which is he attributed as part of the reason the docs took so long to come out. Sounds like he may have gotten a little burned out too.
-
-[36:22] **Mark Erikson:** Oh, yeah. Oh, yeah.
-
-[36:24] **Carl Vitullo:** Burnout is real. Burnout is tough. So it's nice to see him in a new context, working on a new It sounds like he's enjoying getting his hands dirty working on an application rather than staying at the high level of just talking about React and developing it from the core. Um, I think it might, seems like he's enjoying it.
-
-It's nice to see him get back into writing and community discussion a little bit more. Um, this has been a really good thread. I'm, I'm also a big fan of Blue Sky. I have been enthusiastically looking for an alternative to Twitter. So I am optimistic that Dan being a more prolific poster on the platform will help it succeed.
-
-Glad to see a few more of these. Definitely recommend going through the thread and just reading a bit. There's a, there were a couple of really good questions and answers. One that I saw and responded to, so I'm gonna toot my own horn a little bit. Somebody asked about, um, React and, what's the Like, Module Federation, What, Microfrontends?
-
-[37:33] **Mark Erikson:** yeah. Those are probably too
-
-[37:36] **Carl Vitullo:** Yeah, okay, so somebody asked about micro frontends and module federation and how React would work with it. I know that's been a subject of debate for a couple of years. It's sort of come and gone over time, ebbed and flowed, but I think that's a really big challenge. I think it's, maybe we'll see it come back a bit with React server components as those settle down, but I think the real challenge there is CI and CD, the build and deploy process for micro frontends.
-
-Which I think is, it solves a real problem for large teams, but it's difficult to implement. Tends to be a DevOps discipline rather than a library or product. Just, it's too deeply embedded in every step of the build, the development, the deploy, testing. Just too tricky.
-
-Coming back to that React Working Group discussion on GitHub, um, that you started us off with. It's really nice to see some of the Some of what they're looking to invest in more deeply. I've always thought that React worked really well once you get your head into the right mindset of, once you get the right quote, air quotes around right, mental model for how to think about UI. In the way that React would like you to, it unlocks a lot of really powerful possibilities.
-
-So, in the past, those a lot of those best practices and descriptions for the mental model, I have gained mostly through reading a combination of gists. On GitHub, and Twitter threads, and reading code from other people and seeing how they solve problems.
-
-Which is just not a very repeatable process. Like we have a learn page with many links that you have collected, Mark. I think that's been a One of the better ways to gather body of knowledge, but it's nice to see, it's nice to see some of that, some of those best practices working their way more into the docs.
-
-I think that a lot of them have been in flux for a long time, a period of years as we were figuring out first hooks and then like, what is suspense? How does it work? Oh, now it's server components. How do those work? What are they? It feels like a very long journey to where we are right now that is It's nice to see things stabilize and settle down a little bit more.
-
-It's, I look forward to see what the docs are like in 2024.
-
-[40:04] **Mark Erikson:** I actually had a back and forth with Rick Hanlon from the React team in mid November where I was getting a little worked up and complaining that You know, the React docs really need to have more details about how React renders. You know, that's always been one of my biggest and most appreciated blog posts, is the article about React's rendering behavior.
-
-I actually got called out a little bit by Rick, who linked me to certain sections of the docs that actually have some of the information that I was complaining didn't exist. I had looked through some of the early betas of the docs, and to be honest, I hadn't really gone back and dug through them since then, and so there were definitely some pages that called out some of the specific nuances that I thought should be in there that I didn't realize had actually been added.
-
-Like even talking about kind of like the existence of like the render versus commit phase. It is sort of scattered through some of the different learning material pages. It's not like in one single start to finish usage guide or how this works page. But there is actually a lot more of that material in the current docs than, certainly in the old docs, and more than I had actually given it credit for.
-
-[41:22] **Carl Vitullo:** It has been a bit of a challenge to figure out how to stay on top of what changes are coming out in the docs. I note that the last blog post on react. Dev was in May. So, I think you can be a little forgiven for finding it difficult to stay on top of what changes have happened.
-
-I'm not even sure how you would. Because I don't think they get published as releases in GitHub.
-
-[41:45] **Mark Erikson:** Well, no, the React docs should still be a public repo, um, it used to be React. Js slash React. Js dot org, they might have renamed the repo, but the repo exists, so I assume I could watch the repo for PRs.
-
-[41:59] **Carl Vitullo:** That's a high noise source of input though, where's the bi monthly summary of here's all the stuff we've shipped. So anyway whatever. They got more, they got some more DevRel folks. We'll see, we'll see what's going on. Anyway,
-
-[42:13] **Mark Erikson:** cool. Lightning round.
-
-## ⚡️ RequesterImpairment (an IETF joke??)
-
-[42:16] **Carl Vitullo:** Lightning round. I don't quite comprehend the implications of this, but IETF, um, The task force that owns HTTP has put out a draft of an HTTP status code to report requester impairment.
-
-I don't quite know what that means. They talk a little bit about AI requesters.
-
-[42:38] **Mark Erikson:** It's a joke.
-
-[42:39] **Carl Vitullo:** Is it a joke? They put out a joke in December?
-
-[42:42] **Mark Erikson:** Look at the status code.
-
-[42:44] **Carl Vitullo:** RequesterImpairment 420. Okay, this is straight up a joke? It's a very serious looking joke.
-
-[42:50] **Mark Erikson:** Have you ever seen HTTP status code 418? I'm a little teapot.
-
-[42:54] **Carl Vitullo:** But that was released on April Fool's Day, like 20 years ago.
-
-[42:59] **Mark Erikson:** Yeah, I don't know why this one would have been released. But I'm pretty sure this is a joke of some kind.
-
-[43:05] **Carl Vitullo:** It smells like a joke. It's RequesterImpairment 420 Yeah. It smells like a joke, and I don't know how to interpret this. Maybe it's a joke.
-
-Move us on, take us away.
-
-## ⚡️ Jules Blom on FlushSync
-
-[43:18] **Mark Erikson:** A blogger named Jules Blom, who has put out a number of posts in the last year that talk about some very specific technical nuances of React rendering, which is a topic that I always appreciate. And so Jules put out a post recently that talks about a relatively new React API called FlushSync.
-
-And this exists because of the change in how React batches updates. Prior to React 18, React would automatically batch renders if you called set state more than once in an event handler, but it would not do it if you did it in some async function. And so React 18 switches it so that React now always batches any updates that occur in the same event loop tick.
-
-But there might be times when you need to force a render immediately right now after a given setState call. So it's flipping the default behavior, and so now you need a new escape hatch from that behavior. So there's a new API called FlushSync, which says, okay you've queued up one or more setState calls.
-
-Force React to actually render right now, and then continue from there. And I know Ryan Florence had a tweet about this recently, where he says he uses it instead of useEffect in a lot of cases. So you might have like a click handler that does a setState call. And then calls FlushSync to make sure it gets updated right away so that you can do some kind of like a focus or scroll change.
-
-So, this is a useful article talking about what it is and why you would want to use it.
-
-## ⚡️ React Fights You Can Have With Your Team
-
-[44:56] **Carl Vitullo:** Thank you, next. I like this one. It's a little silly. A Christmas post. React fights you can have with your team. I was just reading this and all of these are fights that I have had with my team over the years. So default versus named exports.
-
-Do you call a file in a, a feature folder index tsx, or the same name as the folder? How do you name props, regular functions or arrow functions? I, it, it was, it was just a, a, a great comprehensive list of all sorts of fights that I've had over the years on teams. So, appreciated it. Um, okay, I have a second one queued up here, so I'm just gonna run with it.
-
-## ⚡️ An interview with Kyle Mathews on Gatsby's story
-
-[45:33] **Carl Vitullo:** Um, there was a good podcast recently interviewing Kyle Matthews about building Gatsby. It just, just, it seemed like a very honest and open discussion of the lifespan of Gatsby from Inception to V2, V3, and Acquisition. Reactiflux and Gatsby share some ancestry. Kyle Matthews used to be pretty active here.
-
-At one point he had admin permissions over a subset of channels that Gatsby used as their official chat. So I have a soft spot in my heart for Gatsby. And it's nice to see some discussion of inside baseball, how did it work, how did it grow, why was it made. I, I, something I thought was pretty interesting is he explicitly talks about making it for himself for blogs and small sites.
-
-One of the big complaints is that Gatsby didn't really scale beyond those, so hearing him talk about how he made it for that for himself, it's like, okay, that kind of makes sense then. Yeah, worth a listen. It's like an hour long. It's a podcast. It's a reasonable time investment.
-
-## ⚡️ TanStack Router v1
-
-[46:41] **Mark Erikson:** All right, and last lightning round item is that the ever prolific Tanner Lindsley has released TanStack Router v1. I know Tanner has had a lot of opinions about Things like, how does a router integrate into a framework, type safety, and data fetching and loading.
-
-So, this, I could not sit here and list the differences between TanStackRouter and ReactRouter. But, Tanner has a track record of creating libraries that are very useful, very well thought out, and he puts a lot of effort into them. So, probably worth taking a look.
-
-## What will happen in 2024??
-
-[47:19] **Carl Vitullo:** And Mark, you had a great idea. For an end of episode discussion, what do we think will happen with React and the ecosystem in 2024?
-
-[47:29] **Mark Erikson:** The biggest one that I'm so very much looking forward to and excited about is the React Forget compiler. So the initial mentions of it were well over two years ago. It was kind of quiet. We got tiny little hints and a couple updates. You know, over the last year and a half. And then finally, late this year, we got a couple big updates from the team members who were building the Forget compiler.
-
-Sathya did a talk at React India, and then Joe and Mofe did a talk at React Advanced in London. It sounds as if React Forget is real, it works, it is being used in production at a couple of different metasites, and it sounds like the hard part And now it's the other hard part of trying to fully productionize this and make it ready.
-
-You know the overall goal is not just about It's not just about removing the need to have dependency arrays in your use effects and your use callbacks or whatever. It's also about actually optimizing when it's re rendering. And there's been lots and lots of talk about signals across the JavaScript ecosystem in the last two years.
-
-You know, lots of different frameworks are adopting signals. And the React team has said You know, we, we might end up making the use of signals as like an internal primitive, but we don't really think that they provide a lot of value as a user level piece of code. And so their approach is, let's build a compiler.
-
-And you write your React code exactly the same way you always have. You don't have to think about anything special. You don't have to use special value get, set calls. You just write your components with plain data and eventually, someday, This magic compiler will make things faster. And it sounds as if someday is hopefully relatively sooner.
-
-Obviously there's no actual release date. You know, the, during the talk at London, Joe and Moffay said it'll be available when we think we've got it fully productionized and are ready to support it. I'm hopeful that it will actually come out in 2024.
-
-[49:42] **Carl Vitullo:** I like that. Good prediction. Well, I don't know a prediction, but
-
-[49:45] **Mark Erikson:** Wishlist.
-
-[49:46] **Carl Vitullo:** Wishlist, sure.
-
-I have always taken an approach of no expectations. I prefer to just let the news wash over me and See, I think, I think I find predictions less valuable than responsive, being responsive to what comes out. Updating a mental model periodically. I'm very excited to see how server components continue to shake out.
-
-That's maybe a kind of a cop out answer, the obvious choice, but it's true. I, I, I, I think it's a pretty new paradigm for programming, um I just had my big rant earlier about respect for the core team and how they're pushing the industry forward. Yeah, I'm really interested to see how that continues to shake out.
-
-It's really cool to see momentum build. In the community, in the ecosystem. I think it's complicated, I think it's hard. I think 2024 might be when we hit critical mass on that and start seeing a lot more powerful applications of server components more generally.
-
-[50:51] **Mark Erikson:** another thing that will hopefully happen next year is another stable version of release of React.
-
-Because the current one is 18. 2, that came out well over a year and a half ago. You know, I've voiced my complaints about React's versioning strategy a number of times this year. They put out the blog post about the canary release idea, which has resulted in a lot of arguments about, well, what does it mean that this feature is stable for frameworks, not actually stable and usable by anybody else?
-
-And I think, it kind of goes back to what I said earlier about, Pre release versions. It is very true that for most developers, like even myself included, a fully supported, stable, semver backed release It might as well not even exist, both in people's minds and in the willingness of people to actually use certain features.
-
-So there's been a lot of debate and frustration over the way that like, Next is using pre release and experimental versions of React in order to implement things like the app router. And I'm very hopeful that we will actually get another stable version of React that Actually pushes things forward also in a selfish way because then it would actually have my source maps generation built in the latest Info that I have just trying to keep an eye on the update work team is actively talking about React 19.
-
-Andrew Clark has made a couple comments on Twitter I've started to see some PRs go through in the React repo that are actively starting to clean up deprecated and dead features. Um, they removed a completely unknown variation of how you could define components as a module object. A couple months ago, there's actually a PR up right now that would remove the legacy context system.
-
-You know, the old this. Context in, in class components. I would not be surprised if we don't get an 18. 3 minor release. And instead, the next stable release is 19. 0, with a number of deprecations and removals and things cleared out. Very curious if that would also finally include the better web component support.
-
-It was PR'd probably almost two years ago, and has been sitting in experimental builds. And has resulted in lots of people whining that it's not available yet. I would certainly hope React 19 would be out by this time next year. If and when it does come, I would expect it to be removing a lot of deprecated options.
-
-The question is, how long will it take to come out? And will there be any minor releases before that? I can also safely predict that the React subreddit and Reactiflux will continue to be flooded with questions of Should I use Next versus React? Should I use Next versus Remix? Should I use Next versus Vite?
-
-Should I use Redux versus Context? Da da da da da da da da da da.
-
-[54:09] **Carl Vitullo:** The never ending cycle of questions. Yeah, we're, we're going to be doing a, a thank you to the React core team soon before the end of the year. Years and years ago, we used to do an annual like end of year thank you to the core team, which was really lovely.
-
-And we just fell off and stopped doing it. So we're going to be trying to revive that now. And it's been six years since the last time we did that. Last one was in 2017. It was a good excuse to go back, pull up the web archive, and see how the communities have grown. So I pulled up like this the subreddit, the React. Js subreddit, Reactiflux, and Thackoverflow.
-
-And it was pretty wild. All of those have 10x'd in size. The 2017, there were 60, 000 questions on Stack Overflow. The subreddit was at 30, 000 members. Reactiflux was at 25, 000 members. And now, Reactiflux is at 220, 000 members. Subreddit's at 300, 000. And we've got 600, 000 questions on Stack Overflow.
-
-Just absolutely ludicrous growth. Literally 10x. On each of those communities, over the last six years. Pretty wild. React's taking over the world. Or has taken over the world.
-
-All right, well thank you everyone for joining us on this end of year, weird liminal space between Christmas and New Year's when nothing counts and nothing is real.
-
-We'll be back on the last Wednesday of January. Here in the live stage of Reactiflux or back in your podcast feed as soon as we can. With the end of the year this one might Come out a couple days late. We'll see. I'm not sure what my editor is gonna be up to. Ha ha. If you see anything newsworthy, definitely let us know in the Tech News and Reads channel of Reactiflux.
-
-We do source Links from there, definitely pull from discussion and things as well. Thank you so much for joining us. I'll see you next month.
diff --git a/src/transcripts/tmir-june-2023.md b/src/transcripts/tmir-june-2023.md
deleted file mode 100644
index 109e562..0000000
--- a/src/transcripts/tmir-june-2023.md
+++ /dev/null
@@ -1,391 +0,0 @@
----
-title: This Month in React (June 2023)
-date: 2023-06-28
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-
-
-[00:00] **Carl Vitullo:** Thanks for joining us for this month's, This Month in React, for June, where we recap and digest recent develop elements in the ever evolving React and web ecosystem. We are your hosts. I am Carl Vitullo. I'm a staff software engineer and community manager for Reactiflux.
-
-[00:17] **Mark Erikson:** Hi, I'm Mark Erikson. Most folks might know me as the maintainer of the Redux family of libraries, and my day job is at replay.io, where we're building a true time traveling debugger for JavaScript.
-
-[00:28] **Sebastien Lorber:** Hello, I'm Sebastian and I am known for Docusaurus as being the maintainer and also the creator of the This Week in React newsletter.
-
-[00:38] **Carl Vitullo:** Yeah, I feel like we've had a lot of news this month, so how about we jump into it?
-
-# StackOverflow Developer Survey
-
-- [Stack Overflow Developer Survey 2023](https://survey.stackoverflow.co/2023/)
-
-[00:43] I am starting off a little broad here. The StackOverflow developer survey for 2023 came out and I feel like it had a lot of, I don't know, this is just such a like seminal survey in the programming world generally. And I guess, from the survey I was seeing just how much of the programming world is specifically web and React.
-
-[01:04] So it's, I thought this was interesting to see. This is good to cover for, even though we, this is not specifically about React or Web narrowly, but Yeah, I mean, for example, they had a bunch of questions about what technologies you use and of the top 5, 3 of them are web technologies.
-
-[01:20] 65% of respondents use JavaScript, 38% use TypeScript, half use HTML and CSS. So a lot of good insights in here. Some good examples on hybrid versus in-person work, like only 16% of software developers are currently fully in person. Well, 16% of respondents to the StackOverflow survey.
-
-[01:40] They had some good salary information. US, UK, India. For a front end developer in the US, average reported salary was 140,000., Same title in the UK was 71, same title in India was 15. So one thing I love about this survey is just seeing, sort of a benchmark about the industry as a whole, or at least the portion of the industry that makes heavy use of StackOverflow, but always fun to see and definitely good things to read here.
-
-# Server Components
-
-- [Next.js App Router Update (dev server, docs, etc)](https://nextjs.org/blog/june-2023-update)
-- [Why do Client Components get SSR'd to HTML?](https://github.com/reactwg/server-components/discussions/4)
-- [Remix + RSC POC](https://twitter.com/ryanflorence/status/1663587026384584704)
-- [Redwood: All in on RSCs](https://community.redwoodjs.com/t/redwoodjs-next-epoch-all-in-on-react-server-components/4967)
-- [React WG - RSC from Scratch. Part 1: Server Components](https://github.com/reactwg/server-components/discussions/5)
-
-[02:08] **Mark Erikson:** Nice. Kind of a similar theme, so general big picture news. The biggest topic of discussion that I continue to see in between Twitter and Reddit and wherever else is React Server Components. And there's been a few pieces of information as far as technical updates and helping people understand how they actually work.
-
-[02:31] First off the NextJS folks put up a blog post that gave an update about the NextJS app router and its current functional status. Why they built it, how it supports incremental adoption. It's stable, but they are still working on improving it. They talked about some of the plans they have for improvements, like improving the speed of the local development server, working to make fast refresh faster using the the Turbopack build tool and getting that from beta to production ready.
-
-[03:07] They also talked about trying to improve the docs. They've done a lot of work over the last year to improve the NextJS docs specifically. We'll talk about this more in a little bit, so there really aren't, isn't any documentation about React Server Components in the actual React Docs.
-
-[03:25] The only real official documentation you can find is in next's documentation site. So the blog post talks about like, we're, we're working on that as well. There were a couple other pretty good related links. Dan Abramov has a discussion thread in the one of the React Working Group repos that talks about why client components get converted to html.
-
-[03:49] He also did a very long, deep dive thread, which to be honest, I still haven't even had time to read through where he tried to rebuild the function and some of the basic functionality of React Server Components. From scratch, and I've seen a lot of folks say that this was really helpful in understanding the mental model as well as the technical details of how Server Components work.
-
-[04:13] And I think I've seen a, a couple people try to take the information that Dan wrote in this article and turn it into tutorial videos as well. And then I know that a couple other React related frameworks besides next are looking into using Server Components, and that includes both Remix and Redwood.
-
-[04:37] And then there's at least a few other folks experimenting with Server Components in different ways. Daishi Kato, who's the maintainer of the Zustand and Valtio and Jotai libraries has been doing his own little spin on a server component based framework. So there's a lot of motion going on around the ecosystem in relation to Server Components.
-
-[04:59] **Carl Vitullo:** Yeah, definitely a lot of motion. I hadn't seen the Redwood discussion of Server Components. And I tried to check out Remix Server Components proof of concept, but it doesn't look like there are very many details there at all yet. That, you know, proof of concept tweet from Ryan Florence is just a, you know, it's just Lighthouse, like, cool, okay. I guess it works well, but what, like, what does it look like?
-
-[05:22] **Sebastien Lorber:** There is actually a few links that you can find on on GitHub with repositories where the, the implementation is being worked on. So you can follow this on on GitHub. I don't think it's Ryan Florence for working on it, I think it's Jacob Parish or something like that, that is working on on this implementation.
-
-[05:40] **Carl Vitullo:** Yeah, I guess that makes sense. If you're trying to follow along the implementation, tracking the GitHub directly is where, where that actually happens.
-
-[05:46] Yeah. More, more drama, more resources, more details trickling out. Server Components are definitely still actively evolving and I guess they probably will be for a while still.
-
-[05:57] **Mark Erikson:** We'll get to that part when we circle back around.
-
-[06:01] **Carl Vitullo:** Yeah. Cool. Yeah, I hadn't seen the React Server Components from scratch.
-
-[06:05] That's a, that's a really good resource. That reminds me of Dan Abram's talk. What was it? React in an alternate dimension. Looking at IE6, so definitely feels like he's trying to anchor the React Server Components conversation, sort of going back to fundamentals, like not chasing trends, not sort of saying like, "here's where the path has evolved. Here's the current state," but saying, "let's look back at what web development used to be. Let's look at what it is right now. Let's try and find a, not just a local maximum, but maybe a, you know, universal maximum."
-
-[06:38] I guess I appreciate that framing a lot. It's nice to not just be reactive and see this is what people have been doing recently, this is how the community and ecosystem are evolving, but really trying to go back and say, "okay, this is what we're trying to build. How does that make sense in the current moment, and how does it make sense in previous moments as well?"
-
-[06:59] So I I, I like that. You know, I, I've said that I defer a lot to the React core team because they have not let me down to the past, and I like that. I think that's a good framing and I feel pretty good about the direction that that suggests to me.
-
-[07:14] **Mark Erikson:** Dan's teaching style has always been very much from first principles, like first I will explain the concepts and why they matter and how we arrived at them, and then I will explain the technical details.
-
-[07:27] You can see that in the original Redux tutorials, you can see that in the rewritten React Dev website. And so, yeah, like I'm, I'm just now finally skimming that Server Components from Scratch article, and I can, I can definitely see that same mindset at work, which is good. Like I, I've always found it's useful to explain a problem and then explain the solution to the problem now that you understand why it's there.
-
-[07:52] And I, I think this is a really good post.
-
-[07:54] **Carl Vitullo:** Sebastian, you wanna take us off?
-
-# Skew Protection on Vercel
-
-- [Vercel - Introducing Skew Protection](https://vercel.com/blog/version-skew-protection)
-
-[07:56] **Sebastien Lorber:** Yeah, I wanted to talk about something Vercel released recently. They called it Skew Protection. And I found it interesting because somehow it solves a problem that I had in the past. Where you deploy your new version of your software and then when someone loads a, a website in the browser, they don't always refresh the page, so they, they may have a stale client app locally, and you deploy a new server version, and then there is a mismatch between the server and the client. And somehow Vercel released something recently that permits to, to mitigate this problem.
-
-[08:33] So the idea is that if you have a still client running locally, it'll try to use the server code that match that, that client version. And they can do that because they do some routing on on their infrastructure based on HTTP headers. So the idea is that if you do a breaking change during a deployment, it might not generate errors and they just added this to the last NextJS version. So you can just add the flag to the config and this will be enabled by default.
-
-[09:07] **Carl Vitullo:** Skew protection. Definitely interesting. Definitely a problem I have run into in my career. This has been a problem I've especially noticed on Netlify because they only serve the assets for the most recent deploy.
-
-[09:19] So how I've seen this present is somebody keeps a tab open. You know, the app we have shipped is split into multiple bundles. So then they, they can click around, they can keep navigating within the app for all of the JavaScript they've already loaded. But then they try to go to a new page. It goes to fetch the bundle, the bundle 404s, and then something breaks catastrophically.
-
-[09:41] So how we fixed that on teams I've been on in the past was we set up a 404 javaScript bundle that would just do, you know, browser reload, which it worked. It's fine. It's a little janky. That's led to situations where like if we have state that somebody's entered into text inputs or whatever, that gets lost.
-
-[10:00] So happy to see a more graceful implementation here.
-
-[10:04] **Sebastien Lorber:** Yeah, what is nice, some of our examples just showed the case where you call an api, like you submit a form or something like that, and there is a mismatch between the payload and the, the serverless function. But apparently it also works with the static assets.
-
-[10:19] So if you have a code split app with a prefetching and basic code loading, you should be able to to, to fetch the appropriate bundle to the appropriate immutable deployment. And if you keep your tab open you have like 24 hours of transition, so that you can still access the older deployments.
-
-[10:39] This also present some security concerns apparently because for example, if you have a vulnerable deployment in the past this gives the ability of data here to eventually keep using it, using using HTTP header. So there's a trade off.
-
-[10:54] **Carl Vitullo:** Huh, interesting. Okay. Yeah, a 24 hour grace period for refreshing a tab seems a lot better than nothing.
-
-[11:02] I had always wondered why this wasn't a problem that was solved at the level of the hosting provider, because, you know, it, to me it looked like kind of a bug. You know, I, okay, yes, immutable deployments, but like, it's not that those old assets don't exist anymore, it's just they're not the freshest.
-
-[11:17] So, you know, when I, when I've controlled a server in the past, like I only cleaned up old artifacts every now and again. So, yeah. Interesting though. Cool to see a hosting provider bring it.
-
-[11:28] **Sebastien Lorber:** If you use Netlify for example, there was a way to, to mitigate vita this as well. For example, you could use the net cash and you can keep the previous static deployments in your cash and then merge them with the new deployments so that you get, somehow you keep the old assets and then add the new assets to provide the old assets. And then both remain accessible. So this is not ideal, but at least it was a, a solution.
-
-[11:57] The problem is that you sometimes had to clean up the deployment because it's it would keep growing forever if you don't do the cleanup someday.
-
-[12:05] **Carl Vitullo:** Never want unbounded growth. Cool. Well, I'll take us on.
-
-# React Native 0.72
-
-- [React Native 0.72 - Symlink Support, Better Errors, and more](https://reactnative.dev/blog/2023/06/21/0.72-metro-package-exports-symlinks)
-- [Fabric Renderer](https://reactnative.dev/architecture/fabric-renderer)
-
-[12:09] **Carl Vitullo:** So React native had a new big version put out, version 0.72. The highlights were symlink support in Metro, better errors and developer experience, and some more. It looked like a lot of the "more" is sort of finer points related to. A new architecture. They, you know, they had New Architecture in title case all over this post.
-
-[12:35] So it looks like this relates to the new architecture and React Native, Fabric, which I guess is a new renderer, new core technology for how the apps get put on the phone.
-
-[12:48] **Sebastien Lorber:** Fabric is a new renderer for the new architecture. There are multiple pieces to the new architecture and Fabric is the, is the new renderer.
-
-[12:57] **Carl Vitullo:** Okay. Yeah, so, you know, my, my reading of this news here, they have a new interop layer that makes that new architecture more usable for, a wider range of people who are on older versions of React Native. I saw that it's, you know, they're intentionally not doing a hundred percent coverage right now, just focusing on common issues. Common compatibility. Yeah. Cool. Awesome to see it get better developer experience because that's always been my largest pain point when trying to use
-
-[13:25] **Sebastien Lorber:** it. And also the, the new metro features will be super useful. For example, the symlink support was requested for years. I think it's maybe the oldest issue in React Native.
-
-[13:37] So we are happy to, to finally have the ability to, to use a manual report without having to, to plug any extra config to make it work.
-
-[13:47] **Carl Vitullo:** Yeah. Very nice. Very nice. Yeah, and I see some other little smaller developer experience changes, like not failing on style errors. If you give it a bad style prop, it doesn't blow up anymore, so that's nice.
-
-[13:58] You know, low priority errors not interrupting your workflow is always good.
-
-# Social Dimension of React Server Components
-
-- [Is React Having An Angular.js Moment?](https://marmelab.com/blog/2023/06/05/react-angularjs-moment.html)
-- [Related tweet form Joel Hooks](https://twitter.com/jhooks/status/1670147458360569856)
-- [Next canary broke Apollo and RTKQ](https://github.com/apollographql/apollo-client/issues/10974#issuecomment-1594894341)
-- [React-Query trying to add “use client” and struggling](https://twitter.com/TkDodo/status/1673401744087195657)
-- [Seb describes the `”react-server”` export condition](https://twitter.com/sebmarkbage/status/1673419412144025604)\*\*
-
-[14:02] **Mark Erikson:** Okay, Carl, please prepare to begin pasting and links for this one.
-
-[14:06] **Carl Vitullo:** Uh oh. Uh oh!
-
-[14:08] **Mark Erikson:** Okay, so a minute ago we talked about the kind of the technical news around React Server Components, and then there's the social aspect, which is that there is still a ton of confusion and concern in actual real, no kidding pain points around the rollout of Server Components.
-
-[14:30] The behavior of next. React's versioning and how existing libraries in the ecosystem are supposed to inter-op with all this stuff. , I've, I've been collecting a whole bunch of links and I've actually been forwarding a lot of these over to members of the React team to give them an indication of, "look, these are all the problems people are experiencing, or at least feeling right now. You need to be aware of these so that you can figure out how to actually like, improve the marketing, improve the docs, and address the problems that people are having."
-
-[15:10] So let's, let's roll through a few of those. There was a post that came out entitled, " Is React having an AngularJS moment?" And the background on this for people who weren't around 10 years ago Angular JS 1 was very, very popular for several years, and then the Angular team announced Angular 2, which was effectively a completely different framework, but just using the same name.
-
-[15:39] And the initial announcement was that there would be no migration path to go from Angular 1 to Angular 2. And this killed much of the Angular ecosystem at the time, and it coincided with React coming out. And so in 2013, 2014, a lot of teams said, well, if we're gonna have to rewrite our app anyway, let's just switch from Angular 1 to React instead.
-
-[16:05] And so, a number of people have made this comparison that the rollout of Server Components is like an Angular 1 to 2 transition for React. Now, the React team has pushed back on this idea and pointed out that, you know, we're, we're not killing any of the, the existing client component capabilities. We're we're adding more functionality to React.
-
-[16:31] So in some very real ways. The comparison is a no, but it's also true that there is no migration path that I've seen right now to add Server Components to an existing app unless you're using Next and you start switching over to using the app router, et cetera. So there is a very real feeling of this shiny new thing is being dangled in front of us.
-
-[16:59] And we're being encouraged to use it, and yet many of us cannot. So there's, there's a feeling of being blocked there, even if the technical details are, are somewhat in between and hazy. So the article came out, and then there was one specific, Twitter thread, started by Joel Hooks from, from Egghead.
-
-[17:20] Who was discussing it. And that led to a ton of sub discussions. And I, I got involved in that thread halfway down and actually ended up having a bit of an argument with one of the React team members about, you know, things like defaults matter and, you know, there's, there's missing docs for a lot of these things.
-
-[17:39] And a lot of other people were participating in that thread as well. And it's just an example of the kinds of, Frustrations that I'm seeing echoing throughout the entire ecosystem. So that's one side of things.
-
-[17:53] Another is that a recent Next pre-canary test release broke a couple libraries like Apollo client and React Query, and they reverted that particular change, but the implication and that I'm getting out of it, is that libraries that want to be able to interact with Server Components in some way, basically need to add an entire new bundle file to their packages and specify a new export condition called React Server, so that when the React server component bundler tries to load your library, it finds an extra special version of your library that has all the client code stripped out so that it's not sending extra pieces over the wire.
-
-[18:46] The problem is this means a whole lot of extra work for library maintainers like us. And while there's been some discussion about this on GitHub and Twitter, none of this is actually documented yet.
-
-[18:58] So Lenz Weber, who works on both Redux Toolkit and Apollo client, and myself and Dominik Dorfmeister of React Query have all expressed our frustration with, you know, the fact that our libraries are now breaking and we're being forced to do this extra work, but there isn't even documentation for it yet. So there was, there was a very long discussion thread over in the, the Apollo repo There's been discussion on Twitter.
-
-[19:26] Dominik has a PR up where he is trying to add this new export condition to React Query and Sebastian Markbåge is trying to give some advice. So it's, it's, it's a very frustrating time for library maintainers as well. And then on top of that just within the last week or so, there's been a lot of discussion about versioning.
-
-[19:48] So the current stable version of React is 18.2, and it's been out for over a year, and there's no indication of when an 18.3 or even an 19.0 will come out. Well, it turns out that a lot of the functionality that Next uses in the App Router only exists in what's known as these Canary builds of React. So React has a bunch of internal feature flags.
-
-[20:17] And they put out the stable builds, which have a lot of those feature flags turned off. There's the narrow builds or in experi in the daily experimental builds, which have many of these feature flags turned on. And so if you're using the app router next actually ignores whatever version of React you have listed in your package, J S O N.
-
-[20:39] And instead they use one of these canary builds of React. That has the extra special functionality. And the problem is that right now there is no documentation whatsoever on what features are even turned on in one of these canary builds. And there's no way for a library maintainer to know, okay, well you're reporting a bug with our library, like our, our, our library, but we don't even know what version of React you're using.
-
-[21:09] And, and or we don't know what features we should expect to be available in React when you're using like next in the app router. So there's both frustration from maintainers where we don't know, like the React team isn't documenting, here's what's available for you to use. What are the stability of these APIs?
-
-[21:30] What, what canaries have, what features turned on? And then there's also an argument about (exhale) React wants to be able to try out these new features. A lot of these features are expected to be used by frameworks like Next and Remix. And so the framework can kind of like add a layer of protection on top of those.
-
-[21:52] And even if the features aren't a hundred percent done and they change a little bit over time, the framework can put in effort. To keep them from breaking users applications, but what does that mean in terms of semantic versioning and publishing the libraries? So there was, there was a lot of debate about what is the right way for React to put out these features so people can try them out versus semantic versioning versus framework usage.
-
-[22:22] So it's, it's all very, very confusing right now. I will say that I've, in addition to all the public debate, I've, I've had some messages on the side with some React, some, some kinda like non-public React team members who are explicitly intending to work on core documentation for Server Components and wanting to work on.
-
-[22:46] How to docu, like how do we document these canary builds? Can we do something similar to like the TC 39 stages process where we say, you know, we've got these 15 features. Some of them are just an idea. Some of them we have a proof of concept. Some of them are already ready to go and hopefully be able to like apply that as like a, a matrix or a table or something to all the different canary builds maybe.
-
-[23:12] But Right. As of right now, none of that information exists, and it's very frustrating.
-
-[23:17] **Carl Vitullo:** Yeah. Right. And I, I think another aspect that you didn't even mention in all of that (laughter) is that like, it's already so hard to publish a library correctly because the ES module ecosystem has been such a nightmare.
-
-[23:33] **Mark Erikson:** Oh, don't even get me started.
-
-[23:36] I, I was flying back from React Summit a couple weeks ago. I've been threatening to write a blog post for the last few months about, look, I've been suffering through trying to convert the Redux libraries to e sm. I'm finally going to write, I'm going at some point, I'm going to write down all the stuff I've learned and tried and bang my head against.
-
-[23:53] So I wrote half the blog post on the flight back. It's 4,000 words long, and I still need to sit down and write the other half of that. And I even had the redwood folks ping me and say, Hey, you've, you know, stuff, something about this e sm transition, right? Can you help us? I'm like, I'm not sure that I'm the person to help with this.
-
-[24:13] **Carl Vitullo:** You're the expert, Mark.
-
-[24:14] **Mark Erikson:** No-oooo.
-
-[24:16] **Carl Vitullo:** (laughter) yeah. So I mean, it's already. Very difficult because the ecosystem ha is still reeling from the effects of the last major, you know, bifurcation of package authoring. I guess connecting this back to what I was talking about earlier with the StackOverflow and representation of React as a, you know, portion of the overall tech world and you know, it's something, it's like 60% of respondents are using React or something like that. So like the tech world is enormous. React's influence on it is enormous. The ES modules nightmare is still not over.
-
-[24:54] **Mark Erikson:** Oh, it's still going on, trust me.
-
-[24:56] **Carl Vitullo:** Well, you know, Mark, maybe you can end it finally at long last by finishing your 8,000 word blog post about how to, how to integrate it correctly.
-
-[25:04] **Mark Erikson:** (ironic laughter)
-
-[25:06] **Carl Vitullo:** (real laughter) But yeah, so, I really feel like your, your frustrations here around trying to be a library author, dealing with this transition gracefully and correctly, and feeling like there's no good, like, like there is no way to do so, like, it's an impossible path. Yeah. That's, that feels very real.
-
-[25:25] **Sebastien Lorber:** I, I don't think it's bad for Vercel and NextJS to use the canary version, but the problem is, maybe it's just a documentation problem, I, I mean, it's a good way for them to, to have a quick feedback loop and have some adoption somehow.
-
-[25:40] It reminds me of what we had with Docusaurus too, you know, that it took a long time to release. And the fact that the community adopted the alpha versions gave a lot of feedback because we had a lot of download on, on this version, and many used it in production, including Redux, I think.
-
-[25:59] I know that it produced some pain because we did some breaking changes, but at the same time it provided a ton of feedback, that permitted to refine things. There's a trade off for the NextJS team to, to find between being stuck, not being able to reiterate fast because their software has come somehow, too related to, to React new features to evolve independently. So they need to iterate on, on both of them at the same time.
-
-[26:25] And. If they do that, then the community is a bit confused because the two versions are related and not everything is properly documented on the React side. And if they don't do that, they will be much slower. For example if they need a, a React core feature in to, to do something in NextJS.
-
-[26:47] This may mean that we need a new version of React and Uneven NextJS can use it and uneven we can get feedback because the community is using the new version of NextJS That is using the new version of React. It's a much longer feedback loop, and it's not good for the community to take, to have things, being slower. So, I mean, if it's a bit more painful in the short term, I think it's better to, to have this quick, , feedback loop somehow.
-
-[27:16] **Mark Erikson:** No, I definitely agree with that. I'm like, as a library author, I'm very sympathetic to, like, I've made changes I want people to try it out and, and actually give us feedback. I, I wish we got feedback for the Redux office in beta. But the, the fact that there is no documentation on what any of these, like what these new features are and which Canary build actually have certain features turned on is, is very frustrating.
-
-[27:44] **Carl Vitullo:** You know, like, okay, bundling a library is difficult. Publishing it correctly so it can be consumed is difficult. It seems very frustrating, but it does make sense to me that like the documentation for that, It's not stable yet.
-
-[27:56] **Mark Erikson:** Nonexistent is the problem.
-
-[27:59] **Carl Vitullo:** It's not surprising to me that the documentation for that bundling and publishing concern is not existent. It's confusing to me that the, that there is no documentation for what feature flags are enabled in a specific canary release. Like that seems like a very routine part of publishing a canary package. Like if you can't, if you don't know what's in it, how can you give feedback about it?
-
-[28:20] So, I guess that suggests to me that they, that there's a pretty heavy reliance on like, backchannel communications. And so, you know, the, the 10 people who participated in creating this canary release, they already know what's in it, so they don't need the documentation.
-
-[28:34] And so it feels like that's who the audience for these canary releases are. The people who are already in the room.
-
-[28:40] **Sebastien Lorber:** When you say feature flags, do you have a particular feature in mind that could be activated in the canary?
-
-[28:47] **Mark Erikson:** Well, oh yeah. Like, like the, the `use` hook.
-
-[28:50] You know, the, the React team published this RFC about this new use hook that's supposed to let you unwrap promises like a year ago. And the use hook then, or the use RFC mentions an upcoming cache or an upcoming RFC for some kind of cache component or API and says more details will come later. And the use RFC discussion, 95% of it was, well, people don't like the name, slash what kind of value are you allowed to pass to this either now or in the future?
-
-[29:22] And it went silent. And so as library maintainers who would like to integrate with suspense? Our assumption was, well, nothing is happening with this RFC at all. And then Next comes out with this in the app directory, and they, and suddenly they're telling us that, oh yeah, the use hook is ready to go. You like we either we use it internally or you can do something with it Next. And something something.
-
-[29:45] And we're like, wait, what you're, you're telling us that's usable? What about the cash thing? That never materialized. And, and so like we, we just have no idea where things even stand with that stuff.
-
-[29:58] **Sebastien Lorber:** I understand that at, at the same time, somehow the, the hook is not documented in NextJS also, as far as I remember.
-
-[30:06] For the end user, they are not supposed to, to even use it. So the end user, the app developer shouldn't care about if the feature is enabled on the direct canary flag or not, because, this is used only internally. So the problem is more that you as a library author, can't try the new things because they are not documented.
-
-[30:29] But I, I don't think it's a problem for the majority of users. It's more like that, you can't start working on, on the new cutting edge things now because you are, you don't have the same back channel with the React team. So, I, I see some auto, two different problems. It's one for framework authors and library authors, and another for the end user.
-
-[30:52] I don't think adopting NextJS With Canary release for the end user is a big deal today, apart that there are a lot of bugs that are reported, but they will be fixed. But the, I don't think the end user need to know much about all these new things that are not documented.
-
-[31:10] **Mark Erikson:** Yeah. The, the flip side is that we, we do see a lot of our, our users asking like, you know, can I use Apollo React query, RTK query with suspense?
-
-[31:22] And there's clearly a lot of interest in doing that, and we really don't have an answer for how you can do that yet.
-
-[31:29] **Carl Vitullo:** I have one more thing I wanna pull in. Sebastian posted a very short little Twitter thread. I'll just read some snippets from it.
-
-- [Sebastian Markbåge, "Who owns the direction?"](https://twitter.com/sebmarkbage/status/1673767392369844236)
-
-[31:36] "When a community of consumers grow large enough, it's interesting what happens with ownership. I think there's an argument to be made. It's that at some point the community bought into something and you can't change that from underneath them. They own what they bought into. From that perspective, if we as maintainers want to go a different direction, we should have given it a different brand, even if it's backwards compatible."
-
-[31:53] I think that's very directly talking about all of this React Server Components drama and positioning, he posted those yesterday, about 24 hours ago. I, I'm looking forward to seeing where that may have echoes on. How the React Core team is thinking about React Server Components.
-
-[32:13] And tying it back to, you know, where we started on this with comparisons to Angular 2. Like, okay, maybe this is not an Angular 2 moment for React, it is fundamentally backwards compatible, they are engaging with, you know, maybe not engaging perfectly, but they are making good faith efforts to include stakeholders in the conversation. Yada, yada. But I think this is maybe an early signal of a change in approach and yeah. Interesting to see how that shakes out.
-
-[32:41] Okay, now we can move on. We've beaten it fully into the ground. Sebastian, you wanna introduce our next link?
-
-[32:47] **Sebastien Lorber:** Yeah, it's a quick one. I, I noticed that we are both on the jury of, , React Jam, so I didn't know, but, , that was a happy surprise.
-
-[32:57] So this is a contest where you create a game with React. And I think it it'll be nice if the Reactiflux community wants to participate. So we'll be happy to review your React games in I think next month maybe.
-
-[33:13] **Carl Vitullo:** That's a good call out. Sebastian and I are both judges for a hackathon around developing games using React and web technologies.
-
-[33:22] I think it's happening on July 20th through 30th, so it's 10 days long. As judges we will be given the, you know, I think it's gonna be 10 candidates and then we grade them. I'm excited for it. I think it'll be fun. We've done a couple of Office Hours and interest in video games has been a very common theme on what got people interested in programming.
-
-[33:43] So if that's you, if you are interested in developing games yeah check out React Jam and maybe you'll have me and Sebastian play your game.
-
-[33:52] **Sebastien Lorber:** Yeah. (chuckles)
-
-[33:53] **Carl Vitullo:** Cool. My, my next link here, just a kind of small update. We talk a lot about Next and I feel like Remix maybe gets a little bit short shrift, but I see that they've got a, a new V2 development server that has some relatively large changes to the, some of the core assumptions around Remix.
-
-[34:12] Most notably, it looks like this totally swaps out the semantics around routing. The big comparison that I saw, you know, front and center of this announcement was previously Remix, inferred what routes your pages were on based on the folder structure, with, you know, templates and wrappers and things like that.
-
-[34:33] Now that is purely based on the file name. So instead of the folder hierarchy being reflected in the routes, it's Using. A different mechanism for determining conceptually what's a folder, what's what looks like a folder in the url. That's a pretty big shift.
-
-[34:48] I am interested to see them roll this out because it is such a large change to the everyday development experience of using Remix. So yeah, and seeing like a sub component of a framework, being given a new major version is interesting to me. We just talked a lot about Server Components and the versioning and the struggles of rolling that out.
-
-[35:11] So here's a different example. Smaller, you know, obviously Remix is inherently a subset of React usage, so it, the, the ecosystem is inherently smaller, but yeah, interesting to see another approach to making a major revision to floor behaviors.
-
-[35:28] **Sebastien Lorber:** It's quite interesting that they have implemented future flags to enable V2 features in Remix version one.
-
-[35:36] And I've also seen this this new flat routing convention that they implemented. There also great article that already tried to use this new feature about the ability to create somehow your, your own Remix routing convention.
-
-[35:53] So the, the idea is that you can create your own convention, read the files on the file system, and then eventually create the route you want for that file system secure. And so this gives a lot of flexibility. On Docusaurus, we already have a quite similar thing.
-
-[36:09] We have a concept of autogenerated sidebar. And it gives the ability also to, to create somehow a tree. And we give the, the ability to customize it.
-
-[36:20] Also, they recently released the, the last version of Remix with dev server version two. So as far as I understand, I think the idea if I remember correctly, is that if you change code in the Remix loader, you will also have the hot reloading experience that you expect. While it was not the case before.
-
-[36:41] **Carl Vitullo:** Nice.
-
-[36:41] Before we jump into Lightning Run. So, Sebastian, do you have more links? You wanna do a full discussion on?
-
-[36:45] **Sebastien Lorber:** Yeah, I think it's worth mentioning Panda CSS. It's a new CSS-in-JS solution, , that use a static analysis to, to do many things with with no runtime. Actually, I'm not sure it's completely without any runtime. I think I read there is a very little runtime, but I'm not sure. Now today, the, the devs are like tailwind, css a lot. And there are good reasons for that because you can copy paste code easily and you can also delete code quite easily and, and things keep working.
-
-[37:18] So this is a very interesting property. At the same time, Tailwind CSS get a lot of criticism for, for the very long class names. It looks a bit messy for people that don't approve to, to this way of thinking. And Panda that CSS could be a, a greater alternative to, to Tailwind. It looks quite interesting and it's from the chakra UI team.
-
-[37:43] I think the Quik framework is also trying to adapt it because they are building integrations and making it work in Quik already. So I think it's a tool to follow and we'll see how the community adapt it. But it looks like like one of the most promising CSS-in-JS solution today.
-
-[38:04] **Carl Vitullo:** Cool. Very neat. Oh, I just opened the webpage and the CSS has broken. Haha, not a ideal. Yeah. Interesting though. It's been a, it's been a minute since we've had new CSS-in-JS strategies come out, so I'll have to dive in compared to this and. See what it's introducing.
-
-[38:21] Cool. Okay. Let's go to, let's go to a lightning round. Mark, take us away.
-
-[38:27] **Mark Erikson:** Okay. Two things real fast. One is that ever since function components came out, there were a couple things that they could not do that class components could. One of those was defining an error boundary to catch errors that are thrown while your component is rendering.
-
-[38:44] You still had to use class components to write one of those. There is a PR up that adds a new catch component to React that would basically eliminate the need to use class components for error boundaries. I haven't looked in detail at the api, but there is some form of early EPR up for that.
-
-[39:03] So hopefully we'll get that in the next meaningful release. Also, I had filed an issue a couple months ago. Saying that as good as the new React docs are, they really need to add a page on how to use TypeScript with React and Orta Therox, who's been very involved in the TypeScript website docs just put up a PR that adds that page.
-
-[39:27] And I, I skimmed it right before this, this meeting, and it looks fantastic. So I'm, I'm very, very excited to see a React Docs page saying, here's how you use TypeScript with React.
-
-[39:39] **Carl Vitullo:** Definitely a frustrating experience a little bit. I feel like every time I come back to it after a, a little while away, I need to find some cheat sheet to be like, wait, what am I supposed to use? What am I not supposed to use?
-
-[39:50] So I guess that segues nicely into another one, but React.FC is no longer viewed as an anti-pattern for typing React components. Nice to see that, and nice to have documentation on how to use TypeScript with React. Cool.
-
-[40:05] Sebastian got any lightning rounds?
-
-[40:07] **Sebastien Lorber:** This week in the React Native ecosystem we had we saw a lot of quick demos of running the latest version of React Native on VisionOS the SDK for Vision Pro from Apple. And I found it interesting. I don't know how it works exactly, but apparently the, the React devs had fun with it, so it's already working.
-
-[40:28] I know it's it's already working for, for Flutter too, so maybe it was a simple thing to do, I don't know. There are also pull requests to, to add a support for vision or in Cocoa Pods. So I guess it'll become easier to, to add support for our VisionOS in the future in React Native applications.
-
-[40:47] **Mark Erikson:** I ran across a website within the last couple weeks called the React Handbook. And I haven't even had time to go through it fully in depth, but it's, it's like an overview and guide to the React ecosystem. Common problems like state management and data fetching and it tries to give some advice on what libraries to use and how to work with things.
-
-[41:09] And I had actually tried to, to get a similar kind of ecosystem overview guide website started a couple years ago. And I, I put up a proof of concept page, had some discussion about what I wanted this site to be, but I never got other folks in the community to spend time helping fill out the content. So this React Handbook looks very similar to the kind of idea and the kind of resource that I wanted to help build for the React community.
-
-[41:37] And I'm actually still supposed to talk to the primary author of this site about, you know, here's some of the ideas I had and maybe we can like, sort of join forces and help build this one out more.
-
-[41:48] **Carl Vitullo:** I know it's lightning around, but that also reminds me of us of our Reactiflux learning page, which has, which you curated with a ton of resources. So yeah, looks like a good resource.
-
-[41:59] My next lightning round Chrome for testing, reliable downloads for browser automation. Browser automation's really tough. Puppeteer kind of sucks. Playwright I hear is better. Cypress I have used successfully, but have always run into difficult edge cases, so having a blessed browser version specifically for testing. I see this is titled Chrome for testing. Like heck yeah. That's awesome. This is possibly an absolutely enormous level up for the testing ecosystem and maybe we'll start getting real movement on problems like visual regression tests, which I've seen probably a dozen attempts at companies trying to solve that problem over my 10 years as a web developer.
-
-[42:42] **Sebastien Lorber:** Quick link would be shadcn UI, I don't know to pronounce Shadcn, but You probably heard of this trending library recently. It released recently a new CLI that permits to bring a great developer experience on top of the React component, collection because it's not a library, it's a collection of Tailwind and Radix components.
-
-[43:05] I was quite impressed somehow in the beginning I didn't understand really the value of this library because somehow it looks like just a registry of of code that you can copy paste. Somehow it's bringing a CLI to, to be able to update the components, eventually use artificial intelligence features to it so that you can type a prompt on the CLI and it'll update the component according to what you, you say you want to do.
-
-[43:33] **Mark Erikson:** So at my, my, I, as I said earlier, my day job is working for Replay io and we're building a time traveling debugger for JavaScript. And we just announced something we've been building for the last six to eight months called Replay for test suites.
-
-[43:48] And the idea is that, You know, lots of companies have Cyrus or playwright tests. You run them in CI, but often either they flake, you know, they, they fail unpredictably 10% of the time. Or if a test fails in CI, you have no way to go debug what happened to that test. And so what we've announced is that we have the ability to change your test running setup to record all the tests that occur. And then if a test fails, you can open up the recording and time travel, debug that recording. So we, we, we just announced it we're, we're doing a wait list thing. We're gonna be doing some, some onboarding of teams to, you know, try it out and make sure that what we've built actually works.
-
-[44:36] But I'm, I'm really excited about this. Like, the amount of time I've spent trying to figure out why end-to-end tests are failing is absurd. And we're talking to companies that, like, they routinely waste tens of thousands of dollars on Amazon costs when tests fail and they have to go rerun the whole thing.
-
-[44:52] So I'm, I'm excited for something that will help, help teams fix their tests and run them consistently. Something else that I've been doing myself. So earlier this year I, I built our own, our integration of the React dev tools for Chrome by doing backend post-processing of the recordings to extract the data.
-
-[45:18] And we have officially turned that on. And just a week ago I shipped a major new update for it that actually improves on what you can do with the reactive tools browser extension, so the real React extension in the browser. If you record a or if, if you're looking at the website of a production app, you're going to see minified component names.
-
-[45:44] And what I've figured out is using time travel debugging, I can go look up the original files and find the original component names and show those to you when you debug a React app in a recording. So you can go from, you know, minified names like xz to the original name, like to-do list item in the recording.
-
-[46:06] So I'm really excited about that. And then just yesterday I was hacking on a proof of concept feature that would be able to to look at a React and Redux app recording and pull out information like, here's all the times your selectors ran, here's how long it took to update the ui. Here's like, which selectors were expensive, and hopefully give you like some performance optimization information.
-
-[46:32] **Carl Vitullo:** My last lightning round link here Vitest 1.0 roadmap has been shared. I'm using Vitest. I think it's great. I enjoy it. It's very quick. Runs my tests.
-
-[46:43] I'm very happy with it. I was always a little frustrated with Jest and it's, you know, parallel configuration. Just one more thing to configure and set up. Cool to see it have a roadmap for getting to 1.0. Excited to have that land.
-
-[46:55] **Sebastien Lorber:** Yeah. So my last link will be the Docusaurus version three Alpha.
-
-[47:00] So this is what I've been working on in the, in the last month, and it includes MDX 2 and React 18 finally. And So if you use the Qru, I'd be happy to, if you can try the, the Canary versions and. And give me feedback if it's working fine or if you have any bugs, then I would be happy to help you do the upgrade if you have any trouble.
-
-[47:25] **Mark Erikson:** Oh, nice. We'll have to carry that out for the Redux docs.
-
-[47:28] Okay. Last item I've got is a whole slew of updates for the Redux libraries. So we've published Redux Toolkit 2.0 Beta, which ha Has some small breaking changes to remove deprecated options. It has improved TypeScript types.
-
-[47:43] It has several new features like some reducer injection and other stuff. I don't have an ETA on when this will go final because we're trying to update all of our libraries, which with a bunch of stuff simultaneously. Actually, the other, the other big thing we're doing with a lot of these is trying to update the packaging to support better ES module common JS interop, which as we mentioned earlier, is a royal pain.
-
-[48:10] But the idea is we're gonna publish major versions of all the Redux related libraries simultaneously. And so I'm juggling like 15 different things in my head trying to keep track of what needs to be done sort of related to that. We just shipped React Redux 8.1, which has dev mode warnings if your selectors accidentally return new values when they should't, which is a common mistake that we see people make.
-
-[48:37] So you can think of it, think of it as kind of being similar to React running, use of effect twice to try to catch mistakes. I've got a PR up that will become React Redux nine Alpha. I don't have it merged yet because there's, there's a couple different packaging issues that I, that I ran into that I need to solve there.
-
-[48:56] And then I'm, I'm on business travel this week, but literally on the flight out here on Monday, I was experimenting with some proof of concept changes to how React Redux manages subscriptions and updates the ui. Sort of inspired by signals or observables. And the goal is to hopefully make it more optimized and update the UI faster.
-
-[49:23] I spent four or five hours hacking on the flight and I at least got something running that passes tests at the moment. But I still need to actually do a bunch of performance testing and see like, okay, this thing that I built, is it actually any better or not? If it works out, it would probably show up in React Redux version nine as a new opt-in hook called use Tracked Selector so that all the existing hooks would, and, and you know, components would work exactly the same as they have, but if you want to make use of this new functionality, there's an additional hook that you could use, which would be more optimized.
-
-[50:05] We'll, we'll see if this actually works out or not.
-
-[50:08] **Sebastien Lorber:** Yeah, I have another one. There is a new AI framework called AI.JSX, and it's using JSX as a composition block and is meant to be integrated in React applications, but it's not a React renderer. So I don't know exactly how it works, but this look like quite interesting to, to study.
-
-[50:30] **Carl Vitullo:** Cool! Okay. Thank you everyone for joining us. One more this month in React. Hopefully we're helping you keep on the cutting edge of the React and web ecosystem. Thanks so much for joining us.
-
-[50:40] Keep an eye out. Next week I'm gonna be talking with a conference organizer for React Rally. Yeah, excited to talk, talk with him. It's a great conference. See you guys next month.
-
-[50:50] **Sebastien Lorber:** Thank you. See you. Bye.
diff --git a/src/transcripts/tmir-march-2023.md b/src/transcripts/tmir-march-2023.md
deleted file mode 100644
index 67956f1..0000000
--- a/src/transcripts/tmir-march-2023.md
+++ /dev/null
@@ -1,514 +0,0 @@
----
-title: This Month in React (March 2023)
-date: 2023-03-29
-time: 10am PT / 5PM GMT
-location: Q&A Channel on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Matt Pocock as we break down This Month in React. A lot of news this month, with a major progress update from the React core team, TypeScript 5.0, and TC39 meeting news. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Matt Pocock](https://twitter.com/mattpocockuk)"
----
-
-
-
-**Carl Vitullo:** Thanks everyone for joining us for this month in React, where we break down the news and what's going on in the React ecosystem over the past month. It's March this month. There's been a lot to talk about. Excited to have Matt Pocock joining us to talk about the new TypeScript five release. [00:16]
-
-And very excited to talk about the React Labs post that the core team put out. I think there's been a lot of work that they've been doing over the past several years, and I think this post has been just really brought up a lot of those things. Excited to see what we can get into. [00:31]
-
-Yeah, Mark and Matt, do you, can you introduce yourself real quick? Mark, can you go first? [00:34]
-
-**Mark Erikson:** Sure. Hi, I'm Mark Erickson. I maintain Redux. I sit around here and answer a lot of questions. I work at a company called Replay, where we're building a true time traveling debugger for JavaScript. If you haven't seen it, please check it out. And I generally show up in React or Redux related discussions across the internet. [00:53]
-
-**Carl Vitullo:** (giggle) yes, you do. Cool. And Matt, can you introduce yourself? [00:57]
-
-**Matt Pocock:** My name's Matt Pocock I am a general TypeScript person I guess. I was a software developer for about four or five years, and it's, feels weird to say was a software developer cause I'm now full-time TypeScript educator. I guess since like December left my job at Vercel and now working full-time, building a TypeScript course called Total TypeScript. [01:15]
-
-I was a React developer for for my career as well. So working with React and TypeScript for about four or five years. But I'm, as I said before, I'm a little bit out of the React ecosystem at the moment, but I'm really excited to hear what's been going on. [01:27]
-
-**Carl Vitullo:** Yeah, we're excited to have you bring some more of your expertise about the TypeScript ecosystem in here. Cool. Yeah, let's jump into it. So the format we use for this we will introduce a link in a round robin fashion, just going around one by one and have open discussion about it for a couple of minutes. [01:44]
-
-## Retire SPA and MPA?
-
-**Carl Vitullo:** So I'll kick us off here. A couple days, weeks ago. Dan Abramov tweeted about, he said, petition to retire terms, Single Page Application, Multi-Page Application, SSR, SSG, they represent the previous generation of I think that's interesting. It's a, we're at a moment of time where, single page versus multi-page application like that was such a strong client versus server distinction for a lot of my career. [02:10]
-
-But it, you know, it feels like the ecosystem is really cooled on the idea of a single page application saying it's sort of an acknowledgement that you can't do everything you need just on the client. And a bit of a return to more of the history of, web and software development where things were much more server based and the application side of things was, I don't know, maybe not raised to quite its own separate entity. [02:36]
-
-Yeah. What do you guys think about that? [02:38]
-
-**Mark Erikson:** There definitely has been a shift in the discussion both inside the React community and outside the React community over the last year or year and a half. Some of it positive, some of it negative. I've seen a few different articles and some of them were in the, you know, This Week in React link posts that have expressed a lot of very strong critique about React in the community and how hard everybody went in on the single page application concept starting around 2015. [03:07]
-
-And, I think some of it is miscommunication and, attributing bad will to, to people when there wasn't any. You know, there's, there's the ongoing difference of am I building a website with pages versus like, am I building a fully interactive application that happens to live in the browser? [03:25]
-
-And so you've got different people building different kinds of programs and yelling at each other when, they turns out they actually have different needs and technical differences. So that's one part of it. But also I think there is the fact that the tooling around things, around the React ecosystem, you know, whether it be next or Remix or server components or whatever makes it more feasible to build server side pieces. [03:50]
-
-I mean, React has had a concept of server side rendering for a long time now, but, If you weren't using next, you had to build a lot of that yourself. And the tooling wasn't there. And to be fair, like I have never dealt with SSR in any of my own projects. My own applications have always been strongly client side. [04:08]
-
-So like I'm kind of sitting off to the side and trying to observe what everyone else is doing. And I can't speak to this from my own experience. But if you look at something like next, even when you're doing server side rendering and or static site generation, it still ends up with the client side interactivity and then you transition from page to page. [04:27]
-
-And it's primarily doing that on the client. So even right there, it has that mixture of behavior. So I can see the point that Dan's actually getting at here is that even with the tools we have right now, there is a mixture. And when you start including things like server components and you know, next new app router in that combination, it is somewhere in between. [04:51]
-
-And the terms don't seem to fully apply the way they used to. [04:55]
-
-**Carl Vitullo:** Yeah, I think that makes sense. I saw that Kent C Dodds proposed the term PEMPAs, which I don't, I don't, I don't think I'm a big of. uh, P E M P A for progressively enhanced multi-page apps. And (sigh) yeah, I, I guess my thought on this is like, maybe the problem is that like we're trying to assign specific terms for all of these different behaviors, really. [05:19]
-
-Like, incremental static regeneration and static site generation and all those, like, to me, incremental static regeneration is just a dynamic site behind a cache, you know what I mean? Like, it's not something I would architect a build process around. It would be an implementation detail of the caching for me. [05:36]
-
-Like it's a performance improvement. It's not a core part of the architecture. So I think maybe maybe a challenging point of friction here is that like we're trying to figure out terminology to describe all of these increasingly nuanced and, I don't know, just very specific ways of writing software. So I don't know. [05:56]
-
-**Mark Erikson:** I'm gonna go kind of meta on this one. Thinking about it just now, I think what we're actually dealing with is a categorization problem. And the problem is we're talking about things as categories, and a thing can only fit into one category, whereas what we're really dealing with is programs have like tags and you can have many tags on one thing, or to put it in software terms, it's, is it class inheritance or is it like, you know, a game style entity component system where it's like, this thing is movable and this thing can shoot and this thing can do x and this thing can do Y, and maybe the problem is that the terminology we're using is only one label, and we really need to be able to apply many labels to a given app. [06:39]
-
-**Matt Pocock:** I think there's there's like two things that I would think around this stuff. I think one of Kent's terms was PESPA, right? Progressively enhanced single page application. A lot of these terms, SPA, MPA, they all have "page" in them, right? "Page" is the unit of fetching the unit of thing that you're caring about. [06:55]
-
-And whether you're doing SSR or SSG, you are really talking about the page is the thing that you are, assessing, but really what Next, and it seems like what Dan is tilting at here, is that instead of the page being the unit, now the component is gonna be the unit. [07:11]
-
-Think that's in general where it seems like things are moving to, and whether you use like nested routing in Remix or something, or whether you're doing, server side components, you still have a concept of a single component being exported from a file and attaching a loader to it, or having that component itself to the data. [07:27]
-
-But I also think that people don't consume the categories, they consume the frameworks that sell the categories right? So you have, for the last five years, let's say — probably since 2015 actually — Create React App has been still the dominant way that people make React apps. [07:41]
-
-We have all of this huge conversation around SSR and Remix and the framework wars and all that stuff, but really it's been Create React App all the way, and Next has only caught up recently. So the fact that, now Create React App is disappearing, it's gone out of the React documentation, I imagine we'll see its usage drop off, and then finally Next and other frameworks can come into its place. I think like really we are consuming frameworks instead of categories, but really the conversation is about the categories. [08:11]
-
-**Mark Erikson:** That makes sense. Yeah. [08:12]
-
-**Carl Vitullo:** Yeah. And maybe building on that a little bit. I think that thinking about this in terms of frameworks and, the project bootstrap process I think is limiting in that a lot of people are using React with a wide range of backends. So, you know, if you're not building a new project and starting, with Remix or Next or something like that, but you know, you're working off a project that has existed for five years and is originally built with Rails or Django or something like that. [08:40]
-
-That category of development feels left out from this conversation to me. And I was thinking about this while I was preparing for this, and to me, I think this is like a Venn diagram of three different categories that each have their own, breakdowns within them. [08:53]
-
-So it's like, when is the content rendered? Is it rendered in advance at build time, is it rendered dynamically, is it totally static? It's never built, it's just always the same content. So that's, that's one category with three options. [09:05]
-
-Then, like, how is it cached? Is it not cached at all, it's fully dynamic, it needs to be rendered from scratch every time it's requested, or is it cached for a long time? [09:13]
-
-And then a more subtle one that took me a second to come up with and then even wrap my head around was, who owns the url? Because , the server owns a lot of URLs, and it, you want the server to respond to these. But then there's the other category where you don't want the server to respond to it. It's entirely within the bounds of your client side app. [09:32]
-
-So I don't know. I was thinking about how I was thinking about what terms I might use, and I came up with those three categories and was just thinking like, okay, if there was a Venn diagram showing all of the overlap between these different components, that feels like it could get towards being a complete taxonomy of development. [09:49]
-
-But, like also every intersection of those would need its own acronym. And if we have, three categories that each have between three and five subcategories, that can all overlap with one or more of each other. Like, I don't think we need 25 different acronyms to describe the totality of it. It's complex and maybe the taxonomy we're trying to build is not super valuable. [10:04] [10:09]
-
-## Create React App no longer officially recommended
-
-**Mark Erikson:** I'm gonna take this opportunity to go to the next point because it actually circles right around to this part of the same discussion. [10:14]
-
-So one of the biggest pieces of news from the last month is that the new React Doc site is finally live. That's the good news. The bad news is that it, it took four and a half years after the announcement of hooks, and it took two and a half years since they announced they were even working on a new doc site. [10:31]
-
-But it is finally live. And it came with some big surprises. One is that there's a new url. The new home is at React.dev, whereas the old site was at Reactjs.org. And for the record, the old docs are still available, but they're now at legacy.Reactjs.org, and they all have, you know, headers saying, please look at the new docs instead. [10:53]
-
-The controversial ish side of the docs announcement, and we've mentioned this in passing already, is that the instructions for "how do I start a new React project" no longer mention Create React App basically at all. And instead the focus is on using a broader, more powerful framework. [11:13]
-
-The first three frameworks that it mentions are Next, Remix, and Expo. And I think there might be one other in there, I'd have to double check. [11:22]
-
-And this is actually brought up a fair amount of controversy. You have and this kind of goes back to what Carl was saying about like different people with existing projects or different people who have different concerns. [11:31]
-
-There are people who are worried about beginners needing a simpler tool set to get started with. And Next is more powerful than Create React App, but it's also more complicated. There are people who have said, "okay, fine, Create React App is dead, but the docs or the installation and setup page should talk about Vite because clearly Vite is superior to Create React App." [11:55]
-
-And so it should be like a replacement in that sense. There are people who are concerned with, " if I use Next, which is now in a sense, the default choice, then I have to have a node server and I have to deploy it on Vercel in order to use it." And neither of those is true, but those are sort of the default assumptions that people have. [12:16]
-
-## React encouraging server capabilities
-
-**Mark Erikson:** And so there's been a lot of discussion and debate and pushback. There were a couple articles going around basically saying that the React team now wants to pretend that single page applications don't exist. And there is a little bit of truth to that because the React team wants people to be using a framework that has server side capabilities. [12:36]
-
-You might start only using the client side stuff, but their stance is, you will want to use the server side pieces eventually, you will want to use routing ,and so on. And using a framework that has this built in out of the box is gonna give you a better starting point. So this has fed into a lot of the debate like, okay, the docs are out, but they're really pushing you towards a framework, especially Next. [13:01]
-
-And there are people who are not necessarily happy about that. And there are folks using, different backends like, you know, C# or Java, that aren't Node, who are concerned about their projects not working well with React in the future in some way. [13:14]
-
-**Matt Pocock:** It's a kind of awkward spot for React, because React is a library and it's always styled itself as a library. But what, what happens when your library starts making demands of your architecture, right? React is starting to say, okay, we are not just a client side thing. I mean, you can use us for client side, but our more powerful features, the cool stuff, it's gonna involve a server. That's the messaging coming out of Dan, too. [13:39]
-
-What happens then when your library starts saying, " To use me properly, you need this certain architecture." I think that's a bit of where my, sort of, strange feeling comes with this and especially when it was like Next Conf for last year when they announced Turbo Pack and the new version of Next, Andrew Clark was there from the React team, who I think now works at Vercel, and he said that this new version of Next feels like the new version of React. [14:06]
-
-**Mark Erikson:** The real React 18, I think, was the [14:08]
-
-**Matt Pocock:** Exactly. Yeah, I was in the room actually when he said that. Yeah, "it feels like the real incarnation of React," which is kind of strange because it shouldn't be tied to a framework like that, but it feels like they're building features which can really only be like made live through through a certain architecture. [14:26]
-
-**Carl Vitullo:** I think another dimension of this is, to me, I think the React team has been very consistent about that framing for a very long time. Like they've always tried to be agnostic to anything you want to be able to do and to provide the best experience they possibly can, regardless of what setting you want to use React in. [14:46]
-
-So, I think that is true that React is trying to influence the architecture that you develop apps around. But I also think that it's not entirely something that they're foisting on the ecosystem. I think it is very much responding to express needs from the variety of teams that they talk to and the variety of teams that they have worked with internally at Facebook. [15:09]
-
-So I'm interested to see how the server components development goes, how that whole rollout works. But like this isn't anything shocking to me because from my reading of all of the conference talks and demos and how they've framed React, this seems very consistent to me. [15:27]
-
-## Three TypeScript 5 highlights
-
-**Carl Vitullo:** Matt, can you introduce TypeScript 5.0 for us? [15:29]
-
-**Matt Pocock:** Yeah, so, well, this is pretty recent, I think, was it like last week or maybe the week before? TypeScript 5.0 is out and it brings a bunch of really cool new features, new optimizations, and I've been actually updating my course total TypeScript with the new stuff literally today. So it's fresh in my mind. [15:48]
-
-And the three kind of headline items are, performance, TypeScript performance has gotten a lot better with this release, and that's due to a lot of internal changes that they've made. [15:56]
-
-Decorators are now supported in TypeScript. TypeScript had support for like an experimental version of decorators to help it support Angular back in the day. But this is the new shiny stuff and the stuff that's actually gonna be adopted into JavaScript. [16:08]
-
-The third one is a new type of annotation for generics, which sounds really, really nerdy, but it's going to, I think, make a lot of really cool stuff that you can do with tap script generics a lot easier, especially when it comes to, passing configuration to components or passing things around, or making abstractions that make your life easier as a developer. [16:27]
-
-This kind of TypeScript knowledge is super, super useful. [16:30]
-
-## TS5 performance improvements
-
-**Matt Pocock:** So, Mark, do you wanna kick us off by talking about the performance things that they've done? [16:35]
-
-**Mark Erikson:** Okay. The TypeScript team did a lot of work on their build tooling and code base structure in the run up to TypeScript version five. TypeScript first came out I think in 2012, so it's been over 10 years. Obviously the landscape of the JavaScript ecosystem has changed and TypeScript itself has changed dramatically since then. [16:56]
-
-TypeScript's own source code is written in TypeScript, but a lot of the organization for that was using an early TypeScript feature called Name Spaces. For TypeScript version five, they wanted to restructure their code to use the more modern ES module syntax. [17:14]
-
-There were a few reasons for that. One was to make use of TypeScript's own features while working on the code, but another was that the way that code got compiled for publishing actually made the TypeScript compiler run relatively slow because of the code that was generated. They figured out that if they restructured the code to use ES module syntax, , the JavaScript engine would actually be able to run the code faster. [17:40]
-
-And the size of the package that they published to NPM would be smaller. I think the version four X packages were like, 50 or 60 megabytes extracted into node modules. And with version five, it's down to like half of that. The module structure changes also literally made the TypeScript compiler run about 10% faster. [18:01]
-
-There was a fantastic post on the TypeScript blog where they talked about the nitty gritty technical details of the changes. One thing that I thought was fascinating actually they did a lot of work to convert everything all over to use the ES 2015, let and const keywords for variables. [18:19]
-
-And then they found out that in some places that actually made things too slow because of how the JavaScript interpreter has to handle those variables and hand replacing some of those with var instead actually got things back to being about 10% faster. So it, it was a fascinating read, and some amazing technical detail. [18:39]
-
-So summary is if you upgraded TypeScript five, it ought to actually do the compilation a little bit faster and it will be smaller to download. [18:47]
-
-**Carl Vitullo:** Yeah, I had seen TypeScript 4.9 was 64 megabytes in node modules, and TypeScript five is gonna be 37 and a half, so like that's enormous. Very cool that they were able to get so much benefit to performance and module size and everything, apparently just from switching to ES modules, I say just I'm sure it was a huge amount of effort to convert such [19:08]
-
-**Mark Erikson:** Massive amount of work. [19:10]
-
-**Carl Vitullo:** code base to Right. Just a such a fundamental change of assumptions, [19:14]
-
-**Matt Pocock:** I saw pr, I think it was like 500,000 change lines or something Crazy. [19:19]
-
-**Mark Erikson:** There was a lot of automatic conversion work going so they can keep it updated. [19:23]
-
-**Carl Vitullo:** No doubt. I can't even imagine how you would begin to audit that the code still performs the same, it doesn't immediately break everyone's code, [19:32]
-
-**Mark Erikson:** what tests are for. [19:33]
-
-**Carl Vitullo:** ( laughter) a lot of tests. But 10% faster and half the bundle size or 60% of the bundle size is pretty incredible. [19:41]
-
-## TS5 decorators
-
-**Matt Pocock:** Pretty neat indeed. Carl, you wanna talk about decorators? [19:44]
-
-**Carl Vitullo:** Sure, Decorators are… they've been something that I've watched for— actually, they've been something that I stopped watching in my career because… I first heard about decorators in something like 2013. And, like five years on, they still hadn't an advanced past stage two. And it, that's the TC 39 standards process for introducing something to JavaScript has four stages, you know, like there's stage 0, 1, 2, 3, and 4, where 4 is shipped. [20:09]
-
-So decorators were stuck at stage two for [20:13]
-
-**Mark Erikson:** Years. [20:14]
-
-**Carl Vitullo:** like close to a decade with like competing proposals and different libraries were using different incompatible versions. I know that like Mob X went pretty hard on decorators pretty early, and I think that ended up burning them pretty badly. [20:26]
-
-**Mark Erikson:** Angular has been all in on decorators since day one. [20:29]
-
-**Carl Vitullo:** Yeah. And so it's I saw that they advanced to stage three, which is, I think advancing from stage two to stage three is one of the more crucial hurdles to cross because it means, I think Stage 2 is, "okay, we have a proof of concept for how this is gonna work." Stage 3 means "we have validated that this will work in existing JavaScript engines." [20:49]
-
-**Mark Erikson:** it's going from alpha to beta, basically. [20:51]
-
-**Matt Pocock:** And TypeScript, too, takes that. When it gets to stage three, like optional training did a couple years ago, it takes that as a sign and it says, okay, now it's in stage three. Now we are gonna implement it. So everything that gets to stage three will be implemented by TypeScript. [21:04]
-
-**Carl Vitullo:** Okay, cool. I didn't know that was their go signal, but that makes sense. I think that I think last year when decorators advanced at stage three was like a pretty, maybe a quiet, but I think a pretty big turning point for the standard, finally, we can have a lot more confidence that they're going to land in the form that they are described there. [21:20]
-
-Maybe now we'll see a resurgence of libraries and tools making use of decorators as a first class api. And maybe now I'll actually consider using them because, you know, I'm unlikely to have the rug pulled out from under me and have the spec totally change. [21:34]
-
-**Matt Pocock:** Yeah, I think they've made it inning in kind of like a limited form. So the old experimental decorators had more metadata associated with them, so, which is not something they wanted to guarantee in this new version. So the new version is a little bit stripped down, a little bit less powerful, but I think there's probably gonna be more proposals that they're gonna add new things onto the decorators. [21:55]
-
-But I think they've just split the conversation up into a couple of steps, basically. But now that we've got this sort of basic decorator stuff, which is. For those who don't know decorators, let you wrap a method in a class or wrap a class itself and just let you bundle up some logic within that wrapper to, let's say, add logging to a function, for instance. [22:12]
-
-Or, validate the parameters of a function that gets passed in super useful and I think really nice. And I think, yeah, I'm excited for what people are gonna build with this. [22:21]
-
-**Carl Vitullo:** Yeah, and maybe to tie this back to the React ecosystem a little bit, I think decorators got a lot of excitement around the time when higher order components were one of the primary patterns in the React ecosystem, the idea was that, a higher order component is basically just a decorator, but without a syntactical feature enabling them. [22:40]
-
-Yeah, I think that'll be interesting. Higher order components are much less common now, but , I think they still have a real place in the React ecosystem separate from hooks. Like if you're just trying to, if you have an existing component that works and you want to add a seam between that and whatever is rendering it to add props or guarantee behavior, like for instance, I've used higher order components as an authentication wrapper so I can ensure that a component will never be rendered if the user's logged out. [23:06]
-
-So yeah, it'll be interesting to see what the impact of fully shipped standardized decorators will be on the React ecosystem. [23:14]
-
-**Matt Pocock:** I saw that Rafael asked in the chat, are the decorators fully backward compatible? No, they are not. So, yeah, angular, NextJS apps that, or frameworks that rely on the previous experimental decorators they will have a difficult time. I think too, there's a really interesting thing about React developers in general because if you probably asked the median React developer, do you like classes or not, they were probably gonna say no. Right? [23:37]
-
-Because I think a lot of React developers, especially those who made the transition when hooks came in, they'd probably feel a little bit of, hatred towards the old class components where you couldn't compose logic so easily where you had to do all of this, do all of that. So I feel like decorators might just go over the heads of some people who are primarily using React and JavaScript, but don't sleep on it. [23:57]
-
-There's a lot of cool stuff there. [23:58]
-
-## TS5 const annotations
-
-**Carl Vitullo:** Cool. Matt, can you take us through the constant type parameters? [24:02]
-
-**Matt Pocock:** Sure. So this is a funny one. This is one that's gonna affect, I think, library code more than application code. But what it lets you do is it lets you, when you create a generic function, and for those who dunno what that is, it means that when you call a function, you can tell TypeScript to capture something about the way that you're calling that function. [24:19]
-
-So one of its arguments, for instance, and you might have used in TypeScript, you might have used a feature called `as const`. And `as const`, what it lets you do is it lets you take a configuration object and infer it to like its tightest level. So it, if you have like a b ABC in there with like, let's say, let's say an array of success loading or arid for instance, if you wrap that array in as const, it actually infers success loading or arid, instead of it just being an array of strings. [24:47]
-
-what this behavior does is it gives you that same behavior when you infer it in a function. So you can say, this is like const t, and then that t or that thing that's being inferred will be it's, God, it's so hard to describe without actually looking code front of… my days. I think the question is like, when should you use it? [25:04]
-
-What is this going to help with? This is gonna help a lot, I think, with people who are just dipping their toe into generics and trying to figure out some of the weird stuff that's in there. I'm really excited to start teaching it more because it's gonna mean that more people get more access to more powerful abstractions, I think. And I think that's how it's gonna look. It's, you are gonna find it a little bit easier to make more complicated generic functions. And I think lowering that bridge is something that TypeScript really needs to focus on, because I think in every application you are going to have a part of that app. [25:40]
-
-Probably like the utils folder or some sort of shared abstraction that is going to be complex TypeScript wise. Is there anything that they can do to lower that? Drawbridge a little bit. Let a few more people in I think is great. And I think constant annotations is part of that. [25:54]
-
-**Carl Vitullo:** Yeah, I think that this const annotations would've made a very specific case that I've run into a number of times, easier to work with. When I'm working with TypeScript, I pretty frequently end up with basically, like a lookup object keyed by something to get some value. [26:09]
-
-And I'm trying to come up with an example off the top of my head, and I'm blanking, [26:13]
-
-**Mark Erikson:** Enums to components or something. [26:15]
-
-**Matt Pocock:** The thing that comes to my mind is translations, right? So imagine you have like an object of translations, where the keys are the, the translation and then the the actual values are the actual English translation. If you don't use as cons there, or you don't use cons sanitations, then it's gonna just sort of infer it a string. [26:32]
-
-And so you can't do any sort of like clever interpolation there. Like you can't get really cool with it. But if you strap it with a cons, then you can actually get the literal values of the strings. And so you can, detect whether a string has like a dynamic parameter, like a name or something, and then you can, oh, it is there's just so many cool things you can do with. [26:49]
-
-**Carl Vitullo:** Yeah. I am excited for this. It seems like a cool change. [26:52]
-
-## TC39 proposal advancements
-
-**Carl Vitullo:** Maybe a little bit related, moving one step of abstraction up from TypeScript the TC 39. Technical committee that determines the underlying standard. The JavaScript is an implementation of, had a new meeting and they advanced a couple of proposals. [27:06]
-
-So we've now got well one, one exciting one that I, people have been asking for forever is iterator dot range. Finally we have a way of generating an array range from a standard library primitive. [27:16]
-
-We've got explicit resource management, which actually that one confused me. It seems something somehow related to like generators somehow improves a pattern that's commonly used around there, but I don't know. I've never found generators that useful for things that I was trying to do, so I don't really understand that. [27:32]
-
-There was also Async context, which was advanced, I believe, to stage two. I seem to recall some conversation in the React ecosystem specifically about how like React would make use of the async context primitive. So I think that they had some input onto that standard, but I'm blanking a little bit on the specifics. [27:49]
-
-**Mark Erikson:** My vague understanding of that and that that's more from reading Twitter chatter than the actual documentation is. It's it's a little like React context in that you have some value, which is now accessible anywhere, but instead of being based on like a React component tree, it's like anywhere within an async call stack can access a value. [28:09]
-
-I think the hypothetical idea would be like, you have a server, you have some server side code, you have some incoming data, and you want to store information like per request call stack. So you know, this user, that database value, et cetera. And it should all go away when that async call stack unwinds. [28:28]
-
-I think that's the general idea. [28:30]
-
-**Matt Pocock:** Is the idea then to use that for streaming or to use that for server components? [28:35]
-
-**Mark Erikson:** I would assume server components because my understanding is that normal React context does not work in server components. I think. And so having this ability built into Node and in the language itself would then act as your equivalent for, I need to access this value anywhere within a set of server components. [28:56]
-
-**Carl Vitullo:** Sure. Yeah. This reminds me, I had two thoughts when I was reading this spec. My first one, I tend to write a lot of, functional code rather than object oriented. And one sort of downstream consequence of that is I tend to use, slash, some might call it abuse, module scope variables for tracking state, which that works great in a client side application where every, every user has their own context. You know, it's running on the user's machine. It does not work at all on the server side of things. [29:25]
-
-So I think that this is a new language primitive that would allow me as a, as an application developer to use a similar pattern to module scope singletons, but in a way that works out of the box on the server side. [29:40]
-
-That leads me into my second thought, which is this smells a lot like a. The session global from PHP it, I think it's not exactly that because it's not a global, but I think it allows you to declare something similar to a session wherever you want. [29:54]
-
-So it's, you know, it's not one global session per request, but you can say this is a session associated with this specific running context. So I think that's really interesting. That seems like a pretty large change to the assumptions that a JavaScript run time is based on. [30:08]
-
-There are some other some other small ones. I saw Float 16 array, just a new typed array. It sounds like that came directly out of a W three C request where they want to offer more precision for canvas buffers. [30:21]
-
-And last one that I wanna highlight is the Await Dictionary proposal, which looks like it's a sort of object based complement to Promise.All. [30:29]
-
-It allows you to await an object full of promises and destructure that as named, named variables instead of having to convert it to an array and then deal with argument ordering. [30:39]
-
-**Mark Erikson:** Which, I mean, it's syntax sugar, but if I can totally see how that would be handy. [30:43]
-
-**Carl Vitullo:** Cool. Yeah, some big changes there. [30:44]
-
-Mark, what do you wanna talk about? [30:46]
-
-## React labs update
-
-**Mark Erikson:** Okay. So the, one of the other really big things that came out in the last few weeks the React team put up what they call a React Labs post, which is their category for, here's the stuff we're experimenting or doing research on recently. Lot of really good, discussions there. [31:02]
-
-But some general highlights. One is they talked about their work on React server components. They talked about some of the changes they've made since the first proof of concept announcement that they did a couple years ago. They talked about how you can use async await within server components. [31:18]
-
-The first example of server components is shipped inside of next experimental app router. And they're doing some other work around being able to stream data and metadata as well. [31:28]
-
-## React Forget
-
-**Mark Erikson:** The part that I was really excited to read to the point that I'd been bugging some of the team members about this on Twitter at React Conf last year, the React team announced that they were working on an experimental React, optimizing compiler, codenamed React Forget. [31:45]
-
-And just for reference, the React team has a habit of like every project they have has a codename that starts with the letter F. React Fiber, React… Fizz, React Forget. [31:56]
-
-So the idea that they talked about is you write a normal React component and it looks at it and it figures out how to rewrite the internals of the component to better memorize and optimize the inputs and outputs of that component with the goal that it would eventually help save on this whole, like, "when is my component going to re-render?" [32:19]
-
-How do I avoid unnecessary renderers? When should I use, use memo and use callback and all that stuff. And that if the compiler works out, it would basically just do all that for you. They've had a team of about four or five people working on this for about the last year, and they gave a status update. [32:38]
-
-The general summary is that, they've got the basics of the compiler working. And they've bec because you can have literally any JavaScript logic you want in a React component, writing a compiler is really, really hard, versus a, a framework like Angular that uses HTML templates. [32:55]
-
-So they've started off by supporting like just a small amount of the JavaScript language as acceptable code that the compiler knows how to work with. And they've been trying, trained out inside of Facebook, they have been also trying to figure out like, how tied is this to babble as a compiler. [33:12]
-
-So they've made progress on it. They're hoping to open source it eventually. I don't know. Like I'm really excited about this. If the compiler works out, it will make our React apps run faster, it'll make it easier for us to write components. We won't have to think about that stuff as much. I just really want to see this in action and play with it myself. [33:31]
-
-**Matt Pocock:** To play like a bit of devil's advocate here — this does seem super cool — is there a danger that you could, it could over-optimize in certain places because, like caches aren't free. Like to a cash, reading from a cash or. Would it optimize things into positions where you would get bugs? [33:46]
-
-Are there ways to disable the compiler profile if you, I mean, I dunno why I'm [33:50]
-
-**Mark Erikson:** yeah, there's there's always caveats and trade-offs. One, one of the most obvious ones I can think of is that it'll, like, the idea is it'll look at the logic in your component. And for example, maybe it'll, it, maybe it sees that your component outputs like three different chunks of content in the JSX, and maybe it can figure out that one of those never changes. [34:10]
-
-The second only depends on piece of data. A and the second depends on piece of data B. Now, if I were to optimize that by hand right now, what I could do is extract the first chunk of content to be some JSX elements outside the component and just use that variable every time. And then inside the component right now I could have like a useMemo A, useMemo B. [34:37]
-
-So the idea is that the compiler would hopefully be able to figure that stuff out and figure out, this piece never changes. This piece only changes when data A changes. And the other piece only changes when data B changes. It is possible to do that stuff, but the compiled version might literally be more lines of JavaScript code. [34:58]
-
-So there could be, for example, an increase in the bundle size because it now has the extra logic to determine what needs to be memoized and whatnot. There's always a course of bugs because a compiler is just software, and old software can have bugs, but that's what they're trying to figure out right now is how much of the JavaScript language does it know how to support, what kinds of restrictions does it need to have? [35:19]
-
-How good is the code output? And they're testing it against fa, parts of Facebook internally to try to prove all that out. [35:27]
-
-**Matt Pocock:** It's interesting cuz React, hasn't had a compiler before, but other frameworks, like Svelte or Solid. Have their own compilers, which do their own optimizations as far as I'm aware. So it's interesting that they're joining onto this and it's interesting that this takes React from being just JavaScript, to having this little optional layer, I guess, on top, that sort of takes it away from just JavaScript. [35:48]
-
-So we were talking about React positioning before. I wonder if that impacts it at all. [35:52]
-
-**Mark Erikson:** It, it does in a couple ways, and this also ties back to the server components bit. Nothing about server components suddenly makes our existing client side React logic not work. You can still use Create React App, you can still use Vite, you can still data fetch in a component on the client if you want to, but now there are new options on the server that give React new capabilities. [36:17]
-
-So in the same way, let's say React Forget works, let's say the compiler comes out and it's, you know, it's now built into, next or Remix or whatever. You could still. Build a page by linking the React script tags and writing some plain JavaScript code that, generates the output with React dot create element, none of that goes away. [36:38]
-
-But now there is a newer approach that most of the apps would use, in the same way that, most React apps do use, webpack, Babel, SWC, esbuild, et cetera as a build step. So like, yeah, you could do things the old way, but there would be a new approach that, while technically optional would probably be built in to all these different frameworks by default and hopefully it would just work. [37:05]
-
-Fingers crossed. [37:06]
-
-**Matt Pocock:** Yeah, this feels kind of like eslint, really. Like, it's sort of an optional layer if you want to add it, and the React team has built like custom eslint plugins that help you, prompt you to add different things to useEffect and things. So it feels a nice little, it's a nice to have, right? It doesn't feel critical. [37:20]
-
-**Mark Erikson:** Well, if it works out the way I think it will, I think it'll be a technically optional, but you would really, really want to use it for the benefits kind of a thing. [37:29]
-
-**Carl Vitullo:** Sure, not using it is an escape hatch for if you are working in a context where it doesn't work. For sure. [37:35]
-
-**Mark Erikson:** Mm-hmm. The one other thing to note about this Dan has been trying to figure out like how he wants to describe these things, and this goes back to all the debates over the last couple months about like signals and Reactivity versus, virtual doms and all that kind of stuff. And one of Dan's point is that assuming again, that the compiler works out, the code that you write in your component would still be normal JavaScript, array maps and using plain variables and plain object. [38:03]
-
-There's no special wrappers around the data. You're not having to worry to remember to call functions to access the data, but that the code you write is still basically playing JavaScript and then it's the compiler's job to figure out how to make that better, instead of, you know, needing to remember like, I have to call signal dot, get to access a value, or, some of the other rules there. [38:26]
-
-So his argument is that the compiler would give you basically all the performance improvements, but without you having to worry about it in your own code. [38:34]
-
-**Carl Vitullo:** Well, I'm always all for not having to think about something, so that sounds pretty great to me. [38:39]
-
-## Offscreen rendering
-
-**Carl Vitullo:** That React Labs Post has so much detail in it about what they've been working on. I think it's really cool. Something in there that I thought was pretty interesting, the offscreen rendering feature. [38:48]
-
-**Mark Erikson:** Yes. [38:49]
-
-**Carl Vitullo:** I'm excited for that. I think there's, that's something that I've written some, components to help with. Like, they talk about it, your options generally having been to either not render it and then that has a performance cost of, it's gotta tear it down and set it back up [39:02]
-
-**Mark Erikson:** Losing state. [39:03]
-
-**Carl Vitullo:** Right. Yeah. Losing state, You either lose all your state and blow it away, or you hide it in CSS and then you still have to deal with all the performance implications of [39:13]
-
-**Mark Erikson:** or you put it in Redux or recoil or Mob X or [39:16]
-
-**Carl Vitullo:** Right, which is its own can of worms. This offscreen feature sounds very cool. I also like that it's taking advantage of a feature that was implemented in React. I think in React 18, like this is really a priority hint. This is a way for us as developers to say this is low priority. [39:35]
-
-But framing it as "offscreen" is interesting and useful. It, I think it communicates more about developer intent, like this could have been introduced as " deprioritized" or "low priority". But I think framing it as "offscreen" helps clarify when it's meant to be. [39:51]
-
-**Mark Erikson:** So I can tell you that we are actually using the Offscreen API in my day job at Replay right now. One of my teammates is Brian Vaughn, who used to be on the React Core team. And so he's brought over a lot of his knowledge of these relatively new and somewhat still experimental React features. And we've been using some of them in Replay's code for the last year. [40:12]
-
-So the offscreen component is available in React, but only in the daily experimental builds, not the full like official production releases. And so Replay uses an experimental build of React that has the offscreen component available. [40:29]
-
-We've been using it for, in the last, in most of the last year, and it actually works pretty well. We did run into one or two cases where they were having to like fix bugs in the behavior, and we actually got bit by that once or twice, but for the most part it works pretty well. [40:43]
-
-You just wrap an offscreen component around like the tab panel, or something that you care about. And then as you're switching tabs, instead of tearing down the panel, you just set, `offscreen = false` and it keeps it around and it works great. [40:58]
-
-**Matt Pocock:** They've been thinking about this for a while, right? This links back to the reason that because there was, sort of, a little bit of a furor when useEffect changed in React 18 to fire twice in dev mode, right? [41:10]
-
-**Mark Erikson:** Yep. [41:10]
-
-**Matt Pocock:** And the reasoning behind that was the offscreen was coming and can't remember what the link was. And could you fill in the gap for me? [41:19]
-
-**Mark Erikson:** Yeah. So, [41:20]
-
-um, [41:20]
-
-hang on. There's a very specific discussion from the React Working Group where they, they talked about this, and this is one of those cases where they iterated on how they wanted to describe it. Like originally they were saying like, "it's really strict effects and we're gonna make effects fire twice." [41:37]
-
-And then they changed it to emphasize the positive instead of the negative, where it's like, well, "React is going to preserve your state instead of fully unmounting the component," so kinda like the same thing but a different perspective on viewing it. So like reading that React Working Group discussion covers some of this. [41:55]
-
-**Matt Pocock:** Nice. Yeah I'm really hyped for this. I think it's gonna be great. [41:58]
-
-## Server Components
-
-**Carl Vitullo:** There's a lot we could say about React server components as well. I have not stayed super on top of their development, so I don't feel like I have the most context. been a, there's been a lot going on there. [42:08]
-
-**Mark Erikson:** The one line status summary I'll give is, they exist. The big issue is that they need to be integrated into a bundler and a router and a build system to have any value. [42:20]
-
-So right now, the primary way you could use them is by using the next 13 experimental app directory. Other framework authors are trying to play around with like, how would I build this in to Remix or just like a, or, standalone webpack config or something. [42:39]
-
-The problem is because it's still very experimental, there's no documentation on how to do that, so you've got like individuals playing around with it and trying to reverse engineer, how do I make use of this functionality by looking at next, or looking at the React test just because there, there isn't documentation on how to do it, but a bunch of different frameworks are playing around with the idea at the moment. [43:01]
-
-**Carl Vitullo:** Yeah, definitely. I'll respond to that in a sec. [43:03]
-
-We are coming up in an hour and Matt Pocock has a hard stop here. So yeah. Matt, thank you so much for coming out. It was really great having your perspective on TypeScript changes. [43:11]
-
-**Matt Pocock:** No worries. Really, really fun to chat to you guys as always. [43:13]
-
-**Mark Erikson:** Yep. [43:14]
-
-**Carl Vitullo:** All right. Thanks so much. [43:15]
-
-**Matt Pocock:** See Bye. [43:16]
-
-**Carl Vitullo:** That context for server components I think is interesting. It's the core team is really saying these exist, they are in use by some people, but they are not for general consumption. [43:28]
-
-**Mark Erikson:** Yeah. [43:28]
-
-**Carl Vitullo:** That reminds me of now, close to 10 years ago, that was the state of React context. [43:34]
-
-It was undocumented feature. They were using it internally, they knew that people would want to use it, but they weren't comfortable with the api. They wanted to iterate on a little bit more. [43:43]
-
-**Mark Erikson:** Funny thing is, I think React Redux, and Dan Abramov, like one of the first cases that an external library started using the original Legacy React Context api and that helped prove how some people wanted to use it. It also helped expose some bugs and weaknesses in that API design, and that's what led to the React Team building the current Context API that came out in React 16.3 a few years later. [44:13]
-
-**Carl Vitullo:** Yeah, and I was refreshing my memory on some of the timing around React versions recently. I didn't realize that we only got context around the same time as we got hooks [44:22]
-
-**Mark Erikson:** it was a few months. It was five versions and a few months earlier. Context came out in 16.3 hooks came out in 16.8. [44:30]
-
-**Carl Vitullo:** yeah. Okay. Just to me, context has been around forever. So seeing that actually not that, in, in the overall lifespan of React, it was officially released, not that far away from hooks. Like those would feel like two totally different epochs to me. [44:44]
-
-**Mark Erikson:** Very much so. [44:46]
-
-**Carl Vitullo:** But yeah, so seeing the React core team talking about. Server components in a similar sort of way of like, Hey, don't use this yet. It exists. If you poke around, you can figure out how it works, but we're not going to release documentation yet. Like that is certainly something that, that is a pattern that they followed before. It's not new. Not new for them. [45:06]
-
-**Mark Erikson:** And to be fair, Dan was grinding out the last several pages on the new doc site, and that took him a long time to do it. They just literally haven't had time to write documentation for things like server components, even if they were like fully done, which they're not. I mean, like literally they haven't had time to write documentation on the these things and how you would integrate them into a bundler. [45:29]
-
-**Carl Vitullo:** This feels to me like they are looking at how people are using React and seeing that many people are reaching for Next and Remix over just using React and both Next and Remix found their own solutions for something like server components. [45:45]
-
-So to me, this feels like they have been observing what's going on in the ecosystem, seen what patterns have arisen, and now we're trying to learn from those and introduce it as a feature within React so that then both Next and Remix can expose the same underlying abstraction rather than having, rather than fragmenting the community and coming up with their own core concepts for it. [46:09]
-
-I think that's absolutely the right approach for them to take and I'm sure that Next and Remix are excited for that because now they will have one less, feature that they need to maintain. I know Remix uses a .client or .server file name annotation I'm sure they would love to not have to maintain a feature for determining that separation. [46:28]
-
-**Mark Erikson:** The Next folks are obviously very excited about React server components. Probably cuz you know, half the React team now works at Vercel. [46:34]
-
-**Carl Vitullo (editing):** Fun fact, the core team has 25 members. There are 20 developers and five managers. So four reports each on average. Three of the engineers are independent three, work at Vercel and 19 work at Facebook. There are a lot more folks building React than many people realize. [46:50]
-
-**Mark Erikson:** I think the Remix folks are still kind of hesitant about the whole idea and how it would fit in. [46:54]
-
-**Carl Vitullo:** That's interesting. I didn't realize that. Yeah, I guess that makes sense though because so many of the core team is now at Vercel, Next is very much under their domain at this point. [47:03]
-
-## Asset Loading and Transition Tracing
-
-**Carl Vitullo:** Yeah, I guess closing up on the React Labs post, they also mentioned asset loading and transition tracing. [47:09]
-
-Both of those to me sounded like features that are likely to be pretty big sea changes for developer experience. They're not very flashy features. You know, they're not exciting, you don't get hype about it, but I think that both of those have the potential to be massively influential on what it feels like to develop code. [47:27]
-
-So I'm excited to see what comes out of those, but I, I don't know how much there is to talk about it. [47:31]
-
-And transition tracing, just to explain it to the, to audience. If you are doing performance profiling of a React app right now, they have code in there to track component mounting and unmounting. They can annotate your flame chart with what component is where. [47:45]
-
-But something missing from that is events. So you can't see on the flame chart when was a button clicked, when was a form input fired? So my understanding of this transition tracing feature that they're working on is it will annotate your flame chart with tho those details, which I, as someone who's done a lot of performance profiling for React applications, that is a pain that I have felt many times and I'm excited to see it come out. [48:09]
-
-**Mark Erikson:** I think the other aspect is that with React eighteen's ability to split a render into many pieces over time it's harder to be able to track like, really when did this render start and finish? And they, they wanted to make that more feasible. [48:25]
-
-**Carl Vitullo:** Interesting. Yeah, that makes sense. Yeah. I know they had done, they had the Reactive tools, which had like commit and [48:31]
-
-**Mark Erikson:** Mm-hmm. [48:32]
-
-**Carl Vitullo:** I can't remember the other term, but it had like [48:33]
-
-**Mark Erikson:** render phase and commit phase. [48:35]
-
-**Carl Vitullo:** Yeah, sure. And it, it could, like, you could use that to discover expensive components, but it wasn't super useful for actually figuring out what caused that expensive re-render to happen. [48:48]
-
-I think they said in the React Labs post that they had actually removed some of the code that was powering some of that because it just wasn't working for people, which was my experience. So, Cool. [48:57]
-
-**Mark Erikson:** Can I go off and talk about a work project for 30 for like one minute? [49:02]
-
-**Carl Vitullo:** Ooh, please do. [49:03]
-
-**Mark Erikson:** okay, so, I work at Replay. We're building a time traveling debugger for JavaScript, and we have the ability to inspect anything that happened inside of a running recorded JavaScript program. And over the last f last couple months, I've built some experimental features where I can write code that asks our backend, Hey, when did this piece of code run? [49:28]
-
-Or what was the call stack when it ran? And do more further analysis from there. And over the last couple weeks, I built an experimental feature in Replay, like, because I know a decent amount about how React works inside. I figured out that every time you call set state, it goes through one internal function inside React. [49:50]
-
-And if you ask Replay, tell me every time that function ran, and then you walk backwards up the call stack to user land code. Eventually you find the place in your code that you called setState, or in a lot of cases called a Redux dispatch, which goes through Redux and then eventually hits the same React internal function. [50:13]
-
-So I built a very, very experimental proof of concept panel where it, if you make a recording of a React app, it will walk through the recording and show you list items that represent every time your code called Set State. And then you prep, you click on one of those list items and it jumps you to that line of code and the time in the recording when it made that call. [50:38]
-
-It's still very experimental and proof of concept, but it does actually work. [50:43]
-
-**Carl Vitullo:** Cool. Yeah, I have not used Replay yet. I, and honestly at this point in my career, I'm not really doing like heads down day to day React code to the same extent that I used to be, but, I think if I were in a place where I was more frequently debugging complex issues… oh man, Replay just sounds like an incredible boon for productivity. [51:03]
-
-So getting more understanding of their internals React. Heck yeah. [51:08]
-
-**Mark Erikson:** Hmm. That also actually ties into something else I'm doing for my day job, but it will actually, hopefully have a benefit to the Greater React ecosystem. React ships multiple files in node modules, and they ship both a development copy of the React code, already bundled, and a production copy of the React code, bundled. [51:27]
-
-And the problem is that they have never shipped source maps. And source maps are what a JavaScript debugger uses to be able to translate from the minified code that is actually running in the browser back to like the original source code files. So like if you ship source maps with your application, even though it's been mangled down to one minified bundle, when you go to debug it, you can still see source/features/my-component.tsx and debug that original looking code. React has never shipped source maps. [52:01]
-
-And so that's why whenever you see like a, an error stack trace from React in production, all like there are no function names, everything's like, two letter gibberish. if you were to say like put a break point in a function component and then step, step, step, step out of the component back into React's, internals, it's all gibberish and you can't read any of it. [52:23]
-
-At Replay, we use source maps to also help debug code and so I as a Replay employee, have put in work over the last couple weeks to modify Reacts build system so that it will actually generate source maps for Reacts production bundles. And I got it working and I have a pull request up in the React repo. [52:47]
-
-I just need to convince Dan Abramov to actually merge that PR. So assuming that gets merged, fingers crossed, then starting with the next React release, hopefully, probably 18.3, you would be able to see what the original code looked like for the production bundles. In a, like, in like a deployed application if an error gets thrown in production, at least the stack trace would be a little more readable. [53:14]
-
-The React internals are really complicated, so you're still not gonna understand what's going on, but at least you could read the code. [53:19]
-
-So I'm really, really hoping that I can convince Dan to merge that PR within the next couple of days. [53:23]
-
-**Carl Vitullo:** Yeah. Very cool. Well I hope to see that la I hope you're able to convince Dan that that's a valuable contribution. I think sounds great. [53:30]
-
-**Mark Erikson:** Like, it works and they've got their CI system set up to do example builds from the PR. So you could try installing a copy of React from that PR right now if you wanted to, play around with it. But I tested it out in, a couple different projects, a Vite app, a next app, et cetera, and the source maps look pretty good. [53:51]
-
-**Carl Vitullo:** Nice. Heck yeah. [53:52]
-
-**Mark Erikson:** I probably oughta call it a day here and actually go get something done. In fact, what I probably had to do is go back to that PR and see if I can make a couple tweaks Dan requested. [54:00]
-
-**Carl Vitullo:** Ha. Well, thanks for going 12 minutes over time with me. It's been really great recapping the news and the React ecosystem with you. [54:07]
-
-**Mark Erikson:** Good stuff. [54:08]
-
-**Carl Vitullo:** Excellent. All right. Thanks so much. See you guys next time.
diff --git a/src/transcripts/tmir-may-2023.md b/src/transcripts/tmir-may-2023.md
deleted file mode 100644
index 00a5b4c..0000000
--- a/src/transcripts/tmir-may-2023.md
+++ /dev/null
@@ -1,457 +0,0 @@
----
-title: This Month in React (May 2023)
-date: 2023-06-05
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-
-
-**Carl Vitullo:** Hello everyone. Thanks for joining us for May's This Month in React, where we recap and digest recent developments in the ever-evolving React and web ecosystem. I'm here with Mark Erikson and Sebastian Lober. Mark, you wanna introduce yourself? [00:15]
-
-**Mark Erikson:** Hi, I'm Mark Erikson. My day job is working at Replay, where we're building a time traveling to bugger for JavaScript. My free time, copious amounts thereof is taken up maintaining Redux. [00:26]
-
-**Carl Vitullo:** Heck yeah. Sebastien, can you introduce yourself? [00:29]
-
-**Sebastien Lorber:** Yeah. I'm the author of this in React, the newsletter at keeps You to date with React and React Native, and also the maintainer of Docusaurus React documentation framework from Meta. [00:42]
-
-**Carl Vitullo:** You know, I realized that I have been asking you guys to introduce yourself and I don't really introduce myself. [00:47]
-
-**Mark Erikson:** Carl, would you, would you tell us about yourself? (laughter) [00:50]
-
-**Carl Vitullo:** Yes, I would love to. I'm Carl Vitullo. I am a staff software engineer and freelance community manager, sort of community lead for Reactiflux. [00:58]
-
-I, I think, not a ton of huge news going on right now, but yeah. Mark, can you kick us off with our first link? [01:04]
-
-## Next 13.4, App Router and Server Actions
-
-- [Next 13.4](https://nextjs.org/blog/next-13-4)
-- [Server Actions](https://nextjs.org/blog/next-13-4#server-actions-alpha)
-- [Isomorphic Development](https://meijer.ws/articles/isomorphic-development)
-- [Rich Harris on frameworks, the web, and the edge](https://www.youtube.com/watch?v=uXCipjbcQfM)
-- [RSC data leak security footgun](https://twitter.com/tomus_sherman/status/1654211227172716545)
-
-**Mark Erikson:** Okay. So first off last month, Next 13.4 came out and the, the really big news item out of this is that they are declaring that the NextJS app router is stable, which has a couple different implications. [01:20]
-
-One is that it's a different way to define the routing structure through your page. And the second is that this is the first official "production" ready release of React Server Components. [01:33]
-
-Now this is where it's always dangerous for me to try to describe things because I have not had a chance to use any of this stuff. So, you know, a lot of what I can say here is either looking at the announcement blog post or trying to summarize the stuff that I've read off the various discussions on, on Twitter and Reddit. [01:51]
-
-So at this point, React Server Components are in theory production ready to use, and I've certainly seen people, you know, mentioning that they've, you know, they've rewr rewritten their blog or, you know, put together some actual example sites using React Server Components. [02:07]
-
-It feels like there's still some question about just how production ready they are, both in terms of stability as well as like what are expected usage patterns and how do you integrate various existing community tools and libraries into those. But you know, at least as far as the Next team is concerned these are in theory pretty much ready to go. Um, so that's, that's by far the, the biggest piece of news. [02:37]
-
-And then looking at the release notes the couple other big things in 13.4. Next has a team building a tool called TurboPack, which is a equivalent kind of build tool to Webpack, except it's written in Rust. It's being written by the original author of Webpack, Tobias Koppers, and it's supposed to be significantly faster. And so the release notes say that they, they are marking TurboPack as being in beta. It still does not have full future parity with Webpack, but they are making progress on it. [03:11]
-
-And then the last piece is something that I, I, I've only seen bits and pieces about myself, which is that Next and React are working together on something that they call Server Actions. And this is apparently very inspired by what Remix has, where it's, it's like a new primitive for sending requests to the server based on plain HTML forms. [03:37]
-
-And I, I think the idea, looking at the examples is that on the client side you have a lowercase form input and you provided a prop called action. And that action can then in turn, really run on the server and do like a direct database insertion or query or something like that, and the compiler is able to separate out the fact that this action function needs to run on the server versus the rest of the code, which could technically run on the client or the server. [04:11]
-
-So it's, it's kind of like that Remix style thing where you're writing code in the same file that mixes together client code and server code, and it automatically just works. So they, they announced this Server Actions idea. It's still very much an alpha and experimental, but it is a thing that they're working on right now. [04:31]
-
-And so these, these pieces have the possibility if they, you know, actually pan out to be pretty large changes in the way we structure and write React applications. [04:41]
-
-**Carl Vitullo:** Yeah, definitely as you were and you know, as I was reading the notes on Server Actions, my immediate thought was Remix as well. [04:48]
-
-I do think that's a really powerful pattern that Remix introduced. So I'm excited to see Next Adopt It. And yeah, I mean this is, to me, this is exactly why it's so beneficial to have multiple clients doing, or, you know, mul multiple tools trying to solve the same use cases cuz they come up with different ideas and some of them stick. I'm pretty excited to see Server Action stick. [05:08]
-
-I think this, I think if you're going to have code that spans the server and the client, you know, it can't all be UI code, not everything we do on the server is render UI. So having, you know, an easy way to run other types of arbitrary code. Yeah, that sounds awesome. Excited for Server Actions. [05:25]
-
-**Sebastien Lorber:** Yeah. I'm also excited for, for Server Actions. Maybe for another reason is also the, the support for Progressive Enhancement. Because so, so far Remix has shown that it's possible to, to have a great Progressive Enhancement story with React, but this kind of feature was lacking in in NextJS. And now they, they, they show that they really care about it. [05:49]
-
-And you know, when you submit a form now the abstraction, the the abstraction make makes it possible to, to submit the form without JavaScript, without even direct being hydrated on the client. And the server is able to, to receive the form submission and and send the new HTML page. depending on if JavaScript is running on the client or not, the payload will not be the same. [06:16]
-
-And actually, I think the NextJS markets this feature as Server Actions. But really I think the action prop is right, is a React Core concept. Now you can you can pass an action to a form in React and it can be a very string or callback. And, and depending on whether the JavaScript will run or not the, you will use one form or another in NextJS to support a progressive announcement or the submitting the form locally with a JavaScript. [06:51]
-
-**Carl Vitullo:** Okay. Interesting. I didn't realize that this was a React concept that Next is looking to expose. [06:57]
-
-**Mark Erikson:** I think it's a plain HTML concept that they are extending. So the plain HTML form element has always had an `action` attribute that would, I think it defaults to POST, and that's why if you just have a plain HTML form and you submit it, the browser literally makes a post request to the server, right? [07:19]
-
-Uh, I think you can change it to be GET instead. And so I guess technically what the React team is doing is they're overloading the existing action attribute so that you can pass a function instead of a string. And if so, they, they wire things together on both ends. [07:37]
-
-**Sebastien Lorber:** Actually, what you mean is the method, POST or GET is the method and action with the URL of the, the target endpoint of the form. [07:45]
-
-So somehow they just allowed to accept the callback. But I think on the, on the server, the, the callback is serialized to string by the compiler so that before hydration React is able to know where to post the form on the server. [08:02]
-
-**Carl Vitullo:** Oh, interesting. Okay. So I think I see, I think I see what you're saying. [08:05]
-
-So I just put a little code snippet in the chat here. So there's this page component, it has a function defined inline. [08:12]
-
-**Mark Erikson:** The key, the key thing is that it has the "use server" string inside, and this is where the compiler part comes into play. So similar to Remix, you've got code that could run on either side in the file and some code that only runs on the server in the file. And they have to have some way to delineate which code in that file is server only, and they're basically just gonna strip that out of the part that goes to the client. [08:40]
-
-**Carl Vitullo:** Okay. That's interesting. Okay. So it doesn't need to be inline. That's good (laughs). I, I'm not a huge fan of this "use server" tag, but like, okay, sure. That's how, that's how it works, whatever. Um, it reminds me of an article I read recently talking about "colored functions" and how it's yeah, it just introduces multiple types of functions here. [08:59]
-
-But the point I wanna make here, to me, this actually just reading this code and thinking about this as like, the compiler is extracting out the function, it seems almost more like a developer experience improvement on serverless. You know, because you could write a function like this that handles a single form, but it's pretty painful to do that with a serverless backend. [09:20]
-
-So having a compiler that will extract out that code and handle the packaging it into a serverless, you know, executable and putting it somewhere and inserting the url, or Yeah, inserting the URL into a form. That actually that's, that's actually really interesting to me. [09:37]
-
-**Sebastien Lorber:** There is something to, to not be wrong about this snippet is that, you are not mixing server and client, code inside the same file. The whole component is a server component and the "use server" only expose the function to the public interface of the server, somehow. [09:55]
-
-So I think the, the first reaction you have when you see the, the snippet is, you are able to somehow mix server and client side code in the same file. But it's not exactly that. [10:05]
-
-It's more like, inside your server component you can choose to render functions and some of them will get exposed to the public interface that the server runtime will create. So I just want to, to, to make sure that people don't make this confusion because the, the form is a server component. It's not a a client component. [10:26]
-
-**Mark Erikson:** That, that does kind of go into, I guess my, my biggest concern with all this stuff, and that's trying to wrap your head around the mental model. My biggest personal problem is I just literally have not had a chance to use any of this. So I've been trying to understand it without actually using any of it in practice. [10:43]
-
-But it feels like trying to understand these boundaries between what's, what's a server component, what's a client component? Like as my Redux co-maintainer Lenz has pointed out, it's like, client components can run on the server, the phrases server and client don't necessarily have the meanings you think they do with this technology. Um, I actually wanted to link two other articles that I'll, or, well, an article and a post that I'll throw in here. [11:06]
-
-And I thought these did a pretty good job of discussing some of the, the pros, cons, concerns, and trade-offs with both like,, Server Components as a technology, and in general, what we're doing as we kind of mix and match with this code where you can have a database call and something that runs on the client in the same file, it starts to blur the lines. [11:30]
-
-And we're doing this sort of in pursuit of developer experience, but it does bring up potential concerns around things like accidentally Exposing API's, keys, or secrets into the client if you're not careful enough about how you structure the code, or just trained to wrap your head around what pieces of code are going to run where, and I know Dan has said that, you know, in, in a lot of ways this simplifies how you teach React to people because you don't have to explain, "well, I, I make a fetch call when the useEffect" or "I have to go learn how to use React Query" or something like that. [12:08]
-
-Instead you just, you're just making an async/await call inside of a component and it just works. And I see the point he's trying to make, but there are a lot more moving pieces involved here as well. And I don't have a great answer for how are we going to teach all this and what kind of problems are, are people going to run into as a result. [12:31]
-
-**Sebastien Lorber:** Yeah. By the way, there, it's worth mentioning that there is a little security issue that related to the Server Actions in NextJS, I will post in the chat. A tweet related to that is that if your server action captures a variable in its closure, actually this variable will be sent to the client inside the form as a hidden parameter, so that it'll be sent back to the server so that the, the closure is able to, to see this variable again, because unlike client components, the, the Server Components do not have state. [13:07]
-
-I, I mean, for example, if one server component serve your request, it might be in AWS US west 1, and then on the second request, it might be another data center that serves your request. So all the Server Components have to be stateless. And if you need to preserve state across closures inside your Server Components, they must be sent to the client. [13:31]
-
-And currently this is a risk to expose secrets to the clients. So the React team said that they were thinking about encrypting the hidden parameters, but it's not ideal solution because of course you, you don't necessarily want to expose secrets even encrypted. [13:50]
-
-And I don't know what will be the, the solution and if a decision has been made, but it's worth knowing that there is a little security issue currently regarding the usage of Server Actions. [14:01]
-
-**Mark Erikson:** I actually just had a, a side flashback to the, the old classic ASP.net view state approach for serializing data to the client. [14:10]
-
-**Carl Vitullo:** But so we're, we're 20 minutes in. We've done one link, so we should probably move on (laughs). That's a lot to talk about though. Yeah. Sebastian, you wanna take us on to our next one? [14:20]
-
-## React Native Skia
-
-- [William Candillon – The Joy of Painting with Skia | App.js Conf 2023](https://www.youtube.com/watch?v=Hfb_gpfCHzk)
-
-**Sebastien Lorber:** There have been uh, three React Native conferences this month. There was AppJS in Poland, there was uh, Chain React in USA and there was a React Native Connection in Paris. I like particularly the talk of William Candillon that presented the progress with React Native Skia, which is the renderer used inside Flutter and inside Android and inside Chrome, and inside many of other things. [14:43]
-
-And you can use it in React Native today, and it permits to, to somehow unlock many use case that that were not possible previously. The talk is presenting a few interesting things like the ability to create a screen transitions that are powered by OpenGL shaders and things like that, that's quite impressive. [15:03]
-
-**Carl Vitullo:** Interesting. So it's about, painting. So it's sort of like, is this like a React Native version of Canvas? Sort of? [15:11]
-
-**Mark Erikson:** Just as a little better background Skia is a C++ library for two-dimensional graphics. And my understanding is that most browsers actually use this to literally draw stuff on the screen in the first place, including implementing the HTML Canvas element. So it sounds like this is now, this library is now being exposed as something you can use from React Native to do custom graphics. [15:40]
-
-**Sebastien Lorber:** Yeah, it's exactly that. The idea is that you have a canvas, you have some primitive that you can draw, you can use OpenGL shaders and things like that. [15:49]
-
-In the beginning, I think, maybe last year they released the first proof of concept. And then there was Shopify that was interested in this lib and sponsored it. So now the, the development in is funded by Shopify. I think the first version was more of a proof of concept, and now it's more production ready. [16:09]
-
-I think one of the challenge in the beginning was also that it was not possible to interleave easily the, the canvas inside the native application because somehow the, the canvas was over the native views or it was under, and you have to, to do the trade off of deciding how to integrate the canvas inside your app. [16:28]
-
-So it was a bit complicated to achieve certain visual effects. And now the integration is better. The talk is showing some possible solutions to, to be able to integrate better with native views and things like that. And also to integrate better the canvas with Reanimated, which is the popular animation framework, for React Native today. [16:48]
-
-**Carl Vitullo:** Interesting. Okay. Very cool. So I wonder if using the same primitives as Canvas and the browser, I don't know if this is the case, but I wonder if it will allow a lot more cross compatibility with that sort of graphics rendering. Yeah. That using the same primitive, the same, you know, base tool to bring that into, into native. [17:09]
-
-That, that does seem like a really huge step. Yeah. [17:12]
-
-**Sebastien Lorber:** I think it unlocks a lot of things and we are just in the beginning, yeah. [17:16]
-
-**Carl Vitullo:** Yeah. You know, honestly, that reminds me of the effort to bring Flexbox rendering into Native. So, yeah, I mean, graphics rendering is really hard. It's also really powerful. So if we can have similar primitives for doing graphics rendering on both web and native, yeah, I could see just a little glimpse of what new features that would enable. Yeah. Very cool. That's pretty awesome. Cool. Okay, [17:40]
-
-I'll move this on to our next one. [17:42]
-
-## Struggles with Remix
-
-- [My Struggle With Remix](https://redd.one/blog/my-struggle-with-remix)
-
-**Carl Vitullo:** Yeah. Um, I wanted to share a blog post about someone sharing their struggle with Remix. I think it's good to talk about not just what's great about things, but also where the rough edges are. Um, and this seems like a pretty measured and realistic perspective on where some of the rough parts on Remix are right now. [18:03]
-
-It talks about the developer experience and some of the struggles there. Routing is too magical is one of its points, which I, I do, I, I think I agree with a little bit. It basically has its own DSL, domain specific language, for routing where, as part of the file name, as part of the path for your routes, it does a lot of parsing out of that string and changing behavior based on that. [18:26]
-
-So like having to learn a brand new DSL for routing that you don't really have a lot of control or access into, outside of that, like that, all that, that all happens as part of the Remix dev and build server. It's not super inspectable and uh, definitely a little bit magical. [18:42]
-
-One of the categories of complaints it has is that it gives you enough rope to hang yourself which is both great and terrible. It, it is nice that it is so powerful, but part of the downside of having so much power is that it doesn't do a lot of things for you. [18:56]
-
-This author talks about needing to write a lot of supporting logic for handling things like static assets like you, you put a relative path to an image in your markdown, and then you have to write code that understands how to parse out that relative path and convert it into a, an absolute path when it's actually showing the page. [19:11]
-
-So, I, I, I, this seemed like a really good, I don't know, collection of some of the rough spots in Remix right now. [19:16]
-
-**Mark Erikson:** Uh, again, I, I have not used Remix, so I can't comment on the technical aspects here, but I, I really did appreciate this post because it was very clearly written. it was framed as "these are my experiences and pain points using it," not, "oh no, this tool is awful." it was actually like more of an attempt to say, how can we make this better rather than attempt to bash the tool or its authors. [19:43]
-
-And I appreciate that. Like, there, there's just so many negativity and, you know, "tool X kills Y" being thrown around and I, I, I appreciate it when we can have reasoned debate and discussion about technical trade-offs rather than flame wars. [19:59]
-
-**Carl Vitullo:** Yeah. And I, I appreciate that in the, you know, in the intro setting off the whole post, he says, "I think Remix is a great framework. I will not be mentioning Remix advantages." Uh, it kind of, it reminds me of that scene in the Silicon Valley TV show a number of years ago where they're talking about their frustrations and they, they come up with an acronym for "Richard is great, but." You gotta get that outta the way you gotta "Remix is great, but." [20:23]
-
-So I think this was a great way to, to focus on the challenges without having to extol all of its great virtues of which there are many, it has a lot of great things. [20:32]
-
-**Sebastien Lorber:** Yeah. But the, the author in the end, "I still would use it for a startup," so that's already quite nice. I think the conclusion was he wouldn't pick it again for a blog. I tried also to, to create my newsletter website with Remix in the past, and also I thought it was a bit it had some rough edge, but it was possible to use it, but maybe not the, the simplest solution. But also they focus maybe on low level primitives and a bit on the architecture side. And for example, I'm quite surprised that the author was looking for the, you know, the markdown images to be able to use the relative image path. I don't think it comes for free in many frameworks. [21:12]
-
-I know that does it, but it's not free, it's we have to implement it manually. So maybe NextJS does it. But I don't know. That's not something that for me come out of the box unless the framework is opinionated to where they're using MDX or something like that. But, otherwise not too surprised that this kind of feature is doesn't come outta the box. [21:34]
-
-**Carl Vitullo:** Yeah. Agreed. He mentions. Gatsby doing this for him, and that wasn't my experience. I haven't used Gatsby extensively, you know, in any deep capacity for a number of years now, so maybe something changed, but I, I do remember having to write code that did exactly that when I used Gatsby in about 2018. So, yeah, I don't know. [21:52]
-
-Cool. Mark, you wanna take us off? [21:53]
-
-## You Might Not Need React Query
-
-- [You Might Not Need React Query](https://tkdodo.eu/blog/you-might-not-need-react-query)
-- [Using Apollo Client with Next.js 13](https://www.apollographql.com/blog/announcement/frontend/using-apollo-client-with-next-js-13-releasing-an-official-library-to-support-the-app-router/)
-
-**Mark Erikson:** Yep. So continuing with the, the Next 13 and Server Components theme, a lot of the big questions within the community have been how do data fetching libraries like Apollo React Query, RTK Query, and SWR, work in conjunction with Next 13.4 and React Server Components, and the, the new app directory. [22:19]
-
-And there's a couple, couple big discussions and pieces of news on this front. One is that Dominik Dorfmeister, the maintainer of React Query, wrote a post entitled You Might Not Need React Query, and you should read it because it's, it's a really good post in general, like everything that Dominic writes. [22:38]
-
-Some of the summary here is that , if you choose to do data fetching with React Server Components, well, React Query is a data fetching library and you just chose to use a different tool to solve that problem. That's not to say that React Server Components completely kill React Query because where and how you need that data or some, or if you need some of the specific features of React Query there, there are still very much use cases. [23:10]
-
-But it's, it's that same kind of question of, there's, you know, 3, 4, 5 tools available to solve this problem. If you pick one tool, you probably don't need the other tools that do some of the same thing. Another item is that my Redux co-maintainer, Lenz Weber, recently started working for Apollo and he works on Apollo Client in his day job and thinks about RTK Query in his free time. [23:34]
-
-And he spent a couple months trying to work through Server Components and Apollo and figure out how these things even can work together at all. I'm still not clear on all the details, but he, he put up a RFC document that describes how Apollo and Server Components can even potentially fit together at the technical level. [23:59]
-
-And then there was a blog post that accompanied that, where I believe they put out some kind of a proof of concept library that can help Apollo and Server Components sort of go together. We've been getting a lot of questions about like, so I wanna use Redux, but I also you wanna use Server Components. [24:16]
-
-How do they fit together? And you know, like, to a certain extent, you know, the answer is they don't, you know, both at the, at the technical level and the conceptual level, that's sort of the same thing over here, but it's, it, there's still a lot of open questions around all this stuff. I think that Lenz's proof of concept library is doing some very specific hacks that only work with Next in terms of how it's able to serialize and stream data onto the client. [24:44]
-
-One thing I know when said is you wouldn't want to mix and match fetching data on the server and fetching the same piece of data on the client. It's like it either needs to be done via a server component or it needs to be fetched on the client, but you wouldn't do both for the same piece of data at the same time. [25:04]
-
-The short answer is no one knows what we're doing, we're all trying to figure it out, and there's a lot of open questions. [25:09]
-
-**Carl Vitullo:** Yeah. I mean, how does, when people ask, "how do these things fit together," I think like everyone is still figuring that out because Server Components are such a brand new concept. But you know, there, there's so many different types of server interactions. [25:23]
-
-Like when you're first loading a page, like the data that you need is like, you need to do an auth handshake. Like, do you already have a valid token? You need to load the user settings data, you know, which is my, in my experience, there's like JSON blob for the user that contains, like, do they prefer dark mode, what feature flags are enabled for them? There's, you know, whatever data is initially necessary to render for the page. [25:47]
-
-Then, okay, sure. All of that stuff's loaded. The page is rendered. They're clicking around. Then they need to, you know, they scroll down on Reddit and they need to load more content. Or they submit, they click an upvote button and they need to send something back. Like, all of these are different. [26:03]
-
-Fundamentally, they are server interactions, like an HTTP request is made, A response is sent, whether that's JSON or HTML or whatever. So like superficially, they're all server interactions, but like categorically, like semantically for the user, for the app, they all have very different constraints associated with them. [26:24]
-
-And so like React Server Components very helpful for the first set of those things. Like as you're hydrating, as you're rendering the first HTML that the user will see and interact with, I absolutely understand how Server Components interact with that category of data fetching. But then like the, you know, then there is still the client side mode, like the, if you're doing an infinite scroll interaction, like there is no, the server has nothing to do with that. [26:51]
-
-The server doesn't even know where on the page you are. It has no way of observing that. So that is purely a client side interaction. So, yeah, I, I don't know. I feel like where does this fit in? It is it, it's new. It's, it's a new space. You know, it replaces some of the data fetch, but it doesn't replace everything. [27:11]
-
-**Mark Erikson:** Uh, and another couple examples I think Lenz was pointing to was that Server Components are kind of limited in the sense that it's, it's another way to pass down props to client components. You know, like Apollo has this very powerful normalized cache, so if you like it, it keeps track of items by type and by ID so that it's only re fetching, you know, like the, the three missing to-dos you haven't grabbed out of the 100 that you already have already. [27:41]
-
-And I don't think Server Components can necessarily help with the normalized data use case, and I don't think they can help with the ongoing push subscription use case either. [27:53]
-
-**Sebastien Lorber:** And I think one of the case that Dominik presented was, for the infinite scroll. The idea, for example, was the server component would render, the, the first part of the, the infinite call, maybe the first page and the React Query would be able to kick in later. [28:11]
-
-And you would use React Query for the, for the upcoming page, the, the second page, the third page, and things like that. [28:18]
-
-**Mark Erikson:** Yeah. So a lot of things to be figured out here. Yeah. [28:22]
-
-**Carl Vitullo:** Yeah, definitely. Cool. Sebastian, do you have another link? [28:25]
-
-## Expo Router v2
-
-- [Write Once, Route Everywhere: File System-based Navigation for Native Apps](https://www.youtube.com/watch?v=608r8etX_cg)
-
-**Sebastien Lorber:** Uh, maybe I can just give some little news about the other things that happen that React Native conferences because I know that you won't cover much React Native. [28:36]
-
-Maybe the most important one is the announcement of Expo Router version two. And I think it's important because it shows that actually the using Expo and React Native. For the web is becoming something that is quite serious. I mean, the first version was somehow like a Create React App, but using Ative for creating a website. [28:58]
-
-So it was not so great. It was working because you were able to create an application with React Native and published on the web, but as it was only clientside routing, it was a bit limited and you couldn't really use it for many use case, for example, when you need SEO and anything like that. And clearly the, the Expo Router is progressing to making this much more production ready making less compromises when you create a web application using Expo. [29:31]
-
-For example, this new version will have static routes, so you will be able to pregenerate a static website from your Expo app that you can publish on Netlify or Vercel or, whatever. There are also features that are interesting. For example, universal linking, which means that you use the, the URL forwarding on the mobile app. And this gives a lot of interesting benefits, like the ability to seamlessly transition from your web app to your mobile app and to have universal links. [30:00]
-
-For example, you, you tap a link on an email that you receive on, on mobile and we, it'll open the mobile app if you have it installed, or it'll open the website if you don't have it installed. And there are other things that maybe I should just keep it simple. Expo Router is bringing maybe a, a good experience for the developing website using React Native technologies. [30:25]
-
-And I think it's important because we, we want a shortcut, and I think it's exciting and maybe eventually Expo will catch up on the web with other frameworks and provide more and more features and I don't know, maybe compared with NextJS, someday, I hope it'll be the case. [30:41]
-
-**Carl Vitullo:** Yeah, interesting. [30:43]
-
-My experience with trying to do things and React Native has been the story around navigation is so confusing and different from what I'm used to on the web. You know, like the React promise of "learn once write anywhere" has not been true so far in my experience. Just because the fundamental, the, the base assumptions on mobile for, how do you navigate within the application are so, so different. It, it is learning a brand new context and so it's not learned once I, I do have to learn twice. Yeah. Hmm. [31:15]
-
-Seeing some file system based navigation show up in React Native, anything that brings the experience of navigation on React Native to something more familiar for Web concepts. I'm excited to see that. That makes, that makes a lot of sense. It seems like a big improvement. [31:31]
-
-**Sebastien Lorber:** Yeah. It's not easy to master the navigation in React Native in the beginning. [31:36]
-
-And I think for example, if you look at Expo Router, there are some conventions or things that are not exactly the same as in NextJS because maybe, you know, when you, you target all the platforms, you, you need to think about a few things that NextJS doesn't have to, to think about because As they only target the web they only need to to create conventions that work on the web. [31:58]
-
-But maybe Expo Router needs to, to find some abstractions that work for free platforms instead of just one (chuckles). [32:06]
-
-**Carl Vitullo:** Yeah, for sure. [32:07]
-
-## Improving Performance with HTTP Streaming
-
-- [Improving Performance with HTTP Streaming](https://medium.com/airbnb-engineering/improving-performance-with-http-streaming-ba9e72c66408)
-
-**Carl Vitullo:** I'll, kick us off with our next link. This is, so this is a, a blog post from Airbnb engineering. Airbnb has a history of releasing some pretty influential blog posts on their engineering practices. I know esp, especially in the context of React Native, the Airbnb blog post of, "we're moving away from React Native," uh, still has, I think they wrote that like six years ago and it still has echoes on the ecosystem. [32:33]
-
-But yeah, so they, they, I saw this, you know, improving performance with HDP streaming and it's not directly about React. But I think that the concepts that they're talking about have a lot of overlap with React Server Components because ultimately, you know, the goal for React Server Components is improving first load performance. And so this is one example of a first load performance improvement that can be done entirely in isolation from React and even from JavaScript. [33:02]
-
-Like everything they talk about is an HTML level optimization. But it's also, it's a good background reader on things like network waterfalls, early flush talks about sequencing of loading assets, which I, I think it's, these are things that I had to learn on sort of by trial and error, just sort of realizing like, "Ooh, this has gone badly and I need to figure out how to make it better." [33:25]
-
-And in researching those things, learned a lot of the concepts that are discussed here. So I, I thought this was a really good framing for sort of a background reader on concepts that will be very important to understand as code that takes advantage of React Server Components is being written. [33:43]
-
-Cool. And I guess that's all we gotta say on it (laughter). Yep. Cool. Mark, what do you got? [33:50]
-
-## React Canary Releases
-
-- [React Canaries: Enabling Incremental Feature Rollout Outside Meta](https://react.dev/blog/2023/05/03/react-canaries)
-
-**Mark Erikson:** So the, the React team put up a blog post announcing what they're calling Canary version releases of React. So historically the React team has primarily delivered React as your standard semantic versioning releases. [34:05]
-
-So 18.0 major, 18.1 minor, 18.2 minor. And they've also had an experimental channel, which as the post points out, they'd also referred to as their "next" channel which were just daily experimental daily builds of React, which. In addition to being built every day, also had a bunch of feature flags turned on so that work in progress, experimental features were included. [34:34]
-
-And we've actually been using an experimental build of React at my day job Replay, for a long time now because we've been doing some things with like React suspense in our code base, and those relied on methods that only existed in the experimental builds, not in the public, like 18.1. 18.2 builds. [34:54]
-
-And if you were to go look at NextJS, my understanding is that they have been shipping specific ver like pre-release versions of React with Next for a while now, in order to also make use of some of these not yet final features, and this is actually bringing up a problem for a couple reasons. [35:18]
-
-One is that there's a lot of confusions about what features are actually ready for, for production use. Another is that, you know, you see some people complaining that, well, you know, Next is getting kinda like an unfair advantage in being able to use these features. And third, like it's, it's actually been like a year since React 18.2 came out and we, we, I actually have no idea when 18.3 will even be released. [35:44]
-
-So with this blog post, the React team is announcing that they're going to start releasing a series of canary builds, which are somewhere between like a daily, just whatever is at the tip of, of main build and an official public semantic version in release. So that Canary builds will have these experimental features turned on. [36:08]
-
-And they will actually say ahead of time, here's which ones are basically stable or not. And they're actually encouraging frameworks and, and other packages to try out these features and even say, and even go ahead and use them for real, but to like pin what version you're using to a specific canary release. Not just like whatever one is, is the most recent. [36:33]
-
-And the comment is that sometimes they work for a long time on some of these features and sometimes a bunch of these features overlap and they, they might even be ready before the React team decides to make a new official semantic version of your release. [36:48]
-
-So it, it's good because it's kind of making that like, here's here's some of the work in progress stuff available in a somewhat more official way. It's also really confusing because. It's hard to keep track of what pieces are actually ready or not. And there's, there's a couple examples of this. So like, eight months or a year ago, the React team published an RFC where they announced there was gonna be a new hook called use, which was, it would let you actually kinda like unwrap and await a promise in a, in like a client component. [37:21]
-
-And that RFC was published and there were a lot of comments mostly complaining about the name. And the RFC said there will be a follow up RFC talking about some kind of new caching capability. And like, there's been nothing published about it since then. And frankly, we, like we library maintainers roll, like, "uh, is this thing dead or what?" [37:42]
-
-But apparently it's already like shipped and being used in production in Next 13.4. And so there's a lot of confusion about like, what is the status of these features? So hopefully the Canary builds will ha help make it a little clearer when these features are ready to actually try out. I've also had some discussions with React team members saying like, it would be really helpful if there was like a public list of what features the React team is working on and what their current status is. [38:11]
-
-Kind of similar to how TC 39 develops new JavaScript features. Like is it, stage zero, we have an idea. Stage one, proof of concept. Stage two, it mostly works. Stage three, it's almost ready. Stage four, done. Something like that would really be helpful for the community to understand things, but at least these canary builds are a step in the right direction where it's like a little more ready to try out. [38:35]
-
-**Carl Vitullo:** It's interesting that there's been that much confusion from library maintainers around, really like, what's part of React. I'm a little surprised to hear that that's been a point of confusion because that, that really does seem like a very, very important for both the React team and for library maintainers to both have a shared understanding of, and the core team has definitely been very vocal about being interested in soliciting feedback from and being in dialogue with library maintainers. [39:04]
-
-So that seems like a relatively large communications miss on something that they have talked about being very interested in doing well. [39:11]
-
-**Mark Erikson:** Yeah, and I, I had some in-person conversations with Eli and Lily from the React team at a couple different conferences. It was, it was almost like they were trying to do a listening tour. [39:22]
-
-Like, let's go out, talk, talk to folks in the community, get the pulse of what's going on, hear people's complaints and, and see what we can do about it. I definitely want to give 'em credit for how willing they were to listen to things. I'm hopeful that some of these ideas, like, could you give us like a, a status page of the features and stuff like that will come out of some of those discussions? [39:44]
-
-**Carl Vitullo:** I like the point you made about using TC 39 as a model perhaps, because I think that that framework for feature prioritization and, you know, communicating what's under consideration. I think that that did come about for similar reasons where there were a lot of stakeholders, there were a lot of interested parties who wanted to advance the state of the web in the case of TC 39, the web and JavaScript, well, I guess JavaScript specifically for TC 39, but there were a lot of people who were interested in having a seat at the table, and so they figured out, they put together that mode of communication. [40:21]
-
-And it's, it seems like React is now in a similar place where it occupies a very foundational place in the web ecosystem. You know, it's certainly not as broad as JavaScript does. It's inherently, well, I was gonna say, it's inherently a subset of JavaScript, but you know, I guess with React Native, it kind of, isn't it, it does go a little broader than web and JavaScript, which is interesting. [40:44]
-
-But yeah. You know, maybe that is, maybe that is a model that they could look towards and yeah, I guess if they're doing a listening tour right now, I'll be curious to see what they come back to the community with over the Next couple of months. [40:57]
-
-**Sebastien Lorber:** Yeah. Well, something I found interesting is that, for example in, in the experimental builds of React that NextJS is using, there, there are two new hooks called useOptimistic and useFormStatus that permits to the Server Actions. [41:12]
-
-And they actually are documented in the NextJS documentation, but they are not on the official React documentation. So you, you have to go to the NextJS documentation to, to read more about them. [41:26]
-
-**Mark Erikson:** Yeah. Th this, this was one of the points I specifically brought up, even, even at the uh, React Summit conference a a couple days ago. [41:31]
-
-It's like, I, I realize that, like Dan has, 70 to 80% of this stuff is quote unquote "React". You know, like that, you know, `action={someFunction}` thing is built into React. It's not a Next specific feature, but that also means that there really ought to be information in the React docs about a lot of this stuff. [41:55]
-
-And I, I realize the React team has, you know, limited number of people, limited amount resources, they, and a lot of the stuff is in flight. They can't publish docs on everything right this second, but I would not have expected to look at the Next docs for a React hook specifically. And, and it feels like there is very much a gap in confusion about some of that right now. [42:17]
-
-**Sebastien Lorber:** Yeah. But I think, for Docusaurus, we have been using Canary release, and it's a nice way for them to get feedback from the NextJS team before presenting things publicly to broader audience. So for Docusaurus it has, it has been great to be in beta for long because at, at that time, lots of people were adopting the, the betters of Docusaurus and I was able to get a lot of feedback on, you, you merge a pull request and then one week after you already get feedback on it, even if there is no public release, because people get used to, to using Canary version of your project. [42:57]
-
-And I think also integrating a canary in NextJS like that permits to somehow give the, the new React versions to a broader audience. But we weren't necessarily exposing all the new APIs at once because they're hidden behind abstractions, for example, maybe there are some React APIs that NextJS is using today, but they're not they're not exposed to the, to the users of NextJS app router because they're only used internally inside the inside NextJS [43:31]
-
-**Carl Vitullo:** I think you're right, Mark, about it being unexpected to go to the Next documentation to read something about a beta React hook. I'm sure that there's all sorts of reasons why that was the, you know, most straightforward, most obvious place to put that information. [43:47]
-
-Like, you know, if, if Next is the only place where you can use this right now, I could see why it makes intuitive, logical sense to put that information in those docs. But, given that there has been a lot of confusion and uncertainty and handwringing over the relationship between the React core team and Next specifically, you know, that seems like the sort of communication, I was gonna say communication gap, but maybe not a gap so much as just sending some more signal than you intended. [44:18]
-
-The words they're saying is Next does not have special treatment, but. If Next, if you know the beta features are coming out, are being documented from Next first, and actually not even first from Next only at the moment, then that certainly seems to undercut the words of the message, if nothing else. [44:38]
-
-Yeah. Interesting. [44:39]
-
-**Sebastien Lorber:** And something I just thought about it, but if you look at the Remix team somehow, I, I feel the communication is completely different and the way they approach adding new features has been different in the past. For example they added things in Remix first and then they're trying to backward things to React Router while on for React and NextJS, I think it's a bit the opposite. [45:04]
-
-They try to, to build the abstraction first on, on the React side and then use it on NextJS to dog food. But the, the abstractions on React are working rocky, but maybe this new should be first introduced in NextJS, and if this works great for NextJS users, they could backward them to, to React too. [45:26]
-
-**Carl Vitullo:** Oh, oh, interesting. I see what you're saying. Yeah. That's an interesting thought too. Just sort of a, yeah, we're getting into all the subtleties of PR and comms and API design. All the intersection of marketing and development and developer relations. Yeah. Interesting. [45:42]
-
-**Mark Erikson:** May, maybe, maybe some of the the Next tech writers should actually be filing PRs against the React core docs instead. [45:49]
-
-**Carl Vitullo:** Ooh, ooh. Interesting. Gauntlet thrown (laughs). [45:53]
-
-Cool. Should we go onto the lightning round? [45:55]
-
-**Mark Erikson:** Yep. [45:56]
-
-## Lightning round
-
-### Client-side rendering of HTML and interactivity
-
-- [Client-side rendering of HTML and interactivity](https://web.dev/client-side-rendering-of-html-and-interactivity/)
-
-**Carl Vitullo:** Perfect. Client side rendering of HTML and interactivity, a new post on the web.dev from Google. [46:04]
-
-Uh, it's pretty similar in theme to my, you know, my last link from Airbnb, improving performance with HTTP streaming. Just, I think it has a lot of information about good foundational concepts that will help people be more prepared for writing code when React Server Components are more broadly available. [46:21]
-
-Yeah, Mark? [46:22]
-
-### React Summit, Debugging JavaScript
-
-- [React Summit](https://reactsummit.com/)
-- [Debugging JavaScript](https://portal.gitnation.org/contents/debugging-js)
-
-**Mark Erikson:** Last week I got to go to React Summit. I actually spoke there in the morning, I gave a talk about debugging JavaScript. Honestly, I only saw one other talk, and that's because I spent the rest of the time having discussions with both other speakers and people. But it was a huge conference. [46:36]
-
-It seemed very successful. A lot of atte, a lot of attendees, a lot of great discussions, and I personally had an amazing time getting to meet people. So it was great. [46:48]
-
-### Debugging in React Native
-
-- [Debugging should be easier | App.js Conf 2023](https://www.youtube.com/watch?v=sRLunWEzwHI)
-
-**Sebastien Lorber:** Just a quick mention that debugging in React Native should become easier in the future. It has always been somewhat difficult in the past. Over time there were a lot of different ways to debug in React Native. And none of the methodologies was perfect. [47:05]
-
-And notably you, you could connect your Chrome Debugger to the, to the mobile application and it didn't work so great. For example, you couldn't get the, the network tab to work correctly. And now it, it's going to, to work a bit better in the future, thanks to the work of Expo. [47:23]
-
-### React From Another Dimension
-
-- [React from Another Dimension by Dan Abramov at RemixConf 2023](https://www.youtube.com/watch?v=zMf_xeGPn6s)
-
-**Mark Erikson:** So Dan Abramov did a talk at Remix Conf a couple weeks ago entitled "React From Another Dimension." And it was sort of a couple different points trying to be made. The pitch of the talk was. What if React originally only worked on the server and not on the client, and he actually did a demo where he used like IE6 in a, in like a Windows XP virtual machine and proceeded to build, build out a nifty little like 1990s style webpage and slowly add server-based interactivity to it before he ever actually finally added anything on the client side. [48:01]
-
-And part of it in a sense was this is a pitch for, here's a mental model for how React Server Components work, but it was also a very interesting talk and like alternate history universe, kind of an example. [48:14]
-
-### Server-side rendering React in OCaml
-
-- [Server-side rendering React in OCaml](https://sancho.dev/blog/server-side-rendering-react-in-ocaml)
-
-**Sebastien Lorber:** One link that I found particularly interesting was the, someone posted about creating server side rendering in React. But using OCaml for the server. So somehow they re-implemented the React server rendering in OCaml and um, it's exactly the same, but it doesn't support the, all, all the new things like React Server Components only rendering to string and actually it significantly improved the performance. [48:43]
-
-So I think it's interesting because for example, if you are using OCaml like uh, ReasonML for your application, if you decide to run your server side, your React server in the native language, OCaml, then uh, you can get a much better performance for free because you are using a language that is faster of than NextJS and uh, and things like that. [49:05]
-
-So I thought the idea is interesting and I think it's the first language that I see supporting server rendering of a React application in in another language than JavaScript. [49:17]
-
-### Several links on React rendering
-
-- [The Interactive Guide to Rendering in React](https://ui.dev/why-react-renders)
-- [The Journey of the React Component](https://alexsidorenko.com/react-journey)
-- [React reconciliation: how it works and why should we care](https://www.developerway.com/posts/reconciliation-in-react)
-- [A (Mostly) Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/)
-
-**Mark Erikson:** One of the biggest problems I see that confuses people with React is that they, they don't have a good grasp on the mental model. [49:25]
-
-Like they have the basic idea of components and rendering, but a lot of the real world aspects of how that works confuses them. And there were three really good articles in the newsletter within the last couple weeks that all tackle this idea of how does React rendering work from a different aspect. [49:44]
-
-There was one called The Interactive Guide to Rendering and React from Tyler McGinnis and ui.dev folks. There was a journey of a React component by Alex Sidorenko, who has a great blog post series called A Visual Guide to React Rendering. And then there was an article on React Reconciliation, how it works and why We Should Care by Nadia Makarevich, who has also had a couple previously good posts. [50:07]
-
-They all tackle, you know, some of the same concepts but from different angles. But it's really good information and I think a lot of people would benefit from kinda like going back and reviewing some of those basics to make sure they understand 'em. And then along those lines, I will also toss in my own guide to React Rendering Behavior post as well. [50:27]
-
-**Carl Vitullo:** You gotta, sounds super useful. I love hearing multiple perspectives on the same concept. Super useful. Cool. Sebastian, you got any more? [50:36]
-
-### Spatial Navigation
-
-- [TV Spatial Navigation](https://engineering.atspotify.com/2023/05/tv-spatial-navigation/)
-
-**Sebastien Lorber:** So my last link is about a post of Spotify and implementing TV spatial navigation. So the idea that you use your remote control with the arrow up, down, left, right, and things like that, and you should be able to navigate inside the ui. [50:53]
-
-And the thing is, there is no web standard to, to support this in in the web. So they had to reimplement this themselves by keeping the element that you can navigate to in memory. And I found it, it is a bit interesting because it's quite, unusual topic and I, I see more and more companies doing this. [51:16]
-
-Uh, I know someone two, two persons working at two French companies do doing that also for TV applications. Um, some are web applications, some are React Native applications. And recently we had a talk at React Native connection in Paris about the same subject. So this is basically every time someone needs to create a TV application for using React technology, they do something like this. [51:45]
-
-So if you need to build something for the TV someday maybe it's worth taking a look at. [51:52]
-
-**Mark Erikson:** That's cool. [51:53]
-
-**Carl Vitullo:** Yeah, I think it's also, like, sure, TV, It also reminds me of video game UIs, where you've got a dpad or a joystick. But I think it's also a very powerful accessibility tool. You know, like keyboard navigation is so important. [52:07]
-
-If you, you know, for people who are poorly cited or mobility limited or you know, yada, yada, all sorts of situations where that can be valuable. And yeah, I mean, I, I think that's a really, I think that's a really interesting read to see how people solve that problem. Because if you wanna provide powerful keyboard navigation in a web context, it's not easy. [52:27]
-
-Like, what are you gonna do? Tab index? (laughs) [52:31]
-
-**Sebastien Lorber:** Yeah. No, they, they keep the, the limits in memory. But this is funny because the solution from Spotify and the solution that was recently presented at the React Native Conference were different. For example, I think I remember Spotify is using geometry and trying to figure out which, somehow they, they use maybe APIs like getBoundingClientRect or something to get the positions of the elements on the screen. [52:58]
-
-While the, the other company in France that presented the React Native solution was using somehow recreating a tree, a React tree inside memory so that you know, which are the, the previous and the Next element, but not considering the, the placement on the screen. So it was quite different UX in the end, but uh, the solutions were quite similar. It's just the algorithm to navigate that was different. [53:24]
-
-## Closing
-
-**Carl Vitullo:** Cool. Mark you have any other like lightning round links? [53:27]
-
-**Mark Erikson:** I think we're out, out of, out of items at this point. [53:29]
-
-**Carl Vitullo:** Out of items. Well good cuz we are well over an hour at this point. [53:33]
-
-**Mark Erikson:** Way over time. [53:35]
-
-**Carl Vitullo:** Yeah, that's okay. We had a good time. [53:39]
-
-Cool. All right. [53:40]
-
-Well thank you so much. Thanks for joining us. Thanks for having in the audience for sticking us with us through May in React. All right, Mark, Sebastian, thanks so much for coming up. [53:51]
-
-**Mark Erikson:** Always. [53:52]
-
-**Sebastien Lorber:** Thank you. [53:53]
-
-**Carl Vitullo:** Talk to you guys later.
diff --git a/src/transcripts/tmir-nov-2023.md b/src/transcripts/tmir-nov-2023.md
deleted file mode 100644
index fdc251a..0000000
--- a/src/transcripts/tmir-nov-2023.md
+++ /dev/null
@@ -1,442 +0,0 @@
----
-title: This Month in React (November 2023)
-date: 2023-11-29
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-Chapter list:
-
-- [00:35] Conference news
-- [01:58] TypeScript 5.3
-- [10:24] Kent and Lee, dueling positivity on frameworks
-- [14:58] Next.js 14 and Next Conf
-- [18:07] Using React Server Components without a framework
-- [22:59] Remix 2.2
-- [27:52] Shopify Hydrogen Remix v2 support
-- [29:51] Redux Toolkit 2.0 and related libraries
-- [35:40] CSS improvements - :has() selector, nesting, advanced color functions
-- [37:31] Why you want React Query
-- [39:04] Retrospective on 10 years of JavaScript decorators
-- [40:10] React sourcemaps now available in canary builds
-- [41:47] $22,500 bounty for improving formatter performance
-
-Links discussed:
-
-- Quick hits:
- - [React Day Berlin Dec 8+12](https://reactday.berlin/?utm_source=reactiflux)
- - [Future Frontend conf earlybird tickets](https://futurefrontend.com/blog/ff24/?utm_source=reactiflux)
- - [Render ATL super early bird](https://www.renderatl.com/tickets?utm_source=reactiflux)
- - [State of React closed](https://survey.devographics.com/en-US/survey/state-of-react/2023). Not sure when results will happen. Likely in 2024
- - [State of JS is open!](https://survey.devographics.com/en-US/survey/state-of-js/2023?source=reactiflux)
-- [TS 5.3](https://devblogs.microsoft.com/typescript/announcing-typescript-5-3/)
-- Remix vs Next
- - [Kent](https://www.epicweb.dev/why-i-wont-use-nextjs) – [Leerob](https://leerob.io/blog/using-nextjs)
-- [Next 14 summary](https://nextjs.org/blog/next-14)
- - [Next Conf playlist](https://www.youtube.com/playlist?list=PLBnKlKpPeagl57K9bCw_IXShWQXePnXjY)
-- [React Server components, without a framework?](https://timtech.blog/posts/react-server-components-rsc-no-framework/)
- - [Code](https://github.com/ziir/rsc-demo) – [Demo](https://rsc-demo.timtech.blog/)
-- [Remix 2.2.0](https://remix.run/blog/remix-heart-vite)
-- Hydrogen (Shopify headless ecommerce) [supports Remix v2](https://github.com/Shopify/hydrogen/releases/tag/%40shopify%2Fhydrogen%402023.10.0)
-- [Redux Toolkit 2.0 is _almost_ here! _Hopefully_ shipping by this weekend :)](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-rc.1)
- - [Migration page](https://redux.js.org/usage/migrations/migrating-rtk-2)
-- ⚡️ lightning ⚡️
- - [CSS features roundup (bytes.dev)](https://bytes.dev/archives/237)
- - [https://tkdodo.eu/blog/why-you-want-react-query](https://tkdodo.eu/blog/why-you-want-react-query):
- - [10 years of JS Decorators](https://dev.to/what1s1ove/ecmascript-decorators-the-ones-that-are-real-g96)
- - [REACT SOURCEMAPS FINALLY MERGED WOOHOO!](https://github.com/facebook/react/pull/26446)
- - [Prettier bounty](https://twitter.com/Vjeux/status/1722733472522142022)
- - [claimed by Biome](https://prettier.io/blog/2023/11/27/20k-bounty-was-claimed) – [Full report](https://biomejs.dev/blog/biome-wins-prettier-challenge/)
- - Self-plug: [doing a livestream with Filip Hric tomorrow](https://twitter.com/replayio/status/1727698776125481350)
-- Fun news if we have time:
- - [Angular updated to v17, new docs site](https://angular.dev/)
- - [Docusaurus 3.0](https://docusaurus.io/blog/releases/3.0)
- - [Google-created React components for Google Maps](https://cloud.google.com/blog/products/maps-platform/introducing-react-components-for-the-maps-javascript-api/)
- - [Win95-inspired component library](https://lisandro52.github.io/react-winplaza-98/)
-
-[00:00] **Carl Vitullo:** Thanks everyone for joining us for November's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. I'm Carl, I'm a staff product developer and freelance community leader at Reactiflux. Where you are now, the Discord for React professionals. Uh, Mark, want to introduce yourself?
-
-[00:19] **Mark Erikson:** I'm Mark Erikson. Uh, in my day job, I work at Replay. io, where we're building a true time traveling debugger for JavaScript apps. And outside of Replay, I spend far too much time working on Redux.
-
-[00:31] **Carl Vitullo:** And answering every question about it on every platform.
-
-## [00:35] Conference news
-
-[00:35] **Carl Vitullo:** We're going to try out something new, uh, speaking of conferences in the prep chat. Folks interested in the news may be interested in attending conferences too!
-
-[00:45] We have React Day Berlin coming up on December 8th, with a hybrid online streaming follow up on the 12th. There's also a couple of early bird tickets that were just announced. There's Future Frontend, uh, which is going to be in oh, in Finland. I believe it's being organized by React Finland. That's going to be on June 13th and 14th of 2024. Uh, which competes with Render Atlanta, which is also going to be June 12th through 14th of 2024, and just announced early bird ticket sales as well.
-
-[01:19] There's also a little bit of survey ecosystem news. The wonderful people behind the State of JS ecosystem survey are doing a State of React survey as well. That just closed about two weeks ago. No final word yet on when the results of that will be available, but I've heard that it's going to be early in 2024 and might have Sacha Greif on here to talk about the results when they're ready. So yeah, keep an eye out for that.
-
-[01:46] And also one final note, the State of JS survey has opened for 2023. So definitely check that out, you know, contribute, make it. Give it better data.
-
-## [01:58] TS 5.3
-
-[01:58] **Carl Vitullo:** I'll start us off. First news event that we're going to be talking about here, uh, TypeScript 5. 3 is out. Out of beta, out of release candidate.
-
-[02:08] Looks like it's not a ton of major new changes here.
-
-[02:13] They're adding support for a TC39 proposal, import attributes, that give an inline syntax for module import statements to give more information about what that module is. As far as I know, the only currently supported additional attributes are in support of JSON modules.
-
-[02:34] Instead of JSON modules being sort of like an informal standard that just works, um, this is now formalizing that and giving I'm giving away for more information to be provided about how to import additional modules. So hopefully we'll see this being used for things like image imports, SVGs, fonts, things like that.
-
-[02:54] Um, which currently that's all been just like through Webpack or whatever bundler and whatever plugin, just totally ad hoc based on whatever bundler you're using. So seeing a proposal come in to standardize that is I'm here for it. That's cool.
-
-[03:09] **Mark Erikson:** Yeah, I've seen that the syntax exists. I haven't had it, like, actually, like, most things these days, I haven't had a chance to, like, look at it or play with it yet.
-
-[03:17] Um, like, I've seen the comment that, you know, like, one of the great things about, you know, Webpack and Vite and whatever is that it lets us, you know, mix together, you know, like, I need to import this CSS file, I need to import this, you know, this image file. And then all the processing happens during build time, but it's also true that you're basically almost inventing your own little language, especially if you start adding more plugins to deal with certain build types.
-
-[03:46] And, like, actually, it's a little bit like the React vs. Web component debate. You know, are you supposed to be strictly, strictly using the platform or are you okay with using tools that aren't strictly the platform, build in the specific pieces that you need, but you're, you're, you're maybe kind of conceptually locked in and maybe that's okay.
-
-[04:10] So in this case, I think what we're sort of seeing is that app developers for years have wanted to be able to do things where they are quote importing non JavaScript or TypeScript assets. Into their code for one, for one reason or another, and build tools have supported that for many, many years. And so now we're sort of seeing the little, you know, the trickle down effect where some concept of that is now trickling into the platform.
-
-[04:40] Even if it's not, like, building in functionality to do something with it. But at least now there's a, there's a common syntax for saying, here's a file, treat this specially.
-
-[04:53] **Carl Vitullo:** Yeah, like you were saying, it's, it's not all of the long tail of modules now, but I, I appreciate that it's a low level primitive that will allow for that sort of, that, that later work to be done in a consistent manner. So that's cool. I'm, I'm excited to see that.
-
-[05:09] But another bit that caught my eyes, uh, being valuable is improved type narrowing. If you do a switch with a true case and then, you know, have subcases for different, uh, conditionals, it, the behavior around type inference around there, uh, should be better on, on 5. 3.
-
-[05:27] **Mark Erikson:** That's actually one of the weirder little bits of TypeScript, or actually of JavaScript, really. So, you know, normally with a switch statement, the idea is you have a single variable that could have many different possible values.
-
-[05:40] And the switch case is, if the value is A, do this. If the value is B, do that. And the weird thing is, in JavaScript, you've always been able to say like, switch true, but then the case statements can have actual comparisons that don't even have to do with a single variable. It's kind of like another way of chaining if else statements.
-
-[06:07] And so, this has been legal JavaScript syntax for a long time, and TypeScript is now actually being a little smarter and saying, well, actually, if you're going to do that, we can apply some type level inference to what's going on inside.
-
-[06:20] **Carl Vitullo:** I don't know if this is a widely held opinion, but I've generally viewed that as, that behavior of doing switch true, as like, a little bit of a convenient hack.
-
-[06:29] I don't know where switch cases originated from, but like, I've certainly seen them all the way back to like, C, right? That is very much not the semantics, going back that far in their, you know, legacy. But, you know, that's how people have been using them in JavaScript for a decade.
-
-[06:45] So, acknowledging that and just making it work better, like, that's awesome.
-
-[06:50] **Mark Erikson:** Uh, one other item that I don't, I don't know if it's even listed in these release notes, but Andrew Branch from the TypeScript team has been working on a new set of documentation For the TypeScript website, about how TypeScript understands the concept of module files.
-
-[07:10] So, ESM files, CommonJS files, um, all the different variations in terms of module resolution. And he finally merged that into the actual TypeScript docs a few weeks ago. And there is a ton of information here. I've not even had a chance to read through all of it. But part of this is really long and complex because of how complex the JavaScript and TypeScript ecosystem is.
-
-[07:40] And you know, how many different tools and concepts are interacting. But it's basically an explanation of this is how TypeScript views. The world. And it gives a lot of very good explanations of the theory and choosing a lot of the compiler options and trying to deal with, you know, both using packages and publishing packages.
-
-[08:02] And as someone who has spent a disturbing part of this year banging my head against the wall of publishing packages, uh, this is, having this information available is very valuable.
-
-[08:11] **Carl Vitullo:** Before we move on, I'm just going to read down the list of all the what's new from the blog post. Import attributes, which we discussed.
-
-[08:19] Stable support for resolution mode and import types, which I think is what you were just talking about.
-
-[08:24] Resolution mode support in all module types, so related.
-
-[08:27] Switch true narrowing, what we just discussed.
-
-[08:30] Narrowing on comparison to booleans, uh, which I imagine probably came out of the switch true casing, but also another great, you know, we can narrow types on if statements. That's awesome.
-
-[08:41] Instance of narrowing through symbol has is instance.
-
-[08:45] Checks for super property access on instance fields.
-
-[08:48] Interactive inlay hints for types. I don't even know what that means.
-
-[08:51] Looks like a couple of other optimizations. Consolidation between TSS server library and typescript.js.
-
-[08:58] **Mark Erikson:** That one actually has a little bit of an impact. So, most people haven't noticed this, but if you installed, like, TypeScript version, I don't know, 4. 6, 4. 7, the unpacked file on, er, folder on disk was like 50 or 60 megabytes. And nobody thinks about it, but it's because TypeScript is a really complicated tool, but also they basically shipped, like, three different copies of the same core functionality in different bundles inside node modules.
-
-[09:29] The TypeScript package contents shrank in like 5. 0 because they altered how they build and bundle the TypeScript tools itself. And here they've done further work to say, you know what, actually two of these bundles are basically almost identical, let's extract the common piece so that it's only built once.
-
-[09:50] And then the two bundle files that get used for different purposes just reuse that common functionality. And so the actual installed size of TypeScript has shrunk again down to like, uh, I don't know, like 25, 30 megs? So I mean, it's something. Smaller node modules is always nice. Cool.
-
-[10:12] **Carl Vitullo:** About 20 percent smaller package size on disk after you install TypeScript. Cool, that's nice. Probably going to save a lot of disk space in aggregate across everyone.
-
-[10:21] Alright, Mark, you want to take us on to our next link?
-
-## [10:24] Kent and Lee, dueling positivity
-
-[10:24] **Mark Erikson:** So it's always amusing to me when we have kind of like dueling articles come out. Someone writes, someone writes article A, someone else looks at it and writes article B.
-
-[10:35] So in this case, we had an article from Kent C. Dodds, you know, always very prolific, you know, author and teacher. Who wrote a very long post entitled, Why I Won't Use Next. JS. And he laid out a bunch of reasons here, and there's like a bunch of sort of spin off thoughts that happened.
-
-[10:54] So the first thing is, you know, up front, Kent worked on, as part of the Remix team, for, you know, like, 8 to 10 months. He teaches Remix in his courses. He is a big vocal fan of Remix as a tool. And so, a lot of people ask him, both because he's a teacher and because he likes Remix, "well, why won't you use Next. JS? Or like, why do you prefer Remix over Next?" And so, like any good blogger, he said, okay, I've been asked this question dozens of times, I'm going to go ahead and write an article.
-
-[11:31] And he laid out a whole bunch of reasons, ranging from, you know, Remix is more of a focus on the web platform, it's not part of Vercel, he has some uneasiness with the way Next and the React team are sort of co mingled at this point, he feels it's more stable and does a better job with, you know, managing the pace of changes and it's less complex, You know, frankly, I haven't used Remix, but I actually agree and sympathize with most of the points he's making.
-
-[12:03] I've felt some of that unease with some of the pace of change with Next and the way some of the release processes get managed. Now, a lot of people have complained that Kent has a huge conflict of interest, and I see the comment down there in the chat.
-
-[12:19] I'm gonna side with Kent here. Yeah, he has biases and opinions. This is a post where he is stating his biases and opinions. Like, he's allowed to say, here's why I like this thing. And, you know, people have asked him, what are your thoughts? And so he's documenting that.
-
-[12:37] So, that post was really good. And, you know, got a lot of attention. And a week or two later, Leerob, who is the, you know, the lead developer relations guy for Next, Went out and wrote a post on why he is using Next. And I thought this one was also very well written. Uh, a lot of it is a direct response to what Kent wrote.
-
-[13:00] And I actually liked that both of them were very careful up front to say, like, Here are some opinions, I like this tool, I have preferences, and we even went out of his way to like tweet picture up front of like, "look, here's me and Kent, smiling, we get along, we don't hate each other," but, you know, kind of giving some counter thoughts on, you know, look, Next, Next does use the platform, I like the app router, and, you know, some of the other, you know, features that are built into Next.
-
-[13:30] What I appreciated as a neutral, independent third party is that, these are, these are well written posts, they are basically positive, I mean, they, they express a few, like, pain points and concerns, but they're written in a positive sort of a way, not like a tear everybody else down sort of way.
-
-[13:52] I, I just feel like the entire ecosystem would benefit from more articles and discussions that are organized and pitched with that mindset. So both of those were really interesting. A lot of really good feed for thought there.
-
-[14:05] **Carl Vitullo:** Yeah, I would agree. And both of these come out the day that we recorded October's This Month in React. So I was like, ah, dang it. If we waited a day, we could have discussed these immediately after.
-
-[14:15] So here we are a month later, but yeah, I definitely agree. I'm a big fan of a positive framing of things. I guess, you know, ultimately Kent's post was, why I won't, so that is kind of a negative framing. But the actual content of it is very much, you know, like his, the first heading of it is, "whatever you use is probably fine."
-
-[14:36] I can enthusiastically support anything that Just respects that there are different trade offs, and different people find different trade offs appealing. Only two of the largest people in developer relations for two of the largest frameworks in the React ecosystem having a nice, reasoned discussion with each other in the form of public letters.
-
-[14:56] **Mark Erikson:** And speaking of Next.
-
-## [14:58] Next 14 and Next Conf
-
-[14:58] **Carl Vitullo:** Next14! They announced this at the Next conference, which I'm going to link to a playlist of all the talks there as well. Major highlights here, uh, looks like TurboPack is offering big performance improvements for developer experience locally. They're claiming 53 percent faster local server startup and 94 percent faster updates, so rebuilds.
-
-[15:27] Faster to start, much, much, much faster to rebuild. Sounds cool. As far as I know, the major new feature being rolled out with Next 14 is server actions, which is a React Canary feature that is now being exposed as a first class function in Next. Sounds cool. We discussed that at greater length in the last episode, I think.
-
-[15:49] Partial re rendering, fast initial static response and streaming dynamic content for, I guess, you know, partial pages. Sounds cool. And it looks like they've put out some new educational content as well, teaching about how to use the app router and authentication and databases and stuff.
-
-[16:06] I still have not been able to find a great use case for myself to explore Next, you know, the more advanced Next features like the App Router, uh, in my own time. I'm not currently employed as a full time software engineer, so I don't currently maintain a large scale application, which is, I think, the only way to get real experience with using these, you know, the experience of working on a full team, making decisions in the context of maintaining them for a period of years.
-
-[16:37] Um, so, I'm not going to feel comfortable passing firm judgment on AppRouter, I think, until I've been able to build a real application. So, I don't have a lot to say on the specific details yet.
-
-[16:52] **Mark Erikson:** Yeah, uh, I'm, I'm sort of in the same boat, I mean my, my day job at Replay is technically a Next app, but it might as well be just a, you know, a pure single page application, conceptually. Basically don't make any real use of routing at all.
-
-[17:07] Anecdotally, you know, just looking at discussions on Twitter and Reddit, I, I see a very mixed bag. I, I see people who love the app router and some of the functionality that's built in there. I've seen a lot of people complain that in between the app router and like Vercel's multiple caching layers that there's a lot of pain points they're dealing with.
-
-[17:28] So I see anecdotes, I don't have a lot of, I don't have any personal experience that I can offer in that respect.
-
-[17:36] **Carl Vitullo:** Yeah, and there have been wildly popular framework in the past that had all sorts of blog posts and discussion and everyone raving about how great it was to use. And then a couple years later, everyone started using it for larger scale projects and found all the pain points. And I noticed all of that positivity going away. So, you know, In the interest of not repeating that pattern, I'm just not comfortable passing judgment too quickly here.
-
-[18:02] Want to take us on? Maybe a good segue from Next into Frameworkless.
-
-## [18:07] RSCs without a framework
-
-[18:07] **Mark Erikson:** So, one of the big issues with server components so far, has, well, a number of issues, but one of the issues has been that the only real way to use them has been with Next.
-
-[18:20] And, you know, there's the whole separate discussions over Next sort of getting first access to React features, you know, being sort of a concern, but also, you know, give credit to Vercel because they're literally investing a lot of money and time into building out the core pieces that are in React itself and then making use of those features in Next specifically.
-
-[18:45] So, there's a number of different tools and frameworks that are experimenting with integrating server components right now. I know that the RedwoodJS folks have said that they're all in on server components, and I've seen some of the technical discussions where they're working on it. I've seen, uh, Daishi Kato, who created Jotai and works on Zustend, um, has his own little experimental server components based framework.
-
-[19:13] So, there are a small but interested number of people who have been playing around with trying to build things with server components, but it always, like, needs some higher level of build tool integration to work, and that's by design. So, there was a really, really good post from a guy named, I believe, uh, Tim Tim Pillard.
-
-[19:38] And it's called, React Server Components Without a Framework. And in this post, he kind of breaks down, like, what are the pieces behind server components. Where do server components fit into, like, the build and deploy and usage sequence? And he then kind of dives into, like, what are the pieces inside of React that you would actually need to build your own server components integration?
-
-[20:05] And this was a really, really detailed article. And, is everyone going, like, going to need to, like, dive through this and understand all the inner workings to use server components? No, because you would normally use them just because, you know, Next, or Redwood, or Remix already has them integrated, and you sort of follow, like, the framework version of the docs, for the most part.
-
-[20:30] But, one of the problems with server components has just been that the low level workings have not really been documented so far. So, everyone's either having to look at the very bare bones examples in the React repo, or, in most cases, actually looking at the internals of Next, and trying to figure out, "well, how much of this is something we need to copy and paste, and how much of this implementation is very specific to the way Next works."
-
-[20:58] So, like, everyone's looking at Next's internals and trying to figure out what they're supposed to do. So, having an article that sort of breaks some of this down without any other frameworks involved is actually pretty helpful to understand what's going on inside.
-
-[21:13] **Carl Vitullo:** Most, most definitely. I was pretty surprised at, having never even, I've barely even tried to use server components through Next. So I've had even less exposure to using server components without Next or any other framework. And I was a little surprised at some of the details here, like he mentioned having to use the react-server-dom-webpack webpack plugin, which has no documentation at all for it. So like, ooh, yikes, okay, I've wrangled some complex webpack configs before, and they're hard enough when it is documented.
-
-[21:49] So going, just the setting of transcending the like client server boundary through the bundler without documentation. It's like, oh yeah, okay, we're still in a rough spot here.
-
-[22:02] **Mark Erikson:** There's a whole lot of dragons there.
-
-[22:03] **Carl Vitullo:** There be dragons for sure. So, just, you know, I tried to read through the code to get a general sense of what it would look like.
-
-[22:12] I am a big fan of going from first principles, you know, even if I'm going to stick at the level of, you know, using a framework, I like to generally have a sense of what's going on inside. And, honestly, even reading this code, it was a little bit tricky to unfurl even, you know, what are just internal abstractions that were set up for this little toy example versus what's strictly required.
-
-[22:36] So, yeah, it's definitely, I think, highlighted how rough of a state the experience of using server components is right now. Huge, huge props to Tim for putting this together. I think this is a, I think this will be, you know, regarded as a canonical contribution to the development of server components.
-
-[22:56] You know, just want to applaud Tim for that.
-
-## [22:59] Remix 2.2
-
-[22:59] **Carl Vitullo:** Talked about Next, it's time for Remix. Uh, Remix 2. 2 came out, and, it's interesting. I, so it looks like they are moving away from being a from owning a compiler and bundler step of it and moving towards leaning on Vite. So they, you know, they are claiming, you know, they are now supporting Vite as a bundler internally.
-
-[23:28] Uh, and one of the, one of the things they Called out in this announcement that caught my eye is they, they're saying remix is no longer a compiler remix itself is just a vite plugin. That seems remarkable to me to totally change out the internals of how a framework is operating in that way, transparently and in a way that allows people to opt into it.
-
-[23:52] in advance of the breaking changes being shipped. I think we talked last, it was either last episode or the one before, about the rollout process for new features that Remix is using and I think they're doing it really well. I think a lot of other open source projects could take a, you know, take a page from their book on how to roll out new features.
-
-[24:11] **Mark Erikson:** Yeah, I think I'd seen some discussion from Ryan and Michael over the last couple years that they'd kept their compiler workings internal and abstracted, sort of, I guess, like, in spirit, similar to the way React App tried to hide everything behind a wall, because they were worried about exposing some of the specific knobs to end users, And, you know, that causing trouble for, for future upgrades, you know, like everything, it has trade offs, you know, maybe it made some people's uses of Remix a little bit harder because they couldn't tweak those knobs, but it, it seems like it's also made this particular upgrade process a little easier because now they've, they've swapped the underlying layer entirely and actually sort of been able to get out of the compiler business completely.
-
-[24:57] **Carl Vitullo:** Very cool. Very interesting. It seems like they've made a lot of really good, uh. Choices to set them up for speed of iteration, which I think is a great metric to optimize for. Seeing a comment in the chat, Vite is under scrutiny for using ES modules in development, not convinced this is the best course of action.
-
-[25:15] Yeah, I've also heard some, just in the last day or two, I've seen some blowback. Vite as like, I don't know, the bundle less movement is, I think Next just put out some stuff saying that like, oh, the bundle less Uh, movement has failed, and they talked about how they really tried to make it work with Vite and just couldn't.
-
-[25:34] So, I don't know, curious, you know, we just did a, discussed the comparison of Next and Remix and curious that, uh, Next said, like, ugh, this can't work, we can't make it work. And Remix just Did it.
-
-[25:45] **Mark Erikson:** I'm a little, I'm a little bit curious about what the actual meaning of bundleless in that specific discussion is.
-
-[25:54] I know that in development mode, Vite tries to use ES modules kind of like straight up without, without fully bundling them, but they do actually get bundled for production. And so, like, a lot of the discussion, maybe four or five years ago, was, you know, with, with HTTP2 streaming, and, and like, you know, browsers supporting ES modules natively, we might not have to bundle, you can just have your individual dot You know, JS or mjs files on disk and they can all, like, they can all just get fed out automatically and eventually folks concluded that, you know, based on the number of files that have to be downloaded and dependency, you know, chains and whatnot, that, well, actually, yeah, bundling is still a good idea, but that's really talking about production usages, and so I'm a little confused why I think it was Guillermo Rauch in this case was saying, like, bundleless didn't work and pointing the finger at Vite when Vite does it in dev.
-
-[26:58] So I'm not following all that discussion.
-
-[27:01] **Carl Vitullo:** Thanks for bringing that in. I had forgotten some of that context, but now that you mention it, I know that they have talked over the last six weeks or so about, I know that Next has talked about working to improve the developer experience, and so I wonder if maybe that's the lens they're looking at this from, is they were, they came at it with a goal of making the developer experience better.
-
-[27:21] And we're not able to make the, you know, unbundled files as necessary, actually improve the experience because, right, because of, you know, exactly the same reason that nobody has ever been able to make HTTP a usable experience, uh, just there's constant waterfalls and you request one file and that request more files, which request more and more and more and more.
-
-[27:46] I think that's probably where that came from.
-
-[27:48] **Mark Erikson:** That would make sense.
-
-[27:49] **Carl Vitullo:** I think it's super cool that Remix has been able to make this work.
-
-## [27:52] Shopify Hydrogen Remix v2 support
-
-[27:52] **Carl Vitullo:** Sort of sub Remix news, Shopify acquired the Remix business, so they've been sponsoring development and supporting the team, and it looks like they just shipped the port for Remix 2 in their Hydrogen e commerce headless framework.
-
-[28:09] Cool to see that they are genuinely investing in this, not just sponsoring.
-
-[28:14] **Mark Erikson:** Not just acquire, hiring the team.
-
-[28:16] **Carl Vitullo:** Right, exactly. They didn't just buy the talent. They are genuinely investing in the open source project and then improving their own more narrowly scoped open source development on top of that.
-
-[28:30] So, super cool. It's, I know people have talked about You know, oh, venture capital in open source is, you know, anathema, it's terrible, don't do it. But this looks like a really cool positive outcome for that setting. Okay, Remix, the economics for running that as a venture invested business are maybe, I don't know how you get the growth multiples there.
-
-[28:55] Raising funding to pay yourselves as you develop and then selling to a business that does see a business use case in operating that. This seems like a pretty positive outcome for that, so just, yeah, I appreciate that. Seems cool.
-
-[29:09] **Mark Erikson:** One other little snarky side observation along the way. It's ironic that the React docs emphasize so strongly that you should be using a framework to start any new React project.
-
-[29:21] And of course, you know, the top choices are Next, Remix, Gatsby, (RIP) and Expo. And yet, Remix itself, and like, Vite is relegated to the, "well, if you want to start an SPA, I guess you can, we can't stop you." And yet, Remix itself is now actually based on Vite, which was relegated to that subheader.
-
-[29:47] **Carl Vitullo:** Yeah, low level tools.
-
-[29:48] Cool to see them get used though.
-
-## [29:51] RTK 2.0 (and lots of others)
-
-[29:51] **Mark Erikson:** Okay, so next item, some personal interest here, but it's also actual news, which technically hasn't happened yet, but is about to. We are hopefully about to hit the button on Redux Toolkit 2. 0. Like, so help me, by Sunday, I hope. This is an effort that has been going on since literally the start of this year.
-
-[30:13] When this happens, we're going to simultaneously ship major versions of Redux Toolkit 2. 0, Redux Core 5. 0, Reselect 5. 0, React Redux 9. 0, and, drumroll please, Redux Thunk 3. 0. And all of these are going to have modernized packaging with, hopefully, proper ESM CommonJS compatibility. Modernized JavaScript build output, so we're using the latest, greatest JavaScript syntax and no longer targeting IE11, thankfully.
-
-[30:49] There's some performance improvements. Redux Toolkit now uses Immer 10, which has some noticeable updates in updates, or improvements in update speed. We've cleaned up a bunch of deprecated options and added some new features. A migration guide page already up on the website. There may be a couple last Tweaks that need to go in there.
-
-[31:12] Our hope is that for a lot of apps, it might just be bump the versions and you're done, but we've tried to call out all the things that qualify as either really breaking changes or like this could sort of be considered a breaking change.
-
-[31:29] The one last thing that is sort of holding up the release at the moment is I am about to pull the trigger on changing some of the default behavior for the Reselect library. Reselect has been mostly unchanged ever since its release in terms of how the internals work. It's sort of doing one reference equality comparison for every argument, basically. And if any of those have changed, then it recalculates. But you can swap out the comparison function to do, like, shallow equality, or whatever.
-
-[32:04] CreateSelector has always had a default cache size of 1. If you, like, alternate the arguments back and forth, it'll never memoize, because it's like, "This doesn't look like the last thing you gave me. Recalculate. This doesn't look like the last thing you gave me. Recalculate." And so you kind of have to go through some shenanigans to handle cases where, like, you want to use the same selector in a list item component, but you're passing in, like, the ID of the item as an argument or something.
-
-[32:36] And I had updated reselect a couple years ago to be able to have a larger cache size, but you had to specifically pass in that option. So earlier this year I actually copy pasted this super secret caching function implementation from the React code, and it uses weak maps to form like a tree of cache data.
-
-[33:01] And the net effect is it kind of basically becomes like an infinite cache size with no further work needed.
-
-[33:09] **Carl Vitullo:** Oh, interesting.
-
-[33:10] **Mark Erikson:** And so what I've been debating is, is it worth switching Reselect's default behavior over to use that? As the default preferred approach. And I've, I've been waffling and debating the pros and cons and the trade offs.
-
-[33:25] And I think I'm actually about to do it. One observation I'll make is that technically an infinite cache size is also synonymous with a memory leak, like, you know, sort of looks the same way. Weighing a couple of concerns around that. But I think the improvement in the default behavior is going to be nice enough that it's worth making that switch.
-
-[33:45] And we'll sort of document, like, here's the trade offs with the new built in approach. So, you know, that's the kind of stuff that's been on my mind trying to finalize this over the last couple of weeks.
-
-[33:57] I'm actually literally hoping to make that change to the code tonight, document it, update the release notes, do some, do some hopefully last minute real world ish testing, and then hopefully ship this by the weekend, I hope, because I really don't want to spend December like, while I'm traveling, having this stuff on my mind.
-
-[34:16] **Carl Vitullo:** I remember that being, like, kind of the number one gotcha with, you know, Idiomatic Redux, you get a lot of really great performance characteristics if you get all the selectors just right, but it became kind of a puzzle of how to set it up just right to get there. You know, like, if you, like you said, if you end up having a list of things where you want to select items out of it, then you needed to, like, you needed to instantiate the selector in just this right certain way, so it was actually memoizing, so you actually got the performance benefits. So yeah, very cool. That makes a lot of sense for changing defaults to make it give you good performance in a wider range of circumstances.
-
-[34:54] **Mark Erikson:** Right, so I mean, it ultimately boils down to, I think the, it'll be a small but meaningful improvement to developer experience.
-
-[35:02] Uh, similarly, we've actually added a couple development mode checks to reselect. Sort of similar in spirit to like, you know, how strict mode works with React components. To watch for things like, you know, your input functions are returning a new reference every time, so this selector never actually memoizes. Or, the output function just returns the value it was given with no transformation, which, either of those means you're holding this wrong. Stop it.
-
-[35:34] **Carl Vitullo:** Cool, I'll move us on. I guess that's the end of our full discussion links, so we're into the lightning round now.
-
-## [35:40] CSS improvements
-
-[35:40] **Carl Vitullo:** Couldn't find a better source for this than just a newsletter that I was reading, so I'm posting that.
-
-[35:45] But some good CSS improvements coming out, like the hasSelector, which is something I've needed on a number of occasions and just never found a way to do it. So I'm excited to see that like browser support is currently there to where you can just use this. You can select nodes in the DOM that contain something else.
-
-[36:05] Previously, selectors were sort of upward looking, like you could, you could select, you could narrow in on children under specific parents, but you couldn't say For all parents of this type of thing, style it this way. So it sort of reverses the direction of control for CSS, or gives you a mechanism to do so, which just unlocks a whole other category of things that you can do with CSS in a way that I think is super powerful.
-
-[36:31] There's also CSS nesting, which is Virtually the only reason I still use Sass anymore, just being able to write rules instead of a series of long lines just like wrapping, you know, nesting them under each other for related selectors. And I don't know that this is one that I would use myself specifically, but I think it's pretty cool.
-
-[36:53] a color function for more advanced control over what color space you're using, which not something I need very often in developing web products, but if you're doing something a little bit more like creative coding, artistry, or trying to correctly render colors in a specific setting, like if you know that this monitor can render this color space accurately, use that rather than sRGB.
-
-[37:19] Um, as somebody who has done a lot of photography and gained an awareness of color spaces through trying to do prints and things like that. I appreciate that this exists, that this is now a function that can be used in CSS.
-
-## [37:31] Why you want React Query
-
-[37:31] **Mark Erikson:** So, Dominic Dorfmeister, aka TKDodo, the maintainer of ReactQuery and Uh, tanstackquery put up a really good post talking about why you want ReactQuery.
-
-[37:43] And I believe this was kind of inspired by a, you know, kind of a tweet that was going around showing like, "look, here's a fetch call and a useEffect. It's like 10 lines of code. How many bugs are there?" And the answer is a lot. And some of it's, some of it's bugs, some of it's, well, here's a bunch of edge cases you didn't take into account, like this, this doesn't have error handling, this doesn't deal with, you know, double fetching in strict mode, this doesn't deal with handling, you know, resetting data or error separately.
-
-[38:14] And so, Dominic kind of walks through the process of, like, if we were to make this 10 line example properly robust, Here's all the added complexity that the example skipped over. And dealing with that complexity is not a thing you want to write for yourself. And this is actually why it's worth using a library, like ReactQuery, Apollo, SWR, RTKQuery, to manage that for you.
-
-[38:44] Because all that really complex logic has already been encapsulated inside the library, you would have had to write this yourself anyway. You wouldn't have thought about it, just use the library. It deals with it for you, it will handle it correctly. But very worth reading to get a sense of here's all the edge cases involved.
-
-## [39:04] Looking back on Decorators
-
-[39:04] **Carl Vitullo:** Cool. I just liked this post. It's not necessarily newsworthy, it's not something new, but 10 years of JavaScript decorators. Decorators have been around in various states for 10 years. It's been 2013, yeah, that I first started hearing about them. You know, Angular went pretty hard on them. There was MobX went pretty hard on them.
-
-[39:26] The actual standardized proposal for how to add them to JavaScript just languished for So, so, so many years. Uh, so I just appreciated this, you know, retrospective on the evolution that decorators have gone through over the, over the years and all the reasoning why it got stalled out and thought it was a good read on a relatively common but very confusing part of the
-
-[39:51] **Mark Erikson:** JavaScript language.
-
-[39:52] I would expect that most people who have used decorators have never thought about what's actually going on under the hood or the fact that the definition and the implementation has changed multiple times.
-
-[40:03] **Carl Vitullo:** Yeah, MobX or Angular, were not exactly shouting about how this is an unstable feature and it has not landed yet.
-
-[40:09] Cool, wanna take us on?
-
-## [40:10] React sourcemaps generally available
-
-[40:10] **Mark Erikson:** Okay, so, another sort of personal note, this is one I've been harping on literally for months. So, way back in like, March, I filed a pull request to modify React's build system to actually generate source maps for production build artifacts. And the PR kind of sat there for a number of months.
-
-[40:32] Uh, Dan briefly tried to review it, and we had gotten some back and forth about, you know, some of the nuances of behavior. I am very happy to report that as of a couple weeks ago, this has finally been merged, and it is actually shipping in React builds right now. And you can verify this if you were to go to, for example, unpkg, and look at React, uh, React or ReactDOM.
-
-[40:57] And if you were to select one of the experimental or the canary builds, uh, experimentals are generated pretty much daily, canaries kind of like every couple weeks or so, you would see that the source map files actually exist in published builds of React today. Now, of course, This brings up the question, when will the next stable build of React come out?
-
-[41:19] Who knows? I'm hearing rumors that they're working on, towards an actual React 19. This doesn't exist in a stable build yet, unfortunately. But when the next stable build comes out, it should actually have source maps. I'm very excited about this. It's not necessarily going to benefit everybody all the time, but it's a missing piece that fills in and anyone who's trying to peek inside React in production will hopefully have a better experience.
-
-## [41:47] Formatter performance bounty
-
-[41:47] **Carl Vitullo:** There was a bounty put out for improving performance of code formatting. Uh, the Prettier organization put out a 10, 000 bounty that was then doubled by, I think by Guillermo Rauch.
-
-[42:02] **Mark Erikson:** I think so, yeah.
-
-[42:04] **Carl Vitullo:** I believe the specific criteria for the bounty was a Rust based formatter that passed like 95 percent of the test cases that Prettier has.
-
-[42:14] And. Yeah, it got claimed. The Biome organization, which is a fork of Rome after that project collapsed, came together and less than three weeks after the bounty was posted, they claimed it. So it was 10, 000 from Prettier, 10, 000 from Guillermo Rauch, and then I think another like 2, 500 or like 2, 250 from an unnamed anonymous donor as well.
-
-[42:38] So yeah, cool.
-
-[42:39] **Mark Erikson:** There was something in the Wasm ecosystem, I think.
-
-[42:42] **Carl Vitullo:** Okay, something like that, yeah. Pretty interesting. I like the thought of open source bounties. I think that's an interesting monetization strategy. It's better than nothing, better than just putting a request out. So I appreciate that some companies were, or some people who had funding were willing to put their money where their mouth was on moving the, advancing the state of the ecosystem.
-
-[43:05] **Mark Erikson:** Yeah, there's a couple nice little extra points here. One is that Fabio Spampinato, I believe is his name, got nerd sniped into looking at the actual prettier source code and trying to find ways to speed it up. And sort of similar to how Marvin Hagemeister has been doing this whole series of blog posts, I'm like, I looked inside this JavaScript tool and it's doing stupidly inefficient things inside. And I made it run faster.
-
-[43:29] Uh, Fabio has been able to find a number of inefficiencies and PerfBottlenecks inside Prettier, and has some proof of concepts of making Prettier itself significantly faster, either through caching or improving cases where it was doing, like, file system lookups.
-
-[43:47] I think it even maybe inspired a PR to Node itself, where the fs. stat call was eagerly creating date objects for file times. And it turn like it turns out, you can just lazily instantiate the date object. Like it already knows the numeric times, but you can just l load the date object when it's actually accessed off the stat object. So like there's sort of a ripple effect of performance improvements going on here.
-
-[44:21] And then the other one was. Uh, Christopher Chedeaux, um, handle vjeux put up a comment on Hacker News describing why he decided to go the bounty route. And it had to do with, like, the best way to improve the ecosystem as a whole is to have multiple competing tools that are sort of egging each other on.
-
-[44:43] And so he wanted to get someone else working on it and then see that kind of ripple effect in let's, let's make all these tools better. And he feels that the money was very, very well spent in that way.
-
-[44:55] **Carl Vitullo:** Cool. Want to take us on?
-
-## [44:56] Mark's self plug, Replay.io webinar
-
-[44:56] **Mark Erikson:** Yep, uh, so we're, we're almost out of time, uh, one more kind of self pluggish kind of a thing.
-
-[45:01] So as I said, my, my day job is working for Replay. io, which is a time traveling debugger for JavaScript. Uh, we've been doing a lot of work this year around not just debugging applications, but building features to help people debug flaky test suites. And so, uh, tomorrow, I'm actually gonna be holding a livestream slash webinar over in the Replay Discord.
-
-[45:26] Uh, my teammate, Philip Crick, has done a lot of work over the years with Cypress and test stuff. And so we're gonna have a discussion tomorrow talking about, like, just debugging. This is actually one of my own personal hobby horses. Like, nobody teaches people how to debug. Conceptually, so we're going to spend some time talking about like, how do you think about the process of debugging?
-
-[45:54] And then we'll look at, you know, replay the tool specifically and talk about some of the features and how you use it to actually dig into an application. So I'm excited. Should be fun.
-
-[46:04] **Carl Vitullo:** Very nice. Always here for a, for a live event, a live chat. Yeah, Phillip reached out to me to talk through what that experience is like. So I hope it goes well.
-
-[46:11] Cool. Okay. That was the last of our lightning round links. Uh, we had a couple of Bonus items, they're a little bit broader, uh, like for instance,
-
-[46:20] Angular has a, they're on version 17 and shipped a new doc site, so, cool, good for them, looks great.
-
-[46:25] Docusaurus 3. 0 was released, which, now that Sebastien isn't here, I feel, I feel like we need to keep bringing in some of the, uh, Docusaurus.
-
-[46:34] **Mark Erikson:** We owe it to him.
-
-[46:35] **Carl Vitullo:** We owe it to him, yeah, right, right, right, he's been such a great part of this show.
-
-[46:38] **Mark Erikson:** The biggest couple updates there are, it now uses React 18 and they've updated the MDX parsing library, so it uses the latest and greatest MDX syntax for intermingling, uh, markdown and react components.
-
-[46:54] **Carl Vitullo:** I got two more.
-
-[46:55] Google has officially released a set of react components for using the Google Maps API. Uh, so I, I think the. Projects like this have existed, but this is the first time one from Google, maintained by Google, has been released.
-
-[47:11] So that's cool. And my last one, this is just fun and silly, but somebody made a Windows 95 inspired UI toolkit for React. So, you know, I love, love a nostalgic style.
-
-[47:23] **Mark Erikson:** Yeah, I've, I've seen a bunch of, like, you know, Win95, 98, 2000 XP, like, CSS packages and, and online demos. As, as someone who grew up with that era, it's, it's always very interesting to see.
-
-[47:38] **Carl Vitullo:** It is now safe to turn off your computer.
-
-[47:41] All right, that's all we got. Thank you so much for joining us.
-
-[47:45] We'll be back next month on the last Wednesday here in the live stage of Reactiflux or back in your podcast feed as soon as we can, hopefully by the end of the month. If you see anything newsworthy in the meantime, definitely let us know in the Tech News and Reads channel. We do use that for sourcing new links.
-
-[48:02] And yeah, you can discuss them with the community in the meantime. All right, thanks so much, everyone.
diff --git a/src/transcripts/tmir-october-2023.md b/src/transcripts/tmir-october-2023.md
deleted file mode 100644
index fc725ee..0000000
--- a/src/transcripts/tmir-october-2023.md
+++ /dev/null
@@ -1,379 +0,0 @@
----
-title: This Month in React (October 2023)
-date: 2023-10-25
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation about React Forget, Canary Releases, Barrel Files, TanStack v5, Yarn v4, and a preview of RTK Query v2."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/episode/4xefEOVBMI7mhfOBvOPnDV?si=NKLNBgn3TqOH7HLNLAIMHw)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/tmir-2023-10-react-forget-canary-releases-barrel-files/id1661733526?i=1000633089166)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux/episodes/TMiR-2023-10-React-Forget--Canary-Releases--Barrel-Files--and-new-releases-e2b7tda)
-
-
-
-- [00:00] Introduction by Carl Vitullo and Mark Erikson
-- [01:04] React Forget and memoization ([02:00] Optimizing performance, [02:35] Used in production at Facebook)
-- [03:52] React Server Actions in canary release ([04:09] Versioning policy)
-- [05:40] TanStack Query v5 release ([06:02] New features, [06:13] Deferring changes for Redux Toolkit Query)
-- [07:42] Barrel files and performance ([08:47] Avoid for build performance)
-- [09:13] React useTransition for concurrent rendering
-- [10:37] Photoshop on the web ([11:07] Collaboration between Chrome and Adobe)
-- [12:42] Yarn v4 release ([13:31] Per-project installs, [14:38] Performance improvements)
-- [15:19] HTTP QUERY verb proposal ([16:05] Standardization for query APIs)
-- [17:01] TC39 group for standardizing source maps ([18:31] Improve debugging)
-- [19:00] Parcel performance improvements ([20:16] Data structure optimizations)
-- [21:04] Replay DevTools time travel talk by Mark at React Advanced ([22:17] Peeking inside React internals)
-
-In summary, this month focused on performance optimizations like React Forget and query API standardization, as well as releases like TanStack Query v5 and Yarn v4. Mark also discussed his React DevTools talk diving into time travel and hacking React internals.
-
-- Mark: React Forget and memoization:
- - Sathya, React India: [Statically analysing React components for fun and profit](https://www.youtube.com/watch?v=kjOacmVsLSE)
- - Joe and Mofei, React Advanced: [Understanding Idiomatic React](https://www.youtube.com/live/tUqY9CP38uE?si=lQTtR0ZUklVhe4it&t=5364)
- - TkDodo: [The Uphill Battle of Memoization](https://tkdodo.eu/blog/the-uphill-battle-of-memoization)
- - Response: [React memo is good actually](https://timtech.blog/posts/react-memo-is-good-actually/)
-- Carl: [Server Actions in canary](https://github.com/facebook/react/blob/main/CHANGELOG-canary.md#october-5-2023-1830-canary-546178f91-20231005)
- - [Version policy](https://react.dev/community/versioning-policy#canary-channel)
- - [Client Actions](https://codesandbox.io/s/react-client-actions-l5729f?file=/App.js)
-- Mark: [TanStack Query v5](https://tanstack.com/blog/announcing-tanstack-query-v5)
- - RTK 2.0: we’re deferring all RTKQ changes until _after_ 2.0!
-- Carl: Barrel Files
- - [Vercel - How we optimized package imports in Next.js](https://vercel.com/blog/how-we-optimized-package-imports-in-next-js)
- - [Speeding up the JavaScript ecosystem - The barrel file debacle](https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-7/)
-- Mark: [React useTransition: performance game changer or...?](https://www.developerway.com/posts/use-transition)
-- Lightning round ⚡️
- - Carl: [Photoshop is now on the web!](https://medium.com/@addyosmani/photoshop-is-now-on-the-web-38d70954365a)
- - Mark: [Yarn 4.0](https://yarnpkg.com/blog/release/4.0)
- - [HN](https://news.ycombinator.com/item?id=37985779)
- - Carl: [HTTP QUERY verb](https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html)
- - Mark: [TC39-TG4 - New Task Group created to standardize Source Maps](https://www.ecma-international.org/news/ecma-tc39-ecmascript-initiates-a-new-task-group-to-standardize-source-maps//)
- - Actual working group: [https://github.com/tc39/source-map-rfc](https://github.com/tc39/source-map-rfc)
- - Example: a proposal for tracking scopes data from my Replay coworker Holger Benl: [https://github.com/tc39/source-map-rfc/pull/53/files](https://github.com/tc39/source-map-rfc/pull/53/files)
- - My own React Sourcemaps package: [https://github.com/markerikson/react-prod-sourcemaps](https://github.com/markerikson/react-prod-sourcemaps)
- - Carl:
- - ~~[Astro 3.2 - View Transitions improvements](https://astro.build/blog/astro-320/)~~
- - [7x perf improvement to Parcel bundling](https://vxtwitter.com/devongovett/status/1712169214872867288)
- - [Neat SIMD/Rust function](https://twitter.com/devongovett/status/1712169225786446111)
- - Mark: [My React Advanced talk: Building Better React DeTools with Replay Time Travel](https://blog.isquaredsoftware.com/2023/10/presentations-react-devtools-replay/)\*\*
-
-[00:00] **Carl Vitullo:** Everyone, thank you for joining us for October's This Month in React. We have a solid amount of news this month. Excited to talk through it with y'all. Some news before we get going. Sebastian Lorber, our past co host and author of the This Week in React newsletter, Is not going to be joining us as a regular co host anymore.
-
-[00:19] He is he's a new father. He just had a kid, so he is taking some well deserved time to be a new dad. He's also gonna be taking a break from the newsletter and he'll show up now and again as a guest, but he's not gonna be showing up every month like Mark and I will be and community news. We the star helper committee is finishing up evaluation for Q three.
-
-[00:42] So we should have some new star helpers. Ready to go in a couple of days here. Thank you so much for joining us for this month in react, where we recap and digest recent developments in the ever evolving react and web ecosystem. I'm Carl Vitullo. I'm a staff product developer and freelance community leader here at reactive flux, the discord for react professionals.
-
-[01:00] And I'm sure everyone knows Mark, but Mark, can you introduce yourself?
-
-[01:04] **Mark Erikson:** Hi, I'm Mark Erickson. I maintain the Redux family of libraries. My day job is working at Replay. io, where we're building a true time traveling debugger for JavaScript applications. And I sort of stick my head in anywhere there's a text box on the internet.
-
-[01:20] **Carl Vitullo:** That is entirely too true. Cool, you want to take us off on our first link?
-
-[01:25] **Mark Erikson:** Two years ago, at the online React conf, the React team announced an early work in progress React optimization compiler, codenamed React Forget, and they had a video demo, and the idea was that this compiler could automatically rewrite the logic in your React components.
-
-[01:48] To do a few different things. One was to replace the need to stick use memo and use callback everywhere. And another is that by actually memoizing the JSX elements that your component returns, it could actually optimize the rendering and performance behavior of the application, but they'd been kind of quiet about it.
-
-[02:10] And they gave a brief update back in a React Lab blog post back in March, where they said, you know, we're working on it, we're doing testing internally at Facebook, there's still a lot of work left to do. I've been keeping an eye on this, and kind of like stalking the folks who are working on this compiler anytime they pop up on Twitter and happen to say anything about it.
-
-[02:35] The good news is, That the React Forget compiler team has popped up and actually given a couple conference talks in the last couple weeks. And they've given us a lot of updates and new information about the status of this compiler. So the first one is that Satya gave a talk at React India, where he kind of laid out what are, what are some of the problems?
-
-[02:59] What does the compiler try to do? Um, gave some examples of cases where really hard situations where maybe you reassign a variable to a different name. And then the compiler has to figure out that these two things are actually the same and how does it try to deal with that? And that was kind of a high level look at what the forget compiler does.
-
-[03:20] But the one that I was really, really waiting for was actually just this week at react advanced. Uh, Joe Savona and Mo Fei Zhang gave a talk entitled, uh, Understanding Idiomatic React. And part of the idea here is that, if your components are correctly written, and follow the, the rules of React, In terms of being pure or not having side effects and that sort of thing, the compiler can make some good assumptions about how to actually rewrite the code inside of there.
-
-[03:52] They, they showed kind of a demo of a playground that they use internally where the compiler will rewrite the logic and it shows what the transform code looks like. And they also gave a status update. And some details. So they said that it's actually being used in production in two different applications.
-
-[04:12] One is the Quest VR goggle store for React Native. And the other is Instagram for web's profile page. And what they said is that in both cases they, they sort of expected that, you know, we're probably going to run into a lot of problems. And I think that in both cases, the code basically just worked and there were some modest performance increases out of the box in terms of initial mount time and re render time.
-
-[04:45] So at the moment, it sounds as if the compiler handles, I think they said like. 95 percent of JavaScript syntax and they've tested it against thousands of different components internally at Facebook. So at this point, they're, they're pretty confident that what they've built works. There is a lot more polish left to do, aren't going to open source it until they are confident it's ready for public usage and they have the bandwidth to offer support for doing it.
-
-[05:20] But I, I've been very tentatively hopeful for like the last couple of years that this is an effort that would actually work out. And after hearing the talk and I actually was sitting next to Mophie at dinner at the conference on Wednesday and was asking her a lot of questions about like, how does this work?
-
-[05:37] What's the status? I am actually very, very excited about this. I honestly think this will have a bigger impact on the react ecosystem in a lot of ways, then react server components will, I mean, they, they solve different problems. They're both useful, but I think this will actually, this is actually a very, very big deal.
-
-[05:58] And then finally, you're related to that. Uh, there were two different articles that came out, uh, kind of back to back with each other. They were actually kind of arguing about how often should you use. The use memo and use callback hooks and some discussion of are you using optimizations in the components?
-
-[06:19] Are you using them just in case a child component might worry about trying to optimize its rendering behavior? And there's a lot of very, very good points being made in both of these articles. But part of my takeaway here is that in a hypothetically perfect future world. The react for that compiler could eliminate the need for us as application developers to even have to worry about that sort of thing because it will all just magically happen and it's good.
-
-[06:51] **Carl Vitullo:** I do like that. One of these conference talks was talking about idiomatic react. I feel like that has always been, you know, through my career, I feel like in all of the different workplaces I've worked at, I felt that I have worked towards a better understanding of what is meant to be idiomatic, like not just What do I enjoy using?
-
-[07:10] What, you know, how do I understand it? But like, how did the original authors intend for this to be used? So seeing a talk about those idioms, about what, you know, how the tool is meant to be used in this context of this compiler that is supposed to make many of those ideas work better or more easily, I feel like it really ties together.
-
-[07:32] Here's why we built it this way. And here's why we recommend these things that are not always Easy or convenient or, you know, transparently improvements. So, uh, I, I like that a lot. I have, I haven't watched this talk. Um, I'm not super familiar with react forget and it's, you know, development and capabilities, but, uh, just purely on, you know, the, the name of the talk.
-
-[07:57] I, I, I love that. I think that's a really good framing.
-
-[08:00] **Mark Erikson:** Conceptually, what happens is that it's a compiler, it knows how to parse your own JavaScript source code and all the arbitrary JavaScript logic you have in your component. Declaring variables, mapping over arrays, conditional logic, use memo, use callback, whatever.
-
-[08:18] It's a compiler. It automatically transforms patterns A, B, and C. Into patterns X, Y, and Z. And so it can do the automatically memoizing you're like automatically handling dependencies for use memo or something like that. But the, in terms of like the, the rendering performance wins, most of us have heard about the react.
-
-[08:42] memo API that you wrap around a component. to keep it from re rendering when the props haven't changed. But there is a little known built in React optimization where if your component keeps around a JSX element reference like, you know, the return of angle bracket div or angle bracket my component And it returns that same element object the next time it renders.
-
-[09:11] React sees that and says, Oh, you're like, you're literally, literally asking for the same thing as last time. I'm just going to skip over that. And it's a little bit like the parent component controlling the memoization of that subtree rather than the child component needing to be wrapped in react. memo to control it.
-
-[09:31] And this has been in React for years, um, even like the first versions of React Redux relied on that optimization approach. And so, part of what the React Forget compiler can do is rewrite all the logic in your component so that it memoizes pieces of your JSX output so that those element objects only get recalculated when the data they need changes.
-
-[09:56] And thus, the automatic rendering optimizations kick in. We can debate whether this is, you know, a, a better approach conceptually, then I don't know, signals and observables and, you know, the various other performance improvements that are being used in the ecosystem today. One nice thing is that this is a build step.
-
-[10:16] So you don't actually have to change any of your code in theory to get the advancements. I don't have a good grasp on exactly how much it slows down the build step. I think Moffay said something like 3, 000 components was taking maybe like a couple minutes? Something like that?
-
-[10:35] **Carl Vitullo:** That's not short. That's interesting though.
-
-[10:37] I where I'm picturing this being beneficial. I can think of many, many times when I have written use memo, you know, use callback optimizations because I want to hint to react that like these are stable references. I know that, you know, by by doing this whole chain all the way up from like the inside of this hook to a component to the transformation being done on that data to where it's being passed in.
-
-[11:04] Thank you. If I want the best possible performance, I need to be intentional about when those references change. And so it sounds like this compiler is trying to do that same kind of logic where I would do it manually, you know, take it in my head and then write it all out. Which often I have found myself backed into a corner where it's like, oh shit, if I want to fix this reference, I need to totally fix all of the other logic around this because I have conceptualized the problem incorrectly.
-
-[11:32] So something I've said about hooks in the past is a lot of the time it has felt more like solving a puzzle. It's like, there is a right way to mod, there's a right way to model this problem. And I end up going down like three dead ends before it's like, ah, here's the one where all the references are stable and all the state is correctly modeled, which is difficult.
-
-[11:56] It takes a lot of work. It takes a lot of time and takes a lot of thought. And then sometimes there's a new requirements like, oh, shit, I can't just casually add this because I spent all this time modeling to a different problem. And now the problem has changed. So that has been a recurring pain point of mine in developing with hooks.
-
-[12:14] So. A compiler that gets me 80 percent of the performance benefit of doing it perfectly without many reworks and, you know, deep problem solving. Sounds pretty great.
-
-[12:27] **Mark Erikson:** Yeah, like it's not going to magically fix every single performance issue or problem with your react code, but if it offloads a lot of the mental overhead that we have trying to think through some of those issues, that alone is a really big deal.
-
-[12:42] Yeah,
-
-[12:42] **Carl Vitullo:** most definitely. Onto our next one, I'm very excited because this is, we've got a new canary out, server actions are now in canary. So this is, server actions came out in next recently. I think we talked about it last month or maybe a month before and yeah, now they're officially in the like react canary channel.
-
-[13:04] More of what I wanted to discuss here is sort of the canary release process. Yeah, yeah. So in announcing this, they linked to their. versioning policy specifically saying, like, look, this is how you use canaries. Uh, and the big thing that it said is canaries must be pinned. So it says if you are using a canary channel, you need to use the, this exact version, not a, not a pseudo matcher.
-
-[13:31] They do not follow SemVer. If you don't want unpredictable breaks, you have to actually pin to an exact version. That seems great. I'm glad to get clarity. I'm glad that they have put out this versioning policy with explicit recommendations like that. This is not a new policy. I think it came out a couple months ago,
-
-[13:49] **Mark Erikson:** came out back in March ish, but we're sort of just now starting to see the first working examples of it.
-
-[13:55] **Carl Vitullo:** Yeah, so I guess, you know, March, they like got all these policies in place and then have been sort of working with next and doing development work. And it feels like now they've kind of turned back and are doing more messaging kind of stuff like this. You know, they announced a new feature and said, here's how to use it.
-
-[14:09] Here's supporting documentation about how we think about it. I appreciate that. That's very helpful. Very
-
-[14:15] **Mark Erikson:** clarifying. And this, this is unfortunately a topic I'm far too familiar with both as a, as a, as a library maintainer and then looking at react specifically. So I think most people are sort of used to the concept of libraries might put out an alpha release, a beta release, a release candidate, and then finally an actual stable release.
-
-[14:38] And we've, we've seen that even before with react, you know, like react, 18 went through betas and release candidates before it went stable. And then they put out 18, one and 18, two with some fixes and react 18, two, the current stable release came out almost a year and a half ago. And meanwhile, next has been.
-
-[15:00] Releasing new features. They've got some of the React core team members working over there, and there's been a lot of confusion over like, what is in the versions of React that Next is using? How can other frameworks actually use any of these things? For the last several years, React has had, uh, so there's both like the stable releases, and they also have an experimental channel, which is just automatically built like every day, every couple days.
-
-[15:29] So it's like straight off the tip of the main branch, whatever got merged in. And those experimental builds also have feature flags turned on so that like literally everything brand new that's in the React repo that isn't even like fully enabled yet is enabled in the experimental builds. But those could always change on a moment to moment basis.
-
-[15:50] So with next at the moment, you, I think you can actually end up with like three separate versions of react going because there's the production version. You probably specified in your own package, Jason. And I think that gets used with like the pages router. There's the canary version, which is a new semi react specific concept where it's like, this is semi stable.
-
-[16:14] It's maybe not like done, done. Maybe we're waiting on some other pieces, but we kind of think it's stable enough to use, and then there's the experimental version where, you know, there there's truly stuff that's, it's kind of wild. And so in next, I think if you use the app router. It's using a canary build.
-
-[16:32] I think a couple other experimental features you can opt into, in which case it uses an experimental build. And, you know, the idea of these canaries is that the React team maybe has some features that are in, that are in progress. At this point, they think they're stable enough that frameworks could use them because frameworks could add additional wrapping on top to kind of like hide the rough edges.
-
-[16:59] There's maybe a couple pieces that are still like waiting to tie into those before they can declare them fully, fully done and ready for a stable release. And unfortunately, up until now, there hadn't been any indication of Here's what canary versions have been released, or here's what features are included in a given canary release.
-
-[17:20] And just within the last week, uh, one of the react dev rels, Matt Carroll actually added a change log for the canaries as a markdown file in the react repo. So that's a step in the right direction.
-
-[17:34] **Carl Vitullo:** Yeah, I was, you know, I was just sort of thinking about, you know, versioning and releases and okay, so there's released versions of react.
-
-[17:42] There's canary and then there's experimental. So that's, you know, the MPM releases the release channels. But then there's also they have apis, right? They have the unstable underscore whatever apis. As well as some that are not even available because they're feature flagged out of the build out of the you know what the code that goes on NPM and I was just I'm just thinking about it's like wow wait so there's like six different ways of controlling how people what features are available and how people are able to make use of them and that's complicated like what a dance you have to do I
-
-[18:20] **Mark Erikson:** have unfortunately messed with some of reacts build system for something else and I've seen The code that controls, like, here's the master list of all the packages that are in the mono repo.
-
-[18:31] Here's all the different kinds of build artifacts that need to get generated for each package. Here's some of the feature flags that control individual features. Like it is really complex.
-
-[18:43] **Carl Vitullo:** I had read a line in the Canary Diversion Policy that I was hoping to find so I could quote it exactly. They talked about how part of the reason they do this complicated dance is because they have multiple projects that are all interrelated.
-
-[19:00] And so, you know, people say like, Oh, well, why don't you just release this, this feature while you're working on that feature? And the answer is, well, we can't release that until we release both. And people want access to that before both of them are ready to be released. And so we do this complicated dance in order to facilitate that.
-
-[19:18] And it's a lot of work that they put into. Structuring and communicating these releases, I knew all of these pieces, but I hadn't quite put them together into like, wait, this is a lot to manage to keep in your head. Mark, take
-
-[19:34] **Mark Erikson:** us on our next link. The next item is that 10 stack query version five is out.
-
-[19:40] Um, this of course includes the react adapters, like react query, as well as the adapters for the other frameworks. They've got some breaking changes. I know they changed things like removing callbacks from the mutation hooks. They've apparently altered some of the, the way you pass in options for the query hooks to try to make that more consistent.
-
-[20:02] Uh, there is a number of new features around, um, how you define optimistic updates. Uh, there is suspense support built in. They have a react server components, streaming adapter, and some infinite queries and dev tools. Uh, and it sounds like they even managed to shrink the bundle size. So that sounds like a very impressive release.
-
-[20:23] Definitely worth checking out. And I will say that wearing my Redux maintainer hat, we're getting close to the release of art Redux toolkit 2. 0, I hope. And part of that was actually cutting scope so that we don't, we are not going to make any real changes to our, to our RTK query data fetching API for 2.
-
-[20:41] 0. Because there's lots and lots of requests for changes. So we're going to defer any changes until RTK 2. 0 is out the door. And once we do, we will be looking very carefully at. React query and looking at some of their APIs and how they designed some of the use cases and frankly blatantly stealing from them, which is good because it means familiarity.
-
-[21:04] And also they've had more time to think about some of these problems than we have. And also we're friends with the maintainers. So we, we cross inspire each other all the time. It's
-
-[21:13] **Carl Vitullo:** not stealing it's standing on the shoulders of giants. Taking
-
-[21:16] **Mark Erikson:** inspiration from.
-
-[21:19] **Carl Vitullo:** Look at you, taking inspiration from a release to talk about your upcoming release.
-
-[21:25] That all sounds really great. I haven't, I still have not really extensively used React Query. I love all of the ideas of TanStack and whatever, but somehow I always... I'm stuck with Redux, so I don't know very much about the past experience or what this new release will change. I'll take us on to our next link.
-
-[21:42] There was some discussion of barrel files that I found really interesting. Berthel put out a blog post talking about how we optimized package imports in XJS. The term barrel file was new to me, though I... Have encountered the concept a great many times in many workplaces. It's it's the index. js file that imports and re exports modules or, you know, various exports from other modules and The problems that they talk about here are not ones that I had specifically observed through my career.
-
-[22:16] So basically what they talk about is these barrel files essentially centralize import or, you know, the module tree, the tree of your modules and sort of act as choke points. So it's like, as soon as you import something from one of these barrel files, suddenly every single module is being pulled in. And I guess, you know, maybe a more familiar.
-
-[22:39] statement of the same problem is low dash bundle size inflation. You know, I'm sure many of us, I have encountered this so many, on literally every project I've worked on, where somebody imports low dash, they do group by from low dash. Then, because tree shaking doesn't work reliably, the entire module gets pulled in.
-
-[23:00] And so, That's usually a bundle size problem, but what Vercel is talking about here is there's a second dimension to that, which is sprawling the module tree has a, you know, a noticeable cost to it. There, there is time spent creating and then navigating that tree of modules and barrel files by acting as these choke points mean that, especially on large projects, that time spent.
-
-[23:29] Looking at the tree and figuring out where code is coming from can explode to like a substantial portion of your build time. So Vercel next talked about optimizations they're doing to correct that for you. They will inspect imports to determine whether they are barrel files and then undo that for you silently on the backend so that you don't pay that, uh, that.
-
-[23:55] Discovery cost of, uh, traversing the tree of modules. That's really interesting. This is a new dimension to a problem I had observed in the past. Another thing that is, this is not exactly the same problem, but a pet peeve of mine that I've seen in more than one workplace is barrel files that rename exports.
-
-[24:14] So they'll import from one place and then re export it. Under a different name. So that's that sort of problem is why I had slanted on like, don't use these. Like there's just, if you're trying to find a particular bit of code in a large code base, barrel files do not help. They make it actively harder. So don't use them.
-
-[24:34] It's a bad practice. But also learning about another dimension of performance problems that they introduce. I'm never going to use barrel files again. It's not great.
-
-[24:42] **Mark Erikson:** I've never been a fan of the concept for a few different reasons. I mean, to back up a bit, I think the argument. For people who have used them is that it's a conceptual encapsulation thing.
-
-[24:55] So the idea is that if you have source slash features slash feature one, and you have many different files with different types of code inside of that folder, you can encapsulate the implementation details inside there by having source slash features slash feature one slash index such as it does the re exporting and other parts of the code base.
-
-[25:19] Should not be allowed to import from the nested files directly. They're only allowed to import from the index file. So they aren't like conceptually poking into things that they shouldn't know about. I can understand the architectural thought involved, but as we noted, there's, there's runtime implications.
-
-[25:40] You know, one is that if I right click a, you know, a component name or a function name, and I say, go to definition, it might end up jumping me to this barrel file instead because of how the compiler is trying to trace things. And then, yeah, like if you are bringing everything through one intermediate file.
-
-[26:02] The imports from a hundred other files, then just trying to import one thing is going to force that file to be parsed and loaded and go look at everything else and parse and load it. And, you know, maybe all those files do get used somewhere, but it also means extra processing time during the build step.
-
-[26:22] Maybe even a little extra time as the application is running. And so Marvin Hagemeister has done a lot of work over the last year, year or so to investigate common tools in the JavaScript ecosystem. Yes, lint and, um, a whole bunch of others. And he's found that in a lot of cases, the internals of these tools are actually doing things very inefficiently.
-
-[26:47] So the post that he has here, it's, it's slightly more theoretical. He's not digging into real code in one specific tool, but he had seen real world code bases where having barrel files was leading to drastic slowdowns in build time, and he created a fake example. Which had like a bunch of nested build tools and then, or a bunch of nested barrel files.
-
-[27:13] And that example made the code base build time explode. And so, yeah, like general, I think generally speaking, the advice here is that in order to kind of help speed up build performance, don't use this pattern. Instead, just go ahead and directly import from source nested file. And it's okay. I
-
-[27:37] **Carl Vitullo:** do empathize with the, the general impulse to do this.
-
-[27:42] It lets you treat your folders like internal modules, which is nice. It's convenience. It causes the pit of failure. It causes the foot gun where if you just do that indiscriminately without thought for how many files it is and without an understanding for like the downstream effects, because I think what really happens here is, okay, you do that once.
-
-[28:03] And then you do it twice, and then you have a pat, you know, 15 models, modules that all do that. And so then anytime you import anything, it gets your entire code base. It has to navigate your entire code base for it. So, yeah, that makes sense. And going back to that, you know, speeding up the JavaScript ecosystem series of blog posts.
-
-[28:25] I just saw, you know, another link that I'm not sure if I made the cut for this, but Parcel was talking about performance speedups. And like they changed their internal data structures, like that's it. Like they changed how they modeled it internally and got like a 5x beat up. So like there is clearly there are some low hanging fruits to make the JavaScript ecosystem faster.
-
-[28:47] So, uh, if this is one of them, then cool, let's, let's get rid of it. We don't
-
-[28:51] **Mark Erikson:** have to just go and rewrite everything in Rust. Sometimes we can look for really stupid code patterns and fix those. Performance.
-
-[28:59] **Carl Vitullo:** It's tough. All right. You want to take us on to our next one?
-
-[29:03] **Mark Erikson:** Yeah. So on a, on a sort of related note, React 18 came out with some new hooks and I think most people probably don't know they exist.
-
-[29:13] And to be honest, I still haven't even tried to use most of these new hooks myself, but I have seen my teammate Brian Vaughn, who used to be part of the React core team, using them because he was part of their development process. You might've heard that, you know, React 18 was going to have a concurrent mode.
-
-[29:34] And then they ditched that. It's not a whole standalone mode. Instead, it's concurrent features. So, there are specific React APIs that, when you use them, Make React handle the rendering process in a different way, being able to split a render into pieces or do some of that work in the background. And so two of the new hooks in particular are use transition and use deferred value.
-
-[30:03] Now, like I said, I have not actually used these in practice. Brian has attempted to explain them to me a couple of times and there's this very, very good. Excellent blog post by Nadia Makarevich, who's written a number of very good other articles about React behavior. And she goes into some detail about how these hooks work.
-
-[30:22] If I can try to explain them, and I'm probably going to get this wrong, so please read the article in the official React docs. UseTransition gives you something akin to setState, but it accepts a callback. And the idea is you're supposed to run the callback, run the startTransition callback, And do your actual update work inside of the callback.
-
-[30:45] And that's basically a signal to react that the work you're doing is relatively low priority and it should kind of be handled in the background compared to other potential renders. The other one is use deferred value. And I think the explanation that I sort of half understand is it's almost like a built in debounce.
-
-[31:08] In a sense. So maybe you're getting a value from some other source and you need to be able to render something now, but there's probably going to be like another version of the value coming later. So so you pass a value directly to use deferred value. And it returns what appears to be the same value.
-
-[31:33] Well, it's actually happening is it's starting one render right now and then it's like scheduling a second render for just a little bit later. So again, I don't have like the best understanding of them because I haven't used them in practice and also because I haven't used them. I don't I don't have a good feel for the mechanics.
-
-[31:50] But that's kind of the idea. It's about telling react that some of these pieces of data are lower priority. Let me do something now, schedule some lower priority work, and then rerender again, later when we've got all the pieces that we need. It's
-
-[32:05] **Carl Vitullo:** reminding me of a performance problem. I hit a couple of years ago when I was building a cryptocurrency exchange, because that's how my career has gone.
-
-[32:13] And we had a detailed list of. Tokens and every token had its own sparkline. And so when there were 40 tokens on screen, that was 40 sparklines. 40 charts is a lot to render. And so performance. tanked, and it took like three seconds to render the page. And I solved that by introducing a wrapper component that would immediately return null and then re render with whatever it was.
-
-[32:40] And I called this, you know, poor man suspense back in the day. Just saying like, Do it later. I don't care. Render something. Render everything else first. And I wonder if this might have been a, if, I wonder if this use deferred value hook might have been an alternate solution to that where I could say, you know, could have fed that little chart data out of this deferred value and gotten the same benefit without adding a Another component to the, to the hierarchy.
-
-[33:10] That's interesting. Okay. Very cool. I use transition is also new to me. I was just sort of trying to read that, uh, blog post, but it's long. I can see why this is a, uh, a concept that you, you've had explained to you more than once, but yeah, that looks really interesting. Very curious to hear more about that.
-
-[33:28] Well, okay. That is all of the news items we have. Should we move on to the lightning round? My first Photoshop is now on the web. This is something that I, I remember reading like an early technical write up about two or more years ago, talking about all of the efforts being done to bring a true, proper, real version of Photoshop onto the web.
-
-[33:50] And I know that there's lots of WebAssembly and WebGL and Canvas and just like, it was. It's truly an engineering effort that advanced the state of the web platform generally in a very real way that I think is quite rare, though, you know, I don't know that it has a ton of immediate actionable relevance for react and, you know, how we develop applications.
-
-[34:15] The byline on this article is enabled by WebAssembly and Emscripten, Web Components and Lit, Service Workers and Workbox, and New Web APIs. Chrome and Adobe enjoyed collaborating on it. So this is, you know, a deep collaboration by presumably the Chrome team at Google and Adobe building Photoshop, getting the web platform into a state where it was a suitable host for a real version of Photoshop.
-
-[34:42] As opposed to, you know, I think a lot of this type of application would tend towards doing the heavy lifting on the server. So, like, you know, if you were, you know, they've got a early screenshot in the blog post of generative fill. Uh, so, you know, like, I think, you know, the, the easy, the, the pragmatic. Just get it shipped approach would be just do that on the server, you know, so I think it's really interesting to see a project like this.
-
-[35:12] I think that this is a once every couple of years level of investment in the platform. It's worth reading. It's worth learning more about just seeing how they did it and why they bothered to do all this effort. Cool. Mark.
-
-[35:27] **Mark Erikson:** Alright, so it looks like Yarn version 4 just came out, and I've been a fan of Yarn ever since it was first released, but the transition from Yarn 1 to Yarn 2 was kind of like the Python 2 to 3 transition, or, um, you know, kind of like the common JSTSM transition, in that there were such major changes in the way this product was designed and used, that it...
-
-[35:55] You know, it caused a lot of frustrations and turned people off. Um, so there's a little bit of background. Yarn 1, like most other JavaScript tools, is installed globally on your whole machine. So, you know, npm i dash g yarn. Yarn 4 are supposed to be installed on a per project basis. So you're actually supposed to copy the, like a yarn, like release binary JS file into your repo and commit that.
-
-[36:30] And you have a config file. And when you run yarn inside your repo, yarn one from your system starts up. It sees the config file and sees, Oh, I'm actually supposed to run yarn three, two, one dot JS that's committed. And then it switches over and starts up the, the low, the local newer version of yarn instead.
-
-[36:53] And I think that concept has confused a number of people. The other big thing is that when Yarn 2 came out, they had this really radical idea about how it would manage the installation of the JavaScript packages. They called it plug and play. And the idea was that instead of extracting, you know, 50 or a hundred thousand files into your node modules folder, it would leave all tarballs.
-
-[37:20] So it's smaller on disk, and there's no time needed to extract everything, but in order to make that work, Yarn has to take over and act as an intermediary layer for any tool that needs to import a library or access anything. And there's so many tools in the ecosystem that expect that real files exist on disk in Node modules, because that's how everything works.
-
-[37:46] So, my own experience has been that, you know, Yarn's plug in play mode is a nice concept, but in practice, every time I tried to use it, there were too many other tools that would just break in some way. But, especially with Yarn 3, they have a standard, let's just extract everything into node modules option, and I've actually found that works great.
-
-[38:07] We're using it in my day job at Replay, we're using it in all the Redux repositories. Um, so the, I've, I feel that works great. So with yarn version four, looking at the release notes, um, they've got a couple fairly fancy new options around validating packages that are installed. Um, being able to define constraints, which maybe makes things work more consistently in a monorepo.
-
-[38:31] Yarn three has a plugin model and they had some official plugins, but they weren't installed by default. And it looks like those plugins do now get auto included with yarn. So they're always available. Uh, they've, they've improved some of the UI output and it also looks like they've improved some of the installation performance as well.
-
-[38:51] So if you're using yarn two or three, it's probably worth upgrading to yarn four. And if you're using yarn one, it, it probably is still worth looking at the newer versions of yarn as well. Uh, there was a lot of debate in the hacker news thread. Um, you know, a lot of people are arguing about, you know, why do we need so many package managers or, you know, discussing the, the transition from yarn one to the later versions?
-
-[39:17] Some interesting reading over there.
-
-[39:19] **Carl Vitullo:** Yeah, as someone who has never moved beyond yarn one, I empathize with all of those. There is a discussion of. a query verb for HTTP requests. Uh, this would be in addition to like get, post, patch, put, delete, now query. This is really interesting. Uh, it seems to be a standardization of essentially like GraphQL.
-
-[39:41] GraphQL, I know, uses slash abuses post, which has some negative consequences just because Host is meant to be submitting information, not retrieving information. Um, so this looks like a recognition that the current verbs are not quite sufficient for modern use cases in so far as the get verb has no body.
-
-[40:05] You can't say you can't give any information along with that request that URL. So, you know, you can do query variables, but like at a certain point, the URL is like. You know, if you have kilobytes of data that you're trying to send back using in the URL has some trade off that's not ideal. Um, and post is not idempotent.
-
-[40:28] You know, it is not understood by the spec. It is not safe to retry post requests. That's not a safe assumption. So, you know, you can write an API where it is safe. But if I'm writing. A fetch library, a fetch wrapper, then I, you know, I can't say I, because it is a post request, I can't reliably retry it. I can't, I cannot write code that does that because it might not.
-
-[40:53] Um, so this is now essentially it. I think my summary would be this is get with a body, uh, with the recognition that it's going to be used to query data. Very cool. I think that's, you know, big platform
-
-[41:07] **Mark Erikson:** iteration. Okay, next up, um, so TC39 is the standards body that deals with the JavaScript language. And they've announced a new working group that is going to try to improve the specification for source maps.
-
-[41:24] Now, if I had to guess, probably two thirds of the people here have no idea what a source map is because you've never had to worry about it. Source maps contain data. They contain all the original code, like your code, as it looked like on your machine, before you hit the build button, and then they tell debuggers and other tools, here's how you map, you know, to do list item.
-
-[41:48] ts line 37 into these 30, these 25 characters in the middle of your application bundle. And so this is how JavaScript debuggers like the Chrome DevTools or my own day job at replay are actually able to show you your original code so that you can step through it, see variables, and do all that stuff while debugging.
-
-[42:12] Source maps are really stupidly complicated. I'm not an expert on them, but I've learned a lot about them over the last couple of years. And there is a current spec for what information source maps can contain, but there's a lot more cases where they could be useful. And like Brian handle more cases. So this working group is trying to expand the specification for source maps and add more information that can handle specific cases so that in the future, once the spec is defined and build tools, output this information and debuggers know how to use this information, they can more faithfully represent what your original code was doing as you're trying to debug it.
-
-[43:01] And so one of my, one of my coworkers, Holger Bentel. Is actually part of this working group. And he even has submitted a proposal that, um, to try to capture information about scopes. An example of this from the, from the proposal is that if you have like three nested function calls, the compiler might, you know, or a minifier might collapse all of those and just say, well, the last function just returns a value.
-
-[43:30] I can just get rid of those first two functions entirely and return this value at like in the production code. That means that the source map might not capture the fact that when you wrote it, There were two or three other functions in the middle. And so when you try to debug it, it sort of ends up looking like you skipped from like above the function into the middle function and never paused anywhere in between.
-
-[43:55] So by capturing more information about scopes. It could do a better job of representing the way you wrote the code. And I'll also put in a self plug for one of my own things. Uh, react has never shipped source maps for its production builds, which is why you, when you see a react error, uh, in production, the stack traces are all gobbledygook and earlier this year, I put up a PR to actually add source maps to react build pipeline.
-
-[44:28] That PR has been sitting there for the last five months. Um, I actually had a conversation with a react team member just this last week at a conference. And I'm, I have tentative hope that maybe that'll get merged sometime soon. I hope, but the problem is even once it's merged, that will only be helpful for future releases of react.
-
-[44:52] That actually include the source maps during the build step. So I've actually done the work to backport my react build pipeline changes. And I generated the source maps that would have existed or react 18 to 18, one and 17. And I worked with someone from the century tool. Who then proceeded to put together build plugins for Webpack, Vite, and Rollup, I believe, so that you can install this package in your app, add it to your build pipeline, and it will automatically use the quote unquote original React source map in your application bundle.
-
-[45:34] Is this going to radically improve your debugging experience? Maybe not, but it hopefully can help in situations like, you know, being able to see error messages and some other things like that.
-
-[45:45] **Carl Vitullo:** Yeah, my kingdom for React source maps. Cool. Uh, I'm going to make a game time decision. I was going to talk about, uh, Astro 3.
-
-[45:54] 2, which has view, uh, transition improvements, but I don't really know that much about view transition improvements, so I'm going to switch it up and talk about Parcel performance improvements instead. Uh, I touched on this briefly earlier, um, The, the, the gist is they're claiming, uh, seven times faster rebuilds on large projects, uh, and lots of other performance improvements, um, no rust rewrite, no, you know, massive core, whatever, replacement.
-
-[46:25] Um, but they talked about, they said 50 percent of the time in bundling was spent looking up values in different maps. So that, you know, they have maps and sets that, uh, determine which bundle routes, uh, each module is reachable from. So, you know, basically like, if you're here, then you can get over here.
-
-[46:44] And they switched out those maps and sets into, uh, bitsets. Which is, I guess, more like, I'm trying to... Retreating
-
-[46:54] **Mark Erikson:** and treating the individual ones and zeros in an integer as if they were bullions.
-
-[47:01] **Carl Vitullo:** Yes, there we go. We have one value that represents multiple flags, multiple multiple different, you know, things.
-
-[47:10] So, you know, by they say that purely by switching from storing all of this data in maps and sets. You know, the, the, the JavaScript, you know, concept of a map or a set new set new map, uh, into this bit set where it's working on a binary level rather than a like string level, I guess, uh, they've been able to get a five X improvement in bundling speed in some situations.
-
-[47:40] So. It just goes to show you that, you know, sometimes you're going to, sometimes rewriting in Rust is right, but also, like, if you're rewriting in Rust, you're basically doing this logic, like, Rust operates on, you know, it's a low level language, whereas JavaScript is, by default, a high level language, you're, you know, in JavaScript, if you're just going to write code the most intuitive way, you're probably writing strings, objects, arrays, JavaScript.
-
-[48:05] But there's nothing stopping you from writing code as if writing JavaScript as if you were writing Rust or C. Um, you can use buffers. I guess not in, not in the browser. You have to use typed arrays. You and data arrays. Right. But, you know, you, it is perfectly feasible to write JavaScript that does all, all of those low level manipulations.
-
-[48:25] And it, yeah, if you're thinking, if, if you ever find yourself thinking like, man, I wish I could just rewrite this in Rust, like. Take that same thinking that you would approach writing it in Rust with and try writing in JavaScript. I bet you'll get halfway there on the
-
-[48:39] **Mark Erikson:** performance. The, the funny thing was though, I don't, I don't know if you caught this.
-
-[48:43] So, there was one little bit that they couldn't do from JavaScript. There's apparently a... an advanced CPU SIMD instruction that they wanted to use specifically for some of the comparisons to make them faster. And you can't access specific CPU instructions from JavaScript. It just, it's just not possible.
-
-[49:05] So what they did was they wrote that one tiny, tiny little bit in Rust and compiled it to WASM. And exposed it to JavaScript. So, because they could, they could use that SIMD instruction in Rust. And so by doing that, it's like they made one little function, which is like, you know, fast bit compare or something like that, and expose that to JavaScript from Watson, that's impressive.
-
-[49:32] Yeah,
-
-[49:32] **Carl Vitullo:** that is really cool. I love the idea of SIMD. If folks in the audience aren't familiar, uh, S I M D, Single Instruction Multiple Data. Uh, it's what powers, it's the core concept behind like graphics cards and like all the AI and the mining and whatever. Uh, you take 600 values that all need the same thing done to it.
-
-[49:53] Modern processors will let you pass in That data and an instruction and we'll just do all of that at once instead of one, you know, instead of doing like tick, tick, tick, tick down a list 600 times it'll just go and do 600 units of work all at once. So, yeah, very cool. I didn't, I, I had missed that. They did use rust for a little bit of that.
-
-[50:16] That's very cool.
-
-[50:17] **Mark Erikson:** Okay, we're about out of time, and fortunately this is the last item on the list. So, self plug. Last week I spoke at the React Advanced Conference in London, which was a wonderful time. Uh, that's also where the React for Git talk was. Uh, the live streams are up on YouTube, um, and the, the individual talks will be available on the, the Git Nation, uh, conference organizers site within the next couple weeks.
-
-[50:43] My talk specifically was titled Building Better React Dev Tools with Replay Time Travel. Most of the last year building some very advanced features for replays, time traveling debugger that rely on poking inside the internals of the react library and the react dev tools in replay. We have the react dev tools integrated so that as you jump to different points in time, you can see what the react component tree looked like at that point in time in order to gather that data.
-
-[51:19] I actually had to go make changes to our recording version of Chrome to say here's every time react rendered and then there's a back a server side back end post processing step opens up the recording goes to each point in time injects the react dev tools bundle code and then extracts the component tree data and then it's even able to take some steps further like if you made a recording of a production application it can use source maps to figure out well and Okay.
-
-[51:51] This components name in production was QZ, but that's actually to do list item from your original code. So let's use the original name of to do list item for the component tree instead. And so I talked about, here's how the react dev tools actually saves and transmits that information. And then I talked about the steps needed to actually do this time travel analysis and replay.
-
-[52:17] Um, and I've semi open sourced the actual code. Uh, the, the code is technically speaking in our proprietary backend repo, but I've copy pasted it to an examples repo. It won't run, it won't compile, but if you want to see... 2500 wines of Mark doing stupid, weird, crazy, mad scientist things. It's available. Heck
-
-[52:39] **Carl Vitullo:** yes.
-
-[52:40] Thank you so much, Mark, for talking through the news with me. Thank you so much, everyone in the audience for sticking with us. Uh, well, I hope everyone has a good Halloween. Uh, spooky season is almost only or almost over. Um, yeah, cool. See you guys next month.
diff --git a/src/transcripts/tmir-september-2023.md b/src/transcripts/tmir-september-2023.md
deleted file mode 100644
index 0e1d866..0000000
--- a/src/transcripts/tmir-september-2023.md
+++ /dev/null
@@ -1,513 +0,0 @@
----
-title: This Month in React (September 2023)
-date: 2023-09-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Jacob Paris, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Jacob Paris](https://twitter.com/jacobmparis), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-Remix v2, Docusaurus v3, Node 20.6, Bun 1.0
-
-- [Spotify](https://open.spotify.com/episode/54ClLvCFL82IG93a4g7vXZ?si=j7G_aMnNSwOid70QPsJcBQ)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/this-month-in-react-september-2023/id1661733526?i=1000629732098)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [Or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux/episodes/This-Month-in-React--September-2023-e29vb6o/a-aadsk3b)
-
-
-
-This episode covers major updates across the React ecosystem, including:
-
-- Node 20.6 adding built-in .env support
-- Remix v2 using extensive feature flagging
-- Docusaurus v3 introducing visual regression testing
-- Astro 3.0
-- understanding React Server Components. Server components enable powerful capabilities like data fetching at the component level, but also introduce complexities around data serialization and scoping.
-- Bun 1.0 as a faster Node.js alternative, aiming to replace many common Node.js tools and improve performance. There was discussion around adoption challenges due to non-standard features.
-- Next.js adding server actions for forms
-- Expo moving towards full stack capabilities, which expands capabilities for mobile apps and could position Expo as a compelling full stack solution.
-- and Dan Abramov joining Bluesky
-
-Key themes were leveraging Rust and other languages for server-side rendering, moving away from CSS-in-JS, and enabling easier major version upgrades through techniques like feature flags.
-
-Sebastien discussed using React Server Components in static site generators like Docusaurus to simplify data fetching without GraphQL. There was also discussion around using languages like Rust and OCaml for improved server-side rendering performance.
-
-Links used:
-
-- [Node 20.6 - Built-in .env file support](https://nodejs.org/en/blog/release/v20.6.0)
- - [Node.js 16 End-of-Life](https://nodejs.org/en/blog/announcements/nodejs16-eol)
-- [Remix v2 pre-release](https://twitter.com/remix_run/status/1696525340640936190)
- - [Upgrade guide](https://remix.run/docs/en/main/start/v2)
- - [SemVer philosophy](https://remix.run/blog/future-flags)
-- [Docusaurus v3 beta](https://github.com/facebook/docusaurus/discussions/9312)
- - [Upgrading frontend dependencies with confidence](https://docusaurus.io/blog/upgrading-frontend-dependencies-with-confidence-using-visual-regression-testing)
-- [Astro 3.0](https://astro.build/blog/astro-3/)
-- [Making Sense of React Server Components](https://www.joshwcomeau.com/react/server-components/)
-- [Expo Router RFC - API Routes](https://blog.expo.dev/rfc-api-routes-cce5a3b9f25d)
-- [Bun 1.0](https://bun.sh/blog/bun-v1.0)
- - [My Thoughts on Bun](https://adventures.nodeland.dev/archive/my-thoughts-on-bun/)
- - [Announcing Biome](https://biomejs.dev/blog/annoucing-biome)
-- ⚡️
- - [React-Native running natively on Apple Vision Pro simulator demo](https://twitter.com/o_kwasniewski/status/1701626162521190688)
- - [Are Big Projects Ditching TypeScript?](https://www.totaltypescript.com/are-big-projects-ditching-typescript)
- - [Rust Server Components](https://anto.pt/articles/rust-server-components)
- - [Web Developers, CSS-in-JS is Ruining Your Product](https://cord.com/blog/migrating-from-css-in-js-to-vanilla-extract)
- - [Dan Abramov joins Bluesky](https://twitter.com/dan_abramov/status/1695566446007386214)
-
-[00:00] **Carl Vitullo:** Hello everyone. Thanks for joining us again for September's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. I'm Carl. I'm a staff product engineer and freelance community leader at Reactiflux, the Discord for React Professionals, where you are! Joined today by Jacob Paris and Sebastian Lorber.
-
-[00:22] Jacob, do you want to introduce yourself?
-
-[00:24] **Jacob Paris:** Yeah, sure. Thanks, Carl. So I'm, working in DevRel at the moment. I've been a React dev since, not quite the start, I was one of the later later laggards to drop off of Angular, way, way back then. And on the side I'm an egghead instructor.
-
-[00:38] So I've been producing a lot of content primarily for the Remix ecosystem. And yeah, just trying to share and teach as much as I can.
-
-[00:46] **Carl Vitullo:** Well, also you send out a monthly Remix newsletter yourself, don't you?
-
-[00:49] **Jacob Paris:** Yeah, yeah, I do. So that, that one's called Moulton. I took over as a writer of that. Pretty recently and pretty similar to the this week in react, but it's specifically focused on the Remix ecosystem. So, the, all the cool libraries and articles and courses and updates from the team and everything cool that's happening with Remix.
-
-[01:08] **Carl Vitullo:** Nice. Yeah. A lot going on there. Yeah. And Sebastian?
-
-[01:12] **Sebastien Lorber:** Yeah. So I'm Sebastien Lorber, and you probably know me for the this week in React newsletter, and I'm also the, the maintainer of Docusaurus, which is now, the version three is in beta. So you can give it a try if you want and, give me some feedback.
-
-[01:28] **Carl Vitullo:** Cool. All right, let's jump into it.
-
-## Node 20.6
-
-- [Node 20.6 - Built-in .env file support](https://nodejs.org/en/blog/release/v20.6.0)
- - [Node.js 16 End-of-Life](https://nodejs.org/en/blog/announcements/nodejs16-eol)
-
-[01:30] **Carl Vitullo:** I guess my first link here is new. It's not actually react or react related directly, but it will affect the ecosystem. New Node version 20.6. Really, my big highlight here is they're pulling in dotenv support to the runtime properly. So no more dotenv. We don't need to install a package, we can just use dotenv files.
-
-[01:55] Yeah, a lot of the other changelogs look pretty deep and wonkish. There's one that looks like it might be really interesting or might have really interesting echoes throughout the ecosystem, but I'm not really sure exactly what it is about.
-
-[02:09] It's something about registering module hooks Module customization hooks. They have a call out in the change log saying that those module customization hooks can now handle both ES modules and common JS sources. I don't know exactly what those are for. The reading about them in these release notes was the first time they'd ever crossed my radar. And there's not really a lot of information about what they're for in here.
-
-[02:32] But anything that starts talking about cross-compatibility between ES Modules and CommonJS is like, very interesting to me because that has been such a pain point for like. tears at this point. So that caught my eye too, but it looks like most of these other changes were relatively minor and you know, classic LTS cycle, now node 16 is end of life though.
-
-[02:55] We were using those for reactibot. So if you're using node 16. Stop it. Time to update. Yeah, Jacob, Sebastian, anything you want to chime in on there? Not a lot to discuss there.
-
-[03:06] **Jacob Paris:** Yeah, the CJS ESM incompatibilities have been largely a nightmare for my entire history of being a developer. To be honest, I don't know how new devs really Understand the stuff when they pick up.
-
-[03:21] It's like, you know, which import format do you use? You've got configurations that are automatically generated by different different packages, ESLint, Prettier, and sometimes they work and sometimes they don't. And I, I don't know how anyone makes sense of it. I am all on board for the ecosystem moving toward ESM here in the future, where maybe there's only one thing to do.
-
-[03:41] Or we can go with Bun's approach where everything just works together and it's up to library authors to sort things out between ourselves. I'm, I think that's okay as well.
-
-[03:51] **Carl Vitullo:** Yeah. On your note about people learning web development right now something that has bitten me a number of times is, like, Sindre Sorhus has, all of his packages now are ESM only.
-
-[04:04] And if you want CommonJS, you've got to decrement the major version. And that has bitten me so many times where something is inexplicably broken and I just need to, like, remember which are his packages and decrement them. So it's, yeah, hopefully, I have a lot of fingers crossed here that this is going to make that better, but, you know, we'll, we'll see what it does.
-
-[04:24] It does say, "this should simplify the customization of the Node.js module loading process as package authors can customize more of Node.js without relying on deprecated APIs such as `require.extensions`." So hopefully, we'll see.
-
-[04:37] Jacob, you want to take us off on our next link?
-
-## Remix v2, major release feature flagging
-
-- [Remix v2 pre-release](https://twitter.com/remix_run/status/1696525340640936190)
- - [Upgrade guide](https://remix.run/docs/en/main/start/v2)
- - [SemVer philosophy](https://remix.run/blog/future-flags)
-
-[04:38] **Jacob Paris:** Yeah. Yeah. So I guess the biggest thing from the Remix ecosystem at the moment there is that they just launched the V2.
-
-[04:45] It was quite an underwhelming release, every new feature that came out, everything has already been in place for weeks or months now via feature flag in the previous versions. So anyone who's already running that you know in, in production or in any of their apps they've already been able to opt in to the FeatureFlag, upgrade things and move on.
-
-[05:05] And, you know, if that didn't happen by now, I guess now's your chance to do that before you increment the major version. So in theory, that should make it a really smooth transition for pretty much everyone to upgrade. But then on the same note of ESM versus CJS issues, one new thing that happened is that, with Remix V2, it now has first class support for ESM, which just wasn't a thing before.
-
-[05:28] So now in your dev server, you can run full ESM applications. And, in that process of releasing the new version, they've also changed the default from CJS to ESM. So, um, there's been a lot of people kind of struggling with incompatibility issues because, you know, previously their new applications were being made in CommonJS.
-
-[05:49] And now they're, now they're being made to support ESM and some config files that they've been trying to copy over from other files or from examples that they've copied online old repositories. Now, they just need to be tweaked a little bit, and it's usually not that much work.
-
-[06:05] But there's small changes that need to be done, and you need to know what you're doing to do that. That said, Remix still supports CommonJS, but since they changed the default, there is now this friction and this, this transition period that people are having to go through.
-
-[06:18] **Carl Vitullo:** That's awesome though. Maybe I can stop decrementing my Sindre Sorhus modules.
-
-[06:23] **Jacob Paris:** (laughs) In general even if you're going all in on ESM, you should still be able to run CJS packages by running them through a Bundler beforehand. So they have to be Bundled rather than running natively but just because you're moving toward ESM doesn't mean you no longer have the capacity to use CommonJS modules.
-
-[06:42] It's just a little more work to get them running in the same runtime.
-
-[06:45] **Carl Vitullo:** Okay, very cool. Very nice. Yeah, I was reading a little bit about, you know, in there, in the V2 announcement post, they talked, way more than any, you know, new releases, new features they talked much more about their update, upgrade philosophy, which I thought was really interesting, like the, you know, vertical space associated with advertising what they were releasing versus advertising how they released it.
-
-[07:10] I thought it was an interesting choice, but I really loved the philosophy that they described. I just put a link and link to it in chat. But they, I pulled out a couple of quotes because I thought they were really clever and just useful, kind of useful to hear.
-
-[07:24] For anyone in the ecosystem who's going to be consuming libraries, and maybe also for library maintainers. But if they talked about Semver, "Semver gives us a way to communicate when breaking changes exist, we do not have a similar agreed upon process of how to introduce breaking changes in our frameworks and communicate them to application developers."
-
-[07:42] and they talked a lot about like the long running feature branch development for upgrades, which is a pain I have felt a number of times in my career. I have been that developer maintaining a feature branch for a month, two months, three months, constantly merging back in, rebasing off master, repairing merge conflicts, doing all that.
-
-[08:03] So seeing them talk about the efforts they've gone through to avoid those problems was like, Oh, this is really interesting. I didn't realize that it was like technically feasible to really do this.
-
-[08:16] So yeah, I thought that was really cool.
-
-[08:17] **Sebastien Lorber:** Yeah, I agree. But I have something that I don't really understand is there are some things that are really hard to ship with a future flag, you know, for example in Docusaurus, we upgraded recently to MDX two and it's. Completely different from MDX one on the inside, the AST is completely different, the packages were migrated to CommonJS to ESM and there are many things like that.
-
-[08:43] And I think like if you wanted to. To bring support to MDX2 with a future flag, you would have to vendor the MDX library and all, many dependencies to be able to support the two versions at the same time, and we would have to maintain two copies of the code somehow. I don't know, but For example, I was wondering if Remix version 2 will have support for server components as a future flag, or if it will come only with version 3 at the release time, because it looks like a complex thing to ship as a future flag somehow.
-
-[09:24] **Jacob Paris:** Yeah, yeah, it's, it's definitely challenging and you sort of have to pick and choose which features which features you go with. I'm not 100 percent sure when the RFCs for how Remix is going to handle Server Components are coming out. But, you know, that's something Ryan Florence is working on at the moment. So we'll have a little more information when that comes.
-
-[09:45] But for example, yeah the... You know, updating big major dependencies, like you couldn't feature flag having support for example, React 17 versus React 18 at the same time. So that was one of the big things that Remix did update in the v2.
-
-[10:04] So you can run v1 with all the feature flags enabled on React 17, but at the time you update to v2 officially, it does drop support for versions of React prior to 2018. And it was the same with the, with the CJS ESM thing. That's just, it's not practical to try and, you know, run those side by side in, in everything.
-
-[10:23] So the official first class ESM support, was also sort of a, an add on that came in with the with the new version rather than trying to feature plague that. So I definitely see a lot of value in them as a tool where, you know, as long as you can choose not to break things for your developers, and to give them an incremental path to adoption, you should do that.
-
-[10:47] But you know, as you've said, sometimes with bigger dependencies, sometimes it just can't be done. Yeah, it makes sense. I guess, I guess another, another thing I'm so happy that Remix is going down this road is because developers are just terrified of major version releases. Um, like if you look what happened with Angular, moving from Angular 1 to Angular 2, you know, with React going from React class components to React hooks.
-
-[11:11] You've got Vue 2 to Vue 3, and now, like, all the dialogue I'm hearing with Remix, you know, despite how loud they are taking up the entire announcement post to talk about it. The way this major version release process is working, you're still getting people asking, "well, is this stable yet? should I wait a little later? I don't want to start a project now if I'm going to have to refactor and change everything later."
-
-[11:35] There's just such this ingrained culture where major version updates are, are, are terrifying and not something you want to put a project through if you don't have to. People would rather wait and delay things than Adopting and having to go through that transition period.
-
-[11:50] So if, if what Remix is doing here can really catch on and start to make this a little less painful for upgrades, then yeah, I, I am all for that.
-
-[11:58] **Carl Vitullo:** Yeah, agreed. Definitely true that there's a lot of fear around major version upgrades. And, you know, I, I maybe actually, maybe it's less fear and more just like trauma because so many of the you know, it's not unbased.
-
-[12:11] It's not like, you know, you've heard stories to keep you up at night. It's just like so many people have had lived experiences of, "major version upgrades are super painful." So I hopefully this is a trend. I love this direction. I have to imagine that feature flagging things is this aggressively in a framework is, technically challenging, technically complicating. So yeah, hopefully we'll see it more. Hopefully it's not so complicating that it's difficult for other people to copy, because I love this. I hope this becomes a trend.
-
-[12:42] Sebastien, you want to take us off on our next link?
-
-## Docusaurus v3.0
-
-- [Docusaurus v3 beta](https://github.com/facebook/docusaurus/discussions/9312)
- - [Upgrading frontend dependencies with confidence](https://docusaurus.io/blog/upgrading-frontend-dependencies-with-confidence-using-visual-regression-testing)
-
-[12:45] **Sebastien Lorber:** Yeah, so I thought that as we were speaking about being afraid of upgrading dependencies, actually I posted an article last week about the subject. And it's related to the Docusaurus version 3. So I was working for, on the version three for a very long time. Now it's a, it's an upgrade of the infrastructure, including React 18 and, and MDX 2.
-
-[13:11] And, this changes, not, MDX two can have a lot of, weird side effects. For example, you add. MDX content and it rendered nicely previously. And now if you, if you upgrade to version two it eventually fails to compile now. So you have to reflect all the content of it. And also it can render differently, even if it's compiled.
-
-[13:33] So. you are not very confident that actually the, the upgrade is safe unless you took, you take a look at all the pages of your documentation or your blog or whatever it is and, take a look at all of them and be sure that it renders exactly like before. So, um, what I did for Docusaurus and this is now, um, A solution that, we recommend to our users is to adopt a workflow of visual regression testing.
-
-[14:03] So, the idea is that you take a screenshot of all the pages of your documentation website. And, you do this on the main branch and on the pull request branch, and then you use a tool that can be, something self hosted or external, and this tool permits you to tell you which are the differences between your upgrade branch and your, and the main branch.
-
-[14:28] So, if you have visual regressions that you don't expect, the tool is able to report it as a GitHub commit status. And so, I wrote a blog post about the setup that I used. It's based on GitHub Actions, Playwright, and Argos, which is an external tool to handle the screenshots. And I thought it was quite interesting.
-
-[14:50] I used it in the context of Docusaurus upgrades. For example, while upgrading the React Native website last week, we... catched a few bugs, in the process thanks to this workflow. And I think it can be easily, adapted to work on other sites. What I did to get the, all the pages of the site is to read the sit map point, the XML file, and iterate on, on the list of path.
-
-[15:18] So as long as you're able to take screenshots and are able to get a list of page of your site I think you can try to adopt this workflow and if you want to do a dependency upgrade, then you can do and compare and see if there is a visual difference being reported by the tool that you use.
-
-[15:37] **Carl Vitullo:** Yeah, very nice.
-
-[15:38] I've heard about this kind of visual regression testing. I feel like I've heard about it four or five times over my career. And every single time it hasn't really worked out. Or, you know, I've tried it and it, you know, the the experience doesn't quite work out. But I'm reading about I'm reading your blog post.
-
-[15:57] And I love the idea of I feel like maybe the technology now has developed to the point where it will actually work now, because like Playwright, I've heard only phenomenal things about. Everyone I've talked to who has used it has said that like, yes, this is great. This is what integration and end-to-end testing should be.
-
-[16:16] And GitHub Actions is finally like a great task runner for services like that. whereas, you know, I remember trying to set up this sort of tool in like Jenkins, like eight years ago, and it was like, Oh, I don't, this doesn't work. So yeah, this seems really cool.
-
-[16:34] Cool. Well,
-
-[16:35] I can take us on to our next one then we are going to get to Bun 1. 0, but I want to, I'll say we're going to save that for the end.
-
-## Astro 3.0
-
-- [Astro 3.0](https://astro.build/blog/astro-3/)
-
-[16:43] **Carl Vitullo:** So right now, I want to talk about Astro 3.0, I actually have not yet used Astro very, very extensively, but I have heard only really great things about it and it's a, it's definitely something I want to check out. I think I've heard about it being like very good for like personal sites, portfolios, like relatively smaller marketing sites.
-
-[17:06] So, you know, as I'm looking at making a personal, professional blog or revamping the Reactiflux website. Very interested to give that a shot, give it a real chance of and see how it works out. But yeah, Astro 3.0, new, new release. I don't know. Have either of you used Astro at all, very much?
-
-[17:25] **Sebastien Lorber:** no. But I think it's interesting because, you know, the view transitions make it more, looking like, single page applications. And now that they are able to persist the state between, page transitions, that's becoming a really interesting solution. What I'm afraid, for example, for now, is that if you use third party widgets like intercom, chat, and things like that, If you navigate from one page to another, you would like this kind of widget to persist the state because it's really annoying, you know, to have the chat that resets itself.
-
-[18:00] You are in the middle of a conversation with the support team or something and you click on the link and then, everything is lost. So if they can solve this program, I think it's it's really great for us too. And for multi page applications in general.
-
-[18:13] **Carl Vitullo:** Nice. Sadly, I can't speak very, much more deeply than I already have on this, but yeah, definitely excited to give it a shot. And I love when new versions come out before I have fully learned them. So then I only have to learn one thing instead of two.
-
-[18:28] Jacob, you want to take us on to our next one?
-
-## Josh Comeau's Making Sense of React Server Components
-
-- [Making Sense of React Server Components](https://www.joshwcomeau.com/react/server-components/)
-
-[18:29] **Jacob Paris:** Yeah, sure. So, Josh Comeau put out this great article about, React Server Components. So I, I've kind of been sleeping on React Server Components for a long time, because They've always really confused me.
-
-[18:45] So when the information was first coming out, there was, there were so many different ideas about how these are going to work. And then you start seeing examples and some of the examples are coming from the React team and some of them are coming from the Vercel team and then people from React move over to Vercel and then you get you know, examples from the from the code bases of either moving back and forth.
-
-[19:06] It was just, it was always so unclear, which, you know, in any example you see, which parts were React and which parts were Next. And so, so for me as a, as a Remix developer, I'm wondering, you know, which parts are going to stay in React that then Remix can build on top of and which parts are belonging to Next that, you know, Remix may either have to, may either have to clone or continue to build on top of.
-
-[19:32] For a long time, I just, you know, I kept seeing these server components, and I just really didn't know much about what they were. which is why, yeah really glad Josh has put out this article, because reading through, everything makes quite a lot more sense now. The server components are basically a new model here, where every React component we've dealt with in the past has now been renamed to a React Client component, and these React Server Components render only on the server, and they only render once, and it's a Almost like server side rendering, but instead of executing once and then being all the HTML to the browser is they can render and then send all the information React needs to hydrate a React component to the browser in fact, in practicality, what this means is we can have async data fetching happen right in our components, which is fantastic, And any time you include a client component in there, everything that component imports just works exactly like, components we've had before.
-
-[20:39] It unlocks a lot of abilities that we primarily couldn't do before in terms of composition, for example, in say, in Remix and in Next.JS before this, you can have a, a loader or your get server side props that fetches data, and then it passes it to a server side rendered components.
-
-[20:58] But there was never any way to do that at the component level that always had to do, had to happen at the route level where you would have a, you know, each route would become an end point and you can. You know, you generate your components based on the data that endpoint returns. So there are the server components, um, you could almost model it, you're getting, you know, individual little endpoints for every single, every single component you have, and they can, they can be composed together just in the same way we're already currently using, React, which I, which I think is fantastic.
-
-[21:33] There are some issues with it still, that, that I don't I'm still not 100 percent sure how they solve or how they're going to solve, for example, data serialization. If you're sending data from the server to the client, say you have a date or a map or a set, the client is going to receive that as just just a string or, you know, a stringified array.
-
-[21:55] And... When you're dealing with a very visible network boundary, like you've got a loader and a react components or you've got your server side props and then your react bit it's pretty easy to see where that boundary is, but now with the server components, you can create that network boundary simply by passing data to a prop in a client component, and I just think that's really, really subtle at the moment, so I'm not 100 percent for you know, if that's actually going to cause problems in practicality, you go inside that component, and now your types are just a little different than they were.
-
-[22:30] In the server components it seems like that's going to be space for people to get confused.
-
-[22:36] But all in all the components that these enable are, I think, I think, fantastic. Like, we're looking at, you can imagine a component that render, or that syntax highlights code for you. So you just pack text and it's got all the syntax highlighting built in without needing to ship megabytes upon megabytes of, libraries to the browser to make it understand every programming language it could support.
-
-[22:59] you could imagine a, say an image component that automatically. You know, pre process the image based on its, you know, widths and heights and any resolutions you set. Next already has a sort of proprietary version of that, but it only works on Vercel hardware. Because they are, if they're in charge of the deploy process, they can then transform your code to make that work.
-
-[23:22] But this will now enable that to work on any hardware that supports React Server Components. So yeah, I'm super excited about it. The ability to do that and then you can publish these full stack components in libraries as well. And then users can just import them and things will work full stack, which is you know, it's just, it's, it's, it's unlocking new abilities that we just couldn't do before.
-
-[23:45] **Carl Vitullo:** Yeah, unlocking new abilities really does seem like the big thing here. I feel like I, I too have kind of skimmed past this, despite talking about it with some frequency on this event. But it just, I, I can sense that it's going to be a very wide and deep subject, and I just don't feel like... Like, okay, I can write a toy project and get a little bit of experience of what it's like using it.
-
-[24:08] But, you know, that won't really tell me everything I need to know about what are the performance characteristics for like 99th percentile users or, you know, there's just like such a long tail of things to learn about how it will affect development and performance and user experience and all of those things.
-
-[24:28] And so I feel like I'm going to keep saying, "I don't think I really understand this" for a very long time because the implications are going to take a long time to really shake out.
-
-[24:38] **Jacob Paris:** Yeah, and there's there's some new sort of, foot guns coming in that people will have to watch out for like, for example, you know, it's super common.
-
-[24:45] You have an array of data and you, you, you, you map through it. And on each iteration of the map, you're, you're creating a component, but they have a list mapping through and creating a list item in each one. The, the data you pass to that list is going to be. Individually serialized for every item in that list, if you happen to pass any large document React Server Components are not going to de duplicate that for you.
-
-[25:10] So you, you can end up with tons and tons of data. Ryan Florence was saying there was something similar in in a Shopify Hydrogen application that functioned in, in largely the same way. And yeah, it's, we're, we're introducing a whole new set of you know, things that people are going to have to watch out for if they want to have performant code.
-
-[25:30] I'm really hoping that when this kind of hits mainstream, there's either going to be enough messaging or maybe lint rules or something, you know, maybe some just physical boundaries put into the framework to stop people from making mistakes like this. Because it just, at the moment, it seems really, really easy to make a lot of mistakes.
-
-[25:49] **Sebastien Lorber:** Yeah, I wanted to mention another use case that you maybe didn't think of is you, you know, maybe you used Gatsby before with the GraphQL layer to inject data in, in pages, I think actually, um, React Server Components could be a very good alternative to that, and this is what I'd like to explore in Docusaurus actually, because, you know, the server components do not really need to run on the server.
-
-[26:13] You can actually run them at build time, as part of your build process, so a static side generator like Docusaurus is able to also use server components at build time. And this can give the ability to have a very flexible data layer. So instead of using static GraphQL queries in pages and things like that, you would be able to actually use Node. js code inside Interleaved with the client side React code and be able to inject the right data at the right place without actually the need for creating a complex GraphQL query and things like that. So somehow From my Docusaurus perspective, what I just have to do is to expose the data structure and let the user pick the right, data structure from it from right of a component and inject it in a subcomponents.
-
-[27:08] So, you don't need actually to have something more advanced. You can just use a JavaScript to get the right data at the right place. And you can do it both at the runtime or at build time.
-
-[27:21] **Jacob Paris:** Okay, I, I like that a lot actually. So, so you'd be able to have all of your, um, all of the components in Docusaurus that you're using.
-
-[27:30] Each component can have its own GraphQL queries to fetch the data it needs to do. And then you're sort of... Flattening all of that at a compile time, they just fetch the data, it turns into static content.
-
-[27:42] **Sebastien Lorber:** Actually, the goal is, the goal is to actually not use GraphQL because this is what Gatsby does, and I think the community didn't really like it. it was a bit too complex. So, um, and one of the shortcomings of Docusaurus is that we are, we use a plugin architecture. So we have a blog plugin and a docs plugin, and they don't see each other. And the problem is that, for example, if you want To display the free, the last three blog posts on your docs. It's impossible because the docs doesn't have access to the blog. So, using server components make it possible for you to override, the docs components and from there read the data structure provided by another plugin and somehow this provides a lot of flexibility thanks to being able to do this, some part of the code, running in the Node. js side.
-
-[28:35] **Jacob Paris:** Oh, cool. Cool. Yeah. I like that a lot. That's that is super cool.
-
-[28:39] **Sebastien Lorber:** Yeah. We'll see if it works out. I don't know yet, but I think it will.
-
-[28:45] **Carl Vitullo:** Nice. Interesting. Yeah. The data fetching side and the actual experience of developing and using that is like what I most specifically would like to check out. And I just, I, I don't have an app that I'm working on right now that has those needs, so I, I don't really know how to get that kind of experience that I'm really hoping, hoping to learn.
-
-[29:04] But yeah, on the, on the subject of foot guns, there's a, there's a quote that I love from the guy who made C++, and it's about C and C++, but I think it applies here a little bit, you know, like these server components are like really powerful new tools, but the quote is like.
-
-[29:21] C++ has fewer foot guns, but when you hit one, you blow your whole leg off. And that feels a little bit like where we're at. It's like, you know, we have this powerful new tool and we're still figuring out what, you know, what, what's just like a little injury and what's like a major wound. So, you know, we're gonna, we're gonna, we're gonna, we'll take some time to settle.
-
-[29:42] **Jacob Paris:** Yeah, I think Ryan Florence had a similar quote talking about the server components. He said, you know, this is a very sharp knife, and I like that, but it doesn't have a handle. I would really like a handle.
-
-[29:52] **Carl Vitullo:** Haha. That's actually, I love that metaphor. That's really good. Because that's, yeah that, I feel like that touches on a lot of the complaints that I've heard about this, server components rollout over the last couple of months. I hadn't seen that quote. That's a really good one.
-
-[30:05] Nice. Okay. Well, I'll, I'll move us on to our next subject.
-
-## Bun 1.0
-
-- [Bun 1.0](https://bun.sh/blog/bun-v1.0)
- - [My Thoughts on Bun](https://adventures.nodeland.dev/archive/my-thoughts-on-bun/)
- - [Announcing Biome](https://biomejs.dev/blog/annoucing-biome)
-
-[30:08] **Carl Vitullo:** Um, Bun 1. 0 is officially released. There's so much to talk about there, I think. Bun is so many things, but I don't even know where to start.
-
-[30:21] it's an all in one toolkit they're describing themselves as. there's a huge focus on performance, which is really interesting. They have, I, my favorite performance stats that they quote is they're 40 percent faster at running like 200 and something unit tests than Jest is at printing its own version number. So not even running tests, just like startup and print version number exit. Bun runs all the tests 40 percent faster than that. Um, so hilarious stat.
-
-[30:52] They are claiming to replace a huge list of tools. I'm just going to read this off node, npx, dotenv, although now node has gotten rid of dotenv as well, so that's, there's one bullet point off the marketing that the marketing list they also replaced nodemon, the WS package for web sockets, node fetch, cause fetch is built in, TSC cause it's a compiler Babel, TS node, TSX, esbuild, webpack, parcel, rollup. NPM, Yarn, PMPM, Lerna, Jest, Vitest. So like that's, that's quite a claim.
-
-[31:29] it reminds me a lot of the original promise and claims of Rome as a project, which is unfortunately well, Rome is no longer a thing, now Biome is a, an open source fork. But, so I'm keeping an eye on that too. But. Bun is claiming to be a drop in replacement for Node, where any existing Node application just works in Bun.
-
-[31:53] I know that they also have introduced a number of non standard behaviors. One of my favorites is that they allow you to read input from the console as an iterable, so you can do like `for (input in console)`, and then within the for loop, like boom, there's your REPL, three lines of code. So like, there's a lot of really interesting things that are phenomenal developer conveniences for some specific use cases, but it's non standard.
-
-[32:21] So if you write Bun code. You can't then port it, you know, just run it in a different runtime because that's non standard. It's not specified anywhere. So that seems a little fragmenting to me, but also a lot of these, a lot of the non standard improvements seem really cool. So maybe they'll get standardized. Maybe it'll be a CoffeeScript kind of situation again. Yeah, I, let me, let me hand it back to the floor. Anyone else have thoughts on Bun.
-
-[32:45] **Jacob Paris:** Yeah, yeah, I'm always a little torn on when it comes to non standard features like this. I think it's super cool that Bun can do, that Bun can do all of that.
-
-[32:55] They've also got their ESM and CJS interop, so you can have CommonJS imports, with the require syntax, and ESM imports with the import syntax, all in the same file. And you know that that's fantastic for developers who no longer need to worry about this. But then you look at a larger ecosystem, yeah, any, any libraries built on this they're only going to work with Bun.
-
-[33:17] They won't work on Node and everything else. And that's, that's, it's been a quite a contentious point in the, sort of library ecosystem. Like, it's, you know, it's nice to have these for developers, but is this going to really fragment the ecosystem? Are we going to end up with a bunch of Bun only libraries?
-
-[33:35] **Carl Vitullo:** Yeah, sure. I, I also, I, I read a a, a blog post from one of the node core team members. Just his thoughts on Bun. I thought it was really interesting. This was just sort of a, it was a very grounded take in comparing node versus Bun, and like it has, why is Bun faster than Node.js? And the first item on it is Node. js has no budget and a tiny team maintains NPM.
-
-[33:59] So it's like, they're just talking about very much about the practicalities, not just the code reasons. And yeah, I mean, like, so Buns, Bun 1. 0 announces it as like a drop in replacement for Node. js. This you know, other blog post from a core, a Node core member says Bun does not currently support Fastify.
-
-[34:20] Which is a reasonably popular competitor to express. So like, yeah, I mean, if you're not supporting like one of the top five HTTP servers, then like advertising it as a drop in replacement seems maybe a little bit overstating it. so I don't know, there's still, still a little bit of, a little bit more improvements that I'm going to be keeping an eye on.
-
-[34:40] But honestly, one of the most exciting things for me about Bun is, or rather, something about Bund that fixes a problem I've heard about for so many years now at this point is Node. js slow startup time. You know, like exactly, I mentioned before that it talks about running tests faster than Jest prints its own version.
-
-[35:01] A lot of that is, it's runtime overhead. You know, it's like the, because of how modules are parsed and, you know, executed. there's a very long startup time. So seeing that improve substantially, I think is going to be, you know, maybe that's not going to be like world changing, but I think it will be a pretty significant difference for people who are authoring CLI tools with JavaScript.
-
-[35:25] So, you know, hopefully, I'm excited to see what happens with that. Now that somebody has thrown on the gauntlet of like, this is how fast it can be. I'm interested to see where it goes.
-
-[35:34] **Jacob Paris:** Yeah, yeah, I'm super excited about that as well, and especially since, um, you know, there's some comments in here saying, you know, Node isn't going away, Node isn't going away everywhere, maybe, maybe that's just the key to this, Node isn't going away, library authors are still going to have to support Node and maybe that's why the ecosystem won't fragment, developers can move on to Bun and Node Library authors are still going to have to produce compatible code in either ESM or CJS, just because some developers.
-
-[36:05] The big companies and so on are still going to be using node for at least the foreseeable future. Maybe that's the best of both worlds.
-
-[36:13] **Sebastien Lorber:** And I think, if you want to try it now, maybe the good idea is to start by, using it in consumer code. So not, in, libraries, but just, for example, if you want you locally to run tests. Instead of using Node. js plus Jest, you can, you can try Bun, for example. There's not a lot of risk doing so. Eventually, you can ship it to your GitHub Actions or something like that. I don't know if it runs in, in GitHub Actions, but I assume it does. But yeah, yeah, maybe shipping it to production is a bit risky today, but, for example, running, a Bun install or something like that is not super risky.
-
-[36:52] So maybe we should start by doing this and see how stable it is. And yeah, I don't remember what I wanted to say. So.
-
-[37:00] **Carl Vitullo:** That's okay. Sometimes we trail off.
-
-[37:03] **Jacob Paris:** Maybe part of the issue here when it comes to, you know, Can we use Bun in production is just, since Bun is so many different things what does it actually mean to use it in production?
-
-[37:13] I mean, yeah, you can use it for your tests, you can use it as a package manager, you can use it as a, as a host to actually run your app as a server. Um, maybe that one is the most risky one that we shouldn't be doing, but, you know, if, if it's just installs by so much, um, maybe, maybe that's okay. Maybe that can be the entry point here where we, where we start using this.
-
-[37:35] **Sebastien Lorber:** The problem is that there is not a good Windows support, so if you start using Bun to do this kind of things, the thing is if you have someone on Windows in your team, then it becomes a problem for them because, you know, if you use Bun and it works for you, and they use YARN and it doesn't work because the log file is not the same, then this becomes somehow a big mess.
-
-[38:00] ' cause you don't have the same dependencies. So, I don't know, on, on my side. I think for example, as Docusaurus is a static side generator, I'm not afraid, for example, to recommend to use Bun to eventually, build the site with, with Bun. Because once it's built in the CI you just have static files. So it's not really risky once you have succeeded, building the site. But, yeah, for several run time, I, I would wait a bit before deploying that to, to any cloud.
-
-[38:30] **Carl Vitullo:** Yeah, yeah. One other thing I wanted to bring into the conversation is Bun is a VC funded company, which I was just talking about this last night a little bit with some other React ecosystem buddies and it was brought up, you know, like the runtime companies have not historically done very well. You know, you, you, you think about who maintains JavaScript runtimes. And it's like, you know, five years ago, that was Google, Apple and Microsoft. And now it's just Google and Apple. So trying to start a brand new startup on the basis of, here's a runtime, it's a challenge.
-
-[39:09] as far as I understand, Bunn is coming at it the same way Vercel is as a hosting platform. They're saying, here's our cloud offering, use it. But I, I'm not sure that that is a strong enough differentiator because like, what's it's an open source project. Like what's the stop every other hosting provider from using that, you know, just offering it as a runtime.
-
-[39:29] So I don't know. I don't know exactly what that means. Um, I think that Bun as a runtime is really interesting. I'm not sure that Bun as a cloud platform distinct from Vercel, AWS, GCP, all of those. But yeah, we'll see. We'll see how that all shakes out. if nothing else, we've got a really cool project putting pressure on everyone to improve.
-
-[39:55] **Jacob Paris:** Yeah, it's, it's sort of a catch 22 situation here. Like either, either all the web hosts as they exist right now, they start to support Bun, and then you can use Bun in all your applications everywhere and Bun goes popular, and if that happens, now there's all this competition for Bun as a hosting platform or, or it just doesn't happen.
-
-[40:15] You, your Bun app can't actually run anywhere, and then not enough people are using Bun to justify having it as a, as its own hosting platform. So, I'm a little, little iffy on the business model there, but I, I often, in these situations, I just assume that the people who have, Given, you know, sort of devoted their livelihoods to building these companies no more than I do after reading a bunch of tweets and articles about it.
-
-[40:41] **Carl Vitullo:** At the very least they've thought about it a lot more than I have. So, well, interested to see what they come up with. And, man, what an oversight, I meant to talk about Deno as well I don't want to, we're trying to wrap it up so I'm not going to bring it up too much, but between like Bun, Deno, Biome, there's a lot of really interesting like all-in-one type, runtimes and packages and all that kind of stuff, really interesting.
-
-[41:07] But yeah Jacob, you want to take us on to our, our next link?
-
-## Next.js Forms and Mututations
-
-- [Next.js App Router - Forms and Mutations docs](https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations)
-
-[41:10] **Jacob Paris:** Yeah, yeah. So the next one for me is, um, sort of the announcement of the next, you know, the next stage of the next JS app router with their forms and mutations. So they just pushed out all the new, all the new docs on that and, Lee put out this excellent video running through you know, sort of the concepts of how these, how these server actions actually work.
-
-[41:33] Which has been again, similar to Josh's article from before. I think it answers a lot of questions that people had. So, yeah, it starts off covering you know, the, the traditional way that we're submitting forms in a React app. Where you, you, you have a form, and then in your on submit callback, you prevent default to stop it from automatically reloading the page.
-
-[41:55] You send your data to an API route, and then whatever data comes back, you have to deal with yourself in that callback. And, you know, whether that's writing it to state or performing some other actions, and, you know, for a long time, if you're working with a separate backend server, that would mean going to another repository.
-
-[42:13] You you need to build a new endpoint there. You, if you're dealing with, say, TypeScript at all, you don't have to manage that in two separate repositories, and then you end up with two separate repositories. Pull requests and, those have to be merged and deployed all at the same time, which makes testing a nightmare.
-
-[42:30] You know, I'm sort of glad we moved away that with Next.Js. You just define the API routes in your react app, in another file and the on submit callback use fetch to send data to that. So that, that's kind of the state of where everything was. was right now.
-
-[42:45] I, I do think Remix took that a little step further. So rather than having the API route in a separate file, it then, it moves into the same file. It's just an action in the same file. And rather than having to write this whole on submit thing Remix's form components will do that, all of that for you, which I think is, you know, one step up from where, where Next was.
-
-[43:03] But now, like Next has taken a huge step forward with these server actions. We have this whole progression, I guess, that the, that the ecosystem has gone through where it's less and less code every single time so rather than having, you know, two repositories, now we're down to one, and then now it's all into the same file, and we're, we're sort of co locating all the code together, so you get this really concentrated sort of, sort of concerns here, and the React server actions are the next step in this process.
-
-[43:33] Rather than having all your data fetching being co located to a particular route is that now we can move them into a single component for the form element that has the traditionally would have an action that links to a particular endpoint, you can just pass a function to it now with the next server actions and Next will do all the work of triggering that like a remote procedure call returning the data to a form action and form data hooks to deal with the, to deal with the results of it.
-
-[44:02] It's, it's really, it's the other half of the client components that I was talking about earlier for, for data fetching. now finally for the first time in next existence, they have a proper data mutation story. They're acknowledging that they're, you know, in an application you're going to need to, you know, modify data on the database, you're going to need to save things and deal with the results of that.
-
-[44:26] So rather than using something like, say, React Query or tRPC, which are sort of, you know, historical solutions there, is that these server actions are really, really good. Yeah, so you declare the functions on your server, you mark them as "use server", and... the browser will just call them automatically.
-
-[44:43] They still, they automatically degrade to browser form submissions if you're trying to submit them without JavaScript being enabled. so you get the full progressive enhancement. Yeah, I'm, I'm, I'm a big fan of this. It's it's, it's been super, super cool.
-
-[44:58] **Carl Vitullo:** Definitely reminds me a lot of how Remix implemented the same thing. Although I guess Remix does it as an export from the file, whereas this is just a function within the component or as a separate file, but yeah, one thing that's catching my eye in the, in these docs, the, I do not like the use server, use client directives.
-
-[45:20] I know that like the idea of introducing more directives, you know, so like directives came from the ES6 transition, use strict. So that's what they're basing these off, you know, like you opt into a new mode for the runtime. And, you know, I, I followed like TC39 JavaScript standard discussions loosely through my career.
-
-[45:43] And I've seen a fair number of new directives suggested, brought up by people saying like, Hey, like, it would be really great if we could have this new mode for things to happen in and the message that has been so consistently said from the people who maintain the spec and said, like, "no, we, we are never doing another directive. That was a one time thing because we needed to break, you know, we needed to have a seam where we introduce new behavior and it was not possible to do in any other way without introducing breaking changes."
-
-[46:14] And so to see it go from one ever to, oh, here's two new ones. I don't, I don't, I don't like it. I don't know. It seems like a really big break from the norms that have been set by the people who introduced that pattern. and, and, and. here it is not the first, you know, statement in a file, but the first statement in a function. So it's a new behavior on something that had been, you know, introduced 10 years ago as a, you know, a necessary evil.
-
-[46:46] And I know it gets stripped out. I know that it's just kind of to inform the compiler or whatever, but I don't know. Feels weird to me. I don't like it as much as the way Remix just does an export. That seems very simple to me and I like it. I guess that's what I'm saying.
-
-[47:02] **Jacob Paris:** Yeah, yeah. We certainly need some way of communicating to the, um, you know, to the runtime, what sort of mode it should be in while it's processing this function.
-
-[47:11] Remix handles that with just, just the naming convention. So there's certain functions that behave differently. You got your actions, your loaders, meta, headers, functions, and they're all just exported from the route. Whereas with Next, you're now using these directives to mark different behavior in, in the functions.
-
-[47:29] I don't know what the better way to do that would be. A lot of that kind of is up, above my head. one, one that I don't like is that since you're declaring these... You know, if you declare these server actions in line, anything you close over in there. So it, it looks like if it were a normal function, that you can access variables from the scope above it.
-
-[47:49] Um, so you define a variable and then you include it. And then now that's going to be included. Um, like it's, it's really confusing how that happens with the server bundle. If you have a client component in there, you could very easily end up introducing a bunch of, say private keys. If it is So you have a, like an API key in the upper scope and you're referencing something from, from that class or object within your action, because it looks like you can, that can really easily end up in the, in, in the client. yeah, it's, it's, it's, it's another foot gun where we're having more and more foot guns to worry about with all of this.
-
-[48:25] **Carl Vitullo:** So Sebastian, you want to take us off for our next link?
-
-[48:28] **Sebastien Lorber:** Actually, it's only my second link, I think. And yeah, it's a big one, so I should have started by, by this one, I think. Haha.
-
-[48:37] **Carl Vitullo:** A lot of news this month.
-
-[48:38] **Sebastien Lorber:** Yeah, exactly.
-
-## Expo API Routes
-
-- [Expo Router RFC - API Routes](https://blog.expo.dev/rfc-api-routes-cce5a3b9f25d)
-
-[48:40] **Sebastien Lorber:** Even this summer was quite busy, I think. So it's about, Expo API routes, RFC. So I think it's very interesting because, I think it's the first time that Expo is, going, on the server side. So this is, somehow not a very complicated feature. It's just about deploying API routes creating a convention to deploy API routes to a server, or creating a server runtime that you get, can deploy yourself or eventually on, on hosts like Vercel, Netlify, and maybe soon, the Expo APIs.
-
-[49:16] But what is very interesting, I think is because, you know, it's the very first step toward becoming a full stack framework where you can actually have a universal support for, the web and mobile using server side rendering on the web, so no compromise compared to the other frameworks. And also to support React Server Components in a cross platform way.
-
-[49:41] So you will be able to use the exact same code to render UI on mobile and on the web. And somehow, I think this is very exciting because, you know, currently if you want to build a web application, you don't think you will use Expo because the support of Expo web works, but it's not good enough to be able to bet on Expo just to ship a mobile app.
-
-[50:05] Maybe in the future, if they implement this well, you could even. Decide to use Expo, even if you don't target mobile, I think. So this, this could be very exciting to to have Expo being, becoming a real competitor to other frameworks on the web.
-
-[50:23] **Carl Vitullo:** Yeah. Oh, that's interesting, this builds so well off what we were just talking about with the server actions. So
-
-[50:28] that works out really great, great flow into a great transition. Yeah, oh, that's really interesting. So I know that Expo has been broadly moving towards not being as tightly coupled to React Native, but I didn't realize that they were. Even interested in doing some kind of server route like this.
-
-[50:50] This is, yeah, this is really cool. This definitely unlocks a lot of possibilities.
-
-[50:55] **Jacob Paris:** Yeah, I'm, I, I'm super like, I'm all for it. Any time where we can take the separate backends and frontends and move them into a single repository so that they can share you know, share types and you can develop, you know, push code a single, a single pull request to implement entire features all at once.
-
-[51:13] I, I'm all for that. So. It's, it seems here that Expo is now kind of going the way of Next or Remix, where you, where you can kind of, it just becomes a full stack framework all on its own. And as far as I know, up until now, that, that just wasn't possible in the React Native ecosystem. You always needed a separate backend server somewhere in order to handle that.
-
-[51:33] **Carl Vitullo:** Yeah, I'm definitely a little unsure because like Next and Remix, I understand, you know, you put it on a server and boom, there's your server. I don't really know what the deployment story for Expo is going to look like for these server actions. I'm scanning the blog post here, trying to find that, not seeing it immediately.
-
-[51:55] **Sebastien Lorber:** It's not server actions, they are not really, shipping, something advanced. So for now, it's just API routes like you have in Next. js too. So you just create an API endpoint that you can call on mobile. And I think the, the idea that we, they want to implement is first to enable you to self host the backend.
-
-[52:16] And then eventually the idea is that you just push to Expo cloud and then have the thing being served from their cloud like like if it was their server or Netlify so and you know for example they could be systems like we don't deploy we don't push the mobile update until the backend is deployed or things like that you have to synchronize things because uh mobile is long lived session, so you have to make sure that, the, the API that you deploy is compatible with the mobile side. And I think Explore has an opportunity to build something, that handles that well.
-
-[52:54] Vercel actually, built something similar, that they called Skew Protections. So, somehow if you, you know, if you have a trading application and you deploy a new version, The, the traders that use the, the former application still they don't want to refresh the browser to, to be able to keep using the app.
-
-[53:14] They want to just keep their long running session and keep interacting with the API. So it's important that the API doesn't break when you deploy new software and, for mobile, it's even more important. And I think, Expo Cloud has a card to play there.
-
-[53:27] **Carl Vitullo:** Yeah, interesting. Yeah, my first thought was like, Oh, another cloud provider, but that's actually interesting because there are genuinely different constraints for mobile versus web, because that's honestly one of the biggest differences I've noticed in my career between it is the experience of shipping new changes.
-
-[53:47] Like on a website, you know, I, I push out, I do CICD, boom, done, it's live unless there's a cache, unless I have set up a cache with, you know, a TTL that's long enough to introduce problems for that. I know that as soon as I hit that deploy button, my code is running for everyone. Maybe the service I'm working with has like a red green deployment. And so there's a gradual rollout where they're both going to be happening.
-
-[54:12] But like at the end of that, the code that everyone is hitting is. The code that was just deployed, whereas on mobile, you don't control that at all. People update the app whenever they want to, and maybe they don't for two years.
-
-[54:24] So that actually is really interesting. If I could co locate app specific API calls, have them deployed through some kind of managed service, and then. Had that cloud provider do the version management for me to make sure that they, you know, APIs from this version of the app are served by a compatible route handler.
-
-[54:50] Like, that's actually really interesting. That's pretty slick. That's pretty cool. So I think that they're introducing a new package, Expo Server, which you then need to deploy yourself. It looks like right now. I think that's what you were just saying. So, yeah, that's really interesting though.
-
-[55:03] Okay, should we move on to lightning round? All right.
-
-## ⚡️ React Native on Apple Vision Pro
-
-- [React-Native running natively on Apple Vision Pro simulator demo](https://twitter.com/o_kwasniewski/status/1701626162521190688)
-
-[55:06] **Carl Vitullo:** I guess first lightning round, I'll pull up, I'll just keep the React Native theme going React Native running natively on Apple Vision Pro simulator demo. That's cool. I don't have much else to say about that, but you know, AR VR with React in a 3d environment is like, that's pretty cool.
-
-[55:25] I like it. Jacob, you got a lightning round you like?
-
-## ⚡️ Are Big Projects Ditching TypeScript? (no)
-
-- [Are Big Projects Ditching TypeScript?](https://www.totaltypescript.com/are-big-projects-ditching-typescript)
-
-[55:28] **Jacob Paris:** Yeah, yeah, we got this once. "Are Big Projects Ditching TypeScript?" was, written up by Matt Pocock after DHH did his little let's remove all the types from Turbo thing. the consensus is no, most of them aren't. Svelte has switched to JSDoc, um, a few others in that line but no, TypeScript is here to stay.
-
-[55:47] **Carl Vitullo:** Yeah, ugh, I'm glad to see that was the outcome. DHH has, I've soured on him a little bit. Sorry, this is lightning round. We're not doing a full discussion.
-
-## ⚡️ Rust Server Components
-
-- [Rust Server Components](https://anto.pt/articles/rust-server-components)
-
-[55:56] **Carl Vitullo:** Oh yeah, I saw an interesting Rust server components post. Which is just interesting. The crossover between web and Rust is fascinating to me a little bit. And so now seeing somebody trying to do Server components, a like very fraught and complicated technology in rust. Interesting.
-
-[56:17] **Sebastien Lorber:** I wanted to mention something about the post rust server components. So this is more about using a rust backend with HTMX.
-
-[56:26] But there was recently an , an article from someone from the ReasonML community that I found super interesting because, they implemented React server side rendering in OCaml, in ReasonML, I think, or OCaml.
-
-[56:41] This led to very improved, performance in the benchmark. And I think now, the guy working on this is is now implementing server components in OCaml. So somehow, instead of running JavaScript in the... In the server runtime, they're running, a native language and, apparently it's really much faster.
-
-[57:04] And I find this quite interesting because maybe some day, there will be a faster runtime. maybe we can compile server components to native code on the server and, and run them much faster. But, I found this idea quite interesting to use something else than JavaScript to run, the React server side code.
-
-[57:26] **Jacob Paris:** Oh, interesting.
-
-## ⚡️ CSS-in-JS is Ruining Your Product
-
-- [Web Developers, CSS-in-JS is Ruining Your Product](https://cord.com/blog/migrating-from-css-in-js-to-vanilla-extract)
-
-[57:27] **Jacob Paris:** Here's a link from from, from Cords and, web developers, CS and JS for your product. Was that, was it was a neat a little article and sums up a lot of my, my thoughts here as well basically CSS and JS, so you can't generate the styles until your whole application has been rendered.
-
-[57:44] So you miss out on anything like React streaming. It has to render the whole thing. Styles and then inject them back into the app. There are some, you know, some solutions that are trying to fix issues like that'll extract using compile time extraction.
-
-[57:58] But in general, CSS and JS has kind of fallen out of fashion. And it seems like industry is sort of moving off and away from that.
-
-[58:05] **Carl Vitullo:** Yeah, interesting. We're 10 minutes over. We should probably, we could probably keep doing links forever. I, there's one more thing that I want to pop out then maybe we should call it after that.
-
-## ⚡️ Dan Abramov joins BlueSky
-
-- [Dan Abramov joins Bluesky](https://twitter.com/dan_abramov/status/1695566446007386214)
-
-[58:14] **Carl Vitullo:** But Dan Abramov is now a product engineer, no longer purely library maintainer on the backs, you know, behind the curtain of web development. He's joined BlueSky as a, as a software engineer. And I think that's going to be really interesting because as far as I know, he's still going to be on the core team. So I think specifically Dan Abramov, you know, working on a product and using React as a consumer. It's going to be really interesting.
-
-[58:45] I've been seeing some tweets from him coming out talking about points of friction on using React Native and all sorts of things like that. So just having seen all the different times that he has introduced something because he felt a pain point and then invented a new category of tool.
-
-[59:04] I can think of redux and create react app that were both just like his brain children that he felt the pain. He made something that fixed it. And then everyone else went, I didn't know you could do that. So I'm interested to see what happens now that he's being exposed to more points of friction with more regularity.
-
-[59:20] **Jacob Paris:** Yeah, and especially a shift toward React Native rather than, I guess, primarily React web which was a lot of his work before. It'll be interesting to see what that does for the native ecosystem.
-
-[59:30] **Sebastien Lorber:** Yeah. Maybe Expo, won a great, developer advocate for free.
-
-[59:35] **Jacob Paris:** Ha ha.
-
-[59:36] **Carl Vitullo:** All right, thank you so much Sebastian and Jacob. Jacob, thank you for subbing in for Mark this week. You killed it. You did great. Thanks so much.
-
-[59:43] **Jacob Paris:** Absolutely. Thanks for having me.
-
-[59:44] **Carl Vitullo:** Definitely. Awesome. Thanks so much everyone in the audience for joining us and see you next month.
-
-[59:50] **Sebastien Lorber:** Thank you. Bye.
{latest.title}
+Q&A transcripts
+ >["props"]) {
// A ridiculous method to ignore timezones
- const formattedDate = format(add(parseISO(date), { days: 1 }), "EEEE PPP");
+ const day = add(parseISO(date), { days: 1 });
+ const formattedDate = format(day, "EEEE PPP");
return (
{(setSidebar: any) => (
<>
@@ -66,6 +67,15 @@ ${description}`}
);
}
+/** One line for search results: who, when, then as much of the blurb as fits. */
+function metaDescription(title: string, date: string, blurb: string) {
+ const lead = `Transcript of the Reactiflux Q&A with ${title}, ${date}.`;
+ const rest = blurb.replace(/\s+/g, " ").trim();
+ if (!rest) return lead;
+ const full = `${lead} ${rest}`;
+ return full.length <= 200 ? full : `${full.slice(0, 197).trimEnd()}…`;
+}
+
export const getStaticProps = async ({
params,
}: {
@@ -89,7 +99,7 @@ export const getStaticProps = async ({
all,
...pick(["title", "date"], doc),
html: processMd(doc.content, { wrapFirstList: true }).html,
- description: processMdPlaintext(doc.description).html,
+ description: processMdPlaintext(doc.description ?? "").html,
},
};
};
diff --git a/src/transcripts/tmir-2024-01.md b/src/transcripts/tmir-2024-01.md
deleted file mode 100644
index 25adac8..0000000
--- a/src/transcripts/tmir-2024-01.md
+++ /dev/null
@@ -1,549 +0,0 @@
----
-title: This Month in React (January 2024)
-date: 2024-01-31
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/episode/5vn2bvmAkFxK3hvNQfGcmx?si=LNR0KUNwRnmpt7x2jJMf0g)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/tmir-2024-01-the-year-ahead-why-are-people-so-miffed/id1661733526?i=1000644051585)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick hits
- - [[00:32](#reviewing-layoffs)]: [Layoffs.fyi](https://layoffs.fyi/)
- - [[03:06](#conferences)]: Conferences
- - [React Paris](https://react.paris/) March 22nd, Paris, FR
- - [Epic Web](https://www.epicweb.dev/conf) April 11th, Park City, UT
- - [React Miami](https://www.reactmiami.com/) April 19-20th, Miami, FL
- - [React Connection / RN Connection](https://reactconnection.io/) April 22nd, Paris, FR
- - [React Conf 2024](https://conf.react.dev) May 15-16 Henderson, NV
- - [[03:58](#library-releases)]: New releases
- - [React Aria generally available](https://react-spectrum.adobe.com/releases/2023-12-20.html)
- - [New shadcn/ui components](https://ui.shadcn.com/docs/changelog)
- - [Eslint v9 alpha 0](https://eslint.org/blog/2023/12/eslint-v9.0.0-alpha.0-released/)
- - [jQuery 4.0??](https://github.com/jquery/jquery/issues/5365)
- - [date-fns v3](https://blog.date-fns.org/v3-is-out/)
- - [ReScript v11](https://rescript-lang.org/blog/release-11-0-0)
-- [[08:08](#react-libraries-for-2024-by-robin-wieruch)]: [React Libraries for 2024](https://www.robinwieruch.de/react-libraries/)
-- [[09:54](#rising-stars-on-github)]: [Rising Stars for JS, React ecosystem](https://risingstars.js.org/2023/en#section-react)
-- [[10:56](#bytes.dev-2024-predictions)]: [2024 bytes.dev predictions](https://bytes.dev/archives/250)
-- [[12:29](#speculating-on-react-19)]: React 19 and upcoming features
- - Context Selectors! [Discussion](https://twitter.com/acdlite/status/1741188563926962190) and a [summary from](https://interbolt.org/blog/react-use-selector-optimization/) [Colin Campbell](https://twitter.com/interbolt_colin)
- - [Proper Web Component support planned for React 19](https://github.com/facebook/react/issues/11347#issuecomment-1899140345)
- - [Web Components 2024 feature updates](https://eisenbergeffect.medium.com/web-components-2024-winter-update-445f27e7613a)
- - [[19:01](#upcoming-client-features-in-react)]: [Rick Hanlon: some upcoming client features I'm excited about](https://twitter.com/rickhanlonii/status/1747333623152275685)
- - [New client-side hooks coming in React 19](https://marmelab.com/blog/2024/01/23/react-19-new-hooks.html)
- - [React Forget updates](https://twitter.com/dan_abramov2/status/1747640983980806466)
-- Framework updates
- - [[22:34](#remix-spa-mode)]: [Remix working on “SPA mode”](https://github.com/remix-run/remix/pull/8338)
- - [Likely stabilize as Vite plugin does](https://github.com/remix-run/remix/discussions/7638#discussioncomment-8286839)
- - [Remix also working on RSC support](https://twitter.com/ryanflorence/status/1752166725028872432), and will have [differences from Next’s approach](https://twitter.com/ryanflorence/status/1752711755384692854).
- - [[24:53](#next-14.1)]: [Next.js 14.1](https://nextjs.org/blog/next-14-1)
-- [[27:56](#annoyed-at-react-roundup)]: “Annoyed at React” roundup
- - [Kind of annoyed at React](https://blog.cassidoo.co/post/annoyed-at-react/)
- - [React, where are you going?](https://dev.to/matfrana/react-where-are-you-going-5284)
- - [Mark’s reply](https://dev.to/matfrana/react-where-are-you-going-5284#comment-2c8g3)
- - [Ryan Florence on Twitter](https://twitter.com/ryanflorence/status/1747699804598395215)
- - [Increasingly miffed about the state of React releases](https://macwright.com/2024/01/03/miffed-about-react)
- - [React is getting a bit of a kicking lately](https://piccalil.li/blog/react-is-getting-a-bit-of-a-kicking-recently/)
-- [[37:55](#rsc-updates)]: RSCs
- - [RSCs: The Good, the Bad, and the Ugly](https://www.mayank.co/blog/react-server-components/)
- - [Leerob reacts](https://www.youtube.com/watch?v=8DyzsSWNcDE)
- - [The Two Reacts](https://overreacted.io/the-two-reacts/)
- - [RSC is React Server + Component](https://bobaekang.com/blog/rsc-is-react-server-plus-component/)
- - [“RSC does not require a server”](https://twitter.com/dan_abramov2/status/1745795274977493317) – Dan
- - [React Server Components paradigm](https://www.telerik.com/blogs/react-server-components-paradigm)
-- ⚡ Lightning round ⚡
- - [[47:40](#ryan-carniato-js-frameworks-into-2024)]: [Ryan Carniatto, JS Frameworks heading into 2024](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2024-i3l)
- - [[48:15](#rspack)]: [RSBuild guide to migrating from CRA](https://rsbuild.dev/guide/migration/cra)
- - [[50:10](#benchmarking-react-native-styling)]: [React Native styling tool benchmarks](https://www.reddit.com/r/reactnative/comments/1adasz4/react_native_cssstylesheet_frameworks_benchmark/)
- - [[50:40](#weird-things-engineers-believe-about-web-development)]: [Weird things engineers believe about Web development](https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/)
- - [[51:59](#tea.xyz)]: [Homebrew creator launching Tea.xyz, an OSS funding project](https://twitter.com/mxcl/status/1749894737862025330?s=46&t=uXPe0cHZZfyFyGotvsr9IQ)
- - [[55:44](#everything-on-npm)]: [NPM registry prank leaves developers unable to unpublish packages](https://www.scmagazine.com/news/npm-registry-prank-leaves-developers-unable-to-unpublish-packages)
- - [[57:00](#codepen-top-10)]: [CodePen top 10](https://codepen.io/2023/popular/pens/10)
- - [[57:37](#v8-performance-improvements)]: [V8 performance improvements](https://v8.dev/blog/holiday-season-2023)
-
-[00:00] **Carl Vitullo:** Thanks everyone for joining us for January's this month in React. I'm Carl. I am a staff product developer and freelance community manager here at React Tofl, the Discord for React Professionals. And Mark, you wanna introduce yourself?
-
-[00:14] **Mark Erikson:** Hi, I'm Mark. My day job is at Replay io where we're building a time, traveling demographer JavaScript.
-
-[00:20] And in my copious amount of spare time, I maintain Redux.
-
-[00:23] **Carl Vitullo:** Seems like it's been a big month. I don't know if that's just January, but yeah, let's dive right into it. I'm going to start off with a couple of, like, quick hits of small news.
-
-## Reviewing layoffs
-
-[Layoffs.fyi](https://layoffs.fyi/)
-
-[00:32] **Carl Vitullo:** I've been keeping track of layoffs. fyi. The first month of 2024 is looking not great. January layoffs have picked up a decent amount compared to last month, but compared to last year, January 2023, they're down like 70%. So, seems like it's trending in a good direction on an annual basis, but my instinct is that the next year is going to still be pretty rough.
-
-[00:58] Getting more specific, in January, 2022, there were five layoffs with about half a thousand affected. 2022 had a pretty steady upward trend for the rest of the year, which spiked really sharply in November. And then again, in January of 2023. Uh, so 2023 in January, there were 277 layoffs with about 89,000 affected. Jumping ahead to this year. January, there were 118 layoffs with about 31,000 affected. So this January is significantly less bad than last January, but compared to two years ago, it is... not even close it is super super high, still.
-
-[01:38] But looking at this annually as part of a cycle, um, I attribute some of this, I'd attribute the spike in November to businesses wanting to avoid holiday layoffs and sort of front-loading those.
-
-[01:49] So instead of splitting that same number of layoffs across two months, just doing it all at once in November. Um, and then. In January with new financial fears, starting new budgets. Uh, Annual decisions being made. In this fearful atmosphere management is biasing towards reducing expenses and lengthening runways, which I think is why there was such a large spike in January.
-
-[02:17] I also want to note that the first time the us fed hiked interest rates was in March of 2022. So looking at how. Low layoffs were in the first months of 2022, and then seeing how they spiked, or rather how they grew over time through the rest of the year. I think that a large part of the thrashing, ensuring that we're seeing right now in layoffs and, um, poor job climate is due to really national and global scale economic conditions.
-
-[02:49] Uh, you know, there's no more zero interest rates, so no more zero interest rate phenomenons, and nobody quite knows what the. Important financial metrics to optimize for, and even what to target are in this new funding environment. So I think that's really important context to keep in mind when thinking about layoffs.
-
-## Conferences
-
-- [React Paris](https://react.paris/) March 22nd, Paris, FR
-- [Epic Web](https://www.epicweb.dev/conf) April 11th, Park City, UT
-- [React Miami](https://www.reactmiami.com/) April 19-20th, Miami, FL
-- [React Connection / RN Connection](https://reactconnection.io/) April 22nd, Paris, FR
-- [React Conf 2024](https://conf.react.dev) May 15-16 Henderson, NV
-
-[03:06] **Carl Vitullo:** Conferences coming up in the next two to three months. I'm just going to run through a couple.
-
-[03:11] We've got React Paris going on in March, towards the end of March 22nd, in fact.
-
-[03:17] Epic Web, which is hosted by Kent C. Dodds. That's going to be going on in April 11th in Park City, Utah.
-
-[03:24] React Miami, April 19th and 20th, in Miami, obviously.
-
-[03:29] Another Paris conference it looks like, or, I guess conference.
-
-[03:33] **Mark Erikson:** It's an actual conference, and in fact, I will be speaking at React Connection Paris.
-
-[03:37] **Carl Vitullo:** React Connection, React Native Connection, April 22nd in Paris. That's two Paris conferences exactly one month apart. So that's neat.
-
-[03:46] And React Conf, the React Conf, is happening for the first time in three or four years. So that's, we're going to talk more about that later, but definitely pretty excited to see what they've got to share.
-
-## Library releases
-
-- [React Aria generally available](https://react-spectrum.adobe.com/releases/2023-12-20.html)
-- [New shadcn/ui components](https://ui.shadcn.com/docs/changelog)
-- [Eslint v9 alpha 0](https://eslint.org/blog/2023/12/eslint-v9.0.0-alpha.0-released/)
-- [jQuery 4.0??](https://github.com/jquery/jquery/issues/5365)
-- [date-fns v3](https://blog.date-fns.org/v3-is-out/)
-- [ReScript v11](https://rescript-lang.org/blog/release-11-0-0)
-
-[03:58] **Carl Vitullo:** All right, continuing on. Some more quick hits before we dive into the real proper link discussion. A number of new releases, just like smaller libraries, that don't quite merit a full discussion round in the main segment. Just thought I'd run through them real quick.
-
-[04:13] React ARIA from Adobe, which I As far as I understand is a component library more specifically aimed like the value proposition of it being accessibility, an area I always think of as an accessibility thing. That is a huge advantage of using a component toolkit like that is getting the long tail of smaller benefits like accessibility. So definitely interested to see that.
-
-[04:36] **Mark Erikson:** The important bit to distinguish there is React Aria, the original form of it is actually a whole bunch of hooks that are kind of like the headless data type management. Here's a hook for managing slider data or something. And this specifically, I believe they've then built their own component library on top of that. You've always been able to use the hooks yourself in your own components, but they've now also built a set of components that make use of those hooks as well.
-
-[05:04] **Carl Vitullo:** Starting from the core primitives, ironing out the functionality there and then exposing it for, through a different means of accessing it. That sounds really cool. I'm really into it.
-
-[05:13] There are new ShadCN UI components. I don't have a list prepared to read off. Oh, yes I do. Carousel, drawer, pagination, resizable, a toast component called sonner, and a bunch of CLI updates. Yeah, love ShadCN UI. Love the concept. So, check it out.
-
-[05:30] ESLint has a new version 9 alpha 0. Don't have anything prepared to speak about there. It's not ready for production use just to get feedback right now, but it caught my eye that there's a new major version of ESLint coming.
-
-[05:44] Speaking of major versions, there is a major version of jQuery version 4 that is in the works. It's not released yet, but I caught discussion of the announcement blog post and upgrade guide, so cool! jQuery, blast from the past, love to see it.
-
-[05:59] Two more here for you. There's `date-fns` v3. `date-fns` is definitely a great library. Good replacement tool for Moment, if you're still using Moment. And yeah, I love it. It's great. Major version.
-
-[06:11] And last one. This is a little bit more of a stretch, but Rescript has Major Version 11 coming out. It's a compile to JavaScript typed language that I saw described as TypeScript the good parts. I haven't used it. I'm not super familiar with what its value proposition is, but yeah. New version. Seems cool. Love an experimental language.
-
-[06:32] **Mark Erikson:** There is some amount of buzz around what was originally known as, let's see, what was it before Rescript? Something else that started with RE, and I can't think of it right now. The language itself started as a fork of OCaml with more JavaScript like syntax.
-
-[06:49] Jordan Walke and Chung Lo and some other folks in the React community were really trying to push this around like 2017 or so. And it felt like there might be enough bleed over from the React community to make it a thing. And there was a whole series of forks around the tool and the language syntax that really killed any actual momentum it had.
-
-[07:12] And that combined with TypeScript really taking over as the definitive way to write types for JavaScript. I feel like it's moment passed around 2017, so there's, you know, apparently some, still some development work ongoing, and there's, there's always arguments of, use a better language, and it fixes some of the issues with TypeScript and JavaScript, but I think in practice TypeScript is good enough at this point, and, and the ecosystem momentum is there.
-
-[07:40] **Carl Vitullo:** Tile to JavaScript language is a pretty hard sell on starting. If you're going to start a new product that they're going to maintain for years, it's a big swing to try and use a brand new language. But I always appreciate seeing experimental languages. I think that's where a lot of the experimentation happens.
-
-[07:56] And then maybe some of the learnings from running a language like that will be brought back into JavaScript, the ECMAScript process, or into TypeScript itself. Love to see it.
-
-[08:07]
-
-## [React Libraries for 2024 by Robin Wieruch](https://www.robinwieruch.de/react-libraries/)
-
-[08:08] **Carl Vitullo:** We're going to start off talking about React libraries for 2024 from Robin Wieruch, which I hope I'm not butchering that too badly.
-
-[08:16] **Mark Erikson:** I don't know how to pronounce his last name either.
-
-[08:18] **Carl Vitullo:** Robin has been publishing very high quality blog posts and explanations and Just great content for years and years. I remember reading his stuff way back in 2015, 16, I want to say. And this is yet another in the same vein. It's a huge, very comprehensive list of recommended tools for all sorts of different aspects of building a real production website.
-
-[08:45] I mean, the table of contents, it's A full page on its own. Starting a new project, package manager, state management, data fetching, authentication, database, testing, rich text editor, drag and drop, mail. Just, it's a great list. Definitely worth reading, definitely worth checking out, especially if you're in a position of spinning up a new Greenfield project.
-
-[09:05] Something like that.
-
-[09:07] **Mark Erikson:** And, and actually on, on that note, uh, Robin also just put up a post, um, talking about how to actually create a new React project in 2024. His argument, not surprisingly, is start with Vite, especially if you're learning, it's, it's simpler, there's Fewer concepts to learn at once, and then here's when you would consider Vite, here's when you would consider Next, here's when you would consider Astro.
-
-[09:31] **Carl Vitullo:** What I have found myself reaching for personally when I'm starting out has been either just whatever Next or Remix. They both ship starter kits, but I've been using React for 10 years. I appreciate the concept of a novelty budget when working with a, uh, starting a new project. So, limiting the number of new concepts you're exposing yourself to is definitely smart advice.
-
-## [Rising Stars on GitHub](https://risingstars.js.org/2023/en#section-react)
-
-[09:54] **Carl Vitullo:** Very cool. Somewhat related, I came across a Rising Stars Annual award thing. It's a tracking open source projects that gained the most stars on GitHub over 2023. Pretty cool. Top 10, I think, for the React ecosystem were ShadCNUI, Excalidraw which I don't know, it's a, it's not a library. It's not really a React tool.
-
-[10:21] I know it was created by. Christopher Chedeau . Christopher Chedeau, thank you. So I think that's why it's in here. I love it, but it's not, I don't know if I would call it a React project. Anyway, it did beat out Next. JS though, that's number three. Zustand, number four, Refine, Docusaurus, love Docusaurus, CreateT3App, NextUI, Tremor, and Serverless stack.
-
-[10:42] So that's the top 10. There's a whole lot more, and they had a bunch of different ecosystems represented. It's a pretty cool list, pretty neat to see. Yeah, I've seen a comment in the chat, sad not to see UnoCSS. That's a new one to me. Wanted to check out though.
-
-## [Bytes.dev 2024 Predictions](https://bytes.dev/archives/250)
-
-[10:56] **Carl Vitullo:** Cool, yeah, another, keeping the thread of 2024, I don't know, analysis, predictions, Bytes, the Bytes. dev newsletter, which is one of the places that I pull links from to discuss, it put out a a list of predictions for 2024 and This is put out by Tyler McGinnis. He's been huge in the React ecosystem for years and years. I think bytes. dev is like one of the largest developer newsletters. Definitely a great source.
-
-[11:23] Some of his predictions though,
-
-[11:25] bun becomes the default runtime for the front end. That seems like a big swing. I don't know. Mark, what do you think about that?
-
-[11:30] **Mark Erikson:** So the caveat here is that the Bytes newsletter is written in a very intentional tongue in cheek humorous style.
-
-[11:38] There's real links and real thoughts, but Bytes is very much a sarcastic humor kind of newsletter rather than a strict straight to the point newsletter. So most of these predictions are very tongue in cheek.
-
-[11:51] **Carl Vitullo:** Second prediction was more than three of your favorite open source software slash dev tool startups will die.
-
-[11:57] **Mark Erikson:** I mean, that one's pretty much a given, right?
-
-[11:59] **Carl Vitullo:** Yeah, right. Fair. But you could make that about any startup class over an annual timescale, but fair enough. AI will replace no code, low code tools. Seems plausible. Maybe not this year. Netlify gets acquired by GoDaddy. Yeah. Well, I don't know. I won't go through every single one, but I, one, another one that I did was no one will figure out what local first actually means.
-
-[12:19] I have opinions there. I feel like local first is a good thing to strive for, but hopefully more people figure it out this year.(chuckles) Cool. Mark, you want to tell us about React 19?
-
-## Speculating on React 19
-
-- Context Selectors! [Discussion](https://twitter.com/acdlite/status/1741188563926962190) and a [summary from](https://interbolt.org/blog/react-use-selector-optimization/) [Colin Campbell](https://twitter.com/interbolt_colin)
-- [Proper Web Component support planned for React 19](https://github.com/facebook/react/issues/11347#issuecomment-1899140345)
-- [Web Components 2024 feature updates](https://eisenbergeffect.medium.com/web-components-2024-winter-update-445f27e7613a)
-- [Rick Hanlon: some upcoming client features I'm excited about](https://twitter.com/rickhanlonii/status/1747333623152275685)
-- [New client-side hooks coming in React 19](https://marmelab.com/blog/2024/01/23/react-19-new-hooks.html)
-- [React Forget updates](https://twitter.com/dan_abramov2/status/1747640983980806466)
-
-[12:29] **Mark Erikson:** Yes, so when we did this last month and we were doing some predictions for this year, saying that I expect React 19 to probably happen this year because we were seeing some initial discussions and mentions from the React team, and while we still don't actually have a timeline, there is a lot more activity going on.
-
-[12:50] On that front, item one, Satya, one of the React Forget team members, happened to drop by one of our discussion threads over in the Tech Reads and News channel and said that the general discussion of the React team seems to be that the next stable release of React will be React 19, there hasn't been any specific discussions or plans around a React 18. 3 minor version, and that generally matches just the other bits and pieces of discussion I've seen so far.
-
-[13:20] So we can probably expect that the next actual release will be React 19. One really big thing that came out In some Twitter threads is the idea that React might finally ship a form of context selectors.
-
-[13:36] This was a proposal that was first done back in 2019 by Josh Story, who at the time was just a community member. He now currently works for Vercel building server side React stuff. Andrew Clarke played with a prototype of building context selectors in like 2020 and then it's the concept sat around and hasn't gone anywhere, especially with all the focus on suspense and server components.
-
-[14:01] But in this discussion thread, the React team has said that their approach for implementing quote, context selectors And optimizing re renders when a component only needs one piece of data from a context will actually be to use the new named use, which is still horribly confusing. Like, you're going to be able to call the use hook inside of use memo, and that basically becomes like your selector function, in a sense.
-
-[14:34] And that will actually allow React to look at the contents of what you've returned, and maybe even call the memo callback itself, separately from rendering, determine that, look, nothing actually changed, and actually be able to skip out of potential re renders that way. I don't know if this will actually be in React 19 yet, I don't know if it's Something that they've proof of concepted already, but that's, that is a pretty big deal.
-
-[15:04] We've been waiting for that one for a while. Another one that we've been waiting for a very long time is proper web component support. React allows you to render web component elements. They're just, HTML string tags in that sense, but there's been lots of complexity around being able to accurately pass props into web components because of the differences between React passing around JavaScript values as props.
-
-[15:31] Versus web components having attributes that are strings versus properties that have to be set via JavaScript. And I don't understand all the nuances there, I have not used web components. But a, like an issue was filed back in like 2017, complaining that React did not have correct support for interacting with web components.
-
-[15:55] It took four years until someone from Meta finally went through all the arguments and proposals of what the exact semantics should be, and finally implemented An experimental feature that made them work right for React, but that feature has sat inexperimental for the last two plus years. And so they finally commented on that thread a couple weeks ago and said, this will be in React 19, finally.
-
-[16:24] **Carl Vitullo:** I've never really used Web Components either. In a lot of ways, they felt like they were trying to solve the same challenges, or a similar set of challenges that React did. But in many ways, React seems to take on a much larger scope. I mean, I think that's exemplified by the emphasis on React Server Components now, where you Like web components are trying to componentize web and that's cool, that's great.
-
-[16:50] But React has componentized UI across, I mean, it's used in mobile, it's used in web to make the UI for video games. It's crossing the server client boundary now in a very meaningful way. So I mean, that's why I've, that's why I have never used web components is because I have never felt a pain that they seem to solve that React was not already trying to solve on its own.
-
-[17:14] Yeah, so I don't know. Cool to see it coming in though. It'll be interesting to have, cool to have it as another option. But I'm skeptical that it's going to be that meaningful in the grand scheme of things just because, okay, It's kind, it's, it's the new render target in a way.
-
-[17:29] It's like not the normal DOM. You'd need a compatibility shim make it work with React Native. So I guess maybe that's a good analogy.
-
-[17:39] **Mark Erikson:** There's been lots and lots of arguments. I mean, like a lot of web component fans hate React, you know, because it's too, it's too big. It's too much JavaScript.
-
-[17:47] It tries to take over the, the browser, et cetera.
-
-[17:49] **Carl Vitullo:** It doesn't use the platform. Yeah.
-
-[17:51] **Mark Erikson:** Right, right. I think the best pitch for web components plus React that would benefit from this new support is maybe your company has. The Vue apps and Angular apps and React apps, you're trying to have a unified design system and you build that design system as web components, so you only have to implement it once.
-
-[18:14] And then you can now use those design components properly from within React.
-
-[18:20] **Carl Vitullo:** Intuitively makes sense to me. I strongly suspect that the technical realities of making that work are going to be pretty painful. But yeah, cool. It sounds like a large team. kind of challenge. I don't know. But yeah, I think it, I think to me the mental model that makes sense for it is it's a little bit like dropping down into native code on React Native, but on the web.
-
-[18:43] If you're using web components, you're, you're working at a lower level of abstraction than, than most components you would write in React.
-
-[18:51] **Mark Erikson:** Yep. I've been complaining about the React teams, you know, seemingly single focus on server components to the Somewhat detriment of new features for the client side.
-
-## [Upcoming client features in React](https://twitter.com/rickhanlonii/status/1747333623152275685)
-
-[19:01] **Mark Erikson:** Having said that, Rick Hanlon from the React team did recently put up a Twitter thread where he pointed out that there are a number of new features that work in the client and in some cases can be considered client side only. There's a, these are primarily a new series of built in hooks. poorly named UseHook, which can accept a promise and will be the new official trigger for suspense behavior.
-
-[19:26] You could, you will also be able to call the UseHook and pass in a context object to grab the context value, and apparently you can actually call that inside of loops and non rendering functions like callbacks, and so there will be some very interesting flexibility out of that. There's some improvements to StartTransition and FormActions, and then some new hooks for FormState, FormStatus, and OptimisticUpdates.
-
-[19:56] All those do exist in the latest Canaries, so if you're using Next. js, those are probably available, but they will hopefully actually become stable as part of React 19. So I do have a link under here where someone wrote a follow up article that actually gives some further details about some of those.
-
-[20:15] And then, while it's not specifically listed in there, some other things we can expect are they will finally be removing some deprecated features like the Legacy Context API. Given that it's been deprecated for multiple years, I expect that very few people listening have ever actually used it. People have asked the React team to clean up dead features for a long time, and they're finally going to be doing some of that.
-
-[20:38] And React 19 should also include the source maps work that I did.
-
-[20:44] **Carl Vitullo:** Yeah, I mean I guess that's the big advantage. That's what you do with a major version release, is you remove all the things you deprecated over the, since the last release. So, with, what, 5 years? Since 18?
-
-[20:56] **Mark Erikson:** No, 18, 18 came out in 21, sometime in 22, I think.
-
-[21:03] **Carl Vitullo:** Oh, was it that recently? Okay. Yeah. I guess I'm conflating with hooks, so cool. Yeah. And just to enumerate the upcoming client features that Rick was excited about, there's use in two contact or. Two settings. There's usePromise, which, like you said, is the, uh, how we're going to be interacting with suspense or, yeah, interacting with suspense from now on.
-
-[21:25] UseContext. I don't know, I don't, I appreciate this simplicity being added by this use hook, but calling it a use hook and then not having it follow the rules of hooks as has been established for many years. It just seems like it adds confusion to me. I don't know. We'll have to see how that shakes out.
-
-[21:45] **Mark Erikson:** That plus the literal naming and how carefully I had to word that sentence for it to make any sense.
-
-[21:52] **Carl Vitullo:** So, I don't know. We'll see. But yeah, async transitions in the start transition. Function, form actions for React server components, useFormState, useFormStatus, and useOptimistic. So there's our enumerated upcoming client features, so keep an eye out for those. I think those are currently available in a Canary release, so if you want to play with those.
-
-[22:13] And very cool to have your source maps PR ship out. Finally! Ha ha ha. Looking forward to seeing that. Hopefully, I just want to see, I'd like to see people react like, oh my god, you can do this now! Ah, debugging got so much easier! Yeah.
-
-[22:26] **Mark Erikson:** For the ten of us who actually try to debug into React.
-
-[22:30] **Carl Vitullo:** Well, hopefully it'll make the stack traces easier to read anyway.
-
-[22:33]
-
-## [Remix SPA mode](https://github.com/remix-run/remix/pull/8338)
-
-[22:34] **Carl Vitullo:** Let's move on to some framework updates. Remix is working on a single page application mode, which I think is interesting. I think this makes a lot of sense as a general framing for things like Intuitively, I think my mental model for, like, different forms of complex web applications, there's solutions like Gatsby that did full static generation.
-
-[22:57] Like, you can only, you do a build time and then you publish a bunch of HTML and JavaScript. Then the opposite of that would be like Next and Remix, which are full server client frameworks that help you figure out how to write code across that seam. So, Remix adding more flexibility to cover different areas in that spectrum, I think is really interesting.
-
-[23:20] It's like a single page application, fully static assets shipped from a CDN to the client's browser. That has real use cases. That is the simplest way to host an application. Lowest cost, lowest upkeep, lowest deployment complexity, all of that. That's still a real niche that has real reasons to reach for that.
-
-[23:39] Then, one step advanced from that is something that has a build time generation step. Then, up to the full server, able to respond to requests individually, that is sort of classic Remix or Next. So, I'm excited to see this. They mentioned that it's likely to stabilize as the Vite plugin that they, that we'd talked about, I think, last time, maybe November.
-
-[24:04] But yeah, so SPA mode likely to stabilize alongside the Vite plugin. They're also looking at server component support. It sounds like they're going to be having some different Approaches from how Next is doing it. Yeah, curious to see what they come up with. Ryan Florence has been a little bit on a tear with some good tweets lately.
-
-[24:24] Yeah, I don't know. It feels like something changed. It feels like he's been, uh, a little more visible, at least in my feed lately.
-
-[24:31] **Mark Erikson:** He'd actually take it. 6 months mostly off Twitter, and at least I might have actually deleted his account at one point.
-
-[24:37] **Carl Vitullo:** Yeah, that scans, because I had just felt like I didn't see anything from him for a long time, and I was wondering if that was, I don't know, my consumption habits changing, the algorithm giving me different things, but yeah. Good to see him back because a lot of this is top tier, really great info, really great news.
-
-## [Next 14.1](https://nextjs.org/blog/next-14-1)
-
-[24:53] **Carl Vitullo:** Yeah. Okay. Moving on to from Remix to Next. Next shipped 14. 1. Just going to run through some of the changes. I haven't played with this myself, so just going to, I'm basically summarizing the blog post here. But yeah, they talk about performance improvements, lots of faster local server startup.
-
-[25:12] Faster code updates, a lot faster, say up to 96. 3, very precise. Faster code updates with fast refresh. Faster initial route compiled without caching. And they mentioned that they're, it's not so okay. It looks like they've been adding a lot of caching to get rebuilds faster. They talk about. Adding, in the future, disk caching.
-
-[25:32] So right now you start up the server, and every time you rebuild, the cache is there. The cache is warm. But starting the server has a cold cache, so it's slower. So a disk cache would dump that memory cache to disk, so that when you restart the server, it Still has a warm calf, so it starts up faster. Major trade off there is that you introduce a whole new category of caching bugs.
-
-[25:55] I know when, many moons ago, when I was developing very actively on a Gatsby project, I remember one of my debugging steps. Once one A step less desperate than deleting node modules was deleting the cache. It will be cool to see if performance improvements come out of that. That is always something I'm aware of, just the increased complexity of additional layers of caching.
-
-[26:18] They talk about improved self hosting, new documentation. for some custom cache handling. And I'm going to bring in another tweet that I saw, I don't know if I'll be able to get the link quickly, but I did see, um, a tweet from Dan Abramov in the context of Next. He mentioned that he thought it would be very valuable if Next shipped like a simple mode that did not have any of the advanced features that require The host, to be aware of it.
-
-[26:47] So right now, a lot of things, a lot of features in Next only work exactly as advertised if you're also hosting on Vercel. And that's been a criticism, that's been a criticism especially in the context of Yes, thank you, Mark. Especially in the context of Next and Vercel having a lot of core team members for React, it being tightly coupled to a paid hosting provider rubs some people the wrong way.
-
-[27:15] So I, that makes sense. I think that would be really cool to see, just make it a little bit more portable, especially as like the bleeding edge of React development. It would be nice if that was not required to be hosted on a specific platform.
-
-[27:28] There's some other improvements, TurboPack improvements, developer experience improvements. One that I thought was minor but significant is push state and replace state support in AppRouter. I didn't realize this was missing or something you couldn't do, but yeah, sounds like now you can use the native browser history APIs while you're using the next AppRouter. Not specifically sure what that will enable, but Intuitively, it feels like it should open some new doors.
-
-## Annoyed at React roundup
-
-- [Kind of annoyed at React](https://blog.cassidoo.co/post/annoyed-at-react/)
-- [React, where are you going?](https://dev.to/matfrana/react-where-are-you-going-5284)
-- [Mark’s reply](https://dev.to/matfrana/react-where-are-you-going-5284#comment-2c8g3)
-- [Ryan Florence on Twitter](https://twitter.com/ryanflorence/status/1747699804598395215)
-- [Increasingly miffed about the state of React releases](https://macwright.com/2024/01/03/miffed-about-react)
-- [React is getting a bit of a kicking lately](https://piccalil.li/blog/react-is-getting-a-bit-of-a-kicking-recently/)
-
-[27:56] **Carl Vitullo:** Can we talk about all the people who are annoyed at React?
-
-[27:59] **Mark Erikson:** Yes, let's. One of the hazards of being part of a large tool community, and especially one that is in some ways as controversial as React is, is that there's inevitably waves of discontent that come out. And we've seen this pop up in different ways over the years.
-
-[28:18] I mean, 2017, 2018, there were a lot of people who were posting comments about how much they hated Redux and wanted to kill it. So this is not a new phenomenon, but there has been a very definite series of posts and sentiment from people over the last month or so expressing annoyance with React. And, I'll say this as a meta comment, the real problem at the moment is that there are 30 different overlapping semi related things that people are complaining about.
-
-[28:51] And the problem is, everyone is complaining about a slightly different subset of problems, and It's making it impossible for anyone to actually have a clear and specific discussion about what things this person is actually upset about versus what someone else is upset about. There's complaints about React being tied to Vercel.
-
-[29:14] There's complaints about React's versioning strategy. There's complaints about how the React team does marketing and DevRel or not. There's complaints about the fact that Next and Remix are highly listed in the React docs as tools to start projects. But Vite is relegated to an expandable details section that literally says, Well, I guess if you want to use this, we can't stop you.
-
-[29:43] There's complaints about server components not being sufficiently documented in the actual React docs. And a lot of these complaints are very vibe related. Like, a lot of this stuff isn't specific, technical concerns, and so it's really hard for anyone to meaningfully and coherently discuss a lot of these complaints.
-
-[30:09] So some of the current wave kicked off with Cassidy Williams. Very smart person, well known in the community, has been around for a while. Put up a post where she said she's kind of annoyed at React. It, it is a very, there's a lot of vibes in there. She's very real, she's very actually frustrated. At the same time, if you look at the list of things she says, it's several different pieces, and a lot of it isn't even technical.
-
-[30:34] And, and I'm not discounting her frustration, I'm noting that it's the kind of frustration that can't be solved with. Let's put out a new release. Or something. There was another post that came out a couple days later in response called React, where are you going? Very well written, and it was actually, I believe Published by someone who works on a tool called React Cosmos and some of his complaints came because they'd been trying to update the tool to work properly with the next app router and server components and they got it working but it was a very hard effort and they had to make changes to the API that actually made it less, harder to work with. This person put up a post that expressed a different set of grapes, and among other things, actually suggested that maybe what we need is a new React framework That is owned by the community, and it has like, a steering committee of prominent React community members as like a starting point before we even actually begin any development.
-
-[31:39] And the author actually tagged a whole bunch of people by name on both Twitter and the article, and I was one of the people tagged. So I went in and I wrote a pretty long comment where, you know, I was doing, trying to actually respond to some of the points in the article, but then also saying, look, there is a lot of confusion and miscommunication going on right now.
-
-[32:01] And to be like, to be entirely frank, this has been frustrating for me. I'm, I read discussion. I want people to have meaningful discussion. And, okay, look, fine, it's, it's Twitter, it's, you know, Reddit, it's comment threads, I know too many people talking in too many places for it to be real discussion, but it would be nice if we could at least agree on what we're discussing, and the meta problem right now is that no one is.
-
-[32:25] I have seriously considered writing a 5, 000 word blog post that is just, Here is the definitive list of the 30 different topics the React ecosystem is arguing about right now. Now that we have this list, please continue arguing, just know that you're, here are the specific things that we're discussing.
-
-[32:44] **Carl Vitullo:** At the beginning of the argument, please make sure to enumerate which of these you are arguing about (both laugh). Yeah, yeah, I think the vibes you were talking about, especially in Cassidy's post, is, I think that's very real, but also the vibes are so important and impossible to measure that it's, I don't know, I think she had a really, One of the things that she talks about was it's frustrating that diversity efforts visibly took a backseat with React leadership, and there's just not as many voices from a variety of different people anymore.
-
-[33:13] And, you know, like, how do you, like, what a vibe. That is such a vibe check kind of complaint, and Speaking of vibes, I picked up on a vibe that there were, there was a lot of frustration from within the core team about how the React documentation rewrite went, and yeah, that took a couple of years, and seemed like it really burned out quite a number of people on the core team.
-
-[33:35] And if you are burned out from Social, political aspects of this technical work, then you don't have as much energy to bring to that technical work. So it's like, if there's problems with the vibes, then I don't know what the solution there is, but it feels like it's gonna just have a, like, downstream detriment across the board.
-
-[33:53] **Mark Erikson:** There's a few other good articles and bits of discussion out there. Ryan Florence made a tweet saying he's still very much all in on React as the best way to build apps, but, you know, Remix is working on trying to Have an alternative vision for how do you build a full stack app other than Next?
-
-[34:11] Tom McWright put out a post where he measured the times between React stable releases and noted that the time from 18. 2 until now, is going on a year and a half, I think, and that's the longest we've ever gone between official stable releases of React, and meanwhile you've got Next using Canary builds And so there's definitely frustration over how the versioning strategy is going right now. Andy Bell just put up a post, uh, in the last day or so, saying that React's getting a bit of a kicking lately.
-
-[34:44] So a little bit of the meta commentary there. But it was actually a very well balanced post that said, Look, there's, there are different tools and different trade offs. Certainly the ecosystem, the web dev ecosystem has first swung hard in the direction of Client side rendering and now we're kind of back in a server side thing and where do web components fit in this?
-
-[35:04] But it was actually a pretty decent take some time and think about the trade offs for your situation. In practice, none of this actually necessarily affects you, the individual developer, working on an app for your day job. But there is some value in having a sense of what the big conversation is.
-
-[35:21] Because, honestly, my goal out of all this would be that the React DevRel team does a bunch of work to improve the React docs. I have repeatedly griped that there's a bunch of things that I think should be done in the React docs that I'm shocked that they haven't done yet. If there's anything that comes out of this discussion, I'd like to see a lot of docs improvements.
-
-[35:43] **Carl Vitullo:** All of this conversation, all of this kind of annoyed, where are you going? Increasingly miffed, a bit of a kicking. Last month I went off on a little bit of a rant. I would say in defense of the React core team, like, I think they are truly at the bleeding edge of the web ecosystem.
-
-[36:00] And I think that in a very real way, they have been setting the tone, setting the subject of discussion that everyone else then builds on. And in so many different dimensions, like, Hooks came out of nowhere and invented this new approach to designing an API for web frameworks. Like, nobody else, I can't think of another project and hooks came out that shipped an ESLint plugin as part of using it correctly.
-
-[36:34] Okay, this has enough weird little trade offs of how we've made it work that we need supporting tooling in order to help you. use it correctly, use it well. And now, that's very common. Like, now that's something that, like, Tailwind does. So I, to me, that was something that the core, the React core team introduced to the ecosystem that, as part of API design, you also think about it more holistically, not just, okay, I import this module, what's the function signature?
-
-[37:02] But, okay, I install this package, I import it, what does the error message look like? In my IDE, just a very user centered framing of how to do API design and thinking of what tools are they likely to already use, everything possible to give them the best experience we know how to do.
-
-[37:22] Ryan Florence's tweet, he says, React is still the best rendering library for the web and the people behind it are doing are just doing their best and actually doing a great job. And I think that's extremely true. They are doing a really great job, but what they're trying to do is so advanced and so new that it's just really hard to get every detail of it right. And I think that part of the reason that they are now subject to so much criticism is because of how much they've gotten right in the past, and they've elevated the bar repeatedly, and so now the bar is super high and people have very high expectations.
-
-## RSC updates
-
-- [RSCs: The Good, the Bad, and the Ugly](https://www.mayank.co/blog/react-server-components/)
- - [Leerob reacts](https://www.youtube.com/watch?v=8DyzsSWNcDE)
-- [The Two Reacts](https://overreacted.io/the-two-reacts/)
-- [RSC is React Server + Component](https://bobaekang.com/blog/rsc-is-react-server-plus-component/)
-- [“RSC does not require a server”](https://twitter.com/dan_abramov2/status/1745795274977493317) – Dan
-- [React Server Components paradigm](https://www.telerik.com/blogs/react-server-components-paradigm)
-
-[37:55] **Carl Vitullo:** Should we go on to RSCs? A lot of stuff there. What a month!
-
-[37:59] **Mark Erikson:** Similar to some of the complaints, there was a really good post a few weeks ago called RSCs, the good, the bad, and the ugly. And one thing I appreciated was this was largely focused on technical aspects.
-
-[38:09] Someone tried to use RSCs and gave a bunch of very specific feedback on here's what they're trying to do. Here are some of the pain points I ran into in terms of understanding, like, where do I put the use server versus use client markers? And then, I think there were some additional mentions at the bottom of bigger piece complaints about some of the direction of React and Next, but it was a good article overall, very well written, not Not flame bait, like this was a substantive technical discussion and criticism.
-
-[38:42] Worth reading through that to get a sense of some of the pain points with Next and server components specifically. Which is part of the picture, the issue right now. Is there still really only one real production way to use server components right now. So, Lee Rob, uh, Lee Robinson, who's the primary dev rel.
-
-[39:02] for Vercel and Next did put up a post responding to some of the points that were raised in the Good, Bad, and Ugly post. So, some back and forth there. You can get a, have a chance to compare the thoughts there. Dan Abramov has resumed blogging, and if you've been watching him on Twitter, he has been iterating in public, trying to figure out, like, what is, what are the best analogies and metaphors and tools.
-
-[39:29] To try to get people to wrap their head around server components and the mindset shift that's involved. And in some ways this is kind of frustrating because he is rapid tweeting lots of different ideas, lots of different catchphrases. Server components are like this. Well, server components are like that.
-
-[39:48] And he's been building on some of that and he's got a couple different blog posts up. And I think we probably linked one of them last time where he's building up a series of posts. lead you to think about server components, but he literally hasn't even mentioned the word server component yet. He's been trying to help you understand, where does code run?
-
-[40:10] Sometimes code runs on one computer, sometimes code runs on another computer. What if we had a way to control where that code runs? so he's working up to a metaphor to help people understand the mental model behind server components. And so I know he said that this is turning into an actual blog post series, he's got a few more posts he wants to write, and so this post, the two Reacts, is trying to work towards that train of thought.
-
-[40:41] There was another explainer post from someone else completely. called RSC is React Server Plus Component. One of the other debates on Twitter, and tying into the people are confused or annoyed, is that the term React Server Components is highly confusing, because they don't always have to run on a literal server.
-
-[41:05] Like, not on a web server as we think about it. Like, they can be used at build time and generate static output. They are not strictly a server side rendering concept, and Dan has been frantically trying to make the point that, depending on how you use the technology, like, you could even use it, like, inside of a web worker or something?
-
-[41:27] Like, what, server components really are, like, a pre rendering method that spits out Serialize, React, as JSON. It just so happens that most of the time, and especially with Next, that happens in response to an API request. This blog post is trying to make the argument that rather than saying React Server Components with the implication that it runs on a web server, it's think of your code as like a React Server, React Client split, and the code for React Server could run At anywhere, at any time, depending on the bundler and the system architecture.
-
-[42:09] I realize there's a lot of semantics and technical nuance there, but I thought this was actually one of the better posts. And then there's, again, like I said, Dan has been trying to make the point that they don't require a literal web server. And then there's been a number of other different articles and discussion about this as well.
-
-[42:25] So the mental model and how do you teach server components, I think, is. One of the biggest outstanding questions. And again, I would love to see more of this in the actual docs.
-
-[42:35] **Carl Vitullo:** But, okay, so hopefully this is the putting it out there, ideating phase that then gets brought back in the rough draft, first pass.
-
-[42:45] So hopefully this does get brought back into the documentation as well, but I don't know if that's been I don't know how consistently that's happened over the last year or two. Something about Dan's, the two Reacts posts that stood out to me, I think that he had something really good to say.
-
-[43:00] I mean, just like the opening line of it was, I suppose I want to display something on your screen. Whether I want to display a web page, an interactive web app, or a native app you might download, at least two devices must be involved. Your device and mine. I think that is such a great, useful framing for what they're doing here.
-
-[43:17] Why React server components? It's, there are always at least two machines, the developer's machine, whether that's a local computer that they're running a build on or a server or a serverless function being executed somewhere, and the client machine. There's always a client machine. There's always something else.
-
-[43:38] So because of that, there's always going to be. Communication between those two and so that's my mental model for React server components is they are iterating on what that communication bridge looks like and how to interact with it.
-
-[43:53] **Mark Erikson:** There's been lots of arguments about what would be a better name for server components.
-
-[43:57] People have suggested dozens of different options. My vote would be React serialized components. I think that is the best retrofit for the acronym RSC and I think it's the best explanation technically in terms of what it does rather than the literal word server. You are serializing a component's output.
-
-[44:19] What it does, what happens after that depends on the environment. Maybe you're going to turn it straight into HTML on the server. Maybe you're going to output a file to disk. But ultimately what's happening is there's a pass that serializes the element output and then does something with it.
-
-[44:36] **Carl Vitullo:** Yeah, that actually makes a lot of sense.
-
-[44:38] I don't know if I, I don't know if we want to coin a brand new Well, I don't know if this is coined, but anyway, that's interesting. That's a, that is a good framing for it. Serialized is a little bit more evocative of The benefits and constraints, then server. Of course there's a server. Yeah, okay. That's interesting, I like that.
-
-[44:56] Okay, we're down to our last link, which I guess we'll just go right on
-
-[45:00] **Mark Erikson:** ahead. Yes, so I have been happily highlighting the progress of the React Forget compiler over the last few months. So, there was a blog post in March of last year. Where they said, we're working on it. There were two different conference talks at React India and React Advanced where the React team actually said, we're working on it and here's some of our progress.
-
-[45:20] There was a bit of very interesting discussion on Twitter a couple weeks ago where they talked a bit about some of the technical implementation. So, it is currently implemented as a Babel plugin. Having said that, the Babel plugin is basically just acting as a front end for the actual compiler logic.
-
-[45:41] The compiler itself is currently written in TypeScript, I believe, and not strictly tied to Babel itself. So, there were some thoughts about, I mean, there was some discussion of, well, how fast is it to run? Can you use it for fast refresh? Could it be translated to Rust someday? And one of the other possibilities that came up, Meta has been working on something that they call Static Hermes.
-
-[46:07] Hermes is the JavaScript engine that's used for React Native. It's a completely separate JavaScript implementation. And they've got a research project where they use the Hermes engine to compile your JavaScript or TypeScript code to a native binary. And have seen some interesting early results from that.
-
-[46:29] One other possibility for maybe making the Forget compiler execute faster. Instead of translating it to Rust, maybe they compile the TypeScript code to native with Static Hermes. We'll still know ETA on when this comes out. I have my fingers crossed that we'll see you some more details about it at React Conf in May.
-
-[46:47] But it was interesting to hear a bit more of the technical details of what it's taking to actually build this.
-
-[46:54] **Carl Vitullo:** Yeah, definitely. I have not been following it super closely.
-
-[46:57] **Mark Erikson:** That's why I'm here.
-
-[46:58] **Carl Vitullo:** Yeah, right? Thank you. We can pay attention to slightly different things that overlap and have a great conversation (laughs).
-
-[47:05] Yeah, my general M. O. on a lot of these experimental features is keep an eye out, know what they're called, check in once in a while, and then when they're released, cool, I have a framework for understanding why it exists. Excited to see what comes out of it, but I know this is I don't know. I've seen skepticism that it will be released in a timely manner, though it's not yet.
-
-[47:26] I mean, I'm still catching up on server components, so I just don't have the mental bandwidth to also pay attention to a whole optimizing compiler as well. On to the lightning round. We've got a bunch of links here. I think we should just pick and choose rather than going fully down the list, but
-
-## [⚡ Ryan Carniato, JS Frameworks into 2024](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2024-i3l)
-
-[47:40] **Carl Vitullo:** Ryan Carniato had a solid write up on JavaScript frameworks as we head into 2024.
-
-[47:48] Mark, tell us what that giggle was about.
-
-[47:50] **Mark Erikson:** So he's the author of SolidJS.
-
-[47:52] **Carl Vitullo:** Okay. I did, I, okay. I did not recognize the name. I, sorry, but a lot of talk about signals. And so that makes a lot of sense.
-
-[48:01] **Mark Erikson:** Yeah. Ryan's articles are always excellent. He is so good at. Discussing both technical details and trade offs and nuances. So his posts about what's going on in the front end ecosystem are always worth reading.
-
-## [⚡ RSPack](https://rsbuild.dev/guide/migration/cra)
-
-[48:15] **Mark Erikson:** Next up, so, there's a tool called rsPack, and it is a of Webpack to Rust. Literally, they've implemented all of Webpack's public API in Rust. I think the engineers behind it work at ByteDance, a company that does TikTok.
-
-[48:34] There's a second layer called rsbuild, which is like basically more of an ES builds API, but using rspack as. The implementation layer underneath and I recently saw a tweet suggesting that talking about they've got documentation on how to migrate from create React app to using RS build and I actually had a like my presentation slide tool set.
-
-[49:02] I was using React App with Craco to override the webpack config. And I thought for several years, like, I should switch this over to Vite. But, one, I'm too lazy. Two, that's a rabbit hole. Three, I, my setup uses a webpack plugin in order to parse the markdown that I use to write my slides. And so, I was actually curious about this, and in about one hour, I was able to switch from my CRA setup to using RSBuild, and the compile time went from 30 seconds to one second.
-
-[49:38] I then made it harder on myself and spent and burned like two hours trying to upgrade the version of the MDX markdown syntax that I could use. But that was a separate problem from doing the actual switch. So I know there's a lot of people who are trying to switch from create React app to Vite, and that's absolutely a thing you can do, but you might also want to look at using rsbuild instead, because it's webpack compatible and you might actually have to do less work to switch over.
-
-[50:08] Yeah,
-
-[50:09] **Carl Vitullo:** very cool. Very nice.
-
-## [⚡ Benchmarking React Native styling](https://www.reddit.com/r/reactnative/comments/1adasz4/react_native_cssstylesheet_frameworks_benchmark/)
-
-[50:10] **Carl Vitullo:** I saw a cool post on Reddit. Somebody made a project benchmarking different CSS and stylesheet implementations. It's basically a microbenchmarks list. I don't really know how applicable these are. I don't really know exactly what this would mean from a broader performance.
-
-[50:27] perspective. But, you know, it looked like they put some real work into benchmarking a variety of different approaches in React Native for applying styles, and not sure how much more there is to say on that, though.
-
-## [⚡ Weird things engineers believe about Web development](https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/)
-
-[50:40] **Mark Erikson:** Uh, one article that I really liked, a, an engineer who used to work on the internals of Mozilla Firefox, developing the browser itself, put up a post talking about weird things engineers believe about web development, and it was actually kind of a, here's the stuff that browser engineers think people care about, and then there's the stuff that web developers actually care about, and these are not necessarily the same thing.
-
-[51:04] So, it was just an interesting check on the mindsets of the people using the browsers vs the people building the browsers. I think
-
-[51:14] **Carl Vitullo:** this is a super important read. I think these are, I don't know, there's just this, you get this feedback cycle in knowledge where somebody learned something, they write about it, and then other people learn that from the people who wrote about it. And so you get like a game of telephone going on.
-
-[51:31] So then several, multiple years later, everyone knows all of these things. But if you go back to the actual primary source, some of them are a little warped. Some of them are outright wrong. So this feels like that going back to the primary source. Somebody's up to date on what people claim they know, what the common knowledge is, but they have experience with the actual underlying technology that provides those constraints. So definitely, we recommend reading this.
-
-## [⚡ Tea.xyz](https://twitter.com/mxcl/status/1749894737862025330?s=46&t=uXPe0cHZZfyFyGotvsr9IQ)
-
-[51:59] **Carl Vitullo:** I came across a cool project by the guy who created Homebrew, which is like the de facto dependency manager for macOS. It's like apt for Unix. But, so he is launching an open source software funding project that is I think blockchain based and whatever, so all of the whatever skepticism you have for that is probably warranted, but I'm always interested in new approaches for improving the economic situation of open source maintenance.
-
-[52:32] It is notoriously a very thankless job kind of situation. Yeah, I don't know, Mark, I'm curious if you have any thoughts on this as the only open source maintainer between the two of us. But yeah, it's broadly interesting to me.
-
-[52:45] **Mark Erikson:** I saw this mentioned, I didn't glance at it, so I don't have a lot of thoughts on this tool itself. The flip side is there's another tool in the same sort of space called thanks.
-
-[52:57] dev. One of the complaints about How do we fund open source maintainers has always been the trickle effect. If I provide, if my project uses Jest, ESLint and Webpack and Babel, do I send funds just to those projects? What about all the dependencies those projects are built out of? And so there's been a couple of different attempts over the years to figure out like, how do you divvy this up?
-
-[53:24] And one that I'm actually getting a little bit of something out of is this thanks. dev thing. So, companies like Sentry are donating chunks of money to this intermediary and the intermediary is scanning all the package JSONs and using a particular algorithm to figure out, like, what, what percentage each of the dependencies and sub dependencies that you would actually get, and, you know, full transparency, I'm not getting much out of this, but, you know, like, 15, 20 bucks every now and then, it's okay, it's non zero, okay, cool, thank you.
-
-[53:58] **Carl Vitullo:** I get a similar amount of money from the Medium blogging I did five years ago. It's not nothing, it's not that much. Whether it's enough money to warrant the additional need to remember to add it as income when I file my taxes is debatable.
-
-[54:11] But, yeah, I don't know. It's a hard problem. It's as yet unsolved. I'm always interested in seeing a new approach, trying to solve it. Analyzing package. json and things like that is cool. I kicked around the thought of trying to do a business in this space a number of years ago. Hey, we're Reactiflux. We have so many people donating their time to answering questions.
-
-[54:32] Open source maintainers, but ultimately where I came down on it is it's just so hard to attribute relative value between different projects that like, okay, you can scan thousands, millions of package. json files to understand the dependencies and what depends a lot on this and but then there's also there's so many deep utility functions, deep utility modules that You look at the MP M and they're downloaded like billions of times and it's like that real, is that, should that get the most money outta this?
-
-[55:06] I don't know. When I, when I was doing my own thought exercises and this never left thought land, I never did anything with these thoughts, but when I was thinking about it, it's, I don't know if you can get to the socially understood value versus. Any of the metrics that are available from analyzing dependencies, it seemed like too big of a gulf between the two of them to be obviously valuable to me, but I'm very cool to see anyone who is taking hard problem of open source funding and trying, building code, doing marketing, taking revenue and distributing it back out.
-
-[55:41] Anyone doing that, I will support 100%.
-
-## [⚡ `everything` on npm](https://www.scmagazine.com/news/npm-registry-prank-leaves-developers-unable-to-unpublish-packages)
-
-[55:44] **Mark Erikson:** Yep, and then the last one I got is, there was a recent, I don't know, issue, problem, whatever, with the npm registry, where some folks were experimenting with, Is it possible to make a package that literally depends on every other package in the entire npm registry? And they actually ran into some problems doing this, because there's like a maximum size in your package, or maximum number of dependencies you can have for one package, and what they ended up doing was chunking it up, so the top level package depended on 15, 20 other sub packages, and each of those depended on 5 to 8 packages in all of the npm registry.
-
-[56:26] What this resulted in, though, was it made it impossible to unpublish anything. From the entire NPM registry. Yet another weakness in both how NPM works and how people use NPM. First we had LeftPad, where we found out that unpublishing something dependent on by thousands of other libraries breaks everything.
-
-[56:49] We've had a few other issues over the years, and now this one. It was dealt with, but people continue to find more ways to break NPM.
-
-[56:57] **Carl Vitullo:** Alright, I'm gonna run through a couple here at the very end.
-
-## [⚡ CodePen top 10](https://codepen.io/2023/popular/pens/10)
-
-[57:00] **Carl Vitullo:** I loved this, CodePen put out a Top 10 CodePens of 2023. Love creative coding, love people just making little fun visual things.
-
-[57:10] Just for the joy of it, just to explore a new concept or to make something pretty. Creative coding is not a, an aspect of software development that we have in Reactiflux, had a lot of, people do that in CodePen, people do that in Glitch, people do that in, there's other platforms that are very well suited to it, and we've just never gotten a lot of that energy in Reactiflux.
-
-[57:30] But yeah, really cool, I loved some of these projects, definitely check it out, especially if you're looking for inspiration on a project to work on yourself.
-
-## [⚡ V8 performance improvements](https://v8.dev/blog/holiday-season-2023)
-
-[57:37] **Carl Vitullo:** And last link from me, V8 Performance Improvements. This is, like, extremely nitty gritty, like, close to the metal kind of knowledge. It's probably not going to be very practical in, you know, you as a software developer.
-
-[57:52] But they're adding yet another new level of optimizer, which is interesting. I don't know, I thought it was a good read. It's nice to understand a little bit more about how your code is being executed. There are specific people who will need to know implementation details like that. I know that the, I'm sure that the React core team has done a lot of performance optimization to ensure that the way their code is being interpreted and optimized and the way it runs through these processes results in a as close to optimal performance as possible.
-
-[58:25] I have an affinity for this type of low level post about where our code runs. But yeah, I just thought it was interesting to go through a little bit of history. It's also been 16 years since V8 was released. 16 years since Chrome came out, which is wild. What an era. It's the new era of the web. Definitely check that out if you're interested in bare metal stuff.
-
-[58:48] Thank you so much everyone for joining us. We'll be back on the last Wednesday of February here in the live stage or back in your podcast feed just as soon as we can. If you see anything newsworthy, definitely let us know in the tech reads and news channel of Reactiflux, but yeah, we also check. Quite a range of newsletters and other sources.
-
-[59:08] Mark and I both moderate the React. js subreddit. I love bytes. dev, React Status, ThisWeekInReact. There's close to a dozen sources that I pull links from here. Thanks for joining us. See you next month.
diff --git a/src/transcripts/tmir-2024-02.md b/src/transcripts/tmir-2024-02.md
deleted file mode 100644
index d61aa18..0000000
--- a/src/transcripts/tmir-2024-02.md
+++ /dev/null
@@ -1,446 +0,0 @@
----
-title: "This Month in React, February 2024: React 19 (but more details), Apple tries to kill PWAs"
-date: 2024-02-28
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick hits
- - [[00:25](#layoffs-and-job-market)] [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io job trends](https://trueup.io/job-trend)
- - [[01:46](#new-releases)] New releases
- - [react-email v2](https://resend.com/blog/react-email-2)
- - [Tamagui 1.88](https://github.com/tamagui/tamagui)
- - [Expressive Code](https://expressive-code.com/)
- - [Relay 16.2](https://github.com/facebook/relay/releases/tag/v16.2.0)
- - Remix 2.7 (and 2.6!) discussing later
- - [Isograph 0.1.0](https://isograph.dev/blog/2024/02/15/isograph-0.1.0/)
- - [[03:24](#upcoming-conferences)] Upcoming conferences
- - [React Paris 2024](https://react.paris/) March 22, 2024. In-person in Paris, France + Remote (hybrid)
- - [Epic Web Conf 2024](https://www.epicweb.dev/conf) April 10 - 11, 2024. In-person in Park City, UT, USA
- - [React Miami 2024](https://reactmiami.com/) April 19 - 20, 2024. In-person in Miami, FL, USA
- - [React Connection 2024](https://reactconnection.io/) April 22, 2024. In-person in Paris, France
- - [React Native Connection 2024](https://reactnativeconnection.io/) April 23, 2024. In-person in Paris, France
-- [[05:06](#react-labs-react-19)] [React Labs](https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024)
- - Brad Westfall: [React Will Be Compiled](https://reacttraining.com/blog/react-19-will-be-compiled)
- - [you’ll likely never need these APIs again:](https://twitter.com/acdlite/status/1758229889595977824)
- - [Good writeup from React Training](https://reacttraining.com/blog/react-19-will-be-compiled)
-- [[15:47](#a-pr-for-server-components-support-in-parcel)] React 19: RSCs, Suspense, and Server Actions
- - [Initial PR for Parcel support in RSCs?](https://github.com/facebook/react/pull/28138)
- - [Instant Search Params with React Server Components](https://buildui.com/posts/instant-search-params-with-react-server-components)
- - [Is Suspense Worth the Squeeze?](https://andy-gallagher.com/blog/about-react-suspense/)
- - [Avoid Using React’s `useFormStatus`](https://allanlasser.com/posts/2024-01-26-avoid-using-reacts-useformstatus)
- - [[19:30](#react-strict-dom-package)] [react-strict-dom](https://github.com/facebook/react-strict-dom)
- - [Announcement thread from kelset](https://twitter.com/Kelset/status/1760367655423549480)
- - Builds on [“react dom for native” proposal](https://github.com/react-native-community/discussions-and-proposals/pull/496)
- - [“Spiritual successor to react-native-web but from the opposite direction”](https://twitter.com/dan_abramov2/status/1760245165703184516)
- - [Compatibility chart](https://github.com/facebook/react-strict-dom/blob/main/packages/react-strict-dom/COMPATIBILITY.md)
-- [[25:09](#apple-announce-no-more-pwas)] [No PWAs on iOS in EU](https://developer.apple.com/support/dma-and-apps-in-the-eu)
- - [Action link, if you have an app affected](https://open-web-advocacy.org/apple-attempts-killing-webapps/) (Update, partially rolled back)
- - [MDN PWA Manifest docs](https://developer.mozilla.org/en-US/docs/Web/Manifest)
- - Gary Bernhardt’s [Birth and Death of Javascript talk](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript)
-- [[32:24](#next-app-router-the-good-the-bad-and-the-ugly)] Next
- - [A Next.js App Router Migration: The Good, Bad, and Ugly](https://www.flightcontrol.dev/blog/nextjs-app-router-migration-the-good-bad-and-ugly)
- - [What We’ve Learned from the transition to Next 14 and Server Components](https://medusajs.com/blog/client-server-transition-learnings-nextjs-14-server-components/)
-- [[35:22](#remix-26-27)] Remix
- - [2.6, 2.7 changelog](https://github.com/remix-run/remix/blob/main/CHANGELOG.md)
- - [Open sourced remix.run](https://remix.run/blog/oss-remix-dot-run)
- - [Good first issues](https://github.com/remix-run/remix-website/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
-- [[38:44](#state-of-react-native)] React Native
- - [State of React Native](https://results.stateofreactnative.com/) by Software Mansion
- - [[40:41](#react-native-frameworks-rfc)] [“React Native Frameworks”](https://github.com/react-native-community/discussions-and-proposals/pull/759)
- - [RN on Apple Vision Pro](https://www.callstack.com/blog/announcing-react-native-for-apple-vision-pro)
-- ⚡ Lightning round ⚡
- - [[43:34](#bun-shell-support)] [Bun shell](https://bun.sh/blog/the-bun-shell)
- - [[45:46](#deno-2023-2024)] [Deno in 2023](https://deno.com/blog/deno-in-2023)
- - [Survey results and 2024 roadmap](https://deno.com/blog/2024-survey-results-and-roadmap)
- - [[46:35](#jsrio)] [JSR](https://jsr.io/)
- - [[47:59](#how-hot-module-replacement-works)] [Hot Module Replacement is Easy](https://bjornlu.com/blog/hot-module-replacement-is-easy) (he lies)
- - [[48:33](#pmdrs-webgl-uikit)] [pmdrs WebGL layout engine](https://twitter.com/0xca0a/status/1762069894932160943) UI for react-three-fiber, [full repo](https://github.com/pmndrs/uikit)
- - [[49:25](#updates-from-the-100th-tc39-meeting)] [100th TC39 meeting updates](https://dev.to/hemanth/updates-from-the-100th-tc39-meeting-4j2f)
-
-[00:00] **Carl Vitullo:** Thanks everyone for joining for February's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
-
-I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, the Discord for React professionals.
-
-[00:16] **Mark Erikson:** Hi, I'm Mark Erickson. My day job is working at Replay io, where we're building a true time traveling debugger for JavaScript. And in my free time I do redux stuff.
-
-## Layoffs and job market
-
-[00:25] **Carl Vitullo:** We're gonna start off again, as we have been the last couple times with just some quick hits, layoffs that FYI, it looks like it's peaked, hopefully.
-
-There were just about 15,000 layoffs in February this year, which compares to 34,000 from last month. So that's down a little bit more than half, which seems pretty good. Pattern holds from last year as well, in 2023, numbers for January and February followed about the same pattern of dropping by half. But those numbers were 90,000 and 40,000.
-
-So that's down substantially year, over year, uh, 90,000, January last year to 34,000 january of this year. So that's down like 60%. So that's pretty great. Not out of the woods yet. But definitely comparing to 2023, it's looking a lot less grim.
-
-Here, I found a new resource that looks pretty cool, trueup.io/job- trend. It shows a number of open jobs in tech over time. It's not super clear where these are coming from. So, uh, take it with a grain of salt for sure. Don't know if this includes sales or product roles or if it's just engineering, but it looks like it peaked at 475, 000 jobs in April 2022, uh, down to a low of 163, 000 one year later, April 2023. And back up to about 200, 000. So the creeping back up, seems pretty good.
-
-## New releases
-
-[01:46] **Carl Vitullo:** I'm just going to run through a couple of new releases real quick. We've got React Email v2. Cool. Always a little bit tricky sending email from React. Email is always a pain in the butt, so I love new tools coming out for that.
-
-Tamagui 1. 88, which is a cross platform UI toolkit. The big selling point seems to be that it's seeking parity between web and React Native, which we're going to talk about a lot more later. There's been some cool new developments there. Yeah, they're supporting Expo 50, better types, and they tease a upcoming reduction in generated CSS size. So, seems cool. I know that's a reasonably widely used library. So, cool. New release.
-
-I heard about a cool new project doing syntax highlighting. It looks really good, actually. It's called ExpressiveCode. Definitely check that out if you're doing any sort of project that needs to highlight syntax.
-
-Relay. This is a little bit late, but Relay released version 16. 2. I've never been a big Relay user, so I don't fully understand what changes they just shipped, but if you use Relay, cool. There it is, new version.
-
-And again, something we're going to be talking about later, but Remix released actually two versions, released 2.6 and 2.7. We'll go into a little more depth on that later, but wanted to give it a shout out.
-
-And another, a little bit related, Isograph, which is a new take on doing GraphQL. Just announced a early 0. 1 release. We actually had the maintainer of that, Robert Balicki, on for an Office Hours last week. I think he released this version like an hour before we started the Office Hours event, so that was cool.
-
-## Upcoming Conferences
-
-[03:24] **Carl Vitullo:** All right, moving on from releases, there are a bunch of conferences coming on in the next two months or so.
-
-We've got React Paris, which is going to be March 22nd. It's in person, Paris, France, with a remote option as well.
-
-There is also Epic Web Conf coming out, or that's going to be in April 10th and 11th in person in Park City, Utah. Kent C Dodd's conference. So he always does great stuff. I'm sure this conference is going to be pretty cool.
-
-React Miami coming up April 19th and 20th as well in person in Miami. I went last year. It was really lovely. Reactiflux with a bit of an affiliation in that it's. The React Miami conference is organized by G2I, uh, which is run by Gabe, one of our admins. So definitely check it out. It was really great last year.
-
-There's also another conference in France, React Connection. That's going to be April 22nd, so exactly one month after React Paris. So, you know, great reason to get out to France.
-
-And one more in the next two months is React Native Connection. I guess that's also Same people, next day, also in France. So yeah, man, a lot of stuff going on in Paris.
-
-[04:34] **Mark Erikson:** I will be attending React Miami and then I'm actually speaking at React Connection in Paris. So I'm actually going to be directly, if you look at the timing, React Miami is actually like Friday, Saturday, and then React Connection is the next Monday. So I'm going to be. Going to Miami and then flying directly over there.
-
-[04:53] **Carl Vitullo:** That is going to be fun. We'll see if I can make it to any of the conferences this year. Not sure which ones I'm going to be going to. Yeah, that's all the quick hits we got. So let's go into our main content. Mark, you want to start us off?
-
-## React Labs, React 19
-
-[05:06] **Mark Erikson:** We have some really big news from the actual official React team posted on the actual official React team blog.
-
-They've put up another one of their React labs, what we're working on posts. And it's been 11 months since the previous post in March of 2023. And the good news is that there is a lot of details on what they've been working on, and a lot of pretty big pieces of news.
-
-Most of this is stuff we've actually talked about in previous episode, it's not like most of this is hidden, but it's good to get official confirmation of what they've been up to and where things stand.
-
-[05:40] **Carl Vitullo:** Yeah, you heard it here first, hahaha.
-
-[05:42] **Mark Erikson:** Very true. So, the first and probably the biggest piece of news is that the React team has been working away for the last couple of years on what they previously codenamed as React Forget. And the idea is it's a compiler that will auto optimize the content of your React components.
-
-Now, they talked about it initially at React Conf Online two years ago. They went kind of quiet for a while. They did a couple of talks in React India and React Advanced last fall.
-
-And so the big updates now are that 1. The name has changed. It's no longer React Forget. It's now officially just called React Compiler. And then also that they consider it no longer an experiment, it's effectively production ready.
-
-They are still working to finalize it and get it ready for use and release to the public, but it's a real thing that they effectively consider good enough that it's not just a will this work kind of situation.
-
-[06:50] **Carl Vitullo:** Yeah, and it's good enough that they are using it on Instagram's website right now is what I hear.
-
-[06:56] **Mark Erikson:** Yeah, when they did the talk at React Advanced in October, I believe they said that they were trying it out in production on Instagram Web's profile page, and then some kind of a React Native product page somewhere in Meta's code base.
-
-They might have expanded it to other parts of Instagram since then. I'm not entirely clear if it's being used more broadly than just the one profile page. But it, it, certainly the numbers and the results that they talked about back in October were very good. And they've had another five or, five plus months to try to iterate on this.
-
-Very encouraging to hear that this is progressing forward. Along with that, the React team said that the next official version of React will indeed be React 19. There will not be like an 18. 3 or 18. 4 minor release. I've, I've seen a number of people say that there are bug fixes that they wish would go out in a minor version, just to get them out sooner.
-
-I think I've seen some of the Remix Community talk about some bits and pieces that are in canary builds that they wish were already in a stable build. But certainly what I've seen over the last couple of months had been that they were working towards what they considered to be a React 19 major version, and this blog post confirms that is what they are actually planning.
-
-I do want to talk about the, a couple more bits about the React compiler. The most obvious thing that people will think about is that I don't necessarily need to put in the dependency arrays for things like useMemo and useCallback and maybe even useEffect. Because, you know, as the React team has said since Hooks first came out, if we just have a sufficiently smart compiler, It can figure out what variables you're actually using and fill in the dependency arrays automatically at compile time.
-
-But, the bigger thing, and this is the point that I've tried to make in our last couple discussions, is React has always had some built in optimizations if you memoize the JSX elements that your component returns. And so, the biggest benefit of React Compiler is that it will auto memoize chunks. of the elements that your component returns.
-
-So if your component returns, like, I don't know, three separate divs, and they depend on some combination of four or five different variables, it would auto memoize each of those chunks, so that the element only gets recreated when the input values change. And at that point, React's render optimizations kick in.
-
-And it just skips re rendering those child components, unless they change. You know, React has always had the mental model that we're actually gonna, we're gonna pretend like your entire application just got recreated every time. In practice, what it does is, when a parent component renders, everything inside of that renders by default.
-
-So you can kind of think of React Compiler as flipping that on its head. So that it's not just re rendering all children by default, but only children where their data actually changed. So, in a sense, it's actually kind of taking a common misconception and making that the default behavior.
-
-[10:14] **Carl Vitullo:** Yeah. Always good to if people hold expectations about how something will work, uh, nice to match that.
-
-This is a very high effort way to match people's expectations, but cool that they are confident enough in it working that they're starting to use it themselves on production apps.
-
-[10:31] **Mark Erikson:** And so Brad Westfall from the React training team had, or company, had a good post called React will be compiled, where he goes over some of the implications for that.
-
-Along with that, the React team has always been very big on trying to keep backwards compatibility. You know, you can still even use, you know, the original legacy create class API just as an extended package. React 19 will drop a lot of pieces that have been deprecated for years. They're finally killing StringRefs, they're killing LegacyContext.
-
-And a couple other pieces. Along with that, there's some iteration on how you're intended to use some of the existing functionality. Andrew Clark had a tweet where he's like, You know, we've got a lot of things that have been built in, but with React 19 and the compiler changes, You're actually going to access some of this functionality in a different way.
-
-So, you know, you won't have to worry so much about trying to memoize things. The compiler will take care of it for you. You won't have to use React. forwardRef because now components can just get ref as a prop directly. Apparently you won't need to use React. lazy much anymore. You can just have a promise that represents the component and put the promise directly in your JSX output as a child.
-
-The useContext hook will get replaced by the new use hook that accepts a context directly as an argument. It also will be the replacement for the undocumented but everybody knows about it technique of throwing a promise for triggering suspense. And finally, context objects themselves will now be considered the provider components that you render.
-
-So you can just render angle brackets, myContext. Instead of angle brackets, my context dot provider. Most of those are not huge changes. It's not like it's adding necessarily new functionality, but it is making some existing functionality nicer to work with.
-
-[12:33] **Carl Vitullo:** It really reduces the, you know, surface area of React's APIs quite a lot.
-
-Like, no more UseMemo, UseCallback, or the, you know, React. memo. The number of APIs that React exports is now dropping by like, what, six or seven? It's a lot. That's a lot. That's a lot fewer. Pretty cool.
-
-[12:55] **Mark Erikson:** And then, finally, the blog post talks about a lot of the features that they've been working on, especially in relation to suspense, and server actions, and forms.
-
-And, part of the reason why they came up with this Canary version release concept is they had features that were mostly ready, or close to being ready, and in theory, they were ready enough that frameworks like Next, or Remix, or, you know, something else, could make use of them, but they didn't have all the pieces ready yet, so they couldn't go into a public, stable release.
-
-They've had some of these new, you know, pieces like server actions, or the use optimistic hook, or use form status, available in Canary builds for a while. The key line from this blog post is that they said, the current set of features in React Canary are complete and ready for release. So that's actually a pretty big deal.
-
-One thing that I thought was interesting, which I hadn't really seen talked about anywhere else, and I did not actually understand the first time I read the blog post, React DOM is now going to support rendering metadata tags Anywhere in the component tree. And this means that if you render a title tag or metadata or link, number one, it'll automatically insert those into the head of the document.
-
-And two, you can render those from anywhere, which. As they said, basically replaces the need for a library like React Helmet. I have not had much need to do that myself in my own career, but it's, that's actually a pretty big deal to build in that kind of functionality. And along with that, they're adding support for suspense for things like assets, like script tags and style tags.
-
-So, there's a lot of moving pieces here, and it looks like a lot of this stuff is about ready for release. So that's pretty big news. And my assumption is that React 19 will probably either go final, or at least be in beta plus like a release roadmap at React Conf in May.
-
-[14:59] **Carl Vitullo:** Yeah, that seems like a safe assumption.
-
-They tend to make pretty major announcements at their conferences, so the lack of conferences for the last, what, four or five years? Yeah, definitely seems like Enough pieces have come together that they're comfortable saying like, yes, this is, here we go.
-
-Yeah. And on the React Helmet stuff, that is something I have had to do quite a number of times in my career. And pretty much every time I set up React Helmet, get bit by some bug, some weird quirk in how it works. Look for an alternative, find nothing, and then, you know, begrudgingly make do with whatever weird things React Helmet is doing.
-
-So this seems like a really great small tweak to make the experience of developing a new project in React just that much easier. So pretty excited for that.
-
-## A PR for Server Components support in Parcel
-
-[15:47] **Carl Vitullo:** Cool. All right. Let's talk about React server components, suspense, and server actions. There's a, an initial PR for parcel support for React server components. It looks like React Server Components needs like an external package to do things that I don't really understand because I have not looked at how you implement it from scratch in a framework.
-
-But so it looks like Parcel is now getting that support. So I think that's going to be the second. You know, Bundler that officially supports React server components. So that's, you know, going from one to two, that's a pretty major improvement here. But that's, that's pretty much all I know about it.
-
-[16:25] **Mark Erikson:** Got to have the Bundler build framework integration to actually hook up the pieces and make them do something useful.
-
-[16:30] **Carl Vitullo:** Right, yeah, this crosses a lot of boundaries, and one of the, one of those boundaries is from your app into however that app is being bundled into a production asset. So, do you want to introduce this blog post it looks like?
-
-[16:43] **Mark Erikson:** Yeah, so Sam Selikoff has done some, a couple different blog posts and talks related to how to actually make use of server components in more realistic applications.
-
-I haven't had a chance to go through this post in detail, but I saw Dan retweet it. So it's a discussion of how you would actually use server components and implement logic for things like filtering and displaying pieces and components and pieces of data, primarily based on search parameters. And so it goes through and shows examples of using a lot of the new pieces like some of the form state hooks, server actions, actually being able to control the behavior using suspense.
-
-So it feels like it's a pretty good example of how all the different pieces actually play together in practice. Super cool, yeah.
-
-On the flip side, I also saw a couple articles that are maybe just a little bit skeptical of how to use a couple of these pieces. One was an article called, Is Suspense Worth the Squeeze? And the author basically says, you know, suspense is useful, but in the end, like, showing loading states isn't necessarily, like, The greatest thing in the world. And it feels like, you know, maybe the React team's focus could have been better spent on some other things.
-
-This was at least a little bit more of like a technical set of complaints than some of the articles we've seen recently, where it's just like, I have bad vibes about React. So it's, you know, not necessarily like, you know, a big argument one way or the other, but I thought it was at least a little more of a reasonably technical focused.
-
-Similarly, there was another post called, Avoid using React's new UseFormStatus hook, where the author points out that you can only make use of the hook inside of a form component, and he had some use cases where he wanted to be able to deal with form status outside of the form tag.
-
-I think I also saw some discussion with Dan about this on Twitter, I don't have a link to it. Right this minute, but Dan's reply was that it was something about being able to properly compose pieces of the forms together as to why that limitation exists. So it's good, you know, discussion of, you know, some of the trade offs and understanding the actual limitations of available APIs is important.
-
-[19:01] **Carl Vitullo:** That reminds me of some of the things we've discussed about, like, context dependent APIs that React has started relying on. It seems sort of adjacent to the, you know, use server, use client directives, where you sort of opt into different behaviors in different parts of the tree. So, yeah, definitely having different bits of functionality only available in certain contexts, where it's not always super intuitive what those contexts will be.
-
-Yeah, that's a little bit funky.
-
-## react-strict-dom package
-
-[19:30] **Mark Erikson:** Moving on to the next section. There was another fairly big announcement from Meta within the last month. A new project called React Strict DOM. And this is really about taking React Native and giving it compatibility with web APIs. So let's back up and give a little bit of context on this one.
-
-You know, React Native came out in like 2014. It's, I think it's, it's been a while. Part of the principle of React Native has been, you get to use all the same concepts of React, you know, the components and state and rendering, but because it's targeted to native, and, you know, native could be Android, iOS, or even other platforms like Mac or Windows.
-
-React Native has its own set of abstractions. It doesn't use divs and spans and, you know, lowercase b buttons. It has its own abstractions like a view. And, you know, a view maps to whatever the underlying operating system primitive is for I want to draw a rectangle on screen and do something with it. And so you get to reuse the same concepts that you know from React DOM on the web, but the types of components that you render are completely different.
-
-And so there's been various attempts to make it easier to reuse code across both web and native platforms over the years. And one of the biggest ones was called React Native Web by, created by Nicholas Gallagher, I believe while he was originally at Twitter, and then he eventually left and went to Meta.
-
-React Native Web tried to recreate the names and types of the React Native components, but they rendered to DOM elements. So you would import capital V View from React Native Web in your web app, and you would render it, and on the web it would actually output a div instead. And so the idea is that you would always render a view instead of a div.
-
-And that made your source code compatible with both React Native on native platforms and React on web platforms. And so this is useful, but also had its limits. And so I believe this new project, React Strict DOM, has actually been worked on by Nicholas Gallagher and a bunch of other folks. And it basically takes the opposite approach.
-
-So rather than trying to make, to write web apps Where you're using something that looks like React Native component types. Instead, the goal is to make React Native look and feel more like the web. So they've been working to fill in, you know, various missing pieces of web compatibility behavior. And React Strict DOM gives you tags like HTML. div, and at usage time, those actually turn into a React Native view under the hood. So the idea is, you would now write your React components as if they were web based on both platforms. On the web, of course it outputs an actual div, and on native, it would actually map to a React Native view under the hood.
-
-So the idea is now, let's just pretend we're writing web style code everywhere, and it's just that on React Native it turns into the underlying native view instead. So this is brand new, but it sounds like it is actually being used in production at Meta, and it's gotten to the point where they felt they could open source this.
-
-[23:08] **Carl Vitullo:** I saw a tweet from Dan describing it as a spiritual successor to React Native Web, and like you said, you know, from the opposite direction, which makes a lot of sense. I, it, I have worked on React Native exactly once professionally. I tried to do a couple of side projects that never really got off the ground.
-
-It always struck me as just a little bit weird that like the view to div, you know, they're functionally almost exactly the same. It's just that one doesn't work and, they don't work in each other's contexts. So, trying to unify that just a little bit, trying to get rid of some of those weird edge cases that prevent compatibility from working. Yeah, sounds really cool.
-
-I had been really excited about React Native Web, what, five years ago, six years ago when it was new, but it just never really, never quite fulfilled the promise, the, you know, the vision that it had set out to. So cool to see another take, taking what people already do and making it compatible in the native context seems a lot easier than trying to get everyone to change how they write code to fit better with how React Native is authored. So yeah, pretty excited to see.
-
-Yeah, there was a great announcement thread from Lorenzo Sciandra, Kelset. Who, I think he works on this stuff. He's a senior software engineer at Microsoft working on React Native. Really great thread. Definitely goes into a lot of details, links out to a lot of great resources and RFCs and GitHub issues. So definitely check that out for a lot of details.
-
-There was also a wonderful compatibility chart showing the progress that they're, they've made so far. Look, it's a, it's a little bit rough at the moment. There, there's no green, but a lot of yellow and not too much red. So I think where the red is mostly on the, you know, more fringe side of HTML, although it looks like inputs are not super well supported yet, but I guess inputs are going to be tricky on. Just a little bit more functionality going on there, a little bit more behaviors to replicate.
-
-## Apple announce no more PWAs
-
-[25:09] **Carl Vitullo:** Cool. All right. I guess I'll move us on. This is a bit of a news, I don't know, a broader ecosystem news, but Apple has announced that they are dropping support from, for progressive web apps in response to regulatory challenges in the EU markets. I am pretty disappointed to see this. I had always, I've always been.
-
-Excited about progressive web apps. I love the thought of being able to author web applications in ways that are more meaningfully competitive in terms of user experience in a native context, you know, going back for years, Apple has not meaningfully supported a lot of the deeper functionality that would make this, more meaningfully, you know, work like a native application.
-
-Look, I dug deep on refreshing my memory of how these were, what the original vision for progressive web apps were and how it was meant to unfold. And in like 2014, 15, the Chrome team from Google really put out a lot of effort on doing a cross platform standard for essentially an app store.
-
-If there, you know, if you look at the MDN docs for the progressive web app manifest. It references a lot of things like, you know, screenshots and, you know, install methods. Where does this live? How do you access it? So this ultimately, Apple dropping support for progressive web apps, really it comes out of a series of lawsuits that have, that they, that have been unfolding in Europe around anti competitive behavior in the app store.
-
-You know, it kind of goes back to their 30%, you know, the Apple tax on all purchases in the iOS ecosystem. So, you know, the slightly conspiracy theory minded take on this is that fully supporting progressive web apps would meaningfully cut into their app store dominance. And so they had a strong disincentive from supporting them.
-
-So just, disappointing to see, if you are working on a progressive web app, especially in a European context, there's an advocacy organization called the Open Web Advocacy that is doing a, you know, action. So, if you are based in Europe and maintaining a progressive web application and would be impacted by this, definitely check that out.
-
-Going a little bit more, sort of broadly, back it up into, like, what is a progressive web app, why would this be meaningful? I think there's a lot of overlap there with local first as well. Um, just sort of the general idea of building a website that functions in ways similar to how people expect native applications to work.
-
-So for, like, local first, I think a wonderful example of that is, like, your email client. You know, Gmail on my phone, I can go in airplane mode and I can use it exactly as if I was online. I can archive things, I can recategorize them, I can draft replies, I can send things, and then once I'm back on network, it all works as I expected it to.
-
-So, the original vision for progressive web apps was providing a series of tools and platform features that enable that sort of thing. So, you know, the manifest is a way for web applications to say, these are the files I support. These are the, you know, domains that should open in this app.
-
-Then there's supporting features as well, like service workers. That's how you can provide a programmatic CAF from the web browser context. If they like, okay, if there's no network, here's how to respond. Unfortunately, mostly, it seems like the service workers mostly got used to serve 404 pages that look pretty, which like, okay, yes, that is something you can do with them.
-
-But it would be much more interesting if it would do synchronization of data in the background and queue up updates that you make while you don't have network. So I'm disappointed to see this. I had always been really excited for the potential of progressive web apps. And if this decision by Apple to meaningfully reduce support doesn't get changed, then kind of seems like a, maybe not the final nail in a coffin, but definitely a pretty big nail in the progressive web app coffin.
-
-Very sorry to see.
-
-[29:22] **Mark Erikson:** I haven't read through this in detail, but it seems like some of the claims are about, like, well, if we're, if you're forcing us to support multiple browser engines, we can't guarantee 100 percent perfect security and all the safety guarantees that we want to enforce on our own platform, but frankly, it sounds like, uh, well, if you're not going to let us do what we want, we're going to take our ball and go home.
-
-Kind of a temper tantrum.
-
-[29:44] **Carl Vitullo:** I'd agree with that, generally.
-
-All right in between recording this and publishing it, Apple has announced that they are actually changing tack and will be allowing home-screen web apps as they refer to progressive web apps which honestly is probably a better name.
-
-They're still going to be requiring that progressive web apps be authored in WebKit. So they're not allowing for alternate browser engines to fully integrate progressive web apps on iOS. They're claiming that this is to align with the security and privacy model for native apps. Uh, which to me, I interpret that as they have complete control over how notifications and device access work in iOS, and they're not going to give up any bit of that control to a third party, namely their largest competitor, Google. Apple's also very much in a very real way, hamstrung the way progressive web app notifications function in iOS for years now. They have never really made a serious effort at allowing developers to fine tune the user experience of how notifications are delivered. Which again I take as a subtle indicator that they don't like the operating model of a progressive web app because it is in competition with their other business interests. We're veering out of news and into, you know, I don't know, history, but there was a really great, somewhat satirical talk from 2013, given by Gary Bernhardt, called The Birth and Death of JavaScript, where he takes, it's sort of like a sci fi retrospective of JavaScript.
-
-So, yeah. He, he, he takes the perspective of someone in like 2035 discussing the arc of JavaScript and how it took over the world. And it's actually, it's a really good talk and it really got me excited about the potential for JavaScript in the world. And a lot of that really hit, I think it's very, it was very prescient and I think it got a lot of things very right.
-
-It has a funny bit where he, through the entire talk, pronounces it, "yava" script, uh, which I always found entertaining, but I would recommend that, um, I. Even though it's now 11 years old, um, I think it's, it talks a lot about like WebAssembly and the Browser taking over as the default runtime from the operating system.
-
-Um, it just, it, it, it takes a very broad, interesting perspective on programming and where we write apps and how they run. Definitely really interesting. And yeah, it's from the same guy who did that very famous "wat" talk with. you know, making fun of JavaScript. So definitely, definitely check it out. He's, I think he's been a little bit less active over the last 10 years, but he had a, he was very influential early in my career. So if I can direct any attention his way.
-
-## Next App Router: The Good, the Bad, and the Ugly
-
-[32:24] **Carl Vitullo:** All right, Mark, you want to take us on to talk about Next?
-
-[32:27] **Mark Erikson:** Sure. There were a couple of good articles that came out that discussed different companies attempting to migrate to Next and the Pages router and server components. And it's interesting to kind of look at them and compare and contrast some of the opinions and responses.
-
-So, Flight Control, which is a startup that does a different AWS dashboard, basically, talked about migrating some of their apps over to the app router. They had a number of things they did like. Layout and loading states. And some of the data loading patterns that they were able to use. They also ran into a lot of problems.
-
-They felt that they had to kind of duplicate data fetching code in order to handle live updates on the server. They didn't like issues like lack of routing type safety or some error handling situations. They really struggled a lot with the performance of the development mode server. I saw Brandon Bayer, the founder.
-
-Complaining about this repeatedly on Twitter, and asking, like, what can we do to try to speed this up? And, I know at the time that they were on the Next 13, I think he later said they did switch to Next 14, and it didn't seem to get any better. So, whatever specific problems they were running into with the speed of the dev server and memory usage, They considered those to be really major pain points.
-
-One of the comments in the article was it was marketed as production ready way too early. And it's been, it's a year later and we're still running into all these sorts of issues. So their final conclusion was, we would actually choose Remix if we could have gone back and started over.
-
-There was another article from a company called Medusa where they switched over their own next starter template to use the app router and server components. Medusa is apparently an e commerce framework. Their response, their opinion seems to be fairly positive overall. They thought that, you know, data fetching and caching was pretty good. They liked being able to use server actions to update state on the server. Talked about some different cases like static pre rendering and managing server versus client components.
-
-So they said, you know, it does take some getting used to, but, you know, once you switch over to it, it actually feels pretty natural. So, you know, always good to see some real world examples of people actually train these out in practice.
-
-[34:48] **Carl Vitullo:** Yeah, super cool. I see that Medusa post also talks about moving state to the URL, which I have worked on a couple of apps that did that, where they meaningfully kept application state up to date in the URL as you click around and navigate.
-
-The first time I worked on an app that did that. It just, it blew my mind. It was like, oh my God, every app should do this because then you can share, you can, you know, get the app into a certain state and then send it to somebody and they can, you start using the app from exactly that state. Really interesting concept. So cool to see it discussed in the context of Next 14. Cool. Cool.
-
-## Remix 2.6, 2.7
-
-[35:22] **Carl Vitullo:** I'll move us on to Remix. Like I said earlier, they put out two minor versions. There's 2. 6, which looks like it's mostly a sort of bookkeeping release where they, they made a breaking change to the unstable Vite plugin. So I guess. There you go. There's a minor release necessary to do that.
-
-2.7, they shipped VEET support, so they are now calling their, you know, internal usage of VEET stable, which also unlocks their single page application mode, which is pretty cool. That seems like it makes it meaningfully compete with Well, I don't know.
-
-I don't know. It's interesting to see. I was going to say meaningfully compete with something like Astro or Gatsby, but you know, actually, no, it's not quite that. It's not static generation. It's a single page application. That's a new context. Single page application is still like, I know the enthusiasm for that mode of publishing has dropped off in the last, you know, two or three years, Jamstack and all that kind of stuff has kind of lost mindshare, but it's still the simplest way to ship a web application.
-
-You know, if you're going to be hosting something, putting up static assets and letting it, you know, render entirely in somebody's client browser is lowest cost, lowest number of moving parts way to ship a product. So definitely still has use cases, I think. So cool to see Remix adding support for that.
-
-There was also an interesting feature that I don't quite know if I fully understand, but they called it server bundles, which looks to be support for basically sharding out a backend into multiple servers. So it looks like you can, at build time, communicate to Remix that this part of the backend. needs to be isolated from this other part of the backend.
-
-I could be mis explaining that, so don't take my word as gospel on this. I have not played around with it extensively. They mention that if you make use of this feature, you need to have something in place in front of Remix to direct the traffic and make sure that the correct backend gets, or rather, that the correct bundle gets the requests it expects.
-
-So it seems like, you know, a very niche feature that, like, large teams, large products with a lot of engineers making changes, a lot of performance characteristics to fine tune will need to take advantage of. So that seems cool. You know, one way of, I don't know, dealing with growth.
-
-It also looks to support a React router feature for base names, which is basically just a pre pended route segment. So you can say, this entire web app lives under this part of the path, and then, you know, routing will still work. That is something I have done a couple times in my career, and it has been fiddly every time. So, nice. Good to see.
-
-They also open sourced Remix. run, the, you know, Marketing website for the whole project. So that's pretty cool. They discuss some of the trade offs of, you know, why wouldn't you open source a site like this? Why would you want to? And I guess, why would you want to is basically open source is good and making the website code available is great. Uh, and why wouldn't you want to is sort of vague security risks and, you know, risk of leaking information and things like that. Nice to see the code for the site getting released.
-
-They also put up some good first issues on their, on the GitHub. So if you are looking to bust an open source, there's. There's some options.
-
-## State of React Native
-
-[38:44] **Carl Vitullo:** Moving on to our next set of links. There's been some good stuff coming out for React Native. Software Mansion, who does, they're, they're a consultancy that does a lot of React Native work.
-
-They maintain quite a number of open source projects. I always see them coming up in discussions of new React Native projects. They put out a state of React Native survey, similar to the like state of JS, state of React, state of CSS. But not organized by the same people, just to be clear.
-
-They had like 2, 500 respondents, it looks like. Just going to run through some quick stats here. Like two thirds of those have a higher ed degree, which I was a little surprised by. I thought it would be, as someone without a bachelor's degree, I. Was just surprised to find myself in such a small minority. One sixth of their respondents have no degree at all.
-
-It looks like the median, you know, I, this is a bit of a guess, I didn't have access to the data, so I'm just kind of like looking at percentage respondents. It looks like about the median engineer who responded has two, between two and six years of experience with React Native. Between five and 11 years of experience professionally programming in total, and 95 percent of the respondents were male over half between 25 and 34 years old.
-
-Top three industries represented here, finance, education, entertainment, with below then was consulting, social media, and web three, and. Something I found interesting, the vast majority of respondents, like well over 50%, work on a team with less than five engineers. And one in four people who responded to this survey are solo developers.
-
-So pretty cool to see. Just, I found those, you know, demographic Breakdowns of who is using React Native and how are they using it to be pretty interesting, just macro level. What's going on? But yeah, state of React Native survey definitely has a lot of really cool details that I did not get into. Lots of stuff about usage and opinions and what supporting libraries are being used, what features are being taken advantage of, what aren't. So that was pretty cool.
-
-## React Native Frameworks RFC
-
-[40:41] **Carl Vitullo:** Also a bit on react Native Frameworks. It looks like there was, I was a little bit confused by this, it seems, as I was reading through it, I guess they're more sharply defining the boundary between React Native and Expo.
-
-I'm not sure that there's another Similar framework to Expo. As I was reading it, I was thinking like, Oh, would like React Native web fit into this, would, you know, the React Native Windows, React Native Mac, you know, the VR support and all that, but it looks like they don't. Those are not frameworks by this definition.
-
-So I believe the only framework this is, you know, connected to defining would be Expo. The rest of those are, all of the other runtimes are described as an out of tree platform where, you know, tree there references the Git repo. So React Native. It has first party support for iOS and Android and everything else is an out of tree platform.
-
-So, this is interesting, it just seems like they're being a little bit more thoughtful and proactively communicating about responsibilities, saying, we are responsible for this, and a framework like Expo is responsible for this category of things. So, it seemed like a minor, but significant shift. in how things are, I don't know, defined (chuckles). Seems cool.
-
-[41:59] **Mark Erikson:** That was basically my takeaway. I mean, I think with the general React emphasis on, you should be using React built into a framework and most of the framework's being web focused, I think the React native side of the house was trying to get ahead of the game a little bit and say, Okay, here's what that would look like on our side if anyone else tries to build an RN based framework.
-
-[42:19] **Carl Vitullo:** I'd agree with that. It does seem like a compliment to, like, how Remix and Next are shaping up, but we don't have a sharply defined criteria for what is a framework responsible for in React. So, hey, maybe this is a proof of concept. Maybe we'll see something like that in the web context too. Ha, we can dream.
-
-Cool. One more thing to share on React Native, there is semi official support for. The Vision OS, which is pretty cool. Always cool to see. I'm impressed at how quickly they got that out. I got to say, it looks like they started working on it in June, 2023. They got a group of concept working in like compatibility mode, but that was like super stripped down, like technically it worked, but you could not, you know, the, what it, what behaviors it supported were, the list of that was very short.
-
-So this is now a much more full featured way of writing apps on the Vision OS with React Native. They described it as essentially a fork of the React Native core, which, whoo, that's a lot of work, haha. And something I found pretty cool, pretty impressive, is they got it working without even having access to a hardware device.
-
-So this is all just on the Vision Pro Simulator. Like, wow, that's hard, haha. All right, that's all of the main news items we, we have so far. Mark, take us away with the first lightning round.
-
-## ⚡Bun shell support ⚡
-
-[43:34] **Mark Erikson:** All right. So the Bunn JavaScript runtime has announced that they now have built in shell support. You know, it's always been kind of hard to kick off.
-
-external programs from within a, like a node JavaScript application. Like you can do it, but you have to call, you know, functions that capture standard in, standard out. And it's, it's not really ergonomic or intuitive. So bun now has a built in dollar sign variable. And when you use it, you just pass in like a command that you would have run in a bash shell, like, you know, LS star dot JS, or, you know, the infamous RM dash RF.
-
-And it just automatically executes it and hands back the results as a nice neat async await. I've actually got a little bit of prior experience with something like this. I had used a Python package years ago that did something very similar. So you could write Python scripts that It felt very shell scripty in terms of executing other commands and getting the output back. So I can definitely see some nice advantage of this.
-
-Working with scripting in a language like JavaScript is a lot nicer than dealing with Bash. The issue here is that being able to use commands like ls or rm, assume that you're running inside of a Bash shell. Which normally means that you're running on Linux or Mac, because Windows doesn't have those by default.
-
-A lot of people, like myself, might be using a WSL Linux environment on Windows, or at least the Git Bash version ported to Windows. But they've apparently gone and polyfilled a lot of the common shell commands you would be using, as well. This is not the first attempt to do that. There's an existing library called Shell. js, which provides JavaScript only implementations of common bash commands. I believe the Yarn package manager has already done something similar as well, so that you could, I believe, I haven't looked at this in a while. But I believe if you're using scripts in your package. json, Yarn will automatically fill in some commands like rm or setting environment variables to be cross platform and work on Windows and not just on Linux or Mac.
-
-So there's some prior art here, but it's nice to see this built into Bun.
-
-[45:46] **Carl Vitullo:** Yeah, super cool.
-
-## ⚡Deno 2023, 2024 ⚡
-
-[45:46] **Carl Vitullo:** The Deno team had a pretty cool looking Summary of what they've been up to in 2023. And I'm just going to roll straight into, they also did a blog post about their, they did a survey and announced a bit of a roadmap for 2024.
-
-They're targeting a major release this year, which they say will offer, third party framework compatibility, the ability to use any npm module, and all while having the best in class developer experience.
-
-I love all the explosion of alternate runtimes that we've been getting. I remember watching the Deno talk a couple years ago and just thinking that it was a really interesting take on What did we get wrong in Node?
-
-Deno is from the originator of Node. So he, this is very much a take two on a JavaScript runtime on the server. So I, I've been following him pretty closely just to see what's going on there.
-
-## ⚡JSR.io ⚡
-
-[46:35] **Carl Vitullo:** I guess I'll roll straight into another one that I had queued up for later, but it's closely related.
-
-The Deno team is doing a new JavaScript registry called jsr. io. I just got access to it and it seems pretty neat, I gotta say. For one, it's ESM only, so there's There is no longer going to be a CommonJS option for publishing to this registry, which that alone has me interested. The CommonJS vs.
-
-ESM split has been an absolute nightmare and a huge blight on the JavaScript ecosystem. So, that alone seems like a pretty good reason to try a new registry. It does look like they are starting from scratch. Um, I have I poked around just a little bit, and I don't see any familiar modules published there, but I'm excited to see where it goes.
-
-It's waitlisted right now, so if you are, if that sounds interesting, hop in the waitlist. I got off of it in like two or three weeks, so I have no idea what that means. But yeah, Deno, a lot of stuff going on.
-
-[47:36] **Mark Erikson:** I know I saw an article or two somewhere that was talking about using it.
-
-I think one of the interesting changes is it looks like they actually want you to just publish your TypeScript source code and the registry takes care of doing the compilation, I think, was something I saw. That would be a very significant change.
-
-[47:57] **Carl Vitullo:** Yeah, oh that's super cool.
-
-## ⚡How Hot Module Replacement works⚡
-
-[47:59] **Mark Erikson:** Alright, next up, there was an article talking about how are the hot module replacement feature is actually implemented inside of the Vite bundler.
-
-This is long, it's detailed, frankly this is all information you will never need to know in order to use or build applications. But it's a really good article that actually digs into the technical details of what does it take to implement the, you know, you know, module graphs and swapping and all the specific APIs that actually make hot module reloading possible.
-
-[48:29] **Carl Vitullo:** Yeah, really good post. I love deep dives into obscure parts of the ecosystem.
-
-## ⚡pmdrs WebGL uikit⚡
-
-[48:33] **Carl Vitullo:** Cool. The, the Poimanders, never quite sure how to pronounce that. They shared a fully functional WebGL UI rendering engine. It seems pretty cool, it's basically a layout engine for React 3 Fiber, which is pretty neat. If you're trying to work in WebGL, like that's about as close to bare metal as you can get in the browser from a, you know, like rendering engine side of things, you know, set aside web assembly and whatever you, so, but just like.
-
-Any kind of layout, you don't get any support for. So, pretty interesting to see somebody taking advantage of work done on React Native, actually, because this relies on the Flexbox engine that was built in order to facilitate React Native, the Yoga layout engine. So, super cool, definitely check that out if you are experimenting with WebGL on a side project.
-
-Should make some of these things a little bit easier.
-
-## ⚡Updates from the 100th TC39 meeting⚡
-
-[49:25] **Mark Erikson:** Alright, and the last item on the list is some updates from TC39 as potential new JavaScript syntax features make their way through the pipeline. Not a lot of huge news here, a lot of items at stage 1. There's a proposal called Promise. try, which is basically like a, almost, like a try catch for running any kind of function, sync or async, and getting back a promise for the result.
-
-One other thing that I saw, let me go find the details on this. I believe I saw mentioned that they've actually added a new stage number to the TC39 process. So traditionally it's been like stage 0 is just, we have an idea, stage 1 is we've proposed the idea. Stage 2 is, we, we think this idea could work, but it needs to be fleshed out. Stage 3 is, this basically works, we've got it implemented in a couple browsers, it's just Nailing down the final details and then stage four is it's good to go.
-
-They've actually added a new stage, which is, and this appears to be a real official thing, Stage 2.7 because it's more than stage two, but less than stage three. And I think I actually saw a comment that stage 2.7 is a little bit like what stage three used to be and now stage three is slightly more involved. This actually appears to be a real Thing.
-
-[50:46] **Carl Vitullo:** I love that. It's more than halfway, but. Cool.
-
-Alright, that's all we got. Thank you so much for joining us. We'll be back on the last Wednesday of the month here in the live stage of Reactiflux or back in your podcast feed just as soon as we can.
-
-We gather sources from all sorts of newsletters like React Status, bytes.dev, Next JS Weekly, React Digest, This Week in React, love that one, as well as like the React JS subreddit, here in Reactiflux. We do check the #tech-reads-and-news channel. So definitely if you see any news coming out, let us know. Put it in that #tech-reads-and-news channel, or if you like, you can send it to hello@reactiflux.Com. But make sure to include TMIR in the subject line. It's an acronym for the show.
-
-And we are starting to professionalize. We're trying to grow and find some sponsors. So if this is a show that you get value from and want to support, best way to do so is by giving us a review or telling your friends about it.
-
-Thanks so much. Excited to see what happens in March. Bye all.
diff --git a/src/transcripts/tmir-2024-03.md b/src/transcripts/tmir-2024-03.md
deleted file mode 100644
index 57461a9..0000000
--- a/src/transcripts/tmir-2024-03.md
+++ /dev/null
@@ -1,495 +0,0 @@
----
-title: "This Month in React, March 2024: React canary is 19, New ShadCN bits, Astro looks like Wordpress. Wiz??"
-date: 2024-03-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick Hits
- - [[00:39](#layoffs-seems-better)] [Layoffs.fyi](https://layoffs.fyi/)
- - [[01:20](#new-releases)] New releases
- - [React Native 0.74.0?](https://github.com/facebook/react-native/releases) Soon
- - [New Architecture docs page](https://reactnative.dev/docs/the-new-architecture/landing-page)
- - [TS 5.4](https://devblogs.microsoft.com/typescript/announcing-typescript-5-4/)
- - [“This is how most dependency injection in React apps should be done”](https://twitter.com/sebmarkbage/status/1765828741500981475) says Sebastian Markbåge
- - [Remix 2.8](https://github.com/remix-run/remix/blob/main/CHANGELOG.md#v280)
- - [Mantine v7.7.0](https://mantine.dev/changelog/7-7-0/)
- - [Rsbuild 0.5](https://rsbuild.dev/community/releases/v0-5)
- - [Gleam version 1](https://gleam.run/news/gleam-version-1/)
- - [[05:58](#shadcn-march-2024-update)] [ShadCN March 2024 update](https://ui.shadcn.com/docs/changelog)
- - [[06:55](#astro-45-astrodb)] [Astro 4.5](https://astro.build/blog/astro-450/)
- - [Astro DB](https://astro.build/blog/astro-db/), [Astro DB Deep Dive](https://astro.build/blog/astro-db-deep-dive/)
-- [[09:58](#upcoming-conferences)] [Upcoming conferences](https://react.dev/community/conferences)
- - [Epic Web Conf 2024](https://www.epicweb.dev/conf) April 10 - 11; Park City, UT, USA
- - [React Miami 2024](https://reactmiami.com/) April 19 - 20; Miami, FL, USA
- - $50 off a ticket: `reactiflux4ever`
- - [React Connection 2024](https://reactconnection.io/) April 22; Paris, France
- - [React Native Connection 2024](https://reactnativeconnection.io/) April 23; Paris, France
- - [Post/Con 2024](https://www.postman.com/) April 30 - May 1; SF, CA, USA
- - [React Conf 2024](https://conf.react.dev/) May 15 - 16; Henderson, NV, USA
- - [App.js Conf 2024](https://appjs.co/) May 22 - 24; Kraków, Poland
- - [Local First Conf 2024](https://www.localfirstconf.com/) May 30; Berlin, Germany
-- [[10:58](#react-19-and-react-compiler)] React 19 and React Compiler
- - [Feature flags PR - “Canary now represents React 19”](https://github.com/facebook/react/pull/28647)
- - [React 19 won’t include Compiler](https://twitter.com/en_JS/status/1760433969118769654)
- - [React Compiler & React 19 - forget about memoization soon?](https://developerway.com/posts/react-compiler-soon)
- - [“Compiler Theory and Reactivity”](https://www.recompiled.dev/blog/ssa/) and [“Type System”](https://www.recompiled.dev/blog/type-system/)
- - [Its-fine](https://twitter.com/0xca0a/status/1766032105807483261)
- - [sebmck and drcmda GitHub exchange](https://github.com/facebook/react/pull/28524#issuecomment-1992607052)
-- [[20:02](#react-strict-dom-why-is-it-so-great?)] ["react-strict-dom", why it's so great?](https://szymonrybczak.dev/blog/react-strict-dom)
-- [[23:42](#server-components-updates)] RSCs
- - [Conceptual Model of React and RSC](https://ondrejvelisek.github.io/conceptual-model-of-react-and-rsc/) Ondrej Velisek
- - [Why React Server Components Are Breaking Builds to Win Tomorrow](https://www.builder.io/blog/why-react-server-components) Vishwas Gopinath
- - [Waku has released a “pages router”](https://waku.gg/blog/introducing-pages-router)
- - Lee Robinson’s [List of projects experimenting with RSCs](https://twitter.com/leeerob/status/1772651496544317804) , including Redwood ([which just released an RSC beta](https://redwoodjs.com/blog/rsc-now-in-redwoodjs))
- - [Embracing the Future and Moving Back Again: From Server Actions to tRPC](https://documenso.com/blog/removing-server-actions)
-- [[29:06](#apple-walks-back-on-pwas-neat-safari-features)] [Webkit features in Safari 17.4](https://webkit.org/blog/15063/webkit-features-in-safari-17-4/)
-- [[33:05](#mental-health-in-open-source)] [Mental Health in Open Source](https://antfu.me/posts/mental-health-oss)
-- [[37:20](#angular-meet-wiz)] [Angular codebase is being merged with Wiz](https://twitter.com/sarah_edo/status/1770478763253379488?t=zbCMEoxUsXuLGYtqt3ik8w&s=19)
- - [Announced at NGConf 2024](https://youtu.be/nIBseTi6RVk?t=1869)
- - [[38:49](#designing-very-large-javascript-applications)] [Designing Very Large Javascript Applications](https://www.industrialempathy.com/posts/designing-very-large-javascript-applications/)
- - [Malte Ube discussed in 2018](https://twitter.com/cramforce/status/958696304149868545?t=ETSaJnj2aX9Dnw_yPXgWBA&s=19)
-- ⚡Lightning round ⚡
- - [[43:56](#interaction-to-next-paint-new-core-web-vital)] [Interaction to Next Paint (INP) is a Core Web Vital](https://web.dev/blog/inp-cwv-launch)
- - [What is INP and why you should care](https://blog.sentry.io/what-is-inp/)
- - [[44:56](#rspack-charts-a-path-to-10)] [Rsbuild 1.0 release plan](https://github.com/web-infra-dev/rsbuild/discussions/1678)
- - [[45:42](#remix-might-merge-react-router-in)] [React Router and Remix to be merged?](https://twitter.com/ryanflorence/status/1767560366027129211)
- - [[46:08](#declarative-shadow-dom-in-all-major-browsers)] [Declarative Shadow DOM available in all major browsers](https://www.mayank.co/blog/declarative-shadow-dom-guide)
- - [[47:05](#react-native-community-map)] [React Native community map](https://github.com/kelset/react-native-community-map)
- - [[47:34](#nodejs-2023-year-in-review)] [Node.js 2023 Year in An Article](https://blog.rafaelgss.dev/nodejs-2023-year-in-review)
- - [[48:57](#tailwind-preview-of-40)] [Open-sourcing our progress on Tailwind CSS v4.0](https://tailwindcss.com/blog/tailwindcss-v4-alpha)
- - [[49:26](#vercel-adds-remix+vite-support)] [Vercel adds support for Remix+Vite](https://vercel.com/changelog/support-for-remix-with-vite)
- - [[50:05](#navigating-the-future-of-frontend)] [Navigating the future of frontend](https://frontendmastery.com/posts/navigating-the-future-of-frontend/)
-
-[00:00] **Carl Vitullo:** Thanks for joining us for March's This Month in React! Coming to you live from Reactiflux, the Discord for React professionals. I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux.
-
-[00:13] **Mark Erikson:** Hi, I'm Mark Erikson. My day job, I work at Replay. io, where we're building a time traveling debugger for JavaScript, and outside of that, I do Redux stuff.
-
-[00:22] **Carl Vitullo:** We got a lot of good stuff to discuss and digest here. Lot more details coming out for React 19. We got TypeScript 5. 4, and lots of interesting stuff kind of at the margins. Not really core tools or libraries within React necessarily, but a lot of things all over the place.
-
-## Layoffs (seems better!)
-
-[00:39] **Carl Vitullo:** I'm going to start off with some layoffs news. At time of recording, you know, it's the 27th, so we'll have to see if anything else happens, but layoffs.fyi is showing 33 companies with layoffs, which is the fewest layoffs by count in that way in close to two years, since April 2022. So nice to see that number go down.
-
-[00:58] This month has about 7, 200 laid off so far, which is on the lower end, it's not the lowest of the last year, but it's towards the lower end of the average range. Last March, so one year ago, there were 122 layoffs with about 38, 000 affected. So, 33 layoffs with about 7, 000 affected is a large decline, so that's nice. That's pretty good.
-
-## New releases
-
-[01:20] On to some new releases. We have a pretty big list this month.
-
-[01:23] **Carl Vitullo:** We've got some news from React Native. They are going to be putting out a 0. 74 release soon. They've had a really cool post up , or I guess like a docs page, talking about their new architecture. Not a ton of super concrete items coming out in there. But they did talk a lot about the general new architecture, re architecting how React Native works. We're going to talk a little bit about some of that, too, later on, talking about React Strict DOM, that package that they released last month.
-
-[01:53] Moving on a bit, TypeScript 5. 4, sounds like it's not a huge release, but One thing that I thought was super notable, worth taking note of, they are recommending against using the compiler options paths configuration flag in favor of package. json imports. Since you use the paths for import aliases, moving that out of a TypeScript specific configuration option and into a general module configuration option I think is absolutely phenomenal.
-
-[02:23] Getting that standardized I think is going to simplify a lot of things.
-
-[02:26] **Mark Erikson:** It's particularly interesting because I've seen other tools actually start to use TypeScript's own paths option as the source of truth. So, I guess, you know, switching over to a package. json setup is making it more tool agnostic, in a way, but the question as always is, how long will it take for other tools to also support that kind of configuration?
-
-[02:47] **Carl Vitullo:** I am just excited to see something go out from, I don't know, kind of move from TypeScript into standards, but yeah, generally seems like a quieter release.
-
-[02:56] NoInfer is one of the biggest things they called out and sounds like it's mostly useful in library contexts. Mark, you did point out something coming up in 5. 5 that looks really interesting though, you want to introduce that?
-
-[03:10] **Mark Erikson:** TypeScript has the idea of, I'm always a little hazy on the terminology, typeguards or predicates, which are functions that take some object and you assert at the type level that if the function returns true, then the type of the value must be this thing.
-
-[03:25] And so it's a way to mix together control flow and telling TypeScript what a thing looks like at compile time. And the problem is that when you do an operation like array filtering, that has not actually done the type narrowing that you might expect. So, you might be filtering to ensure that, you know, the returned array only contains real values and removes null or undefined, but TypeScript wouldn't actually pick up on that so far.
-
-[03:51] And so you might have to do, like, an extra cast or some other check to make sure that the output array has the correct type. Well, TypeScript 5. 5, which should be out in a few months, actually now has a PR merged that uses TypeScript's existing inference in new ways inside of filter functions so that you can do normal logic when filtering and TypeScript will try to narrow down the returned array type based on the logic in the filter callback.
-
-[04:18] It's not a huge deal, but it's gonna be a nice little quality of life thing. And then I also saw a tweet mentioning that the TypeScript team is continuing to do work on the publishing process to try to shrink the install size. I think as of, like, TS 4. 9. Installing TypeScript was around 50 megs. They did a lot of work with TS 5. 0 to change their internal setup, which dropped it to like 30. And it looks like as of 5. 5, it might be down to 20 ish or so. So, you know, hey, smaller install size, always a good thing.
-
-[04:50] **Carl Vitullo:** Much, much later, I'm going to talk a little bit about a Node. js 2023 year in review, and that has the opposite trend. It has a chart in there showing the binary size for the Linux binary for Node. js, and it is much, much larger than it used to be. So, good to see that TypeScript is going the other direction. Maybe they can cancel each other out a little bit.
-
-[05:09] I'm just going to run through a bunch of other releases pretty quick.
-
-[05:12] Remix released 2. 8. Looks like it's just a bunch of minor changes, configuration stuff.
-
-[05:17] Mantine has 7. 7 out. I didn't see any changes in there that really jumped out to me. It looks like a bunch of new components, a couple new hooks. useStateHistory looks neat, undo is always a challenge.
-
-[05:29] RSBuild released a version, 0. 5, which they say it's most of a 1. 0 release that will happen approximately in Q3 of this year, but it'll be much, much later this year.
-
-[05:40] I saw a cool fringe language inspired by Elm. Gleam, released a version 1. First stable release of a new experimental language. I always need to see how people play around with different languages. It says it's inspired by languages such as Elm, OCaml, and Rust. Experimental languages. Lots of stuff going on there.
-
-## ShadCN March 2024 update
-
-[05:58] **Carl Vitullo:** Okay, here's another big one. We've got some ShadCN new updates. They put out a March 2024 update, which is the first time they have done one of these update posts since I think December. So definitely worth calling out. It looks like the single biggest new thing that they have is blocks, they call it.
-
-[06:15] Which looks like it's basically template pages for very common and like very low differentiation application pages like a settings UI, or two factor, an authentication page, some other things like that, so it's basically just, copy these out, use it yourself. It looks neat. It looks exactly like every instance of those pages that I've done many times over my career.
-
-[06:36] So having a nice copy paste target for that is, seems super helpful. They also had one for an input one time password, like the classic, you know, paste in these six digits and it will appear in nice pretty blocks. Again, something I've implemented many times and there's never any variation, but for some reason you can never use the last one you did, so nice to see that.
-
-## Astro 4.5, AstroDB
-
-[06:55] **Carl Vitullo:** One more big one here that I'm just going to kind of blast through because I find it interesting. So Astro, the static site generator, I guess. I don't know if that's quite accurate, but.
-
-[07:05] **Mark Erikson:** Close enough for now.
-
-[07:07] **Carl Vitullo:** They released 4. 5, improved developer experience, a dev audit UI for site performance and accessibility issues, which is cool. They are announcing that they're offering a hosted database in conjunction with their site generation, the site building tool. They're calling it "the database platform for content driven websites" and also describe it as "Astro DB is a fully managed SQL database designed exclusively for Astro." it's got Drizzle built in and uses LibSQL.
-
-[07:37] Apparently Lib SQL is a fork of SQLite, which, they posted a deep dive that goes into a lot of the sort of the history and how this whole thing unfolded. And they talk about trying to make it work spring of last year with SQLite, but they ran into constraints with the fact that SQLite relies on compiled components within it, the C native code produced performance constraints that didn't really work very well within serverless environments. So they then tried again with this fork of SQLite that does not use those same native compiled, subcomponents within it. that's super cool, I think this is neat.
-
-[08:11] It sounds like they're very much positioning themselves as a WordPress competitor. So it's, you know, content driven websites with an included database. Like, that sounds like WordPress to me. So I think that's pretty cool. Astro's been doing a lot of things, this really does seem like a substantial change to the core offering.
-
-[08:29] **Mark Erikson:** And purely from a technical perspective, it is interesting to see that there's been a number of tools and services that are being built using SQLite as more than just like a local datastore as of late.
-
-[08:40] I think Cloudflare Durable Objects, are built on SQLite. You've got this AstroDB, I think I've seen a couple other tools as well. A lot of tools that are basing themselves around SQLite in some way.
-
-[08:52] **Carl Vitullo:** Yeah, definitely. I read a really good blog post talking about why SQLite makes sense in a lot more contexts than we've generally given it credit for.
-
-[09:01] And, yeah, it seems like people are really experimenting in real meaningful ways with different places to use it, which I think is awesome. I think it's a great project. You know, co locate your database with your executing code because it's small and fast, keep it a single binary.
-
-[09:15] Yeah, this is not quite directly related, but while we're talking about databases, I also heard about, PGLite, which is a Postgres implementation packaged as a WASM module, which, that's neat.
-
-[09:27] It's not quite SQLite, but if you need a database in your browser app, it seems like a cool new option.
-
-[09:34] **Mark Erikson:** There's probably also some kind of application for, I don't know, running end to end tests in the back end with that as like an in memory database or something like that?
-
-[09:43] **Carl Vitullo:** Yeah, that's actually, that blog post I mentioned about SQLite, that was one of the things that they've said that SQLite has been relegated to just being like the test database because it's, you know, super fast and, you know, super easy to spin up. So, yeah. Definitely makes sense in those sorts of contexts.
-
-## Upcoming conferences
-
-[09:58] **Carl Vitullo:** Blasting through conferences.
-
-[09:59] Epic Web is coming up April 10th and 11th in Park City, Utah.
-
-[10:03] React Miami, Mark and I will both be there, is April 19th. We actually have a discount code. So if you are interested in going to React Miami, make sure to, one, get your ticket soon, cause it's in like three weeks, and get your ticket with the code REACTIFLUX4EVER with number 4.
-
-[10:21] Very much looking forward to that though. There's React Connection and React Native Connection on April 22nd and 23rd in Paris.
-
-[10:27] **Mark Erikson:** And I will be speaking there going straight from Miami.
-
-[10:30] **Carl Vitullo:** Haa, wonderful, yeah, 20th to 22nd, that's a quick turn for an international flight across the Atlantic.
-
-[10:36] There's PostCon April 30th and May 1st. That's from Postman. So they're doing like an API conference, they're calling it.
-
-[10:42] And then the big one, React Conf, is happening May 15th and 16th in Henderson, Nevada, just outside Las Vegas. Cool.
-
-[10:50] Alright, whew, we finally made it to the main bulk of the content. Yeah, Mark, you want to take us off with our first set of discussions?
-
-## React 19 and React Compiler
-
-[10:58] **Mark Erikson:** Alright, so there's a number of pieces of news around React 19 and the React compiler tool that was announced a couple months ago. So first off, I saw a PR go up just a day or so ago. React's codebase has lots of feature flags because they build React for many different use cases. There's internal Facebook builds, public open source builds, React Native builds, experimental builds, canary builds, lots of different combinations.
-
-[11:23] And so the React team is constantly adding new feature flags, altering the feature flags, changing the default value. And so this PR makes it sound as though what's in Canary right now is what's expected to go into React 19. So that sounds like a, you know, fairly meaningful step towards a potential React 19 release.
-
-[11:43] Also, if you've just been keeping an eye on the list of pull requests in the repository, there have been a ton of internal cleanup PRs where they've been changing over a lot of the existing tests to actually use some of the more modern React APIs, like, uh, React on client slash render, instead of the old React render, et cetera.
-
-[12:01] One thing that wasn't entirely clear from the React labs blog post in February is that React 19 and React compiler are not directly tied together. They're both things that are in progress, but React compiler is a separate project. And it probably will come out sometime after React 19 is released. So, different projects, separate schedules, but still both very much in flight.
-
-[12:29] Speaking of React Compiler, there's been a couple good posts discussing how it works and what practical effects it'll have. Nadia Makarevich has done multiple great blog posts about React rendering somewhat similar to the post that I had written a while back. And she put up a post talking about React 19 and React Compiler and, you know, some of the practical benefits like not having to write code that does a lot of your own memoization logic because the compiler will do it for you and it will help with rendering performance.
-
-[12:59] And then, Satya, who is on the actual React compiler team, and has popped in and hung around Reactiflux a decent amount, put up a couple really good posts talking about the internal implementation details of the compiler itself. The compiler is currently exposed to the world as a Babel plugin, but that's more for ease of integration with the existing build tool ecosystem.
-
-[13:24] The way I understand it is that the Babel plugin basically acts as just kind of like an outer shell and then all the real logic is like a full blown compiler from scratch that the Babel plugin kind of forwards everything to.
-
-[13:38] So, you know, perhaps at first to make use of it. You would need to have Babel set up, but with the way they've got it designed, they would eventually be able to, you know, maybe expose it as, you know, an SWC plugin, or its own standalone tool, or something like that. Also, sort of tied to React 19, there was, I don't know, maybe controversy is a little strong, but kerfluffle? Annoyance? Frustration back and forth?
-
-[14:03] **Carl Vitullo:** A joke that didn't land.
-
-[14:04] **Mark Erikson:** Yeah. So, a little bit of background. The React Three Fiber ecosystem is pretty large. uh, DRCMDA, however you pronounce his username, uh, I think his name's Paul Henschel, and a bunch of other folks have done some amazing work over the last few years to create a React renderer that wraps the three.js 3D WebGL library so that you can write React components that render full blown 3D scenes and control them. And while I have not played with this myself, I've seen lots of examples and snippets and videos of some incredibly impressive demos and apps and tools that they've built over the last few years.
-
-[14:44] Now, one issue is that React three fiber is its own separate React renderer different from React DOM. Like, they both have their own copies of React's core logic embedded in them. And React has a limitation that different renderers in the same program don't actually know about each other. And so, if you think about a typical web app, you're probably using React DOM to render the outer page, and then you might be using React Three Fiber to render, you know, like a 3D animated scene or a game or something inside of the page.
-
-[15:22] And the problem is that if you try to render a context provider, In, like, React DOM, React Three Fiber will not see it, because they are effectively totally separate worlds that just happen to be nested in each other. And so, there was a PR, there was an issue request all the way back in 2019, where some folks like the React Three Fiber people were asking, " Can React add a way to try to share context?"
-
-[15:48] between renderers. And that PR has been open for a long time, er, issue, and nothing's happened with it. So, the React Three Fiber folks ended up writing a very intentionally hacky package called `its-fine`, which, you know, references that goofy little, like, dog in the fire meme. It very intentionally reaches into React's internals and accesses fields that you're not supposed to be able to grab context instances from.
-
-[16:15] And pass them across the renderer boundary so that you could have like your context provider with user data or something at the top of the whole application and both React DOM and React Three Fiber could read from it. Well, a few weeks ago, Sebastien Mårkbage from the React team put up a tweet where he linked to the dependents of the it's fine package and said, " yeah, this is a list of Packages and tools that will break in React 19," which is fair.
-
-[16:41] I mean, it's a package that intentionally reaches into React's internals. You have to expect that there's going to be breakage. So that's a very legitimate observation.
-
-[16:50] But then it kind of went off the rails a little bit. Another one of the React team members, Rick Hanlon, actually posted a PR in the React repo that he labeled, " it's not fine," and that PR literally just looks for the existence of the it's fine package in your project and throws an error if it's detected. Now, while he didn't explicitly say it in the initial version of the PR, it was obvious this was a joke and it was never going to be merged. But, I'll be honest, speaking personally, I found that joke to be in very bad taste.
-
-[17:23] To me, as a library maintainer, if people are writing code in a way that reaches into my own library's internals, that usually says to me that there's some use case that I haven't considered that I ought to at least think about trying to handle. and make a public API for. As an example, with React Redux, up through version 5, used the old style React context system.
-
-[17:50] And everybody knew that you could reach in and grab the Redux store by accessing `this.context.store`, but it was never part of our public API. And so when we switched over to the new context API in version 6, Number one, all those old usages broke. And number two, we actually publicly added a useStore hook, that, you know, just grabs the store off of new context and returns it. And so it's not something we recommend using, but it's a thing people sometimes had a reason to do. And so we provided an API to do it.
-
-[18:26] So my stance as a maintainer and a community person here is that, number one, the joke PR was a bad idea. The React team has had enough issues with marketing and PR and DevRel.
-
-[18:39] Mistakes in the last few years and this really did not help the situation. And number two, you know, making the original observation that, hey, these things are going to break is fine, but maybe instead of making a joke, Pierre saying, "haha, we're going to ban this package", maybe you should be trying to address the legitimate request for a way to use React that does not officially work right now.
-
-[19:02] **Carl Vitullo:** It looks like this did turn into that as well. In a reply on that, you know, joke PR, Sebastien Mårkbage did come in with some like real analysis on, you know, he said, I spent some time investigation or investigating. "The proper solution behaves like a portal should forward the value during a concurrent render into the child."
-
-[19:26] Yeah, it's, it basically, it sounds like what he was saying is, " it's tough, it would require some adjustment to these other guarantees that we make, will take a fair amount of time to evaluate whether this is going to be actually possible. It's not our top priority because of the bit of a fringe need."
-
-[19:42] Which, all very fair. So I'm glad this did come back and get some, like, real technical back and forth. it just felt like it felt a little bit like targeted and kind of mean spirited. So, you know, glad it came back and had some more meaningful discussion about the problem and what the right solution—
-
-[20:00] **Mark Erikson:** the technical feasibility aspect of it. Yeah.
-
-## React Strict DOM, Why is it so Great?
-
-[20:02] **Carl Vitullo:** Yeah, most definitely.
-
-[20:04] Next one, there was a really great post called, React Strict DOM, Why is it so great? From Syzmon Rybczak? I am so sorry if I'm murdering that, but, interestingly, he, he claims to be 17 and working at Callstack. So, wow, cool. This is a great post flat out. And this is a phenomenal post for a 17 year old developer. Like, wow, cool. Somebody to keep an eye on.
-
-[20:24] But, talking about, React Strict DOM, and, sort of the, Technical background of where it came from and contrasting it with React Native for web. Actually, as I was reading this, it reminded me of some of the discussion we've had, but this is a really great long form write up of, that hits a lot of the same notes that we discussed previously, but with added benefit of pretty great technical diagrams made with Excalidraw . Yeah, definitely good to check out.
-
-[20:52] It talks about how React Native Web is It's ultimately a shim that offers compatibility with the React Native API, which the big downside of that is because of the approach it took, it is necessarily a relatively large shim, and adding A large core package to a web app, just it, it inflates the bundle significantly, more significantly than not using it, which is just the extra friction, which makes it just that much harder to get adoption.
-
-[21:23] And since React Native Web didn't really get adoption. So the React strict DOM approach sort of comes at it backwards, where it takes web APIs to render components out and, because it is taking such a different approach to a similar problem, it is able to keep the size of this shim, this compatibility layer, much, much smaller.
-
-[21:44] So it looks like the core of it is coming from these two CSS and HTML exports from the ReactStrict DOM package, and those are how React Native would then understand how to handle these UI primitives.
-
-[21:59] **Mark Erikson:** Yeah, another way to put it is that the React Native web package gave you what looked like React Native components, so you would write your web code as if it were targeting React Native.
-
-[22:12] With React Script Dom, it's flipped, so that you're You write React Native code as if you were targeting the web, and so you write, you know, your components return a, quote, div on both platforms, but now with React Strict DOM, what you said was a div on native actually becomes a React Native view instead.
-
-[22:33] **Carl Vitullo:** Yes. Thank you for that. I guess I didn't realize that the React Strict DOM package is built on StyleX? Like it looks like that is very core to what is enabling this, I guess? I know you have explained StyleX to me at least once before and I just don't have a, it doesn't, it didn't stick in my brain.
-
-[22:50] **Mark Erikson:** As usual, I've only glanced at it myself.
-
-[22:52] It is yet another CSS in JS type tool. It was developed internally at Meta, like many of the other tools that they've put out there. As I understand it, some of the defining features are it's more of a compile time tool instead of runtime. And I believe it compiles down to more of an atomic CSS setup so that it.
-
-[23:14] Like over time, the amount of extra styles that get generated stay pretty limited because, you know, like everywhere you use like a certain margin size or something that only ultimately adds one rule to the code base.
-
-[23:28] **Carl Vitullo:** It's definitely similar ish to the like compiler for the Tailwind compiler works ish, but operating on a different set of, uh, underlying primitives.
-
-[23:37] Very interesting. Didn't realize that it was so connected to React strict DOM. So that's pretty cool.
-
-## Server Components updates
-
-[23:42] **Mark Erikson:** Moving right along, we have a few different articles and bits of information related to server components. There was A couple articles that discussed kind of like some of the philosophical or conceptual model of React and server components.
-
-[23:57] There was one article in particular that tried to go back to React's, early selling point of your UI is a function of state. And, when we say state, we normally think about state in components, or maybe state in, you know, You know, an external state library like Redux or Jotai or something. The article makes the point that there could actually be lots and lots of sources of state in your application.
-
-[24:22] You know, there's the URL, there's server files, there's the current time, operating system settings, environment variables, You know, lots of different potential sources of state. And so, you know, kind of walking back philosophically about, you know, how do these concepts tie together. And the author goes in a couple different directions.
-
-[24:40] On the one hand, extrapolating some of React's principles, you know, the React team has always been very focused on composability. And that's why we ended up with the custom hooks model that we did, because it enables arbitrary composition of hooks. On the other hand, the author also put up a follow up post saying that they think that Next actually kind of breaks some of these React fundamentals with the way that server components work and some of the way you have to actually structure your code base and your data flow.
-
-[25:10] I don't have a particularly strong opinion here, but it's always nice to see people actually kind of thinking through the concepts and the consequences involved.
-
-[25:18] **Carl Vitullo:** Yeah, and I really like the focus on. Discussing what state is. I feel like the, you know, the React ecosystem has been talking about state and state management for so long that, you know, there's always a game of telephone that happens in trying to communicate concepts out.
-
-[25:34] And I feel like where that has ended up over the years in the React ecosystem is people think state is a single blob of JSON. You know, that their app uses. But what this article is bringing back up is like, no, that's not the only type of state. State is something that your app needs to track in order to function correctly.
-
-[25:55] So yeah, I just wanted to call that out. I think that's a really useful clarification.
-
-[26:00] **Mark Erikson:** There was also a pretty good post over at Builder. io entitled, Why React Server Components are Breaking Builds to Win Tomorrow. I actually didn't quite catch the where in this it's talking about the breaking builds concept specifically, but it does a pretty good job of talking about the different concepts of rendering on the client, versus rendering on the server, versus streaming HTML, and how suspense and server components actually make some of these capabilities possible. So it's a pretty good kind of like technical architectural walkthrough.
-
-[26:31] Moving on a little further to the ecosystem. The Waku project from Daishikado, who's the author of Jotai and Valtio and Maintainer as Zustand, is making good progress. They've announced that they're working on a Pages router.
-
-[26:44] And I believe they're up to version 0. 20. Not sure what the roadmap is to 1. 0, but it's definitely a nice alternative approach to what we've seen with Next. And I believe they're pretty serious about trying to make it like a full blown, meaningful, usable framework based on server components. Similarly, Lee Robinson from Vercel actually just tweeted out a list of at least a half dozen different projects that are working on server component support in some fashion.
-
-[27:14] And so there's definitely work being done in the ecosystem. More specifically, the Redwood project. which originally went all in on GraphQL as the back end, just announced that they have finally managed to succeed in integrating server components. And I think they actually put up a post a few months ago saying that we are all in on server components as a concept.
-
-[27:36] So, server components have been out in Next for a while. We know that Remix is working on them, but there's other tools and frameworks that are trying to adopt them as well. And finally, I, one slight counterpoint, found an article just a little bit earlier where a company said, you know, we've tried server components and we like them, and we tried the new React server actions support.
-
-[27:57] But they ran into a few technical details, or technical issues. They didn't get a lot of details. It looked like something about some bundle problems, and then they felt that there was too much magic going on at the architectural level, and so they actually dropped server actions and went back to using tRPC instead.
-
-[28:13] **Carl Vitullo:** Interesting. Yeah. Too much magic is a very hand wavy type of complaint that can be used for all sorts of different, uh, underlying problems. So I'm curious what some more of those technical details would have been. But it's cool to see more experimentation and a wider range of experiments being done with server components generally.
-
-[28:33] When we first talked about WACU, I kind of expected it to be like just sort of an experiment, just sort of a like trial, because we'd seen a couple of those. We've seen, we had seen a couple of people just throwing together a project, doing it for learning, doing it to just explore. There's been. Pretty consistent development on Waku, so very interesting to see.
-
-[28:52] We'll have to see if it grows into a, like, serious competitor framework for, you know, okay, like, if it makes it to Remix or Next tier, then I would be very impressed. But, you know, they're definitely working on it in a much more meaningful way than I was anticipating originally.
-
-## Apple walks back on PWAs, neat Safari features
-
-[29:06] **Carl Vitullo:** A bit of a follow up to something we talked about last month of, uh, Apple's Attempted undoing of PWAs attempted.
-
-[29:15] I don't know how to frame that, but the last month. Apple announced they were going to drop support for progressive web applications for installing a web app to your home screen. They very quickly walked that back. And actually now, like I was just checking in on WebKit updates and they're adding more support for progressive web apps.
-
-[29:32] They are most specifically, they're going to be supporting the shortcuts manifest property, which allows you to add context items for the home icon. So, you know. On a Mac, if you add it to the dock, you can right click on it and it will show up a couple of options that take you to specific URLs within the app.
-
-[29:51] So, you know, it's a shortcut. It's a context item for your home screen icon that takes you to somewhere specifically within the app. Like, these are the kind of things that Like what progressive web apps have been a thing for like a decade now. Like there was never a technical reason why Apple could not support shortcuts in this.
-
-[30:08] So this feels like a shift of tack to more meaningfully support progressive web apps so that they can entrench themselves and say like, no, look, we are, we do support alternatives. We're not a monopoly while they're defending lawsuits against the iPhone and app store. So cool. You know, if that ends up bringing more meaningful support of progressive web apps. Uh, I'm pretty excited. You have to see how that shakes out though.
-
-[30:32] Another small, interesting thing coming from here, not related to progressive web apps, just Safari web kit features. They added a like progressive enhancement type option for checkbox. So they added a switch attribute to the input in Safari.
-
-[30:48] So if you say input type checkbox switch. It will render as a switch. It was one of those solutions that felt really obvious in hindsight, and I have implemented so many switches in my career, and they are a pain in the butt to get to work correctly. So having a native option, like, now I want Chrome and Firefox to roll it out, like, immediately, because it is Just a great improvement.
-
-[31:08] It's a very small, but very meaningful improvement. I love to see, it's not even like innovation in form inputs. It's just like fixing a problem, fixing something that's been missing for 15 years at this point.
-
-[31:21] **Mark Erikson:** Nicole, who had been heading up a lot of Chrome's work around interacting with frameworks, I know that she had spearheaded a lot of efforts to try to improve native form controls as a concept.
-
-[31:33] I also know there's a project called Open UI, which is somewhere between let's build another set of web components, but also let's kind of like prototype and experiment with what additional built in browser forms and features would look like. And what if there were a tabs or a carousel kind of control built into browsers natively?
-
-[31:56] And so they've been doing work to try to spec those out.
-
-[31:59] **Carl Vitullo:** Oh, very cool. In some ways, I feel like in trying to be agnostic and provide maximum flexibility to developers, I feel like we used to have, like, the operating systems, before everything moved into being web based, operating systems provided, like, a very limited toolkit of, like, here are your UI elements.
-
-[32:18] **Mark Erikson:** And bring back the styled win Windows XP Common Controls, Doug on it. .
-
-[32:23] **Carl Vitullo:** Right, right. Where's the, where's the Windows 95, you know, tab list? Like, okay. Sure. Uh, we've had a lot more experimentation in different types of UIs and different types of ex uh, different types of user experiences. But like, man, you know, it's, I feel like it's also gotten super fragmented.
-
-[32:38] And so maybe this is the pendulum. Maybe, you know, it went, it started by technical necessity on a super constrained set of core components that you just added. And then we went all the way, maximum flexibility. You can do anything you want, anything and everything. And now people are going like, uh, I'm tired of figuring out new unfamiliar UIs.
-
-[32:57] I'm tired of implementing things from scratch. So, uh, yeah, I, maybe we'll. Consolidate a little more back on a simpler set of UI primitives.
-
-## Mental Health in Open Source
-
-[33:05] **Mark Erikson:** All right, changing topics completely. There was an excellent article this week from Anthony Fu, who is a prolific maintainer and developer within the Vite and Vue ecosystems.
-
-[33:17] And, you know, strictly speaking, this has nothing to do with React, but it is an excellent article. And so he wrote about mental health in open source. And he talked about, you know, he got involved in open source kind of by accident. Thanks And he made a lot of great points that absolutely resonated with me.
-
-[33:34] Like, as a fellow open source maintainer, I 100 percent absolutely agree and endorse and stamp and repeat every single thing that he said in this post. So we talked about, you know, not being prepared, like, as a maintainer, you are a developer, and tech support, and marketing, and docs writer, and team leader, and project manager, and, you know, a whole bunch of other hats, and nobody teaches you how to do any of this stuff.
-
-[34:03] But there's also a really big problem with expectations, both internal and external. You know, users file bug reports, and they expect their bug to be fixed right away. But then, as a maintainer, you also put a lot of pressure on yourself to try to get stuff done. And I unfortunately am very guilty of this.
-
-[34:21] I routinely have put far too much expectations and self responsibility to get certain things done. And then I feel bad when I don't live up to my own expectations. As an example, I've said that this year I want to do a refresh pass on the Redux docs tutorials. And I've sat down like three different evenings and made some progress on it, but I've been otherwise focused on some different things and my brain is yelling at me because I quote, haven't made as much progress as I should have made by the end of March.
-
-[34:54] Nobody's watching me. Nobody is keeping track. Like, I've tweeted that I was gonna do this, but like, no one is watching me. It's my own head that is yelling at me because I don't feel like I've gotten enough done. And so Anthony has, you know, some similar points that he makes in his post. And then he also talks about, you know, in some ways your dream of working on this tool can become its own entire second job.
-
-[35:17] So there's not like a specific solution that he discusses, but everything he said on that post, like is absolutely my own experience and it's very much worth reading.
-
-[35:28] **Carl Vitullo:** Definitely worth reading. You have a lot of good things to say about like making your hobby, your job, that definitely resonates with me because that's kind of what I've been trying to do with the community stuff here in Reactiflux, part of why we are doing this podcast is because I thought, you know what, podcasts, that's the way to make money, not that it's worked yet, but you know, hey, sooner or later.
-
-[35:48] But yeah, this is, I definitely thought this was a really great and, I think it's a pretty vulnerable post. He's being very open about the difficulty of taking on this category of work. So yeah, also he talks, he says in the beginning, it's been about four years since I started doing open source and that's like, man, that puts him at.
-
-[36:07] 2019, 2020? 2020? That's four years ago? What? I don't know. This blew my mind a little bit. I have never been an open source maintainer, really. I did briefly take over a, you know, abandoned project and did a little bit of work on it. But, you know, it was so small that I don't feel like I can meaningfully claim the open source maintainer.
-
-[36:27] But, you Even just, even a very small library that was, ultimately was functionally replaced by a browser standard, it was a sticky, you know, Sticky banner library. Even just doing that for a couple of, I guess it was close to a year, just fielding issues and diagnosing and figuring out the, whether the answer to a question is yes, this is the bug that needs to be fixed or no, this is a
-
-[36:49] **Mark Erikson:** Intentional design limitation or something.
-
-[36:52] **Carl Vitullo:** There we go. Yes. This is an intentional constraint that. The trade offs are such that this is the correct decision. That's a lot of mental energy to expend. Like, you know, separate from, and I never did any blogging on it. I never, you know, spoke at any conferences. It was like a, an extremely small part of my, Attention.
-
-[37:09] And it still wore on me a little bit. So yeah, definitely a really good post to read. Really good projects alive that all of us use to do our jobs. Yeah, definitely recommend reading it.
-
-## Angular, meet Wiz
-
-[37:20] **Carl Vitullo:** I'll move us on. This is even farther afield from React, but, um, I saw Sarah Drasner tweeted that the Angular is going to be merging with a heretofore unopensourced internal Google framework called Wiz.
-
-[37:36] Wiz was brand new to me, I had never heard of it. So. Hearing that, you know, Angular, one of these huge projects, one of the projects in web is going to be internally combining with a never open source project. That's a pretty big statement. That's a pretty big plan.
-
-[37:51] It looks like this ultimately came from a exploration of using signals within, you know, signals and reactivity within Angular and drawing inspiration from this well understood internal framework called Wiz that I believe it is.
-
-[38:07] No. Okay. So the combination of Angular and Wiz is already rolled out to 100 percent of YouTube traffic. So like, this is not, you know, an abstract. Intent to, like, no, this is done. This is, you know, I took this as a similar in weight to when the React core team announced that server components were being used on the Instagram web property, you know?
-
-[38:29] So this is a meaningful investment. One of the big reasons that I think this is worth discussing on our React news show, Malte Ube, he is currently working at Vercel. He did a lot of work on Wiz. Back in the day at Google, he, and he had a really good post where he talked about like, why was that? Why was Wiz developed?
-
-## Designing Very Large Javascript Applications
-
-[38:49] **Carl Vitullo:** What problem was it trying to solve? And so he put up this blog post called Designing Very Large JavaScript Applications, which is ostensibly about Wiz and about, you know, these frameworks. But I found it to be a really clear and cogent articulation of a lot of the challenges that React. is trying to solve as well.
-
-[39:08] It's, you know, it talks about like the challenges of centralizing configuration and how, you know, things like a routes configuration file or the webpack configuration file, when you start maintaining a Enormous web application begins to be such a large constraint as to be like prohibitive. Like it just, it doesn't work.
-
-[39:29] You can't scale it. It ends up being append only. And so then you end up loading the bundle, like it becomes fragile because nobody wants to remove things. So then nobody wants to change, make certain categories of changes. Definitely a really good post discussing a lot of the finer points around bundling and architecture limits of current tooling and the most challenging.
-
-[39:49] Parts of large and complex applications. Uh, specifically he talks about Google search results and you know, now they serve up lots of little, uh, widgets as the first result. Like, you know, you search some math and it will spit out a calculator. You search a currency conversion and it puts up.
-
-[40:03] A calculator. Or all sorts of those things. Like each of those is basically its own tiny web app, and so if you just pull up Google, obviously they cannot serve up dozens and dozens of these tiny web apps that you're not using. So that's sort of the category, that's the backdrop and the framing for this architecture that's gotten.
-
-[40:21] Yeah, definitely really interesting. Definitely recommend giving it a read.
-
-[40:24] **Mark Erikson:** One other small tangent off that is, you know, we've heard the discussions and the arguments about front end development doesn't get the respect that it deserves for being its own very complicated domain. And I think that post is a very good example of, you know, real world apps have a lot of complexity and there are, they have their own unique sets of constraints and concerns and potential problems they have to work through.
-
-[40:47] Yeah,
-
-[40:48] **Carl Vitullo:** very true. And on that note, something that struck me reading it is that is an entirely different set of constraints than I personally have ever experienced in my career. So of all of the weird, quirky, you know, specific reasons why like this tool doesn't work for this product or whatever, That was a whole new category that I've never encountered, like, I, you know, I don't work on a Google type app where there might be one of a hundred and fifty different things served on the same page.
-
-[41:16] So I just thought that was really interesting. It was a glimpse into a different part of the web world. Just broadened my perspective just that little bit much more.
-
-[41:23] **Mark Erikson:** I mean, similarly, you were talking earlier about like, you know, I've implemented, you know, a half dozen input widgets or something in my career.
-
-[41:30] Like, I've never done anything like that. I mean, I've never worked on a project that really made meaningful use of a router. At all. Like everything I've worked on in my career has basically been the equivalent of a desktop app that runs in a browser that, you know, it's an app, not like pages or routing.
-
-[41:51] So like I've barely ever used routing in my own career because the products I've worked on just haven't required it.
-
-[41:58] **Carl Vitullo:** Yeah. I think that is so true and very underappreciated even within frontend. I think that so like you said, I've implemented a lot of checkboxes. That's because I've jumped around to a lot of different startups and I've worked on a lot of greenfield projects.
-
-[42:11] So I actually think that I have a relatively rare perspective on the industry of, you know, I didn't spend six years at, you know, Google. Four years at Facebook. In, in my, over my 10 year career, I worked at nine different companies. Like, you know, I've seen a lot of different types of products. I've worked in advertising tech, agriculture tech, cryptocurrencies, done brochure sales sites for credit card companies.
-
-[42:34] So like, I have worked in a bunch of different contexts. And what I've learned is that Well, something I experienced was that surprisingly little of what I used in one company was immediately relevant at the next company. Like, the architectures were just so different that the assumptions I couldn't bring any of my past assumptions.
-
-[42:53] I had to leave all those assumptions at the door and just rediscover a new problem space every time I joined a new company. And so here's Malte discussing an entirely new type of architectural constraint that I have never encountered, despite my wide range of encountered problems. Last thing I'll say on that, he gave a talk at JSConf Australia in 2018.
-
-[43:13] Speaking about Wiz and talking a little bit about his decision not to open source. He says at the time didn't want to compete with React. There were already so many options, adding another one seemed unnecessary. And like, yeah, I, 2018, I feel like that was about peak JavaScript fatigue era. Um, but now he describes that decision not to open source as a misread of the market demand.
-
-[43:36] So that's interesting. So just bringing it back to Angular meets Wiz. I think, yeah, I'm going to be paying attention to that to see how that shakes out a little bit more. It seems like it's, he regards it as a correction to a mistake made like five or six years ago.
-
-## Lightning round
-
-[43:51] **Carl Vitullo:** We're into the lightning round. We are over an hour.
-
-[43:53] **Mark Erikson:** Lightning the lightning round.
-
-[43:55] **Carl Vitullo:** Yeah, lightning the lightning round. Cool.
-
-## ⚡️ Interaction to Next Paint, new Core Web Vital ⚡️
-
-[43:56] **Carl Vitullo:** First off, there is a new Core Web Vital, which are the, like, lighthouse, Performance characteristics that are measured by Google. I believe the Core Web Vitals are one relatively significant input to search ranking for like search engine optimization.
-
-[44:12] Interaction to NextPaint, INP, is replacing first input delay as a Core Web Vital. So really quick overview, uh, first input delay was You open up a new website, how long until that code responds to the first input you give it? You know, a click, a scroll, a keystroke. That is no longer going to be a Core Web Vital, and instead it will be how long between an interaction and the next paint.
-
-[44:36] Notably, that's A change from measuring like startup responsiveness to ongoing responsiveness, which I think is very important. 'cause you know, it's much easier to do a, a one-time optimization of the app as it's loading versus a just optimizing the entire app so it's more responsive and just faster, better. So yeah, definitely seems like a much more meaningful metric.
-
-## ⚡️ RSPack charts a path to 1.0 ⚡️
-
-[44:56] **Mark Erikson:** Next up, there's been a plethora of rust based javaScript build tools as of late. One of those is called RS Pack, which is a rust based reimplementation of the entire web pack tool being built by ance. RS Build is a layer on top of that from the same team that makes the web pack layer easier to use.
-
-[45:20] So conceptually this is like a CRE React app equivalent, and they actually have how to migrate from CRA in their docs. They have announced plans for their roadmap to a 1.0 release. For what it's worth, I tried out RS build in one relatively small CRA project that I had, and it worked great. Like the build time dropped from like 30 seconds to one second.
-
-## ⚡️ Remix might merge React Router in?? ⚡️
-
-[45:42] **Mark Erikson:** Entirely other news, Ryan Florence has been talking about how the Remix team has been continually adding more features to React Router, things like loaders and such. And so he's now tossing out the idea that they might end up effectively merging the Remix and React Router projects in some way. Details TBD. But it's something that they're thinking about.
-
-## ⚡ Declarative Shadow DOM in all major browsers ⚡️
-
-[46:08] **Carl Vitullo:** I have another broad web update here. Declarative Shadow DOM is now available in all major browsers. This is related to web components. I know that one of the major criticisms in the past several years, many years, has been Of web components has been that it is not possible to use them without JavaScript.
-
-[46:27] How they get added to the page is through JavaScript. And so if you are trying to make, there are many categories of web products, web properties. Where that just doesn't work. You can't use JavaScript, you can't rely on it, many reasons it doesn't work. And so, this is a declarative version of Shadow DOM that is now supported in all major browsers.
-
-[46:46] And, theoretically, maybe this will unlock a new era of experimentation in web toolkits. Now that we can use Web components without JavaScript. I think that we might start seeing some more experimentation. This kind of feels like what web components have always been meant to be. So yeah, interesting.
-
-## ⚡️ React Native community map ⚡️
-
-[47:05] **Mark Erikson:** Okay, next up, there's a developer named Lorenzo Sciandra, who works at Microsoft, I believe, on Microsoft's maintenance of React Native for Windows and React Native for Mac, and he's put together a repository list that points to lots of community resources for React Native. Discords and servers and discussions. So if you're interested in React Native and other possible community resources, that's useful.
-
-[47:31] **Carl Vitullo:** Yep, we're on there. Woo! (chuckles)
-
-## ⚡️ Node.js 2023 Year in Review ⚡️
-
-[47:34] **Carl Vitullo:** As mentioned much earlier, there was a Node. js 2023 year in review post.
-
-[47:39] It's mostly just sort of talking about, like, Technical overview of how Node itself has changed over the years. So it's not so much like how you use it or, you know, performance. It's here is how usage of different versions have, has trended over time as different ones have gone end of life or been released.
-
-[47:58] It has a great chart of the binary size per version over time, which let me just call out. So version 10. 24. was about 40 megabytes or mebibytes. I'm just going to call it megabytes. Version 21. 6 was 98. So that's a long time. Version 10 versus version 21. I think that's Like close to 10 years, something like that.
-
-[48:22] But yeah, seeing it 2. 5X in size over that time is, yeah, I guess it's been kind of append only. So yeah, like we discussed earlier, TypeScript has been focusing on reducing its install size. It sounds like there might be growing appetite to do so in Node as well. But this is just sort of like a, it's a pretty deep in the weeds discussion of how Node has evolved, and specifically some of the changes in 2023. So I found it was a good read. Not immediately actionable in any kind of way, but just sort of broad context. Stay on top of what's going on.
-
-## ⚡️ Tailwind preview of 4.0 ⚡️
-
-[48:57] **Mark Erikson:** Next up, Tailwind is working on a new version and they've put up a post talking about some of the changes that they're making for version four. The biggest one is they've got a whole new CSS engine.
-
-[49:08] Apparently it's built on top of Lightning CSS, a Rust based CSS parser and translator from the author of Parcel, but they're working to make it the whole thing smaller, faster, built in. They're also making some potential changes to the configuration so it actually kind of looks and feels more like CSS in the process.
-
-## ⚡️ Vercel adds Remix+Vite support ⚡️
-
-[49:26] **Carl Vitullo:** So, Vercel has announced that they are now supporting Remix with Vite. Pretty cool. Just especially because they maintain Next. It seems nice that they would pretty quickly jump on adding support for some new features coming out of Remix. They say in this post, they collaborated with the Remix team to add server bundles to Remix, which we discussed really briefly last month as a kind of confusing, deep optimization.
-
-[49:52] So just to see that. Vercel is meaningfully working to support some kind of fringe, niche features within one of their major competitors. Cool. That seems really nice. Very glad to see that. Also adds support for Remix features like the streaming, server side rendering, API routes, more advanced caching, data mutations.
-
-[50:13] Yeah. Happy to see that.
-
-## ⚡️ Navigating the Future of Frontend ⚡️
-
-[50:15] **Mark Erikson:** And finally, there's an author named Rem, uh, I don't know any more details about them, that's just their handle, who has put up a series of very good posts at a site called Frontend Mastery, talking about various aspects of React and frontend development. And the latest one's called Navigating the Future of Frontend.
-
-[50:32] And it talks about some of the aspects of JavaScript frameworks, and their capabilities, and what are some of these tools even doing for you. And talks about some of the directions that they are going these days in terms of routing, and mingling backend and frontend, and dealing with caching, and components that can be used on the server or on the client, and in a mix of some way.
-
-[50:55] So it's not like a specifically actionable post, but it's a useful guide to, like, where have we been and where are we going.
-
-[51:02] **Carl Vitullo:** Yeah, definitely looks like a really interesting post. And I just realized, just now, that it's not on Frontend Masters, it's Frontend Mastery, which is not an educational platform hahaha.
-
-[51:12] **Mark Erikson:** It looks like it's basically this one person's blog.
-
-[51:15] **Carl Vitullo:** Interesting. Yeah, I, I saw the link and I had assumed that it was really the front end masters, which makes perfect sense because they've been doing web education for my entire career, insofar as I learned React by taking a front end masters class. But yeah, no, this is front end mastery.
-
-[51:29] It's just somebody's blog. Still, it's really good, really good post to echo everything Mark just said.
-
-[51:34] That's everything we got. We'll be back on the last Wednesday of next month in April on the live stage here in Reactiflux or back in your podcast feed just as soon as we can. We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, React Digest, the React. js subreddit, here in Reactiflux, and directly from people publishing articles on Twitter or whatever.
-
-[51:57] If you see anything newsworthy, definitely let us know in the Tech Reads News channel here in Reactiflux, or let me know by sending an email to hello at reactiflux. com with T M I R in the subject line. It's an acronym for the show.
-
-[52:11] I read literally every email that comes in, including spam and all sorts of other things. So yeah, if you send an email to hello at reactiflux. com, I will read it. And if this is a show you get value from and want to support, the best way to do so is submit a review or tell your friends and co workers about it.
-
-[52:26] Just drop it in Slack. And I know that I will personally thank you if I am ever made aware of you broadcasting us. Cool. Thank you so much. See you next month.
diff --git a/src/transcripts/tmir-2024-04.md b/src/transcripts/tmir-2024-04.md
deleted file mode 100644
index 4edf563..0000000
--- a/src/transcripts/tmir-2024-04.md
+++ /dev/null
@@ -1,535 +0,0 @@
----
-title: "This Month in React, April 2024: So many new releases, React 19 featureset"
-date: 2024-04-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- Quick hits
- - [[00:46](#upcoming-conferences)] [Upcoming conferences](https://react.dev/community/conferences)
- - [React Conf 2024](https://conf.react.dev/) May 15 - 16, 2024. In-person in Henderson, NV, USA
- - [App.js Conf 2024](https://appjs.co/) May 22 - 24, 2024. In-person in Kraków, Poland
- - [Local First Conf 2024](https://www.localfirstconf.com/) May 30, 2024. In person in Berlin, Germany. Followup hackathon on the 31st
- - [Render ATL](https://renderatl.com/) June 12-14, 2024. Atlanta, GA, USA
- - [Future Frontend](https://futurefrontend.com/) June 13-14, 2024. Helsinki, Finland
- - [React Norway](https://reactnorway.com/) June 14, 2024. Larvik, Norway
- - [React Summit](https://reactsummit.com/) June 14 + 18, 2024. Amsterdam, Netherlands (+remote)
- - New releases
- - [[02:32](#react-183-19)] [React 18.3](https://github.com/facebook/react/pull/28843)
- - [React 19 beta](https://react.dev/blog/2024/04/25/react-19)
- - [[03:15](#nodejs-v22)] [Node.js v22](https://openjsf.org/blog/nodejs-22-available)
- - [[04:02](#expo-sdk-51-beta)] [Expo SDK 51 beta](https://expo.dev/changelog/2024/04-24-sdk-51-beta)
- - [React Native 0.74.0](https://reactnative.dev/blog/2024/04/22/release-0.74)
- - [React DevTools 5.1](https://github.com/facebook/react/pull/28840)
- - [Next v14.2](https://nextjs.org/blog/next-14-2)
- - Bun v1.1 (discussion later)
- - [Pnpm v9](https://github.com/pnpm/pnpm/releases/tag/v9.0.0)
- - [Biome 1.7](https://biomejs.dev/blog/biome-v1-7/)
- - [Supabase goes GA](https://supabase.com/ga-week) after 4 years in beta
- - [Docusaurus 3.2](https://docusaurus.io/blog/releases/3.2)
- - [Gulp v5](https://medium.com/gulpjs/announcing-gulp-v5-c67d077dbdb7)
- - [Pragmatic Drag and Drop](https://github.com/atlassian/pragmatic-drag-and-drop)
- - [RedwoodJS 7.3](https://github.com/redwoodjs/redwood/releases/tag/v7.3.0)
- - [React on Rails v14](https://github.com/shakacode/react_on_rails)
-
-# Main Content
-
-- [[12:43](#new-react-release-details)] New React development
- - [React Blog - React 19 Beta](https://react.dev/blog/2024/04/25/react-19)
- - [React Blog - React 19 Beta Upgrade Guide](https://react.dev/blog/2024/04/25/react-19-upgrade-guide)
- - [React 18.3 changelog](https://github.com/facebook/react/blob/4508873393058e86bed308b56e49ec883ece59d1/CHANGELOG.md) : dev-only warnings for string refs, `findDOMNode` , default props, legacy context, `test-utils`
- - Internal changes:
- - [Rename SECRET INTERNALS to \_\_CLIENT_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE](https://github.com/facebook/react/pull/28789)
- - [Fast JSX: Don't clone props object](https://github.com/facebook/react/pull/28768)
- - [Remove defaultProps support (except for classes)](https://github.com/facebook/react/pull/28733)
- - [Ship optimized-but-unminified prod bundles and drop sourcemaps](https://github.com/facebook/react/pull/28881) ([current package contents](https://unpkg.com/browse/react-dom@19.0.0-beta-4508873393-20240430/cjs/))
- - [Don’t patch `fetch` anymore](https://github.com/facebook/react/pull/28896)
- - Future: [patching Date object?](https://twitter.com/acdlite/status/1785691330988986587)
-- [[33:29](#react-native-0740)] React Native [0.74.0 release](https://reactnative.dev/blog/2024/04/22/release-0.74)
- - [React Native Navigation v7](https://reactnavigation.org/blog/2024/03/25/introducing-static-api/)
- - [VisionCamera v4.0](https://github.com/mrousavy/react-native-vision-camera)
-- [[38:17](#kotaken-rscs-with-just-bun)] [Kotekan](https://kotekan.dev/blog/introducing-kotekan)
-- [[39:02](#bun-11)] [Bun v1.1](https://bun.sh/blog/bun-v1.1)
-- [[39:37](#jsr-by-deno)] [JSR](https://deno.com/blog/jsr_open_beta)
- - [First Impressions](https://dbushell.com/2024/02/16/jsr-first-impression/), [Second Look](https://dbushell.com/2024/03/04/jsr-second-look/)
- - [First Things I Learned about JSR](https://mariusvatasoiu.com/first-things-i-learned-about-jsr)
-- ⚡️ Lightning round ⚡️
- - ⚡️ [[45:09](#-why-i-like-react-even-in-2024-)] [Why I like React (Even in 2024)](https://ejosh.co/de/2024/03/why-i-like-react-even-in-2024/) ⚡️️
- - ⚡️ [[45:46](#-netlify-updates-their-nextjs-runtime-)] Netlify: [Introducing the new Next.js Runtime](https://www.netlify.com/blog/introducing-the-new-next-js-runtime/) ⚡️️
- - ⚡️ [[47:18](#-design-principles-behind-the-nextjs-app-router-)] [Design Principles behind the Next.js App Router](https://twitter.com/feedthejim/status/1785243633328758978) ⚡️️
- - ⚡️ [[48:04](#-nodejs-website-redesign-)] [Diving into the Node.js Website Redesign](https://nodejs.org/en/blog/announcements/diving-into-the-nodejs-website-redesign) ⚡️️
- - ⚡️ [[48:44](#-dives-into-react-features-)] [How does `useOptimistic` work internally?](https://jser.dev/2024-03-20-how-does-useoptimisticwork-internally-in-react/) (and many other code dives) ⚡️️
- - ⚡️ [[49:27](#-honeypot-releases-nodejs-documentary-)] [Node.js: The Documentary](https://www.youtube.com/watch?v=LB8KwiiUGy0) ⚡️️
- - ⚡️ [[49:56](#-flow-ships-react-features-)] [New Flow Language Features for React](https://medium.com/flow-type/announcing-component-syntax-b6c5285660d0) ⚡️️
- - ⚡️ [[50:26](#-vercel-updates-pricing-)] [Vercel cuts prices a lil](https://vercel.com/blog/improved-infrastructure-pricing) ⚡️️
- - ⚡️ [[51:28](#-redwoodjs-compares-data-fetch-methods-)] [Redwood Blog: Techniques for Fetching Data: Comparing Next, Remix, and Redwood](https://redwoodjs.com/blog/techniques-for-fetching-data) ⚡️️
- - ⚡️ [[52:02](#-kuto-reverse-js-bundler-)] [Kuto, “reverse JS bundler”](https://samthor.au/2024/kuto/) ⚡️️
-
-[00:00] **Carl Vitullo:** Thanks people for joining for April's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
-
-[00:09] **Mark Erikson:** And boy, is it evolving right now.
-
-[00:11] **Carl Vitullo:** Boy, is it evolving. Oh my God. There's so many releases. It's so much to get through.
-
-[00:16] So I guess let's try and run through it quick. Coming to you live from Reactiflux, the place for professional React developers.
-
-[00:24] I'm Carl, a staff product developer and freelance community manager here at Reactiflux, running community events like these.
-
-[00:31] **Mark Erikson:** And I'm Mark Erikson, my day job, I'm a senior front end engineer at Replay where we're building a time traveling debugger for JavaScript with some amazing test analysis features coming your way in the near future.
-
-[00:42] And outside of that, I do Redux stuff.
-
-[00:45] **Carl Vitullo:** So much Redux stuff.
-
-## Upcoming Conferences
-
-[00:46] **Carl Vitullo:** There's so many conferences coming up in the next, like, two months.
-
-[00:49] We've got this month, why I'm in Vegas. So if you're coming to React Conf, hit me up. If you're local and not attending the conference, come on down and we can do a watch party. Otherwise, I'm probably going to try and organize a couple of pre conf Things, post conf, after parties, ReactConf, May 15th and 16th in Henderson, Nevada.
-
-[01:09] AppJSConf is May 22nd through 24th in Krakow, Poland. The local first conf, I love local first stuff.
-
-[01:18] I think it's just a really powerful way to develop applications that is Kind of complicated. So I love seeing a conference dedicated to it. That's going to be May 30th in Berlin, Germany with a follow up hackathon on the 31st.
-
-[01:31] There's Render Atlanta in June 12th through 14th in Atlanta, Georgia.
-
-[01:36] Future Frontend, June 13th and 14th in Helsinki, Finland.
-
-[01:40] React Norway, June 14th in Larvik, Norway.
-
-[01:45] And React Summit, June 14th and 18th it looks like in Amsterdam with a remote option there.
-
-[01:51] **Mark Erikson:** I'm still crossing my fingers that I might at least be able to attend ReactConf here in a couple weeks and then I will be speaking at React Summit in Amsterdam as well.
-
-[02:01] **Carl Vitullo:** Awesome. Very cool. I can't believe how many are crammed into the middle of June. It's, it's a lot of good looking conferences. I know FutureFrontend
-
-[02:09] **Mark Erikson:** Is he the one who has been involved in like writing a webpack book years ago?
-
-[02:14] **Carl Vitullo:** I think so. He was involved in Reactiflux pretty actively a number of years ago.
-
-[02:18] I just wanted to give him a shout out because he's been deep in the React community for a very long time and seems like a cool dude.
-
-## New releases
-
-[02:25] **Carl Vitullo:** We're going to move on to a bunch of new releases. This has been a crazy dense month for new releases.
-
-## React 18.3 + 19
-
-[02:32] **Carl Vitullo:** The big ones, obviously two new React versions have been announced at least. There's React 18. 3. Which I think it's just sort of a pro forma release, getting ready for React 19. No behavior changes, just some extra warnings, a bit of improvements to developer experience to facilitate upgrading to React 19.
-
-[02:54] React 19 beta. Ooh, new major. Definitely excited to see all of the stuff going on there. I don't know. We've talked a lot about all of the development going on into React 19 with stuff like Form Actions, useActionState, RSC is obviously going to be big. Lots of form helpers and stuff.
-
-[03:12] **Mark Erikson:** We'll cover that in detail in a few minutes.
-
-[03:14] **Carl Vitullo:** For sure.
-
-## Node.js v22
-
-[03:15] **Carl Vitullo:** Yeah, new Node. js major version.
-
-[03:18] **Mark Erikson:** And I'm not sure where the versioning ties in, but I know I saw an announcement that some version of Node, probably this one, now has support for importing ESM files via Require, which is gigantic. I don't know what it was they had to do to finally make that work, and why they couldn't have done that like eight years ago, but hey, better late than never.
-
-[03:42] **Carl Vitullo:** Better late than never. Yeah, that, oh man, the ESM versus CommonJS has been such a troubling split in the web ecosystem. So seeing Node finally supporting native ESM import through Require, hopefully will lessen a lot of that pain. Definitely very excited to see that.
-
-## Expo SDK 51 beta
-
-[04:02] **Carl Vitullo:** Okay. Blasting through. We've got Expo SDK 51 is out in beta.
-
-[04:06] That looks interesting. They are including the new React Native release, which we're going to talk about later too. And just lots of other improvements to like cameras and SQLite APIs, iOS privacy manifest, definitely looks like a pretty big one.
-
-## React Native 0.74.0
-
-[04:21] **Carl Vitullo:** React Native 0. 74, definitely pretty big release. We're going to talk about it.
-
-[04:26] A lot more in depth later. Uh, they've got a new version of the yoga layout engine and using yarn three in the default community CLI. But yeah, more details later on.
-
-## React DevTools 5.1
-
-[04:36] **Carl Vitullo:** New DevTools version as well. For React, the React DevTools put out version 5. 1. There's a bunch of changes there, but you know, I don't know. It's the DevTools.
-
-[04:47] **Mark Erikson:** Mostly related to support for the new features like use action state.
-
-[04:52] **Carl Vitullo:** Right, love some better DX there. The DevTools have always been pretty powerful and excited to see what the new experiences there look like.
-
-## Next 14.2
-
-[05:02] **Carl Vitullo:** Next, 14. 2. Gonna chat more on that later, of course.
-
-## Bun v1.1
-
-[05:07] **Carl Vitullo:** Same with Bun, version 1.1. New Bun minor. Again, gonna get deeper into it later on.
-
-## pnpm v9
-
-[05:12] **Carl Vitullo:** PMPM put out a new version 9, so a major version of a pretty significant package manager. I didn't quite realize that the P in PMPM stands for performant. The whole idea is there is that it just is MPM, but faster and better. I've heard from a number of people that it's their package manager of choice.
-
-[05:33] I've never substantially used it. I had used Yarn for a long time, but then I never upgraded from version 2. As I understand, the big improvement for PMPM is that it does sort of what Yarn 3 does similarly with not installing duplicate versions of packages when you have them already installed on disk somewhere.
-
-[05:52] So, That seems really cool. They're also adding like CorePack compatibility, which I understand to be a node standard for better supporting different types of different package managers. So, cool to see them supporting that standard. Always good to see behavior become more standardized, as well as improvements to the lockfile.
-
-## Biome 1.7
-
-[06:12] **Carl Vitullo:** We got Biome 1. 7. I have a soft spot in my heart for Biome. I was an early supporter of Rome and it was very sad to see that, I don't know, kind of go into vaporware mode. So I was excited to see that many of the maintainers of Rome forked the project and came out with Biome. They're advertising single command migration from ESLint as well as Prettier.
-
-[06:34] So I guess two commands, one for ESLint, one for Prettier. And looks like a bunch of smaller developer experience improvements for using it. Like, you know, checking staged files with a command flag. And good default linter configuration. Love the project getting a sort of a bundling. Well, how to disambiguate the term bundling.
-
-[06:55] It sort of bundles up a bunch of behaviors from other tools like linting and. Formatting and all those sorts of things. So I like that. I think it's a very interesting project. Definitely check that out.
-
-## Supabase leaves beta
-
-[07:06] **Carl Vitullo:** Okay. Supabase, which is a, I guess, Postgres as a service. I always have conceptualized it as an open source Firebase competitor.
-
-[07:14] I guess Supabase, yeah, Firebase. I didn't realize that they're still, they had been still in beta, but earlier this month they went general availability, so definitely check out the launch event. Week that they did. I have heard it as, you know, sort of an open source darling. I've seen it all over, you know, Twitter, used by many people who do lots of side projects and smaller greenfield work.
-
-[07:35] So if you're considering something like Firebase, if you're considering a back end as a service, definitely check out Superbase because it is generally available. No longer in beta.
-
-## Docusaurus 3.2
-
-[07:45] **Carl Vitullo:** Docusaurus put out version 3. 2, looks like it's mostly performance improvements, a better table of contents from partials, which I guess is, you know, if you stitch together a bunch of documents into a single page, they now have better support for generating a table of contents.
-
-[08:02] And this is a silly thing that I have always had on my mind, but one of the things they advertised was An accurate last mod time in the sitemap. I have found that tricky. I think that makes a reasonably big difference in SEO. You know, you're signaling to Google or whatever search engine that your content is fresh, is up to date.
-
-[08:21] And in the past, I have generally found sitemap generation tools they just seem to not care about that, like they just put together a list of all the URLs. So just seeing that taken seriously by Sebastien, by Docusaurus, I like it. They also mentioned in their release post that they have overtaken Gatsby in NPM downloads, which seems like a pretty significant milestone.
-
-[08:43] Changing of the guard a little bit.
-
-[08:45] **Mark Erikson:** That is interesting because we use DocuSource for the Redux documentation sites, and it's not like it's getting downloaded continuously in our case, we only do docs updates kind of intermittently. And so for it to actually be getting downloaded frequently suggests there's a lot of people using it for like a non library documentation site kind of use case.
-
-[09:06] You know, more of that static like website beyond just Docs.
-
-## Gulp v5
-
-[09:11] **Carl Vitullo:** This is a bit of a throwback, but Gulp, the now at this point quite long in the tooth build tool, script runner, just released version 5. Man, I haven't thought about Gulp in a number of years, so seeing it cross my path again was just like, oh, Gulp. Nice.
-
-[09:26] **Mark Erikson:** I'm genuinely surprised it's being actively maintained, much less putting out major versions. I mean.
-
-[09:32] **Carl Vitullo:** A little bit!
-
-[09:33] **Mark Erikson:** Admittedly, my own experience is biased. I've been in the React ecosystem where we, you know, webpack, blah, blah, blah, but very surprised to see that it's getting actively developed.
-
-[09:42] **Carl Vitullo:** Would generally agree.
-
-[09:43] They say in the release post, this release contains four years worth 60 projects. The team closed over 200 issues and pull requests. Cool. It's neat to see. Doing a major version seems like maybe a big ask for a project that is, I think, most likely to be used in a maintenance mode capacity. So, major version there seems like a little bit of a hard sell. Nice to see an old name resurface.
-
-## Pragmatic Drag and Drop
-
-[10:07] **Carl Vitullo:** I'm going to shout this out because it's related to a project that we had the maintainer on as a guest a number of months ago, but Pragmatic Drag and Drop from Atlassian. Drag and drop is brought. I've always found it to be kind of challenging to implement.
-
-[10:23] I remember when I spoke with the, the, the maintainer, Alex Reardon a couple of months ago, he had a lot of really interesting things to say about serving the different use cases in drag and drop. And I think he has been involved in maintaining like three different drag and drop open source libraries. So he's been just very deep in it for a very long time. And it sounded like he really pulled a lot of learning from those different types of uses into this project, made it more like pluggable and, only pull in what you need to get the behaviors you want and things like that.
-
-[10:54] So definitely check that out. If you're considering some drag and drop stuff.
-
-## Redwood v7.3
-
-[10:58] **Carl Vitullo:** Redwood JS released version 7. 3. It's the app framework for startups. I'm familiar with the name, but I've never really worked on it too much.
-
-[11:08] **Mark Erikson:** Their big sales pitch was that they did single file component setups where you export a GraphQL vary as a variable.
-
-[11:17] Like, conceptually, think of like a view single file thing, where both the component and other pieces were in a single file. By convention, you export a named variable with a GraphQL query, and all the rest of the pieces just hook together from there. However, they had announced about a year ago that they were going to, quote, go all in on server components.
-
-[11:36] I've seen a lot of chatter from their developers who have been actively working on trying to figure out the mysteries of making server components work for anyone not named Vercel. And so, like I said, I haven't even looked at the release notes here, but from what I've seen, they're getting pretty close on having that working.
-
-[11:53] **Carl Vitullo:** Yeah, that's right. I think I mostly remembered the name from hearing you talk about them as people who are investing pretty seriously in server components. So yeah, new version there. Looks maybe like it has a little bit of overlap with Superbase. Just a little bit closer to the front end half of the stack.
-
-[12:11] But full stack JavaScript application framework, batteries included, backend, React, all that stuff. Definitely interesting.
-
-## React on Rails v14
-
-[12:17] **Carl Vitullo:** And our last new release that we're going to shoot through, React on Rails version 14. This is not something that I've ever made significant use of. I think one of the companies I worked at was using it because they were deeply invested into Rails.
-
-[12:32] But yeah, I mean, you know, if you're using Rails, if you are trying to use React with your Rails app, this seems, as far as I understand, this is the way to do so. So I thought it was worth shouting out a new major version.
-
-## New React release details!
-
-[12:43] **Mark Erikson:** All right, let's roll into a couple of the bigger items from this week. And by far the biggest one is, hallelujah, after two years, we finally have new actual releases of React itself.
-
-[12:57] Literally, there was a guy who had put up a website that was like, what was the time breakdown between consecutive React releases? And, you know, some of these 16 or 17 releases had been like a few months apart, and it had been two years between 18. 2 coming out and today. So, the biggest news is that React 19 is finally in beta, and the React team has an extensive blog post that covers what's actually included.
-
-[13:25] And if you've been paying attention to, you know, the discussions of the canaries and what's been available in Next. js, most of this stuff should not be a surprise. But it's worth briefly summarizing what's there.
-
-[13:36] There's what they're calling actions, which admittedly as the Redux maintainer is a little bit frustrating for me because the word action now has like 15 different overloads. There's what Redux means by it, what MobX means by it, what server components now means by it, but oh, well, whatever.
-
-[13:51] There's a lot of stuff that has to do with forms and async behavior. So if I have a form and I want to send some data to the server and I want to track pending state related to that form submission, React 19 now has multiple new features around being able to provide a callback As the action prop on the form tag itself, there are hooks for tracking form status and trying to handle transitions related to that.
-
-[14:22] As, I unfortunately keep having to say, like, I've read about this stuff, I sort of have the picture in my head of what these things roughly do. I certainly have not had time to play with them, and honestly the kind of apps that I work on today don't even necessarily benefit from this myself. But it is very interesting to see the React team investing in, like, this, this kind of overlaps with a couple of things.
-
-[14:45] One is server components in general, because, you know, Dan's pitch is that server components extend React's one way data flow model to the server. So a server component fetches some data, passes it as props to a child component, which then renders, but if you want to go back to the server component and make it actually do something to force a re render and fetch new data, you have to have some way to reach back to the server.
-
-[15:12] And so my understanding is that server actions are the equivalent of a callback from the parent, except now it's crossing the network boundary And going back all the way to the server. So there's that aspect. There's a hook for optimistic updates and a whole bunch more pieces. It's also interesting because basically all of React's lifetime, we had certain conventions.
-
-[15:33] React was a primarily single page client side app tool, although you could always use it for what we now refer to as the islands architecture, little bits of React inside of an existing page. And you're supposed to use controlled inputs. You were supposed to have a state field for, you know, your first name, your last name, field, et cetera.
-
-[15:56] And you were supposed to keep that data in state and control the input because that matched reacts concept of the UI is always based on your state. And, that still exists, and React still has a ton of logic to make controlled inputs work, but it looks like with React 19, and the new emphasis on forms and actions, that conceptually the React team is now sort of going back to the, well, okay, fine, let's use the platform and have uncontrolled inputs as a default, and grab values from the form, using a form data object. Which is also basically what the Remix team has been telling us for the last two or three years.
-
-[16:40] I, I know that the new React docs now actually have an API reference page for the HTML form tag. Like, there isn't like a usage guide page that says here's how you're supposed to use forms in React, but I believe there is an API ref page that talks about what you can do with the form tag in React. Clearly forms and data inputs are a big emphasis as part of React 19 as a whole.
-
-[17:08] Another big piece is the new use hook, which I guess this means it's finally stable? Maybe? This is the replacement for the long known but always technically internal trigger suspense by throwing a promise.
-
-[17:24] So, instead, now you call the use hook, you pass in a promise, the promise needs to be cached so that you're passing in the same promise reference across renders of the component, but that is what will trigger the suspense boundary in some parent component and make this component wait until the promise is resolved for the data.
-
-[17:44] There's a lot of stuff around the actual. RSC functionality, and there's improvements with things like, with React 19, we now actually get ref as a prop, which means that forward ref can actually go away, finally. And this required a number of changes to React's JSX transform that actually had a lot of internal tweaks that had to be made, like we don't really think about compilation or behavior step of going from JSX tags to React element objects.
-
-[18:18] React originally had the CreateElement API, eventually that got replaced with a somewhat more sophisticated compiler based JSX transform, which still did roughly the same job. And for React 19, they've done a number of changes to the internals of that to make things like passing through ref directly possible.
-
-[18:36] On that note, there was also a PR to change some of the internals where they used to always have to clone. Whatever props object was getting passed into element creation. And that's a hot path because every render is calling this element creation logic thousands of times. And I'd seen some issues filed that complained, like this is a noticeable part of React's performance overhead.
-
-[19:01] So, they've done some optimization work there, and that means that React 19 should have lower overhead in the overall rendering process because it's having to do, less object copying as part of the actual rendering step.
-
-[19:16] A couple other things, you can no longer apply default props to function components. You're now supposed to just use ES6 destructuring defaults. Apparently that still exists for classes, because you can't destructure anything there. There's also been a couple interesting changes on the build tooling side. So, one that I have a personal vested interest in.
-
-[19:37] Early last year, I had done a lot of work to modify React's build pipeline to generate source maps, because React had never shipped with source maps. That meant that any time there was an error message in production, you got a totally unreadable stack trace. And, if you were in the hopefully rare situation of needing to debug and step out of React, like outside of a function component and into the React bundle, well, React's source code is hard enough to read.
-
-[20:09] In its original form, once it's been bundled and minified, it's literally completely unreadable. And for companies like Replay that care about source maps and debugging, that was a problem for us. So I'd done the work last year to add source maps to React's build pipeline. So, in an interesting twist, a week or two ago, Andrew Clark removed my changes from the build pipeline BECAUSE React is no longer going to ship pre minified bundles.
-
-[20:38] Now, to understand some of this, React has always used a very advanced minifier called the Google Closure Compiler. It's like Terser, but much, much more powerful. And it is like the best tool for optimizing and minifying JavaScript bundles, and they wanted to shrink it as much as possible and like really do a good job of inlining functions to make things fast.
-
-[21:01] So when I did the source map work last year, I was capturing a copy of the source code right before it went through closure. But, that didn't have some of the other optimizations that Closure does besides the final minification step. So, what they've done is they've dropped shipping source maps and they've stopped pre minifying the bundle, but they are still doing the optimization and inlining step with Closure. So, in the future, as a, or actually as of the latest beta, what's in the bundle is no longer react dom. production. min. js, which is what it's always been, but rather a react dom. production. js that's still like 500k, un minified, but it's got all the source code optimizations applied.
-
-[21:52] So, your application build step will now do the final minification process out of that. One other interesting side effect here is that if you look at this, strictly speaking, actually ReactDOM. production is now like a six kilobyte file. And this is unexpected. And in fact, if you look at BundlePhobia for ReactDOM 19 beta, it thinks that ReactDOM is now only six, like, like three and a half K minified.
-
-[22:19] Which is clearly not the case, and it's because the Reconciler logic is now in a separate file, React dom client . If you think about writing web apps now, ever since React 18, when we switched over to the new CreateRoot method, that comes from the react-dom/client entry point. So, they've re architected the bundles so that the bulk of the code is in that slash client file, and because of that bundle phobia, it doesn't actually trace through and connect the dots to see that both these files end up getting used in a real app.
-
-[22:55] Finally, a couple other bits that are stirring up some controversy. So a couple of years ago, the React team announced that they were patching the fetch method in order to allow caching in case, you know, multiple components are trying to make similar requests on the server side.
-
-[23:09] And many people got pretty justifiably angry about this because we learned back in the mid tens, patching global objects in JavaScript is a really bad idea. So the React team has finally given up on that and they've reverted those changes for the final release. And they've said. If you want to make sure you're deduplicating requests, wrap your request logic in the cache method.
-
-[23:32] Which makes it really ironic that Andrew Clark just tweeted today that they might actually end up patching the date object down the road in order to prevent hydration mismatches. I don't know. I understand why he says that. I am not sure this is a good idea. I don't have a better solution. So, we'll see how this one pans out.
-
-[23:53] **Carl Vitullo:** Yeah, I am empathetic to that. And he does talk about, as long as it's standards compliant, nobody has cared about patching internals, people haven't complained about polyfills, and dates are such a pain in the butt when you're doing hydration. Just, you know, it's so easy to have them accidentally rely on current time, which then causes a hydration warning and is just super annoying.
-
-[24:14] So I can understand the motivation for doing it, but yeah, agree, it's, you know, patching stuff is scary, it's risky.
-
-[24:19] **Mark Erikson:** So we've got a beta out, and I actually was not even expecting a beta this soon. I did not expect that we would see a beta for another couple weeks, and it would actually be announced at React Conf.
-
-[24:31] I do not expect a React 19 final at React Conf. I could be surprised, but the fact that it's only been in beta for a couple weeks, Plus, I'm still seeing lots and lots of PRs flying through in the React repo. I, I would not expect React 19 final for at least another three or four months, but I have no specific info on that either way.
-
-[24:54] **Carl Vitullo:** Yeah, I also want to call out a couple of other less conceptual changes, they seem a little bit more like pragmatic, use the platform kind of adjustments. React 19 adds support for document metadata directly in rendered React output. Previously, this is the sort of thing that you would use a tool like React Helmet to render.
-
-[25:14] You know, if you're putting document metadata, title, link, meta tags, stuff that normally lives in the head. Part of your HTML. Now React is adding support for rendering that pretty much anywhere. And then React will do the work to figure out that it needs to go in the head, and putting it there at all. That's pretty interesting. I have been routinely let down by React Helmet, which it just has a lot of bugs.
-
-[25:39] It was one of the first open source React libraries that I ever remember coming across like way back in 2013 14. And it was written by the NFL, which always struck me as like, what? The NFL? So it Great name, like the NFL putting out something that renders to the head and calling it helmet is just like, oh my God, that is the perfect name.
-
-[26:01] So I love that. But then I just, oh man, I ran into so many weird bugs and edge cases every single time I tried to use it, which often I ended up compromising on behaviors because it just didn't work and there was no viable alternative. So excited to see. First party support for that without having to use a janky out of date library from eight years ago.
-
-[26:21] So that's nice. Kind of related to that, so, you know, keeping the theme of dumping stuff in your rendered output, they're also adding better support for style sheets in rendered output. They call this out in the release page saying, Style sheets require careful positioning of the DOM due to style precedence rules.
-
-[26:38] And I guess this is going to be a little bit related to the patching platform things. They've got a precedence prop on these link tags. So you know, so not only can you now render link tags in your output instead of having to figure out how to put them in your head, then you can just put them in your rendered output anywhere, signal what level of precedence they should have, and React will do the work to figure out.
-
-[27:04] Where it should live. Interesting. Seems to unlock a lot of new ways of using CSS in your React projects. It strikes me that it may inspire a new wave of, like, maybe not CSS in JS libraries, but may inspire new ways of Making use of CSS from your React components, of scoping your styles to your logic.
-
-[27:29] Definitely find that interesting. And another slightly related feature is the port for async script tags they talk about. Previously it was considered kind of, actually I don't know that I ever saw enough discussion of this to say considered an anti pattern. Just didn't feel right to render a script tag from your React component like you're already in JavaScript.
-
-[27:48] Why would you then load more JavaScript from your rendered output of your component? It feels weird, but they're calling out support for async scripts normal. They say normal scripts and deferred scripts, load and document order, which makes rendering these kind of scripts deepen your component tree challenging, you know, that's kinda the problem I was articulating there in React 19.
-
-[28:05] We've included better support for async scripts by allowing you to render them anywhere in your component tree without having to manage relocating and duplicating script instances. So, that's, again, a little bit interesting. I can imagine, I have run into situations where using React is maybe not the best tool for a specific type of UI.
-
-[28:25] You know, like, things like A complex map, or a highly complex and interactive data visualization, or there's a lot of things that you might want to render to like a canvas, or to WebGL, or in an iframe, or things like that, where React either can't do it because of security limitations, or because, you know, you can't render A component in WebGL or Canvas.
-
-[28:50] So there are circumstances where I've either bailed out of using React and just said like, Nope, everything inside this component renders once, and then some other script takes over for it. So in circumstances like that, I could see this being a significant experience improvement. And again, building on that, they're also adding support for preloading resources.
-
-[29:09] So the React DOM package now exports a couple of new, I guess I'll call them helper functions, listing them here. PrefetchDNS, Preconnect, Preload, and Preinit, which are similar to like the link or meta tags. You give it a URL and. Sort of a configuration object, and it signals to React that you will want these assets, but not right now.
-
-[29:30] It's not like rendering out a style tag or a script tag, but it's saying, here's a resource. I want you to resolve the DNS, or connect to the resource, but don't start loading it yet, or start loading it, but don't start parsing it yet. So it looks like a lot finer grain control over external resources.
-
-[29:49] So combined with greater level of control over how resources get loaded, and then clearer, simpler semantics around taking those resources and rendering them from a component, It does seem like it unlocks a lot of really powerful behaviors. I think it's going to introduce some churn into the ecosystem, but I can at least see, I have run into a lot of problems where I can see this set of tools being a pretty big unlock.
-
-[30:17] So excited to see it.
-
-[30:18] **Mark Erikson:** And then one more item that's all the way down at the very bottom of the beta release notes is support for custom elements aka web components finally work properly inside of React. I've never used web components. I've tried to read the threads that have had hundreds of comments and complaints.
-
-[30:40] I have a vague partial sense of what the problem space is. In general, like with React, we pass props and we pass real JavaScript values, objects and numbers and whatever. But with web components, there's the issue that, you know, like there, there's something about the attributes versus properties distinction.
-
-[30:59] Like HTML is you're defining attributes that are strings. DOM objects have properties that can be mutated and these are not always the same thing. So like you, you can't just always directly pass real objects into a custom element, the same way we would pass a prop from a parent to a child in React.
-
-[31:21] And there's been like a whole bunch of other interop issues trying to render web components inside of a React component and pass data and handle events between these. And so the web components community has complained for years that, well, every other UI framework manages to make this cooperate. Why can't React do it?
-
-[31:43] it's a reasonably fair complaint, but there'd been an issue filed all the way back in like 2016, 2017 saying, so React, are you finally going to make this just work? And it took another four or five years before an engineer from Meta actually sat down and implemented it. Now, apparently part of the problem.
-
-[32:02] It was unclear what the exact behavior semantics should be. I guess there is no single specification for how Web Components define, like, what kind of event props they take. And a lot of questions about the exact mechanisms for passing Props from a React component to a web component. So like the React team's like, well, okay, there's like a half dozen ways we could do this, and these are kind of mutually exclusive.
-
-[32:27] We're not the experts here. How would the web component community like us to build this? And everybody had very different opinions. So that was part of the reason why this took multiple years to happen. But, eventually, there was some adequate kind of consensus reached, and so a meta engineer actually went in and did a ton of work, a couple massive PRs to implement the support, and it got merged, like, two years ago, but it was always in, you know, under a feature flag, just in the experimental branches.
-
-[32:56] So, React 19 now finally ships with, quote, proper support for web components, and all three people who care cheered.
-
-[33:06] **Carl Vitullo:** Well, one of them is in the chat here, definitely interesting, I don't know. Like you said, I've been loosely paying attention to it for years at this point, and generally loosely paying attention to web components for even longer than that, and Cool.
-
-[33:18] I don't know. Good to see. I will continue to loosely pay attention to see what kind of effects it has on the ecosystem, but I'm a little bit skeptical it's gonna make big waves.
-
-## React Native 0.74.0
-
-[33:29] **Carl Vitullo:** Cool. Okay, React Native. They have officially released their 0. 74 version, which is gonna be I actually talked to someone when I was at React Miami about some of the work they've been doing.
-
-[33:40] So the, the One of the things included in this is Yoga 3. 0. Yoga is the Flexbox layout engine re implementation that powers React Native. It's, it's one of the core technologies that facilitated React Native approximating web layout. And I had, I had spoken with someone at React Native who said that it took them a long time to sort of spin back up on development, you know, some internal priorities and, people moving, they lost some expertise on that. So they had to reinvest, re relearn how to develop it.
-
-[34:15] So cool to see that in here. It looks like it fixes a couple of layout bugs that were, you know, non standard. They were different from the semantics on web. It was something about. Like, you know, row reverse columns with like start and end edge was not behaving correctly previously, and now it is. So you may find some weird margins.
-
-[34:34] They're also removing a tool called Flipper by default. You can still add it back in. Inspecting React Native layouts, network requests. Uh, it sounds like it has a lot of overlap with the React Dev tools in, browsers. Uh, it was deprecated in 0. 73. Thank you, Cedric and chat. And is now being removed by default.
-
-[34:52] **Mark Erikson:** I'm very curious what the debugging story is. As usual, I have not worked on React Native. I don't know what the debugging process is overall.
-
-[35:00] But if they're removing Flipper, I'm curious what the intended workflow is for debugging tools. And I see someone says Chrome DevTools.
-
-[35:07] **Carl Vitullo:** Yeah. I think when I was using React Native, this is now close to three years out of date. I believe I was already using the Chrome DevTools at that point. So it sounds like this shouldn't be too impactful on too many people.
-
-[35:19] Yeah. Community CLI for React Native, I guess, to make an analogy, sort of the create React app for React Native is now. Using Yarn 3 for new projects by default. So that's a reasonably opinionated change. I know that Yarn 3 has very different semantics from Yarn 2.
-
-[35:38] **Mark Erikson:** My, I would assume that they're going with Yarn's node modules behavior by default rather than the attempt to do the plug and play, don't extract everything on disk approach that Yarn 2 tried and failed to get out there.
-
-[35:52] **Carl Vitullo:** Can confirm using node-linker/node-modules.
-
-[35:55] **Mark Erikson:** I actually got to meet the primary maintainer of Yarn, Emil Nusson in Paris.
-
-[36:00] We talked a bit about, you know, where Yarn stands. Like Yarn 4 is out, but apparently kind of, Came out a little past, you know, whatever preparation deadline the React Native team had for trying to figure out things on their end. I don't think there were too many big changes between Yarn 3 and Yarn 4, but it is interesting.
-
-[36:18] You know, we mentioned earlier that, you know, PNPM has gotten a lot of popularity. And so, like, a segment of the ecosystem is going to be pretty, you know, pretty much set on Yarn 3 for the foreseeable future.
-
-[36:30] **Carl Vitullo:** Whoa, I consider myself a Yarn user, and I didn't even know they had a version 4. 0. Looks like it was released in October of last year. Interesting. Cool.
-
-[36:38] React Native Navigation version 7 is out, which looks like some of the major improvements there are around the configuration of it. Previously, talked about how previously there were of difficulties with Types, and basically you needed to keep your types manually synced with your route configuration.
-
-[36:57] So it looks like they've made some general architecture improvements, such to where TypeScript types can now be inferred from the root navigator with a static param list type, and it'll be available anywhere UseNavigation hook. So that's cool. Needs a, like, one line script. Global namespace adjustment in TypeScript in order to enable.
-
-[37:16] But that seems like a really big improvement. Type support in your navigation is definitely a lot more safe. So that's really good. And last React Native thing I'll do is just a small shout out. There's a Vision Camera package that just released a 4. 0. Looks like it supports a lot of Powerful camera stuff, you know, like QR codes and like some other visual recognition stuff.
-
-[37:41] looks like a really cool project and definitely some big React Native relevance.
-
-[37:46] **Mark Erikson:** On the note of React Native, I was at a React Connection and React Native Connection conference in Paris last week.
-
-[37:53] And I've always been a web dev, but it was interesting to me just sitting through the React Native talks and half of the material was familiar, half of it was like a completely different ecosystem that I'd never heard of. It was very interesting to see how there's just this entire different branch of the React ecosystem that I basically didn't almost even know existed in terms of mindset and what they're dealing with.
-
-## Kotaken, RSCs with just Bun
-
-[38:17] **Mark Erikson:** So, rolling through a few items very quickly. A new experimental server component framework that I had never even heard of until I saw it pasted in the links like an hour ago called Kotaken. And the interesting sales pitch here is what would a React framework look like if Bun we re the only tool in the tool chain.
-
-[38:37] This sounds very interesting in a lot of ways. Certainly the tool setup makes it sound like it's a lot simpler. It sounds like it has some interesting variations in how they're trying to use server components. I assume based on the description that it's brand new and highly experimental, but you know, another example of playing with the baseline ideas of server components and seeing how a different framework makes different choices around it.
-
-## Bun 1.1
-
-[39:02] **Mark Erikson:** On that note, Bun 1. 1 is out and it actually has Windows support. And as the, you know, the 1 percent of web developers who is actually a Windows user, cool. Yay. I'm excited by this. I actually played with Bun briefly on a very small work project a couple of weeks ago.
-
-[39:19] I was trying to prototype some SQL changes and Bun has SQLite support built in. So rather than try and mess with Postgres adapters or whatever, I just used that and it ran, it worked. I don't have further experience to report on, but I'm very excited to see BUN support getting fleshed out.
-
-## JSR, by Deno
-
-[39:37] **Carl Vitullo:** I wanted to talk about JSR, the JavaScript registry being put out by the Deno team. New registry is pretty interesting to me. We've seen a lot of experimentation in package managers, but ultimately all of them still hit NPM.
-
-[39:52] And the Deno team was talking a little bit about how that's a bit of a shame. We've had so much experimentation happening, but so little of it happening At that level, where a lot of behaviors are ultimately driven from. A couple of notable changes that they've done, this is ESM only, which is definitely going to be a pretty big level up for React. The ecosystem as a whole, I think, just, you know, ESM versus CommonJS has been such a pain for so long. I think a clean break in a new package registry might be a bit of a kick in the pants, as it were, just to kind of force the issue and say like, nope, clean break, new stuff.
-
-[40:33] They do say that JSR is backwards compatible with NPM, so that should facilitate migration at least. Obviously moving to a whole new package registry is a bit of a tough sell. Maybe not as tough as something like switching from Angular to React. As it were, but I think it's, I think it's up there. You know, if you are trying to use a new registry, but like, oops, there's no express, like that's just pretty hard.
-
-[40:58] A lot of the assumptions that you have about what open source code is going to be available. It may not be available. So I think that's going to be a little bit tough. They also said some interesting stuff like TypeScript has emerged as not only a way to write JavaScript with compile time type checking, but as a test bed for the latest JavaScript language features coming out of TC39.
-
-[41:17] That rang really true to me. So seeing a team push the boundaries of something as, you know, maybe a little bit esoteric and like less thought of as a package registry is, I don't know, I appreciate that they are also following the cutting edge Broadly across the rest of the ecosystem as well. They talk about Node is no longer the only relevant JavaScript runtime outside the browser.
-
-[41:40] Some other really cool stuff. I think something I saw was package provenance through a tool called SIGstore, this is sort of like, Supply chain attacks, if you're familiar with that, where how do you know that the code you believe you're installing on NPM is actually what you expect?
-
-[41:58] So provenance is dealing with that sort of end to end guarantee that something is what it claims to be. There have been a couple of notable Vulnerabilities, actually not even vulnerabilities, just straight up attacks where an open source project solicits a new maintainer, has malicious intent and publishes some kind of script, some kind of backdoor.
-
-[42:19] You know, whether that is trying to attack the end application that is consuming the library, or I think more frequently they have been attacking developer machines to then try to gain access to other parts of the system. I know there was a notable example a couple of months ago. Maybe years at this point ago, where somebody installed a crypto miner into a install script.
-
-[42:42] So people's developer laptops started mining crypto for them. So all that to say, package provenance as a core part of the package registry, I think is a really important area to explore. And contrasting something like package provenance Verifying contents with the, I would say, kind of failed attempt NPM did of doing like NPM audit.
-
-[43:05] You know, that was so unsuccessful that like Dan Abramov put out a post talking about how it was broken by design, like just the fundamental assumptions it made about security and how you address security issues being so wrong as to be harmful.
-
-[43:18] I have a reasonably high degree of confidence in the Deno team generally. You know, it's a project started by Ryan Dahl, who created Node in the first place. So having him come back and say, I got some things wrong. I'm going to try again in a new context with Deno. And then now expanding that into, I think that The Node ecosystem got some things wrong with how packages work.
-
-[43:40] I'm going to try that again. I think that's very exciting. I am not going to immediately jump on it and start using it for everything, but I am going to be paying pretty close attention because I think this is a serious attempt at a very complex and large problem space. Let me just run through a couple of guarantees, expectations that the JSR team has put out.
-
-[44:02] As for what a package manager should do, they say it should embrace ESM as the web standard for JavaScript modules, should be designed for TypeScript from first principles, should be simple, fast, provide excellent developer experience, should be free and open source and work anywhere that JavaScript does, and should build on the success of NPM, not fork it.
-
-[44:20] Seems pretty good. There's a couple other really good posts that I'm just going to dump in chat here. Those will be in the show notes as well. Some other things that I think are important, every module must be scoped, which I think is a positive change. It's always a little bit funny, you know, on NPM modules that don't have a scope feel somehow more official in some way.
-
-[44:39] It's so just requiring that all packages are scoped kind of eliminates that funny little. Bifurcation in the ecosystem. Like, is it scoped or is it not scoped? It also has a concept of multiple scopes per account. I saw a mention of four scopes per account as a limit. So being able to manage different scopes without having to set up like a dummy account, which I believe is how that has to work on NPM.
-
-[45:02] It's been a while since I've had to deal with that myself, but that seems like a really good idea. Interesting, useful, evolution of the ecosystem.
-
-## ⚡️ Why I like React (Even in 2024) ⚡️
-
-[45:09] **Mark Erikson:** And then hitting a couple of the lightning items really fast. We've commented how there's been a whole series of articles and tweets and complaints about, you know, being, people being frustrated with. React as a technology, based on the slow pace of development, or, you know, poor communication from the React team, or, you know, React just doesn't feel as modern as other frameworks that are adopting things like signals, etc.
-
-[45:36] And so, I thought this post on why I like React in 2024 was well written, and just a decent alternative train of thought to some of the negative chatter.
-
-## ⚡️ Netlify updates their Next.js runtime ⚡️
-
-[45:46] **Carl Vitullo:** Netlify put out a blog post introducing a new Next. js runtime, which I was pretty surprised about.
-
-[45:52] I think of Netlify as a static site host. When I think Netlify, I generally think Buildstep. Static assets, essentially static HTML and JavaScript served by a CDN. So seeing them talk about a runtime for a framework that I consider to require a server, it's pretty interesting to me. That seems like a pretty large evolution in their product offering in a pretty interesting way.
-
-[46:18] And. You know, Vercel's level of influence on React and it's coupling to the cloud runtime environment has been a little controversial to say the least. So seeing some more competition there is definitely pretty interesting. I guess relevant to that, I also saw somebody wrote a blog post discussing how Cloudflare is the best alternative to React.
-
-[46:40] Vercel, which I'll share as well while we're talking Vercel competitors. Definitely interesting. I guess this is not a new thing from Netlify. They say this is Next. js runtime version 5, so definitely pretty cool. Supports the app router, fine grain caching, on demand and time based revalidation. Oh, maybe a big one.
-
-[46:59] This is a problem that I've run into on Netlify using Next. They now support the Next image component. By default, so being able to optimize your images automatically through the next image package is definitely a pretty big, like, performance and user experience win. So that seems pretty good.
-
-## ⚡️ Design Principles behind the Next.js App Router ⚡️
-
-[47:18] **Mark Erikson:** There was also a really good tweet from one of the Vercel devs, I think just like a day or two ago, talking about design principles behind the Next. js app router. And frankly, it was an extended length tweet that really was a miniature blog post, and it talked about some of the ideas that it's really about layouts. and being able to identify which pieces of the page need data and which can be pre cached. And the fact that they actually don't expose things like the request object directly so that they can better detect which pieces could be cached versus which pieces have to be fully re rendered on the server side.So, whether or not you like the approach, it's clear that they've put a lot of actual thought into it. .
-
-## ⚡️ Node.js website redesign ⚡️
-
-[48:04] **Carl Vitullo:** I saw a blog post from Node. js about their website redesign. I thought this was a fun, technical write up to white paper, relevant to a lot of, relevant to our jobs. You know, like we do lots of website redesigns. I thought it was pretty cool. Just to see, you know, they talk about a failed attempt at restarting it with a nodejs.
-
-[48:25] dev domain. In retrospect, this might have unintentionally doomed the project from the start. Yeah, it seemed like a really good breakdown of the technical challenges and organizational struggles of Doing a major website overhaul. So yeah, definitely check that out. They talk about reassembling the airplane while in flight. Always a fun metaphor.
-
-## ⚡️ Dives into React features ⚡️
-
-[48:44] **Mark Erikson:** There's a website I've run across that has been doing a whole series of dives into the actual React codebase and picking out specific features like the new Use Optimistic hook. And talking about how they actually are implemented in React.
-
-[48:59] And one of React's strong points has been that it is a black box and you don't need to know how it works internally to be able to use it. You need to understand the mental model of the data flow. But you don't have to dig into the code and worry about the actual implementation details. But, I frequently see people asking, how does such and such a feature in React work?
-
-[49:20] And so I appreciate that the person behind this site has been doing dives into the codebase to try to explain things.
-
-## ⚡️ Honeypot releases Node.js documentary ⚡️
-
-[49:27] **Carl Vitullo:** The people behind the React. js documentary, Honeypot. io, which I believe is a recruiting platform, put out a documentary on the origins of Node. js. I haven't been able to give it a watch yet, but their React. js documentary was. Very good. Got to watch that at, on the big screen at React Miami last year, and I got a chance to speak with the filmmaker who put it together, who did all the recording, and found her very impressive. She's very skilled. So definitely check that out.
-
-## ⚡️ Flow ships React features ⚡️
-
-[49:56] **Mark Erikson:** The flow type system, which was a competitor to TypeScript and then in a sense, basically died outside of Facebook like three or four years ago, because the flow team didn't ship often and they didn't really, frankly, care about the community, has still been working on things and they recently announced some new language level features for React components. I think we might've touched this briefly last time, but they've added some actual syntax for defining components and prop types in React, which is interesting
-
-## ⚡️ Vercel updates pricing ⚡️
-
-[50:26] **Carl Vitullo:** Another small update, Vercel is cutting prices a little bit, or they are updating their Infrastructure pricing, which they expect to reduce costs for most users. So, cool. Looks like it's not a major alteration. It's not going to be like an order of magnitude fix, but it's include some like finer granularity on bandwidth costs.
-
-[50:48] So instead of per hundred gigabytes of bandwidth, it's per gigabyte. Well, which should help a lot. I saw it discussed, you know, if you use 105 gigabytes of bandwidth, now you'll be billed for 105, not 200. So a couple of little things like that. I saw some chatter about a limited number of people who had costs shoot up quite a bit, but that seems to be relatively rare.
-
-[51:11] if you have a very particular performance characteristic on how you're using the Vercel platform, it may not be a big cost savings, but it just, you know, as I was reading these, as they're breaking down the price changes, it looks generally like I would expect it to reduce costs.
-
-## ⚡️ RedwoodJS compares data fetch methods ⚡️
-
-[51:28] **Mark Erikson:** And then finally, the last one I'll mention is the Redwood JS, which we mentioned earlier, you know, had originally been focused on using GraphQL to define data fetching needs for React components.
-
-[51:40] And over the last year, they've been doing work to adopt server components. And they just put up, they put up a blog post that. Showed some comparisons in data fetching between the next AppRouter, the next PageRouter, Remix, and Redwood. there are some variations in how the tools work and some of the trade offs. I always appreciate posts that actually try to cross compare things.
-
-## ⚡️ Kuto, reverse JS bundler ⚡️
-
-[52:02] **Carl Vitullo:** I saw a neat project called Kuto. They called it a reverse JavaScript bundler. And it's around reusing your code as you're shipping updates to your application. This is something I've thought about a number of times at different companies I've worked at, but never made any significant headway on actually addressing.
-
-[52:22] You do a production build, you produce your new set of bundles, you upload those to the, to your production server. And you know, like most of that code didn't actually change. Like presumably just made, A bunch of small alterations. Like, I can't imagine that any new production release affects more than like, what, like one to five percent of your overall code?
-
-[52:43] Maybe even less when you start including dependencies and, you know, vendored code. So it looks like this is trying to sort of do a diff, kind of ship a diff on production releases, which is super cool. Like, if you can Do a new production release and know that much of the code that didn't change is still going to remain cached by your existing users, then that seems super cool.
-
-[53:06] They say, you know, just really quick, like first line of the page, for a real world site with three megabytes of JavaScript, updating the React dependency resulted in a 71 percent smaller download and a 28 percent faster startup time on an old phone. So I don't know exactly what the process of using this tool looks like, but.
-
-[53:24] Seems like a pretty compelling performance improvement. Reverse JS bundler, new category of infrastructure maybe.
-
-[53:31] That's everything I got, thank you everyone for joining us. We'll be back at the end of this month because we're recording late. We record on the last Wednesday of every month here in the live stage of Reactiflux, and we'll try to get back in your pod feed as soon as we can after that.
-
-[53:45] We gather sources from This Week in React by Sebastian Lorber, from Bytes. dev, Reactstatus, React JS Weekly, react Digest, the React JS subreddit here in Reactiflux, and direct from people publishing articles. If you see anything newsworthy, definitely let us know in the #tech-reads-and-news channel in Reactiflux, or you can email me directly at hello@reactiflux.com. Send that with TMIR in the subject line just to help me find it. It's an acronym for the show.
-
-[54:13] I read literally every email that comes in, usually even the ones that are marked as spam, so if you send me an email, it'll go in my brain.
-
-[54:20] If this is a show that you get value from and want to support, best way to do so, share it, send it to your co workers, say, hey, this seems like a really useful way to stay on top of everything.
-
-[54:29] And if you could leave us a review on Spotify or whatever platform that you listen on, that would be super helpful as well. I'm also seeking sponsors for this. I'm trying to professionalize. I've got a new logo. Looks all nice and fancy. If you are interested in getting your product or company in front of a group of professional React engineers, definitely reach out.
-
-[54:50] Thanks so much. Talk to you next month.
diff --git a/src/transcripts/tmir-2024-05.md b/src/transcripts/tmir-2024-05.md
deleted file mode 100644
index ae67c12..0000000
--- a/src/transcripts/tmir-2024-05.md
+++ /dev/null
@@ -1,640 +0,0 @@
----
-title: "This Month in React, May 2024: Updates from React Conf"
-date: 2024-05-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-
-
-- [9600 laid off from 36 companies](https://layoffs.fyi/)
-- New releases
- - [[02:07](#docusaurus-33)] [Docusaurus 3.3](https://docusaurus.io/blog/releases/3.3)
- - [[02:17](#mantine-790)] [Mantine 7.9.0](https://mantine.dev/changelog/7-9-0/)
- - [[02:30](#astro-48)] [Astro 4.8](https://astro.build/blog/astro-480/)
- - [[03:18](#redwood-75)] [Redwood 7.5](https://github.com/redwoodjs/redwood/releases/tag/v7.5.0)
-- [Upcoming conferences](https://react.dev/community/conferences)
- - [[03:32](#render-atlanta)] [Render ATL](https://renderatl.com/) June 12-14, 2024. Atlanta, GA, USA
- - [[03:53](#future-frontend)] [Future Frontend](https://futurefrontend.com/) June 13-14, 2024. Helsinki, Finland
- - [[04:49](#react-norway)] [React Norway](https://reactnorway.com/) June 14, 2024. Larvik, Norway
- - [[05:01](#react-summit)] [React Summit](https://reactsummit.com/) June 14 + 18, 2024. Amsterdam, Netherlands (+remote)
- - [[05:15](#react-nexus)] [React Nexus](https://reactnexus.com/) July 4-5, 2024. Bangalore, India
- - [[05:43](#chain-react)] [Chain React 2024](https://chainreactconf.com/) July 17-19, 2024. In person in Portland, OR, USA
- - [[06:12](#the-geek-conf)] [The Geek Conf](https://thegeekconf.com/) July 25, 2024. Berlin, Germany
-- [[06:53](#react-conf-recap)] [React Conf recap](https://react.dev/blog/2024/05/22/react-conf-2024-recap)
- - [Livestream recording](https://www.youtube.com/watch?v=T8TZQ6k4SLE) (165k views 🤯)
- - [Seth Webster's mentioned thread](https://twitter.com/sethwebster/status/1792739000366809363)
- - [[08:21](#react-19-rc)] [React 19 RC](https://react.dev/blog/2024/04/25/react-19)
- - Talks:
- - [What’s new in React 19](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=8880s) by [Lydia Hallie](https://twitter.com/lydiahallie)
- - [React Unpacked: A Roadmap to React 19](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=10112s) by [Sam Selikoff](https://twitter.com/samselikoff)
- - [[09:44](#server-components-on-expo)] [React Server Components Demo on Expo](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=20765s) by Expo Team
- - [[12:12](#react-for-two-computers)] [React for Two Computers](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=18825s) by [Dan Abramov](https://twitter.com/dan_abramov2)
- - [[15:46](#qas-with-react-and-react-native-core-team)] [React Q&A](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=27518s) hosted by [Michael Chan](https://twitter.com/chantastic)
- - [React Native Q&A](https://www.youtube.com/watch?v=0ckOUBiuxVY&t=27935s) hosted by [Jamon Holmgren](https://twitter.com/jamonholmgren)
- - [[16:33](#react-compiler)] [React Compiler](https://react.dev/learn/react-compiler)
- - [Compiler playground](https://playground.react.dev/)
- - Lauren Tan’s [walkthrough of using the compiler and seeing the output](https://www.youtube.com/watch?v=T8TZQ6k4SLE&t=18825s), and Sathya + Mofei’s [deep dive into how the compiler works](https://www.youtube.com/live/0ckOUBiuxVY?si=yK4-4Ph_tm91zO8V&t=9303)
- - [Jack Herrington’s compiler walkthrough](https://www.youtube.com/watch?v=PYHBHK37xlE)
- - [Recommended for library authors to ship compiled artifacts](https://twitter.com/_gsathya/status/1792968851212169441)
- - [A talk from Lauren Tan in 2016](https://speakerdeck.com/poteto/embercamp-2016-i-can-write-my-app-with-no-handlebars-declarative-templating-in-ember) that’s spiritually related to React Compiler
- - [[23:39](#remix-is-merging-back-into-react-router)] [Merging Remix and React Router](https://remix.run/blog/merging-remix-and-react-router)
-- [[28:08](#effect-js)] [Effect](https://effect.website/blog/effect-3.0)
- - [Great 10 min intro](https://www.youtube.com/watch?v=SloZE4i4Zfk)
- - [Production-Grade Typescript talk](https://www.youtube.com/watch?v=PxIBWjiv3og) at an event they hosted
-- [[34:23](#forensics-of-react-server-components)] [The Forensics Of React Server Components](https://www.smashingmagazine.com/2024/05/forensics-react-server-components/)
-- [[35:39](#nextjs-v15-rc)] [Next 15 RC](https://nextjs.org/blog/next-15-rc) ([tweet](https://twitter.com/nextjs/status/1793670209443680382))
- - Unrelated: [Vercel raised $250m](https://www.reuters.com/technology/vercel-completes-250-mln-series-e-round-325-bln-valuation-2024-05-16/)
- - [[37:05](#its-not-just-you,-nextjs-is-getting-harder-to-use)] [It’s not just you, Next.js is getting harder to use](https://www.propelauth.com/post/nextjs-challenges)
-- React Native:
- - [[39:21](#react-native-new-architecture-beta)] [“New Architecture” is now in beta](https://github.com/reactwg/react-native-new-architecture/discussions/189)
- - [[40:25](#expo-is-now-the-recommended-framework)] [“useFrameworks”](https://reactnative.dev/docs/environment-setup) - Meta announcing that you should use Expo by default.
- - [[41:17](#react-native-skia-on-webgpu)] [React Native Skia](https://www.youtube.com/live/s0wn7qpBoB8?si=HDsihzf803fTLlIc&t=2802) updates
- - [[43:39](#react-native-ide)] [React Native IDE](https://ide.swmansion.com/):
- - [[45:03](#react-native-on-tvs)] [Amazon doing a keynote talk on using React Native for TV](https://conf.react.dev/talks/14) and other devices.
-- [[48:04](#lightning-round)] ⚡️ Lightning round ⚡️
- - [[48:07](#speculation-rules-api-in-chrome)] [Speculation Rules API](https://developer.chrome.com/blog/speculation-rules-improvements) in Chrome
- - [[48:33](#josh-comeaus-post-on-usedeferredvalue)] [Snappy UI Optimization with useDeferredValue](https://www.joshwcomeau.com/react/use-deferred-value/)
- - [[49:24](#bluesky-engineering-culture)] [BlueSky Engineering Culture](https://newsletter.pragmaticengineer.com/p/bluesky-engineering-culture), from The Pragmatic Engineer
- - [[50:16](#why-patching-globals-is-harmful)] [Why Patching Globals is Harmful](https://kettanaito.com/blog/why-patching-globals-is-harmful)
- - [[50:54](#new-webkit-features-in-safari-175)] [Webkit features in Safari 17.5](https://webkit.org/blog/15383/webkit-features-in-safari-17-5/)
- - [[53:56](#why-react-query)] [Why React Query?](https://ui.dev/why-react-query) (and upcoming React Query course)
- - [[54:45](#we-can-have-a-different-web)] [We can have a different web](https://www.citationneeded.news/we-can-have-a-different-web/)
- - [Athena Crisis is now open source](https://cpojer.net/posts/athena-crisis-open-source)
- - [Security Risks of Postman](https://www.leeholmes.com/security-risks-of-postman/)
- - [Angular v18 is now available!](https://blog.angular.dev/angular-v18-is-now-available-e79d5ac0affe)
-
-**Carl Vitullo:** Hello everyone. Thank you for joining us for May's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. We have so much news this month because there was ReactConf and so many of the things that we had been discussing over the last three or four months actually like dropped and landed. [00:23]
-
-And are available and there are eight hours of talks discussing all of the things that we have been like punditing and talking heads about direct from the source. So I am excited about that. We're going to dig into it. [00:34]
-
-But first, I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux, where I run community programs like these and build tools to help keep the community running. [00:44]
-
-Before I hand it off to Mark I'm gonna hand it off first to our new guest host for the month where it's a bit of a trial. [00:50]
-
-**Mark Erikson:** I think he's gonna do fine! [00:51]
-
-**Carl Vitullo:** Mark, thank you for introducing me to our new guest host! Do you want to introduce yourself? [00:56]
-
-**Mo Khazali:** Nice to be here with you all. So my name is Mo. I head the mobile team at Theodo and I've been sort of an active part of the React and React Native ecosystem for a few years now. And I help organize some meetup groups like the React Native London meetup and have here and there dabbled in some open source contributions within the ecosystem with libraries like Expo and Tamagui. [01:16]
-
-Very happy to be here with you all and looking forward to chatting all things React Native. [01:20]
-
-**Carl Vitullo:** Awesome. Thanks for joining us. [01:21]
-
-**Mark Erikson:** And I'm Mark Erikson, my day job is working at Replay. io, where we're building a time traveling debugger for JavaScript. And outside of Replay, I do Redux stuff. [01:30]
-
-**Carl Vitullo:** Some quick hits before we get into the main news. [01:33]
-
-## Layoffs news
-
-**Carl Vitullo:** Quick layoffs overview from layoffs. fyi. This month, over May, there were 9, 600 laid off. from 36 companies, which is down quite a bit actually from April. last month in April, there were 22, 000 laid off from 57 companies. So that's improving a little bit. So far, this year has been substantially better than last year, but that's not saying very much because last year was like, the worst year in the last 20 years. So improving steadily is still not great. [02:02]
-
-## New Releases
-
-**Carl Vitullo:** Some new releases. It looks like there's been a couple of new releases in sort of the fallout of React 18. [02:07]
-
-## Docusaurus 3.3
-
-**Carl Vitullo:** 3 coming out, there's a Docusaurus just doing a minor release on 3. 3. Nothing too new there, it's basically just like fixing some new warnings that popped up. [02:17]
-
-## Mantine 7.9.0
-
-**Carl Vitullo:** Mantine has also put out a 7. 9. 0 release. Mantine seems pretty cool, I haven't played with it too much myself, I don't play with very many UI toolkits, but this is high on my list of ones to look at. [02:30]
-
-## Astro 4.8
-
-**Carl Vitullo:** There's also Astro 4. 8, which just came out. They're coming out with a couple of new things that look pretty interesting. You know, also like classic performance improvements and bug fixes. They have an experimental Astro Actions, which, you know, okay. We have one more thing in the ecosystem called Actions, which is unfortunate, they pitch it as, "actions make it easy to define and call backend functions with full type safety from your client code." And full type safety on a backend request is wonderful. Happy to see that. That's pretty great. [03:00]
-
-They also have an experimental request rewriting feature. Request rewriting is pretty important on a large production application. It's where you receive a request on one URL and handle it internally as if it was a different URL. So you can do stuff like aliases or rewrites or silent redirects and things like that. [03:18]
-
-## Redwood 7.5
-
-**Carl Vitullo:** There's also Redwood 7. 5. I recently spoke with the Redwood folks at ReactConf and it got, it actually got me a lot more excited about the project. [03:26]
-
-## Upcoming conferences
-
-**Carl Vitullo:** All right, switching into some upcoming conferences. Me and Mo are going to bounce off each other here a little bit. [03:32]
-
-## Render Atlanta
-
-**Carl Vitullo:** In two weeks, I am sad that I will not be able to make it to this one, but Render Atlanta is happening June 12th through 14th in Atlanta, Georgia. [03:41]
-
-Looks like a really great conference. I have heard nothing but phenomenal things from past years, and it looks like a great crew is heading out there this year. So yeah, definitely check it out if you are looking for a conference this month. [03:52]
-
-Yeah, Mo? [03:53]
-
-## Future Frontend
-
-**Mo Khazali:** And just around the same time, so June 13th to 14th, Future Frontend is happening in Helsinki. [03:58]
-
-So that's up north in Finland. And I can personally attest to how good this conference is. It's one of those conferences that has a real community feel to it. You know, 100, 150, 200 people coming. And everyone is super passionate about building front end apps, not just in the React world, but across boundaries. And that means you get some really cool wacky ideas coming up. [04:15]
-
-Last year, someone demoed a talking hamster that was built in JavaScript, which was one of the most wacky and coolest conference talks I've ever seen in my life, and I really enjoyed it. So would definitely give it a shot if you're kind of in Europe and around at that time. [04:27]
-
-**Carl Vitullo:** And I, I believe one of the organizers is, uh, Juho Vepsäläinen. He has been active in Reactiflux from very early on, he used to have a channel himself for his project, SurviveJS. [04:37]
-
-So I, he's been on my radar for my entire career. He seems like a wonderful person. I've never met him in person though. So I'm sad that I also won't be able to fly out to, you know, I can't make the Georgia, so Finland is a bit of a tough sell. [04:49]
-
-## React Norway
-
-**Carl Vitullo:** But that week is a heavy conference month because React Norway is also happening June 14th in Larvik, Norway. I don't know anything about the organizers there. So, can't comment. [05:01]
-
-## React Summit
-
-**Carl Vitullo:** There's also React Summit, June 14th and 18th in Amsterdam in the Netherlands with a remote option as well. React Summit definitely, uh, I've spoken with the organizers in the past and they seem quite great. I have not attended it myself though. [05:15]
-
-## React Nexus
-
-**Mo Khazali:** At the very beginning of July, 4th to 5th of July, in Bangalore, in India, there's React Nexus. Now, last year I had the pleasure of attending React Nexus, and it was such a great community. [05:24]
-
-I gave a talk then and really just an amazing level of energy there. I think it was about four or five, 600 developers all there. And I really felt like there was something unique about it. There was a lot of passion and a lot of drive there and people were just genuinely interested in learning. So really would recommend it if you're kind of near the South, South Asia area to definitely give React Nexus a try. [05:43]
-
-## Chain React
-
-**Mo Khazali:** Around a couple of weeks after that, there's Chain React. So that's July 17th to 19th. That's in Portland, Oregon. Now, I haven't had the opportunity to visit Chain React, but I'm very close with some of the organizers of it, the folks from Infinite Red. I've met them here and there at different conferences, most recently last week, actually, and they are a lovely crew, are a lot of fun, genuinely so much energy and fun, and I've heard nothing but great things about Chain React. So if you're US based and can make it out to Portland, definitely would recommend going to Chain React. [06:12]
-
-## The Geek Conf
-
-**Mo Khazali:** And then a week after that on July 25th, there is the Geek Conf. I happen to know these organizers because they're a key part of the React Native community, the folks from GeekyAnts, and they are hosting a conference in Berlin. So it's the first year that they're doing this and I'll be doing a talk there. So a shameless plug that you should definitely come around and we should hang out. [06:31]
-
-But the Geek Conf is really kind of intersecting web and React Native, which I think is the direction that the ecosystem is going towards. They have some really great lineup of speakers coming around. Folks like Tejas Kumar and Bruno Polino and many others, not including myself there, which I don't consider myself to be a great speaker. So you should come for those folks, and maybe we can hang out in the process as well. [06:50]
-
-**Carl Vitullo:** Let's jump into the main content then. [06:53]
-
-## React Conf Recap
-
-**Carl Vitullo:** Obviously the main subject this month is going to be React Conf. They put up a post on the blog with a React Conf 2024 recap, which is phenomenal. [07:03]
-
-Something I appreciate, they link to the section in the live stream where each of the talks happened. So appreciate that. I feel like so many conferences take weeks to get their conference recordings up. So just leaving the live stream up and linking to the talks. What a solution, it's so good. Something else I found impressive. The livestream recording already has 165, 000 watches. Nope, sorry, since I watched it last night, it's now up to 167,000, which is wild. [07:29]
-
-They open with a recorded bit from the CTO of Meta and then go to Seth Webster, manager of the React team. And he just shouted out on Twitter after the fact, because he was getting some questions about his voice, he apparently had COVID and has had some enduring health effects as a result of complications from that. So I just thought it was really like powerful of him to take center stage, introducing the concept, knowing that that's his experience right now. So, I just wanted to shout that out. He put up a really good, a little explanation of it after the fact. And, I just thought it was really powerful. Wanted to give that a little bit of a signal boost. [08:04]
-
-**Mark Erikson:** Nice to touch on the fact that there are real people with real human concerns involved in building the tools that we actually use. [08:12]
-
-**Carl Vitullo:** Yes, the human aspect of React. But yeah. Let's also dig into some of the technical aspect of React as well. Mark, you want to lead us in here? [08:21]
-
-## React 19 RC
-
-**Mark Erikson:** Happily. Pointing to a couple of the big announcements from the conference. The first one was that React 19 itself has actually gone straight all the way from beta to release candidate. [08:31]
-
-I wasn't sure that they would even get to this step by the conference, but clearly they feel pretty good about the overall stability of, you know, what they've been trying to work on. I'm not going to try to go through all the various features and everything. If you've been listening to the podcast for the last few months, you've heard us discuss most of them at some point. [08:49]
-
-And the blog post itself does actually touch on all the major things that are in there. Things like, you know, hooks for dealing with for the new HTML streaming capabilities for things like assets. A lot of different stuff in there and whether these are going to have direct relevance for your own application will always vary, but there's been a lot of time and effort put into all these different pieces and how they tie together, even strictly on the client side, beyond things like server components as well. [09:21]
-
-Definitely worth taking a look at the RC blog posts, a great summary of what all is there in React 19. Related to that specifically, of course, there were talks at the conference that then went deeper into some of these aspects. Lydia Howley and Sam Selkoff both had talks that kind of gave overviews of the pieces there, especially some of the server component stuff. Worth watching those if you get a chance. [09:44]
-
-## Server Components on Expo
-
-**Mark Erikson:** Along with that, there was also a talk from the Expo team and Evan Bacon talking about how server components might actually fit into the React Native side of things. Mo, you have any thoughts on that one? [09:55]
-
-**Mo Khazali:** Yeah, so, this is something that the Expo team's been kind of silently working in the background for a little while, there was an interesting tweet that Evan had at one point. I think it was in a tweet exchange where he was like, if you look through my Git commits and my sort of hobby repos, you'll see the direction that Expo's going, because it's a very direct sign into my psyche. And you can see that he started working on this several months ago, and it's finally come to fruition. [10:15]
-
-But they've kind of been trying to work out what server components mean in a React Native ecosystem, which was, it was a big question mark, I think, for everyone in the community, because traditionally mobile apps are client side, and what does it mean to have the server rendering native layer components and elements? [10:31]
-
-I think they delivered on a phenomenal demo. There's still a long way to go before it reaches production and something that we can use, but really the core is that as long as there's sort of native layer supports for the right components, you can stream any JS that you want across the wire that's sort of serialized in the RSC way. [10:48]
-
-And then that can render native layer components on the device, which is quite cool. And what that means is you can basically stream JS that can orchestrate certain native behaviors, like maybe showing a native share card or showing a contact card on someone's phone. Those are sort of native elements, but they can still be orchestrated and sent across the wire with JS. [11:05]
-
-I'd really recommend going through and watching the demo that they had, because the majority of the talk is actually the demo, and you'll get a real good sense of what that means and what it would look like in practice. And interestingly, in the aftermath of it, it fueled a massive debate across the entire React Native ecosystem on the place where debates always get fueled, which is Twitter or X these days. It was a question of, because you can just basically send any JavaScript across the wire that will change how the app behaves, what does that really mean for Apple's terms of service? [11:32]
-
-And there was a bunch of people who were like, this absolutely violates Apple's terms of service. Your app will get rejected. Why is Expo doing this to the community? Why are they putting them down a rabbit hole? [11:40]
-
-And then other people saying, no, absolutely not. You can basically replace the entire JavaScript bundle today in React Native. So why should this change it? So interesting debates came out of it, but nonetheless, there's some exciting stuff going on. And I think we're just at the very tip of the iceberg so far. [11:55]
-
-**Carl Vitullo:** Yeah, a couple months ago, I had presumed that server components were just not going to be a thing on React Native, and was very surprised that they had full plans to integrate and make them work, pretty much the same as how it does on web. [12:09]
-
-So yeah, definitely worth checking out the demo to see how they get that going. [12:12]
-
-## React for Two Computers
-
-**Mo Khazali:** On top of that, afterwards, there was a talk by Dan Abramov, where he went over the paradigm of React for two computers, kind of sticking with the server component mode and model. And it was a really primitive explanation. I really love explanations like this, where someone kind of breaks things down into the very, very basic primitives. [12:30]
-
-Like you've got a web server. Here's how you can render HTML on the web and send it across to the client. Okay, what happens if we start to extract certain parts of this, separate them out and see how you can kind of construct React server components from scratch. I think Dan did a post on, it was something on GitHub that he posted, which kind of walked through the thinking for this talk, but really articulating it in a talk, put it into a nice story. [12:51]
-
-It was quite fascinating. And I think it was a really good explanation for anyone who wants to really understand server components. I don't know if you had any thoughts on it, Mark, yourself, but I quite enjoyed that. [13:00]
-
-**Mark Erikson:** A couple bits. He actually did put up a post earlier this year on his blog called The Two Reacts, which I think directly is, the exact same line of thought that led into this talk. [13:10]
-
-If you've watched Dan over the last year and a half, he's been throwing a lot of ideas against the wall to see what sticks in terms of teaching people server components and the mental model that, and like, we're trying to figure out what mental model makes sense to both explain it and make use of it properly. [13:29]
-
-The thought process here of, you know, it's expanding React to the server, but also it's still one React tree just split across two computers is something worth trying to wrap your mind around. [13:42]
-
-**Carl Vitullo:** Yeah, I was just thinking of whether I wanted to share this under the React compiler notes, and I think I'll get deeper into it. [13:47]
-
-But, I do think that this is a continuation of a pretty stable vision that the core team has had for React. From the outset, server rendering was something that was, you know, ostensibly possible to do with React. And there were many years and people were just kind of like wild westing it and doing it themselves and, you know, render to string and, Oh, cool. Now we can render a, you know, like a streamable HTML. [14:12]
-
-This is not new, it's just a new attempt at solving the same problem in a way that does it better than previously. So it's just a, you know, it's one more incremental step forward. [14:23]
-
-**Mark Erikson:** Yeah, I actually had a chance to talk with Ricky Hanlon while I was there in Vegas, actually, ironically, like five feet from where Carl's sitting right now, and he was talking a bit about, we didn't exactly know what the end state looked like, but we had a lot of intuitions about what it would feel like when we got there, and There, there was like partially a master plan, but also partially not. [14:48]
-
-It was just, we think these are the big problems we need to solve along the way. And that's how we ended up in things like hooks and whatnot. Eventually those have led to the point where now the grand vision is kind of coming together. [15:02]
-
-**Mo Khazali:** And I guess just to go in from the React Native perspective as well, me and Evan were having a chat about this at App.Js and a few other people as well were kind of echoing the same sentiment, which is it's been the same in the React Native ecosystem. [15:14]
-
-Larger scale organizations have been using server driven UI, where you kind of describe your layout in the form of a JSON object and ship that through an API endpoint or from your CMS directly to define how your page is layouted. [15:27]
-
-And server components on React Native as well are just kind of a continuation of that same paradigm of starting to move some of the layouting and some of the business logic of your front end app over to the server to kind of optimize it and also allow for more flexibility and better performance in many cases. [15:43]
-
-Like you say, it's just a natural continuation, whether you're on web or on mobile. [15:46]
-
-## Q&As with React and React Native Core team
-
-**Mark Erikson:** So, wrapping up a couple of the talk links here, there were also Q& As with both the React core team and React native core teams. I admittedly did not have a chance to watch these, but there's, I'm going to assume that there is material worth watching in both those sets of discussions. [16:04]
-
-**Carl Vitullo:** Sadly, I missed it as well. There was just too many interesting people to have great conversations with. I did hear that, I saw like a kind of snarky, sarcastic tweet from someone on the, I can't remember who now, someone on the React Native team, saying something to the effect of, like, we dropped so many bombs in this React Native Q& A and you're talking about this? Just as sort of a meta commentary on the Twitter discourse. It sounds like the core team thought that they got very deep in the weeds talking about some of the, talking about the technical details. [16:33]
-
-## React Compiler
-
-**Mark Erikson:** All right, moving along to another fairly sizable announcement from the conference and something I've been very eagerly waiting for it at the point that I almost stood up and did actually cheer when it happened. [16:43]
-
-The long awaited React compiler is now actually both open source and usable. Finally! The React team had been promising that it's real, trust us, it works. And they'd said at a couple talks last year that, you know, we're trialing it in production in a couple real Facebook sites. [17:03]
-
-It is now open source. You can now actually use it. And they've dropped a lot of information about how it actually works as well. So it's now actually officially listed in the docs. And there's instructions for setting up and using it. It's worth noting that in its current form, the way to use it is as a Babel plugin, which means that ironically we've been doing all this work to switch our build tooling over to Rust, and suddenly we might actually need to re add Babel, just to get the compiler to work. [17:31]
-
-Having said that, the compiler itself is like 90 percent it s own code, and it's really just using the Babel plugin layer as a way to manage the parsing of the code. But they've even played around with an eventual rewrite of some of the compiler logic in Rust. Um, there will likely be other alternative ways to load it into your build system down the road. [17:55]
-
-So, it's not like it's Strictly built out of Babel. One really neat piece is that they actually have a live playground. If you ever went to the Babel website, Babel has a playground that shows you, if you write some JavaScript code and have certain compilation settings activated, here's what the output looks like. [18:14]
-
-They've got a playground for the compiler as well. And I think this is really valuable on multiple levels. One, is that it literally shows you what the output will look like, so you can get a sense of the transpiled code without having to do an actual build step. It also actually has a set of vertical sidebars which show you what the actual compiler internals are outputting at each step of the transformation process. [18:43]
-
-The compiler itself is awesome. A real, no kidding, deep compiler, like, with all the, you know, real world compiler optimizations. And so getting a sense of both what kinds of passes they're doing and what the results look like, I think is really cool. There were a couple of really good talks at the conference about it. [19:01]
-
-Lauren Tan did a kind of a usage walkthrough, you know, let's add it to a project. Let's use it. The React DevTools will now show you if certain components have been optimized. She even had written her own little proof of concept VS Code plugin that would show in your editor if certain components were being optimized. That's not actually available yet that I know of. They may end up releasing like an official version of that VS Code plugin at some point. [19:29]
-
-Meanwhile, Sathya and Mofei, also on the compiler team, did more of a deep dive into how it works. And Mofei in particular did a live coding demo where she showed like, let's actually write a little Babel plugin that makes use of some of the compiler internal, and see how the output of it changes as they add each piece of the compiler logic to it. [19:50]
-
-One more good explainer, Jack Harrington had a chance to do, I think, both a video and a blog post where he walked through using the compiler and talked about some of the usage changes and the mental model aspects. I think one of the big pieces for people to understand is that this does several different things. [20:10]
-
-One is it adds like the dependency array aspects to useEffect, useMemo that we've always kind of wanted so we don't have to do it ourselves. [20:18]
-
-Another is that it overall optimizes the rendering performance of components. But on top of that, it kind of flips the mental model of React rendering on its head. [20:29]
-
-One of the big things you've always needed to know is that React renders recursively by default, and now the compiler flips it, so that finally, only components whose data actually changed will re render. So this is a big deal. [20:42]
-
-**Carl Vitullo:** Yeah, I also saw on Twitter, just sort of an open question that I thought was a good one to ask. [20:48]
-
-Jamie Kyle asked if library authors were going to be expected to ship components and hooks pre compiled. And Sathya responded that like, yep, they're just like all of the other transpiling, compiling in the ecosystem. You know, if you're authoring in TypeScript or Flow or, I can't think of any other compiled things off the top of my head, then yeah, so you published the compiled artifacts to npm, so I thought that was worth calling out for anyone here who might maintain a library. [21:17]
-
-**Mark Erikson:** It's worth noting that the compiler output does expect to use a new hook that is, strictly speaking, only available in React 19. Having said that, there is a very simple polyfill. [21:31]
-
-It's really just a useMemo that allocates an array. That polyfill ought to make the compiler's output work if your app is still on React 17 or 18. So, in theory, you could drop this into an existing React 17 or 18 application and still get the same performance benefits. Which is nice because, you know, basically nobody's on React 19 yet. [21:54]
-
-**Mo Khazali:** I guess in terms of another small detail as well, to keep in mind if you're trying to add this in, is the React compiler, as far as I'm aware, expects for you to list it as the first Babel plugin in your config, and the idea with there is they want to have the state of your code base before any other plugins mess around with it and transform it. [22:12]
-
-So, it's, that's just a little gotcha in case you are trying to integrate it. Just now into your app, hearing about this. [22:18]
-
-**Mark Erikson:** And again, with Carl, with what you said earlier, it's, this is a vision that the React team has had for a while. You know, they, they'd said early on that they designed the hooks APIs, you know, specifically the dependency arrays under the assumption that someday a future magical compiler could do that for you. [22:36]
-
-They honestly weren't sure if, and when they would ever get around to it. And it was pointed out that they didn't have compiler expertise on the team. At the time that they were making that assumption, but that was a thing that they assumed would eventually happen. You know, they played around with a proof of concept compiler called prepack years ago. [22:54]
-
-That attempt didn't work out. And even this current compiler took a couple of different attempts to really figure out what they, what it was supposed to do and how they were going to do it. But the thought process of we could use a compiler has been around for a while. A couple other quick notes to wrap this up. [23:12]
-
-Lauren Tan did a talk all the way back in 2016 that has kind of a couple indirect precursors to the thought process of the compiler and using it. They apparently used it in the official React Conf app. And the BlueSky Twitter alternative is already using it in production, partly because Dan works on BlueSky now. [23:32]
-
-And also the React core team added it to BlueSky to help prove that it would work in a separate real world application. [23:39]
-
-## Remix is merging (back?) into React Router
-
-**Mark Erikson:** I'll toss out one other announcement that came out of the conference. So Ryan Florence did a talk where he announced that Remix and React Router are merging, sort of, conceptually. [23:51]
-
-The way he put it is that Remix itself, at this point, is basically just the latest version of React Router plus a Vite plugin that adds the actual build steps. And so, rather than continuing to put more things into the Remix packages specifically, they're just gonna move a couple more things over into the React Router packages, label that React Router v7, and it has an optional Vite plugin if you want to do server usage. [24:21]
-
-Um, this of course was met with much confusion and complaining on Twitter. Personally, it makes sense to me. And it's worth watching Ryan's talk to get a sense of why they're going this way. [24:32]
-
-**Carl Vitullo:** Yeah, and this was surprising. I won't say that it wasn't surprising. I just thought that, like, Remix, I mean, they're a venture backed business. They got acquired by Shopify. I am surprised to see them say that Remix is just not going to be a thing anymore. For that, for those branding reasons, branding and funding and,[24:49]
-
-**Mark Erikson:** The caveat there is Ryan said in both the talk and the later blog post that they put up, like, we have more plans for Remix as both a brand and a set of tools that we want to circle back to in a few months. [25:05]
-
-Like, we have some idea of something new we want to do with it, but for now the focus is like, let's just roll all this stuff into the next version of React Router and then you can pick and choose whether it's just doing client side stuff or server side stuff too. [25:19]
-
-**Mo Khazali:** And I guess on the Shopify piece, Carl, I'd love to get your thoughts, but I feel like Shopify kind of achieved what they were trying to achieve with Remix, which was ultimately they took it and made it the backbone of Hydrogen, which was their own sort of, I guess, framework, so to speak. [25:33]
-
-And it's great if you've ever used it to make a Shopify app. I don't know if that, maybe they're looking to get more out of it or not, but I feel like it probably achieved at least some of the purpose of why they, they, backed it as a framework and invested in it. [25:44]
-
-**Carl Vitullo:** That's true. Yeah. And I guess, actually, I don't know this, but I think it was an acqui-hire, they started working at Shopify? Yeah. So that, that certainly makes sense, Shopify got their value out of business transaction for sure. But, so I guess, as surprising as it was to me for them to announce that they're now moving back to React Router as their primary brand for the work they're doing right now, they also have a long history of doing things like this. [26:09]
-
-The React Router folks put out React Router and then they've done at least one, I think, departure that sort of builds on because they had done Reach router for a while because they had some new concepts that they wanted to explore. And I think that is a phenomenally responsible way to approach public experimentation in an open source setting. [26:30]
-
-They have a large enough audience that if they announce a new project, people will give it a shot. And I think it is so smart, in terms of, like, branding and messaging and, managing expectations, I think they are tremendously smart and thoughtful about how they use brands, because, you know, you can do, like, a major version, you can do a beta or an RC, or, you know, do, like, an experimental phase in a project, but I think it is really great and honestly kind of them to the community to say like no This is different enough that we are giving it a new brand and we're gonna experiment and then now twice now They've said "cool, we learned a bunch of stuff and we're just gonna bring it back, now it's just React Router again." [27:12]
-
-So because React Router specifically React Router is such a like foundational part of the Ecosystem. Like, you know, the React team has never blessed a routing tool to use with React. So it's, they've always just been the de facto one to use. And I think it is really marvelous that they have taken that position with such seriousness and done this kind of thoughtful experimentation with it. [27:38]
-
-**Mark Erikson:** I can vouch that naming and branding and getting people to migrate is a really hard problem. [27:45]
-
-**Carl Vitullo:** I want to call that out, I think it's really clever and smart and, just having been in the ecosystem since 2015 and watching a lot of thrashing and watching a lot of arguing on Twitter about like this and that and the other, I think they've been really consistently great about, once all the dust settles, at the time it was kind of confusing, but so I guess I want to be the voice that's like," it's going to be okay." [28:08]
-
-## Effect JS
-
-**Carl Vitullo:** Okay, moving on to the next subject, I guess. This was a subject that I almost brought in on the last episode and held off because it seemed a little bit too out there. But I dug into it a little bit over the last month. [28:19]
-
-Effect, they have released 3. 0 and they are now calling it production ready. It, it had crossed my radar in April with some people asking folks like Kent C. Dodds and other prominent educators, what they thought about it. So, and the consensus I saw then was like, looks neat, but it's real big. That's a lot to learn. I'm not, I'm not dipping my toes in yet. [28:41]
-
-And basically what I understand it to be is a, it's almost a standard library for TypeScript, but it's also. Like a functional programming kind of paradigm, like it introduces new concepts for all the way down to console. log. So there's a fetch replacement. There's a console. log replacement. There's a promise replacement. It's an enormous surface area for the API. So in a very real way, it's like learning a new language, which is why I held off on this, because it's a Big swing. [29:15]
-
-It is an enormous swing. One of the reasons I decided to bring it in is that I learned while digging into it that Johannes Schickling is one of the people backing this, one of the creators of the project. And he's been, I can't remember what his first project was. I've been following him for, it feels like forever. He was the founder of Prisma, which was a very influential ORM, schema declaration model. [29:40]
-
-**Mark Erikson:** He's done some GraphQL stuff, and I actually had a chance to meet him in person back in December, and one of the ideas he's been playing around with is like a local first application where every single bit of the code from fetch data to literal client side state is held in an in memory SQLite database. [29:59]
-
-So, like, rather than a bunch of used state hooks, he's got, like, reactive hooks that tie into SQLite running as WASM in the browser, and literally every bit of data in that example. is coming straight out of that SQLite database. Which sounds odd, but when you see it in practice, it's like, oh, I can see the intent behind why he's playing with this idea. [30:22]
-
-**Mo Khazali:** I don't know if you folks recall Project Lightspeed, that Meta did a few years ago, I think it was like 2019, 2020. With the messenger app that they did, it was a very similar approach, which was everything on the client side is backed by SQLite database, the data fetching, the layouting, the local state. So I don't think it's an, it's that odd of a paradigm. [30:40]
-
-It sounds like a, it could be a good scalable way to handle things. So interesting to hear that somebody else is like digging into that vision, Mark. [30:47]
-
-**Mark Erikson:** So with the effect thing, like I echo what you're saying, Carl, is like, just trying to describe what the project is. And a couple bullet points is hard. If I could attempt to restate what you were saying a minute ago, it's multiple different pieces. [31:01]
-
-One is that there's some similarity to the Redux Saga package, where instead of using Async await syntax, and actually kicking off things like async requests right now, I think your code uses generators and generally returns descriptions of like what kind of side effectful behavior you want the code to execute. [31:26]
-
-But nothing actually happens until you return those descriptions to some kind of runner that actually goes off and does the work. Another aspect is that instead of relying on throwing errors just from any piece of the code, you actually end up specifying at the type level that this function could return a number and could throw a, like, could not parse integer error, or something like that. [31:54]
-
-And so you, like, it's a very, like I said, functional programming way of modeling code. Returned values versus possible thrown errors, and they have an entire JavaScript standard library built up because as we all know, one of the weaknesses of the JS ecosystem is we don't have much of a standard library built into the language itself. [32:17]
-
-And there's a whole bunch of primitives around async concurrency. So things like retries and, you know, iteration, backoffs, and that sort of thing. So, like, that, as usual, I've not played with it, I've only tried to skim over the docs, and, yeah, like, my own reaction is like, Wow, that's a lot, I can't even wrap my head around this, but I think that's the best description I can come up with, and I think I see where they're trying to go with this. [32:45]
-
-**Carl Vitullo:** I did dig around a little bit more than trying to read the documentation. I was directed to, a wonderful 10 minute introduction about it. That was what really sold me, and I'm like, yep, okay, we're gonna talk about this. So I definitely recommend checking that out. Um, from Ethan Niser, yeah, just, it's a great 10 minute introduction. [33:02]
-
-And going back to Johannes Schickling, he gave a, an hour long talk titled Production Grade TypeScript at, they put on a conference, they put on a conference already, Effect Days 2024. It was also great. It was much deeper in the weeds. At one point he said, like, "I'm sure that a lot of people watching this talk on YouTube are going to be angry I'm not explaining what effect is." And I was like, dang it, that's me. I wanted to know what effect is (laughter). But it was a great talk besides that, uh, it just didn't quite answer the question I was hoping for. [33:32]
-
-If he's got bona fides in, like, querying, schema, GraphQL, as well as local first, like, to me, those both extensively deal with the hardest parts of asynchronous behavior, with, like, retries and backoffs, like you were mentioning. So that is A lot of very deep experience with some very hard problems. [33:53]
-
-And I do love local first. I think it is an absolutely wonderful paradigm and it is very challenging right now. So if we end up getting a relatively widely used and supported standard library that makes things like exponential backoff and retries and responding to different kinds of errors in different ways. Then. All of the myriad things that make asynchronous behavior difficult, then that sounds pretty cool. [34:19]
-
-I'm pretty excited about it. So, I don't know, that's, that's all I will say on effect. [34:23]
-
-## Forensics of React Server Components
-
-**Mark Erikson:** All right, moving along. We've discussed and linked to a lot of articles over the last few months that attempt to dig in and explain various aspects of React server components. [34:34]
-
-What are they? Why would you care about them? How do you use them? How would you even go about building your own server components based framework? [34:42]
-
-And we want to point to one article along those lines this month, the forensics of React server components. This one does a really good job of laying out a lot of the different pieces and how they fit together. [34:54]
-
-It talks about, you know, client side rendering and kind of illustrates some of the data fetching and rendering workflow, server side rendering, and how data gets fetched on the server and rendered and loaded into the client. Hydration and servers and some of the issues with that, and then goes and digs into server components and kind of walks through a lot of what the data flow and mental model of where data and where server components fit into the life cycle, how the data fetching behaves, the interactions between server components and client components, and even shows some examples of the serialized output that server components return. So, it's a pretty good one stop shop for kind of wrapping your head around some of the actual usage and mental model of server components. [35:39]
-
-## Next.js v15 RC
-
-**Carl Vitullo:** Okay, uh, Next15 has an RC coming out, or that is now out. [35:44]
-
-Not entirely related, but I did see that Vercel has now raised 250 million dollars. So they are capitalized for a good minute longer. They're not going to go out of business anytime soon. [35:54]
-
-But yeah, Next 15 supports React 19 and the compiler, they have changed their caching behavior pretty extensively, which I had understood to be one of the bigger pain points of using the app router. They have an experimental API called Next After, which solves a problem where you can schedule work to be processed after the response from the server has finished streaming. It solves the problem of needing to figure out, needing to guess when the response has come in. I think that's pretty neat. [36:22]
-
-They also have a neat feature, they call it partial pre rendering, it is neat looking to me. They say, you can wrap any dynamic UI in a suspense boundary, when a new request comes in, Next will immediately serve a static HTML shell, then render and stream in the dynamic parts with the same HTTP request. That sounds a lot like out of order streaming that I had heard some stuff about in the past. [36:43]
-
-I mean, that's always been the dream of server side rendering is you make a request, you immediately respond with something, so it's not just a blank screen and then fill in the rest of the bits. So it seems like a clear improvement to me to be able to do that in a single HTTP request without having to open a new connection and do all the TCP handshaking. So that, that should be a pretty good performance improvement. [37:05]
-
-## It's not just you, Next.js is getting harder to use
-
-**Carl Vitullo:** I just wanted to call out an article that I saw entitled, It's Not Just You, Next. js is Getting Harder to Use. It just kind of calls out the increasing complexity of the framework. It's a little pessimistic, it's a little down note, but I think it's reasonably fair. [37:20]
-
-Just to call out a couple of sections that seemed worth it to me. You need to understand a lot about the internals to do seemingly basic tasks. There are many ways to shoot yourself in the foot that are opt out instead of opt in. This is just a funny bit talking about like, you know, you go to a GitHub issue and you see an explanation of why that thing that you want to do isn't possible and go like, "oh, that does make sense." But they say, you probably read this and left with five more things to Google before realizing that you probably have to restructure your code, which is Brutally familiar. [37:49]
-
-So, and on the app router, if you started a Next project, Next will default you into it, which implies that it's production ready. It implies that if you're starting something new that you're going to ship to production, you should use the app router. [38:02]
-
-But this article calls out, "the official React docs don't share that same sentiment. They currently recommend the Pages router and describes the app router as a bleeding edge React framework." So, it seemed like a really good, really fair. Non complementary discussion of Next. [38:17]
-
-**Mark Erikson:** I've seen a number of folks complain that the app router works great for the layouty stuff, but some of the integrations have been both buggy and somewhat hard to use. [38:28]
-
-One comment I saw was the effect that, ironically enough, the app router Works better for static pages and the pages router works better for applications in terms of data fetching. So the names almost seem a little bit backwards, ironically. [38:43]
-
-**Mo Khazali:** I don't know about you folks, but when the App router came out and you know, I've gotten more and more used to it as time passes, but I just found that the pages router, even just things like being explicit with, you know, whether you're doing get server side props or you're doing get static props, just found that I love the fact that it's explicit, so at least you as the developer have to explicitly define how you want sort of that page to be rendered, rather than sort of the automated, magical nature of the app router. [39:08]
-
-I do miss that sometimes, but there's also a lot of benefits to having the app router, so I guess it's, as with all things, there's trade offs with it. [39:15]
-
-**Mark Erikson:** All right, Mo, you have a lot more expertise on React Native than either the two of us. Want to hit some of those highlights? [39:21]
-
-## React Native New Architecture beta
-
-**Mo Khazali:** Let's jump into it. So let's start off with Meta news. Firstly, we've been hearing about the new architecture for years now, if you've been in the ecosystem, uh, but they have officially put it into beta, which is a big deal if you've been here for a hot minute and the word on the street unofficially is that we might finally see it going into production or going into default and out of beta sometime this year. We'll see if that happens, but it'd be very exciting. [39:46]
-
-The good news with all of this is there's more and more, uh, Third party libraries or open source libraries that are coming with new architecture support. And I think that's the real bottleneck right now is one having a good interop layer, which the folks shipped last year from the meta team. [40:00]
-
-So that helps kind of ensure some level of backwards compatibility, whether it's with the layouting engine or with the rendering engine, but I think it's a really good step that they're going into beta and soon more and more libraries are going to support new architecture. [40:12]
-
-There was this massive Google Sheet that just had all of the libraries that currently support new architecture that are commonly used in, in, in the community and some of the ones that don't yet. So it's, it's going in that direction. I think everyone's trying to push and get, get it finally over the line. [40:25]
-
-## Expo is now the recommended framework
-
-**Mo Khazali:** Uh, in other news, Meta, both in React Conf and also at AppJS did kind of similar talks about how you should use a framework. So if you've been in the React space with Next, you will be familiar with this. Very much, but the idea here is that they've officially came out and endorsed that you should use Expo by default. [40:43]
-
-And this isn't anything new. If you had been frequenting the React Native docs for the last couple years, they give a nod to Expo here and there, they use Expo Snacks for the coding examples, and they kind of make points to say you should go and check out Expo if you're starting out a new app. [40:59]
-
-Um, but now they've explicitly said, you know, you should use a framework for the same reasons that you see in the React ecosystem. Routing, um, tooling, and having the right ecosystem in place, which I think is a great step because it really, using something like Expo really saves developers a lot of, uh, hassle and a lot of difficulty that you oftentimes face if you're just on a bare React Native project. [41:17]
-
-## React Native Skia on WebGPU
-
-**Mo Khazali:** Now, going into community news, these things are fresh off of the press, predominantly out of App. js that happened last week. So, the first thing that I think was incredibly exciting was that we got some updates on React Native Skia. React Native Skia has been a 2D rendering sort of canvas that you can use in React Native to draw graphics, nice animated graphics, sometimes interactible graphics if you want to integrate it with things like Reanimated or GestureHandler. [41:43]
-
-The announcement for this was in some ways the most amazing and also the most sort of cheeky announcement possible because it was sort of Apple esque intros with sort of rainbow colors going to form a hello and really just showing that they're very much great graphists at heart that are working behind this. And Skia is backed by Shopify as well. So it's got massive backing. It's a great project. So you should definitely check it out. [42:05]
-
-Previously Skia was mainly used for 2D graphics. So it gave you a canvas. You could draw things on it. And people had I've been using it to kind of extend the boundaries to create what they call 2. 5D, which is 2D graphics that kind of resemble 3D, and through the illusions of looking at it, they kind of look like they're 3D, but they're still just rendered on a 2D graphic, uh, and this has a few limitations, it runs on the CPU, it's not really truly 3D. If you want to do anything like interactivity with it, you're quite limited by sieve there in terms of your performance. [42:35]
-
-And hence, the talk that they had at Appjs was called Hello GPU. So first they started off saying, ah, there's video support now, so you can do a whole bunch of shaders on videos, which was quite cool, but really the key thing that was exciting was that they actually brought WebGPU into the React Native world. [42:50]
-
-So you can use WebGPU to obviously target web, uh, with React Native Skia, if you're using React Native on the web, but you can also use it for iOS and for Android and having those sort of cross platform 3D visualizations and rendering, I think is going to be really cool for the community and not something that we've actually been able to do very effectively on the GPU layer. [43:09]
-
-And they've integrated all the way down into the native layer APIs, so, Metal on iOS as an example. Especially with something like React Native running on Vision OS, where you really want to have these 3D objects that you kind of put in your vicinity in the spatial navigation paradigm. [43:24]
-
-It will be so cool to be able to actually use that as well for VR and not just on Vision OS, but also maybe on some of the Quest runtimes and so on and so forth. So I think it's, it's a really cool step and it stops us from having to drop into the native layer as we've often had to do with this type of thing. [43:39]
-
-## React Native IDE
-
-**Mo Khazali:** Next up on the announcements from AppJS, we saw the React Native IDE. So this has been kind of teased by the folks at Software Mansion for a long time. We've had a lot of sort of disparate tools in the React Native ecosystem. You know, when you're usually developing with React Native, you have to have your terminal running your Metro bundler and then maybe have Some Chrome DevTools running connected to the React Native DevTools to kind of, uh, your network requests coming in and analyze your source code. [44:04]
-
-And then if you want to dig in and look at what elements are being rendered, where it's all really just sort of a bunch of different parts to the dev experience. And it's not been amazing. There's obviously been a lot of improvement. And if you come from the native world, sometimes those things can be a lot more integrated with Android Studio and Xcode. [44:20]
-
-And so the lovely folks at Software Mansion have developed an IDE and it does some really cool stuff. I won't go into too much details. It does everything you would expect from an IDE. And I think it brings first class DevEx into the React Native world. It's going into beta or went into beta last week. [44:34]
-
-And the coolest thing out of all of the demo was debuggers across the native boundaries, so when you put in a debugger, it not only could handle debugging on the JS code that you write, but you could also place debuggers inside of your node modules on the iOS Swift code, or maybe your Android code that you have written in Kotlin, which I think is really cool, because one of the challenges is you're kind of fiddling between Xcode and Android Studio and also Visual Studio Code, And this brings it all into one place, which is really quite exciting. [45:03]
-
-## React Native on TVs
-
-**Mo Khazali:** And then the last thing that happened around React Conf, and they nodded at it again at AppJS, was around Amazon doing a keynote talk about using React Native beyond web and mobile. And so Amazon has started becoming a big proponent of React Native in general, but also React Native on TV specifically. [45:20]
-
-And they have actually been using React Native for years now. They kind of hit it very cleverly where you couldn't really see it on first glance in the app binaries, but they came out with a big bang announcement last year saying we have actually been using React Native for a very long time, and it's been most of our apps. Huh. Gotcha. [45:35]
-
-And so it was quite a nice announcement in that, well, there's more people using React Native and that's always a good show of faith in the technology for the community. But it was quite funny that they hid it for so long. [45:45]
-
-Amazon obviously does a lot with Firesticks and TV devices, and their OS is based off of Android. So you can build TV apps for it with React Native. And I think they're very keen on people using React Native just because of its cross platform nature. They talked about many different things, challenges of performance and spatial navigation on TV. One thing, if anyone is interested in React Native for TV, a bit of a shameless plug here, so I apologize to you both, Carl and Mark. [46:12]
-
-**Mark Erikson:** Shameless plugs! Gasp! [46:15]
-
-**Carl Vitullo:** Who does those?? [46:16]
-
-**Mo Khazali:** Questionable on my, on my character there, I'm so sorry, folks. But, as part of like some of the community stuff that, I've been doing with some of the folks from Amazon. We actually started an RNTV.dev blog, and it's kind of meant to be a centralized resource for everything about React Native on TV, because that doesn't exist. We thought, why not make it so that we can help people onboard into it more and more. [46:36]
-
-The other last thing that they kind of dangled was they said, we want to support open source projects, especially ones on React Native for TV. So if you're interested and you've got a project that's extensively used on React Native for TV, Sign up for this form and we're gonna be, start starting to sponsor more and more projects on the React and React native ecosystem. [46:53]
-
-So if you're a community maintainer, wink wink, you might wanna check that out and see if there's something that you can, uh, get some support from them for. [47:01]
-
-And that is all of the React native stuff. Sorry folks for going into that rabbit hole. [47:05]
-
-**Carl Vitullo:** No, thank you. That's, we have a dearth of React native expertise on our end, so I'm very glad you can speak to it. [47:11]
-
-It's cool to hear more about the React Native TV stuff. Cause a couple of months ago, Oh God, probably a year ago now. I spoke to Kaleb McKelvey, I want to say it is, about React Native on TV. [47:24]
-
-In that setting. And it was a fun, interesting talk. It's an interesting input paradigm. You know, a remote control is very different from a keyboard or a touchscreen. [47:33]
-
-**Mo Khazali:** Yeah, it's really quite tough, Carl. Like, you know, we're used to touch displays or, you know, cursors on the web or the pointers or whatever it is. And then you're really suddenly limited to up, right, left, down, and a select key. And you're like, Oh, wow, how do I, how do I, what happens when I press down and I'm at the end of a carousel? Like, it's just so much, like, undefined behavior that isn't standardized. So, it's definitely a cool engineering challenge to delve into if you want something new. [48:01]
-
-**Carl Vitullo:** For sure. It's a funny, stateful mode of input. [48:04]
-
-**Mo Khazali:** Yeah 100%. [48:04]
-
-## ⚡️ Lightning round ⚡️
-
-**Carl Vitullo:** Okay, cool. On to the lightning round. [48:07]
-
-## Speculation Rules API in Chrome
-
-**Carl Vitullo:** I'll take the lead with some new Speculation Rules API in Chrome. This was a new term to me, Speculation Rules, but so this is apparently finer grained control over how Chrome will prefetch pages. [48:22]
-
-So this lets you more clearly signal to the Chrome browser whether and how it should try to prefetch something as a user, like hovers or begins to click, things like that. [48:33]
-
-## Josh Comeau's post on useDeferredValue
-
-**Mark Erikson:** Josh Comeau put out a, yet another one of his incredible blog posts. I mean, basically every blog post or article that Josh Comeau ever writes is amazing. [48:42]
-
-And this one was on snappy UI optimization with the relatively new React use deferred value hook. Now this came out in React 18, so it's actually been out for a couple of years, but frankly, almost nobody knows how to use this, including myself. And he pointed out that it's almost like a built in debounce for re rendering with a lower priority state update. [49:06]
-
-And so he gave some examples of a feature on his own blog or site that really benefited from moving some expensive calculations and rendering. In debouncing them via used, used deferred value and it really improved the smooth smoothness and snappiness of the ui. [49:24]
-
-## BlueSky engineering culture
-
-**Carl Vitullo:** Cool. I saw a pretty solid looking article from the pragmatic engineer about BlueSky engineering culture. I am all about BlueSky. I would love it if they are successful. And I always love a deep dive into engineering culture and, uh, you know, a white paper, as it were, of how an engineering team operates. So I thought it was pretty neat. For instance, they have two to three person teams with a directly responsible individual and lots of long form writing. [49:53]
-
-So it's like little things like that, I think are really cool to, you know, it's the, in our careers, we get so little, opportunity to experience different types of workplace cultures. So I think articles like these are super valuable for understanding whether there is something better for you out there. [50:11]
-
-So yeah, go check it out. Also, Dan Abramov works there, so you can learn about how Dan Abramov works. [50:16]
-
-## Why Patching Globals is Harmful
-
-**Mark Erikson:** Let's see, Artem Zakharchenko, uh, his handle is kettanito, he's the creator of the mux service worker tool. Put up a post called, Why patching globals is harmful. And, you know, sort of in response to, you know, some of the, the React and Next teams a couple other teams as well, suggesting that, like, we should patch globals automatically in various situations. [50:38]
-
-And his whole sales pitch is that, especially today, like MockServiceWorker just uses standardized JavaScript interfaces for doing this behavior, and we've collectively learned that patching globals is a really bad thing. So, you know, some useful food for thought there. [50:54]
-
-## New Webkit features in Safari 17.5
-
-**Carl Vitullo:** There was a great post from New WebKit Features in Safari 17. 5. [50:59]
-
-This caught my eye just because in so many cases, Safari is the last browser to implement something. So seeing oh, Safari implemented something, just caught my attention as like, Maybe we can use this now. It looks like Firefox is still a bit of a laggard on some of these features, but, there's a light dark function, light dark as a CSS function, which is a bit of a simplified developer experience for doing dark mode. [51:25]
-
-So it previously there had been a media query for, I believe it was prefers dark mode. That doesn't sound right, but there was a media query where you could apply different styles if the user had a setting for preferring dark mode. This is now a function that does effectively the same thing. So, This is a solid improvement because with the media query, you pretty much have to like copy an entire style block. [51:50]
-
-Whereas this you can just do inline, like if somebody wants a dark mode, you get this color. If somebody wants a light mode, you get this color. Just boom, nice little either or that you can do right in line. So I thought that was great. [52:01]
-
-This is, I cannot believe that we are only just now getting this in 2024, but we now have text wrap balanced, where you can tell CSS that you want, for instance, a title of a document to stay balanced instead of like, this goes deep into design and typography. It's a classic problem of designers saying like, well, hey, on certain screen sizes, we have a dangling word here. Can we just fix that? And the answer for so long has been, "no, that's really hard." So now we have a CSS rule that lets us give better control over how text wraps. So that's wonderful. [52:38]
-
-**Mo Khazali:** And I think there was a React library that was dedicated to this exact thing for the longest time. So it's cool. [52:44]
-
-**Carl Vitullo:** That's why — cuz it's so hard. You needed JavaScript. You needed to like measure the characters and like know what font you're using. [52:52]
-
-**Mark Erikson:** This is, this is a place I will legitimately happily use the platform. [52:56]
-
-**Carl Vitullo:** Right? It's such a core part of designing a web page, like how does the text wrap? It's just so outrageous to me that it's 2024 and we are just now getting some mode of control of it that doesn't require JavaScript. And it didn't even work well in the past because you like, measuring fonts was not easy on its own, so that was weird. [53:15]
-
-**Mo Khazali:** I'm going to rabbit hole again. You should have seen the, uh, Next. js implementation of that, because how do you consolidate the server rendering of the balanced text from the, it was, it had a whole, I went into the cores of that library, uh, massive rabbit hole. It was so funny to see how much work had to go into just getting that working on Next and on React client side. [53:33]
-
-**Mark Erikson:** Part of me wants to go look and the rest of me doesn't want to. [53:36]
-
-**Mo Khazali:** I will send you the link. Yeah,[53:37]
-
-**Carl Vitullo:** we'll put it in the show notes too. Haha. Cool. [53:40]
-
-And they also, there's also an app starting style rule for things like entry transitions, which is great because we now have a lot more options for entry transitions because stuff like popovers and modals are now entering the platform as well. [53:53]
-
-Cool. Love it. Here for it. That's all I got. [53:56]
-
-## Why React Query
-
-**Mark Erikson:** The folks from the UI. dev educational material site have put up a post that talks about why React query. I always love historical posts or posts that explain like, here's an abstraction, why does this extraction even exist? Like what work is it doing for us in the first place? [54:15]
-
-And so they kind of walk through like, okay, if you were to actually just fetch data inside a component, here's all the work you have to do it correctly. And, oh look, React Query actually does all that work for you. Same thing for RTK Query and Apollo and SWR, in principle. They put up this in support of their new upcoming React Query course, which I believe has been written by the current maintainer of React Query, Dominic Dorfmeister. Knowing that and knowing the folks behind UI. dev, highly endorsed, even though I haven't actually looked at it. [54:45]
-
-## We can have a different web
-
-**Carl Vitullo:** I saw a wonderful post from Molly White, who I am most familiar with her writing on looking at Web3 through a skeptical lens. [54:54]
-
-**Mark Erikson:** Web3 is going great. [54:56]
-
-**Carl Vitullo:** Yes, right. Her blog, Web3 is going great. She is a wonderful writer. She just gives great incisive commentary on Web3. She has put out this post titled, we can have a different web, it caught my eye. Because Web 3 took that moniker as trying to, kind of trying to ape the, like, Web 2. [55:13]
-
-0. They're like, well, Web 2. 0 is dead. We are now Web 3. And what a shame that only refers to kind of scammy cryptocurrency projects. I guess now I'd love to see like a Web 4. I know Block, briefly, Tried to do web five as a branding thing. [55:27]
-
-**Mark Erikson:** Let's do the Winamp thing. It's like version two, version three, version five. [55:32]
-
-**Carl Vitullo:** Yeah, right. If we could have Chrome just shout at you, it really whips the llama's ass, that would be great. [55:38]
-
-But yeah, so, okay. This is, Molly White put out this great post. We can have a different web. Just talking about the local Maxima that we've found ourselves in. as users of the internet, you know, sort of bemoaning how if you search something on Google, you used to be able to find it. [55:54]
-
-I think one of the points she makes that is important and nice is that all of those things that people loved about like the good old days of the internet, they're still there. It's just a little bit harder to find them. So sort of her claim is like, we can still have that. We just, you know, there's, needs to be a little bit more. [56:09]
-
-I just definitely recommend checking it out. It tickled my brain a little bit because obviously I've been thinking a lot about community and communities of developers. And so we can have a different web, what is just a very exciting subject to contemplate for me. So definitely recommend checking that out. [56:23]
-
-**Mo Khazali:** It just briefly also reminded me of the work that the folks at ARC are doing with the browser company with the new browser that they've released, ARC, that's based on Chromium. But, you know, I think they're also trying to kind of re envision what it means to search for something on the web where. And integrating some level of generative AI to pull everything and kind of give you a summary and signpost you to the right links so it's less overwhelming than searching on Google these days. [56:46]
-
-It's definitely an interesting take. I think other people are also struggling with that same problem and trying to tackle it. Or we could go for a fully decentralized internet on everyone's phones. A certain TV show might have tried to spin that idea. [56:58]
-
-**Mark Erikson:** A Black Mirror reference? [56:59]
-
-**Mo Khazali:** No, I was, I was referring to Silicon Valley with Pied Piper. [57:02]
-
-**Carl Vitullo:** Ah. No, Pied Piper. Okay. Yep. I also thought Black Mirror. So that says something. [57:08]
-
-**Mark Erikson:** So Christoph Nakazawa, who some folks might know as one of the long, I guess, previous maintainers of Jest while he was working at Facebook, has gone off and created a 2D strategy game sold on Steam called Athena Crisis. [57:23]
-
-I think it has some influences from, like, Advance Wars and that sort of genre. He built the entire game using React and CSS. And even though the game itself is, like, genuinely being sold on Steam, he's gone and open sourced the vast majority of the codebase. I had a chance to hear him talk about it a little bit while I was at React Conf, and he's even done things like putting up bounties for people to, like, improve the AI, or add new features to the map editor. [57:52]
-
-Someone added, like, a tile mirroring feature so you can, you know, create maps that have, like, equal challenges for all the players. And so, his explicit goal was that, like, look, you know, maybe there's people out there who want to get into some kind of game related programming. And while this isn't like a 60 frames per second shooter style of game, there's still aspects of building a game that people might be interested in learning about, and they might be coming from the React community. [58:19]
-
-And so by open sourcing this code base, folks can actually, you know, dig inside and learn and play around with it. So, you know, like kudos to him for taking that approach. [58:29]
-
-**Carl Vitullo:** I also want to shout out that if you played Advance Wars back in the day, this will scratch an itch for you, I think. I've played it a fair amount. [58:37]
-
-It's pretty good. I enjoy it. It's a good game. Having it also be fully open source and come with that ethos is just lovely. I love it. [58:44]
-
-Cool. I'm going to share this. Lee Holmes put out a blog post. Actually, this is not new, but it just crossed my radar. I don't remember where. I think it was in one of the newsletters that I read. [58:54]
-
-But it was titled, Security Risks of Postman. This is not new. This is, I think, even, maybe even reasonably well known. But like, Postman thinks data. They have a cloud service. It is meant to make it easier for you to, you know, keep your different development computers synchronized with each other. But, also You're probably using Postman to, you know, make requests to a development environment. [59:15]
-
-And it might include things like authorization tokens, API keys, like all kinds of really sensitive information that You probably don't want other people to get access to. So that's just generally the topic of this blog post of like, Postman is a security threat. And yeah, can't argue with that. That's you, you should not be putting your API keys into something that feeds them into a third party. [59:38]
-
-So yeah, definitely something to consider. I have always been confused about Postman. Their development path. I loved it for a long time and then they got really complicated with request collections and cloud features and whatever. So this didn't seem like something that needed to be a venture backed business, which is what it is, I believe. [59:58]
-
-**Mark Erikson:** And last item out of our lightning round, while it's not React related, Angular 18 is out. And of course, not being an Angular dev, I only have the vaguest clue of what's going on over there, but looking at the changelist, they're in the process of dropping something that they used called zone. [01:00:15]
-
-js, which monkey patched, like, every possible source of asynchronicity in the browser. In order to detect when data mutations happened so that the UI could then do the diffing and know if it needed to re render. They've also, I believe, been integrating things like signals and trying to move away from RxJS a little bit. [01:00:36]
-
-So, you know, there's various aspects that are there for interop between RxJS and signals. But they're kind of shifting some of that mindset and data flow approach. [01:00:46]
-
-**Carl Vitullo:** Yeah, man. Speaking of, funny to also talk about how patching globals is harmful and wow, I did not realize that Angular was patching globals quite that extensively. That is not great. [01:00:56]
-
-**Mark Erikson:** Angular 1 had some kind of a loop that would just keep checking the controller values to see if they'd been mutated and Angular 2 plus, so going on like the last seven or eight years. Has all relied on this tool called Zone. js to, like, monkey patch every source of asynchronicity in the browser. [01:01:15]
-
-**Carl Vitullo:** Yeah, that's a little bit wild. [01:01:17]
-
-**Mark Erikson:** Alright, I think we're out of things to talk about for now. [01:01:20]
-
-**Carl Vitullo:** 22 minutes over our planned time. Lot to get to this month. [01:01:23]
-
-Alright. Thank you so much everyone for joining us. We'll be back on the last Wednesday of the month here in the live stage in Reactiflux or back in your podcast feed just as soon as we can after that. [01:01:33]
-
-We gather sources from This Week in React, Bytes.Dev, React Status, Next JS, Weekly React Digest, the React JS subreddit, here in Reactiflux from the #tech-reads-and-news channel, and direct from those publishing articles, usually on Twitter or BlueSky. I'm not on threads, but maybe people post there. [01:01:51]
-
-If you see anything newsworthy, definitely let us know. You can do so in the #tech-reads-and-news channel here in Reactiflux, or you could send us an email to hello@reactiflux.com with T M I R in the subject line. It's an acronym for the show. I read literally every email that comes in, even ones marked as spam. So if you send me something to that address, I will read it. I may not reply, but I will read it for sure. [01:02:13]
-
-If this is a show that you get value from and want to support, the best way you can do so is by submitting a review, wherever you listen, and definitely tell your friends and coworkers about it. My thesis for the show is that there are a large number of people who are overwhelmed by trying to consume the fire hose. And so I'm trying to consume the fire hose for you and your coworkers. Yeah. [01:02:33]
-
-Thank you so much. Catch us next month. [01:02:35]
-
-**Mark Erikson:** Bye. [01:02:35]
-
-**Mo Khazali:** Bye everyone.
diff --git a/src/transcripts/tmir-2024-06.md b/src/transcripts/tmir-2024-06.md
deleted file mode 100644
index 54a471c..0000000
--- a/src/transcripts/tmir-2024-06.md
+++ /dev/null
@@ -1,703 +0,0 @@
----
-title: "This Month in React, June 2024: React 19 delayed (drama-ish), why no JS Laravel, TS 5.5 and more"
-date: 2024-06-26
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- Quick hits
- - [[00:51](#layoffs-updates)] [Layoffs.fyi](https://layoffs.fyi/)
- - [[01:35](#the-riseand-fallof-the-software-developer)] [Software jobs down 20% vs 2018? From ADP](https://www.adpri.org/the-rise-and-fall-of-the-software-developer/)
- - [[02:12](#new-releases)] New releases
- - [Turborepo 2.0](https://turbo.build/blog/turbo-2-0)
- - [React Admin v5](https://marmelab.com/blog/2024/06/20/react-admin-v5.html)
- - [Rsbuild 0.7](https://rsbuild.dev/community/releases/v0-7)
- - [Biome 1.8](https://x.com/biomejs/status/1797963672004043040)
- - [Astro 4.1](https://astro.build/blog/astro-4100/)
- - [Valibot 0.31.0](https://valibot.dev/blog/valibot-v0.31.0-is-finally-available/)
- - [[06:51](#upcoming-conferences)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [React Nexus](https://reactnexus.com/) July 4-5, 2024. Bangalore, India
- - [Chain React 2024](https://chainreactconf.com/) July 17-19, 2024. In person in Portland, OR, USA
- - [The Geek Conf](https://thegeekconf.com/) July 25, 2024. Berlin, Germany
- - [WeAreDevelopers World Congress](https://www.wearedevelopers.com/world-congress) Berlin, Germany & Online July 17-19
- - [CityJS Singapore](https://singapore.cityjsconf.org/) Singapore, Singapore July 24-26
- - ~~We Love JS~~ Unfortunately this appears to be a [fake event](https://twitter.com/_jessicasachs/status/1811394314112565301)
- - [React Rally](https://www.reactrally.com/) August 12-13, 2024. Salt Lake City, UT, USA
-- Main Content
- - [[09:43](#suspensegate)] [React 19 delayed](https://github.com/facebook/react/pull/26380)
- - [[09:55](#this-is-the-exact-build-well-release-as-190)] Previously, per Andrew: [React 19 _was_ ready to release](https://x.com/acdlite/status/1797668537349328923)
- - TKDodo: [React 19 and Suspense - A Drama in 3 Acts](https://tkdodo.eu/blog/react-19-and-suspense-a-drama-in-3-acts) , and also [How React 19 (Almost) Made the Internet Slower](https://blog.codeminer42.com/how-react-19-almost-made-the-internet-slower/)
- - [[19:03](#joe-savona-some-thoughts-on-the-suspense-changes-from-19-rc)] [Joe Savona “We'll hold the 19 release”](https://x.com/en_JS/status/1803480672327311425)
- - What does the React team _want_ for data fetching?
- - Seb: [“We never released official Suspense on the client, we did RSCs instead”](https://x.com/sebmarkbage/status/1801258093327593717) and [“Some people got the render-as-you-fetch memo. Some people chose to ignore it.”](https://x.com/sebmarkbage/status/1801294251965198578)
- - Andrew: [“the community shouldn’t think ‘we bullied React into changing fetching strategies”](https://x.com/acdlite/status/1803551296974168171).
- - Related: how do we communicate with the React team?
- - [[21:33](#tanner-linsley-react-needs-a-permanent-working-group)] [Tanner Linsley: “I feel there needs to be a permanent React + community working group”](https://twitter.com/tannerlinsley/status/1802798385810018769)
- - [Joe Savona: “we’re working on ideas to get feedback earlier and more users trying canaries”](https://x.com/en_JS/status/1803480684331483644)
- - [[23:42](#tc39-proposal-advances)] [TC39 proposals advanced](https://x.com/robpalmer2/status/1801239842908438694)
- - [[26:05](#react-partners-with-codemod)] [Codemod partners with React](https://codemod.com/blog/react-announcement)
- - [[27:52](#react-compiler)] React Compiler
- - [[28:03](#i-tried-react-compiler-today,-and-guess-what-)] [I tried React Compiler today, and guess what... 😉](https://www.developerway.com/posts/i-tried-react-compiler)
- - [[29:32](#understanding-react-compiler)] [Understanding React Compiler](https://tonyalicea.dev/blog/understanding-react-compiler/)
- - [[29:50](#why-dont-we-have-a-laravel-for-javascript-yet)] [Why We Don't Have a Laravel For JavaScript... Yet](https://wasp-lang.dev/blog/2024/05/29/why-we-dont-have-laravel-for-javascript-yet)
- - [Why Don't We Have A Laravel For JavaScript?](https://www.youtube.com/watch?v=yaodD79Q4iE)
- - [[35:45](#vercel-ship-2024)] [Vercel Ship 2024](https://vercel.com/blog/vercel-ship-2024)
- - [[37:35](#ts-55)] [TS 5.5 released](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5/?ck_subscriber_id=1888282043)
- - [Matt Pocock breaks it down](https://www.youtube.com/watch?v=sciBO_IaxTw)
- - [[40:41](#mind-the-gap-talk)] [Mind the Gap by Ryan Florence](https://www.youtube.com/watch?v=1g5ruM-16_Y&t=7595s) at Big Sky Dev Con
- - React Native Stuff:
- - [[41:36](#lorenzo-sciandra-exiting-react-native)] [Lorenzo leaving RN world 😭](https://x.com/Kelset/status/1800158749811966280)
- - [[43:47](#expo-atlas)] [Expo Atlas available](https://expo.dev/blog/introducing-expo-atlas)
- - [[46:40](#expo-adds-compiler-support)] [Expo adding React Compiler support](https://github.com/expo/expo/pull/29168)
- - [[46:52](#starlinks-react-native-app)] [Starlink’s RN story](https://www.notjust.dev/blog/react-native-starlink)
- - [[47:14](#expo-router-35)] [Expo Router 3.5](https://twitter.com/Baconbrix/status/1788235769812795559)
- - [[48:16](#sf-symbols-beta-support-in-expo)] [SF Symbols Beta Support in Expo](https://docs.expo.dev/versions/latest/sdk/symbols/)
-- ⚡Lightning round ⚡
- - [[50:03](#react-internals-explorer)] [React Internals Explorer](https://jser.dev/2024-05-11-introducing-rie/)
- - [[50:44](#whats-new-in-javascript-frameworks-for-may-2024)] [What's new in JavaScript Frameworks (May 2024)](https://developer.chrome.com/blog/frameworks-may-2024)
- -[[51:24](#memory-leaks)] Memory leaks:
- - [Memory Leaks from LocalAsyncStorage?](https://lucumr.pocoo.org/2024/6/5/node-timeout/)
- - [Sneaky React Memory Leaks: How useCallback and closures can bite you](https://schiener.io/2024-03-03/react-closures)
- - Follow-up: [Sneaky React Memory Leaks II: Closures vs React Query](https://schiener.io/2024-05-29/react-query-leaks)
- - [[52:21](#data-fetching-patterns-in-single-page-applications)] [Data Fetching Patterns in Single-Page Applications](https://martinfowler.com/articles/data-fetch-spa.html) from the Martin Fowler blog
- - [[57:19](#migrating-to-the-next-app-router-with-zero-downtime)] [Modularizing React Applications with Established UI Patterns](https://www.icodeit.com.au/posts/modularizing-react-apps)
- - [[58:12](#deno-standard-library-nearing-10)] [10 modern Node.js runtime features to start using in 2024](https://snyk.io/blog/10-modern-node-js-runtime-features/)
- - [Migrating to the Next.js App Router with Zero Downtime](https://workos.com/blog/migrating-to-next-js-app-router-with-zero-downtime)
- - [Deno announces the standard library is nearing 1.0](https://deno.com/blog/stabilize-std)
- - [[59:11](#why-dont-we-do-acid-tests-anymore)] [Why don’t we have things like the Acid3 test anymore?](https://twitter.com/vcarl_/status/1805627502036983995)
- - [[01:03:09](htmx-simplicity-in-an-age-of-complicated-solutions)] [htmx: Simplicity in an Age of Complicated Solutions](https://www.erikheemskerk.nl/htmx-simplicity/)
-
-[00:00] **Carl Vitullo:** Hello, thanks for joining us. This is June's edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers.
-
-[00:13] I'm Carl, I'm a staff product developer and freelance community manager here at Reactiflux, where I run community programs like these events and build tools that help keep the community going.
-
-[00:24] **Mark Erikson:** Hi, I'm Mark Erikson. My day job is working at Replay. io where we're building a time traveling debugger for JavaScript. And outside of that, I do Redux stuff.
-
-[00:33] **Mo Khazali:** Hi everyone. I'm Mo. I head the mobile team at Theodo. I'm quite active in the React Native community and I organized the React Native London meetup and here and there dabble in open source with a couple of libraries in the React Native ecosystem. Very happy to be here.
-
-[00:47] **Carl Vitullo:** Uh, I'm just going to start off with some quick hits of new releases and conferences.,
-
-## Layoffs updates
-
-[00:51] **Carl Vitullo:** Starting off immediately, because the market, the job market is so bad, I've been reading off stuff from layoffs.fyi.
-
-[00:59] We're not quite at the end of June, it's a couple of days left at time of recording, but most of the way through June, we're at about 9. 2, 000 laid off from 40 companies, which is down, I mean compared to six months ago we're down substantially, but compared to two years ago we are up substantially, so it's still not great. I've seen some other broader metrics trickling out from other places, like I saw a link from ADP that I unfortunately don't have handy suggesting that the overall like, tech market is at about 80 percent of it was, I believe, compared to 2018.
-
-### [The rise—and fall—of the software developer](https://www.adpri.org/the-rise-and-fall-of-the-software-developer/)
-
-[01:35] **Carl Vitullo:** Yeah, I, I found that really interesting because between hearing headlines about like record hiring during the pandemic and record layoffs in the two years, after that, it was like, Where do we end up? So that's the first data point I've seen, uh, addressing that question of, like, what's the net gain loss, and it suggests net loss of, like, 20%, which seems massive, but yeah, it's also, it's ADP, I don't know how much to trust that, I would assume that they got a very large sample size, but I'm not sure how they defined, like, tech, so, I don't really know how to interpret that in, through a lens of like software development.
-
-## New Releases
-
-[02:12] **Carl Vitullo:** But yeah, moving on to some new releases.
-
-### [Turborepo 2.0](https://turbo.build/blog/turbo-2-0)
-
-[02:14] **Carl Vitullo:** There is TurboRepo 2. 0. That's probably especially relevant if you're doing stuff with Next. It looks like it's mostly like a fancier UI. They're doing like a pretty high effort in terminal UI. Like it's, you know, reactive and interactive. And you can now break down your logs on a per task basis rather than it just being, you know, a constant scroll back the way terminals usually are.
-
-[02:38] So that seems neat. Oh, they had some new docs, and it looks like they included some, like, fundamental information about Monorepos, which seems cool.
-
-## React Admin v5
-
-[02:47] **Carl Vitullo:** React Admin released version five. We actually had Francois Zaniotto, hope I'm not mispronouncing that, on as a guest a couple of weeks ago, and I think he's super cool.
-
-[02:57] I love his ethos for the company that he's building, which maintains React Admin and does agency work. So I just wanted to shout that out.
-
-### [Rsbuild 0.7](https://rsbuild.dev/community/releases/v0-7)
-
-[03:04] **Carl Vitullo:** RS build released version 0. 7, which they say is going to be the last release before 1. 0. Mark, you had some thoughts?
-
-[03:14] **Mark Erikson:** ByteDance, the folks behind TikTok, have a massive web tooling infrastructure team. They've actually rebuilt Webpack in Rust, and I know that, you know, rewrite it in Rust is its own meme at this point, but it seems like they've, they've truly built a Webpack compatible version in Rust called RSPack. On top of that, they have a higher level abstraction layer called RSBuild, which has an easier configuration format, a little bit like ESBuild does. if you actually look in their docs, they have a migration guide for switching from Create React app to RSBuild. I did that on a little side project a few months ago.
-
-[03:55] It was really easy to switch and the compile time dropped from like 30 seconds to less than a second. it feels like a, an actually viable competitor tool.
-
-[04:06] **Carl Vitullo:** Nice. Super cool.
-
-### [Biome 1.8](https://x.com/biomejs/status/1797963672004043040)
-
-[04:08] **Carl Vitullo:** We've also got biome 1. 8. Yeah. I have a soft spot for biome. I was an early supporter of Rome. I have been eager to see what comes out of that.
-
-[04:17] So yeah, it looks like they've got like new support for CSS. They have better support for language servers in workspaces, so if you've got like a big monorepo, it should work a little bit better. New reporters, migration, some more linting options, but yeah, Biome is like kind of an all in one. They try to do like formatting and linting and, yeah, it's a bundle play.
-
-[04:38] They're taking in a bunch of tools that, were separate and doing it all as one package.
-
-[04:42] **Mark Erikson:** And written in Rust.
-
-[04:44] **Carl Vitullo:** Written in Rust. Sure. So super fast, blazing fast. Is blazing fast still cool?
-
-### [Astro 4.10](https://astro.build/blog/astro-4100/)
-
-[04:51] **Carl Vitullo:** There's also Astro 4. 10. I am hoping to play around with Astro this month. So maybe I'll be able to actually, you know, say some more intelligent things about what the experience is.
-
-[05:01] But I, I know lots of people who love the tool. It looks like some small improvements, nothing too major.
-
-### [Valibot 0.31](https://valibot.dev/blog/valibot-v0.31.0-is-finally-available/)
-
-[05:06] **Carl Vitullo:** This is a new library to me, Valibot released 0.31.
-
-[05:10] It's a competitor to Zod, which does like schema validation or, you know, data validation through a schema with like type generation and all that kind of stuff.
-
-[05:19] This looks like a pretty solid competitor. They talk about, tree shaking and stuff, which I'm broadly skeptical of tree shaking as a general promise. It's very difficult to verify.
-
-[05:30] **Mark Erikson:** My understanding is that Zod, when you import it, you're basically importing a giant object that has all the possible validation types built in, and I think Valobot's sales pitch is that it's a bunch of individual functions, and so you would only import the actual bits that you need.
-
-[05:47] And therefore, you're not getting a giant blob of runtime code.
-
-[05:51] **Carl Vitullo:** Yeah, I think they said it was like, could be up to like 95 percent smaller than Zod, while also like significantly simplifying the mental model of the schema and the type validation.
-
-[06:02] If I can think about it less and have it affect the size of my code less, like both of those sound like things that I would want.
-
-[06:10] **Mo Khazali:** I guess the thing is, it's a question of how much you want to really optimize your bundle size and at what stage you're at. If I'm recalling correctly, Zod minified and gzipped was about 60kb, something around that size.
-
-[06:22] So it is quite a chunky library to add into your dependencies. So, I guess if this actually delivers on that promise and it's closer to 90 percent less than that, which is I guess 6kb, it wouldn't be too bad of a shave to do, I'd say. But, remains to be seen if it's in practice going to be that good.
-
-[06:40] **Carl Vitullo:** Yeah, I just pulled up Bundlephobia for Zod, and it's, yep, 61kb minified, 14kb minified and zipped. Which is Hefty. Yeah, that's enormous. That would give me a lot of pause.
-
-## Upcoming Conferences
-
-[06:51] **Carl Vitullo:** Onto some conferences. Mo, I think you had a few.
-
-[06:53] **Mo Khazali:** Yeah, I'll jump right in.
-
-### [React Nexus](https://reactnexus.com/)
-
-[06:54] **Mo Khazali:** So, firstly, at the very beginning of July, 4th to 5th of July, React Nexus is happening in India.
-
-[07:00] One of the great conferences that I attended last year, I really enjoyed. The crowd there was quite a, quite a large crowd as well. I think there's about 500, 600 people. So a massive conference, but people are so friendly and I got to meet a lot of lovely people. So would highly recommend if you're sort of in the South Asia region to, to definitely give it a shot, if you can make it to Bangalore.
-
-### [Chain React](https://chainreactconf.com/)
-
-[07:19] **Mo Khazali:** Mid July, we have Chain React and this is hosted by the folks at Infinite Red. Another one of those great conferences. I've not been to Chain React myself, but I'm, So involved in the React Native community that I get told every year, why are you not at Chain React? And you're missing out on one of the best conferences ever.
-
-[07:34] So the FOMO hits real hard every time around Chain React. The folks at Infinite Red are absolutely amazing, and they organized an incredible conference from all accounts that I've heard of. Everyone really loves Chain React, so if you are in the U. S. and you're in the React Native scene, you really do not want to be missing Chain React. If I was in the U. S., I would definitely be at Chain React this month, so I cannot give it more praise than that.
-
-### [GeekConf](https://thegeekconf.com/)
-
-[07:58] **Mo Khazali:** And then, lastly, towards the end of July, we have GeekConf, so GeekConf is another sort of React Native conference with a little bit of a blend of web as well added into it. So that's happening on the 25th of July in Berlin. There's also a day that's dedicated to remote track, but 25th of July is the key date that's going to be happening in person, and I'll be speaking at that conference as well, and hopefully if any of you folks are there, please do come around and say hi, would be lovely to meet some of you in person.
-
-[08:24] **Carl Vitullo:** Heck yeah.
-
-### [WeAreDevelopers World Congress](https://www.wearedevelopers.com/world-congress)
-
-[08:25] **Carl Vitullo:** Leaving the list of conferences that us as hosts have personal experience with, there's a We Are Developers World Congress in Berlin, July 17th through 19th.
-
-### [CityJS Singapore](https://singapore.cityjsconf.org/)
-
-[08:35] **Carl Vitullo:** There's a CityJS in Singapore. That's going to be July 24th through 26th.
-
-### [We Love JS Amsterdam](https://welovejs.vercel.app/)
-
-[08:42] **Carl Vitullo:** We love JS in Amsterdam in the Netherlands, August 9th and 10th.
-
-### [React Rally](https://www.reactrally.com/)
-
-[08:46] **Carl Vitullo:** And then the last conference that we're highlighting in the next two months is React Rally, which is going to be August 12th through 13th in Salt Lake City. Actually, I have been to that one in the past and it was pretty quality.
-
-[08:58] **Mark Erikson:** Yeah, I, I would also. Emphasize like React Rally has been fantastic. the organizers are great.
-
-[09:04] they do a really good job of giving it a good community feel. I was there last year and attendance was unfortunately just a little down because of trying to revive it after COVID. So if, if you can all make it to React Rally in August, please go. It's, it's totally worth, worth it.
-
-[09:19] **Carl Vitullo:** Yeah, and it's the home neighborhood for a lot of really big people in the React and web ecosystem.
-
-[09:25] there are quite a number of people who live generally in Utah and in Salt Lake City. I think Kent C. Dodds is out there.
-
-[09:32] **Mark Erikson:** Kent, Tanner, Ryan.
-
-[09:33] **Carl Vitullo:** Yeah, it's their home neighborhood. I assume they'll be at the conference. Yeah, anyway, cool. All right, moving on to some of our main content here. Mark, you want to start us off?
-
-## "SuspenseGate"
-
-[09:43] **Mark Erikson:** Boy, oh boy, oh boy. Okay, welcome to SuspenseGate. So, for the for those of you who may not have been following all the drama on Twitter, we're here for you.
-
-### ["This is the exact build we'll release as 19.0"](https://x.com/acdlite/status/1797668537349328923)
-
-[09:55] **Mark Erikson:** About a month ish ago, a month and a half ish ago, Andrew Clark actually tweeted that, We've, we've updated to a new React 19 release candidate, and we think that this release candidate is going to be the final one, like, these are the actual bytes we plan to release as React 19, unless there's any other major changes.
-
-[10:17] Well, there is now cause for major changes. And in fact, React 19 has been delayed semi indefinitely. The React team is going to be doing some updates, and we don't know how long that's going to take. Why are they doing these updates?
-
-[10:32] In November of last year, Andrew Clark put up a PR that changed the behavior of the suspense component and how it manages loading children that are suspending to fetch data.
-
-[10:44] Previously, if you had multiple children inside of suspense, And they all wanted to fetch some data. The suspense component would give each of these components a chance to start rendering and start the data fetching. And then actually pause and wait for all of the components to finish fetching their data.
-
-[11:04] Doing it all in parallel, kind of like a promise. all combination. And with this PR, the React team changed it. So that React really only gives the first child that suspends a chance to fetch, and then it waits for that child to finish loading its data, tries to re render, and then keeps going until the next child component tries to fetch data.
-
-[11:28] Basically doing all of that in serial instead. Now, they, if you look at the PR, Andrew listed some potential reasons for this. One is that this actually made Facebook. com load a little faster. But also, it has to do with how the React team thinks. that people should be doing data fetching on the client side.
-
-[11:51] And basically their argument is, you, you shouldn't be doing data fetching nested deep in the component tree. Instead, you should hoist it up to the top at like the route level or the page level instead. And so their argument is like, well, we don't think people should be doing this pattern much anyway.
-
-[12:11] So it's okay for us to change it. Now, this was done as part of React 19's development, and React 19 is a major version. So you can totally, you know, make changes. It's, it's legal under the terms of semantic versioning. And this was available in the React 19 Canaries, but as we all know, nobody actually tries out pre release versions, everyone waits until it's actually released, and then tries it, and then reports bugs.
-
-[12:38] So, this basically went unnoticed by the community for months. And about a month ago, someone mentioned it on Twitter, very briefly, and TK Dodo, the maintainer of React Query, Saw that comment and said, oh, that doesn't look great, and then didn't think about it. And then just a couple weeks later, there was another discussion thread, and suddenly TK Dodo and a bunch of other people began to realize, wait a minute, this is actually a very significant change in how suspense works.
-
-[13:08] And in particular, the React 3 Fiber developers, which is the React for 3D game engines, Realized we depend on suspense heavily because we need to be able to load a lot of different things async like game assets. So it's not just about data fetching, it's about lots of other async behavior. And they, and they started showing demos where, everything went from loading in parallel to loading as a waterfall in serial.
-
-[13:38] And now example apps were way, way slower as a result. There was a massive firestorm on Twitter. A day or so later, Sophie Alpert from the React team said, We talked about this in a React team meeting today. We didn't realize how many people would be affected by this. But also, this was a very major change to React's internals. We did this, like, seven months ago. We've continued making lots more changes to the internal since then. We can't just roll back this change. We know what we would need to do in order to re enable the old behavior, but it's going to take another fairly significant set of internal changes to do that.
-
-[14:19] So, we don't know when we're going to get around to it. Stepping back for a second, at that point in time, the community conclusions were, they already said React 19 is release candidate and ready to ship, and we don't, like, we know this would take major changes. Therefore, the conclusion was React 19 is about to ship with this behavior and we're all going to be stuck with it for the duration of React 19 as a major release.
-
-[14:45] **Carl Vitullo:** Yeah, I don't know, some of the like firestorm framing for this, it makes me a little bit like, I don't know, it's, okay, this was a, this was a confusing behavior, and something that they overlooked, but I am glad that this conversation did happen.
-
-[14:59] And ultimately, the React team had this pointed out to them and did respond ultimately, I think, appropriately. So, like, it's, I don't know, how do you, How do you do open source development with millions of people, very few of whom actually try out pre releases?
-
-[15:15] **Mark Erikson:** Yeah, that actually even ties into the events this week of Jordan Harband and some of the package updates going on. Mo, you had a thought?
-
-[15:24] **Mo Khazali:** Well, I was just thinking, well, firstly, ironically, I remember when we did the last, last month's episode, we were talking about how this might be like the quickest release cycle for React, or, well, you know, it'll be a quick transition into Release Candidate and then released, and then this came up. So I find that quite funny that sometimes these things will come up and we can't predict it.
-
-[15:41] But I think it's, you know, around the whole expecting people to test canaries and, and release candidates, I almost wonder if there's a different way that that needs to be done and if there's some level of automation that can be done to ensure that not just, you know, apps that are using RSCs and are, you know, the most up to date and exactly architected in a way where Meta wants them to be architected, are tested, but rather, there's a whole wide range of apps, ones that are built over a long period of time, there might be SPAs or other things like that, all of those get tested. I don't know if there's a nicer way to handle that, but I feel like just expecting people to test Canaries and test RCs will not catch stuff like this .
-
-[16:20] **Mark Erikson:** That's the thing, I believe the Vue ecosystem has like a full fledged, I don't know the right term for it, they have a massive automation setup that tests all kinds of libraries across the ecosystem against the latest versions of like Vue and Vuex and Pinia and Vue Router and all these other tools. And similarly TypeScript, every time you push a PR to TypeScript, it does checks against almost all of DefinitelyTyped, or at least like a, the most widely used libraries on, on DefinitelyTyped and across the ecosystem, to try to catch a lot of these issues ahead of time.
-
-[16:56] But even then, there's a distinction between, do the library's tests fail, and how are people using that library. I think in this case, React Query had one test that did parallel fetching in a suspense, but it was like two components running locally. And so the effects of it would not have been meaningfully visible in terms of timing.
-
-[17:18] **Carl Vitullo:** Right. Right. And ultimately this is a like timing and parallelism issue. And I don't know, I'm not sure that that's something that would work. have been proactively tested? Like, I'm not sure that it's something that An automated test suite could like reasonably easily evaluate. And I'm not sure that someone would have said, Oh, this is a large enough risk that we need to invest, you know, several days of engineering time in order to make sure that we have test coverage that will flag this if it breaks.
-
-[17:48] So I don't know, I, to me, this is just like such a. Niche interaction between, you know, it's, it's such a corner case between the assumptions of the React core team and the, you know, evaluation work that they do against the Facebook project and the, you know, broader needs. So like, I don't know, I saw various negative takes, like, oh, I don't know, I saw lots of various negative takes, I'm not even gonna try and imagine, try and make up one.
-
-[18:16] **Mark Erikson:** the React Summit organizers for the last couple years Have done an event that they call the React ecosystem contributors summit, where they get like 25 to 30 maintainers and contributors to various tools and libraries together in a room. And they just give us a chance to vote on whatever topics we think would be worth discussing and then give us three hours to, talk about it in whatever way we think would be useful.
-
-[18:44] So, I was there. There were two topics that were discussed. Two thirds of the room was discussing the technical aspects of the suspense change, two thirds of the group was discussing the technical behaviors. One third of us were discussing, how can we have better communication and interactions with the React team.
-
-### [Joe Savona: Some thoughts on the suspense changes from 19 RC](https://x.com/en_JS/status/1803480672327311425)
-
-[19:03] **Mark Erikson:** A couple of days later, Joe Savona from the React team put up a long Twitter thread, which is very, very good and very worth reading. And he said, number one, we're going to hold off on the React 19 release. We agree that this is a major behavior change. And frankly, we underestimated how many people would be affected by this pattern change.
-
-[19:24] So they're going to step back and they're going to do something to do it. My, my, my assumption is trying to do the actual work to re implement some of the older behavior in the, in the reconciler internals. So that's good. Like the community complained, we communicated, they listened, they changed plans.
-
-[19:43] These are all actually very, very good things, but that ties into the communications question. Like a semi official way to communicate to the React team is by filing an issue, and the React issues are basically useless in that sense. One thing, they've been full of spam, both in terms of like really, really old issues and literal, literal spam issues, but also like the React team doesn't pay tons of attention to their issues list.
-
-[20:10] And so just filing an issue is not necessarily going to get like a quick response. There's Twitter, and a lot of the, you know, React team members are very active on Twitter, and that's great, but it's also not like a formal communications channel. So, what we concluded in our little set of people talking during this Contributors Summit, is that we really need to bring back this idea of a working group.
-
-[20:36] For React 18, the React team put together a React 18 working group where they specifically invited 50 to 75 people from across the ecosystem and continued adding to it over time. And there was a public GitHub repo where the React team and the invited contributors could write comments. Anybody could read it, so the discussions were public, but the idea was have a high signal ratio of meaningful discussions and questions about React 18, how things worked, how people could actually use some of the features and what the practical results would be.
-
-[21:12] And I think that was a great success. Like, there was a lot of really good information in that repo. So our conclusion, as the little group of people talking amongst ourselves, was we should somehow have a permanent version of the working group. And actually, Tanner Linsley independently tweeted the same thing a few days later, as well.
-
-### [Tanner Linsley: React needs a permanent working group](https://twitter.com/tannerlinsley/status/1802798385810018769)
-
-[21:33] **Mark Erikson:** So along with that, Joe Savona also said in his tweet thread that we are actively looking at how can we get more feedback on pre release versions and how we can actually Have better communication with the community. So, I don't know exactly what will happen, but I'm hopeful that something like this working group model would be an option going forward.
-
-[21:55] **Mo Khazali:** That's not, you know, too far away from how the React Native team does it, you know, for, for the past couple of years, I'd say, since, you know, Nicola Corti and Riccardo have come into the React Native team, they've been pushing this sort of release cycle where they'll have two, three different people from the community owning the release process for each version of React Native that comes out, and that Inherently add some level of community involvement to the releases.
-
-[22:17] Obviously a working group with more and more and more people, you know, about 60, 70 people sounds like there's going to be even more exposure, which is great. But I think it's, it's something that could take a page out of the React native core teams book as well, because they've done it successfully there.
-
-[22:29] **Mark Erikson:** Overall, takeaways are, nobody tries pre release versions, we really need a formal communications channel between the React team and the community that they will pay attention to, and that we can collectively offer feedback that they will see.
-
-[22:44] **Carl Vitullo:** Yeah, I, I, I chimed in on that because I don't know, Reactiflux, we're a thriving subset of the community.
-
-[22:50] Maybe we could be a neutral space for that type of communication to happen where they don't need to own the moderation side of things that has not turned into a conversation. So, hey, maybe it will eventually, but yeah. Twitter is definitely, I'm not sure how effective it was ever as like a DevRel, you know, source of truth, but now, like, if you don't have an account, they don't even let you view tweets, so, I think it is past time, well past time for DevRel from the React team to go somewhere else. Like it is, it's been over a month since the last blog post. And other than that, I don't know where any communications from the React team out to the broader community come from. It's basically the blog and the Twitter and the blog is not active. So. Yeah, I hope that that working group concept turns into something a little more effective.
-
-### [TC39 proposal advances](https://x.com/robpalmer2/status/1801239842908438694)
-
-[23:42] **Carl Vitullo:** But yeah, okay, cool. Next subject, TC39 proposals. A bunch just came out. I'm just going to kind of run through this on the high level. Yeah, promise. try, it looks like it's pretty much just like a quick wrapper on, , you know, new promise, and then you immediately resolve with a value.
-
-[23:58] I've done that a number of times, so I guess there's a use case for this, but in the abstract I'm not really coming up with a great example of why you would want to just Take a synchronous value and make it a promise.
-
-[24:09] Deferred import evaluation seems useful. it's a way, it's a way of delaying execution of some parts of the import process when you're getting a module in.
-
-[24:20] You can, you know, mark it as deferred so that it will not actually evaluate the module. It'll still like parse it and do some other interpretation steps that I'm blanking out at the moment. But it will not actually evaluate the code until later on.
-
-[24:33] **Mark Erikson:** Basically this, this allows. Speeding up, like the initialization process by not running all the code in the application right away on startup, even though you know, you'll need some of that code later.
-
-[24:48] **Carl Vitullo:** Yeah. Okay. There we go. Another one was joint iteration. I thought this was pretty cool because I've needed this a number of times. It's a way of iterating over more than one. iterable at the same time. That's on stage 2. 7, which means it's still pretty far from getting shipped.
-
-[25:03] Error. isError seems very useful for, for types. I guess lots of new stuff is moving down the pipe, I don't know how many of these are super important to call out in great detail, but yeah, Mark, Mo, anything that caught your eye is particularly important?
-
-[25:18] **Mo Khazali:** I, I really think Error.isError is the one that I'm most interested in. Obviously quite a while away before it gets to adoption. It's still on the process step two, it's stage two, but hopefully very soon. Well, I don't know how long this process is going to take for them.
-
-[25:31] It was interesting. The TC39 meeting that they had was happening in Helsinki, uh, near Future Frontend, which was a conference that we gave a shout out to last month.
-
-[25:39] And I happened to be there. That was quite cool to see some of these folks gather together and how they chatted about some of these standards. Just being privy to those conversations was fascinating. So they have a, they have an incredible process that I've, I've not seen anything like before in any other sort of working group.
-
-### [Panel discussion at Future Frontend](https://youtu.be/29wHaG7eVPM?t=17422)
-
-[25:53] **Mo Khazali:** So quite interesting, would recommend. There's a, if you go onto the Future Frontend streams, they actually have a big panel discussion for, from the second day of Future Frontend, and they actually discuss some of these proposals in detail, which is quite cool.
-
-### [React partners with Codemod](https://codemod.com/blog/react-announcement)
-
-[26:05] **Carl Vitullo:** All right, let's move on to the next one.
-
-[26:08] This is, I'm, CodeMod they announced they are partnering with the React team to help migrate to React 19.
-
-[26:16] I know, I feel like the React team initially popularized the idea of CodeMods. So this is like not a surprise at all to me. I guess I wasn't really familiar, wasn't really aware of Codemod as like its own separate team. I see, you know, this is posted by the founder of CEO of Codemod, I guess.
-
-[26:34] So that's kind of news to me. But yeah, so there's gonna be more Codemods, I guess, to help your codebase stay up to date with React 19.
-
-[26:42] **Mark Erikson:** I am very familiar with code not code mods as a technical concept I had no idea there was an entire company devoted to building tools for code mods as like a corporate thing.
-
-[26:53] **Carl Vitullo:** Right, right as a technical thing Very familiar. I don't really understand what the business case for that would be. I don't know, I guess maybe consulting. Maybe it's a services business.
-
-[27:03] **Mo Khazali:** Apparently the way that they also make it more effective is that they apparently pair it with some AI. It might be a pivot, I don't know, but apparently they pair it with some AI and some nice CLI tools to make your code mods more effective. That's not an endorsement, I don't know if it works well, but that's seemingly their model.
-
-[27:20] **Carl Vitullo:** Makes me a little skeptical, but yeah, I don't know. Codemods generally are great.
-
-[27:24] Any migrations and like major refactorings like that are definitely substantially helped by having automated tools that do, you know, even if it's like 60 to 80%, that's still pretty great, but yeah, cool. So there's an official partnership there. So I guess there's a business that is writing these codemods and the React team is in collaboration with them to make sure that they work well.
-
-[27:45] That's cool. That's great. Love that it's not just the core team trying to do everything on their own. Yeah, Mark, you want to take us on to React Compiler?
-
-## React Compiler
-
-[27:52] **Mark Erikson:** Sure. So, React Compiler came out in beta at ReactConf, and so we're starting to get, you know, various examples of people trying it out hands on in the real world.
-
-### [I tried React Compiler today, and guess what… 😉](https://www.developerway.com/posts/i-tried-react-compiler)
-
-[28:03] **Mark Erikson:** There was a very good post from Nadia Makarevich, I believe is the name, who has written a number of excellent articles about React rendering in the past. And she tried it out on both some toy applications and some larger, real world codebases that she had. And she found that the results were mixed. She expected the compiler to optimize fairly large percentages of the components in those codebases.
-
-[28:29] And it only seemed to optimize like 20 or 30 percent. Now, , apparently the compiler tool does have a health check command that will tell you which components it would bail out of because those are breaking the rules of React. And I believe that the updated React lint rules can also give you an indication of which components might not get optimized.
-
-[28:51] But her takeaway, I believe her takeaway was You know what? Well, okay, like this, this seems promising, but if real world code bases aren't going to get, or are we going to have like 20 to 30 percent of the components improved, that's not quite what we were pitched. Now, I will note that, uh, Satya from the React, React compiler team, I believe commented here in Reactiflux that, hey, this article is great.
-
-[29:14] Like, we got to See these example apps that she posted about, and we've been doing a bunch of additional changes to make sure we're handling those cases. So, I mean, just because it didn't work perfectly in her case, doesn't mean that the compiler's bust. It just means that it's still a work in progress. So having that real world feedback is actually very good.
-
-### [Understanding React Compiler](https://tonyalicea.dev/blog/understanding-react-compiler/)
-
-[29:32] **Mark Erikson:** And then Tony Alicea, wrote an Excellent article that actually breaks down what the compiler does and what the output looks like and how it works in practice. So, very worth reading if you want to understand what the compiler actually does for you.
-
-[29:47] **Carl Vitullo:** Heck yeah. Cool. Yeah, I guess I'll move us on.
-
-### [Why don't we have a Laravel for JavaScript... Yet](https://wasp-lang.dev/blog/2024/05/29/why-we-dont-have-laravel-for-javascript-yet)
-
-[29:50] **Carl Vitullo:** I wanted to call out this There's been a lot of, conversation that I've seen around, like, Laravel, specifically, specifically Laravel, Theo put out a video that then somebody wrote a blog post replying to of, " why don't we have a Laravel for JavaScript?"
-
-[30:06] And this actually crossed my radar from somebody who's not in the React world at all, they were talking about scoping a project, adding authentication to some app. And they said, "this developer estimated two weeks to add authentication to the product and I thought that was ridiculous. We have that out of the box in Laravel."
-
-[30:24] I, I, I chimed in because it's like, you know, I've done auth a couple of times in my life, in my career and like, yeah, you know, okay, sure. A login form, that's not hard to do in a day, but when you get like a settings page and you know, you got to be able to change your email address and reset your password and do two factor authentication and, you know, social login, It's like, you know, I mean, two weeks doesn't sound that wrong to me.
-
-[30:48] And he replied like, All of this is, all of that, everything you just described comes out of the box in Laravel. And it's like, alright, you know what, okay, maybe we do complicate things a little bit. Maybe not overcomplicate, but I guess, it, it, we do have so much flexibility and modularity and ability to Write things from scratch in React and, you know, in the React ecosystem more broadly, maybe that we have, you know, as far as the pendulum swings, maybe we have stayed in maximum modularity mode for a little bit longer than might be optimal.
-
-[31:21] I don't know. I, I'm curious what you guys think of that. where's the trade off? Where's the optimal line between modularity and out of the box functionality? I
-
-[31:29] **Mark Erikson:** mean, I think a lot of it also is the, you know, the whole back end, front end split. I mean, Laravel, you know, PHP, Rails, Ruby, they are back end languages, and the use case is You know, like, you know, the back end is doing basically all the work for you, and then, you know, there, there might be some additional stuff on the front end.
-
-[31:53] And so I think the frameworks there, they've, they've been around longer, and also they evolved to have, we, we need to have everything the back end needs to do all the work. Whereas, JS has always had the front end, back end split, and it's not that we couldn't build something that was, you know, absolutely out of the box like that.
-
-[32:13] I mean, there are, you know, some examples of that in the JS ecosystem, but I think it's typically been much more of a, like, I just need a basic HTTP server like Express. to serve up my client side code and then go from there. So, I think the modularity is a big aspect, but then also the differences in, like, the ecosystem historically as well.
-
-[32:34] **Mo Khazali:** I do think, you know, I've spent a bit of time working in the Django world a little bit, and I can definitely see the appeal to having something like Laravel, where so much comes out of the box. Done for you. And that interconnectedness means that it is a lot smoother to do things like you mentioned, like settings on a profile to modify those things.
-
-[32:51] They're all like one centralized model in Django. And it's significantly easier to create those sort of CRUD operations for users on like a settings page. It doesn't take you weeks. It takes you a day. And I know a lot of people who've been developing a while, like they spent time in the PHP world or in the Python world with Laravel or Django, and then they, you know, started doing React in our company and they were all like, this sucks, really don't like doing this.
-
-[33:12] It was so easy with Django, but I guess it's the pendulum swings and we probably land on some sort of midpoint, you know, I wouldn't be surprised if people start building things on top of Next, which allows it to be a more full fledged opinionated server that also can render and template React code.
-
-[33:26] **Mark Erikson:** That's what Blitz was. Blitz started off as the whole suite of things to go with Next, and then they tried to fork Next, and then they gave up on that idea.
-
-[33:35] **Carl Vitullo:** Yeah, and I mean, I guess this is, over the last ten years, React has slowly, I feel like it's grown in scope of, like, where people want to use it.
-
-[33:43] Like, when I first started it, There was a lot of, put it in, like, this spot, this little rectangle on the website, like, that's where React goes, and several years ago, that moved into, most people are using React to build their entire app, like it owns the entire client side, and now we're moving Up the chain into React owns more of the server side as well.
-
-[34:05] So maybe that's just kind of like the, this projects like Laravel already owned the data model in the server. And they had to come from there into owning more of the client side to provide a better experience there. And they certainly don't compete with React there in any meaningful way. Like nobody would, I don't think anyone would seriously suggest that projects like Laravel are able to provide. An exact, or a highly comparable, interactive client side experience.
-
-[34:35] You know, as I'm saying that, nobody would argue that. I think DHH has seriously argued that.
-
-[34:39] **Mo Khazali:** I was gonna say DHH hasn't argued that yet.
-
-[34:42] **Carl Vitullo:** So, okay, people do People do argue that, but let me add the caveat of offline capable. I don't think anyone would seriously argue they provide an offline capable client side experience comparable to React.
-
-[34:54] And so, yeah, I guess, you know, now with, as server components expand in utility and capabilities, like, yeah, maybe we will start seeing more of a Laravel. Or Ruby on Rails type of full ownership of the experience, which would make it more easy. Because that's really the problem here is React isn't even aware of the data model in most applications.
-
-[35:18] So that makes it very hard to do CRUD interactions, if you don't have the data, if you don't have direct access to the data. I just thought that was a really interesting framing for this. Like I have all, I've, I've lived in React for many, many years. And so then seeing people talk about how quickly you can do common tasks in a Laravel, it's like, Oh, Shit. Interesting. That's, that is a big difference.
-
-[35:39] Cool. Let's move on to Vercel Ship, their conference roundup. Moe, do you want to take us on that?
-
-### [Vercel Ship 2024](https://vercel.com/blog/vercel-ship-2024)
-
-[35:45] **Mo Khazali:** Sure. just the general and quickly running through this, Vercel is obviously moving across and, and taking up more of the, more than just becoming a hosting platform, so.
-
-[35:54] There's pieces on how you can collaborate and people in different teams can collaborate and, you know, preview different sort of webpages. And we've seen some stuff like that and more focus on observability. So they've added things like metrics and feature flags. And so there was someone who actually commented on Twitter about how beautiful their toolbar was as well, which I thought was quite cool. But no, there's, there's like a lot of direction around like product collaboration and a push in that, in, in that direction. So that's quite interesting.
-
-[36:18] Just on the observability piece, I actually found it quite interesting that hosting providers are going in that space. So Cloudflare a few months ago acquired Baseline, which is also an observability tool, and I think they're trying to integrate it into their workers slash Cloudflare pages space, which is a competitor to Vercel's, you know, hosting platform plus their, their serverless functions that they've got.
-
-[36:37] So, or the edge functions that they've got. So I think it's interesting that a lot of them are moving. Past just hosting into that observability space as well. And I think there's going to be a pretty big competition in that space in the next couple of years.
-
-[36:48] **Carl Vitullo:** Okay. That makes sense. Yeah. I haven't yet played with this at all, but I think I've heard people discussing the Vercel, metrics and feature flagging and that, yeah, I think that the, tacking those onto the, to a hosting provider does make a lot of sense to me because I feel like you get, you start getting a lot more things for free if those are all bundled together into one thing, like, I don't know, just having used LaunchDarkly and other feature flagging tools like that.
-
-[37:14] It feels like if they knew when a release was happening, if those feature flagging tools knew when a release was happening, I can imagine various optimizations or improvements to the, like, developer experience, the experience of putting out a new release that could be enabled by that. So yeah, that's something I'm paying attention to.
-
-[37:34] We'll see how that goes.
-
-### [TS 5.5](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5/)
-
-[37:35] **Mark Erikson:** All right, next up, TypeScript 5. 5 is out. And the, the single biggest thing that is interesting about this release is what they're calling inferred Type predicates. So as a little bit of background, one of the nifty things about TypeScript is you can write code that does runtime checks, and TypeScript uses that to narrow down TypeScript type of a particular variable is.
-
-[38:00] And part of that is not just having like an if statement, but actually having separate functions that, for example, accept any value, and then they do some runtime checks and you tell TypeScript, if this function returns true, then the actual TS type of the value must be some more specific type. And so you can use that to tie together runtime checks and type and compile time behavior.
-
-[38:27] But the issue was that things like filter callbacks for arrays, which return a boolean, didn't do any of that narrowing. And so you might have, like, an array that could be, like, item or null, and you could do a check. In the filter callback and say, if thing is not null, you know, return true, which ought to tell you that by the time we're done, we only have actual items and no nulls.
-
-[38:53] But TypeScript wouldn't automatically narrow down the TS types based on callback functions like that. So with TypeScript 5. 5, they've improved the type inference. So that if you have a function that accepts some value and does some checks and returns a boolean, TypeScript will automatically try to narrow down the TS types of the output to be stricter.
-
-[39:18] And so, this is going to be a nice little quality of life improvement for a lot of different TypeScript use cases. One other interesting thing that I saw in there, is that apparently they're doing some syntax checking on regular expressions. Mostly just catching things like, you know, like you have too many parentheses in there.
-
-[39:36] But that one's actually pretty cool too.
-
-[39:38] **Carl Vitullo:** Yeah, definitely super cool. I, on my list of things that I, that would make me excited, like typescript checking regexes was not on there, so I, Very unexpected for them to even start moving in that direction. But like, heck yeah, please help me make my regexes a little more robust.
-
-[39:54] **Mark Erikson:** One other thing towards the bottom that's under the hood. So they've done some changes on their internal variable definitions. So that they get more optimized by the JavaScript runtime, basically making sure that the same fields always exist. And you don't like occasionally add an extra field to the object dynamically.
-
-[40:15] And so because of that, the runtimes are able to optimize the behavior. And they found that it actually improved compile times by like 5 to 10 percent just by making the fields more consistent.
-
-### [TypeScript 5.5 is a BANGER](https://www.youtube.com/watch?v=sciBO_IaxTw)
-
-[40:26] **Carl Vitullo:** Yeah, I also want to share, Matt Pocock did a really great, just like quick 10 minute video breaking down what's new in TypeScript 5.
-
-[40:35] 5. So definitely worth, he's just such a great TypeScript expert. Just wanted to call that out. Great resource.
-
-### [Mind The Gap talk](https://www.youtube.com/watch?v=1g5ruM-16_Y&t=7595s)
-
-[40:41] **Carl Vitullo:** Cool. I wanted to shout out a conference talk by Ryan Florence that came out of Big Sky DevCon. I saw quite a number of people referring to it as like the best talk I've seen in years. I don't know if I would go that far personally. It's a great, it is a great talk.
-
-[40:57] It's, it's kind of just, I think I would describe it as like an oral history of the Problem space that React Server Components is trying to address. It just sort of talks about like the difference between, you know, the server and the client and the network being in the middle and plots out a couple of different tools and where they live in that, You know, taxonomy.
-
-[41:19] Definitely worth checking out. I mean, Ryan Florence has been around for so, so long. So hearing him just do kind of a dump of history of a problem, I thought was really interesting. It was definitely worth listening to.
-
-[41:32] **Mo Khazali:** I'll jump in with some React Native stuff quickly.
-
-### [Lorenzo Sciandra exiting React Native](https://x.com/Kelset/status/1800158749811966280)
-
-[41:36] **Mo Khazali:** So first, and I'd say most significant news in this space is unfortunately that Lorenzo Sciandra from the Microsoft team is leaving the React Native world and also leaving Microsoft, which is, I would say personally, a pretty big blow to this, to this community.
-
-[41:51] He's been such an instrumental part of. Getting more and more community involvement inside of React Native. He's been doing React Native for more than six years and, you know, being based in the UK. I've known him personally for a couple of years now and such a lovely guy. And I think he's moving on to focus something around making sure that the tech space is A little bit healthier and a little bit more humane, as he likes to put it.
-
-### [debug:mind by Lorenzo 'kelset' Sciandra](https://www.youtube.com/playlist?list=PLiD6R_aXkpLiMfS2YrhSgtSj09JJCaP2y)
-
-[42:13] **Mo Khazali:** And he's been focusing on mental health struggles within the tech ecosystem and within, within a career of tech. So you should definitely check out his podcast called Debug Mind. But really just want to, from the bottom of my heart, say a big thank you to Lorenzo for everything that he's done over the last six plus years.
-
-[42:27] An absolute shame that he's leaving us, but I am very excited for everything that he's going to be doing afterwards.
-
-[42:33] **Carl Vitullo:** Yeah, I have repeatedly come across his name when I've looked for React Native resources. He's done so many great lists of like, I can't even remember the various types of lists he's done, but just like major projects in the React Native space and educational resources on React Native.
-
-[42:51] Yeah, definitely a big blow to have him exit the ecosystem.
-
-[42:55] **Mo Khazali:** And, you know, more than that, you know, I think Lorenzo has been sort of the person who's been trying to bring the meta team closer and closer to the community. So, you know, Lorenzo, for the first time that I went to Meta's offices, Lorenzo invited me and, Organize that with a lot of the Meta folks to, to bring me over and, you know, for me to be able to chat and bring some of my concerns over to some of the folks at Meta and, you know, that became more of a recurring thing, all thanks to Lorenzo.
-
-[43:17] So he's been very instrumental and he's one of those sort of open source maintainer that maintainers that really cares about the community. So yeah, definitely a big blow.
-
-[43:24] **Carl Vitullo:** Yeah, and earlier, Mark was talking about how the React Native team has been a little bit better than the React core team at interfacing, doing like working groups and things like that, and including the community and the development.
-
-[43:36] I wonder, I wonder what role he played in making that happen.
-
-[43:40] **Mo Khazali:** A major one, definitely. So, yeah, but. Best of luck to him. I'm sure he's got some amazing stuff lined up that he's going to be exploring next. And yeah.
-
-### [Expo Atlas](https://expo.dev/blog/introducing-expo-atlas)
-
-[43:47] **Mo Khazali:** Next up, one thing that I'm personally super excited about is Expo Atlas. So Expo Atlas is almost like a sort of bundle size visualizer, but taken to a little bit of a higher level.
-
-[43:57] And this is something that's been missing from the React Native ecosystem for a long time. So just a little bit of context. Bundle size has never been a concern for the React Native ecosystem, unfortunately. For, for, for better or for worse, because it's all sort of sent once in the bundle of an application, when you download it from the app store, people don't seem to really care that much about how much JavaScript you ship, so long as it's downloaded once it's done.
-
-[44:19] And, you know, things like app startup time and actually, you know, having a lot of JavaScript and runtime don't affect React Native apps as much because of. Things like Hermes existing, where you have an engine that will have some sort of like bytecode representation and not have to load the entire JavaScript bundle into, into its runtime.
-
-[44:35] So that's been a challenge when you're trying to take React Native and put it on the web and deal with this whole universal story. And so, you know, one of the things that I spent a lot of time around React Summit, speaking to Evan and Cedric from the Expo team about was, you know, how do we make sure that some of the third party libraries that have.
-
-[44:52] I've been creating over a long period of time in the React Native ecosystem, actually have small bundle sizes when you try to take them to the web. And Expo Atlas is kind of the take that the Expo team has at doing that, which is, well, a lot of these libraries are all CJS based, so if we just introduce tree shaking into the bundler for React Native, It's not going to necessarily solve that problem by itself because most of the libraries won't be tree shakable.
-
-[45:13] So then what's the way to do it? Well, let's just visualize the problem, see what libraries are bundling in a lot of crap, and then see if we can slowly start to, as a community, shave some of that off and improve the performance for React Native web apps. This is a slow burn. It's not going to. Change over the next year, two years, maybe even three years, because there's a lot of legacy there.
-
-[45:31] But I think it's the right step. It's showing and visualizing the problem. So great tool that's out there. We'd definitely check it out. It shows you in a different way to how like the bundle visualizers that you might be used to, it actually shows you which import of a library you have in your code that is actually causing this library that might be bloating your bundle to be loaded.
-
-[45:50] So, you know, it might, it goes down the tree for transitive dependencies as well, which is quite cool.
-
-[45:54] **Mark Erikson:** Oh, that's wonderful.
-
-[45:56] **Mo Khazali:** Really great tool.
-
-[45:57] **Carl Vitullo:** Yeah. I'm looking at this, the visualization of the blog post with the, you know, recursive squares showing the, the bundle size and, oh man, I remember almost a visually, almost identical tool, much less polished.
-
-[46:10] Clearly this has someone who did a design pass, but there was a very similar tool that came out for Webpack in like, I don't know, 2014.
-
-[46:19] **Mark Erikson:** There's been a number of them, Webpack Bundle Analyzer, Source Map Explorer, and a couple others.
-
-[46:25] **Carl Vitullo:** I, I like practically made a career out of like fixing performance issues just because I learned that tool and it actually enabled me to do things.
-
-[46:33] So yeah, cool. Love to see it. Love to see it in the React Native context. Definitely looks valuable.
-
-[46:38] **Mo Khazali:** Cool. So then a few sort of quick things.
-
-### [Expo adds Compiler support](https://github.com/expo/expo/pull/29168)
-
-[46:40] **Mo Khazali:** Firstly, Expo's now added React compiler support. We saw this in the React Conf app. It was already using the React compiler. So just, you know, if you want to try it out experimentally, you can use the React compiler and see how it works for your app.
-
-### [Starlink's React Native app](https://www.notjust.dev/blog/react-native-starlink)
-
-[46:52] **Mo Khazali:** Next up is Starlink's React Native story. So this was interesting because it came out during AppJS, which happened last month. So the Starlink app is, is obviously built with React Native and it uses a lot of the expo libraries and things like React 3 Fiber. And it's really cool to see how some of these tools that we all have available to us are used in practice in some pretty serious production apps.
-
-### [Expo Router 3.5](https://twitter.com/Baconbrix/status/1788235769812795559)
-
-[47:14] **Mo Khazali:** And then another quick fire one, minor changes to Expo Router in Expo Router version 3. 5. So, just some stuff like, you know, supporting the, the sort of the hash parameters. There's some stuff around native, native intents with deep linking that you'll need for having a more seamless handoff between different Devices, and also for allowing for certain links to, to come with more details to, to really augment the native functionality.
-
-[47:38] Another small thing that I think is quite important, that's not actually one of the top headlines with this, is that previously Expo router was using an, a non standard version of the request and response. And with this version, they've, they've standardized it a bit more, which is great because that should definitely be standardized.
-
-[47:55] And then a few. Other minor things that I'm just going to run through. One is React Native Vision OS won the Git Nation Open Source Award, which was quite cool. It's a really cool project. Definitely give it a shot. And the folks from Callstack were there at a bunch of these different conferences with Apple Vision pros, trying to get people to try out React Native with Vision OS, which was quite a fun thing to try out.
-
-### [SF Symbols beta support in Expo](https://docs.expo.dev/versions/latest/sdk/symbols/)
-
-[48:16] **Mo Khazali:** Next up there is sf symbols. So sf symbols is sort of an icon pack that comes default with iOS. It oftentimes feels very Apple esque and having that inside of your app means that the icons are uniform with the OS and they look and feel like it's an iOS application and Expo's added beta support for it.
-
-[48:36] This is an interesting one because React Native is obviously cross platform. The main targets that you'll have is an iOS and an Android app, so specifically supporting icon sets and an icon set that's available for iOS means that you may need to have some divergence in your code base if you want to really use those SF symbols, and you'll need to create or choose equivalent Android icons, so a little bit of an odd take, but I'll see you A lot of people seem to really want to use SF Symbols, even with React Native apps.
-
-[49:03] So I'm sure that there was a level of feature requests and community involvement in trying to get that working. So that's definitely there. And then lastly, React Native Screens. This is actually a library that you will rarely ever have to use directly inside of your application code, but it's actually being used under the hood by React Navigation, which is by far the most common navigation library within React Native.
-
-[49:25] And they've just added some extra minor improvements. One that's quite cool is transparent header support. Obviously on the native layer, there's functionalities on iOS and Android to be able to add a transparent heading that's got a little bit of a blur, and it comes up with some cool effects. You can do that in React Native with the, with the default navigation libraries.
-
-[49:43] So React Native Screens has been updated to support that on both iOS and Android now, which is just cool minor changes. And that's just about everything that's been happening in the React Native ecosystem in the last month.
-
-[49:53] **Carl Vitullo:** Nice. Excellent. Thank you for catching us up.
-
-[49:56] Okay, shall we move on to our lightning round, see how many links we can get through there?
-
-[50:00] **Mark Erikson:** Yes, because we're already an hour in, so moving right along.
-
-### [React Internals Explorer](https://jser.dev/2024-05-11-introducing-rie/)
-
-[50:03] **Mark Erikson:** I saw a really, really cool tool called React Internals Explorer. It looks like you write some React code in a sandbox editor. And then it actually digs into the React fiber tree and shows you the structures of that.
-
-[50:17] I haven't even had time to play with this, but just like glancing at it and seeing a screenshot. I'm actually really, really excited about this because I love digging inside React's internals. I know most other people don't need to, but this looks really helpful. And the author has already written a whole series of blog posts where they actually go straight into the React source code and explain how specific features of React are implemented under the hood.
-
-[50:41] So if you want to know how React works inside, very worth reading.
-
-### [What's new in JavaScript Frameworks for May 2024](https://developer.chrome.com/blog/frameworks-may-2024)
-
-[50:44] **Carl Vitullo:** Yeah. I wanted to call out a blog post from the Chrome team where they just, they do a recap. What's new in JavaScript frameworks for May, 2024. So this is, I guess this is old. It's undated. So I guess it must have come out last month, but they are just, they just quickly round up a bunch of.
-
-[51:02] they go through like Angular, Astro, React, Remix, Next, Vue, NUC, Solidsfelt, and a couple of others. Yeah. This is Adi Osmani is. One of the, you know, it looked like they did a video and wrote a blog post with it. I thought it was curious, or I thought it was interesting to see what the Chrome team thinks about JavaScript frameworks.
-
-### [Memory leaks](https://lucumr.pocoo.org/2024/6/5/node-timeout/)
-
-[51:24] **Mark Erikson:** There were a few different blog posts that touched on the theme of memory leaks. There was one that talked about memory leaks inside of Node, potentially if you're using the relatively new local async storage feature. the example there was with setTimeout.
-
-[51:42] Apparently, Node can be keeping track of async call stacks attached to the context storage, and so you could actually end up leaking a whole bunch of memory if you're using it in certain ways.
-
-### [Sneaky Memory Leaks](https://schiener.io/2024-03-03/react-closures)
-
-[51:53] **Mark Erikson:** Uh, similarly, there are also a couple of very good blog posts talking about potential ways you might end up with memory leaks in a React application.
-
-[52:00] In cases where you're using like use callback or use memo or with React query where you're writing functions that are doing data fetching or something like that, and they're closing over variables that are in scope and they might not even be getting used. But the closure keeps those variables alive longer than you would have expected.
-
-### [Data Fetching Patterns in Single Page Applications](https://martinfowler.com/articles/data-fetch-spa.html)
-
-[52:21] **Mo Khazali:** Cool. So next up is an article that's actually on Martin Fowler's blog. So Martin Fowler being the big thought leader and evangelist of, of all things, application development, period.
-
-[52:33] **Mark Erikson:** Enterprise architecture patterns.
-
-[52:35] **Mo Khazali:** You see, divisive at the best of times, Martin Fowler is, but there's, there's been more and more React articles popping on, and they're not actually written by Martin Fowler, but they're written by someone who works at, whose name is Juntao, or actually, I don't think he works at ThoughtWorks, but he's very close with Martin Fowler, so he writes on Martin Fowler's blogs.
-
-[52:53] And he's been doing some really cool work on writing articles that start from the basic principles and expand out and create more and more complex applications that explain a bunch of concepts. So his latest article is about data fetching patterns in single page applications, and it starts with basic React concepts, builds up around, you know, asynchronous states being handled on the client side, parallel data fetching, how do you handle fallbacks, and then things like pre fetching, and then kind of It takes you through this journey and tells you when you should use which one.
-
-[53:21] Would recommend it. It's a very, very long read, probably one of the largest blog articles I've seen in a very long while, but it's definitely worthwhile if you want to get a more holistic viewpoint. And he's written a lot of articles like this. Another great one that he's written just to give a shout out is called modularizing React applications with established UI patterns.
-
-[53:38] And this is one that Mark is not going to be very happy about, but this one is one of those, which is like, how do you enterprise ify React code, but it's actually a very interesting article that has some thoughts about how you should architect React apps. And some of those patterns, not all of them, are actually very good to make it easier for you to do things like testing and so on and so forth.
-
-[53:55] **Carl Vitullo:** Cheers. Yeah. Oh man, I remember reading Martin Fowler's blog like 15 years ago when I was like starting my career. So just for it to still be relevant is like a little bit mind boggling to me.
-
-[54:07] **Mo Khazali:** The website still looks like it's from 15 years ago as well.
-
-[54:10] **Carl Vitullo:** Yeah. It's unchanged from when I started reading it.
-
-[54:13] Yeah. Not a single change that I can identify.
-
-[54:16] Cool. Yeah. I wanted to bring up a blog from Snyk, a security. Firm, I don't know, security product service, 10 modern Node. js runtime features to start using in 2024. It's, I have always found it really tricky to stay on top of every level of development over time.
-
-[54:35] So I appreciate a little roundup post like this that just sort of calls out a number of new features that I may not have caught the release of. It's sometimes it's hard to see, see the each individual release. So the 10 that they call out are a test runner. Native mocking, native test coverage, watch mode, core pack, the env loader, some import meta fields for the **dirname and **file fields, native timers and promises, permissions module and a policy module.
-
-[55:08] Those last two are not super clear to me, but like the test runner and native mocking and test coverage. Super great to not have to pull in a third party tool for that. As well as, yeah, I mean, watch mode. The number of times I've installed NodeMon. If I can stop relying on a third party package for that, I'll be pretty happy.
-
-[55:26] I haven't checked that out yet, though. CorePack is actually, I feel like the name of it makes you compare it to Webpack, or it makes me compare it to Webpack, at least. But actually, it's, the main use for it is being able to specify a package manager at a specific version, which is so useful. Um, I appreciate that they have made it, I guess it's a, I guess it's a combination of being able to pin a specific version of your package manager, but it's also, I think, some underlying tools to make cross compatibility possible between package managers.
-
-[55:59] **Mark Erikson:** The primary issue is that NPM has always come pre installed with Node. But if you want to use Yarn or PNPM, or, Bun, I guess, you have to first use NPM to install those tools globally. And that's kind of a one off per system thing. And then you have to remind everybody that they're supposed to be using this package manager, the project.
-
-[56:22] And so I think the idea of CorePack is that if you specify in your package JSON, that, Hey, we're actually using Yarn 4. 1 or PMPM 9. 2. It will automatically do the work to make sure that the right package manager is available and being used in that project.
-
-[56:40] **Carl Vitullo:** Right. It fills the gap where, like, PackageLock or Yarn.
-
-[56:44] Lock will let you pin your dependencies, left the, you know, the gap of what about the version, you know, for the package manager because the different versions interpret that lock file slightly differently sometimes. Or, you know, I've had a more recent version of Yarn blow away my Yarn or, you know, start adding things like a, a digest half to the, to the lock file.
-
-[57:06] So being able to pin a version, super great. Yeah. As well as like having a env loader, so we don't need to use env anymore. But yeah, so I appreciated this as a quick summary of a number of new built ins for Node.
-
-[57:18]
-
-### [Migrating to the Next App Router With Zero Downtime](https://workos.com/blog/migrating-to-next-js-app-router-with-zero-downtime)
-
-[57:19] **Mark Erikson:** There was a very good post on migrating to the next app router with zero downtime. One of the pain points with server components is that you have to have the entire application set up with server components as the outer layer of the application in order to use them at all.
-
-[57:36] There's no straightforward, simple, like migrate, just a little piece of my component tree. And while you can use the app router with everything still on the client, as a client component, it's still a key step in order to even be able to think about using server components with Next. And so, this article was a good example of how a team with an existing Next app that used the Pages router was able to mimic the routing setup in the app router and carefully, step by step, make sure that things worked the same both ways.
-
-[58:05] Switch over and then be able to start using some server components piece within the existing structure.
-
-### [Deno Standard Library nearing 1.0](https://deno.com/blog/stabilize-std)
-
-[58:12] **Carl Vitullo:** All right, Deno announces that the standard library is nearing 1. 0. That sounds great to me. The standard library is now a collection of 38 packages, they say. I appreciated this. Rather than doing it all in one big bang 1.
-
-[58:26] 0 release for the standard library, they're actually going to repeat a process for bringing each of those 38 packages up to stable relief. So they're gonna do it through like a release candidate and then gather feedback with like a a one month timeline for each of those packages to gather feedback.
-
-[58:45] So yeah, that's A lot of effort, a lot of energy being invested into creating a standard library and oh man, here's a standard library for a JS runtime.
-
-[58:55] **Mark Erikson:** I'm confused. Are we allowed to have that?
-
-[58:57] **Carl Vitullo:** Right? It's, it, the classic criticism of JavaScript is the lack of a standard runtime.
-
-[59:02] So, oh my goodness, we have a standard runtime hitting stable. I feel like that's going to affect the ecosystem in some way, but we'll have to see what happens there. Cool.
-
-### [Why don't we do Acid tests anymore?](https://twitter.com/vcarl_/status/1805627502036983995)
-
-[59:11] **Carl Vitullo:** I'm going to call this one out. This was, I put, I put up one of my tweets. I don't know. I think it's a good question. I'm going to do it.
-
-[59:16] I proposed the question out, why did we stop making checks like the ACID3 test? Why isn't there an ACID3 test for, for example, progressive web apps? I remember the ACID test series of, projects was
-
-[59:30] **Mark Erikson:** Browser rendering behaviors.
-
-[59:32] **Carl Vitullo:** Browser rendering behaviors. It was, is the browser you're viewing the web page in standards compliant? Here is something. It should look like this. And I remember checking that in, you know, 2008 or whatever, when I was a wee baby nerd. And, my browser didn't render it correctly, and then a couple years later it did.
-
-[59:50] I was considering, like, what factors may have moved us away from things like that, and I feel like it used to be so hard to ship new things, new standards. That it took big coordinated pushes like that, or maybe the ecosystem was also just smaller and the number of players involved were, you know, it could fit in a room, but I feel like we've lost something a little bit in there.
-
-[01:00:12] Like the acid three test was CSS three was ratified as a standard. They put out an associated test for this rendering behavior so that. Users could check if their browser was working in compliance with the standards. And I guess I, I put up the comparison to progressive web apps because like, They are not fully rolled out, like Chrome put out, the Chrome team put out a lot of support for progressive web apps, very much as a attempt, I think, to make web pages viable as competitors to native apps, and it just kind of never really happened, I think in large part because we never got cross compatibility With all the browsers for those capabilities.
-
-[01:00:54] And I don't even know that we, as an ecosystem, as web developers, have a shared understanding of what makes a progressive web app, you know, what defines a progressive web app? How do you distinguish that what you've made meets all the criteria? So, I don't know. I just, it was lamenting our lack of those sort of litmus tests for, I guess, bringing a Technical definition to some of the terms that we throw around frequently.
-
-[01:01:21] **Mark Erikson:** It's, it's not quite what you're asking for here, but I can point to a couple ways that there's been more efforts to do interoperability efforts. One is I think the latest version of the speedometer benchmark for JS engines was specifically built to include a bunch of different things.
-
-[01:01:38] Reasonable, plausible example applications using various JavaScript frameworks. Like I know that there's like a React, Redux, Todo application as part of the benchmark sequence. So that's been an attempt to semi standardize things and make things a little more plausible. Also, I believe the last three or four years, all the major browser Vendors have done, I don't remember the exact term but like an interoperability effort where they identify like the top five or six pain points of places we know where browser behavior is differing and we're all going to make a push this year to make sure we all work the same way for these things.
-
-[01:02:15] So it's, it's not quite the same as having like the ACID3 test or, you know, a named version of CSS that we're all trying to implement, but it is, it is kind of along those lines.
-
-[01:02:27] **Carl Vitullo:** Right. Yeah. I don't know. I guess I, I, I think the branding that used to be baked in to those sort of releases served, I think to me, it served a valuable function in developer education. And I think that we've lost something through not having it.
-
-### [Web Platform Tests dashboard](https://wpt.fyi/)
-
-[01:02:41] **Carl Vitullo:** Like there was a web platform tests dashboard that like, yes, here is a single place that compares all of the features, accessibility, all of the compatibility across browsers, but it's not actually, you know, as a developer, it doesn't tell me what features are grouped together? What features go well together? What capabilities are unlocked by supporting this thing? We're going well beyond the scope of a lightning round link right now.
-
-### [HTMX: Simplicity in an Age of Complicated Solutions](https://www.erikheemskerk.nl/htmx-simplicity/)
-
-[01:03:09] **Mark Erikson:** all right, and last one we got on the list. HTMX is a library for basically adding attributes to HTML tags that do things like data fetching and automatically inserting the results into the page without having to explicitly write JavaScript yourself, and they put up a blog post entitled Simplicity in an Age of Complicated Solutions, where they have some examples of handling inputs and data fetching with VanillaJS or with React code.
-
-[01:03:37] And they point out and say, look at how complicated this is. Whereas if we just slap HTML into the page and we add a couple attributes, look at how simple this is. And there's, there's some valid trains of thought to this. Certainly you're writing less code as an application developer. I questioned a little bit some of their arguments on general principle, but it is worth reading for an alternate viewpoint on how application behavior should be implemented.
-
-[01:04:00] **Carl Vitullo:** Yeah, definitely interesting from a perspective of just considering expansion of complexity too. I thought that was, I thought it was cool to read from that lens too.
-
-[01:04:08] Cool. All right. That is all of the, all the links we have. Thanks everyone for joining us. We'll be back on the last Wednesday of the month in here in the live stage of Reactiflux or in your podcast feed as soon as we can after that.
-
-[01:04:20] **Mark Erikson:** Thank you for listening. Plug, please check out Replay. io for debugging your tests and trying to fix flakes. And also, I'm almost done with a very large revamp of the primary Redux tutorial to make it TypeScript first and explain more things. Carl just pasted a link to the draft PR in there. I would appreciate feedback.
-
-### [Revamp "Redux Essentials" tutorial](https://github.com/reduxjs/redux/pull/4706)
-
-[01:04:43] **Mark Erikson:** I'm hoping to have this done within the next couple weeks. Like, I'm almost done with the first draft, and then hopefully there's not too much more work to do. So, feedback, please?
-
-[01:04:52] **Carl Vitullo:** For sure. Awesome. Yeah. Mo, anything you want to add?
-
-[01:04:55] **Mo Khazali:** Nothing. Just thank you again for having me and always a lovely time chatting with you all and going over everything that's been happening.
-
-[01:05:02] And yeah, looking forward to the next one.
-
-[01:05:03] **Carl Vitullo:** Most definitely. Yeah. Always good talking to you guys. Cool.
-
-[01:05:07] we, we gather links from, um, a bunch of different sources, including thisweekinreact, bytes. dev, reactstatus, nextjsweekly, the reactjs subreddit. Right here in Reactiflux from the Tech Reads and News channel, um, and directly from people publishing articles, usually on like Twitter or Blue Sky.
-
-[01:05:26] If you see anything that you think that we should be paying attention to, definitely feel free to email us at hello at reactiflux. com with T M I R in the subject line. That's acronym for the show. I read every email that comes in, even the ones marked as spam. If this is the show you get value from and want to support, the best way to do so is to send it to someone.
-
-[01:05:45] Send it to your co workers, help them learn how you know so much about React. Otherwise, you know, submit a review, do stuff like that. But yeah, thank you so much for joining us. Appreciate it. See you next month.
diff --git a/src/transcripts/tmir-2024-07.md b/src/transcripts/tmir-2024-07.md
deleted file mode 100644
index 09fe1d9..0000000
--- a/src/transcripts/tmir-2024-07.md
+++ /dev/null
@@ -1,642 +0,0 @@
----
-title: "This Month in React, July 2024: State of React, State of JS, React, HTML"
-date: 2024-07-31
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- Quick hits
- - [[02:14](#job-market)] Job market
- - [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE)
- - [Layoffs.fyi](https://layoffs.fyi/)
- - New releases
- - [[03:48](#vitest-20)] [Vitest 2.0](https://github.com/vitest-dev/vitest/releases/tag/v2.0.0)
- - [Future plans](https://github.com/vitest-dev/vitest/discussions/5828)
- - [[04:06](#remix-210-fog-of-war)] [Remix 2.10](https://remix.run/docs/en/main/start/changelog)
- - [[04:24](#jotai-29)] [Jotai 2.9](https://github.com/pmndrs/jotai/releases/tag/v2.9.0)
- - [[04:34](#storybook-82)] [Storybook 8.2](https://github.com/storybookjs/storybook/releases/tag/v8.2.0)
- - [[04:52](#react-native-reanimated-314)] [RN Reanimated at 3.14](https://github.com/software-mansion/react-native-reanimated/releases/tag/3.14.0)
- - [[04:59](#htmx-20)] [HTMX 2.0](https://htmx.org/posts/2024-06-17-htmx-2-0-0-is-released/)
- - [[05:03](#mako-released)] [Mako is Now Open Source](https://makojs.dev/blog/mako-open-sourced)
- - [[06:01](#conferences)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[06:01](#react-rally)] [React Rally](https://www.reactrally.com/) Salt Lake City, UT, USA August 12-13
- - [[06:25](#react-universe)] [React Universe 2024](https://www.reactuniverseconf.com/) Wrocław, Poland September 5-6
- - [[07:23](#jsconf-chile)] [JSConf Chile](https://www.jsconf.cl/) Santiago, Chile September 5-7
- - [[07:32](#utahjs-conf)] [UtahJS Conf](https://utahjs.com/conference) Salt Lake City, UT, U.S.A. September 13
- - [[07:44](#react-alicante)] [React Alicante](https://reactalicante.es/) September 19-21
- - [[08:00](#jsconf-ireland)] [JSConf Ireland](https://www.jsconf.ie/) Dublin, Ireland September 25-26
-- Main Content
- - Survey results:
- - [[10:21](#state-of-html)] [State of HTML 2023](https://2023.stateofhtml.com/)
- - [[14:39](#state-of-react)] [State of React 2023](https://2023.stateofreact.com/en-US)
- - [[17:43](#state-of-js)] [State of JS 2023](https://2023.stateofjs.com/en-US)
- - [2023 State of JavaScript Survey Highlights: Vite Dominates, TypeScript Adoption Soars](https://socket.dev/blog/2023-state-of-javascript-survey-highlights)
- - [Dark Matter Developers: The Unseen 99%](https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99)
-- ⚡Lightning round ⚡
- - Company migrations:
- - [[37:54](#nyt-and-slack-update-to-react-18-enzyme-to-blame)] [NYT just updated to React 18](https://open.nytimes.com/enhancing-the-new-york-times-web-performance-with-react-18-d6f91a7c5af8)
- - [Slack converted from Enzyme to RTL with some AI assistance](https://slack.engineering/balancing-old-tricks-with-new-feats-ai-powered-conversion-from-enzyme-to-react-testing-library-at-slack/)
- - RN news
- - [[39:05](#rise-tools-launched)] [Rise Tools Launched](https://rise.tools/)
- - [[39:48](#mos-talk-about)] [Mo Khazali – Server-Driven Mobile Apps With React Native](https://youtu.be/vjTVnSUZVEk?si=KIURXZGKMz-gtRFB)
- - [[40:15](#nativewind-ui-launching)] [NativeWindUI launched](https://nativewindui.com/)
- - [[40:51](#gluestack-too)] [Gluestack is going in a similar direction with v2](https://gluestack.io/)
- - [[41:30](#swift-package-manager-support-moving-away-from-cocoapods)] [Swift Package Manager Support for React Native](https://github.com/facebook/react-native/pull/44627)
- - [[43:24](#react-native-filament)] [Using React Native MacOS with Expo](https://github.com/expo/expo/pull/30660)
- - [React Native Filament](https://twitter.com/mrousavy/status/1811354708235239680)
- - [[44:31](#react-native-for-web-devs)] [Guide to React Native for Web React devs](https://expo.dev/blog/from-web-to-native-with-react)
- - [[45:09](#build-windows-apps-from-a-mac)] [How to build Windows apps for React Native with a Mac](https://devblogs.microsoft.com/react-native/2024-07-18-running-rnw-from-a-mac-md/)
- - [[46:06](#ecosystem-performance-group-e18e)] [e18e (Ecosystem Performance) - A new community initiative | e18e](https://e18e.dev/blog/e18e)
- - [[48:10](#es2024-released)] [ES2024](https://tc39.es/ecma262/2024/)
- - [Tweet from Rob Palmer](https://x.com/robpalmer2/status/1806064466510897240)
- - [[49:00](#memory-leaks-compiler-wont-save-you)] [Sneaky React Memory Leaks: How the React compiler won’t save you](https://schiener.io/2024-07-07/react-closures-compiler)
- - [Garbage collection and closures](https://jakearchibald.com/2024/garbage-collection-and-closures/)
- - [How to publish a JavaScript package in 2024](https://www.youtube.com/watch?v=nl4B1asyMdI)
- - [[50:33](#react-native-flutter)] [React Native + Flutter](https://x.com/mdj_dev/status/1811317534936719562)
- - [[51:01](#bun-q3-roadmap)] [Bun’s Q3 roadmap (not exhaustive)](https://x.com/jarredsumner/status/1807731197046653438)
- - [[51:57](#learn-suspense-by-building-a-suspenseenabled-library)] [Learn Suspense by Building a Suspense-Enabled Library](https://www.bbss.dev/posts/react-learn-suspense/)
- - [[52:39](#marks-talk-why-use-redux-today-at-react-summit)] [Why Use Redux Today?](https://blog.isquaredsoftware.com/2024/07/presentations-why-use-redux/)
- - [[53:24](#chrome-collects-extra-data-for-google-websites)] [Chrome gives Google properties privileged information about your system resources](https://x.com/lcasdev/status/1810696257137959018?t=r9eYl5mMXDWVzZ9suZugjQ&s=19)
- - [[53:48](#component-composition-colocation)] [Component, colocation, composition: A note on the state of React | bobae kang](https://bobaekang.com/blog/component-colocation-composition/)
- - [[54:15](#secret-knowledge-to-selfhost-nextjs)] [Secret Knowledge to Self-Host Next.js](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)
- - Node news:
- - [[54:37](#node-can-strip-ts-types-soon)] [TS stripping](https://github.com/nodejs/node/pull/53725)
- - [[55:01](#native-sqlite-drive-in-node)] [SQLite support](https://nodejs.org/docs/latest/api/sqlite.html)
- - [[56:00](#node-moving-away-from-corepack)] [Removing experimental `corepack` tool for version managers?](https://github.com/nodejs/TSC/pull/1527#issuecomment-2258868015)
-
-[00:00] **Carl Vitullo:** Hello. Thanks for joining us for the July edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We are coming to you live from Reactiflux, the place for React developers.
-
-[00:13] And we actually have a sponsor this month. Woo! First time we're supported by Infinite Red, a consultancy that works exclusively in React Native. They've been around since 2015, have employees on the core team of React Native, and are super great.
-
-[00:26] I'm going to do a little more on them after we do introductions, but I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs and otherwise build tools to keep the community running.
-
-[00:39] **Mark Erikson:** I'm Mark, most of you know me as the guy who does Redux stuff, and as far as day job things go, I am actually looking for a new position, which is a bit of an interesting personal development, so if folks have suggestions for places I should be getting in touch with or that might be interested in me, please ping me and let me know.
-
-[00:59] **Mo Khazali:** And I am Mo. I head the mobile team at Theodo, and I'm an active community member within the React Native ecosystem. I organize the React Native London meetup and soon to be conference, and just contribute here and there, dabble a little bit into open source. Nowhere near as much as Mark does, but I do try.
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-[01:18] **Carl Vitullo:** Yeah, and a little more on our sponsor. Infinite Red is a expert React Native consultancy. I'm actually uniquely excited to get them specifically, Infinite Red, as a sponsor. They have been around, I've been seeing their name for the entirety of my career since I started in about 2014 with React. And they organize conferences, they host the largest React Native podcast, and generally have just shown up in very real ways to support the ecosystem and the community.
-
-[01:46] So I got a chance to connect with one of their founders, Jamon Holmgren at React Conf down in Las Vegas, and we just really vibed. They seem like really great people, they talk about how they are a team of 30 with mostly developers, mostly with more than 10 years of experience, and they work with your team to coach you on how to best use React Native.
-
-[02:07] So if your company is looking to build up some React Native expertise, definitely check them out. And thank you, Infinite Red, for sponsoring us.
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE) + [layoffs.fyi](https://layoffs.fyi)
-
-[02:14] **Carl Vitullo:** Cool. All right. On to some quick hits. Job market updates.
-
-[02:18] So there's a new source of data that I'm following, which is amusingly called FRED, an economic data set based out of the St. Louis Fed. So apparently the job site indeed does some like data analytics stuff that now the Federal reserve is relying on for like labor information. And this is a chart of software development job postings that have been posted to Indeed. And it is, indexed off the beginning of 2020. So it's more than doubles at about the start of 2022 and is down to about like 68 percent of that 2020 baseline and it's been pretty flat.
-
-[02:57] I really like this because I've been looking at layoffs. fyi for, you know, a year now and it just doesn't quite do it. It is, there's, there's enough, there's a lot of variability. It's only the source of Layoff. So this is kind of the other side. What does hiring look like? And unfortunately, hiring is flat to down, which is not great. But at least people aren't getting laid off as quickly anymore.
-
-[03:20] Yeah, speaking of layoffs, layoffs. fyi. This is the first time in, like, the A year and a half that we haven't had a, like, a pop of layoffs at the start of a new quarter. So that's a small positive sign. It's down versus last month in June and only the second time this year that we've had less than 10, 000 developers laid off. So, seems good. Hiring is not ticking up though.
-
-## New Releases
-
-[03:44] **Carl Vitullo:** Mark, you want to take us through some new releases?
-
-[03:46] **Mark Erikson:** Sure, a couple of the most interesting ones.
-
-### [Vitest 2.0](https://github.com/vitest-dev/vitest/releases/tag/v2.0.0)
-
-[03:48] **Mark Erikson:** Vitest 2. 0 is out. A bunch of small changes, but it's interesting to note that they're working towards a browser mode. Because we've had browser based testing for a while, but trying to focus on running unit tests in the browser. So, this has some very interesting potential there.
-
-### [Remix 2.10, fog of war](https://remix.run/docs/en/main/start/)
-
-[04:06] **Mark Erikson:** Remix put out a new release that has a fog of war feature, which looks like it's about trying to optimize downloads of route information. Looks like rather than bundling all the route information ahead of time, they will actually download chunks of it as you go, which should improve loading speed.
-
-### [Jotai 2.9](https://github.com/pmndrs/jotai/releases/tag/v2.9.0)
-
-[04:24] **Mark Erikson:** Uh, Jotai 2. 9 is out. And it looks like the public behavior is basically the same, but they've reworked the internals.
-
-### [Storybook 8.2](https://github.com/storybookjs/storybook/releases/tag/)
-
-[04:34] **Mark Erikson:** Storybook 8. 2 has, trying to look at the release notes, a few small changes, probably not a whole lot of big stuff.
-
-[04:42] **Carl Vitullo:** I've never quite understood the niche, the purpose that Storybook really serves. But, you know, hey, minor release, so it seemed worth calling out. I know it's pretty widely used.
-
-[04:52]
-
-### [React Native Reanimated 3.14](https://github.com/software-mansion/)
-
-[04:52] **Mark Erikson:** React Native Reanimated has 3. 14. So I guess there's your, there's your Pi release.
-
-### [htmx 2.0](https://htmx.org/posts/2024-06-17-htmx-2-0-0-is-released/)
-
-[04:59] **Mark Erikson:** Totally outside of React. HTMX just hit 2. 0.
-
-### [Mako released](https://makojs.dev/blog/mako-open-sourced)
-
-[05:03] **Mark Erikson:** And there is yet another Rust based JavaScript build tool that came out. This one's called Mako. I saw it. I'll be honest. I have no idea how this is any different than the other seemingly like 15 other Rust based build tools at this point.
-
-[05:20] **Carl Vitullo:** Mako has come out of the Ant design. That's what caught my eye as being notable.
-
-[05:24] So this is a Rust based developer being built by the team that put together one of the reasonably popular component toolkits. It seems notable for that reason to me. But yeah, yet another Rust based build tool. One more thing on Mako. They put up a bunch of benchmarks that show it being like 10 times faster than Webpack and noticeably faster than RSBuild 0. 6, which is pretty impressive. They also talked about like not being able to get it to work, getting their benchmark to work with the latest release of RSBuild, which is 0. 7. So who's to say if those benchmarks will really hold up, but yeah, cool.
-
-## Conferences
-
-### [React Rally](https://www.reactrally.com/)
-
-[06:01] **Carl Vitullo:** Some conferences coming up. We've got React Rally in Salt Lake City, August 12th and 13th. I've been to React Rally a couple of times Over the years and definitely a great one. I also noticed it's pretty much the only conference in August. I think because everyone's on vacation.
-
-[06:16] **Mark Erikson:** React Rally is wonderful. They've done a great job of really having a good community vibe over the years. I should be there. So folks want to come by and say hi, please do.
-
-[06:24]
-
-### [React Universe](https://www.reactuniverseconf.com/)
-
-[06:25] **Mo Khazali:** Next up. We've got React Universe Conf in Wroclaw in Poland on September 5th and 6th. I actually am seeing this conference. So if you like listening to me talk about weird stuff and ramble, it's the place to be, I guess, but no, it's a great conference.
-
-[06:41] It used to be the former React Native EU, and now it's expanding to cover all things React based. And we've got some really good speakers there. So obviously you've got the, the popular React Native speakers that are the lineup of every single React Native community conference that you know, but we've also got folks like Dan Abramov, who's been I can't see Dodds and some others, and I would highly recommend coming to it.
-
-[07:03] The organizers really know how to organize conferences. They've done it for many, many years and you're guaranteed pretty much to have a great time.
-
-[07:10] **Carl Vitullo:** Yeah. And on them knowing how to organize a conference, they organized React Conf. They were one of the organizer partners for that. So yeah, they certainly do. They have organized yet another conference. Definitely would love to get up to Poland if I can. Cool.
-
-### [JSConf Chile](https://www.jsconf.cl/)
-
-[07:23] **Carl Vitullo:** A, an overlapping conference. There's also a JSConf Chile in Santiago. That's September 5th through 7th.
-
-### [UtahJS Conf](https://utahjs.com/conference)
-
-[07:32] **Carl Vitullo:** There's a Utah JSConf again in Salt Lake City on September 13th. I guess this is. JavaScript versus React for React Rally. But yeah, so we have two conferences in Salt Lake City a month apart.
-
-### [React Alicante](https://reactalicante.es/)
-
-[07:44] **Carl Vitullo:** There's React Alicante, which is going to, it looks like it's going to be an online conference.
-
-[07:49] **Mark Erikson:** It's in person in Spain and I'm speaking there.
-
-[07:53] **Carl Vitullo:** Cool. Oh, awesome. Wonderful. Go see Mark speak in Spain. That is September 19th through 21st.
-
-### [JSConf Ireland](https://www.jsconf.ie/)
-
-[08:00] **Carl Vitullo:** There's also JSConf Ireland in Dublin with also streaming September 25th and 26th.
-
-[08:07] And that is all of the conferences we have this month. Uh, I will shout out, last month I mentioned a conference that I will not name again because it came to light that they were using fake speakers on their website and had various people listed as speaking at the conference who were not. So, uh, I updated the transcript, but I wanted to shut that out. I did try to check. I do look at the conference websites and try and vet them, but I got it wrong last month. Sorry.
-
-## State of the web surveys
-
-[08:32] **Carl Vitullo:** All right. Onto our main content. We are slightly behind the times by a month or two on State of surveys. There have been a bunch of state of React, state of JavaScript, state of HTML, all kinds of states that have come out over the last two months or so, which is later than I expected.
-
-[08:50] Usually these have, in years past, the state of JS surveys have done a pretty good job of coming out. Pretty promptly, they've been running for, it seems like, most of my career. So, just surprised. Seemed like there were some, hitches this year.
-
-[09:04] **Mark Erikson:** Yeah, like, I'm not sure if it was that they, they just took a really long time to analyze the data, or they were working on, I know they did a lot of work on, like, new data visualizations as part of the survey results.
-
-[09:14] So, it might just have been that it took them a long time to get the new sites put together.
-
-[09:19] **Carl Vitullo:** I did notice that they had some really cool data interactivity bits on it, like you can, for a lot of, at least on the State of JS site, the State of React one got, looked like a little bit less attention, which is fair, it's a much smaller survey, it's like a third of the size. But, they had some interesting stuff where you could filter or correlate responses. So it's like, Oh, you can see years of experience as it pertains to salary. So there was a lot of really cool data exploration stuff there.
-
-[09:48] I did also see a little bit of chatter online or on Twitter about how the survey was promoted and what that means for its sample size and audience. demographics mainly, like the survey responses were like 92 percent male and that's not great. I've seen other spaces get up to like 80 percent male, so, you know, 15 to 20 percent female, which seems to be about the high watermark, unfortunately, for online based tech communities. But yeah, so just, just wanted to shout out that I have heard a little bit of that.
-
-## [State of HTML](https://2023.stateofhtml.com/)
-
-[10:21] **Carl Vitullo:** I'll start with the two smaller surveys.
-
-[10:23] So state of HTML was actually really interesting to me. I don't super duper know how to stay on top of, like, HTML and CSS changes, so I feel like every couple of years I, like, see a talk from someone who's a genuine cutting edge expert in CSS and, you know, use the platform kind of stuff and go like, "oh, holy shit, I don't know how to use HTML anymore," because just reading the state of HTML, I found a bunch of little things, a bunch of new features that I was not aware of. I unfortunately didn't take a bunch of notes on them, but just scroll through, see what catches your eye, see what you haven't stayed up to date with.
-
-## "Use the platform"
-
-[10:58] **Mark Erikson:** I know we've had, you know, there's, there's kind of the running meme of, you know, the, the folks who insist on use the platform and the, and the React community is a little bit like, "but the platform doesn't support all the things we want to do," but browsers are continuing to implement, new features, the HTML and JavaScript specs keep advancing.
-
-[11:17] And it's a fair critique that folks who tend to focus on, the React type front ends probably don't know as much about the nuances of what's available in HTML and CSS as folks who are more focused on that. So, like, there's sort of fair critiques on both sides, and it's worth keeping an eye on, the new advances there.
-
-[11:39] **Carl Vitullo:** Yeah, something that I have thought of many times over my professional career is like, there's use the platform, you know, there's a lot of things you can do without writing JavaScript code. If you can do it with a native feature, it's going to be less development time. It's going to be, it's probably going to be faster, more performant for the user.
-
-[11:56] But that use the platform nature is in tension with the flip side of React trying to allow people to write code that runs in more environments. So it's sort of, there's sort of that dichotomy. There's the pressure of writing a tool tip library, writing a modal library that works in React Native as well as natively on the web.
-
-[12:16] And if you rely on the platform features, then you can't do the React Native side of things. So There's been a big tension there for many, many years, but I have been very interested in what it would look like if there was a component toolkit that just said like, nope, fuck the other platforms, we're just going to go all in on web, we're going to do it in as few lines of code to get the best user experience and the best developer experience possible.
-
-[12:38] I don't know of one that's really working in that way, but I think it would be really cool.
-
-[12:42] **Mo Khazali:** So two points on that, which I think was a really interesting point that you raised, Carl. One is part of the reason why a lot of these libraries don't really work well for React Native is the lack of web API support in the React Native ecosystem.
-
-[12:54] And it is actually something that's being worked on. So Microsoft opened an RFC last year and they said, well, you know, we, we, whether we like it or not, as native developers, the web APIs have won. They're becoming standardized. Things are. Relatively stable. So why not try to at least use those as the interfaces, even if the native implementations are different under the hood, so that when you do use your trusty old React library, it does just kind of work out of the box in the React native ecosystem.
-
-[13:18] So there is a move towards that and you've got React strict DOM and whatnot. But the example, the counterside to that is the example of tooltips that you mentioned. Like tooltips are not a mobile. Friendly UI element. So there's no easy answer to this unless you create really high level primitives that are UI agnostic.
-
-[13:35] But functionality wise, they kind of behave similarly. So, you know, from a way that it looks, it's totally different on iOS, Android, and web, but at least the APIs for the developers are the same. So opens a tool tip on the, the, the web with a hover, but you know, maybe opens up a modal. A bottom sheet modal on native.
-
-[13:52] So it's a big point of contention for us React Native developers that we're trying to figure out. I don't think we have the answer, and I don't think anyone's figured out the sweet spot. But we'll get there. We will get there.
-
-[14:02] **Carl Vitullo:** Yeah, I feel like it crosses my mind every couple of months, but just hearing you talk about like, the web platform just makes me think yet again of a 2013 talk called the birth and death of JavaScript.
-
-## [Birth and Death of Javascript](https://www.destroyallsoftware.com/)
-
-[14:13] **Carl Vitullo:** And yes, JavaScript is intentional. But yeah, if you are not familiar with JavaScript. That birth and death of JavaScript talk, watch it because like, oh my God, it's the most, it has remained the most like prescient talk I've ever watched. It is exactly discussing how JavaScript takes over the world and we're just living it, we're just living that 10 years later, 11 years later. Anyway, that's a, that's all kind of long diversion for state of HTML, but.
-
-## [State of React](https://2023.stateofreact.com/en-US)
-
-[14:39] **Carl Vitullo:** There was also a state of React survey. It was pretty good. I kind of got more interesting signal I felt out of the state of JavaScript survey. There was a lot of survey time dedicated to like, what React features do you use? And that's just not really a question that I have, you know, I don't really care if you use, you know, use context. You probably do. If you don't, you probably should. That section, what features do you use, is interesting in terms of like, what are people aware of, but I don't know that it really changes that much.
-
-## Component Libraries
-
-[15:07] **Carl Vitullo:** It did have a lot of good data about component libraries and ecosystem that I thought was, just, we, we spend so much time in here bantering about like, what the vibes are and how does it feel What tools does it feel like people are using more and talking about more?
-
-[15:23] So this is a good data based check in on how accurate the, the vibes, our read of the vibes are and pretty accurate. I'm pretty happy. We'll get more into it with the state of JS, just that did have a lot more of the vibes, but some things I thought were notable component libraries, generally not popular.
-
-[15:40] Some of them are reasonably widely used, but like not loved. Radix were the most loved with Headless UI, also pretty high up there. Radix and Headless UI are not ones that live large in my mind, so it was cool to see those surfaced. Definitely, like, you know, obviously we talk about ShadCN pretty frequently, but Redux and Headless UI, good ones to check out.
-
-[16:03] Headless UI looks cool because it's unstyled, so it's just behavior, and then you make it look the way you want. Which, here for it, love it.
-
-[16:11] **Mo Khazali:** I think that's kind of the direction that they're all going with as well. Like, you know, R a bit more opinionated, but still flexible in a lot of ways compared to, let's say, your run of the mill material UI.
-
-[16:21] I think that's the general direction where these things are going. And Headless is great for that. I guess that's the appeal with Shad for me as well, right? Like I know a lot of people love ShadCN. The appeal is, well, if you don't like the rounded corners specifically, it's just a tailwind prop to change and you're kind of done.
-
-[16:36] So you have a lot of flexibility there.
-
-[16:38] **Carl Vitullo:** Yeah, definitely makes sense. It's been curious to see how slowly that has evolved over the years. I, I bailed out pretty quick on component toolkits cause I just, I don't want it to look like a bootstrap site.
-
-## StyledComponents still big
-
-[16:48] **Carl Vitullo:** So there was also something that I found interesting just because it seemed like a, you know, narrative violation is styled components are still pretty dominant in terms of actual usage, like enormously widely used, you know, everyone talks aboutTailwind and whatever, but. Style of components, they're here to stay, they're sticking around.
-
-[17:05] Some other interesting data, 23 percent of respondents are still on either React 16 or 17. So this is like, how many years after 18 was released? And 6 percent of survey respondents don't know what version they use, which is interesting to me.
-
-[17:21] So, yeah. If you're using React 18, congrats, you are on the cutting edge. The only 68%, less than 70 percent of survey respondents are on React 18. Talking about nobody uses beta versions. Nobody uses advanced versions. I think it was like less than 1 percent have tried a canary. So rounding error. All right.
-
-## [State of JS](https://2023.stateofjs.com/en-US)
-
-[17:43] **Carl Vitullo:** State of JS, the big one. Mo, you want to, you want to kick us off with your thoughts? Break up my monologue.
-
-## A Note on Survey Sample
-
-[17:48] **Mo Khazali:** Sure. Good to start off with what you kind of start off generically about the survey results, which is you got to look at the sample size.
-
-[17:53] It's like the most important thing to do when you start with this, because it makes the data seem a lot more contextualized as a result. So a colleague of mine, she was talking about this and I kind of took notes and then looked through it and I was like, yeah, wow, that's very accurate. She was giving me her thoughts.
-
-[18:09] But the first thing is, location is heavily US based. So if you look at the respondents, 16 17 percent are from the US. If you combine Germany, France, and the UK, Those become close to the US respondents. They're about the same as the US respondents, a little bit more. So all of this data is heavily skewed by the US market.
-
-[18:25] Things like, let's say like the Indian developer community is very, very underrepresented. There was only about 500 respondents where that's about two, 3%. Whereas, you know, they should be a lot more because proportionately they'll have a larger developer community than that, which is represented.
-
-[18:41] **Carl Vitullo:** I think the total number of respondents was like 20 or 30, 000.
-
-[18:44] So hearing only 500 from India is like a little bit shocking. Yeah,
-
-[18:47] **Mo Khazali:** it's, it's quite poorly represented. Or the Netherlands, as an example, has got about 500 as well. The Netherlands is a big tech hub in Europe. A lot of big tech conferences happen, JavaScript conferences happen in the Netherlands because there's already a big community there.
-
-[19:00] So it's very interesting, I think it's probably more to do with marketing and how they got the word out, and which communities it goes to. And so when you have location being heavily based in the US, then it skews salaries quite significantly. US salaries for developers are much higher. than European salaries And so all of the salary data is being taken on sort of an average, and so that moves the whole scale, basically.
-
-[19:20] The other thing which kind of you hinted on, Carl, was it's almost exclusively male. So 94 percent men, which isn't great. It's really heavily, disproportionately male. Men who have responded to this. And then the worst view that you can see, and this should, if anyone has any doubts about this, just look at this view and hopefully your doubts will be completely gone but when you combine the gender and the yearly income views, you can see that men have a higher average salary.
-
-[19:47] Shocker. So the gender pay gap is very much there, and it's something to the degree of 20, 000 on average between men and women. Shocking, right? And unfortunately as well, again, racial demographic, it's mostly white respondents, 70 plus percent as well.
-
-[20:02] So there's, there's, the sample size isn't very representative, I'd say. Still interesting findings, but just those caveats are very interesting to contextualize everything.
-
-[20:10] **Carl Vitullo:** Definitely. Yeah. It's funny. The salary to gender is one of the only things I did to play with the data. So it's funny that we both went straight for that. Yeah. Also on salary on, you know, US based salary, skewing it, you know, higher, I actually was, looking at that chart, looking at the, you know, the, the quartiles and seeing that my last job, like two years ago, my last full time software tech job was like, On the very high end of that.
-
-[20:36] So it's like, Oh, apparently I kind of maxed out the scale, which is interesting because I definitely have not, I was not at the top of the scale. I, my last salary is 171, 000. Like it was good. I was very happy with it, but. I know plenty of people who are making like double that. So I was surprised as much as US salaries will skew it higher, I was a little surprised to see the absolute high end of the scale, not really represented. Do you know, just knowing people who are making that.
-
-[21:04] **Mo Khazali:** So. Fascinating. You know, you say that because again, it's relative because if you, let's say like, look at the UK, 170, 000 per year, and your yearly salary is basically the top, top, top end, like maybe top two, 3 percent of developers. in the UK. So it's, it's all relative.
-
-[21:18] Like, like you say, yes, even in the U. S. you can go much higher and then it starts to become really skewed. So yeah, very interesting, but the data is never going to be accurate.
-
-[21:26] **Carl Vitullo:** Right, right, right. Yeah, I think top of market, I don't know, Netflix intentionally tries to pay top of market. I think they're in like 350 range.
-
-[21:33] I've heard rumors, consider this a rumor, but I've heard of like super top developers at OpenAI making upwards of like seven, eight, nine hundred k, a million dollars a year salary. So yeah, high end of the scale is crazy in the US, but we can, we can bail out of demographics for a minute.
-
-[21:52] I'm going to just rapid fire some of these, some of the breakdowns, some of the analysis that I was looking at.
-
-## Vue Tops Angular for usage
-
-[21:57] **Carl Vitullo:** Vue has surpassed Angular by usage according to this survey, which caveats about sample aside is interesting. Angular definitely not loved. It had a like net unfavorable view of it. I think majority of respondents had a negative view of it. it's still in competition with Vue and React by usage, but it is substantially more negative than either of those, than either React or Vue.
-
-[22:22] Everyone still loves Svelte. It was number one by like a long shot on interest and favorability rating, but not very top by actual usage. It has been consistently, growing in usage over the years. So React is still generally positive. It's still the most positive by rank. You know, in this list, it was number one most positive, but that's been declining over the last two or three years and is very tight with Svelte right now.
-
-[22:49] The dots were like practically overlapping, like definitely within margin of error for which one was more positive. Astro topped out the list of other options, It did not make the cut to be in the main list, but one of the shout out, Astro is in contention. it was funny.
-
-## Developer Happiness
-
-[23:05] **Carl Vitullo:** The, they had a chart of happiness and generally all of the libraries people were happiest in 2018, which I just thought was funny because I tend to think of 2018 as like peak tech for, in a lot of different ways.
-
-[23:18] Like when I think of Reactiflux and its activity and its growth and its vibes. 2018 was definitely a banner year. So that seems to just generally be true across the industry. Everyone was happy in 2018 and people are less happy now.
-
-[23:31] Next usage has been growing pretty consistently for like the last four or five years by this survey. Remix has been pretty flat, which I put them in the same usage bucket. I put them in the same popularity bucket in my mind. So that was a little surprising to me. There's also, Remix had a much more negative perception than I expected. It's about even for, you know, positive and negative responses.
-
-[23:52] I love it. I thought it was great. So I'm just surprised to see that. Over the last, like, three years, testing, usage of test tools. has grown pretty significantly, whether it's Jest, or VTest, or Playwright, or Cypress. All of them saw usage go way up in the last two to three years, which is very funny because that, that tracks very well with my experience of three to four years ago, nobody was writing tests.
-
-[24:17] Just, people actually started writing tests in the last couple of years, which is funny. Yeah, Playwright versus Cypress. The vibes are supported by the data. People love Playwright. It's got really great retention. It's got really great net favorability rating. Cypress, a little bit less so. It's still very widely used, but the retention chart was much more negative.
-
-[24:39] And it's just not as well loved, which generally tracks with the sentiment that I've seen.
-
-[24:44] **Mark Erikson:** Yeah, I think I saw that Playwright Downloads had recently surpassed Cyprus's. I know I've seen a lot of mentions of companies migrating from Cyprus to Playwright. So, yeah, matches my experience.
-
-[24:55] **Mo Khazali:** We literally, this week, migrated one of our clients from Cyprus to Playwright.
-
-[25:01] So, another anecdote of how the general vibes are going in the community.
-
-[25:05] **Carl Vitullo:** Yeah, Roboto just asked in the chat, what are people's problems with Cypress? I've run into a bunch of weirdness on flaky tests and just general quirks, like the edges have been rough. I haven't really done enough with Playwright to say what's better about it, but it seems like it's based on a more stable foundation.
-
-[25:24] **Mark Erikson:** I can briefly speak to this. Cypress runs your entire test in the browser. It basically kind of like hijacks everything about the browser behavior and sort of re implements a lot of that itself. Whereas Playwright, the test is running externally. And it's sending, like, DevTools protocol commands to the browser.
-
-[25:42] CypressR also has a really weird not actually async model. The way I understand it is it actually runs through the entire test code ahead of time and collects a queued list of commands, and then it executes those later. So you can't even use, like, real async await in your test syntax, whereas with PlayWrite you can.
-
-[26:03] **Carl Vitullo:** Interesting. Yeah, because I think Cypress came out before, like, headless Chrome was a thing, because I remember they, all of the browser automation stuff from, you know, years gone by are very hacky. Like, they're scripting the browser in a just really janky way, and the browsers produced a headless variant that is more intentionally able to be scripted.
-
-[26:26] And so I'm pretty sure that Cypress predates that change, and so they had to do the hacky weird stuff, and Playwright came about after that change, and they do less hacky weird stuff.
-
-[26:36] **Mo Khazali:** There's one more thing with the Cypress, I guess, model that pushed people away in the last couple of years, which was that they basically, they, I believe they're VC backed.
-
-[26:46] They needed to find a path towards monetization. So they released a paid model where you had a dashboard on their sort of like hosted platform. And then there was free alternatives. And they were scanning your node modules. There was this thing that came up where they were scanning node modules and sort of sabotaging if you were trying to use an open source alternative to their paid platform, which people really did not like.
-
-[27:09] And there was a lot of backlash. So I think a lot of people lost a lot of trust with Cypress as well after that.
-
-[27:13] **Carl Vitullo:** That tracks. Okay. That's not great. Yep. Also in testing, the generically branded testing library is also losing ground, which I'm surprised by. I loved it. I thought it hit a really great niche between like unit tests and full end to end tests.
-
-[27:28] But I guess my thought is maybe. Playwright is now stable enough to cover that use case with less setup process. Cause it did take quite a bit of work and influenced how I developed features when I had testing library tests in place. So maybe it's a similar benefit for less work using Playwright instead of testing library.
-
-[27:49] **Mark Erikson:** It is worth noting that Playwright actually added testing library inspired APIs like get by test.
-
-[27:56] **Mo Khazali:** And I have another hypothesis to this, which is again anecdotal, but it's from working with many different sort of clients. I think it might also be market led, and the reason I say that is because end to end tests are much easier to sell to your business stakeholders.
-
-[28:10] Oh, we're running and executing the full end to end lifecycle as if it was a user, and it helps prevent bugs because you can see when a flow, a major flow is broken. Whereas Component tests, whether they're with React testing library or any other solution or unit tests, are much smaller pieces of the segment.
-
-[28:26] And I think when you're crunched for budget, but you still want to have some level of testing and confidence as a business stakeholder, you'll push your developers to do more end to end tests because they understand it more. That's my hypothesis. I've seen it more in conversations with some of the leaders and the companies that we've been working with.
-
-[28:40] **Carl Vitullo:** Yeah, that makes sense. I personally find that a benefit because it'll, testing library lets me sidestep the whole, a whole set of questions. Like how do I log in? So weird stuff like that gets easier if you strip away the, you know, the stuff surrounding the feature you want to test. And once you've just run through the interactions there, but it definitely would be easier to sell.
-
-[29:01] We're going to test the whole thing. All right. Many diversions later. So testing, State of JS. Vitest usage has really skyrocketed. It's been very impressive. Jest is still surprisingly well loved to me. Generally testing across the board, way up. Everyone is writing more tests. Moving out of tests into native.
-
-[29:20] There's generally, it looks like a lot more people are building native code. This is probably a reflection of how much work the React Native and Expo teams have done to make that feasible for people who are use, who are coming at it from web development. Like in the, you know, different runtime section of this, they had, are you using, Electron, Expo, Cordova, React Native, all sorts of things, including native mobile.
-
-[29:48] You know, just, are you building a native app? All of those are, well, all the modern popular options are way up. You know, Cordova is, you know, Declining, luckily, but React Native, Native Mobile, all of that is trending pretty way up.
-
-[30:02] One option that was brand new to me in this survey is Tauri. Looked like an option that people love for doing native stuff and wanted to shout it out.
-
-[30:11] **Mark Erikson:** Yeah, and for those who aren't familiar with it, Tauri is basically a competitor to Electron. You know, the idea is you're writing a web app that runs it runs within the desktop as a native like application.
-
-[30:22] The distinction being that with Electron, you're having to ship an entire separate standalone copy of Chrome to run your web app, whereas Tauri wraps whatever the native web view is for that platform. So, you're only shipping, say, like, A five meg set of assets instead of, you know, 150 megs of Chrome to run your couple of megs of JavaScript.
-
-[30:45] **Mo Khazali:** And just from a native app developer's purist perspective, I would, from a React natives perspective would say that's not really your native, but it's a good hybrid option, but that is just a personal thing because you're not rendering native views at the end of the day. You're rendering a web app with some connections onto the native layer APIs.
-
-[31:02] But that's generally the challenge with anything like Electron, Ionic, Capacitor, or Tauri.
-
-[31:08] **Carl Vitullo:** Yep. Into like bundling and those tools, Webpack declining sharply. Really bad compared to others, like favorability and retention and all of that. Unfortunately, the way the questions are asked is, What have you used?
-
-[31:23] So there, it doesn't have a way of capturing What people currently use versus what they have used and have switched off. So it's hard to say whether people are actually not using Webpack anymore or, and whether they've added new tools to their toolkit or whether they've replaced it, that is not a question that we can answer with this dataset.
-
-[31:42] My, my intuition, my guess here would be that a lot of people are still using Webpack professionally, still working on a project that was spun up, you know, over the last two to five years. And, you know, switching bundlers is a really challenging project with not a lot of business value. So, yeah, I, I, it would not surprise me if a lot of people are still using Webpack at work, but have stopped relying on it for projects they make on their own or for, you know, open source work.
-
-[32:10] **Mark Erikson:** Also worth noting on that, on that front, that, Create React app. There's still plenty of CRA apps out there, even though it's no longer officially maintained or recommended, and that has always used Webpack internally. And Next is still a Webpack wrapper. They've been working on TurboPack, which I think now fully supports dev mode, but I don't think it supports production builds yet.
-
-[32:33] So, Next is still wrapping around Webpack for the foreseeable future.
-
-[32:38] **Carl Vitullo:** Yeah, generally, like, ESBuild and Vite have been the big winners here as Webpack is losing usage. Rollup is going up as well a little bit, but as far as I know, that's largely used by library maintainers, not app developers. Yeah, monorepo awareness is also growing a lot.
-
-[32:55] You know, the classics from, like, Several years ago where Yarn Workspaces and Lerna, those are declining. They are not the popular options anymore, but NX and PMPM are currently the leaders there, although I'm not sure if people would answer, I'm, I'm, I'm wondering if people might've said, Oh yeah, I use PMPM when they didn't mean they use it for monorepos, that's not the primary use of PMPM as far as I know.
-
-[33:18] And TurboRepo from. Vercel is also growing, but for other runtimes, Bun is slightly more popular than Deno. Interesting to check in on.
-
-[33:27] **Mark Erikson:** Now, is that, is that in sentiment or like actual usage amounts that we know of?
-
-[33:33] **Carl Vitullo:** That was claimed usage. So people saying, yes, I have used this. More people said that for Bun.
-
-[33:39] But, who's to say if it was personal, who's to say if it was professional, playing with something is very different from introducing it in a work setting, and my intuition says that Deno is currently better positioned than Bunn to be used at work, which is a much stickier usage. Yeah, another fun stat that I caught and wanted to shout out.
-
-[33:57] 18 percent of respondents have not used any AI tools. You know, whether that's Copilot or ChatGPT or Claude. Yeah, 1 in 5 of tech people who are aware enough of the online Zeitgeist to respond to a survey have not used it at all.
-
-[34:14] **Mo Khazali:** Just another interesting fun one. Apparently, 50 percent of respondents are still using Lodash actively, which I found was interesting, but more interesting than that is the 33 percent that still use Moment, despite some of those APIs basically being available in the, in the browser APIs.
-
-[34:29] So, takes a long time to get rid of some third party libraries, it seems.
-
-[34:32] **Carl Vitullo:** Yeah, yeah, it really does. Yeah, and I wanted to shout out the 20 percent of people who responded that are still hoping for, a pipe operator and pattern matching. My heart goes out to you as one of you.
-
-[34:44] I, that's something, those are two features that I got really excited about and like. 2015 16 that we are still waiting for. So I think I'm, I think I've given up at this point. Yeah. And Mo, about, uh, on library usage, I was really surprised to see that RxJS had a lot of usage. I think of it as a niche library, but, but by survey responses, a surprisingly large number of people are making use of it.
-
-[35:09] **Mo Khazali:** That's quite interesting. I mean, the, the, the one that everyone makes jokes about is jQuery as well, which is 22 percent still, but you know, yeah, it's, it's, RxJS has always been more niche and I'm, I think it was mainly used predominantly by the Angular community, if I'm not mistaken, right? Someone from the, uh, from the comments is saying that it's still a first class tool in Angular, so that, that might check out as to why it's got such a high usage.
-
-[35:31] **Carl Vitullo:** Okay, that, that would scan. Sure, sure.
-
-[35:33] Okay. Maybe this is my React bias showing then.
-
-[35:37] **Mark Erikson:** Yeah, I mean, they've, Angular has been introducing signals within the last couple major versions as they're, they are trying to put some emphasis on that, but RxJS is still very integrated into the Angular ecosystem.
-
-[35:49] **Carl Vitullo:** Gotcha. Okay. Looking at survey respondents generally, you know, the number of people who answered like the demographic questions at the beginning versus number of people who answered, who gave any answer for what content do you consume, like 80 to 90 percent do not consume content.
-
-[36:05] Like they did not give any answer for what content do you consume, which I just think is really. I think it's an important thing to keep in mind when you're, you know, as people are saying like, Oh, you know, Oh, everyone is, everyone's talking about this. Everyone's thinking about this. So and so made a video on this.
-
-[36:19] Like, you know what? Most people didn't see it. Most people are not thinking about that. Most people aren't even aware of that. I just think that, I just think that is a great, Demonstration of like the participation inequality that happens in so many software communities, or that happens in communities generally, where like 90 percent of the people are not participating in the same way as the most active 10%.
-
-## [Dark Matter Developers](https://www.hanselman.com/blog/)
-
-[36:43] **Mark Erikson:** And I have a very specific link for that, which is Scott Hanselman's classic post on dark matter developers, people who are just going to work and doing their thing and going home, and they don't know about the Twitter discussions or what's popular or the trends. They're just doing their thing quietly.
-
-[37:01] And we don't hear about them because they're not involved in the discussions. But the
-
-[37:06] **Carl Vitullo:** That is actually specifically the target that I'm kind of going for, for this podcast. I want to be the once a month, one hour long summary of that fire hose. Like, you don't care enough to drink the entire fire hose, stick your face in front of the blast of water, but want to get the signal.
-
-[37:23] that's what I view our role here as. We pull that signal out so that you can spend one hour consuming it instead of More than that, If you, instead of it being a part time job, staying on top of the latest news, I want this podcast to be an effective way to do so.
-
-[37:37] So yeah. Hello, Dark Matter developers. All right. That is half an hour of content on State of JS, which is good because there was not a ton of, React news otherwise. So yeah, Mark, you want to take us into our lightning round links?
-
-[37:49] **Mark Erikson:** Yep. So having said that we do have a bunch of lightning round stuff to go through.
-
-## [NYT](https://open.nytimes.com/enhancing-the-new-york-times-web-performance-with-react-18-d6f91a7c5af8) and [Slack](https://slack.engineering/balancing-old-tricks-with-new-feats-ai-powered-conversion-from-enzyme-to-react-testing-library-at-slack/) update to React 18 (Enzyme to blame)
-
-[37:54] **Mark Erikson:** First off, a couple of interesting company migration blog posts. We were talking earlier about, you know, like only two thirds of respondents being on React 18 and the New York Times put up a pretty big post about how they just updated React. to React 18. Some good details on the work they had to do and some of the challenges they ran into, especially with some of their embedded interactive setups, and some information on some of the performance improvements that they saw.
-
-[38:21] One interesting note is that A lot of their work had to do with migrating from enzyme tests to React testing library. And so, on a very similar note, Slack put up a post where they said, you know, we have tons and tons of enzyme tests and we, we tried to migrate those to React testing library. And, it was so hard, we actually ended up trying to automate a lot of the conversion using a combination of AI language models and some various additional tools.
-
-[38:52] So, this goes back to the test, and to the whole test discussion. Like, tests provide value, but they're code. And code becomes legacy. And you have to update it and modernize it. And that in itself can be a real drag on trying to change things.
-
-## [Rise Tools launched](https://rise.tools/)
-
-[39:05] **Mo Khazali:** So I'll jump in with a few things. First is that Rise Tools has been launched.
-
-[39:11] So Rise Tools is created by Mike Grabowski. So Mike is the former founder of Callstack and he's been very involved in the React Native ecosystem. It's basically, it's not tied to React Native, but it's basically targeting React Native for now. It's a way to build server driven apps. It's a server driven UI app where the server controls how the UI is layouted.
-
-[39:32] And it kind of comes with all things battery included, from the server, all the way up to the React primitives, and even some more opinionated UI design systems like Tamagui if you want to use it. It's kind of evolving in a way where it ends up being a bit of a meta framework on top of a meta framework.
-
-## Mo's talk about server-driven mobile UI
-
-[39:48] **Mo Khazali:** So a meta meta framework, we're getting into that age of front end development. Um, but it's really cool. It's server driven UI is very difficult. And I talk about how difficult it is in mobile development, many places. And I did a talk recently at a meetup in Poland. So shameless plug. If you're interested to see why this is an actual challenge in the React native world, just take a look at that YouTube video and hopefully you'll get a bit of a primer.
-
-[40:11] **Mark Erikson:** Gasp! A shameless plug on this podcast. What?
-
-## [NativeWind UI launching](https://nativewindui.com/)
-
-[40:15] **Mo Khazali:** Next up, Native Wind UI is launching. So this goes very much along the same train of thought as we were having a conversation about with the state of React, where a lot of these component libraries are not popular anymore, but people want these sort of copy pastable code components that have 90 percent of the stuff there and they can modify and change it as much as they want.
-
-[40:35] It doesn't come with any behavioral APIs. It's just. UI wise, how do things look like and what do the components look like? So this is basically like Tailwind UI. It's going to be a paid UI kit, UI copy and pasteable components and templates. But I think it's interesting that the React Native community is going in this space.
-
-## [GlueStack too](https://gluestack.io/)
-
-[40:51] **Mo Khazali:** Similarly, the GlueStack team. So GlueStack is, made by the former creators of NativeBase, which was another popular UI library and. GlueStack is basically the successor to that and they initially had a more batteries included opinionated API component library that is now going seemingly in a very similar direction to native WinDUI and Tailwind UI, which is, we have these copy pastable components.
-
-[41:16] So think of it as ShadCN as well, but in the React Native ecosystem. And the lovely thing about both of these libraries is, they work universally with React Native. So if you're targeting React Native on the web, these libraries will automatically work on both web and mobile, which is really cool, and a step in the right direction.
-
-## [Swift Package manager support, moving away from CocoaPods](https://)
-
-[41:30] **Mo Khazali:** More in the React Native ecosystem, so, If you've been in this ecosystem, you'll know that typically what we use on the iOS and MacOS front is we will use CocoaPods as a dependency and package manager. Now, CocoaPods is good, it works, it's one that's been around for a while. The iOS native community is moving towards Swift Package Manager that Apple created themselves.
-
-[41:53] And so now this PR got merged, but we will have Swift package manager support for React Native. So if you want to use Swift package manager, you now have the option to do so, which is going to be great for brownfield apps. So apps that are, some parts of it are in React Native, other parts are just purely native.
-
-[42:07] This will make it much easier to adopt if you've already been using Swift package manager for your native apps.
-
-[42:11] Now, one of the things that has been a challenge with the React Native ecosystem is around out of tree platform support and how easy it is to integrate them with tools like Expo. So out of tree platforms, for everyone who's not aware, are platforms that are not iOS and Android.
-
-[42:26] So, web, macOS, Windows, AR, VR, headsets like Vision Pro, and so on and so forth. So those are all platforms that are not officially managed and maintained by Meta, but they have sort of community partners that are maintaining them. And so macOS is maintained by, uh, Microsoft. And one of the challenges there was how do you get Expo to work with it?
-
-[42:45] Because previously you would need to do it in a bare React Native app, which means you have to do a lot of the typing and the wiring and all of the infrastructure underneath it. There's this concept of config plugins in Expo, and now there's support for React native Mac OS, and people are seemingly getting ready to be able to develop desktop apps with Expo, which is really exciting.
-
-[43:03] **Carl Vitullo:** Sorry, wait, did you say that this is maintained by Microsoft?
-
-[43:06] **Mark Erikson:** Yes. Microsoft maintains the React native implementations for Windows and for Mac.
-
-[43:13] **Carl Vitullo:** Okay. Just needed to check that. Cool.
-
-[43:15] **Mo Khazali:** Yes. Yeah. this is one of the things with React Native where there's so many people involved now. It's not just Meta, it's Meta, Microsoft, Amazon, Shopify, and name a bunch of other companies.
-
-## [React Native Filament](https://twitter.com/mrousavy/status/)
-
-[43:24] **Mo Khazali:** Next up, we have React Native Filament. So, it's a hot time in the 3D rendering space of React Native. there's a lot of stuff that's happening in the last few months. React 3 Fibers suddenly got a big boost in the React Native ecosystem. More and more people are talking about it. I've seen a lot of talks in 2024 about it.
-
-[43:41] The Skia team, the React Native Skia team have also been talking about GPU and 3d rendering. So they did that at their talk in AppJS. We covered it in the podcast back in May. And so now the team at Margello have released React Native Filament. So it's a base 3d rendering engine built for React Native. The nice thing about it being C is that it works kind of out of the box for most of these native platforms.
-
-[44:02] It is seemingly, again, this is how it's marketed, is that it's basically with less than 50 lines of code for you to load a 3d model and basically have things like pan gestures, zooming, and all of that, which is really hard to get.
-
-[44:15] And you need to actually manually code a lot of that yourself. So this is really cool. We'll see how it, how it materializes and how it evolves. There's a lot of 3d libraries that are coming to fruition and you've got to choose and see which ecosystem grows. So you're basically placing bets on horses and seeing which one kicks off.
-
-## [React Native for web devs](https://expo.dev/blog/)
-
-[44:31] **Mo Khazali:** On the trend of what we talked with the state of JS and, you know, how, uh, native usage is growing, Kati Kraman from the Expo team, she's written an article, a guide to React Native for web React devs. So people that haven't been in the native space kind of understand what are the things that you need to learn sort of like a TLDR before you can start creating React Native apps.
-
-[44:51] This is amazing because frankly, this is one of the things that I always rave about and rant about, if you don't tell people about the gotchas, they'll come and burn themselves in the React Native ecosystem, and then they will hate React Native for the rest of their lives. So, I love education and good education like this, which is specifically targeted for web React devs.
-
-## [Build Windows apps from a Mac](https://devblogs.microsoft.com/)
-
-[45:09] **Mo Khazali:** And last in this React Native train, at least in this one, is that one of the things, again, with out of tree platforms, again, with the Microsoft team, is that they maintain React Native Windows. But you need to have a Windows machine to develop for React Native with Windows, which many of us don't, myself included.
-
-[45:25] I have renounced the Windows days since many, many years ago. And so it makes it really hard to build Windows apps. And I've always wanted to do it. I've got an Xbox. You can build Xbox apps with React Native using the Windows implementation, but you need a Windows machine to be able to test your apps, which kind of sucks.
-
-[45:40] So they've written an article on how you can build Windows apps, with React Native. On a Mac. The spoiler alert is that it's not straightforward, unfortunately, you have to boot up a parallel Windows machine and then sort of port forward stuff and then use it on a VM to test it out, which is not the best DevEx, but at least there is an escape hatch if you really are inclined to do so.
-
-[46:00] So hopefully that opens the doors to React Native Windows for more and more people who are using Macs as their development drivers.
-
-## [Ecosystem Performance group, e18e](https://e18e.dev/blog/e18e)
-
-[46:06] **Mark Erikson:** Changing gears entirely, we all know the jokes about how, you know, Node modules is the heaviest object in the known universe. you know, you install one package and you get 1, 500 dependencies installed as a result.
-
-[46:20] And there's a lot of factors that go into it. It's how the Node ecosystem has evolved. There's also cases where, you know, certain maintainers are obsessed with Maintaining infinite backwards compatibility instead of allowing the ecosystem to move forward with modern tooling. I've been complaining for years that surely there has to be a way that we collectively as a community could go in and start You know, removing unnecessary dependencies from popular packages and end up improving, you know, download speeds and number of dependencies for everybody.
-
-[46:52] And there's now an actual community effort to do this. It's in a group called the Ecosystem Performance Effort. And it's just a community group. They've got a Discord for discussing things and a repo for pointing things out. But it's things like, could we look at, say, the isnumber package? And find the most common parent packages that depend on it, and replace those.
-
-[47:16] And end up saving, you know, like, cutting down on dependency trees, and saving download bandwidth for everybody. I'm very, very excited to see a lot of people actually spending time and effort on this. This is the kind of grassroots, you know, like, effort that actually benefits everybody.
-
-[47:32] **Carl Vitullo:** I saw a PR specifically about inlining `isNumber`, and it did, I don't know if I quite 100 percent buy this math, but the math they did was, by inlining this package instead of installing it as a dependency, we save this many kilobytes. This module is downloaded this many times per week. You multiply those together and ergo, we are saving 440 gigabytes of bandwidth every week. I am, I wonder if that is how that shakes out in practice with like caching and stuff. But if by inlining is number, we can have 440 gigabytes less data flowing through the air. Uh, that's, that's fascinating.
-
-## [ES2024 released](https://x.com/robpalmer2/status/1806064466510897240)
-
-[48:10] **Carl Vitullo:** We have also, ES2024 has been ratified by the, by TC39. We've got the spec, which is very dense and hard to read. Fun. Rob Palmer, who's part of the team involved in that also announced it on Twitter. A lot of these are like pretty esoteric to me, like well formed Unicode strings.
-
-[48:30] I didn't know they were not well formed. Promise. withResolvers, I guess. I don't, I don't know what that is either. ResizableArrayBuffers, ArrayBufferTransfer. Two that are a little bit more salient for me is Array. GroupBy and Object. GroupBy. What a great thing to have added to the standard library. So that's nice.
-
-[48:50] There's a regex v flag for creating regular expressions with more advanced features for working with sets of strings. Yeah. Lots of stuff. We've got a new spec, nothing too exciting though.
-
-## [Memory leaks: Compiler won't save you](https://schiener.io/)
-
-[49:00] **Mark Erikson:** We've mentioned one or two different articles that looked at ways you can end up with memory leaks in React applications due to closures and how JavaScript engines actually behave, and there's, there's some discussion of what happens when React Compiler comes into play, and so the author of those posts did some more research and concluded that no, you can, you can still end up with memory leaks, even with React Compiler.
-
-[49:25] It sort of ends up in the same situation where. Capturing variables in scope, and due to the way JavaScript engines work, you can still end up with some memory leaks if you're not careful. Similarly, Jake Archibald, who's done a lot of articles and research over the years around JS behavior, also just put up a very, very similar post talking about memory leaks and garbage collection with closures.
-
-[49:46] So, this is stuff that I only sort of half understand myself. And so seeing people go into these deep technical dives to research the actual behavior is very helpful. We've also, I believe we've mentioned the new JSR package registry a couple times, created by the Deno team. And there was a video talk from, I believe, Luca, who's part of the Deno team, going into some details on You know, a lot of the stuff that I've run into publishing the Redux packages over the last couple of years.
-
-[50:15] You know, issues trying to do the publishing, various problems with npm, goes into some details on how JSR is different, how it's supposed to work, and give some examples of actually doing the publishing. I don't know how much actual usage JSR is getting, but it's nice to see people actually rethinking this.
-
-## [React Native + Flutter](https://x.com/mdj_dev/status/)
-
-[50:33] **Mo Khazali:** The next thing is just a little bit of memes. More than anything, someone has decided to post a demo of React Native and Flutter running in a single app, which is quite funny. Believe it or not, I actually have tried this about a year ago. And the reason was we had someone who wanted to migrate away from Flutter.
-
-[50:50] So out of these memes, good conversations have actually started around how you can migrate and integrate Flutter and React Native together. In the case where someone wants to move away from Flutter. And you use React Native instead, so pretty fun times.
-
-## [Bun Q3 roadmap](https://x.com/jarredsumner/status/1807731197046653438)
-
-[51:01] **Carl Vitullo:** Earlier this month, Jared Sumner posted about the Q3 roadmap for BUN.
-
-[51:06] He says it's not exhaustive. And in the replies, adds more like, Oh, maybe we'll get to this too. But new stuff they're looking, they, they want to add a full stack bundler. I'm not exactly sure what that means, but I guess it's going to have overlap with like RSPack and probably server components too. I don't know.
-
-[51:22] A text lock file. So I guess another lock file format. I don't know why we need another package dependency tool. A CSS parser? on this roadmap seem confusing to me as a JavaScript runtime. He also talks about adding V8 C API compatibility, which sure, that makes sense, I can, I can see that, and getting better snapshots and timers for the bun test and mentions that he would like to ship a Postgres client sometime this quarter, but it's not in the main roadmap post that he made.
-
-## [Learn Suspense by building a Suspense-enabled library](https://www.)
-
-[51:57] **Mark Erikson:** So, we've been talking about suspense for, what, like six plus years now, but, there's been all the confusion over, how can you use suspense? Suspense only works with, React server components, or can you use it on the client? Are you supposed to use it on the client? There was a really good post that came out recently, Learn suspense by building a suspense enabled library that goes through some of the actual mechanics of trying to build a client side lib that uses suspense.
-
-[52:24] I'll be honest, I bookmarked this one because people have been begging for suspense support for RTKQuery. I looked at the issue actually, the issue is at least three years old. So I will probably be referring to this post when we hopefully get around to doing it, maybe later this year?
-
-## Mark's talk, "Why Use Redux Today" at React Summit
-
-[52:39] **Mark Erikson:** And the obligatory self plug, so I gave a talk at React Summit last month on why use Redux today, because this is a question that gets asked all the time.
-
-[52:50] TLDR, there's a lot of reasons why people adopted Redux in the first place. Some of those reasons no longer make sense, like avoiding the legacy context API, but the architectural reasons to consider using Redux are still valid. Being able to have a centralized store, being able to see that the state changes in the dev tools, having a well documented pattern for keeping state outside the component tree, So, it's not a lot of a sales pitch, it's like half of a history lesson, and then, discussions of trade offs, because I still find myself unable to give an unambiguous sales pitch.
-
-## [Chrome collects extra data for Google websites](https://x.com/)
-
-[53:24] **Carl Vitullo:** Cool. This is sort of general tech news a little bit, but Chrome apparently gives Google properties privileged information about your system resources, which is sketchy as heck. Why does Google need to know how much CPU my computer is currently using? Anti competitive behavior. Chrome taking advantage of vertical integration to suck up more data to use for reasons. Not great. Not exciting.
-
-## [Component, composition, colocation](https://bobaekang.com/blog/)
-
-[53:48] **Mark Erikson:** There was a really good post talking about trade offs and various architectural patterns between different ways to fetch data. Do you fetch data in hooks as components render? Do you do suspense based data fetching that starts nested down in your component tree versus do you try to kick it off, higher in the component tree, say like with a route or a page loader? Some very good actual thoughts of trade offs between these different patterns.
-
-## [Secret knowledge to self-host Next.js](https://www.flightcontrol.dev/)
-
-[54:15] **Mark Erikson:** And then, there was a good article from the folks at Flight Control, where they talked about challenges in trying to self host Next. js anywhere other than Vercel. It's feasible, but you definitely have to do some extra work.
-
-[54:29] Hosting Next on Vercel is obviously the happy path, and there's some challenges to try to fill in some of the pieces that Vercel would provide for you.
-
-## [Node can strip TS types soon?](https://github.com/nodejs/node/pull/)
-
-[54:37] **Mark Erikson:** Last but not, not entirely least, a few bits of news from the Node ecosystem. Node has merged a prototype PR to strip types and allow being able to just run TypeScript files directly.
-
-[54:50] Obviously, they're not actually checking the types, but similar to like TS Node, at least stripping off the types so it can just execute the code. Very perfect concept, but they're interested in iterating on it.
-
-## [Native SQLite drive in Node](https://nodejs.org/docs/latest/api/)
-
-[55:01] **Carl Vitullo:** Yeah, there's also, there's now a native SQLite driver in Node. Like if you're, if you have Node, you can now use SQLite. Wild! Apparently this came out of As Node was adding support for more browser stuff, like, apparently, I actually didn't really know this, you can also use local storage, quote unquote, from within Node, and that is backed by SQLite, and so then they did the work, after they got local storage in there, they added on a native SQLite driver.
-
-[55:30] I have been interested in Sqlite and the opportunities that it brings for like development patterns for a while, I'm actually making use of it in a bot that we use here in Reactiflux. I have a Kubernetes cluster set up with a Sqlite database just to keep everything co located and local. So I just have to back up a file instead of having to keep a running database server somewhere.
-
-[55:52] So yeah, just seeing more motion on Sqlite and seeing it get closer to the, uh, the actual runtime is, Very cool. I think that's awesome.
-
-## [Node moving away from CorePack?](https://github.com/nodejs/TSC/pull/)
-
-[56:00] **Mark Erikson:** Then, last item. So, Node ships with the npm package manager. And you've always had to use npm to then install other package managers like yarn and pnpm globally. There's been a long running effort to give Node a way to more directly install and use other package managers automatically.
-
-[56:21] If a project actually specifies it, and that's involved Node shipping a tool called CorePack. And it's been considered experimental this whole time, and it now seems as if there's discussions about removing CorePack. from Node. Folks like the Yarn maintainer are not happy about this, and I've seen a bunch of arguing about it, even within the last 24 hours.
-
-[56:43] So, who knows where this is going to land. You know, it's not like it prevents you from using Yarn or PMP in either way, it's about ease of usability. But clearly there's a lot of both technical debate and opinionated feelings involved.
-
-[56:56] **Carl Vitullo:** Yeah, I'm surprised to see a move towards getting removed.
-
-[56:59] It seems like a very valuable thing to have. It seemed very in line with the general direction of trying to decouple NPM from Node. js. But like you said, it's, this seems to be still very early.
-
-[57:12] **Mo Khazali:** I'm also quite surprised we've started using Corepack, and I think it's actually in the interest of other package manager maintainers, but I'm surprised they have backlash, interested to definitely read more about it.
-
-[57:21] **Carl Vitullo:** All right. That is the last link that we have. Thank you everyone for joining us. We'll be back on the last Wednesday of the month here in the live stage or back in your podcast feed just as soon as we can, which will hopefully be before Monday.
-
-[57:33] **Mo Khazali:** Thank you everyone for having me. Thank you for listening on to my rambling as always.
-
-[57:37] Always a pleasure and see you all next month.
-
-[57:39] **Mark Erikson:** Likewise, my two things, I will hopefully be publishing a very, very updated version of the Redux Docs Essentials tutorial within, like, the next few days, I've been working on it all year, and I will be glad to have that done. And as I mentioned at the start, I'm looking for a new position.
-
-[57:54] So, if you have suggestions, let me know. Please contact me.
-
-[57:57] **Carl Vitullo:** We gather sources from This Week in React, Bytes. dev, React status, Next. js Weekly, the React. js subreddit, and here in Reactiflux from the Tech Reads and News channel, as well as just following a million people on Twitter and looking for articles that way.
-
-[58:11] If you see anything that it seems like we missed, definitely send us a message. An email at hello at reactiflux. com with T M I R in the subject line. That's an acronym for the show. I read every email that comes in, including spam. So I will read it, even if I don't respond to it. We actually got a tip about the RISE tools for React Native.
-
-[58:30] Thank you for sending in a tip. That's our first one. Shout out. Thank you. If this is a show that you get value from and want to support, the best way to do so is, like, subscribe. Give it a review, help us show up in discovery charts for other people, or send it to your co workers, even if that gives away the secret of how you know so much about React.
-
-[58:46] Thank you so much, see you next month.
diff --git a/src/transcripts/tmir-2024-08.md b/src/transcripts/tmir-2024-08.md
deleted file mode 100644
index d848fd9..0000000
--- a/src/transcripts/tmir-2024-08.md
+++ /dev/null
@@ -1,646 +0,0 @@
----
-title: "This Month in React, August 2024: Matt Pocock taught us to make modules, RN is faster, iterator helpers are cool, JSR/Deno going sour"
-date: 2024-08-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-### Main Content
-
-- [[00:56](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
-- [[01:53](#react-19-progress)] React 19 progress:
- - [Initial “Suspense sibling pre-rendering” implementation work](https://github.com/facebook/react/pull/30800)
- - [DevTools support for Server Components](https://github.com/facebook/react/pull/30684) and [Viewing Source of Server Components](https://github.com/facebook/react/pull/30798)
-- [[05:23](#react-native-075)] [React Native 0.75 released](https://reactnative.dev/blog/2024/08/12/release-0.75)
-- [[07:30](#how-to-create-an-npm-package)] [How To Create An NPM Package | Total TypeScript](https://www.totaltypescript.com/how-to-create-an-npm-package)
- - [[08:13](#httpsblogisquaredsoftwarecom202308esm-modernization-lessons)] [Blogged Answers: My Experience Modernizing Packages to ESM](https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/)
-- [[10:36](#implementing-react-from-scratch)] [Implementing React from scratch](https://www.rob.directory/blog/react-from-scratch)
- - [Didact - build your own React](https://pomb.us/build-your-own-react/)
- - [Getting Closure on React Hooks](https://www.swyx.io/hooks)
-- [[12:04](#vercel-adds-retention-periods)] [Configure retention periods for deployments – Vercel](https://vercel.com/changelog/configure-retention-periods-for-deployments)
-- [[13:03](#waku-021-adds-server-actions-support)] [Waku 0.21 includes React Server Actions support](https://waku.gg/blog/server-actions-are-here)
- - [React Beyond the Render](https://playfulprogramming.com/collections/react-beyond-the-render)
-- [[14:35](#redux-essentials-tutorial-updated)] [Redux Essentials tutorial updated](https://redux.js.org/tutorials/essentials/part-1-overview-concepts)
-- [[17:46](#ts-56-rc)] [Announcing TypeScript 5.6 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-rc/)
- - [[18:31](#httpsgithubcomtc39proposal-iterator-helpers)] [Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers)
-- [[19:17](#expo-dom-released-)] [Using React DOM in Expo native apps](https://docs.expo.dev/guides/dom-components/)
-- [[24:51](#nitro-modules)] [NitroModules](https://x.com/mrousavy/status/1821165226546323930)
- - [Comparing to ObjC Turbomodules, it is significantly faster](https://x.com/mrousavy/status/1821651719945953309)
-- [[29:53](#jsr-and-deno-final-review--)] [JSR and Deno: Final Review 🚮 – David Bushell](https://dbushell.com/2024/08/09/jsr-and-deno-final-review/)
- - [What Deno Got Wrong About HTTP Imports](https://deno.com/blog/http-imports)
- - [The Deno Package Paradox – David Bushell](https://dbushell.com/2024/08/05/the-deno-package-paradox/)
-- [[35:45](#2024-stack-overflow-developer-survey)] [2024 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2024/)
-
-### ⚡ Lightning round ⚡
-
-- [[39:53](#cocoapods-going-into-maintenance-mode)] [Cocoapods going into maintenance mode](https://blog.cocoapods.org/CocoaPods-Support-Plans/)
-- [[34:30](#web-infra-devrslib-the-library-build-tool-powered-by-rsbuildmove-this-httpsgithubcomweb-infra-devrslib)] [web-infra-dev/rslib: The library build tool powered by Rsbuild.](https://github.com/web-infra-dev/rslib)
-- [[41:07](#accident-forgiveness--the-fly-blog)] [Accident Forgiveness · The Fly Blog](https://fly.io/blog/accident-forgiveness/)
-- [[42:17](#spatial-compute)] [spatial compute](https://sunilpai.dev/posts/spatial-compute/)
-- [[43:25](#how-airbnb-smoothly-upgrades-react)] [How Airbnb Smoothly Upgrades React](https://medium.com/airbnb-engineering/how-airbnb-smoothly-upgrades-react-b1d772a565fd)
-- [[44:34](#use-useid-instead-of-hand-making-ids)] [Use useId() Instead Of Hand-Making IDs](https://reacttraining.com/blog/use-useid-instead-of-hand-making-ids)
-- [[45:42](#common-sense-refactoring-of-a-messy-react-component)] [Common Sense Refactoring of a Messy React Component](https://alexkondov.com/refactoring-a-messy-react-component/)
-- [[46:20](#introducing-structured-outputs-in-the-api)] [Introducing Structured Outputs in the API | OpenAI](https://openai.com/index/introducing-structured-outputs-in-the-api/)
-- [[47:42](#httpsblogsentryiosentry-is-now-fair-source-sentry-is-now-fair-source)] [Sentry is now Fair Source](https://blog.sentry.io/sentry-is-now-fair-source/)
- - [Fair Source Definition](https://fair.io/definition)
-
-### Quick hits
-
-- [[50:51](#job-market)] Job market
- - [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE)
- - [Layoffs.fyi](https://layoffs.fyi/)
-- [[52:06](#new-releases)] New releases
- - [Material UI v6 is out now 🎉 - MUI](https://mui.com/blog/material-ui-v6-is-out/)
- - [Tauri 2.0 Release Candidate](https://v2.tauri.app/blog/tauri-2-0-0-release-candidate/)
- - [Nx 19.5 is here! Stackblitz, Bun, Incremental Builds for Vite, Gradle Test Atomizer](https://nx.dev/blog/nx-19-5-adds-stackblitz-new-features-and-more)
-- [[54:20](#upcoming-conferences)] Conferences
- - [React Universe 2024](https://www.reactuniverseconf.com/) Wrocław, Poland Sept 5-6
- - [JSConf Chile](https://www.jsconf.cl/) Santiago, Chile Sept 5-7
- - [UtahJS Conf](https://utahjs.com/conference) Salt Lake City, UT, U.S.A. Sept 13
- - [React Alicante](https://reactalicante.es/) September 19-21
- - [JSConf Ireland](https://www.jsconf.ie/) Dublin, Ireland & Online Sept 25-26
- - [SquiggleConf](https://2024.squiggleconf.com) Boston, MA USA Oct 3-4
- - [RenderCon](https://www.rendercon.org) Nairobi, Kenya Oct 4-5
- - [React India](https://www.reactindia.io/) Goa, India Oct 17-19, 2024
- - [React Brussels](https://www.react.brussels/) Brussels, Belgium Oct 18
- - [React Advanced London](https://reactadvanced.com/) London, UK Oct 25, 28
-- [[57:09](#outro)] Outro
-
-**Carl Vitullo:** Hello folks, welcome, thanks for joining us. This is the August edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. We're supported by Infinite Red, a consultancy that exclusively works in React Native. but more on them later. [00:22]
-
-Hello, I'm Carl. Uh, I'm a staff product developer and freelance community manager, here at Reactiflux mostly, where I run community programs like these events and the star helpers, and build tools to help keep the community operating. [00:34]
-
-**Mark Erikson:** I'm Mark. most people know me as the Redux maintainer or that guy with the Simpsons avatar, and I am currently an engineer at Replay. [00:42]
-
-**Mo Khazali:** And I am Mo. I head the mobile team at Theodo, which is another React Native and just generically tech consultancy. I'm also the organizer of the React Native London community and super excited to be here as always. [00:56]
-
-## Sponsored by Infinite Red
-
-**Carl Vitullo:** We are brought to you by Infinite Red, our main sponsor right now. They are an expert React Native consultancy that I am quite pleased to be a partner with because they are like authentically showing up to support the React Native and React ecosystems in like really meaningful ways. [01:12]
-
-They organize conferences, they host the largest React Native podcast, they publish the largest React Native focused newsletter, and they're Just really excited to work with them. Other than being great people who do great things in the community, they also, well, more precisely, they're a team of about 30 people, mostly developers with mostly greater than 10 years of experience. [01:33]
-
-So they actually work with your team to help you develop an expertise in building React Native. So if you are. Building something with React Native and need a little help hitting the ground running on that, definitely reach out to them because they are great people who will help you do good work. Cool. [01:51]
-
-All right. Mark, you want to start us off? [01:53]
-
-## React 19 progress
-
-**Mark Erikson:** So, last couple sessions, we talked about how React 19 had been delayed due to what has been known as Suspense Gate, where the React team had made a change last fall to pre rendering behavior for multiple nested suspense components. [02:07]
-
-So that instead of doing them in parallel, it effectively does them in serial. And people complained and said, we rely on these existing behavior, you're going to make a number of people's apps slower. And there was an outcry, and the React team had been ready to release React 19, and instead they backed off and said, "okay, yes, we see this is a big deal, we are going to figure out how to change the behavior." [02:30]
-
-But, the original PR that got merged was pretty complex, they've continued iterating on the internals. So it's not nearly as simple as revert the PR, it's we need to iterate further on the internals and figure out how to re implement some of the older behavior on top of the newer code changes. [02:48]
-
-### https://github.com/facebook/react/pull/30800
-
-**Mark Erikson:** There's been a thread where people have been trying to ask for updates, and the last comment in that thread a few weeks ago was, well Stay tuned to this thread for updates, but no indication of actual work. And so finally, within the last week and a half, I've seen a couple PRs where there is actual evidence of work being done on this. [03:07]
-
-Uh, Andrew Clark filed one PR that's added a feature flag that would later be added to gate this upcoming work. And then he just put up a PR a couple days ago with what looks like the initial implementation work for this Suspense sibling pre rendering behavior. I'm not sure if it's basically just this one PR, if he's working to split it into further PRs, or what the actual status is, but there is an actual PR with actual progress, and no idea how long it'll be before that gets merged, how long things will stay in beta or RC, but there is public evidence that they are actually pushing forward on this, and if you look at the code, you can see some of the complexity of the implementation work, like it's not just You know, one flag that gets turned on and off. It's a bunch of additional logic internally to make the older behavior possible. [03:57]
-
-### https://github.com/facebook/react/pull/30684
-
-And meanwhile, I've been very interested in this part. Sebastien Mårkbage had been spending, you know, really most of his last couple of years working on the server side aspects of React. Server components and a lot of the HTML, you know, related pre rendering work, but he's actually turned his attention to the React DevTools in the last month and a half. [04:17]
-
-And he's just been putting up a whole series of PRs, refactoring the guts of the React DevTools and making a whole bunch of improvements. And so two of them in particular, he's actually implemented what looks like React DevTools support for showing server components as part of the tree in the React DevTools. [04:37]
-
-### https://github.com/facebook/react/pull/30798
-
-**Mark Erikson:** And along with that, what looks like a feature for being able to view the source of server components from React DevTools on the client side. This is something that I had always wondered, like, when are they going to get around to doing this? Like, we've supposedly shipped this production ready feature, and yet there's no way to really debug or view server components. [04:56]
-
-So to me this is a pretty big deal. [04:58]
-
-**Carl Vitullo:** Yeah, definitely. Dev tool support has always been so good in React that calling it, you know, production ready when there isn't that dev tool support seems a little surprising. So yeah, cool to see that coming. I'm a little surprised to see that they are actually able to get like the source of server components into the client seems cool. [05:16]
-
-That PR is only a hundred lines added, 35 lines removed, so that seems very easy if they had a lot of support. [05:23]
-
-## [React Native 0.75](https://reactnative.dev/blog/2024/08/12/release-0.75)
-
-**Mo Khazali:** So, next up, React Native version 0. 75 has been released. Now, this has been one of the most sort of subtle and quiet releases of React Native I've seen in a very long time. There's a lot of sort of minor improvements under the hood that's happened. [05:37]
-
-The first thing is that we have a new version of Yoga. So, Yoga is the layouting engine in React Native that basically handles Your JavaScript code being translated to native layer drawing on the canvas. And so it's now got support for, so, so recently a couple of versions ago, we got support for gap when you're dealing with flex like layouting, and now there's also percentage value support for for GAP as well. So it's getting closer and closer to what you can do on the web. Another sort of update within this version is that you've got new architecture support that's getting more and more mature, and so you see that some of the libraries that previously didn't have new architecture support are getting more and more. [06:12]
-
-Positive support within the new architecture paradigm. And also, um, what you see is that tools where you can see the list of dependencies that you have now also mark whether or not new architecture is supported within it. It seems like we're kind of gearing towards finally having the new architecture as a default with the next release of React Native, which would be a pretty big deal. [06:31]
-
-But again, we've been saying that for a little while, so I'm not holding my breath, but I'm very, very cautiously optimistic about that. And then the last big thing within this version is that a couple of versions ago, again, they announced that you should use a framework and they suggested Expo as kind of the only option really that's, that's available currently. [06:46]
-
-And so we see a few movements that are coming out of that announcement. One of which is that the CLI tool React Native init is now being sunsetted in some capacity and moved to a community CLI. So. By the end of the year, so December 31st onwards, when you run the commands react native init, they just will no longer work, um, and you'll be guided either to use expo or to use the community fork of the CLI that will be maintained by the community. [07:11]
-
-But this is kind of a, let's just move it to the side. And wait for it to reach its demise type of thing. Which is, that's fine. That's kind of the direction that it's going towards. But it's just something to keep in mind though. [07:21]
-
-**Carl Vitullo:** Yeah, sure. Shades of create react app sunsetting. Commonly used tool that's just gonna slowly fade away. [07:28]
-
-**Mo Khazali:** Yes, exactly. Very much so. [07:30]
-
-## [How to Create an NPM Package](https://www.totaltypescript.com/how-to-create-an-npm-package)
-
-**Mark Erikson:** Alright, Matt Pocock, who's probably best known for a lot of his articles and courses on how to use TypeScript properly, has actually put together something adjacent and published a very long, detailed article on how to properly create and publish a package on NPM. This is an extremely detailed and very step by step guide that goes all the way from, you know, literally create a new Git repo to creating a package. json file, some of the fields you would want to define in there, setting up tools like TypeScript and Prettier, and one of the more complicated pieces, how to actually define the JavaScript files that are used in terms of the package exports. [08:13]
-
-### https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/
-
-**Mark Erikson:** Now, I spent a very large portion of 2023 trying to figure out a lot of this stuff for myself, because in today's JavaScript ecosystem, figuring out how to publish packages that properly support things like both ES modules and common JS modules is an absolute nightmare. [08:32]
-
-And there's all kinds of different permutations and different runtimes and environments and other things that you're going to run into. This guide isn't going to cover every different use case you'll run into, but it is a very, very good detailed look at a lot of the common things you would want to do to set up a reasonably standard package setup in today's environment. [08:52]
-
-So definitely worth looking at. [08:53]
-
-**Carl Vitullo:** Yeah, definitely. I have needed something like this many times. I've always kept track of generally each change in the ecosystem, but then when I, you know, actually sitting down and needing to write a new package and remembering which changes happened, what the current state of the best practice for setting up a new package are is always Very difficult. [09:12]
-
-So I'm really excited to have this. It's, I think your post from 2023 was like the first time I had seen somebody try to articulate what best practices for publishing a, you know, like professional quality NPM module looked like, and it's so weird. It's gotten so strange. [09:29]
-
-**Mark Erikson:** It is so painful and so bizarre. [09:31]
-
-Now I will, I will say I will say like a lot of the pain comes from Node, not allowed to import CommonJS into ESM, I can never remember which way it is. Um, like, you could do A into B, but not B into A. I just don't remember which way the limitation was. But the last couple versions of Node 22, I believe they've finally started to implement valid support for going both ways without any errors. [09:59]
-
-I can't remember if it's behind a flag, but at some point that version is going to become widely used enough that we can maybe, in five years, start to go past this. [10:10]
-
-**Carl Vitullo:** Hopefully. Yeah, I had actually just seen a tweet somebody put out complaining about a similar thing where, I think they called it a cardinal sin of CommonJS, but it was conditional exports. [10:20]
-
-You could put what you exported behind a flag. [10:23]
-
-**Mark Erikson:** Yeah, I think that was probably Ketanaito, the author of MSW. [10:27]
-
-**Carl Vitullo:** Correct. Arya in the chat saying, can't import ESM from CommonJS, but can import CommonJS from ESM. [10:35]
-
-**Mark Erikson:** Yep, that sounds right. Yep. [10:36]
-
-## [Implementing React from Scratch](https://www.rob.directory/blog/react-from-scratch)
-
-**Mark Erikson:** So I've always been a very big fan of articles that try to build a miniature version of a real library from scratch and kind of walk you through, here's the kind of functionality, here's what it actually looks like internally. Here's some of the pieces that you might consider. These are really, really good for both understanding the mental model and you know, kind of peeling away the black box and like understanding what's actually going on inside of these libraries. So I've seen a few different good articles along that line for both, you know, React and Redux and, and, you know, bundlers and other tools over the years. [11:11]
-
-So someone named Robbie Prusin just put out a really, really good new example of this implementing React from scratch that walks all the way through the process of creating elements um, modifying the DOM, putting, and putting all the pieces together. Really, really good post. Definitely recommended. And so, along that line, two other earlier posts that I'd recommend. The one I've pointed people to for me, for years, was from Rodrigo Pombo back in 2019, Build Your Own React. And then swyx has a classic post on how React hooks work by building your own version of hooks in 30 minutes. [11:45]
-
-**Carl Vitullo:** Yeah, also a huge fan of this kind of, like, first principles, understand how it works by making your own miniature version of it. Reminds me of, like, in the physical world, building a model. You're not going to use it for something for real, necessarily, but this gives you a really clear mental model of what's going on under the hood. [12:04]
-
-## [Vercel adds retention periods](https://vercel.com/changelog/configure-retention-periods-for-deployments)
-
-**Carl Vitullo:** I'm going to throw this in. This is maybe a lightning round tier post, but I'll show you right now. Vercel announced that they are going to allow you to configure retention periods for your deployments. I saw Guillermo Rauch post on Twitter about this and saying it was something that people have been requesting since he released, now, the precursor to Vercel. [12:25]
-
-So this is a feature that goes back nearly 10 years of people requesting it. And just like generally, retention periods, I feel like they're underrated. I feel like they're super powerful and just really good for a lot of things. Being able to configure how long data sticks around, I think, is a bit of a superpower. [12:42]
-
-It's one of the things that, like, once you figure out how to make use of it, it just lets you do a lot of really good, powerful things. I have an affinity for them because my first full time job was doing tech support for a backup server, and so learning retention periods and how the retention policies were structured was a big part of my early tech career. I think it's cool. It seems good. [13:03]
-
-## [Waku 0.21 adds Server Actions support](https://waku.gg/blog/server-actions-are-here)
-
-**Mark Erikson:** All right. So we're continuing to see folks try to work on building out React server component support in various frameworks. Uh, you know, Redwood's done some work. The remix folks are trying to work on things and one framework that's been plugging away kind of quietly is Waku, which is the brainchild of Daishi Kato, the author of Jotai and Valtio and maintainer of the Zustand library. [13:27]
-
-They have just released version 0. 21, which now includes support for server actions. We're still at a point where Next is really the only, like, full, you know, quote unquote, production ready implementation of React server components and server actions. But it's good to see that other frameworks in the ecosystem are getting closer. [13:47]
-
-While I don't know the overall status of WACU, like, it feels like it's starting to get a lot of the pieces fleshed out. And, you know, worth at least looking at. I mean, probably not ready to use in production yet. But it's an alternative approach to server components that'd be worth investigating. [14:02]
-
-**Mo Khazali:** Quite interesting that on their website, when you scroll down at the very bottom, it has a big sponsored by Vercel. Which seems quite funny, given that it's somewhat a competitor to Next in some capacity. [14:13]
-
-**Mark Erikson:** I was talking with Tanner Linsley and he said that like, Vercel has actually been doing a lot of work to both, like they, they sponsored, React Rally, the conference at the last minute, and they're even sponsoring some of the work on TenStack Start, I believe. [14:24]
-
-**Carl Vitullo:** Yeah, they are definitely all over the place sponsoring all sorts of stuff. So I guess they're just generally investing in the React ecosystem. Here for it. Let's distribute VC money. [14:34]
-
-**Mark Erikson:** Yeah, very much so. [14:35]
-
-## [Redux Essentials tutorial updated](https://redux.js.org/tutorials/essentials/part-1-overview-concepts)
-
-**Mark Erikson:** Okay. Next up is an item that is very near and dear to my heart because this has taken me like the entire calendar year in one form or another. [14:44]
-
-In fact, I think I actually published this, might've even been like the day after our last recording in July, but you know, hey. So Redux Toolkit came out in the fall of 2019. In the first half of 2020, I wrote a brand new tutorial for the Redux docs that I dubbed the Redux Essentials Tutorial. [15:02]
-
-And it was about 25, 000 words, and it covered how to use Redux Toolkit to build a plausibly realistic example app. And it taught Redux Toolkit for the first time as the default way to use and build Redux applications. And so that has been the primary Redux tutorial for the last four plus years. [15:23]
-
-But it was starting to get a little bit outdated in a couple ways. While I still think that the original version of the tutorial was, frankly, a really good piece of work and something I'm very proud of. I saw in retrospect that I could have done a better job explaining various, you know, Redux concepts. So, at the start of this year, I set out to do a pretty thorough modernization and update pass on that tutorial. [15:46]
-
-I did the work to convert the existing example application to TypeScript. Start to finish every single commit. And then I added some additional features and examples to demonstrate newer Redux Toolkit features that did not exist in 2020. From there, I went through and did a very thorough update on all the content. [16:06]
-
-Improved a lot of the explanations, moved pieces around. Ended up adding about 9, 000, close to 10, 000 words of overall content, not counting the content that got changed and shifted and moved around. So, a month ago, I published the finished update to this Redux Essentials tutorial. So, it is now TypeScript start to finish. [16:27]
-
-Which is something I spent a lot of time, I had spent time debating it out in the past. You know, I've always been concerned that adding TypeScript into the mix this early is going to add more learning overhead. [16:38]
-
-And that's still the case. But ultimately TypeScript adds so much benefit, and it's how we want people to learn. to use Redux, that I decided it was worth it to just do the whole tutorial in TypeScript all the way through and try to explain the pieces as I went. So, it's live, uh, it's now up to like 50, 000 words, it is incredibly comprehensive, covers effectively all the APIs in Redux Toolkit and explains Enough about how things work that you can follow through and use it and understand most of the why. [17:11]
-
-It doesn't go into how things work internally. For that, we still have kind of the lower level Redux fundamentals tutorial that explains, you know, like, how does a Redux store work, or how do some of the pieces connect together. But this is the way we want people to use Redux, and, you know, I'm pretty I'm biased, but I think it's the best way for people to learn Redux. [17:32]
-
-So I am very excited to have that out. It took me multiple months of effort to try to put that together. [17:38]
-
-**Carl Vitullo:** Nice. Cool. 50, 000 words. You could sell that as a book. [17:42]
-
-**Mark Erikson:** Pretty much. [17:43]
-
-**Carl Vitullo:** all right. I will pull us onto our next one. [17:46]
-
-## [TS 5.6 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-rc/)
-
-**Carl Vitullo:** TypeScript 5. 6 has a release candidate. Seems cool. Just going to call out a couple of cool things. [17:52]
-
-Something that caught my eye was the disallowed nullish and truthy checks. It's practically a linting rule, really. It just helps catch stuff that are pretty obviously bugs. Like, a good example they called out was if you accidentally switch the equals and the greater than in the, you know, trying to do a greater than equal comparison. [18:10]
-
-Oops, that's an arrow function, which is always going to be truthy. And so now TypeScript will give you an error for that. This expression is always truthy, you probably didn't mean to put that in an `if`. That just seems pretty useful. They talk a bit about other situations where they do allow, you know, constant expressions, but truthy expressions will now warn, which seems really great. [18:31]
-
-### https://github.com/tc39/proposal-iterator-helpers
-
-**Carl Vitullo:** I also liked the iterator helpers. It looks like they're pulling in a stage three proposal for, you know, ECMAScript, JavaScript, which I'm a little surprised by. You know, I, I thought that they generally wait for things to ship. [18:43]
-
-**Mark Erikson:** Stage three has usually been their target. [18:45]
-
-**Carl Vitullo:** Yeah, okay, cool. Good to know. But yeah, iterator helpers, it looks like that feature generally looks to be a recognition that people want to use iterables as if they were arrays, and so it adds a lot of array type, you know, functions to iterables. [19:01]
-
-So you can do things like map and filter and things like that on them. So that's super great. I'd love to see TypeScript adding support for that because that looks really great. I have tried to do that a number of times and been really annoyed that I had to spread it into an array first before using map. [19:16]
-
-So that's, I'd love to see it. [19:17]
-
-## [`expo-dom` released ](https://docs.expo.dev/guides/dom-components/)
-
-**Mo Khazali:** So, let's switch gears a little bit into some React Native news. So, a couple of cool things. First off, Expo DOM has been announced. So, now you've got a whole bunch of different ways to do code interoperability between web and mobile, uh, and all things in between. So, you now have React Strict DOM, there's React DOM, there's Expo DOM. [19:36]
-
-It's getting very confusing very quickly. But, really, the gist of all of this is, Expo's been really pushing this narrative of you want to be able to use a single code base to target web and mobile at the same time. Part of the challenge that will come up with a lot of people will be, well, I already have my web code base and I already have my React Native code base and combining these two together is going to be a bit of a tough egg to crack when you're dealing with a massive length in migration. [19:58]
-
-This is one of the things that they want to target with this, which basically is that they want to allow you to use DOM Primitives directly within, your React Native applications. So you put a use DOM directive at the very top of your file, and then that basically means you can start using DOM in there, and what it does under the hood is it basically constructs a web view and renders those DOM elements instead of real native elements. [20:17]
-
-Now this is quite powerful because it kind of means you can mishmash a little bit of DOM in places where you already have some code that's using React DOM inside of a React Native code base. And in theory, if your code is responsive and behaves well on mobile web, then it'll kind of work as you expected within your React Native app. [20:33]
-
-There is a lot of disclaimers within this in terms of how your data flow works and all of the different things that come with that, you can't, you know, render children within it. It's very primitive rendering at the moment. But, it's a path towards migrations, if you so need it, desperately. It's not a long term thing, I think it's a very short term, temporary, here's how we just get a fully functioning app out in the meantime while we slowly add native views into our application. [20:56]
-
-**Carl Vitullo:** Ah, interesting, okay. This is a stopgap they're not necessarily looking to have people build full React Native applications using web primitives. [21:06]
-
-**Mo Khazali:** Thanks. It's more of a migration thing. So, you know, I've worked on a number of apps. In fact, I'm working on one right now where it's a hybrid app. [21:13]
-
-A lot of companies will have hybrid apps where they have some of it in React native, that's native views. Some of it are web views and you have to use a web view inside of the native app to render some of the screens because, you know, they didn't have the time to build that out in a native fashion. So this is kind of just streamlining that process a little bit. [21:28]
-
-I think it's just to try to entice people to come over to the dark side of the native world, and then hold them hostage afterwards. Jokes aside with all of this though, I think it's a, it is a migration path. It is very experimental, it's nowhere near production ready, it's just being brewed as we speak this month, um, and they've released a bunch of demos and it's now officially on their docs, but it's very much with all of the disclaimers of you shouldn't use this yet. [21:49]
-
-And it comes with a whole bunch of limitations. [21:50]
-
-**Carl Vitullo:** Reminds me of Cordova and things like that. I'm a little surprised to see Expo doing something along those lines. I thought we had generally agreed that just like flapping a web view in a native app was not great, but okay, cool. [22:01]
-
-**Mark Erikson:** So just to make sure I follow the technical train here. [22:03]
-
-So roughly speaking, you write a line or two of code that looks like it's just rendering. Another React component, but under the hood, it's actually creating a whole web view, attaching it to the native layout, injecting the JavaScript code into the web view, and then actually rendering a web component, a React DOM component inside of that, right? [22:24]
-
-**Mo Khazali:** Exactly. That is exactly what it's doing, yeah. Layers of abstractions on top of layers of abstraction. So I think this will be around as a migration path. I think this is a small side project that they're just whipping up to make it easier for people to adopt the universal app paradigm, which is, you know, I want to have a single code base for all of my platforms. [22:40]
-
-I think you really want to focus on React strict DOM if you're thinking about the long term of your app, if you want to go down the route of having a universal app. This is just a temporary stopgap if you happen to have code in the web world that you want to easily use and migrate over to the native world. [22:56]
-
-**Carl Vitullo:** Sure. Yeah, right. I guess I still had the strict DOM in my head as you started talking about this and it threw me off. Definitely a, uh, a subtle but significant boundary between those things. Okay. Interesting. [23:08]
-
-**Mark Erikson:** And to recap for people who might not have listened to the last couple, last few episodes, React strict DOM, on the other hand, is adding more web like API capabilities to the React Native platform. [23:19]
-
-So you write more code that looks like React DOM for the web, and it makes your React Native code basically read as if it were web code. [23:27]
-
-**Mo Khazali:** Because the, the current status, and I guess maybe going a little bit further back into the context of this, we've had React Native Web for a long time, which allows you to basically take React Native code and run it through almost like a translation layer, uh, with almost like an interoperability layer that lets you render those native views and native texts on the web. [23:44]
-
-So this is, this has been around for years. It's like pretty much been there since the launch of React Native a few months after they kind of, somebody launched this project who now works at Meta. But that was a very big bloated piece of, of a dependency that you would add to your web app. So then React Strict on was like, can we, can we kind of find a way that's in the middle that uses the web based APIs, also makes it easier for web developers to come into the React Native world, translates them down to native views. [24:06]
-
-But also has a minimal overhead to use that same code on the web. And so, this is pretty much the exact opposite of that, but it's sort of a temporary stopgap. [24:15]
-
-**Carl Vitullo:** Yeah, interesting. Okay, so if, like, React Native Web from, you know, ye olde days was asking web developers to write code like React Native developers And React strict DOM is allowing web people to write what looks like web code, [24:31]
-
-**Mark Erikson:** Native code that looks like web code. And then this is this, eh, let's just shove a web view in the middle of our, all of our native views. [24:38]
-
-**Carl Vitullo:** They're covering all their bases. They're trying everything and seeing what works best. Cool. All right. [24:43]
-
-**Mo Khazali:** Where there's a will, there's a way. [24:45]
-
-**Carl Vitullo:** We've got a lot of wills going on. [24:48]
-
-**Mo Khazali:** There's many wills going on here. [24:50]
-
-**Carl Vitullo:** Neat. Very neat. [24:51]
-
-## [Nitro Modules](https://x.com/mrousavy/status/1821165226546323930)
-
-**Mo Khazali:** Let's move on to Nitro modules because this has been a big thing in the React Native ecosystem in the last month. Again, a little bit of context because I think this will help everyone kind of understand and set the scene. So, a few years ago with the old architecture, when you wanted to access native layer code, you would need to use a native module. That used something called the bridge and the bridge would basically serialize some JSON or some, some sort of JavaScript objects, send it across a bridge as we like to call it. And that data could be used by the native layer to be interacted and run some native operations. And that's how sort of the JavaScript layer and the native layer used to communicate with each other. [25:23]
-
-That bridge caused a lot of issues because you had sort of this one pathway to communicate between the native layer and the JavaScript layer and it caused slow apps and many issues and a lot of library maintainers were incredibly frustrated because it meant that if you use their library in a certain way, it would completely bog down people's apps and they were getting a bunch of issues around how their library is slow or React Native in general as being slow. [25:43]
-
-So then the new architecture tried to create a better way to interact between the JavaScript layer and the native layer. And so that's where TurboModules came into place. So the idea with TurboModules was you would create a TypeScript interface to define the type of functions and values that you want to communicate between the JavaScript layer and the native layer. Then it would run through some C code gen to generate the connection layer between the native layer and the JavaScript layer. And then you could write native layer code and use that with what they call turbo modules, which was the name for it. [26:13]
-
-That was a much more neat and streamlined way to communicate between the JavaScript layer and the native layer. That's a massive step up from the old architecture, and now Mark Roosevee, who is one of the sort of like people in the React Native ecosystem who's known to create some really cool native layer libraries that work really well, has now been playing around with this idea of creating an even faster way to communicate between JavaScript and the native layers and to write native layer code as, as a React native developer. [26:39]
-
-And he's calling it Nitro Modules and he's created a lot of fun puns out of them. For example, if you wanted to generate a Nitro Module, you run Nitrogen, which is, uh, quite fun. Um, [26:49]
-
-**Carl Vitullo:** Oh, my god. [26:50]
-
-**Mo Khazali:** It's great. [26:51]
-
-There's, this isn't really public at this, it's not very clear a lot of the stuff that works under the hood. I think it's getting released and drip fed as we kind of speak this month, but just some comparisons that he's run with Objective C based turbo modules compared to Nitro modules is that it's apparently like 10x faster, so 220 milliseconds in a benchmark that he ran versus 20 milliseconds. There's also another way that the Expo team have created Expo modules. [27:16]
-
-We're going, we're seeing a trend here, right? Like the React Native Ecosystem likes to invent and reinvent different ways of doing the exact same thing, whether it's with the strict DOM stuff or with this, but anyway. So then you've got Expo modules, which is slower to Turbo modules. And then now there's Nitro modules, which is apparently the fastest of them all. [27:31]
-
-So we'll see how this plays out. It's yet another approach of trying to handle this native to JavaScript communication. We'll see if it, if it actually pans out and how it, how it goes on, but promising signs at the beginning, and a lot of people seem very excited about it. [27:43]
-
-**Carl Vitullo:** Yeah, super neat. Throwing a bunch of shit at the wall and seeing what sticks, trying a bunch of different approaches. [27:49]
-
-I feel like that naturally flows out of where React Native sits in the world because it has iOS, Android, web, macOS, Windows, well, you know, it gets touched by so many different developers. And so I feel like where web and React can get a little bit like monoculture a little bit just because it's, you know, there's the one true way of doing it, but I feel like that sort of variety of approaches maybe flows a little bit more naturally out of React Native as a kind of a, I don't know, kind of a natural melting pot of developers. I appreciate that. [28:21]
-
-**Mark Erikson:** Polyglot development. [28:22]
-
-**Carl Vitullo:** Yeah, sure. [28:23]
-
-**Mo Khazali:** It feels like React in the early days, rather than what React is today. [28:26]
-
-Like, I've been in between the web and the mobile ecosystem. And, you know, I feel like the React ecosystem has reached a point of maturity, and there's less experimentation going on, it feels. Whereas with the React Native ecosystem, there's a bunch of people working on 3D rendering at the same time, and then there's a bunch of people working on web support at the same time, and then there's a bunch of other people working on native to, you know, JavaScript interfacing all together. I think it brews, a healthy amount of competition to try to get the best solution out of there. [28:52]
-
-**Carl Vitullo:** Yeah, thriving ecosystem in the biological sense. It's uh, evolution, survival of the fittest, many, many competing strategies and competition with each other. It's cool to see work on the bridge happening, because, I haven't done a ton of serious development with React Native, but that has always been a huge bottleneck. [29:10]
-
-I mean, you know, anytime you have a lot of data flowing through one thing, like, it's gonna be a challenge, it's gonna be a limiting factor if it's not fast. Interesting to see this come out of CodeGen from using TypeScript as a schema, it sounds like. It sounds familiar to my extremely vague understanding of things like protobuffers, where, like yeah, if you're just sending JSON, There's only so much you can optimize it because JSON as a data structure is just slower to parse. [29:37]
-
-You know, you don't have a schema, you don't know what it looks like, so you have to figure out what it looks like as you go. So starting from a schema, starting from a specification of what the data contains, and then using that to generate like ultra fast native code makes a lot of sense to me. That's, that's pretty cool. [29:53]
-
-## [JSR and Deno: Final Review 🚮 ](https://dbushell.com/2024/08/09/jsr-and-deno-final-review/)
-
-**Carl Vitullo:** All right. I will bring us on. Just a couple thoughts on JSR and Deno. I think Mark brought these up and had them cross my radar, but David Bushell, who is a WordPress developer mostly, wrote a couple of blog posts that I think are pretty It's a pretty rough indictment of the JSR, you know, module ecosystem and generally the path that Deno has taken through module, you know, managing modules, package dependency. [30:20]
-
-One of the criticisms that he brings up about Deno in general is as a, you know, okay, it's a venture backed company. We've talked a little bit on this show before about venture backed open source projects. One of the criticisms that David Bushel puts out is that it doesn't really feel like, it feels corporate, like the communication feels corporate. [30:38]
-
-It feels like corporate PR, not, you know, somebody talking about what they're working on. And that was actually, that resonated with me because that's something I've noticed. Like, for instance, I set up an ecosystem news channel here in Reactiflux, and Deno stuff is some of the only things that come through it, and it feels like somebody set up a corporate process and there's somebody whose job it is to make sure that all of the communications channels get populated, you know, in a way that it doesn't feel that way for other projects like Expo or React or things like that. [31:07]
-
-So, I don't know, just like as a vibe. That was an interesting call out that I had noticed on my own as well. They talk about the meandering path that Deno has taken through trying to get package dependencies going, you know, cause, um, Ryan Dahl had a, you know, what node got wrong about Imports, I'm misquoting that, but he complained about errors he had made in creating Node and talked about how he was going to do it differently this time with Deno. [31:34]
-
-And then they, you know, they did like a deno. land package registry for a while and then like, oop, nope, we're replacing that with JSR. But now it's all a little confused. Like it's, JSR applies certain restrictions on what you can publish. Like you have to annotate the return types. of any published module. [31:53]
-
-So you can't just let it infer the return type, which seems like a kind of strange restriction to put on it. I guess it's maybe to enforce SemVer through types, you know, use those return types as a schema and assert like, oh, nope, you got to break it. You change the types. I don't know. It's interesting. [32:08]
-
-It's curious. The single most, like, disruptive point that David Bushell made was pointing out that Dnode doesn't resolve sub dependencies like Node does. Like, the way that the JSR registry works does not permit sub dependencies in the same way, in the way that we've grown accustomed to with Node. Which, like, I have called that out before. [32:28]
-
-That, subdependencies, dependencies of dependencies, is one of the best parts of the JavaScript ecosystem. The fact that I can install a package and I don't need to, you know, to an extent, I don't need to Manually make sure that I have given it everything that it needs. You know, there's some exceptions, like if you're using, you know, there's peer dependencies where that is still the case, but in general for if I install a library, that library brings in what it needs on its own. [32:56]
-
-There's downsides to that of course, as well, but I generally consider that to be one of the major differentiators between JavaScript and, you know, PHP or Python. So seeing that go backwards is, seems like a bad thing to me. So that seems, yeah, I don't know. It's just a, a lot of pretty negative takes on Deno and JSR. It's given me a lot of pause on it. [33:15]
-
-**Mark Erikson:** I mean, it's not just one hard problem, it's dozens o f hard problems simultaneously. I mean, you know, think, think back to, you know, trying to work with C where there is no such thing as a package manager. Java is sort of its own different world. C sharp is its own different world. [33:31]
-
-Rust has the cargo tool and a centralized registry. Python is an utter mess. There was an XKCD years ago about how bad Python package management is, and I've continued to kind of just keep a general eye on developments in the Python world. And it's more confusing over time. So there's a lot of very, very justified complaints about how bad package management is on multiple levels in, we, we say the JS ecosystem, and by that we usually mean the Node plus NPM. [34:02]
-
-But all things considered at the same time. Most of that ecosystem generally works, and so it's been interesting to see Deno take a slightly different path and actually have to sort of backtrack a bit and say, Well, yeah, actually it turns out maybe a couple of those ideas weren't so bad after all. [34:19]
-
-**Carl Vitullo:** Right, they went pretty hard in copying Go style dependency management. [34:23]
-
-And I always thought Go style dependency management sounded like an absolute nightmare. And so, yep, alright, they're walking some of that back. [34:30]
-
-## [web-infra-dev/rslib: The library build tool powered by Rsbuild](https://github.com/web-infra-dev/rslib)
-
-**Mark Erikson:** There's yet another new build tool out called RSLib to work through the chain of pieces on this one. [34:37]
-
-So, the folks at ByteDance have an incredibly prolific infrastructure team, and so the way I understand this is they built a full blown Rust re implementation of Webpack that they call RSPack. In fact, they've actually made a couple comments about it would be nice if this could just be turned into Webpack version 6, in theory. So RS Pack is web pack five, but entirely rebuilt and rust, effectively. [35:02]
-
-RS build is a layer on top of RS Pack that makes it a lot easier to configure, or the, the configuration syntax is closer to like Es builds configuration level roughly than web pack's configuration level, where you're having to create a whole bunch of plugins. [35:19]
-
-And so, rsbuild is meant more for applications, and I guess they've made a third layer on top of that where rslib is a wrapper or specialization of rsbuild that is more meant for building libraries with a proper configuration output. So, I'm not sure what's leading to all this proliferation of build tools from them, but they are very happily cranking away on a whole series of things. [35:45]
-
-## [2024 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2024/)
-
-**Carl Vitullo:** All right. I'll pull us onto our next one. We spent a lot of time last month talking about state of JS, state of React, state of HTML, we have another survey, the Stack Overflow Developer Survey, the results came out this month. I'm not going to do too deep a dive, I think, although Mo, yeah, we had talked about, you know, demographics and selection biases of the state of JS, definitely more to talk about here. Yeah, some, some points that I took away from this that were interesting to me. I mostly looked at the professional developer respondents, just that's who I am. That's who I am viewing as the target audience for this show. [36:20]
-
-Something that surprised me a little bit, they said that more than 75 percent of professional developers have at least a bachelor's degree. I think it was like 45 percent have a bachelor's, like 26 have a master's, and like another 5 percent have some kind of specialized professional degree, like a JD or, you know, something like that, legal, medical, whatever. [36:40]
-
-For years of experience, front end developers were absolute bottom of the list, except for student, which was interesting, but also not surprising. You know, Boot camps, they probably teach you front end, like, makes sense. It's probably the most accessible part of the software field. So not super surprising there, but yeah, uh, also less than 6 percent of respondents to this survey self identified as a front end developer. [37:03]
-
-That's lower than I think it was in previous years. It feels like front end has kind of. I don't know, it feels like it's diminished over the last couple years. I was looking at the country demographics. I was curious about this because I know from our statistics who uses Reactiflux, I know that we have a huge Indian population within the server. Having my own read, my own perspective on what those metrics look like by actual like usage and participation. I was curious to see how they'd be reflected. And the answer is not great. Top five countries as responded to the Stack Overflow survey were the U. S. with like 19 percent, Germany with a bit over eight, India with a little over seven, UK with five and a half, Ukraine four and a half. [37:45]
-
-I was curious to see how, what data I could find to back that up on, you know, what those stats look like. I couldn't find a direct comparison between the US and India, partly because the only English sources I could find for tech jobs in India just said all of IT, all of software in one. [38:02]
-
-### https://www.meity.gov.in/content/software-and-services-sector
-
-### https://www.bls.gov/oes/current/oes151252.htm#nat
-
-**Carl Vitullo:** But yeah, they said five and a half million IT and software workers in India, when I summed those same jobs up for Bureau of Labor Statistics in the U. S., that was like four and a half million. So just to say, there's definitely a huge English speaking bias in these surveys, which is unfortunate because the programming world is much larger than the English speaking world. some other Things, JavaScript was the number one most used technology here, and 25 percent of people learning to code self reported using Google Cloud. [38:32]
-
-I think that was like one of the top. That was the number one. That was the like most reported. Vercel was number three in people learning to code. Uh, for professional developers, top three, obviously, AWS, Google, and uh, Microsoft, but Google and Microsoft combined were about equal to AWS's numbers. On that list, Vercel was seventh. [38:51]
-
-Just about a percent lower than DigitalOcean, which was behind Cloudflare, which was behind Firebase. React and Node, together, both topped the web frameworks list of, technologies used with jQuery in number three. But yeah, 18 points behind React and Node, so definitely a different tier. But yeah, jQuery, what staying power it's had. I actually saw that this was, I believe the 18th birthday? It's old enough to vote. [39:15]
-
-**Mo Khazali:** The one thing that's interesting to me is just the 25 percent of folks learning to code use Google Cloud. I have a suspicion that might be to do with the fact that I know that there are GCP is quite involved in student fairs and a whole bunch of stuff giving free credits to people for hackathons and whatnot. [39:31]
-
-I wonder if there's some sort of correlation there where a lot of people seem to use it for their student experimenting and hacking, but maybe not so much when they get into the professional world. Just an observation. [39:42]
-
-**Carl Vitullo:** Yeah, that actually makes a lot of sense. I have seen them sponsor a lot of hackathons and things like that. [39:46]
-
-Yeah, I hadn't considered that, but scans. Cool. That was our last main content piece, uh, I guess into the lightning round. [39:53]
-
-## [Cocoapods going into maintenance mode](https://blog.cocoapods.org/CocoaPods-Support-Plans/)
-
-**Mo Khazali:** I'll just jump in with an update from the React Native ecosystem, or more, more broadly speaking, the mobile ecosystem. So, in terms of package managers, CocoaPods used to be the be all and end all when you wanted to build an iOS app, in terms of managing your packages, and we've come a long way where CocoaPods is now going into maintenance mode. [40:10]
-
-Now, CocoaPods is actually used by most of the cross platform technologies as the package manager of choice. So React Native uses it, but I think Flutter also uses it, and apparently Unity also uses it for some of their stuff as well. So there's a whole lot of this ecosystem that's being built in CocoaPods. [40:25]
-
-But what's happened here is that Apple's actually released their own package manager called the Swift Package Manager, or SPM for short. What the CocoaPods team called it was that they got Sherlocked, which is a reference to old school OS X, where they Basically got rid of an app called Watson, which was what Spotlight is now. [40:41]
-
-They created Sherlock at that point, which basically did all of the functionality that Watson used to do that was already integrated into the OS itself. So they're basically citing that saying we've been Sherlocked and we're now going to go into maintenance mode as a result, because there's no competing with Apple. [40:55]
-
-So a sad day for everyone who loved and used CocoaPods for years, but obviously we're going forward into the SPM era and React Native is already kind of on that route to adopt SPM support. [41:07]
-
-## [Accident Forgiveness · The Fly Blog](https://fly.io/blog/accident-forgiveness/)
-
-**Carl Vitullo:** I saw a cool policy change for Fly. io, which is a, sort of a competitor to Vercel, it's a cloud compute platform. [41:14]
-
-They are doing an explicit accident forgiveness policy, which is just kind of great. It's generally socially understood that platforms like AWS or Vercel or, you know, whatever if you have some weird billing situation that arises, like I think one that happened was like somebody got in an infinite loop during their CI build and that caused a huge number of function invocations and because you could build per function invocation, they had, you know, like a 200, 000 bill when they're used to paying like 2, 000. [41:45]
-
-It's socially understood that most of the time, if it's not a repeat occurrence and it's not malicious, then they will forgive the bill. But it's socially understood. It's not in policy anywhere. It's just you put it on Twitter, you complain, it becomes a PR issue, and the company refunds you. [42:00]
-
-So now fly. io has put up an actual policy saying we forgive accidents and has given more clarity around there. I appreciate that. It's always nice to see social norms turn into policies, especially when they deal with six figures in billing. [42:17]
-
-## [spatial compute](https://sunilpai.dev/posts/spatial-compute/)
-
-**Carl Vitullo:** I saw a wonderful blog post from Sunil Pai, who I'm just a big fan of. We've collaborated a little bit in the past, but he has done PartyKit. He worked on Wrangler at CloudFlare. He's now working at CloudFlare again. He wrote about spatial compute, which is letting the network decide where in the world to run your code. So this is sort of an incremental step forward for serverless paradigm. [42:40]
-
-Instead of starting up a server that runs your code, you just say, this is the code that I want to run. Please start it when this request is made. But you still generally tell it, what region of the world that code is going to be hosted in. So this is just a blog post talking about not doing that. Letting the server decide, letting the network decide where in the world to run your code. [42:59]
-
-I just think that's a really interesting idea. It seems good. Seems kind of inevitable. Uh, and this is the first time I've ever seen anyone mention it. So calling it out. [43:06]
-
-**Mo Khazali:** Interestingly, he's called it spatial compute. And I think he's put a disclaimer at the top saying, sorry, Apple, but that I wish he chose another term for that. [43:13]
-
-That's already been used. [43:15]
-
-**Carl Vitullo:** Oh, that's true. That is what Apple called their Vision. [43:17]
-
-**Mo Khazali:** Yeah. Vision Pro Computing. Yeah. It's, it's, I wish there was another term he could use for this. [43:22]
-
-**Carl Vitullo:** I like that he called it out and still did it anyway. [43:25]
-
-**Mo Khazali:** Yeah, exactly. [43:25]
-
-## [How Airbnb Smoothly Upgrades React](https://medium.com/airbnb-engineering/how-airbnb-smoothly-upgrades-react-b1d772a565fd)
-
-**Carl Vitullo:** Womp womp. Yep. Airbnb, we talked about Airbnb last episode as well. Uh, they put out a blog post about how Airbnb smoothly upgrades React. [43:34]
-
-Last month, we talked about how they had just upgraded to React 18. So this is now two months later. them talking a little bit more about the process by which they did so. It was a pretty good read. It talks a lot about, like, feature flagging, you know, blue green deployments, and just sort of the trials and tribulations of what it means to update a core dependency of a widely used app that is in many, many phones with a huge variety of, you know, Performance and, you know, network and all those sorts of things. [44:01]
-
-So I appreciated that, just right at the beginning of the They show like, you know, here's the ideal, like a stair step function of what version we're using. And then here's the reality of what version we've used over time. And it's got lots of like false starts where it's, they ship it and it's like, Oh, nope. [44:14]
-
-Okay. There's a bug. We got to roll it back. Let's try again. Nope. Still bugs. Roll it back. This is, Relatable to my career. There's just, you can't do a big overhaul without missing some kind of edge case that you didn't anticipate. So, um, just always appreciate seeing people pull back the curtain and show what those pains look like, especially at big companies that have huge distributions. [44:34]
-
-## [Use useId() Instead Of Hand-Making IDs](https://reacttraining.com/blog/use-useid-instead-of-hand-making-ids)
-
-**Carl Vitullo:** all right, great blog post from React Training, which I'm actually not sure who's running this anymore, but it was started by Michael Jackson and Ryan Florence of React Router and Remix. They've been on my radar for a very long time. Looks like this was written by Brad Westfall. Use ID instead of hand making IDs. [44:50]
-
-This was one of the clearer articulations of what use ID is meant to be used for that I've read. This just really kind of made it click for me. It talks about using. an ID attribute on the DOM, and why you shouldn't handwrite them. And it was just very clear and simple. The gist of it is, if you handwrite an ID, then you can only use that component once in order to not violate the guarantees that an ID has with the browser. [45:17]
-
-You know, in a browser, an ID is supposed to be unique. If you select an ID, you get one element exactly. And so if you hand write an ID, your component can't be reused without violating that contract. What a simple idea. That makes sense. I now intuitively understand why use id is a valuable API to have. Um, yeah, just appreciated that. I love when something I didn't understand just clicks and becomes intuitive. I like it. [45:42]
-
-## [Common Sense Refactoring of a Messy React Component](https://alexkondov.com/refactoring-a-messy-react-component/)
-
-**Carl Vitullo:** Calling out this great blog post from Alex Kondov, he wrote, Common Sense Refactoring of a Messy React Component. Refactoring messy components, breaking them down into, from one mega component that does way too much into a smaller number of components that each have a smaller, you know, a single responsibility, has been a recurring theme in my career. [46:01]
-
-This looked like a really great write up. I appreciate that it just does, like, A two paragraph preamble and then dumps 300 lines of kind of gross code on you. It's like, yeah, you know, that is, that's the experience of entering a new code base most of the time. I appreciated this breakdown of here's what the process of refactoring a messy component looks like. [46:20]
-
-## [Introducing Structured Outputs in the API](https://openai.com/index/introducing-structured-outputs-in-the-api/)
-
-**Carl Vitullo:** All right, small news from OpenAI. I had actually noticed this. We use OpenAI to do a resume review AI feature here, and I just did a revision to it, and it's much better. It's a little bit sassy. It's very terse. I like it. But yeah, OpenAI now has structured outputs in the API, so you can tell it what shape of JSON you want it to give you back, and it will give you that structure. [46:43]
-
-I know in the past that has been a pain point. I remember people complaining about like just getting OpenAI to give you pure JSON without like, okay, here's the JSON you asked for, JSON. Uh, you know, just purely unhelpful. Just caught this bit of news. If you're curious about writing a little open AI side project, I think this is maybe going to make it a bit easier. [47:03]
-
-**Mo Khazali:** It's also quite interesting for the mobile world, because you see a lot of a bigger shift towards server driven UI now, where, you know, you render things or you compile a JSON object that defines how the UI should look like in the mobile space, because, you know, that really works in mobile because, you You don't have to go through App Store updates, so you can basically have a dynamic page that uses JSON to decide how to layout itself. [47:24]
-
-And so maybe pairing that with something like this could be very interesting because you can give it the right confines and restrictions and then say generate me dynamic UI and then it'll kind of be a smart AI native based app. [47:35]
-
-**Carl Vitullo:** Wild. Kind of V0 vibes. V0 from Vercel. [47:40]
-
-All right. Here's my last little news item. [47:42]
-
-## [Sentry is now Fair Source](https://blog.sentry.io/sentry-is-now-fair-source/)
-
-**Carl Vitullo:** This actually crossed my radar very late. I would like to be more prepared to talk about this because it's at the intersection of, you know, open source and licenses and legal stuff, which I am personally fascinated with. But Fentry has announced that they are FairSource. FairSource is a new concept to me. [48:00]
-
-It's a new project. So they say, today we're launching FairSource, a new approach to software sharing that is safe for companies to adopt and developers to use. Seems pretty neat. They talk about, they give a list of projects that are working with it, and they define it as like publicly available to read, allows use, modification, redistribution with minimal restrictions, and I guess notably it says that it undergoes delayed open source publication, which they give as a four letter acronym, D O S P, very enterprise. [48:29]
-
-It's not quite a license, it's sort of a social contract surrounding a license, I guess. They talk about a new functional source license, but it also recognizes a fair core license. And the business source license. It's interesting. I'm definitely gonna have to dig into this a lot more because this is just referencing a bunch of licenses that I haven't heard of in a like social contract for how source gets released that I haven't seen codified. [48:56]
-
-I've seen companies do things similar to this before, but there hasn't been a name for it. It hasn't been saying like, yes, we are. This, we are FairSource, so definitely interesting. It's not quite free and open source, but it is adjacent free and, you know, FOSS, FOSS has been difficult for many companies to actually execute on and live up to. [49:17]
-
-So this looks like a more friendly. type of license, mode of releasing source code into the world. So maybe it'll give engineers at more companies greater ability to make a compelling case for open sourcing internal code, which would be lovely. I would love to see more proprietary code get open sourced. [49:35]
-
-Too many things happen in secret. [49:37]
-
-**Mo Khazali:** The delayed open source publication is quite interesting because it's having a separate Closed source version of a code base that gets synced with an open source version is not, you know, unheard of. The React Native code base, as an example, is like this. So, it's not the most bizarre thing to have, and it's been happening. [49:52]
-
-It's just maybe not been codified like you mentioned, and maybe this is the way to do it. [49:56]
-
-**Carl Vitullo:** Right, exactly. That's the classic problem in a lot of businesses that would like to open source, is there's some part of it that is, like, truly proprietary, where if they release that, then, like, you know, they're giving away the secret recipe. [50:07]
-
-Or Contractual agreements they have with their customers where like they wrote some custom integration code and like that can't get open sourced. So like there are very real business constraints that make it difficult in some cases to open source code. Like you said, some companies have done that through things like synchronizing source code, but that's been done kind of ad hoc. [50:29]
-
-It's, you know, Each company has figured out its own way to work, to make that work. So seeing this as a template, a framework for people evaluating that decision, to push it over the finish line, to make it actually happen. Uh, that seems really valuable. This seems like one of those like quiet things that will have an outsized impact on the open source world. Pretty neat. [50:51]
-
-## [Job Market](https://layoffs.fyi/)
-
-**Carl Vitullo:** All right, some information about the job market. It was not great this month, but most of that was because of layoffs at Intel, just not great. So 15, 000 layoffs from Intel alone, overall like 25, 000 layoffs in tech. Which is not great, but since most of that came from one company, that's still pretty on track from where it was last month. [51:11]
-
-Intel screwing up doesn't really reflect too much on the broader, you know, tech and software ecosystem, I don't think. [51:18]
-
-### https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
-
-**Carl Vitullo:** I've been using this Fred data source of. Job postings on Indeed. And that is still trending down, which I'm a little surprised about. It's just been a consistent downward trend. It's down to 68 percent of the baseline of like the start of 2020. So, you know, pre pandemic, which I'm surprised. That's wild. I thought it was getting better. [51:38]
-
-**Mo Khazali:** Just on that, I guess like Intel and Cisco both together are 21, 000 out of the 25, 000 layoffs. So if you take those two out, it's, it's actually like three, four thousand. [51:49]
-
-**Carl Vitullo:** Okay. That's actually quite a bit smaller. [51:50]
-
-That's nice. So yeah, last month I commented that it was the first time in a while we haven't had a pretty big pop of layoffs at the start of a new quarter. So yeah, cool. I guess that's generally holding true except for two megacorps running into problems. [52:04]
-
-A couple of new releases. [52:06]
-
-## [Material UI v6](https://mui.com/blog/material-ui-v6-is-out/)
-
-**Carl Vitullo:** material UI put out version 6. They commented that they took two and a half megabytes out of the bundle size they'd installed on your disk, not the published size of your bundle, which made me look at that and go, wow, this is a 12 megabyte Install size, which is wild. That's larger than I realized. But yeah, Material UI, if you're using it, there's a new version out, new major. [52:28]
-
-**Mark Erikson:** Although on that note, the TypeScript team has done some fantastic work shrinking the size of the installation on disk. Like it, it was up to like 50 megs, I think, as of like 9. And they did a lot of work in 5. 0 to convert some of the internals over to ES modules. And then, and then. Working on deduplicating some of the bundled files that they had and other internal optimizations. [52:55]
-
-I think at this point it's down to like 20 or 25 megs, which is still sizable, but I mean on the other hand, you know, 50 percent net win is a net win. [53:04]
-
-**Carl Vitullo:** Adhering that size, you know, 25 megs for all of TypeScript versus, you know, I don't know if it's exactly 12, I don't have the number in front of me right now, but half of TypeScript for material UI seems like a pretty big lift. [53:16]
-
-## [Tauri v2 RC ](https://v2.tauri.app/blog/tauri-2-0-0-release-candidate/)
-
-**Carl Vitullo:** There's also Tauri v2 has a release candidate out. I don't know a ton about that, but we talked about it briefly in the past. [53:24]
-
-**Mark Erikson:** It's an Electron competitor allows you to build apps that run on the desktop But the UI is built with web technologies The difference is that Electron you're shipping an entire copy of Chrome as the rendering engine Whereas Tauri uses whatever OS's native web views instead So the overall shipped size is a lot smaller. [53:43]
-
-**Carl Vitullo:** Heck yes, seems cool. So they've got a new version 2 coming out, which should be big. [53:47]
-
-## [NX v19.5](https://nx.dev/blog/nx-19-5-adds-stackblitz-new-features-and-more)
-
-**Carl Vitullo:** There's also NX version 19. 5. I don't know a ton about NX. [53:53]
-
-**Mark Erikson:** It's primarily a monorepo management tool. So managing lots of individual packages for both, you know, multiple libraries, multiple applications in one repo, which each of which could be, you know, being built with different tools. Like you might have, you know, a common TypeScript library and maybe, you know, a Vite app and an Angular app all in the same repo. And so NX does work to deduplicate the builds as well as manage creating and updating a lot of those packages. [54:20]
-
-## Upcoming conferences
-
-**Carl Vitullo:** On to some conferences that are coming up. [54:22]
-
-### https://www.reactuniverseconf.com/
-
-**Mo Khazali:** Next week, if I'm not mistaken, and time is not escaping me, is React Universe Conf. React Universe Conf happens every year in Wroclaw in Poland. So it's happening on the 5th and 6th of September. Uh, it used to be called React Native EU, but it's now evolved since React and React Native are getting closer and closer together by the day. So I will be emceeing the conference. Hence why I'm giving this shout out. [54:44]
-
-So come along. Hopefully it'll be a good time. There's a lot of great speakers headlining there. [54:48]
-
-**Mark Erikson:** Was it September, almost September already? [54:50]
-
-**Mo Khazali:** That's why I have to take a double glance at the calendar. [54:53]
-
-### https://www.jsconf.cl/
-
-**Carl Vitullo:** Cool. There's also JSConf in Santiago in Chile. Overlapping with React Universe. So that's going to be September 5th through 7th. [55:01]
-
-### https://utahjs.com/conference
-
-**Carl Vitullo:** I feel like we've been talking about Utah conferences a lot, I guess. But yeah, Utah JS is doing a conference. Seems like there's been a lot of stuff going on in Salt Lake City. Yeah. [55:10]
-
-### https://reactalicante.es/
-
-**Carl Vitullo:** There's also React Alicante in Spain, September 19th through 21st. [55:15]
-
-**Mark Erikson:** I'm speaking, looking forward to it. [55:17]
-
-**Carl Vitullo:** Woo! [55:18]
-
-### https://www.jsconf.ie/
-
-**Carl Vitullo:** And JSConf Ireland in Dublin, September 25th and 26th. [55:23]
-
-### https://2024.squiggleconf.com
-
-**Carl Vitullo:** Yeah, SquiggleConf in Boston is October 3rd and 4th. This is organized by a conference buddy of mine, Josh Goldberg. He is author of a book on TypeScript and just a wonderful, friendly, lovely person. I'm actually going to be volunteering there, so I'll be helping out with making sure the conference goes off. [55:41]
-
-**Mo Khazali:** Yeah. So Josh, I was going to similarly give a big shout out to Josh for being an amazing person. But beyond that, me and him have been bonding. So we spent a bit of time in Amsterdam and we bonded over being first time conference organizers this year. So him and I have been trying to be each other's support group here and they're sending each other some tips and advice. [55:57]
-
-But Josh is, is incredibly well known in the community and he's going to hopefully put together a really, really cool event. So definitely go there if you're in the U. S. [56:05]
-
-**Mark Erikson:** The other organizer, Dimitri, is less well known, but also a wonderful person. [56:10]
-
-**Carl Vitullo:** Yep, I just got to meet Dimitri the other day, uh, talking about volunteering. Seems really cool, seems really lovely. I'm going to brag, I was at the table at React Miami where Josh Ideated the name SquiggleConf, so I was there for the origin. So, very happy to volunteer. [56:26]
-
-### https://www.rendercon.org
-
-**Carl Vitullo:** Overlapping with that, there's RenderCon in Nairobi, Kenya, October 4th and 5th. [56:32]
-
-### https://www.reactindia.io/
-
-**Carl Vitullo:** Then, React India in Goa, India, October 17th through 19th. [56:37]
-
-### https://www.react.brussels/
-
-**Carl Vitullo:** There's React Brussels in Brussels, Belgium, October 18th. I went to that not last year, but the year before. It seemed really great. I got to hang out with the organizer at React Conf in Las Vegas, and just really great dude. Would recommend React Brussels for sure. [56:53]
-
-### https://reactadvanced.com/
-
-**Mo Khazali:** Cool, next up we've got React Advanced London, so this happens around October time every single year in London, so I've been going for a few years now, and the Great React Conference is probably the biggest React Conference that there is in the UK, so definitely head there, I will be there again this year, so if you're around, pop me a message and we'll say hi. [57:09]
-
-## Outro
-
-**Carl Vitullo:** All right, cool. That is everything we've got for today. Thank you everyone for joining us. We will be back on the last Wednesday, even though today is Thursday, uh, last Wednesday of the month to hear on the live stage of Reactiflux or back in your podcast feed just as soon as we can. [57:23]
-
-**Mo Khazali:** Thank you all for joining and listening to us ramble on and chat all things React and React Native. [57:28]
-
-It is always a pleasure and see you all next month. [57:31]
-
-**Carl Vitullo:** We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, the React. js subreddit, and here in Reactiflux. If you see anything that seems newsworthy, uh, that you think we should discuss, just put it in the tech reads and news channel here in Reactiflux. [57:49]
-
-Or, if you like, You can send it to me in an email at hello at reactiflux with T M I R in the subject line, which is a, it's an acronym for the show. I read every email that comes in, including spam because I'm a crazy person. So I will read it even if we don't end up covering it. If this is the show you get value from and want to support, the best way you can do so is by giving a review on Spotify or whatever platform that you actually listen to. [58:15]
-
-Tell your friends, tell your coworkers, we're cool and smart and we can help you sound cool and smart too. You're pretty cool and smart too. See you guys next month. Bye.
diff --git a/src/transcripts/tmir-2024-09.md b/src/transcripts/tmir-2024-09.md
deleted file mode 100644
index 3ac2e84..0000000
--- a/src/transcripts/tmir-2024-09.md
+++ /dev/null
@@ -1,517 +0,0 @@
----
-title: "This Month in React, September 2024: Async Components??, a React 19 cheatsheet, static Hermes, and trademarks drama"
-date: 2024-09-25
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Mo Khazali as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Mo Khazali](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-### New releases
-
-- [[00:57](#node-v2280)] [Node v22.8.0](https://nodejs.org/en/blog/release/v22.8.0)
-- [[01:06](#deno-v2-rc)] [Deno 2.0 Release Candidate](https://deno.com/blog/v2.0-release-candidate)
-- [[01:47](#relay-v18)] [Relay v18](https://github.com/facebook/relay/releases/tag/v18.0.0)
-- [[02:28](#redwood-v8)] [Redwood v8.0.0](https://redwoodjs.com/upgrade/v8)
-- [[04:09](#epic-react-v2)] [EpicReact v2](https://x.com/kentcdodds/status/1838263679025844378)
-- [[04:55](#rspack-v1)] [RsPack 1.0](https://rspack.dev/blog/announcing-1-0) and [Rsbuild 1.0](https://rsbuild.dev/community/releases/v1-0)
-- [[06:20](#metro-08011)] [Metro 0.80.11](https://x.com/MetroBundler/status/1831709057670861260)
-- [[07:52](#effect-38)] [Effect 3.8](https://effect.website/blog/effect-3.8)
-- [[08:43](#astro-415)] [Astro 4.15](https://astro.build/blog/astro-4150/)
-- [[09:45](#react-email-v3)] [React Email 3.0](https://resend.com/blog/react-email-3)
-- [[10:26](#react-native-076-rc2)] [React Native 0.76 RC2](https://github.com/facebook/react-native/releases/tag/v0.76.0-rc.2)
-
-### Main Content
-
-- [[15:08](#bulletproof-react-updated-to-include-nextjs)] [Bulletproof React updated for NextJS](https://github.com/alan2207/bulletproof-react)
-- [[15:52](#new-react-native-debugger)] [New React Native Debugger](https://www.youtube.com/watch?v=b48Lax2-jOQ&t=4350s)
-- [[18:05](#hermes-new-runtime-bytecode-translation)] [Hermes new Runtime Bytecode Translation](https://www.youtube.com/watch?v=pfeTPSai6vc&t=8702s)
-- React 19
- - [[22:14](#react-19-cheat-sheet)] [React 19 Cheat Sheet](https://www.epicreact.dev/react-19-cheatsheet)
- - [[24:10](#whats-new-in-react-19)] [What’s new in React 19](https://vercel.com/blog/whats-new-in-react-19) (moreso a discussion of the evolution of the rendering model)
- - [Build-time Components](https://codehike.org/blog/build-time-components)
- - [You can use async functions for components in React 19??](https://x.com/kentcdodds/status/1831331752343716003)
- - [Core team forgot to put it in release notes??](https://x.com/sebsilbermann/status/1831405742257271202?t=RkXE1h91Ckher4kWUrzWuQ&s=19)
-- [[26:22](#a-milestone-for-typescript-performance-in-tanstack-router)] [A milestone for TypeScript Performance in TanStack Router](https://tanstack.com/blog/tanstack-router-typescript-performance)
-- [[27:46](#weve-decided-to-make-a-few-changes-to-ease-the-adoption-of-next-15)] ["we’ve decided to make a few changes to ease the adoption of Next 15"](https://x.com/feedthejim/status/1829569083777437745)
-- [[30:07](#trademark-disputes)] Trademarks drama
- - From Deno: [JavaScript™](https://javascript.tm/)
- - [[31:46](#wp-engine-v-automattic)] [WordPress](https://x.com/photomatt/status/1838738735795703976) v [WPEngine](https://x.com/justinferriman/status/1838356417482514842)
- - [[33:10](#trademark-diff-seems-targeted)] [Trademark page diff seems targeted](https://www.diffchecker.com/tJ29tGIn/)
-- [[33:49](#youre-writing-a-vite-based-spa-you-need-to-add-a-few-api-routes-ie-for-authentication-what-do-you-do?)] ["You're writing a vite-based SPA. You need to add a few API routes (i.e., for authentication). What do you do?"](https://x.com/aboodman/status/1836470815862460506)
- -[[36:43](#mos-talk-at-future-frontend-2024)] Mo at Future Frontend: [Dynamic UI at the Edge](https://youtu.be/BRce-DHEoNc?si=AsVqdVrxbiO9nyW9)
-
-### ⚡ Lightning round ⚡
-
-- [[39:03](#nitromodules-released-to-the-public)] [Nitromodules released to public](https://mrousavy.github.io/nitro/)
-- [[39:31](#nodejs-adds-an-experimental-permission-model)] [NodeJS adds an experimental permission model](https://twitter.com/liran_tal/status/1830621784770555915)
-- [[40:54](#typescript-with-react-styleguide)] [TypeScript Styleguide](https://mkosir.github.io/typescript-style-guide/#appendix---react)
-- [[43:05](#inside-ecmascript-javascript-standard-gets-an-extra-stage)] [Inside ECMAScript: JavaScript Standard Gets an Extra Stage](https://thenewstack.io/inside-ecmascript-javascript-standard-gets-an-extra-stage/)
-- [[44:34](#remix-the-web-from-mjackson)] [The Neverending Story](https://garrettdimon.com/journal/posts/the-neverending-story)
-- [[44:34](#remix-the-web-from-mjackson)] [Remix The Web from mjackson](https://github.com/mjackson/remix-the-web/)
-- [[46:42](#replacing-react-code-with-css-has-selector)] [Replacing React code with CSS :has selector](https://www.developerway.com/posts/replacing-react-with-css)
-- [[48:19](#performance-optimization-strategies-for-large-scale-react-applications)] [Performance Optimization Strategies for Large-Scale React Applications](https://old.reddit.com/r/reactjs/comments/1f6abzy/performance_optimization_strategies_for/)
-
-### Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-- [SquiggleConf](https://2024.squiggleconf.com) Boston, MA USA Oct 3-4
-- [RenderCon](https://www.rendercon.org) Nairobi, Kenya Oct 4-5
-- [React India](https://www.reactindia.io/) Goa, India Oct 17-19, 2024
-- [React Brussels](https://www.react.brussels/) Brussels, Belgium Oct 18
-- [Next.js Conf](https://nextjs.org/conf) SF, USA Oct 24
-- [React Advanced London](https://reactadvanced.com/) London, UK Oct 25, 28
-- [HalfStack London](https://halfstackconf.com/london/spon) London, UK Nov 13
-- [React Native London](https://www.reactnativelondon.co.uk/) London, UK Nov 15
-
-**Carl:** Hello, everyone. Thank you again for joining us for the September edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live in Reactiflux, the place for professional React developers, and we're supported by Infinite Red, a little bit more on them. I'm going to do something different this month. I'm going to do the ad read after our You know, quick hits at the start. [00:21]
-
-Hello, I'm Carl. I'm a staff product developer and a freelance community manager here at Reactiflux, uh, where I run community programs like these events and help keep the community operating. [00:31]
-
-This month we don't have Mark, sadly. He's in Turkey, um, I think. Not sure if he did a conference, but he just couldn't swing it this month. [00:37]
-
-**Mo:** And I am Mo. I head the mobile team at Theodom. I'm quite active in the React Native ecosystem. Get very involved in a bunch of different conferences and some open source here and there. [00:47]
-
-I organize the React Native London, community. And basically oversee a team of different developers who are specialized in React Native. So, happy to be here to chat, as always. [00:56]
-
-**Carl:** All right, straight into some new releases. [00:57]
-
-## [Node v22.8.0](https://nodejs.org/en/blog/release/v22.8.0)
-
-**Carl:** We've got Node version 22. 8. I didn't see anything super big that caught my eye in this change. New Node, minor version released. [01:06]
-
-## [Deno v2 RC](https://deno.com/blog/v2.0-release-candidate)
-
-**Carl:** We've got Deno v2 release candidate coming out. It looks like this is coming out in Continuing the trend over the last couple months that we've discussed of Deno kind of walking back some of its opinions, they have gone pretty hard on Go style dependency management and a couple of other Go and other highly opinionated back end languages. [01:25]
-
-They're kind of walking those back. Stuff like, they had been Encouraging people to use window instead of process. They are changing that in order to be more compatible with existing NPM modules. Just generally be more compatible across the ecosystem. Yeah, a couple of other things like that too, like making it easier to use with NPM. [01:41]
-
-Generally making it more compatible, which I think is why they're walking back some of their highly opinionated opinions. [01:47]
-
-## [Relay v18](https://github.com/facebook/relay/releases/tag/v18.0.0)
-
-**Carl:** We've also got Relay version 18. Are people still using Relay? I don't really have a good sense for its, I don't know, usage. I know, obviously, Facebook still uses, Meta still uses it, but, yeah, not sure how much community uptake it's had over the last three or so years. [02:01]
-
-**Mo:** Not much on our side. [02:03]
-
-**Carl:** But a change that should make it a little bit easier for people to start using, they have added IntelliSense for the Relay config file. Just getting started, I've tried to get started with Relay two or three times over my career, and just never got over that initial hump of figuring out how to get it working. [02:17]
-
-So, uh, maybe some stuff like that will help. Make it a little easier to use. Not having used it, I can't really speak to the other changes they have, but you know, improve validation of argument types, an alias, catch, throw on field error. Cool. [02:28]
-
-## [Redwood v8](https://redwoodjs.com/upgrade/v8)
-
-**Carl:** There's also Redwood with a major release, version 8. Redwood is sort of trying to be the Laravel of the React ecosystem, sort of an all in one framework that does all the things that you need. Instead of making you find all the packages yourself to glue the bits together, which seems pretty cool. Yeah, this major release upgrades a lot of dependencies, adds Docker support, which I was a little surprised to see. I, I think of Docker support as not something a framework needs to, like, explicitly add, but cool. [02:53]
-
-I guess maybe they're making it a little bit easier to just get running in that environment, which since Docker is such a widely used primitive, that makes a lot of sense. Seems cool. They talk about an experimental SSR and RSC setup, so if you're doing server side rendering, or if you're interested in server side rendering and server components, might be, should be easier. [03:12]
-
-As well as adding support for background jobs, which is definitely something that an all in one framework, I think, I would expect to provide. So that's cool. [03:20]
-
-**Mo:** The Docker support is really interesting because It's almost in direct, I want to say, almost opposing to how Next does it, which it seems to me like Docker is like, hey, you have a Docker image and you can basically use it to deploy your full stack web app into, into whatever cloud platform you want to use. [03:38]
-
-Super easy, primitive, that's agnostic to whatever cloud provider you want, you self host it, you scale it up yourself, however you want, and our batteries included framework will just work. Whereas Next is notoriously difficult to be able to, uh, self host. So I just find that interesting. Maybe it's directly done as sort of a distinguishing factor compared to Next. [03:55]
-
-I don't know, but I find it quite interesting. [03:57]
-
-**Carl:** Yeah, makes sense. I have preferred to host anything I do in Docker for most of the last 10 years, so it's, that will make it easier. I'm interested in trying out Redwood, so having it better support my preferred environment will definitely help with that. [04:09]
-
-## [Epic React v2](https://x.com/kentcdodds/status/1838263679025844378)
-
-**Carl:** There's a new release of Kent C. Dodd's Epic React, version 2. The overview of the course, it's going to teach you React fundamentals, hooks, advanced APIs, suspense, advanced patterns, performance, and server components. I was a little surprised I couldn't easily find like a diff of what is being covered and what they're focusing more on, uh, between the old version and the new version, which I had been hoping to see. [04:33]
-
-I have not bought it. I consider myself an epic React dev already, so I don't feel like the target audience. But yeah, they're doing a 40 percent off promo right now, so if you have an educational budget at work, definitely consider spending some of it on this. it's about 420 right now. Nice. [04:48]
-
-Full price is 700, and I think it's jumping up there in about two weeks from time of recording, which is on the 25th. [04:55]
-
-## [RsPack v1](https://rspack.dev/blog/announcing-1-0)
-
-## [RsBuild v1](https://rsbuild.dev/community/releases/v1-0)
-
-**Carl:** Some kind of big news. RS Pack and RS Build both released 1. 0 in the last month, about two weeks apart. RS Build is like a Rust based build tool, if you have not paid attention to previous episodes where we've discussed it. [05:10]
-
-A decent amount. And RSPack builds on top of that to provide a Webpack compatible bundler. I feel like this was all the way back to like 2014 15 when Webpack was new. I mean, Webpack really replaced tools like Gulp. I think I went straight from Gulp to Webpack, and it was a massive just step change improvement. [05:28]
-
-It was clearly better in just doing everything. Uh, but It was really complicated to configure, uh, not the fastest tool. So like, almost immediately people were talking about ways to make it faster, ways to make it do the great things that it did in a better manner. I feel like, uh, especially in the web ecosystem, we love our tools to be fast and snappy. [05:50]
-
-so a counterpoint to that, people have been interested in having a faster, better solution than Webpack, but the flip side is that Webpack does so much that it's just really hard to actually make a replacement. So I feel like this is a culmination of like a decade long process. [06:05]
-
-project to produce something like that. So to get a Rust based natively compiled language build tool that provides drop in compatibility with an existing massively complex, massively used tool. Awesome. Seems really cool. [06:20]
-
-## [Metro 0.80.11](https://x.com/MetroBundler/status/1831709057670861260)
-
-**Mo:** So, speaking of bundlers and staying on the same thread, as you will know, React Native has its own bundler that, uh, is purpose built. [06:28]
-
-or the use of React Native apps. Um, and it's called Metro. So, Metro just released a more of a patch than a minor although React Native's versioning is a little bit confusing because everything is a minor because they want to be able to do as many breaking changes as possible, but they released a patch and there was some insane performance benefits here, so They took the resolver step, which was a bit slow within Metro, and they made it around 15 percent, sorry, 15 times faster, and that made a massive difference. [06:56]
-
-So when they ran it on the, uh, Expensify app, which is notoriously a large scale, open source React Native app, the total build time, was brought down from around 13 seconds down to about 3. and that's about 4 times faster for the whole build process, right? So resolving is just one step of it, they've made that significantly faster, but that makes a big impact on the overall build time. [07:16]
-
-And so this is really cool, but one of the added benefits of this is because it's, it's, it's a, it's a patch here, it's actually not a breaking change at all. So you can use it 3 versions back, 3 major React Native versions back, and it kind of works. So all you need to do is just bump your dependencies and you'll get the faster resolving times, which is really cool. [07:34]
-
-So big shout out to the Metro team, specifically, uh, Rob Hogan's been working on this. They did a really good job, and hopefully it just makes our dev tools a little bit faster, which we all love. [07:42]
-
-**Carl:** Yep, yeah, right. Like I just said, we love our fast dev tools in the web ecosystem. Cool. 15 times faster in a patch release. That is rare. Very cool. [07:52]
-
-## [Effect 3.8](https://effect.website/blog/effect-3.8)
-
-**Carl:** Wish I could say more about this, but Effect has released version 3. 8. Cool. Effect seems really cool, but it's also got a really steep learning curve because it's basically an entire new, like, standard library and programming paradigm all at once. It seems really cool. What I've seen in it, it seems to take a lot of inspiration from functional programming tools like languages and environments like Elixir. [08:15]
-
-Just encouraging you to build more like composable APIs? Yeah, we, again, we've talked about this a little bit in the past, so it, I, I won't fully rehash everything, but it's a huge, massive, steep learning curve that seems really cool and possibly worth it. So it's, you know, it's, I feel like I say this so many times every episode, but this is something that I'm really curious about, learning more about and using more and yeah. [08:39]
-
-if you like functional programming in web, definitely. Consider looking at effect. [08:43]
-
-## [Astro 4.15](https://astro.build/blog/astro-4150/)
-
-**Carl:** We've got Astro 4. 15. Big change, they say that Astro actions are stabilized. Um, and it looks like they've swapped out how those actions are configured so that it's a little bit more concise. [08:54]
-
-Uh, you describe the shape of the data that it receives and what to do with that data when you get it. Rather than treating it like a whole request where you then, like, do the validation and the error handling yourself. That's adding some opinions to it, but doing a validation schema and then providing a handler that receives valid data that conforms to the schema that you provided. [09:16]
-
-Seems like a pretty solid abstraction point there. There's also some other things like, the astro islands pattern. you could previously configure it to load those islands asynchronously, idly, when the, when the tab is idle. Uh, and they've now added a timeout so you can set a maximum time that it will wait for your page to go idle. [09:36]
-
-Uh, which seems like a nice, you know, 99th percentile performance improvement. If, if, if you're on a slow device that never goes idle, that's going to cause problems if you're only loading when idle. [09:45]
-
-## [React Email v3](https://resend.com/blog/react-email-3)
-
-**Carl:** So we've also got a new major version of React Email, uh, version 3. 0. Looks like this is another, you know, release getting ahead of React 19. [09:54]
-
-They have swapped out their rendering. So it's now async by default. as well as adding a new component library, improving performance. They added a superbase integration so that you don't have to manually, like, render and then copy the output into superbase, which seems nice. I'm a little surprised to see a new component library here, but I guess in an email environment there are just so many ridiculous constraints that, uh, I guess it makes sense that you need a specialized component library for that environment. [10:20]
-
-But yeah, uh, React Email, if you're doing anything with emails, that seems like a pretty solid tool to use. [10:26]
-
-## [React Native 0.76 RC2](https://github.com/facebook/reactv0.76.0-rc.2)
-
-**Mo:** So, I've kind of stuck the next one in. It's not really a release, but it's a release candidate, so it's kind of a blurred line, but we'll just go with it. The second release candidate of React Native 76 is out. [10:38]
-
-So, when I say, for those who aren't in the React Native ecosystem, when I say 76, I mean 0. 76. It's just, it's so far up that we've just We just get rid of the zero because it's easier to say. But anyway, React Native, 0. 76, Release Candidate 2's out. Um, now, this will still take a few more weeks, at least, to, to land, but, this version of React Native is going to be, quite monumental because the new architecture will be the default. [11:02]
-
-Going forward from this version. Now this new architecture is nothing new. It's been around, it's been talked about for years now. Um, contrary to the name, uh, it was new a while ago. Um, but it was a, it was a massive undertaking because you're basically gutting the internals of React Native, replacing it with React. [11:18]
-
-Something that's totally different in terms of how the native layer is handled. And so you're needing a new rendering engine, you need a new way to interact with native code and the native APIs. And so what that's meant is that this, it's had this long tail of getting library maintainers, 3P libraries, and, and, All of these things ready so that app developers don't have that much of a pain with some of their libraries not working if they switch over to the new architecture. [11:43]
-
-And so hopefully it's going to result in a lot more stability, some performance gains. We're waiting to see, but this is going to be a big release and you can still use the old architecture, but new one is the default. And it will be going forward. So, very exciting times, very monumental times. It's probably going to come with some teething pains as it does when you do such a major rewrite, but we're keeping our fingers crossed. [12:02]
-
-They've put a lot of work into this. [12:04]
-
-**Carl:** For sure, yeah. And as we've discussed many times on here, especially Mark, nobody tries really as candidates. So if you're using React Native, just At least give it a shot. See if there's any, like, obvious failure points, because, uh, open source maintainers love hearing about those growing pains as you're trying to switch over. [12:20]
-
-This is a great opportunity to do it. We're RC2. We're running out of candidates. [12:24]
-
-## Sponsored by Infinite Red
-
-**Carl Vitullo:** We are brought to you by Infinite Red, our main sponsor right now. They are an expert React Native consultancy that I am quite pleased to be a partner with because they are like authentically showing up to support the React Native and React ecosystems in like really meaningful ways. [12:40]
-
-They organize conferences, they host the largest React Native podcast, they publish the largest React Native focused newsletter, and they're Just really excited to work with them. Other than being great people who do great things in the community, they also, well, more precisely, they're a team of about 30 people, mostly developers with mostly greater than 10 years of experience. [13:01]
-
-So they actually work with your team to help you develop an expertise in building React Native. So if you are. Building something with React Native and need a little help hitting the ground running on that, definitely reach out to them because they are great people who will help you do good work. [13:17]
-
-## Upcoming conferences
-
-**Carl:** Moving on to some upcoming conferences. There's a lot, so I'm gonna just do, like, half of these, because we're already 15 minutes in. Mark and I will both be at SquiggleConf in Boston, Massachusetts, October 3rd and 4th. it's organized by a conference buddy of mine, Josh Goldberg. [13:32]
-
-I'm looking forward to it. It should be, should be a great time. It's going to be at the Aquarium in Boston, which seems great. there's also going to be RenderCon in Nairobi, Kenya, October 4th and 5th. React India is in Goa, India, October 17th through 19th. And React Brussels in October, uh, 18th, Brussels, Belgium. [13:51]
-
-There's also Next. js Conf in San Francisco on the 24th of October. [13:55]
-
-**Mo:** And then, if you're in London, ReactiveLabs London is happening on the 25th of October for the in person day and the 28th of October for the remote day. I will be there. I'll be doing a talk about React Native there, so if you're around, come and say hi. [14:07]
-
-**Carl:** Uh, I think Mark will be there too. Sadly, I will not. I will be in Mexico City, having a great time. There's also Halfstack London in London on November 13th. [14:16]
-
-**Mo:** And then this is the announcement that I've been waiting a long time to make on this conference, but we have the two month rule, so we're trying to remain impartial. [14:23]
-
-We are doing the first ever React Native conference in London. So, RNLConf, React Native London conference, effectively, is happening on the 14th and 15th of November. in London, central London at the Brewery, which is this like old building from the 1800s, uh, where a bunch of the monarchs of the UK went and visited, and it was a big festive place. [14:42]
-
-Anyway, it is now an events venue that we have gotten, and we're gonna have a lot of core people from the React Native ecosystem there. Charlie Cheever, the founder of Expo, is gonna be there. we have a lot of different cool folks from Meta, from Amazon, and from a bunch of different places coming to share. [14:54]
-
-Ideas and talks with everyone. If you are interested in joining, we have also, I've just made a discount code for anyone who listens to the podcast, so it's TMIR. Feel free to just grab a ticket that way, and hopefully you'll save a little bit of cash as well. [15:05]
-
-**Carl:** All right, into our main content. [15:08]
-
-## [Bulletproof React updated to include Next.js](https:/bulletproof-react)
-
-**Carl:** Bulletproof React got updated for Next. js. This is a simple, scalable, and powerful architecture for building production ready React applications, it describes itself as. Um, so this, I guess it's a set of example apps, to help you get started. I wanted to call this out because it seems like a pretty good resource. You know, it's a question we get in, you know, Reactiflux all the time. [15:30]
-
-It's like, hey, where can I find a, production grade application to use as a reference? I want to learn. I want to learn more about how they do it. and yeah, this seems like a good resource. It's, it's a whole ass. They have an example app written in a couple of different frameworks, so they have updated it to use the app router, I believe, and yeah, seems like a great resource. [15:52]
-
-## [New React Native Debugger](https://www.youtube.comt=4350s)
-
-**Mo:** Cool. So, this month we had React Universe Conf happening in Wroclaw in Poland. I was there hosting the conference and there was a lot of React Native stuff that was announced. now they were kind of s I want to say soft announcements in some capacity because people kind of knew about them already. It wasn't anything like mind blowingly new, but it was really cool to see the output of a lot of hard work that people have been anticipating for a while. [16:14]
-
-So the first one was the new React Native debugger. just a little bit of context on some of this. Debugging in React Native has been a pain. Anyone who's built with React Native knows that, like, debugging has been a mess. Like, you could use a bunch of different tools in conjunction with one another. [16:29]
-
-Some of them worked for certain things, other ones worked for other things. there was a point where, you know, you used Flipper for a while, and Flipper wasn't great. everyone really did not like Flipper, and so it got deprecated because it was just not really usable. so it was a lot of different tools that you needed to have in your tool belt to be able to effectively debug. [16:45]
-
-the new, the team at Meta tried to kind of, go from a fresh blank slate and say, hey, how do we build a really good debugger that resembles some of the experiences that people are used to with other frameworks and other other languages? And so they built a completely new debugger that's fully built on the Chrome DevTools protocol. [17:00]
-
-And it looked like it was, from what we saw at the conference talk, it looked like it was a lot more reliable. It addressed a lot of the minor pain points that you felt when you were trying to debug. And I guess the big thing was that we finally have reliable breakpoints. Which was a real pain to get working within React Native. [17:16]
-
-So, really, really, exciting stuff to, to, to get. And it should be public soon. So we're excited to get, get our hands dirty with it and, uh, and try it out. [17:25]
-
-**Carl:** Getting into the Chrome debug protocol seems like such a massive improvement here. Instead of using some kind of like bespoke debugging system, I love that you can just actually tap into a widely used tool that a lot of people are familiar with. [17:38]
-
-**Mo:** And it makes sense in terms of the direction that, you know, React Native is going, which is they want to make it more friendly for the web devs to be able to come in and build native mobile apps, right? So you don't want to force React web devs to learn a totally new dev tool framework or a model. You just use the tools that people are familiar with. [17:55]
-
-And so I think it was a great choice, and it looks good. So we'll wait for it to come into the hands of all of us, and then we'll play around with it and make it better over time, and it'll be a great time. Oh, yeah. Cool. [18:05]
-
-## [Hermes new Runtime Bytecode Translation](https://wwwv=pfeTPSai6vc&t=8702s)
-
-**Mo:** So more stuff from React Universe Conf. Another announcement, almost like a thing that we saw into, was, Hermes, which is the JavaScript engine that's used with React Native on most apps, now has a new runtime sort of bytecode translation. [18:19]
-
-Now it's very complicated and complex, and the talk explains it far better than I do, because it's some really low level stuff, so you kind of need to wrap your head a little bit around assembly and some, some stuff like that. A little bit of context, just to contextualize this, I think helps. last year there was a talk by the Hermes team at React Native EU called, uh, talking about this, this new concept of Static Hermes, which was, could we take JavaScript code and, uh, Make it typed native code, and sort of compile that down so that you get near native, if not just native performance, using C Um, and so that was a really cool concept, and the benchmarks that they ran from their early tests was showing that it was massively faster to execute JavaScript code because you were basically executing native code there. [18:59]
-
-it was a really cool approach of, you know, How you bypass the restrictions of JavaScript's runtime. But there were some limitations in the sense of how people use React Native in practice. And, you know, people use a lot of different features like over the air updates, which means you can kind of replace your JavaScript bundle. [19:17]
-
-with a server and add new code to a mobile app without going through an app store. So that's like a big feature that a lot of people use in React Native. And so this wouldn't work with the current model of static Hermes. a lot of different build tools. when you, when you pass your code through something like Babel, it loses the type annotations. [19:32]
-
-So how does that then get compiled down to, you know, typed native machine code. It was hard to really wrap it into the ecosystem and how people are using and developing React native apps. So, Intermediately, the Hermes team's been working on sort of runtime bytecode translation, which means, Okay, well, if we can't do this at compilation time, could we? [19:52]
-
-Find ways to boost performance at runtime and compile things to native instructions without needing to necessarily rely on things that you might only have at compilation time, like your type annotations. whilst being able to still let people do things like over the air updates. And so that's this. [20:08]
-
-concept of the runtime bytecode translation. This isn't landed anywhere and it will take a long time. It will probably first go through Meta's internal process of testing and seeing how it works within their apps. And then if it's stable, it'll phase, in a phased approach, get drip fed to the rest of the community. [20:24]
-
-So it's going to take a little bit of time, but it's really interesting stuff and it can have massive performance gains when you're running really computationally heavy tasks that you would previously run in JavaScript, using this bytecode translation. [20:35]
-
-**Carl:** Interesting. Okay. So I remember Hermes. That's like, that was like a V8 competitor. It was a runtime for JavaScript optimized for React Native. So it sounds like this is going to be doing. Like, you know, all these JavaScript runtimes, they always have various levels of, JIT, just in time compilation happening. I remember, you know, V8 has like TurboFan, and I don't remember any of the other brand names. [21:00]
-
-But, okay, so this is sort of a new type of JIT sort of thing, where it, like, over time will create a I don't know, like codify the bytecode so that it doesn't need to do the JIT every single time? Is that, am I understanding that right? [21:14]
-
-**Mo:** That's what it seems like to me. Again, there's a blurred line between static release that happens at compilation and this, which is kind of JIT. [21:22]
-
-And this is a little bit, there is some level of caching that you can do, right, because those instructions don't change commonly. They're changing once every time you kind of do an over the air update. So, um, a lot is still unknown. it's just more, showing the possibility of if you have unannotated JavaScript code, how much could we, compile it down to bytecode and still get some of the performance gains that you can get out of something like Static Hermes. [21:46]
-
-Which would be a lot more aggressively, compiling things down and, and it has a lot more context because of having access to the source code and being able to run this at compilation. So it's a more practical step that they're trying to address with how the community uses React Native and how probably Meta uses React Native internally as well. [22:03]
-
-**Carl:** That makes sense. My mental model here is aggressive caching of JIT bytecode. Definitely will be curious to see how that shakes out as it starts to roll out. Exits idea stage and enters production stage. [22:14]
-
-## [React 19 Cheat Sheet](https://www.epicreact.dev/react-19-cheatsheet)
-
-**Carl:** All right. A bit of stuff on React 19. Man, I'm a little sad Mark isn't here today because there's a couple of new resources and some, some new info that I'd love to get his take on. [22:23]
-
-But yeah, so Kent C Dodds put out a React 19 cheat sheet and it looks pretty great. You know, even just kind of casually skimming this, I learned several new things that I hadn't realized. Even, even as someone who considers himself to put a decent amount of effort to stay on top of things as they happen. [22:40]
-
-I still learned about like four or five new things from this cheat sheet. Probably the single biggest one is that since when could we use async functions? Like we apparently in React 19 you can do if you know you're doing a function component like you do now you can just mark that as async and it will return a promise like async functions do and React just like knows how to handle that. [23:01]
-
-That makes a lot of sense. I am curious how that, I guess where I really wish I had Mark to talk about. This instead of me is, I don't really understand the difference between the suspense primitive of like throwing a promise versus now this where you can just return a promise. Yeah, this is a really great single page cheat sheet, you know, eight and a half by 11 with a bunch of great resources. [23:25]
-
-You know, it talks about like what the use hook is for, talks about the better error reporting, resource preloading APIs, so you can make sure that You know your fonts and your images are available. Loading style sheets with precedence. Uh, I, something I had known was that React 19 will let you render like scripts and style sheets just within your output and it will hoist them up to, you know, be Loaded as appropriately, something I didn't know is that you can signal their precedence, their relative precedence. So, you know, default precedents or high precedents. This is, this is a base level style sheet that needs to apply to everything versus this is a, you know, could override those base styles, things like that. Really great resource. Kent C. Dodds, of course, putting out lovely educational resources. [24:10]
-
-## [What’s new in React 19](https://vercel.com/blog/whats-new-in-react-19)
-
-**Carl:** There's also a great, What's New in React 19 blog post put out by Vercel. Mostly the bulk of the content talks about how the rendering model for React has evolved over the years. Uh, I thought this was just a really great breakdown of why. [24:25]
-
-We've gone from why React is pushing server components and like what the value proposition there is. It has a really great series of diagrams showing like, all right, this is how, this is how data fetch and resource loading happens in a single page application versus an SSR application versus now what React server components unlock. [24:47]
-
-And just showing like the data flow of like server to client. And it really does a good job of illustrating those waterfalls and how those waterfalls end up hap end up being imposed by the rendering model and how server components change that rendering model to enable fewer waterfalls to happen. another good resource talking about new things unlocked. In React 19, there was a good post talking about build time components, which is distinct from like server side rendering or server components, pretty related to like, you know, SSG, static site generation. Yeah, static site generation. [25:22]
-
-If you say that acronym SSG, the presumption is that that refers more to something like Gatsby, which is a one time, it doesn't have a server, it has static generation. so this, this discusses build time components, I think sort of as a complement to server rendering or server components, where as part of the build step, as part of, you know, your transpilation and compilation and whatever, you can statically generate. [25:47]
-
-Some of your, some of your resources, some of your pages, some of your components. I thought that was a good call out as new technical capability. Returning back to my earlier thought on the cheat sheet, I saw in real time Kent C Dodds learning that you can return a Promise from a component. So just like earlier this month, he put out on Twitter like, oh, you can, you can just do this. [26:08]
-
-You can just mark it as async. Amazing. So just to drop the link to a good thread in there, but really good. I'm not sure what the difference is between that. You know, classic suspense, throwing a based thing and just doing an async function. [26:22]
-
-## [A milestone for TypeScript Performance in TanStack Router](https://tanstack.com/blog/tanstack-router-typescript-performance)
-
-**Carl:** Moving on. TanStack had a really great post discussing a performance optimization they did for TanStack Router. [26:29]
-
-This is a very different type of performance optimization than most that we see discussed. This is not like runtime performance. This is not, you know, how the library works while you're using it. This is an optimization they did in your editor. So like, as your site grows larger, because their routing is type safe, it's actually doing a lot of, it's actually throwing a lot of work at the language server, at the TypeScript language server that your IDE is running. [26:56]
-
-In this blog post, they break down a pretty complicated site that has, I think they say, This example has 400 route definitions with validated search parameters, and I, you know, it takes like three seconds for the language server to get back to you. So, like, if you're writing code and you, like, open IntelliSense to see, like, oh wait, what, what query strings can this receive? [27:17]
-
-Like, sitting and waiting for three seconds as it parses that. Not great. but yeah, they talk about improvements they did for that. And just because, like, type safe routing is super cool and super difficult, and like, how often do you think about the performance of the TypeScript language server in your IDE? [27:34]
-
-For me, never. so just seeing this, like, Deep technical write up of how they've improved the performance of something that I have never thought about is pretty great, pretty interesting. [27:46]
-
-## ["we’ve decided to make a few changes to ease the adoption of Next 15"](https://x.com/feedthejim/status/1829569083777437745)
-
-**Carl:** Cool, an update on Next 15, which is not out yet. Yeah, they said, we've decided to make a few changes to ease the adoption of Next 15. [27:54]
-
-We'll relax the React 19 requirement for the Pages router so you can upgrade in your own time. I appreciated this because my read on the Next. Ecosystem right now is that there's a lot of attention being paid to the app router, but technically that's Bleeding Edge. That's the newest, still experimental grade, kind of. [28:14]
-
-So they encourage you to use it in the same way that open source maintainers encourage you to use release candidates. But strictly speaking, the Pages router is still where the business is. So seeing them talk about sending support for that into React 19 seems good. Bethany, for the app router, we decided not to block on the general release of React 19. [28:34]
-
-So I guess that they are looking to release. Finished non-experimental app router, before or, or they're decoupling released app router from the React 19 release. [28:45]
-
-**Mo:** Does that mean that they would ship the app router apps if you start a new app, router app with Next, that it would just be using like an RC of React 19, or would it just be using React 18 unless re 19 gets launched? [28:59]
-
-**Carl:** There was some confusion a while ago because they were using release candidates by default. Uh, I don't remember where that landed off the top of my head right now, but I think that's right, but I can't answer you definitely. I'm just looking at this thread again and I see someone ask a very similar question. [29:15]
-
-How do you relax the React 19 requirement when React is bundled into Next? Do you maintain a release for 18 and 19? Did not get a response, so not sure. This is kind of continuing the trend of version confusion with Next and React, like, it's not very clear. [29:33]
-
-**Mo:** I wouldn't personally feel comfortable using an RC with Next, if, Next 15, if they say, we've tested it, it's stable, but then at the same time, I wouldn't trust it to work well with React 18 either, because I would suspect they haven't tested that enough. [29:46]
-
-So, you're in this no man's land where you're like, do I just stay on Next14 until it's actually, you know, stable and React 19 is launched and out of our seat? Interesting questions. [29:57]
-
-**Carl:** Yeah. Confusing, but a similar, you know, vein of confusion as we've had for like most of 2024. That confusion has not been cleared up. Confusion remains. [30:07]
-
-## Trademark disputes!
-
-## [Oracle, it’s time to free JavaScript](https://javascript.tm/)
-
-**Carl:** There's been a couple of trademark dramas this month. Like, I don't know why all the trademark stuff is coming out of the woodwork right now, but um, the Deno team put out a, like an open letter requesting that Oracle release the trademark for JavaScript. and this is one of those like, Funny, weird like quirks of history that not that impactful, but it is still a thing. [30:27]
-
-Like Oracle owns the trademark for JavaScript. Like the reason that the TC39 standards body that determines what JavaScript is technically They are not building JavaScript. They're building ECMAScript, which ECMA is an international standards body. And the reason it's called that is because Oracle owns the trademark on JavaScript. [30:47]
-
-And they have done nothing with it. They have not enforced it, as far as I know, in a decade. They have not They haven't done anything with it. So, yeah, the Deno team is asking people to sign a letter. so, I would encourage you to do so. I have signed this letter. I think it's great. I would love for Oracle to be less in the web ecosystem. [31:04]
-
-Please. [31:05]
-
-**Mo:** I don't think I knew that Oracle had the trademark for JavaScript until I saw this. I don't know if you did, but it was, uh [31:11]
-
-**Carl:** I did know that. I mean, it's one of those stupid things. Like, it's called JavaScript because they were trying to, like I don't know. Ape on the popularity of Java back in the 90s, even though there's no relation. [31:23]
-
-So it's like, I think because I, I think it was something like in those early days, Oracle was like, no, no, no, no, hang on. You can't call it JavaScript. We own Java. And so I think that's how they ended up owning it, but then they didn't do anything in JavaScript or in the web because they're Oracle. And yeah, so it's just one of those like weird quirks of history. [31:40]
-
-So this feels like writing a wrong to me in a way that like, yes, please, let's resolve this tech debt, like get out of there. [31:46]
-
-## [WP Engine v Automattic](https://x.com/photomatt/status/1838738735795703976)
-
-## (https://x.com/justinferriman/status/1838356417482514842)
-
-**Carl:** And this is a little far afield from React, but there's been some WordPress drama. my, I don't do WordPress. I've never worked as a WordPress developer. So this is a little bit of me catching up on stuff. [31:59]
-
-But so my understanding of this is that there's. the WordPress maintainer is Automatic with two T's, and then there's a, another company called WP Engine that seems to, I think they're like a services business, I think, so I guess it's, it's a little bit like If there were two Vercels, like an official one that was actually maintaining Next, and then another one that, like, didn't actually do very much of the maintenance, but also provided all of the same, like, hosting, just with a different set of defaults. [32:26]
-
-And if that other actor that did not do all the maintenance work and the development work was making way more money than the people actually building on it. So, that's my understanding of the difference between Automatic and WP Engine. Is that WP Engine makes a lot more money and contributes less. so the CEO of Automatic has gone on a bit of a tear and it seems not great to me. [32:48]
-
-They are now accusing WP Engine of like infringing on the trademark of WordPress by way of introducing confusion. Like people think that WP Engine is, you know, WordPress engine and they think that they play a larger role in the ecosystem than they actually do. But they've done so, Automatic has done this by sending a cease and desist that doesn't, I don't know, it seems not great. [33:10]
-
-## [Trademark diff seems targeted](https://www.diffchecker.com/tJ29tGIn/)
-
-**Carl:** There's, um, the trademark page, I saw a diff, like, just in the last week, like, as they sent the cease and desist, Automatic updated the trademark information page from saying, you can do whatever you want with the abbreviation WP, to you can do anything you want That doesn't add confusion to the ecosystem, and also WP Engine is not great and we don't like them. [33:30]
-
-And so it's just like they specifically called out this organization that they are sending a cease and desist to in updating their trademark guidelines. It's just like, Oh, Oh, okay. I feel like if you wanted to make that argument and you needed to make it 10 years ago when they started. So it's drama, some big drama happening in WordPress right now. [33:49]
-
-## ["You're writing a vite-based SPA. You need to add a few API routes (i.e., for authentication). What do you do?"](https://x.com/aboodman/status/1836470815862460506)
-
-**Carl:** I saw a great. Twitter post from someone who is doing like a sync engines and lots of other like local first type development that I find very interesting. He posed the question, you're writing a Vite based SPA. You need to add a few API routes like for authentication. What do you do? And got a lot of engagement and I thought it was just a really good discussion. [34:11]
-
-I wanted to draw a little bit of attention to it just because a lot of great opinions coming out in there. I have recently been playing with. Cloudflare workers. And to me, they hit this really great niche that is perfect for this. Cloudflare workers are basically like serverless architecture. You, you know, set up a handler, and like, you don't do any of the infrastructure administration yourself. [34:31]
-
-It just, you know, starts up and stops. But they do it way better than anyone else that I've played with so far. Like, you know, I've used Lambdas and some other similar, you know, serverless architecture things, and all of them have, you know, Awful, terrible, brutally bad developer experience. Like, uh, this is a couple years out of date, so I think it's changed, but I don't think it's changed that much. [34:53]
-
-I, I just remember having to upload a zip file into AWS in order to test, in order to deploy changes to a, to a lambda function that I had written. And like, There's no environments, there's no way to say like, this is in test, this is in production, there's no way to test locally. So then like, this entire serverless framework spun up around that to try and make it better, but like, oops, it didn't actually work that way. [35:14]
-
-It didn't, it didn't match functionality, so it didn't serve the purpose. So yeah, I think for me this, the answer to what do you do if you need to add a few API routes is set up Wrangler, and then in locally and use Cloudflare Workers. [35:28]
-
-**Mo:** You stole the words from me, basically, which was I would use Cloudflare Workers for a few reasons, like AWS's serverless model means that you're still managing your infra to some degree, like what region do you place your serverless function? [35:41]
-
-How does it scale? How does it, you know, uh, how do you do API routing? Maybe you'll need to add another layer, with API gateway in front of it. It's not, like, Straightforward. And so Cloudflare Workers for me was like truly serverless because it's just a function that runs close to the users, somewhere on a CDN, and you get access to run some JavaScript somewhere on the edge, which is really quite cool. [36:03]
-
-there's some stuff around, you know, like I think that there's some trade offs, like you can't use Node packages, it's a custom runtime, and you know, if you want to use a specific router, like there is Hono as an example that you can use within Cloudflare Workers to do API routes. Auth is not as straightforward, I'd say. [36:19]
-
-So, like, for small tidbits And, you know, tasks that I just need something that runs without me worrying about it, definitely Cloudflare Workers. And so, shameless plug, I did a talk with, a very close friend of mine, Samuel McLeod, who now actually works at Cloudflare and is on the Wrangler team, so he works directly on Workers, and we were talking about how do you Move your front end code to live on the edge in Cloudflare Workers with minimal effort. [36:43]
-
-## [Mo's talk at Future Frontend 2024](https://youtsi=AsVqdVrxbiO9nyW9)
-
-**Mo:** So it's a, it's a, it's a talk that we did in Finland this year. Um, so, I'll share the link. but basically the gist of this was what if you could just take your use states that you have inside of your app and change it to use server state with a different import from a third party library and it would automatically just pop it inside of a durable object on the Cloudflare Worker environment. [37:02]
-
-And so there's a lot of cool magic and a lot of cool primitives that they've got that lets you build on top of, and I really like it. If I wanted to build a little bit more full fledged, you mentioned Auth as an example, maybe. I quite like Superbase these days. It's relatively simple. You know, you can run Deno functions within it. [37:18]
-
-It also has a database model, which, you know, is managed for you. It's kind of, for mobile devs, I think it's The better Firebase, which, you know, Firebase promised to be the way that you don't have to write back end code for a mobile dev, and then it really wasn't great. and I think Superbase is a little bit nicer, and it's also relational DBs, which I prefer personally, so. [37:38]
-
-It kind of just works. [37:39]
-
-**Carl:** Pretty much the major constraint of a serverless runtime is they pretty much have to be stateless because, you know, they start up and they spin it down. So if you want to persist state, you need to maintain some kind of other infrastructure to, you know, some kind of database or something like that, which like, as soon as you start running your own server for a database or something like that, like, well, why not just put the code on there too? [38:01]
-
-And Cloudflare workers give you both durable objects. Which are interesting and cool, and I haven't played with them very much, because they also have a key value store that is like this. Dead simple. It works basically like local storage with shared context between invocations of your workers, which just like, if I'm doing something small that I don't want to spend like a week setting up new infrastructure and then don't want to have to maintain that over time, like something that I can just forget about for two years and then come back to and go like, what, how, how the hell does this work? [38:33]
-
-Workers. Love it. I guess I should while hyping Cloudflare and workers so much, I should probably mention that they are like basically the only stocks that I individually own that isn't in an ETF, because I like Cloudflare. But yeah, that's, I don't know if I have a conflict of interest, but. [38:50]
-
-**Mo:** That is a vote of confidence, Carl. [38:51]
-
-**Carl:** I'm trying to put my money where my mouth is. Or, you know, now I'm putting my mouth where my money already was. ( both laugh) [38:57]
-
-**Mo:** is this some sort of, like, ramping up stock prices? I don't know. Yes, yes. [39:03]
-
-## [Nitromodules released to the public](https://mrousavy.github.io/nitro/)
-
-**Mo:** There's just a very quick update on NitroModules, which we talked about last month. And so, uh, NitroModules is this way to run faster native code from React Native. [39:12]
-
-And, uh, it's now been released to the public. And so a few people have been playing around with it. William Candillon, who builds React Native Skia and now React Native WebGPU, or WGPU, so to speak, is now using it on his project, and a few other people I know are experimenting with it. So we'll see some cool results, and I think it'll hopefully improve the performance of the React Native ecosystem as a whole. [39:31]
-
-## [NodeJS adds an experimental permission model](https://twitterstatus/1830621784770555915)
-
-**Carl:** Um, Node. js is taking a cue from Deno and they are adding a permissions model. I think this is super cool. I thought the permissions model is something that Deno got right. I think it's just very interesting to, rather than just allow all the permissions that your process has, being able to signal to the process, what this code is going to need to access. [39:56]
-
-Um, I think that's a, I think that's really good and interesting and useful, especially in alternate runtime environments like workers, like serverless environments and things like that. An example where this would be useful. I remember a couple of years ago, uh, someone in Reactiflux set up a little five project allowing anyone to execute code from within the chat. [40:15]
-
-Yeah. Um, so you could just, you know, like, use some chat command with a code block. They had set up a bot that would pull that code block in, execute it, and spit out the output. They were able to do that, I believe, because of Deno's permissions model. Because they could guarantee that the code only had access to this very tight sandbox. [40:32]
-
-You know, if you're running code from arbitrary people in a chat room, that's very dangerous. So you need an effective permissions model. So, um Now we have that. Now Node. js has that. Uh, maybe not relevant for most people, but especially if you are working on something that would allow, or that would benefit from allowing your users to run code, run arbitrary code, Node. js now supports that better, at least. [40:54]
-
-## [TypeScript with React styleguide ](https:/typescript-style-guide/#appendix---react)
-
-**Carl:** This isn't new. I don't think I, I have, no, it's undated. I don't know when it came out. but I just crossed my radar and I like it. It's a TypeScript style guide. they have a, they have a react appendix that I, I thought was pretty neat. And just, I love a good style guide. [41:09]
-
-Another common question in Reactiflux is like, what are the best practices? Well, there's a lot of practices. Some of them are worse than others. Some of them are good generally in all circumstances. Some of them only make sense in a very narrow range of circumstances. [41:23]
-
-So just like, what are the best practices is a very difficult question to answer. And I think this TypeScript style guide does a pretty good job of Outlining a decent range of them. You know, some of them are opinionated, like it talks about project structure and like how to organize your source code and like, okay, there's a lot of ways to do that acceptably. [41:40]
-
-but something in the, you know, the first thing it talks about in the React Appendix is like required versus optional props. And. It calls out props as a discriminated type, which is, it's so good. Instead of having a props object with a bunch of optional values, doing it as a group of different, you know, fully formed Types. Uh, so like, you know, the example they give is like a status indicator. Instead of saying like data, you know, error, status as like optional props, just saying like, no, no, the success status has a status value of success, data with this type, whatever. Then the loading status has, says this That's so much better. Like that is absolutely a best practice. So, um, Good resource, I enjoyed it. it had a couple of, maybe it's just because its opinions align with my own opinions, but I thought it was a really good resource. Definitely recommend it. And also, more generally, on the subject of style guides, I think a style guide is a wonderful resource to bring into your company. [42:44]
-
-Uh, the most effective teams I've been on have had a style guide document that was routinely updated. Just, uh, if. I think it's a really great anchor point for technical discussions. Like, if you have a technical argument with your team about, like, we should not be doing this, this is bad. Argument should have an output in the form of a PR to a style guide. I think that's really great. [43:05]
-
-## [Inside ECMAScript: JavaScript Standard Gets an Extra Stage](https://thenewstack.io/inside-ecmascript-javascript-standard-gets-an-extra-stage/)
-
-**Carl:** Not new news, but a good resource. We've talked briefly in previous months about the TC39 ECMAScript standardization process. You know, there's four stages, you can present an idea in stage one, then if you do X technical work, it gets to stage two. Stage three is like, basically standardized, but it's not shipped yet, and stage four is like, fully shipped. [43:27]
-
-There has been a problem over many years of a lot of things getting stuck at stage two. The transition between Stage 2 to Stage 3, and then like, oh, we found a new problem in Stage 3, so we gotta ship it back to Stage 2. Just like, the delta between Stage 2 and Stage 3 has turned out to be very, very large, in a way that has made it difficult to ship some of these proposals. [43:50]
-
-Just like, If it gets shipped back down to stage 2, that has some problems. So this article from The New Stack just did a really good job of explaining more of that history than the half assed summary that I just gave, and talks about the stage 2. 7, you know, sub stage that they added relatively recently. [44:09]
-
-It sounds like the gist of it is that if you've written tests for your thing, then getting bumped back all the way back down to stage two, like, calls into question the validity of those tests. And stage 2. 7 resolves that problem to make it a little bit clearer about what that means. If you're curious about, you know, if there's like, if there's a, proposal that you've been following and are curious about the standardization process. [44:30]
-
-Um, I just think this is a pretty solid resource explaining the history. [44:34]
-
-## [Remix The Web from mjackson](https://github.com/mjackson/remix-the-web/)
-
-**Carl:** cool. I came across a fun project from Michael Jackson, from the Remix team called Remix the Web. Michael Jackson, Ryan Florence have been so involved in the web React, in the React ecosystem for so long. I have always. I've respected them greatly as people who, like, they don't just try to solve a problem. [44:55]
-
-They try to solve a problem in a way that makes sense, given the primitives available on the web. So it's not just trying to do everything in JavaScript. Like a lot, a lot of Java, a lot of React libraries I've seen, they end up, re solving a lot of problems in JavaScript that you might not need to if you just leaned on the web platform a little bit harder. [45:14]
-
-And some of that is because of aspirational support for React Native. If you solve it in JavaScript, then it can work not on the web platform. So like, there's trade offs to doing that. The trade off is that If you write in JavaScript, like, it's probably going to be slower. It's probably going to be worse in some way than if you can use a native, you know, web platform feature. [45:34]
-
-That is the backstory for why I'm particularly interested in this. So, Michael Jackson is putting together a monorepo of modules that are narrowly scoped to do one thing and do that thing well. An example of this that I remember him talking about Years and years ago, in the context of React Router, is they built React Router on top of a primitive, on top of a wrapper they made around the history API. [45:59]
-
-So it's like, in trying to make a router, they found all of these weird, nasty edge cases around managing history, managing scrolls position, things like that, and found the platform feature to be highly deficient. as a, you know, mode of interacting with that. And so they made a wrapper abstraction around that to make it easier to deal with. [46:19]
-
-And so my understanding is that this Remix the web monorepo project is a bunch of those. So like in, if they find, A rough and grody, web platform feature, they write a wrapper around it, and into this repo it goes. So, uh, I'm interested, it seems curious, it seems pretty cool to me, I have certainly found a lot of platform features that don't do quite what I want, so, uh, I'm, yeah, I'm paying attention to it. [46:41]
-
-Seems cool. [46:42]
-
-## [Replacing React code with CSS :has selector](https:/posts/replacing-react-with-css)
-
-**Carl:** And somewhat related to the idea of solving things with JavaScript, I saw a good blog post titled, Replacing React code with CSS colon has selector. The gist of it is, I'll pull a quote. Until recently, we couldn't select objects in the opposite direction of the CSS cascade. You know, CSS is top down. [47:06]
-
-You can get, you can start from the top and it gets more specific. So you can say, in all of these elements that are under this type of parent, style it this way. But you can't, you couldn't say previously, in this parent, if it has this type of element within it, style it this way. It was a, it was sort of a, you know, unidirectional control flow in that way. You could style descendants based on their parents, but you couldn't style parents based on their descendants. And the CSS Has Selector enables you to do that, which I have run into so many situations where I wanted to do that, and you just can't. You just couldn't. So, uh, you end up having to solve it with JavaScript to like add a little bit of state to communicate whether some element is within it. [47:51]
-
-And yeah, so the CSS has selected something I've been wanting for a really long time, and I really appreciated that. I'm seeing it framed as, here's all the things you can stop doing with React because of this CSS feature. And yeah, it's written by Nadia Makarevic. I hope I'm not mispronouncing that. She also wrote a great book on React as well. Yeah, just really, I really enjoy her writing. She seems like a great writer and seems to pick good topics. I like it. [48:19]
-
-## [Performance Optimization Strategies for Large-Scale React Applications](https://old.reddit.com/r/reactjs/comments/1f6abzy/performance_optimization_strategies_for/)
-
-**Carl:** And last lightning round link, just going to call out a Reddit thread. I've started, I set up a thing to pull in top posts from Reddit into the tech reads and news channel, and it's served us some good stuff. [48:31]
-
-I like it. But yeah, somebody asked the question, somebody asked about. Performance optimization strategies for large scale React applications and it got a decent amount of response. So I just thought that was a good, I just wanted to call attention to a cool thread full of a lot of opinions. It seemed like a good thing. [48:47]
-
-I didn't really see anything that like massively caught my eye as like, this is the right thing to do. But it did get quite a few Lengthy explanations of how some person or another has done performance optimizations at work. Uh, and that was always a big part of my work. My career has always, I've put a lot of emphasis on performance optimizations. [49:08]
-
-Wanted to call that out. Go read it. It's good. [49:10]
-
-## Outro
-
-**Carl:** Cool. Alright, that's everything we got. thank you for joining us. We will be back on the last Wednesday of October here in the live stage or back in your podcast feed just as soon as we can, if that's how you listened. We gather sources from This Week in React, Bytes. [49:23]
-
-dev, React Status, Next. js Weekly. The React js subreddit here in Reactiflux and direct from those publishing articles. usually on Twitter, maybe on blue sky, maybe on RSS feed. Lots of things. If you see anything newsworthy, uh, definitely let us know in the tech News and reads channel of Reactiflux. [49:39]
-
-Or send it directly to me hello@reactiflux.com, uh, with TMIR in the subject line. It's an acronym for the show. I read literally every email that comes in, even the spam. So yeah, if you've got a hot tip, send it to me and I'll read it. if this is a show that you get value from and want to support, best way to do so is by submitting a review on Spotify, which helps us, Rank? [50:01]
-
-I'd say stay in the rankings, but like, we don't rank, so, you know. Or, you know, post it on Twitter, send it to your co workers, stuff like that. Appreciate it. Thanks for listening. [50:08]
-
-**Mo:** Always fun to do this every single month. Thanks, for having me, and hopefully I'll see you all at some point in person, somewhere, maybe at the, uh, RNLConf. [50:15]
-
-Till next month.
diff --git a/src/transcripts/tmir-2024-10.md b/src/transcripts/tmir-2024-10.md
deleted file mode 100644
index 5013bb5..0000000
--- a/src/transcripts/tmir-2024-10.md
+++ /dev/null
@@ -1,751 +0,0 @@
----
-title: "This Month in React, October 2024: React DevTools update, React Native 0.76 (new architecture dropped), Web Components are(n't) the future"
-date: 2024-10-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:56](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- [[01:40](#new-releases)] New releases
- - [[01:43](#react-native-076-proper)] [React Native 0.76 proper](https://reactnative.dev/blog/2024/10/23/release-0.76-new-architecture)
- - [[01:54](#new-architecture-is-here)] [New Architecture is here](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here)
- - [[05:18](#bluesky-and-expensify)] [BlueSky](https://github.com/bluesky-social/social-app/releases/tag/1.92.0-na-rc.2) and [Expensify](https://blog.swmansion.com/sunrising-new-architecture-in-the-new-expensify-app-729d237a02f5)
- - [[06:22](#react-compiler-beta)] [React Compiler Beta](https://react.dev/blog/2024/10/21/react-compiler-beta-release)
- - [[07:23](#react-devtools-v6)] [React DevTools v6](https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#600)
- - [[07:50](#zustand-v5)] [Zustand v5](https://github.com/pmndrs/zustand/releases/tag/v5.0.0)
- - [[08:17](#eslintpluginreacthooks-v5)] [eslint-plugin-react-hooks v5](https://github.com/facebook/react/releases/tag/eslint-plugin-react-hooks%405.0.0)
- - [[08:45](#announcing-deno-2)] [Announcing Deno 2](https://deno.com/blog/v2.0)
- - [[08:45](#rbun-deno-2-vs-bun-what-are-your-thoughts-rdeno-deno-2-vs-bun-what-are-your-thoughts)] /r/bun: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/bun/comments/1fp9ndk/deno_2_vs_bun_what_are_your_thoughts/) [](https://www.reddit.com/r/Deno/comments/1fp9mom/deno_2_vs_bun_what_are_your_thoughts/)
- - /r/deno: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/Deno/comments/1fp9mom/deno_2_vs_bun_what_are_your_thoughts/)
- - [[10:14](#tauri-20)] [Tauri 2.0](https://v2.tauri.app/blog/tauri-20/)
- - [[11:40](#one-the-new-rn-framework)] [One - the new RN framework](https://onestack.dev/)
- - [[11:40](#creators-of-tamagui)] Creators of [Tamagui](https://tamagui.dev/)
- - [[11:40](#built-on-zerosync)] Built on [ZeroSync](https://zerosync.dev/)
- - [[16:15](#cloudflare-workers-updates)] [Cloudflare Workers updates](https://blog.cloudflare.com/builder-day-2024-announcements/?ck_subscriber_id=1888282043/)
- - [[22:05](#zeego-20)] [Zeego 2.0](https://github.com/nandorojo/zeego/releases/tag/v2.0.0)
-- [[22:33](#conferences)] Conferences
- - [[22:35](#halfstack-london-london-uk-nov-13)] [HalfStack London](https://halfstackconf.com/london/spon) London, UK Nov 13
- - [[22:40](#react-native-london-london-uk-nov-15)] [React Native London](https://guild.host/events/rnlconf-2024-y9arho/attend?discount=TMIR) London, UK Nov 15
- - Special Discount for podcast listeners with discount code TMIR
- - [[23:10](#react-summit-us-new-york-usa-nov-1821)] [React Summit US](https://reactsummit.us/) New York, USA Nov 18-21
- - [[23:14](#react-africa-casablanca-morocco-nov-29)] [React Africa](https://react-africa.com/) Casablanca, Morocco Nov 29
- - [[23:19](#react-day-berlin-berlin-de-dec-13-&-16)] [React Day Berlin](https://reactday.berlin/) Berlin, DE Dec 13 & 16
-- [[23:33](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red)
-- [[24:50](#some-react-19-progress-but-no-eta)] Some React 19 progress, but no ETA
- - [[24:50](#lazy-context-propagation)] [Lazy Context Propagation](https://x.com/sebastienlorber/status/1841042683122286641)
- - [[25:51](#“server-actions”-renamed-to-“server-functions”)] [“Server Actions” renamed to “Server Functions”](https://19.react.dev/reference/rsc/server-functions)
-- [[26:08](#react-native-bottom-tabs-library-using-native-bottom-tabs)] [React Native Bottom Tabs library using native bottom tabs](https://github.com/okwasniewski/react-native-bottom-tabs)
-- [[27:45](#meta-connect-showcasing-new-arvr-apps-built-with-rn)] [Meta Connect showcasing new AR/VR apps built with RN](https://engineering.fb.com/2024/10/02/android/react-at-meta-connect-2024/)
-- [[29:07](#static-hermes-updates)] [Static Hermes Updates](https://github.com/EvanBacon/expo-static-hermes-demo)
-- Reddit is revolting against Epic React
- - [[30:16](#anyone-else-feel-burnt-by-epic-react--rreactjs)] [Anyone else feel burnt by Epic React? : r/reactjs](https://old.reddit.com/r/reactjs/comments/1fwks6r/anyone_else_feel_burnt_by_epic_react/)
- - [[30:42](#epic-react-v1-=>-v2-upgrade-&-deception)] [Epic React V1 => V2 Upgrade & Deception.](https://old.reddit.com/r/reactjs/comments/1fut75h/epic_react_v1_v2_upgrade_deception/)
-- [[37:12](#web-components-are-not-the-future)] [Web Components Are Not the Future](https://dev.to/ryansolid/web-components-are-not-the-future-48bh)
- - [[37:12](#followup-to-this-from-march-2020-maybe-web-components-are-not-the-future)] Followup to this from March 2020: [Maybe Web Components are not the Future?](https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh)
- - [[37:34](#web-components-are-not-the-future--they’re-the-present)] [Web Components Are Not the Future — They’re the Present](https://www.abeautifulsite.net/posts/web-components-are-not-the-future-they-re-the-present/)
- - [[37:53](#liskovs-gun-the-parallel-evolution-of-react-and-web-components)] [Liskov's Gun: The parallel evolution of React and Web Components](https://www.baldurbjarnason.com/2024/liskovs-gun/)
-- [[44:10](#announcing-voidzero-next-generation-toolchain-for-javascript)] [Announcing VoidZero - Next Generation Toolchain for JavaScript](https://voidzero.dev/posts/announcing-voidzero-inc)
- - [[44:37](#oxc-transformer-alpha)] [OXC compiler](https://twitter.com/boshen_c/status/1840322879424258115)
- - [[44:37](#oxc-compiler)] [OXC Transformer Alpha](https://oxc.rs/blog/2024-09-29-transformer-alpha.html)
-- [[45:23](#updates-from-the-104th-tc39-meeting)] [Updates from the 104th TC39 meeting](https://dev.to/hemanth/updates-from-the-104th-tc39-meeting-14cp)
- - Stage 4 proposals
- - [[45:33](#promisetry)] [Promise.try](https://github.com/tc39/proposal-promise-try)
- - [[46:21](#sync-iterator-helpers)] [Sync Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers)
- - [[46:48](#import-attributes)] [Import Attributes](https://github.com/tc39/proposal-import-attributes)
- - [[46:58](#json-modules)] [JSON modules](https://github.com/tc39/proposal-json-modules)
- - [[47:05](#regexp-modifiers)] [RegExp Modifiers](https://github.com/tc39/proposal-regexp-modifiers)
-- [[47:11](#language-evolution-jssugar-proposal)] [Language Evolution](https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o/edit#slide=id.g30432c5cd9c_0_30) “JSSugar” proposal
- - [[47:11](#nullvoxpopuli-on-x)] [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389133810913338)
- - [[47:11](#nullvoxpopuli-on-x)] [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389157693227375)
- - [[47:11](#brendaneich-on-x)] [BrendanEich on X](https://x.com/BrendanEich/status/1842630141304025263)
- - [[47:11](#daniel-ehrenberg-thoughts)] [Daniel Ehrenberg thoughts](https://gist.github.com/littledan/a590784a72f2e1b8cc633ff5ff8a9dc2)
-- [[50:44](#⚡-lightning-round-⚡)] Lightning Round
- - [[50:44](#the-disappearance-of-an-internet-domain--io)] [The Disappearance of an Internet Domain](https://every.to/p/the-disappearance-of-an-internet-domain) – .io
- - [[51:51](#how-to-control-a-react-component-with-the-url)] [How to control a React component with the URL](https://buildui.com/posts/how-to-control-a-react-component-with-the-url)
- - [[53:16](#if-wordpress-is-to-survive-matt-mullenweg-must-be-removed)] [If WordPress is to survive, Matt Mullenweg must be removed](https://joshcollinsworth.com/blog/fire-matt)
- - [[55:09](#web-without-walls--dan-abramov)] [Web Without Walls — Dan Abramov](https://www.youtube.com/watch?v=F1sJW6nTP6E)
- - [[57:23](#preact-compat-discussion)] [Preact compat discussion](https://old.reddit.com/r/reactjs/comments/1fy2jjh/i_ran_into_preacts_false_promise_what_can_i_do/)
- - [[57:44](#content-visibility-in-css)] Content-visibility in CSS
- - [[57:44](#using-css-containment)] [Using CSS containment](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Using_CSS_containment)
- - [[58:00](#contain-caniuse)] [contain](https://developer.mozilla.org/en-US/docs/Web/CSS/contain) - [CanIUse](https://caniuse.com/mdn-css_properties_contain)
- - [[59:50](#contentvisibility-caniuse)] [content-visibility](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) - [CanIUse](https://caniuse.com/mdn-css_properties_content-visibility)
- - [[01:00:39](#how-i-built-my-blog-•-josh-w-comeau)] [How I Built My Blog • Josh W. Comeau](https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2/)
- - [[01:02:24](#types-of-react-components-2024)] [Types of React Components 2024](https://www.robinwieruch.de/react-component-types/)
-
-**Carl:** Hello everyone. Thank you for joining us for the October edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. [00:14]
-
-And we're supported by Infinite Red, a consultancy that exclusively works with React Native, but we'll do a little ad read for them later. [00:21]
-
-Hello, I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux where I run community programs like these events and the star helpers, and do other stuff to keep the community running smoothly. [00:33]
-
-**Mark:** Hi, I'm Mark. My day job is at replay. io, which we're going to have a slight tangent on the io part of this later on. And other than that, on Redux stuff. [00:43]
-
-**Mo:** The mobile team at Theodo which is a global consultancy and I'm active within the React Native ecosystem, organizing the React Native community and here and there dabbling in some open source. Happy to be here as always. [00:56]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Yeah. First up, some quick hits while people start filtering in. We did not do a job market update last month. It was actually pretty quiet. Not a lot of news. It seems kind of back to baseline. data for posts made to Indeed is still, like, two thirds of what it was at the beginning of 2020 before pandemic hit. [01:14]
-
-that might have been a high watermark for the industry, so it's, it's kind of hard to say. Layoffs at least have been, look very low for the last two months in a row. So that seems good, but yeah, the hiring has not really picked up. But not sure it's going to. [01:29]
-
-I wonder about that. Definitely the vibe I've been getting is that most of the roles being hired for are more on the seniors end of the scale, which is Not ideal, not great, but yeah, seems to be where it's at. [01:40]
-
-## New releases
-
-**Carl:** Yeah, into some new releases. [01:41]
-
-Moe, you want to tell us about React Native? [01:43]
-
-## [React Native 0.76 proper](https://reactnative.dev/blog/2024/10/23/release-0.76-new-architecture)
-
-**Mo:** Yes, indeed. I feel like this is years in the making, so I've got to really drum this up as much as possible. But, the new architecture is finally here, [01:54]
-
-## [New Architecture is here](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here)
-
-**Mark:** Woohoo! [01:55]
-
-**Mo:** So this is React Native version 0. 76. And if you go back into likethe history of React Native over the last five years, the first mention of the new architecture publicly was in 2019. [02:08]
-
-And really what the whole purpose of the new architecture was, was to make a more stable Baseline for React Native interacting with native platforms. How components are rendered. How does JavaScript code trigger native code and native modules? And how do we move different things around different threads and make sure that everything is optimized and consistent? [02:28]
-
-A lot of people think that the new architecture is like a performance oriented update. It doesn't really have that many major performance improvements. There's minor ones, but really what it's trying there for mainly is, I think, for library maintainers and for framework authors to be able to create a more consistent pattern of communicating between native and React Native. [02:47]
-
-So, for a little bit of context, React Native's old architecture used this thing called the bridge. So it was basically a messaging bridge where you could pass in serialized JSON from the JavaScript layer and from the native layer and it would kind of get communicated across this bridge. But the issue with a bridge is that it can have some traffic, right? [03:03]
-
-So you can bombard it with a lot of JSON and suddenly because it's asynchronous it has limits in terms of how much it can communicate if you were trying to update things frequently or send a lot of data through that bridge you would block that, and what we would call that is that the JS thread is blocked, and so your app would basically drop in its frame rate, the CPU usage would spike, and everyone would be unhappy, and your users would be like, Hmm, this is not quite native feeling to me. [03:30]
-
-But, as of now, there's been a lot of work that's been done. React Native has a bunch of different stuff that I'm not going to go into too much detail about. But the bridge has been replaced with what we call the JavaScript interface. And so what that means is JavaScript code can get a reference to a C object that communicates with a native layer, and it can directly invoke methods within that C layer that would live on the native layer. [03:51]
-
-So it removes the bridge and it's just direct communication via JavaScript interface to the native layer. So that makes things significantly more efficient. It's not just that, the new architecture is a lot of different parts. There's the new event loop, there's the new renderer and then there's the new native module system, and of course the JSI, which is kind of underpinning all of that. [04:11]
-
-the article that you shared in the chat has a lot of details and it's a good summary, so I would start from there if you've been kind of under the rocks. In the React Native ecosystem and not,really hearing much about the new architecture. I think it's a really good summary about why it matters, what you can achieve. [04:25]
-
-And ultimately, I think one of the biggest things is that it's giving you parody with React behaviors, because a lot of things that were in React before just didn't work in React Native properly and people were figuring that out on usage. Basically, it wasn't really documented very well anywhere. very exciting times. [04:40]
-
-it's finally happened. [04:42]
-
-**Carl:** Yeah, I feel like this is an update that's a little easy to be, you know, under a rock on. If it's been in progress for literally five years now, I could see how that might slip into the back of your mind as something like, There's a lot of things I waited five years for, and by about the third or fourth year, I started wondering if it was ever going to actually happen. [05:01]
-
-**Mo:** exactly, and you know, it's one of those things where yeah, it's been happening for five years, but you do get new architecture talks every conference that's a React Native conference or like React Native adjacent. So it's been the topic of conversation and everyone's like, Oh, that'll probably come at some point. [05:15]
-
-And it feels quite surreal to have it actually here. [05:18]
-
-## [BlueSky](https://github.com/bluesky-social/social-app/releases/tag/1.92.0-na-rc.2) and [Expensify](https://blog.swmansion.com/sunrising-new-architecture-in-the-new-expensify-app-729d237a02f5)
-
-**Carl:** Cool. I saw a post from Software Mansion, which is a React Native focused, consultancy as far as I know, talking about bringing the new architecture into the Expensify app, and I understand that the Blue Sky native app is doing a release candidate for it that's like, opt in, and they say it's, you know, it's a release candidate, it's unsupported, try it at your own risk, please report bugs. [05:41]
-
-But like, those are real apps, like Expensify is widely used enterprise app. So that's some real usage. That's pretty cool. [05:48]
-
-**Mo:** props to the meta team, they actually spent a lot of time with real apps that are large scale apps that, you know, were popularly React Native. They approached the developers of those apps and said, Hey, can you turn on the new architecture before we release and make sure that it's working and behaving and functioning in a way that doesn't really have regressions and is actually better than it was before. [06:06]
-
-So they've really tested this out and drawn it out. They've worked with library maintainers one on one to get them on to the new architecture boat. So, this is as good as it ever will get in terms of just biting the bullet and releasing. [06:19]
-
-**Carl:** Nice. Yeah. [06:22]
-
-## [React Compiler Beta](https://react.dev/blog/2024/10/21/react-compiler-beta-release)
-
-**Mark:** The first one is that the React compiler is now in beta. The first, you know, early adopter, I guess, releases came out at React Conf back in May. And it's now in beta you can actually meaningfully try it out, they've done a lot of work to try to improve the behavior against real world applications. [06:42]
-
-Along with that, there's a couple different ESLint plugins the Rules of React Hooks plugin has been updated, and it's got some additional checks for whether things are actually components. Along with that, the compiler has its own associated plugin that tries to check for the rules of React behavior. [07:02]
-
-You know, basically, are you doing anything that is considered illegal, even if it technically runs inside of your React component? And so they're highly recommending that people start trying to use the rules of React plugin in your applications to find places where you're doing things that you're really not supposed to in React. [07:23]
-
-## [React DevTools v6](https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#600)
-
-**Mark:** Along with that, there's a new React DevTools extension release. They did a lot of shuffling around of the internals, but what is probably most relevant here is that the DevTools now actually have support for showing server components in the tree. And this is a big deal, because up until now there really hadn't been any way to atsee what server components were actually, being used when you were looking at the code on the client side. [07:47]
-
-So that's a pretty distinct improvement there. [07:50]
-
-## [Zustand v5](https://github.com/pmndrs/zustand/releases/tag/v5.0.0)
-
-**Mark:** Flipping away from that over into state management, Zustan just came out with version 5, and it doesn't have any new features, but it does drop some, legacy backwards compatibility changes, default exports, a couple other things, and it now requires React 18. [08:08]
-
-So if you're using Zustan, you may want to look at picking that up. [08:11]
-
-**Carl:** Yeah. Hang on. The Redux guy talking about another state management library. Hold up. [08:15]
-
-**Mark:** I'm allowed to. ( laughter) [08:17]
-
-**Carl:** For sure . [08:17]
-
-## [eslint-plugin-react-hooks v5](https://github.com/facebook/react/releases/tag/eslint-plugin-react-hooks%405.0.0)
-
-**Carl:** There's also a new major version of the ESLint plugin for React Hooks. Looks like it supports ESLint v9, and it doesn't look like there's a lot of changes, I think it's mostly just compatibility for latest versions. But, they did change how the rule works for component names. [08:33]
-
-So now, previously it used to require a non lowercase letter. So it'll let you do things like an underscore in front, and now it doesn't. Now it has to be an uppercase letter. they kind of flipped the bit on that. [08:44]
-
-**Mark:** Picky, picky. [08:45]
-
-**Carl:** Cool. [08:45]
-
-## [Announcing Deno 2](https://deno.com/blog/v2.0)
-
-## /r/bun: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/bun/comments/1fp9ndk/deno_2_vs_bun_what_are_your_thoughts/) /r/deno: [Deno 2 vs Bun? What are your thoughts?](https://www.reddit.com/r/Deno/comments/1fp9mom/deno_2_vs_bun_what_are_your_thoughts/)
-
-**Carl:** Deno released version 2 as well. We've covered Deno sporadically over the last couple of episodes, but the highlights here that they shout out are backwards compatibility with Node. [08:56]
-
-js and NPM, native support for the package. json and Node modules. I guess that's part of backwards compatibility. More package management, I know, you know, the original idea behind Deno dependencies was just like a little bit more URL based and kind of free for all like no registry just like install code very like go Inspired and I guess they're walking that back pretty hard. [09:21]
-
-**Mark:** they've walked [09:22]
-
-back a lot of things around NPM compatibility. [09:25]
-
-**Carl:** Yes, I feel like they started out heavily opinionated and are walking back a lot of those opinions, which okay I mean, I guess fair enough. They did also do a lot of work on the standard library and things So it could well be that some of those opinions were just like this is less work. [09:40]
-
-We're gonna launch it they've got a standard library Support for private NPM registries. Yeah, a lot of these things are just kind of like details on backwards compatibility with node and NPM they're doing LTS releases. They've got their own JSR, JavaScript, something registry. [09:57]
-
-And there were a couple of threads that I wanted to shout out of exact same title posted in the Bun and Dino subreddits, Dino2 vs Bun. What are your thoughts? I won't summarize them. It's just like a bunch of Reddit commenters, you can see, see the two, the two camps reacting to the news, [10:14]
-
-## [Tauri 2.0](https://v2.tauri.app/blog/tauri-20/)
-
-**Mark:** The Tari framework, which lets you build desktop apps using web technologies as an alternative to Electron just came out with version two. They have some improvements around HMAR and plugins and various other internal improvements. If you're building desktop apps, probably worth taking a look. [10:32]
-
-**Carl:** Yeah, I thought it was neat that they added a permissions model. I guess they used to have like an allow list of things that your app was allowed to do. And they talked a little bit about enhancing that with, you know, a permissions model, which seems like a good improvement. Yeah, they also mentioned mobile support, which was like, what? I feel like they buried the lead on that. It's like, I want to know a lot more about that. I feel like Rust based native app framework where you can use React on Android and iOS. Like, huh, I want to know a lot more about that, but they didn't say too much in the announcements. [11:04]
-
-**Mo:** Yeah, it's, as with all things with thisso it's not official yet with Taure. I think they're just kind of working on it, so I,suspect they're kind of saying, hey, we're working on it. The general gist with all of these Electron like frameworks it ultimately ends upbeing something like Cordova with Ionic. [11:22]
-
-it's a web view that triggers some native functionality. It won't be a truly native app, which is, I guess, one of the distinguishing factors of React Native. But it'd be very interesting to see how they play this out. And how it works in practice. It might be something a bit different, but they're being very cryptic about it so far. [11:38]
-
-So, remains to be seen. [11:40]
-
-## [One the new RN framework](https://onestack.dev/)
-
-## Creators of [Tamagui](https://tamagui.dev/)
-
-## Built on [ZeroSync](https://zerosync.dev/)
-
-**Mo:** Moving on. So, earlier this year the React Native Core team came up with this big announcement saying, Hey, we think you should use frameworks. And not build your own frameworks every time you initialize a new React Native app. And so at that point they introduced Expo as the only option to, as a pre built framework. [11:57]
-
-They said, you know, you're either using Expo, or you've built your own framework by building on top of the core of React Native. And so now we have finally gotten a second framework that's come in and said, Hey, I I'm a contender for that spot as well. the framework is called one. I'm not too sure why there's, that's the naming, but, there we are. [12:16]
-
-You have a theory. All right. [12:17]
-
-**Carl:** so it looks like they're built on a sync engine that's called Zero. ZeroSync. so I guess this is, you know, they're built on Zero so they are one. [12:26]
-
-**Mo:** Cool. So, this is an interesting development because the person who's behind this is behind the library called Tamagui. So Tamagui is a styling library within the React Native Ecosystem. the whole spiel with Tamagui is that it's an optimized view layer library that you can use not just for your React Native apps, but also in things like Next. [12:46]
-
-js. So you can kind of share your UI across the board between React Native and the web. it's used to build these universal apps. Tamagui is quite an interesting project. It's actually a very heavyweight library, because it comes with things like a styling solution, a compiler that, does view flattening. [13:05]
-
-Next. js optimizations out of the hood. it's a very heavy styling solution when you're using it just for React Native, and it's notoriously complicated as well. they've taken Tamagui, paired it with a whole bunch of other stuff, like a file system routing based solution, and the most interesting part, I'd say arguably, is the fact that this is beat based.previous to this, you couldn't use Vite for React Native because you'd have to use either Metro or in some cases you could use Webpack, but it was quite a pain to actually get that working. the creator of this, Nate, has been working on seeing if Vite can become a compiler for React Native. [13:42]
-
-React Native, and it seems like there's some good movement on this. So, it uses Veep by default to kind of standardize the bundler across web and mobile. So, it's a very interesting proposition and they have a lot of experience but it's still going to be interesting to see how this plays out. [13:58]
-
-It's very early days. So, I would Tread with caution until it's reached some point of stability and it's being used. But it's very interesting to see how it's forming. [14:09]
-
-**Carl:** Yeah, definitely early days, but like, I'm taking this reasonably seriously. It seems like a pretty clever and opinionated take on how to do a framework on React Native. I guess, you know, like, my rough mental model for this this feels to me like the React Native equivalent for Remix. [14:28]
-
-in large part because it's beat based, you know, okay. [14:31]
-
-**Mo:** but it has a lot of, like, very similar ideas, right? Like, they've kind of introduced this concept of loaders as well. it's very Remix esque. so I can see why you take that comparison. [14:42]
-
-**Carl:** another thing that I find fascinating here is they put local first and sync engine very heavy in their homepage marketing for this. they talk a lot about this being built on zero sync, which is built by a company that I've heard of and that the CEO follows me on Twitter. [14:57]
-
-I think that's cool. it's being built by a team that worked at a decentralized exchange that I had heard of. Six years ago. So they worked on decentralized tech that I took seriously as someone I also worked in decentralized tech six years ago. So I think it's really interesting that that's the Opinion they're bringing to this company that they named that they worked at Uniswap I viewed as one of the serious contenders in web 3 before it became overtaken by scams So it looks like they have now moved out of Web3, taken that decentralized technology experience, and are building a React Native framework that is based around local first, you know, data on your device, primarily synced to a backend. [15:40]
-
-And I think that's really cool. I am pretty bullish on local first generally, I'm very curious to see how this works. Early days, like you said, it's interesting to me. I am intrigued. [15:51]
-
-**Mo:** and Uniswap is built with Tamagui. So the web and the mobile app is built with Tamagui which kind of is a real implementation, real world production app that's using the universal app paradigm. they know how to do it. It's just a matter of how, easy to use it is for other developers who aren't that familiar with this sort of framework or this [16:10]
-
-**Carl:** it's Yeah, right. It's easy to say how powerful and useful something is when you are the person who made it. [16:15]
-
-## [Cloudflare Workers updates](https://blog.cloudflare.com/builder-day-2024-announcements/)
-
-**Carl:** Cloudflare Workers released a bunch of new updates, and a lot of them look really cool to me. So I'm using Cloudflare Workers a little bit in like, a side project or two. [16:24]
-
-I would like to use it more for ReactiFlux projects, but actually Discord does not allow the gateway to connect to like, the Cloudflare Workers durable objects. For some reason, I don't know why, that seems weird. than the fact that you just can't connect to the API, they seem like a really powerful way to interact with Discord. [16:43]
-
-So, I would love to use them for that. Sadly, I can't. ButI think Cloudflare released, yeah, 18 big updates to the workers platform is the headline here. Literally the title of release. Something that I found really interesting is they are advertising CICD with PR preview releases for workers. [17:01]
-
-I think that's not going to be quite as like turnkey, instantly useful as it is in like Netlify or you know, Vercel where, you know, like, you get a PR preview on your website, you just get a new domain, boom, done, everything kind of works. Assuming you didn't like actively screw something up and how you are doing, you know, base URLs. [17:22]
-
-I think for a backend service like this, it's just not going to be quite so simple and like zero effort to take advantage of PR previews. Like you, you need to have a staging environment where you can be notified of a new URL being available and then dynamically swap out the, like, base route for this. [17:39]
-
-And then like other stuff, like what about. Seeding test data and things like that. So I don't think this is quite so like Mind blowingly immediately useful as it is on a web deployment CICD, but that's still super cool Like that's you know, like for it for a discord bot, which is mostly where I've tried to use these like that's still pretty Accessible. [18:00]
-
-Yeah, so I think that's pretty pretty useful some other smaller stuff Logging on the dashboard for your workers. I have run into issues with like Observability was not easy before this, so I have actually already enabled logging on the dashboard in one of my projects because I needed it, and I was like, oh, cool, great, now I can just do it's not effort. [18:17]
-
-Better Node. js compatibility, they have, because it's a serverless runtime, they don't have stuff, like FS or HTTP or things like that. It was a little bit more Sandbox, like, Request Lifetime, they give you the entire environment in the request handler. So, when they say greater Node. [18:35]
-
-js compatibility, I'm not quite sure how to interpret that. The, they had like a compatibility chart, and it included like 100 percent on, you know, NodeFS. But like, I don't know what that means when you don't have a file system, you know. I don't think they are actually emulating a file system where you can read and write. [18:52]
-
-Maybe they are, I don't think they are. [18:54]
-
-**Mo:** [18:54]
-
-they're slowly going through the list of Node APIs, And I think they support like only 50 percent of them. So they still don't support like file system in any capacity, just because it doesn't make sense for the runtimes they have, because our workers kind of just run in a V8 isolate. [19:11]
-
-just running somewhere on their edge network [19:13]
-
-**Carl:** That's what confused me though, because the compatibility thing said 100 percent coverage for FS. And so it's like, I know you don't support this because of the environment, what does that mean? I don't know how to interpret this chart. [19:24]
-
-**Mo:** yeah, I think some of them are probably just weird polyfills or just like shimmed values. I'm [19:30]
-
-**Carl:** Yeah, I mean, I guess even like, doesn't immediately explode is an improvement, you [19:36]
-
-**Mo:** Is it an improvement yet? [19:38]
-
-**Carl:** Which is where it's been for me, like, oh my god, there were some weird things that happened when I was trying to develop that. Like, CommonJS imports and things, yeah, so, yeah, I have to play around with that a little bit more. [19:48]
-
-Yeah, they also have Next. js support. via open next, which they've open sourced. So like, cool, here's an open source runtime that they are using themselves in production to provide next support. And like, that's enormous. I think I saw when this was announced Vercel, some of the big Vercel DevRel folks who are active on Twitter seemed a little bit like they were nervous. [20:12]
-
-**Mo:** I've used Cloudflare Workers quite a lot recently, and they had some, like, Next. js support, limited. They've been increasing it for the past few years. They started off with just, like, you can static export Next sites. Great. You can do that with anywhere and host it anywhere. Right? Then it was like, we'll support some limited sub features of Next. [20:28]
-
-And I think they're now supporting it almost fully with the OpenNext runtime. And I can see why some of the Vercel folks would be a little bit on edge, because if you support Next to that degree, yes, Vercel has a lot of nice DevEx features, but when you look at the cost for a large scale site, and where Vercel would make a lot of their money you can get the majority of those functionalities, or like 80 percent of those functionalities on CloudFlare pages. [20:52]
-
-it kind of works similarly. You get those preview branches and all of that. So I can see why they'd be a little bit anxious about that, but I suspect they'll do what Vercel usually does, which is introduce a new, like, runtime dependency, and then it'll take everyone six months to basically get on the same compatibility. [21:11]
-
-So we'll see. [21:12]
-
-**Carl:** They'll just dig that moat a little bit deeper, maybe. Yeah, they also have per worker SQLite, which is neat. Previously, I guess it had only been, like key value store based, so it was kind of like having local storage available per worker, which is great, but, you know, you can't query it.you can't really do structured data in a situation like that. As well as blue green deployments, incremental rollouts. And queues, and a vector database, performance improvements, like, you know, one of the performance improvements is faster time to first token on their AI, platform. [21:41]
-
-like you were saying, Mo, about Vercel getting maybe a little nervous aboutCloudflare workers with real Next support for things like the dynamic images, some of their, longer tail of server based functionality with PR previews, incremental rollouts, and, a queuing system, like,that starts to sound a lot like the offerings that Vercel offers. [22:03]
-
-But yeah, [22:05]
-
-## [Zeego 2.0](https://github.com/nandorojo/zeego/releases/tag/v2.0.0)
-
-**Mo:** Cool. I'll quickly just give a shout out to version Zgo. So for those of you who aren't familiar, Zgo is a wrapper, it's almost like an abstraction, on top of context menus on both native and web. So again, going in that universal app trend you can use a single API in your code base to create context menus for your web with Radix, and then it'll hook into the native layer context menus on iOS and Android. [22:26]
-
-So it's a nice little library to use as a utility when you do want to have context on certain elements of your app. [22:32]
-
-**Carl:** Cool, seems useful. [22:33]
-
-## Conferences
-
-**Carl:** Alright I'm gonna fly through some conferences. [22:35]
-
-## [HalfStack London](https://halfstackconf.com/london/spon) London, UK Nov 13
-
-**Carl:** Halfstack London is happening in two weeks. November 13th. [22:40]
-
-## [React Native London](https://guild.host/events/rnlconf-2024-y9arho/attend?discount=TMIR) London, UK Nov 15
-
-**Mo:** Yes, and another shameless plug React Native London conference, this will be the last announcement before it actually happens in Just over two weeks now. So, this is happening in London, of course on the 14th and 15th of November. Tickets are gonna probably start closing soon, in the next week and a half, roughly, so grab your ticket if you're interested, and there's a discount code with TMIR for this month in React. [23:03]
-
-Where you can get 10 percent off. So come along, say hi to me if you're there, shoot me a message if you do plan on attending. We'd love to host you. [23:10]
-
-## [React Summit US](https://reactsummit.us/) New York, USA Nov 18-21
-
-**Carl:** There's also React Summit in New York November 18th through 21st. [23:14]
-
-## [React Africa](https://react-africa.com/) Casablanca, Morocco Nov 29
-
-**Carl:** React Africa in Casablanca, Morocco at the end of the month in November 29th. [23:19]
-
-## [React Day Berlin](https://reactday.berlin/) Berlin, DE Dec 13 & 16
-
-**Carl:** And React Day Berlin December 13th and 16th. [23:23]
-
-**Mark:** I will be speaking at React Summit. [23:25]
-
-**Carl:** Cool. Yeah, go to React Summit in New York and go meet Mark. I live in New York. [23:31]
-
-I will try and make it if I can. [23:34]
-
-## [Sponsored by Infinite Red](https://infinite.red)
-
-**Carl:** So we are exclusively brought to you by Infinite Red. That's very tongue in cheek, but yes, they are our only sponsor right now. Infinite Red is an expert React Native consultancy. They've been around since 2015 uh, and are owned by Jim and Holmgren. [23:47]
-
-Todd Wirth and Gant Laborde. They've been super active in the community for literally my entire career. I got my start like professionally with React around 2014 or so. So like, I have been aware of them for a really long time. And yeah, I connected with them in a conference and just great vibes. So good. [24:04]
-
-They only do React Native and have built over 75 apps for companies from startups to like huge enterprises. And just like, other than being good people who do a lot of good things for the React and React Native ecosystemsthey seem to be very good to their people because they, like their average tenure of employees at their company is more than seven years. [24:23]
-
-Which is wild to me. That's double the tenure I've ever spent at one company. So that seems great. They are not a like feature factory. They work alongside your developers at your company and help you develop your own expertise there. So if you are spinning up a new product with React Native and want some help hitting the ground running, definitely give them a ring. [24:41]
-
-And uh, you do let them know that you heard about them from us. Not that we get anything out of it. Just, you know, Maybe help us in the next contract negotiations. He he he. [24:48]
-
-## Main Content
-
-**Carl:** Into our main content though. [24:50]
-
-## Some React 19 progress, but no ETA
-
-## [Lazy Context Propagation](https://x.com/sebastienlorber/status/1841042683122286641)
-
-**Mark:** So we've been attempting to track the progress of React 19 and there were a couple of progress that I saw happening in the last month or so. The. Big thing is that we're still waiting for them to finish work on the changes related to the parallel suspense rendering behavior that caused an outcry earlier this year. [25:13]
-
-And I saw a couple PRs from Andrew get merged. I later saw one of them get reverted. And then, just in the last week or so, I think I saw one of them get unreverted or a feature flag get landed around that. So, there is work going on, I have no evidence to say how much more work is needed to be done. I also think I saw someone from the React team, possibly Sophie, mention that they're hoping to get it out by the end of the year, but, you know, nothing concrete either way. [25:46]
-
-So, stuff's happening, stand by, and wait. It's all we can do. [25:51]
-
-## [“Server Actions” renamed to “Server Functions”](https://19.react.dev/reference/rsc/server-functions)
-
-**Carl:** Hurry up and wait. Yeah. And I guess one concrete change that has happened is server actions have been renamed to server functions, which I don't know, I guess that seems good. There's a lot of things in the ecosystem that were called actions. So one less thing called action seems good. [26:07]
-
-**Mark:** Probably. [26:08]
-
-## [React Native Bottom Tabs library using native bottom tabs](https://github.com/okwasniewski/react-native-bottom-tabs)
-
-**Mo:** Cool. So, the next update is that there's this library called react native bottom tabs that's made by one of the developers at Callstack, Oskar Kwaszynewski. Who I've known for a little while. And This is quite an interesting development. Because The current library that you use for navigation within React Native Is called React Navigation. [26:28]
-
-And React Navigation has bottom tabs within it. But they're not fully native backed bottom tabs. And so it means when there's updates Or specific Styling applied to certain platforms Let's say onLet's say on iOS Where if you're on like tvOS, the tabs go on the top. And if you're on tablet, you can have them as like a sidebar. [26:47]
-
-But on mobile, they kind of just look like a normal tab bar. Those changes wouldn't be reflected because they were just basically JavaScript views that were customized. And so the whole purpose of React Native bottom tabs is to create native based navigationOn React Native apps using a JavaScript API. [27:05]
-
-So this will hook into the native layer and it'll look and be styled as a native layer bottom tab, which is quite cool. And a lot of work's being placed into it. One of the things that I've been thinking about with this is could this possibly be introduced and upstreamed into React Navigation because It's a really good alternative. [27:27]
-
-So in React Navigation, we've got native stack navigators, which is the stack navigator that you can use. And it uses the native functionality for the stacks. This could also be introduced as some sort of native tab navigator. So still to be seen, but quite interesting as an update. [27:45]
-
-## [Meta Connect showcasing new AR/VR apps built with RN](https://engineering.fb.com/2024/10/02/android/react-at-meta-connect-2024/)
-
-**Mo:** Cool. Next up, we have MetaConnect happening, and there was a whole bunch of AR VR showcases, which was cool. Obviously, Mark Zuckerberg went on stage and showed off the Orion headsets, which are not really going on sale, but they're kind of showing the future of where Meta wants to go, which I'm personally quite excited about, I really like AR, I hate massive VR goggles, but I really like the form factor of the uh, Google Glass. [28:09]
-
-And I was quite gutted that Google Glass was, was basically chopped. I think it was just a bit too early for its time. But, on the side of that demo there some sort of, like, engineering blogs that were released. And they showcased at the event the Instagram and Facebook apps for the new MetaQuest. [28:25]
-
-interestingly despite Instagram being a native application and despite you know, parts of the Facebook app also being backed by native the Instagram and Facebook apps for the MetaQuest have been rebuilt with React Native, which is quite a big step forward. win for the React Native ecosystem because it's being used on more and more platforms and powering more of Meta's apps that is part of the core business. [28:50]
-
-So this was quite cool to hear and they've built some incredible apps. Like if you, if you look at the demos, there's really swift animations there. Everything looks really buttery smooth and looks really nice. So, it's a really cool showcase of, what they've been able to achieve by rebuilding some of this stuff in React Native. [29:06]
-
-Cool. [29:07]
-
-## [Static Hermes Updates](https://github.com/EvanBacon/expo-static-hermes-demo)
-
-**Mo:** Just a quick update on Static Hermes. Not much is happening here. There's a lot of discussions around like how compatible it would be and you know, what challenges it would introduce with the existing ecosystem. Svetlan Mikhov, who's one of the people behind Static Hermes and who first introduced it last year at React Native EU actually talked about some of the limitations that they were facing trying to take Static Hermes to production with the wider ecosystem. [29:30]
-
-A few people have been playing around giving him some feedback. He's been going on long threads on Twitter explaining some of the details of the implementation, especially with assembly code. So he's been like pasting assembly code in Twitter threads which is quite interesting and he's been styling them like, he's been going through a lot of effort to try to really like explain to the community, which is props to him. [29:48]
-
-But Evan Bacon, as Evan Bacon does came up with a demo of using Static Hermes with Expo dev clients on iOS. So Software Mansion's been working on some stuff around trying to take Static Hermes to production, and Evan Bacon's been trying to see if he can find a way to make it work with a basic Expo app. [30:07]
-
-There's still some limitations it's not anywhere near production ready, but it's just, things are being done in that space, which is quite cool to see. [30:14]
-
-**Carl:** Yeah. Super cool. Nice. [30:16]
-
-## [Anyone else feel burnt by Epic React? : r/reactjs](https://old.reddit.com/r/reactjs/comments/1fwks6r/anyone_else_feel_burnt_by_epic_react/)
-
-**Carl:** This is maybe a little bit of a small note, but I think we've plugged it before. So I wanted include some follow up from the ecosystem. Folks on Reddit have been sharing about feeling burnt by Epic React, which is Kent C. Dodd's React course. I empathize. I get it. Their criticisms are pretty legit. [30:34]
-
-Some of them are legit. Some of them feel like, you know, reddit commenters having strong opinions about how the world works, which are not necessarily based in economic realities. [30:42]
-
-## [Epic React V1 => V2 Upgrade & Deception.](https://old.reddit.com/r/reactjs/comments/1fut75h/epic_react_v1_v2_upgrade_deception/)
-
-**Carl:** Butsome of the complaints that seemed a little more legit to me were, like, people who had bought the, version one, the old version a couple of years ago, were upset about having to pay almost full price to get the upgrade. [30:54]
-
-## Marker
-
-**Carl:** And on the one hand, like, if you bought a course and you learned the course, why do you need to buy it again? I can understand wanting it. And I guess I can understand, like, wanting to, I don't know, it feels a little bit like folks, Feels a little entitled. Feels a little bit like wanting stuff for free. [31:13]
-
-Like I don't know, he put in a lot of effort to update it. I think the previous version came out like four years ago and that's a long time. A lot of things have changed and been updated and the ecosystem has moved on a lot. So I don't know that it is a reasonable expectation to get a brand new course for free or for extremely cheap just because you paid for it a couple of years ago. [31:37]
-
-If you paid for a course that is intended to like help you kickstart a career using the technology, I don't know that you should necessarily need to buy another course targeting people who are trying to kickstart careers in the industry several years later. If you do, like, maybe you didn't take full advantage of the first course. [31:55]
-
-I don't know. So I empathize with that. People were also criticizing the cost of it as being very expensive. It is like, you know, it's several hundred dollars. Like, I think full price for it is like 700. [32:05]
-
-**Mark:** my train of thought on that one is that Kent is entitled, it's a free market, Kent is entitled to put whatever price on, you know, something he's selling, and you are free to ignore it if you don't feel like it's going to be useful or provide enough value. there were maybe some comments about, like, folks not liking his teaching style. [32:24]
-
-That's more of a valid concern, but if you don't want to pay that much money for his course, if you feel like a 20 Udemy course is better, then go pay 20 for that course and move on. [32:36]
-
-**Mo:** Yeah, I'm inclined to agree as well with Mark there. It's just, you do your research before you purchase something. I think he's abundantly popular where you can watch some videos online of Kent. See if you like his teaching style, if you don't like his teaching style, and then make an informed choice as to whether or not you want to spend several hundred dollars for it. [32:53]
-
-I think trying to argue after the fact to say, hey, this wasn't great, it wasn't worth the price, well, cool, but, you know, leave a review for it, I guess, and move on. It's, a free market with this type of thing. Yeah. [33:04]
-
-**Carl:** what? Like, I dropped out of college after a year. Each of those college credits was like 1, 500, 15 years ago. So I feel like I would have gotten much more value out of a course like this than I did out of any individual college course that I took. I don't know, I left that comment on Reddit and they did not find it compelling or I got a negative score. But that's my opinion on it. Like, education, in general, costs so much money. And the value to Cost for something like this to me seems pretty clearly at least worth trying I don't know if you're going for it Yeah, and in the comments to joshwcomo has a course out as well. [33:47]
-
-Also seems really great Also a pretty similar price point, like curated education material from an industry leading expert. You don't get that for free. It's a lot of effort. It's hard to be an industry leading expert. It's hard to design a course syllabus. It's hard to produce that content. [34:03]
-
-It's hard to distribute it. It's hard to, yeah. So I don't know. It's,they're doing it all on their own. These are independent educators in general. Like they are doing their own thing on their own time. Yeah. [34:15]
-
-**Mark:** And, I mean, just, just as a related point, so I did all that work in the first half of this year to update the Redux Essentials tutorial in the Redux docs, which I did all that work for free, and I'm not charging any money for it. And, for the first time I actually tried tracking my hours. And I put in 80 hours of actual focused time, which on the one hand feels like it's not much, you know, like my first instinct is, well, that's only two weeks of work. [34:44]
-
-On the other hand, let's face it, across a typical two week period, I don't actually put in 80 hours of focused effort in my day job. you're in your seat for eight hours, maybe, but you're getting maybe four or five hours of productivity tops. And like, that was, quote, just building off of an existing tutorial where I'd written the content and written the example app. [35:05]
-
-I wasn't coming up with that stuff from scratch. I was converting it to TypeScript, figuring out how to add a couple new features to teach a couple new ideas and then, you know, doing the work to get the right commit sequence, and then turning that into code. Updated content. So, I mean, it was effort, but like, I wasn't doing all this stuff from scratch and that still took me like multiple weeks worth of focused time that I did for free. [35:33]
-
-And so, I got a sense of the amount of work Kent was putting into version two of his course and like he was significantly revamping things. [35:42]
-
-**Mo:** there's a comment in the Reddit thread, which I actually agree with quite a lot and I think it's the right approach with this, which is The person says, well, it is expensive and you can go through YouTube and find each of those topics and find like a tutorial video on them for free on YouTube. [36:00]
-
-But if you have the money, what you're basically paying for is someone to curate that content for you. Summarize it, create a syllabus for you, and give it to you on a silver platter, right? instead of searching for that material, you're paying for that person's time to curate that material for you. [36:15]
-
-The information is there for free, but you are paying for Kent's time and organization to come in and create something valuable for you so that you don't have to spend the time searching. So if you got the money for it, great, go for it. There's someone else in the chat as well that mentioned, which I think is a good point to put it into perspectivea lot of companies will let you expense stuff like this on like a training budget or, an upscaling budget that they have. [36:36]
-
-So when someone like probably prices something at several hundred dollars, I don't think he's expecting indies to come in and all shell out several hundred dollars. I suspect the goal is to find like a midpoint price point where it's. Expensive for indies, but quite cheap for corporates to pay for a large number of licenses. [36:58]
-
-And he does have a option to select multiple licenses and buy for your team. So I think that's probably where the pricing is coming into place. [37:05]
-
-**Mark:** Yeah, sort of the training equivalent of targeting the enterprise market. [37:09]
-
-**Mo:** Exactly. [37:09]
-
-**Mark:** moving along touching on some drama. [37:12]
-
-## [Web Components Are Not the Future](https://dev.to/ryansolid/web-components-are-not-the-future-48bh)
-
-## Followup to this from March 2020: [Maybe Web Components are not the Future?](https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh)
-
-**Mark:** I think we might have mentioned some previous bits of the web components versus React thing that's been going on the last couple months. This started with a post from Ryan Carniato, the author of the Solid Framework. Where he said that Web Components aren't the future. [37:27]
-
-And that spawned a whole lot of discussion after that. A lot of folks from the Web Components community were upset. [37:34]
-
-## [Web Components Are Not the Future — They’re the Present](https://www.abeautifulsite.net/posts/web-components-are-not-the-future-they-re-the-present/)
-
-**Mark:** Someone wrote a post called, Web Components are not the future, they're the present. Which made a bunch of arguments, both technical and sociological, about how Web Components should be fitting in. [37:46]
-
-Lots of debate in Twitter threads, Mastodon threads. I'm not on Blue Sky, but I bet there was probably some debate over there, too. [37:53]
-
-## [Liskov's Gun: The parallel evolution of React and Web Components](https://www.baldurbjarnason.com/2024/liskovs-gun/)
-
-**Mark:** there was one other article that really stuck out to me called the Parallel Evolution of React and Web Components. It's stupidly long, even by my standards. [38:01]
-
-It's 11, 000 words. It's a very long read, and I had mixed thoughts on it. I thought the first third of this was a really good technical discussion about, Some of the web component's early specs came out even before React did. Both of them have evolved over time. The middle third devolves into the author kind of bashing on React for a while, and then it kind of finishes up with some more decent thoughts about technical aspects and how they fit into web application architectures. [38:31]
-
-I'm not gonna suggest that everyone should read it, but there was some interesting background material, and at least the author put in actual time Writing this post as opposed to just, you know, random bashing of things purely on Twitter if you want to see some of the web components discussion that stuff's out there [38:48]
-
-**Carl:** my understanding is that one of the biggest problems of web components, I've never used them, I understand them to be in, you know, Intended to be used as like leaf nodes, kind of like your, your design system. Like if you are going to build a design system in React, I think that web components advocates would say, no, no, no, don't build those components with React, build them with web components. [39:10]
-
-And then you can use them in many, many places and many frameworks and yada, yada. My understanding is that web components have many of the same problems as trying to build your own design systems, where the hardest part is things like versioning. And if you don't get it exactly right the first time, it's kind of difficult to ship new changes to them. [39:29]
-
-So it sounds like web components are still hit a lot of the same problems. They just kind of shift the context. And so you have to figure out like, when you're doing a design system in React, The problem is around versioning and like packaging. Like, do you do many sub libraries? Like, do you make your own like React modal component and your own tool tips and your own buttons and your own accordion tabs, whatever, or do you do one big bulk package? [39:54]
-
-But then it's like, you end up with these like, well, okay. If you ship a change to this. Low level component used within this design system, like, how do you migrate all of the clients that are using that design system without doing like a big bang rewrite across dozens of clients? [40:11]
-
-And like, that's hard. It's not trivial and it sounds like web components have that same problem But instead of versioning happening through semver in npm, it happens in this entirely bespoke Web component standard system and like that doesn't seem better to me. It's like you have to learn a whole new, Context, as well as dealing with the same problem. [40:32]
-
-So, like, I haven't seen that discussed at all in any of these, you know, discussions. These, you know, when people are talking about the technical merits of Web Components, I'm not seeing, like, and here's why it works better for this reason. I also just really, like, the Web Components are not the future, they're the present article. man, I did not like it. I thought it was good. So, this is not a compelling argument. Like, you know, a quote from it that I pulled was like, they're not solid components, they're not React components, they're not Svelte components, they're not Vue components, they're standards based web components that work in all of the above. [41:04]
-
-And that seems like a big assertion to make when the maintainers of solid, React, Svelte, and Vue are all saying, they don't work for us. So, I feel like you can't just say, they work in all of those, when the maintainers of those frameworks are saying, they don't work. And it doesn't really argue why they work, it just kind of asserts that they do. [41:21]
-
-**Mark:** it's a little bit like a lot of the React arguments that were happening earlier this year, where there's like 30 different partially overlapping topics. And people are arguing about a different subset of them. [41:33]
-
-So, in this case, the concerns are technological, some of them are ideological. Folks who prefer web components or advocate for web components tend to be the kind of people who like frameworks. They feel that frameworks are too heavy, they feel that frameworks have bad results on the industry, they prefer to, you know, kind of stay closer to the browser, you know, they use the platform mentality, and so they see large frameworks as sort of the enemy, and so anyone who is using a framework is kind of a bad person. a lot of the vocalness here is coming from these people who's like, it's a standard,therefore it's better.These frameworks aren't standards. I don't see a lot of people in the React ecosystem, like, actively advocating against web components. more of a, whatever, we don't care.So, worth noting that, you know, Ryan's article, came from his perspective more as a framework author, and similarly, Rich Harris, the author of Svelte had a number of complaint threads on Twitter recently, where he was talking about there's a bunch of really, really weird behaviors in browsers that only exist because the web component specs demand those, and that has caused problems for him as a framework author. [42:58]
-
-Things like, Cloning domnodes requiring you to pass in an additional flag, but that makes the cloning process 30 percent slower, [43:08]
-
-**Carl:** Right. And in contrast to that, the present article says, towards the back half of it, it says, I'm not a conspiracy theorist, but I find interesting the number of people who are and have been sponsored and or hired by for profit companies whose platform rely heavily on said frameworks. [43:25]
-
-So it's like, I feel like the web components aren't working for us. Framework authors are making arguments like that. I'm taking a 30 percent performance hit because of the spec requirements to support these. Like that's a very precise technical argument. Not, I'm not a conspiracy theorist, but [43:42]
-
-**Mo:** [43:42]
-
-that sounds like, here's my friend's opinion about these guys. They're awful people. Not my opinion. I'm just quoting what my friends, I'm not a conspiracy theorist. That sounds pretty conspiracy theorist to me. [43:52]
-
-**Carl:** Yeah. It's big, just asking questions energy. we should move on though. I think Mo, you said you have to duck out. [43:57]
-
-**Mo:** I do have to leave, so I guess I can just say goodbye hereand hopefully see you all next month. So it's been a pleasure in all things react and react native and I'll see you all in the next one. [44:08]
-
-**Mark:** we've got a bunch more stuff to get through, [44:10]
-
-## [Announcing VoidZero Next Generation Toolchain for JavaScript](https://voidzero.dev/posts/announcing-voidzero-inc)
-
-**Mark:** Evan Yu, the author of View and Veet and a number of other things, Has announced a venture backed company called VoidZero, which is quote working on the next generation of JavaScript tooling This might sound a little bit familiar. [44:24]
-
-That was sort of the pitch behind the Roam tool set So in this case some of the things that VoidZero is working on correlate a lot with Things that were already in progress with the VEET framework. [44:37]
-
-## [Oxc Transformer Alpha](https://oxc.rs/blog/2024-09-29-transformer-alpha.html)
-
-## [OXC compiler](https://twitter.com/boshen_c/status/1840322879424258115)
-
-**Mark:** There's a Rust based JavaScript compiler called OXC, which also includes a linter and reusable parsers and things like that. [44:46]
-
-So I believe that's now gonna be sponsored under Void0. There's a project called Rolldown, which is going to be a Rust based re implementation of the Rollup build toolset. So eventually the goal is to really make Vite a whole lot faster, ultimately. Vite currently uses a mixture of, I believe, ESBuild for local dev builds and Rollup for production builds. [45:12]
-
-And so they're also trying to make the behavior more standard, or more similar across dev and production as well. [45:18]
-
-**Carl:** Yeah, definitely seems interesting. Always down for stuff to core dev tools to be made faster. All right, cool. [45:23]
-
-## [Updates from the 104th TC39 meeting](https://dev.to/hemanth/updates-from-the-104th-tc39-meeting-14cp)
-
-**Carl:** I'll move us on some new TC39 news. They just had a meeting and blog post I saw said four new proposals advanced to stage four and the list had five items in it. [45:33]
-
-## [Promise.try](https://github.com/tc39/proposal-promise-try)
-
-**Carl:** so there's promise. try, which is now stage four. It seems neat. It looks like it's basically a likeconvenience so that if you don't know whether a function is going to return a promise or not, you can give it to promise. try and then you can handle any errors that it emits as though it were a promise. [45:53]
-
-And the advantage of that is that, you know, if you did something like promise. resolve. then and then execute that function, which would be a great way to achieve this behavior without a change to the language that would process it on the next tick. [46:06]
-
-So it doesn't execute synchronously as, you know, line by line. It gets thrown to the event loop and then event loop comes back and executes it. So, you know, that's. Not always what you want. If you are trying not to do that, now you have a new tool to do so, which is promise. try. [46:21]
-
-## [Sync Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers)
-
-**Carl:** I also liked the sync iterator helpers. [46:23]
-
-I think we mentioned this in a previous episode. Maybe not the last one, maybe the one before. But it's. Basically letting you do stuff like map, filter, reduce on iterable objects without Spreading it into an array first Which I think creates a copy. So like this seems great. You can now map over without the cost of Producing an array from it first. [46:47]
-
-I love it. Here for it. [46:48]
-
-## [Import Attributes](https://github.com/tc39/proposal-import-attributes)
-
-**Carl:** Some other ones that I didn't talk about Think about as hard there's import attributes which I think is like metadata for describing what you're importing, something like that. [46:58]
-
-## [JSON modules](https://github.com/tc39/proposal-json-modules)
-
-**Carl:** JSON modules. So you can import JSON files as modules without, you just kind of natively. It seems good. [47:05]
-
-## [RegExp Modifiers](https://github.com/tc39/proposal-regexp-modifiers)
-
-**Carl:** as well as regex modifiers. couple of new changes, five new things to the language. Seems good. [47:11]
-
-## [Language Evolution](https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o/edit#slide=id.g30432c5cd9c_0_30) “JSSugar” proposal
-
-## [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389133810913338)
-
-## [NullVoxPopuli on X](https://x.com/nullvoxpopuli/status/1842389157693227375)
-
-## [BrendanEich on X](https://x.com/BrendanEich/status/1842630141304025263)
-
-## [Daniel Ehrenberg thoughts](https://gist.github.com/littledan/a590784a72f2e1b8cc633ff5ff8a9dc2)
-
-**Mark:** And one other thing that came up at that meeting there was a presentation I think co authored by a number of JavaScript engine implementers at Google and Mozilla and a couple other companies. That is very long and complicated, and it's worth reading through, but as a high level summary, we've had the TC39 process for, like, 15 some years now, and, you know, we had the big bang change to the language with ES2015, and then a steady stream of new language features since then. [47:45]
-
-And the expectation is that once TC39 finishes standardizing a given feature, Every JavaScript engine out there. Is going to end up fully implementing this. Now in practice, if it's basically V8 and spider monkey from, you know, from Mozilla, that's the majority of people as far as browsers are concerned, but there are other JS engines out there as well, and implementing all these new language level features takes time and effort, some of these engine implementers were actually saying, you know what, we actually. [48:19]
-
-are thinking that maybe we shouldn't be required to implement every feature that is added to the JS language spec. Sometimes these things have performance implications, sometimes these things have actually caused security related concerns, It's not like a full blown proposal, but it's kind of like a what if we considered this kind of a thing. [48:42]
-
-what if we sort of split the JavaScript language spec into things that are actually going to be implemented by runtime engines, versus things that are in the spec, and we agree it's part of the language, But would only ever be implemented by transpilers, like Babel or ESBuild or something like that. [49:05]
-
-So that, the JS engines don't have to literally implement every finished feature ever. a number of folks felt this was probably a bad idea. I can understand some of the concerns that are being raised by the engine folks. But, splitting the language feels problematic. You know, certainly the folks who are, you know, kind of in on that, like, I don't want to have to use build tools to write my JavaScript are, are not happy about this. [49:34]
-
-But, even knowing that, you know, some of these things won't make it into the engines and might not be able to take advantage of, you know, built in optimizations feels kind of sketchy. [49:43]
-
-**Carl:** Yeah, I can definitely understand that though, like so many things, I feel like, I mean there are so many lingering polyfills and transforms and whatever that Babel and all of them are like still implementing, even though they are now part of the language, just because how do you know when it's okay to remove stuff like that? [50:03]
-
-I can understand the motivation of saying like, look, this is the reality. We are still transforming this even though technically by the spec, we don't have to. I can definitely understand why they would see, just start saying like, this is a practical reality, pragmatically, this is what's happening. the standardization process should reflect that and acknowledge that some things will just live in the transformer. [50:25]
-
-I can definitely understand that argument. But yeah, I guess that's also weird. Like it introduces a new like point of abstraction in the standardization process and like, what is JavaScript? that's weird. [50:38]
-
-**Mark:** Alright, so, now we're in and we haven't started the lightning round. So, let's try to actually make this a [50:43]
-
-lightning round, shall we? [50:44]
-
-## ⚡ Lightning round ⚡
-
-## [The Disappearance of an Internet Domain](https://every.to/p/the-disappearance-of-an-internet-domain) – .io
-
-**Mark:** Moving along. So there was an article titled Disappearance of an Internet Domain. the TLDR here is that the io domain is associated with a set of islands in the Indian Ocean owned by Great Britain and Great Britain just signed a treaty to eventually hand those islands over to you. [51:05]
-
-I think the island of Mauritania. And so based on international law, there's a chance that once this 3D handover is complete, there is no longer a separate territory. And if there's no longer a separate territory, then there's no legal reason to have a io domain associated with that. And so the article says that, you know, if we, if we've, Assume that these laws and practices get followed strictly, then hypothetically, five years from now, the io top level domain might go away completely. So that's up for grabs, but it's a legitimate concern. [51:46]
-
-**Carl:** The intersection of geopolitics and tech debt seems bad. [51:51]
-
-flying through a little bit. [51:51]
-
-## [How to control a React component with the URL](https://buildui.com/posts/how-to-control-a-react-component-with-the-url)
-
-**Carl:** So I saw a great blog post by Sam Zelikoff called How to Control a React Component with the URL. blog post makes the argument that it's a very common feature request. [52:00]
-
-I think that it is not as common a feature request as it should be because it is the power of the web. URL addressability, deep linking, being able to open a URL and have it, represent the same page that somebody else is seeing. So I think that is a phenomenal goal to seek, and so more things should behave that way. [52:17]
-
-just a pull quote from it that I think summarizes What makes that hard is the fundamental reason why we're heading down a bad road, he says that we now have two sources of truth for the search text. And that's exactly it, like, when you are writing React, you tend to have your source of truth be something in React state. [52:35]
-
-But if it's in the URL state that it exists outside of React's Awareness, you know the universe that you've created for your app that is within react the URL state lives outside of that So it's very easy to accidentally duplicate state then you have a state synchronization problem and I also want to call out that problems like that are a Wonderful example of why dogmatic best practices can really easily lead you to broken apps [52:59]
-
-Then if you use a form library, it's going to keep track of its own state. Then you have to do state synchronization between the URL and the form. That's a really easy way to get a lot of bugs. So if you follow the rule of always use a form library, you're going to run into state synchronization bugs if you try to implement this feature. [53:16]
-
-## [If WordPress is to survive, Matt Mullenweg must be removed](https://joshcollinsworth.com/blog/fire-matt)
-
-**Mark:** one more drama related item, I'm really gonna TLDR this. The WordPress community is basically blowing up right now. WordPress founder and project company CEO Matt Mullenweg went on a seemingly unprovoked rampage. [53:35]
-
-He is basically upset that one of the biggest WordPress hosting companies, quote, isn't giving back enough to the project. And there's all kinds of issues where Matt is both simultaneously the CEO of Automatic, one of the other bigger hosting companies. And the leader of the open source project and the nonprofit foundation. [53:58]
-
-And it turns out that in some cases, he's the sole person who controls some of the key websites. There's been issues with him, basically hijacking a plugin that was developed by this other company blocking people from the Slack and all kinds of other Like, he's basically blowing up their community single handedly, and seemingly for no reason. [54:22]
-
-And a lot of folks who had been very involved with WordPress are like, I can't be involved with this anymore. So, a lot of WordPress folks are actively looking to stop using WordPress and find something else. There's an extremely long, very well written post that lays out a lot of the details linked in the chat, called, If WordPress is to survive, Matt Mullenweg must be removed. [54:45]
-
-It's long, it's complicated, but it's also a very thorough look at everything that's happened. [54:50]
-
-**Carl:** Yeah. Oh man, there's so much to get into. There's so much that could be said about this, but yeah, it's,oh, this has been, this has built its own cottage industry of podcasts and interviews and blog posts. Yeah. It's also not really React. WordPress developer is like an entirely separate thing from web developer. [55:06]
-
-So yeah, it's kind of not related to our main topic. [55:09]
-
-## [Web Without Walls — Dan Abramov](https://www.youtube.com/watch?v=F1sJW6nTP6E)
-
-**Carl:** we've had a couple of tangential references to Blue Sky. I love Blue Sky, I think it's really cool, I've been on it for like over a year because Twitter sucks and meh, I have opinions. [55:20]
-
-But so Dan Abramov, who I'm sure some of you may have heard of once or twice, gave a really great talk. he's currently working at BlueSky as an app developer which is, I'm actually interested to speak with him a little bit more about that kind of transition because he went from core team, building React to now React consumer and I think that is just such a relatively rare Transition to make and I'd be really curious to hear not just like what he thinks about that transition as someone who's made it But also what Dan Abramov thinks of that as a very clear thinker and clear speaker butwe gave a really great talk about the app protocol, which is the underlying technology that BlueSky is built on top of and it hits a lot of really cool things that I personally have been thinking about for a decade about the future of social media and data portability and federated access. [56:14]
-
-not just social graphs, but also to the actual data. I just think it's really cool. Like, I saw some people talking about, like, Oh, it doesn't matter if you have You know, you can always export the social graph because you have your contacts list. And like, that doesn't really matter. [56:28]
-
-It doesn't matter if you have the social graph, if you have the connections between the people. If the people are not producing content, you know, if they're not interacting with each other on that platform. And I would boil down this hour long talk that Dan gave that is really good. And I think you should watch if you're interested in social media and building apps on social platforms. [56:47]
-
-It really comes down to, like, it's not just an open source Twitter clone. It is an open network that people are publishing Twitter like data to, and no one can close your app off. You know, there is no way for something like the, Twitter X API Shut down, the Reddit API shut down. [57:10]
-
-You can't do that because it's built on a federated decentralized protocol. it's not just a proprietary API. So yeah, I think that's really cool. This is a really interesting thing. I think this is going to be a generational shift in how social media operates. So yeah. [57:23]
-
-## [Preact compat discussion](https://old.reddit.com/r/reactjs/comments/1fy2jjh/i_ran_into_preacts_false_promise_what_can_i_do/)
-
-**Mark:** There was a Reddit discussion thread going and was looking into the compatibility of Preact with, you know, actual React and debating some of the pros, cons, and trade offs. And since Preact has been traditionally pitched as a React compatible library, worth looking at. [57:43]
-
-**Carl:** Yeah. [57:44]
-
-## Content-visibility in CSS
-
-## [Using CSS containment](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Using_CSS_containment)
-
-**Carl:** There's some interesting stuff with CSS containment. It seems pretty, like, wonkish, deep in the weeds stuff to properly understand, but it looks really interesting as, like, a performance optimization for rendering. [58:00]
-
-## [contain](https://developer.mozilla.org/en-US/docs/Web/CSS/contain) [CanIUse](https://caniuse.com/mdn-css_properties_contain)
-
-**Carl:** The bulk of it, as I saw in researching it for, you know, an hour and a half, I haven't really used it yet, is there's a contain and a contain visibility, you know, a CSS attribute now, that let you signal more precisely to the browser renderer, how much effort to dedicate to rendering a particular part of the page. [58:19]
-
-So, you know, like, how I'm making sense of this is in React, if you're trying to choose whether or not to render something, for a long time the decision has been kind of like, conditional rendering, like, is the DOM in the page at all, or, like, display none. [58:34]
-
-And you know, there's a lot of other, like, subtle variations around that, like, should it live in the accessibility tree as well, like, You know, there's a lot of subtle nuances to that. So this adds a lot more subtle nuances. Very exciting. But yeah, so it looks really interesting. It lets you constrain So that's kind of part of it, but it's also a little bit on like sandboxing. Like, I guess the contain element is maybe a little bit more on sandboxing. It's like, if you were to like render an ad into your page, you might be able to do it using this instead of an iframe. [59:07]
-
-So, and still maintain the same kind of strong guarantees about how it behaves on the page, how it looks on the page. [59:16]
-
-**Mark:** someone in the chat just said it's like, it's kind of like Shadowroot, and I think that's a little bit, like, along the right lines. Like, you're telling the browser that elements inside here aren't going to have layout interactions with the rest of the page. [59:28]
-
-So, like, whereas, a normal element, depending on your CSS, might, interact or overlap or something with other parts of the page, might cause the browser to do, a bunch of additional checks against other DOM nodes to see if they in some way. And so contain tells it, nope, anything under here is scope, you don't have to waste time and effort checking locations versus the rest of the page. [59:50]
-
-## [content-visibility](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) [CanIUse](https://caniuse.com/mdn-css_properties_content-visibility)
-
-**Carl:** Yeah, and something else they shout out in the docs about it is, like, really long pages using it to optimize, you know, rendering performance. If you've got a massive, massive amount of HTML, then just saying, like, nope, this is off screen, like, don't render it. If that makes sense they were saying that that would help you maintain performance on a huge page. [01:00:07]
-
-But it also talks about like reducing layout shift. So I wonder if that is actually going to be like practical and useful, or if it just would just be like too weird to have to, I've, I've had to do that kind of performance optimization and. Cracking the size of the content being rendered so that you don't have it, like, you scroll down, something goes out of view and then like gets, stops being rendered and then everything on the page shifts. [01:00:31]
-
-So you have to keep like scroll because what you were looking at just changed. I, I don't know. I don't know if that advertised benefit will actually be real. I don't trust it. [01:00:39]
-
-## [How I Built My Blog • Josh W. Comeau](https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2/)
-
-**Carl:** We mentioned Josh W Comeau earlier. He has put out a great blog post. How I built my blog. Looks pretty interesting. [01:00:45]
-
-I, I just always appreciate little technical write ups of things like this. [01:00:49]
-
-**Mark:** and like, it's more than just the blog. I mean, I think he goes into some details about the developer, the education platform and whatnot. But Josh always puts such care and effort into everything he builds. [01:01:03]
-
-**Carl:** Yes, a consummate crafts person. So yeah, it's a good write up. He's very thoughtful about how he builds and how he writes. So this is really great. I have also built a large documentation site for a previous employer. And as I was reading this, I just saw so many problems that I remember dealing with in that. [01:01:19]
-
-Like he talks about, you know, authoring content in MDX and the kind of weird errors you get when doing that. He talked about like doing syntax highlighting with Prism and how it can really explode complexity of, you know, just the amount of HTML on a site, which is a problem I had I built this whole thing, put all of this documentation on a single like API reference massively tall site and oops, it's 12 megabytes of just HTML. [01:01:45]
-
-So I ended up having to like totally re architect how the syntax highlighting was happening because just it totally exploded the amount of HTML on the page. so he talked about using, like updating to the latest version of MDX and using Sheeky which is like a server side, Syntax highlighting tool that seemed pretty interesting and definitely sounded like it would have solved some problems. [01:02:04]
-
-I had a couple years ago And he also referenced he's got a like interactive rainbow on the home page And You can edit how it behaves and that behavior gets synchronized across all viewers of the site simultaneously through PartyKit, which is near and dear to my heart. I helped set up their community a couple years ago. [01:02:23]
-
-cool. It's a good read, [01:02:24]
-
-**Mark:** All right. [01:02:24]
-
-## [Types of React Components [2024]](https://www.robinwieruch.de/react-component-types/)
-
-**Mark:** And the final item for today Robin Wierich is another prolific React educator and author of useful tutorial learning blog posts. Thanks. And he put up a post called Types of React Components in 2024. it's actually a bit of a history lesson. It goes back and looks at the old style create class and mixins, the still newer but by now out of date class components, the higher order components pattern, and then the relatively modern function components, server components, and async components. [01:02:58]
-
-So it's not something that's necessarily going to teach you to do things, but it's a useful look at and sort of like the evolution of React over the years. [01:03:06]
-
-**Carl:** And apparently this is part of a whole series that he's doing updating his most popular blog posts for 2024. generally, I saw a couple of other ones and I wanted to add them, but I, oh god, we already had so many links. So, yeah. Definitely go check those out. he's a great writer. I have been reading his blog for 10 years and he just keeps putting out bangers. [01:03:29]
-
-So yeah, definitely check it out. [01:03:31]
-
-**Mark:** right. I think we're actually at the end. [01:03:33]
-
-**Carl:** We are at the end. We've made it. Oh my God. You guys, you're still here with us. Thank you for sticking around for 80 minutes. Thank you so much for joining us. We'll be back on the last Wednesday of next month here at the live stage in Reactiflux or back in your podcast feed just as soon as we can. [01:03:48]
-
-Lennart, [01:03:49]
-
-**Mark:** Yeah. I got nothing this week other than I am diving into working on some RTK query features, specifically infinite queries, which is a complex thing that I didn't know about and I'm thankful that we're basing it off of how React query works. So My side project for a while. [01:04:08]
-
-**Carl:** That was fun. Cool. We gather sources from ThisWeekInReact, Bytes. dev, React Status, Next. js Weekly, React. js, Subreddit and here in Reactiflux, mostly from the tech reads and news, If you see anything that you feel like we should talk about feel free to send it to us via email to hello at reactiflux dot com T M I R in the subject line. [01:04:28]
-
-Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/) Help them know how smart you are. Alright, see you later.
diff --git a/src/transcripts/tmir-2024-11.md b/src/transcripts/tmir-2024-11.md
deleted file mode 100644
index 3196344..0000000
--- a/src/transcripts/tmir-2024-11.md
+++ /dev/null
@@ -1,723 +0,0 @@
----
-title: "TMiR 2024-11: React 19 is unblocked, Next 15 is 'stable', Expo launch week. The cool kids are on BlueSky"
-date: 2024-11-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:35](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- New releases
- - [[01:51](#vscode-195)] [VSCode 1.95](https://code.visualstudio.com/updates/v1_95)
- - [[02:20](#node-v23)] [Node v23](https://openjsf.org/blog/announcing-node.js-23-key-features-and-enhancement?ck_subscriber_id=1888282043)
- - [[04:12](#docusaurus-36)] [Docusaurus 3.6](https://docusaurus.io/blog/releases/3.6)
- - [[04:40](#react-navigation-70)] [React Navigation 7.0](https://reactnavigation.org/blog/2024/11/06/react-navigation-7.0/)
- - [[04:46](#better-auth-v10)] [better-auth v1.0](https://www.better-auth.com/v1)
- - [[05:06](#mantine-v7140)] [Mantine v7.14.0](https://mantine.dev/changelog/7-14-0/)
- - [[05:14](#storybook-84)] [Storybook 8.4](https://storybook.js.org/blog/storybook-8-4/)
- - [[05:22](#gatsby-v514)] [Gatsby v5.14](https://github.com/gatsbyjs/gatsby/releases/tag/gatsby%405.14.0)
- - [[05:34](#rspack-11)] [Rspack 1.1](https://rspack.dev/blog/announcing-1-1)
- - [[05:39](#angular-beat-react-to-v19)] [Angular beat React to v19](https://blog.angular.dev/meet-angular-v19-7b29dfd05b84)
-- [[05:57](#conferences)] Conferences
- - [[06:06](#react-day-berlin)] [React Day Berlin](https://reactday.berlin/) Berlin, DE Dec 13 & 16
-- [[07:39](#main-content)] Main Content
- - [[07:39](#react-19-rc1)] React 19 RC1
- - [[08:17](#tech-writeup-of-a-solution-to-the-sibling-rendering-issue-that-delayed-react-19s-release)] [Tech writeup of a solution to the sibling rendering issue](https://github.com/facebook/react/issues/29898#issuecomment-2477449973) that delayed React 19’s release
- - [[11:27](#nextjs-15)] [Next.js 15](https://nextjs.org/blog/next-15)
- - [[15:25](#ts-57)] [TS 5.7](https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/)
- - [[19:48](#react-router-v7--remix)] [React Router v7 | Remix](https://remix.run/blog/react-router-v7)
- - [[24:28](#vite-v6)] [Vite v6](https://vite.dev/blog/announcing-vite6.html)
- - [[24:50](#environment-api)] [Environment API](https://github.com/vitejs/vite/discussions/16358)
- - [[27:52](#expo-launch-party)] [Expo Launch Party](https://expo.dev/launch-party)
- - [[28:19](#the-magic-of-expo-dom-components)] [The magic of Expo DOM Components](https://expo.dev/blog/the-magic-of-expo-dom-components)
- - [[32:24](#introducing-workflows-cicd-built-for-your-app)] [Introducing Workflows: CICD built for your app](https://expo.dev/blog/expo-workflows-automate-your-release-process)
- - [[33:33](#environment-variables-in-eas-new-changes-to-simplify-setup)] [Environment variables in EAS: new changes to simplify setup](https://expo.dev/blog/environment-variables)
- - [[36:59](#expo-sdk-52)] [Expo SDK 52](https://expo.dev/changelog/2024/11-12-sdk-52)
- - [[40:10](#new-css)] New CSS
- - [[40:14](#a-friendly-introduction-to-container-queries)] [A Friendly Introduction to Container Queries](https://www.joshwcomeau.com/css/container-queries-introduction/)
- - [[41:05](#a-framework-for-evaluating-browser-support)] [A Framework for Evaluating Browser Support](https://www.joshwcomeau.com/css/browser-support/)
- - [[43:48](#state-of-css-2024)] [State of CSS 2024](https://2024.stateofcss.com/)
- - [[47:02](#framework-betas:)] Framework betas:
- - [[47:08](#rsc-in-expo-router-is-now-in-beta!)] [RSC in Expo Router is now in Beta!](https://expo.dev/blog/universal-react-server-components-developer-preview)
- - [[47:29](#tanstack-start-beta)] [TanStack Start beta](https://tanstack.com/router/latest/docs/framework/react/start/overview)
- - [[49:14](#react-native-077-rc0)] [React Native 0.77 RC0](https://github.com/facebook/react-native/releases/tag/v0.77.0-rc.0)
- - [[50:02](#new-list-dropped-in-react-native)] [New List dropped in React Native](https://x.com/jmeistrich/status/1855663310386958840)
- - [[51:45](#twitter---bluesky-migration)] Twitter -> Bluesky migration
- - [[54:54](#starter-packs-ericclemmonsawesome-starter-packs-stevendborrellibluesky-tech-starter-packs-bluesky-directory-a-complete-guide-to-bluesky-)] [ericclemmons/awesome-starter-packs](https://github.com/ericclemmons/awesome-starter-packs), [stevendborrelli/bluesky-tech-starter-packs](https://github.com/stevendborrelli/bluesky-tech-starter-packs), [A complete guide to Bluesky 🦋](https://mackuba.eu/2024/02/21/bluesky-guide/)
- - [[55:13](#technical-debate-over-how-decentralized-bluesky-actually-is)] [Technical debate](https://dustycloud.org/blog/how-decentralized-is-bluesky/) over [how “decentralized”](https://whtwnd.com/bnewbold.net/3lbvbtqrg5t2t) Bluesky actually is.
- - [[55:57](#web-without-walls--react-universe-conf-2024)] [Web Without Walls | React Universe Conf 2024](https://www.youtube.com/watch?v=F1sJW6nTP6E)
-- [[59:03](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[59:06](#deno-v-oracle-canceling-the-javascript-trademark)] [Deno v. Oracle: Canceling the JavaScript Trademark](https://deno.com/blog/deno-v-oracle)
- - [[59:27](#two-ways-to-the-two-reacts)] [Two ways to the two Reacts](https://bobaekang.com/blog/two-ways-to-the-two-reacts)
- - [[59:52](#thats-not-an-abstraction-thats-just-a-layer-of-indirection)] [That's not an abstraction, that's just a layer of indirection](https://fhur.me/posts/2024/thats-not-an-abstraction)
- - [[01:00:04](#react-anti-pattern-stop-passing-setters-down-the-components-tree)] [React Anti-Pattern: Stop Passing Setters Down the Components Tree](https://matanbobi.dev/posts/stop-passing-setter-functions-to-components)
- - [[01:00:31](#what-is-http3)] [What is HTTP/3?](https://www.cloudflare.com/learning/performance/what-is-http3/)
- - [[01:01:03](#leaked-vercel-v0-system-prompts)] [Leaked Vercel v0 system prompts](https://old.reddit.com/r/LocalLLaMA/comments/1gwwyia/leaked_system_prompts_from_v0_vercels_ai/)
- - [[01:01:59](#react-scan-to-highlight-component-renders-by-the-author-of-millionjs-which-he-used-to-point-out-githubs-code-view-re-rendering-on-every-scroll)] [React Scan to highlight component renders](https://react-scan.million.dev/) (by the author of Million.js), which he used to point out [Github’s code view re-rendering on every scroll](https://x.com/aidenybai/status/1859267710498263073)
- - [[01:02:56](#whats-next-for-the-react-compiler)] [What’s Next for the React Compiler?](https://www.youtube.com/watch?v=qd5yk2gxbtg)
- - [[01:03:14](#framer-motion-spinning-out-as-an-oss-tool-motion-and-conversely-gsap-is-joining-webflow)] [Framer Motion spinning out as an OSS tool (Motion)](https://motion.dev/blog/framer-motion-is-now-independent-introducing-motion), and conversely [GSAP is joining WebFlow](https://gsap.com/blog/webflow-GSAP/)
-
-**Carl:** Hello everyone. Thank you for joining us for October's This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem come and do live out of Reactiflux, the place for professional React developers and supported by Infinite Red a React Native consultancy, but more about them later. [00:18]
-
-I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like events like this. And build some tools to help keep the community operating smoothly. [00:31]
-
-**Mark:** I'm Mark. My day job is working at Replay, which is a time traveling debugger for JavaScript, and outside of that I do way too much Redux stuff. [00:38]
-
-**Mo:** And I am Mo. I head the mobile team at Theodo. I am an active, semi active part of the React Native community. And I organize the React Native London conference and the meetups and sometimes dabble in open source with libraries like Expo and Tamagui. [00:54]
-
-**Mark:** If you're only semi active, what qualifies as active? [00:57]
-
-**Mo:** I don't know. I, I feel like I'm less active than I was a few months ago. Maybe I just need to take a little bit of a break and become reactive. [01:05]
-
-**Mark:** You just ran a conference! [01:07]
-
-**Mo:** Yeah, maybe that's taking most of my energy out of my sails. [01:10]
-
-**Carl:** Yeah, right. I think organizing a conference gives you a little bit of a pass on other contributions. That's a lot. That was a [01:16]
-
-**Mo:** Yeah, it was it was a fun time. Intense, but fun time. [01:19]
-
-**Carl:** All right. Jumping into some quick hits. I'm gonna change up the format a little bit. The last couple months we've had so many new releases that new releases are just mostly part of the content now. But I'm gonna run through some quick new releases with like, no discussion. Just like, this is out, go check it out if you want. If it's relevant to your life. [01:35]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** But job market stuff looks pretty steady state compared to last month. Like, layoffs. 23andMe has laid off a couple of folks. But, generally seems to be pretty stable again. not much to say there. Okay. [01:50]
-
-New releases, lightning mode. [01:51]
-
-## [VSCode 1.95](https://code.visualstudio.com/updates/v1_95)
-
-**Carl:** VS Code they released like every, I don't know, six weeks, something like that. They've got VS Code 1. 95, which mostly looks like it brings out co pilot things. thing that caught my eye the most was you can add multiple files to like a working set, they call it, in the co pilot AI assistant stuff. [02:10]
-
-So that seems kind of neat. I haven't used the copilot very much, but being able to say, here are the files that are relevant. Please do this for me. That seems neat. That seems cool. [02:20]
-
-## [Node v23](https://openjsf.org/blog/announcing-node.js-23-key-features-and-enhancement?ck_subscriber_id=1888282043)
-
-**Carl:** There is a new version of Node, Node 23 Which means Node 22 is now LTS Two things caught my eye that seemed neat Biggest one is they now have native support for loading ES modules using Require. [02:37]
-
-this seems like a huge compatibility bridge between common JS and ESM, which has been a pain point for like five years, literally since the ES modules were released. So that's cool. It's been experimental for a long time and is now no longer experimental. It's just stable. So that's cool. [02:54]
-
-They also added a native, flag to node, the node executable to run your package. JSON scripts. So no longer do you have to do NPM run. Now you can do node dash dash run. Which is just kind of cool. that was like a weird coupling between NPM and node. So like moving that into the runtime just kind of makes sense to me. So cool. Just especially while we have more variation in like runtimes and, Package management [03:19]
-
-**Carl:** tools and whatever. [03:20]
-
-**Mark:** I agree that Node having support for being able to use require to pull ESM modules into CommonJS a huge thing. I think you could do it the other way around where you could import CJS files, apparently. I'm still hazy on that one. But in general, the interop panes between ESM and CommonJS in Node have been the big barrier and reason why package maintainers like myself have had to go through shenanigans trying to get our packages defined and published properly with multiple different artifacts inside. [03:58]
-
-As always, the fact that a new version of Node. js has support for this doesn't mean we'll be able to drop that immediately because, you know, the long tail but at least it's a step in the right direction. [04:12]
-
-## [Docusaurus 3.6](https://docusaurus.io/blog/releases/3.6)
-
-**Carl:** DocuSource put out 3. 6. It's faster apparently. Seems good. [04:16]
-
-**Mark:** Apparently that's because they did switch from using Webpack to using RSPack, which is, it's effectively Webpack. But rebuilt in Rust, so it's like public API compatible. So, an example of a migration path to get faster build tools without having to sort of switch which build tool ecosystem you're in. [04:40]
-
-## [React Navigation 7.0](https://reactnavigation.org/blog/2024/11/06/react-navigation-7.0/)
-
-**Carl:** React Navigation put out version 7 if you're in React Native World. [04:46]
-
-## [better-auth v1.0](https://www.better-auth.com/v1)
-
-**Carl:** A project I've mentioned at least once on this show for authentication, BetterAuth, is at 1. 0. They've been doing a really fast, rapid release cycle, I've noticed. like, last month they were on version, 0. 6 and then they did, like, 0. 0. 9, and now 1. 0. So, cool. Seems good. Love authentication. And it seems like a good project for it. [05:06]
-
-## [Mantine v7.14.0](https://mantine.dev/changelog/7-14-0/)
-
-**Carl:** Mantine put out version 7. 14. Seems like a decent UI toolkit. [05:14]
-
-## [Storybook 8.4](https://storybook.js.org/blog/storybook-8-4/)
-
-**Carl:** Storybook has 8. 4. I have opinions about Storybook. I don't use it. But hey, if you do, they are talking more about like testing and stuff. [05:22]
-
-## [Gatsby v5.14](https://github.com/gatsbyjs/gatsby/releases/tag/gatsby%405.14.0)
-
-**Carl:** Throwback Gatsby released version 5. 14. It's out. [05:28]
-
-**Mark:** genuinely surprised anyone's still working on it. [05:30]
-
-**Carl:** Gatsby is still here. It still exists. Me too, a little bit, [05:34]
-
-## [Rspack 1.1](https://rspack.dev/blog/announcing-1-1)
-
-**Carl:** RSPack put out 1. 1. We talked about version 1 release Recently. [05:39]
-
-## [Angular beat React to v19](https://blog.angular.dev/meet-angular-v19-7b29dfd05b84)
-
-**Carl:** And amusingly, Angular has released version 19, beating React to the punch. Nothing that means anything, but yeah, well, Angular's got a new major version out. [05:50]
-
-I saw they're looking to revise their style guide, which is apparently 52 pages long currently. So that's ridiculous. [05:57]
-
-## Conferences
-
-**Carl:** Yeah, conferences. Mo, you wanna talk? [06:00]
-
-**Mo:** Yeah, sure. So, we're reaching the end of the year, which means conferences are going into hibernation mode as expected. [06:06]
-
-## [React Day Berlin](https://reactday.berlin/)
-
-**Mo:** But we've got one more left for you all this year, React Day Berlin. And React Day Berlin happens in December every year. It's a really cool gathering of people. I was there last year and I'll be doing a talk this year with a friend of mine from Amazon, Anisha Malde, about universal React, so it's a, it's a great of React people. [06:25]
-
-They have a really cool venue called Cosmos It's a really historical city. If you're in Europe, I'd recommend you come around. It's, it's a good time. [06:32]
-
-**Carl:** And it's on my birthday, so I'm not going. [06:34]
-
-**Mo:** Happy birthday, Carl. Early birthday. Very early birthday. [06:38]
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl:** All right, sponsor time. We are sponsored currently exclusively by Infinite Red. They're an expert React Native consultancy that's been around since 2015. Coming up on 10 years, wild. They're our only sponsor in part because very few companies do as much as they do for the React Native ecosystem. [06:55]
-
-And so just really happy to be a part of it. Have a earnest collaborator in that kind of way. Yeah, I've seen their name around for as long as I've heard about React Native being used professionally. They only do React Native and have built over 75 apps for companies from startups to like the biggest fortune, whatever companies in the world. [07:13]
-
-than being great people who I'm happy to collaborate with, be sponsored by they're a team of about 30, mostly developers, mostly with more than 10 years of experience. And they work alongside your team to help you develop expertise in React Native. So if you are working for a company, spinning up a new product with React Native, and want to hit the ground running, definitely give them a ring. [07:36]
-
-Infinite. red is the website. Cool, all right, [07:39]
-
-## Main content React 19 RC1
-
-**Mark:** so we actually have a very, very big Big development if you've been paying attention the last few months, we've been tracking that the React 19 release has got delayed because of concerns over changes to suspense behavior when multiple sibling components all want to suspend you know, the change had been made last fall, the community pointed out problems with it, Back in the spring, and the React team said okay, fine, we'll hold on React 19 until we can come up with a solution for this issue. Well, the good news is, that fix is actually done and out as a new React 19 RC. [08:17]
-
-## [Tech writeup of a solution to the sibling rendering issue](https://github.com/facebook/react/issues/29898#issuecomment-2477449973) that delayed React 19’s release
-
-**Mark:** And the React team put together a very good visual and technical explanation of what they changed and how the behavior works. They're in the GitHub issue link, so I highly recommend taking a look at that. Big picture is that the original behavior as of 18, if you had multiple sibling components that all wanted to suspend, was it kind of acted like a promise. [08:40]
-
-all, Where, in one render pass, it would kick off all of them, wait for them all to complete, and then actually show the content. The change that effectively broke things was it would render the first child that's suspended, see it, and say, oh, wait, let's wait for that one to complete, then pick up with the siblings, making it more like a serial for loop. [09:05]
-
-And the new behavior is when that first child suspends, It will go ahead and show the fallback, but it will kick off kind of a pre warming step in the background. So like, not like a complete render, but I guess kind of like a partial render, enough to kick off the requests. So that at least the other requests are in flight right away. [09:29]
-
-And so the overall behavior should be at least as good as it originally was, if not maybe actually kind of better. In, in some certain ways. So the two key takeaways here are that the, you know, the suspense behavior that people were concerned about has been addressed. It did take them a few months, but they, they did it in a comprehensive way, not just slapping in a bug fix. [09:52]
-
-And also that hopefully React 19 final is very, very close. There's still no specific timeline, but they did make the comment that we hope to publish 19 stable. Boy, [10:03]
-
-**Carl:** Yeah, and just maybe to restate what you were saying in different words, so my understanding of like the problem that they introduced and why they introduced it is Like you said previously, it was just sort of rendering all of the siblings before it handled the suspense. [10:18]
-
-And that was undesirable because it introduced latency before the fallback would be rendered. It did a bunch of work before showing the fallback. So they wanted to change it so that the fallback would be shown quicker, but caused requests to behave as a waterfall rather than kicking off in parallel. [10:36]
-
-It would kind of waterfall shape of your component tree. If you had requests being kicked off by like child components and sibling components and stuff and so now they managed to find like a happy balance where they don't do all of the work of rendering, you know doing the I'm fuzzy on the terminology around like commits and rendering and all that so I can't speak to precisely there [11:00]
-
-**Mark:** someone had a blog post that explained these things. [11:03]
-
-**Carl:** I read that but many moons ago, yeah, so it's a nice Midpoint between what it used to do and what they wanted it to do and now it works correctly. [11:13]
-
-So yeah, They delayed it back in June and they now have a fix So, you know, only a couple of months delayed. It's only all year that we've been talking about React 19. So maybe it'll be released soon. moving on. [11:27]
-
-## [Next.js 15](https://nextjs.org/blog/next-15)
-
-**Carl:** Next. js has version 15, out and stable. You know, they call it out and stable, but I don't know, it's stable version is like using of the big changes is using like React 19. RC in the apps router, the app router. And so that still feels to me like the proving ground for React 19. [11:50]
-
-So calling Next. js 15 stable when it's recommending that you use an unstable version of React feels funky to me. Feels like a, like a workaround to the problem of people don't test, you know, release candidates, so they're just going to call it stable. [12:06]
-
-But yeah, I'm not sure that I personally would base a production system off of the app router in Next 15 because it just, because of that, it feels like a beta, beta is maybe too strong, but it feels like they're still exploring. claim it's stable, I don't know what sort of underlying technical issues might cause things to have to be changed. [12:27]
-
-**Mark:** This touches on multiple different aspects that we've talked, at least I think we've talked about previously. One is that, you know, especially with all the server component stuff, the React team used to be able to, pre alpha test all their ideas internally at Facebook, but they can't do that with server components because it relies on having a separate server, and Facebook has all their own server, which is one of the reasons they ended up collaborating with Vercel. [12:55]
-
-To be like, they convinced Vercell to go with their vision, but also it conveniently aligned with, we need someone who doesn't have Facebook server infra to let us build out server components and prove that it works. Along with that the app router has always used a pre release version of react. [13:14]
-
-Like this. Like, even before they came up with the Canary system, it was using, assorted, experimental, unstable builds. And so, haven't been keeping track of which version specifically, but, I would assume that over the last year, versions of Next 14 have been using, you know, React 19 Canaries, betas, RCs. [13:36]
-
-So, if anything, it's, More stable now than it was a year ago. But part of the point was that, the App Writer needs all this new functionality in 19 in order to work. And the whole point of the Canary system was that, well, even if it's not fully 100 percent stable stable as a standalone release, frameworks like Next are able to paper over the rough edges so that from their point of view and from the consumer's point of view, It's stable. [14:05]
-
-So, I agree that the versioning system is funky, but it's also not a new thing. [14:10]
-
-**Carl:** Right. Definitely not new for sure. But yeah, if you're doing a little side project, probably fun to play with. If you're a founding engineer at a new company, I'm not sure I would start a new thing on it. It's not sure I would start a new revenue generating entity on it. [14:25]
-
-So, yeah, one new thing that they introduced is an instrumentation. js file, hook, I don't know. It's a place where you can plug in to the core, like, network level of the system. Next. js for things like observability and monitoring. [14:43]
-
-So that seems pretty cool. I think that is one of those like quiet underrated things that every app needs and that is not always super easy to figure out how to fit it in. In the past, I have done a fetch wrapper that introduced things like performance metrics and observability and stuff. So just having that as like a a framework feature in Next. Makes a lot of sense to me. Glad to see it. [15:07]
-
-They also put out a, a form component, which seems like it overlaps with like the native behavior that the native form enhancements that React 19 is introducing, so I'm a little bit fuzzy on like what that abstraction is super duper for, but yeah, it's there. [15:22]
-
-Cool. On to TypeScript. [15:25]
-
-## [TS 5.7](https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/)
-
-**Mark:** So, the TypeScript release chain also keeps chugging along. I think they do releases every two or three months. And so we're now up to TypeScript 5. 7. There are a couple nice to haves, like checking for variables that never got initialized, like borderline winter. Related stuff, but at the types level. The, the interesting thing from an ecosystem perspective the story around, you know, how TypeScript interacts with module output and file paths has always been very complicated, because it's always been very complicated at the JavaScript level. [16:00]
-
-And one of the things that had been kind of a pain point, weird point, frustration thing was that even when you were writing, like, Writing TypeScript files in order for some ES module, you know, import behavior to work properly, your imports still had to say you were importing from a js file in the import path. [16:25]
-
-And that always felt really weird. It's like, yes, I realized that's what is actually executing at runtime and that the build output is a bunch of js files, but the file name I'm, but with the file that I'm writing this in is a ts file. Like this, this doesn't make sense. This is weird. I don't want to have to do this. [16:45]
-
-And the TS team had resisted trying to make changes here because after the first couple of years of doing TypeScript features that required actual separate output, like enums, they're now very much on board with like, we are a superset of the JavaScript language and the compiler doesn't do anything to have to rewrite the actual behavior of your code. [17:11]
-
-But they appear to have actually added a mode that will change import path names. So when you have an import that says import from something. ts If this flag is enabled, it will rewrite that to say import something from a js. It only does this in certain conditions where it's a relative path and not, and not a, like a globally scoped path. [17:41]
-
-I, I don't pretend to understand the rationales behind it. I'm mostly just going off the release notes here. So, it seems like a rather grudging Decision to tweak things in favor of better ecosystem interop. [17:54]
-
-**Carl:** this feels very much like stuck between a rock and a hard place in that, like, Now there are more and more ways to run your TypeScript code without doing a full compilation pass, sending it fully through the TypeScript compiler, TSC, It's an intersection of like, there are more ways to run your code without fully compiling it and executing the built output. And there are more ways to, or rather, imports are getting stricter about file extensions and just like, Ooh, oh no, what do you do with that? Those are like incompatible assumptions. [18:29]
-
-this seems, I agree, this seems like a grudging, I don't know if I want to call it a hack fix or a band aid or something, but like, just even as they're talking about it in the release notes, it's, I feel like I can sense their trepidation and like angst over, like, you know, like a quote from it is like, you might need to use conditional exports with scoped custom conditions to make this work for like absolute paths, like if you're using, you know, your TS config to, you know, import, you know, structure and not use relative paths and it's just like, Oh no, that's [18:59]
-
-**Mark:** so thrilling, [19:01]
-
-**Carl:** Right! [19:01]
-
-It's like, oh god, that's, this sounds like a whole new problem. they're trying to fix a problem. They may introduce more problems. I think this is going to be painful for a long time. [19:11]
-
-**Mark:** but it's there. If you feel you need this. [19:14]
-
-**Carl:** maybe you do. Yeah, I don't know. Anyway, seems, seems rough. V8 introduced compile caching, which allows runtimes to reuse some of the like JIT compilation steps. So TypeScript is taking advantage of that new V8 feature to improve its startup time. They talked about, you know, if you do like TSC dash dash version, it now prints faster. [19:38]
-
-So like, that's cool. That's nice. Startup time is definitely a pain point for Node generally, JavaScript generally. And that's nice. Less latency. [19:48]
-
-## [React Router v7 | Remix](https://remix.run/blog/react-router-v7)
-
-**Carl:** Cool, okay, moving on. React Router v7 slash, you know, the one with Remix. headline, big pull quote, " We encourage all Remix v2 users to upgrade to React Router v7." This seems really neat. I want to play more with this, but I think really playing with it is going to take a lot. I have an app in mind that I want to try and move over. [20:12]
-
-It's currently using Remix 1, so I can upgrade to 2 and then upgrade to React Router 7. Woo! Multistage upgrades. Yeah, the big highlight here, I guess, is that Essentially, I think my mental model for understanding this change, you know, Remix to React Router is what was Remix is now Framework Mode in React Router. [20:34]
-
-So you can still use React Router as you always have, as just like a library. Or you can use it in Framework Mode, which has a Vite plugin to get more control over, you know, the build step, the compilation, which is what used to be Remix. So it feels like they explored a lot of like API surface area. [20:55]
-
-Like, how do we fix this? How do we make this work correctly as we want it to with Remix? And then it feels like they got it, they got it where they want, they refined it to where it was just kind of an abstraction over existing build tools. Like that was the big push to not have like, you don't interact with Remix, you interact with Vite and there's a plugin that is Remix. [21:15]
-
-And so now this feels like the next logical step there where like it is truly just an agglomeration of existing tools that you can choose how to use in the way you want. I think that's pretty neat. That seems pretty cool. I definitely want to play with this a lot more. [21:27]
-
-**Mark:** as I roughly understand the sequencing, so Remix itself was originally based on ESBuild, and there was no way to really mess with that configuration. Then they managed to come up with a Vite plugin, which did the same thing. And then the Vite plugin, I guess, became the default way to use Remix. [21:44]
-
-And now that it's like, well, at this point, there actually isn't much left that's specific to Remix the framework. It's all in the plugin. And so that enabled them to help take some of this, and take basically all this functionality, back into React Router, the library. And so as you said, there's the client side piece, which has always been there, and then it's like, well, all this stuff that used to be server related, and used to be specific to the Remix framework, is now encapsulated in the Vite plugin, so it's just there if you want to use it. [22:14]
-
-**Mo:** I mean, it's quite interesting because I feel like this idea of, frameworks being almost add ons or plugins to the bundler, whether it's Vite, I guess I've seen this with Vite only, is quite an interesting premise and I think it's picking up a little bit, maybe almost as a response to how Next. js is such like a, tightly It's not proprietary, but proprietary like piece of software where you're like really buying into Next rather than buying into the tools that are, you know, underlying Next. [22:43]
-
-And I see that with the new React Native Framework One as well, where it's really kind of, it's a Vite plugin. Everything's on Vite and we're building on top of Vite and we have some extra functionalities that comes out if you want to use it as kind of a framework. So it's interesting to see how this shift from the Remix team has had, I think, probably reverberations across to other, parts of the ecosystem. [23:04]
-
-I guess the question that I still have is, why have they done this from a branding perspective? Like, it seems like a lot of brand capital that they probably had in Remix Is, kind of disappearing by going into React Router. Now you could argue whether or not that's good brand capital or not, because Remix has had its fair share of controversies. [23:22]
-
-it's an interesting move for me. [23:24]
-
-**Carl:** I would raise, as a counterpoint, That they already captured the brand value because they sold Remix to Shopify, [23:31]
-
-**Mo:** It's a monetary brand value rather than anything else. Like a monetary for acquisition brand value. [23:36]
-
-**Carl:** I think there's a decent argument to be made there. but also like react router has been Around for like 12 years 11 years Literally, like, the original way of doing routing in React. So it kind of makes sense to me to say like, Look, we solved this problem. [23:54]
-
-I have been watching them try to figure out where the boundaries are between routing and, like, server and, they've been trying to figure out how to do data loading and, bundle splitting at the router level. For that entire time. So it feels to me like they spun up a new brand to do more experimentation and now got there and then folded it back into the original tool that they've been trying to solve this in forever. [24:20]
-
-**Mo:** the process got acquired, which is a nice payout as well. [24:24]
-
-**Carl:** great bonus. Yeah. [24:25]
-
-**Mo:** Yeah, makes sense. [24:27]
-
-**Carl:** Speaking of Vite. [24:28]
-
-## [Vite v6](https://vite.dev/blog/announcing-vite6.html)
-
-**Mark:** So associated with that Vite version six just came out. And it's interesting because they've tagged it as the most significant release since Vite 2. And yet I was looking through the announcement and the migration guide, and it looks like there isn't a lot that really feels user facing in terms of features and changes. [24:50]
-
-## [Environment API](https://github.com/vitejs/vite/discussions/16358)
-
-**Mark:** Best as I can tell, a lot of this one is on the inside, and it looks like they did a lot of major refactoring internally to enable what they're calling the Environment API. And as I understand it, the idea is that because JavaScript these days is used in so many different ways, it's used in the browser, it's used in Node, in Deno, in Bun, in worker runtimes, that may have differing constraints. [25:18]
-
-It seems that the environment API is going to allow you to generate build output targeted for different environments based on certain definitions. I'm still kind of hazy on that part myself. I have seen a number of mentions that things like some of the other, Framework level Vite wrappers are going to benefit from having the environment API available. [25:45]
-
-So, seen some mentions here, I don't quite know how all the pieces connect. general takeaway is like, it seems like, a fairly easy upgrade. saw a couple people on Reddit say like, yeah, I just like bumped the version and it just worked. So it might not have an immediate benefit for an application in terms of speed or build output per se, but it does seem like it's fairly foundational for a lot of the framework level stuff that's going on in the ecosystem. [26:12]
-
-**Carl:** Yeah, we definitely agree with that. I've encountered a little bit of that environment pain. Not using Vite, but just like trying to use Cloudflare workers. Trying to do, a worker serverless type of architecture. Definitely can tell that it is, Like bleeding edge of the ecosystem and a lot of the existing tooling is just like not well suited to support it precisely. [26:37]
-
-Yeah, just like having an existing, like daemon, existing process that is long lived. It's just a very different set of constraints from a short lived process that Handles a request and shuts down. So, Remember the era of the, of the acronym for rendering? SSG and SSR and ISR and S So, I feel like this environment API to me, it feels like a reaction to that, of like, look, we have all of these contexts in which web pages are being rendered and used. [27:08]
-
-And we don't even have a language to talk about it. I guess Vite has, spent most of the version five release iterating on what has then turned into this environment API. It sounds like they introduced it as. Something else the runtime API in 5. 1 and iterated on it, iterated on it, realized that what they landed on was different enough from that, that they just came up with a new name for it and put out a major release. So yeah, definitely looks interesting and valuable. [27:38]
-
-And yeah, given how Vite seems to be like the common building block that everyone else is starting to rely on, here for it. This seems like the kind of exploration that is super, super valuable, especially given that place in the ecosystem. [27:51]
-
-**Mark:** Definitely. [27:52]
-
-## [Expo Launch Party](https://expo.dev/launch-party)
-
-**Mo:** yeah, let's move on to some React Native land. And interestingly so, towards the end of November, we've had Expo's launch week. This is where Expo kind of bundle a bunch of the stuff that they've been working on and launch it in one go over a few days. it's been quite interesting to see some of the stuff that's been coming off. [28:10]
-
-Nothing is particularly a big surprise but it's interesting to see the culmination of some of the stuff being released out to the public. So, I'll go through some of this bit by bit, and we'll talk through it. [28:19]
-
-## [The magic of Expo DOM Components](https://expo.dev/blog/the-magic-of-expo-dom-components)
-
-**Mo:** So, the biggest thing that the Expo team has been talking about over the last few months, I'd say, is DOM components. [28:26]
-
-This idea of how uh, Can we make it super easy to run web based DOM elements inside of a native app without turning the entire app into a Cordova Ionic sort of web view based app? this is controversial at the best of times, I think, right now. A lot of people seem to really like it. [28:44]
-
-There's some people who feel like it's kind of a step I think the expo team is trying to take this pragmatic approach of, a lot of people have React web apps, how do we kind of get them to migrate incrementally and introduce them into the React native ecosystem. So, The article that we've linked has some interesting use cases. It kind of looks at the integration of, you know, you still, if you have a WebView based app, maybe there's some cases where you still want to introduce some native functionality. [29:11]
-
-So, you know, you press a button, maybe you still want to have a haptic on the native device. So how do you integrate those things together? And make it kind of feel native in some capacity. So it talks about some of that, some of the patterns that you want, and some use cases. So some of the things that have been really difficult to do in React Native is things like displaying markdown. [29:28]
-
-Markdown, you know, you have to create your own renderer with native components for it. And it's a lot of work to do that natively. Anyone who's done that will kind of attest to that. And Stuff like that gets really easy because it's a solved problem in the web world. So, they're kind of not saying you should use this for your entire app. [29:44]
-
-They're kind of being very, very, very clear about that. thinking of using that in places as an escape hatch more than anything. [29:51]
-
-**Mark:** More interop is always a good thing. [29:53]
-
-**Mo:** yeah, you know, it's good to have that. Now, this isn't something that necessarily is new. Like, you can always use WebViews in React Native. It's been around for probably since the very, very, very early days. [30:03]
-
-It's nothing new. There was always React Native WebView as a library. this is just an easier way and a nicer way to do it. And it uses the favorite directives that everyone has now in the React ecosystem, which is the use directive at the top of the file. And you just pop in a use DOM and it kind of works. [30:18]
-
-I think we're starting to overuse directives. We should probably stop as an ecosystem. It's just getting a bit out of hand, but that's a different conversation for another time. I see Carl passionately nodding at this. Mm [30:30]
-
-**Carl:** flashbacks to like, I guess it was like ES6 when the use strict directive was introduced. And I just remember the emphatic, you know, like people would say like, Ooh, what if we did this other directive? And I just remember the reaction being like an emphatic, like, No, this is the only directive we're ever going to do. Never again. This is terrible. We should not have had to do this, but we needed to. Never again. [30:53]
-
-And so now seeing like, we got like, what, four or five now in React? And they don't even have the same semantics. Like it used to be only at the top of the file and now it's like top of the source file, which is technically different. Not the, and like some of them are at the tops of functions. It's, it's complicated. It's too much complication. [31:13]
-
-**Mo:** I tend to agree with you. I quickly want to touch on some of the limitations to dissuade people from trying to use this for their entire app, so I'll just quickly quickfire those. The first thing is that performance is really going to suffer. Because, you know, when you're running a React Native app, it does have a JavaScript engine that uses Hermes under the hood. [31:30]
-
-But for this, you're basically instantiating a new JavaScript engine that will run web code, so that can be JSC on iOS and V8 on Android. And that basically slows down your load time quite significantly. And then if you do want to tackle that, you're probably going to have to have some hacky stuff to preload these components, hide them, and then display them. [31:48]
-
-It becomes a mess. So you really want to use this when you have no other options, or, you know, You have an escape path long term to basically get rid of these, these webviews. And then the other thing here is you have to be very, very clear as to how you handle your navigation. Because the worst thing for a user experience is having multiple layers of navigation. [32:06]
-
-So, you know, you have your stacks and your tabs inside of your native app, and then suddenly someone clicks a button inside of the webview, and it just adds a new screen onto your webview. And so you've got like two or three layers of navigation. It gets messy. Be careful, think about it deeply basically use at your own risk and think about the consequences of your actions. [32:24]
-
-## [Introducing Workflows: CICD built for your app](https://expo.dev/blog/expo-workflows-automate-your-release-process)
-
-**Mo:** In other things that the Expo team's been launching so Expo launched workflows. This was one of the more surprising things. They hadn't, they kind of kept this under wraps a little bit. But the whole concept with this is so far you know, Expo's got their cloud build tools, EAS build and EAS update. [32:38]
-
-So you can use builds to create your mobile native builds. They've got a submit tool. solution as well, which kind of pushes that thing to the App Store for you on Google Play and Apple App Stores. And they also had an update mechanism, which allowed you to issue over the air updates to your users. [32:52]
-
-Now, this, they never had a workflow or like a proper CICD tool. So you would have to basically almost run your CICD on another cloud or another sort of CICD tool and then call Expose. servers just to trigger the build or trigger the update. So they've kind of created some very basic workflow functionality. [33:11]
-
-It's YAML based. You know, you can run bash commands, you can run NPM commands in it. It has some very basic control flows as well. So if you kind of want to get away from, you know, using GitHub actions for your, for your mobile builds and mobile updates, it's a cool option if you don't want to add that as an extra piece that interacts with Expo. [33:30]
-
-It's something to see how they develop and extend over time. [33:33]
-
-## [Environment variables in EAS: new changes to simplify setup](https://expo.dev/blog/environment-variables)
-
-**Mo:** other unexpected, but this is incredibly welcome news they have revamped the way that you handle environment variable handling within Expo. Now this is something that has been a real pain. I think it's the place that the Expo team probably struggled the most to come up with a good and comprehensive solution. [33:52]
-
-Because you've got sort of different layers of environment variables when you're dealing with a mobile app. You have sort of secrets that are stored inside of the app's binary. Then you've got JavaScript based environment variables that anyone can inspect if they go into the JavaScript, so you don't really want to use any secrets or put any secrets within them. [34:10]
-
-Then you've got some stuff for your build processes. So there's sort of these like multiple layers of environment variables and they each had different sort of sensitivities or levels of secrecy that you needed to maintain. And so they've centralized all of this in one place. So EAS can kind of manage all of this for you. [34:26]
-
-And they've tried to centralize this because environment handle, variable handling in Expo was a nightmare. You had to kind of deal with three different environment variables, like working in a consultancy was one of those things that clients would come to us and be like, why is this so hard? And I would be like, I don't know, there's probably should be a solution. [34:43]
-
-One of our clients actually, prior to start a startup, like, like, thought very seriously about starting a startup to solve this problem, and I told them don't, please don't, Expo will probably solve it, and they have. So, it's good. I think it's still to be seen how it bodes in practice, but from first glance, it looks like you kind of define these centralized environments, and they have all of your environment variables in one place managed by Expo, which can make things significantly easier, and you can kind of define the visibility, visibilities as well. [35:08]
-
-So this is very welcome, because I think it's. It's kind of long overdue and it's one of those things that was a big pain point. [35:13]
-
-**Carl:** I love that. It sounds great. Sounds like a real problem that needs, you know, sounds like an improvement, but I have never worked anywhere that did not have some kind of pain with environment variables, including on my like solo projects, like currently the, you know, the main app that I write code for. As a stupid, terrible environment variable setup, because like, you know, it's CICD with GitHub Actions deploying to a Kubernetes cluster. [35:41]
-
-And so like, I have to take, I can't remember the, I think I put all of the secrets in GitHub. But then they get loaded into GitHub Actions alongside lots of context, build context, that the action provides on its own. And then I have to manually take all of the information that's relevant to the executing code and put that in a secret in Kubernetes and then load that. [36:03]
-
-So, like, I'm glad they're trying to improve it. I also just kind of think dealing with secret data is just a hard problem. So, I suspect this may not be the end of it. [36:13]
-
-**Mo:** I don't think it's the end of it. If they make it marginally better, especially, I think, I think it kind of ties hand in hand with their workflows functionality because they needed a, you know, solution to environment variables if they're creating almost a CICD. So, I think it's kind of hand in hand with that, but yeah, the exact same problem, right? [36:29]
-
-Like, even if you, before these workflows, what you had was you had the same environment variables, probably in GitHub, and then you had them replicated somewhere in EAS for your builds, and then somewhere else in your, for your updates. Maybe this removes some of that duplication, so at least your client side secrets. are sort of shared by Expo and managed by Expo. I hear your pain with the Kubernetes and backends, like infrastructure environment variables. I've done the exact same thing with GCP and Terraform and trying to manage those and it's not a, it's not a fun ride. [36:58]
-
-**Carl:** Nope. [36:59]
-
-## [Expo SDK 52](https://expo.dev/changelog/2024/11-12-sdk-52)
-
-**Mo:** Cool, and last but not least, obviously they also released Expo SDK 52. they say that this is their biggest release ever and I kind of believe it because the new architecture is out Cool. So that is a big, big revamp of everything in the internals of React Native, and they obviously manage a massive SDK with a bunch of different libraries. [37:16]
-
-So they've had to make sure all of it is compatible. So far we're hearing about some pains with Expo Go. Some people are having some troubles with Expo Go because it suddenly switched to the new architecture by default. So people are having some upgrades. Issues, but that's to be expected, to be honest, with such a big revamp of the internals and people will need to update their apps. [37:35]
-
-Some interesting highlights, just quickly running through these. Expo Video is a new library that's become stable now. So this is a revamp of the old Expo AV library that handled audio and video. They're splitting these out to Expo Video and Expo Audio. And it comes with a whole bunch of cool stuff. [37:50]
-
-Like, being able to generate thumbnails, being able to have picture in picture and a whole bunch of other stuff which is, is needed to, to kind of play video in a, in a high quality way in native apps. They've also released a beta of Expo Audio, which is, again, a rewrite, and this is great, and hopefully it just becomes a little bit nicer implementation. [38:09]
-
-And then they're releasing a whole bunch of stuff to their file system libraries, their cameras, and so on and so forth, Expo Images getting some updates. So there's a lot of good things. I'm not going to go through all of them because it is a massive changelog. But go and try it out. DOM Components as well, which we mentioned earlier on, is available with Expo SDK 52. [38:25]
-
-So if you want to play around with those DOM Components and figure out how you can integrate WebViews inside of your existing app with DOM Components, go for it. Expo SDK 52 is the place to try it out. [38:36]
-
-**Mark:** Sounds like a pretty big deal. [38:38]
-
-**Mo:** Yep. [38:39]
-
-**Carl:** Maybe one day I'll use Expo. [38:41]
-
-**Mo:** I'd love to hear your feedback on it, Carl, because it's quite a nice DevEx. I've had people who've, like, have you, you've built for React Native back in the day, right? [38:49]
-
-**Carl:** Yes. Short answer, yes. [38:51]
-
-**Mo:** it's usually people who have built with React Native or built native apps before, ages ago, and then they come in and try Expo, and they're like, holy crap, this is something. it has that, like, mind blowing effect, so I'd love for you to try it and then come with your feedback. [39:04]
-
-**Carl:** I briefly tried Expo like five years ago, [39:08]
-
-**Mo:** Not the same. yeah, they're totally different, totally different, totally different ecosystem. Yeah. [39:13]
-
-**Carl:** I remember it had a huge constraint of, it felt a little bit like a create react app in that it did a lot. But if you were building a production app, you were going to have to eject from it sooner or later. And the ejection story sounded pretty rough. [39:28]
-
-**Mo:** yeah, ejection was not a fun time. they had a lot of, I think that was the biggest, like Expo had almost a dip in reputation and it was because of ejecting. And so they, they completely got rid of ejecting. You don't eject anymore. You can add native dependencies as you wish. And it's a totally different mechanism. [39:42]
-
-So Expo in 2019, 2019. is a very different thing to Expo in 2024. And I'd say they've regained that reputation, which is great. [39:52]
-
-**Carl:** Cool. Sounds good. Yeah. I guess my, perception way back when was like, this feels like create react app, create react app feels like it's dying. This feels like it might die, but here we are five years later and it is totally transformed. Looks really great. This is definitely what I would, you know, were I to try a native app. I got a long list of other things to do. [40:10]
-
-## New CSS
-
-**Carl:** Cool. Okay moving on. This is slightly unstructured. [40:14]
-
-## [A Friendly Introduction to Container Queries](https://www.joshwcomeau.com/css/container-queries-introduction/)
-
-**Carl:** I'm going to frame this conversation around a Josh Kumo article about a friendly introduction to container queries. I don't think I had heard of container queries, but like, I was reading this was like, holy shit, there is so much new CSS stuff that I, that has just not crossed my radar. [40:31]
-
-So container queries are basically media queries, but for the containing element. So you can say all sorts of things. not super duper sure what the support story looks like for them. that's basically why I checked out of paying close attention to CSS news is because it was so much of it is like Chrome only, or, you know, not supported in Firefox or Safari. [40:54]
-
-And so like, stopped paying attention because so many of the things that looked really interesting and neat were not stable. And if a CSS feature is not stable, you can't polyfill it in the same way as JavaScript. Bye. [41:05]
-
-## [A Framework for Evaluating Browser Support](https://www.joshwcomeau.com/css/browser-support/)
-
-**Mark:** Conveniently on that note, Josh also just put out a post that discusses his approach for looking at browser support for various features, CSS or JavaScript, and sort of like his mental model of, how do I decide when a feature works? Might be good for me to actually use in practice. Of course, like it literally, it basically boils down to it depends, but he walks through kind of the process of how he gets to that and the article actually literally starts out according to can I use container queries are supported for almost 93 percent of users. [41:39]
-
-**Carl:** Right, and I see in the, thumbnail, in the, you know, preview image, is 93 percent good enough? And that was exactly my response to that. So, I don't know. it's a hard thing. [41:47]
-
-so, container queries just caught my eye as like a great Way to do a great enhancement over media queries because media, queries, you can adjust your styling based on, you know, the size of the screen, based on the capabilities of the device, but container queries, it looks like, I don't know the depth of the capabilities, but the most obvious one I'm seeing right here, you know, the first one it shows is, you know, mid width of the containing element and like, that's great. [42:18]
-
-I have had so many responsive. design bugs where, I try to reuse an element in a new context and it's narrower because I wanted to put more elements next to each other or something than I did in the previous one and it looks like with container queries I could Avoid those bugs by saying, if the space this is in is this size, render in this way. Which is a very different, much more powerful method of querying than just the device support. So, yeah, that seems really [42:53]
-
-**Mo:** I'm curious as to when, I think it's still probably in, experimental phase, but I'd love to see when this becomes available for something like Tailwind. [43:01]
-
-**Carl:** Right, and it might, I wonder if it would even be like a breaking change. Because they currently have, you know, SM, MD, different size constraints. Thanks. Thanks. And it feels like they might be able to just modify those to be based on the container. [43:16]
-
-**Mo:** they've done that exact pattern when they like introduced the group functionality. Like, they obviously had like hover, active, focus, or whatever for the different states, and then they just added a group colon active. So I wonder if this becomes like a container dash sm, container dash md, or something like that. [43:31]
-
-Like, that would be consistent in my mind, at least. [43:34]
-
-**Mark:** quick Google search says that they put out a first party plug in for container queries back in 2022. And there's something involving an at container wrapper on a parent. [43:48]
-
-## [State of CSS 2024](https://2024.stateofcss.com/)
-
-**Carl:** I said this is going to be kind of a loosely structured thing, related to this conversation, there was a state of CSS survey, you know, same as state of React, state of JS, whatever, Devographics, Sasha Greif and I was just looking at the list of CSS features and thinking like, wow, I have not used more than half of these. CSS is totally different. And you know, in the introduction to this State of CSS survey shouts out, "let me make a prediction. We'll look back at 2024 as the turning point between CSS classic and new CSS." And that's interesting. I feel I definitely learned and became expert in classic CSS. CSS Classic. [44:31]
-
-Describes as like, the build steps and all of that. I had to learn floats and positioning and box model and I feel like none of those things are super relevant anymore. Now it's grid and flex. And so it's just like a whole new set of Primitives that I have not had professional experience using like oh dang cool. Wow shifting landscape know what? I thought was stable land is now totally different just really [45:01]
-
-**Mo:** I the one that always, like, that winds me up that I learned about a little while back, that was just like, What? Why does this exist? But it's also very impressive that it exists. Is, like, the mathematical functions that you can use now in, like, CSS for calculating values. Like, power of, square root, logarithms. Like, how do I, what case do I have where I need to, like, calculate a size based off of a logarithm in CSS? Like Cool, I'm glad it exists, but I can never imagine needing to use that. [45:30]
-
-**Carl:** we do some funny layout logic and on the Reactiflux website. And yeah, you can do that. the font size is based on the viewport width, for instance. [45:41]
-
-**Mo:** but would you ever use a logarithm based off of that? [45:43]
-
-**Carl:** Hey, maybe if I wanted to, you know, nonlinear scaling, [45:46]
-
-**Mo:** Yeah, maybe. Anyway, it's quite cool. [45:48]
-
-**Carl:** I don't know. Wild. [45:49]
-
-**Mark:** big picture metaphor. I think what's come into my mind is that it feels like it's a little bit like the ES 2015 spec where you could do a lot of stuff in JavaScript prior to that. And a lot of stuff in ES2015 was effectively syntax sugar for stuff you could do before. But there were also a number of things in ES2015 that required support at the language runtime level, like proxies, that simply could not be done before and enabled virtualization. [46:17]
-
-A whole lot of new functionality from there. So, you know, I, I know that CSS is not like a strictly versioned spec the way that, you know, the JS language is at this point, but I think that's kind of the, the metaphor that we're going for here. [46:31]
-
-**Mo:** yeah. [46:32]
-
-interesting. Complete side note before we move on, but since we started with this, Josh Comeau his website is like one of the most beautifully designed tech websites I've seen. Like, I say this every time I look at it, I'm like, wow, this is beautiful. He's done a phenomenal job with this website. [46:47]
-
-**Mark:** Josh is amazingly talented, he is an amazing educator, his blog is wonderful, I can vouch for his courses without having looked at them because I see the care and effort he's put into his blog post. So, highly recommend all of Josh's stuff. [47:00]
-
-**Carl:** Very, very true. [47:02]
-
-## Framework betas:
-
-**Mark:** Okay, moving on a little more quickly, a couple different frameworks and pieces are in beta. [47:08]
-
-## [RSC in Expo Router is now in Beta!](https://expo.dev/blog/universal-react-server-components-developer-preview)
-
-**Mark:** One is that the Expo router now has support for server components. And Mo can probably talk a little bit more about the actual implementation nuances here, but big picture, it's a big deal because it's server components coming out in any framework other than Next, and more specifically within the React Native ecosystem. [47:29]
-
-## [TanStack Start beta](https://tanstack.com/router/latest/docs/framework/react/start/overview)
-
-**Mark:** And then as sort of an inverse of that, Tanner Linsley's 10 stack start framework is now in beta, and it's a deliberately non server component framework for now. Tanner has said he will look at adding some server component support down the road, but his argument, and he's made BlueSky within the last few days, is that he feels server components are actually of very limited use. [47:59]
-
-and really much less flexible compared to a server function concept architecture for managing data. So he did just do a talk about and kind of advertising some of the features at React Summit New York last week. I looked, if you check out the Git Nation website, the video is available for people who have, you know, paid up for the early access to the videos and it'll go public sometime in the next month. [48:27]
-
-**Mo:** Just to quickly touch on the exporouter RSC stuff, So it is very much an experimental at this point, it's beta. You can't even host it on a production server, you need to do it locally, so it just means you're basically testing it out in dev at this point. It was previously just on Evan Bacon's machine, and now it's on, you can have it on your machine, which is quite, quite cool. [48:47]
-
-But yeah, like the cool thing about RSCs and React Native is that you're rendering native components under the hood. So you almost render native views, native texts, native images, and you almost do a building block of components through an RSC that is then rendered natively, so it's not web views or anything like that. [49:03]
-
-So it's very different to the DOM component stuff that we talked earlier, which makes it very interesting. Still very early days, but we've seen really cool demos of this over the last year at React Conf and beyond. [49:14]
-
-## [React Native 0.77 RC0](https://github.com/facebook/react-native/releases/tag/v0.77.0-rc.0)
-
-**Mo:** Picking on the React Native terrain, very quickly, React Native version 0. 77 has had its release candidate, which is very quick after 0. 76. This is a very small release. Expectedly so, after the massive release that was the new architecture becoming default. So, just some quick things. Swift templates for iOS. [49:35]
-
-This is taken away from the Objective C base of code in the internals of React Native and making it more Swift based and more modern, which is great. They've done some improvements on tvOS integration, which is great because tvOS has kind of been one of those platforms that's been in the shadows and not well supported. [49:52]
-
-And there's some general better performance improvements specifically when dealing with animations. So there's some minor improvements, but nothing super major and not a whole lot of breaking changes. [50:02]
-
-## [New List dropped in React Native](https://x.com/jmeistrich/status/1855663310386958840)
-
-**Mo:** Now, speaking of the new architecture Last month we had the release of the new architecture with 0. 76, and we're already seeing some interesting stuff coming out of it. [50:12]
-
-So, Jay Meistrich, who I've known for a little while now, actually released a completely new list component for React Native called LegendList. So, Jay maintains a few libraries called, like, LegendState, another state management library, and I think LegendMotion, which is an animation library. And he recently Created a new list, and now he, he claims that I inspired him to do this at a talk that I did at React Advanced, which is very flattering, and I think he's giving me way too much credit and I definitely don't deserve that, but basically the, the whole concept is with the new event loop in React Native, you can kind of synchronously call on layout events. [50:50]
-
-Which you previously couldn't with React Native and so this is a JS only implementation as a list and it seemingly, on first glance, outperforms FlashList and the FlatList that comes default with React Native so it may be the quickest list in the React Native ecosystem right now. A lot of people are very, very excited by it. [51:08]
-
-Jay is quite good at performance stuff because he spent a lot of his time as a game developer back in the early 2000s basically. So, he was dealing with a lot of very, very, very low memory and low CPU devices. And I guess he kind of knows this stuff decently well. So it's going to be interesting. [51:25]
-
-He's released it to public, so you can go and try it out right now. But it's still to be seen. He's adding more and more APIs as we, as we speak. So it's quite interesting. [51:33]
-
-**Carl:** Super cool. Mo, I'm going to challenge you on that because if somebody tells you that you were an inspiration, I think you should [51:39]
-
-**Mark:** Take all the credit. [51:41]
-
-**Mo:** I just did a talk. It was nothing special. [51:44]
-
-**Carl:** Ah, that's pretty special. [51:45]
-
-## Twitter -> Bluesky migration
-
-**Mark:** All right, and our, our last big item for this episode is, is not directly tech related, but it is, because React is more than the tech, it's the people in the community, and, you know, we, we spend time talking about conferences, but, you know, we, we get a lot of our links and keep an eye on things from, you know, historically, from Twitter, and Twitter has been where, you know, most of the web dev community has chatted and interacted online for the last several years. [52:11]
-
-And without going into, you know, some of the, the political or, you know, aspects behind it Twitter has declined a lot in the last couple of years. And there's been various waves of people saying I'm done with Twitter and I'm leaving. And the main alternative that a lot of people had gone with was Mastodon. [52:27]
-
-But Mastodon's always had sort of that, like, I'm a Linux user and I know how to set up everything myself kind of a vibe to it. And there's been an alternative to Twitter called BlueSky, which had been invite only for a while. I believe they opened up to public signups maybe about a year ago. But it always felt very niche. [52:48]
-
-And really the main thing I knew about it over the last year was that Dan Abramov, after leaving Facebook had gone over there to actually work on their web and native apps as, as his day job. Well, there has been a massive migration of the greater web development tech community from Twitter over to BlueSky really within just the last month. [53:13]
-
-And I mean, there's, there's been lots of other. Twitter communities that have moved over there black Twitter, football, Twitter, basketball, Twitter, science, Twitter, etc. And feels like, to me, like one, in the earlier era of Twitter where it was people talking rather than just bots or big businesses. And two, the, you know, just the general atmosphere and sort of discussions that are, that are happening. [53:43]
-
-So, a lot of people from the React community have signed up and started being very active over there. A number of people have specifically deleted their old Twitter accounts. As an example, Seb Markbaga from the React team. I believe actually nuked all his old tweets, and moved over to Blue Sky. I think Dan Abramov's Twitter accounts are, are, are gone at this point. [54:09]
-
-So a number of people are doing the Scorched Earth thing, and like, wiping out all their old messages, which I'll be honest, as someone who has always depended a lot on, you know, archiving the web and, you know, linking to external discussions makes me sad because I hate to see historical discussions and tweets and artifacts go away. [54:33]
-
-Having said that, as far as the community goes, I personally am feeling Like Blue Sky is probably where I'm going to put my posting energy going forward. There is, there's a lot of people there. It feels like the community is self sustaining at this point. And it's where a lot of the discussion is happening now. [54:54]
-
-## Starter packs: [ericclemmons/awesome-starter-packs](https://github.com/ericclemmons/awesome-starter-packs), [stevendborrelli/bluesky-tech-starter-packs](https://github.com/stevendborrelli/bluesky-tech-starter-packs) [Bluesky Directory](https://blueskydirectory.com/) [A complete guide to Bluesky 🦋](https://mackuba.eu/2024/02/21/bluesky-guide/)
-
-**Mark:** One nice thing is that Blue Sky has these things called starter packs, where anyone can just make a list of people they recommend on a certain topic. And it makes it very easy to follow some or all of them. At once. There are directories of starter packs out there. there's a question about whether BlueSky is kind of related to crypto related things. [55:13]
-
-## [Technical debate](https://dustycloud.org/blog/how-decentralized-is-bluesky/) over [how “decentralized”](https://whtwnd.com/bnewbold.net/3lbvbtqrg5t2t) Bluesky actually is
-
-**Mark:** there were a couple good articles talking about some of the technical implementation differences at the server level between Mastodon and BlueSky and like how actually decentralized things are. Loosely put, BlueSky is semi centralized, but it's possible to run your own server and own your own data, somehow. [55:38]
-
-So, big picture, a lot of folks who are from the React community are no longer active on Twitter, and they are now active on BlueSky. [55:47]
-
-**Carl:** Yep, can confirm. Definitely saw a massive shift in the last, like, month. It's been notable. Yeah. Definitely a lot more people posting out there, yeah. [55:57]
-
-## [Web Without Walls | React Universe Conf 2024](https://www.youtube.com/watch?v=F1sJW6nTP6E)
-
-**Mo:** because of the crypto question, if you're interested in how the BlueSky backend and like the decentralized nature of BlueSky operates, Dan Abramov did a talk at React Universe Conf about this called Web Without Walls, so I've just shared that and that gives a pretty comprehensive, it is a 40 minute talk, but that gives a pretty long and comprehensive discussion about what the nature, the decentralized nature of BlueSky is. [56:22]
-
-Quickly to add on this, actually, BlueSky is a universal React Native app. So it uses ExpoRouter and it's basically using the same code base for web and mobile, which is quite cool. And you're seeing something in production that's being used by, as we speak, 17, 18 million users now, which is pretty [56:40]
-
-**Mark:** They reached over, like, 21 million a couple days ago. okay. So I'm clearly off of the uh, off of the numbers. [56:47]
-
-There was about a week and a half where they were adding about a million people a day. [56:51]
-
-**Mo:** React Native London Conf, we actually had the and Sam from the BlueSky team. Dan now works mostly on the AT protocol stuff, but Sam works on the mobile app and the web app. They are talking about it. This was while they were getting a million per day. So it was quite cool to see them there talking about some of the stuff that they're working on. [57:06]
-
-It's a really cool team, and it's a very small team that's building this, which makes it all the more impressive. And it's super cool that they can take on the likes of a certain someone who's multi multi multi billionaire who's trying to create his own community. So, you know, pretty cool. [57:20]
-
-**Carl:** Yep, it is super cool. I could probably talk a lot more about it. I have opinions on this. And I've been thinking about the need for data portability and the benefits, the potential benefits of decentralization in the context of social media for most of a decade. I'm actually considering if I want to try and do a business effort based on the underlying data that is BlueSky. [57:45]
-
-I think that there's a lot of opportunity to iterate on the UI layer of social media. And if you have a common public data set, that's a lot easier to do. [57:53]
-
-**Mo:** on that Carl, the current BlueSky app was not the original BlueSky app Which makes it all the more interesting. So Sam created his own BlueSky client It was better than the original BlueSky app because he could use it with the AT protocol And then they just hired him and made Sam So it kind of shows that like, with this decentralized nature, anyone can make a client and sometimes it'll be better. [58:14]
-
-Kind of like the, what was that Reddit client that was better on, on iOS back in the day, but then Reddit shut it down? I forget [58:20]
-
-the name. [58:21]
-
-**Carl:** of them. Apollo? [58:22]
-
-**Mo:** Well, [58:23]
-
-**Mark:** all, all of them, yeah. [58:24]
-
-**Mo:** all of them, but Apollo. So yeah, similar story, but the decentralized nature helps with that. [58:29]
-
-**Carl:** It does. And also the BlueSky client is both a universal React native app, and it's also open source. So I've seen a bunch of React and web people, like not just posting on BlueSky, but what they're posting is their experiments building, you know, iterate changing the UI of the client they're posting from like, Oh, wouldn't it be great if we had Markdown support in BlueSky? [58:51]
-
-Look at this proof of concept that just hacked [58:52]
-
-**Mark:** We're splitting [58:53]
-
-**Carl:** a PR. [58:53]
-
-**Mark:** the notifications tab into subtabs. [58:56]
-
-**Carl:** could talk a lot more about this. We're already 10 minutes over and. Still need to do the lightning round. But yeah, okay, Blue Sky's great. Follow me. [59:03]
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Alright, lightning round, go! [59:06]
-
-## [Deno v. Oracle: Canceling the JavaScript Trademark](https://deno.com/blog/deno-v-oracle)
-
-**Carl:** Deno vs. Oracle. We mentioned this a while ago. I think two months ago. Deno opened a petition to ask Oracle to release the JavaScript trademark, and this is a follow up to that. Seems neat. Seems cool. Love it. They are like formally asking Oracle now. It has moved on from just a petition. [59:27]
-
-## [Two ways to the two Reacts](https://bobaekang.com/blog/two-ways-to-the-two-reacts)
-
-**Mark:** Next up, an author named Bobae Kang has written some good articles talking about the mental mindset of React at a very conceptual, architectural level. And has a good post called, The Two Ways to the Two Reacts, which kind of contrasts Next, where everything is about the server first, versus something like a tan stack start, which is client first, and then optionally adding in the server. [59:52]
-
-## [That's not an abstraction, that's just a layer of indirection](https://fhur.me/posts/2024/thats-not-an-abstraction)
-
-**Carl:** Another one. Great post that I love, called, That's not an abstraction, that's just a layer of indirection. [59:59]
-
-**Mark:** True that [01:00:00]
-
-**Carl:** Just generally true, like, end of, end of comment. [01:00:04]
-
-## [React Anti-Pattern: Stop Passing Setters Down the Components Tree](https://matanbobi.dev/posts/stop-passing-setter-functions-to-components)
-
-**Carl:** Related, while I was looking for, you know, doing my final pass of resources to pull in I've seen this anti pattern kind of blog post called stop "passing setters down the components tree" and, agree. [01:00:17]
-
-That is a wonderful example of not an abstraction. If you're just passing the set state setter down as a prop, you should probably do it differently. [01:00:26]
-
-**Mark:** something something dispatching actions. [01:00:29]
-
-**Carl:** Aha. What Redux? [01:00:31]
-
-## [What is HTTP/3?](https://www.cloudflare.com/learning/performance/what-is-http3/)
-
-**Carl:** Yeah, I saw a neat post from Cloudflare called, What is HTTP 3? That made me go, whoa, I didn't know there was an HTTP 3. So yeah, that exists. It's something about QUIC. And I think it's related to, like, I don't know. It sounded like the promise benefits. They sounded very familiar from what I remember reading about HTTP 2, which as far as I know have not really been realized. So Seems like a new attempt to edit something something UDP, HTTP 3. [01:01:03]
-
-## [Leaked Vercel v0 system prompts](https://old.reddit.com/r/LocalLLaMA/comments/1gwwyia/leaked_system_prompts_from_v0_vercels_ai/)
-
-**Carl:** Someone posted on Reddit that they managed to exfiltrate the system prompts for Vercel's V0 AI UI generation tool. And that's cool, that's interesting. It looks like this was not, you know, any weird black hat stuff, like they just saw something leak. and managed to continue prompting the AI until they got the full system prompt. [01:01:25]
-
-So this is output from the AI, which means it might not be real, but it does seem approximately correct. You know, Must write valid JavaScript code that uses state of the art Node. js features and follows best practices. Does not use the components. You know, so it's like massive, massive prompt. [01:01:44]
-
-I think it's an interesting, you know, peek behind the curtain. This is what the wizard looks like kind of [01:01:50]
-
-**Mark:** And today's example of why I do not want to spend the rest of my career writing prompts. I want to write code. [01:01:57]
-
-**Carl:** What's the difference? [01:01:59]
-
-## [React Scan to highlight component renders](https://react-scan.million.dev/) (by the author of Million.js), which he used to point out [Github’s code view re-rendering on every scroll](https://x.com/aidenybai/status/1859267710498263073)
-
-**Mark:** Alright, a couple perf related items. Aiden Bai, the author of the Million. js React plugin for performance, I guess. Recently put out a new tool called React Scan, which can be used to identify, you know, components that are over rendering in your app. I glanced at the source code for 30 seconds and saw that it's messing around with some of the internals of React's Fibretree, and as someone who has spent a lot of time messing around with the React code, And React's internals in the React DevTools. [01:02:28]
-
-I have a sense of how this is probably working, and I approve. In fact, he actually used it to identify that GitHub's current source file display, which is based on React, was apparently re rendering all the lines every time you scrolled. And he even managed to identify, yeah, like, here's the component. [01:02:46]
-
-And here's like the prop that needs to be memoized in order to fix that. And a couple hours later, some GitHub engineer actually fixed it. So that's a step in the right direction. [01:02:56]
-
-## [What’s Next for the React Compiler?](https://www.youtube.com/watch?v=qd5yk2gxbtg)
-
-**Mark:** On a similar note, Satya from the React team just did a, just did a, an update talk called what's next for the React compiler talking about some of the upcoming features they're thinking of working on that would hopefully further improve performance. [01:03:10]
-
-**Carl:** Very smooth. Unrelated, non smooth transition [01:03:14]
-
-## [Framer Motion spinning out as an OSS tool (Motion)](https://motion.dev/blog/framer-motion-is-now-independent-introducing-motion), and conversely [GSAP is joining WebFlow](https://gsap.com/blog/webflow-GSAP/)
-
-**Carl:** Framer Motion which is a React animation tool. Uh, Is spinning out. It is no longer under the Framer brand and it is no longer React specific. Uh, It's just an open source tool called Motion, which seems cool. Framer Motion is definitely something I've heard about a lot for doing like complex, advanced animations and whatever. [01:03:37]
-
-So yeah, it seems cool. Love it. In the inverse direction GreenSock animation platform, GSAP, was acquired by Webflow. Love it. Love seeing open source tools get money. The maintainers do a lot of work and they deserve to be compensated for it. So yeah, super happy to see that. [01:03:54]
-
-**Mark:** This feels like that, you know, that classic line about there's two ways to make money. Bundling and unbundling. [01:04:00]
-
-**Carl:** Yes. 100%. [01:04:03]
-
-**Mark:** One library leaves, another library joins. [01:04:05]
-
-**Carl:** Right, every company is either a bundling or unbundling play and here we go. Here's two examples. Well, all right Thank you everyone for joining us and sticking with us all the way to the end. We will be back Well, actually we will not be back on the last Wednesday of the month because the last Wednesday of December is Christmas and we are Not recording on Christmas. I am so sorry. I'm not sorry [01:04:26]
-
-But yeah, we so we will be back recording at the end of December probably that Monday TBD Or back in your podcast feed as soon as we can. Yeah, thanks so much, Mark. Yeah. Always [01:04:37]
-
-**Mark:** nice too be here. I'm very much looking forward to a nice long Thanksgiving break where we'll probably mostly be hacking and Redux stuff. [01:04:43]
-
-**Mo:** yeah, it's always a pleasure to be here. Um, Lovely chatting with you all and loved getting into blue sky shenanigans this month, so we'll see what next month has in store for us. [01:04:52]
-
-**Mark:** Thank you for the behind the scenes bit on that. I did not know that they'd swapped clients. [01:04:56]
-
-**Mo:** I'll hopefully share the recording once we have it live and everyone can hear the story from the comforts of their home. [01:05:02]
-
-**Carl:** Cool. All right. We gather sources from this week in React, bytes. dev, react status, Next. js Weekly, the React. js subreddit, here in Reactaflux, and directly from people publishing articles, mostly on BlueSky. If you see anything newsworthy, definitely let us know by posting it in the Tech News and Reads channel here in Reactaflux, or send me an email. [01:05:24]
-
-I will read it if you send me an email to hello at reactiflux. com yeah, I read everything. I will read it. If this is a show you get value from and want to support, best way to do so is by submitting a review and by telling your friends and coworkers about it. Help them get as smart as you are about React. [01:05:41]
-
-See you next month.
diff --git a/src/transcripts/tmir-2024-12.md b/src/transcripts/tmir-2024-12.md
deleted file mode 100644
index eac2257..0000000
--- a/src/transcripts/tmir-2024-12.md
+++ /dev/null
@@ -1,592 +0,0 @@
----
-title: "TMiR 2024-12: React 19 is here 🎉 "
-date: 2024-12-23
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:45](#sponsored-by-infinite-red)] Sponsored by [Infinite Red](https://infinite.red/)
-- [[02:46](#new-releases)] New releases
- - [[02:48](#relay-v182)] [Relay v18.2](https://github.com/facebook/relay/releases/tag/v18.2.0)
- - [[03:07](#react-admin-v54)] [React-admin v5.4](https://github.com/marmelab/react-admin/releases/tag/v5.4.0)
- - [[03:16](#preact-v1025)] [Preact v10.25](https://github.com/preactjs/preact/releases/tag/10.25.0)
- - [[05:25](#playwright-v149)] [Playwright 1.49](https://playwright.dev/docs/release-notes)
- - [[05:33](#astro-v50)] [Astro 5.0](https://astro.build/blog/astro-5/)
- - [[06:00](#radon-ide)] [Radon IDE](https://ide.swmansion.com/)
- - [[07:57](#react-19-compatibility-in-react-redux-and-redux-toolkit)] React 19 compat for [react-redux](https://github.com/reduxjs/react-redux/releases/tag/v9.2.0) and [Redux Toolkit](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.5.0)
-- [[10:37](#main-content)] Main Content
- - [[10:39](#react-19-is-finally-out-blog-post)] [React 19 is actually out](https://github.com/facebook/react/releases/tag/v19.0.0) ([blog post](https://react.dev/blog/2024/12/05/react-19))
- - [[11:16](#upgrade-guide-from-april)] [Upgrade guide from April 2024](https://19.react.dev/blog/2024/04/25/react-19-upgrade-guide)
- - [[11:31](#removed-things)] Removed things
- - [[17:07](#new-things)] New things
- - [[28:42](#ref-callbacks-react-19-and-the-compiler)] TKDodo: [Ref Callbacks, React 19, and the Compiler](https://tkdodo.eu/blog/ref-callbacks-react-19-and-the-compiler)
- - [[34:07](#react-native-screens-400)] [Introducing React Native Screens 4.0.0](https://blog.swmansion.com/introducing-react-native-screens-4-0-0-1b833ff98a55)
- - [[37:00](#react-19-and-react-native-and-pr)] [React 19 support in React Native TBD](https://github.com/react-native-community/discussions-and-proposals/issues/842#issuecomment-2527591610) (0.77/78?)
- - [[38:58](#expo-experimental-support)] [Expo has experimental support](https://x.com/Baconbrix/status/1864785257297305833)
- - [[40:37](#next-151)] [Next 15.1](https://nextjs.org/blog/next-15-1)
- - [[39:52](#nextjs-experimental-css-inlining)] [experimental: css inlining](https://github.com/vercel/next.js/pull/72195)
- - [[41:33](#react-native-fast-io)] [React Native Fast IO now in prerelease](https://github.com/callstackincubator/react-native-fast-io)
- - [[43:27](#npx-create-target)] [Create Target Widgets in Expo](https://x.com/Baconbrix/status/1868672438898455023)
-- [[44:55](#lightning-round)] ⚡ Lightning round ⚡
- - [[45:02](#react-native-demo-for-android-xr)] [React Native demo for Android XR](https://x.com/o_kwasniewski/status/1868645896239690009)
- - [[45:43](#if-not-react-then-what)] [If Not React, Then What?](https://infrequently.org/2024/11/if-not-react-then-what/)
- - [[50:14](#vitest-vs-jest)] [Vitest vs. Jest](https://www.speakeasy.com/post/vitest-vs-jest)
- - [[52:29](#aiden-bai-render-shaming-sites-while-working-on-react-scan)] [Aiden Bai “render-shaming” sites](https://x.com/aidenybai/status/1862529226727121366) while [working on React Scan](https://react-scan.com/)
- - [[55:14](#lenzs-webers-testing-libraryreact-render-stream-testing-library)] [Lenz’s Weber’s testing-library/react-render-stream-testing-library](https://github.com/testing-library/react-render-stream-testing-library)
-- [[58:13](#outro)] Outro [00:00]
-
-**Carl Vitullo:** Hello people. Thank you for joining us for the December edition, the end of 2024. this is almost this year in React, this time around. [00:08]
-
-But yeah thanks for joining for December's This Month in React, wherewe recap and digest recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:22]
-
-I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like this. [00:29]
-
-**Mark Erikson:** Hi, I'm Mark. My day job is working at Replay building a time traveling debugger for JavaScript and outside of that I do ridiculous amounts of Redux stuff. [00:39]
-
-**Mo Khazali:** And I am Mo. I head the mobile team at Theodore. I'm quite active in the React Native ecosystem and I organized the React Native London meetup and conferences. [00:47]
-
-**Carl Vitullo:** Right into it. I don't really have a job market or conferences coming up this month. I had noted that over the last, six weeks or so, the list of upcoming conferences has dwindled down to zero. I've seen them start to pop back up again. [01:01]
-
-So we've rounded that corner of people getting prepared for next year, but we'll be back with some more conferences. to notify you of next month. [01:10]
-
-**Mark Erikson:** that is that I actually sat down and started trying to do preparation for applying to conferences for next year. Some of them apparently have already closed for next year. So it's, getting ahead of the timeline process. [01:24]
-
-**Carl Vitullo:** definitely getting ahead of it. Yeah small fun news for me, I am on staff for SquiggleConf next year, so, I'll have news for that, but it's not until September, so, no rush. Highly [01:36]
-
-**Mark Erikson:** recommendd folks going to SquiggleConf. It was great. [01:40]
-
-**Carl Vitullo:** But yeah, into it. Before we get all the way into the main content a note from our sponsor. [01:45]
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl Vitullo:** We are sponsored by Infinite Red, which is an expert React Native consultancy. They've been around since 2015, so like about to be 10 years, Give it another week or so and that'll be ten years. They're owned by Jermaine Holmgren, Todd Wirth, and Gant Laborde. They're our only sponsor in part because they do so much more than most consultancies and most of the companies in the ecosystem. [02:07]
-
-there's just not many other people who operate at the same level as they do. I've been seeing their name for as long as I've been active professionally. And they're still around. They're still doing great stuff. They only do React Native. They've built over 75 apps for companies and startups. [02:21]
-
-And other than great people who've done great things for the ecosystem they're a team of about 30, mostly devs, mostly 10 years of experience or more and they work alongside your team to develop expertise at that company. So if you are spinning up a new product with React Native, or just trying to develop in house expertise with React and React Native, they can definitely help you hit the ground running. [02:44]
-
-So give them a ring. https://infinite.red/. [02:46]
-
-## New Releases
-
-**Carl Vitullo:** cool. Into some new releases. [02:48]
-
-## [Relay v18.2](https://github.com/facebook/relay/releases/tag/v18.2.0)
-
-**Carl Vitullo:** First on the list, we got Relay18. 2. They've got an experimental hook for pagination with prefetching and a at catch directive, or the catch directive has been updated so it can be used on fragments and queries and mutations. [03:03]
-
-So just better error handling, looks like. Better pagination, better error handling. [03:07]
-
-## [React Admin v5.4](https://github.com/marmelab/react-admin/releases/tag/v5.4.0)
-
-**Carl Vitullo:** There's React. Admin, 5. 4 not a lot of notes here, but it's out, it's new, if you're using it, definitely check it out. [03:16]
-
-## [Preact v10.25](https://github.com/preactjs/preact/releases/tag/10.25.0)
-
-**Carl Vitullo:** Preact has a release, 10. 25 looks like stronger types. Support for object interface as a listener, , It looks like the last couple of releases have all been pretty small. So, you know, this is just sort of Preact doing its Preact thing. I'm not really sure if they're still abiding to the original idea of like drop in replacement for React. It's, I think, especially with React server components, they've diverged a little bit. But yeah, there's still use for it for sure. [03:45]
-
-**Mark Erikson:** Yeah, I've not sat down and tried to do a strict line by line feature comparison, but I think at this point generally support most of the original hooks. But I think beyond that, , they've stopped trying to match things feature for feature. So, if you're doing relatively straightforward things, then, you may have actual compatibility, especially if you like want to use any of the new, like React 19 features or anything with the Preact bundle, then obviously they wouldn't work. [04:14]
-
-**Carl Vitullo:** right. I guess my mental model for it is this is like, if you're working in a highly constrained environment where you would still like the niceties of React, React is great, but if you're not dealing with a highly constrained environment, then might not be necessary. [04:28]
-
-**Mo Khazali:** So an interesting one, I guess an interesting use case for Preact is that it's commonly used in TV development. If you're building web apps that are going to run on TVs, where there's a very, very small amount of resources. A lot of times I've seen people use Preact. So some big names in TV apps that you might've known, which I don't know if I should mention, but you know, some big TV apps will be using Preact because a lot of the apps that you have on TVs are web apps, but they need to be constrained in the resources that they use. Mm [04:57]
-
-**Mark Erikson:** is just ironic how Web app has become the default, way to distribute things everywhere. I [05:05]
-
-**Mo Khazali:** Yeah. I mean, web is like kind of a standard almost for TV, for TVs. Like if you're building for Samsung, if you're building for LG and a bunch of other TVs, you build it using a web app, so it's pretty cool that it's standardized around that. [05:18]
-
-**Carl Vitullo:** Yeah, I talked to someone about React Native on TV too, yeah. Neat. Funny. JavaScript eating the world. [05:25]
-
-## [Playwright v1.49](https://playwright.dev/docs/release-notes)
-
-**Carl Vitullo:** There's also Playwright 1. 49. Nothing too fancy there, but pretty widely used test tool, so if you're using that, there it is. [05:33]
-
-## [Astro v5.0](https://astro.build/blog/astro-5/)
-
-**Carl Vitullo:** Astro has a major release, version 5. 0. what they're calling content layer, a new flexible and pluggable way to manage content, providing a unified type safe API to define, load, and access your content, no matter where it comes from. Sounds a lot like Gatsby's [05:48]
-
-**Mark Erikson:** was about to say that, yeah. [05:50]
-
-**Carl Vitullo:** So fair enough, you know, like that's a real need, you know, loading content from many places. Very real need. Sounds like they're not using GraphQL for it. So, different take. Fair enough. [06:00]
-
-## [Radon IDE](https://ide.swmansion.com/)
-
-**Carl Vitullo:** Yeah, there was Radon IDE. Mo, you want to talk about that? [06:03]
-
-**Mo Khazali:** it used to be called the React Native IDE, and then they rebranded for obvious branding reasons to Radon IDE, fun little Easter egg. Radon on the element lists is RN. So, anyway React Native traditionally has not had an IDE. So, you know, you build in VS Code, but a lot of the functionalities that, if you were like a Swift or an Android developer, just wouldn't be there. [06:23]
-
-And so, the folks at Software Mansion have created Radon IDE as sort of a way to make your VS Code more of a Full fledged IDE for React Native development. So it comes with a bunch of cool stuff like integrating with like your simulator and then being able to inspect elements that are on the screen and find out where they are in code, which is really, really cool. [06:42]
-
-And it's sometimes a pain in React Native breakpoint support, understanding your navigation tree. They have debugging kind of nailed down, which has been a real pain in React Native, so that's quite cool. And then another thing that was a cool little gimmicky feature, I'd say, is instant replays. [06:57]
-
-So, you know, if something happens on your simulator and you're like, oh crap, that was a bug you can click back and get, like, the last 5, 10 seconds as a replay and then save that , to a file. So some cool little utilities, I'd say that you can use when you're building React Native apps. It is a paid IDE, so You know, it starts at, it's around 20 a month per seat. [07:17]
-
-But you know, so something to consider. So they're going for the paid model as almost a paid extension onto VS code. [07:23]
-
-**Carl Vitullo:** Interesting, huh? Definitely makes sense. I mean, times I've worked with React Native, the debugging experience was among the rougher sides of it, so it makes sense to have a stronger IDE integration for debuggability things. Cool. [07:37]
-
-and I believe Software Mansion is also Nope, never mind. I was gonna say behind React Admin, but no, they're not. [07:44]
-
-But then Software Mansion does lots of stuff in the ecosystem. They are Certainly, you know, I say not many companies do as much as Infinite Red and Software Mansion is definitely in the running there. A trusted name for sure. [07:57]
-
-## React 19 compatibility in [react-redux](https://github.com/reduxjs/react-redux/releases/tag/v9.2.0) and [Redux Toolkit](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.5.0)
-
-**Carl Vitullo:** Yeah, there's also React 19 compatibility release of Redux Toolkit. [08:02]
-
-Mark, anything you want to say there? [08:04]
-
-**Mark Erikson:** yeah number one, I actually had nothing to do with the work on these. One of the other maintainers, Arya, did all the actual grunt work. in React Redux, we now test against both 18 and 19. you'd think it would be as simple as just bumping the peer dependencies list and shipping, but, you know, you actually want to test against them, you have to check any, any types related issues. [08:27]
-
-in the Redux toolkit case, it's actually caused a ripple effect where we. I merged the PR to support React 19 at, you know, at the code level. And we accidentally ended up, semi accidentally ended up bumping React 19 for our DocuSource based docs website. And that ended up breaking client side interactivity because we were still on DocuSource version two. [08:52]
-
-Which didn't correctly support React 19 somehow. So the doc site built and you could view it, but it was the static, you know, HTML only and all the client side interactivity broke, search, copy code button, everything else. On the one hand, it's like, you know, conceptually, it's simple. On the other hand, there's actually a lot of work involved. And then there's always the, you know, the unexpected ripple effects afterwards. [09:19]
-
-One other ripple effect I've seen, which I don't think we have listed directly, but I've seen a lot of people report problems with Create React App because, you know, like, beginners are trying to I assume beginners are trying to create new CRA projects. They're using, you know, It uses NPM to do the installation by default, and the CRA templates still use an existing version of React testing library that wants React 18 as a peer dependency. [09:50]
-
-And so, what happens is, NPM tries to install the packages, Also tries to install React 19, because that's the latest. And then, NPM being its helpful self, throws an error because there's a peer dependency mismatch between the installed React 19 and React Testing Library 1. 18. So, I've seen a bunch of people report, Why can't I create a new React project? [10:16]
-
-With that kind of an error in the last couple weeks. And so basically CRE's borked at this point. I [10:22]
-
-**Carl Vitullo:** That is unfortunate, yeah. But also not too surprising. I guess it's a little bit of a matter of time for that. Too [10:28]
-
-**Mark Erikson:** in theory it could be fixed with, like, someone publishing updates to the templates, but I have no idea who, if anyone, would do that. [10:35]
-
-**Carl Vitullo:** Not sure how actively maintained that is anymore. [10:37]
-
-## Main Content
-
-**Carl Vitullo:** Alright, into our main content. [10:39]
-
-## [React 19](https://github.com/facebook/react/releases/tag/v19.0.0) is finally out ([blog post](https://react.dev/blog/2024/12/05/react-19))
-
-**Carl Vitullo:** The main, main, main, main, main content of React 19 is out. It is officially released and usable. [10:47]
-
-**Mark Erikson:** Yay! [10:48]
-
-**Carl Vitullo:** Yeah, so, we're gonna spend a minute, pretty much everything in these, you know, release notes and, , overview blog posts. , there's nothing brand new, , they've been messaging this, they've been talking about it, they've been, you know, trickling out bits. over the last year and a half. So pretty much everything in this episode that we're going to discuss, at least for React 19, we've already covered in some detail in the past, but we're going to bring it all together. this is the one where we talk about it all holistically. [11:16]
-
-## [Upgrade guide from April](https://19.react.dev/blog/2024/04/25/react-19-upgrade-guide)
-
-**Carl Vitullo:** Yeah, there's a great upgrade guide from back in April. I think that was before they found the issue with Sibling. [11:23]
-
-**Mark Erikson:** Yep, because that happened at the start of June. [11:26]
-
-**Carl Vitullo:** So that was when they thought it was going out pretty, pretty shortly. Here we are eight months later, and it's out! [11:31]
-
-## Removed things
-
-**Carl Vitullo:** I'm gonna start with what they took out, because I, it's a lot of things that I, Remember using, I remember fondly. [11:38]
-
-So they removed prop types. There's no more prop types it just silently gets ignored. know, they mentioned prop types were deprecated in April 2017. So here we are seven years later, and it's finally, a deprecated feature is finally being removed. Wow. Likewise, they removed default props for functions. For class components, those still have default props, but for a function component, just give it a default argument. It'll figure it out. [12:05]
-
-Finally removed legacy context. Also, just like prop types, deprecated in October 2018. Six years later, here we are. They removed string refs, the create factory helper, because that was if you can't use JSX, you can use this instead. So yeah, everyone uses JSX. Widely supported. [12:25]
-
-**Mark Erikson:** I've used a couple different little third party helper libraries for JSX environments, but this was one that was sort of built in. [12:34]
-
-**Carl Vitullo:** Yep [12:34]
-
-some testutils, removed some deprecated DOM helpers. Or, Render and Hydrate are now removed in favor of their concurrent equivalents, the CreateRoot and HydrateRoot, as well as UnmountComponentAtNode and FindDomNode. They also removed UMD builds, Universal Module Declaration definition. [12:58]
-
-**Mark Erikson:** Definition, yeah. [12:59]
-
-**Carl Vitullo:** Yeah, that's not really been super relevant for a very long time now, not sorry to see that go. What was the, what was the main tool that used UMD? [13:09]
-
-**Mark Erikson:** Well, okay, so, recap for people. So we had, you know, we, originally we had script tags and everything's a global, and then the AMD format, Asynchronous Module Definition, was a, community created module format for use in the browser. CommonJS, loosely put, was designed for use in Node because it requires reading a file off disk synchronously. [13:31]
-
-UMD was a, someone figured out the incantation to wrap the actual code that you cared about in a complex header that basically tried to figure out, am I being loaded as a script tag, a CommonJS file, or an AMD file, so that one bundle could serve as all three formats. Simultaneously. In practice, UMD files have basically been generated for use as script tags loading off of unpackage or something like that. [14:04]
-
-**Carl Vitullo:** sure, right. Yeah, I was thinking of RequireJS with the AMD module. but yeah, now with ESM and you know, dynamic import and all the bundling tools that we have now, that's, that hasn't really been relevant in six or eight years, something like that. Or it hasn't been cutting edge, at least. Hasn't been the recommended. [14:22]
-
-But yeah, so, cool. That's all the stuff they removed. A lot of old things that haven't really, that have been deprecated for long enough that, yeah, they can go away. [14:32]
-
-**Mark Erikson:** Yeah, a couple observations there. One, I made the same decision around removing the UMD bundles from the Redux packages when I shipped RTK 2. 0 last year. The difference there is that I replaced it with an ESM format file that had all the process node env references compiled out of it. [14:52]
-
-And the React packages still don't have, quote, proper ESM support. So this, in one sense, they did actually remove something without a direct replacement for it. I've seen a number of suggestions to you that if you need to use React, like, in essence, as a script tag, then the intended replacement is to use a site called ESM. SH, which I actually looked into that a little bit, and what it does is it apparently uses ESBuild to compile various third party libraries with some sort of an ESM wrapper around them. So, even though React itself is still only shipped in common JS format, this site, this service it'll re wrap various packages with ESM around them, even if they didn't ship with it. [15:46]
-
-And then serve that up as, you know, a script tag. [15:50]
-
-**Carl Vitullo:** Interesting. Yeah, I hadn't heard of esm. sh. Looks like it's maybe sponsored by Cloudflare? It says the CDN is powered by Cloudflare. So it looks like this might be a service, you know, for the ecosystem that they're running. [16:05]
-
-**Mark Erikson:** and then the other one is, if you look at the issue with people complaining that find DOM node was about to be removed, there's, there's still a number of people who are not terribly happy about that one. they've got cases where their component structure is, it's deep enough, nested enough that they, they needed to rely on find DOM node to Find the right things to interact with and, people are not happy that it's been taken away. [16:30]
-
-**Carl Vitullo:** That seems a little strange to me. I feel like if you're in that position, there are native browser features that would do you pretty well enough, but okay, sure. I've not been in that situation, so I don't know what the weird technical trade offs involved there might be. [16:44]
-
-**Mark Erikson:** And then our favorite hidden internal non documented API, `SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED`, has been renamed to `SECRET_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE` [17:00]
-
-**Carl Vitullo:** okay, that's a little more descriptive. It's a little more actionable. I don't know of anyone who's been fired for using those, so, a little more accurate. [17:07]
-
-## New things
-
-**Carl Vitullo:** Yeah, some, getting into some new things, what they're, you know, what they've added now looks like, to me, it looks like the big stuff is mostly around transitions. my mental model for this is a little bit like, for most of React 18, we used like useState and useEffect and like a couple things around there to do basically everything. [17:31]
-
-And I think the core team identified that there was a pretty consistent and tricky use case of what happens when you need to take actions and manage state as components are, mounting and unmounting. That was definitely a little bit painful. Getting the intricate dance of as things unmount and remount, or different things swap in to replace them has definitely been awkward and tricky, especially for little things like animations. [18:02]
-
-Like If you have an animation, you can't actually unmount until the animation is completed, which may, you know, if you have a state change that would remove the component, but you want an animation to finish, then you need to like add in this like extra ceremony to keep it technically mounted while not actually in use, not actually responding to new events and things like that. So that's my mental model for what these transitions are intended to support. [18:28]
-
-**Mark Erikson:** That feels a little different than my understanding. So I've not used transitions myself, probably because I haven't been writing as much React front end stuff lately. But, like we, you know, there used to be the discussion of, you know, React 18 is going to have a concurrent mode. [18:42]
-
-eventually said, okay, like, having an entire mode isn't what we need, we're going to have concurrent features instead. So my, my understanding is that transitions are, primarily part of that concurrent feature set where you're basically telling React, we're going to start a render, but this is going to be considered low priority. [19:02]
-
-This could be interrupted. It will do the, like, you know, render a tree for five milliseconds and then pause to see if the browser has any events. So, my understanding is that transitions are primarily telling React, do some work, but this is considered a low priority render versus all the normal use state type based rendering. [19:26]
-
-**Carl Vitullo:** Interesting. Okay, fair enough. [19:28]
-
-so this is where the, you know, confusing verbiage that React introduced around like actions and how now we have many, many, many Actions is a very overloaded term in the ecosystem. [19:40]
-
-**Mark Erikson:** for Redux, another thing for MobX, now another thing for React Forms. [19:44]
-
-**Carl Vitullo:** Right, and I remember Astro had an actions thing as well a while back. So, right, there's just many, there's a lot of actions being taken. Yeah, so functions pass to start transition are actions. There's some additional hooks that are also able to tap into those, into the Actions as being used by active transitions. [20:05]
-
-So there's used action state which is a new hook to order actions inside of a transition with access to the state of the action and the pending state. So it, accepts a reducer that can call actions. So this is this smells a little bit like redux, baked into an interaction. a little bit. [20:24]
-
-As well as useOptimistic, which ties into these transitions by letting you update state while the transition is in progress, and it returns the state as well as a set function to optimistically update the state within a transition to be the expected final value. So, you know, like if you're doing optimistic updates within your UI, firing it off to persist in the back end, but immediately updating the local UI as if that has already finished. [20:51]
-
-But then gracefully handling the actual outcome of the of whatever action you took. [20:57]
-
-**Mark Erikson:** one observation here, you know, less around the behavior and more around the description. When React 19 came out a few weeks ago, the post in the JavaScript subreddit, the main discussion was basically around that paragraph and how hard it is to read for someone who isn't intimately familiar with React already. [21:19]
-
-And You know, a couple of different thoughts around this, like, one is that, you know, React has added a lot of things over time. Another is that there's been some cases where the React team has tried to turn things into proper named nouns in a way. Like, it's not just like, the useEffect hook, there are capital E effects. [21:44]
-
-And so, and so now it's not just, you know, we're going to do a low priority render, it is a capital T transition. And I, I just glanced at the docs. Like I'm, I'm looking at the use transition docs page and it does intro with use transition as a react hook that lets you render a part of the UI in the background, but like it right away starts using capital T transitions without ever defining what that word means. And there isn't really like a conceptual explainer. [22:19]
-
-So, part of it, like I realized that release notes aren't the right place to, you know, to go out and define a bunch of things, but both reading this specific paragraph, as well as trying to figure out how some of these new features are integrated into the docs and the teaching workflow, it feels like they're like, we're kind of missing a bit of a, like a conceptual explainer for some of these terms and how they relate to each other. [22:46]
-
-it's fixable, but, you know, like that, that's just one of the things that stuck out to me. [22:50]
-
-**Carl Vitullo:** Yeah, makes sense. Yeah, that's fair. it feels like an Apple type of branding. You know, it's not a, it's not an mp3 player, it's the iPod. [22:59]
-
-**Mark Erikson:** not the, just iPod, iPad, iPhone, whatever. [23:03]
-
-**Carl Vitullo:** No articles. Sure. [23:04]
-
-Yeah. other than transitions, they got the use hook, which is a little bit old hat by now, accepts a promise or context for accessing resources within render. If you give it a promise it will suspend until the Promise is resolved. [23:19]
-
-**Mark Erikson:** the naming still feels awkward, like, I don't have a better suggestion, but, in today's world, naming things for Googleability is very relevant, and giving this thing the name use is like the most un Googleable thing ever. [23:37]
-
-**Carl Vitullo:** There, right, right. [23:38]
-
-And back to my pet peeve about some of the quirks of React 19. This is the use hook, and it says right in the release notes, use can only be used in render, but can be called conditionally. And like, come on, rules of hooks, like, drilled into us repeatedly. Anything called use Use whatever. Cannot be called conditionally. [24:04]
-
-**Mark Erikson:** With the exception that you could already get away with, you could apparently already get away with calling useContext conditionally. I've never actually done it myself, but apparently, technically that worked. [24:14]
-
-**Carl Vitullo:** Interesting. I have not either. I don't think I knew that, actually. So I guess, cool, this is consistent with use context. [24:20]
-
-So clearly, I guess, it has its lineage in there. It is the way to use context. it just seems a little strange to me to, like, this seems like it's going to be a very widely used hook, and so for it to break the rules of hooks, quote unquote, quote unquote. [24:34]
-
-Feels like it adds a lot of, I don't know, weirdness, ambiguity, confusion. [24:39]
-
-**Mark Erikson:** it does I mean, I know that there's plans to hopefully expand that down the line. My, my Redux co maintainer, Lens, who also works on Apollo, has been begging for the ability to pass an observable. to use for a while now. So it's possible that that may happen at some point. It also is kind of one of those things where like they, you know, they needed the rules to be strict originally. [25:03]
-
-And now that the rules are defined and the ecosystem understands them, they can start to tweak it. But as you know, that also leads to confusion as well. [25:11]
-
-**Carl Vitullo:** Right, right. it's all a game of telephone and this adds strangeness. It adds exceptions to the rules. lots of other convenience features coming out with React 19. You can render metadata tags in components wherever, and they'll automatically get hoisted into the head section, which is great. [25:28]
-
-I, I think I said it when this was first announced, but like, the, React Helmet was, as far as I know, the main way to really interact with head in React, and it was just like not very consistently maintained. I kept running into, like, I feel like every time I used it, every time I was spinning up a new project and trying to interact with the head, it's like, oh, React Helmet, cool. [25:48]
-
-Pull that in. Oh, this does not behave in the way I expect in these many different ways. And so then what I thought was just gonna be a trivial, it works. Was not, was not trivial, did not work. So love that. Love to see that. [26:03]
-
-But yeah, RIP React Helmet. That was, I remember, I remember when that was released. I remember that was announced and going like, what the hell? NFL is releasing an open source project at the bleeding edge and they called it React Helmet. This is perfect. Protects the [26:18]
-
-**Mark Erikson:** one, definitely one of the best project names ever. [26:21]
-
-**Carl Vitullo:** Yes, absolutely. So, RIP to NFL's React Helmet. another convenience feature, you can use async scripts. [26:30]
-
-You can render them anywhere in the component tree, and they will be, React will handle the ordering and deduplication of them, which is neat. Yeah, deduplicating async scripts sounds That makes me a little scared. But yeah, I guess it shouldn't be too bad as long as you're not doing any weird stuff with the file name. Yeah, likewise, more head stuff. React 19 will ensure style sheets are inserted into the head before revealing the content of a suspense boundary. So, you know, predictable, Easily anticipated ways of interacting with the head. Also some initial load optimizations. Initial load and transition, page transition optimizations around pre init, pre load, pre fetch DNS, pre connect. [27:14]
-
-These are all, like, kind of low level optimizations that used to be exposed at the level of, like, script tags, where you could say, you could communicate to browser what level of initial connection to try and get ahead of. You know, because it takes a little bit of time to look up the DNS, to connect to the server, to open, you know, begin streaming data. [27:34]
-
-So, it sometimes introduced extra latency that was undesirable. So you can now, in React 19, have a little bit more control over how external assets get loaded in that way. You know, just even like pre fetch DNS and pre connect. Will cut the latency a decent amount. I've used those things in the past. It's a pretty nitty gritty performance optimization, but yeah, definitely important that we can now do that. That's nice. [28:00]
-
-Yeah, a big one, a nice one. One less use case for Refs can now return cleanup functions, so that's definitely big. That's definitely good. I think it had definitely been a pattern to, like, do a useEffect, to do things like setting up event listeners, and that was a little bit weird. [28:19]
-
-I don't know, it's just a little funky, because they're, they're clearly tied to the DOM. It's associated with a DOM node so having to do it in useEffect introduced, it just, extended that distance between the code that was being run and what it relied on. You had to do extra weird deduplication stuff because it was an effect. [28:36]
-
-So now, because refs support cleanup functions, it's just a little bit closer, you can keep it a little more self contained. [28:42]
-
-## [Ref Callbacks, React 19, and the Compiler](https://tkdodo.eu/blog/ref-callbacks-react-19-and-the-compiler)
-
-**Mark Erikson:** Yeah, and there's a, there's a good post from Dominic Torfmeister, the, you know, maintainer of React Query, he had written about dealing with, dealing with refs a couple years ago. And so he kind of revisited that topic and showed that, you know, hey, there, here's, here's cases when, You know, now you can do things like setting up a resize observer in a ref, and you don't even have to have a useEffect plus a useRef to manage that. [29:10]
-
-**Carl Vitullo:** another very small convenience feature, you can now render just context instead of context. provider. That's nice, that's good. Very small, very petite. React 19 also has support for custom elements, i. e. web components. For the first time in React's history we discussed that at much greater length in previous episodes. I don't know if there's that much more to say, web components. If you're using web components, cool, great, now you can use React as well. [29:36]
-
-**Mark Erikson:** it's still really complicated You know, a lot of it boiled down to, like, React can, in theory, render any arbitrary HTML tag. React have a hard coded list of element types that it knows are part of HTML. But, React 18 and earlier had issues with properly passing complicated props into web components. [30:02]
-
-And that's because of the whole difference between HTML attributes versus JavaScript DOM node properties, which I still only partly understand myself. But think part of the issue was React wanted to pass in. properties, but a lot of these things expected attributes instead. [30:23]
-
-And so there, there was a mismatch in, in how things would get passed down as well as issues with setting up event listeners as well. And from what I've read, went into the, the mile long discussion threads, they're like the web component spec does not necessarily define how a given web component receives this. [30:42]
-
-it's It's implementation dependent on a per web component basis. So it's literally how it's almost as if every single web component author, as they write that component decides, how is this component going to get its data or trigger its events? And so, different libraries, different wrappers, different authors take different approaches. [31:09]
-
-And so, part of the issue with implementing this was trying to find a reasonable set of heuristics that would work most of the time, and also allow React to pass this web component in framework compat spec that had been put out there. And after React 19 came out, I saw a couple more people posting complaints that certain scenarios didn't work right. [31:34]
-
-Like, I guess if you define a function field on your web component class. And then you also try to pass in a prop with that name. React will happily overwrite the function because it just assigns the field name, but ultimately it seems like web component authoring is a very inconsistent and per component basis kind of a thing. [32:00]
-
-And there's a lot of edge cases with the interop and so they're never going to make everybody happy. [32:06]
-
-**Carl Vitullo:** Awesome. Sounds great. Yeah, the finer points of attributes versus properties is, my eyes began glazing over at that point. [32:13]
-
-**Mark Erikson:** Yep. [32:14]
-
-**Carl Vitullo:** Yeah okay. a convenience that got me a little excited in React 19. Hydration errors will now be collapsed into a single error, even if there are multiple mismatches. [32:23]
-
-Like, nice. [32:26]
-
-Just [32:26]
-
-Right, just having my console be blasted with, like, 30 stack traces because, like, obviously this hydration did not match is, yeah, very happy to have that just be didn't work, not here's every point at which hydration did not work. That's nice. [32:44]
-
-So kind of subtle, I don't quite, I don't understand the, the precise details here, but errors in render are not rethread. If they're not caught by an error boundary, they're reported to window report error, not logged with console error. There's also, they've introduced onUncaughtError and onCaughtError methods to the create root and hydrate root. APIs to customize how those errors get handled. So I guess they're kind of stepping back from like automatically handling every error and logging it to the console to saying, if you have a boundary, we'll log it. [33:18]
-
-If you don't have a boundary, you can configure how it gets handled on your own. [33:23]
-
-**Mark Erikson:** You know, that's interesting. This, this might be the kind of thing that libraries might end up caring about more, but I, I actually feel like I need to go back to those React 19 compat PRs that I did not write myself, but I did merge. Because I, I think we had some tests where we had, like, assertions that, like, if an error happens while doing, like, a React Redux render or something, that errors would either get thrown of rendering or get logged somewhere. [33:50]
-
-So now I'm actually curious how we, how those PRs ended up handling them. [33:54]
-
-**Carl Vitullo:** Sure. Right. You can never know what you don't know. obviously that's the majority of our, I think that's the majority of what we wanted to get to today. [34:01]
-
-But uh, yeah, Mo, tell us about React Native screens. Hang [34:07]
-
-## [React Native Screens 4.0.0](https://blog.swmansion.com/introducing-react-native-screens-4-0-0-1b833ff98a55)
-
-**Mo Khazali:** Major version of the React Native Screens library, version 4. 0, came out. So, you, as a React Native developer, probably don't interact directly with React Native Screens. If you use React Navigation or ExpoRouter, which uses React Navigation under the hood, you will be using React Native Screens. [34:23]
-
-React Native Screens is native layer implementation of screens on iOS and Android for your app so that you're not creating JavaScript views and not handling the view transitions on the JavaScript layer, rather you handle them on the native layer. And so a few updates here that will likely be picked up by the React Navigation libraries. [34:43]
-
-React Navigation and ExpoRouter libraries. One is that they're adding more support for the forum sheet presentation. So this is kind of the bottom sheet interaction that you'll be used to on phones. And previously it wasn't supported on Android. And now there's an Android support. It was supported on iOS but you had a limitation. [35:02]
-
-So if you ever played around with those bottom sheets, you can kind of pin them to certain points, and they'll kind of stick. They call these detents, I think. [35:10]
-
-**Carl Vitullo:** This is like the sort of mobile version of a modal, where it's like an overlay that you slide around. [35:16]
-
-**Mo Khazali:** Yeah, exactly, those ones. So the ones that come from the bottom, and, you know, you've got a little modal, and the screen behind it is still kind of visible, and you can adjust how big the modal is. they call them sheets, I guess, in mobile development. Modals, when you're talking about in a mobile navigation world, it's the ones that kind of fully cover the screen. [35:35]
-
-Not the ones that can partially cover the screen. So you've got some of these pop ups that fully cover the screen. Sometimes you'll see them on, like, login pages or something like that. And so, a lot of these sheets, you can kind of control where they are, so you can pin them to different locations. [35:47]
-
-So, with this new API, you are able to, on iOS, set as many points to kind of have these snap points. And on Android, I believe, there's three different snap points. That you can define. So this is kind of sticking true to the iOS and Android APIs on the native layer. They've also made some minor improvements on animations when it comes to iOS to make it a bit more smooth. [36:11]
-
-And one of the other things that they've done is that if you've got a screen that's now detached, from the main tree of your navigation, so it's no longer rendered. You can preload these screens, and so this will kind of happen through React Navigation so that if you know a user is going to go onto a specific screen, you preload it, render everything, create the native views, and so you won't have this delay in getting the screen loaded onto the app, which is quite a nice feature, and I think this is great. [36:39]
-
-Quite important for optimizing your app and making sure that everything is smooth, quick, and snappy. So those are kind of some of the things. You won't really be implementing any of these yourself. You'll probably use React Navigation, so keep an eye out on the React Navigation docs and the ExpoRouter docs, because some of this stuff will be landing. [36:56]
-
-Some of it's already been landed as well. [36:58]
-
-**Carl Vitullo:** Nice. Makes sense. Yeah. [37:00]
-
-## [React 19 and React Native](https://react.dev/blog/2024/12/05/react-19), and [PR](https://github.com/react-native-community/discussions-and-proposals/issues/842#issuecomment-2527591610)
-
-**Carl Vitullo:** Tell us about React 19 and React Native. [37:04]
-
-**Mo Khazali:** so taking a step back, React Native just released the new architecture. So that was the, big release that they've been kind of working on for many, many years. And so, I think they're going through a stabilization period right now. They are I think waiting to make sure that everything is smooth, stable with the last two versions of React Native that have been released. [37:26]
-
-I suspect this will be some point in early to mid 2025, sometime in the next two releases of React Native, where they'll actually support React 19. I know that there's been some issues with supporting React 19 anyway with React Native. I think there's been some internal testing, but they haven't conclusively made sure that everything is working as expected. [37:46]
-
-So, I think there's just going to be some delay on this. But I think it's not something that we haven't seen in the React Native ecosystem. There's sometimes a lag with these major version upgrades anyway. [37:55]
-
-**Carl Vitullo:** Yeah, that makes sense. And especially, I'm just, I'm kind of connecting dots of what you were just talking about with like React Native screens, adding support for like preloading. And that sounds adjacent to, like, some of the use optimistic or use transition hooks that have popped up now as, like, first class APIs. [38:15]
-
-So I wonder if that's maybe some of the tension there, is that now that it's a first class API, a feature of React 19, React Native needs to figure out how to implement it [38:28]
-
-**Mo Khazali:** Because it's not just JavaScript there's also an element of, you know, how do you map those to native functionalities, right? So if you're transitioning to allow a native component to be rendered, well, how do you handle that on the native layer? [38:41]
-
-So there's a lot more support that needs to happen, it's not just the browser. But you need to also make sure that at least iOS and Android support those features, not to even get into the whole out of tree platform shenanigans where you've got a bunch of other platforms that are maintained by the community and they also need to support it. [38:56]
-
-So yeah, it has a long tail. [38:58]
-
-## [Expo experimental support](https://x.com/Baconbrix/status/1864785257297305833)
-
-**Carl Vitullo:** But it looks like Expo has experimental support. [39:03]
-
-**Mo Khazali:** this is probably one of the musings of Evan Bacon over a weekend just hacking away, but yeah, there's a lot of these sort of, like, Expo kind of goes ahead of the curve with some of these things and tries to push the React Native ecosystem forward, which is great so, I'm not surprised that this is supported with some sort of flag in Expo. [39:21]
-
-So yeah, it's the experiments. reactCanary, setting that to true. In Expo SDK 52, it works. These are very much experimental. Don't try these for any production apps, but it's just kind of trying to see what the effects would be ahead of time. I mean, we've seen this pattern, like Expo supporting RSCs with the bundler, with some custom changes to the bundler ahead of time before it's even, you know, supported, in any capacity officially by Meta. [39:46]
-
-So, it's cool to see it, but it's still a long way to go for production apps. [39:51]
-
-**Carl Vitullo:** Sure, yeah. Makes sense. [39:52]
-
-## [Next.js experimental CSS inlining](https://github.com/vercel/next.js/pull/72195)
-
-**Carl Vitullo:** Well, I have a very, very small bit of React, er, a very small bit of Next. js news. They've added a experimental CSS inlining feature. And now, if you are generating, you know, if you're, you're, if you're pulling in CSS styles, instead of it being compiled into a CSS asset and Loaded with a link tag. You can configure next so that it will just inline those styles in a style tag Yeah, this takes advantage of the React 19 precedence in deduping You know, CSS features. [40:28]
-
-So I guess this is enabled by React 19 But yeah, definitely pretty small, relatively minor performance optimization. [40:37]
-
-## [Next 15.1](https://nextjs.org/blog/next-15-1)
-
-**Carl Vitullo:** guess a larger bit of news. Thank you, Mark. There's also Next 15. 1 that's out Yeah, last episode we talked about how Next 15 was stable and now they're up to 15. 1 [40:50]
-
-**Mark Erikson:** The biggest one here is that because React 19 is now actually out, they've switched to using React 19 everywhere. So actually, it's kind of funny because for now they're on React 19 stable, but there's a good chance that they will continue using those canary releases in future versions of Next down the road. [41:10]
-
-So this may actually be only a temporary problem. you know, period of time where they're, where the version of React they use actually exactly matches the stable version. [41:20]
-
-**Carl Vitullo:** Right. I didn't know they have, you know, One of the headers on the 15. 1 release notes is React 19, parentheses stable. So yeah, right. They've been on Canary for forever. [41:33]
-
-## [React Native Fast IO](https://github.com/callstackincubator/react-native-fast-io)
-
-**Mo Khazali:** Cool. So, next up we've got the pre release version of React Native Fast. io out. So this was sort of first showcased at React Native London Con in November. So this is made by Mike Grabowski, who is the co founder and CTO of Callstack. And so it's basically built on top of the Nitro modules package that we've seen and talked about in the past few months that's been made by Mark Roussevy. [41:59]
-
-And so it's a way to create native libraries that are super, super fast to execute. And so, Mike from Callstack has been working on trying to get some of the I. O. functionality in React Native implemented with Nitro modules so that they're as fast as possible. And hence, React Native Fast I. O. [42:18]
-
-So he started off with WebSockets but he eventually wants to target WebSockets, Fetch, FileSystem APIs, Blobs, and Streams. And so the whole idea is you can use the WebSockets or the Fetch that comes from React Native Fast. io and in theory it should beat all of the benchmarks for any other implementations of I. [42:36]
-
-O. related functionality in React Native. So this isn't anywhere near production. But it's something that you can give it a shot and play around with and just run some benchmarks on and eventually at some point it should land and it could be quite interesting to see what that means for the whole ecosystem because these are quite core functionalities, right? [42:54]
-
-**Carl Vitullo:** Yeah. I uh, definitely pretty low level. If that gets much faster, that enables a lot of other interesting experiments. [43:00]
-
-**Mo Khazali:** Exactly. And I think The, one of the things with this is that it's one of the, like, first implementations of an actual library with Nitro modules. So, so far Nitro modules have been very hypothetical in terms of what you can achieve. Mark's been using it on a few of his libraries, but nobody else, sort of, in the community has adopted it to this degree to build an actual package. [43:20]
-
-So, it can really start to push a lot of people towards Nitro modules when they're building native dependencies. [43:25]
-
-**Carl Vitullo:** Neat. Cool. [43:27]
-
-## [NPX Create Target](https://x.com/Baconbrix/status/1868672438898455023)
-
-**Mo Khazali:** In other news, and we talked about Expo's random demos that they release with some cool features and going ahead of the curve. Evan Bacon in a very truly Evan Bacon fashion has been working on a new CLI tool specifically for iOS called NPX Create Target. And so the whole idea with this is, is that there are certain parts of an iOS app that you can't build with React Native and you need to build in the native layer. [43:51]
-
-So what are those? Those are things like widgets, live activities. Lockscreen widgets, and there's a whole host of things that are not part of, like, the main app that you use, but are almost extensions on top of on top of your main app. And so, the whole idea with this is, is that it's been quite difficult to get these up and running with React Native so far, because you need to go into Xcode, add those, widgets and then kind of do the binding between your React Native app and the widgets that you create or those targets that you create. [44:19]
-
-And so the whole idea with this is is that it's a simple NPX command that you can run and you choose the type of target or widget that you want to use and then it kind of bootstraps all the code, links it to your React Native app, has a way for them to communicate between each other, and all you need to do is just write the Swift code to basically implement that on the native layer. [44:37]
-
-And so it's a much easier way to add these targets to your existing application to your existing Expo application. So it's a pretty cool thing. It's, it's it's nothing that you couldn't do before, but it obviously was a lot more work. And this just makes it significantly easier to get up and running with those features to make your app feel even more interconnected within the OS, within the person's phone. [44:55]
-
-I [44:55]
-
-## Lightning round
-
-**Carl Vitullo:** Alright, that's all of our main content. Let's jump into the lightning round. Moe, you're up again. [45:02]
-
-## [React Native demo for Android XR](https://x.com/o_kwasniewski/status/1868645896239690009)
-
-**Mo Khazali:** So, quick thing. Android released some new features. Cool mixed reality stuff Android XR. So there's a whole release on that. And of course someone had to create a demo of React Native running on it. So there's a quick tweet showing React Native running on Android XR. [45:17]
-
-We'll see how this expands, but it's always within days that someone creates a demo of React Native running on any new platform or any new APIs. [45:25]
-
-**Carl Vitullo:** Nice, cool. Okay, so this looks kind of like Android version of Apple Vision. [45:30]
-
-**Mo Khazali:** Yeah, it seems like it's a competitor to Vision OS, basically but Android's really trying to standardize the way that XR goggles are built with Android. [45:41]
-
-**Carl Vitullo:** right, cool. Good luck. [45:43]
-
-## [If Not React, Then What?](https://infrequently.org/2024/11/if-not-react-then-what/)
-
-**Mark Erikson:** Another post from Alex Russell was going around in the last few weeks. Alex generally is on a one man crusade against client side JavaScript and the React ecosystem in particular. This one was titled, If Not React, Then What? And most of it boils down to most sites shouldn't be single page applications. [46:04]
-
-Most sites shouldn't be using react. I guess there's other client side libraries that you can use, but generally they shouldn't be client side in the first place, which is frankly, like, like my own summary is actually a, like a reasonable stance to take. And if he phrased it that way, he would probably have more people listening to him. [46:23]
-
-But the vitriol and the vehement and the anger that he puts into these posts, even when he has valid points, makes it really hard for people to actually listen to what he's saying. [46:33]
-
-**Carl Vitullo:** Sure. I haven't read this in depth yet. I would like to but yeah, he like very strongly states that, let me pull a direct quote. " React is a legacy technology, but it continues to appear in Greenfield projects. In short, nobody should start a new project in the 2020s based on React. Full stop." That is uh, not something I'd agree with. Strongly stated. [46:57]
-
-**Mo Khazali:** reading the About Me page, and Alex Russell, I didn't know this, works at Microsoft. And he's a partner project manager on the Edge team. [47:05]
-
-**Mark Erikson:** he was previously at Google and he also basically invented like two thirds of what we now know as the web component spec as well. I. [47:11]
-
-**Mo Khazali:** Yeah, I wonder how Microsoft feels about these stances. all of these posts are, these are not my, you know, employer's opinions. These are endorsed by no one except me. [47:22]
-
-**Carl Vitullo:** I randomly, I was just trying to refresh my memory on who Alex Russell is. Cause I, I recognize his name, I know his Twitter handle is slightly late, and I have seen him for years, as like, somebody in the ecosystem. So I was just trying to refresh my memory more specifically, and I quickly found A random Hacker News comment that describes him as early member of the Chrome team, three time elected member to the W3C from 2013 to 2019, and representative of TC39 from 2006 to 2017. [47:52]
-
-this is from two years ago, and it says, Lately, he's been very critical of single page apps in React, going as far as to call the past ten years a lost decade. guess he's been on this for a minute, but has some, like, Drawing deep credentials to, on, you know, web technologies. So, interesting. [48:08]
-
-Curious. But if he's on, if he's coming at this from a web components perspective, that adds a lot of color to my understanding of the situation and his arguments. [48:19]
-
-**Mark Erikson:** my take on it is like, he, he absolutely has the technical credentials to back up most of his opinions as well as statistics on like how bad, I mean, like many website bundles actually are like, he's not wrong about that, but he then goes from that to say that anyone using react is doing it wrong. Basically any single page app is wrong and the people who push react have been doing so with malicious intent from day one. Which is way over the line. [48:49]
-
-**Carl Vitullo:** Yeah, I'm gonna, I would disagree strongly with that. I feel like in, I feel like I can understand his macro perspective there, cause like, I have used a lot of like news websites that are like clearly using React very badly. It has been, it has been put in a lot of contexts that I don't know that it was the best tool for the job, because it was a popular tool that was easy to hire for. So I guess I can empathize with the perspective a little bit, but, I don't know, the nuance there, I feel like there's more nuance [49:18]
-
-**Mark Erikson:** no nuance, and that's the issue. [49:20]
-
-**Mo Khazali:** Well, just to go a little bit more into this. I just read his Rebuttal to if someone says, well, what about React Native? And I'm just going to read this verbatim. "React Native is a good way to make slow apps that require constant hand tuning and an excellent way to make a terrible website. It has also been abandoned by its poster child, [referring to Airbnb]". And then he goes on to suggest that you should use Capacitor and Cordova instead. Cordova is The poster child of making awful applications. [49:47]
-
-**Carl Vitullo:** everything he just said applies way more to Cordova than to React Native. [49:51]
-
-**Mo Khazali:** yeah, his, he seems to be pushing you to make web apps and use those on mobile with responsiveness. So I've at least on the native side, I think his opinions are incredibly unvalidated. He's probably has more credentials on the web, but that is a bizarre take to then go and say Capacitor and Cordova are better options. [50:10]
-
-**Carl Vitullo:** Oh yeah, yeah, definitely agree with that one. [50:13]
-
-**Mark Erikson:** Moving right along. [50:14]
-
-## [Vitest vs. Jest](https://www.speakeasy.com/post/vitest-vs-jest)
-
-**Carl Vitullo:** Great post titled Vitest vs Jest. I think this is Very needed. I think this is a great post. Just it starts with like just like a raw feature comparison comparing what does Vitest support and what does Jest support. And just goes into a bit of like a oral history of like, why did Jest appear? Why did it succeed? always appreciate some oral histories. I think it's really useful to understand how things came about. [50:41]
-
-Like I remember when ultimately Jest succeeded because it got open sourced. Also by Meta right, like within six months after React came on the scene. So like people had started using React, people had started using all of the everything Facebook was putting out, Facebook at the time was putting out React and Flux and then like, Oh sure, Jest. [51:06]
-
-So it definitely got a huge, huge, huge boost by the timing of its open source release. I never really got a ton of professional experience using other tools like Mocha or Chai and all of those. I don't really know what the comparison is from my perspective like functionality wise they all seemed about the same and But I don't know I used Jest because I was early in my career and I didn't have opinions and it seemed popular So why not? [51:31]
-
-Yeah, over the years definitely it became It, it became not a preferred tool of mine because I found myself needing to maintain parallel bundle configurations for, a production build, and then for Jest, and then for like end to end testing, and then, and so it's just like, it just became like one more target that made upgrading instance, like, new webpack or new, I don't know, any new core technology, I found updating Jest was just a huge pain in the butt. [52:03]
-
-So it became not my preferred tool for that reason. And Vitest seems to be a little bit better about that, but But I have not had that same professional experience of, I'm on a team with 15 other engineers trying to update a core technology without breaking everything or stopping work. So that's really the litmus test for me on a tool like Vitest or Jest. [52:23]
-
-And I've had negative experiences with Jest and no experiences with Vitest. Ergo, Vitest is obviously better. But [52:29]
-
-## [Aiden Bai “render-shaming” sites](https://x.com/aidenybai/status/1862529226727121366) while [working on React Scan](https://react-scan.com/)
-
-**Mark Erikson:** there's a young engineer named Aiden Bai, who I, I think is, I could be wrong on this, might not even be 20 years old yet. But he's the creator of a tool called Million. js, which is kind of like a, almost like a proto version of React compiler where you could isolate parts of your component tree and it would optimize like the text updates in there. [52:50]
-
-And he's since gone on and been working on a bunch of other React related performance tools. Some of them have been branded with Million as well. I think there's a like a million lint and like a a million VS code extension that try to highlight some React performance issues. But he's working on a tool called React Scan, and it loosely put pretends to be the React DevTools in the browser in order to get access to React saying, I just got done rendering, here's the new component tree. [53:24]
-
-And he's been advertising this with a tweets that are kind of render shaming. Sites like he did one where he pointed out that like typing in a search input in Twitter Makes basically every component on the page Rerender and those naturally got a lot of circulation and stuff going around So he called out a number of sites that way And it's, it's both really, really clever marketing, as well as, you know, a bit of an example of ways that React does not necessarily lead to a pit of success kind of a thing you know, just because of, you know, React's default render behavior. [54:07]
-
-I've very briefly dug, you know, dug into the source code just enough to see that that's how it's hooking into React's updates. I've not tried to go through the code and see how the rest of the analysis is implemented. But this feels very similar in spirit to some of the work I've done at Replay over the last couple years. [54:24]
-
-So I, I always approve of people digging inside React's internals in ways they're not supposed to. [54:28]
-
-**Carl Vitullo:** Yeah, I small reaction. I saw one of the site, one of the render shaming tweets he put out was about GitHub. [54:35]
-
-**Mark Erikson:** The list view that is used to render source code was re rendering all the list items every time you scrolled. And so, scrolling performance was relatively bad. And he tweeted it, tagged someone at GitHub, and they did actually fix it like a day or so later. [54:53]
-
-**Carl Vitullo:** yeah, that's worse than I was thinking. I thought it was uh, something about typing, but scrolling, ooh, rendering every line of code on a diff while scrolling. Yeah. That's, that's, that's not going to do good things. [55:03]
-
-**Mark Erikson:** it's virtualized, so like it wasn't rendering like 50, 000 lines of code at once. But even just what was on screen could be, you know, relatively slow. [55:14]
-
-## Lenz’s Weber’s [testing-library/react-render-stream-testing-library](https://github.com/testing-library/react-render-stream-testing-library)
-
-**Mark Erikson:** And then the last one plug for a friend uh, Lenz Weber is co maintainer of Redux Toolkit and works on Apollo Client. And he'd been putting in a ton of work to try to write tests for Apollo in conjunction with React Suspense and ran into all kinds of problems. And this is one of those things that is, it's a library maintainer problem. [55:36]
-
-This is not an app developer. But, you know, like we've, we've had lots of tests in the React Redux code base over the years that say, okay, I'm going to render a component, do an update. And I expect React will have re rendered this many times in the process. And as React's internal behavior changed over time, we kept having to go in and tweak those assertions, you know, like when, when React 18 switched to batching by default, like the number of render counts changed in a lot of our tests. [56:07]
-
-And in fact, at one point we had to say, like, if it's 17, then we expect that this test will render four times. If it's 18, we expect it'll render three times, et cetera. So like, this is not the kind of thing that an application test would need to care about, but a lot of library tests needed to care about this thing. [56:26]
-
-And, you know, we always implemented it with basically. You know, having a, having a variable outside a component, the components defined inside the test and you count how many times it rendered. So in the process of working on the test for Apollo, Lens came up with a new approach, which he's called the React Render Stream Testing Library, and it actually got included in the testing library. [56:52]
-
-organization, part of the, like the RTL group that we all know and love. And this takes a different approach where it actually kind of buffers up all the renders that occurred. And then you can say, okay, give me almost like a wrapper for the contents of the next render in the sequence. [57:12]
-
-And then let me write assertions against the contents of the DOM as it happened in that render. So you're still doing the usual testing library approach of, like, let me look for a button, let me, you know, assert that certain text is on screen. But rather than kind of conceptually testing it against a, quote, live version of the DOM, You're asking for a series of snapshots of it, and this library does the work of kind of buffering those, and then you can just sort of take the next one, do some assertions, take the next one, do some assertions. [57:47]
-
-I actually tried making use of this in a test with Redux Toolkit the other day. And it required a bit of a mental model shift to try to use it that way, but it actually ended up being much more consistent, and like, I didn't have to write any waitfors, because it wasn't timing based anymore. So, again, if you're not writing libraries, you probably don't need this, but if you are writing libraries, this might be useful. [58:13]
-
-## Outro
-
-**Carl Vitullo:** All right. That's all the news we have for you this month, this year. Woo! Thanks for joining us. We will be back next month on the last Wednesday of January here in the live stage, or back in your podcast feed just as soon as we can. [58:28]
-
-**Mark Erikson:** And Mo was worried we wouldn't have enough to talk about. [58:31]
-
-**Carl Vitullo:** Haha, it's gonna be a short episode. [58:32]
-
-Well, [58:33]
-
-**Mark Erikson:** all. Yeah look forward to talking with you folks next month, and enjoy the break, everybody. [58:39]
-
-**Carl Vitullo:** yeah. Happy holidays. [58:40]
-
-**Mo Khazali:** Always a pleasure. Hope everyone has a lovely time off, and enjoys the festivities, and uh, looking forward to what next year's got in store for us. [58:48]
-
-**Carl Vitullo:** 2024 was good to you. Good to you all. It was good to me. It's been a, it's been a weird year for me, but a good one. Yeah, end of episode. Personal updates. this has been the first year of my life when I accepted for myself that I'm queer. I'm not straight. It's been a good year for me, I hope it's been a good year for you. [59:06]
-
-Thanks so much. We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, our React. js, the subreddit, here in Reactaflux, and direct from those publishing articles. If you see anything newsworthy, definitely let us know at hello at reactaflux. [59:21]
-
-com. Bye! I read every email that comes in, even the spam, so send me an email. I'll check it out. If this is a show you get value from and want to support, the best way you can do so is by submitting a review wherever you listen, and by telling your friends and co workers about it. Cheers. Thanks for listening.
diff --git a/src/transcripts/tmir-2025-01.md b/src/transcripts/tmir-2025-01.md
deleted file mode 100644
index 1cd2ba5..0000000
--- a/src/transcripts/tmir-2025-01.md
+++ /dev/null
@@ -1,542 +0,0 @@
----
-title: "TMiR 2025-01: Movement on CRA, Redwood.js dead?"
-date: 2025-01-29
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:29](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- [[03:09](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://docs.google.com/document/d/1V-wc6YRW7TeKSREPxREI70vfIyA0vVmVbYKr6sU2jZc/edit)
-- [[04:17](#new-releases)] New releases
- - [[04:26](#react-query-563)] [React query 5.63](https://bsky.app/profile/tkdodo.eu/post/3lfaeteulds2i)
- - [[04:45](#docusaurus-37)] [Docusaurus 3.7](https://docusaurus.io/blog/releases/3.7)
- - [[05:17](#react-native-audio-api)] [React Native Audio API](https://blog.swmansion.com/hello-react-native-audio-api-bb0f10347211)
-- [[07:30](#main-content)] Main Content
- - [[07:30](#cra-deprecation-react-team-against-recommending-vite)] [CRA deprecation, React team against recommending Vite](https://bsky.app/profile/acemarke.dev/post/3lggg6pk7g22o)
- - [[09:28](#dans-why-cra-exists-dont-use-it-possible-future-options-comment-from-2023)] [Dan’s “why CRA exists, don’t use it, possible future options” comment from 2023](https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741)
- - [Dan: “turn CRA into a launcher” still on the table, but stuck](https://bsky.app/profile/danabra.mov/post/3lggs4ql72k2w)
- - [“CRA is broken and not deprecated” umbrella issue](https://github.com/facebook/create-react-app/issues/17004)
- - [Ricky merged the PRs, working on legacy docs SEO redirects](https://github.com/facebook/create-react-app/issues/17004#issuecomment-2620263140)
- - [[37:46](#revealed-reacts-experimental-animations-api--motion-blog)] [Revealed: React's experimental animations API - Motion Blog](https://motion.dev/blog/reacts-experimental-view-transition-api)
- - [[37:59](#main-pr)] [Main PR](https://github.com/facebook/react/pull/31975)
- - [[40:17](#static-hermes-update)] [Static hermes update](https://x.com/tmikov/status/1869945330638442651)
- - [[42:38](#react-native-hosting-with-eas)] [React Native Hosting with EAS](https://expo.dev/blog/expo-announces-eas-hosting-service)
- - [[44:44](#everything-you-need-to-know-about-nodejs-type-stripping)] [Everything You Need to Know About Node.js Type Stripping](https://satanacchio.hashnode.dev/everything-you-need-to-know-about-nodejs-type-stripping)
- - [[47:57](#composable-caching-with-nextjs)] [Composable Caching with Next.js](https://nextjs.org/blog/composable-caching)
- - [[51:56](#thoughts-on-what-rsc-means-for-spas)] [Thoughts on What RSC Means for SPAs](https://blog.axlight.com/posts/thoughts-on-what-rsc-means-for-spas/)
- - [[52:44](#chromes-2024-recap-for-devs)] [Chrome's 2024 recap for devs](https://developer.chrome.com/blog/chrome-2024-recap)
- - [[53:39](#shoutout-webstatusdev)] Shoutout [webstatus.dev](https://webstatus.dev/)
-- [[54:26](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[54:26](#redwoodjs-shutting-down)] Redwood.js 😱
- - [[55:59](#a-checklist-for-your-tsconfigjson)] [A checklist for your `tsconfig.json`](https://2ality.com/2025/01/tsconfig-json.html)
- - [[56:30](#recoil-repo-archived)] [Recoil repo archived](https://x.com/dai_shi/status/1875910305802514649)
- - [[57:47](#bun-firstclass-support-for-s3)] [Bun: first-class support for s3](https://bsky.app/profile/bun.sh/post/3legdozw3nc2p)
- - [[58:48](#interpolate-auto-height-for-animations)] [Interpolate `auto` height for animations](https://bsky.app/profile/joshwcomeau.com/post/3lf5zwg2ths22)
- - [[59:47](#free-javascript-oracle-not-voluntarily-releasing)] [Free javascript; Oracle not voluntarily releasing](https://bsky.app/profile/deno.land/post/3lfapjn7gns2w)
- - [[01:00:31](#understanding-react-server-components--tony-alicea)] [Understanding React Server Components | Tony Alicea](https://tonyalicea.dev/blog/understanding-react-server-components/)
- - [[01:02:13](#follow-us-on-bluesky)] [Follow us on Bluesky!](https://bsky.app/profile/tmir.reactiflux.com/post/3lc6ziumnq22p)
-
-**Carl:** Hello! Thank you everyone for joining us for the January edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux. The place for professional React developers. We are supported by Infinite Red, a consultancy that exclusively works with React Native. [00:19]
-
-I am Carl, I am a staff product developer and freelance community manager here at Reactiflux, where I run community programs like this and Star Helpers and some other stuff, and just generally try to keep the community humming nice and smoothly. [00:32]
-
-**Mark:** Hi, I'm Mark. My day job is working at Replay, where we're building a time traveling debugger for JavaScript and other fancy uses of introspecting application behavior. Outside of that, I do Redux, and I apparently argue with people about the right way to use React. [00:48]
-
-**Mo:** And I am Mo. I head the mobile team at Theodo. And I am involved in the React Native ecosystem, where I frequently jet off to some of the different conferences, meeting some lovely folks in the community and help organize the London community with the React Native London Conference and the meetups that we run monthly. [01:04]
-
-Yeah, very excited to be here, as every month. [01:07]
-
-**Carl:** Yeah I feel like There has been some stuff, just not like a wide range of libraries and whatever, but yeah, I think we'll definitely find a lot to talk about. Uh, Actually this month, Mark is not only a pundit, but active participant in the ecosystem, [01:24]
-
-**Mark:** am making the news. [01:26]
-
-**Carl:** making the news and then reporting on it. Cool.
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Yeah, let's start off briefly, overview of the job market tech. Man, you know what? I thought it was like recovering a little bit, but I'm looking at the metrics and like, okay, the FRED data, some Federal Reserve data source, it only shows job postings to Indeed, so like that's a pretty narrow slice. [01:50]
-
-Who knows what other activity is happening, but like, presumably they're publishing it because they believe it's a reasonable proxy for the broader market. And it keeps going down! It just keeps going down. I don't know, hopefully that's just an indicative of Indeed, like, not being the place where people hire software engineers, which, you know It's probably, likely true? [02:09]
-
-I don't know. But yeah, it's just lower and lower every month it looks like. It's lower in January than it was in December, and December was lower than November. So, that's not great. Layoffs are also trending down. There's not as many people getting laid off anymore. But there was a bit of a spike in January this month. [02:26]
-
-Looks like 5, 200 people were laid off from 20 companies. Yeah, that's fewer companies than December, but like twice as many people, so that sucks. I think a lot of those are coming from a small number of companies. Yeah, Meta laid off 3, 600 employees two weeks ago. So yeah, job market is maybe not gonna be As improving as quickly as I hoped it might from some early indications towards the end of the year and in the first couple weeks of 2025. [03:00]
-
-But conferences still don't have a ton of queued up ones. I think people are still getting their ducks in a row with planning and scheduling for 2025.
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl:** like I said in the open, we are sponsored by Infinite Red. They are currently our only sponsor. But we don't communicate with them about, like, editorial or anything like that. They gave us some money, and I shot them out. Woo! They are an expert React Native consultancy that's been around since 2015. [03:22]
-
-And they're our only sponsor in part because so few companies do as much as they do for the ecosystem. They, put out a newsletter. They host the largest React Native podcast. They run, I think, the largest US based conference. Specifically on React Native and generally they are just like great people who do good work. [03:44]
-
-They have built over 75 apps for companies ranging from startups to the biggest in the world and they generally work with your team to help you develop expertise, not just build the app for you and get out of there. So yeah, if your company is looking at starting up a new React Native project, definitely consider reaching out to them. [04:02]
-
-They are infinite. red. [04:04]
-
-**Mark:** I've met Jamon a couple times and seen some of his discussions online. He's a good guy. [04:09]
-
-**Carl:** I mean, they're our sponsor because I met him at a conference and just sort of chatted idly about what we were doing. He was like, yeah, that sounds good. Let's talk more. great dude.
-
-## New Releases
-
-**Carl:** into some new releases. Not a ton this month, in part because I've been distracted with some other projects and have not paid quite as close an eye as I would have preferred.
-
-## [React query 5.63](https://bsky.app/profile/tkdodo.eu/post/3lfaeteulds2i)
-
-**Carl:** But React Query put out 5.63 looks like, you know, I mean, it's a 63 point release, like there's, it's gonna be some fine tune and revisions, but uh, looks like they added an ability to unsubscribe an observer from the cache which should help in React Native. So, yeah, PanStack, great, great resource.
-
-## [Docusaurus 3.7](https://docusaurus.io/blog/releases/3.7)
-
-**Carl:** Docusaurus also put out version 3.7, so if you're using that, consider upgrading. Great [04:52]
-
-**Mark:** actually updated the Redux Toolkit doc site from DocuSource 2 to DocuSource 3, and it's definitely some improvements. thing I think was in 3.6, previously they've always used Webpack as their build tool. And with 3.6, they introduced an experimental option to use the RS Pack, Webpack re implementation in Rust for faster builds, and it definitely did seem to speed things up,
-
-## [React Native Audio API](https://blog.swmansion.com/hello-react-native-audio-api-bb0f10347211)
-
-**Carl:** Yeah Mo, you want to talk about the React Native Audio API? [05:20]
-
-**Mo:** so this one is really, Interesting. Because for the longest time, obviously, like, the Web Audio API is incredibly mature. It gives you so much functionality, you can make some really cool stuff with it. So if you're trying to do anything with audio, like, I don't know get information about your audio sources, run it through effects Be able to generate audio graphs, you know, things like showing wave, waveforms and stuff like that. On the React Native side, it's a lot more difficult to achieve similar things because you're dealing with native level APIs, they're not standardized and you may end up having to just write some code yourself to be able to do that on the native layer per platform and to try to achieve similar things. [06:07]
-
-So, the example that is quite common is generating wavelengths. I've tried to generate wavelengths on the client for certain files. Not a very easy task to do, it turns out. So some functionalities like that are just so much easier to do on the web. [06:21]
-
-And so the folks at Software Mansion have recently started building out A React Native audio API, and so the whole idea is, let's try to bring over the Web Audio API, which is incredibly mature, very standardized, and high performance, into the React Native scene, so that you can have the same levels on control and playback as you do on the web, and standardize it. [06:46]
-
-It fits quite well into the sort of universal app story where you want to standardize around web APIs because they're mature and allow native developers to ingest the same ones but delegate the implementation and the runtime of those APIs onto the native layer. So this is quite cool. It's still early days. [07:06]
-
-And it's, it's not, you know, ready and it doesn't have all the bells and whistles that you have in the web, but it is a very, very good step in the right direction. And so I, I'm super excited to see how this evolves over the next few months and years, I guess. [07:21]
-
-## Main content
-
-**Carl:** Cool our main content. So this is our first episode of the year. I was thinking that we'd discuss a little bit about what we'd like to see, but,
-
-## [CRA deprecation, React team against recommending Vite](https://bsky.app/profile/acemarke.dev/post/3lggg6pk7g22o)
-
-**Carl:** Mark, you want to start us off talking about Create React App and we we can springboard from there [07:37]
-
-**Mark:** gladly. So, React 19 came out last month, in the culmination of, couple plus years worth of technical effort from the React team, and we've all been very excited about that huge jump forward for the ecosystem. Thanks But it also had some unexpected technical side effects, and the technical problems have then spiraled into drama. [07:57]
-
-And I actually happen to be squarely in the middle of that. So I'm going to be describing things, I am both a participant and an observer. And we'll go from there. So Create React App came out in late 2016, early 2017, and it was designed for a couple of purposes. The whole point was make it really easy to start a new React project with a good default build config out of the box with one command. [08:23]
-
-You know, previously you had to spend a lot of time configuring yourself. And so part of this was to make it easy for beginners to start a new project and be able to focus on trying and learning and using React. And it also, you know, had, you know, was perfectly fine for actual production projects as well. [08:42]
-
-And so Create React App succeeded wonderfully. It became the default standard, you know, set up for tutorials. Lots of companies used it for actual apps, but over the next few years, you know, other build tools came out, things that were faster than Webpack CRA was having trouble kind of keeping up with, you know, some of the maintenance demands. [09:03]
-
-They were very slow, you know, dealing with the, the Webpack upgrade. [09:07]
-
-**Carl:** Right [09:07]
-
-**Mark:** And by like 2022, Create React App was actually kind of basically unmaintained. Now, even though it was in the Facebook GitHub org the last people maintaining it were not even Facebook employees or, or part of the React team. And it basically like a ton of issues had piled up.
-
-## [Dan’s “why CRA exists, don’t use it, possible future options” comment from 2023](https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741)
-
-**Mark:** So in, I think it was early 23 Theo Brown put up an issue saying we should mark Create React App as deprecated and we should point people to use Vite instead. That's it. And, you know, he, the issue got, you know, went viral and it collected tons and tons of thumbs ups and eventually Dan Abramov responded and wrote a massive detailed reply saying, saying, here's why Create React App exists. [09:55]
-
-We see that the ecosystem has changed. We've also been changing some of our thinking about the right ways to use React. And here's five possible futures for the Create React app tool, ranging from kill it completely to, modernize it, to change the CLI tool to be a multi launcher that would end up pointing to, creating a next app or uh, remix app or something. And that's where things kind of left off. You know, lots of people read that comment. The community just sort of absorbed the knowledge that you're not supposed to use Create React App anymore and everyone asking questions about how should I start a project was told, use something else. But Create React App itself never formally got deprecated. [10:40]
-
-The CLI still ran, nothing changed in the docs, Dan's extensive comment was never turned into actual documentation. And so that brings us forward to, you know, this last month. React 19 came out and Create React App promptly started breaking. The Create React App CLI has always tried to install the latest version of React into whichever template package you specify. [11:06]
-
-And the templates have some dependencies, including tools for linting and testing. And it turns out that the React Testing Library version had a peer dependency on React 18, and suddenly CRA was trying to install React 19. And since NPM throws errors anytime there's a peer dependency mismatch, what happened was you try to run create react app my app, and it promptly throws errors saying I was told to look for React 18, but there's React 19, these don't match. And so over the last month, I've seen dozens of people file issues or You know, Reddit threads or comments saying, Hey, I'm trying to start a new React project, and it throws an error. And a lot of these people are beginners. And so I was seeing so many of these threads pop up that I began to make a couple comments on social media saying, Hey, like, no one owns Create React App at this point. [12:01]
-
-It's unmaintained. This is bad for the ecosystem. It's bad for beginners who don't know they're not supposed to be using it and are just trying to follow a tutorial. And that's actually part of the problem, is that a lot of older tutorials They'll reference create React app and no one's telling them you should be using something different. [12:21]
-
-And if it breaks, they don't know what their other options are. [12:24]
-
-**Carl:** the SEO for it is so strong. Like if you're just, if you don't know anything about the ecosystem and it's like, I want to make a new React app, like you search new React app or something like that in Google, [12:35]
-
-80 percent odd, you find Create React App. [12:38]
-
-**Mark:** I literally Googled that, and the, the top hit is the actual CRA docs. The third hit is the legacy React installation page. And like the second hit is the current React installation page. So I started griping about this on social media. And the second or third tweet that I put up about this actually is what really spawned the discussion and drama. [13:03]
-
-So that thread went viral and took off. And a couple members of the React team, Dan and Ricky, began to reply. And Overall, my main goal was, I felt that number one, somebody, aka the React team, that had the right project permissions, should fix the Create React App templates so that it doesn't error when you create a new project. [13:26]
-
-It's still a tool, it should work, it shouldn't break. But, both the CLI tool and the docs should be updated to say, Create React App is deprecated, don't use this anymore. Like, yeah, it'll work, but you shouldn't use this. Thanks. And that they should, you know, hopefully point to like some kind of a migration guide, like here's what you should use instead. that's where we also start to run into other problems. if we point people to the existing new React docs, start a new project page, that's the one that specifically says you should only use React with a framework like Next, Remix, Gatsby of all things, and Expo. And it actually specifically argues against trying to do things yourself. Now, the most direct equivalent to Create React App today is Vite. And Vite works great. And in fact, Vite is being used by millions of React projects. But the React docs don't actually list Vite as a real option. [14:30]
-
-They mention it a couple times. And it's buried down in, at the bottom of the React docs. Can I use React without a framework section where they sort of grudgingly say, well, if your project doesn't fit any of these constraints, I guess you can use something like Vite which I'll get, I'll touch on that a bit further later. So to me, the right thing to do to get people off Create React App is to have Vite listed prominently on the setup page because it's the direct equivalent and say, this is good for someone who's beginning or has, you know, just doesn't need all the bells and whistles that come with a framework. [15:10]
-
-So that turned into more arguments. The React team still insists that you should only ever use a framework and have generally refused to list Vite in that page. And a lot of other people besides myself find this to be a pretty ridiculous stance. So the good news is after, you know, a lot of debate online this weekend, the React team did say we will update Create React App so it doesn't break. [15:35]
-
-Mark it is deprecated, and we will do some work to change the SEO on the old docs and the CRA docs to try to point them to the current SEO. Setup page. And so I've, I've seen Ricky doing the work in the PRs on that in the last couple of days. So it's been a lot of frustration and debate. [15:53]
-
-The good news is the immediate problem appears to be getting solved. Doesn't touch on changing the docs to list Vite as a valid option. And then that ties into all kinds of other general complaints about how the React team runs things. So that's the general state of play. [16:12]
-
-**Carl:** It does seem like the, this stems a lot of the worst of the bleeding, like, you know, the SEO issue of if you're trying to enter the React ecosystem as a newbie, then those PRs will address the worst of that in that, like, I think they realized that there was like a real legacy issue, legacy docs issue in that like, The SEO for those links are so good that it ranks above the current docs in a lot of cases. [16:36]
-
-So I'm glad to see them looking at ways to manage that SEO, but like, I've also managed documentation sites before and done SEO for them, like it legitimately took six months for those SEO changes to like fully settle down. So it's just going to take a minute for these changes to fully be reflected in search results too. [16:57]
-
-**Mark:** You know, I don't blame them for you know, taking a few weeks for this, you know, Create React App breakage to bubble up. You know, like I said, no one had really been maintaining Create React App through 21 and 22. It's been widely considered deprecated and no one's owning it for the last couple years. [17:18]
-
-So, You know, no one's really looking over at the repo issues. I saw the issues being filed in the actual React repo and on Reddit and Reactaflux. But I can understand that, like, it wasn't bubbling up and, really catching their attention. So, I'm not upset that it, you know, it took me, you know, raising this issue and pushing it and, kind of stirring up the drama in order to get their attention. [17:43]
-
-I can also understand that, you know, with React 19 having just come out, like, they're still kind of trying to catch their breath from that. That said, like, obviously I'm overly invested in this because I was the one trying to make the point that it needed to be fixed, but I've spent so much of my time as a maintainer Trying to think about how beginners will, read my documentation or, Trying to make things easy to use or answering questions from beginners And so I, you know, I care deeply about, giving beginners a good, you know, Startup path. [18:12]
-
-And so it kind of bothers me that, they didn't jump on this as, Oh yeah, this is an obvious problem and we should do something about it right away. [18:20]
-
-**Carl:** yeah, Dan gave such a long and thoughtful reply, acknowledging the issues, but then, yeah, it's, it sat for two years. [18:27]
-
-**Mark:** There was kind of like, like I said, kind of the spinoff of the, you know, CRA is broken part is that the insistence on using a framework has become. Such a stubborn ideological stance, and I understand the reasons why the React team feels it's better for people to use a framework, it's coming with all the pieces out of the box, those pieces are pre assembled to, you know, be guaranteed to try to work the right way You know, the React team has kind of shifted gears to where they feel that, you know, server rendering is an important capability, routing is an important capability. [19:03]
-
-You know, obviously it ties into their vision for React server components, which can only work with a framework for technical reasons. for years I've felt that there is a pretty big disconnect between how the React team thinks that people are using React, And how people actually are using React in practice. [19:23]
-
-And there's, there's, there's a lot of reasons for this. I experienced it myself with Redux. Like I, I don't even use Redux to build apps anymore. And so I'm, as a maintainer, I'm having to just kind of like take cues from issues people file or, well, a lot of people have asked for this feature. [19:39]
-
-I think it's worth it. But it's, it's reactive and I'm sort of over in my corner doing things almost by guessing. So there is always that danger when you spend all your time building a library of not seeing and feeling the way it is to use something in the real world. And, you know, part of the issue is that the way Meta, Facebook uses React, is different from how everyone else does, just because Meta has all their own infrastructure for routing and serving and bundling and everything else. [20:08]
-
-They don't need lots of third party libraries for that. But, given how huge React is, It is at least the job of the maintainers to be aware that it's used in a lot of other ways. And even if you don't necessarily want to focus on all those use cases, you still need to be able to be aware and support that. [20:31]
-
-And a lot of the React team's decisions and statements over the last few years have been basically very focused on we sort of assume that everyone who's using React is using it to build a server rendered, data fetched, routed CRUD app. And we don't really seem to care about any of the other ways people use React. [20:53]
-
-**Carl:** Yeah, having been paying attention to React since it was like, since relatively shortly after it was open sourced, there has always been a pretty clear, I don't know, like they came at developing React with a philosophy for how to do web development. [21:09]
-
-And I think that like over the last 10 years of React, 12 years of React. I think that has borne out more often than it's, there's always been people saying like, What the, what the heck are you doing? Like, this doesn't make any sense, this isn't, how I want to use it, you should be doing this. [21:25]
-
-And I have seen many cases where the naysayers were wrong. I am sympathetic to the, You know what the vibes that are I'm getting from the core team of like, this is our lane. Like, we understand what we're doing here. Like, "you'll understand one day" kind of vibe. but I, I think there are a couple of, I don't know, I guess they, they've always had this ideological stance that they were sort of. [21:49]
-
-Putting out into the world like people talk about react brain and you have to like change the way you think in order to Really effectively develop with react and like coming out of react you have to sort of Drift back into a different way of thinking to use other tools again And I think that's real and I do think that it's One of the great things about React, but I don't know It's uh, we're definitely in a kind of weird spot here where I guess some of the specifics about it have gotten a little bit Divorced from the everyday usage. [22:20]
-
-Yeah [22:20]
-
-**Mark:** Yeah let me give three reasonably specific anecdotes that kind of tie into this. So, when the new React docs came out a couple years ago that's when they, they really made that shift from, you know, you, you can use create React app, the old React doc said, if you're learning or building a single page app, use CRA. [22:42]
-
-If you need server rendering, use Next. If it's a static site, use Gatsby. The new doc site, when it came out, said, use a framework. Next, Remix, Expo. And then it had the Can I use React without a framework section with five paragraphs of explaining why they think it's a bad idea. And the original screen at the end of it was, if you feel you need to do something else go ahead, we can't stop you. Now they've said they didn't mean that to be sarcastic, But everybody I've talked to have said, like, that is just like the most passive aggressive, insulting way to phrase it. And it took over a year for them to finally rewrite that paragraph to take out the passive aggressiveness. [23:27]
-
-And, like, that is not a good way to treat your user base. Especially when using React without a framework had been the default way to do it. And it's what you were recommending in your docs up until you flipped the switch on the new ones. Second example, so the suspense gate thing last year, you know, the React team had made a code change to alter how nested suspense components in as siblings would load from in, in parallel to in sequence. [23:58]
-
-and you know, they had a good reason to make a change. You know, they were trying to make facebook. com a little bit faster and I'm not expecting them to have gone out and like, you know, run hundreds of example apps just to see if this might alter anything. But it Later on, in some of the discussions, they were saying, Well, I mean, you really shouldn't even be doing this pattern anyway. [24:18]
-
-Like, if you want good perf, you should always be hoisting your data fetching up to a route or a page for best performance. Which, okay, like, it's a valid thing to do to improve perf, but it turns out that, like, React 3 Fiber people were using suspense to load 3D assets. And it's still a va and like, even ignoring that, nested suspense is a valid thing to do. [24:44]
-
-So, it's a, you know, second example of, well, we, we really assume that you're gonna be doing things this one way that we recommend, and Not really following through of, but are there other people doing things a different way? And as a last example I even just ran some quick searches on GitHub in the last couple days, just querying for package.json [25:05]
-
-files that reference either Next, the Vite React plugin, or the React scripts package from create react app. And it's, it's napkin math, I think it might have actually been, like, CRA was 1.9, Vite was 1.1, and Next was 1.5. And so, mathematically, that means that there's 3 million projects that are You know, a basic single page app, and only one and a half million projects that are on Next. So the single page apps actually outweigh Next by two to one. [25:38]
-
-And yet, the React docs don't even list Vite fairly compared to the other options. So it feels like they're cutting out an awful lot of the ecosystem compared to how people actually use it. [25:50]
-
-**Carl:** Right, right. And like the, the recommendations they make around like best practices for performance and like whatever around loading and how to use suspense. Like, those are great. That's true. I don't disagree with it, but I also like most of my projects are like solo things. Or, you know, I'm collaborating with like one or two other people. [26:10]
-
-And I'll skip a lot of that a lot of the time just because it introduces complexity. Like it's, it's an extra couple of days of like introducing scaffolding and, piping data around. And like then, especially when I'm just like iterating and exploring and I don't really know if I'm even following the right path yet. [26:28]
-
-Like, I don't, I don't want to do that yet. I'll do it later once I know it's good, and I do want to care about performance, but that to say that like, I think a lot of development ignores those best practices because it is, because ignoring it is the right trade off for that bit of work, you know, the available, you know, it If you end up not shipping because you tried to follow all the best practices and blew out your budget for time or money or, you know, motivation from your contributors, then like, that's not great either. [27:00]
-
-Yeah. [27:01]
-
-**Mark:** So, in general I've seen a lot of frustrations about how, you know, the communications has been handled, about the React team's resistance to, you know, just adding a couple paragraphs in a header to one docs page. And I have a lot of thoughts about it that I'm working on writing a blog post on that will hopefully come out in the near future. [27:19]
-
-But that's, that's been a pain point for myself, for a number of other prominent figures in the React community that I've talked to, and for a lot of other people that I've talked to as well. [27:31]
-
-**Carl:** Well, so maybe, maybe let's try and bring it back. what do you think good relations from the core team to the ecosystem might look like over the next year? Like, just blank slate, what is, what does a good, I don't know, comms program look like? [27:48]
-
-**Mark:** Yeah, so, I've actually, you know, mentioned this in a couple of my tweets, if I could magic wand things, we've fixed the CRA brokenness, that's great, we're marking as deprecated, great. You know, for CRA specifically, I would get the docs updated, so the CRA docs have migration guides, and they point to the setup page. [28:07]
-
-And the setup page lists Vite as both a learning tool and a, if you just want a simple project. Because that both handles the, I'm a beginner, I just want to start a new project so I can write some components and learn aspect. But it also recognizes the breadth of ways that React is actually used. [28:28]
-
-In practice, whether it's, I'm spinning up just a little sample project or, you know, an enterprise that has like a Python or Java backend and can't even run Node on their server. But just like, we're not even giving you details, we're just saying here's a valid way to do it and here's a pointer to where to go. [28:45]
-
-Another thing that the React team has struggled with is general public updates on where they're going. And there's a lot of reasons for this. The React team has historically not had, a real full time paid devrel person. Historically, Dan Abramov did a lot of that work in an unofficial sense. [29:04]
-
-Like, he was the public face of the React team, but it's just because he spent all his time answering questions on his, of his own volition. they've hired a couple devrels or announced that they had a devrel a couple times, and then those people always seem to just sort of and not really do anything within a couple months. I think Matt Carroll has been in that position for a while, but in all honesty, I couldn't tell you much of what he's done. I know I've seen some people say they've had conversations with him, [29:36]
-
-**Carl:** I do know he put a lot of energy into the, into React Conf last year. But obviously a conference is not a like complete developer relations strategy, I don't know. But yeah, just to say, I do know that was a big effort. [29:48]
-
-**Mark:** And especially since, you know, Dan shifted over and both left Twitter publicly and actually started working at Blue Sky. It generally feels like there's no one from the React team who is actively reaching out and looking to be involved in conversations. [30:06]
-
-flip side of this is that a lot of that has come from Vercel and Next. [30:12]
-
-You know, Lee Robinson has been incredibly active in terms of actually looking for discussion threads around Next. And popping in, but also the Vercel dev rels have written some really good content explaining things like how, you know, how does, you know, suspense or concurrent rendering work and, you know, how to use some of the new React 19 features. [30:35]
-
-And some of that is in the next documentation and it's not at all in the core React docs. Some of it's on the Vercel or Next blogs and it's not in the core docs. Thanks. And frankly, a lot of that information feels like it should be in the core docs. Like, you know, the core docs describe the use server and use client directives. [30:59]
-
-And they, they talk about some of where and, and when to use it, but they don't have any information on what are server components, how do they fit into the React architecture conceptually, when and why would I want to use server components in general? And so that, that feels like a documentation gap there. [31:21]
-
-**Carl:** Yeah. [31:24]
-
-**Mark:** docs are wonderful. Dan poured his heart and soul into this tutorial. It is excellently crafted, comprehensive. In page sandboxes, all kinds of other things, it's great, but if you were to follow the tutorial linearly, you get past the couple of, like, nah, never use useEffect pages, then it just sort of ends. [31:47]
-
-And there's no direction on how to take this sort of theoretical knowledge of I'm writing some components in these sandboxes, and How to actually apply that to starting a real project. So like at a minimum I'd like to see a page at the end that says, Okay, you've finished the tutorial, great. Here are some active next steps. [32:08]
-
-Here's how you can start a project. And by the way, if you're like using Next or Vite or Remix. Here's how you would write components in the file structure in those actually give people a pathway. And then the last thing I'm, I guess, one other thing I'd like to see is more active communication on the blog. [32:28]
-
-Historically, they've done announcement posts for big releases. And then they basically do like one. What we're working on post a year. That's about it. I realize that they, you know, they do a lot of prototyping. They're very reluctant to, you know, give early details on prototypes because everyone gets overexcited about them. [32:51]
-
-And, You know, also this goes back to the, you know, the lack of a formal devrel person to have the capacity to do the writing. But, you know, even, and just, you know, some more frequent updates on what direction we're headed, or the kinds of things we're experimenting with. Even if you have to plaster it with, with very loud, this is a proof of concept. [33:11]
-
-Labels you know, the idea of using the TC39 stages as descriptions of how far along things are has been kicked around a few times. But you just, some sense of like, what is the roadmap and where are we actually going would be nice. [33:28]
-
-**Carl:** Or like, heck, like you said, there's lots of great blog posts that people like Lee Robb or other, you know, Next and Vercel people are putting out. Like, just reposting those to the official blog would probably be pretty good. [33:41]
-
-**Mark:** another one that I saw was the uh, I think, Some of the, you know, the team folks did a lot of great work in fleshing out the API references in the docs. And the only indication that anything had changed was they made a post in the discussions section of a, of a working group repo. No one is reading that. [34:03]
-
-Put up a blog post saying, Hey, we added five new docs pages covering these topics. Like that is a thing worth announcing. [34:10]
-
-**Carl:** Absolutely, 100%. Yeah. Well, one other thing I want to chime in on. On the documentation side of things too, I just saw, I just caught some discussion from people looking to make their own frameworks, were expressing frustration, like, you know, they were reading the docs and it says like, this is best left to the framework authors, and they're like, that's me! [34:30]
-
-How do I do this? yeah, [34:32]
-
-**Mark:** or library authors. Yeah. [34:34]
-
-**Carl:** right, and you know, then I'm seeing people talk about like, oh yeah, I was, I, I spent a week, three weeks, months reverse engineering this and understanding it so that I could write something on top of it, and it's like, yeah, you know what, that's, that's a pretty big documentation gap if like a half dozen people are all reverse engineering stuff in order to do what is being advised, you know, they're trying to own it, [34:58]
-
-**Mark:** seen a couple framework author kind of behind the scenes discussion groups and there, there is chatter back and forth and asking questions, but I mean, again, like a lot of that stuff would have been nice to see covered in public documentation in the first place. [35:15]
-
-**Carl:** I guess maybe, maybe to close this discussion out, this is all like refinement. Like, I also want to highlight that as far as frameworks for building web applications, The React documentation is absolutely world class, and like, you compare it to its peers in the, you know, ecosystem, and like, both what it's trying to do and how well it communicates it to someone trying to learn is actually quite good. [35:45]
-
-in my opinion, like, I, I think that there are many things that it does really, really, really effectively, and As, you know, pundits opining, we're seeking out the rough edges to focus on. I do just want to bring that in. [35:59]
-
-**Mark:** I have huge respect for the React team. I have a very good understanding of the constraints that they deal with, both from having watched and talked to And then, you know, as a, as a maintainer of a widely used library myself, I, I totally understand, like, I just don't have time to sit down and document this. [36:15]
-
-it's both the, the success that they've had, And the work that they've put in that makes a lot of these gaps and pain points all the more frustrating. And so it's not that they're doing a bad job. It's that the pain points really stand out. [36:32]
-
-And a lot of them feel like self inflicted wounds that could have been addressed fairly simply. [36:37]
-
-**Carl:** And, perhaps, because it has had such a vibrant, thriving ecosystem for so long, and so many phenomenal, wonderful, generous, talented individuals who are filling some of these gaps, Like, now that the momentum, now that some of the heat has gone out, like, you know, there was a, there was probably a five year span where a lot of the hype in tech was focused on React and now, you know, then there was like a kind of like, ooh, should we focus on Web 3? [37:08]
-
-Like, ooh, is blockchain interesting? And there's like, no, no, no, actually, no. And now, like, that, that laser has Fully focused away from tech like React and more onto AI things. So I think that a lot of those individuals who were driven and talented and motivated and ended up filling those gaps are now doing other things. [37:27]
-
-makes sense and it's fair, but it means that those gaps are not getting filled anymore. [37:31]
-
-**Mark:** I have a lot more thoughts on this topic. I will not go through them here. However, I am planning to put up a very, very, very long blog post explaining a lot of this stuff hopefully within the next few days. [37:43]
-
-**Carl:** I've read half of it. It's good. Okay. Moving on.
-
-## [Revealed: React's experimental animations API - Motion Blog](https://motion.dev/blog/
-
-**Carl:** Somewhat small. We can maybe do this in lightning round, but too late. speaking of new developments in React, there is an experimental animations API taking advantage of the view transition, platform API On the web.
-
-## [Main PR](https://github.com/facebook/react/pull/31975)
-
-**Carl:** Uh, It's currently unstable. It looks like it's going to be a view transition component that also comes with a little bit of ceremony around how to set state in order to make the transition aware that a change happened. [38:12]
-
-But seems cool. I don't know if view transitions look great. And being able to easily tap into them when you're doing your react logic. Definitely here for that. Looks great. [38:23]
-
-**Mark:** I still don't even know exactly what view transitions even are. I've been too occupied to have a chance to read about or learn them. Having said that, this also does feel like kind of a big deal. People have been griping about the lack of real animation support in React itself for years. There's been lots of, you know, community packages, Motion and React Transition Group, and A whole bunch of other things. [38:48]
-
-and they've said that they wanted to get around to it eventually, but it really needed to be integrated into concurrent rendering behavior because you got to track multiple copies of the tree at once. So this does actually feel like a pretty big step forward. [39:01]
-
-**Carl:** Yeah, and I used like React Motion Cheng Lou's library from many, many years ago which was great. I found that really cool and really powerful. I did some really fun, exciting things with that. the single most fun thing I did with that, I did a spotlight. Like onboarding tour for an app I built, where I did a custom SVG to cut a hole out of a, like, transparent, translucent overlay. [39:26]
-
-And then I used React animation to, like, animate it, and so it would, like, do a, like, little springy animation around. And, like, it was performant. It was fast. It took me, like, three hours to do. So for me, user space implementations like that were like, cool, great, this is solved, I don't need to do this. [39:44]
-
-And I don't need React to be more aware of this because this works great for me. I think that's part of the reason why they haven't brought anything in before this. And I think now there has been more of a, I don't know, general understanding of how animation should work at a platform level. [40:01]
-
-And so They've been brought in as platform features to do like flip animations. First, last, interpolate, play. And so I think that's what view transitions are, but I'm in the same boat. I've read about them. I have not actually put them to practice in any real project yet.
-
-## [Static hermes update](https://x.com/tmikov/status/1869945330638442651)
-
-**Mo:** Let's jump into Static Hermes, because I think that one's quite interesting. So, we've talked about Static Hermes over the last few months a few times, but right before Christmas there was an update that went on by Tzvetan, who's basically really the person who's leading the efforts as far as I know, at Meta, and so people are kind of asking the question, like, when is Static Hermes actually going to come out? [40:38]
-
-Because we saw it like years ago. It was super exciting. When is it coming out? And I think we got the first glimpses of hope in there. In the sense that in 2025, so in 2024, they say, next year they want to start to make it an opt in branch and maybe towards the end of the year, later in the year, at some point, make it the default React Native Engine. [40:57]
-
-And one of the biggest hurdles that they face, which they seemingly have overcame now, is that There wasn't good support for un typed JavaScript and obviously there's gonna be a lot of un typed JavaScript in the world. Like the whole premise of static Hermes is that you use the types within TypeScript to be able to compile better typed code at a c plus plus level. And so this is a big step and it was one of the hardest sort of hurdles that they had and they've compared the performance. with different benchmarks and seemingly they are doing, you know, somewhere to the ranges of 20 to 60 percent better with a bunch of different benchmarks that they're trying. [41:36]
-
-So it's quite cool and we'll see how it evolves, but I guess it's a very exciting update, whether or not that stays in practice and it'll be, you know, available at some point in 2025, we'll see, but you know, first glimpses of a supposed Timeline of delivery. So we'll, we'll see how that plays out. [41:53]
-
-**Carl:** Yeah, definitely makes sense that untyped JavaScript is a major hurdle, like, yeah, it's a JIT compiled language. If you're trying to do a static compilation of it, that's gonna be tough. [42:03]
-
-**Mo:** And it's honestly like super impressive what this team has been trying to achieve in itself. It's it's I don't think I have the capabilities to be able to, to dissect such hard problems. So kudos to them. [42:14]
-
-**Carl:** And also, just to, like, carry in the tone from this, you know, Hermes update post, I love that it has this hero image of a, I'm gonna call [42:21]
-
-it a flag that says "we do this not because it is easy, but because we thought it would be easy." [42:27]
-
-**Mo:** I love that so much, yeah, that hero images. Tzvetan is a really funny guy, like a very like, specific sense of humor, I've met him a couple times at conferences, he's just, he's such a joy to be around.
-
-## [React Native Hosting with EAS](https://expo.dev/blog/expo-announces-eas-hosting-service)
-
-**Mo:** I also want to quickly touch on Expo hosting, so this was announced a few weeks ago, and so, in sort of that light of, you know, there's Resell, which is the way that you host React applications or so called Next. js applications, I guess, mainly and you know, it's the framework that you use with the Expo world, obviously they are also kind of going into that footing of, we are the framework to use, and we also can host it because Expo is obviously going in this universal direction of, you can also use Expo and React native on the web and build full stack sort of across the board multi platform application on web and mobile and so obviously as part of that you're going to have to think about hosting where do you host the web applications and so they've launched EAS hosting which is their sort of first attempt at creating a hosting platform that will host your, you know, Web applications, but also your API routes, because if you remember from last year, we talked about Next.js's [43:31]
-
-API routes that they had, and so very similar to Vercel's API routes, you've got Next. js's API routes now, I'm sorry, you've got Expo's API routes now. And so it's a very sort of basic hosting platform for now. It lets you keep a track of, you know, the requests coming in, your deployments, the crashes. [43:48]
-
-And just some basic logging into your requests and so on and so forth. But I think it's, it's a, it's an interesting start and it's, you know, it's one of the pieces that they've been missing a little bit when it came to this universal story. So, we'll see how that expands, we'll see how it grows and evolves, but it's just the first and the early days of, you know, of EAS hosting. [44:07]
-
-**Carl:** I wish I had more to say on Expo, because it does seem really cool, and I have really admired its development over the years, but man, I just, I don't, I don't need to make native apps. Maybe one day. [44:17]
-
-as I'm charting my year in January I have a couple projects booked for the next couple of months, but back half of the year I might actually try and do like a fork of the Blue Sky plant, and that's Expo, so hey, maybe I'll get some real first hand knowledge [44:32]
-
-**Mo:** very keen. I love the comment. Someone's saying, I wonder if Tanstack will launch their own hosting one day. [44:37]
-
-**Carl:** That makes, yeah, that actually would not surprise me. Yeah, Mark you want to tell us everything we need to know about Node. js type stripping?
-
-## [Everything You Need to Know About Node.js Type Stripping](https://satanacchio.hashnode.dev/everything-you-need-to-know-about-nodejs-type-stripping)
-
-**Mark:** Well, I won't, but I'll tell you about the post that does. So, like bun have TypeScript support built in, but it's basically been like, Okay, we read the TypeScript source code, don't bother type checking it, we just execute it. And so, you know, given TypeScript's popularity, Node has finally jumped on the bandwagon and some of the latest Node releases actually integrate some tools that will do the type stripping so that TypeScript syntax code can at least run directly in Node without needing an additional tool like the TS Node. And, the big thing about this is that because they're stripping the types, they're not doing type checking the output also needs to be, like, your TypeScript code needs to be just types. Now you might think, well, it's TypeScript. Of course, it's just types. The problem is that some early TypeScript features do also result in additional runtime code being generated. [45:43]
-
-For example, when you use the enum keyword in TypeScript, it results in an object lookup table being added. And so because Node is just stripping the type syntax, if you try to use an enum with this new Node feature, it'll actually break things. So, I believe one of the upcoming TypeScript versions will actually have a flag that will enforce that you're only using type strippable syntax, but Big picture what this means is that it'll be easier to take, like, a node script that is written as a ts file with ts syntax and just say, like, node myscript.ts [46:25]
-
-or whatever. I don't think you have to pass in any additional arguments. So overall, it's, it's basically like matching the feature set of other tools like Bunn and making it easier to use TypeScript code across the ecosystem. [46:38]
-
-**Carl:** yeah, I am trying to quickly refresh my memory here, but I believe that I am actually using the strip types. No, I played with it but I found a different way around it. Yeah, I did, I did it. This is a feature I got to play with. I have first hand experience with strip types. It was pretty good. But yeah, there's still some weirdness around, like, type extensions, I think, in imports. [47:02]
-
-**Mark:** That does not surprise me. [47:04]
-
-**Carl:** I know, in trying to play with it, I had to do a code mod in order to add extensions, you know, like js extensions everywhere, and yeah, I know, I think a couple of episodes ago, we ended up talking, we talked a little bit about TypeScript, Faking what extensions it would use in order to make that work for compatibility reasons. [47:25]
-
-And so yeah, I got some first hand experience and it's weird. It worked. I got it working, but it felt weird to have, you know, to be authoring a ts or tsx file and importing it as js. That's definitely unintuitive. [47:41]
-
-**Mark:** complicated but valid technical reasons why they made that stance. [47:45]
-
-All right, Mo, I know you need to drop off shortly. Any other points you want to cover before you head out? [47:49]
-
-**Mo:** no, I think it's been a relatively quiet React Native month and I've been completely off the grid.
-
-## [Composable Caching with Next.js](https://nextjs.org/blog/composable-caching)
-
-**Mo:** The only thing that I am quite keen to talk about actually is the caching with Next. js, our little composable caching. Because I've been dealing with Next.js caching for the last two weeks and oh boy, oh boy, [48:10]
-
-I have been trying to, after dealing with the Pages router for a very long time I've been now dealing with Next. js caching for a little bit, and this use cache is obviously something that's more in canary at the moment. It's not published in, in sort of the, the stable versions, whatever that means in Next world these days, in terms of a stable version. [48:32]
-
-But, Basically, the caching is a little bit complex with Next14, as we know, and currently, if you want to cache things like database responses in server components, or you want to cache fetching, you have to wrap it in an unstable cache function that takes in the function, a promise, some key, and then some revalidation time. [48:56]
-
-And so, there's this really weird syntax to do this, and then of course there's also another level of caching when you have static pages, which means those static pages get cached after they're published. Built in whatever capacity. And there's just so many layers of caching at this point. It's hard to wrap your head around how your application is functioning. [49:16]
-
-And to make matters more confusing now, there's this use cache directive that they're planning on introducing, which looks really cool, but I can just imagine this getting ever more and more complicated. And to me, a real symptom of this is the fact that they've 180'd on the defaults of caching with Next 15. [49:36]
-
-Like, you've set some definitions on what is cached by default, what's not cached, and it went so poorly that you had to flip it 180 degrees. That does not give any semblance of stability to me as a consumer of the technology. And so I just look back at the days of the Pages router and wish we could just go back to the simplicity of having and getServerSideProps and just live life in that naivety of how simple that was. [50:06]
-
-**Carl:** I was thinking in similar directions and I'm actually now in a position where I'm maintaining a React Router v7 project, which I upgraded all the way from Remix 1 to React Router v7 in one go, or in one go, sequentially all the way up. And the, the Reactiflux website is I think it's a Next 14 Pages router app, so that one I could probably play with a little bit more. [50:35]
-
-But it's like, oh, I'm now actually maintaining apps on several of the largest frameworks And you know what? I like Remix the best. It's just got, like, the, the mental model is most familiar to me. It seems most predictable. And, like, I hate magic. I am someone who completely avoided the entire RWBY ecosystem because it's too magical. [50:57]
-
-I'm just like, man, Remix hits right for me. not much there. Just yeah, it feels good. I don't know. I like it. [51:03]
-
-**Mo:** I've used Remix as well, and I must say, like, It takes a little bit of adjusting from when you've just dealt with Next. js for several, months and years, but is just simpler. Like it feels more native webby, the bits of magic are really just like the loaders, the actions that you have, but like everything else just feels sort of you're dealing either with React or you're dealing with the web. [51:24]
-
-And I quite like that as a concept. [51:27]
-
-**Carl:** Right. [51:28]
-[51:28]
-
-**Carl:** it lets me think in terms of like, HTML, HTTP, and like, cookies. And like, yes please, let me think about the platform and not the toolchain. Yeah. [51:39]
-
-**Mo:** And someone in the chat, one of our listeners, is actually pointing out that the app router is still defined as the bleeding edge of on the React install docs, basically, on start a new React project. [51:51]
-
-**Carl:** definitely some bleeding happening. [51:53]
-
-**Mo:** So yeah, that was my little, my rant. [51:55]
-
-**Carl:** Cool. Yeah,
-
-## [Thoughts on What RSC Means for SPAs](https://blog.axlight.com/posts/thoughts-on-what-rsc-means-for-spas/)
-
-**Carl:** Mark, next link up is like thoughts on what RSC means. did you read that? Can you talk about that? [52:02]
-
-**Mark:** Yeah, I, I skimmed it a bit. So it's a, it's a post from Daishi Kato who worked maintains Zustand, created Jotai and Valtio and has been working on the, the Waku RSC based framework. So it's a couple different points. One is, can R RSCs actually relate to single page apps? And the answer is sort of maybe yes. [52:25]
-
-Like, you know, for example, the RSC payload could be served statically. And not dynamically generated on a server. it's actually kind of a, kind of a short read, but you know, just like some, alternative thoughts from just like, RSCs are on the server and, you know, can only be used with Next, et cetera. [52:42]
-
-So it's short, but worth reading.
-
-## [Chrome's 2024 recap for devs](https://developer.chrome.com/blog/chrome-2024-recap)
-
-**Carl:** last main content article Chrome put out a 2024 recap. That was just pretty good. I don't know. Some of it, I'd call it like 30 to 40% marketing fluff. [52:55]
-
-They spent a lot of time talking about how they added AI to the chrome dev tools, which I actually have heard some positive things about, like interpreting errors. Like okay, yeah. Neat. But yeah, I noted that it called out view transitions, which just 'cause we talked about it earlier in the episode. [53:09]
-
-Like, hey, look at that. platform and react in unity in sync. I think we'd mentioned this before, but there's a CSS popover and like anchor positioning. So you can do popovers without JavaScript, which. I have implemented popovers in so many apps, and I hate it. I am so tired of it. Like, I do not use popovers anymore because I'm so tired of making them. [53:33]
-
-So, being able to do it without crazy layout logic in JavaScript sounds great. Maybe I will actually use them again.
-
-## Shoutout [webstatus.dev](https://webstatus.dev/)
-
-**Carl:** And I also learned about a new site recently through reading that, webstatus.dev, which has a, like, annualized baseline browser feature summary, which looks neat. Although I'll note that, you know, we're into 2025. [53:55]
-
-We're a month into 2025, and the 2024 baseline is not met. Like, yeah. Safari looks to be generally the worst offender, But, Firefox and Edge also, slipping behind a little bit. Well, no, maybe that's not fair, because Firefox is ahead in a couple of them, ahead of Chrome in a couple of them. So, anyway, this is neat. [54:14]
-
-I love these kind of like, broad based what features Are being implemented. this is how I have always kept an eye on what's coming down the pike. So, didn't know this existed. Cool. Useful.
-
-## Redwood.js shutting down?
-
-**Carl:** I don't have a link for this, but I've heard, through the grapevine, that there will be some impending announcements from Redwood.js generally the shape of what I've heard is that like an original found co founder of the project who had kind of left or like gone dormant came back and has decided that I I don't know what is going on I read some like Google translated slack messages from I believe Swedish and it sounds like a co founder has come back out of the woodwork and basically taken over and Just said like This is good SEO. [55:01]
-
-This, there is value to this domain, this brand. It's mine now. I'm going to do something entirely different with it. So yeah, keep an eye out. Redwood. [55:09]
-
-**Mark:** Another way to phrase it is it sounds like Redwood the framework is dead and the name and repo are going to be repurposed. [55:19]
-
-**Carl:** that's the shape of what I've heard. I think I heard that they will be doing an announcement in the next month. So like, ooh, breaking story, our first one, but, ah, it's just such a shame because I, I've met them at a conference or two, they seemed really good, and I liked the general, like, like, I understood them as trying to do Laravel for the React ecosystem, and I thought that was a pretty good niche, so, just a shame. [55:45]
-
-Shame to see it die to some drama like this. But yeah, there should be some more details, maybe we can talk about it maybe we will have some, you know, perspective to give [55:55]
-
-this month. [55:56]
-
-**Mark:** next month. [55:56]
-
-**Carl:** Actual details, not screenshots of Slack.
-
-## [A checklist for your `tsconfig.json`](https://2ality.com/2025/01/tsconfig-json.html)
-
-**Mark:** Axel Rauschmeyer has done a lot of articles over the years about like, what's new in this year's version of the, you know, the, the ES language spec. He's also been writing some articles recently about some TypeScript related things, like different ways to define a NUS or similar things. And he put up a post call a checklist for your TS config, JSON, which walks through and actually like, looks at a lot of the config options and what they do and when it makes sense to use a lot of them. [56:27]
-
-pretty sure that Matt Pocock has done a similar post somewhere.
-
-## [Recoil repo archived](https://x.com/dai_shi/status/1875910305802514649)
-
-**Mark:** completely different note We talked about Redwood maybe kind of going away. The recoil library repository has been officially archived. Now, it had been unmaintained for a while. I had read from people who had been involved that apparently both the people who had been maintaining it had gotten caught up in layoffs from meta. [56:52]
-
-So, But, honestly, it also seemed as though the project had stagnated for quite a while. The thing that gets me, really, is that when Recoil was first announced whenever that was, like 2017, 18 ish there were just so many people who looked at the announcement and took it as Oh look, this is an official React State Management Library. [57:19]
-
-When in reality it was just some other app team at Meta came up with their own solutions and decided to publish it. But, you know, the combination of Redux backlash, and like, It's from Facebook, it must be official! meant that a lot of people jumped on it, and then it sort of stalled, and then Jotai came out, and Recoil just sort of went away. [57:45]
-
-**Carl:** Sad to see stuff drop
-
-## [Bun: first-class support for s3](https://bsky.app/profile/bun.sh/post/3legdozw3nc2p)
-
-**Carl:** Alright Bun is shipping first class support for S3, which is interesting. So, first class support for S3 here means being able to use it as like a file system, I guess. standard library tool for implementing Or for interacting with file storage services that themselves implement the S3 API, which is pretty widely supported. [58:11]
-
-So this is actually pretty interesting because, like, I don't know, I hate dealing with, stuff like the AWS SDK. I've, like, partially avoided learning AWS because it's just so complicated and annoying. So seeing some little details like S3 interactions being brought into the runtime is actually pretty neat. [58:32]
-
-Yeah. I'm seeing in the chat, there's a lot in that 2 announcement. Sadly, I don't actually use bun in my day to day. So I am just kind of an observer here and I have not stayed super up to date. Just that caught my eye as like, Oh, interesting. What an opinionated stance.
-
-## [Interpolate `auto` height for animations](https://bsky.app/profile/joshwcomeau.com/post/3lf5zwg2ths22)
-
-**Carl:** There is now, I believe in the latest Chrome, there is an interpolate size CSS property you can set on like high up on your your page to allow interpolating allow animations to interpolate between Auto, like if you say height auto and height zero. Previously you couldn't animate between those two states. [59:11]
-
-And now, You can in latest Chrome. That's super cool. I have always thought it was super weird that that extra step of just letting your size, letting the size of an element be automatically determined meant that you couldn't use CSS transitions. That just never made sense to me. So it's, it also doesn't make sense to me why it took 10 years from me feeling, oh, that's weird, to this actually shipping, but super cool. [59:37]
-
-Neat. Love it. I believe it's currently Chrome only, but yeah, I mean, hopefully it'll, hopefully it'll filter out pretty quick. He says, after complaining about waiting 10 years.
-
-## [Free javascript; Oracle not voluntarily releasing](https://bsky.app/profile/deno.land/post/3lfapjn7gns2w)
-
-**Carl:** And a small, extremely small update to something we discussed previously, the Deno organization's campaign to get Oracle to free the JavaScript trademark. [01:00:00]
-
-Oracle has Declined to voluntarily withdraw the trademark. So Deno is doing legal things to advance the process. This is a legal drama. So this is probably going to be something we're still talking about in like 2026. And I would not surprise me if it's like 2030 before the trademark actually, like before this case settles, let's say. [01:00:23]
-
-But yeah, neat. Maybe I'll stop giving updates, but Oh God, it would be so nice if Oracle did not own JavaScript.
-
-## [Understanding React Server Components | Tony Alicea](https://tonyalicea.dev/blog/understanding-react-server-components/)
-
-**Mark:** All right, and last one Tony Alicea is an educator who has written some very, very good deep dive blog posts into some things like React rendering, which is a topic I care deeply about, so I appreciate that and he recently put up a post on understanding React server components. [01:00:48]
-
-Now we've, we've mentioned a lot of different dive into server components type posts over the last couple years. This one walks through a lot of how server components fit into the rendering process, looks at some of the actual JSX related data that is serialized and sent back and forth, and talks about how it then fits into things like streaming and bundlers and hydration. [01:01:12]
-
-So it's not something you would read to understand, like, how do I use a server component? But it's a really good explainer that, you know, how digs through a lot of the technical aspects and talks about why server components work the way they do. [01:01:26]
-
-**Carl:** Yeah. Oh man. Wouldn't it be cool if this was put out as like a guest post on the React blog? [01:01:32]
-
-Cool. Okay. That's all of the links we have for you this month. Thank you for our persistent listeners who stuck with us all the way to the end. Yeah, we'll be back on the last Wednesday of February next month or in this episode, we'll be back in your podcast feed just as soon as we can. Thanks so much for listening. [01:01:50]
-
-**Mo:** Lovely to be here with you all again every single month. it's always a pleasure. Thank you, Mark. Thank you, Carl Thank you to everyone who's listening in and see you all in February [01:01:59]
-
-**Mark:** Yep, thank you, appreciate it. And if you want to stay up on the current drama that I am involved in in the React ecosystem, please follow me on Bluesky or watch for my upcoming blog post within the next few days.
-
-## [Follow us on Bluesky!](https://bsky.app/profile/tmir.reactiflux.com)
-
-**Carl:** Oh yeah, we can follow, you can actually follow this podcast on BlueSky too. We are tmir.reactiflux.com and I'm going to put a link in here. Cause you know what? I should do that. [01:02:23]
-
-We gather sources from thismonthinreact, bytes.dev, reactstatus, nextjsweekly, the reactjs subreddit, here in Reactiflux from the techreadsandnews channel, and sometimes even directly from people publishing content. [01:02:38]
-
-If you see anything that would be useful for us to discuss or just that you want to share with the community. Definitely pop it in the Tech Reads the News channel, or if you like, you can send it to hello at reactiflux.com. I will read literally anything you send to that. So, yep, go ahead. If this is a show that you get value from and want to support, best way to do so is by submitting a review, wherever you listen, or tell people about it. [01:03:02]
-
-It's great. Help us grow. Woo!
diff --git a/src/transcripts/tmir-2025-02.md b/src/transcripts/tmir-2025-02.md
deleted file mode 100644
index 523c407..0000000
--- a/src/transcripts/tmir-2025-02.md
+++ /dev/null
@@ -1,494 +0,0 @@
----
-title: "TMiR 2025-02: Updated new project docs"
-date: 2025-02-24
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[01:11](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
- - [[02:35](#microsoft-performance-based-job-cuts-have-started)] [Microsoft Performance-Based Job Cuts Have Started](https://www.businessinsider.com/microsoft-performance-based-job-cuts-have-started-termination-letters-2025-1)
-- [[03:07](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[03:10](#react-paris-march-20-21-paris-france)] [React Paris](https://react.paris/) March 20-21 Paris, France
- - [[03:14](#react-native-connection-april-34-paris-france)] [React Native Connection](https://reactnativeconnection.io/) April 3–4 Paris, France
- - [[03:19](#react-miami-apr-17-18-miami-fl-usa)] [React Miami](https://reactmiami.com), Apr 17-18 Miami, FL, USA
- - [[03:25](#cityjs-london-april-23-25-london-uk)] [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
-- [[03:53](#sponsored-by-infinite-red)] Sponsored by [Infinite Red](https://infinite.red)
-- [[04:48](#new-releases)] New releases
- - [[04:50](#react-router-72)] [React Router 7.2](https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v720)
- - [[05:11](#ts-58)] [TS 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8-beta/)
- - [[09:01](#prettier-35)] [Prettier 3.5](https://prettier.io/blog/2025/02/09/3.5.0)
- - [[09:12](#rtk-query-v260)] [RTK Query v2.6.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.6.0)
- - [[10:04](#standard-schema)] [Standard Schema](https://standardschema.dev/)
- - [[10:34](#astro-52-also-astro-53)] [Astro 5.2](https://astro.build/blog/astro-520/) (also [Astro 5.3](https://astro.build/blog/astro-530/))
- - [[11:35](#turborepo-24)] [Turborepo 2.4](https://turbo.build/blog/turbo-2-4)
-- [[12:20](#main-content)] Main Content
- - [[12:23](#sunsetting-create-react-app)] [Sunsetting Create React App](https://react.dev/blog/2025/02/14/sunsetting-create-react-app)
- - [[16:59](#original-sunsetting-cra-post-vs-build-a-react-app-from-scratch)] Original “[Sunsetting CRA](https://github.com/reactjs/react.dev/pull/7495)” post vs [Build a React app from Scratch](https://react.dev/learn/build-a-react-app-from-scratch)
- - [[25:26](#backlash-and-confusion-over-initial-version)] [Backlash](https://x.com/youyuxi/status/1891721924197351497) and [confusion](https://x.com/youyuxi/status/1892000761778929931) over initial version
- - [[26:52](#mark-filed-a-pr-to-rewrite-the-docs-the-react-team-closed-that-but-based-a-new-one-off-it)] [Mark filed a PR](https://github.com/reactjs/react.dev/pull/7618) to rewrite the docs, the React team closed that but [based a new one off it](https://github.com/reactjs/react.dev/pull/7624)
- - [[38:09](#between-the-wires-an-interview-with-mootools-contributors)] [Between the Wires: An interview with MooTools contributors](https://www.freecodecamp.org/news/between-the-wires-an-interview-with-mootools-contributors-33d764957575/)
- - [[42:58](#how-to-start-a-react-project-2025)] [How to start a React Project [2025]](https://www.robinwieruch.de/react-starter/)
- - [[43:56](#jack-herrington-published-create-tsrouter-app-under-the-tanstack-umbrella)] [Jack Herrington published `create-tsrouter-app`](https://bsky.app/profile/tannerlinsley.com/post/3lif6fdpzkw2s) under the Tanstack umbrella
-- [[47:24](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[47:29](#vercel-acquires-tremor)] [Vercel acquires Tremor](https://vercel.com/blog/vercel-acquires-tremor)
- - [[48:29](#things-people-get-wrong-about-electron)] [Things people get wrong about Electron](https://felixrieseberg.com/things-people-get-wrong-about-electron/)
- - [[48:57](#initial-observables-support-in-chrome-135-observable-api)] [Initial Observables support in Chrome 135](https://x.com/BenLesh/status/1893053275995357608), [Observable API](https://chromestatus.com/feature/5154593776599040)
- - [[49:33](#why-i-rebuilt-prosemirrors-renderer-in-react)] [Why I rebuilt ProseMirror’s renderer in React](https://smoores.dev/post/why_i_rebuilt_prosemirror_view/)
- - [[49:52](#javascript-temporal-is-coming)] [JavaScript Temporal is coming](https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/)
- - [[50:44](#do-javascript-frameworks-still-need-portals)] [Do JavaScript frameworks still need portals?](https://fullystacked.net/portal/)
- - [[51:46](#what-do-we-do-with-you-old-react)] [What Do We Do with You, Old React?](https://www.manuelsanchezdev.com/blog/what-to-do-with-old-react-upgrading-to-modern-react)
- - [[52:18](#records-and-tuples-proposal-is-now-composites)] [“Records and Tuples” proposal is now “Composites”](https://bsky.app/profile/littledan.dev/post/3liwo57opl22b)
-
-**Carl:** All right. Hello, everyone. Thank you for joining us for the February edition of This Month in React, where we recap And digest the recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:00]
-
-But I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like these events and build tools to help keep the community operating. [00:16]
-
-**Mark:** And I'm Mark. My day job is working at Replay. Io. We're building a time traveling debugger for JavaScript and figuring out how to integrate that with AI DevTools. And in my copious amounts of spare time, I both work on Redux and spend entirely too much time complaining about the React ecosystem. [00:26]
-
-**Carl:** And also now writing documentation and long, enormous blog posts. I actually printed out your blog post that I offered to help you edit, and it was 50 pages long. 50 sheets of paper. [00:42]
-
-**Mark:** I apologize to the forests that suffered for that one. [00:53]
-
-**Carl:** It's entirely your fault. [00:56]
-
-Yeah, our third co host, Mo, is off this month. He is very busy with work and things, and just needed to take some time, not in the right space to have this conversation this month, so he'll be back next time. [00:58]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Some quick hits. Job market. I was hoping around December, January, it was looking like, I don't know, new quarter, new year, new budgets. I was cautiously optimistic from seeing activity in the job board, yada yada. But sadly that has not borne out. [01:11]
-
-## [Microsoft Performance-Based Job Cuts Have Started](https://www.businessinsider.com/microsoft-performance-based-job-cuts-have-started-termination-letters-2025-1)
-
-**Carl:** I guess, you know, maybe some small companies were hiring, but like, Meta is doing performance based layoffs. Microsoft is doing performance based layoffs. And talking to someone about the job market and the ecosystem, and they shared something that made me think differently about layoffs that are happening right now. [01:29]
-
-Like, when the company is signaling that it is performance based, That is a very different situation than when you just get laid off. Like, was pointed out to me that like, if you have on your resume that you worked at Meta and that you got laid off January 2025, that is no longer, like, the golden ticket. You know, like, for many, many years, if you worked at one of these big tech companies, that was, like, pretty much, not a free pass, but, like, it opened a lot of doors. But now a lot of people are getting let go when the public messaging is we're letting go of low performers. And that is a very different environment to lose your job in. [01:46]
-
-So that's, yeah, I hadn't really thought about that, but yeah, how the company messages, how they're letting people go definitely can have a huge impact. And I saw a quote from a Bloomberg article about the Microsoft layoffs. [02:23]
-
-## [Microsoft Performance-Based Job Cuts Have Started](https://www.businessinsider.com/microsoft-performance-based-job-cuts-have-started-termination-letters-2025-1)
-
-**Carl:** " Employees losing their job will see health care benefits end immediately. In three specific cases, employees were told that they weren't getting severance." [02:35]
-
-So like, not only is, are they publicly signaling that these are like performance based and therefore really doing harm to the like future employment prospects, like they're not, they're being pretty stingy about these severance deals. [02:43]
-
-Losing your health insurance with no notice. It's pretty brutal, like, that's, that's just rough. Especially, like, yeah, hopefully they weren't getting any active treatments. Ugh, anyway, that's all I'll say on that. [02:56]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** some upcoming conferences in March and April, [03:07]
-
-## [React Paris](https://react.paris/) March 20-21 Paris, France
-
-**Carl:** we've got React Paris. March 20th and 21st. [03:10]
-
-## [React Native Connection](https://reactnativeconnection.io/) April 3–4 Paris, France
-
-**Carl:** We've got React Native Connection, April 3rd and 4th, also in Paris. [03:14]
-
-## [React Miami](https://reactmiami.com), Apr 17-18 Miami, FL, USA
-
-**Carl:** we've got React Miami, coming up in April 17th And 18th. [03:19]
-
-## [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
-
-**Carl:** there's also CityJS London, April 23rd to 25th in London. [03:25]
-
-**Mark:** Then whole slew of things in late May and early June. Conference season kicking off. [03:30]
-
-**Carl:** Yeah, definitely. I need to actually book things. I don't have anything, I'm going to render Atlanta in June, but I don't have anything booked before then. Yeah, going to Brazil for 12 days is really kind of complicated by Soaked up a lot of my logistical planning. [03:35]
-
-, Um, yeah, our sponsor. We are sponsored. We have a sponsor. [03:49]
-
-## Sponsored by [Infinite Red](https://infinite.red)
-
-**Carl:** Infinite Red is an expert React Native consultancy. It's been around since 2015. So basically the entire time that React Native has been around. They are our only sponsor in part because very few companies do as much as they do for the ecosystem. [03:53]
-
-, and I just don't know Too many other companies that have done quite so much for quite so long. So very happy to be partnered with them in that way. They only do React Native and they've built over 75 apps for companies from startups to the biggest in the world. And other than being kind, great people who have done great things for the ecosystem, like hosting podcasts and organizing conferences, They are generally just a small team that focuses on like building for the long term. [04:07]
-
-So if you are working at a company that's spinning up a new React Native project and needs to get build some expertise, definitely give them a call because they will actually not just build it, but they will work with you to help develop expertise and hit the ground running. Cool. [04:34]
-
-## New releases
-
-**Carl:** onto some new releases. [04:48]
-
-## [React Router 7.2](https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v720)
-
-**Carl:** We've got React Router, putting out a minor release, 7.2. Looked pretty minor. The headline for me here is that they have a type safe HRF tool, which sounds pretty interesting if you can have type safety. That your links work like that's just neat. They have a new way of doing that how well it works remains to be seen, but it seems cool [04:50]
-
-## [TS 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8-beta/)
-
-**Carl:** We've also got TypeScript version 5. 8 with a bunch of stuff. Of course TypeScript new version [05:11]
-
-**Mark:** thing that I'm interested in here is the new erasable syntax only flag. And for background on that, so TypeScript has always been described as, you know, a types only layer on top of JavaScript. But there are a few TypeScript features that actually do have some runtime code. Enums, I think a couple of the, a couple of the old legacy, um, syntax features as well. [05:18]
-
-And so, there are a number of tools today which work to strip out TypeScript types. But if your code uses some of those features that do have some runtime code, they, they don't work right. And this actually matters a lot for things like Node's new TypeScript, Stripping support. [05:43]
-
-And so, to try to work better with those tools, TS has added this erasable syntax flag, which I believe actually throws an error if you are using any of the syntax that has runtime output. So it's basically like a, an extra enforcement check to make sure that you're not using any of those features. And that way you can ensure that your code is compatible with just stripping the types as opposed to like a transpilation. That's actually a really big deal. [06:01]
-
-**Carl:** Yeah, super helpful. And it's actually, that's like a reasonably large build time optimization if you can get away with it. Because if you're not actually analyzing the types while compiling the code, you're just doing the parsing and the output. Like that's a lot less work. And your, like, VS Code, our IDEs, our language servers are already surfacing most of those type errors. [06:29]
-
-So, like, I think it's really neat to, for one, I have used this just Because it's less effort to stand up a new project. You know, if I can just lean on the language server, then that's just less code, fewer moving parts, fewer things to go wrong, fewer things to break when I pick the project back up in four months. [06:52]
-
-but yeah, it's also like if you can move the actual type checking into like CI or something like that and just do it less frequently, that's, that can be a lot less work overall. Yeah, there was a relatively subtle thing, slightly smarter return types when generic arguments are used in conditional types. [07:08]
-
-It's really specific and only a partial solution, but I've run into some problems like this. And the overall like pattern that they were showing off for this was like not super familiar with to me and looked useful. So like, I that caught my eye as like a kind of subtle but useful thing. [07:27]
-
-They are adding support for using require to get ESM modules. Which is interesting, like this is, you know, a continuation of the long tail of complexity that the switch over to ES modules, standardized modules, is having. But like, cool, now we have one more way to run into fewer problems when In an ESM environment, but needing to depend on CommonJS code. [07:43]
-
-it still does not allow you to require an ESM file that contains a top level await. [08:10]
-
-**Mark:** Because `require()` is synchronous. [08:16]
-
-**Carl:** yes, facts. Also added a new flag that just caught my eyes, like a nice, I don't know, LTS feature. They have a `--module node18`. So you can tell TypeScript what module, like parsing, what determines what modules to use, how it evaluates what modules are being imported? You can tell it to use specifically the behavior for node 18. [08:18]
-
-I've done a lot of maintenance of legacy apps and weird edge cases like that, like, Oh, in the last five versions, they have changed in what order or in what manner modules are crawled. Stuff like that can cause so many weird, obnoxious, difficult to debug errors. [08:42]
-
-## [Prettier 3.5](https://prettier.io/blog/2025/02/09/3.5.0)
-
-[09:01]
-
-**Carl:** Cool, new version of Prettier. I saw they're adding an option, which they do not do very frequently, so that's cool. [09:01]
-
-**Mark:** Looks like they're trying to let you configure how it formats collapsing objects. [09:07]
-
-**Carl:** Useful. [09:12]
-
-## [RTK Query v2.6.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.6.0)
-
-**Mark:** I am very pleased to announce that yesterday I shipped Redux Toolkit 2. 6, which now has infinite query support for RTKQuery. This has been our single most requested feature since RTK Query came out, and I started working on this back in October, after another user had submitted a draft PR to get a first proof of concept going. [09:12]
-
-There was a lot of discussion, a lot of trying to figure out what the problem space is, and how to implement this properly. We ended up adopting the React Query public API design for this. And I had some discussions with Dominic Dorfmeister, the, you know, TK Dodo, the React Query Maintainer, who specifically gave us advice on why they ended up with this API design and how they implemented it. [09:34]
-
-So, worked on this intermittently when I had time over the last few months and very happy to get this out the door. [09:58]
-
-## [Standard Schema](https://standardschema.dev/)
-
-**Mark:** There's also a, project or a standard, I guess, called Standard Schema, which is an attempt to, you know, sort of unify or find a common denominator between a bunch of the different TypeScript validation tools out there, like Zod and Valobot and Archetype. So apparently you can now say that your project needs Just the standard schema definitions, and then the end users can then swap in their preferred validation library where and where they want to. [10:04]
-
-## [Astro 5.2](https://astro.build/blog/astro-520/) (also [Astro 5.3](https://astro.build/blog/astro-530/))
-
-**Carl:** there's also two Astro releases. There's 5. 2 and 5. 3. Looks like it's You know, relatively. Small iterative improvements. I was just reading a little bit more. Astro 5. 3 is talking about automatic session storage setup. And as someone who has opinions about off, And prefers, you know, session storage to jWTs for authentication, that caught my eye. [10:34]
-
-I don't know a ton about this, but definitely anything that makes sessions a little bit easier to like wrangle and manage, is definitely nice. I've been, as an exercise, I've been building my own. Authentication from scratch in session storage with React Router v7. So that's just fresh on my mind. [10:59]
-
-I would love to be able to tell you more about what the experience of using Astro is like, but I, I have tried and failed to start several projects because I just don't have time. I have too many different projects going on. But It always crosses my mind when I'm thinking about, like, a blog, or a static site, or things like that. Seems like a very good tool for those purposes. [11:18]
-
-## [Turborepo 2.4](https://turbo.build/blog/turbo-2-4)
-
-**Carl:** There's also TurboRepo 2. 4. TurboRepo is a great tool for managing monorepos. From the next team, and they've got a number of improvements to enhance your repository as they say Boundaries, watch mode caching, continuing the trend of Vercel dealing with caching issues and Versioned configuration validation from within your repository, interesting. And they've also got circular dependency recommendations for adopting Turbo repo in large repos more easily. That's interesting. I've run into so many circular dependency issues throughout my career that just very much catches my attention. Very neat. Cool. [11:35]
-
-**Mark:** I spent time trying to squash those as well. [12:16]
-
-**Carl:** Just the worst. So painful. [12:19]
-
-## Main Content
-
-**Carl:** Cool. Into our main content. Mark, you wanna start us [12:20]
-
-## [Sunsetting Create React App](https://react.dev/blog/2025/02/14/sunsetting-create-react-app)
-
-**Mark:** All right, yes, yes, I, I have thoughts and opinions on this topic. So, in our last episode, as a Relatively brief recap. When React 19 came out, it broke Create React App because of a peer dependency version mismatch, where the old templates wanted React 18, but CRA tried to install React 19. So I spent a chunk of January griping about this and trying to say, this is broken and it needs to be fixed. [12:23]
-
-That led to several heated discussions on Blue Sky with the React team about, and trying to convince them to fix it. And so, right before our last episode, I had filed an issue that recapped what was broken and why, and pointed to a couple of PRs that other people had filed to both fix the CRA templates and actually mark the Create React App repo and command line tool as deprecated, and the React team had actually taken action on that and merged the initial PRs And they hadn't actually put out a new release of Create React App that fixed the brokenness, but the changes were in there and they were trying to figure out the process for doing the releases. [12:53]
-
-Along with that, though, I had specifically said that I felt the React Docs setup page ought to recommend Vite as, you know, the equivalent replacement tool. So that people being told, CRA is dead, don't use it, would have a direct equivalent tool to try to use. So that's where we left off a month ago. [13:38]
-
-And the entire topic has continued significantly over the last few weeks. So, from my perspective, there were several additional debates going on, on, you know, BlueSky and Twitter and in the docs about, you know, what ought to be done as follow ups and, you know, what should be recommended as tools. [13:59]
-
-And on my side, I had actually started writing a rather lengthy blog post that tried to cover a bunch of topics from how has React been developed over the years to erecting some community confusion, like. You know, the ongoing claims that Vercel is driving React development just to make money on servers, which is wrong. [14:20]
-
-but also describing sort of my take on the history of interactions between the React team and the community and frustrations and miscommunications and docs problems and frameworks and all these different things. So I'd been working on that. In, you know, over the course of a couple of weeks and kind of like teasing my progress online. [14:42]
-
-And I'd also been having discussion with some other maintainers and without having given specific details publicly, the React team actually reached out to folks like Tanner Linsley and myself and specifically said, we can, like, we can tell you're frustrated. We would like to hear your feedback directly. [15:04]
-
-And so I know that, Joe from the React team had a call with Tanner Winsley, where Tanner expressed a lot of thoughts about, I think especially some of lack of new client functionality in React as well as where React was headed. And so, Joe and I had a call. In early February ish, where I summarized all my different concerns, and then there were a couple follow up calls, and, Carl and I actually were on one with, both Joe and Matt, where the React team talked about what they're trying to work on. [15:25]
-
-In response to a lot of these discussions and feedback. One of the things they said was we're, we're preparing a blog post and some docs updates in response to CRA being dead. As well as even things like they've been talking about trying to have a new community working group for a while, but they've kind of gotten bogged down in what the logistics should be. [15:59]
-
-So, based on that, I could see that the React team was very actively trying to listen to feedback and trying to take some actions in response. And so, I think it was later that week that the React team finished the draft of the blog post and the docs updates. They gave me a chance to review it and offer feedback and a bunch of other folks as well. [16:20]
-
-And so they published that blog post and they, I did actually see that they had applied some of the feedback that I'd suggested. They did not apply all of the feedback that I suggested. [16:45]
-
-## Original “[Sunsetting CRA](https://github.com/reactjs/react.dev/pull/7495)” post vs [Build a React app from Scratch](https://react.dev/learn/build-a-react-app-from-scratch)
-
-**Mark:** And this actually kind of got rather controversial again as I rather predicted that it would. They put up a blog post labeled Sunsetting Create React App, where they said, CRA is dead, here's all the things that it didn't include. [16:59]
-
-There's better tools, but also we really, really, really, really, really think that people should be using frameworks that have routing and data fetching and everything else built in. And the first version of this blog post really, really emphasized the framework part. And they did make changes to the setup docs, but they also put up a new blog post that was called Building a React Framework. [17:14]
-
-And so, you know, what, what everyone's been clamoring for is just recommend VEET in the setup page, please. And they didn't actually do that with this first update. They instead, what they said was, well, when you pick your own build tool and your own router. And your own data fetching library. What you're really doing is building your own framework badly. [17:39]
-
-And I can understand the mindset behind that, but frankly, this was not a helpful approach for anyone actually reading the framework. If you are a learner or a beginner, or want to try to choose some other tools, what would be helpful is instructions that say, you can use one of these two or three build tools, you can use one of these couple routers, and one of these data fetching libraries, and at least giving people a valid direction to go with it. [18:07]
-
-And instead, what we got was a pretty straightforward, page that said, if you don't want to use a framework, you can build your own framework. Step one, install Vite or Parcel. Step two, you're going to have to think about routing and data fetching and code splitting, and boy, these are complicated and you will never be able to do this by yourself. [18:35]
-
-Don't do this, please! Use a framework instead. And that really was not helpful for the audience that was going to be reading it. And so I had tried to offer feedback saying I don't think this page is good before the post went up, and that was one of the things they did not listen to me on. [18:57]
-
-**Carl:** Yeah, And it, it definitely feels like that the fe it seems like the feedback that you gave is in line with like community expectations. Just seeing the Reddit response to, you know, the comments on the Reddit post for this blog. I, you know, I saw like Rick Hanlin had replied to something and got down, voted to like, you know, minus 20, something like that. So, it does, just like for more data points coming, rolling in in real time around, the core team is out of step with expectations for the community. [19:16]
-
-**Mark:** Yeah, so, you know, I, I understand what the React team is trying to accomplish, and in fact, actually, one of the, one of the most interesting data points that came out of those couple conversations with the team. So, they've said, since they started this frameworks emphasis that, Part of the goal is that, you know, they, they don't want people to start off with a single page app and then have to do like a major tool migration in order to add SSR functionality. [19:48]
-
-What I didn't realize was a lot of their goal and mindset around this is actually around React app performance. And they are actually very sensitive and I've heard a lot of the criticism. From folks like Alex Russell that, you know, single page apps and the average React app are horribly performing tens of megabytes of JavaScript. [20:14]
-
-Like, they're actually very, very sensitive to that criticism, and I don't think I'd realized how sensitive it was. Turns out that part of their reason for emphasizing frameworks Is, they feel that if most apps start with a framework by default, then on average, more React apps will have somewhat better loading performance, data fetching, code splitting performance, etc. [20:38]
-
-That is actually one of the big drivers for why they recommend Framework so strongly, and I didn't realize how big a driver that was until they told me that themselves repeatedly. [21:05]
-
-**Carl:** Yeah, I can understand that, and like, I don't think that's wrong. Like I have worked on so many different apps and so many of them have been like badly broken in different ways. Like shout out to the company I worked at that had a 45 minute Docker build that produced 36 megabytes of webpack output. Had six different copies of the app because every, Each of their six pages was a different entry point, so you literally had to download six copies of the app as you clicked around. [21:16]
-
-So, like, I've lived that. I've seen that. That is true. Just facts. Also, I don't know, I guess it's maybe just like in this, I feel like it's an inherent tension to the goals of encouraging deep learning and, setting up default incentives that produce better outputs, better outcomes. [21:43]
-
-Like, I feel like they're going very hard at, um, We know that this will produce better outcomes in aggregate. And I don't think they're wrong. I think they're correct to say that. But I don't think it's The ideal path for many individual developers. So I feel like this is, this is a tension between micro and macro. [22:04]
-
-You know, they are taking the macro perspective of in aggregate, this will produce more good. And you and I maybe are looking at the micro of this is not filling the needs for these people specifically. Yeah, [22:23]
-
-**Mark:** Yeah, so like, you know, I, I understand the, you know, make, make sure that you use a tool that has all the features you will ever need. So you don't have to migrate and make sure you use a tool that has all the optimizations built in. So you're getting good default performance. What it leaves out and ignores, though, is that. [22:39]
-
-if you're a learner or a beginner, having fewer knobs and having fewer concepts to worry about is going to make it easier to learn. A lot of companies are in positions where they can't or don't want to use Node on the back end. They just want a very simple SPA. Um, there's a lot of people who, for good or bad reasons, don't like Node. [22:59]
-
-The React team's emphasis on frameworks. They're suspicious of, you know, the, the incentives in Vercel. And so the React ecosystem is very large and for better or for worse, a lot of people are very happy building React apps the way we have for years. And so my perspective is that the thing that the maintainers should do is Provide recommendations, but also recognize that it is a broad ecosystem and at least say The way you're using react is valid and we recognize you and support you Even if you've made choices that we don't think are the most optimal and the problem is the one line emphasis on frameworks And the tone of the statements in the docs has basically told half the ecosystem, We don't care about you, and we think you're doing it wrong. [23:23]
-
-Which is not very helpful. [24:17]
-
-**Carl:** Yeah. For sure. Right? Like, I wanna, I wanna bring in a strong opinion I have, which is that the world is held together with shoestrings and duct tape. Like, everything in the world barely works. If you look too closely at anything, like, it's a miracle that things are functional. And, My impression is that the core team is kind of railing against that a little bit. [24:18]
-
-Like, they wish things worked better. They wish that the world were a little bit more ordered. And they are meaningfully trying to shift, you know, they are exerting their influence on the world as the caretakers for a tool used by literally millions. So, yeah, I don't know. I guess, circling back a little bit, you had brought up, like, community working group and some chats. It's very early, but you and I and Jack Harrington and maybe some other folks are talking about what that might mean. What that might look like, what processes might be involved, and what outputs might be produced. [24:39]
-
-So yeah, I don't know, maybe ReactiFlex can play a larger role in that conversation, in that, I don't know, activity. [25:19]
-
-## [Backlash](https://x.com/youyuxi/status/1891721924197351497) and [confusion](https://x.com/youyuxi/status/1892000761778929931) over initial version
-
-**Mark:** Yep. So ultimately what happened was they put up the new docs PA and the new blog post and the docs page, and this spawned a bunch of controversy and outcry, lots of arguments on Reddit and Twitter and Blue Sky. And, you know, one ex, one example of this was, Evan You, you know, the Vite creator. Um, putting up a couple of tweets where he said that, you know, like, I, I just don't understand why the React team is refusing to reasonably recommend Veep. [25:26]
-
-And, like, I'm, I'm happy to work with them, I just don't understand where they're going with this and why. And that actually got kind of a positive response. Rather, strongly worded initial response from a couple of React team devs that later got retracted and there were a bunch of follow on discussions. [25:56]
-
-But, it's like, from my perspective, the React team has pretty explicitly stated what their goals are, and no one wants to take those statements at face value, which is Interesting. So last weekend, after like two days after the blog post and the docs updates had gone live, I was sitting around on a Sunday night and I'm like, I could try to offer more feedback and suggestions, but I did that once already and I knew what some of the responses would be and that's why I offered this feedback and they didn't take it and apply all of it. So what if I just take this into my own hands? [26:13]
-
-## [Mark filed a PR](https://github.com/reactjs/react.dev/pull/7618) to rewrite the docs, the React team closed that but [based a new one off it](https://github.com/reactjs/react.dev/pull/7624)
-
-**Mark:** And I actually try rewriting the docs page and the blog post myself to try to get across the same message but with a better tone and actually provide better guidance and instruction on using React without a framework. So, I actually filed a PR a week ago that rewrote the docs page. [26:52]
-
-And the next day the React team actually closed that PR, and I actually got a message on the side from Matt Carroll on the React team who said, you know, like, actually do thank you for doing the work on this, but it's not quite the direction we want to go with it. [27:14]
-
-However, they did then open up a new PR that was explicitly intended to address a lot of the feedback from over the weekend. They did copy and paste several of the sections that I had had in my PR, as well as tweaking some other sections. And this did actually get merged. So, it did not have some of the phrasing and the writing approaches that I felt should be in there, but it is legitimately an improvement. [27:30]
-
-And it does actually meet, I think, a minimum acceptable bar where it says, like, they changed the build a React framework page into build a React app from scratch, which is roughly the phrasing that I had used. And it does actually say, you know, you can use V or Parcel or RSPack and a data fetching library and a router. [27:59]
-
-And so it's giving actual instructions And that is linked prominently from the intro paragraph on the main setup page, and it's linked at the bottom. And the setup page actually explicitly uses the word VEET in a paragraph. And so it's not ideal, it's not the exact phrasing I would want, but they did make a second round of changes. [28:24]
-
-And they did listen to feedback, and I do think it meets a reasonable minimum bar of recognizing that you can use React without a framework, and here are steps to do so. So it's been painful, it's still not exactly what I'd like to see, but I think we've actually reached an acceptable state at this point. [28:47]
-
-**Carl:** Heck yeah. All right, nice that it's ended in that spot. We haven't talked about this, but where have you landed on your giant blog posts? Are you still sitting on those? [29:09]
-
-**Mark:** Yeah, I'm sitting on it, so Like I said, part one was a recap of the history of how the React project has been developed, the influences like Meta and Vercell, as well as, you know, dispelling conspiracy theories like Next is dr or Vercell is driving it just to make money. Part two was all the history of, you know, frustrations and good and bad interactions and everything else. [29:18]
-
-And, you know, part of my goal was to document things, and part of my goal was to drive change. And it's ended up helping with the change, but indirectly. I did show the draft to the React team after a couple of our conversations, they, you know, frankly, they asked me not to publish it. [29:43]
-
-they didn't tell me not to, they said I should consider not publishing, which is. But like, my goal with this was not to burn bridges. Instead, I wanted to push them to make changes to the docs, to make changes to the messaging. And, we talked, and they were listening, and they were in the process of making changes. [30:04]
-
-So I felt that at a minimum, I ought to at least give them a chance to publish the doc updates and see how things would work out, because they were in the middle of that. And so now that they've done some of that, I feel like publishing the post in its current form would be like slamming, hitting them with a sledgehammer after they did some of the thing that I already asked them to do. [30:25]
-
-And that doesn't feel good. So where I'm at right now, is I, I still think the first part the history and the conspiracy theories part is probably worth publishing stand alone, and I can probably just extract that. I feel like there's a lot of useful content in the second part, but I would, I would need to extract and restructure a lot of it, and I haven't had time to sit down and think about it, and frankly, after, I would actually like to think about something else for a while. [30:44]
-
-So, I expect to end up publishing some of that content at some point, but it's not top of my priority list right now. [31:08]
-
-**Carl:** That makes sense. Yeah, I actually did sit down with it and four highlighter pens and I feel like there's like four posts in there. I feel like there's your personal [31:17]
-
-experiences of trying to make changes. There's the, like, summary. Oh, man, just like the oral history you captured of like, here's how things have evolved over the last, like, nine years. [31:25]
-
-I feel like is really useful. But Yeah. So cool. Yeah, go sit on it. Don't think about it. I will come to you with thoughts that I have in a, in a number of weeks. [31:36]
-
-**Mark:** Yeah. So overall, it's been a couple months of, you know, a lot of kind of painful discussion and, and a lot of drama and arguing, but I think we've ended up in a fairly good place by the end of it. So Create React app's officially dead. The docs have been updated. The docs say both, you know, use a framework and those recommendations are updated. [31:47]
-
-But they also say you can build an app from scratch and here's concrete instructions on how to do so. The tone is a lot better. So we've, we've ended up in a fairly good point, but a lot of this has shown that there is a really big gap between, you know, the React team's vision of where they want to go with React versus how a lot of the ecosystem wants to use React and I, I don't think that's going to go away anytime soon. [32:07]
-
-Yeah. And I, [32:37]
-
-**Carl:** Yeah, would agree. That reminds me of, uh, Posts that I put on Blue Sky. Opinions. I feel like the current, like, conflict is a, an example of the different, perspectives, really. Like, in this post, I say it's a clash between the indie hackers, the corporate cogs, and the academics. [32:38]
-
-Where, like, by background, I'm a corporate cog, like, I have always had a large team supporting me. And so, like, I was usually the guy, like, playing around in this code base, trying to make it work better for my colleagues, who were then the ones actually shipping, like, individual features. That's a very different setting than if you are, you know, an indie hacker doing your own things and just trying to ship features and functionality. [32:59]
-
-Which is, again, a very different perspective from, the core team, who I'm considering the academics here. Like, I've said before in this podcast, like, I strongly feel that the React core team is managed more like a research project than anything else. And, you know, I, some signal in that, in that I got some, I think like two or three of the core team members responded to this. [33:24]
-
-It was just like a, like, I'm just going to brag that they saw it and engaged. But yeah, like they have, the core team has had a very stable vision for what React could be really since 2013. Like from the beginning, they've talked about stuff like algebraic effects and functional programming and, you know, encapsulation component models. [33:47]
-
-And if you're like, I've been paying close attention to that. So I feel like I have a reasonably clear understanding of what that vision is and has been. And so like, I can see that it's stable, but I think if you're not paying close attention to what they're doing, you're not watching this research team go. [34:08]
-
-You're off dealing with your own projects, shipping code, building features. You know, setting up processes for your team, then I think that. Vision is actually really hard to gather, like just from resources, from reading the documentation, from reading, from following their social media feeds. I think it's really hard to catch up on what the vision is. [34:27]
-
-So that's maybe a gap currently in like what's available. [34:48]
-
-**Mark:** And I think that ties a lot into something that the team mentioned to us in the couple calls I had with them. So, like, we just said that they have a vision, and that's, that's very accurate and valid. And yet, in a lot of ways, I've learned that the vision is almost like a vague, amorphous thing that they're figuring out as they go. [34:53]
-
-You know, it's not that they have, apparently it's not that, like, literally everyone is driving towards the one true vision all the time. It's that, in a lot of ways, are individuals going off and experimenting with things, and then it's almost every so often they get together and figure out, okay, we've played around with a lot of ideas. [35:13]
-
-do we have a consensus on where we're going? And like, one of the things they said was that, you know, like, I've complained that they put up very infrequent updates on the blog, on, in terms of like, roadmaps and where they're going. Like, they've put up three React Labs posts almost like a year apart. [35:32]
-
-And my assumption reading those was that, oh, well, like, clearly they already know what they're doing, and the blog posts are just documenting that plan. And Matt Carroll said it's actually the opposite. Like, they sort of look around at each other, it's like, we probably ought to put up an update post. What are we working on and do we have agreement on where we're going and so that the blog posts actually take them multiple months to write because it's almost like a forcing function to figure out like and actually nail down where they're headed. [35:51]
-
-So that was actually really really surprising for me to hear. [36:26]
-
-**Carl:** Yeah, and you know what it made me think of? The valve management structure, the flat Non hierarchical, anyone can work on whatever interests them, and if you want to get a project done, you have to pitch it to your colleagues. Which was famously, I don't know, Valve has its own vibe, and I don't know, it's like the vibe of Valve is not super far off from the vibe of React releases. [36:30]
-
-You know, the uh, indefinite delays and lack of communication. So, yeah. [36:51]
-
-**Mark:** So, you know, I, I think we're going to see them continue to push forward. I mean, even just in the last few weeks, seeing Sebastian working on implementing Vue transition support and some other pieces like that, they're going to keep building on these things and it's great to see the forward 19's out, but you know, there, there's a lot of people out there that are just very happy to keep using React essentially the way they have. [36:58]
-
-And there's going to continue to be a mismatch because what they're, well, what they're doing is absolutely valid and fine at a technical level. It's not the direction that the React team is trying to push. And so that leaves a lot of people feeling. You know, left out, unsupported, on the outside, and in the worst cases, concerned that somehow, like, client side React is going to stop functioning someday, just because it's not part of the server emphasis. [37:25]
-
-And I mean, anyone can look at, like, you want to be able to look at that and realize it'll never happen, but it shows you some of the, the vibes and the extrapolation happens that leave people concerned. Um, [37:57]
-
-## [Between the Wires: An interview with MooTools contributors](https://www.freecodecamp.org/news/between-the-wires-an-interview-with-mootools-contributors-33d764957575/)
-
-**Carl:** Yeah, I feel like I re share this every couple of months, but I want to share again this resource from FreeCodeCamp where they interviewed a bunch of the React core team through the lens of let's talk about your past work on MooTools. So, like, this is, a now 8 year old interview with, Sebastian Morkabug, whose name I'm sure I'm saying incorrectly, but it's as close as I can get, Tom, Tom Acino and Christoph Poyer, now, Christoph Nakazawa, I believe. Those are still Major players in the current React world, and they have been collaborating since 2009. So, like, they are coming up on 16 years of working together on foundational tools for the web. Like, I never personally used Mutools. But it was a, you know, meaningful minority use tool competing with jQuery. [38:09]
-
-And it remained relevant because I think in like 2014, 15, something like that, they wanted to do, wanted to release a new array tool, you know, an array primitive. And they couldn't because MooTools hadn't yet been released. But yeah, FlatMap, that was it. That was the one, FlatMap. SmooshGate. They couldn't release the standard because Mutools had monkey patched the Array object with its own FlatMap that was incompatible with the standard, and so releasing this would have broken the web. [39:09]
-
-So, like, this team, the core team, has, more than ten years ago, First hand experience with what it means to engage with standards and what it means to break the web. So, like, that's part of why I give them so much leeway and, like, kudos on their approach. Because, like, they know how bad it is to get it wrong. [39:40]
-
-They know that a decision you made 15 years ago can have lingering echoes. That prevent future work from happening. [40:04]
-
-And like, that's a really hard lesson to learn. It's a really hard lesson to apply. [40:13]
-
-**Mark:** The web is forever. [40:16]
-
-**Carl:** The web is forever. [40:18]
-
-**Mark:** So, it's, one of the other interesting points that came out of the discussions with Matt is that the React docs are very much aimed at beginners. And it's not just the tutorial, it's the setup guides. And I think that's, that's also some of the tension here is that people are not looking at the setup instructions page and saying, Oh, this list of tools is especially oriented for beginners. [40:19]
-
-I know what I'm doing. I can make, make my own choices. And that's fine. People have been looking at that page and saying, well, it doesn't explicitly list VEET. Therefore, the React team must have something against Vite. It's somehow bad to use Vite, et cetera. And in my, in my own draft PR, I had tried to rework some of their, their own paragraphs and phrases into a page on web app architectures to provide some guidance on like, what is a server, like a single page app versus multi page versus SSR versus SSG. [40:48]
-
-When might you want to use one versus the other? As a way of, like, applying some guidance to choosing a build tool. And they don't seem to want to go that direction yet, because it's not, in essence, it's not something a beginner should be worrying about immediately. And so I think that's another piece of the tension. [41:24]
-
-In what people want to see listed in the docs recommendations versus React team actually is willing to cover, which then ties back to the thing that Carl and I have been tossing around, which is, what if we had, A fully community written set of recommendations and docs and guidance for using React in the real world as a supplement to the beginner oriented, getting started level official React docs. [41:46]
-
-So we're still trying to figure out what that might look like and what the content might be. In fact, we're supposed to be talking about it literally right after this, [42:20]
-
-but that's sort of a pitch. Like if the React docs are going to explicitly focus on the beginner use case, then it's kind of up to the community to officially, to quote unquote, officially document what it's like to expand beyond that. [42:28]
-
-And how to use React properly in the real world. It's something that I, I had played around with trying to pitch this kind of a community doc site idea a few years ago. It didn't get off the ground and I'm, I'm hopeful that maybe this time around we can make something like that work. [42:43]
-
-## [How to start a React Project [2025]](https://www.robinwieruch.de/react-starter/)
-
-**Mark:** So as an example of this, Robin Weirich, who's a prolific React author and, tutor, Has put up a number of blog posts over the years with advice on, you know, common React libraries and tools. And so he's updated his post on how to start a React project for 2025 with a set of recommendations. And it's interesting to note how this is different than the actual React Docs setup page, because this one actually starts with prefer using Vite as the starting point. [42:58]
-
-, actually discusses some trade offs, both pros and cons, for all the different tools. Talks about using Next, talks about using Astro, which the React docs don't mention at all. And so it's the same problem space, but a very different approach to describing what your choices are than the actual setup page. [43:30]
-
-And on a similar note, So, with Create React app itself actually being officially deprecated. [43:50]
-
-## [Jack Herrington published `create-tsrouter-app`](https://bsky.app/profile/tannerlinsley.com/post/3lif6fdpzkw2s) under the Tanstack umbrella
-
-**Mark:** Jack Harrington actually put together a Vite based starter kit called Create TS Router App with the idea that it would be a, basically a drop in replacement. For the old create react app command that you get a basically like instead of running create react app, you run create TS router app, you get a Vite based project with TanStack router built in. [43:56]
-
-It has the same starting. Application component content and basically equivalent features, but you're starting with a modern set of functionality. You have routing built in, whereas CRA didn't come with a router. You can expand to file based routing if you want to. So, this has been moved into the TANstack organization, and it's now an official TANstack project, and it feels like a pretty useful tool. [44:23]
-
-**Carl:** Yeah, I actually had talked to Jack, just coincidentally, not about this, shortly before he released that tool. And he, just talking to him about, like, create react app and the legacy of it, I realized that, like, the original, promise of create react app was for it to be an abstraction over your build tool. [44:49]
-
-Over all of the build tools, and I hadn't really considered that that was really kind of, that promise never really realized, like, we, yeah, we had it for a while, but It took years for it to update from Webpack 4 to 5, for instance, and then it never released again. So it would, like, I remember at work arguing in support of using create react app instead of doing our own tooling, because, like, let's just never think about tooling again and just stay within the sandbox and get better. [45:09]
-
-What we need out of it. And that promise just never quite happened. So yeah, I don't know that just Hearing it, hearing this TS router, create TS router tool Build as like sort of a drop in replacement for it It is a drop in replacement for the functionality But it does not even attempt to provide that same kind of like social contract promise of future maintenance Just inaccurate, correct. [45:38]
-
-I mean, Create React app never lived up to that promise either, [46:03]
-
-**Mark:** I would actually have a slightly different opinion. I would say it mostly fulfilled that promise. I would, I would agree that it never, it didn't achieve the goal of eliminating the need to think about build tools. In the cases of like the Webpack upgrade or, you know, the fact that the, The blackboxing of the webpack config meant you needed third party tools to alter the config, etc. [46:05]
-
-So like, it didn't make those parts go away, but it did succeed in giving you a single command that would start a project without having to spend time on creating the build config yourself. Or using a boilerplate project or copy pasting it from your last working config. And that did enable tutorials to just say, run, create React app, and now let's start learning React, which was a big goal, as well as making it actually useful for real world, real world projects. [46:30]
-
-So it didn't eliminate those concerns entirely, but I think it sufficiently succeeded in the goals of not having to think about it just to get started. [47:01]
-
-**Carl:** I would agree with that. I understood it to be, to have a larger scope in mind of being an enduring abstraction that would evolve over time. And that didn't happen. Yeah. Anyway, Yeah. [47:10]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Oh man, we have so many lightning round links [47:24]
-
-**Mark:** Lightning Round! [47:25]
-
-**Carl:** Yeah, cool. All right, we're going to fly through this a little bit. [47:26]
-
-## [Vercel acquires Tremor](https://vercel.com/blog/vercel-acquires-tremor)
-
-**Carl:** Uh, Vercel bought an open source React, toolkit, which is interesting to me. Like, I hadn't heard about this in advance, but like, Tremor is apparently a open source React dashboard tool that was funded by Y Combinator in 2023, and now Vercel has bought them. So like, I don't really understand what it means for an open source library to be venture backed. [47:29]
-
-, but like I'm generally supportive of it. Like I would love it if open source maintainers could paid for the work that they do, which is meaningful and impactful and takes a lot of effort. It's a little bit unfortunate to me that the model by which you can get paid for that work seems to be rich dudes in tech decide that they're going to give you money and then other rich dudes in tech buy that work from you. [47:53]
-
-But yeah, that was just interesting. That seems like an outlier. I have not heard of very many open source tools either getting VC funding or getting acquired. Really, Remix is the only other example that comes to mind. [48:18]
-
-## [Things people get wrong about Electron](https://felixrieseberg.com/things-people-get-wrong-about-electron/)
-
-**Carl:** Yeah, I saw a fun post titled, Things People Get Wrong About Electron. And just sort of a fringe at, you know, a fringe post talking about tech kind of at the margins. [48:29]
-
-Like, I have written a re an Electron app in, like, 2015. Oh my god, 10 years ago. Ugh, I'm so old. But yeah, just, it's neat. It's fun to see such a different context for the web. Definitely recommend checking that out. Just as a, as a curiosity, really. [48:41]
-
-## [Initial Observables support in Chrome 135](https://x.com/BenLesh/status/1893053275995357608), [Observable API](https://chromestatus.com/feature/5154593776599040)
-
-**Mark:** So, there's been a decade long effort to try to get some form of observables baked into the browser. Ben Lesh of RxJS has been beating this drum for years, and it looks like they've finally succeeded in getting some of it. Some form of observables actually baked into the browser. It seems partially limited in scope, partially related to, event handlers, but I think it's at least a starting point for adding this kind of an API directly. [48:57]
-
-And so Ben's pretty excited about that. Also on, also on the note of just, you know, really good deep dive technical articles. [49:25]
-
-## [Why I rebuilt ProseMirror’s renderer in React](https://smoores.dev/post/why_i_rebuilt_prosemirror_view/)
-
-**Mark:** someone who used to work for the New York Times talked about taking the pros mirror rich text editing library, which is partially react related, but partially independent. [49:33]
-
-, and rebuilding the ProseMirrorRenderer directly in React on top of the data structures. Great article, very well written. [49:43]
-
-## [JavaScript Temporal is coming](https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/)
-
-[49:52]
-
-**Carl:** Mozilla had a post at the end of January, about Temporal. JavaScript Temporal is coming. Dates in JavaScript are garbage. They are awful. My favorite example of a specific way they're awful is that they have no concept of time zone. And so every date uses your local system time zone, Which is absolutely awful. [49:53]
-
-If you're trying to do anything involving time in two different locations, [50:13]
-
-**Mark:** is why we've had Moment and DateFunctions and Lexon and who knows how many other libraries. [50:18]
-
-**Carl:** All fine. So Temporal is a new, date standard tool, standard library for JavaScript doing dates and it's coming. I hope it's good. I haven't really played with it. I tend, I don't want to think about dates, so I don't want to think about them any more than I have to. And so I haven't really looked at this. [50:24]
-
-It's coming. It's soon. That was a good post. [50:41]
-
-## [Do JavaScript frameworks still need portals?](https://fullystacked.net/portal/)
-
-**Carl:** this was kind of neat. Do JavaScript frameworks still need portals? React has had portals for a long time for like, rendering stuff like modals or tooltips or popovers that exist like, outside of the hierarchy, quote unquote. Just sort of as a way of rendering something within the component tree, but not having the DOM output be in the same hierarchy. [50:44]
-
-And that comes with all sorts of quirks and weird bits. Like z index can get really weird. Think it's awkward and funky for like cross platform stuff. I don't know how well it works in React Native or, you know, other contexts to make use of these portals. So just like this was a kind of fringe topic, like how often do you think about using React portals? [51:07]
-
-And so just like reevaluating, like, are they still necessary? Do they still, is the problem that they were introduced to solve Still relevant in 2025. And I thought that was a good question to ask regardless of what the answer is. [51:33]
-
-## [What Do We Do with You, Old React?](https://www.manuelsanchezdev.com/blog/what-to-do-with-old-react-upgrading-to-modern-react)
-
-**Mark:** we've had years of migrating from other frameworks to React, and we've now had two or three different eras of different styles of React code. So, now you can migrate and modernize your old React code to modern React code. And so there was a good post called, what do we do with you old React that just gave some quick examples of migrating from things like class components to function components and old Redux to modern Redux and old testing approaches to React testing library. [51:46]
-
-, nothing fancy. A lot of this has been covered elsewhere, but it was a good, useful summary. [52:14]
-
-## [“Records and Tuples” proposal is now “Composites”](https://bsky.app/profile/littledan.dev/post/3liwo57opl22b)
-
-**Mark:** And finally, for the last couple, last few years, we've had a work in progress TC39 proposal called records and tuples, which was an attempt to build fully deeply equal objects and arrays directly into the runtime so that you don't have, so that you could just use like the triple equals operator and it would do like a deep equality comparison of all the fields rather cheaply, rather than having to use a library like immutable. [52:18]
-
-js. And this proposal has apparently just undergone a significant revision. It's, I guess it's no longer even called records and tuples, and instead they're calling the objects composites instead, and you would need to call a specific composite. Equals method to compare them. I saw the tweet, I skimmed through the readme of the summary of the changes, I have not had a chance to look through the slides yet, but it's interesting to see how this proposal keeps evolving. [52:48]
-
-**Carl:** Neat. Super cool. Oh yeah. That was all of our lightning round links in like less than 10 minutes. For sure. Proud of [53:19]
-
-**Mark:** us! [53:24]
-
-**Carl:** Cool. Thank you everyone for joining us. That's all we got this month. We'll be back on the last Wednesday of the month, for real this time, I think. [53:25]
-
-, uh, we'll be back at the end of the month in the live stage here in React to Flux or back in your podcast feed just as soon as we can after that. I try to get it by the first of the month, but not always. We gather sources from This Week in React, Bytes. Dev, React Status, Next. Js Weekly. The React. Js subreddit, here in Reactiflux, and directly from those publishing articles as well. If you see anything newsworthy, definitely let us know in the tech news and reads channel here in Reactiflux, or shoot us an email at hello at Reactiflux dot com, with TMIR in the subject line if you can. I read literally everything that comes in, even spam and whatever, so if you send it, I'll read it for sure. [53:32]
-
-And if this is a show that you get value from and want to support, the best way you can do so is by either submitting a review or telling your friends and coworkers about it. Like, if this was useful, just like, send it to one other person. That would actually do a lot for us. Cool! Thank you so much for joining us! [54:09]
-
-**Mark:** Thanks, appreciate it, and hopefully we'll have less drama to talk about next month. [54:24]
-
-**Carl:** Maybe. [54:28]
diff --git a/src/transcripts/tmir-2025-03.md b/src/transcripts/tmir-2025-03.md
deleted file mode 100644
index 881d8dd..0000000
--- a/src/transcripts/tmir-2025-03.md
+++ /dev/null
@@ -1,563 +0,0 @@
----
-title: "TMiR 2025-03: Next had an auth vulnerability, TypeScript is porting to Golang"
-date: 2025-03-26
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:45](#job-market-fred-data-layoffsfyi)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-- [[01:28](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:29](#react-native-connection-april-3--4-2025-paris-france)] [React Native Connection](https://reactnativeconnection.io/) April 3 \+ 4, 2025 Paris, France
- - [[01:36](#react-miami-apr-17-18)] [React Miami](https://www.reactmiami.com/), Apr 17-18
- - [[01:49](#cityjs-london-april-23-25-london-uk)] [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
- - [[01:55](#appjs-conf-may-28-30-krakw-poland)] [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
- - [[02:06](#cityjs-athens-may-27-31-athens-greece)] [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
- - [[02:13](#squiggleconf-2025-cfp-closes-may-23)] [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
-- [[03:19](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
-- [[04:24](#new-releases)] New releases
- - [[04:26](#typescript-58)] [TypeScript 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/#the---erasablesyntaxonly-option)
- - [[05:00](#typescript-release-with-go)] [Typescript Release with Go](https://devblogs.microsoft.com/typescript/typescript-native-port)
- - [[06:26](#react-native-078---react-19-and-more)] [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
- - [[06:44](#next-152)] [Next 15.2](https://nextjs.org/blog/next-15-2)
- - [[07:07](#tanstack-form-10)] [Tanstack Form 1.0](https://tanstack.com/blog/announcing-tanstack-form-v1)
- - [[07:54](#zeego-v3)] [Zeego v3](https://github.com/nandorojo/zeego/releases/tag/v3.0.1)
- - [[09:04](#material-ui-v7)] [Material UI v7](https://mui.com/blog/material-ui-v7-is-here/)
- - [[09:04](#slot-pattern-for-overriding-internals)] ["Slot pattern" for overriding internals](https://mui.com/material-ui/customization/overriding-component-structure/)
- - [[10:45](#parcel-v214)] [Parcel v2.14](https://x.com/devongovett/status/1902022923764076808)
- - [[12:33](#xstate-store-v3)] [XState Store v3](https://stately.ai/blog/2025-02-26-xstate-store-v3)
- - [[13:11](#better-auth-v12)] [Better Auth v1.2](https://www.better-auth.com/changelogs/1-2)
-- [[14:31](#main-content)] Main Content
- - [[14:31](#lynx-released)] [Lynx released](https://lynxjs.org/)
- - [[14:33](#release-blog)] [Release blog](https://lynxjs.org/blog/lynx-unlock-native-for-more)
- - [[18:20](#security-vulneratibility-in-nextjs-cve-2025-29927001820-original-researcher-report)] [Security vulneratibility](https://nextjs.org/blog/cve-2025-29927) in Next.js: [CVE-2025-29927](https://github.com/advisories/GHSA-f82v-jwr5-mffw)[18:20] [Original researcher report](https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware)
- - [[20:36](#cves-and-the-nvd-process)] [CVEs and the NVD Process](https://nvd.nist.gov/general/cve-process)
- - [[25:03](#postmortem-on-nextjs-middleware-bypass)] [Postmortem on Next.js Middleware bypass](https://vercel.com/blog/postmortem-on-next-js-middleware-bypass)
- - [[27:00](#nextjs-and-coordinated-disclosure)] [Next.js and Coordinated Disclosure](https://sxlijin.github.io/2025-03-23-next-js-and-coordinated-disclosure)
- - [[30:17](#you-should-know-this-before-choosing-nextjs)] [You should know this before choosing Next.js](https://eduardoboucas.com/posts/2025-03-25-you-should-know-this-before-choosing-nextjs/)
- - [[31:37](#react-native-078---react-19-and-more)] [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
- - [[34:27](#react-native-core-contributor-summit-2024-recap)] [React Native Core Contributor Summit 2024 Recap](https://reactnative.dev/blog/2025/02/03/react-native-core-contributor-summit-2024)
- - [[36:42](#typescript-compiler-golang-rewrite)] [TypeScript compiler Golang rewrite??](https://devblogs.microsoft.com/typescript/typescript-native-port/)
- - [[41:23](#github-discussion-and-on-reddit-too)] [Github discussion](https://github.com/microsoft/typescript-go/discussions/411) and [on reddit too](https://www.reddit.com/r/javascript/comments/1j8s441/comment/mh7ms9n/)
-- [[44:50](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[44:52](#jsc-being-extracted-from-rn-core)] [JSC being extracted from RN Core](https://github.com/react-native-community/javascriptcore)
- - [[45:22](#node-modulesdev-v040)] [node-modules.dev v0.4.0](https://bsky.app/profile/antfu.me/post/3ljubvzvwec2w)
- - [[46:00](#fernando-rojo-joining-vercel-as-head-of-mobile)] [Fernando Rojo joining Vercel as Head of Mobile](https://x.com/rauchg/status/1896943726486032783)
- - [[46:41](#next-vs-tanstack-router-vite)] [Next vs TanStack (Router \+ Vite)](https://www.kylegill.com/essays/next-vs-tanstack/)
- - [[47:46](#expos-ai-strategy)] [Expo’s AI Strategy](https://expo.dev/ai/strategy)
- - [[48:39](#laravel-launched-starter-kits-including-react)] [Laravel launched “starter kits” including React](https://laravel.com/docs/12.x/starter-kits)
- - [[49:36](#react-native-enterprise-framework)] [React Native Enterprise Framework](https://enterprise-framework.callstack.com/)
- - [[50:36](#state-of-react-native-2024)] [State of React Native 2024](https://results.stateofreactnative.com/en-US/) [00:00]
-
-**Carl:** Thank you everyone for joining us for the March edition of this month in React, where we recap and digest the recent developments in the ever evolving react and web ecosystem. We are coming to you live here in Reactiflux, the place for professional react developers. [00:14]
-
-And we are supported by infinite red, but more on them later. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I run community programs like these events and build tools to help keep the community operating. [00:28]
-
-**Mark:** Hi, I'm Mark. My day job is working at Replay io, where we're building a time traveling debugger for JavaScript, and also trying to find ways to make AI developers smarter by giving them access to replay runtime data and in my copious amounts of spare time. Outside of that, I do redux stuff. [00:45]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/)
-
-**Carl:** Some early quick hits. My general temperature check on the job market is that it's not good. It seems bad. Layoffs for March are higher than they were in every month, except last month since September, 2024. So that's five months, yeah, that's not great. It seems like hiring is down. Oh yeah. Look at that. The Fred economic data is a continued decline, so that's not ideal. I guess that is software development, job posting, so I wonder if maybe there's like some kind of title shift leading to that decline as well. [01:20]
-
-But yeah, job market not good. So yeah, if you are on the market, I hope you are. I don't know. Good luck. Sorry. [01:28]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Upcoming conferences. [01:29]
-
-## [React Native Connection](https://reactnativeconnection.io/) April 3 \+ 4, 2025 Paris, France
-
-**Carl:** There is React Native Connection April 3rd and fourth in Paris. So if you're in France, definitely check that out. [01:36]
-
-## [React Miami](https://www.reactmiami.com/), Apr 17-18
-
-**Carl:** React Miami. A beloved conference that I have attended several times but will not be at this year. [01:41]
-
-Is April 17th and 18th in Miami, Florida. [01:45]
-
-**Mark:** I'll be hanging out there. [01:47]
-
-**Carl:** now go see Mark. He'll say, Hey . [01:49]
-
-## [CityJS London](https://london.cityjsconf.org/) April 23-25 London, UK
-
-**Carl:** There's City Js London on April 23rd through 25th in London, the uk. [01:55]
-
-## [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
-
-**Carl:** We've also got App JS Conf May 28th through 30th in Cacao Poland. I've heard good things. I looked at going, but it's just can't swing it. Too big of a trip. [02:06]
-
-## [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
-
-**Carl:** CDJS Athens is also gonna be May 27th through 31st in Athens, Greece. [02:13]
-
-## [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
-
-**Carl:** And I'm helping organize squiggle conf, which is coming up much later this year. But their CFP is open, so if you are interested in speaking go ahead. Submit. It's gonna be open until May 23rd. [02:26]
-
-**Mark:** I, I got to attend Squiggle Con last year. I, I also know the organizers, Dmitri and Josh, they're wonderful people. They did a fantastic job for a first year conference last year. Squiggle Conf was great. You should totally try to go. It's in, it's in Boston. [02:40]
-
-**Carl:** It is in Boston. Yeah. Dmitri, his most recent accomplishment that made pretty big waves is he got doom running in TypeScript types, which is bananas, and took like a year and a half and he had to learn all sorts of like compiler and like processor stuff. Yeah. Unbelievable. [02:56]
-
-**Mark:** we should totally toss a link to that in here on general principal. [02:59]
-
-**Carl:** Yeah, we probably should. I don't have one handy. But yeah, super cool. Super impressive. Unbelievable maniacal in fact. But yeah. [03:06]
-
-Yeah, our sponsor you know, bear with us through all of our setup stuff before we get to the real news. We, there's so much news. We've got like a pretty major security vulnerability in next. [03:17]
-
-There's like a couple of new releases to talk about, but yeah. [03:19]
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-**Carl:** We are sponsored by Infinite Red. They are an expert react native consultancy that's been around since 2015. And I actually just saw a post that they put up on LinkedIn where in 2015 they hired 21 people and 14 of those 21 are still there, like 10 year tenure for two thirds of the organization. Like that's impressive. [03:38]
-
-I've been laid off and fired a lot and I appreciate a company that is willing to get let its people stick around. Yeah. They're currently our only sponsor, in part because so few companies do as much as they do for the ecosystem. They host the largest React native podcast. They host the largest US-based React Native conference. Yeah, lots, tons of React native stuff. They very meaningful ecosystem investment. [04:04]
-
-They only do React native and have built over 75 apps for companies from startups to the biggest in the world. And they will work with your team in order to help you develop expertise, not just get code running and dip out. [04:16]
-
-So, yeah. if your company is looking to start a new React native project, definitely check them out. They are at Infinite Red, [04:24]
-
-## New releases
-
-**Carl:** into some new releases. [04:26]
-
-## [TypeScript 5.8](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/#the---erasablesyntaxonly-option)
-
-**Mark:** last month we mentioned the TS 5.8 beta, and so now it's come out as final. The biggest thing here is probably the erasable syntax only flag, which ensures that you're only using TS types that can just be stripped away without having to go through with transation step useful for use with node, for example. [04:45]
-
-**Carl:** Yep, super great. I'm already using something like that in code that I run. It's just nice. I don't know it's nice to not do like a full compilation step. It just lets me cut an entire thing an an entire build tool out of my, outta my local development, which I like. [05:00]
-
-## [Typescript Release with Go](https://devblogs.microsoft.com/typescript/typescript-native-port)
-
-**Mark:** Although on that note, and we'll talk about this more later the TS team has announced that they have finally rewritten the TypeScript compiler itself in another language go instead of TypeScript still in an early preview stage, but they're seeing 10 x speed up and compilation time. And so the trend of converting JS build tools into other languages continues, and we'll, we'll talk about this more in depth later. [05:26]
-
-**Carl:** Probably, we'll talk about it later and we'll then probably continue talking about it later and later and later, because they have said that this is really gonna ship in like TypeScript seven, which by current release cadence [05:40]
-
-**Mark:** Is like two years from now. [05:42]
-
-**Carl:** Yeah. [05:42]
-
-two and a half, three years. So yeah, we, this is gonna be a topic for a very long time. [05:47]
-
-But yeah, they are continuing the trend of rewriting build tools in native and they are disrupting the trend of rewriting JavaScript build tools. rest. Yep. [05:55]
-
-But yeah apparently they chose Go not Rust because the like general ethos, you know, the, the way you write code in Go is more similar than Rust. So they can do like more similar patterns in the code they're offering. So it's more of a one-to-one rewrite rather than like different enough code that it would have different semantics and different, you know, challenges there. [06:19]
-
-**Mark:** And we have a mo. [06:20]
-
-**Carl:** Ammo welcome. That's okay. We're gonna throw you immediately into the hot seat with React Native 78. [06:26]
-
-## [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
-
-**Mo:** So React native 78 is out. Bunch of small things, but we're getting smaller releases and so this one is mainly focusing on React 19 support. So you can get all the React 19 features that you know and love on the web now working on Native World. And we finally get our logs back in Metro. [06:44]
-
-## [Next 15.2](https://nextjs.org/blog/next-15-2)
-
-**Carl:** Cool. Yeah, There's next. 15.2, which, you know, we're gonna talk a lot about next and more later. But um, this looks like not too crazy. A release they redesigned error ui, more streaming metadata, performance improvements, yada yada. Some experimental features as well. [07:02]
-
-And ooh, experimental node js middleware. A lot more on middleware later. [07:07]
-
-## [Tanstack Form 1.0](https://tanstack.com/blog/announcing-tanstack-form-v1)
-
-**Mark:** Tan Stack Form is a brand new form library in the vein of libraries like formic and React Hook form. This one I, I believe, was started by Tanner Winsley himself. The current maintainer is Corbin Crutchley who'd worked on a previous library, I think, called House Form, I believe. But like some of the big selling points are things like type safety, you know, being able to infer that, you know, like when you pass in the name of a field as an argument that all the other callbacks and everything else know exactly what the, you know, the proper value type for that field is. [07:41]
-
-Lotted, different validation options a lot. And working with SSR and other scenarios haven't used it, but it looks fairly comprehensive and worth taking a look at as a, you know, form solution for your apps. [07:54]
-
-## [Zeego v3](https://github.com/nandorojo/zeego/releases/tag/v3.0.1)
-
-**Mo:** Yeah, so Zeego is a library that I quite appreciate. So it's made by Fernando Roho, who very recently actually joined Vercel as their head of mobile, which is going to, which tells us a lot about the direction that Vercel is going in terms of some of their mobile offerings. But Zeego released a new sort of major release. [08:13]
-
-And so the, the big points with this is and just just for a little bit of context, we have talked about Zeego before in the podcast, but just for anyone who might have missed it, Zeego is a library that allows you to create context menus that are native to each platform and it's universal. So what that means is that it will let you create context menus on the web and it defers that to something like rad. [08:34]
-
-Then on native platforms like iOS and Android, you actually get the native context menus that you get on the platform. So those are native elements that are rendered. And it's, it's a really good example of using the same API but getting very different looks and feels that are native to each platform. [08:49]
-
-So it's, it's, it's a, it's a cool library. It's a very nice like utility library that you might need to use when you wanna get some native functionality inside of your mobile app. But the major things with this is just supporting the new architecture and React native and working with some of the new versions of Expo. [09:04]
-
-## [Material UI v7](https://mui.com/blog/material-ui-v7-is-here/)
-
-## ["Slot pattern" for overriding internals](https://mui.com/material-ui/customization/overriding-component-structure/)
-
-**Carl:** Yeah. Material UI has version seven out. Main thing that caught my eye here is they have a slot pattern for overriding the internals of their different, you know, components. Customizing component library components is like the number one reason why I have not extensively used component libraries in my career. [09:25]
-
-I just, like every company I've worked for, they have wanted a greater level of customization than is achievable just by doing things with the component library. I've been very interested in Chad CN for that reason, because it's just like, it's a co generator, not a library. [09:40]
-
-You use it to make components and then you customize those components to your needs. But this looks like a really interesting alternative pattern for it. Basically, it looks like they have a pair of props slots and slot props where a component will specify different slots that you can override. [09:59]
-
-So you can give it different components to put into places where, you know, like in, in a tab or a dropdown or whatever. That's really interesting. That seems good. Generally, it's nice that they are like trying to standardize it a little bit and like have a specification. I appreciate that and it's, yeah. [10:20]
-
-I've seen a lot of libraries do things like add in. Sort of slots. They don't call it that, but like they let you pass in a component that it will use in place of something else or whatever. But I've always seen that as very like ad hoc and like there's no standardization or structure around it. [10:37]
-
-So seeing this as a pattern is interesting to me. It's definitely, definitely interesting. Yeah. That's all I gotta say. [10:45]
-
-## [Parcel v2.14](https://x.com/devongovett/status/1902022923764076808)
-
-**Mark:** The Parcel Bundler released version two point 14, and this is kind of a big deal because it actually adds built-in React server component support. I was actually just looking at the download stats. So parcel has been around for several years. The primary author, Devin Govet, also works on React Aria and React Spectrum and a couple other component libraries. [11:05]
-
-He's put a ton of effort into building it, but it's, it's very much an also ran in terms of actual usage. Like last month, Webpac had 116 million downloads. V had 85 million downloads. Parcel only had 800,000, so non-zero, but obviously not like, you know, anywhere near the level of the other tools. [11:25]
-
-That said it is a, an actual tool in the space and so it is interesting to see what's more of a bundler rather than a framework. Adding React server component support and looking at the examples the usage pattern here looks to be a whole lot simpler than what Next has and, and has put together, you know, next is the, the defacto standard implementation of React Server components at this point. [11:52]
-
-And so I think a lot of us have tended to assume that the way server components work in NEXT is the way that they work, whereas it, it's really more like React exposes the primitives and it's up to the framework or bundler to decide how they get used. So in this case, apparently parcel actually supports using server components, like just within a, like a, like a basic express request handler, which actually looks a lot simpler conceptually. [12:20]
-
-So parcel may not have a lot of actual real world usage, but this looks like a, a, a nice example of what can be done with server component support. [12:32]
-
-**Carl:** That's cool. Oh, nice. [12:33]
-
-## [XState Store v3](https://stately.ai/blog/2025-02-26-xstate-store-v3)
-
-**Mark:** Meanwhile, the, the X State and people, AKA, mostly David Khourshid has released X State Store. Version three. X State Store is meant to be a, a much wider weight state management tool. Kind of more along the lines of a, of a zoo stand, but with a little bit more of a, a state machine twist on it. So there, there's some updates to make the usage and the developer experience a little nicer. [13:00]
-
-**Carl:** Yeah. Love X State. I don't know, I've just always had an affinity for it. They had a, they've always had a great state machine design tool and I found that useful even while not using the library. So I dunno, I just like them. [13:11]
-
-## [Better Auth v1.2](https://www.better-auth.com/changelogs/1-2)
-
-**Carl:** There's Better Auth version 1.2, which is interesting and cool. I have been following Better Off for a while. I haven't actually used it myself yet. But they've been, [13:21]
-
-**Mark:** Theme of this podcast? [13:23]
-
-**Carl:** yeah, a little bit. There's just so many things. It's hard to stay, it's hard to, staying on top of it is hard to know. Actually using all of it as well is uh, impossible. [13:31]
-
-Yeah, I, I, I like the general vibe of it. [13:34]
-
-I have been let down by literally every auth tool that I've ever used. I have written my own auth far too many times because I'm so irritated with trying to use all of the authentications libraries. And yeah, this seems good. I'm just gonna read what bytes.dev said, 'cause they summed it up very well. [13:51]
-
-"It's got Stripe subscriptions, recapture API, keys teams and sub orgs and a new init CLI, and they rewrote the core library to fix TypeScript editor lags. So like, it just seems really good. They've really been on a tear with shipping improvements. Like I, I subscribed to GitHub notifications for them and I slightly regret it because I swear to God I got like five a week with just like beta releases and new minor releases. [14:18]
-
-So it's, it's, I'm impressed at their pace of development. They seem to be doing a really good job of shipping pretty major upgrades as they go. So, if you're doing a greenfield project that needs authentication, consider it. [14:31]
-
-## Main Content
-
-**Carl:** Mo can you tell us about Lynx? [14:33]
-
-## [Lynx released](https://lynxjs.org/)
-
-## [Release blog](https://lynxjs.org/blog/lynx-unlock-native-for-more)
-
-**Mo:** SO this is, this is not specifically React native related, but it's React native adjacent and definitely react related. So, you may have heard that bite Dance, the team behind TikTok released links, and links is effectively sort of a competitor to React Native. They've created another way that to build native applications using JavaScript tooling and using React as the way that you define UIs, which is really cool. [15:01]
-
-And so, the, the real sort of reason why why this is exciting is because this is actually what's powering TikTok behind the scenes. So this is what they're using internally for TikTok. And you know, TikTok is as large scale of an application as comes. And so it's actually quite a. Quite a big deal to have something like this release and it brings healthy competition to the space of sort of cross-platform native applications where it's been traditionally just rack native and flutter. [15:27]
-
-So I think there's some really interesting stuff here. The TLDR is that they have a sort of multi-threaded a multi-threaded architecture in place. And that's one of the things that they really, really empathize, em, emphasize on. And so the whole idea is that this architecture and this multi-threaded runtime allows you to take priority on sort of synchronous UI tasks that are high priority so that the app feels snappy and responsive. [15:52]
-
-And things like event handlings are done sort of with a high priority. This is getting quite similar to the space of sort of what the React native team is trying to achieve with the new architecture, which was trying to. Targets similar benefits. And so they, they give a lot of examples on things like instant first frame rendering, which is one of the metrics that they're trying to target with this architecture to make sure that the first time you open up your app, you get as quick to instant as possible launches. [16:18]
-
-And sort of multi-threaded scripts for when there's a you know, important scrolling event or something that requires really good responsiveness. Having those sort of concepts embedded into the architecture, which is really, really quite cool. And one of the nice things about this is that their JavaScript layer functionality is not actually react specific. [16:36]
-
-So in theory, down the line, albeit React is really the only main way that you can define UIs right now down the line, they may create other versions of it. So currently there's links, which is the core, and then there's React links as well, which is the sort of the React library that you can use to define UIs for links currently. [16:54]
-
-There could be in the future initiatives where it can allow you to use other UI libraries to do this, which can be really quite cool. [16:59]
-
-**Mark:** I think I saw even at least a mention or like someone at least asking like, when can you use Vue with this? And it sounded like that was a thing that they were trying to work on. [17:07]
-
-**Carl:** Interesting. [17:08]
-
-**Mo:** but you know, that in itself is quite powerful because, you know, one of the, you know, there is nothing like rack native or there wasn't anything like rack native where you could use web-based UI libraries to define a mobile app. And so this actually opens up the door for people to use view to make actual native apps rather than sort of PWAs or hybrid web view based apps that are not gonna be good experiences. [17:31]
-
-So, quite exciting stuff. [17:33]
-
-**Carl:** That is really interesting. And it, it's, it's funny that I feel like over the last year we've talked about a couple of projects that we're exploring different ways of authoring react and getting some form of mobile app out of it. And I'm surprised that there's still like new approaches. This, we've seen so many with like, I don't know, react native web and I'm forgetting the names of all of them, but I swear to God [17:55]
-
-Four of React strict dom. [17:56]
-
-Yep. So, okay. Interesting. That sounds really cool. And I like that there's a way, I don't know, just like it, I love the web. I secretly wish that Web os from like 2012 had been a viable option. So it's just, I'm, I'm, I love seeing the web expand more meaningfully into the native arena. That's really cool. [18:17]
-
-Cool. Alright. Into the headline. [18:20]
-
-## [Security vulneratibility](https://nextjs.org/blog/cve-2025-29927) in Next.js: [CVE-2025-29927](https://github.com/advisories/GHSA-f82v-jwr5-mffw)[18:20] [Original researcher report](https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware)
-
-**Mark:** All right. The biggest news story of the month occurred just a few days ago, and that was that there was a major security vulnerability with next's middleware implementation that ultimately allowed any external attacker to send a fairly simple set of headers and force next to skip the middleware. [18:46]
-
-And if you, your app used the middleware to provide authentication to. You could actually just bypass the entire authentication process. So the assumption here is if you're using next to do middleware, and then there's some other caveats around where your app's actually hosted. But ultimately this was rated as an extremely high concern security vulnerability. [19:11]
-
-So Next has released actual, actual fixes across a couple different major versions to try to patch up the issue. There's been. You know, breakdowns of, you know, what the actual bug is and why this is a concern and how it works. And then there's been a lot of fallout from this issue in terms of how did Vercel handle communicating the vulnerability to the general public as well as other partners. [19:38]
-
-And follow on questions like, you know, how does Vercel and next actually kind of handle their development processes? associated pieces to go through with this. So let's, let's try and break some of this stuff down. [19:49]
-
-**Carl:** Let's see what we can do. Yeah. So you, you mentioned how many versions that they shipped. So they, in, in their, you know, blog post, it's very. I don't know, no details, no extra explaining what happened. They explaining the advisory, I guess they, they then put out a, like timeline of the thing and gave a lot more details. [20:09]
-
-But so they released patches for version 12, 13, 14, and 15, which means that this has been a vulnerability since at least 2021, which is wild [20:19]
-
-**Mark:** It sounds sounds like Al, almost exactly, almost since like the, the middleware feature probably came into existence. [20:26]
-
-**Carl:** Which I guess that makes sense. Like you add a new feature and it has vulnerabilities and until somebody notices it, you don't fix it. But wow, four years for an auth bypass based on a header. [20:36]
-
-## [CVEs and the NVD Process](https://nvd.nist.gov/general/cve-process)
-
-**Carl:** So I want to lead in a little bit breaking down like the CVE process, which I am not sure. I feel like everyone, I feel like a lot of people will have a general, I. [20:47]
-
-Awareness of what, of what A CVE is. I didn't quite realize that it was like an NIST national Institute of Standards and Technology Program. Like this is a government program established in 1999 to track, [21:02]
-
-**Mark:** known security bugs. [21:04]
-
-**Carl:** Right. So like, yeah, and it has a, there's a calculator that lets you figure out the severity of a vulnerability. [21:12]
-
-And it has criteria like the attack vector, the attack complexity, the requirements of the attack privileges required, user interaction are required, and then the impact of the vulnerability. It's confidentiality, integrity, availability. It's basically like how do you do the attack and if you execute the attack, what are the impact, what are the effects of it? [21:35]
-
-So this. You know, the scoring criteria for this vulnerability is it's a network attack vector, which means you don't need to be physically present which is bad if you can do it over the network that's like a high level of access. The attack complexity is low, the privileges required are none. [21:54]
-
-The user interaction required is none. And the impacts confidentiality are high, integrity is high but no impact on availability. So you can, you know, get into confidential spaces and, you know, violate the integrity of the data. [22:09]
-
-You so it, it's, it's basically an attack you can do from anywhere in the world that's very simple. That gets you a high level of access, which is why this is a, you know, critical severity bug. That's so bad. Oh my God. Just for a, a bug of that severity to exist for four years before anyone noticed is oof rough. [22:30]
-
-**Mark:** The general concept here is that, you know, middleware can be chained together. But there's, there's internal implementation details around like possibly needing to rerun middleware or possibly needing to skip middleware. [22:43]
-
-And so at some point Versel opted to implement skipping, running middleware by looking for a specific header that they could attach to the request. And the intent was that this would only be an internal thing, that the header would only ever get added by next itself in response to, some piece of code saying, Hey, we're, we're good. [23:09]
-
-We can just keep going. Or I guess maybe to, to, to get rid of loops in the middleware chain. And someone figured out that. You know, wait a minute, I could, I could attach this kind of a header as part of an external request. And the piece of information that next was looking for the, in the header is just a name of the middleware itself, which is pretty much always based on the file you would've added in your next project, which is apparently in some cases like just the literal word middleware. [23:44]
-
-And so you could end up like having a header value of middleware, colon, middleware, colon, middleware, colon or something like that. the end result is that someone could send a request to a next base server, add this header to their original external request, and end up convincing next, skip all the middleware and never run them. [24:07]
-
-And. And so if some of the were trained to do authentication, then the request would end up just skipping that entire process. I believe Vercel said that the way they have their systems architecture set up it was not really possible to have that be a problem on if your app was hosted on Vercel infrastructure. But then there was questions of, okay, well what if you're running on Netlify or CloudFlare or using one of the Open Next adapters? So the bug exists in next, and then there's the question of, well, how is next being hosted and what requests could actually get through? [24:46]
-
-**Carl:** Right, so. I think what I saw is that they're saying if you hosted on Vercel, you were never vulnerable to this because of how we set up our system, which is great. I guess this. Certainly fuel on the fire of like Vercel is privileging itself in the ecosystem. [25:03]
-
-## [Postmortem on Next.js Middleware bypass](https://vercel.com/blog/postmortem-on-next-js-middleware-bypass)
-
-**Carl:** And I guess building on that a bit, so they put out, you know, their postmortem breaking it down and breaking down the response. [25:11]
-
-**Mark:** Which, which came out about like, like two to three days after the actual announcements. [25:16]
-
-**Carl:** Right. And it looks like, you know, in the timeline they talk about like receiving emails and like multiple reports, which delayed the triaging. But like, you know, the core of the timeline, I. [25:27]
-
-**Mark:** A month or something. [25:28]
-
-**Carl:** it looks like somebody reported this at the end of February on the 27th, and then it didn't get triaged until two weeks later, which seems not good. [25:38]
-
-I don't know. I, I, I have done triaging of security vulnerabilities. I was the point person for that at my last job for like two years, a year and a half, something like that. And there's a lot of noise. There's a lot of garbage that comes in. There's a lot of, you know, quote unquote security researchers who are just like running automated tools like nmp. [25:58]
-
-You know, it's like, you know, you are an NPM audit and it's like 63 critical violations and like, none of them actually matter at all. So like, there is a lot of noise and I can understand how triaging might get delayed, but you know, like even just reading the headline, you know, if somebody submits like authorization bypass, like that would wake me up. [26:17]
-
-So, I don't know, just waiting for two week lag time on that is not ideal. [26:22]
-
-**Mark:** One, I mean, one, one bit of that is, it sounds like the initial submission just said, this looks like it's a problem in next, in, next next 12, which was out of date. And so like it sounded like someone may have glanced at it and said, oh, we don't even support next 12 anymore. It's not a big deal. [26:38]
-
-And then the researcher came back and said, actually, it's a problem in like every version of next. And that finally got someone to wake up. [26:46]
-
-**Carl:** for sure right? So, like, okay. Devil's in the details on this as always, but yeah, it's not a great situation. And what's more is that, it sounds like they did no coordinated disclosure. [27:00]
-
-## [Next.js and Coordinated Disclosure](https://sxlijin.github.io/2025-03-23-next-js-and-coordinated-disclosure)
-
-**Carl:** This person talks about some other CVE environments or disclosures that they've either, you know, been a part of seen and for instance, you know, like heart bleed, some of those other like large scale mass impact vulnerabilities, like this is not obviously of that scale, but it is large. [27:21]
-
-So the, the, those ones like heart bleed, they had like multiple months of coordinated disclosure where behind the scenes in secret. You know, once these vulnerabilities are known, the companies are coordinating with each other to say like, are you vulnerable? Yes. Here's how we fix that. Are you? Yes. Okay, let's fix that too. [27:40]
-
-And. What they're claiming is that Net or Vercel did nothing like that. They received a report, they validated it, they pushed their own fixes, and then they went public with it and basically caught other platforms like Netlify, cloud Flare, et cetera, with their pants down. And it was just like, oh shit. [28:02]
-
-You what? What? We're vulnerable. And so now everyone's scrambling. And it's been publicly, it is, it's been publicized. So like now many websites are vulnerable, it's public knowledge and the a patch isn't ready. So like, that's, that's just not nice. it's not collaborative at all for sure. [28:22]
-
-So it, it just means that like, it became a race to fix this before it got exploited in the wild. That's definitely not ideal that like that's, I guess I can understand how a company might say like, this is a problem with our product. We are fixing it. We have fixed it. It is time to go public. I guess I can understand that thought process, but man, as far as like being a participant in a broader ecosystem, that's a big blind spot. [28:49]
-
-**Mark:** yeah. The, that, that link about coordinated disclosure is really good. It, it breaks down what did happen at what times, and then talks about like what are, what are the proper practices for handling a security disclosure? What did, like, what actually happened instead? How did this, like, how did other people end up finding out about it? [29:09]
-
-And then like, what, what would have been a proper sequence of results? Instead, I. So like ultimately, you know, things have sort of been handled here, but really, really badly along the way. [29:24]
-
-**Carl:** Yeah, and I guess one more detail that I'll highlight as part of like, this response was not handled well and maybe went through the wrong channels, the wrong internal channels. when they announced the vulnerability, I. One of their claims as part of it, which is accurate as best I can tell, is that you as our customers of Vercel, were not vulnerable because you were protected by our firewall. [29:47]
-
-So it's like, it feels like it went through the marketing department rather than like, I don't know, engineering, security, whatever, where they were making an honest claim about a differentiating factor. But like part of the differentiating is that they were not collaborating with anyone else to help protect end users. [30:08]
-
-So it's like, yeah, sure that's true, but it's also kind of mean that you did that. So, I don't know. It's not ideal. Not great. [30:17]
-
-## [You should know this before choosing Next.js](https://eduardoboucas.com/posts/2025-03-25-you-should-know-this-before-choosing-nextjs/)
-
-**Mark:** And then one other good blog post related to this somebody who works at Netlify and has spent a lot of their engineering time trained to reverse engineer some of the somewhat more proprietary features of Next to make sure that they work on Netlify. Wrote a very long blog post that. Digs into both, you know, some of the, some of the vulnerability aspects, but then also just general concerns about the way next is developed and deployed and, you know, does not necessarily work with the ecosystem as well as it ought to. [30:54]
-
-Describing a lot, a lot of the concerns, you know, that there, that there aren't, official adapters to run on other platforms that it doesn't have serverless support, that there's certain code paths that really only work on versal. And then also kind of talking about, you know, some of the security aspects. [31:11]
-
-It's not like, it's not a, it's not a flat out indictment, but it's a, it's a very fairly written post from, you know, someone who acknowledges, you know, the own biases upfront, but like, it's a, it's a very valid set of concerns from someone who deals with next, from an external ecosystem perspective. [31:29]
-
-**Carl:** Sure. [31:30]
-
-Yeah. Not a great situation overall, but it's out, it's fixed. That's good. Onto the next [31:35]
-
-um, okay. [31:37]
-
-## [React Native 0.78 - React 19 and more](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
-
-**Mo:** We are back with another release of React Native. And so this one is is focused again, we're, we're going through faster releases now. So you might've noticed if you've been staying tuned for a little while that our release cadence within the React native ecosystem is becoming shorter and shorter, which is great news because it means we get updates quicker. [31:58]
-
-And that's largely due to the new architecture being out now. And so that allows us to basically the, the core of React native is a lot more stable. And so there is there's, there's more of a foundation to release a lot faster, which is great. Other highlights for this release is React 19 is now available on React Native, which is great. [32:17]
-
-So if you, you know, followed along with the previous React 18 implementation for React Native, you will have been aware that it took years to get it up to date with all of the React 18 features, largely because of the new architecture not being out fully. And so now you can see there's much of a smaller lead time to get React 19 support. [32:38]
-
-So all of the new sort of features of React, things like actions use, optimistic, the use hook, all of that stuff, and, you know, not needing to use forward ref anymore. All of that stuff is there now. On top of that the React compiler support is is now there. So you can actually install the compiler, configure it, and it should be able to work just as you would on the web, which is awesome. [32:59]
-
-The, probably the most, important feature for the community though is that they've brought back JavaScript logs in your metro bundler. So this was one of the things that the react native team did last release was they removed logs being shown in your JavaScript bundler. So they were trying to push people to use the react dev tools that they released, or the new dev tools that they released for the React native ecosystem only to face the most crazy amount of backlash from the community because their logs had moved. [33:27]
-
-And people were very unhappy about that. So, they rolled back that. you can pass on a flag now and basically get the logs showing in your bundler once again, like it was for the last. However many years React native has been out for. And so they have said that they will eventually remove this again. [33:43]
-
-But they're trying to give a little bit more time for people to adjust to using the new dev tools. So we'll see how that goes when that happens. Once again, there's some other minor changes, but those are really the big things that's worth mentioning. And I think we're gonna get a lot more React native releases happening a lot more regularly since the new architecture is up. [34:00]
-
-**Mark:** Sounds like a pretty substantial set of changes. [34:02]
-
-**Carl:** And it's cool that they are able to release more quickly, to keep better aligned with the, you know, main mainline react version. I hadn't really registered that as a benefit that would come out of the new architecture, but it makes sense, especially while they are effectively maintaining two versions, you know, new architecture, old architecture, suddenly only have to do the new architecture. [34:25]
-
-That makes a lot of sense. That's super cool. [34:27]
-
-## [React Native Core Contributor Summit 2024 Recap](https://reactnative.dev/blog/2025/02/03/react-native-core-contributor-summit-2024)
-
-**Mo:** So the, the next thing that I, I thought I'd just drop in here. it was technically published in February, but I think we missed it and I, I wasn't around in February is the React Native Core contributor Summit for 2024. The recap was finally released. So this is an article on the rec native dev blog. [34:43]
-
-I actually co-authored this. So last year in SLA in in Poland, I think it was around September we had the React Native Core Contributor Summit, which is a, a full day workshop. Talking about a bunch of different. Things that are strategic to React native in general. And one of the things we talked about was the release process. [35:02]
-
-We talked about, you know, what's the next big thing after the new architecture. So there was a bunch of different sessions and we split off. There was a session about how do we bring web APIs into, into to, to the React native world to standardize some of the APIs for interacting with the native layer. [35:15]
-
-So a lot of really interesting stuff. We talked about Nitro modules, which is sort of, we've talked about several times in the last few sort of podcast episodes outta tree platforms and react native on desktop. I held a session as well, so I led a session during this during this core contributor summit lean Core 2.0. [35:31]
-
-So just for a bit of context lean core, was an initiative in the React native ecosystem back in 2019. And so the goal of Lean Core was to bring down the surface area of React Native's, core APIs because there was just so much stuff in there. Like somebody needed access to something in IOS's specific APIs and they just create a component and pop it into React Native Core and that would just be a part of maintenance burden for the core React native team. [35:56]
-
-So there wasn't much strategic direction around what goes into core and what goes into sort of community packages. And so they went through this effort in 2019. But the goal of the session this time around was actually, I think we we're due for another cleanup. 'cause there's a lot of random stuff there that is either props in certain core components that are tying specifically to Android or iOS, or there's just some components that don't get used anymore because there's much better components in community libraries that you can use. [36:23]
-
-And most people end up using those. So it was a good conversation around what should be deprecated in the long run. And so that's one of the sessions that I think was quite fruitful. And I say that probably being quite biased because I was the person who hosted the session. But yeah, that's a, that's a summary about the uh, the React Native core contributor Summit from last year. [36:39]
-
-If you're interested please feel free to go and, and read the article. [36:42]
-
-## [TypeScript compiler Golang rewrite??](https://devblogs.microsoft.com/typescript/typescript-native-port/)
-
-**Mark:** Alright, so the other really big piece in and piece of news for not just the React ecosystem, but the web development ecosystem as a whole is the, the TypeScript team has officially announced that they have created a fort, not a rewrite of the TypeScript compiler, the current version of TypeScript itself is written in TypeScript, which means it's actually, you know, in the end it's the, it's just JavaScript executing and they have ported the compiler itself to be written in. [37:14]
-
-Go. And what they say in the announcement is that they're seeing like generally 10 x speedups in the actual TypeScript compilation stage of processing people's programs. I saw at least one post on Reddit where someone was complaining that people are gonna be confused. That this means that they think that this means their code runs faster. [37:34]
-
-It's like, no, this is just compiling the TypeScript types 10 times as fast. And this is a really big deal. this trend over the last five, six years of all these different JavaScript ecosystem build tools being rewritten in native languages, mostly rust, and getting a lot of speed ups that way. [37:53]
-
-So, you know, es e es build as in go you know, RS pack and roll down are both written in rust, et cetera. I mean, a lot of tools being rewritten in native languages to try to speed things up, but a lot of them have still, like the actual build pipelines still get bottlenecked on TypeScript compilation time because it doesn't matter how, how fast you can process all these different, you know, individual module files and bundle them together if you're still doing a full type script type check during that section of the build phase. [38:29]
-
-And so there's been a bunch of attempts to rewrite the TypeScript compiler. I. Into native languages from random people in the ecosystem. The author of SWC had tried to do a couple different attempts at porting. One in rust, one in go. I saw somebody who had done one with trying to, trying to create some kinda like a stack based virtual machine to process the types, and he'd gotten like a baby example working that seemed way faster, but it was only for, it only worked for very, very simple types. [39:01]
-
-So, I mean, there, there's been attempts from individuals, but none of these got anywhere past, like a modest proof of concept stage, like they proved they could work, but then it's a massive amount of effort just to catch up with where the TypeScript compiler is much less keep up with where it's going on a month to month basis. [39:21]
-
-And so, you know, a lot of people had said that, well, it feels like the only way this would actually happen is if the TypeScript team themselves actually decides to do it. Well, it turns out the TypeScript team decided to do it about a year ago, and they've been working on this in secret, and now they've gotten this far and proven it works and are actually intending to push this forward to become, you know, the actual TypeScript compiler down the road. [39:49]
-
-as Carl mentioned, so right now we're on TypeScript 5.8. They put out quarterly ish releases, I think. So basically four, four releases a year. They also follow a kind of a, a, a decimal based versioning system where it's not really SemVer, but they just roll over from 5.8, 5.9, 6.0, 6.1. So they've said that the plan is that the new native go compiler will probably officially become TypeScript 7.0. So that means we probably have about two to three years before that actually happens officially. [40:26]
-
-**Carl:** But they may also just release it like when it's ready. I, I don't believe that the version seven is a firm commitment. So it, maybe, it will, maybe validating it, maybe making sure that it won't break. Everything will happen faster than they expect, and it may be [40:42]
-
-**Mark:** I mean, they, they, they might like, they, they might end up going from like a six four to a 7.0 instead of having to get through 6, 4, 5, 6, 7, 8, 9. [40:52]
-
-**Carl:** Okay. I don't know. I thought they just did straight up incremental and when they got to nine they incremented, [40:57]
-
-**Mark:** right, right, Like, so my, my point is that if it's ready in say one year from now, we would be at TypeScript 6.2, and rather than officially waiting another two years and eight more releases to get to 7.0, they might just say, okay, yeah, this is the end of the line for the old compiler here. [41:15]
-
-**Carl:** yeah. Hard to say. Who knows? I do wanna, I wanna highlight a couple of, you know, comments from the people who worked on this. [41:23]
-
-## [Github discussion](https://github.com/microsoft/typescript-go/discussions/411) and [on reddit too](https://www.reddit.com/r/javascript/comments/1j8s441/comment/mh7ms9n/)
-
-**Carl:** Ryan Cavanaugh put out a great Reddit comment describing why they chose go, basically. And, you know, we kind of talked about it a little bit, but I, I wanted to enter his words into the cannon a little bit here. [41:36]
-
-**Mark:** I was shocked at how much pushback there was, especially from the C sharp folks. Oh my word. The C sharp community was up in arms about why the Microsoft engineers did not pick C Sharp as the language for the new compiler, [41:51]
-
-**Carl:** Yeah, sure. I, the amount of space in my brain that C sharp developers occupy rounds to zero. So anytime they come on, I am a little surprised. But yeah. So like, I wanna, I wanna try and pull out a good quote here. So, like, really their primary goal here was portability. They don't wanna rewrite anything. [42:09]
-
-They would like to adapt it into a new faster language. So they really say portability was always a key constraint here. As we thought about how to do this, we tried tons of approaches to get a representation that it would've made the port approach tractable and rust. But all of them either had unacceptable trade-offs or devolved into write your own garbage collector style strategies. [42:28]
-
-So right, like they, it looks like they really genuinely validated trying to use multiple languages here at least between Rust and go. And they say, [42:38]
-
-**Mark:** I think I saw mention they also tried in c as well, okay, in this post, but elsewhere. [42:42]
-
-**Carl:** yeah, sure. That makes sense. I saw a quote that I liked. " In our opinion, rust succeeds wildly at its design goals, but quote is straightforward to port to rust from this particular JavaScript. Code base is very rationally not one of its design goals. It's not one of goes either, but in our case, given the way we've written the code so far, it does turn out to be pretty good at it." [43:01]
-
-So like basically they chose to write code in a style that happens to align thematically with Go. And so when they chose to port it, it ended up working out pretty well. [43:11]
-
-**Mark:** one of the key points here is that like anyone who's actually worked with a lot of TypeScript types or has dared to peek inside the TypeScript compiler, I. Is aware that there, there are a lot of very complex and very subtle behaviors of TypeScript and you know, one of the complaints about TypeScript for years is that there is no official spec for the language itself and how everything should work. [43:36]
-
-It's pretty much just, well, the spec is what the compiler does for this release and that's it. So in other words, the, the spec is the tests that they have. It's not an official language design document. because of that, if you try to rewrite the compiler in another language and you kind of start from scratch, you run the risk of ha of like trying to do things the same way. [44:05]
-
-But the code ends up being kind of different. I. Then you end up getting literally different output from the rewrite of the compiler, which would be really bad for the entire ecosystem that is depending on the compiler to return consistent type results. And so one of their conclusions was go allows us to make an almost literal one for one line for wine port of the exact data structures and the exact logic that we already have written in TypeScript. [44:36]
-
-And so that guarantees that we should get exactly the same calculation results from the new compiler just faster. Faster. So that was a really, really big consideration here. [44:49]
-
-**Carl:** Definitely makes a lot of sense. [44:50]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Cool. Okay. Onto the lightning round. [44:52]
-
-## [JSC being extracted from RN Core](https://github.com/react-native-community/javascriptcore)
-
-**Mo:** first one JSC is being extracted from React Native Core. So, several years ago there was a custom JavaScript engine that was introduced into React Native called Hermes. [45:01]
-
-That's what everyone has been using for the last several years, or most people have been using for the last several years. There are some people who still use JSC for very specific niche use cases. And so it was inside of the reactive core package up until recently when it's been extracted out. [45:16]
-
-So if you want to use JSC instead of Hermes, it is now an external package and you're gonna need to install it separately. [45:22]
-
-## [node-modules.dev v0.4.0](https://bsky.app/profile/antfu.me/post/3ljubvzvwec2w)
-
-**Carl:** This is very small, but seems neat. I'm just going to call it out. Anthony Fu put out a node modules dev, which just seems kind of cool. It's like a way of analyzing the dependency tree for a specific node module. It seems cool. I have had to do various ways of visualizing dependency trees a number of times throughout my career, and it's always been a pain in the butt. [45:47]
-
-So just seeing a tool that's online, on the internet where you can just like plug it in and analyze it visually is very cool and interesting to me. Seems good. I like it. [46:00]
-
-## [Fernando Rojo joining Vercel as Head of Mobile](https://x.com/rauchg/status/1896943726486032783)
-
-**Mo:** next up on the lightning round is that, as we mentioned a little bit earlier on in the episode, a little bit of a, of a spoiler. Fernando Roho has joined Vercel as the head of mobile. [46:10]
-
-And so this is a very interesting development because Vercel traditionally was very web focused. Expo was traditionally mobile focused. So those were the two frameworks. And it seems like they're starting to bleed into each other's territory, which is gonna get really, really interesting. So that is that's gonna be quite an interesting one to see because maybe Vercel is working on a framework for React Native. [46:32]
-
-And we know that the Expo folks have been working on sort of web-based support as well, so we will see on how this develops. But it's just an interesting signal from the Vercel folks. [46:41]
-
-## [Next vs TanStack (Router \+ Vite)](https://www.kylegill.com/essays/next-vs-tanstack/)
-
-**Carl:** Kyle Gill put out a next JS versus Tan Stack article, which he at the very start says, was inspired by a 2019 post from Jared Palmer contrasting Gatsby with next js. [46:55]
-
-I highlight that because Jared Palmer currently works at Versal. Fun fact, I interviewed with him for a job in 2017. I did not get it. And 2019 when Jared Palmer wrote that Gatsby versus Next Post I feel like was about the turning point for Gatsby enthusiasm starting to die off. That's when mine started to die off for sure. [47:17]
-
-So that, it's, it's interesting seeing that he is calling back to that moment, in this moment in a pretty different direction. So we'll see, you know, who, who knows if that same trend will continue, but it's, it's, it looks like a great comparison of functionality between Next and Tan Stack. And Tan Stack is certainly getting a lot of interest in mind share. [47:42]
-
-So yeah, if you're thinking about it, definitely check that out 'cause it seems nice. [47:46]
-
-## [Expo’s AI Strategy](https://expo.dev/ai/strategy)
-
-**Mo:** Cool. Next up there's a blog post that the CTO of Expo did on their AI strategy. it's quite a short blog post so you can kind of skim through it. But really the point they're trying to make is that we're in an age that you can use AI to democratize building apps. And so they talk about how they're gonna take efforts to make sure that their docs and, you know, all of their material is well suitable for things like the model context protocol, the MCP that philanthropic released but also other sort of, protocols and interfaces that AI agents may use. And then they talk about how Expo is being used by tools like Repli by Bolt and other tools already to build apps from prompts so that, you know, non-technical people can sort of, as we say today, vibe code their apps. But I think they, they're really seeing this as a uh, as an opportunity to, to get people to build apps. [48:37]
-
-The everyday person who's not a developer to be able to build apps. [48:39]
-
-## [Laravel launched “starter kits” including React](https://laravel.com/docs/12.x/starter-kits)
-
-**Carl:** Laravel just released starter kits this month including some for React. So that's interesting. They're doing, like, I, it looked like it included server-side rendering. I'm not sure if that is owned by Laravel or React but just interesting. [48:54]
-
-I don't know. I, Laravel is maybe on my mind because I was seeing a number of months ago some conversation discussing what you get out of the box with tools like Laravel and the general lack of anything comparable in the React ecosystem. Specifically around auth. I saw people talking about what you need to, what you get for free with a tool like Laravel. [49:18]
-
-And I was a little bit surprised because you do not get that for free. In my experience when you're building an app with React, so that just gave Bit, gave me a bit of a respect for the, the, the tool. So it seems neat. It's a new major version, version 12. It's got starter kits. One of the starter kits uses React. [49:34]
-
-It claims server-side rendering support. [49:36]
-
-## [React Native Enterprise Framework](https://enterprise-framework.callstack.com/)
-
-**Mo:** So next up, call stack, the folks behind React Universe Conf and libraries like React Native Paper, have announced that they're creating a new React native framework that's specifically targeting enterprise. [49:49]
-
-Now, this is very early days. They're trying to target some of the pain points that enterprise clients with large, large number of you know, devs and with restrictions on where they can host their infrastructure are facing. And so they want to try to target that niche of React native apps which is quite interesting. [50:07]
-
-And so, this is still very much in sort of waiting list stage. So it's, it's early days. But their, that, their start focus is that you can have reusable cloud builds that run on anywhere. Potentially GitHub actions but potentially also other pipeline providers. And also a nice way to be able to integrate Brownfield into existing iOS and Android apps so that you have an incremental migration path. [50:30]
-
-So, very early days, we'll see. We'll see where we, where we, where this kind of develops and, and, and where this goes. [50:36]
-
-## [State of React Native 2024](https://results.stateofreactnative.com/en-US/)
-
-**Mo:** And last on our list is the State of React native 2024. So this is a survey that the folks at Software Mansion do every single year and they touch on a whole bunch of stuff like dev backgrounds, demographics, what libraries people are using, and what you use for state management and all of that. [50:52]
-
-And so, this year the main things that they're that they basically concluded, which is, is kind of no surprise whatsoever, is the um, expos becoming sort of the main way to build react native apps. And they see momentum with tools like Chrome, the, the, the Chrome dev tools, protocol based new React native dev tools that Meta's announced and tools like Expo Atlas. [51:14]
-
-But take a look into it if you're interested in. Analyzing the trends in the React native ecosystem. [51:19]
-
-**Carl:** Alright, thanks everyone. That's everything we got. We will be back on the last Wednesday of next month in April on the 30th. come join us on April 30th here in the live stage, or we will be back in your podcast feed just as soon as we can. [51:33]
-
-**Mo:** Yeah, well, always a pleasure guys, and looking forward to jumping on in April to see you all there. [51:40]
-
-**Mark:** Likewise. [51:41]
-
-**Carl:** Cool, see you then. We gather sources from this week in React bys.dev, react status next JS weekly, the React JS subreddit here in reactive flux, and sometimes even directly from those publishing articles. If you see anything newsworthy, definitely let us know in the Tech reads, tech News and Reads channel here in reactive Flux. [52:00]
-
-Or you can send me an email at hello@reactiflux.com. I read everything that comes in, even if it gets marked as spam, so don't worry. If this is a show that you get value from and would like to support, best way to do so is by telling people about it or by submitting a review on whatever platform that you listen to it.
-
-Thanks for listening. See you next month. [52:16]
diff --git a/src/transcripts/tmir-2025-04.md b/src/transcripts/tmir-2025-04.md
deleted file mode 100644
index 629d510..0000000
--- a/src/transcripts/tmir-2025-04.md
+++ /dev/null
@@ -1,504 +0,0 @@
----
-title: "TMiR 2025-04: React 19.1 helps debug owner stacks"
-date: 2025-04-23
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- Quick hits
- - [[00:52](#job-market-fred-data-layoffsfyi-trueupio)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
- - [[01:50](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:53](#appjs-conf-may-28-30-krakw-poland)] [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
- - [[01:59](#cityjs-athens-may-27-31-athens-greece)] [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
- - [[02:04](#react-summit-june-13-17-amsterdam-nl)] [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
- - [[02:09](#react-conf-is-back-oct-7-8)] [React Conf is back](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Oct 7-8
- - [[02:22](#squiggleconf-2025-cfp-closes-may-23)] [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
- - [[02:37](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
- - [[03:24](#new-releases)] New releases
- - [[03:27](#animejs-v4)] [Anime.js v4](https://animejs.com/)
- - [[04:03](#rn-v79)] [RN v79](https://reactnative.dev/blog/2025/04/08/react-native-0.79)
- - [[05:00](#nextjs-153)] [Next.js 15.3](https://nextjs.org/blog/next-15-3)
- - [[05:20](#rspack-joins-the-nextjs-ecosystem)] [Rspack joins the Next.js ecosystem](https://rspack.dev/blog/rspack-next-partner)
- - [[06:29](#react-aria-april-11th)] [React Aria April 11th](https://react-spectrum.adobe.com/releases/2025-04-11.html)
- - [[07:13](#redux-toolkit-27)] [Redux Toolkit 2.7](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.7.0)
- - [[07:44](#vitest-31)] [Vitest 3.1](https://github.com/vitest-dev/vitest/releases/tag/v3.1.0)
-- [[07:55](#main-content)] Main Content
- - [[07:57](#react-labs-view-transitions-activity-and-more)] [React Labs: View Transitions, Activity, and more](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more)
- - [[22:04](#react-191)] [React 19.1](https://github.com/facebook/react/releases/tag/v19.1.0)
- - [[22:53](#one-react-mistake-thats-slowing-you-down)] [One React mistake that's slowing you down](https://www.epicreact.dev/one-react-mistake-thats-slowing-you-down)
- - [[26:12](#advanced-react-component-patterns)] [Advanced React Component Patterns](https://kentcdodds.com/blog/advanced-react-component-patterns)
- - [[26:54](#improvements-in-expo-using-owner-stack)] [Improvements in Expo using owner stack](https://github.com/expo/expo/pull/35866)
- - [[27:48](#dan-abramov-is-writing-again)] Dan Abramov is writing again
- - [[29:09](#react-for-two-computers-complement-to-his-react-conf-talk)] [React for Two Computers](https://overreacted.io/react-for-two-computers/) (Complement to [his React Conf talk](https://www.youtube.com/watch?v=ozI4V_29fj4))
- - [[29:26](#jsx-over-the-wire)] [JSX Over The Wire](https://overreacted.io/jsx-over-the-wire/)
- - [[30:11](#impossible-components)] [Impossible Components](https://overreacted.io/impossible-components/)
- - [[35:28](#dont-ruin-his-process)] [don’t 👏 ruin 👏 his 👏 process](https://bsky.app/profile/danabra.mov/post/3lmi3gpiluk2m)
-- [[35:47](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[35:48](#nextjs-rfc-deployment-adapters-api)] [Next.js RFC: Deployment Adapters API](https://github.com/vercel/next.js/discussions/77740)
- - [[36:23](#flightcontroldev-from-last-year-secret-knowledge-to-self-host-nextjs)] flightcontrol.dev from last year: [Secret knowledge to self-host Next.js](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)
- - [[36:38](#styled-components-in-maintenance-mode)] [Styled-Components in maintenance mode](https://opencollective.com/styled-components/updates/thank-you)
- - [[37:15](#rip-styled-components-now-what)] [RIP Styled-Components. Now What?](https://fadamakis.com/rip-styled-components-now-what-a8717df86e86)
- - [[38:50](#redwood-announces-new-cloudflare-based-rsc-sdk-existing-framework-in-community-maintenance-mode)] [Redwood announces new Cloudflare-based RSC SDK](https://redwoodjs.com/), existing framework in community maintenance mode
- - [[40:18](#tc39-kills-records-and-tuples-proposal-possible-alternative-is-composites)] TC39 kills [Records and Tuples proposal](https://github.com/tc39/proposal-record-tuple/issues/394). Possible alternative is [“Composites”](https://github.com/tc39/proposal-composites)
- - [[41:36](#react-compiler-rc)] [React Compiler RC](https://react.dev/blog/2025/04/21/react-compiler-rc)
- - [[42:29](#just-use-vite-with-the-workers-runtime-vite-on-cloudflare)] ["Just use Vite”… with the Workers runtime](https://blog.cloudflare.com/introducing-the-cloudflare-vite-plugin/) (Vite on Cloudflare)
- - [[44:21](#silk-library---native-like-swipeables-for-the-web)] [Silk Library - native-like swipeables for the web](https://silkhq.co/)
- - [[45:22](#transitions-fstate)] [\{transitions\} = f(state)](https://jordaneldredge.com/blog/transitions-f-of-state/)
- - [[45:51](#tailwind-4-bun-and-old-macs-a-supermarket-bag-and-a-truckload-of-fomo)] Tailwind 4, Bun, and old Macs: [A Supermarket Bag And a Truckload Of FOMO](https://blog.julik.nl/2025/03/a-little-adventure-in-modern-frontend)
- - [[46:47](#introducing-firebase-studio)] [Introducing Firebase Studio](https://firebase.blog/posts/2025/04/introducing-firebase-studio/)
- - [[49:05](#gumroad-is-open-source)] [Gumroad is open source!](https://gumroad.gumroad.com/p/gumroad-is-now-open-source)
- - [[49:50](#automattic-laid-off-16-of-staff)] [Automattic laid off 16% of staff](https://automattic.com/2025/04/02/restructuring-announcement/)
-
-**Carl:** Thank you for joining us for the April edition of this month in React, where we recap and digest the recent developments in the ever-evolving reactive web ecosystem. [00:07]
-
-We are coming to you live from Reactiflux, the place for professional react developers, and we are supported by Infinite Red, a consultancy that works exclusively in React Native. I am Carl. I'm a staff product developer and freelance community manager here at Reactiflux, where I do community programs like these and build tools to help keep the community operating. And I might oversee a hackathon next month. So yeah, keep an eye out. [00:30]
-
-**Mark:** I'm Mark. My day job is working at Replay io and in my free time I spend entirely too much stuff and time working on Redux and griping about the React docs. [00:39]
-
-**Mo:** And I am Mo, I had the mobile team at Theodo. And I am an active member of the React Native ecosystem and organized the React Native London Meetup and the React Native London Conference. Happy to be here as always. [00:51]
-
-**Carl:** Heck yeah. [00:52]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
-
-**Carl:** Very quick overview of job market stuff. I found a new data source that I don't know how I hadn't heard of it before 'cause it is not super new. trueup.io has a job trend page that looks pretty good. similar but distinct from layoffs.fyi. [01:05]
-
-They are saying that there's been a little uptick of open tech jobs. But you know, there's also been a bunch of layoffs. Although this month most of the layoffs are coming from Intel, which yesterday had a bunch of reports filter out saying they're gonna lay off 20% of staff. [01:23]
-
-But like 20% of staff in Intel probably means a lot of manufacturing jobs, not like software tech. So I don't know what that means, but yeah. I don't know. Vibes are still bad. One thing I like about TrueUp is that they have a, like remote index where it estimates what percentage of available jobs are remote friendly And that has been trending down, sadly. [01:45]
-
-It's slightly sub 20% right now, which is, not great. Yeah. [01:50]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** So upcoming conferences in May! [01:53]
-
-## [App.js Conf](https://appjs.co/) May 28-30 Kraków, Poland
-
-**Carl:** At the end of May, May 28th through 30th in Krakow Poland, we have App.Js conference [01:59]
-
-## [CityJS Athens](https://athens.cityjsconf.org/) May 27-31 Athens, Greece
-
-**Carl:** . There's also City JS Athens around the same time. May 27th through 31st. [02:04]
-
-## [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
-
-**Carl:** Then in June we've got a React Summit in Amsterdam. [02:09]
-
-## [React Conf is back](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Oct 7-8
-
-**Carl:** This is very early, but the React core team has announced that React Conf will be back this year. last year. It was when I was in May. this time last year I was in Vegas for that, but yeah, they're doing it you know, mid-October. So that's cool. [02:22]
-
-## [SquiggleConf 2025 CFP](https://2025.squiggleconf.com/cfp) closes May 23
-
-**Carl:** there's an open CFP that closes one month from now for squiggle conf, which I am on staff for. if you would like to maybe speak at a conference. It's a great conference. I love it. It's organized by a, you know, a good buddy of mine. Yeah, definitely check that out. [02:37]
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-**Carl:** And of our sponsor read, we are sponsored solely right now by Infinite Red, which is an expert React native consultancy that's been around since 2015. [02:46]
-
-They're our only sponsor, partly because very few companies do as much as they do for the whole React and React native ecosystem. They host podcasts. They run conferences, they sponsor all sorts of different organizations generally just seem like really great people. They're a team of about 30 people, mostly developers, mostly with more than 10 years of experience. [03:06]
-
-And they will work with your team to help you develop react native expertise rather than just doing contract engineering and then saying, here you go, this is your problem now. So if your company is looking to start working on a React Native app in the near future, definitely reach out to them and give them a shout. Yeah. Cheers. [03:24]
-
-## New releases
-
-**Carl:** Okay, running through some new releases. [03:27]
-
-## [Anime.js v4](https://animejs.com/)
-
-**Carl:** This is only tangentially react related, but anime js a animation library, or they describe it as an animation engine. Just had a V four release and the website is super slick. Definitely a phenomenal advertisement for what you can do with the tool. [03:46]
-
-Very impressive. And animations are always, I don't know, doing high level animations with like a bunch, you know, interactive and different layers, and it, it's always complicated. So this looks like a pretty great tool. So wanted to give it a shout out. Yeah. Mo, can you tell us a bit about the latest React native. [04:03]
-
-## [RN v79](https://reactnative.dev/blog/2025/04/08/react-native-0.79)
-
-**Mo:** react native version 0.79 has been released. There's. Sort of some small changes here. The big one is that the JavaScript engine, JSC that previously used to be the default is now actually being removed completely from react Native Core and being moved to a community package and is effectively really being deprecated. [04:21]
-
-The few other changes some improvements to performance with Android, but all in all, as we'll see, and as we've seen in the past few months with React native releases, they're getting slimmer and a lot more frequent. So this whole idea of sort of continuously releasing React Native rather than having a few Big Bang releases, so good to see that it's chugging along. [04:40]
-
-**Carl:** Yeah. Very cool. I saw this is their third release this year, whereas in the past , they've generally done like three releases in any given year, [04:48]
-
-**Mo:** I think the trend is going towards doing a release every two months or so. [04:52]
-
-**Mark:** That's a pretty solid cadence. [04:54]
-
-**Mo:** Yeah. I think they've really taken a lot of steps over the last two years to try to bring down that release time and it's starting to pay off. [05:00]
-
-## [Next.js 15.3](https://nextjs.org/blog/next-15-3)
-
-**Mark:** Next 15.3 is out. Biggest news for this one is they now have alpha level support for using the turbo pack bundler for production builds. Previously, it had only been available for dev mode. So it looks like there's alpha level version for that. they have it passing most of their tests, but it's apparently not ready yet. [05:20]
-
-## [Rspack joins the Next.js ecosystem](https://rspack.dev/blog/rspack-next-partner)
-
-**Mark:** Also 15.3 now has support for optional using the third party RS Pac Bundler. I. For builts RS Ppac is a rust based re-implementation of Webpac and basic compatible with web pack's configs. So given that the existing version of Next still uses Webpac under the hood, the next and web and RS Ppac teams were able to collaborate and figure out how to get a plugin that would essentially allow it to use RsPack instead of Webpack as one possible alternative way to try to speed things up. [05:55]
-
-**Carl:** Yeah, I did see that the performance improvement from using RsPack and Next is like not that great and like in some circumstances could actually be worse than Webpac, which seems confusing to me. [06:07]
-
-**Mark:** some of it was due to things like JS based plugins and, and some of the, the interrupt back and forth between. Uhland and JS land. [06:16]
-
-**Carl:** Right. I mean, hey, similar problem is how React Native had with the, parsing data back and forth. kind of goes to show you how even once you have a tool that is written in native, it's, you know, it's not a silver bullet. It doesn't fix all the problems. [06:29]
-
-## [React Aria April 11th](https://react-spectrum.adobe.com/releases/2025-04-11.html)
-
-**Carl:** Yeah, react Aria by Adobe had a release. [06:32]
-
-They don't, I guess they don't do versions, they do just date releases. So this is the April 11th release. One thing that caught my eye that I thought was pretty interesting, so they have a calendar tool and they now allow custom calendar support. So it lets you implement your own like calendar schedule in re rendering this calendar thing, which, you know, they, they shout it out, for instance, using a 4 5, 4 fiscal calendar, which I had to Google because I'd never heard of it. [07:01]
-
-So this seems like a very, like, deep in the weeds kind of feature edition for, I don't know that that goes to show how seriously they are exploring the problem space. And I, I take that as a pretty positive sign. [07:13]
-
-## [Redux Toolkit 2.7](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.7.0)
-
-**Mark:** Last week I shipped Redux Toolkit 2.7 as I was on my flight to React Miami. [07:18]
-
-the main feature outta this is that RTK query now supports use of standard schema definitions for both validating requests and responses and errors, as well as potentially inferring the TypeScript types for those errors so that you don't have to hand rate those when you're defining the endpoints. As well as a bunch of other, other bug fixes and improvements. [07:41]
-
-**Carl:** That's super cool. I love generated types. [07:44]
-
-## [Vitest 3.1](https://github.com/vitest-dev/vitest/releases/tag/v3.1.0)
-
-**Mark:** And then Vitest 3.1 is out. Doesn't look like there's a, a huge standout feature, but a, a bunch of, again, small fixes and performance improvements, obligatory. [07:55]
-
-## Main Content
-
-**Carl:** Yeah, into our main content. [07:57]
-
-## [React Labs: View Transitions, Activity, and more](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more)
-
-**Carl:** So conveniently, like 35 minutes ago, the core team put out a new blog post a new React Labs post. React Labs are posts where they write about projects in active research and development. So this is like, definitely, this is like, you know, leading edge. What is the core team working on? [08:14]
-
-They do like what, maybe two of these a year? [08:18]
-
-a solid year since the actual React Labs post. They did have like the, the React 19 release announcements in that since then, I. [08:24]
-
-**Carl:** dated React Labs, March, 2023, react Labs, February, 2024, and now April, 2025. [08:31]
-
-**Mark:** So the headline out of this one is that they have been working over the last few in couple months on official support for the browser view transitions. API now. Going backwards. A lot of folks have asked over the years for some kind of official animation support in React itself. I know that people have compared, versus something like Svelte, which has apparently has the ability to declare some animations directly in your templates. And they've pointed at React and said like, why can't I do the same thing? Or like, you know, animating elements in and out is, is really, really difficult. And there's been lots of, you know, different animation libraries for React over the years, react Transition Group, react Spring, et cetera. But this is the first time we've ever had anything related to animations baked into the React core itself. Now as usual, I'm not actively ready in a lot of React myself these days. And when I have, I've never done anything animation related, so I'll be honest. I still don't even fully know what a view transition actually is, but I see a lot of people really, really excited about it. My, my vague understanding is that it's taking elements that are within the page and being able to move them back and forth. [09:46]
-
-**Carl:** As far as I know, it's largely about like page transitions, like when you navigate it will let you emulate like the kind of a native style of like, oh, this new, you know, new pane slides in over top [09:57]
-
-**Mo:** I mean, there, there's a few different types of transitions. There's like a fade transition that's native sort of there. But there's also the, the one that you're referring to, I think Carl, is the shared element transition, which is you have one element that exists on the first page and then the second, that element kind of persists, changes shape. [10:13]
-
-So the best example of that is like Instagram when you open up a a post and it kind of expands to take up the whole screen. That's what we call shared element transition in the mobile world. [10:22]
-
-**Mark:** Yeah, that, that makes sense. And I can definitely see how something like that would be difficult to do in React, where, you know, normally you stop rendering A and you start rendering B. [10:32]
-
-So the React team has been working on an official actual view transition component which has a number of different. Pieces of functionality, being able to, to label the transitions animate navigations, do some customization of these behaviors. the blog post goes into some examples of what these different capabilities are and how you would actually try to use them in practice. So it is still experimental. You have to specifically switch over from a production stable build of react to using the latest experimental channel release. But it's gotten to the point where they think it's actually ready for folks to try out. [11:09]
-
-on a similar note the React team has been working on and off for the last three or four years on a component that they originally called off screen. And the idea for this is that, as we all know, when you unmount a React component, everything about that component goes away. The effects are cleaned up. [11:27]
-
-The state that was unique to that component instance goes away, and that's made some things like, you know, building tabbed UIs difficult because you either have to do some work to hide the other tab contents, you know, maybe using like display none in CSS. But, and or you actually have to unmount them. [11:49]
-
-But in that case, state that was there goes away. And so the intent of this offscreen component. Was that you could wrap it around a section of your UI and you could tell React to toggle the display, but it would keep those components around and preserve their state. And then when you make it visible again, everything's still there. So they have since renamed this to be called the activity component. And they've also, and so now that is all at a point where it's officially ready for trial in an experimental form as well. And I think this is actually gonna be kind of a big deal. , we've actually used the predecessor offscreen component in replays UI for a while, which is why we're stuck on an old experimental build of react. And it, it really does prove pretty useful. [12:37]
-
-**Carl:** this like scratch an itch in the back of my brain because it, I, remember talking about this previously, so I was just googling like the, you know, offscreen and oh my God, like they've, they've been talking about this in both of the last two labs posts that we just mentioned. [12:50]
-
-So like, you know, they've got a tab called offscreen Rendering in 2023. "Offscreen rendering is an upcoming capability and react for rendering screens in the background." Like, okay. Alright. So they've been looking at this for over two years, I guess. It does seem really useful. Like I have definitely used every trick in the book to make things, you know, deprioritized. But yeah, I'm a little surprised to see that this is still in progress [13:16]
-
-**Mark:** The other two interesting bits out of the blog post about this, and they were not things that I, I had thought about in relation to this component. Another use for this is that if you start off with the activity labeled as Hidden, React will pre-render that content even before it's been displayed at all. But using concurrent capabilities, it'll be done in the background. So this can be useful for, you know, maybe you have like a more expensive piece of the UI that you know will be shown eventually, but maybe it doesn't need to be part of the initial render. And then that also ties into SSR capabilities as well. [13:54]
-
-And based on the initial value, react might like, include it in the content and then hydrate it later, or, do it in the background. And they also mentioned the possibility of adding some additional modes to this. Right now, currently it's, it's an nu that is just hidden or visible and they may actually have some other alternative behaviors down the road as well, which is why it's not a bullion. [14:16]
-
-**Carl:** Yep. Love flags rather than Boolean. That's great. Yeah. Interesting. I guess. I guess I'll keep an eye on it, but like, man, I guess I've been keeping an eye on it for two and a half years now. [14:24]
-
-**Mark:** The post covers a few other things. There's some performance tracking stuff they're working on. They are talking about trying to have the compiler automatically insert dependencies into use effect dependency arrays. there was one phrase in there in the post that I thought was kind of understandable, but also slightly oddly phrased. They, they gave a classic example of like a, a chat room connection in a use effect. they had a sentence to the effect that " Some hooks can be hard to think of in function instead of life cycles, developers get confused," da da da. " We think one of the reasons for the confusion is that developers think of effects from the components perspective, like a life cycle instead of the effects point of view, what the effect does." [15:10]
-
-And it basically what that's trying to say is. You know, the, the entire Rack React community looked at the use effect hook when it came out and we said, ah, this is the replacement for component. Did Mount and Component did update from class components to the point that, you know, often people even even create their own abstractions with those names. [15:28]
-
-I. And the React team has been valiantly trained to get us to stop thinking in those terms for years. And so I think this paragraph is basically saying, we've been trying to convince people not to think this way and failed. But it also like, it's, phrased slightly, like they're almost surprised. [15:45]
-
-People still think of it that way. [15:47]
-
-**Carl:** Yeah. it feels like a documentation problem. I feel like so many people are learning, react from a mishmash of strange places that they're learning, not what the core team would like. And you fix that by writing really good docs. [16:00]
-
-**Mark:** So anyway, the ul ultimately they're trying to work towards making the compiler be able to insert all those dependencies for you, and then maybe someday we get to stop thinking about this entirely. [16:08]
-
-They are also working on an early version of a compiler ex or extension for IDs, which has the potential to act as maybe like a super winter or show you what the transformed component might look like or even like what dependencies it would insert into use effect array automatically. [16:29]
-
-A couple other tidbits. And then one, the last item is very short, but as a library maintainer, it caught my eye. We all know that React has component-based state and that this has the strength that it's isolated to that component and the portion of the component tree, it has the weakness that you can't easily share it across different portions of the component tree. And we also know that Reacts concurrent behavior really only works with state that React owns, which is why external libraries like Redux and Zustand rely on the used sync external store hook, which works, but also kind of forces react to give up on doing things like transitions in the most optimized way. [17:13]
-
-So they've talked on and off for years about what if we were to add some sort of like a reusable store primitive to react. there's discussions about this going back to like 2015 and the blog post hasn't mentioned that they are working on something called concurrent stores. And it gives sort of a one line example that you would pass this to the use hook, and it does say, our goal is to allow external state to be read during render without caring and to work seamlessly with all the concurrent features that React offers. There's no further details. It's something they're just starting to think about. But it sounds like maybe down the road, react-redux and Zustand could use this and still work the same way, but better without the limitations. I don't know. I'm interested. I. [18:05]
-
-**Carl:** Right. I've never used used sync external store, partly because of the warnings they gave of like, this is gonna break stuff. So yeah. That's interesting. That's cool. [18:12]
-
-I'll also shout out, they mentioned, two other things very tangentially, like, we are looking at this, or we intend to look at this. [18:21]
-
-I'm curious about fragment refs. So like, you know, if you want to get a reference to the underlying dom node and react, you can do that with a ref. And you can use fragments to group elements, as a single top level rendered item rather than like wrapping it in a diviv or something like that. [18:35]
-
-But you cannot grab a reference to that group of nodes. But now they're looking, they "intend to research" refs on node groups like that, which is definitely interesting. I could see that being valuable in something like rendering a table or a list of something else. [18:55]
-
-Like especially if you're trying to do drag and drop kind of things. I could understand why being able to access a reference to a list of rendered nodes might be useful. But yeah, so I, I'm, I'm curious about that, but also given how long we've waited for some of these other things that are being researched with maybe clearer use cases, I will not be holding my breath on that. [19:17]
-
-**Mark:** will say that I've, I've watched them put up and merge several prs that are input, are trying to implement fragment refs. So it's, it's definitely not just a theoretical research project. They're actively trained to work out the implementation deals and details. At the moment, [19:33]
-
-**Carl:** That makes sense. Yeah. [19:34]
-
-Likewise for gesture animations gestures are generally just like a pain in the butt. I have never found anything that worked super well for that. So they say we're researching ways to enhance new transitions to support gesture animations, such as swiping to open a menu or scroll through a photo carousel. [19:50]
-
-That's cool. I will be excited to see if they get something working there. Just 'cause gestures are always annoying and part of why they're annoying is because it's such a, I don't know, they're just very far from like the rendering model. The way you have to think about gestures is very far from the way that React asks you to think about rendering a tree of components with like, self-contained state. It's just like fundamentally outside of a component. It's at the level of the browser, the device. [20:17]
-
-So, figuring out a way to, I don't know, reduce the distance between those is definitely interesting and sounds valuable and useful. But they also say for now we're focused on shipping view transition and we'll revisit gestures afterwards. So this definitely sounds a little bit more like intent to explore than active exploration. [20:34]
-
-They say they, they also say, we believe we found an approach that works well and may introduce a new API. So cool. They've done some research, they've got an idea, but it's not their immediate focus right now. [20:44]
-
-**Mark:** the other sort of big picture thing that I took away from this post. So there's been a lot of. Complaints and concerns from the community over the last couple years that the React team kind of stopped caring about the client side. That, you know, all their effort was going into building server components and pushing people towards frameworks and all this other stuff, which I. There's definitely been a push. The React team has noted that part of it is just how much, how hard everyone went in on single page apps over the last several years, and so there, there has been a swing back towards server-side rendering and ess, but even like React 19 had a bunch of client-centric features for, for forms and whatnot. it is interesting that basically all the things that they've got in this blog post are client side pieces, you know, view transitions, activities compiler stuff. Sort of there is a real focus on stuff that works on the client and adding like fairly meaningful core level functionality to the library itself. And so I think this actually kinda counterbalances some of the concerns people had that, you know, they were focusing on the server too much as well as noting that, okay, like, okay, now that the big React 19 push is done, now they've got some room to actually pick up with some of the features that they were trying to work on. [22:04]
-
-## [React 19.1](https://github.com/facebook/react/releases/tag/v19.1.0)
-
-**Carl:** Let's move on to React 19.1. [22:07]
-
-literally the headline in the post itself is the owner stack. They're introducing development mode only stack trace to help identify what components are rendering, which. And this really brought the, the whole concept of the owner staff back to mind for me. [22:23]
-
-Like this was something that I remember learning about and thinking about, thinking in terms of a lot in the first several years that I worked with React. And I think it's been slightly deprioritized in people's minds, like it's lost mind share. But it is super valuable for a ton of different things. [22:41]
-
-So surfacing it better in the developer tools and such I think will be really powerful. I wanted to bring in a couple of like, old, old, old posts that I remember reading and remember being, you know, instructive for me. [22:53]
-
-## [One React mistake that's slowing you down](https://www.epicreact.dev/one-react-mistake-thats-slowing-you-down)
-
-**Carl:** Kent C Dodds, put out a, you know, one react mistake that's slowing you down blog post a while back and it talks about like component composition and like how you structure the tree and it doesn't name owner stack. [23:07]
-
-I So it doesn't name the owner stack, but like really that's what it's talking about. It talks about like, you know, context and like prop drilling and how you can avoid it and why it's painful. And really what they're talking about, what Kent is talking about in this post is mindfully managing your owner stack. [23:23]
-
-Because the reason you have to prop drill is because the owner stack is weird and you need to go through intermediate components between data source and data usage. But if you restructure that owner stack so that you're, instead of passing a prop through one component so that it gets rendered in another component rendered by that component, you can just render children and then you don't need to pass the prop through. You just render them all at the same level. [23:52]
-
-Or, you know, you maybe not all at the same level, but you can collapse that you can make the tree broader and shallower. And prop drilling is like a developer experience, you know, convenience. It's nice to not have to remember, you know, if you think about it as like the length of a pipe, it makes the pipe a lot shorter and you, you know, there's fewer places for things to go wrong and you have to think about fewer twists and turns. [24:13]
-
-So like, that's great. But also a flatter, broader owner stack is just naturally good for performance because when you have a deep tree, something at the top re rendering will cause like everything to re-render underneath it. Whereas when you have it flatter and broader, then just you can re-render in smaller batches, like smaller units of components will be forced to re-render when things [24:39]
-
-**Mark:** I will caveat that one. [24:40]
-
-So rendering does work at the direct parent child level. So like if I have parent component, I. Inside of its own JSX, it renders a child of A, and then it inserts B as children inside of A. So like both the tag A and the tag B are inside of parent. There is still a three component level parent-child relationship tree. So root is the parent of of A, A is the parent of B. But the root is the owner of both A and B. [25:19]
-
-There's still three levels of components that have to get rendered, but it does flatten , the logic needed to generate those. And that's kind of like , the distinction that a lot of people haven't quite seen as they're learning. [25:31]
-
-**Carl:** Right, right. I guess let, yeah, maybe I'll, I'll revise that a little bit. So it's at that root level, if the root level component is re rendering, sure. All of the children still need to re-render, but the deeper the tree, the more parents that're in the loop there are. So this has been like moving components so that it's, the owner tree is flatter, has been like the number one, general approach I've done when there are performance problems in a code base, , which generally comes from, like, you can think in smaller units. I don't know. feel like I'm going deep in the weeds and not stating anything clearly. [26:07]
-
-**Mark:** generally speaking Composition is a good thing that more developers would benefit from taking advantage of. [26:12]
-
-## [Advanced React Component Patterns](https://kentcdodds.com/blog/advanced-react-component-patterns)
-
-**Carl:** Yeah. Another, old, old old post that I'll just shout out. Uh, again had a phenomenal post from 2017 talking about advanced react component patterns and like, okay, some of these are no longer like super duper relevant anymore, like higher aortic components. [26:27]
-
-Like, hmm, probably just use a hook. But these types back in this era of blogging about React stuff like owner stack was a little bit more, closer to the surface, it was still not on the surface. People are not referencing the owner stack. But yeah, just like when. I feel like owner stack is secretly the other option when people are talking about like prop drilling versus context like, well also what if you just restructured it so it's simpler? [26:52]
-
-**Mark:** Yep. [26:52]
-
-**Carl:** Anyway, super cool to see it surfaced. [26:54]
-
-## [Improvements in Expo using owner stack](https://github.com/expo/expo/pull/35866)
-
-**Mo:** one of the things that this owner stack, change is actually powering is some updates to the expo CLI for when you run your app in dev mode because one of the challenges in the React native world is that you get these massive log, massive log spans. [27:10]
-
-The stack trace is not at all discernible because it's kind of interacting in between the native world and, and the react world. but with this, the expo team actually ran a p and I think it's been actually merged now into hopefully the next release of, of Expo where they're actually showing you where in the react tree, the, the, the specific component is being rendered. [27:31]
-
-So it makes discerning some of these error messages a lot simpler. So I think we'll start to see some, maybe some improvements on like the framework level as a result of this. [27:41]
-
-**Carl:** Okay. That's all we got for React 19.1. Really. I don't know. There's just, there's not that much in 19.1. [27:48]
-
-## Dan Abramov is writing again
-
-**Carl:** This is kind of small, this is maybe just like commenting on the ecosystem, but Dan Abramov is writing again, and That's nice. He was writing a lot. I don't know how many hours of text do you think he's written, mark? [28:00]
-
-**Mark:** Many, many hours. Like I, I read fairly fast and there, there is a lot of content there. [28:06]
-
-**Carl:** One of the newsletters I subscribed to that shared this out you know, does share estimated reading time. And it was, you know, one of the posts was estimated reading time of an hour. And like, that's just if you're scanning your eyes over the words, I think, not trying to digest and understand it, but like broadly what he's writing about is server components. [28:25]
-
-**Mark:** Dan is fascinated with server components at like a technical concept, architectural. Where did this come from? How did we get here? What does this, how is this similar to old approaches? How is this different? What does it enable that you couldn't do before, kind of a level. [28:47]
-
-And he's, not even officially on the React team anymore. Like, think of him as like a, private citizen expressing his own opinions at this point. But the different posts are going through different aspects of. Server components from like a, very conceptual level and trained to explain from first principles, how did we get here? [29:09]
-
-## [React for Two Computers](https://overreacted.io/react-for-two-computers/) (Complement to [his React Conf talk](https://www.youtube.com/watch?v=ozI4V_29fj4))
-
-**Mark:** So like react for two computers is taking some of the concepts of, well, we have code that runs on the client and code that runs the server. How do we sort of figure out how to intermingle those? How can we shift pieces of that code back and forth and still have all this work together? [29:26]
-
-## [JSX Over The Wire](https://overreacted.io/jsx-over-the-wire/)
-
-**Mark:** JSX over the wire, I believe looks at, you know, if we, like we started with rest APIs, but rest APIs often end up growing special cases to handle data that the UI needs. And there's precedent for server driven UIs where you specify, here's a list of components in a JSON format. And then you know, the. All your different UI layers, you know, mobile, web, whatever, can just, you know, figure out on the fly what components you're talking about and render those and that RSCs take that sort of idea form a backend for front end pattern, but it's one that has more flexibility. And being able to send the list of components to render over the wire in a rather dynamic way. [30:11]
-
-## [Impossible Components](https://overreacted.io/impossible-components/)
-
-**Mark:** I always skimmed the most recent one, impossible components, but it's, it's kind of expanding on some of this, like where can the logic live? What are some of the capabilities of things you could do, like having a server component read blog files off disk and estimate the reading time rather than like having to insert them into a database somewhere. So. The first couple were very, very abstract and you know, that was a complaint that a lot of people had. the last one was more concrete. He's also kind of trying to be careful to, I. Explain concepts without literally invoking the word react server component. So like think through the mindset without getting caught up in the trap of, well, this is like a thing I can only use with next, or whatever other complaints people have, [31:00]
-
-**Carl:** funny, I just saw a meme that was like, name something that you can describe and people will agree with until you call it what it is called, and I was like, server components. [31:08]
-
-**Mark:** Yeah. So. I've seen a number of reactions. You know, some folks are just saying like, look, Dan, your blog posts are too long. They need a table of content, or at least a, a summary upfront of what is the point I'm trying to make here? And Dan's like, that's not the way I write, and I'm sort of ready for myself at this point, which I totally get and good for him. I've, I've seen a number of comments where people have said like, well, I followed the train of thought and now I'm actually sort of getting. What the point of server components are, and I've seen a couple other folks say that like, you know, if, it's taking this much explanation to try to convince me of what server components do, maybe the React team really needs to like come up with like a 500 word summary, which are, which are all I think, are all very valid reactions. But it's , Dan loves explaining things from first principles. he's a very like, logical, think it through. Why does this exist kind of a person. On a personal level, I'm just very happy that he's gotten past his writer's block and feels good about writing the stuff he wants to say, the way he wants to say it. And also, there is some value in reading through these to try to understand like, what is the point of all this? [32:12]
-
-**Carl:** And like at the end of the day, this is not, I think the, I think " feature in a JavaScript tool" is the wrong mental model for thinking about server components. I really do think that they are exploring a new. Compute paradigm, like it's a blending of the client server modes and they're constrained by, you know, technical aspects, everything in JavaScript in the browser is based around like batch and requests, it's hardcore based around a client server model. And they're trying to blur those lines and they do not really have platform support for doing it. So they are, you know, that's where things like the "use client" / "use server" directives, I think like they're kind of a hack fix because they don't have better primitives in the language, in the runtime to work with. [33:02]
-
-to me, yes, it's taking a lot of words to explain this and to explore it and to try and make it digestible and comprehendible, but it was also really hard to convince people that like, like I, you know, I, I remember early in my career there were a lot of words written about like pets versus livestock servers because like, you should be able to like, kill and restart any server and it shouldn't cause a problem and that's a livestock server, rather than one that you like very gently take care of and, you know, evolve over, over time and love and dote on. [33:34]
-
-And similarly when serverless became more of a thing, like these are different models for thinking about how your code executes and they're complicated and they're hard and I feel like this is cutting edge in so many different ways and so many, I dunno, I, I appreciate Dan really occupying this space at the bleeding edge, especially now that he's not, you know, professionally obligated to as a member of the core team. [33:59]
-
-**Mark:** last thought real fast. when the new React Docs came out, there was nothing in there about server components, and for a while the only official docs about server components were over in the next framework documentation that Vercel's devrel team had written, I still thought there was absolutely nothing in the React docs all, about server components until about a week and a half ago. [34:21]
-
-When I made that statement, after searching to try to confirm that there were nothing, and I missed that, there had been a page added about server components to the docs about a year ago, and I flat out missed that it existed. Having said that I do feel that the React docs would really benefit from having a much more concrete set of pages that describe server components. Ideally I would like to see an intro page, an overview, and in fact, there was actually a Versel blog post about server components that I think should just be literally copy pasted into the official React docs as the intro. I'd like to see kinda like a modest technical explanation. Like what are they architecturally, where do they fit in? [35:02]
-
-What does running a server component output? Maybe some kind of an FAQ because there's an awful lot of questions people still have about them, including some pretty stupid ones. And then maybe even like some kind of like a adoption or migration page. Like I would like to start using them. [35:17]
-
-I feel like having those pages would, it wouldn't solve all people's complaints, but it, it would at least centralize and make some of the information more official to reference. [35:28]
-
-## [don’t 👏 ruin 👏 his 👏 process](https://bsky.app/profile/danabra.mov/post/3lmi3gpiluk2m)
-
-**Carl:** Last thing I'll say on the subject of Dan writing again about server components. he posted on blue sky. "I kind of wanna write a dozen more posts about react server components. But I also feel like it's inviting endless takes about Dan trying to explain RSC means RSC is bad and it kind of ruins some of the process for me." [35:44]
-
-So don't ruin the process. [35:45]
-
-**Mark:** Be nice Dan, please. [35:47]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Okay. Lightning round. [35:48]
-
-## [Next.js RFC: Deployment Adapters API](https://github.com/vercel/next.js/discussions/77740)
-
-**Carl:** There is an RFC from next to do deployment adapters which is pretty cool. Like one of the big endless complaints about next is how hard it is to run anywhere other than versal. So they are meaningfully exploring what it would take to make that easier. [36:09]
-
-Yeah, it was post put up three weeks ago. I, I haven't seen a ton of like movement yet on what exactly that means, but yeah, it's seems cool here for it. Interested. Very excited to see what comes out of that. [36:23]
-
-## flightcontrol.dev from last year: [Secret knowledge to self-host Next.js](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)
-
-**Carl:** And I also wanted to shout out a blog post from October of last year from Brandon Bayer of Flight Control, secret Knowledge to Self-Host Next js. [36:33]
-
-So that seems like a relevant read in, in conjunction with this new deployment adapters. [36:38]
-
-## [Styled-Components in maintenance mode](https://opencollective.com/styled-components/updates/thank-you)
-
-**Mark:** I don't think we mentioned this last month. the style components CSS and JS library has announced that it is officially going into maintenance mode. Part of this is the amount of work needed to do it, and part of it is the shifts in the ecosystem such as relying on context when server components don't support context on the client. So that's both A FYI. This library is going into maintenance mode and also like more evidence that CSS and JS is sort of both falling out of favor and kind of being discouraged by technical changes in React itself. [37:15]
-
-## [RIP Styled-Components. Now What?](https://fadamakis.com/rip-styled-components-now-what-a8717df86e86)
-
-**Mo:** One sort of interesting like experience from my side on this specific thing was we actually migrated on a project of mine that was on the web that was using Next js. They went into the app router and tried to embrace all things server components and part of that process was they had a styled component library, like a shared component library that they had internally, which was all in components and, immediately they hit a brick wall and they had like 80 plus components that were all styled components and they couldn't use any of that there. So to throw in a little bit of AI magic what we actually did was created a custom prompt in like two hours that took styled components and converted it into their choice SaaS modules. [37:54]
-
-Which is going back to basics, but you know, a good technology choice nonetheless, if you want zero js runtime styles. And it worked shockingly well. So if you give it a good set of rules and you define the problem and you give it a nice workflow to follow, as if it was a developer did a shockingly good job, it reduced like the time for each component from like two hours to 15 minutes, 10, 15 minutes with a review process, like manually looking through the code it would generate. [38:22]
-
-So if you're stuck in style components world and need a little bit of help, try to use gen AI and the reasoning models shockingly worked very well because. With CSS, things cascade and it needs to have an internal representation of how styles cascade down. So your four OS in chat, GPT wouldn't work very well, but your O ones and O threes would work quite well. bit of a weird guideline, but it was quite a fun experience and I think it's a good use case for it. Trying to play around with gen ai. [38:48]
-
-**Mark:** I would not have thought about that. [38:50]
-
-## [Redwood announces new Cloudflare-based RSC SDK](https://redwoodjs.com/), existing framework in community maintenance mode
-
-**Carl:** Redwood has announced that they are now doing a CloudFlare based react server components, SDK. So like they used to be more of a framework and now they're like, it's kind of a reduced scope. I don't know. This connects back to, part of the headline of our January episode was "RedwoodJS, dead?" [39:12]
-
-We caught word that like some other person who had been involved in the project early but hadn't been involved recently, came back out outta the woodwork and basically what Redwood JS has been for the last, I don't know, two years, it is not anymore and it is now something else. That's, strange. [39:31]
-
-the SDK looks neat. I haven't played with it yet. I had been pretty interested in Redwood js because I thought they were trying to be like a Laravel for JavaScript and React Universe, and I thought that was cool. Something that is more narrowly like about doing the rendering is a lot less interesting to me. [39:48]
-
-For me, the value of a framework like that is more like, when they were trying to be the Laravel of reactive, I was excited because I would love somebody to make things like authentication and toast messages and all those kinds of things. Easier to do, easier to build a product rather than, I dunno, a rendering model. So this is now kind of going back into rendering model. [40:13]
-
-So it, it seems like an interesting, worthwhile exploration, but it's not what got me excited about Redwood in the first place. [40:18]
-
-## TC39 kills [Records and Tuples proposal](https://github.com/tc39/proposal-record-tuple/issues/394). Possible alternative is [“Composites”](https://github.com/tc39/proposal-composites)
-
-**Mark:** Yep. Meanwhile in, not directly react, but very related news, the TC 39 JavaScript Specification Committee has officially killed the records and two polls proposal. This was intended to add. Deeply comparable immutable objects directly into the JavaScript language, both in terms of runtime and specific syntax for declaring them. The idea was this would sort of like replace all your.dot object spreads and be able to have two objects and deeply compare them with the triple equals sign. [40:53]
-
-And apparently there was pushback from JavaScript engine, you know, developers who were concerned about the impacts this would have on like internal performance. So that proposal's dead. There is a new proposal called composites, which is sort of lighter weight, like it looks like you would construct objects use, like using like a new composite class that could then have like a composite equals comparison, possibly. So sort of the same direction, but like less deeply embedded in the language itself. So I know a lot of folks had a lot of interest in records and tuples, and we're hoping that one would really come to pass and it didn't happen. [41:36]
-
-## [React Compiler RC](https://react.dev/blog/2025/04/21/react-compiler-rc)
-
-**Mark:** React Compiler just came out, it was in beta and they've now gone rc. so number one, they, you know, they think it's, it's pretty good. It's almost ready. Number two, they've rearranged some of the lint rules previously. The React. The React compiler lint rules were in their own package, and I believe they're moving them into the existing rules of Hooks package. then they, they also announced experimental support for integrating the compiler with the SWC build tool, which is, you know, conveniently what's actually used by next. the compiler is primarily exposed as a babble plugin, even though the, all the implementation is not babble specific. they've found a way to integrate it into SWC, even if it's maybe not the most optimized way and are continuing to work on, you know, different approaches for configuring it as well. [42:27]
-
-So it's getting fairly close. [42:29]
-
-## ["Just use Vite”… with the Workers runtime](https://blog.cloudflare.com/introducing-the-cloudflare-vite-plugin/) (Vite on Cloudflare)
-
-**Carl:** Nice. Yeah, CloudFlare has announced better support for Vite with the Workers' runtime while also throwing a little bit of shade, I think, at the React ecosystem by titling it quote, just use Vite dot dot dot, with the workers' runtime. I don't know. It just feels like they're throwing a little bit of shade out there. [42:47]
-
-it looks pretty neat. I would like to play with this a little bit more, like yeah, they say "we're announcing release of the CloudFlare v plugin as well as official support for the React Router v7." So that's cool. I am currently running a React router v7 app. [43:01]
-
-That would be interesting to connect to CloudFlare in that way. I guess like the big distinction here is that previously I. They say, "the V dev server would always run your server code in node js, even if you were deploying the CloudFlare workers." in local development. Previously if you were using workers it would just run in node and that's not the same. [43:21]
-
-There are node APIs that are not available in the workers' time. So now taking advantage of the environment, API that we talked about a couple of months ago they are able to run your local development workers in an identical environment to what they will have in production. So that's cool. [43:40]
-
-Definitely very neat. And I generally, I think workers are super cool and just like an interesting programming paradigm. Like talk about, you know, exploring new paradigms for executing code workers are the most exciting other than server components [43:54]
-
-**Mark:** Last month we announced one of the major pieces of news was a vulnerability in Next's middleware implementation that could potentially have author related concerns. And there was a, you know, a major CVE vulnerability announced around that. This month it was react routers turn something was announced to have to do with some of the the path parsing definitions. [44:12]
-
-There are fixes out for both React Rider and remix. Please upgrade appropriately. [44:17]
-
-**Carl:** Yeah, this one looks a lot less major than the next one, but yeah, they did get a CVE. [44:21]
-
-## [Silk Library - native-like swipeables for the web](https://silkhq.co/)
-
-**Mo:** So next up, I just a library that I saw floating about in the, blue Sky and Twitterverse. Silk is a pretty cool library that takes in sort of these like native swipeable sheets that you're used to in the native world and brings it to the web in a React library. [44:37]
-
-So, you know, native feeling sidebars or bottom sheets or sort of like a, a, expandable bottom sheet for things like media players and stuff like that. All of that is quite difficult to do in the web world but very easy to do in the native world. And so they've created a React library and it works delightfully, like, it's very hard to tell that it's not native, which is really, really cool. [44:58]
-
-The. I guess the, the caveat is that it's not open source for anything that's commercial. So any like hobby projects that you're using or open source projects that you're using, it's free. But you need to pay around 300 euros if you want to use it in any commercial projects [45:17]
-
-**Carl:** reminds me of like sublime text, sublime merge, like the, the shareware. Please, please pay us. [45:22]
-
-## [\{transitions\} = f(state)](https://jordaneldredge.com/blog/transitions-f-of-state/)
-
-**Mark:** Jordan Eldridge, who is possibly best known for having created the React reimplementation of the Winamp music player from the good old days. wrote a post a month or two ago about transitions, RA function of state. it's not talking about the new React transitions, API, but rather kinda that mindset of viewing the contents and the logic of your component as state machines. It's kinda short, but some good thoughts there that are useful to put into practice. [45:51]
-
-## Tailwind 4, Bun, and old Macs: [A Supermarket Bag And a Truckload Of FOMO](https://blog.julik.nl/2025/03/a-little-adventure-in-modern-frontend)
-
-**Mark:** And then tossing out one more There was a very interesting article from someone who is trying to switch from using Tailwind three to Tailwind four. [45:58]
-
-I. But they were doing it on an old Mac, and as usual, I haven't used Tailwind, tailwind much myself, but apparently the latest version of Tailwind now uses a customized version of the BUN runtime to do its build steps. BUN is distributed as a native binary, and apparently the bun binary requires some of the latest CPU instructions. So it wouldn't even run on this Mac, even though it was a perfectly valid functional laptop. And so this person kind of got stuck, like, how can I even use Tailwind on this laptop when the latest version of tailwind's, compiler won't run on the laptop? And so it's well written, but also it's, just interesting to see how upgrades can cause problems sometimes. [46:47]
-
-## [Introducing Firebase Studio](https://firebase.blog/posts/2025/04/introducing-firebase-studio/)
-
-**Mo:** if you are somewhat following the world of Gen AI and the whirlwind of different tools and stuff that comes up every day some of them good, some of them not so good. There's been these sort of app builders that have been appearing, right? So things like V zero is the, is the big one that you'll probably be familiar with because of Sha Cian and, you know, the Versal ecosystem. [47:08]
-
-But you know, there's other ones like Repli lovable Dev Bolt and, and many, many more I'm sure. It's a problem that a lot of people are trying to solve, which is, you know, how can we enable non-technical people to build out apps or maybe accelerate developers to actually build them out in some sort of agent tech model. [47:25]
-
-And so, Firebase. the classic sort of toolkit that was there for mobile and front-end devs to be able to create backends without being real backend developers and needing to worry about things like infrastructure and whatnot, has thrown its hat into the ring and created Firebase studio. [47:41]
-
-So the whole idea with Firebase Studio is that it's it's kind of giving you the full stack. So, you know, Firebase already existed to help you build backends without really building backends. And so they're thinking of building on top of that. They've released this using sort of the Gemini models that Google has to allow you to also build the front end so you know, in one sort of prompt or set of prompts. [48:02]
-
-So you can generate a screen and then that goes all the way back and creates the sort of the backend for you as well in, in Firebase world, which is an interesting approach because they already have sort of a backend as a service. That people love and use quite often. And I, I still see it being used on a lot of sort of passion projects and even on some production applications. [48:22]
-
-One of the reasons I thought it was interesting to mention here was because if you look at some of the examples that they've released they don't actually, they have a lot of react examples and not as many angular examples, albeit you can use it to generate angular apps as well. And that makes me think that they're sort of coming around to this fact that it's, you know, there's a lot more react and next js open source code on the internet, which means gen AI is probably better at generating it than something like Angular. [48:49]
-
-But that's just a, that's just a take that I have and it's not grounded on any reality. So take that with a grain of salt. But that's my thought process as to why they're, showing a lot of react examples. Of course, they're showing flutter and some angular as well. So it's not like it's just react, but it's definitely interesting. [49:05]
-
-## [Gumroad is open source!](https://gumroad.gumroad.com/p/gumroad-is-now-open-source)
-
-**Carl:** maybe further afield from React and such, but Gumroad, for their 14th anniversary of being a product in the world is going open source. So they are, I guess, open sourcing their entire product which is cool. I like that. I'm confused about why, because like, you know, like fundamentally, usually people guard their source code if they're a like, functioning business that like makes revenue, you know, having the source code is a decent moat. [49:34]
-
-But yeah, it's cool. I, I like that. I like to see it. I love seeing real production code bases made open source because like, that's such a, that's such a common request that I see people asking for is like, okay, cool, I'm learning all of this, but how do I know if it's good, if it's real? [49:50]
-
-## [Automattic laid off 16% of staff](https://automattic.com/2025/04/02/restructuring-announcement/)
-
-**Carl:** And my last link also a little further afield, kind of at the intersection of our first job market section and our lightning rounds. But checking in on some of the WordPress drama that we had covered a couple months back; Automattic. The company that maintains WordPress and led by Matt of much drama, the last six months is laying off 16% of its staff. It's a little bit, this like restructuring announcement from earlier this month is a little bit goofy to me to read because it, it's, you know, it's just like why we're making changes. We've reached an important crossroads. While revenue continues to grow, we operate in a highly competitive market. It's like, well, yeah, and you also alienated your entire, like, product base and like open source ecosystem and customer base. [50:37]
-
-so just like seeing them talk about laying off one, one out of every six people who works there without talking about how, like, this was a total self own where the CEO just like burned every bridge he could find is like, alright buddy, good luck. [50:51]
-
-**Mo:** It's kind of poetic in some. [50:53]
-
-**Carl:** it would feel more like poetic justice if Matt was the one losing his job. [50:56]
-
-Not people unrelated, but Yes. Ugh. [50:59]
-
-**Mo:** But you know, I, I, I hope that other tech executives think twice and it becomes a learning lesson before they try to take open source products and monetize it in their favor when they have control over an ecosystem. I hope that people uh, think twice after this. [51:15]
-
-**Carl:** Yeah, right. I feel like this is gonna be some kind of business case study somewhere. So that's, you know, hopefully [51:20]
-
-**Mo:** I hope he also loses any bonuses that he was banking on getting this year [51:24]
-
-**Carl:** anyway, That's all we got for you this month. Thank you so much for joining us. We will be back on the last Wednesday of the month, next month here in the live stage or back in your podcast feed just as soon as we can. [51:34]
-
-We gather sources from this we in React Bites, dev React status, next JS Weekly, the React JS subreddit here in Reactiflux, and those direct from those publishing articles. If you see anything newsworthy, definitely let us know in the Tech News and reads channel here in Reactiflux or shoot me an email at hello@reactiveflux.com. [51:52]
-
-I read everything that comes in, so definitely send me something. This is a show that you value and would like to support. Best way to do so is by submitting a review. It would be cool if it was, you know, five stars, but whatever, any feedback is appreciated and definitely tell your friends and coworkers about it if you like. [52:09]
-
-Cool. Thank you so much. See you next month. [52:11]
-
-**Mo:** See you all next month.
diff --git a/src/transcripts/tmir-2025-05.md b/src/transcripts/tmir-2025-05.md
deleted file mode 100644
index 7afb0b8..0000000
--- a/src/transcripts/tmir-2025-05.md
+++ /dev/null
@@ -1,526 +0,0 @@
----
-title: "TMiR 2025-05: Dan explains RSC. Remix v3? React core team WIP?"
-date: 2025-05-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:54](#quick-hits)] Quick hits
- - [[00:57](#job-market-fred-data-layoffsfyi-trueupio)] Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
- - [[01:19](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:20](#react-summit-june-13-17-amsterdam-nl)] [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
- - [[01:57](#render-atl-june-11-13-atlanta-ga-usa)] [Render ATL](https://www.renderatl.com/) June 11-13 Atlanta, GA, USA
-- [[02:12](#sponsored-by-infinite-red)] [Sponsored by Infinite Red](https://infinite.red/)
-- [[02:59](#new-releases)] New releases
- - [[03:01](#tanstackdb)] [TanStack/db](https://github.com/TanStack/db)
- - [[05:28](#legend-list-10-released)] [Legend List 1.0 released](https://bsky.app/profile/jayz.us/post/3lni5ofbuvs2s)
- - [[06:48](#redux-toolkit-v280-and-bugfixes-after)] [Redux Toolkit v2.8.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.8.0) (and bugfixes after)
- - [[07:37](#mui-v71)] [MUI v7.1](https://github.com/mui/material-ui/releases/tag/v7.1.0)
- - [[08:30](#jest-has-a-v30-beta3-4-out-first-alpha-of-it-was-published-october-2023)] Jest has a v30 [beta.3](https://github.com/jestjs/jest/releases/tag/v30.0.0-beta.3) \+ 4 out. [First alpha](https://github.com/jestjs/jest/releases/tag/v30.0.0-alpha.1) of it was published October 2023
- - [[09:11](#zustand-505-jotai-2124-and-5)] [Zustand 5.0.5](https://github.com/pmndrs/zustand/releases), [Jotai 2.12.4 and .5](https://github.com/pmndrs/jotai/releases)
- - [[09:17](#devstore-deprecated)] [devstore deprecated](https://x.com/jotaijs/status/1919778234037878919)
- - [[09:28](#radix-has-new-primitives-onetimepasswordfield-and-passwordtogglefield)] [Radix](https://www.radix-ui.com/primitives/docs/overview/releases) has new primitives: [OneTimePasswordField](https://www.radix-ui.com/primitives/docs/components/one-time-password-field) and [PasswordToggleField](https://www.radix-ui.com/primitives/docs/components/password-toggle-field)
- - [[09:38](#ant-design-525)] [Ant Design 5.25](https://ant.design/changelog#5250)
- - [[10:02](#react-aria-may-19-2025-release)] [React Aria May 19, 2025 release](https://react-spectrum.adobe.com/releases/2025-05-19.html)
- - [[10:21](#relay-19-with-react-19-support)] [Relay 19](https://github.com/facebook/relay/releases/tag/v19.0.0) with React 19 support
- - [[10:29](#storybook-9)] [Storybook 9](https://github.com/storybookjs/storybook/releases/tag/v9.0.0)
-- [[10:38](#main-content)] Main Content
- - [[10:45](#expo-sdk-53-release)] [Expo SDK 53 release](https://expo.dev/changelog/sdk-53)
- - [[16:01](#packagejson-imports-support)] [Package.json imports support](https://x.com/satya164/status/1916095938604548366)
- - [[17:32](#react-router-rsc-preview-and-other-rsc-topics)] [React Router RSC preview](https://remix.run/blog/rsc-preview) and other RSC topics:
- - [[20:49](#vite-community-pr-to-add-rsc-support)] [Vite community PR to add RSC support](https://github.com/facebook/react/pull/33152)
- - [[21:33](#leerobs-list-of-other-rsc-explorations)] [Leerob’s list of other RSC explorations](https://bsky.app/profile/leerob.com/post/3lo4l2rmy7k2b)
- - [[21:44](#more-dan-posts-like-static-as-a-server-and-one-roundtrip-per-navigation)] More Dan posts, like [Static as a Server](https://overreacted.io/static-as-a-server/) and [One Roundtrip Per Navigation](https://overreacted.io/one-roundtrip-per-navigation/)
- - [[22:33](#redwoodsdks-your-react-framework-feels-broken)] RedwoodSDK’s [“Your React Framework Feels Broken”](https://rwsdk.com/blog/your-react-meta-framework-feels-broken)
- - [[23:20](#remix-v3-announcement)] [Remix v3 announcement](https://remix.run/blog/wake-up-remix)
- - [[26:04](#discussion-between-evan-you-and-michael-jackson-about-bundling-hmr-approach-and-tradeoffs)] [Discussion between Evan You and Michael Jackson about bundling / HMR approach and tradeoffs](https://x.com/mjackson/status/1928297364726632499)
- - [[29:56](#react-core-wip)] React Core WIP
- - [[30:08](#react-mcp-server)] [React MCP server](https://github.com/facebook/react/tree/main/compiler/packages/react-mcp-server/src)
- - [[34:08](#concurrent-store-skeleton-pr-a-concurrent-compatible-integration-for-external-libraries)] [“Concurrent store” skeleton PR](https://github.com/facebook/react/pull/33215) a concurrent-compatible integration for external libraries
- - [[35:49](#suspenselist-being-worked-on-again)] [\ being worked on again](https://github.com/search?q=repo%3Afacebook%2Freact%20SuspenseList&type=pullrequests&s=created&o=desc)
- - [[36:29](#compiler-integrations-with-swc-and-oxc)] Compiler integrations with [SWC](https://github.com/swc-project/swc/pull/10475) and [OXC](https://github.com/oxc-project/oxc/issues/10048)
- - [[37:19](#apple-app-store-epic-games-saga-30-apple-cut-ruled-unlawful-in-the-us)] Apple App Store Epic Games Saga 30% [Apple cut ruled unlawful in the US](https://www.macrumors.com/2025/05/19/epic-asks-judge-apple-approve-fortnite-app-store/)
- - [[40:59](#next-reducing-vercel-mentions-in-docs)] [Next reducing Vercel mentions in docs](https://github.com/vercel/next.js/pull/78557)
-- [[45:52](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[45:54](#shared-element-transitions-in-reanimated)] [Shared Element Transitions in Reanimated](https://github.com/software-mansion/react-native-reanimated/pull/7466)
- - [[46:56](#v8-explicit-compiler-hints)] [V8 explicit compiler hints](https://v8.dev/blog/explicit-compile-hints)
- - [[48:05](#ts-native-previews-usable-build-of-the-go-based-compiler)] [TS Native Previews](https://devblogs.microsoft.com/typescript/announcing-typescript-native-previews/?s=33) (usable build of the Go-based compiler)
- - [[48:26](#vite-rolldown-preview-build)] [Vite \+ Rolldown preview build](https://voidzero.dev/posts/announcing-rolldown-vite)
- - [[49:10](#seeded-pseudo-random-number-proposal-advances-to-stage-2)] [Seeded pseudo-random number proposal advances to Stage 2](https://bsky.app/profile/did:plc:w227epg3attqnssfdkx6ex6a/post/3lqcugizbls2g)
- - [[50:34](#3-layer-data-data-fetching-for-complex-react-apps-rscs-react-query-optimistic-ui)] [3-layer data data fetching for complex React apps](https://www.trevorlasn.com/blog/fetching-data-for-complex-next-and-react-apps) (RSCs, React Query, optimistic UI)
- - [[51:05](#johannes-schickling-announces-livestore-reactive-sqlite-sync-layer)] Johannes Schickling announces [LiveStore (reactive SQLite \+ sync layer)](https://bsky.app/profile/schickling.dev/post/3lq5gucxsj22a)
-- [[53:02](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the May edition of this month in React, where we recap and digest the ever evolving react and web ecosystem. We are coming to you live from Reactiflux, the place for professional react developers, and we are supported by infinite red uh, consultancy that exclusively works in React Native. [00:00]
-
-I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like this and build other tools to keep the community operating. [00:18]
-
-**Mark:** Hi, I'm Mark. My day job is with Replay io, where we're building a time traveling debugger and trying to find ways to make AI chat bots smarter with time travel. And also I spend a lot of time working on redux and ranting about the React teams communication. [00:28]
-
-**Mo:** my name is. I had the mobile team at Theodo and I'm an active member of the React Native community, a core contributor, and I organized the React Native London Meetup and conference. [00:42]
-
-## Quick hits
-
-**Carl:** Quick job market news new releases. [00:54]
-
-## Job market: [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
-
-**Carl:** Generally it looks like this Fred data source that looks at Indeed, I'm starting to doubt whether it's an accurate reflection of the current market. It's just been continuously trending down which I think may just indicate that people are hiring fewer software engineers on Indeed, since that's the only source of data for it. [00:57]
-
-Drew up dot iOS job trends shows a different direction. It's been a little bit better, but you know, it's not categorically different. [01:11]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** upcoming conferences. [01:19]
-
-## [React Summit](https://reactsummit.com/) June 13-17 Amsterdam, NL
-
-**Carl:** We've got React Summit in about two weeks, so if you are looking for something to do that's gonna be June 13th through 17th in Amsterdam. In Netherlands, [01:20]
-
-**Mark:** as usual, they're doing one day of an actual in-person conference, and then there's a remote only streaming set of talks. I think like the, the following Monday or something. I'll be speaking there in person. If you've heard me I said I've been doing routine. If you've heard me talking about things like, you know, the community misunderstanding reacts development or the React team having opinions about frameworks and stuff, I will be talking about that sort of thing, live on the main stage. [01:29]
-
-**Carl:** Very nice. Excellent. Well, I will be at a different conference. [01:54]
-
-## [Render ATL](https://www.renderatl.com/) June 11-13 Atlanta, GA, USA
-
-**Carl:** There's also gonna be render Atlanta June 11th through 13th. they seem to have really good vibes. It looks like it's pretty well attended in general. So this is my first time attending the event, but yeah, I'll, I'll be there June 11th through 13th. [01:57]
-
-## [Sponsored by Infinite Red](https://infinite.red/)
-
-**Carl:** We are sponsored by Infinite Red. They are an expert react native consultancy that's been around since 2015. So very long running. They do a lot for the ecosystem, including hosting podcasts. The hosting, the largest React native podcast hosting, I believe the largest or organizing, I believe the largest React native specific conference in the us. [02:12]
-
-And they only do React native and have built over 75 apps for companies ranging from startups to the biggest in the world. And they generally will work with a team in order to develop expertise, you know, within that team rather than just being a airdrop in Build the Thing and leave kind of consultancy. [02:34]
-
-So if you are working at a company looking to develop some React native expertise, definitely reach out to them. they're good people. [02:52]
-
-## New releases
-
-**Carl:** Into some new releases. [02:59]
-
-## [TanStack/db](https://github.com/TanStack/db)
-
-**Carl:** a new TanStack sync engine that looks like it ties in pretty well with TanStack Query. I haven't played with this, but it looks pretty interesting. [03:01]
-
-**Mark:** Looks like Kyle Matthews is working on it. Kyle's probably best known as having created Gatsby, but he's currently working at Electric sql, which, which is a syn engine company, so probably making use of some of his expertise there. I. [03:10]
-
-**Carl:** Yeah. Very cool. Definitely nice to see that kind of expertise being brought a little more broadly into some other projects. I think local first and like syn engine kind of stuff seems like. A very powerful area of exploration right now. I don't think we really know what it's gonna shake out to. But yeah, I've seen a couple of apps developed in this way over the years and they always, it just strikes me as a really powerful way to do it. [03:23]
-
-I think a great example of Local First is actually Gmail. They've been very local first forever in a mobile app, you know, you can just functionally use it and then you come back online and it actually executes all the things you did. That's just generally how I think most apps should work. So seeing a lot more exploration and how to support that with different types of tools definitely looks really cool. [03:47]
-
-And then coupling that, tying it very closely in with the query engine as it appears that this Tan Stack DB does. Definitely makes a ton of sense. Definitely really interesting there. [04:08]
-
-**Mo:** It's quite interesting 'cause I was having a chat with a fellow mobile developer just a few days ago, and he was telling me how he uses TanStack Query as like really like the central data store. Of his application on a React native app. But then the challenge is that things working locally is always a real pain and things working offline is a real pain because taking that either means you have to just like store the entire cache inside of like adjacent blob living somewhere on the device disc. [04:19]
-
-It's quite messy and it, doesn't follow those like asset principles that you would want to make sure that the data's intact and there's no sort of conflicts when you do reconnect. This looks pretty cool. I know it's only for react at this point, as far as I can tell, and it doesn't necessarily seem to be targeting React native support, but I think a lot of people in the React native ecosystem would probably love to use something like this so that these things are just synced onto a SQL like DB somewhere on the phone, which is kind of a way to do local first stops in React native. [04:50]
-
-**Carl:** network is so much more unpredictable on a phone than it is on, on the web. So yeah, that, that makes sense. That's maybe a little underwhelming, but it's not targeting React native support. [05:18]
-
-## [Legend List 1.0 released](https://bsky.app/profile/jayz.us/post/3lni5ofbuvs2s)
-
-**Carl:** Mo you want to tell us about Legend List? [05:28]
-
-**Mo:** Yes. So this is super exciting because legend list, for those of you who've been following along with the podcast for the last few months has been something that we've been talking about on and off, but it's been sort of in that alpha beta phase. So Jay Meistrich, he used to be a game developer, so I say that because. [05:29]
-
-Game development is super, super hard and you optimize for performance as much as you can. So he has that background and worked on a bunch of sort of low level OS stuff for a while. And so he's been a active member of the React native community. Made a library that was the most performant, well by his metrics, one of the most performant state management tools called Legend State. And and so Legend List is sort of, taking that experience and putting it into React native lists, which is one of the most challenging parts of the React native sort of development workflows, making performance lists. [05:45]
-
-And it is by far on all accounts of different people testing it in the ecosystem. The fastest React native list implementation. And it is a hundred percent js. It is very stable. At this stage. I know a lot of actual production apps that have been using it before 1.0. And so I would highly recommend you, you'd give it a try. [06:14]
-
-It's pretty straightforward to replace any existing list that you have, whether that's flat list or flash list. [06:31]
-
-**Carl:** Very cool. Yeah. List performance while like rapidly scrolling is one of those really visible things in an app, so definitely, definitely really cool to see a great, low level primitive for use there. [06:36]
-
-## [Redux Toolkit v2.8.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.8.0) (and bugfixes after)
-
-**Mark:** If you've been listening for a while, you've also heard me ranting about the complexities of publishing JavaScript packages and ESM and CommonJS compatibility. We shipped Redux Toolkit 2.8, which was primarily intended to improve our compatibility with the Metro Bundler and React Native. It did that and then it promptly started breaking tests with just environment js dumb due to reasons. we shipped a fix for that and then a process we act, we found out that the release had also ended up messing up some of our bundling so that the different and things weren't getting shaken out properly. And oops, our nested imports were actually like three times as big as they were supposed to be, so we had to fix that. So RTK 2 8 2 is out, and if you're going to upgrade, please use that one. [06:48]
-
-**Carl:** For sure. Yeah, we've got a bunch of smaller releases or like beta stuff, so I'm just gonna kind of fly through some of these. [07:30]
-
-## [MUI v7.1](https://github.com/mui/material-ui/releases/tag/v7.1.0)
-
-**Carl:** Material UI has version 7.1 out. It looks like it's mostly bug fixes. We talked about the new like slot pattern that they introduced in 7.0 in the last episode. Interestingly, they also talk about Tailwind V four support, which is a little bit surprising for a component library of this complexity. [07:37]
-
-I don't know exactly what Tailwind support means in this context, but it does appear that you can use a styled engine provider with a, like CSS layer not quite clear on whether this is doing all of the compile time tailwind optimization kind of stuff, or. Right. The implementation details here are not totally clear to me from the release notes but definitely interesting. [07:55]
-
-Yeah. I know that Tailwind V four support has been kind of a sticking point for some projects, so it's interesting to see such a large and complex style library take advantage of. It [08:20]
-
-## Jest has a v30 [beta.3](https://github.com/jestjs/jest/releases/tag/v30.0.0-beta.3) \+ 4 out. [First alpha](https://github.com/jestjs/jest/releases/tag/v30.0.0-alpha.1) of it was published October 2023
-
-**Carl:** Jest has a new V 30 beta beta three. I was checking the release notes for it and alpha one of version 30 was first published in October of 2023. [08:30]
-
-So this has been a long time coming. It looks like beta three introduced a lot more new things than the re the other alphas or, you know, many more fixes and whatever. So yeah, I don't know exactly what to think about that, Jest has been generally a kind of finished project in my experience. But yeah, they've got a new version turning its way through. [08:43]
-
-Although with two years, a year and a half since the first Alpha, I'm not sure if this is gonna be released anytime soon. Mark, tell us about Zustand and Jotai. [09:03]
-
-## [Zustand 5.0.5](https://github.com/pmndrs/zustand/releases), [Jotai 2.12.4 and .5](https://github.com/pmndrs/jotai/releases)
-
-**Mark:** Just a couple minor bug fix releases. Probably not in much meaningful, but you know, always worth looking at updates. [09:11]
-
-## [devstore deprecated](https://x.com/jotaijs/status/1919778234037878919)
-
-**Mark:** Jotai is also switching from whatever previous standalone dev tool support they had to their own built-in dev tools. [09:17]
-
-**Carl:** Yeah. Deprecating whatever internal tooling they had for that. [09:25]
-
-## [Radix](https://www.radix-ui.com/primitives/docs/overview/releases) has new primitives: [OneTimePasswordField](https://www.radix-ui.com/primitives/docs/components/one-time-password-field) and [PasswordToggleField](https://www.radix-ui.com/primitives/docs/components/password-toggle-field)
-
-**Carl:** Radix has a new release that has a couple of new primitives if you're using that. It's got a generally password adjacent. There's a one time password field and a password toggle field, so neat. [09:28]
-
-## [Ant Design 5.25](https://ant.design/changelog#5250)
-
-**Carl:** Ant design also has a new release with a, a new. [09:38]
-
-Timer statistic component. I've never used ant design. It was interesting to me. Well, I was looking to read more of the, you know, release details on this, but an awful lot of the contribution is in Chinese and I do not read Chinese. I know that's, been a bit of a bifurcation in the React ecosystem is, you know, language barriers are challenging. [09:41]
-
-they got a new thing. It looks cool. [10:00]
-
-## [React Aria May 19, 2025 release](https://react-spectrum.adobe.com/releases/2025-05-19.html)
-
-**Carl:** React Aria has a new dated release, you know, they don't do versions, they do dates. So this is the May 19th release. It looks like it's pretty much just small bug fixes, although they do also say they have support for the React 19 ref cleanup call that was introduced. [10:02]
-
-So yeah. Neat. Cool. [10:19]
-
-## [Relay 19](https://github.com/facebook/relay/releases/tag/v19.0.0) with React 19 support
-
-**Mark:** relay GraphQL version 19 is out. It's got support for react 19 as well as they've been working on their documentation. [10:21]
-
-## [Storybook 9](https://github.com/storybookjs/storybook/releases/tag/v9.0.0)
-
-**Mark:** And then storybook version nine is out, and it looks like they've made a really big effort to try to shrink the bundle size of their own tooling. [10:29]
-
-**Carl:** Cool. Alright, so that's all the new releases. [10:36]
-
-## Main Content
-
-**Carl:** We got so many small ones this month into our main content. Mo let's start off with expo. [10:38]
-
-## [Expo SDK 53 release](https://expo.dev/changelog/sdk-53)
-
-**Mo:** Cool. So we have a major release of a new expos DK. So expos, DK 53 is out, and this has been under the, the, the works for a very. Very long time. So Expo usually historically would release a version of an SDK with every React native release that would come out. So, you know, react native dot 72 comes out. [10:45]
-
-And then SDK version 40. I can't remember the corresponding, but you get the point. Every single version is tied to a specific SDK version. But as the React native team has been releasing more frequently the expo team found that it was actually probably a good time to stop tying those things together and sort of bunch some of these SDK releases into larger releases so that they can make. changes to the actual SDKs rather than having to keep up with React native and the versions that are being released every few months. So SDK 53 is a big one primarily because now the new architecture is default everywhere. So if you were paying attention, the last release that they had, the new architecture was default for new projects. [11:05]
-
-What they've now done is they set the new architecture even for existing projects when you update test SDK 53. And this fits with sort of the larger push that the React Native Core team is doing to push people onto the new architecture. And so React native version 79, as an example, has the same thing where, you know, existing apps will also be in the new architecture by default, and you need to opt out. [11:45]
-
-And as of yesterday as well meta announced at app js that they're going to be freezing the old architecture. So they're not really gonna be doing and adding any new features into the new architecture either. So very much going down the deprecation path with eventual sort of removal from React Native Core, which is kind of as we would expect it. [12:06]
-
-Other things to mention. So. Android developers will know about a requirement that came in to the Android ecosystem a few years ago called Edge to Edge support, which meant that your app needs to cover the full sort of corners and notches of an app of an Android phone. And this was sort of opt in for the longest time, but as of the next Android version that's soon to be released, I believe it's Android 16, edge to Edge support will be required. [12:23]
-
-On all apps. So if you submit an app that doesn't have Edge, edge to Edge support, they will reject it. So a bunch of people in the community have been working on getting this up and running because it's not trivial, it's actually quite complicated. So Zoom Tech who's well known in the React native ecosystem's, been working on this. [12:47]
-
-So he's worked with the expo team to get that implemented by default in SDK 53. So once you update to SDK 53, your app will already have Edge to Edge support. This is not the case yet for React Native Core. So if you have a non expo app, that won't necessarily be the case and you're gonna need to add it in manually yourself. [13:02]
-
-The goal is that eventually this will be merged and upstreamed into React Native Core anyway, and will just be handled as a core part of, RNs functionality. [13:19]
-
-**Carl:** That makes sense. So I'm thinking of like instead of safe area, it's gotta be edge to edge. I. [13:27]
-
-**Mo:** It's adjacent to that, but not directly related. So safe area views in react native, typically, historically were more of an iOS thing because iOS introduced the notch and then they introduced the dynamic island. So that safe area view was for that more than anything. 'cause Android app devices typically were a little bit more uniform, albeit not the exact same. [13:31]
-
-And then. Android devices followed suit with that. Edge to edge is more sort of how the app interacts underneath the notch or like in the corners of your, of your, of your screen. So, you know, you have a bunch of things in the Android world, like curved screens, and you have screens that, you know, have a a rounding on the corners and so on and so forth. [13:51]
-
-And edge to edge support is to basically make sure that it covers the full sort of portions of that which wasn't there by default. it's, I'm not an Android developer, so it's not necessarily my specialty, but I do know that it is a requirement there, and I think it's certain Android screens can be a little wacky and edge stage support is necessary to make sure that things are behaving correctly on all Android devices. [14:12]
-
-I. A few other things to mention with Expo SDK 53. Background tasks. If anyone's been building rack native apps since the beginning, he'll know that doing background tasks is really, really hard and making sure that they actually execute and you have some level of confidence that things are gonna be run in the background when your app's not sort of front and center in the foreground of, of the user's phone. [14:33]
-
-It's challenging. So Expo actually like went through this. They had a background tasks module. They went through just re-architecting it all because it was fundamentally flawed in the way that it was trying to tackle the problem. So they're actually using they, they've released the expo background task module and it uses sort of the up-to-date latest APIs on both Android and iOS. [14:54]
-
-And so they recommend you use this for different things, like let's say if you need to download data in the background. Or if you need to run over the air updates, so you wanna check, see if there's over the updates, and then actually download it in the background. You can do that, or, you know, garbage cleanup and so on and so forth. [15:12]
-
-If you need to do that in the background of your app. So this is quite useful. It's one of those things that happens behind the scenes, but I think is incredibly important to make an app really perform and, and feel like a native app would. Another sort of minor thing is expo audio. [15:27]
-
-So there's an expo audio update within this release. And expo audio is generally the replacement of Expo av, but the audio portion of that library. So that library was quite complicated And so they've split it off into expo audio and expo video and expo video came first. [15:41]
-
-Whilst they were working on audio, and now audio is, being released at this point, which is quite cool. [15:57]
-
-## [Package.json imports support](https://x.com/satya164/status/1916095938604548366)
-
-**Mo:** Last point on SDK 53, that's kind of adjacent to SDK 53, more of a React native thing, but it's part of SDK 53 as well is package json import support, which is great because it's oftentimes quite a big in React native projects with. [16:01]
-
-Babel and TypeScript working together for these package imports. So now React native has this feature built in, so you just define imports within your package js. You update your ts config to just resolve package JS imports and that's it. Which is a really good standardization. So, if you're using the older way of doing sort of aliases for your imports go ahead and change that because I think it'll make your life a lot easier in the long run. [16:15]
-
-**Mark:** I do kind of object to the use of the word just in that sentence. [16:39]
-
-that's basically what we were trying to, trying to get compatibility for with, our RTK 2.8 release. [16:43]
-
-**Carl:** I'm glad to see this standardization rolling out. I remembered this coming through in node. I went and looked it up. It was originally released in node 14, which came out April, 2020. So this has been a pretty decent long time coming though, you know? a lot of ducks to get in a row to make it work. [16:48]
-
-But definitely really nice to have alias resolution happen just from package. Jason, instead of needing to, I just, I can just remember all of the various pain I've had with like, trying to keep the aliases between like web pack and Babel and jest and storybook in, you know, all of the different parallel configuration that each needed, its own different way of configuring aliases. [17:05]
-
-So I love that standardization around that is settling out. [17:29]
-
-## [React Router RSC preview](https://remix.run/blog/rsc-preview) and other RSC topics:
-
-**Mark:** we've got a bunch of different things happening related to server components this month. Probably the biggest one is that React Router has announced a server components preview. this is probably a big deal for multiple reasons. We've already had at least one other tool parcel put out what it considers like a, a fully production ready release of server component support. [17:32]
-
-So we, we are getting more tools other than just next supporting it. But in terms of usage, react router, you know, even if you're, and you're just looking at the client side functionality has always been one of the biggest packages in the ecosystem. And part of the point of the whole React router, remix, react router back and forth was to try to make more of those pieces available in React router itself so that you could just turn on the framework mode flag and start to get server side rendering bundling type support. [17:55]
-
-And so having RSC support there. Is really going to be, from my perspective, the first widely available usage outside of next. So that feels like a big deal. It's also a big deal because I think most of our understanding of how to use server components has been very heavily shaped by the fact that next was the only real implementation. And so there's sort of been this, well, the way that the next app router works must be the, the way that server components have to work. [18:26]
-
-And instead here we see that the React router team has made some very different implementation choices in how you use server components. So in particular, they've got the ability to actually return server components as individual fields from your loader functions. So you can return some, data. You can return some components, and then your actual component on the client side just receives the loader data and you receive the elements much like you would props dot children, and you just include that in the output. They've also got some more options for server components, routes, and intermixing them support for server functions and then still doing things on the client side. So this looks like a pretty big deal release if you want to try that out, sort of adjacent to that. one of the complexities for server components in general is that they require tight integration with a bundler. And so the React team had specifically most of their initial work was around implementing integration for Webpac because Webpac is so widely used across ecosystem. And they've repeatedly stated that Vite's internal architecture just did not support the proper module graph handling to make real server components support possible. [19:01]
-
-so the, the React team has tried to keep the packages for the Bundler integrations in the React repo so that they can more easily iterate on changes to the core functionality versus what's specific to the bundlers. Like there isn't really like, kinda like a, a publicly defined API for that sort of thing, easier to all have it in one repo. But that's also meant that they didn't have the expertise or knowledge to do the Vite integration properly. [20:24]
-
-## [Vite community PR to add RSC support](https://github.com/facebook/react/pull/33152)
-
-**Mark:** So there is now a PR from the community to try to add, quote, unquote, proper Vite and RSC integration. And there's been some back and forth on that. Don't know how long it'll take to get that landed, but that does seem like a fairly big step. [20:49]
-
-**Carl:** Yeah, it definitely does, right? The lack of public API and general documentation for this is definitely, we've talked a little bit about how that's a pretty big barrier for people looking to explore this. You really have to reverse engineer it yourself if you wanna look into it. Seriously. [21:04]
-
-**Mark:** so at this point, we've got Next has been out for a while. Parcel just released its own quote, production ready, RSC support. We've got React Router coming out with a preview. So it, the, the ecosystem is starting to flesh out. [21:19]
-
-## [Leerob’s list of other RSC explorations](https://bsky.app/profile/leerob.com/post/3lo4l2rmy7k2b)
-
-**Mark:** Lee Robinson from CEL has been collecting a list of some different frameworks that are experimenting with RSE support in various alpha and, and, you know, test preview approaches. [21:33]
-
-## More Dan posts, like [Static as a Server](https://overreacted.io/static-as-a-server/) and [One Roundtrip Per Navigation](https://overreacted.io/one-roundtrip-per-navigation/)
-
-**Mark:** meanwhile Dan Abramov has cranked out several more blog posts trying to. Pitch the mental model of es. A couple folks have said that, you know, he's kind of hitting the same theme from different ways he's basically trained to start from different mental models and work backwards to, "and here's how RSCs address all these different problems." I think he actually put out four different posts this month. Two in particular one talks about how RSCs allow you to do static site generation and don't even require a, like a running application server to do the work. As well as how rses help handle the need to fetch multiple different pieces of data in one round trip. So there's those couple posts plus a couple others. So, as usual, worth reading, [21:44]
-
-## RedwoodSDK’s [“Your React Framework Feels Broken”](https://rwsdk.com/blog/your-react-meta-framework-feels-broken)
-
-**Mark:** One other sort of related post. So we previously mentioned that Redwood pivoted from their previous, very GraphQL based framework and they, they deprecated or archived that framework entirely, and they've come out with a new tool called Redwood, SDK which is based on CloudFlare and RSCs. And they, they put out a post called your React Meta Framework Feels Broken, which is both a, a kind of a critique of other frameworks as well as a sales pitch for their particular approach to dealing with server components. So we really are seeing different parts of the ecosystem trying to figure out how to actually make use of server components and ship those as actual features. [22:33]
-
-## [Remix v3 announcement](https://remix.run/blog/wake-up-remix)
-
-**Carl:** Well, yeah, that leads us sort of into new remix. They have released, or they've announced a version three which is somewhat surprising to me because I had understood it as a deprecated brand that was being merged back into React Router. But actually I, you know, reached out to them to be like, huh. And, you know, reached out in the remix Discord just to express confusion. And I had my attention directed back to the blog post that was released around when they actually did that talk at React Con last year revealing that they would be merging remix back into React router. And they, they were very clear about this from the beginning. [23:20]
-
-I don't really remember it in the talk and I'm not sure that I went back and read the announcement blog post after hearing the talk. So that may have been why I missed this. But yeah, they do talk about how this is, you know, that was their plan. They were going to re remix was a, a Fork of React router, I guess. They did a big thing with V two and merged that back into React router V seven. And in that blog post they talk about how V three is gonna be something totally brand new, but it will be coming, it was in progress. So it's here and remix is not dead despite reports to the contrary. [24:03]
-
-**Mark:** Or at least it's, it's far enough long that they were actually, ready to announce it. I don't know if any of this is available or visible in any way yet, but at least they're saying we're, we're working on it. [24:35]
-
-**Carl:** Yeah, true. [24:45]
-
-**Mark:** So, yeah, this is. it's confusing. I've seen a lot of people pushing back on, you know, like there's already been lots of people complaining over the years about the various React Rider major versions and changes and, you know, Ryan and Michael can't seem to settle on a single API design. I, I will say that the bouncing back and forth is kind of confusing. And then having a version three of an existing package that seems to throw all the existing, previous pieces out the window, is also kind of confusing. You can sort of make the parallel between the angular one or angular JS one versus angular two changeover that happened like a decade ago. [24:46]
-
-The general sales pitch, looking at the announcement blog post and some of the comments by Ryan and Michael on Twitter. So. They're, taking inspiration from, you know, tools like Rails and Express and whatever. You know, , they're sort of trying to apply like best lessons learned from all the other tools out there. [25:29]
-
-They really seem to be, want, seem to, want to go for simplicity and a non bundling approach. Like they seem to want their tool to minimize the number of actual dependencies that it needs to run. And they want to avoid having a bundling step in both development and production. [25:44]
-
-## [Discussion between Evan You and Michael Jackson about bundling / HMR approach and tradeoffs](https://x.com/mjackson/status/1928297364726632499)
-
-**Mark:** In fact there was a, a conversation between Evan Yu from, you know, from V and View who is saying that, you know, modern apps really need HMR, they need bundling even in development. [26:04]
-
-That's why, you know, that's part of why VIT is redoing its internals. And Michael replied and said. Yeah, we are, we, we want to minimize the number of tools that are involved. We want to minimize the number of transformation steps. We want things to be able to run without needing to do a bunch of compilation. And we're actually not going to ship HMR, we are going to rely on page reloads in Dev, and we think we can make it fast and work. [26:15]
-
-So they clearly have a vision, it's definitely a bit of a zigzag from where the ecosystem has gone over the years. One of the other interesting points is that it's not even going to use React as the UI layer. It's going to use Preact and in fact, apparently it's going to use a fork of Preact so that they can do some additional customizations. I don't have any additional details on what those customizations will be, but that's the direction they're going. I think, check me in this Jason Miller, who originally created Preact also now works at Shopify, right? [26:40]
-
-**Carl:** That sounds right to me. [27:16]
-
-**Mark:** So both, you know, Ryan and Michael, you know, like Remix got bought by Shopify a couple years ago and Jason Miller is there. So that, that presumably makes it easier for them to potentially collaborate on some of that work. I. [27:17]
-
-**Carl:** Yes, his Twitter bio lists him as platform developer experience at Shopify. So, right, like that job title is exactly this kind of work, like making developer tools and frameworks easier to use. So interesting [27:31]
-
-**Mark:** One of the other bullet points was they, they want to have an emphasis on LLM model based development. Ryan has made some comments recently that he's using LLMs in his day-to-day work, and it's helping to make him more productive. And I think I saw him mention that like the first line of the draft new docs for this version three is "disregard all previous remix versions" as an instruction. [27:46]
-
-So I, I don't know what all they have in mind there other than, being able to organize the docs in such a way that it's LM friendly, but it's something that they have in mind. So no ETA on when any of this will be available. But given how influential React Rider and remix have been, this is certainly something to keep an eye on. [28:13]
-
-**Mo:** there's sort of two thoughts on the, like the LLM friendliness that stands out to me. The first one is, ironically, I think by naming this remix, they've actually shot themselves a little bit in the foot because it's gonna be a fun challenge trying to teach an LLM how to disregard a version two versus version three documentation or stack overflow question that has been trained on, [28:34]
-
-**Carl:** That's actually a really good point. [28:55]
-
-**Mo:** I do wonder if inherently by building on top of web APIs and like staying as close, which, which has kind of been the philosophy with remix, old remix slash react router anyway, by trying to stick to web APIs and standardized sort of W3C primitive, so to speak, that are so well defined in terms of documentation, more so than probably anything else on the web. [28:57]
-
-Plus them adding some good documentation that is LLM friendly in very, very loose air quotes. If that just makes it a little bit more predictable, because I feel like. Having gone through a lot of the W3C docs, it is so well structured and so logical. Obviously it's quite convoluted a lot of times for people who aren't used to it, but it's, it's very like organizationally structured and I wonder if that can help an LLM understand it better than anything else. [29:20]
-
-But that's just a, that's just a personal guess. Could be very wrong. [29:45]
-
-**Carl:** Yeah. Well, I was gonna say that kind of leads us into our next topic, which is react core work in progress. [29:49]
-
-## React Core WIP
-
-**Carl:** And one thing that they have checked into the repo that I, I don't think has been really discussed or publicized anywhere, is they have a MCP server work in progress. [29:56]
-
-## [React MCP server](https://github.com/facebook/react/tree/main/compiler/packages/react-mcp-server/src)
-
-**Carl:** And so MCP is model context protocol, I believe. It's basically a generally standardized way of authoring tools for LLMs to make use of. I think this react core MCP server is mostly around the compiler. So Lauren has done a lot of work on the compiler and is now doing, it looks like some work on this MCP server. I don't really have a great grasp of what MCP servers are good at, but as far as like tools that LLMs can take advantage of, like sure. Having your IDE be able, your, you know, the LLM and your IDE to query, react, to say, please run this through the compiler and tell, you know, check the performance optimization, see if it's better than it, you know, this other attempt that seems interesting and potentially useful in a, relatively limited capacity, but connecting it back to the remix v3 and LLM friendliness, I could imagine a world where like there's an MCP server that looks up documentation for your specific version that you have installed. [30:08]
-
-I don't know if that's, you know, a direction that they're going to explore, but that def, that sounds plausibly workable to me. I don't know. That's interesting. [31:13]
-
-**Mo:** specifically like an MCP server. Is is more for the LLM to be able to externally call tools rather than just generating text. So it gives it like a way to interact with the outside world. And I guess going through the code of this specific MCP server they've defined a few different tools to compile with the React compiler. [31:21]
-
-If you give it a set of code basically but also then run performance tests. And sort of go through this process of assessing what, the LCP is, I-N-P-C-L-S, and also the core web vitals. And so looking through the actual source code, it seems to me what they kind of want you to be able to do is to use the, use this MCP server to basically compile some of your code, open up a browser and run core web vital scores. [31:43]
-
-Run the react compiler, see if it improves it, and then sort of do that in a loop, almost in an age agentic fashion, so that you can optimize a react component until it's kind of at a state where things are performance, as performance as they get. So it's almost like write your react component. It's fine if it's crap, and then leave it to the model to go in and optimize. [32:09]
-
-Measure, optimize, measure, optimize until it's at a state where, things are working as expected and is as performing as it gets. [32:29]
-
-**Carl:** Yeah. There's also some mark, I think this is more of a you question, but they've got a skeleton PR for a concurrent store. I. [32:35]
-
-**Mark:** Yeah. So this is a topic that's been discussed for a while. So one of the big limitations that limitations thus far around suspense and concurrent rendering and transitions has been that React needs to own the state in order to be able to postpone or interrupt or reschedule work in progress state updates, which means that for external libraries, Redux, Zustand, Jotai, you know, X State, you know, take your pick here. We've had to rely on the use Sync external store hook as our integration with React so that when the external store updates, react gets notified and it can trigger or re-render. [32:42]
-
-But the limitation is that used syn external store can quote unquote det, which the React team has never done a great job of defining that term. But as best as I understand it, what it means is that if React was in the middle of a concurrent render and something happens with the external store, like say a Redux action gets dispatched while React was paused, rendering halfway down the tree, it ends up having to throw away the entire work in progress render and do a full synchronous render start to finish in order to ensure that the whole tree has access to the right data. And, you know, from their point of view, that's, that's a bad thing, which is understandable. [33:24]
-
-## [“Concurrent store” skeleton PR](https://github.com/facebook/react/pull/33215) a concurrent-compatible integration for external libraries
-
-**Mark:** So. They've put up a PR for what they're calling a concurrent store, and this appears to be a react built-in object that you can create and then you can pass it to the use hook to extract the value. And somehow the internals of this will be concurrent compatible. And it looks like that will allow external libraries to interact with that instead of use syn external store and potentially allow them to be concurrent transition compatible in a way that use syn external store is not. Now, thus far, what we have is a draft PR that just adds the skeleton of this to the code base feature flags and some tests, no implementation details, nothing we can run or try out. But based on some of the stated comments on social media and this draft PR and then the last React lapse blog post, it looks like that's the idea of what this could do. So at some point we may have to put out React Redux version 10, which which is over to this, it's good to see that they're iterating on this, on this concept. [34:08]
-
-**Carl:** well you, you certainly would know a lot better the context behind that than I would having maintained redux for so long. But it seemed like the, you know, use concurrent or, you know, concurrent store or whatever the various things they've tried, it seems like none of them have quite solved the problem they were hoping it would. So. [35:17]
-
-**Mark:** External store avoids the tearing problem. But at the cost of, if you happen to have that sequence of events occur, then you, it has to, you know, take the time to do a full render, which could be costly 'cause it can't interrupt itself. [35:32]
-
-**Carl:** Trade offs not ideal. [35:48]
-
-## [\ being worked on again](https://github.com/search?q=repo%3Afacebook%2Freact%20SuspenseList&type=pullrequests&s=created&o=desc)
-
-**Mark:** Along with that, Sebastian has done some more work on view transitions and they're working on resurrecting the suspense list component idea, which had been prototyped quite a while ago. And they're found Trying to bring it back. This is apparently meant to try to allow you to define intended order for multiple different, like adjacent or nested suspense components to reveal themselves. Say maybe like you have a, I guess like a list of items or something. Admittedly as usual, it's outside the scope of what I've actually ever tried to use, but it's a thing that had been sitting around for a while and it was unclear when they would get back to trying to work on it. [35:49]
-
-## Compiler integrations with [SWC](https://github.com/swc-project/swc/pull/10475) and [OXC](https://github.com/oxc-project/oxc/issues/10048)
-
-**Mark:** And, and then finally the React compiler is currently implemented as a Babel plugin. And given how the ecosystem has been shifting away from Babel, that was a bit of a pain point. The core of it does not rely on Babel. Like Babel was just sort of used as the way to get it into your build tool. And so they've been working on, in, they have a semi working integration with the SDC compiler, which is what next and other tools use. And they're also talking with the folks from OXC, which is what the New V implementation will use about the best ways to try to integrate. So still early days there, but it's good to see that we are, they're trying to find better ways to integrate with both, you know, with the latest generations of build tooling so that we hopefully don't have to have Babel in our build tool chains. [36:29]
-
-After all. [37:19]
-
-## Apple App Store Epic Games Saga 30% [Apple cut ruled unlawful in the US](https://www.macrumors.com/2025/05/19/epic-asks-judge-apple-approve-fortnite-app-store/)
-
-**Mo:** Next up a little bit of a segue. Not specifically React news, but I think reasonable enough to call out here because it does affect React native apps. So if you've been following the news, apple and Epic games have been locked in a feud for the last. Several, several years. Apple basically taxes any company on in-app purchases for digital goods of 30%, which is quite a significant revenue hit for any app developers that are out there. [37:19]
-
-There's some provisions for startups and so on and so forth to bring that down to a lower number. But once you hit a certain amount of revenue, I think it's around 1 million or 1.5 million a year on the app store, you have to pay 30%. And so. Epic games and Apple have been going to court over this for a very, very long time. [37:48]
-
-And Fortnite was off of the app store for a while several years ago now. So it's been going back and forth. If you use Netflix on your phone as an example, you'll notice that you can't actually purchase or change your subscriptions on the app. You need to go onto a website. And there's no sort of link from the app whatsoever to manage anything related to your subscriptions. [38:05]
-
-And that's kind of by design because they don't really wanna pay the 30% to Apple. So, in a sort of shocking turn of events a court came in and basically said that apple's 30% tax is actually unlawful in the us. Which is kind of a. nobody kind of expected this to come out especially because the EU didn't even go this far. [38:23]
-
-And so, the EU basically went in and said, Hey, you should be able to have a, you know, alternative app store rather than just the Apple app store available, but didn't say that, you know, 30% tax should be removed and it's unlawful. in the first sort of events that happened in May. Epic Games won and basically they, courts ruled that Apple should reduce the 30% tax or remove the 30% tax. [38:44]
-
-And how they do that is basically you can use in-app purchases. Basically use another external payment platform for it so you can use Stripe or whatever else you want to take payments for digital goods inside of your app. The next day, apple basically blocked Fortnite from the app store in a sort of weird turn of events saying, no, we don't, we don't accept this. [39:08]
-
-Only to then get overruled with a judge asking Apple to approve the app store submission for Fortnite. So now if you're in the US you might see some apps. Having a big warning on the app store from Apple saying, Hey, this app is unsafe in terms of transactions and you're not gonna be protected by the App store, so proceed at your own risk, which is quite funny. [39:29]
-
-So still doing anything that they can to stop people from doing this. But for React native developers, that basically means that you can now use Stripe only for the US market. So if this. If this is functionality that you have for any locale outside of the us, your app will still be rejected because this is on a US only ruling. [39:50]
-
-But you can use Stripe or any other payment provider for digital goods inside of your app, circumventing in-app purchases, and still have your app approved in the us which is a big, big deal for a lot of people in this ecosystem. And folks like Charlie Cheever have been speaking about this being a big day for, for mobile developers. [40:08]
-
-A bit of an aside, but it's relevant to react native developers to be in the loop about what's happening in the ecosystem. [40:27]
-
-**Carl:** that's like half of a seismic shift for native apps. the fact that it's only in the US locale is, you know, definitely dampens that quite a bit, but [40:32]
-
-for such a large market to now be required to accept. Different payment methods that don't have a 30%, you know, cut removed that is still quite large. [40:43]
-
-Still quite significant. [40:53]
-
-**Mo:** Hopefully this kind of reverberates to other markets as well and I can kind of see that happening. [40:54]
-
-**Carl:** All right. [40:59]
-
-## [Next reducing Vercel mentions in docs](https://github.com/vercel/next.js/pull/78557)
-
-**Carl:** Our last main, you know, topic here, kind of small, but sort of speaks to the general undercurrent, the vibes that people have felt around next and react. next has reduced how many mentions Vercel gets in the next documentation. Lee Rob in the PR for this says some of the mentions were egregious and unneeded. [40:59]
-
-Others were documenting specific behavior for how next runs on Vercel, which is better suited for Vercel documentation. That seems good. I would certainly agree that some of the mentions were egregious. Some of the behavior being documented was better suited to the platform documentation rather than the project. [41:20]
-
-The next project documentation, you know, it's just such a persistent topic of discussion that like next verse and react are all just like so tightly coordinating and whatever. This is definitely a small but positive change on that. I appreciate seeing it. I. [41:37]
-
-**Mark:** I think we even also put up a similar PR to tweak the phrasing that where next is listed in the React op docs set up an installation page. I think it used to have a phrase like, next or next is hosted by Vercel, or developed by Vercel or something. And they specifically tweaked that to remove some of that reference. And like it all, like, it also kind of goes along with, Vercel being intentional about reaching out to like the Open Next folks and trying to more standardize how next actually can be hosted. think people's complaints have been valid. Like this has been both a pain point technically as well as it has it, it's looked bad, but I think we ought to give credit to them for saying, okay, yeah, we, we agree, we kinda screwed up here and we're going to try to improve the documentation and the actual usage to make it more generic. [41:53]
-
-**Mo:** Looking at this a slightly different lens as well. I mean, props of them for this goes without saying, but I think Vercel is also starting to reach this realization that they can't just rely on being a next hosting platform to monetize. Because, you know, you see in the last you. Few months how their business model has kind of shifted into three spaces, which is, you know, hosting for next and, and other things. [42:49]
-
-But also observability has become a lot more of a mention on their sort of product listing pages. And more recently, I think they're really going hard on the AI space. So a few days ago, I think they announced that you can use Vercel. Sort of ISDK as a proxy to call 40 plus different LLMs without needing to set up different billing with each of these different platforms. [43:10]
-
-So I get a sense they're trying to go for a larger cloud play, which means that they're probably less reliant on next Js being sort of their guarded secret. And, you know, their tool that only runs on Vercel. And they can open it up a little bit more without worrying about it being sort of their only lever for business. [43:32]
-
-**Carl:** Yeah, that's interesting. I hadn't thought about how they were, they were super early on the ai SDK, they definitely have first mover advantage there, I'd say, and that is, that does position them well for like, if they are a point of entry for LLM based APIs, then that I could imagine a world where they then try and be like host their own models. [43:49]
-
-And then you are paying them for that hosting as well, which is adjacent to hosting your, your web app, but not quite the same maybe. Yeah. That's interesting. Yeah, they definitely own a pretty significant front door there and so where that door goes could certainly lead to stronger monetization for them in the future. [44:12]
-
-I also want to, you know, since in the last couple of episodes we've, one of the topics of discussion has been Vercel, and its. Collaboration or lack thereof with other adjacent hosting providers. noticed at the bottom of this PR it says Netlify has confirmed they're okay with a specific feature matrix link included, and I did my best to include the CloudFlare and Amplify versions based on their documentation, which I'm going to read into and say they do not have open lines of communication with CloudFlare and AWS which is maybe not ideal. I feel like they should have, you know, the, the head of dx, head of, I don't know. [44:30]
-
-I don't know exactly what Lee Robb's title is, but he is highly active, engaging with many individuals throughout the ecosystem. And for him to reveal that they do not have, you know, maybe not a red phone, but like any means of getting in touch with people within CloudFlare or AWS somewhat surprising. [45:06]
-
-I don't know. [45:24]
-
-**Mo:** CloudFlare, yes, I agree with you. Amplify. Oh boy. I've, used Amplify on and off to host various applications. I'm instinctually going to say that that might be more on the Amplify team, just by virtue of how they deal with their own users, let alone with other community leaders. But that's just a guess. [45:24]
-
-CloudFlare is probably a different, [45:45]
-
-**Carl:** I have very briefly used Amplify and that is approximately my read of things too. Fair enough. [45:47]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Alright Should we go to the lightning round? [45:52]
-
-## [Shared Element Transitions in Reanimated](https://github.com/software-mansion/react-native-reanimated/pull/7466)
-
-**Mo:** I'll kick it off with shared element Transitions, a very, very exciting prospect that we've been waiting on in the React native ecosystem So there's a draft PR going into React native reanimated for shared element transitions on the new architecture. I. Shared element transitions very quickly is basically what happens when you navigate from a screen to another screen in the React native or in a mobile app, and some element is taken, expanded, or animated onto the next screen. [45:54]
-
-So, you know, Instagram, you click on a post, it navigates you to that post, but it opens it up so you see a transition of that post expanding or something like that. There's been a lot of sort of POCs of this in the React native ecosystem, but nothing standardized that people can use easily and consistently in their apps. [46:22]
-
-So, Bart from Software Mansion has been working on this for a while and we've seen some really good promise of, of things actually working out for it to be available. So keep an eye out, keep an eye out on that. But it's still early stages, but I think that the new architecture can enable stuff like that, which is really, really exciting. [46:38]
-
-## [V8 explicit compiler hints](https://v8.dev/blog/explicit-compile-hints)
-
-**Carl:** This is extremely niche. But V8 now has, or is providing a new way of ge improving startup time by using comments to hint to the compiler what will be used and what should be compiled. So this is like very deep in the weeds of the runtime engine and like how it gets compiled and when it will compile things. [46:56]
-
-So this is certainly not something that I think most of us will need to use, if optimizing startup time is something that you care about, V eight is now giving you some new things, some new ways to play with that. I don't super duper understand all the, you know, twists and turns of this, but the gist of this blog post is saying that you can add a comment you know, slash slash. [47:18]
-
-Hash bang or no, not a hash bang, just a hash slash slash ash. All functions called on load. And that will signal to V eight that it should compile it differently than it would otherwise, which will improve startup time so that it, you know, because it doesn't have to guess so much at what is being compiled. [47:40]
-
-I always appreciate seeing some of these runtime optimizations. It's just like a little window into the black box. [47:58]
-
-## [TS Native Previews](https://devblogs.microsoft.com/typescript/announcing-typescript-native-previews/?s=33) (usable build of the Go-based compiler)
-
-**Mark:** All right. we're always talking about tools that are, and putting out, you know, faster releases, rewrites and native languages. And this month we've got a couple of previews. We've previously a announced that TypeScript is being rewritten in Go, and the TypeScript team has put out preview builds of the go based tooling. So you can try those out and see how fast it is. [48:05]
-
-## [Vite \+ Rolldown preview build](https://voidzero.dev/posts/announcing-rolldown-vite)
-
-**Mark:** Similarly, Vite just announced like right before we, we, we started recording this, that they've got a preview build of their roll down based. Bundle. So the idea right now, v uses a mixture of es build in development modes and roll up, which is a, which is written in JavaScript for their production builds. And so roll down is a rust based reimplementation of roll up, but they're going to use it for both dev and prod. And they're also going to look at, start doing bundling in dev rather than just shipping standalone ES modules to the browser. So it's preview, you can try it out. They've got some stats saying builds have gotten a lot faster as a result. [48:26]
-
-## [Seeded pseudo-random number proposal advances to Stage 2](https://bsky.app/profile/did:plc:w227epg3attqnssfdkx6ex6a/post/3lqcugizbls2g)
-
-**Carl:** Another deep in the weeds. update, but this is pretty early too, TC 39. But a seated pseudorandom number generator proposal has advanced to stage two. You know, math, that random is useful for many things, but cryptographically secure random generation is not really one of them. [49:10]
-
-Although actually this is sort of adjacent to that. This is one of the problems of math thought random is it doesn't let you provide a seed for the randomness, which has various drawbacks where sometimes you, you know, you want something that appears random, but is actually deterministic so that you can, you know. [49:29]
-
-Have other parallel computation that will produce the same output regardless of what the random is. some specific example tying in a CSS feature that I am not familiar enough with to speak at length to. But yeah, just like generally this is a huge expansion in the functionality, the randomness support in the web, in JavaScript. [49:46]
-
-I, I think it said it's like 17 new various random functions. So that's, that seems very nice. [50:10]
-
-**Mark:** a couple times where I needed to do some seated ran number generation, even if it was just for something like a, a, a tutorial example app and had had to rely on various third party libraries for that. So, I mean, definitely a useful thing to add to the platform. [50:17]
-
-Okay. And wrapping things up, a couple, couple bits around data fetching. [50:29]
-
-## [3-layer data data fetching for complex React apps](https://www.trevorlasn.com/blog/fetching-data-for-complex-next-and-react-apps) (RSCs, React Query, optimistic UI)
-
-**Mark:** I saw one article that gave and gave some suggestions around a way to manage your data fetching at a a three tiered approach where you can use server components on the server to do some initial fetching. Pass some of that as props into components and use it to seed react query on the client and then set up React Query to do some optimistic UI updates for faster behavior. Not necessarily new and groundbreaking, but it was nice to see a reasonably detailed article that suggested some ways to tie all three pieces of those together. [50:34]
-
-## Johannes Schickling announces [LiveStore (reactive SQLite \+ sync layer)](https://bsky.app/profile/schickling.dev/post/3lq5gucxsj22a)
-
-**Mark:** And finally Johannes Schickling, who I believe originally co-founded Prisma has been doing some work over the last few years around a local first sync engine called Live Store. He gave me a demo in person when I was, in a conference a couple years ago. And then he gave me and David corse a preview of his talk for local First conf a couple weeks ago. And this is really interesting. So he is running SQ Lite in the browser. He's got a reactive layer around SQ Lite. [51:05]
-
-So you would have like a, a, a data-fetching-like hook that you'd use in your components, except it's talking to sq l under the hood. But then the sq LI instance itself is being based on. A series of descriptive events. One might almost call them actions that describe a thing that happened that ultimately define how the data ends up in SQL eight in the first place. And so he actually very intentionally drew parallels to the, the redux mindset and architecture in his talk. So he, he just put that, I put that out and announced it at local first conf. it genuinely looks very interesting. Like, would all apps need it? No, but it looks like it would be extremely useful for things like a, like a local first setup needing to work offline. [51:35]
-
-**Carl:** I know Johannes Schickling is also very involved in effect, which is a interesting, like massive, huge API scope, like functional programming library. So like, man, he's doing a lot of stuff. He is really shooting his shot in a lot of different directions. Very cool. I somehow feel like he was involved in organizing the local first con. [52:24]
-
-Trying to confirm that. Yes. Okay, cool. He is in fact one of the organizers of Local First Comp, so that, that [52:47]
-
-**Mark:** Oh, that's cheating. Accepting your own talk. [52:52]
-
-**Carl:** Right. [52:55]
-
-it feels like he's very all in on building the future of local first. So Very cool. [52:55]
-
-## Outro
-
-**Carl:** Alright, that's all we got for you this month. Thank you so much for joining us. We will be back on. I'd say we'll be back on the last Wednesday of the month, but I think we haven't hit that for a minute, [53:02]
-
-**Mark:** I can already say that I, I'm still traveling. In fact, I will probably, I'm pretty sure I will be at a conference on the last Wednesday of next month. So we, we may need to bump it back a few days. [53:12]
-
-**Carl:** recording time, TBD usually the last week of the month. and we will be back in your podcast feed just as soon as we can after that. I hopefully will get it up on Monday. We gather sources from this week in React bites.dev react status next JS weekly, the React JS subreddit and herein Reactiflux from the Tech news and reads channel. [53:22]
-
-And also sometimes directly from people publishing, but that's a, that's an noisier signal. If this is a show that you get value from and would like to support, best way to do so is by submitting a review on whatever platform you listen to and by telling your friends and coworkers about it. Thanks so much for listening. See you next month. [53:41]
-
-**Mark:** Take care. [53:56]
diff --git a/src/transcripts/tmir-2025-06.md b/src/transcripts/tmir-2025-06.md
deleted file mode 100644
index ecb8cf6..0000000
--- a/src/transcripts/tmir-2025-06.md
+++ /dev/null
@@ -1,361 +0,0 @@
----
-title: "TMiR 2025-06: kinda quiet tbh. ES2025 finalized, new Safari"
-date: 2025-06-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-We had some problems with transcript generation this month, downstream of the audio recording issues. Sorry! Fixed for July.
-
-- Job market [FRED data](https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE), [Layoffs.fyi](https://layoffs.fyi/), [Trueup.io](https://www.trueup.io/job-trend)
-- New releases
- - Shadcn
- - updated Calendar component
- - Moving from \@radix-ui/... to radix-ui
- - [Recharts v3.0](https://github.com/recharts/recharts/releases/tag/v3.0.0)
- - [Vite 7.0 is out!](https://vite.dev/blog/announcing-vite7.html)
- - [Biome v2](https://biomejs.dev/blog/biome-v2/)
- - [Announcing Oxlint 1.0 \| VoidZero](https://oxc.rs/blog/2025-06-10-oxlint-stable)
- - [Prettier 3.6: Experimental fast CLI and new OXC and Hermes plugins!](https://prettier.io/blog/2025/06/23/3.6.0)
- - Experimental "fast CLI" support, first discussed [Nov 2023](https://prettier.io/blog/2023/11/30/cli-deep-dive) 👀
- - [Jest 30](https://jestjs.io/blog/2025/06/04/jest-30)
- - [React Native 0.80](https://reactnative.dev/blog/2025/06/12/react-native-0.80)
- - [Safari v26 beta](https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/)
- - [Apollo Client 4 RC1](https://github.com/apollographql/apollo-client/releases/tag/%40apollo%2Fclient%404.0.0-rc.1)
- - May actually ship pre-compiled with the React Compiler ([discussion with Lenz and Joe](https://bsky.app/profile/phry.dev/post/3lsl7w4ynjc2v))
-- [Sponsored by Infinite Red](https://infinite.red/)
-- Main Content
- - Mark's "[The State of React and the Community in 2025](https://blog.isquaredsoftware.com/2025/06/react-community-2025/)" ([slides](https://blog.isquaredsoftware.com/2025/06/presentations-react-community-2025/))
- - Remix direction?
- - "[Disillusioned with React Hooks](https://x.com/mjackson/status/1937979887815692465)"
- - "[I can break signals quickly, don't use them for real apps](https://x.com/mjackson/status/1938362165221523542)"
- - [React Router "Open Governance"](https://remix.run/blog/rr-governance) (and [governance doc](https://github.com/remix-run/react-router/blob/main/GOVERNANCE.md#steering-committee))
- - [Debate over Radix UI status](https://x.com/colmtuite/status/1935629877069172861)
- - [Shadcn has thoughts](https://x.com/shadcn/status/1936082723904565435) on switching component libraries
-- ⚡ Lightning round ⚡
- - [Towards React Server Components in Clojure, Part 3](https://romanliutikov.com/blog/towards-react-server-components-in-clojure-part-3)
- - Dan's latest posts:
- - [Progressive JSON](https://overreacted.io/progressive-json/)
- - [How Imports Work in RSC](https://overreacted.io/how-imports-work-in-rsc/)
- - ES2025 spec released. [What's New in ES2025?](https://2ality.com/2025/06/ecmascript-2025.html)
- - [The Future of React Native Graphics: WebGPU, Skia, and Beyond ](https://shopify.engineering/webgpu-skia-web-graphics)
- - [Open sourced identity](https://nodejs.org/en/blog/community/2025-pride)
-- Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [React Nexus](https://reactnexus.com/) July 3-5 Bangalore, India
- - [Big Sky Dev Con](https://bigskydevcon.com/) Aug 2 Bozeman, MT, USA
- - [Kansas City Developer Conference](https://www.kcdc.info/) Aug 13-14 Kansas City, KS, USA
- - [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025. Wrocław, Poland
- - [WaysConf](https://www.waysconf.com/) Sept 16-17
- - [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [SquiggleConf](https://squiggleconf.com/) Sept 17-18 Bostom, MA, USA
- - [React Conf is back](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Oct 7-8, Las Vegas, NV, USA
-
-# This Month in React: June, 2025
-
-[00:00] **1-vcarl:** Hi, Carl here. Just a quick note before we get into this episode. We had a little bit of an issue with the audio recording, so the quality is a little bit lower than I usually go for. Sorry about that. We'll do better next month.
-
-[00:11] Hello everyone. Thank you for joining us for the June edition of this month in React, where we recap and digest recent developments in the ever evolving react and web ecosystem. We are coming to you live here in Reactiflux, the place for professional React developers.
-
-[00:27] We're supported by infinite red. Consultancy that works in React Native.
-
-[00:31] I'm Carl, a staff product developer and freelance community leader here in React Plex, where I run community programs like these events and build tools to help keep the community operating.
-
-[00:41] **2-acemarke:** Hi, I'm Mark. I maintain Redux. I work at Replay.io io and I apparently spend too much time debating the React team's documentation and communication.
-
-[00:51] **1-vcarl:** Endlessly!
-
-## [00:52] job market
-
-[00:52] **1-vcarl:** Start off with a little bit of job market news. I don't know, maybe we should stop doing these. 'cause I feel like it's not really in crisis anymore and it's not really making any dramatic shifts and I feel like I just keep giving about the same update every month. But yeah, data from Indeed trended up for the first time in a while.
-
-[01:12] True up.io, which also. Attempts to answer about the same question in terms of like, are people hiring in tech shows a slightly more positive trend. So I think that might be like giant people are using Indeed and they are not hiring as aggressively in tech for tech roles and everyone else is using a random smattering of hiring tools and they are hiring. So I wonder if that's like a big tech versus little tech dichotomy. I don't know. That's not based off too much concrete in summation at all.
-
-[01:43] The layoff charts for June are the best that they've been in a year and a half. Fewest number of people laid off by a decent margin and fewest companies running layoffs again by a pretty decent margin, about half for each. Lowest five 50%. So that's good. That's nice. I'm not sure if anecdotally feels that much different, but yeah. I don't know if you disagree, lemme know.
-
-[02:08] We're gonna change up order a little bit. Previously we've done on job market, the conferences and the releases. I'm gonna throw conferences back at the end because I could tell in the data that people were skipping through it. So we're gonna move it.
-
-## [02:19] New Releases
-
-[02:19] **1-vcarl:** Yeah. New releases.
-
-## [02:21] ShadCN
-
-[02:21] **1-vcarl:** Shadcn pushed out an updated calendar components. In the release notes, they included like a, a code mod to move imports from at rad cy slash whatever to just rad, cy, like top level like barrel import kind of thing. I don't know what that's about. I didn't really see any new releases from RadixUI that mentioned that.
-
-[02:40] So like I don't really know why that shift is happening, but like, okay, cool. That seems fine.
-
-[02:44] **2-acemarke:** A couple other things about RadixUI UI later on in the discussion.
-
-[02:47] **1-vcarl:** Yeah. Oh yeah. We've got some main content chatter about them. Just like some Twitter threads, debating, usefulness and whatever. Yeah, more of them later.
-
-## [02:55] rechart
-
-[02:55] **1-vcarl:** Recharts has a major release for the first time in a long time. Their last major release was January 4th, 2023. So two and a half years. That's a while. Recharts is not a library that I'm often happy to use, but it is a library that I often use because it just makes charts pretty easy. Not always as powerfully and flexibility as I want, but, it's good enough. It's pretty great.
-
-[03:16] The big thing that caught my eye in these release notes was they're claiming it's now accessible by default, so you can tap into it in these arrow keys to navigate it. So that's nice. Accessible charts are hard.
-
-[03:27] Most people don't do them, so getting it in the default is lovely. That's, that should help a lot more charts be access, and then Mark feel like you'll have more to say on that.
-
-## [03:37] vite 7
-
-[03:37] **2-acemarke:** Maybe so, so Vite 7 just came out. I've actually been having a little bit of trouble just trying to keep track of some, some of the releases, it feels like they've, they've really sped up some of the development.
-
-[03:49] They've bumped their, their node version support. Part of that is because they want to make use of the relatively recent node support for requiring ESM packages. In other words, importing an ESM module from a CGS module. Which was always the, the sticking point for a lot of the ESM common JS compatibility.
-
-[04:10] So they're actually distributing e and Vite 7 as ESM only, which. It feels like a fairly big step in the progress of, you know, the ESM ecosystem. They're also changing the default browser target to use the baseline, widely available preset in terms of browser features. They also now have some better support for the environment.
-
-[04:35] API, I'm still a little hazy on what exactly that does. My understanding is it, it allows you to ultimately generate bundles for different target environments, I believe is the best way to put it. So Vite 7 feels like it's a fairly big release.
-
-[04:51] **1-vcarl:** We had talked about the environment a while ago. I also don't really understand it too well, but definitely like deep in the weeds for library authors or, I don't know, framework authors. I've heard some positive things, but yeah, it seems esoteric.
-
-## [05:06] biome
-
-[05:06] **2-acemarke:** Meanwhile, we also have a slew of new formatting and lint tool leases, all seemingly with an emphasis on making things go a whole lot faster. First off Biome, which is, you know, formerly known as Rome back in the day, just released a version two, which is a fairly big deal, partly because they're, they now actually have some type aware linting rules.
-
-[05:31] Part of the issue here is that I. Up until now, the only option for doing types based linting was to use the TypeScript ES lint package, and that involves using the TypeScript compiler actually compiling things. And so it's kind of slow, and I don't know exactly how they've managed to implement this, but Biome now has some form of lightweight type analysis that does not appear to rely on the TypeScript compiler.
-
-[05:58] And so they've used that. To implement things like the no Floating Promises Rule. Now, it does not appear to be anywhere near as comprehensive as what TypeScript ES lent supports, but it is an interesting step in that direction.
-
-## [06:11] Void Zero
-
-[06:11] **2-acemarke:** Meanwhile, Void Zero, which is the VC backed company behind now Vite and other related build tooling development has released Oxlint 1.0.
-
-[06:24] So we have another lint tool that is a competitor to ES lint. They're claiming they have 50 to 100 x speedups and built in support for over 500 ES lint rules. And they say it's being used in a number of major companies. So if Linting is a particularly slow portion of your build pipeline. You may wanna check that out.
-
-## [06:45] Prettier
-
-[06:45] **2-acemarke:** And meanwhile, prettier 3.6 is out and they've been working on an internal rewrite of their existing CLI to try to speed it up as well. It's not a, it's not a rewrite and rust, it's just finding more efficient ways to do the same work in JavaScript. So the general theme here is people want to do linting faster.
-
-## [07:07] jest
-
-[07:07] **1-vcarl:** Yeah, we've got a new release, new major release from Jest as well. I think we had teased this the other day because they had a beta out. But yeah, first major release in three years. Again, faster perf, faster module resolution with some better ESM support. I know that generally like crawling your modules is one of the slowest is like, you know, broadly one of the slower parts of all of these bundling linting testing, whatever tools.
-
-[07:34] I wish I knew a little bit more details about the internals of like how just versus Vitest do it differently. 'cause my sense is that J is like heavier weight. It like does more, is more, I don't know, doing more on your disk and like crawling the condenses and all of those kinds of things. Yeah. So like one more place where there's a focus on performance in our build environment.
-
-[07:56] **2-acemarke:** Faster build tools, always a good thing.
-
-## [07:57] rn 0.80
-
-[07:57] **2-acemarke:** Those who in the audience may have noticed that MO is not here this week. He had a prior commitment and wasn't able to make it. So I will have to do a poor job of filling in and describing some of the React native changes. React Native 0.80 is out and it looks like the two biggest things out of this are they have frozen support for the legacy architecture.
-
-[08:18] I believe one of the recent releases made the new architecture default. So they are, they're seizing work on the legacy architecture, and this also brings support for React 19.1 as well. Now along with that, I believe the current version of the Expo SDK, version 53, does not have support for this directly yet.
-
-[08:41] If you want to use React Native 80 with Expo, they do have a canary version of the SDK that you can try out at the moment. But full support, I believe is. Or is planned that Expo SDK 54 coming out later this year would have support for React Native 0.81. So good luck trying to juggle those.
-
-[09:03] **1-vcarl:** Yeah, I know Expo has visibly been like focusing on release cadence.
-
-[09:07] I feel like for the last year or so, it seems like they've just been releasing something, being constant. And I know that Mo has talked previously about React Native working to have a more frequent release cadence, which is also has been very apparent. Kudos to Expo for like still being able to address this. Even if it's only in a pre-lease version, we can still test it out.
-
-[09:28] And also just like, it seems like it speaks well to the cadence that they're able to hit that they are, Expo is just saying like, yeah, we'll catch the next one because that's how fast it's gonna come out. I do wish Mo was here 'cause I feel like I see references here that make me curious to have an expert explain a little more.
-
-[09:45] They have a good post referenced in these release notes, moving towards a stable JavaScript API. I would love to hear Mo talk about how they are getting rid of JavaScript deep imports, so that, you know, basically just like saying, here's the public API stop importing things from deep within the project, which makes sense that if you let people import whatever the heck they want from inside of your package, then yeah, you just don't have a public API and you have to support literally everything. Everything is a break and change. Seems really cool. We'll have to have Mo catch us up next month.
-
-## [10:15] webkit 26 beta
-
-[10:15] **1-vcarl:** Yeah, this is a big one that is, I wish I had slightly more context for, but WebKit Safari version 26 is in beta. They're jumping from version 18, I believe it was all the way up to 26. So that all of the different, you know, iOS, whatever technology things can all be in sync.
-
-[10:33] This was announced of a WW BC 25 keynote. Yeah, so like Mac, os, iOS, iPad os, vision os and Watch OS are all now version 26. And so is Safari because the browser is also an operating system. Vision's a pretty large update and it has like all sorts of things from like cutting edge. Now you can use a model.
-
-[10:54] HTML tag, if you're Envision OS to render a 3D model all the way. So like that's very cutting edge, like future looking high tech, whatever. All the way back to you can also use SBGs as your favicon. A feature that like many other B browsers have had for a decade. So they're like both pushing the envelope and playing catch up.
-
-[11:14] Yeah. Safari has the di very different release cadence from other browsers. It's much closer to like the old style release. Cadence as opposed to how Chrome and Firefox and Edge are all like Evergreen, constantly updating. So I guess it makes sense that we're gonna have such a huge, massive dump of features, but like definitely check it out because they've got all sorts of stuff.
-
-[11:34] HDR images, web GPU, lots of CSS changes, lots of, you know, new standardized APIs, standardized job J JavaScript, APIs, all sorts of stuff. Finally, Apollo client just shipped a release candidate for version four. The release notes for this version don't have like a consolidated list of everything that's changed, but if you scroll back some, and you look at some of the lists of the prior alphas, it's clear that the, the Apollo team has been very, very busy and I know that.
-
-[12:05] In some discussions with Lens, who is my fellow Redux maintainer, but also works on Apollo client as his day job. They've been doing a lot of work to try to improve some of, and some of the packaging setup that had been, that had stuck around for years. One interesting side point out of this is that there's a good chance that Apollo client for might actually ship pre-compiled with the React compiler to try to optimize some of the internal hooks and components in the library.
-
-[12:34] There was a really interesting discussion thread on Blue Sky between Lens from Apollo and Josepha from the React team where they were discussing like, should libraries go ahead and ship like React compiler pre-compiled bundles already? Does it make sense to wait until some of the compiler runtime pieces are more stable, so clear, like.
-
-[12:58] This is very new and new and unusual territory for all of us library maintainers, and so it's interesting to see Lynn's trying to figure out some of these things that for the rest of us, yeah. That question of whether libraries should be pre-compiled with the React compiler definitely seems like a big open one in the ecosystem.
-
-[13:18] Cool. Alright. We are sponsored by Infinite Red. We are an expert React native consultancy that's been around since 2015. I. They're our only sponsor right now, in part because very few companies do as much as they do for the ecosystem. Just they, I don't know of anyone else who's done it quite so much for quite so long.
-
-[13:34] I've been seeing the name Internet Red around for as long as I've been in React and around React. React Native, which goes back all the way back to like 20 14, 20 15, they host the largest React Native podcast. They organized the largest React native conference in the us. They only do React native and have built over 75 apps for companies from startups to the biggest in the world, other than being great people who've done the great things to the ecosystem.
-
-[14:00] It's a team of about 30, mostly developers, mostly with more than 10 years of experience, and something like half of them have been there since the company was created. So just, you know, dev shop with Longevity. A dev shop with loyalty to its employees. What wild, they aren't just a feature factory. They will work alongside your devs and help you develop your own expertise.
-
-[14:20] So if you're spinning up a new product, being React native and want some help in the ground running, definitely give them a ring intimate top red. Cool. Okay. Into our main content. Start us off with your posts and talk. Hi. Yes. This is the part where I go off on things for a while, so if you, if you've been listening to the podcast for a while, you know, following me on Blue Sky or something, I've been involved in a lot of discussions and had a lot of opinions about, I.
-
-[14:44] A number of the interactions between the React team and the community, as well as a lot of the common misconceptions that have been unfortunately running around in a lot of community threads for a while now. It seems like pretty much every time you open up a discussion, for example, about Next.JS, there's complaints that the React team has is, you know, too close to next.
-
-[15:06] Or that Elle invented server components just to, you know, just to make money. Or why is the React team doing all these server things? Does the React team even care about, you know, single page apps anymore? And. A lot of this stuff has been going on for a while, all the way back in January and February when some of the CRE React app deprecation stuff was going on.
-
-[15:28] I kind of got fed up for a while and I was writing an extremely long blog post that I never actually published. I did a lot of research. I wrote a lot of words. It was cathartic. In reviewing it, I concluded that publishing it probably would've burned some bridges, even if the content there was accurate.
-
-[15:46] But there was, there was some good historical information in there and a number of folks said that it would be worth, you know, trying to publish that. Anyway, so I had a chance to speak at React Summit in Amsterdam a couple weeks ago, and my talk there was actually directly based on some of the content in the post and.
-
-[16:07] I decided it was worth trying to revisit the draft that I never published and extract the info that was relevant to the talk and hopefully make some of the points that I'd originally tried to think of, but, you know, maybe in a slightly more tact, tactful and less inflammatory kind of way. So really the the post and the talk.
-
-[16:28] Are trying to push back on a lot of the myths and misconceptions and FUD that have floated around in the React community for the last few years, but also point out some places where I think the React team's communication has has kind of fallen down. So a lot of people get confused about. The relationship between the React team and the next team who actually invented server components, why they were invented.
-
-[16:55] So as usual, a good portion of the talk and the post are basically a history lesson. You know, I tried, I did my best to try to recap, as I understand it, the origin of server of server components, the timeline of when they were invented, basically that the React team invented them while they were still at Meta, before Versal ever got involved.
-
-[17:15] And that it was something the React team invented because they ultimately, they saw the infrastructure that Meta had for server side rendering and data fetching. That was always very specific to meta and it really couldn't be generalized. And so server components was an attempt to. Implement kinda like a generic version of what Meta had for its own infrastructure, but because Meta had that infrastructure, they really couldn't iterate and Alpha test the features the way that they had everything else.
-
-[17:47] They ended up reaching out to Versal and getting Versal to build out the React team's vision of what they wanted to do. So a lot of this was me attempting to push back on the Versal invented server components to make money narrative. But then I also ended up addressing some of my points of concern where the lack of documentation about server components.
-
-[18:11] Has been a point of confusion. People not understanding when do I use them, how much should I use them? Is the React telling me to use them or are they optional? As well as a lot of the, the back and forth about why are the docs pushing the concept of frameworks so hard. And so I went into some details on my understanding of the React team's rationales for actually trained to say frameworks should be the default way to use react.
-
-[18:39] I put a lot of effort into it. I hope it's been informative and the feedback to the post and the talk have been pretty good. Dan Abramov actually retweeted it and basically said that, you know, he, he had a couple nitpicks about the way I described some of the timelines and bits of info, and he actually passed me some corrections on the side, which I tried to, to fill in, but he seemed to think it was generally accurate, and also he said that he'd been kind of stuck.
-
-[19:06] Debating whether to write his own history post, and he might end up being able to write one. Now that I've done most of the heavy lifting on it, that at least tells me I was directionally accurate. I. Like I can't have been too far off if he wanted to correct me on. So I don't expect that my me writing a post and doing a conference talk is going to silence a lot of the confusion, but at least I've done my best to try to clarify things.
-
-[19:33] So hopefully we'll see. Yeah, I think it's really valuable is to just check in every couple of years I'm like, what is. True. What did happen? What, what were the facts here? Oral history is very, very valuable. Sometimes capture some of that local knowledge. You put it in the paper. Yeah. I would be very curious to see what kind of oral history Dan OV can write though.
-
-[19:52] That's, uh, you know, you and I have been paying attention for a long time, but we have not been. Operating anywhere near the same level as Dan has for as long as he has. I would say, I hope it doesn't feel unfair to make the same claim for you, but useful post. Interesting. I think it's interesting too, how I.
-
-[20:10] As big as reactors, you know, the millions of people using it and relying on it and affected by it. At its core, the people in control of it is still like very countable. You know, it's not like unaccountable machine of like hundreds of people turning knobs and dials and you know, like it is at the end of the day, very much a core group of a handful of people making a lot of these decisions and doing a lot of this work.
-
-[20:37] And I feel like that's maybe, I don't know, that feels relevant when we're discussing its evolution and such. There's a team page in the React Docs and that page Curie lists about 20 people. There's about 13 to 15 at Meta at the moment. There's about five people at Versal, and then there's two or three sort of independent slash emeritus people.
-
-[21:00] So for example, Dan Abramov is not directly on the team at this point, actually. I'm not even sure if he's still listed on the page. I would've to double check. Sophie Alpert, who was at Meta for a number of years is still listed on the team page. I don't think she does a lot of development at this point, but still involved in discussions.
-
-[21:19] So it's about 20 ish people that would be considered sort of the, the core team that's separate from, you know, whoever might be doing like React native or other pieces like that. Right. React native is its own court team, which I think is larger. Yeah, I can confirm. Dan Amont was still listed on the meet between page second, so very highly along with me giving my talk.
-
-[21:43] Earlier in the afternoon. Tanner Winsley did a talk about couple different things. Some of it was, you know, pitching the various 10 stack pieces. So router query the upcoming 10 Stack start framework as well. But part of his thesis was that. Single page apps are still by far the dominant way to build React, even if there's been more of an emphasis on server side pieces in the last few years.
-
-[22:10] He really likes single page apps and a lot of his goal is to build good tooling that would be used by single page apps. I don't think any of the talks from React Summit are are online yet. I think they said they would try to have 'em online within two to three weeks after the conference. I haven't seen a notification that any of 'em were up yet, but I would definitely recommend watching Tanner's talk once the video for that's available.
-
-[22:38] Yeah, maybe we can, oh wait. Oh wait, I see a playlist. No, there's only five videos on it. Yeah. Maybe we'll be able to share those out next month. Yeah, they, I believe they, they're generally put up directly on get nation.org or.com, I think, rather than being listed in the YouTube channel. But we'll have to see.
-
-[22:57] Okay. I do see a React Summit 2025 playlist that has a couple of videos with like children views, maybe a ways to watch. Yeah. Moving on. Remix React router, going back to last month. So we've had a lot of. Back and forth between what is Remix, what is React Router? First we had React Router, the client side, LI Library.
-
-[23:21] Then we had Remix the SSR framework, and then we had Brian Forres announcement at React Conf, I think two years ago that most of the features in Remix we're going to migrate back to React router. And so React router gained things like loaders and a framework mode, and they announced that Remix was going into some kind of hibernation.
-
-[23:46] What was Remix is now basically all in React router, version seven I. And so Remix had kind of stopped development at version two last month. We talked about the announcement post where they said that Remix V three is coming. It's going to be very different. It's not just like, you know, upgrade to the latest version of React Features or something like that, but instead that it would be.
-
-[24:12] A new framework, one that actually is gonna use a fork of the pre-ACT alternative library, and with various emphasis on things like LLM based development and no bundling. That's the context for where things stand with Remix and react Router as a whole. So from there, Ryan for and Michael Jackson are both pr, you know, still pretty active on Twitter and they've been making a lot of comments that are either teasing things in directions that they want to go with Remix, but also, I'm not entirely gonna call them like clickbait or flame bait posts.
-
-[24:55] But kind of close stating a number of opinions about React itself that frankly make me very, very, very confused about what it is. Remix V three is actually even gonna look like. An example of this would be that Michael Jackson recently tweeted that he's now very disillusioned with React Hooks. You might even remember that Ryan Florence did one of the original talks at React Con 2018 where he helped, you know, demo React hooks for the first time.
-
-[25:22] And you know, granted, this is Michael's comment, not Ryan's, but I think it kind of shows their shift in mindset over the last seven years. Yeah, definitely big moves. I don't know, there's. They've been such big figures throughout my career. Like when I was learning React, I learned React rather in parallel, in like literally 2014.
-
-[25:44] And it's a little bit funny to have like been there for the whole saga because I've just watched them go like back and forth and back and forth on like what should be the API do. We care about data fetch at the router level. Just like watching them explore this and like watching their opinions shift and evolve and like double back and unfold in slightly different directions.
-
-[26:06] It's, I don't know, it is a bit of a surprise. I, I don't know. It is and isn't surprising to see Michael Jackson here come out against hooks. Also, I'll just say I was trying to confirm whether Michael Jackson still worked at Remix post Shopify acquisition, but I, I had a funny interaction years ago, managed to get enough of the profile in the ecosystem where Michael Jackson was following me on Twitter and we had a interaction during COVD about like lockdown stuff, where he was skeptical of lockdown.
-
-[26:36] And I was like, it's keeping people safe. And he ended up unfollowing me. So I don't know, like that felt like, that felt like a moment, that was a moment for me. I dunno, big famous person in the ecosystem unfollows you on Twitter. Like it stuck in my head and I don't know, it's just like, to me that feels like that feels relevant here as like point of contrarian and like, I don't know.
-
-[26:56] It's seemed since then that there was kinda like a closing off since then of him being like, Nope, I believe what I believe and I'm very confident that it is right. And like, screw all you. So I don't know. This is interesting. On the one hand, like hell yeah. Know your principles live by them and put the work in and like he's doing that.
-
-[27:16] Heck yeah. It's interesting hearing him say like, I don't like hooks. They're not great. And also like I relate to that. I don't know, like I, I started like learning hooks and like rewriting a bunch of code and using them professionally for a number of years. It felt like there was a right way to solve the problem.
-
-[27:35] It felt like I was, it felt less like I was writing code and like doing a thing and more like I was figuring out a puzzle somebody else had made with a right answer. And if you didn't get just the right answer, like you kind of had to start over. You know, it felt video gamey in that way of like, you make a bunch of progress and then you realize that you're at a dead end and it's like, let me start over.
-
-[27:54] I think that, you know, that feels like what he's complaining about here. You know, everything about them just seems so unnecessarily complex. But then he is also like down on signals, which is what a lot of other people are very pro. I'm also skeptical having used, I don't know there, I hear there are differences from event emitters, but I'm skeptical that the differences are that significant.
-
-[28:16] I keep hearing similar trade offs about circular dependencies and like event storm type of stuff. So if he's rejected like pokes and signals, which are the two top of mind ways of dealing with reactivity in React. And he's also stated the intent to use a fork of a fork of react in Remix D three. Yeah, whatever that's gonna be called.
-
-[28:39] I don't know. It's interesting. Like it doesn't sound like it's react anymore. It sounds like it's, he's gonna try and explore. The same problem space that React has been exploring, but doing so while challenging some of the core assumptions. So I don't know, it's space to watch. Yeah. And, and to be clear, like I'm, I'm not sitting here and saying like, oh no, Michael Jackson hate hooks.
-
-[29:00] He's a bad person. And anyone who's actually. Excuse, react, understands that hooks have trade-offs. They are not perfect. They have a different set of trade-offs than class components did. There are a lot of pain points, depths, arrays, data flow, you know, reactivity, mental models, et cetera. I am certainly very well aware that.
-
-[29:21] Hooks have their own set of trade-offs and flaws. But yeah, like my point, looking at the thread and this discussion is basically what you were saying, like Remix was a react based framework in version one and version two, Remix V three is not a React based. Framework, but given that they don't seem to like hooks and they don't seem to like signals at this point, I just honestly have no idea what it is they're even trying to build or what the feature set is, what the.
-
-[29:56] Usage patterns are supposed to be. I, I am just, I, I, I don't have a good mental model for what it is they're trying to do at this point, just by reading the discussion and the tweets. I believe they said that, I think there's a, a Remix jam conference coming up later this year. I think possibly in Toronto, if I remember hearing correctly.
-
-[30:18] I don't have a date for that off the top of my head, but I think it's this fall, and I think I've seen them say that they will have some announcements to make. At Remix Jam, which is understandable. I don't know, like I'm curious to see what they've got, but it, it doesn't seem like we'll really have a decent understanding until they make an actual announcement and then there's good documentation to look at, and then we could critique that.
-
-[30:39] Yeah. Right. So, I don't know. I'm curious. If they have my attention, for sure. It feels like they're being coy about it too. I feel like they have a lot more of this banged out than they're talking about and you know, I feel like there's a private group chat or like a secret repo somewhere that it'd be very fascinating to get access to.
-
-[30:57] Another little bit about this, they have posted about the open governance. Technical committee, steering committee that reactor adder will now have, I hold some skepticism, some level of skepticism just based on like the contents of this governance stock that you know, this governance announcement blog post, like notably the only people on the steering committee at inception, our existing Remix and react to router contributors, the announcement and the governance model.
-
-[31:28] Both focus very heavily on technical goals while discussing governance and how this is going to be open and like, you know, participant participatory from the ecosystem and whatever. They set up a lot of fences pretty early and strongly of this is what we care about. This is the direction we're gonna be going.
-
-[31:46] So like saying, not including outside people in the initial steering committee. And very aggressively setting direction while discussing open governance to me says this is visible governance, but I don't know if it's gonna be open to that, open to outside participators. Yeah. This feels reminiscent of like some of the working groups in the React ecosystem where they, we were just, you know, a little bit, they had blinders on.
-
-[32:11] They were gonna do their thing and they did their thing and that's great, but it's, it's not that open, it's not really that participatory. So this is, this is one that I've only partly read, but it feels like there's some amount of relevance. So the RAD X UI is a headless UI library that is pretty popular, especially because it's been used by the Shad CN component library.
-
-[32:36] But RAD X UI has been borderline unmaintained for quite a while. I believe the library itself got bought out a while back by a company called Work Os. And there's now basically a, a halftime maintainer of the library. And I've actually spoken to that maintainer before at a conference and he is like, yeah, I'm, I'm pretty burned out.
-
-[32:59] And I would almost rather like not even do anything with redix at this point. I. So there was some chatter in the last few weeks about whether people really ought to even be using it at this point. And apparently one of the original co-creators of Readex is now working on a competing package called Base ui.
-
-[33:20] And so basically saying that, look, Readex is unmaintained. Try using base ui, try using Aria kit. So I, I don't necessarily have a lot more feedback and thought and no, I have not seen Theo's video on it, so I have no opinions there. I will say that just because something is not getting active maintenance does not mean that the code is dead or suddenly more broken.
-
-[33:46] But I can definitely understand people's reluctance to use something that isn't getting, you know, like still getting active fixes. Yeah, I do have some opinions. I think that to some extent, like I don't really expect that much active maintenance from a like mature and wide used component library because there's not really that much changing in how you would develop a component library.
-
-[34:12] Like there has been so many component libraries. All like, you know, building on each other and exploring different directions and like pulling different types of abstractions and different types of like interactivity or whatever, different developer experiences. Going back for like long enough that it's pretty well trot ground at this point, and for a very long time it reacts life.
-
-[34:37] The patterns and the abstractions and the ecosystem they existed in were churning very heavily, and so it, it was not that surprising to see new component libraries coming out like every, you know, six months because there were meaningful differences. Every six months, you know, like, you know, is, is this written with higher order components or render props or hooks or, right.
-
-[35:00] Oh, you know, like when I first started, I started writing things with mix-ins, and then I was like, wow, mix-ins are, and then someone was like, oh, here's a higher order component. I was like, oh, that's cool. Let me try that. And then someone was like, here's a render prop. Here's a hook. You know? Now node and MPM support different modes of like consuming libraries.
-
-[35:21] And so now as a component library maintainer, I need to go refactor everything to support tree shaking or to be ESM only. So like there's just been so many big seismic shifts that like, yeah, we got used to that, but it's not really, that hasn't really been strongly the case for a minute now, like I would say, I.
-
-[35:44] 2022. I feel like it was when we had a, started getting, you know, as an ecosystem, the wisdom of how to use hooks had really settled down pretty well. Like we, we explored a lot of patterns and figured out things that did or did not work. And Hooks came out in 2018. 2022 is like four years of like playing with them.
-
-[36:06] And then that was three years ago. So like we've been, we've had a stable set of primitive tools within React. For doing abstractions for seven years now, which is absolutely, you know, that's longer than pre hooks. We only have three years before hooks existed. Four years, maybe five. No, it was 2013 when it came out.
-
-[36:25] So like that's more time with hooks than we had without hooks. So I don't know, like. I see this thread started with hot tape using Chad CN slash radix. The liability at this point, and maybe this is also an echo of a point that I try to drive home periodically on this podcast of like there are many different audiences using React and if you're an indie hacker than your constraints are extremely different from someone four years into maintaining a legacy application that's making tens of millions dollars for its parent company.
-
-[36:56] So like. This hot take sounds to me like someone doing small team build it and set it down projects, not somebody maintaining a legacy application. So like, sure, if you are trying to use the latest, greatest, sharpest leading edge tools, I. Is maybe that, not that name water, but I don't think it's getting rusty that quickly.
-
-[37:16] So like if you are not building a new thing every three months, I think it's probably fine. I dunno. Seems okay. And like, and you know, oh there was a really great, oh shoot, did I lose the link? There's a really great, I. Response that I saw from the maintainer of chat already, just baed it in. Lovely. Yes, thank you.
-
-[37:33] You just did that. Yeah. And he says, he says a lot of things that resonate with me that I think I have hit on here. Like here's what I'd suggest already. There's a quote here, here's what I'd suggest already using redix and prod. Stick with it. Starting a new project. Consider ics React Aria or Aria Kid.
-
-[37:49] All great choices. So like, yeah, that's, I would agree with all of that. And he closes this, what I'd suggest section with Shae is built for this code. Your own code can approve, rewrite or replace and like, yeah, that's the whole like reason for Shae and being built in the way it was, is that like it's not a library if you're unhappy with it, it's your code, it's hidden, your repo, you committed it.
-
-[38:11] So change it, commit something else. So I don't know. It seems cool. This seems, not that I have a lot of opinions on this, but at the end of the day, my opinion is like chill out, care less. Do the thing that's right for you. I guess in a very broad level, the JS ecosystem is entirely too prone to saying Tool X is dead because tool Y exists.
-
-[38:34] Yeah, I could rant about that. The human trend towards X is dead long lives. The new X on with Y? Yeah. Okay. I think we've beaten that to death now. Okay. Into our lightning round. I don't have too much to say on this, but I like it. This is a blog post. Of somebody writing React components. Enclosure, this is part three of his series, and that just seems to be, I don't know.
-
-[39:01] I love seeing people play around with server components more and playing around in different languages, in different room times. Is extra interesting, so that's cool. Just a great like use case, write up. There's been a subset of the closure script, whatever community that's used, react in their own way for many years now.
-
-[39:21] So seeing, seeing someone attempt to bring server components over in that direction's kind of cool. Dan Abramov has continued to crank out blog posts and he put out a couple more since we did our, our last podcast. He wrote one on progressive JSON, where he talks about how server components will progressively send over pieces of JSON and insert placeholders via suspense.
-
-[39:44] And then he did another post on how imports work with server components. And the majority of this post actually doesn't have anything to do with. Server components per se. It's really describing how the JavaScript module ecosystem works and then brings in some bits about how server components allow you to connect the dots between the client side and the server side, as well as enforce that certain code only exists on one side or the other.
-
-[40:13] We've got new ES 2025 out, which seems pretty good. Man, I, it, it took me a little bit to catch up on. Order of operations and what came out when. So this is everything. This contains everything that went to stage four, more or less over the past year. The most recent stage four is going out in 2026. So this what's contained here is Sync Iterator Helpers Promise.
-
-[40:40] Try some new set methods. Methods on the set primitive. That is JSON modules for imports. Import attributes and then a couple of like Redex updates for escape and modifiers and main capture capture groups. Sync iterators. Sync Iterator helpers are definitely the most like, interesting thing on this list to me.
-
-[41:00] Just like they're the, the number of times that I've taken a set or, you know, some iterable and then spread it out into an array so that it can map over. It is like constantly. I, every time I use an Iterable, I'm doing stuff like that because I like using e. Map and four each more than I like doing four ofs, so that's cool.
-
-[41:19] I'm excited to see that. Just being able to natively map over Iterable is lovely and I love it. One thing that's probably worth noting is that apparently the iterator support is, might be a little better for perf in some cases because it doesn't have to create a separate array every time you do like a filter or a map, right?
-
-[41:37] That's the main thing I think about every time I do that. Oh man, I'm just iterating a new array for no reason. New RA for no reason and kind of related promise that try is sort of a similar type of performance optimization, you know, performance micro optimization. This, the last time I was reading about it, the advantage I saw is that it lets you, it lets you ignore whether something is or is not a promise without skipping a tick.
-
-[42:03] If it is a promise, you know, and you do a dot, then like, okay, it's gonna consume a tick. But if it's not a promise and you wanna just run something afterwards. All of the like poly fills for something like promise try that would let you exit. Whether or not it returns, a promise would consume a tick. So now that, that's the advantage here is if it, if you're looking for that, it just is a little bit faster.
-
-[42:27] It's a little bit less talking. Then the, the set methods are a very nice, convenient thing. Sets now have built-in methods for intersection union difference, and a couple other things, which is something that really should have been in there from the beginning. Yeah. Definitely, there's so many more details on Axel Meyer's blog, so like definitely the dive into that and yeah, little teaser of ES 2026 is they have already sh shipped.
-
-[42:57] Well, they've already landed. Error is error, like an identity function for errors. So you can actually get like type safety in catch blocks. More easily. That is stage four, but it did not make the cutoff for S 2025, so that'll be out in 2027. There was a post on the Shopify engineering blog about the future of React Native Graphics Web GPU, SKIA and beyond.
-
-[43:21] The land of low level 2D graphics toolkits is complex with. Wrappers and abstractions and cross compat and all kinds of other layers of complexity. And so the post goes into into details on the existing React Native ski, a package for 2D graphics, how they've been able to add web GPU support to React native so they can do things like running three JS inside and some of the other upcoming improvements to React Native Skia as well.
-
-[43:51] Yeah, I, I know I've heard Mo talk about Yeah. A couple of times. See it getting, I don't know, broader. It seems cool. It's neat to see it still going, still chugging along. Cool. This is a personal plug. I wrote a blog post for the node js blog. I. It's June, it's Pride month. I'm proud. I have not always, I have accepted within the last couple of years that I am queer and began understanding what the heck that actually means.
-
-[44:18] I was asked to write a blog post for Pride and I pulled together one discussing open source and it's parallels with queer identity and how you know, we all take the labels that exist. Learn from them, incorporate them into our understanding of ourselves and use those as a springboard to find new things.
-
-[44:38] So, I don't know. I'm proud of it. I like it. It's a good post if you're interested. Check it out. Yeah, I, I've been checking the Twitter replies on the announcement and yeah. Yep. Those people still exist. They don't like it. So anyway, it's all I'll say on that. Closing with conferences, we have a quite a number of conferences coming up, like basically next week, July 3rd through fifth.
-
-[45:00] Is React Nexus in Bangalore, India. There is Big Sky devcon out in Bozeman, Montana. Which seems cool. I don't know. I I appreciate that. It's called Big Sky. I know that there's a, I think there's a big Sky National Park and I, I used to do astrophotography, so big skies are like near and dear to my heart. So this one just looks sweet.
-
-[45:22] I don't know. I don't have any, there's not no other reason beyond that for me to have an affinity foot, but I like it. So if you can get up to Bozeman, Montana. There's Kansas City Developer Conference, August 13th through 14th of Kansas City, Kansas. KCBC. 2025, which made me assume from the label that Kent c Dodds might be affiliated, but he is not.
-
-[45:42] It is not. Kent c Dodds conference. It's Kansas City Developer Conference. There is React Universe, September 2nd through fourth in Poland. Then September 16th and 17th, Wacon also in Poland back to back pretty much after Wacon. There's Cascadia Js up in Seattle, Washington, September 18th and 19th. So I think Squiggle conf is happening in Boston the exact same time.
-
-[46:07] I. Yeah, you've got SW Con, September 18th, 19th, Boston, Massachusetts. They are great. I plan to be there. This is slightly further afield for further down the line, but React Cons will be back in LA in Las Vegas. I. October 7th and eighth. So yeah, I was there last year and it was a pretty great time.
-
-[46:26] Definitely check it out. Although tickets are expensive and lottery system, so good luck. That's everything we got for you this month. Thank you so much for joining us. We will be back next month. I hesitate to promise on Wednesday because we have not done that in a minute, but maybe next month on Wednesday here in the live stage, or we'll be back in your podcast feed just as soon as we can after that.
-
-[46:46] Scheduling is hard. Yo scheduling is so hard. We gather sources from this week in React Bites. Do Dev React status, Next.JS Weekly the React JS subreddit. And here in react to plugs from the Tech News Andres channel. If you have any news that you wanna share with us. Tech Reads and News is a great place to do so, or you can send it to us at hello@reactiveflex.com.
-
-[47:09] If this is a show that you get value from and would like to support, one of the best ways you can do so is give it a review on whatever platform you listen to, listen to it on, and just share it with friends, share it with coworkers. Go to a meetup and say, Hey, there's this great podcast. I like. Yeah, thanks so much for listening.
-
-[47:25] We'll see you next month. Take care.
diff --git a/src/transcripts/tmir-2025-07.md b/src/transcripts/tmir-2025-07.md
deleted file mode 100644
index 0bc5808..0000000
--- a/src/transcripts/tmir-2025-07.md
+++ /dev/null
@@ -1,669 +0,0 @@
----
-title: "TMiR 2025-07: Vercel shakeups, new React Compiler docs"
-date: 2025-07-28
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-# This Month in React: July, 2025
-
-- [[01:17](#new-releases)] New Releases
- - [[01:20](#rn-reanimated-v4)] [RN Reanimated v4](https://blog.swmansion.com/reanimated-4-stable-release-the-future-of-react-native-animations-ba68210c3713)
- - [[08:46](#rn-ignite-toolkit-v11)] [RN Ignite toolkit v11](https://shift.infinite.red/announcing-ignite-11-bison-f2802a85f94d)
-- [[10:18](#main-content)] Main Content
- - [[10:21](#compiler-docs-are-merged-live-docs-and-config-api)] [Compiler docs are merged!](https://github.com/reactjs/react.dev/pull/7868) ([live docs](https://react.dev/learn/react-compiler/introduction), and [config API](https://react.dev/reference/react-compiler/configuration))
- - [[11:42](#expo-docs-say-its-on-hold-but-evan-bacon-says-expo-54-may-enable-the-compiler-by-default)] [Expo docs](https://docs.expo.dev/guides/react-compiler/) say it’s “on hold”, but Evan Bacon says [Expo 54 may enable the Compiler by default](https://x.com/Baconbrix/status/1949714155482841094)
- - [[12:45](#oh-no-more-function-directives-use-memo-and-use-no-memo)] Oh no — [more function directives](https://react.dev/learn/react-compiler/incremental-adoption) , “use memo” and “use no memo”
- - [[12:51](#directives)] [DIRECTIVES](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
- - [[13:13](#good-thread-on-some-history)] [Good thread on some history](https://x.com/en_JS/status/1948502925468467369)
- - [[14:19](#some-tech-discussion-on-the-complexities-of-making-react-compiler-work-with-oxlint)] Some tech discussion on [the complexities of making React Compiler work with Oxlint](https://github.com/oxc-project/oxc/issues/10048)
- - [[15:41](#directive-prologues-and-javascript-dark-matter)] [Directive prologues and JavaScript dark matter](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
- - [[18:01](#node-api-support-for-react-native)] [Node API Support for React Native](https://www.callstack.com/blog/announcing-node-api-support-for-react-native)
- - [[21:49](#vercel-shaking-things-up)] Vercel shaking things up
- - [[22:02](#leerob-is-at-cursor-now-five-things-he-learned-at-vercel)] [Leerob is at Cursor now](https://x.com/leerob/status/1943446393819177342) — [Five Things \\[he\\] Learned at Vercel](https://leerob.com/vercel)
- - [[27:43](#swc-creator-leaves-focusing-on-swc-for-a-while)] [SWC creator leaves, focusing on SWC for a while](https://x.com/kdy1dev/status/1941129219293225273)
- - [[28:01](#sam-selikoff-just-joined-to-do-content-and-stuff)] [Sam Selikoff just joined to do content and stuff](https://x.com/samselikoff/status/1943325592260092298)
- - [[28:23](#nuxt-acquired)] [Nuxt acquired](https://x.com/nuxtlabs/status/1942575789645640071)
- - [[29:58](#netlify-staff-eng-philippe-serhal-replies-to-the-vercel-deployment-adapters-rfc-from-april)] [Netlify Staff Eng Philippe Serhal replies to the Vercel Deployment Adapters RFC from April](https://github.com/vercel/next.js/discussions/77740#discussioncomment-13893373)
- - [[30:48](#ryan-carniatos-react-and-signals)] [Ryan Carniato’s “react and signals”](https://www.youtube.com/watch?v=VgGl9i-OBBI)
- - [[33:09](#react-native-unistyles-30-released)] [React Native Unistyles 3.0 Released](https://www.reactnativecrossroads.com/posts/introducing-unistyles-3)
- - [[35:39](#react-router-and-rscs-the-path-forward)] [React Router and RSCs: The Path Forward](https://remix.run/blog/react-router-and-react-server-components)
- - [[36:57](#parcel-writeup-for-server-components)] [Parcel writeup for Server Components](https://devongovett.me/blog/parcel-rsc.html)
- - [[37:26](#wip-vite-rsc-plugin-support)] [WIP Vite RSC plugin support](https://github.com/vitejs/vite-plugin-react/issues/531)
-- [[38:15](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[38:35](#corbins-history-of-react-through-code-deep-dive)] Corbin’s [“History of React Through Code”](https://playfulprogramming.com/posts/react-history-through-code) deep dive
- - [[39:06](#tkdodos-thoughts-on-when-usecallback-is-useless)] [TkDodo’s thoughts on when `useCallback` is useless](https://tkdodo.eu/blog/the-useless-use-callback)
- - [[39:26](#eslint-config-prettier-compromised-as-part-of-an-npm-supply-chain-attack)] [`eslint-config-prettier` compromised](https://safedep.io/eslint-config-prettier-major-npm-supply-chain-hack/) as part of an [NPM supply chain attack](https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise)
- - [[40:48](#expo-router-demo-by-evan-bacon-ai-rscs-expo-router)] [Expo Router demo by Evan Bacon AI \+ RSCs \+ Expo Router](https://github.com/EvanBacon/app-that-builds-apps)
- - [[41:16](#some-tech-details-on-how-meta-serves-react-pages)] Some tech details on [how Meta serves React pages](https://www.reddit.com/r/reactjs/comments/1ltbw2e/how_does_facebook_serve_react_pages/)
- - [[41:40](#nitro-image-library-for-react-native)] [Nitro Image library for React Native](https://github.com/mrousavy/react-native-nitro-image)
- - [[42:08](#a-very-hacky-way-to-test-rsc-components)] [A very hacky way to test RSC components](https://www.nico.fyi/blog/how-to-test-react-server-component)
- - [[42:31](#a-good-technical-dive-into-improving-inp-in-a-next-app)] [A good technical dive into improving INP in a Next app](https://medium.com/preply-engineering/how-preply-improved-inp-on-a-next-js-application-without-react-server-components-and-app-router-491713149875)
- - [[42:51](#extra-css-properties-in-react-native)] [Extra CSS Properties in React Native](https://github.com/facebook/react-native/pull/52284)
- - [[43:16](#chrome-137-adds-if-support-in-css)] [Chrome 137 adds `if` support in CSS](https://developer.chrome.com/blog/new-in-chrome-137)
- - [[44:50](#react-devtools-for-firefox-may-not-get-updated-due-to-review-restrictions)] [React Devtools for Firefox may not get updated due to review restrictions](https://bsky.app/profile/ricky.fm/post/3ltkxpo5ewk2i)
- - [[46:29](#both-oxlint-and-biome-are-investigating-typed-lint-rule-support-biome-v2-tsgolint)] [Both `oxlint` and `biome` are investigating typed lint rule support](https://www.solberg.is/fast-type-aware-linting) ([Biome v2](https://biomejs.dev/blog/biome-v2/), [tsgolint](https://github.com/oxc-project/tsgolint))
- - [[47:49](#remix-v3-dev-branch-containing-support-packages)] [Remix v3 dev branch containing support packages](https://github.com/remix-run/remix/tree/v3)
- - [[48:40](#react-native-wallet)] [React Native Wallet](https://blog.swmansion.com/introducing-react-native-wallet-90c1ee103d3e)
- - [[50:07](#deno-v-oracle-update)] [Deno v Oracle update](https://deno.com/blog/deno-v-oracle4)
- - [[51:23](#content-independence-day-from-cloudflare-theyre-blocking-ai-crawlers)] [“Content independence day” from Cloudflare](https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/) (they’re blocking AI crawlers)
- - [[52:04](#some-updated-static-hermes-perf-numbers-release-available-soon-being-tested-internally-at-meta)] [Some updated Static Hermes perf numbers](https://x.com/tmikov/status/1945348222110859500) release available “soon”, being tested internally at Meta
- - [[52:47](#state-of-html-survey-is-open)] [State of HTML Survey is open](https://survey.devographics.com/en-US/survey/state-of-html/2025)
-- [[53:26](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[53:29](#big-sky-dev-con-aug-2-bozeman-mt-usa)] [Big Sky Dev Con](https://bigskydevcon.com/) Aug 2 Bozeman, MT, USA
- - [[53:36](#kansas-city-developer-conference-aug-13-14-kansas-city-ks-usa)] [Kansas City Developer Conference](https://www.kcdc.info/) Aug 13-14 Kansas City, KS, USA
- - [[53:47](#react-universe-conf-sept-2-4-2025-wrocaw-poland)] [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025. Wrocław, Poland
- - [[53:57](#waysconf-sept-16-17)] [WaysConf](https://www.waysconf.com/) Sept 16-17
- - [[54:06](#cascadiajs-sept-18-19-seattle-wa-usa)] [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [[54:10](#squiggle-conf-sept-17-18-boston-ma-usa)] [Squiggle Conf](https://squiggleconf.com/) Sept 17-18 Boston, MA, USA
- - [[54:17](#react-conf-is-back-oct-7-8)] [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l)
- - [[54:22](#remix-jam-oct-10-toronto-canada)] [Remix Jam](https://remix.run/jam/2025) Oct 10 Toronto, Canada
-- [[54:33](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the July edition of this month in React, where we recap and digest all of the latest news and developments in React. React Native, and across the web. We're coming to you live from Reactive Flux, the place for professional developers using React. [00:00]
-
-I am a staff product developer and freelance community leader here in React Flux where I do community programs like these events and build tools to help keep the community operating. May be making more progress on one of those. So maybe I'll do a product announcement in the next couple of weeks or months maybe. [00:16]
-
-**Mark:** Hi, I'm Mark. I maintain Redux. My day job is at Replay where we've built a time traveling debugger and are currently trying to get in on the AI app generating craze. And other than that, I may moderate things and read too many articles. [00:32]
-
-**Mo:** My name is Mo. I head the mobile team at Theo. I'm an active member of the React Native community and I organize the React Native London Meetup and the React Native London Conference. Excited to be here. [00:46]
-
-**Carl:** Excellent. Yeah. We missed you Last month there was react native things to discuss. [00:58]
-
-**Mark:** We had no idea what we were talking about. [01:01]
-
-**Carl:** Not even a little bit. We basically just punted on it. Great. Cool. [01:03]
-
-I'm gonna skip job market stuff. I don't think I'm gonna do that anymore. 'cause like who even knows what's going on? The jobs are wild and the indicators are. Too fuzzy to really be that useful, I think. [01:07]
-
-## New Releases
-
-**Carl:** Mo, tell us about some React native new releases. [01:17]
-
-## [RN Reanimated v4](https://blog.swmansion.com/reanimated-4-stable-release-the-future-of-react-native-animations-ba68210c3713)
-
-**Mo:** Cool. So we recently had React Native Reanimated version four being released. So for those of you who are sort of avid React native developers, you'll know that React Reanimated is sort of the defacto way. To be able to animate elements, layouts and whatever you have inside of your React native applications. [01:20]
-
-So the team's been hard at work. Animates has been around as a package for, for several years now, and they've been iterating on it and making it better and better over time. There's a general push that you'll sort of know from the previous episodes over the last year or so towards sort of unifying React native and react in the web as much as possible. [01:40]
-
-And so CSS transitions and animations are sort of becoming a key part of Reanimated as well, so that the APIs and the way that you can animate things in Native world are as similar as possible. Obviously there's some limitations that can't make it one-to-one, but as similar as possible between web and mobile. [01:59]
-
-And one of the other things is now that we're in this world where you could use React native on web and mobile, trying to find a way to have performance. Web-based animations and transitions is quite important as well. And Reanimated has been working on this under the hood so that when you do use reanimated in your React Native universal app, it actually has performant animations on the web as well, not just on native devices. [02:18]
-
-One of the challenges in the past has been that it's not quite great on the web because it would use JavaScript to orchestrate animations. Not really great, and really, really bogs down the performance of your app on the web. So some good work being done there. A few other things to mention is that Worklet is a part of Reanimated as well. [02:41]
-
-It's, it's a way to basically allow some level of multithreading in your apps. It kind of formed as a need of reanimated itself, but they've made it sort of an open public API that you can access for other multithreading needs that you may have. So they're trying to move that. Across into sort of a separate library and start to separate that up because it's not just useful for reanimated or animations. [02:59]
-
-It's useful for a whole bunch of other stuff like background fetching and, and you know, computationally heavy tasks that you need to run behind the scenes. Other things to mention is that Reanimated used to be this huge package and once you had, you know, imported one thing and Reanimated, everything was imported and so obviously that affects things like your app bundle size. [03:21]
-
-They've now took an approach to make it modular so that you can import. And Bobs of Reanimated rather than the whole thing. Obviously it's not just a JavaScript sort of tree shaking thing that matters here because we're in Native World. There's also sort of the native compiled code and you need to be able to modularize that as well. [03:38]
-
-So it, it's not necessarily a straightforward process for the team, and I appreciate that. It was probably quite complex to decouple a lot of this code and separate it up into different packages, both on the native layer and the JavaScript layer. [03:54]
-
-**Carl:** What does that affect on a native. Package, I guess like app, total package size, or does it affect like startup performance and things like that? [04:04]
-
-**Mo:** It, it can affect both. Mainly the app total size that you would need to download is, is a key thing. It can also affect, like you say, the startup time, albeit startup time is largely sort of. Handled by Hermes, the engine that's been created for React Native specifically because it, it sort of optimizes to, to avoid large startup times as a result of having a big app bundle. [04:11]
-
-But it's really mainly the, the, the bundle size. And again, when we're going into this sort of web and mobile world where you use the same packages across the board, modularizing as well on the web, even though you'll have tree shaking, is going to be good practice so that you're not importing a whole bunch of stuff that you don't need. [04:33]
-
-Lastly, and I, I think this is. Something that everyone is quite passionate about in the React native ecosystem and has been a challenge is shared element transitions. So shared element transitions is sort of the transitions that you might be familiar with in the native world where an element is is sort of present and is animated from one screen to another. [04:49]
-
-So when you navigate from one screen to another, there's this sort of shared element. So it might be like an image you click on and you navigate to a sort of detailed view of that image. You have a navigation that happens in the background. But you want to have these on separate screens, but you wanna kinda keep that seamless expanding of the image animation as an example or transition. [05:08]
-
-This is very difficult to do in React Native. You can kind of achieve it in some hacky ways, but it's sort of on the app developers to figure it out. There's not been like a unified API that you can use and it's usually quite hacky and doesn't work most of the times. They are working on this, [05:26]
-
-**Carl:** would that be stuff like flip animations, like first, last, interpolate, play? [05:38]
-
-**Mo:** No, I don't think it would be flip animations. The examples that I would give is, you know, like in Instagram as an example, if you're on the, the search page and you see a set of posts that are sort of laid out in a grid and you click on one of those posts, it expands out and takes over the whole screen. [05:43]
-
-Right. [05:57]
-
-**Carl:** I meant more like would the hacky interpret in the hacky implementation of. what should be a shared element transition? Would that be, is that the kind of thing somebody might use flip for? [05:58]
-
-**Mo:** I'm not sure, I haven't actually seen flip, but there are some approaches where people have been sort of tapping into the native layer to be able to do that manually, but it's not gonna be quite extensible putting some tags and then using the native layer to do those transitions. [06:08]
-
-So there's a few different approaches that I've seen people do some sort of like third party libraries that people have created as POCs more than anything is how I've seen it done. The, the, the gist of it is that there isn't really like a. Standardized well-defined and like well tested API to do this in React Native. [06:20]
-
-And so that's what the Reanimated team have been working on. It's not out yet, but they've said that they're gonna be releasing it as part of this major release cycle. So four dot something will have. Some support for shared element transition, still TBC, but keep your eyes open for that one. [06:37]
-
-**Mark:** Cool. [06:52]
-
-Honestly, that whole discussion reinforces how many things people are doing that I have no experience with whatsoever. [06:53]
-
-**Carl:** Love that. Yeah. I guess just to close the loop a little bit on like flip animations, like it reminds me a lot of shared element here. 'cause I guess like shared element means that it doesn't like vanish. [06:58]
-
-You know, it's one thing persists. From this state to that state. That's my general understanding of it. And how I had done that in 2017 was, so you've got the current state, you've just rendered, you have something up and then you re-render and you get the new state. Then you have some abstraction that cracks the old state after the new state shows up and says, okay, this element is tagged with this animation, you know, indicator. [07:09]
-
-And that indicator has now gone to this element in this new state. It used to be here. Now it's here. Let's measure it triple eight, you know, the old size versus the new size. And then do Aran smooth transition, you know, generate a CSS animation to make it look like it's the same element. [07:37]
-
-**Mo:** Yeah, it gets a little bit more complicated in the native world because these are different sort of screens that are different view nodes on the native layer, you'd need to have a little bit more control over how you do that on the native layer, the native layer might override it. [07:54]
-
-If you write that JavaScript logic as an example, it definitely needed some native components to be able to handle it. Under the hood, the algorithm and the native layer will do something very similar, which is first screen, screen A has this size for this element. Screen B has this size. Let's look at the positions and interpolate the values and the, the zoom of it to match the target size as we're migrate, as we're opening up the new screen as an example. [08:07]
-
-**Carl:** Right. Oh, interesting. Okay. Sure. On native, there are things already doing that for you, so you don't need to hack into the, into that. You just need to actually support it. Cool. Makes sense. Okay. [08:29]
-
-**Mark:** Probably just as well. We really didn't have all that many new items and new release items this month, given that we just sort of deep dived on that one. [08:40]
-
-## [RN Ignite toolkit v11](https://shift.infinite.red/announcing-ignite-11-bison-f2802a85f94d)
-
-**Mark:** So one other thing from the React Native world, the Infinite Red has a very long running boilerplate toolkit called Ignite, and they just put out version 11. The big news for this one is it. Only sports, the new architecture. It's been bumped to E Expo, SDK 53, some changes to the theme implementation and they've made it bring your own state management. [08:46]
-
-They used to default to MobX State Tree and now they've tweaked it. So you can pick and choose how you want your state to be handled within the new app. [09:06]
-
-**Mo:** There's a little bit of context here, which is that the maintainers of this library, infinite Red, have been very opinionated on Malbecs being the best sort of tool for React Native. [09:14]
-
-State management there. There's some some reasons behind that. Like Mob State Tree is quite good in terms of sort of heavy memorization and that can really affect performance if you don't have stuff like that and React native or you're not careful. So I think they were trying to set some practices that they were used to. [09:25]
-
-**Mark:** And also I believe Jamon from Infinite Red was the maintainer of MobX State Tree for a number of years, and he either still is or recently handed it off to somebody I think. [09:41]
-
-**Mo:** Might be that he was maintaining it to some degree. Yeah. [09:51]
-
-**Mark:** So I mean there was, there was a very understandable preference there. [09:54]
-
-**Mo:** So the main maintainer of MobX and MobX State Tree as far as I'm aware is Michelle West Streett. [09:56]
-
-From WHO, who works at Meta, [10:00]
-
-**Mark:** I think Michelle handed off MobX State Tree to into Jamon a number of years ago. Okay, cool. Didn't know about that really. That's fair enough. [10:02]
-
-**Carl:** Oh, interesting. I didn't know that [10:08]
-
-**Mark:** he spiked MobX State Tree. And then it's like, okay, I've, I've proven I can build this, but I don't have time to maintain it would someone else like to? [10:10]
-
-Cool. [10:17]
-
-## Main Content
-
-**Mark:** Onto the main content for today? [10:18]
-
-## [Compiler docs are merged!](https://github.com/reactjs/react.dev/pull/7868) ([live docs](https://react.dev/learn/react-compiler/introduction), and [config API](https://react.dev/reference/react-compiler/configuration))
-
-**Mark:** The big news this month is that the React team has written completely brand new docs for the React compiler. Not only did they put them up as a PR this month, that PR has been merged and the new docs are now live. Previously there was just a single page under the installation setup section of the React Docs that gave some amount of details, and now the React compiler has its own top level section with multiple pages under both the learn and reference sections of the React docs. [10:21]
-
-These sections cover a lot of things. What is the compiler? What does it do? How does it work? Should I try it out? What build tools do it? Does it work with? How do I install it? How can I incrementally adopt the compiler? As well as some reference section information, talking about configuring it and some of the concepts it includes. [10:54]
-
-And even like if I'm a library author, should I pre-compiled my library bundle to make use of the compiler? So it's very clear that they've been looking at some of the discussion threads where people have complained that, you know, it doesn't feel like it's ready for adoption yet. I don't know if it, you know, I don't know how to configure it. [11:16]
-
-And they've taken a lot of that to heart and put together some pretty good docs to try to actually address a lot of those points. [11:34]
-
-## [Expo docs](https://docs.expo.dev/guides/react-compiler/) say it’s “on hold”, but Evan Bacon says [Expo 54 may enable the Compiler by default](https://x.com/Baconbrix/status/1949714155482841094)
-
-**Mark:** We noted that the, if you look at the expo docs, there is currently a section that says that their integration with the React compiler is on hold, but that may be superseded because I saw a tweet from Evan Bacon just earlier today where he said that we are actually going to enable the React compiler by default in Expo version 54. [11:42]
-
-And along with that, the compiler docs themselves in the introduction section. Actually say like, should I try the compiler and is it safe to use? And they specifically say at this point, we encourage everyone to start using it. It's still optional, but it's in release candidate. It is safe to use. It's been tested in production and we really would like people to actually try it out. [12:05]
-
-Of course they do. [12:30]
-
-Oh yeah. But I mean it's, it's a pretty big vote of confidence that this is not just a whim. That it is something they're very serious about, that it is basically ready for release and that they would like to see the ecosystem start adopting it. [12:31]
-
-**Carl:** Yeah, makes sense. [12:43]
-
-## Oh no — [more function directives](https://react.dev/learn/react-compiler/incremental-adoption) , “use memo” and “use no memo”
-
-**Carl:** I am not super thrilled about seeing more function directives being introduced here. [12:45]
-
-## [DIRECTIVES](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
-
-**Carl:** Like I'm on record for like the past two years here, being frustrated with introducing more and more directives, and so seeing now basically a compiler flag for memorize or don't memorize this. As the, uh, incremental adoption method. I just don't like it. It's, it feels like magic. It feels gross. I don't like it. I don't like directives. They scare me. [12:51]
-
-## [Good thread on some history](https://x.com/en_JS/status/1948502925468467369)
-
-**Mark:** Couple other compiler bits of news. There was some discussion on Twitter, I believe, where Joseph from the React compiler team gave a little bit of background on who had worked on the compiler, some of the timelines and some of the influences, and then the compiler right now has a couple limitations in terms of tool support. [13:13]
-
-One is that while the 90% of the compiler code is its own independent true compiler, currently the only way to integrate with that and actually use it is via a babble plugin shell around it, which also means you have to have babble. In your build pipeline, and a lot of people are not happy about that. We got rid of babble. [13:33]
-
-We use, we use SWC, we use, you know, whatever other, you know, ES build something that's not babble anymore. And so there's been lots of questions about, you know, when will they get around to offering a non babble integration? No timeline on that yet. But as a related part of that, the lint rules that React offers are also ES lint based. [13:55]
-
-## Some tech discussion on [the complexities of making React Compiler work with Oxlint](https://github.com/oxc-project/oxc/issues/10048)
-
-**Mark:** And we now have other winters like biome and oxalate that are not ES lint and not esent compatible. So there was a pretty good thread between the React compiler team and the oxalate team talking about like what would it take to make React compiler and the React ES lint rules. Runnable inside oxalate, and there's a bunch of low level technical details about, you know, js rust interop and, and some of the complexities that might be needed there. [14:19]
-
-So the answer is probably not anytime soon, but there's discussions about what it might take to make that happen. [14:48]
-
-**Carl:** Yeah, and circling back to your, you know, good thread with like some timeline and influences and whatever frustration I have, this is like such a, this is exactly the same problem that React and I guess web and like development in general has had for a long time. [14:55]
-
-But like all of that happened on Twitter and like that's great knowledge and such good resource. But the guy who asked the question asked it on his private alt. So like, if you are not one of the, you know, 1100 approved people that he has granted access to see his thoughts, you can't see what was asked, just the response. [15:09]
-
-So at least you can see the response. That's nice. But I wish they'd put something like this in like, I don't know, an introspective blog post or whatever. So. I'm just gonna keep shouting at clouds throughout this episode, I think. Cool. Cool. Let's move on though, [15:28]
-
-**Mark:** even before we get there. [15:40]
-
-## [Directive prologues and JavaScript dark matter](https://macwright.com/2025/04/29/directive-prologues-and-javascript-dark-matter)
-
-**Mark:** I found the article I was looking for, it was indeed in Tech reads the news a few weeks ago. [15:41]
-
-This was in linking a post on directives, prologues and JS Dark Matter, which was an archeological explanation of how things like JSX, pragmas and function directives and magic comments. Have all been used to indicate to build tools, Hey, do something different with this code than what you would expect. [15:45]
-
-Just reading it. [16:05]
-
-**Carl:** Love that. That is actually really good. And like basically this is all just communicating with different levels of abstraction between like runtime and source code. So it's like, I don't know, the linter or the formatter or the, I don't know. I guess you don't really do tests so much there, you just do it elsewhere. [16:06]
-
-But the compiler, or transpiler compiler is now a fuzzy, overloaded term, and I guess they all make sense for one reason or another, but something about directives and the way that they like persist through. I prefer a magic comment, like at least a magic comment is like very clearly something like not runtime. [16:24]
-
-I don't know, something about it feels wrong. The [16:41]
-
-**Mark:** fact that a directive is just a string hanging out there. [16:44]
-
-**Carl:** I dunno. It seems weird. And since it is just a string, like why not a magic comment? Ah, I don't know. Maybe there was some kind of weird esoteric, like the compiler, you know, the, all the various compilers and whatever, transpilers, and ASTs transformers are all like, maybe they muck with comments and whatever, but also like the compiler requires that you put it first in your Babel so it gets the untransformed code anyway, so that doesn't sound right to me. [16:47]
-
-I don't know. Weird doesn't seem necessary. I guess the root of my angst here is that like when they introduced the "use strict" directive, like when they introduced the concept of a directive, they said, we're never gonna do this again. Like, don't do this. This is bad. We should, we shouldn't have had to do this, but we did because weird legacy concerns don't do any more of these. [17:13]
-
-**Mark:** And then the community decided, okay, now we got a new mechanism to play with. [17:32]
-
-**Carl:** We got like, how many do we have for React now? Like. I can think of four off the top of my head. [17:36]
-
-**Mark:** Client server memo. No memo. [17:40]
-
-**Carl:** Yep. Okay. Maybe four, but like, come on. That's 400% increase from one. Come on. [17:43]
-
-**Mo:** Now you can have two at the top of one file, which is gonna look weird. [17:49]
-
-It's gonna take some time getting used to that one. Wait, [17:52]
-
-**Carl:** can those even, are the, is that even compatible? 'cause it's gotta be, the directive has to be the first line. I [17:54]
-
-**Mo:** don't know how that would even work. Moving right along. [17:58]
-
-## [Node API Support for React Native](https://www.callstack.com/blog/announcing-node-api-support-for-react-native)
-
-**Mo:** Alright, so back into React Native World. The folks at call Stack have been working on some other projects under the, under the smoke screens, and it's some cool stuff that they've released. [18:01]
-
-They've basically enabled Node API support at a very basic, primitive level. They're, they're working, still working on this. They've made some good headway with this. So they're bringing Node API support into React native. Now, not to be confused with node itself, node API is basically like a mechanism by node js that allows you to use C based languages to interact from JavaScript code to call native code. [18:12]
-
-And so you can write native add-ons in CC plus plus. Even rust or swift. And then they can be used and ingested by JavaScript applications. So there's a few reasons for doing this and it, it really goes more into the internals of React Native. And you know what this means for library maintainers, for built tool maintainers, and for really meta itself as well. [18:38]
-
-But the two key things here is faster build times. And closer convergence with native web libraries that may already exist and be using the node API mechanism. So at a first level build times, and I think this is the bit that will affect users more than anyone else is. Basically in the rate of world today, most native modules are actually distributed a source. [18:59]
-
-So every time you make a build, you actually have to compile it all and do the build step, which is quite long. Building a typical rec native app somewhere around 10 to, if you've got a massive scale app, it could takes several tens of minutes to actually do the full build of the app, right? But it's a long, long time now. [19:22]
-
-You don't need to do this for like your development workflow typically, or that often, because you wouldn't change native dependencies every day. You would just do this when there's a new native dependency that's been introduced, but it's still a significant amount of time. Right? And so the idea is if we can get some of these prebuilt. [19:41]
-
-Using a mechanism like the node APIs, then we can bring this time down quite significantly. And so one of the things that they ran as a test was for a basic sort of React Native core app that you know is just having the basics of React native within it. They think that they could bring down. The build time to close to seven seconds, which would be insanely fast in comparison to what it's today. [19:59]
-
-So this could be some really cool stuff that's down that's coming down the line. The other side is that there is already an ecosystem of node API compatible sort of applications and run times, and so, so many sort of libraries. Web API libraries like Web RTC or Web Audio Canvas. These are implemented with node API. [20:21]
-
-Now, they're not going to be direct one-to-one mappings for native, but there is already an initiative to try to, to try to align on the web API spec. And so this is sort of another part of that puzzle. And so if you bring these two together, suddenly we can use sort of web APIs and React native, and it could be a really, really cool future to look into. [20:42]
-
-None of this is. None of this is sort of like fully there, and there's gonna be, this is a long term effort, but it's something that they announced this month, and it's quite exciting. [21:02]
-
-**Carl:** I've had enough struggles with native binaries on desktop where they're, you know, like intended to be compiled for just like, like mostly across, like upgrading, upgrading a version of that, or node versions or whatever. [21:11]
-
-But I, I've had enough struggles and complications there to be wary. Of what the actual experience of using this will look like. But this is, this is really cool. This just even having made enough progress at this to announce it and like meaningfully talk about it as a thing they desire is pretty cool. [21:25]
-
-Very hard, really hard problem. I'm curious how they're implementing it. [21:43]
-
-**Mo:** It's definitely not trivial. [21:48]
-
-## Vercel shaking things up
-
-**Carl:** Cool. Alright, moving on a bit. So there's been a bunch of Vercel things this week, a fair number of departures. I'm sure people are coming and going all the time and we just, you know, we can't get a comprehensive list of that. [21:49]
-
-## [Leerob is at Cursor now](https://x.com/leerob/status/1943446393819177342) — [Five Things \\[he\\] Learned at Vercel](https://leerob.com/vercel)
-
-**Carl:** But they, they had a couple of relatively high profile departures in the last month, starting with the most notable Lee Robinson, who has been there for. Five years, a long time. Was he there before COVID? [22:02]
-
-**Mark:** Not sure on the timeline. Like it, it felt like he'd been there much longer than that, but apparently it has only been five years. [22:15]
-
-**Carl:** Yeah. Okay. No, you're right because he, he put out a blog post. Well, anyway, I'll, I'll stop speculating on the timeline, but to me, he is highly identified. With Versel, like, you know, if I think of Versel, I think of, uh, Guillermo, Roush, and Leero, just like by volume of activity and like prolificness in content and social media interaction and blog posts and example resources. [22:21]
-
-So just all of it. So he has now left Versel and is working at Cursor, which like. That seems great, at least in terms of like mind share and hype and you know, alignment, potential, alignment with future, whatever. Cursors is definitely a really hot company right now. I've had some private conversations of with like, can they keep doing that? [22:45]
-
-'cause at the end of the day they're a fork of VS code and like fork of a large project with 30 people working on it. Which I think is in the ballpark of how many employees Cursor has versus like Anthropic, which is, you know, a giant, huge beast with all of the money. So like it's cool. Great for him. [23:05]
-
-Definitely there's a lot more like oxygen in the room in terms of excitement and like potential at cursor. I think so. Cool. I'll be keeping an eye on that. I use cursor. It's nice, so he'll still remain in my, I don't know, professional spheres. But yeah, he had a really good blog post that he put up called, UH, five Things I Learned From Five Years At Versa. [23:24]
-
-I appreciated it. His number one was go hard at work, then go home, and he closes it with, when I'm offline, I'm offline. I'm a hundred percent focused on my wife and daughter. To be clear, I still get this wrong sometimes. It's a never ending pursuit of work, life, harmony, takeaway. You can work really hard and set clear boundaries. [23:46]
-
-I'll say That's hard. I struggle with that. I don't, I don't have a wife, I don't have kids. So like in that section he talks about like responding to tweets from the beach on his honeymoon and like, yes, I want to believe that you can work really hard and set clear boundaries to where you're not working on vacation doing, you know, social media comms work from the beach, but also like if you're not there. [24:03]
-
-Like, people aren't gonna wait three days for you to get back from vacation to, you know, get the authoritative answer. Like, if they ask a question, then like, the person who is Johnny on the spot answering it in their time of need, like they are gonna get the, I don't know, the kudos, the energy they're gonna, you know, people are gonna start gravitating towards them for future questions. [24:27]
-
-I'm like, that's. This going so hard is how Leero managed to get that level of status, like in my own brain. And so I wanna believe you can work really hard and set clear boundaries. I'm not always so sure about that. I, I dunno. I wrote, I actually wrote a little blog post kind of on that subject almost exactly a year ago. [24:47]
-
-I'll link it here. I probably won't put it in the transcript. Just kind of talking about that general thing and like I, I had a kind of similar experience to what he describes here of like, going really hard and like poor boundaries and like burnout and all of the, a lot of the benefits, a lot of the costs. [25:06]
-
-And what I kinda realized is that like, I don't know that I could have achieved the kind of success that I got without that level of burnout and I don't know, poor boundary setting because like, it's because I gave. All of my attention to maybe not just work, like some of, a lot of my attention, you know, the full-time work, but also investing in things like reactive flex or just learning new tools and staying on top of the cutting edge outside of work. [25:23]
-
-Like that was really poorly boundaried and like fully throughout my twenties, I ignored a lot of myself. I just really think that that is, I wanna believe that you can succeed and achieve big success without giving up that kind of, I don't know, intimacy with yourself. But I don't know that you can, I don't know, it seems really hard. [25:50]
-
-And it, it just notable to me that like the only people I see talking about that and like saying things like, you can work really hard and set clear boundaries are the people who had poor boundaries, achieved success, and are now reflecting on it. So, I don't know. [26:09]
-
-**Mark:** Yeah. It, it is tough, but I, I have a, I have a lot of respect for Lee Rob and that the work and effort that he's put in, when I just think of the word derel, he is the first that comes to mind. [26:22]
-
-He, he's always, you know, omnipresent in any kind of Reddit or Hacker News or Twitter thread that mentions Versel and Next. And, you know, even if you maybe, you know, at times disagreed with, you know, what he was saying or representing the company wine, he absolutely like did a great job of being there and answering questions and, and being involved in reaching out. [26:33]
-
-It's definitely a loss for Versel and when I wrote my React Community article, you know, recently, I had a line in there about Versal had a large Dere team that updated the next docs, and he corrected me. It's like, no, there were two of us at that point. I was like, oh, whoops. I got that wrong. It seemed like you had a large team because you were doing so much work. [26:55]
-
-**Carl:** Right? So, yeah, I don't know. From the comment, from the, from chat, from re Sam, bit of taking advice from lottery winners, vibe occasionally like, yeah, that's, that's what it is. It sounds like survivor bias, things like that. Anyway, this is, we're already like kind of far afield from where we started here. [27:21]
-
-This was talking about Versel and some of their updates. This was a good piece. Lee Rob, wish him the best at cursor. I'll be paying attention still. [27:35]
-
-## [SWC creator leaves, focusing on SWC for a while](https://x.com/kdy1dev/status/1941129219293225273)
-
-**Carl:** The, uh, creator of SWC also left Versal. He's taken some time to, to rest and focus back on, uh, SWC again, so that's great. I'm not as familiar with him as a, you know, individual human, but I am familiar with s wc. [27:43]
-
-So cool. Good luck to him. Love that. [27:59]
-
-## [Sam Selikoff just joined to do content and stuff](https://x.com/samselikoff/status/1943325592260092298)
-
-**Carl:** And another prolific react ecosystem speaker and like educator, Sam Selikoff joined Versal to do content and some other things. His Twitter feed is all like, all about ramping up and like, you know, spinning up on a new team. So that's, that's a fun, that's a fun moment in time. [28:01]
-
-Team transitions and gathering context in a new spot. [28:20]
-
-## [Nuxt acquired](https://x.com/nuxtlabs/status/1942575789645640071)
-
-**Mark:** And then overall, and not, not react, but adjacent. So next is the view ecosystem equivalent to next Js. And Versel had already picked up, you know, rich Harris who builds Svel, possibly one or two other non-reactive framework authors as well. And VL actually just acquired whatever group or company has been behind N and is hiring all of the developers, including Daniel Grow, who I think is the, the lead. [28:23]
-
-Developer maintainer for N So you know, Versal is not just about react like they, they are sort of putting their money where their mouth is and trying to back many different tools that, you know, build apps and of course can be run on versal. That's [28:55]
-
-**Carl:** got me curious about what kind of like corporate structure is behind Nuxt. [29:11]
-
-'cause like, you know, if it's individual developers then like. You can't acquire that, you just hire them. [29:16]
-
-**Mark:** I think next Labs may be an actual company, but I don't know how much of a like profit seeking company it is versus some kind of little holding thing. [29:21]
-
-**Carl:** Right. I'm now, I'm on the next website. I see next UI Pro, A hub for managing apps. [29:29]
-
-So I guess like deployment and then like a visual editor. And I see some reference to courses and stuff too, so like, yeah, that sounds like a business. That sounds like they're selling products. Kind of a mishmash of various different open source monetization techniques there. So. Cool. Nice. That's good to know. [29:36]
-
-I appreciate that. Love someone who's trying to take a project and turn it into a business Relat. Another smaller update. [29:50]
-
-## [Netlify Staff Eng Philippe Serhal replies to the Vercel Deployment Adapters RFC from April](https://github.com/vercel/next.js/discussions/77740#discussioncomment-13893373)
-
-**Carl:** This is like barely an update, but I've been tracking A an RFC, actually an RFC that Lee Robb started back in April on deployment adapters for next from Versal, basically making it. [29:58]
-
-More robust and reliable, I guess, to deploy next projects to infrastructure that isn't hosted on Versal. So the, a staff engineer from Netlify gave a response that's pretty lengthy, pretty serious, you know, it's got like, you list six gaps and 10 questions and four suggestions, mostly minor suggestions. [30:13]
-
-It's just cool to see that moving along slowly and I question the momentum now that Lee Robb is no longer there. It's just really hard to hand off major projects like that, major initiatives like that. But yeah, that's cool. Neat. Love to see it. [30:32]
-
-**Mark:** Okay. Somewhat smaller item, but definitely worth calling out. [30:45]
-
-## [Ryan Carniato’s “react and signals”](https://www.youtube.com/watch?v=VgGl9i-OBBI)
-
-**Mark:** So Ryan Carniato, the author of Solid, is, you know, pretty much the world's foremost expert on signals as a state management mechanism. And there was a lot of back and forth and chatter, and I think we even referred to some of it in our, in our last talk about like Ryan for and Michael Jackson from Remix were kind of questioning like, why does Signals exist? [30:48]
-
-Why do you know? Why do these different frameworks look sort of the same? And I think somewhat inspired by some of those questions and discussion. Ryan put together a 10 minute video on React and Signals what every React developer should know about signals. And Ryan like me is very big on history and context and explaining how we got from past tools and decisions to current tools and decisions. [31:09]
-
-He goes into some, some of the history of signals, you know, they originated with early JavaScript frameworks like Knockout, but the concepts and implementation of signals have evolved significantly in the last 15 years ago. And so he talks about some of the actual technical advantages of signals. And then he also does some, some myth busting. [31:36]
-
-You know, he pushes back and says they're not magic. They do scale. A lot of other frameworks like Angular and View rely on signals to make them faster. And he also talks about comparisons between like, what's the difference between three ACT compiler and signals or reacts virtual dumb in signals. And I think what a lot of that sums down to is that in react. [31:56]
-
-The component is the smallest unit of update granularity, like you set state, at least one component will re-render the whole component renders, and then maybe only a few bit bits of it need to be applied, but you had to run the whole component to see what needed to change. Whereas with signals, it's this one value changed and it's more directly attached to the output. [32:19]
-
-And so only the bits of the output that actually relied on that need to be calculated. And it's not an earth shaking discussion, but given that there's been a lot of hype and discussion and arguing back and forth, it's a good overview. Looking at some of like. Some of the pros, cons, concepts, and myths around signals. [32:42]
-
-**Carl:** Yeah, I missed that. I need to give that a watch because I hold a number of myths and misconceptions about signals, and I would like to understand them better. Yeah. [33:01]
-
-## [React Native Unistyles 3.0 Released](https://www.reactnativecrossroads.com/posts/introducing-unistyles-3)
-
-**Mo:** Nice. Next up, we have another release. So we've been talking about this for a few months. On and off because it's been sort of an RC mode, but React Native Uni Styles 3.0 has finally been released. [33:09]
-
-Now there's a few points to sort of hit here. Uni Styles came out as sort of like a very performant, lightweight styling option for React Native because there's a lot of styling libraries that are quite complex and have a lot of. Stuff included within it. But the challenge with a lot of those is that it also comes with a little bit of a performance hit because you've got a lot more being bundled into your application. [33:21]
-
-Uni styles is, is sort of since then being this sort of lightweight JavaScript only implementation has has dug into this sort of performance space a bit more. And this newest release is really digging into the new architecture with with Fabric, which is the new render and it uses native code and c plus plus. [33:45]
-
-To basically bypass the JavaScript layer when possible and keeps us track of the styling dependencies in c plus plus, and we'll only update affected styles and components on the native layer as much as possible. Again, this is like some things are possible on the native layer. Some things aren't. In terms of styling and, and the visuals of it, but as much as it can possibly do, it does that in the native layer and avoids re-render. [34:03]
-
-The maintainer kind likens this to CSS on the web in that it's not handled by JavaScript, but it's a different layer that that handles it. On top of that, added a bunch of extra functionality through a babble plug plugin to handle things like theming, break points, orientation, font scale, and maybe even right to left styling if you need that for your app. [34:29]
-
-And so the by and large, the biggest thing here is that there is a performance boost and they've done some measurements to, to show how much of a performance boost you can get because of these safe three renders that would've previously been happening because of styling changes. Other noteworthy things to mention are that there's some new features around sort of variance or scoped themes and so on and so forth. [34:48]
-
-You can go read through the blog post in more details to understand what are the sort of more granular new features that exist. But also given that this is sort of a universal library that works on web and native, there is a new web functionality as well. Some web only styles, some pseudo classes that they've introduced and some support for class names that would be targeting the web. [35:10]
-
-So there's some stuff around web support as well, which is quite interesting. But yeah, that's Uni Cells 3.0. Give it a give it, give it a quick look. Cool. Love that. [35:30]
-
-## [React Router and RSCs: The Path Forward](https://remix.run/blog/react-router-and-react-server-components)
-
-**Mark:** Finally, we have a couple different, uh, react server component updates. The React Router team has been iterating for a while on their work in progress server component implementation, and they've put together a blog post describing a path forward, so they go through some details talking about the, and ways you would handle things like streaming UI or in lighting data in existing React router framework mode versus how you might handle it with their server component implementation. [35:39]
-
-And so there the summary is that. apparently they're going to revamp the framework mode to be built on top of their server component support. [36:10]
-
-They are still labeling the server component support as unstable, but they do want people to try it out and give it a shot. So looking at some of these examples, it looks pretty significantly different usage wise than say like the next app router. It maybe looks even a little more similar to how Parcel had almost like a pick and choose your own server component usage approach. [36:19]
-
-So it is very cool to see additional frameworks providing support for server components. As well as that we're starting to finally see some variation in how they might get used and not just. The way next does it is the only way to do it. [36:42]
-
-## [Parcel writeup for Server Components](https://devongovett.me/blog/parcel-rsc.html)
-
-**Mark:** Along with that, Devin Govett from parcel put together a pretty good article where he was talking about how parcel bundles, server components, and he goes into some background detail about like, you know, what is a bundle even do in the first place? How does it. You know, follow the, the module graph. How does it handle dynamic loading? How do the pieces fit together? And then talks about, okay, and since React server components is really a bundler driven feature, here's how server components actually rely and make use of some of those bundler aspects. [36:57]
-
-## [WIP Vite RSC plugin support](https://github.com/vitejs/vite-plugin-react/issues/531)
-
-**Mark:** And along with that, I think we've previously mentioned that there's been an in progress. Attempt to build RSC support directly into Vite's React plugin. And there's one person who appears to be steadily cranking away on trying to make that support possible. And I'm seeing a number of the to-do list items in the roadmap being checked off. [37:26]
-
-So I don't know how far along that is. But it seems like a pretty serious effort to make that happen. So the server component ecosystem is slowly filling out. [37:50]
-
-**Carl:** Yeah. Interesting. I see one of the to-do list items in that is moving waku to VJS plugin, RSC. That's interesting. 'cause I, I had understood, I mean, Waku was like. [38:02]
-
-A proof of concept implementation of like how to do a framework on RSC. So it's interesting to see that move from like custom one-off implementation to relying on a, you know, kind of delegating RSC support back into, back into Ved. Love to see that. That's cool.
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Okay, moving on to the lightning round. [38:32]
-
-## Corbin’s [“History of React Through Code”](https://playfulprogramming.com/posts/react-history-through-code) deep dive
-
-**Mark:** Lightning round. Corbin Crutchley, author of the Framework Field Guide ebook, put together a very lengthy deep dive, which I highly approve of, called the History of React through Code, where he goes back and looks at a whole bunch of different react features that were added over time and kind of argues that you know what these, the, these actually have sort of a. [38:35]
-
-Intellectual cohesiveness a like a design cohesiveness to them and that they, they all, it makes sense when you look at the sequence of, of features and how they were added. [38:56]
-
-## [TkDodo’s thoughts on when `useCallback` is useless](https://tkdodo.eu/blog/the-useless-use-callback)
-
-**Mark:** Meanwhile, TK Dodo, Dominic Dorf, Meister maintainer of React query, just put up a post today where he has some thoughts on when use callback is actually useless. [39:06]
-
-And I think his argument is actually, it's useless in a, in a lot more cases and you probably don't actually need it all that often. [39:18]
-
-## [`eslint-config-prettier` compromised](https://safedep.io/eslint-config-prettier-major-npm-supply-chain-hack/) as part of an [NPM supply chain attack](https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise)
-
-**Carl:** Cool. There was a NPM supply chain attack that was pretty interesting. I believe. The issue was that a couple of relatively high profile maintainers got phished, and yes, there's a phishing campaign on a typo, squatted, URL, which is NPN js.com. [39:26]
-
-So it's a couple of major. Maintainers got successfully phished through that, which then, uh, stole their NPM credentials and published malicious versions of packages. Yeah, so, uh, malicious releases included lin config, prettier. That's big Lin plugin, prettier. Think kit packager, core and nappy post install. [39:45]
-
-So the, like, most of those not so big. I, I haven't really heard of, heard about 'em, but yeah. Esly config, prettier, that's big. And they got version, they got major versions. 8, 9, 10. Eight, nine, and 10. Okay, so make sure you're not using version 10.1, 9.1 0.1. Anyway, if you're using those, check it. If you're using ES link config, prettier or ES link plugin prettier. [40:06]
-
-Make sure it's not a vulnerable version. Check your lock files. Yeah, that's not great. [40:29]
-
-**Mark:** I know one of the other redix maintainers got the phishing email and avoided it. It's definitely semi widespread campaign. [40:34]
-
-**Carl:** Wild. They must have hit so many people to get a couple of major vulnerabilities in. Cool. [40:41]
-
-## [Expo Router demo by Evan Bacon AI \+ RSCs \+ Expo Router](https://github.com/EvanBacon/app-that-builds-apps)
-
-**Mo:** So next up, very quick one. [40:48]
-
-You might've remembered the old expo router demo from last year's react conf, where they showed RSCs in the world of expo router for building an AI app. Something very similar to that is now an open source project that you can clone and play around with. So Evan Bacon has released a demo of an AI app that can generate. [40:50]
-
-With AI native components and stream them in with RSCs. It's pretty cool. So clone the repo, play around with it. It's an interesting little demo. [41:08]
-
-## Some tech details on [how Meta serves React pages](https://www.reddit.com/r/reactjs/comments/1ltbw2e/how_does_facebook_serve_react_pages/)
-
-**Mark:** There was a Reddit thread that was asking how does Facebook slash meta actually build and serve their React applications? And some former meta engineers responded with a few technical details talking about how they do a bunch of dynamic bundling, and they also use, I believe Hermes or static Hermes on the back end to pre-build some of the server rendering pieces. [41:16]
-
-So, you know, a little peek behind the curtain. [41:38]
-
-## [Nitro Image library for React Native](https://github.com/mrousavy/react-native-nitro-image)
-
-**Mo:** Cool. And we talked a little bit about Nitro modules over the months, the past few months, there is a new library that the Margie folks folks have been working on called React Native Nitro Image. And so this is built on top of Nitro modules. I was actually talking with someone this morning about some of the challenges with images on the native layer when it comes to loading them in React Native. [41:40]
-
-So this is very much welcome as a change to hopefully improve performance across the board for React native. [42:02]
-
-## [A very hacky way to test RSC components](https://www.nico.fyi/blog/how-to-test-react-server-component)
-
-**Mark:** One of the weaknesses of React Server components has been that there hasn't been a good testing story for them yet, or at least not one that I've heard of. Someone put up an article with a way to test them. [42:08]
-
-However, it's incredibly hacky and relies on overriding some of reacts internals, so it's probably not a good way, but it is a way to try to test them if you like. [42:20]
-
-## [A good technical dive into improving INP in a Next app](https://medium.com/preply-engineering/how-preply-improved-inp-on-a-next-js-application-without-react-server-components-and-app-router-491713149875)
-
-**Mark:** And then there was a pretty good article that gave, it went into a bit of a technical dive and deep dive on how a company improved the interaction to Next Paint Web Vital Metric in their app, and gave a bunch of very practical examples of problems they found in their app and ways that they, they addressed those. [42:31]
-
-## [Extra CSS Properties in React Native](https://github.com/facebook/react-native/pull/52284)
-
-**Mo:** Cool. Next up, there are some new styling properties that are being proposed to be added to React Native. So this is being done by Nishan Bede, who has been doing a lot of work in trying to bring some CSS styling into React Native and better support. This time there's a pr up that adds support for background size, position, and reply and, and repeat. [42:51]
-
-So this will be quite interesting to see when and if it gets merged in. [43:13]
-
-## [Chrome 137 adds `if` support in CSS](https://developer.chrome.com/blog/new-in-chrome-137)
-
-**Carl:** Yeah. Speaking of, I don't know, new CSS things. Chrome 1 37 added an if to CSS. There's a conditional flow, or I don't know, there's a condition now in CCSS. I have not seen that before. So I guess it's a way of, you know, you can consult the various variables you've set up and evaluate what the associated styles are or associated values and conditionally. [43:16]
-
-Do one thing or another. Yeah. [43:43]
-
-**Mark:** Yeah. It, it, it looks like it's a built-in function. You pass in a very, like a, an existing variable or property value as the first, and then it's, if it matches, then it's a, if it doesn't match, then it's b like, almost like an Excel function, like kind of a thing. [43:44]
-
-**Mo:** Reminded me exactly of that. [44:01]
-
-Are we finally at the stage where CSS is turning complete? [44:03]
-
-**Carl:** I remember seeing a demo of turning complete CSS like 15 years ago if you include user input. So yeah, it was like a grid of check boxes and uh, I think the, the human had to interact with stuff, but it was turning complete, if you included that. [44:06]
-
-**Mo:** So I think we just need loops and it'll technically be turn complete. [44:20]
-
-**Carl:** Yeah. Wild. Anyway, that, that seems interesting and new. This document that I'm reading is using something else that I don't recognize. The, the example they have here is if style, you know, dash color, white, so I guess that's using a different function to read the styles of the current element. [44:23]
-
-Something. That's what it looks like to me, but that's also new to me. So like between conditionals and being able to read the current state of element are, uh, interesting. [44:41]
-
-## [React Devtools for Firefox may not get updated due to review restrictions](https://bsky.app/profile/ricky.fm/post/3ltkxpo5ewk2i)
-
-**Mark:** There was a discussion thread on Blue Sky where someone, where one of the React team members said that. They were, they had tried to submit an update to React Dev Tools extension in Mozilla's, Firefox, add-on store, and it was getting blocked because Mozilla has some very specific and strict rules around how code gets built into extensions, and suddenly, all of a sudden, someone on the Mozilla side is complaining that the way React builds their extension is hypothetically a security concern. [44:50]
-
-There were also some numbers thrown around about how many Firefox users of the dev tools extension actually exist. And it was only like, maybe like 120,000 or something. Whereas I think the, the last time I looked at the, the dev tools extension for Chrome, it's like 4 million. So the React team was actually saying, you know, maybe we, we won't even bother building the extension for Firefox anymore. [45:23]
-
-It's, it's not worth the effort. You can always add the, you know, the unbundled version yourself. I think they maybe managed to get the attention of someone from Mozilla to try to, you know, bypass the stuck review process. But clearly that's a pain point. And [45:47]
-
-**Carl:** I gotta say, just side load this extension that can read all of your input on every site is the dangerous thing to do at scale. [46:03]
-
-Like if you just tell millions of people side load this application, there's gonna be dozens of malicious actors who spin up their own. Side load version of the extension that does malicious things. So Oof. Don't like that. So yeah, hopefully they can fix this, you know, correctly. [46:12]
-
-## [Both `oxlint` and `biome` are investigating typed lint rule support](https://www.solberg.is/fast-type-aware-linting) ([Biome v2](https://biomejs.dev/blog/biome-v2/), [tsgolint](https://github.com/oxc-project/tsgolint))
-
-**Mark:** And so another item, so we've previously mentioned that, you know, biomes working on version two and they had included some typed some support for typed aware rules that normally would've required integration with the TypeScript DS went package and the TypeScript compiler ENT came out with 1.0. [46:29]
-
-There, there's a bit of additional information and updates on both of those. So there was, there was an article. Talking and comparing the different approaches that Biome and Oxalate are using to implement typed support. And then we got a couple links to some of the discussions where those linters are doing it. [46:49]
-
-Biome appears to be building in like their own, almost like a miniature version of. Typed processing, whereas Oxalate has taken the new TypeScript written in Go compiler and sort of hacked up an interop layer. Then they're relying on the new TypeScript go compiler to do the type checking work. And that approach appears to be working it. [47:09]
-
-They said they've implemented a number of the different type to wear rules, and it seems highly performant, so you know that in addition to being able to build our apps faster, we may be able to lint our apps faster as well. [47:35]
-
-## [Remix v3 dev branch containing support packages](https://github.com/remix-run/remix/tree/v3)
-
-**Mark:** Cool. We've been going on for a while about how the remix team has been dropping very, very vague hints about what remix version three is going to be, to the point that it's really getting very, very annoying for those of us reading their, their Twitter accounts, and I still haven't seen any actual code of what the framework itself. [47:49]
-
-Will be like, however, there they did put up a development branch that includes some of the support packages that they're going to be using as part of the implementation of version three. So like it's not the full framework, but there's a lot of individual sub packages for various like tar parsing and other sorts of things that they want to be usable standalone, but they're building them for the purpose of usage in version three. [48:07]
-
-So it's not a full look at what, what they're doing, but it's a little bit of a peek behind the curtain. [48:35]
-
-## [React Native Wallet](https://blog.swmansion.com/introducing-react-native-wallet-90c1ee103d3e)
-
-**Mo:** Cool. Next up, we've got another sort of honorable mention of releases that happened over the last month, and this is React native wallets. So there's a lot of sort of. Wallet style libraries that have come and go in the React native ecosystem, not one that's really been maintained extensively. [48:40]
-
-And so the folks at Expensify and Software Mansion have partnered together to create the React Native Wallet library. And so the idea is that. It's firstly a cross-platform way to add payment and credit cards to Apple and Google Wallet. Now, there's libraries that like handle passes and tickets. They're quite limited. [48:58]
-
-I've used a few of them in the past, but this is more specifically on payment cards. And so the idea is that you can maybe. Hopefully through this process avoid needing to integrate a whole bunch of different SDKs for different cards and different and different platforms, and you can kind of just use this library to handle a lot of that functionality for you. [49:19]
-
-Sounds quite complex because, you know, payments are usually quite difficult to get working, so I'm curious to see how well this works in practice, but I've not had the use case yet. Typically payments and, and cards and stuff like has so many different people that you need to communicate with. The card issuer, apple, and a whole bunch of other people in the process. [49:37]
-
-So curious to see how extensible and generic this is gonna be, but very cool. [49:56]
-
-**Carl:** Yeah. Interesting. Also, it's the first time I've seen a wallet library that was not Web3 in a long time, so additional wallets, right. [49:59]
-
-## [Deno v Oracle update](https://deno.com/blog/deno-v-oracle4)
-
-**Carl:** This is a very small update, but we've. I talked a bit in the past about Deno versus Oracle. [50:07]
-
-Deno has been suing Oracle for use of the JavaScript trademark because did you even know that Oracle owned it? Oracle owns the JavaScript word, the word JavaScript. So basically the only content update here is that in the past, at some point previously in the litigation, Deno filed a claim of fraud because. [50:13]
-
-Oracle filed supporting evidence of prior use of the trademarked term JavaScript by referencing the node JS project. Generally as something that they did and you know, who did not start or maintain node js is Oracle. So like basically they filed a just wildly inaccurate claim supporting that. They do in fact use JavaScripts. [50:36]
-
-So that unfortunately was dismissed. The fraud claim was dismissed, which seems strange to me because like if you say I made this and you didn't, seems wrong. But anyway, that's really the only major update here, but hopefully we will hear more. Hopefully this will go in a good direction. I am not super confident of that, but August and September have some major court dates, so maybe there will be more updates later this year. [51:00]
-
-## [“Content independence day” from Cloudflare](https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/) (they’re blocking AI crawlers)
-
-**Carl:** There's also an update from CloudFlare on AI crawlers. They have declared content independence stay. No AI crawl without compensation, which seems lovely, Cloudflare's in a pretty good position to meaningfully control traffic in that kind of a way. Lots of real services are using CloudFlare for that purpose. [51:23]
-
-So, yeah, seems good. I've heard a couple of anecdotes of people with smaller services getting absolutely slammed with traffic from, you know, poorly coded AI supporting crawlers, trying to gather information and doing it just greedily or excessively. So, seems good. Seems nice. [51:45]
-
-## [Some updated Static Hermes perf numbers](https://x.com/tmikov/status/1945348222110859500) release available “soon”, being tested internally at Meta
-
-**Mark:** All right, and last couple items. [52:04]
-
-The folks at Meta have been working way on static Hermes, which is an attempt to take the existing Hermes JavaScript engine for React Native and be able to pre-compiled entire JavaScript apps to a native binary. And they put up a tweet with some. Performance numbers comparing static hermes's output versus a couple of other JavaScript runtimes. [52:06]
-
-The numbers seem higher, which seems like a good thing. And they also mentioned that they think they will have a release available, quote unquote soon, and that they are using it internally at meta. So, you know, that seems like another potentially useful tool to have in the ecosystem. [52:29]
-
-## [State of HTML Survey is open](https://survey.devographics.com/en-US/survey/state-of-html/2025)
-
-**Mark:** Finally, the folks behind the various state of surveys have put out the state of HTML survey. [52:47]
-
-So that's open. You can fill it out, test out your knowledge, answer some questions about what various new H TM L features you may or may not be familiar with and what you think about them. [52:54]
-
-**Mo:** I did not know them. State of HTML. Very interesting. [53:04]
-
-**Carl:** Yeah, I think they started like two or three years ago. It's relatively newer. [53:07]
-
-I mean, the state of. X has really exploded in the last couple of years. It's great. I love that. But I do worry about like survey fatigue and a lot of these are trying to solicit answers from the same population of developers. So I don't know, maybe, maybe. We'll, we'll see how that plays out. Cool. [53:10]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Alright, before we close out, let's, uh, talk about some coming [53:26]
-
-## [Big Sky Dev Con](https://bigskydevcon.com/) Aug 2 Bozeman, MT, USA
-
-**Carl:** like four days, there's Big Sky devcon in Bozeman, Montana. [53:29]
-
-## [Kansas City Developer Conference](https://www.kcdc.info/) Aug 13-14 Kansas City, KS, USA
-
-**Carl:** Seems good. Kansas City Developer Conference, which is not KCD. It's KCDC, but it's not Ken C dos that's happening August 13th and 14th in Kansas City, Kansas. [53:36]
-
-## [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025. Wrocław, Poland
-
-**Carl:** We also have React Universe September 2nd through fourth in Wroclaw [53:47]
-
-**Mo:** I've been there enough times where I've been taught the pronunciation because butchered it several times, but it's, [53:52]
-
-## [WaysConf](https://www.waysconf.com/) Sept 16-17
-
-**Carl:** uh, we've also got Ways Conf coming up September 16th and 17th in Krakow. [53:57]
-
-I'm also probably butchering, but also in Poland. [54:04]
-
-## [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
-
-**Carl:** Cascadia js is September 18th, 19th in Seattle, Washington. [54:06]
-
-## [Squiggle Conf](https://squiggleconf.com/) Sept 17-18 Boston, MA, USA
-
-**Carl:** And we've got Squi Squiggle conf in Boston, September 17th and 18th, which should be great and I should be there, I believe. [54:10]
-
-## [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l)
-
-**Carl:** And of course, react Conf October 7th and 8th in Las Vegas, Nevada. [54:17]
-
-## [Remix Jam](https://remix.run/jam/2025) Oct 10 Toronto, Canada
-
-**Carl:** I also just heard about Remix Jam, happening October 10th in Toronto, Canada. Yeah, that's new. I don't know that they've done a conference like that before, so that's interesting. [54:22]
-
-## Outro
-
-**Carl:** But yeah, that's all we got for you this month. Thanks so much for joining us. We will be back probably on the last Wednesday of August, but we've been. Jumping around the last few months, but we'll be back in your podcast feed just as soon as we can. [54:33]
-
-**Mark:** Always fun. Way too much to keep track of, but hopefully this has been useful. Lovely to be with you all and see you all next month. [54:46]
-
-**Carl:** Great. We gather sources from this week in React Bites, dev Next JS Weekly, the React JS subreddit, and here in React to Flux from the E, the Tech Reads and News Channel. If you see something that you think we should talk about, definitely Sheridan. [54:53]
-
-Channel or send it to me at hello@reactiflux.com. If this is a show that you get value from and want to support, one of the best ways you can do so is by submitting a review on whatever platform you listen to it on, or tell your friends and coworkers about it. [55:07]
-
-Thanks so much for listening. Talk to you later. [55:19]
diff --git a/src/transcripts/tmir-2025-08.md b/src/transcripts/tmir-2025-08.md
deleted file mode 100644
index 15b5e9f..0000000
--- a/src/transcripts/tmir-2025-08.md
+++ /dev/null
@@ -1,498 +0,0 @@
----
-title: "TMiR 2025-08: Nx compromised; no more throwing promises; Remix-ing new component models"
-date: 2025-08-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-
-
-- [[00:47](#new-releases)] New releases
- - [[00:51](#ts-59)] [TS 5.9](https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/)
- - [[02:50](#ts-60-may-enable-strict-by-default-and-change-other-defaults)] [TS 6.0 may enable \\\`strict\\\` by default](https://bsky.app/profile/robpalmer.bsky.social/post/3lxar2cp5rs2p) and [change other defaults](https://github.com/microsoft/TypeScript/issues?q=milestone%3A%22TypeScript%206.0.0%22)
- - [[03:46](#react-native-081)] [React Native 0.81](https://reactnative.dev/blog/2025/08/12/react-native-0.81)
- - [[05:40](#next-155)] [Next 15.5](https://nextjs.org/blog/next-15-5)
- - [[07:10](#preact-11-beta)] [Preact 11 beta](https://github.com/preactjs/preact/releases/tag/11.0.0-beta.0)
- - [[07:39](#hydration-20)] [Hydration 2.0](https://github.com/preactjs/preact/issues/4442)
- - [[07:52](#bun-1221)] [Bun 1.2.21](https://bun.com/blog/release-notes/bun-v1.2.21)
- - [[08:54](#native-yaml-support-definitely-not-going-to-cause-any-problems)] Native YAML support. Definitely not going to [cause any problems](https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell)
- - [[10:21](#tanstack-db-beta)] [Tanstack DB beta](https://tanstack.com/blog/tanstack-db-0.1-the-embedded-client-database-for-tanstack-query)
- - [[11:30](#ghost-v6)] [Ghost v6](https://ghost.org/changelog/6/)
-- [[13:09](#main-content)] Main Content
- - [[13:13](#react-api-changes-updates)] React API changes / updates
- - [[13:24](#react-deprecating-the-throw-a-promise-suspense-trigger-method)] [React deprecating the “throw a promise” Suspense trigger method](https://github.com/facebook/react/pull/34032)
- - [[16:20](#discussion-between-dan-dominik-and-ricky-about-how-to-support-multiple-react-versions-if-at-all)] Discussion between Dan, Dominik, and Ricky about [how to support multiple React versions (if at all)](https://bsky.app/profile/tkdodo.eu/post/3lv4rhr4mrs2i)
- - [[17:43](#github-discussion-with-joe-about-why-no-context-selectors-api-or-signals-research-into-data-modeling-and-why-concurrent-stores-are-the-current-focus-area)] Github discussion with Joe about [why no context selectors API or signals, research into data modeling, and why “concurrent stores” are the current focus area](https://github.com/reactjs/rfcs/pull/119#issuecomment-3214971470)
- - [[21:25](#pr-for-concurrent-stores-skeleton)] [PR for “concurrent stores” skeleton](https://github.com/facebook/react/pull/33215)
- - [[23:13](#third-party-react-concurrent-store-ponyfill-package)] [Third-party \\\`react-concurrent-store\\\` ponyfill package](https://github.com/thejustinwalsh/react-concurrent-store)
- - [[26:39](#lee-robinsonss-reflections-on-the-react-community-wrap-up-post)] Lee Robinsons’s [“Reflections on the React Community”](https://leerob.com/reflections) wrap-up post
- - [[31:18](#remix-doing-its-own-component-model)] [Remix doing its own component model??](https://x.com/mjackson/status/1954975322157486408)
- - [[36:46](#remix-3-and-the-end-of-react-centric-architectures)] [Remix 3 and the End of React-Centric Architectures](https://thenewstack.io/remix-3-and-the-end-of-react-centric-architectures/)
- - [[37:21](#popular-nx-packages-compromised-on-npm)] [Popular nx packages compromised on npm](https://www.aikido.dev/blog/popular-nx-packages-compromised-on-npm)
- - [[39:43](#last-month-eslint-plugin-prettier-maintainers-were-targeted-this-is-a-much-broader-attack)] Last month [eslint-plugin-prettier maintainers were targeted](https://snyk.io/blog/maintainers-of-eslint-prettier-plugin-attacked-via-npm-supply-chain-malware/), this is a much broader attack
-- [[41:31](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[41:33](#react-strict-dom-vs-react-native-for-web-in-2025)] [React Strict DOM vs React Native for Web in 2025](https://shift.infinite.red/react-strict-dom-vs-react-native-for-web-in-2025-bb91582ef261)
- - [[43:34](#faster-jsonstringify)] [Faster JSON.stringify()](https://v8.dev/blog/json-stringify)
- - [[44:56](#node-2218-unflags-ts-type-stripping-support)] [Node 22.18 unflags TS type-stripping support](https://nodejs.org/en/blog/release/v22.18.0)
- - [[46:23](#waku-switches-to-vites-wip-rsc-support)] [Waku switches to Vite’s WIP RSC support](https://waku.gg/blog/migration-to-vite-plugin-rsc)
- - [[47:00](#rari-a-fast-react-framework-with-rsc-support-built-with-rust)] [Rari, a fast React framework with RSC support built with Rust](https://ryanskinner.com/posts/how-i-built-a-full-stack-react-framework-4x-faster-than-nextjs-with-4x-more-throughput)
- - [[47:52](#selecting-values-from-query-results-as-well-as-the-useless-usecallback)] [Selecting values from query results](https://tkdodo.eu/blog/react-query-selectors-supercharged), as well as [The Useless useCallback](https://tkdodo.eu/blog/the-useless-use-callback)
- - [[48:26](#ts-postmortem-effect-ts-experimental-ts-fork)] [TS\+ postmortem (Effect-TS experimental TS fork)](https://effect.website/blog/ts-plus-postmortem/)
- - [[50:48](#react-usetransition-update-ordering-details)] [React useTransition update ordering details](https://jordaneldredge.com/notes/react-rebasing/)
- - [[51:13](#a-clock-that-doesnt-snap-techniques-for-fixing-hydration-of-values-like-dates)] [“A Clock that Doesn’t Snap”](https://ethanniser.dev/blog/a-clock-that-doesnt-snap/), Techniques for fixing hydration of values like dates
- - [[51:36](#react-cache-its-about-consistency)] [React Cache: It’s about consistency](https://twofoldframework.com/blog/react-cache-its-about-consistency)
- - [[52:26](#self-hosting-next-at-scale)] [Self-hosting Next at scale](https://dlhck.com/thoughts/the-complete-guide-to-self-hosting-nextjs-at-scale)
- - [[53:26](#server-and-client-component-composition-in-practice)] [Server and Client Component Composition in Practice](https://aurorascharff.no/posts/server-client-component-composition-in-practice/)
-- [[54:04](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[54:06](#react-universe-conf-sept-2-4-2025-wrocaw-poland)] [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025\\. Wrocław, Poland
- - [[54:14](#waysconf-sept-16-17)] [WaysConf](https://www.waysconf.com/) Sept 16-17
- - [[54:21](#cascadiajs-sept-18-19-seattle-wa-usa)] [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [[54:26](#cascadiajs-sept-18-19-seattle-wa-usa)] [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
- - [[54:32](#react-alicante-oct-2-4)] [React Alicante](https://reactalicante.es/) Oct 2-4
- - [[54:51](#react-conf-is-back-oct-7-8-las-vegas-nv-usa)] [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
- - [[54:56](#remix-jam-oct-10-toronto-on-ca)] [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
-- [[55:10](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the August edition of this Month in React. As we recap what's going on with React, react native in the web we're coming to you live from Reactive Flux, the place for professional developers using React. I'm Carl. [00:00]
-
-I'm a staff product developer and freelance community leader here at Reactive Flux, where I do community programs like this event and write some code to help keep the community running. [00:13]
-
-**Mark:** Hi, I'm Mark. I maintain Redux. I try to find time to maintain Redux. Life is busy these days and my day job is working at Replay where we've built a time traveling debugger for JavaScript and are also attempting to get in on the AI app generating craze. [00:22]
-
-**Carl:** Mo is unfortunately out this month, he seems to have food poisoning or something similar. So he's gonna take a break and I'm gonna do my best on React Native news, which is only Okay. [00:37]
-
-## New releases
-
-**Carl:** But yeah, let's start off with some new releases. Mark, tell us about new TypeScript. [00:47]
-
-## [TS 5.9](https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/)
-
-**Mark:** The TypeScript release train keeps on rolling. They've just put out TypeScript 5.9. Few points of interest out of this one. They've updated some of the options for generating any new TypeScript project. They've simplified the initial TS config, JSON that gets generated. They also have support for the upcoming JavaScript import, defer syntax. This is a new thing. That is coming down the pipeline for JavaScript engines where you can use the defer keyword in an import statement and the JavaScript runtime will know that it needs to go read this file, but it won't try to actually load and execute that JavaScript right away. [00:51]
-
-Right now, when you do imports, everything's imported and executed synchronously. This can have a lot of effect on startup time, and so the import, defer keyword is meant to la effectively lazy load some pieces of the JS system without having to use the the separate import statement. So TypeScript now at least has support for that syntax, but in a sense it won't do anything until JavaScript engines fully support actually doing something with that. One thing that I personally am excited for is that TS 5.9 now has support for expandable hover previews. If you, if you ever work with TypeScript, you have big type definitions, you know that TypeScript often cuts down the amount of information it shows about a type in the hover preview or, you know, the types are deeply nested and you, you don't already know like what is inside this field. So ts 5.9 now has support for actually being able to drill down into hover previews. you do need to have an updated version of VS code to make use of that as well. But as someone who has spent too much time fiddling with those settings, I'm actually very excited about that one. [01:37]
-
-**Carl:** Yeah, that sounds great. [02:48]
-
-## [TS 6.0 may enable \\\`strict\\\` by default](https://bsky.app/profile/robpalmer.bsky.social/post/3lxar2cp5rs2p) and [change other defaults](https://github.com/microsoft/TypeScript/issues?q=milestone%3A%22TypeScript%206.0.0%22)
-
-**Mark:** And then along with that, there are a couple bits about the future of TypeScript. So right now we're on 5.9. The TypeScript team has said that the go port of the TypeScript compiler will become a TypeScript 7.0. They've put out some news and plans on the roadmap for TypeScript 6.0. There's an issue in some discussion about making the strict flag the default, or maybe not the entire strict flag, but maybe graduating some of the specific settings, like strict null checks to be turned on by default. As a maintainer, that makes me very, very happy. I'm tired of seeing people post issues against my library saying, your library doesn't work. Right. And the problem is they didn't have TypeScript in strict mode in the first place. So. still to be worked out, but it's good to see that they are trying to figure out the transition plan for all this. [02:50]
-
-**Carl:** Definitely super cool. [03:44]
-
-## [React Native 0.81](https://reactnative.dev/blog/2025/08/12/react-native-0.81)
-
-**Carl:** We've also got React native releasing version uh, O 81. Obviously I am not anywhere near as deeply versed in React native as Mo would be. So, uh, hopefully we'll have him around to catch us up again later on. But we've talked a little bit about what's coming on, what's in this release in previous months. [03:46]
-
-Nothing here struck me as super new. They're deprecating, the safe area view which they talked about as being originally an iOS specific. Component in order to support, you know, the safe area because of the notch. But now Android has notches too, and it doesn't work very well for that. So it's being deprecated and they're leaning on the, Safe Area Context. They recommend that you migrate to the React native safe Area context library for that. They are also defaulting to Android 16 now in React Native. They had an, a curious call out that seems strange to me. They say predictive back gesture is now enabled by default for apps targeting Android 16 and just , the phrase predictive back gesture. [04:07]
-
-Is, I don't know, it seems like a lot to me. I know gestures, you have to predict them and whatever, and I guess everything is now gestures, but I have my phone sent to use buttons still, so I don't know what they're talking about, but that sounds complicated. It also talks like, you know, if you have overridden your, the back behavior of your app, then you may need to migrate or change how your app works. [04:50]
-
-So man, if only you could reliably go back in Native apps isn't the web great. They also are introducing pre-compiled iOS builds, which they say cuts the compile time by up to You know, 10 x so like one 10th the compiled time. It used to be in projects where react native is a primary dependency. [05:11]
-
-And they've got better error rendering in the dev tools as well, which is great. it now shows the original message in Stack trace of uncut JavaScript errors. So how, how lovely to know where your errors come from, [05:29]
-
-## [Next 15.5](https://nextjs.org/blog/next-15-5)
-
-**Mark:** Next 15.5 came out. A couple things worth noting from this one. They now have turbo pack builds for production in beta. Turbo Pack had previously really only been used for local development, and so they've been cranking away on trying to get it to full compatibility for production builds. And it seems like that's getting close. They now have node support for middleware. They've got some TypeScript improvements, like actually having full typing for routes. So it'll catch things like mistyped link tags as well as trying to get rid of the old next lint command. [05:40]
-
-**Carl:** Yeah, the middleware support for no JS also seems like a pretty big step. You know, one of the main complaints, a large complaint about next is how difficult it is to run yourself not on Vercel. So supporting a more generic runtime for your middleware seems really great. [06:16]
-
-I haven't run into this with next specifically, but I have run into. Compatibility issues between edge runtimes and node JS code. it's such a constraint if you're trying to run on, edge runtime, which is, you know, okay, so next Vercel is they have their Edge Runtime, in title case. [06:33]
-
-But also, you know, CloudFlare workers are also a very similar kind of runtime that offer a similar set of constraints. And man, you just can't use a lot of the node ecosystem when you're in one of those constrained environments. So this, this should open up compatibility quite a lot it sounds like to me. [06:51]
-
-## [Preact 11 beta](https://github.com/preactjs/preact/releases/tag/11.0.0-beta.0)
-
-**Mark:** Meanwhile, the Preact library, the, the longstanding smaller replacement for React just put out a beta for version 11. Preact has always been dom slash web only, not native. And the calling cards have been that it's much smaller than full-blown react, but maintains most API compatibility up to a certain point. [07:10]
-
-I think they've stopped trying to, maintain compatibility for some of the newer React APIs in 18 and 19. [07:33]
-
-## [Hydration 2.0](https://github.com/preactjs/preact/issues/4442)
-
-**Mark:** A couple of the big points this one they finally dropped IE 11 support and they've improved hydration and a number of other small tweaks. So it's always good to see that them making progress as well. [07:39]
-
-## [Bun 1.2.21](https://bun.com/blog/release-notes/bun-v1.2.21)
-
-**Carl:** Every so often it's nice to check in on what BUN and Dino and everything are doing. BUN has a 1.2 point 21 release out. A couple things that caught my eye on it were the bun sql, you know, standard library tool now supports MySQL, MariaDB, SQL Light, and Postgres, all from like one dependency. [07:52]
-
-And that's pretty great. I don't know. Nice to have, nice to be able to swap those out. I wonder what the experience of actually trying to swap them out would be, because the different engines have slightly different constraints. I appreciate that. That's cool. I, I love, especially for like SQL light stuff, it just seems so simple as maybe overstating it, but it's really nice to be able to just spin up a database without installing dependencies. [08:12]
-
-So, uh, kudos to BUN for adding that. They've also added native YAML support which is great. You know, it's lovely to not for parsing confi common configuration file formats again, seems like something that should be in the standard library. However, I am generally aware of YAML as like a very challenging format to parse. [08:35]
-
-## Native YAML support. Definitely not going to [cause any problems](https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell)
-
-**Carl:** There's a, a blog post that lives in my brain about YAML from 2023 titled The YAML document from Hell Enumerates some of the complexities one of my favorites being sex decimal numbers. And so a, a, apparently a common older format quirk is that some, ranges of ports that you might try to map in, say a Docker file like Port 22, mapped to port 22 is not parsed as 22, colon 22. [08:54]
-
-It's parsed as a sexagesimal, IE base 60, number. So then instead of the string 22:22, you get 1,342. Which is not a valid port mapping. So like things like there are like 30 different ways to put Booleans to encode Boolean in a YAML file. And so like yes and no are one of the valid formats. And so if you're trying to do a list of countries using standard country codes, apparently Norway will be interpreted. [09:24]
-
-**Mark:** Is NO, [09:53]
-
-**Carl:** So like, just hearing about that, those kind of like foot guns that exist in the format and apparently like variations in parser behavior is an existing problem throughout the YAML ecosystem. So, great. I [09:56]
-
-**Mark:** let's add another parser. [10:09]
-
-**Carl:** Right what? Great. One more parser there. Wonderful. I can't wait to hear about what weird, terrible, hellish bugs emerge from this new parser. [10:09]
-
-Good luck to them. I hope it's good. [10:19]
-
-## [Tanstack DB beta](https://tanstack.com/blog/tanstack-db-0.1-the-embedded-client-database-for-tanstack-query)
-
-**Mark:** Next up the folks over in the Tan Stack Collective have just put out a beta of the new Tan Stack database library. it's a little interesting to describe. It's a layer that's supposed to sit on top of your tan stack query setup, and it kind of acts as like a local in client database and sync engine. [10:21]
-
-So you can still use 10 set query to do the fetching, but the database layer is supposed to provide a normalized view of the data, supposed to have very fast in client updates. I believe this has been worked on by Kyle Matthews, who you may know as the original creator of the Gatsby framework back in the day. He's been working on electric sql, which is itself a AYC engine layer, so he clearly now has some expertise over there. So, looks like a very potentially interesting tool for fast client side data management. [10:41]
-
-**Carl:** it seems like hand stack throwing their hat in the ring on like sync engines at a slightly different level of abstraction than like where React query sits. Further to the backend, further to here's your internal store being managed, not just request caching. [11:12]
-
-So that's cool. Yeah. Interesting. [11:28]
-
-## [Ghost v6](https://ghost.org/changelog/6/)
-
-**Carl:** A very small shout out, a little bit further away, but this is a tool that I evaluated for use in a professional setting on a React project. So I'm gonna shout out a new major version. Ghost version 6.0 has been released. Ghost is a, like CMS, an open I believe open source CMS. [11:30]
-
-And they generally seem nice. They seem great. I, you know, as contrasting things like Contentful or Ghost or Substack or Medium or what have [11:47]
-
-you, uh, Word, right? They sit in a good spot in the niche. They, so they're now, they're announcing as part of this version six that they have added distribution. [11:57]
-
-So now you can automatically publish your posts from Ghost across social platforms. So like they, they call out Blue Sky Flipboard Threads, MAs it on WordPress, interestingly and Ghost, they can, so, okay, so you can publish the ghost and it will be distributed elsewhere on, in Ghost, I don't know, I don't know what that means. [12:09]
-
-Or any other social web platform as well as like analytics. And they talk a lot about how much revenue they have passed along to publishers on their platform. So they show their earnings broken down into like. Hosting revenue and platform revenue, and it's like $38 million for their own company and like a hundred million dollars through, you know, distributed to people publishing on ghosts. [12:28]
-
-So like that, I don't know. That's great. They, they shout out 4 0 4 Media, which is a site that I'm familiar with and did not realize hosted on this platform. So, you know, love that. That's great. I love a, love a open source media platform that's doing good work right now. [12:56]
-
-## Main Content
-
-**Carl:** Cool. Uh, That's all the new releases we have for now, into the main content. [13:09]
-
-## React API changes / updates
-
-**Mark:** All right, so we have a roundup of a number of topics related to changes in reacts APIs. So get your technical hats on for these. [13:13]
-
-## [React deprecating the “throw a promise” Suspense trigger method](https://github.com/facebook/react/pull/34032)
-
-**Mark:** The first one is that Sebastian Markbåge put up a PR to officially deprecate the throw a promise technique for triggering suspense. So let's wind backwards and unpack a little bit, like what is that in the first place and why does it even exist? So. Currently up through React 17 and 18. The suspense component came out in I think like 16.6, but originally it was only used with React lazy for importing and deferring loading of components. There wasn't an official like react for data fetching method, but there was the unofficial experimental. [13:24]
-
-This is never documented, but the code exists and works. If you wanted to trigger suspense in terms of like, you know, managing some data fetching yourself, the super secret technique was that you would throw a promise from within your component. And the reason the React team picked this was because we. It like, to a certain extent, it enabled them to reuse the existing infrastructure from catching errors within a component where, you know, it kind of conceptually, you have a catch block around the actual component call and then react knows, here's where I'm rendering in the tree, and then it can sort of bubble up the behavior to some ancestor component that was supposed to catch it for errors. [14:07]
-
-It's a, you know, actual error handling with the component did catch. And for suspense it's, you know, where's the nearest suspense component in the tree? And so this was never officially documented, but, you know, library maintainers and people investigating the code saw that it was there. And so it's been known and used by the community and libraries for years. [14:57]
-
-And so pretty much anything, any library that had suspense support built in was internally just throwing a promise. So with React 19, we now have the use hook built in, and that is the officially documented publicly, you know, described way to actually trigger suspense. If you look at the use hook, I think internally it does actually still end up throwing a promise last time I checked, but it's now an implementation detail. And it does some other things in there as well. So if you read a pr, they are officially going to get rid of the throwing a suspense, throwing a promise technique for a number of reasons. Some of it has to do with internal implementation details and optimizations. Some of it has to do with, well, we can have the lit rules look for uses of the use hook and flag any, any time you try to put that in a place that it's not legal to do so. [15:19]
-
-## Discussion between Dan, Dominik, and Ricky about [how to support multiple React versions (if at all)](https://bsky.app/profile/tkdodo.eu/post/3lv4rhr4mrs2i)
-
-**Mark:** This did then lead to some discussion on Blue Sky amongst a couple of the maintainers like Dominic Dorf, Meister of React Query asking, well, if this comes out in like, you know, 19 3, 19 4, something like that, how are we supposed to manage having our own libraries work with both like React 18 and 19.1 and 19.4 at the same time when there's now three different variations of what is a legal way to trigger suspense. there was a bit of a back and forth on that. One partial answer was, your library can check if the use hook is exported from React and prefer that if it exists and fall back the promise if it doesn't. One of the React team members, Ricky said, well, you probably should just focus on supporting the latest version of React. I'll admit, I feel like that kind of hand waves the problem a little bit. [16:20]
-
-**Carl:** How great if everyone could just rely on that. Yeah. [17:17]
-
-**Mark:** yeah, because I mean that, that probably also means putting out new major versions of our own libraries, which is then an effort and also has a ripple effect on the ecosystem. I mean, I don't really want to publish a new version, a new major version of, you know, some of the Redux libraries just to support that. But it's good to see that there, that we are actually making headway on that now that 19 is out. [17:20]
-
-## Github discussion with Joe about [why no context selectors API or signals, research into data modeling, and why “concurrent stores” are the current focus area](https://github.com/reactjs/rfcs/pull/119#issuecomment-3214971470)
-
-**Mark:** Another interesting point. So buried in a blue sky thread Joseph from the React team said that. They're planning to not actually implement an idea that they had discussed a few months ago where they'd said, we are going. [17:43]
-
-They were thinking about allowing you to call use or use context inside of use memo as a way to optimize context. So backing up technical detail on this one, the weakness of context has always been that when you update the context value, every component that reads it will re-render. And then at that point, all the children inside of that will re-render as well, just because react defaults to when any component renders. [18:01]
-
-It just keeps on going all the way down the tree unless you optimize it to stop. And so the problem is if you have, you know, fairly large objects with multiple fields as your context value, some of your components probably only care about one or two of those fields. But as soon as you update that object at all, every component that read the context will re-render. And so it ends up leading to, you know, potentially lots of components rendering slower render performance, et cetera. So years ago, like, I don't know, 20 18, 20 19 there was a user land RFC suggestion that react should add context selectors as an API. So, you know, kind of similar to like a, a react redux use selector, but optimize for context instead. [18:28]
-
-And so that proposal has been around for a long time. Andrew Clark even briefly tried implementing a proof of concept of a context selector's API in like 2020, and then it didn't go anywhere. So a few months ago, the React team said we're, we're thinking about a. Use context in use memo as a alternative to actually writing a selector for context. And apparently their thinking has evolved and they're not going to do that at this point because the React compiler basically gives you 95% of the performance benefits that a context selector's API would have without them needing to design and ship a context selector's API, into React itself. If you think about it, the point of the compiler is that it not only optimizes like your used memos and whatever, it also optimizes the render output. And so if you have a component that reads from a context, it will, it will render because the context value changed. But if none of the data that it needs from the context has updated, it will end up skipping all of its children. And so that drastically cuts down on how many components would render when the context updates. So there was actually some very, very good discussion in the longstanding context, selectors RFC thread, just within the last two or three days where a few people were agitating for react should really add contact selectors. It'll get rid of all these other state management libraries. [19:18]
-
-And I left a couple comments trying to explain how the compiler solves this problem and Joe Savona from the React team then went on and wrote some very extensive, detailed comments talking about how the React team has been doing research into these ideas of data flow analysis. And how do you manage large amounts of state and how does it compare with react context and signals and, you know, third party state management libraries. [20:57]
-
-## [PR for “concurrent stores” skeleton](https://github.com/facebook/react/pull/33215)
-
-**Mark:** And so he confirmed that, they're not planning to add a context selector's, API and instead their thought process is actually now about this concept called concurrent stores. So as best as I understand it, the idea is that right now a third party library like Redux or Zeus stand relies on the use sink external store hook to be able to tell react that there's a subscription data changed. This component needs to update, but. That has the limitation that it doesn't play well with suspense and transitions because if something got updated in the middle, react has to throw away work in progress and do a full render. It can't do all the, you know, the performance optimizations and with transitions. So it sounds like this concurrent store idea is supposed to be like an improved, better version of use sync external store where you can still have some data living externally. You can still have selectors saying like, only these components need to update. But the concurrent store would wrap the updates in a concurrent transition compatible way. [21:25]
-
-So he said that they're really trying to put some focus in API design onto figuring out what a concurrent store, API ought to look like. And it sounds like they've got some, some amount of progress on that design to talk about in the near future. They did put up a pull request a couple months ago with the skeleton for concurrent stores. It's just like defining some, some data types and adding some tests. There's no implementation code yet. [22:41]
-
-## [Third-party \\\`react-concurrent-store\\\` ponyfill package](https://github.com/thejustinwalsh/react-concurrent-store)
-
-**Mark:** However a third party developer that I saw has actually looked at all the tests and then gone off and tried to implement a third party hacky polyfill version of what it looks like the concurrent stores are supposed to be and publish that as a React concurrent store package. I'm very excited about this and I have not had time to actually try it out yet. So the takeaways are a. Most developers probably won't need to use some of these things directly. A lot of this is going to be more library maintainer concerns but it's very good to see that the React team is actively thinking about how, how can we make React apps faster? What are the best ways to manage complex state? How can we better integrate with third party libraries and try to make all the react features like transitions work well in those cases? [23:13]
-
-So there's your info dump for the day. [24:08]
-
-**Carl:** Love that. I had said some stuff just before we started recording, just before we started the event about, I've been playing with effect effect ts lately, which we, we've mentioned once or twice now. And again and when you're talking about these concurrent stores and you know, like I'm reading the post from Joe Savona talking about context selectors. [24:10]
-
-One of the things that I think effect solves well is dependency injection. it's focused on the backend, that actually says in the documentation like, effect is not meant for front end. They're, it may seem good, but it's not what it's meant for. And they're interested in exploring that, but they haven't yet. [24:30]
-
-But I think the execution model is pretty similar. It's like, it's almost like componentized backend a little bit. But with type safe dependency injection and error generation and, and using effect pretty extensively for the last three or four weeks has really made me. Itch for some of those benefits in React. [24:44]
-
-I'd be curious to see if they can, well, I've got a little bit more connections to make on that later on, so I guess I'll end it there. I don't know, just about dependency injection in effect and type safety and whatever in the context of selecting data on the front end, I think is interesting. [25:05]
-
-I think there's still a lot of API design exploration to do there. [25:20]
-
-**Mark:** I definitely recommend taking a few minutes to read some of Joe's comments in that context. Selector's, RFC thread, if you got some time, and then I, I expect there be, and to be at least some announcements, possibly about concurrent stores coming up at React Conf in October. [25:25]
-
-**Carl:** Interesting. [25:41]
-
-**Mark:** Then the last item out of the React related changes they merged a PR to add what looks like a new suspense timeline to the dev tools. They've got a demo video in there, and so it looks like it's actually now a, a third extra tab in the Chrome dev tools. So you've got the component tree, you've got the performance tab, and then there's a suspense timeline tab. And it looks like what it does is a mixture of , a rough rec out, like rectangle outline of the shapes of your components, but not showing like any of the HTML, just like , here's the structure of what your component tree looks like visually, and some highlighting for which ones have suspended, and then possibly some further details in a sidebar about which components suspended and when. So. as a dev tools type person, I'm always very, very excited to see new dev tools capabilities being added. [25:42]
-
-## Lee Robinsons’s [“Reflections on the React Community”](https://leerob.com/reflections) wrap-up post
-
-**Carl:** Okay, let's go into. We talked a little bit about Lee Rob leaving Vercel recently and going to Cursor. He put out a really great blog post called Reflections on the React Community. This sort of summarizing his, his time at Next and in React. Yeah, I don't know. Mark, do you wanna start? [26:39]
-
-I don't know if I have anything specific to start here. It's a really good overall hot, you know, 30,000 foot view of his time. [26:59]
-
-**Mark:** So Lee Robinson was the primary developer relations person for Vercel for about five plus years. And even in my own head like. when I hear the word devel Lee is pretty much the first person that comes to mind. And Lee was always in a very tough position. You know, CEL is, you know, a somewhat divisive company in some ways. You know, it, it puts out some wonderful technology. They've genuinely done a lot to advance the React ecosystem makes, make apps, you know, easier to host, they build next, et cetera. But, you know, they've also been accused of, you know, the React team and pushing reacts direction and making changes just for profit. And you know, as I've discussed in some previous episodes and blog posts, like a lot of that is undeserved criticism or, you know, misinterpretation of the background. And so, as you know, the visible face of Vercel and the next team we was. Frequently the target of a lot of those criticisms, even though, you know, none of it was, you know, like he wasn't the one developing the tool set or, you know, making the businesses decisions. And one of the things I've always appreciated about Lee is that, you know, he was always very, very active in discussions on, you know, Reddit and Twitter and Hacker News. You know, like not just in like the next sub Reddit, but you know, the React Reddit hacker news discussions. Like anytime a discretion thread would happen, he would pop up and, you know, respond to comments, offer feedback, and, you know, yeah. [27:07]
-
-Because of his position. Like occasionally people would interpret it as being like a corporate ish response, but he was always very, very active in being in there. And unfortunately that meant he was also the, you took the brunt of a lot of the criticism. So a lot of his blog post, you know, talks about, you know, react has, react has become stable, it's grown, the community's big. [28:48]
-
-Working with any community is really, really hard and it can be very stressful and very frustrating. He talks a bit about some of the difference between, you know, a, you know, more broadly like projects like React versus Rails you know, dealing with some of the community management acts, aspects, how you get feedback. He even talks some about, incentives like the React team in some ways builds react for meta. And sometimes that means that, you know, issues slip through the cracks. You know, like Meta isn't trained to make money off React. Well, in some ways Vercel is. And he also talks about, you know, some of the, the server component development process, how that was marketed how it's been interpreted. And he talks about burnout. And boy can I understand and sympathize with this one on multiple levels. responding to issues and comments, even when they're positive, takes a lot of time and effort. And when a lot of those comrades are, you know, angry and critiquing and throwing around conspiracy theories, that wears away at you a lot. So I have a huge amount of respect for Lee and everything he's done for Vercel and next in the React community over the last several years. And so I appreciated him doing the writeup and I could totally identify with a lot of the points he was making in here. [29:13]
-
-**Carl:** Yeah, definitely. And it's funny, I, you know, nobody, nobody's ever paid me to do reactive flux things, and it's a very different type of like community management. But I definitely, a lot of what he said resonated with me. But from that perspective, and also just like, I don't know. The burnout and, you know, thanklessness of wrangling a large group of people is is pretty real. [30:35]
-
-**Mark:** So it's a post worth reading. And Lee, if you ever hear this, thank you for all your time and effort. [30:58]
-
-**Carl:** Yeah. Thank you for all your time and effort. It's been a lot. It's been great. what you said about like Lee really being like you think Lee, Robb is definitely a canonical dev rel, like showed the world how dev rel happens. I think [31:04]
-
-really, uh, personified it. [31:16]
-
-## [Remix doing its own component model??](https://x.com/mjackson/status/1954975322157486408)
-
-**Carl:** Maybe in two remix doing its own component model. [31:18]
-
-**Mark:** we've been doing sort of a running observation of what in the world are Michael Jackson and Ryan Florence doing over in their corner. They, they continue to drop cryptic hints on Twitter about the directions of remix version three. And while this isn't, trying to keep this from being the, just repeat what they say on Twitter podcast, but, you know, so far all we have to go by is the cryptic hints that they're dropping. And so we've gone from, you know, just Remix v3 is its own thing to, it's going to use Preact to, well, actually, I guess now it's not using Preact. [31:22]
-
-**Carl:** Yeah, so I, I, I guess they want to explore a similar kind of problem space as react and React are, I mean, I, you know, that's the signals that they're putting out here is that like, well, these existing tools do not solve the problem well enough, we believe. And so we're going to explore that. And, you know, I, fair enough, I, I think there is more room to explore there. [32:01]
-
-I know some discussion in reactive flux on this, you know, on this link earlier Ricky had said like, you know, good luck to them. I think they may find some of the same constraints as React has, and I think that's pretty likely. But, you know, also there's a term coming to mind uh, path dependence, which is, you know, like what the options available to you going forward are dependent on the choices you made in the past. [32:26]
-
-And so, like, you know, react is pretty far down, it's set of chosen decisions. So I think there is some value in backing out and saying like, well, hey, maybe we're in a local maximum. Let's explore some other possible paths here. And yeah, so let me pick up where I sat down earlier talking about effect. [32:49]
-
-Right. So like, it, it feels to me like a componentized model for the backend. And it's really interesting because each, you know, backend component that you write, which I'm, they call 'EM Effects, but you know, this is a React chat, so I'm going to translate. So you write like a backend component and it has a type safe it uses TypeScript generics to describe its outputs, its possible errors emitted and what dependencies it requires to be passed in effects. [33:08]
-
-These backend components can like, make their own dependencies available, you know, or they can say, you need to provide this at runtime. And so that's pretty, that feels very similar in use to me in like ideology to me as what React is trying to do. [33:37]
-
-**Mark:** your props and your output. [33:54]
-
-**Carl:** Right. Props, return value, boom. Like, okay, every return value is JSX and it doesn't really matter specifically what, but you know. Yeah. So it, it, it's really interesting having error safety as well as dependency type safety because like props are one thing. But you know that there's no way to describe that. [33:56]
-
-This component being rendered relies on being nested underneath a context provider. Like you can do a runtime check for that, but you can't do a a compiled time type safety check for that. And that's the kind of thing that effect is enabling. It's that kind of dependency injection. Like what environment does this expect to be run in, not just what inputs does it expect to be provided. [34:16]
-
-I. So like using that in a backend context, you know, in this, going all in on this in a backend space where it's intended to be used has really made me reflect on the experience of using React and what kind of, what some of its pain points are. And so I guess like the React core team has gone all in on the transition boundary between the client and the server with server components. [34:41]
-
-Like they wanna really make that smooth and instead of this request response model, just have it be more fluid and you know, whatever. Yeah, streaming all that which is great and that's a very interesting direction to explore, but it does not address all of those kinds of things of how do we make a robust. [35:04]
-
-Reliable application that can be statically verified, will run as expected. And that is more of where effect is coming at the problem space of code authoring from. And yeah, I think the, like both of those are really interesting viable problem spaces to explore. And if Remix is saying, we think the path that React is exploring is not the ideal user experience, maybe they're gonna go more in something like this. [35:23]
-
-And if they do, this is wild, pure, rampant speculation on my part right now. But if they, you know, I can see a possible world where one thing that might interest them is the same kind of guarantees that effect is trying to provide. And that would be valuable. Like, so I, I, yeah, I'll still be paying attention to this. [35:51]
-
-I do have a greater degree of skepticism it's a huge expansion of what scope of problem they're exploring. So that's challenging. But you know, they've taken on big challenges before. Shipped things. So yeah, we'll be paying attention and see what they see. What they come out with. [36:09]
-
-**Mark:** Yeah, so basically where things stand at the moment are lots of cryptic hints on Twitter. It's not gonna be a React. It's a different component model. They want to make it LLM friendly. We still haven't seen any good examples, but I'm assuming they will do a big announcement at the Remix Jam conference, which I think is in [36:24]
-
-October. [36:42]
-
-**Carl:** Yeah. Oh, they had just done, just recently announced that. [36:43]
-
-## [Remix 3 and the End of React-Centric Architectures](https://thenewstack.io/remix-3-and-the-end-of-react-centric-architectures/)
-
-**Mark:** And then along with the rampant speculation bit I saw a blog post just earlier, earlier today, but it was from a month ago called Remix Three and the End of React Centric Architectures, which also does a bit of, you know, speculating, hypothesizing on the ways various frameworks have chosen to build things and says, you know, maybe it's a good thing that Remix three is supposedly going back to a more web native framework approach. [36:46]
-
-**Carl:** Yeah, and they're doing Remix Jam right after React Conf in Toronto, so, yeah. We'll, we'll shot that out at the, in the conferences section at the end too. [37:13]
-
-## [Popular nx packages compromised on npm](https://www.aikido.dev/blog/popular-nx-packages-compromised-on-npm)
-
-**Carl:** Yeah. Okay, moving on. our last main content subject for the month, there's another security vulnerability. I feel like we, you know, we, we, we talk about these somewhat regularly it feels like, but some pretty popular NX packages were compromised on NPM. So NX is a, [37:21]
-
-**Mark:** Monorepo management and build tool [37:39]
-
-**Carl:** yes. It's a competitor to turbo repo. I, I, I think I would [37:42]
-
-**Mark:** to, to some extent. Yeah. [37:46]
-
-**Carl:** it got wholesale compromised as in like everyone who installed it had a post install script run that swiped a bunch of configuration files like .env and .npmrc, anywhere you can think that credentials might be stored in your project workspace or elsewhere on your system. [37:47]
-
-This script looked for and then uploaded to GitHub. So that's really bad. This is a, this is a, this is a theoretical exploit that I've been hearing about for the last 10 years. Like the vulnerabilities possible by NPM post install has been a subject that comes up every couple of years. And, oh boy, this is a bad one. [38:07]
-
-The, this blog post discussing the vulnerability said that when they were, they were monitoring GitHub. 'cause the way the script worked is it would, if it found your GitHub credentials, if it found a valid SSH key for GitHub or I guess actually an API token, not an SSH token. But if it found a GitHub API token, then it would silently upload a new repo. [38:27]
-
-So it, it, which is interesting because it was a public repo on GitHub created by this malware. So there was some kind of public metric that could be gathered for its scope of impact. And so there this blog post says that they saw at one point, 1,400 of these repos created by this malware script. [38:51]
-
-So like, that's quite a number of people who got all of their secrets swiped off their system. One interesting thing that this malware did is if it found an LLM tool on your system, it would write a prompt to that LLM asking it to find all of the secrets on your system. So like if you, if you've got Claude, like suddenly Claude is maliciously gathering all of your tokens from your entire system that it can, you know, whatever it can access. [39:11]
-
-Like, holy shit, that's bad. That's not, yeah, that's, that's pretty bad. [39:38]
-
-## Last month [eslint-plugin-prettier maintainers were targeted](https://snyk.io/blog/maintainers-of-eslint-prettier-plugin-attacked-via-npm-supply-chain-malware/), this is a much broader attack
-
-**Carl:** you know, last month we discussed a, another vulnerability where the eslint-plugin-prettier package maintainers were targeted. So I guess this, this could be, this could be the same attackers perhaps, and they were just more successful in that, you know, instead of. Getting busted while trying to steal credentials for a major packages maintainers. [39:43]
-
-They actually got it. And so now they have successfully executed on this broader attack that they were maybe trying to do earlier. Woo. That's bad. And it sucks 'cause like what do you, how do you even respond? What do, how can you keep yourself safe if just [40:02]
-
-**Mark:** Monitor your, monitor your dependencies, actually look at lock files. I, I can say that there are some good tools out there that will watch PRS for, you know, like what packages are getting updated in this PR and, you know, warn you if any of them have known PO known problems. That's definitely a valuable thing to include in the CI process. [40:16]
-
-**Carl:** Yeah. True. But man, one of the, one of the challenging parts about this particular vulnerability is the. I, I remember half of the discussion that I saw earlier, and I can't remember where I found it, so I can't quickly refresh my memory, but there, a, a popular tool uses NX at latest on like, you know, project Bootstrap. [40:39]
-
-So like, you know, if you're just casually idly using whatever project generator this was to start something new oops. You got the latest NX that was compromised. So like that's not even, yeah, I don't know. Just like [40:59]
-
-**Mark:** the comment was actually in the, the tech reads and news link and it was [41:13]
-
-the NX vs. Code extension. [41:16]
-
-**Carl:** Okay. Okay. That's a li that's at least a little bit different vs. Code extension is not as popularly used as a, you know, project bootstrap tool, but yeah, not great. [41:19]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Okay. Into the lightning round. [41:31]
-
-**Mark:** Go for it. [41:33]
-
-## [React Strict DOM vs React Native for Web in 2025](https://shift.infinite.red/react-strict-dom-vs-react-native-for-web-in-2025-bb91582ef261)
-
-**Carl:** I saw this post from, it was a blog post summarizing a podcast from react Native Radio from Infinite Red. Great Folks. They spoke with the maintainers of React strict Dom and React native for web comparing and contrasting. We had discussed React strict dom a about a year and a half ago. [41:33]
-
-It was like February of 2024. And a, a lot of what we did was compare and contrast it against React native for web. So this was like very precisely the type of conversation we had except with the maintainers who aren't just speculating and guessing and inferring, but like they, no, they made this like, they know how it works. [41:54]
-
-They know what the trade-offs are. So it's got some really great architectural diagrams explaining the distinction and what the difference is. It lines up pretty well with what I recall us discussing and they have a really good little flow chart for making decisions about you know, TLDR should you adopt React strict dom. [42:13]
-
-And they did a nice little handy visual, which I'm gonna go to the Happy Path through the Happy Path on, which is do you already have React native app? No. Will you need web support eventually? Yes. Use extract Dom. So like basically they're saying this is a great low level set of abstractions that will make it more feasible to reuse your code in more places. [42:30]
-
-You know, like the benefit has always theoretically been that you could reuse much of the code between React native and web. But I've tried to do that a couple of times and the practical realities are challenging. Like, you know, just you need to use doing abstractions so that, that work in both places is really hard. [42:54]
-
-So this acknowledge React native sorry, react strict. Dom sort of acknowledges that and says, rather than trying to make a brand new abstraction on top of both React Native and react dom, we are going to lean more heavily on the web platform as an existing stable abstraction. Which is cool. I like it. [43:12]
-
-It seems cool. This is a really great blog post. Definitely recommend. [43:31]
-
-## [Faster JSON.stringify()](https://v8.dev/blog/json-stringify)
-
-**Mark:** The V8 JavaScript engine developers put up a post where they said they've spent a lot of time trying to optimize js, ON stringy. Think about how many times your code stringys stuff, whether it's sending back an H TT P response or you know, serializing things into an extension. they go, they go into a bunch of technical detail about how they've tried to make this faster. [43:34]
-
-**Carl:** specifically that problem parsing Jason, Jason Parse performance is exact, like that was the reason for React native doing the new architecture, which they've spent like much of the last year communicating and executing on. So yeah, the massive problem for the entire ecosystem, [43:56]
-
-**Mark:** You know, like other than actually executing the JavaScript code faster, like string finding stuff has to be [44:14]
-
-one of the most common things your JavaScript code does. So I believe this is supposed to be out in, I think it was like V eight like 13.8 I think it said which is available in Chrome 1 38. And I don't know what node version will contain that, that version of V eight. But faster is good. [44:19]
-
-**Carl:** Yeah, faster is so good, especially for stringifying. Yeah, man. Just the number of plate serializing and des serializing is one of the largest costs, you know, performance costs like everywhere. So yeah, it'll love that. That's great. [44:42]
-
-## [Node 22.18 unflags TS type-stripping support](https://nodejs.org/en/blog/release/v22.18.0)
-
-**Carl:** Node 22 point 18 flags TypeScript type stripping support. [44:56]
-
-node has had experimental support for. Interpreting TypeScript code and stripping out the types. doesn't actually check them or anything, but it allows you to take a project authored natively in TypeScript and run it with node without a compilation step, without building it through the TypeScript compiler. [45:02]
-
-**Mark:** Or, or using a tool like TS Node to execute it. [45:21]
-
-**Carl:** Yes. Yeah. Right. More directly. This is a replacement for TS node. And that's great. It's no longer experimental. It's, they're now saying it works. it's officially blessed, it's released. Love that. Definitely the ecosystem has moved more from, you know, a long time ago it was very focused on you compile the code and then you take those built artifacts and you run them, and if the type checker fails, you don't get a built artifact and you know, the metagame here has shifted a little bit more into the. Type checking is one very valuable part of verifying your code statically, but it is not necessarily where the compilation step lives. So, many more projects in my experience have moved towards sort of a parallel model where you have a build step and there is type checking in the project, but it just kind of runs separately from that build step. [45:24]
-
-So this is, this is a great tool enabling that kind of pattern. And it's released, it's done. Yay. [46:16]
-
-## [Waku switches to Vite’s WIP RSC support](https://waku.gg/blog/migration-to-vite-plugin-rsc)
-
-**Mark:** A couple RSC and project related updates. We've talked previously about how, vet itself has been missing some pieces in that would enable like full RSC support for vet based frameworks and that there has been a work in progress PR to try to add better RSC primitives into vet somehow. So the Waku RSE framework is now making use of vet's work in progress plugin rather than whatever layers they had built for themselves internally already. So it's good to see that that's coming together. [46:23]
-
-## [Rari, a fast React framework with RSC support built with Rust](https://ryanskinner.com/posts/how-i-built-a-full-stack-react-framework-4x-faster-than-nextjs-with-4x-more-throughput)
-
-**Mark:** And then I saw an announcement for a new framework called rari, which is sort of an acronym for something, some, something faster rendering somehow. But it looks like a, it's supposed to be an RSC based framework that has a custom low level layer. Built with rust. And of course, as we all know, rust makes everything faster. But it sounds like someone looked at some benchmarks of, you know, like next RSC performance and said, I think I can do better myself. And has built their own full stack framework that has RSC support using a custom low level rust layer. [47:00]
-
-**Carl:** Neat. Cool. Yeah, they do claim four, four times faster component rendering under load four milliseconds versus 17 milliseconds. And that's cool. I don't know that if your problematic performance is 17 milliseconds, that's maybe not the worst problem to have. [47:37]
-
-## [Selecting values from query results](https://tkdodo.eu/blog/react-query-selectors-supercharged), as well as [The Useless useCallback](https://tkdodo.eu/blog/the-useless-use-callback)
-
-**Mark:** Then separate from all that the always wonderful Dominic Dome TK Dodo has put up a couple great blog posts. One is the latest in the series of posts on how to use React Query correctly in this case, how to use the ability to select values out of a query. So maybe like you have a, a list items query and you only want to grab one of 'em. And then you also put up a post talking about how a lot of time you don't actually need the used callback hook. There's a lot of cases that used callback is actually kinda useless. So excellent reading as always. [47:52]
-
-## [TS\+ postmortem (Effect-TS experimental TS fork)](https://effect.website/blog/ts-plus-postmortem/)
-
-**Carl:** Can you tell I've been using effect and it's just been living in my brain for a lot of the time. I, as part of reading it, I found this blog post that they wrote pretty recently beginning of July. Where they had done, they had actually forked the TypeScript compiler wholesale and tried to do what they called TypeScript plus TS plus. [48:26]
-
-And I guess part of the idea, as you, as I've been using effect, I can feel very strongly the desire for JavaScript to support a couple of different tools that I, I I, I had remembered seeing as proposals many, many years ago and waited many, many years for them to land mo specifically the pipeline operator for composing functional, you know, programs together and pattern matching, which resembles a switch case, but lets you match on like properties and attributes and, you know, things like that in a different way, in a more flexible way. So. They tried to fork the compiler to make errors a little bit better. Basically, like they're really pushing the bounds of everything you can do in TypeScript and JavaScript. [48:45]
-
-So the, as part of that, they explored fully forking, TypeScript and this, so this is a great postmortem of their design goals and what they were trying to achieve and why they have backed off of that. Yeah, how far we went and what went wrong, what we learned it's pretty good. Definitely very interesting like this. [49:35]
-
-Just reading more about effect, I can just like, it just the amount of the number of different places where they're pushing the envelope and like iterating on the state of the art in web on the backend is just really palpable to me. So, definitely an interesting read here. [49:55]
-
-**Mark:** I, I, I thought it was a good blog post. Honestly, I also partly appreciate it just because they said we spent like an entire year trying to build this thing and it didn't pan out. Here's what we tried and what we learned and what went wrong in the process. I, I, appreciate good art, good write-ups, like that. [50:12]
-
-**Carl:** Yeah, right. I feel like this is good to read as an engineer because it's just a really good postmortem where you can really understand their thought process of why they tried to do this, what benefits they were hoping to get, and what challenges they ran into that made them say, okay, this is not achievable. [50:29]
-
-Just really good, really good read. [50:46]
-
-## [React useTransition update ordering details](https://jordaneldredge.com/notes/react-rebasing/)
-
-**Mark:** I saw a good short post from Jordan Eldridge, who I believe created the web amp recreation of Winamp. Where gave some, gave some thoughts on what happens when you do a React used transition and you apply some other state updates while the transition is going on. Short but useful, especially since transitions are a newer part of the react rendering model. [50:48]
-
-## [“A Clock that Doesn’t Snap”](https://ethanniser.dev/blog/a-clock-that-doesnt-snap/), Techniques for fixing hydration of values like dates
-
-**Mark:** And then I also saw a post called A Clock That Doesn't Snap, which talks about some of the dealing with inconsistency problems between server rented values like dates, and then what happens when you try to actually hydrate that on the client. And a couple different techniques for trying to make it not be inconsistent. [51:13]
-
-**Carl:** Interesting. [51:35]
-
-## [React Cache: It’s about consistency](https://twofoldframework.com/blog/react-cache-its-about-consistency)
-
-**Mark:** There was an article on React Cache. It's about consistency, so React added the cache, API for use on the server, and it's, it's a sort of memo function. The idea is that you can get, like if you need to make one fetch call in multiple places while doing server side rendering, you can try to ensure that it only happens once during that particular render pass on the server. And so the post goes into some detail on what the cache method is, why you want, would want to use it, and how it, you know, actually using that cashed value during the render can produce more consistent results during the render process. And then goes into a little bit more about like some of the conceptual behavior of React components and what is pure versus impure anyway. [51:36]
-
-## [Self-hosting Next at scale](https://dlhck.com/thoughts/the-complete-guide-to-self-hosting-nextjs-at-scale)
-
-**Mark:** saw an article that gave some battle hardened details on the complete guide to self-hosting Next JS at scale. So next is commonly used with Vercel. You can deploy it yourself, but you sometimes have to fill in some of the missing hosting pieces. And so this was a good post that gave and that talked about, you know, what are, what happens when you try to use Next Cache? [52:26]
-
-And it by default cache is values locally. But if you've got multiple copies of the server rendering, now you can have inconsistencies between different instances. So how would you break that out into using a Redis server or something? Instead, how can you handle image optimization and CDN configuration? So if you're trying to do any self host, you know, next, this looks like a very useful guide. [52:53]
-
-**Carl:** Love that. Such a good, deep technical writeup of, I mean, right. Self-hosting next is such a big problem that people discuss regularly that I, I just love seeing, you know, a proper writeup about it. [53:14]
-
-## [Server and Client Component Composition in Practice](https://aurorascharff.no/posts/server-client-component-composition-in-practice/)
-
-**Mark:** Then finally we have a post from Aurora Scharf who spent a lot of time researching and writing about server components and various usage patterns, and she has an excellent post on server and client component composition in practice, which gives some examples of how you can intermingle server and client components to do some of the work on the server, some of the work on the client figure, and figure out where the boundaries ought to be. [53:26]
-
-**Carl:** Yeah. figuring out where the boundaries are should lie in things that's uh, very challenging. [53:53]
-
-**Mark:** And I think that's actually all we've got for this month, which is good 'cause we're right about at at time. [53:59]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Cool. Let's wrap up here with some conferences. [54:04]
-
-## [React Universe Conf](https://www.reactuniverseconf.com/) Sept 2-4, 2025\\. Wrocław, Poland
-
-**Carl:** We got React, Universe coming up in just about a week in September 2nd through fourth in Wroclaw, Poland. [54:06]
-
-## [WaysConf](https://www.waysconf.com/) Sept 16-17
-
-**Carl:** There's also Ways Conf September 16th and 17th. Krakow Great. Also in Poland. So yeah, Poland heavy uh, September. [54:14]
-
-## [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
-
-**Carl:** Then right after that, Cascadia Js, September 18th and 19th in Seattle. [54:21]
-
-## [CascadiaJS](https://cascadiajs.com/2025) Sept 18-19 Seattle, WA, USA
-
-**Carl:** Coincident with Squiggle Con September 18th in Boston, which I will be at [54:26]
-
-## [React Alicante](https://reactalicante.es/) Oct 2-4
-
-**Carl:** Then in October we've got React Alicante, October 2nd through fourth in Spain. [54:32]
-
-**Mark:** I will be speaking at that one. [54:37]
-
-I was not going to be there originally, but I will be flying back from Spain and showing up at React Conf in Las Vegas. That's gonna be a trip. [54:39]
-
-**Carl:** Yeah. Oh, wild. Yeah. [54:49]
-
-## [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
-
-**Carl:** 'cause we've got, you know, react conf in Las Vegas right. Then October 7th and eighth, [54:51]
-
-## [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
-
-**Carl:** then, like we mentioned earlier, we've got Remix Jam October 10th in Toronto. So if you really, like, you could fly out to Vegas and then fly across the, well, I was gonna say across the country, but it's a different country. You can fly across the continent to Toronto. [54:56]
-
-## Outro
-
-**Carl:** Cool. That's all we got for you today. Thanks so much for joining us. We will be back on the last Wednesday of the month here in the live stage or back in your podcast feed just as soon as we can after that. [55:10]
-
-**Mark:** Thank you all for listening. Hopefully the list of links has been useful and informative. If you are going to be at either Squiggle Con, react Delicate, react Ante, or React conf please say hi. I will be running around possibly wearing my Simpsons picture as a name tag. [55:19]
-
-**Carl:** great. Love that. Yeah, same. Likewise. If you see me in Boston or in Las Vegas say, Hey, We gather sources from this week in React Bites, dev the React JS subreddit, and here in Reactive Flux from the uh, tech News and Reads channel. If you see anything that you think we should discuss definitely send it over to us at hello@reactiveflux.com. [55:37]
-
-if this is a show you get value from and wanna support, best way you can do so is by submitting a review on wherever you listen and tell your friends and coworkers about it. Thanks so much. you next month. [55:56]
-
-**Mark:** Take care. [56:04]
diff --git a/src/transcripts/tmir-2025-09.md b/src/transcripts/tmir-2025-09.md
deleted file mode 100644
index e58673b..0000000
--- a/src/transcripts/tmir-2025-09.md
+++ /dev/null
@@ -1,728 +0,0 @@
----
-title: "TMiR 2025-09: React 19.2 on the horizon; npm is still getting compromised"
-date: 2025-09-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl](https://twitter.com/vcarl_), [Mark](https://twitter.com/acemarke), and [Mo](https://twitter.com/mo__javad)"
----
-
-
-
-- [[00:52](#new-releases)] New releases
- - [[00:54](#tanstack-start-10-rc)] [TanStack Start 1.0 RC!](https://tanstack.com/blog/announcing-tanstack-start-v1)
- - [[01:13](#react-window-20-rewrite)] [`react-window` 2.0 rewrite](https://react-window.vercel.app/)
- - [[01:44](#apollo-client-40)] [Apollo Client 4.0](https://www.apollographql.com/blog/announcing-apollo-client-4-0)
- - [[01:59](#redux-toolkit-290)] [Redux Toolkit 2.9.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.9.0)
-- [[02:47](#main-content)] Main Content
- - [[02:52](#react-192-coming-soon)] [React 19.2 coming soon?](https://bsky.app/profile/ricky.fm/post/3lzt6yvs6o22r)
- - [[03:24](#activity-in-canary-with-docs)] [ in canary, with docs](https://react.dev/reference/react/Activity)
- - [[07:18](#last-react-labs-post-mention)] [last React Labs post mention](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#activity)
- - [[11:43](#useeffectevent-in-canary-and-has-docs)] [`useEffectEvent` in canary and has docs](https://react.dev/reference/react/useEffectEvent)
- - [[15:47](#compiler-inferring-function-names)] [Compiler inferring function names](https://github.com/facebook/react/pull/34410)
- - [[16:08](#docs-for-eslint-plugin-react-hooks-including-rules-and-compiler-issues)] [Docs for `eslint-plugin-react-hooks`](https://react.dev/reference/eslint-plugin-react-hooks), including rules and compiler issues
- - [[17:15](#react-native-10-on-the-horizon)] [React Native 1.0 on the horizon](https://youtu.be/GPtopk4y2LI?si=JoZVprPW33szn-6D)
- - [[22:02](#react-won-by-default--and-its-killing-frontend-innovation)] [“React Won by Default – And It's Killing Frontend Innovation”](https://www.lorenstew.art/blog/react-won-by-default/)
- - [[22:18](#inevitable-hn-argument)] Inevitable [HN argument](https://news.ycombinator.com/item?shownew&id=45252715)
- - [[27:54](#ricky-on-ryan-carniatos-stream-talking-about-scheduling-and-demoing-using-modern-react-features)] [Ricky on Ryan Carniato’s stream](https://www.youtube.com/watch?v=3vw6EAmruEU) talking about scheduling and demoing using modern React features
- - [[33:41](#server-components)] Server Components
- - [[33:44](#react-router-rsc-framework-mode-preview)] [React Router RSC framework mode preview](https://remix.run/blog/rsc-framework-mode-preview)
- - [[34:36](#also-middleware-is-now-stable)] also [middleware is now stable](https://remix.run/blog/middleware)
- - [[34:44](#krasimir-tsonevs-can-i-use-rsc-today-support-matrix-and-experimental-forket-rsc-without-a-framework-build-tool)] Krasimir Tsonev’s [“Can I Use RSC Today?” support matrix](https://rsc.krasimirtsonev.com/) and experimental [Forket “RSC without a framework” build tool](https://krasimirtsonev.com/blog/article/vanilla-react-server-components-with-no-framework)
- - [[35:43](#rsbuild-support-for-rscs)] [RSBuild support for RSCs](https://bsky.app/profile/ebey.bsky.social/post/3lyf6vixick26)
- - [[35:55](#useful-post-on-parallel-and-recursive-route-rendering)] Useful post on [parallel and recursive route rendering](https://twofoldframework.com/blog/parallel-and-recursive-route-rendering-with-rsc)
- - [[36:35](#all-the-npm-compromises-and-malware-this-month)] All the NPM compromises and malware this month
- - [[39:47](#npm-package-maintainer-qix)] [npm package maintainer Qix](https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack)
- - [[39:48](#crowdstrike-npm-packages)] [CrowdStrike npm Packages](https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages)
- - [[40:16](#github-actions-npm-token-theft)] [GitHub Actions npm Token Theft](https://socket.dev/blog/nx-supply-chain-attack-investigation-github-actions-workflow-exploit)
- - [[41:01](#github-response)] [GitHub response](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/)
-- [[42:00](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[42:03](#porting-modern-typescript-to-run-on-dos)] [Porting Modern TypeScript to Run on DOS](https://jimb.ly/2025/09/23/qauntumpulse-from-steam-to-floppy/)
- - [[42:35](#cloudflare-ddosed-themselves-with-a-bad-useeffect-fetch)] [Cloudflare DDOSed themselves with a bad `useEffect` fetch](https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/?amp%253But)
- - [[43:11](#a-very-lovely-writeup-of-the-evolution-of-css-zoom)] [A very lovely writeup of the evolution of css `zoom`](https://www.bocoup.com/blog/the-webs-most-tolerated-feature)
- - [[43:56](#what-you-need-to-know-about-modern-css)] [What You Need to Know about Modern CSS](https://frontendmasters.com/blog/what-you-need-to-know-about-modern-css-2025-edition/)
- - [[45:21](#fetch-streams-are-great-but-not-for-measuring-uploaddownload-progress)] [Fetch streams are great, but not for measuring upload/download progress](https://jakearchibald.com/2025/fetch-streams-not-for-progress/)
- - [[45:40](#why-do-browsers-throttle-js-timers)] [Why do browsers throttle JS timers?](https://nolanlawson.com/2025/08/31/why-do-browsers-throttle-javascript-timers/)
- - [[46:01](#how-modern-browsers-work-deep-dive-addy-osmani)] [“How Modern Browsers Work” deep dive, Addy Osmani](https://addyo.substack.com/p/how-modern-browsers-work)
- - [[46:32](#biome-stress-testing-wip-nofloatingpromises-lint-rule)] [Biome: Stress-testing WIP `noFloatingPromises` lint rule](https://vercel.com/blog/stress-testing-biomes-nofloatingpromises-lint-rule)
- - [[48:37](#bun-how-bun-install-is-so-fast)] [Bun: How `bun install` is so fast](https://bun.com/blog/behind-the-scenes-of-bun-install)
- - [[49:23](#styled-components-fork-for-perf-and-react-19-compat)] [Styled-Components fork for perf and React 19 compat](https://www.sanity.io/blog/cut-styled-components-into-pieces-this-is-our-last-resort)
- - [[50:02](#vite-ssr-custom-getstaticprops)] [Vite SSR: Custom `getStaticProps`](https://www.patron.com/blog/post/vite-ssr-getstaticprops-replacement/)
- - [[50:11](#dominic-gannaways-new-framework-ripple)] [Dominic Gannaway’s new framework Ripple](https://github.com/trueadm/ripple)
- - [[50:35](#remix-v3-mj-hints-iframe-like-async-primitives)] [Remix v3: MJ hints “iframe-like async primitives”](https://x.com/mjackson/status/1971816432427298951)
- - [[51:57](#react-native-rfc-to-remove-old-architecture)] [React Native RFC to remove Old Architecture](https://github.com/react-native-community/discussions-and-proposals/pull/929)
- - [[52:28](#cloudflares-new-capn-web-rpc-graphql-alternative)] [Cloudflare’s new “Cap’n Web” RPC; GraphQL alternative?](https://blog.cloudflare.com/capnweb-javascript-rpc-library/)
- - [[55:26](#expo-ui-building-swiftui-apps)] [Expo UI: Building SwiftUI apps](https://docs.expo.dev/guides/expo-ui-swift-ui/)
- - [[55:57](#tanstack-db-an-interactive-guide)] [TanStack DB: An interactive guide](https://frontendatscale.com/blog/tanstack-db/)
- - [[56:21](#ts-60-may-switch-to-strict-options-by-default)] [TS 6.0: may switch to `strict` options by default](https://github.com/microsoft/TypeScript/issues/62333)
- - [[57:28](#shopifys-rn-new-architecture-migration)] [Shopify’s RN New Architecture migration](https://shopify.engineering/react-native-new-architecture)
- - [[57:42](#the-bloat-of-edge-case-first-libraries)] [The Bloat of Edge-Case First Libraries](https://43081j.com/2025/09/bloat-of-edge-case-libraries)
-- [[58:51](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[58:53](#react-alicante-oct-2-4)] [React Alicante](https://reactalicante.es/) Oct 2-4
- - [[59:13](#react-conf-is-back-oct-7-8-las-vegas-nv-usa)] [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
- - [[59:29](#remix-jam-oct-10-toronto-on-ca)] [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
- - [[59:43](#viteconf-oct-9-10-amsterdam-netherlands)] [ViteConf](https://viteconf.amsterdam/) Oct 9-10 Amsterdam, Netherlands
- - [[59:52](#jsconf-north-america-oct-14-16-chesapeake-bay-md-usa)] [JSConf North America](https://events.linuxfoundation.org/jsconf-north-america/) Oct 14-16 Chesapeake Bay, MD, USA
- - [[01:00:03](#jsconf-chile-oct-24-25-santiago-chile)] [JSConf Chile](https://jsconf.cl/) Oct 24-25 Santiago, Chile
- - [[01:00:10](#react-native-london-oct-30-31)] [React Native London](https://www.reactnativelondon.co.uk/) Oct 30-31
- - [[01:00:22](#react-india-oct-31-nov-1-goa-india)] [React India](https://www.reactindia.io/) Oct 31 Nov 1 Goa, India
- - [[01:00:26](#wey-wey-web-nov-17-18-malaga-spain)] [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
- - [[01:00:39](#react-summit-nov-18-21-new-york-ny-usa)] [React Summit](https://reactsummit.us/) Nov 18-21 New York, NY, USA
- - [[01:00:48](#react-advanced-nov-28th-london-uk)] [React Advanced](https://reactadvanced.com/) Nov 28th, London UK
-- [[01:01:08](#outro)] Outro
-
-# This Month In React - September 2025 (SM)
-
-Carl: Alright. Hello everyone. Thank you for joining us for the September edition of this Month In React. As we, uh, get together and recap what's going on with React, react Native and the web, we're coming to you live from Reactiflux, the place for professional developers using React. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I do community programs like these events and build tools to help keep the community operating. [00:00]
-
-Mark: Hi, I'm Mark. My day job is working at Replay.io and digging into the guts of React and its internals. And in my copious amounts of spare time, I'm currently rewriting the guts of Immer for faster performance. [00:23]
-
-Carl: Yeah, you did a live stream on that. That was cool. [00:34]
-
-Mark: Yeah, that was a lot of fun. [00:36]
-
-Mo: And my name is Mo. [00:37]
-
-I am the head of Mobile at Thedo. And yeah, I spent a lot of time in the React and React native communities, speak at conferences here and there, and organize the React Native London Meetup and conference, which is coming up in November. [00:38]
-
-Carl: Yeah, more on that later. [00:51]
-
-## New releases
-
-Carl: Let's jump into some new releases. [00:52]
-
-## [TanStack Start 1.0 RC!](https://tanstack.com/blog/announcing-tanstack-start-v1)
-
-Carl: We're gonna talk more about this in depth in the main content section, but Tan Stack start has released a 1.0 rc, so that should be coming together. I've tried playing with this a little bit and didn't make it too far. It just ended up being a larger task than I really imagined, but I'm excited about it. [00:54]
-
-## [`react-window` 2.0 rewrite](https://react-window.vercel.app/)
-
-Mark: React Window. Just put out a version 2.0. Brian Vaughn did a pretty major rewrite of the library to try to simplify some of the props and add some nice built-in features like automizing of the list items and auto resizing. So you no longer need a resize plugin to handle that. [01:13]
-
-Carl: Oh, that's nice. Okay. Yeah, and react window is efficiently rendering large lists. [01:32]
-
-Mark: It's virtualizing lists. Yeah, so you got a list of, you know, a million items. You can only show a hundred on screen at once, that sort of thing. [01:36]
-
-## [Apollo Client 4.0](https://www.apollographql.com/blog/announcing-apollo-client-4-0)
-
-Mark: Also, on that note, Apollo client for GraphQL just put out version 4.0. I know this was a, a pretty major effort to try to improve the packaging, consolidate. Remove a bunch of deprecated features, so that should be a significant improvement if you're using Apollo. [01:44]
-
-## [Redux Toolkit 2.9.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.9.0)
-
-Mark: And on my side, I actually just shipped a Redux toolkit 2.9 earlier this month. The biggest thing there is I made a bunch of perf optimizations to RTK query, especially for cases where you've got a lot of components that are reading from the same cache entry. And we also added a few new options and bug fixes, but the perf improvement and some in-flight requests cleanup was, were some of the biggest pieces there. [01:59]
-
-Carl: Okay. Yeah. Not too many new releases for open source libraries this month, I guess. [02:25]
-
-Mark: Well there, there probably were a few more. We just didn't collect them. [02:30]
-
-Carl: Yeah, I wish there were a little bit more consistent standards across the ecosystem for how to publish a list of new releases. Like the GitHub release is, it is pretty good, but it's still only like 60% hit rate, I guess. Something like that. [02:32]
-
-It feels like. [02:46]
-
-## Main Content
-
-Carl: Cool though. Let's go into our main content. Can you tell us a bit about React updates? [02:47]
-
-## [React 19.2 coming soon?](https://bsky.app/profile/ricky.fm/post/3lzt6yvs6o22r)
-
-Mark: I don't actually have any real details on this, but Rick Hanlon from the React team tweeted out like yesterday, a screenshot of himself apparently working on release notes for React 19.2, so I would assume it's fair to say that it's probably coming out in the near future associated with that and potentially coming out in 19.2. Although the timing may be a little too soon, we have two React features that have graduated from the experimental branch to the Canary branches. [02:52]
-
-## [ in canary, with docs](https://react.dev/reference/react/Activity)
-
-Mark: The first one is the new activity component. This has been around in some form in in the experimental branches for. Probably multiple years at this point. It was originally known as the offscreen component, and then they officially renamed it to the activity component maybe about six or eight months ago. [03:24]
-
-And this is gonna be a pretty big deal. So one of the issues with React has always been that built-in state is managed at the component level. And if you unmount a component, then it, you know, both cleans up the effects and they go away. But the state that was in that component goes away as well. And so that's one of the reasons why there's been, you know, so much use of external state libraries like, you know, Redux and Juice end and Jot and MobX over the years is because in order for state to persist, you either needed. [03:45]
-
-To have the state live outside UAC component tree, or you needed to hoist it up to the top and pass it down via context or props and if you unmount a section of the tree that DA and that data could go away. So the activity component is going to allow you to essentially disable and hide a section of the component tree, but react will keep around the state for those components. [04:22]
-
-And in fact this actually kind of goes along with some of the strict mode stuff that people have, you know, complained about for years. The activity component will also unmount the effects for the components that got hidden. People have complained for years, you know, strict mode, double running effects, you know, shows bugs and, and all the other things like that. [04:52]
-
-But part of the point of that has been to work towards, eventually this feature will come out where you can toggle the activity component on and off. And React will run the UNM mounts because the components aren't fully mounted, therefore, they shouldn't have active effects going. But it will keep the state for those components alive. [05:14]
-
-And so you can imagine this could be useful for a couple of different things. One is like a tabs component. Right now, if you have a tabs component, you either stop rendering the other tabs completely as you switch back and forth, or you use something like CSS display, none, which means the tabs are active and in the page, even though they're not even being displayed. [05:37]
-
-And so with the activity component, you can say I want to pre-render the content for the other tabs, but it's not actually attached to the page until we swap back and forth. But they could still persist the state. So if someone goes back and forth between the different tabs and makes some edits, then. [05:59]
-
-You know, that still stays alive. There's a comment in the chat that the naming choice for the component seems very strange to me. I agree. I didn't like it either. There was some rationale in the PR that actually renamed it to activity. I don't remember what it, what it was specifically off the top of my head, but they, I think it was that like, it's more about is the component active rather than is it quote unquote off screen. [06:19]
-
-Yeah. But I, I don't entirely buy that myself. [06:46]
-
-Carl: Yeah, right. Because this is like hitting that midpoint between that decision point of do you render null or do you render the dom with styling to suppress its visibility. And so I guess this is like smack in the middle, like the internal representation of all of that. [06:51]
-
-Dom remains. But you don't use styling to hide it, which is great for cross-platform stuff. 'cause like there wasn't a cross-platform way to hide something as far as I know before. [07:07]
-
-## [last React Labs post mention](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#activity)
-
-Mark: So if I, if I look back at the last React Labs post from April where they talk about, you know, the plans for the activity component, there's a section there that says, in the future we may add more modes for activity. [07:18]
-
-One of them could be content visible, but keep it unmounted and pause dom updates. Another is the ability to destroy state for hidden activities if too much memory is being used. So I think part of the mindset is it's not just like a bullion toggle, it's we're shipping with two mode options that are like a bullion toggle for now. [07:31]
-
-But we envision some possible additional modes for this down the road. [07:57]
-
-Mo: And, and you know, this is like particularly interesting to me because this has like been a long standing problem in the React native space when you're dealing with native apps. And I, I doubt this will work out of the box with React Native, but I think it's gonna be one of those things which will eventually get there. [08:02]
-
-And hopefully the new architecture makes this easy for the, the core team to adopt and like make sure that those APIs are working correctly. But it's a classic issue, especially when in Native world you're dealing with this concept of like stacks of pages on top of each other. You really don't want the, the stacks that aren't visible or the pages that aren't visible in your stack showing or getting all of the DOM updates, or in this case this, the updates to the actual screens whilst they're inactive because that's a massive performance bottleneck on native devices. [08:17]
-
-And so this type of thing, people have massed over it in the most dirty ways possible and hacky ways possible in, in the React native world. It's been like a longstanding problem because if you, you know, unmount them and then remount them and reestablish the state, there's sometimes like a flashing white screen before the actual components reload. [08:46]
-
-Then you need to delay the transition because all of these things are like transition with page transitions and native. So it's basically to say there's a lot of complexity and if there's a native React way to deal with this, that ties into navigation on the native device as well, then I think it's gonna be a game changer and it'll simplify and fix a lot of performance issues that people often have with their React native apps. [09:05]
-
-Mark: Yeah, I, I know we've, we've had a couple of open issues on the `react-redux` repo with people complaining that. Components that are off, quote unquote offscreen in the React native stack are still subscribed to Redux updates and taking up perfects from running all the subscription logic and asking for us to add random options to make that toggle or something. [09:26]
-
-And so if you know, the activity component ought to be the built-in solution for that. And so that would actually means we don't have to do anything, which is great. Yeah, exactly. [09:48]
-
-Mo: And you know, like some state management libraries have adopted some work around components that you can use for that, but it comes with trade-offs, right? [09:57]
-
-And ideally, your state management library really should not worry about this. This feels like a core react primitive problem rather than a state management library problem. To me, [10:06]
-
-Carl: back to what you said about like the layering of UI and performance problems and like listening to events and things. Fun fact, I've chatted with some people who did React native or like React UI for automotive companies and that was a problem they dealt with like sometimes for certain cars. [10:15]
-
-The reason the UI sucks sometimes is because of this issue and because it's rendering multiple UIs on top of each other and doing all sorts of weird, crazy stuff. There's two [10:35]
-
-Mo: devices that are particularly bad for that. One is Smart TVs and the other one is cars. And the reason for that is both of them are awful processors and like they really cheap out on the hardware because they're cutting costs everywhere in the actual like manufacturing bit. [10:45]
-
-And so something that might run in your web browser with your laptop that like has like several hundred megabytes of RAM per tab. Will, you know, be restricted to 50 megabytes of ram or it'll get killed by the operating system that lives on the automotive car infotainment system. And this is a big problem for any, like one of those types of devices. [11:01]
-
-And I think a lot of those, you'll be surprised, run on React and like web-based platforms or sometimes even rec native, and it's a big, big issue. So I think something like this. You know, you can fix those issues, but it's hacky and not everyone will do it. So then you'll get really crappy infotainment systems, like you said, Carl. [11:23]
-
-So, [11:40]
-
-Carl: okay. That's probably long enough talking about activity though. [11:41]
-
-## [`useEffectEvent` in canary and has docs](https://react.dev/reference/react/useEffectEvent)
-
-Mark: So one other, one other feature that's migrated from experimental to Canary, I just saw this one a few minutes ago, is the `useEffectEvent` hook. This is something that the React team has also talked about for a while, and I actually didn't even know that any progress was being made on this until I just saw the PR announcement. [11:43]
-
-I'm gonna describe this very badly. Someone should correct me on this, but it's almost like a used memo for callbacks where you'll get the latest reference to a. Callback inside when you execute it, but you get a consistent function reference back when you use it. And so this avoids the need to do a workaround where you're like, main, where the, the callback is reading something off of a ref to get the latest value. [12:04]
-
-I know that this is something that had been proposed a while back and then the initial proposal got killed and they said, we'll, we'll come back and we'll rethink this later. And apparently later is finally now. [12:34]
-
-Carl: Later is now. That's great. Yeah. Interesting. I'm, I'm not super up to date on this, so I'm just reading the docs right now to understand it better. [12:48]
-
-Interesting. The, I definitely know that I have used refs. You know, red values off refs because of weird issues. So I'm not quite groking how this solves this immediately, but that's interesting. [12:57]
-
-Mark: So, and okay, so a partial example, and again, this is me going off the top of my head and not even trying to read the post at the moment. [13:09]
-
-So, if you have like a used callback that needs to access a value, you either let the callback get recreated every time, which in case there's no point in the use callback at all, or you have the item in the dependency array, which means it's gonna, the callback is gonna get recreated still when the value changes or you don't rate it all, and oops, now you have a steel value, which is bad. [13:17]
-
-Carl: Right. [13:42]
-
-Mark: So what happens when you want a consistent callback reference that never changes, but it still needs to see the latest value in order to do something useful when it runs. So one workaround for this is you put a use ref a couple lines up in the component that runs first. You assign to it even in like another use effect before the one that you care about. [13:42]
-
-That means it gets updated. Now you've produced this kind of weird sequence of events where I know that the ref has already been updated before the callback ends up getting run. And so part of the point of this hook is to eliminate the need to do that little dance yourself. [14:08]
-
-Carl: Yeah. Okay. That makes sense. [14:24]
-
-I'm reading this list of caveats and it seems tricky. The only call inside effects define it just before the effect that uses them. Do not pass them to other components or hooks. Do not use `useEffectEvent` to avoid specifying dependencies. This can hide bugs. Sure. Use it only to extract logic that does not depend on changing value. [14:26]
-
-That's quite a set of constraints. [14:48]
-
-Mark: When the new docs came out, and Dan and a couple others wrote the tutorial. There were a couple pages in there that actually referenced this hook as the solution for some of the problems that were being described. Even though the hook didn't exist yet, some of the docs pages also try to make the terminology very unique, where they talk about lowercase e effects as in like, you know, just the generic concept of a side effect versus a capital E effect, which is like a somehow react specific concept that I don't think the docs ever fully defined. [14:51]
-
-And so in, in a way like the use effect event hook, is the React team trained to somehow solidify this. Notional react effect term in a way. [15:30]
-
-Carl: Interesting. Interesting. [15:46]
-
-## [Compiler inferring function names](https://github.com/facebook/react/pull/34410)
-
-Mark: Alright, two other little data points and, and updates Worth noting. The React team merged a work in progress PR to the compiler to try to do and to try to automatically infer function names for things like callbacks that you pass to use effect so that you know when they show, like show up like in a stack trace, they are nicer and easier to read. [15:47]
-
-## [Docs for `eslint-plugin-react-hooks`](https://react.dev/reference/eslint-plugin-react-hooks), including rules and compiler issues
-
-Mark: And then the docs now have a page for the Eslint plugin of react hooks, including a bunch of information on all the different rules that it cover and that includes issues that'll get flagged by the compiler as well. [16:08]
-
-Carl: Also, yeah, I wanna say on the compiler inferring function names like that is like one of the most quietly mind blowing things I have seen in a long time. [16:19]
-
-I actually commented on the PR to ask like, what if this became a TC 39 proposal? Because this would have saved me days of effort over the life of my career. If there had been a little bit more data about what the heck is throwing an error instead of just like cannot read property of undefined. Oh thi this is quietly one of the mo going to be one of the most impactful changes in a long time I think. [16:29]
-
-Mark: I have actually, even just recently in some of the Immer work that I've been doing, gone in and replaced anonymous arrow functions with a named function just to try to get a better name and a stack trace. [16:55]
-
-Carl: Totally. Yeah, a hundred percent. And the annoyance of assigning an arrow function to a variable versus using a named function and how those are not the same thing. [17:06]
-
-## [React Native 1.0 on the horizon](https://youtu.be/GPtopk4y2LI?si=JoZVprPW33szn-6D)
-
-Mo: Cool. Let's move on to some React native news, which has gotten people a, a fair bit excited, which is one of the talks that was at React Universe comps that happened at the beginning of this month called React Native 1.0 is on the horizon. This is pretty exciting stuff because it's anecdotally, and I'm sure many people have had the same experience as me. [17:15]
-
-One of the biggest things that people oftentimes use, which is a really, really, you know, straw man argument, but nonetheless is there, is that, oh, react native's not stable because it's not 1.0. I kid you not, when I say three weeks ago we were talking about starting a new project here at Theo and someone brought this up as a reason not to use React Native as one of like the prospective clients that we had because another company who was trying to push them to use Flutter had told them, oh, it's not stable because it's not 1.0 da da da da da. [17:37]
-
-And you know, there's a little bit of fear mongering around this. The reality of it is that React Native has been around for way too long and it's been used in many, many serious production apps for, you know, several, several years now. And so I think this is something that a lot of people have discussed with the React Native Core team over the years. [18:06]
-
-And you know, there's always been a bit of a reluctance on going to 1.0 for various reasons. Um, and so this talk is really interesting 'cause they talk a little bit about the history of that and what the reasons are for that. But really what's happened over the last year is that the release process for React Native has been significantly streamlined. [18:23]
-
-So there are now six releases. Being targeted for every single year. So every other month there being a release from two releases, which was what we had in 2024 and you know, a lot more sporadic releases in the previous years. So there was no really never a schedule to it before where, whereas now there is one of the things that's been happening over the years, but really accelerated over the last, I'd say year, is that a lot of the APIs are being really stabilized, reduced, and the surfaces are being completely trimmed down. [18:38]
-
-And so the whole idea with this is less API surfaces externally means that there's less likelihood for breaking changes in the long term, which helps them feel confident to say, Hey, this is a 1.0 or reaching out sort of monumental point where they can actively say, Hey, this is a 1.0 release. And the other thing is that the React native. [19:06]
-
-Pipelines for building React native Core was quite a manual process in the past, and so what they've done in sort of recent years is worked on introducing a lot more end-to-end testing, some workflows that would test our C bugs and you know, breaking changes much quicker. And so that's really been a lot of the efforts behind the scenes, which you won't see in features and functionalities, but it's really been to the workflow for building React native. [19:25]
-
-And so a lot of this is really moving us towards that direction where there can be at 1.0. And so the conversation isn't. Potentially, hey, there's gonna be a 1.0 in the next few months. Maybe not even in the next year, but it is somewhere there where they're feeling like, okay, we can go ahead to, to basically releasing a 1.0 for React native at some point in the near future. [19:48]
-
-So the React team's gonna be, the React native team is gonna be working on this quite extensively and trying to reach a point where they're happy and so they're gonna be working with a bunch of people to start to potentially put a date on it, which is very exciting. [20:09]
-
-Carl: That is really exciting. That's a long time towards 1.0. [20:20]
-
-But like it would've felt premature I think for them to get, to call it a 1.0 before, or at least they would've had to do a lot of breaking. [20:22]
-
-Mark: Even just waiting for the new architecture to be the default, I think was a big thing. Mm-hmm. Yeah, definitely. [20:30]
-
-Carl: Yeah. And that really seems like it was a meaningful, a meaningful reason to delay, like it was such a large disruption to so many different parts of the ecosystem, but also so essential. [20:36]
-
-Yeah, it feels more truly native under the new architecture, rather than having to like serialize between two independent systems. It kind of reminds me of like when Docker launched because it was a Linux feature, you know, a Linux kernel feature. I remember for years they had like a, if you wanted to use it on Mac, you had to technically run a vm, which introduced all sorts of weirdness. [20:47]
-
-And so that feels, I dunno, this feels technically similar to me in how they like figured out how to not have two independent systems communicating with each other in that kind of way. And now that they've cleared that hurdle, they can get towards a greater level of stability. Cool. Awesome. [21:09]
-
-Mark: One other thing that actually kinda reminds me of, so we had squiggle conf a week and a half ago and one of the talks was from Shelley Vohr, who's part of the Electron core team and she did a talk about automating systems and you know, things like security and repeatability and what happens if the system goes down. [21:25]
-
-And it sounds like a lot of the effort that's been involved on the RN side really is about CI pipelines and automation and turning a manual release process into an automated release process. And you know, having that consistency is a pretty big deal here. [21:44]
-
-## [“React Won by Default – And It's Killing Frontend Innovation”](https://www.lorenstew.art/blog/react-won-by-default/)
-
-Carl: Cool. Drama post? [22:02]
-
-Mark: Drama post. [22:04]
-
-Carl: Yeah, so there was a recent post called React Won by default and it's killing front end innovation. [22:05]
-
-Mark: To some extent. There's nothing new in this post. People have been making complaints about this for years. [22:13]
-
-## Inevitable [HN argument](https://news.ycombinator.com/item?shownew&id=45252715)
-
-Mark: It's a pretty well written post, and it did make all the rounds and spawned massive 800 comment, hacker news thread and responses on Twitter and a bunch of other places. The first argument is that React itself has kind of stagnated that it was a big deal in 2013 when the virtual do solved problems with Angular, but that React really hasn't innovated since then claim, and that things like the React compiler are a bit more of a bandaid. [22:18]
-
-Whereas other frameworks like solid and spelt and quick are doing new and innovative things around signals and ruins and resum ability and other approaches to updating the dom. But the rest of the argument is that. The typical discussion these days for a project is, okay, which framework should we use? [22:48]
-
-Well, let's use React because it has the biggest ecosystem, because there's the most developers available because AI are familiar with it, because there's lots of libraries out there, et cetera. And the phrase that always comes to mind and for me is the old one about no one ever got fired for choosing IBM that back in the day, like IBM was the safe choice for, you know what, whatever tools it is sort of that same principle today. [23:09]
-
-Like most people are not generally choosing React. Because they're specifically excited about suspense or transitions or other things like that. It's the industry standard, so we'll stick with that. And so the article argues that because of that, because the mindset is used, react by default, that it's sort of choking out other frameworks that have had more innovation and newer interesting approaches. [23:39]
-
-And so it ends up offering some suggestions for things to evaluate about scaling and performance and team skills and whatnot. And then tries to counter argue the typical like size of the ecosystem type points. It's a well-written article, like it's not flame bait. The title is is well out there, but it makes a pretty good actual point and it spawned a lot of discussion, like I said, hacker News and a bunch of other places. [24:08]
-
-But I think the really interesting counterpoint to all that. Is Rick Hanlon from the React team put up a very long thread on Blue Sky, which really should be its own blog post at this point where he says that all the frameworks know how to update the do efficiently React has innovated in the past, but it's also, it was so good in the past. [24:34]
-
-People are actually kind of ignoring the innovations they've done since 2017 and 2018, and that reacts focus for the last seven years has been not about how can we make Dom updates faster per se, but about scheduling. Things like concurrent mode, transitions, suspense, even the new activity component builds off of the foundations that they've built for the last several years. [24:59]
-
-Yeah. And so his argument is that number one, when people say react is an innovating, they're ignoring all the new features built around concurrency. And number two, that most people are still thinking about using React in a very 20 16, 20 17 ish sort of way. Most people aren't even thinking about using the new capabilities that React has unlocked. [25:23]
-
-I think he's actually got a pretty good point. [25:50]
-
-Carl: That's fair. I would generally agree with that and like I am very much in that boat, I'll be honest, like I haven't written extensive from scratch, like build an app and react since about that time. The last time I really did that from scratch to like a full production level where I was like exclusively focused on the front end was about that time, like ended around 2021. [25:52]
-
-So I've been following a lot of this, but I haven't used it at the same level of depth that I used to. I have seen somebody who, you know, one of my internet acquaintances who I have a lot of respect for, as you know, both technically and like entrepreneurial and whatever. He's been extolling the virtues of server components for the last couple of months, I think, and it's been on my, you know, it's been somewhere on my to-do list to talk more with him. [26:15]
-
-Mark: Daniel Switz. [26:40]
-
-Carl: Yep, yep. Daniel Switz. Just like I've heard him say some things. It's like, okay, I feel like you get it and I feel like you get it in a way that you could communicate. It's crossed my mind actually to have him and Ricky and or him and Dan or I don't know, a group of people on a stage like this and just like talk about it and be like, what the fuck? What are we doing? How do you do this? So yeah, I don't know. It's like, it's definitely there is innovation happening. I think a lot of the innovation, like there's innovation happening and there's also just like roadblock clearing. It's like, you know, there's the innovative, you build the road, but then you have to deal with the consequences. [26:41]
-
-Like, great, you have this road. Like what is it like to actually use it? And then a lot of the time you realize there are speed bumps and whatever that you didn't realize you were building in the first place. And the fix there is not innovate. You don't just like, well that sucked. Let's build a new road. [27:16]
-
-No, you fix it. Figure out different ways to approach the same problem that have a different set of trade-offs. And so I think that's some of what's being complained about here is that like people are like, we need a new thing. We need to rewrite from scratch. And No, we don't. I don't think we do. So, yeah, I don't know. [27:33]
-
-I guess that's what I, what I have to say there. [27:52]
-
-## [Ricky on Ryan Carniato’s stream](https://www.youtube.com/watch?v=3vw6EAmruEU) talking about scheduling and demoing using modern React features
-
-Mark: So, sort of on on that note, Ryan Carniato from the solid team routinely does streams where he talks about what he's working on or you, where the ecosystem is going. He and Ricky have had a number of like, actually. Intentional and productive discussions back and forth on Blue Sky and Twitter where Ryan has said, we've got our own version of suspense, we've got our own version of transitions. [27:54]
-
-We're trying to do things this way. And Ricky has put up a demo and said, how does this, here's the React way to do this. How's this compare to the way you guys are doing it? And so Ricky was actually just on Ryan Carniatos stream on Friday and I looked, and it's a six hour long video. No, I most definitely did not watch the video. [28:17]
-
-I cheated and used a summarizing tool to try to gimme a sense of what they were actually talking about. But it looked like they talked about where React has gone and what has changed with all the different concurrency related features. And then I think they tried to take a sort of a classic react. I think it was like a React 17 to do application, and then they updated it live on stream to use all the modern latest React features. [28:38]
-
-So if you want to watch them talking about this for six hours, the video's there. But it's a good example of people who know how this, how these technologies are implemented, discussing them as well as Ricky demoing how you could actually use these in an application. [29:06]
-
-Carl: Yeah. I will say, going back to a point a little bit about, you know, you shared the long thread and made an offhand comment about like, this could really be a blog post at this point. [29:23]
-
-Like the post on Ricky's feed right before that is the, if you all promise not to ask me for docs or blog posts, maybe I'll explain a bit about why creating a cache API for suspense is so hard and it's, oh, I love that you're doing all of this, like social media outreach and everything, but like part of the problem that, part of the reason why nobody understands all of this and you have to do all the social media outreach is because there aren't static available resources for people to read. [29:31]
-
-So it's like, ah, I love that this is happening and it's so good and so helpful. And there's follow up that's not happening that I think is really crucially important. [29:55]
-
-Mark: That's actually been one of my running frustrations and complaints for a while. Ricky and I have actually had some back and forth on this, multiple times on Blue Sky. [30:03]
-
-Yeah. Admittedly, I'm also not sitting here, honestly. I should probably start watching the docs repos so I have a better sense of what updates do happen. That one's on me, but to a certain extent, my, my knowledge of what's in the docs can get a little stale. Right. But Ricky has repeatedly complained that. [30:12]
-
-People keep making the same wrong assumptions about what React has available, why the React team is doing things, et cetera. I've pushed them multiple times this year and said, you know, my answer is go write a docs page. Yeah. That covers exactly the topic you want and to have answered, and it answers it in exactly the way you want This material covered. [30:29]
-
-A lot of people are still not gonna read that docs page, but some people who are already looking at the docs will see it. And when you run into yet another one of these questions on social media, now you have the pre-written answer and you link to it rather than having to answer it from scratch every time you see the same misconception pop up on social media. [30:55]
-
-I, I wanna be clear, I, I am genuinely excited that Ricky has done so much outreach over the last year or so. Even just in the last couple weeks he was, he wrote dozens of tweets on both Blue Sky and Twitter around the threads related to the React innovation by default discussion. And I'm genuinely happy he's doing this much outreach. [31:18]
-
-It's sort of taking Dan's place in that sense. But when your great answers are buried, 15 replies deep in a Twitter thread, no one sees them other than the person you're responding to. And that is the kind of material that desperately ought to be its own blog post, as well as these couple top level threats as well. [31:40]
-
-And so I genuinely happy he's engaging. I would just love to see that material written up longer term. [32:03]
-
-Carl: This is clearly a bit of a cycle, you know, like social, this has been true for years generally. So like maybe this is an opportunity for someone here listening to go through some of the, to go through these threads. [32:09]
-
-Like if you're champing at the bit for an opportunity to have an impact on the ecosystem and on the industry, like this could be a pretty achievable way to do so. Like this content is out there, it exists, but not in a way that's discoverable. So like taking this knowledge that is being produced in ephemeral social media threads and then just like restructuring it, reformatting it into a markdown document and submitting a PR to react could be really effective. [32:24]
-
-I, I'll throw that gauntlet down, like that is an achievable thing that I am probably not gonna do. [32:52]
-
-Mark: People used to say that the real React docs was Dan Abramov's Twitter account, which he then deleted and all that info is gone. I don't expect blue sky to go down, but yeah, like if someone out there wanted to go through some of, you know, Dan and Ricky and whoever else's Blue Sky threads and pull out info and submit docs, prs like that would genuinely help the entire ecosystem. [32:58]
-
-Carl: Yep. Right. And it doesn't need to be perfect first. Drafts are so good. First, the first draft is so hard and going from first draft to published thing is still a lot of work. But man, just getting a first draft out is often the thing that tips it over the edge into actually happening. Yep. I'll just say that if anyone's looking for something. [33:20]
-
-Mark: Love the idea. Alright, moving right along. [33:38]
-
-## Server Components
-
-Mark: A few different updates related to server components this month. [33:41]
-
-## [React Router RSC framework mode preview](https://remix.run/blog/rsc-framework-mode-preview)
-
-Mark: The biggest would be that React Router now has RSC support in their framework mode builds. So React Router, as I understand it now, has three different modes. There's sort of the, the traditional client side only, here's your list of routes mode, there's a somewhat more complicated data mode, and then there's the full blown full build framework mode. [33:44]
-
-And so I believe they previously announced some RSC primitives available in data mode. And then I believe the framework mode is now taking those and expanding on them somehow to make it available for the full build. So, you know, again, having more RSC options available besides just next is a pretty big deal. [34:09]
-
-And especially when it's built into something as widely used as React router. [34:30]
-
-Carl: Yep. Love that. [34:34]
-
-## also [middleware is now stable](https://remix.run/blog/middleware)
-
-Mark: They also announced that React router now has stable middleware support as well. Your routes can now have middleware. [34:36]
-
-## Krasimir Tsonev’s [“Can I Use RSC Today?” support matrix](https://rsc.krasimirtsonev.com/) and experimental [Forket “RSC without a framework” build tool](https://krasimirtsonev.com/blog/article/vanilla-react-server-components-with-no-framework)
-
-Mark: Krasimir Tsonev, who is a React educator and has been around for a while, put up a nifty little support matrix called, can I use RSC today, where he tried to do equivalent bits of RSC usage and features across several different tools from next in, in Remix and Waku and various other tools. [34:44]
-
-He was also very curious. I, I actually talked to him at React Summit in, in June, and I think this is what. And he was talking to a couple other folks, and I think this is what spawned him doing that deep dive where he was actually kind of bothered by the fact that server components require a framework. [35:07]
-
-And so he went off and ended up implementing his own tool called for cat. Which is supposed to be somehow a proof of concept for using an RFC without an actual framework per se. So sort of a more primitive, granular client server separation build tool. [35:24]
-
-## [RSBuild support for RSCs](https://bsky.app/profile/ebey.bsky.social/post/3lyf6vixick26)
-
-Mark: Speaking of build tools, I saw mention that there is a set of plugins available that try to add some RSC support to the RS build, rust based bundler as well. [35:43]
-
-## Useful post on [parallel and recursive route rendering](https://twofoldframework.com/blog/parallel-and-recursive-route-rendering-with-rsc)
-
-Mark: Finally, I also saw a good blog post that talked about techniques for doing parallel and recursive route rendering with RSCs. As Carl mentioned earlier, all this stuff is frankly outside of my experience, I've never tried to render, you know, RSCs much less do parallel and recursive stuff, but it clearly, people are out there experimenting with these things and that's good. [35:55]
-
-Carl: Oh man. I'm looking at the blog post. You mentioned React server components without a framework and it's got a mention of Flux. Oh, throwback. Yeah. I mean we're Reactiflux because for about a six or eight months it was React and then you pair it with Flux and that was how you do UI and state management. [36:15]
-
-So it's wow, throwback. That's a long time. [36:33]
-
-## All the NPM compromises and malware this month
-
-Carl: Alright, little bit of a roundup on. Vulnerabilities and security incidents on MPM. There's been a lot this month. [36:35]
-
-Mark: I think that the first one happened late last month, and we mentioned it briefly. Yeah. And then there was just like this constant flood of new compromises, new vulnerabilities, all kinds of packages being taken over, ranging from crypto miners to like full-blown credential stealing. [36:44]
-
-It's, it's been pretty bad out there folks. [37:02]
-
-Carl: Right? So last month. NX was compromised, which is discussed in this set of links that we have here. I'll send one at a time as we get into it, but yeah, so it, what we've seen has been everything from like pretty, there was a targeted attack that would do like intercede, crypto payments and sub out addresses for, you know, an attacker's wallet actually that had a small innovation in that category of attack where it would generate an address that was visually similar to the one that you had used to try and escape. Notice I heard that attack only got like $50 or like less than $500. I've seen some conflicting numbers, but like generally not effective, did not achieve its goals. [37:04]
-
-But like it hit debug. Like it hit a package that I saw the security alert go out and I was like, oh, that sounds like something that I might use. And I checked. I'm like, yep, a bunch of projects on my computer were using that package. That was the one that got targeted with crypto interception, but previously, I think it was nx, was it last month, that we had the people who were stealing credentials and using AI to generate other code to steal credentials. [37:50]
-
-Like, ah, that's the worst attack I've ever seen. And the only reason it wasn't worse was because of the limited scope of compromise. So like I was primed seeing that innovative, highly effective attack when I saw this massively widely distributed compromise of debug. And I have a little bit of egg on my face regarding this because I had pinged in the node Discord that I help operate saying like, oh, you need to look at this. This is awful. And it ended up not being as bad as I thought because that was a crypto miner, not a credential stealer. [38:19]
-
-Mark: The attack itself seemed like a pretty big deal, and then it was almost sort of wasted on, well, it has to lead to you accidentally build a client side app that has the compromised version built into it. [38:54]
-
-Carl: Right, they managed to successfully target one of the single most widely used packages. And completely squandered it by using it to execute an attack that had such limited application that they just didn't get anything. So like that's just straight up, like they screwed up, like they achieved a massive level of success and just like immediately fell on their face and did nothing with it. [39:08]
-
-That's just a miss. Like that was just luck, that it wasn't worse than it was. [39:34]
-
-Mark: But on the, on the flip side, the article that's talking about the ongoing supply chain attack did do a bunch of credential stealing, targeting a bunch of packages like [39:38]
-
-## [npm package maintainer Qix](https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack)
-
-Mark: tiny color and a [39:47]
-
-## [CrowdStrike npm Packages](https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages)
-
-Mark: bunch of CrowdStrike packages. Yeah. I don't know the extent of like what sites got hit because of that compromise. [39:48]
-
-Yeah. But I believe that one's, that one had did a, done a pretty good job of finding credentials and publishing them on either, I think it was like either creating a new GitHub repo or creating a new specially named branch in GitHub repos to try to exfiltrate the credentials. [39:57]
-
-Carl: Yeah. Oh, I was just reading this one actually. [40:14]
-
-## [GitHub Actions npm Token Theft](https://socket.dev/blog/nx-supply-chain-attack-investigation-github-actions-workflow-exploit)
-
-Carl: It was, they had, they, somebody had added a line to the GitHub action that did, that would echo out the title of the PR and because it just did an un escaped string, you know, echo this. You could just terminate that and then run whatever you wanted. On the GitHub action, like, do not let any arbitrary person run whatever script they want in your seat. [40:16]
-
-Like, oh man, that it's, that's pretty bad. And also, oof, this is CrowdStrike. Like, remember CrowdStrike and how they took down like every, like air travel around the world from another security problem that they had, and oops, they're a cybersecurity company where preventing attacks is their job. Oops. Yeah. [40:38]
-
-I don't understand how they're still operating successfully. [40:57]
-
-## [GitHub response](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/)
-
-Mark: So, GitHub and NPM did actually put up a, a, an announcement saying that they're gonna be doing a lot of work to try to tighten up. Publishing of packages down the road, they're gonna be making changes to two fa it says they're gonna deprecate time-based passwords. [41:01]
-
-That sounds like it's gonna end up being a, a big deal. I don't fully understand the implications yet. And, and they said they're gonna, you know, take time to roll these changes out. But that one seems like a big deal. We're also making and trying to apply more limits to tokens and work on better trusted pet publishing workflows as well. [41:20]
-
-Interesting. [41:40]
-
-Carl: Yeah. That's all important and useful, but like also, I don't know if there, if you just, if somebody opens a PR to your CI, that adds. A vulnerable un escaped string. Like it doesn't really matter how, what your authentication or publishing workflow looks like if that gets merged. Like you're vulnerable. [41:41]
-
-So dunno how, dunno what you do about that specifically. But, okay. [41:56]
-
-## ⚡ Lightning round ⚡
-
-Carl: Let's hop into our lightning round. [42:00]
-
-## [Porting Modern TypeScript to Run on DOS](https://jimb.ly/2025/09/23/qauntumpulse-from-steam-to-floppy/)
-
-Mark: I love a good article that just goes into absurd amounts of detail on a ridiculous thing that someone's trying to do, but they commit to the bit fully. And this one was, someone had a. JavaScript based game and they ported it all the way back to work on dos. [42:03]
-
-Like why would you want to, I don't know, but apparently they actually made this work and I love it. [42:21]
-
-Carl: That is insanity, and I also love it spiritually similar to Doom running in TypeScript types, just for no reason. Yep. Love. [42:27]
-
-## [Cloudflare DDOSed themselves with a bad `useEffect` fetch](https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/?amp%253But)
-
-Mark: CloudFlare got into the news this month because they had a dashboard failure that cascaded, and believe it or not, it was caused by manually fetching data in a use effect that went into an infinite loop, which also means they weren't actually using like React query or anything like that. [42:35]
-
-Oops. [42:55]
-
-Carl: Yeah, I did hear like none of their services were affected. It was just the control panels that was taken down, so that's good. I also saw Guillermo Roush throwing some shade at the CloudFlare CEO after that. So, you know, drama post. [42:56]
-
-## [A very lovely writeup of the evolution of css `zoom`](https://www.bocoup.com/blog/the-webs-most-tolerated-feature)
-
-Carl: There's a cute post from Bocoup. There are web consultancy that's had a, a big impact on standards and web platform implementation details. [43:11]
-
-So they, they've heard a cute blog post, the web's most tolerated feature looking into Zoom and how Zoom works. And it is kind, it's kind of cute. I don't know, just like it's a fun look at standards and like how. Cross browser implementation stuff works and how like, oh actually this like totally unstandardized thing just happens to work really well and everyone uses it. [43:21]
-
-So, I don't know. It's cute. It's a cute post from people who are deeply involved in the standardization and implementation process, highlighting a case where like standards like just kind of didn't happen and it was fine. [43:44]
-
-## [What You Need to Know about Modern CSS](https://frontendmasters.com/blog/what-you-need-to-know-about-modern-css-2025-edition/)
-
-Carl: Anyway, yeah, there was another good post from front end Masters who I, I've just always had a soft spot in my heart for front end masters because they were, that's the first platform that I learned react from. [43:56]
-
-It was like a comparative class of Angular React and Ember, and I was like, oh, react seems nice. So like I owe them a debt to, you know, my entire career. So that's, it's cool. It's nice to see 'em still around and still staying on the ball. They published a post What you Need to Know about Modern CSS 2025 edition. [44:09]
-
-Mark: And it was long too. It was long. [44:26]
-
-Carl: It's big and I appreciate that because I've gone to a couple of conferences and I've seen talk from various people who are more, who work on CSS a little bit more. Una Kravets, I think is who I'm most specifically thinking of, who's wonderful and great and a great speaker. [44:28]
-
-But like I'll see her talk about some CSS stuff and be like, wow, all of this is stuff that I've never heard of and CSS is completely different than what I've used in a lot of my career. That's awesome. And I don't know what to do about that. So this is a great post for me in that situation and going, ah, I need to catch up on like the last six years of stuff that I haven't really paid close attention to as it evolves step by step. [44:44]
-
-So, great summary. [45:09]
-
-Mark: We have a few different posts on browser behavior. So there was I and all from folks who have worked on browsers for a long time, I might add. [45:10]
-
-## [Fetch streams are great, but not for measuring upload/download progress](https://jakearchibald.com/2025/fetch-streams-not-for-progress/)
-
-Mark: Jake Archibald did one on fetch streams are great, but don't use them for measuring upload download progress points out that you still basically need to use XHR for that instead. [45:21]
-
-Although there's discussion of adding some new options and callbacks to fetch that might accurately handle that at some point. [45:33]
-
-## [Why do browsers throttle JS timers?](https://nolanlawson.com/2025/08/31/why-do-browsers-throttle-javascript-timers/)
-
-Mark: There was one from Nolan Lawson talking about why do browsers throttle JS timers? So you know, why does that time timeout zero actually be, why is it more like four milliseconds, et cetera? [45:40]
-
-And basically it's because people rate bad code or either intentionally or unintentionally that can do bad things. [45:53]
-
-## [“How Modern Browsers Work” deep dive, Addy Osmani](https://addyo.substack.com/p/how-modern-browsers-work)
-
-Mark: And then Addy Osmani did a pretty long post a, mid-level overview of how modern browsers work overall, going from, you know, parsing JavaScript in HTML in various ways to using GPUs to put pixels on the page. [46:01]
-
-Carl: Yeah, it's funny to me to see, I don't know, I've just been seeing Addy Osmani and Nolan Lawson and Jake Archibald for so long. It's like, man, how great for them to stay on the top of the game for so long. It's great. [46:18]
-
-## [Biome: Stress-testing WIP `noFloatingPromises` lint rule](https://vercel.com/blog/stress-testing-biomes-nofloatingpromises-lint-rule)
-
-Carl: One that I like here. I like seeing Vercel and Biome collaborated on stress testing, biomes new, no floating promises lint rule. [46:32]
-
-I, again, have a soft spot in my heart For Biome, I was a initial backer of Rome back in the day, which was then forked after some maintainer shenanigans into Biome. They never really achieved the original vision, or have not yet at least, which was like unified, like linting compiling, you know, one tool to rule them all kind of thing. [46:41]
-
-That it was called Rome because all paths, all roads lead to Rome, so it was trying to do all of it. They have achieved a lot of their goals, but not quite enough to really meaningfully claim to do all of it. [47:02]
-
-Mark: It's become a pretty solid, a pretty solid formatter, but they never really managed to get into any of the multi tools sharing one a ST side. [47:15]
-
-Carl: Yeah, right. Oh, that was it. It was because you know, you, you would have like Babel and ES lint and TypeScript and prettier and all of those, and all of them were independently parsing ASTs and then operating on. So like that's just a lot of wasted effort. So the, the goal was, the original goal was like one AST, all of this stuff talking to that will be an order of magnitude performance improvement. [47:23]
-
-Mark: Mm-hmm. [47:44]
-
-Carl: But anyway, so enough background, they have a new no floating promises rule because if you don't await or you know, respond to a promise, it can cause all sorts of super weird stuff. They say that, you know, a lot of engineers have campfire stories of floating promises taking down production, which is definitely true. [47:44]
-
-I've definitely, a lot of the weirdest errors I've ever encountered track back to, oh, we didn't correctly wait for this promise to resolve, so this is it. This is a fun, deep dive technical writeup of how do you detect that promise. Has not been waited for. What does it even mean to return a promise when TypeScript has a built-in promise? [48:02]
-
-Like construct? It's a good read. It's a good deep dive. [48:23]
-
-Mark: I should point out that the article was written by Dmitri Metropolis, who just got done organizing Squiggle conf and is also the person who did Doom in Typescripts. [48:27]
-
-Carl: Oh, it is, Love Dmitri. Love that. [48:34]
-
-## [Bun: How `bun install` is so fast](https://bun.com/blog/behind-the-scenes-of-bun-install)
-
-Carl: There is a good deep dive here into Bun Install and how it's so fast. [48:37]
-
-They say on average it runs seven times faster than MPM and 17 fast times faster than you yarn. It's a large post and it's got a lot of real deep benchmark stuff. Mm-hmm. [48:43]
-
-Mark: I think Lydia Halley wrote that one actually very well written post. Lot of detail. [48:53]
-
-Carl: Wait, was she on React? [48:58]
-
-Mark: I believe she was working for Vercel and left, and I think she actually just joined Bun as a DevRel. [49:00]
-
-Carl: Great. I'm just always here for like a deep technical dive. So many, so many blog posts are just a little bit more surface level, so seeing something more like a white paper, a technical writeup, I just love I, it's such a good window into the real challenges that different people around our industries are encountering [49:06]
-
-## [Styled-Components fork for perf and React 19 compat](https://www.sanity.io/blog/cut-styled-components-into-pieces-this-is-our-last-resort)
-
-Mark: for folks who are still using style components, the sanity company actually forked the existing now unmaintained library and made a couple major updates. [49:23]
-
-One, to try to optimize the overall performance and another to try to provide React 19 compat. They say they are not maintaining these forks per se, but they have done the work because they themselves still relied on it. And so they've made those, they've published those so that other people can benefit from it. [49:35]
-
-So if you're still work, still using style components, you may want to take a look at that. [49:57]
-
-## [Vite SSR: Custom `getStaticProps`](https://www.patron.com/blog/post/vite-ssr-getstaticprops-replacement/)
-
-Mark: Also saw a nice little post that talked about building your own get static props alike equivalent if you're using Vite for SSR. [50:02]
-
-## [Dominic Gannaway’s new framework Ripple](https://github.com/trueadm/ripple)
-
-Mark: And in the frameworks that are not actually React, but related category. Dominic Getaway, who originally created a React Delight called Inferno and was on the React team for a while, has built his a new independent framework called Ripple, which tries to pull together some new ideas around template compilation and use of JS syntax, but in a way that's different than React. [50:11]
-
-## [Remix v3: MJ hints “iframe-like async primitives”](https://x.com/mjackson/status/1971816432427298951)
-
-Mark: And then Michael Jackson and Ryan Florence continue to drop assorted hints online about what their Remix version three is going to look like. Michael's latest tweets are saying, what if he could just sort of use iframes or iframe like behavior for async loading? And I really just want to see the actual examples at this point, but they're dropping hints about what it'll be like. [50:35]
-
-And oh, the plan is to actually show stuff off at Remix Jam, which I think is coming up next month. [51:00]
-
-Carl: Yep. I am skeptical. I don't know, I, I appreciate the broad strokes of iframe, but the actual security constraints of using iframes is, that's just not, they're not good. It's not pleasant. It's not, you know, that's very like 2003 era web development and we stopped doing that because it kind of sucked. [51:07]
-
-It was hard to make good experiences. If it's not literally in I frames, that's very different. So maybe it'll be better than that. There's an argument to be made that what he is talking about shares significant overlap with the islands style micro front ends. So, I'm not checked out. I'm curious, but I'm skeptical. [51:27]
-
-Unfortunately. It sounds like Mo's having like significant internet challenges in his office right now. So I'm gonna, I'm gonna pull in some of the stuff that would've been, you know, that he wanted to talk about. [51:49]
-
-## [React Native RFC to remove Old Architecture](https://github.com/react-native-community/discussions-and-proposals/pull/929)
-
-Carl: There's been a RFC for React native, for a plan for actually removing the old architecture, the previous way of serializing communication between the JavaScript engine and the native layer. [51:57]
-
-So it's not only, not only is the new architecture default, they are now proactively communi or they're proactively planning how to get rid of the old architecture entirely. Well, that's great. That feels like a big step towards 1.0, like we were talking about before. [52:13]
-
-## [Cloudflare’s new “Cap’n Web” RPC; GraphQL alternative?](https://blog.cloudflare.com/capnweb-javascript-rpc-library/)
-
-Mark: So CloudFlare announced a new tool called Cap'n Web, which is a RPC system meant for browsers and web servers. [52:28]
-
-And this was created by the same person who, by Ken and Varta, who had created a couple other serialization libraries, one called Capin Proto, and Capin. Proto works with both c plus plus and JavaScript and possibly a couple other languages. And Capin proto is sort of a follow on that's specifically meant for use with web and can be sent back and forth using just plain JSON. [52:38]
-
-I believe the article actually kind of pitches it sort of as an alternative to GraphQL in a way. It actually does a funky little thing where if you make what looks like an initial request for an item and then you get back a promise for that response, you can call map on the promise and. Essentially map over what will be the list of items and say, for example, gimme details on all the child items by their id, but then it'll actually get batched up into a single request. [53:05]
-
-So there's some technical trickery going on there, but it sounds like it's meant to simplify both making a request back and forth and managing the overhead of what would've potentially been many independent requests as well. Thus, the comparison to like a GraphQL style thing. [53:42]
-
-Carl: Interesting. And also, I'll shout out. [53:59]
-
-You know, Cap'n Proto here is spiritually very similar to the challenge, it's solving a problem that's spiritually very similar to the new architecture and React Native, like basically, you know, this RPC is going instead of going across like a native JavaScript layer, like a new React native, this is how do you do a similar type of communication between systems across the network boundary? [54:02]
-
-And the challenge is like the reason you would use something like Cap'n Proto or Protocol Buffers, which you know, there's kind of competitors there is because the serialization costs and the volume of communication if you're using JSON, is just much higher, like converting it into a string. It's basically a string versus a binary data format. [54:25]
-
-Like the, one of the problems with JS is that you're encoding not just the data, but also the structure. You're saying, here's the object, here's the keys, here's what it looks like. And that's. That's information. You know, if you're sending that information across the wire, that's extra effort. If you already have two, two agents on opposite ends of a network and they say, we agree that our communication is in this format, then you don't need to send the format across the wire. [54:46]
-
-So that's the fundamental like reason why you might use one of these tools instead of just sending JSON over HTTP and yeah, it's interesting. This is, it's pretty cool. [55:16]
-
-## [Expo UI: Building SwiftUI apps](https://docs.expo.dev/guides/expo-ui-swift-ui/)
-
-Carl: Cool. The Expo had an interesting post talking about using Swift UI in React Native, so that, that's pretty cool. Like being able to directly, if you're in, only, if you're only targeting a native environment, being able to. [55:26]
-
-Exclusively use native primitives is like a huge win. Like if you don't, you know, it's always good to remove compatibility layers if you don't need the compatibility. So that's really cool. It's it, this looks pretty interesting if you're doing stuff on Mac Os or like Apple TV or things like that. [55:40]
-
-## [TanStack DB: An interactive guide](https://frontendatscale.com/blog/tanstack-db/)
-
-Mark: So the TanStack folks recently announced a new package called TanStack DB, which is supposed to be a smart syncing layer on top of TanStack Query that can do things like in-memory filtering and querying of data very efficiently. [55:57]
-
-And so there was a neat post that was an interactive guide to TanStack db and discussing some of the options and some of the things you can do with it. [56:13]
-
-## [TS 6.0: may switch to `strict` options by default](https://github.com/microsoft/TypeScript/issues/62333)
-
-Carl: TypeScript version six may switch to strict options by default. This is, [56:21]
-
-Mark: hallelujah. [56:27]
-
-Carl: Yeah, right. What a long time coming. Like I have treated this as a deep, you know, this has been step one of setting up a new TypeScript project for me since I've started using TypeScript. 'cause it's always been the best practice. So I love that they are discussing, switching this over. Yeah. It starts almost a decade ago. We began to add certain options beyond, no implicit any in strict no checks. So, yeah, like almost a decade ago. So that's the, that's cool. TypeScript 6.0 will assume that dash dash strict is on unless explicitly disabled, which means specific settings like strict no checks and no implicit any will be enabled unless it's turned off explicitly. [56:28]
-
-Woo. Cool. No implicit any is if you don't turn that off, like you're not really using Patrick, like it's just sparkling JavaScript. So that cool. Love that. Love to see this. [57:05]
-
-Mark: There's a lot of debates over the nuances of what that concept of turning on strict by default actually means. But I would assume that something along those lines would land and yeah, it's way overdue. [57:16]
-
-## [Shopify’s RN New Architecture migration](https://shopify.engineering/react-native-new-architecture)
-
-Mark: Alright, last couple ones and then we're done with the not so lightning. Lightning round Shopify put up a post talking about their migration to the React native new architecture and went through both some pros and cons and pitfalls of what that process involved. [57:28]
-
-## [The Bloat of Edge-Case First Libraries](https://43081j.com/2025/09/bloat-of-edge-case-libraries)
-
-Mark: And then the last one is from James, who has the really funky username that I'm not even going to try to pronounce, but he's been working as part of the E 18 E ecosystem speed up process. [57:42]
-
-In fact, he's the person that I did a stream on a couple days ago where we talked about my work to make the Immer library faster. And his post looks at like, gives an example of, let's say you have a math clamp function that takes some arguments. But you don't want it to crash if someone does something stupid like passing in, you know, a string instead of a number and next thing you know, like two thirds of your function is just validating the inputs before it actually does anything. [57:54]
-
-And he argues that, you know what? This actually ends up being kind of a waste of space and execution time. And that to a certain extent, if someone passes in bad input, that's their problem and not your problem, which I can sort of get behind. [58:24]
-
-Carl: Yeah, interesting. That makes a lot of sense. It's kind of the right, it's a challenge between sharing code and doing it inline how when you start trying to do it inline, you end up re-implementing a lot. [58:40]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-Carl: Cool. Let's talk about some conferences. [58:51]
-
-## [React Alicante](https://reactalicante.es/) Oct 2-4
-
-Carl: We have in like three days, two days. React Alicante in Spain, October 2nd through fourth. [58:53]
-
-Mark: I will be speaking there. I'm flying out on Wednesday. [59:01]
-
-Carl: Woo. And then you're fly. And then you're flying [59:04]
-
-Mark: all the back and then flying all the way back across, across the world for to attend React Conf. [59:07]
-
-Carl: Yep. I'll be there too. [59:11]
-
-## [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
-
-Carl: So yeah, react Conf in Henderson, Nevada, right near Vegas. I'm actually gonna be driving from San Jose, so like if you're in the Bay Area a couple days before the React conf, lemme know. I don't know. I'm gonna go hiking, so, we'll, it's gonna be an adventure. [59:13]
-
-## [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
-
-Carl: Then a couple days after React Conf, Remix is doing their own conference in Toronto, the Remix Jam. [59:29]
-
-So yeah, maybe. We'll, we will see. It'll be interesting to see what they come out with. Yeah, I'm curious. Yeah. [59:37]
-
-## [ViteConf](https://viteconf.amsterdam/) Oct 9-10 Amsterdam, Netherlands
-
-Carl: Anyway, coincident with that, ViteConf is happening October 9th and 10th in Amsterdam. That'll be cool. [59:43]
-
-Love to see what they come out with. [59:50]
-
-## [JSConf North America](https://events.linuxfoundation.org/jsconf-north-america/) Oct 14-16 Chesapeake Bay, MD, USA
-
-Carl: JSConf is doing a couple of events all over the world actually, so they're doing JSConf North America October 14th through 16th in Chesapeake Bay, Maryland, [59:52]
-
-## [JSConf Chile](https://jsconf.cl/) Oct 24-25 Santiago, Chile
-
-Carl: and they're also doing re JSConf Chile, October 24th and 25th in Santiago, Chile. [01:00:03]
-
-## [React Native London](https://www.reactnativelondon.co.uk/) Oct 30-31
-
-Carl: We've also got, after that React Native London, October 30th and 31st, [01:00:10]
-
-Mark: and Mo runs that, so you should totally be there and support him [01:00:18]
-
-## [React India](https://www.reactindia.io/) Oct 31 Nov 1 Goa, India
-
-Carl: after that, there's React India October 31st and November 1st, [01:00:22]
-
-## [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
-
-Carl: and then the Wey Wey Web, I think I'm pronouncing that right. It says it's a yay, yay conference, international conference for ux. But yeah, that's happening in Malaga, Spain, November 17th and 18th. [01:00:26]
-
-## [React Summit](https://reactsummit.us/) Nov 18-21 New York, NY, USA
-
-Carl: And then we've got React Summit happening in New York, November 18th through 21st. [01:00:39]
-
-So that's cool. We'll see. Maybe I can make it to that. It's in my hometown, so Yeah, that'd be great. [01:00:43]
-
-## [React Advanced](https://reactadvanced.com/) Nov 28th, London UK
-
-Mark: And then React. React Advanced is November 28th, all and although it's uh, inconveniently the day after us Thanksgiving this year, they had done it in late October, previous years, and I think since they're not doing React Berlin, they bumped the schedule for React Advance to be sort of in the middle where those would've been. [01:00:48]
-
-## Outro
-
-Carl: That's everything we got for you this month. Thank you so much for joining us. We'll be back on the last Wednesday of the month probably, although we had to reschedule this month again, sorry. Or we will be back in your podcast feed just as soon as we can. We gather sources from, actually this month we pretty much only gathered sources from Reactive Fly. [01:01:08]
-
-It was a good month for, you know, us staying up to date. Yeah, generally we do subscribe to this week in React, which is a great source. Follow lots of people on Blue Sky and Twitter, the React JS subreddit and just, you know, generally all over the internet. We try and stay in touch. If you see anything that you think that we should be aware of, definitely post. [01:01:25]
-
-Actually, you should just post it to the Tech News and Reads channel here. I would love it if we could have some more chatter going on there and it really does help us stay on top of things and helps me understand it. If, you know, if you post a link and then you and somebody else have a conversation, I will read that and it will inform my opinion. [01:01:46]
-
-So yeah, it's a great way to do it. If this is a show that you get value from and wanna support, best way to do so is by reviewing us on whatever platform you listen to or tell your friends and coworkers about it. So, you know, send 'em a link. Cheers. Thanks so much for listening. [01:02:02]
diff --git a/src/transcripts/tmir-2025-10.md b/src/transcripts/tmir-2025-10.md
deleted file mode 100644
index 5773f74..0000000
--- a/src/transcripts/tmir-2025-10.md
+++ /dev/null
@@ -1,759 +0,0 @@
----
-title: "TMiR 2025-10: Post-conf; React 19.2, React Foundation, React Native removing old architecture. Next.js has too many directives"
-date: 2025-10-29
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down 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](#intro)] Intro
-- [[00:46](#new-releases)] New releases
- - [[00:49](#immer-102)] [Immer 10.2](https://github.com/immerjs/immer/releases/tag/v10.2.0)
- - [[01:55](#arktype-arkregex-typed-regex)] [ArkType ArkRegex](https://arktype.io/docs/blog/arkregex) (typed regex)
-- [[02:41](#main-content)] Main Content
- - [[02:45](#react-conf)] React Conf
- - [[02:50](#official-reactconf-2025-recap)] [Official ReactConf 2025 Recap](https://react.dev/blog/2025/10/16/react-conf-2025-recap)
- - [[02:57](#introducing-the-react-foundation-also-from-linux-foundation-meta-engineering-and-seth-webster)] [Introducing the React Foundation](https://react.dev/blog/2025/10/07/introducing-the-react-foundation) (also from [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-the-react-foundation), [Meta engineering](https://engineering.fb.com/2025/10/07/open-source/introducing-the-react-foundation-the-new-home-for-react-react-native/), and [Seth Webster](https://thenewstack.io/react-foundation-leader-on-whats-next-for-the-framework/))
- - [[17:03](#192-activity-useeffectevent)] 19.2 (Activity, useEffectEvent)
- - [[17:27](#react-native-news)] React Native news
- - [[17:32](#new-architecture-only-from-v082)] [New architecture only from v0.82](https://reactnative.dev/blog/2025/10/08/react-native-0.82#new-architecture-only)
- - [[18:52](#vega-os-announcement)] [Vega OS announcement](https://developer.amazon.com/apps-and-games/blogs/2025/09/announcing-vega-os)
- - [[19:04](#vega-introduction-at-react-conf)] [Vega introduction at React Conf](https://www.youtube.com/watch?v=p9OcztRyDl0&t=5737s)
- - [[22:36](#joe-savonas-exploring-react-performance-talk)] Joe Savona’s “[Exploring React Performance](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=20274s)” talk
- - [[23:26](#rickys-async-react-part-i-and-part-ii-repo)] Ricky’s “[Async React Part I](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=10907s)” and “[Part II](https://www.youtube.com/watch?v=p9OcztRyDl0&t=29073s)” ([repo](https://github.com/rickhanlonii/async-react))
- - [[27:12](#async-react-working-group)] [Async React Working Group](https://github.com/reactwg/async-react)
- - [[27:35](#first-discussion-of-more-docs-ideas)] First [discussion of more docs ideas](https://github.com/reactwg/async-react/discussions/2)
- - [[28:27](#remix-v3-announcement)] Remix v3 announcement
- - [[29:03](#announcement-demo-timestamped-breakdown)] [Announcement demo timestamped breakdown](https://github.com/markdalgleish/remix3-resources)
- - [[31:28](#updates-syntax-can-be-customized)] [Updates syntax can be customized?](https://x.com/sergiodxa/status/1976878377509568871)
- - [[34:44](#i-built-the-same-app-10-times-code)] [I built the same app 10 times](https://www.lorenstew.art/blog/10-kanban-boards) ([code](https://github.com/lorenseanstewart/kanban-comparison))
- - [[37:57](#same-author-as-react-won-by-default-and-its-killing-innovation)] Same author as [React Won by Default and It’s Killing Innovation](https://www.lorenstew.art/blog/react-won-by-default/)
- - [[43:33](#solito-5)] [Solito 5](https://solito.dev/v5)
- - [[46:49](#next-16-and-directives-debate)] Next 16 and Directives debate
- - [[46:56](#next-16-released)] [Next 16 released](https://nextjs.org/blog/next-16)
- - [[49:41](#directives-and-the-platform-boundary)] [Directives and the Platform Boundary](https://tanstack.com/blog/directives-and-the-platform-boundary)
- - [[50:34](#technical-critique-of-next-app-router-everyone-hates-nextjs)] Technical critique of Next App Router: [Everyone Hates Next.js](https://paperclover.net/blog/webdev/everyone-hates-nextjs)
-- [[54:56](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[54:58](#viteconf-roundup)] [ViteConf roundup](https://voidzero.dev/posts/whats-new-viteconf-2025)
- - [[55:49](#aws-outage-postmortem)] [AWS Outage Postmortem](https://aws.amazon.com/message/101925/)
- - [[57:10](#voltra)] [Voltra](https://x.com/saul_sharma/status/1972161677165473980)
- - [[58:10](#building-fully-native-apps-with-eas)] [Building fully native apps with EAS](https://blog.swmansion.com/building-fully-native-ios-apps-with-expo-eas-760b5480d7c5)
- - [[58:52](#react-native-imgui)] [React Native \\\<\\\> Imgui](https://x.com/tmikov/status/1979771014340047088)
- - [[59:53](#lodash-maintenance-foundation)] [Lodash maintenance foundation](https://blog.ulisesgascon.com/the-future-of-lodash)
- - [[01:00:45](#build-your-own-key-value-database)] [Build Your Own Key-Value Database](https://www.nan.fyi/database)
- - [[01:02:24](#jared-palmer-asking-for-gh-pr-suggestions-and-giving-some-technical-details)] [Jared Palmer asking for GH PR suggestions](https://x.com/jaredpalmer/status/1979204222420664405) and giving [some technical details](https://x.com/jaredpalmer/status/1980619222918262842)
- - [[01:03:54](#node-25-with-jsonstringify-improvements)] [Node 25 with JSON.stringify improvements](https://nodejs.org/en/blog/release/v25.0.0)
- - [[01:04:15](#cloudflare-vs-vercel-cpu-benchmarks-and-perf-optimizations)] [Cloudflare vs Vercel CPU benchmarks and perf optimizations](https://blog.cloudflare.com/unpacking-cloudflare-workers-cpu-performance-benchmarks/)
- - [[01:05:07](#ff-interop-feature-request-rankings)] [FF Interop Feature Request Rankings](https://interop-rank.jakearchibald.com/)
- - [[01:05:53](#vjeuxs-history-of-prettier)] [Vjeux’s History of Prettier](https://blog.vjeux.com/2025/javascript/birth-of-prettier.html)
-- [[01:10:41](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:10:43](#react-native-london-nov-13-14-london-uk)] [React Native London](http://reactnativelondon.co.uk) Nov 13-14 London, UK
- - [[01:11:26](#use-code-tmir10-to-get-10-off)] Use code \`TMIR10\` to get 10% off
- - [[01:11:42](#wey-wey-web-nov-17-18-malaga-spain)] [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
- - [[01:11:49](#react-summit-nov-18-21-new-york-ny-usa)] [React Summit](https://reactsummit.us/) Nov 18, 21 New York, NY, USA
- - [[01:12:10](#react-advanced-nov-28-london-england)] [React Advanced](https://reactadvanced.com/) Nov 28, London, England
- - [[01:12:33](#react-paris-cfp-is-open)] [React Paris](https://react.paris/) CFP is open
-- [[01:12:49](#ending)] Ending
-
-# This Month in React - October 2025 (SM)
-
-## Intro
-
-**Carl:** Hello everyone. Thank you for joining us for the October edition of This Month in React. As we recap what's going on with React, React native in the web, we're coming to you live from React Flux, the place for professional developers using React. [00:00]
-
-I'm Carl. I'm a staff staff product developer and freelance community leader here at React Flux, where I run community programs like these events and build tools to help keep the community operating. [00:12]
-
-**Mark:** Hi, I'm Mark. My day job is at Replay.io and in my copious amounts of spare time, I maintain Redux and rewrite Immer. [00:23]
-
-**Mo:** I am Mo, I head the mobile team at Theo. I'm an active part of the React native ecosystem and community, and I organize the React Native London Meetups and conference, which is coming up in two weeks. [00:30]
-
-Terrifyingly so. [00:42]
-
-**Carl:** Coming right up. Yeah. And you got a shout out that we're gonna talk about. [00:43]
-
-## New releases
-
-**Carl:** Let's start with some new releases. Mark, tell us about Immer. [00:46]
-
-## [Immer 10.2](https://github.com/immerjs/immer/releases/tag/v10.2.0)
-
-**Mark:** Okay, I can, I can do both these things. So I actually take very full credit for this one. So to be clear, I do not maintain the Immer immutable update library that is Michelle West Rate, who created it and has maintained it all the easier years. [00:49]
-
-However, since the start of September, I have sunk a stupid amount of time, something like 120 plus hours into trying to rewrite the internals of Immer for faster performance after some re users filed complaints to the Redux repos, that it was kind of slow. So I filed a few different prs, one to make some relatively small tweaks, and then a couple larger architectural changes. [01:01]
-
-And Michelle just merged and released Immer 10.2 with the small options. And we are hoping to land the larger architectural changes in the near future. And those will probably come out as Immer version 11, hopefully in the next few weeks or something. So I'm excited faster for performance free upgrades. [01:26]
-
-Yeah, should be. [01:45]
-
-**Carl:** Yeah, love some big core performance improvements of deep packages. That's awesome. [01:46]
-
-**Mark:** And I will also hopefully turn this into a conference talk. Nice. [01:51]
-
-## [ArkType ArkRegex](https://arktype.io/docs/blog/arkregex) (typed regex)
-
-**Mark:** Along with that, I, I just saw the announcement, I think like yesterday, that the author of the ARC type validation Library, which is a, a competitor to Zod that takes a, a rather different API approach, just released a, a similar tool called ARC RegX. [01:55]
-
-It's a function that is supposed to be a replacement for defining regular expressions in JavaScript, but it actually parses the RegX string into TypeScript types so that it can both. Interpret at the type level, what the regular expression is doing, and also even provide syntax errors if the reg itself is invalid. [02:12]
-
-Just looking at the docs, my mind is blown. [02:38]
-
-## Main Content
-
-**Carl:** Well, yeah, other than new releases, we have a bunch of main content this month. [02:41]
-
-## React Conf
-
-**Carl:** The React conf happened, what, three weeks ago, and a bunch of new stuff came out of there. [02:45]
-
-## [Official ReactConf 2025 Recap](https://react.dev/blog/2025/10/16/react-conf-2025-recap)
-
-**Carl:** They did put up an official recap blog post from it on the 16th, about a week after the event happened. [02:50]
-
-## [Introducing the React Foundation](https://react.dev/blog/2025/10/07/introducing-the-react-foundation) (also from [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-the-react-foundation), [Meta engineering](https://engineering.fb.com/2025/10/07/open-source/introducing-the-react-foundation-the-new-home-for-react-react-native/), and [Seth Webster](https://thenewstack.io/react-foundation-leader-on-whats-next-for-the-framework/))
-
-**Carl:** The big takeaway here, I think, well, I don't know, we got a couple of big takeaways, but one of the headlines is definitely the React Foundation. This is a pretty big change to, or this sounds like it will be a moderately large change to the governance of React. They're pretty light on details of the actual governance, so far. They have talked about like a new technical steering committee. But they also say that the governance of that is not finalized. The members are not finalized, but they do have the founding members of the founding sponsors basically of this foundation, which are Amazon Call Stack, Expo, Meta, Microsoft Software Mansion, and Vercel with Seth Webster. [02:57]
-
-Seth Webster is executive director and he's the what manager of the React core team, [03:39]
-
-**Mark:** Basically. Yes. [03:44]
-
-**Carl:** Yeah, so that makes sense. He is basically already doing that role and expanding what the core team means to an intercompany organization. But yeah, it's a lot of the details that I was most curious about, like what does, what does this mean for governance? Like how will decisions be made are not yet answered right now from the, from the various posts on this. A quote is, the React team is actively working on this new technical governance structure, and we'll share more details in a future post. So this is an announcement of a future announcement in some ways, but it's pretty real. [03:46]
-
-So this is in collaboration with the Open JS Foundation, which is a partner to the Linux Foundation. So like th these are very large, pretty well-founded organizations that the React team is glomming onto in support of like a neutral home for React, as they call it. [04:19]
-
-It's sounds like they're in incorporating React Native into this as well, which I think is not necessarily a given. You know, if you're talking about the governance of React, what that means for React Native is not necessarily implied. But just looking at the founding members like Amazon, Call Stack, Software Mansion, and Expo, and I guess Microsoft too, like those are all heavy React native investors. [04:38]
-
-**Mo:** I think it's quite surprising in that sense because it's more heavy on the React native side. Like Vercel is really the key sort of non-react native player. The rest are really heavy on React Native and there's like noticeably missing membership from like Shopify on the Remix side as an example. I, I actually find it's very skewed towards React Native, almost shockingly. [05:01]
-
-**Carl:** Yeah, I'd agree with that. It's, it is almost shockingly skewed towards React. React Native, given that it was not really pitched as the React Native foundation. That's true. I guess Software Mansion does do a fair amount of web React work. But I, I believe Call Stack is predominantly a React native shop as well. [05:24]
-
-**Mark:** So I'll do my usual thing where I, I step back and provide historical context and what matter at all. So React was invented at Facebook. It has always been a project owned by Facebook and Meta. The code has been open source, but. You know, for years the entire development team was Facebook meta employees paid by Meta to work on React. And I've said even in my conference talks this year about Meta, Vercel, React ownership, that the React team has had the freedom to work on what they want. And that's true, but I've, I was reminded in some conversations with React team members at React Con, how much their work is constrained by, like the fact that their performance reviews are, "what have you done to further meta's goals this year?" [05:42]
-
-And so in some ways their ability to push React in the technical directions that they think are right, are limited by how much they can make the case for that. Inside Meta, even something like the Concurrent Stores work is essentially being pitched as, how can we make Facebook's Ads Manager app faster in a lot of ways? [06:38]
-
-So we saw multiple React team members move over to Vercel. Like people used to complain that this is all a Facebook app, all the meetings are inside Meta. There's no public roadmap, it's only meta. And then we had team members move to Vercel, and then it became, well, now Vercel is applying too much ownership to React and all the stuff we've talked about with Next and server components and Vercel and how that's supposedly driving the roadmap, et cetera. [07:02]
-
-And so the team itself has been split across two companies, and they're working together. It's one team, but it's kind of within these two companies. And so because of Reacts widespread usage, there's been calls for many, many years that there ought to be some kind of an independent foundation that would own the trademarks, the rights, the development process. [07:30]
-
-To React itself. And it always seemed kinda like one of those pipe dreams. The calls on Twitter to build, React into the browser. And obviously there's no way that's going to happen. And, and this felt like much of the same kind of idea. And so they, they did the initial React and the initial keynote at React Con, and they were mostly focusing on technical things. [07:56]
-
-Like last year we, we fixed the, the sibling preloading bug. That was the suspense gate problem that everyone was talking about last year. And 19.2 came out and the compiler is 1.0. And then Seth came out and he did the one more thing routine and as soon as he put the React Foundation slide up, my jaw dropped. [08:17]
-
-And I think I even said out loud, oh my word, they actually did it. And my first reaction was, even without knowing. Any actual details about what the foundation is or how it's going to work or whether this is even going to work out in practice. The fact that they have taken the time to do the legal preparation work to try to make this happen and are actually attempting to execute on that is a huge deal for React and the ecosystem. [08:40]
-
-It, it is a statement of good faith and intent for how they want React to proceed in the future. Like without any details, my immediate reaction is, yes, finally, this is a good step forward. We'll see what it means in practice, but this is a really big deal. [09:12]
-
-**Carl:** Yeah, I would agree with that. It's a really big deal that they're moving in this direction. [09:32]
-
-I'm really curious about the details because I think there's a lot of, I don't know, like in the past they've done working groups and et cetera. And my understanding of the takeaway is generally, has generally been that they found it really difficult to manage participation in those like open access kind of arenas. [09:37]
-
-So maybe the, this is kind of like adding a new layer of abstraction perhaps with administrative support from currently thriving independent foundations. Mm-hmm. So that, that definitely makes me think that this has a real chance of being something real and valuable that goes on for a long time. I'm curious what it means for things like, like in practice, it's not like anyone's employer is changing. [09:56]
-
-No details have been shared yet. At least that anyone is being paid from this new foundation. I, I don't know whether to call it meta or Facebook 'cause it's on the fb.com domain. Mm-hmm. But in the Facebook engineering announcement here, they do say that Meta has committed to a five year partnership with over $3 million in funding. [10:23]
-
-I don't know what other funding they might have. I don't know what other sources of funding they might have in the future, but like just looking at five years, $3 million, like that's 600,000 per year, which is like, you know, for meta engineers, that's like free engineers. So I don't know. I don't know what that means for people's incentives and where they will work and how their focus and performance will be evaluated. [10:42]
-
-Yeah. [11:04]
-
-**Mo:** What that rules out is that effectively the React Native or React and React Native Core teams will definitely not be unemployed by the React Foundation. Right. 'cause that would basically cover three salaries, which is far smaller than what the React teams are. [11:05]
-
-**Carl:** I think the React core team has like 10 engineers. [11:19]
-
-**Mo:** And RN is about the same. So you're talking 20 engineers. It's definitely not going to cover those employees to move them over, which is in some capacity. And then details are to be fleshed out. But in some capacity it is a bit disappointing because it would be great if they had more freedom as the React Native Core team to play around without the restrictions, like you mentioned, of the reviews that Meta has internally. [11:22]
-
-And so it's gonna be interesting to see how that Dyna dynamic plays out effectively because there is still gonna be that same team. At Meta [11:44]
-
-**Mark:** I, I have three sources of information that I'm piecing together for some of how the foundation is supposed to work. Seth Webster answered a few questions about this during the q and a session that was broadcast at React Conf. [11:51]
-
-I had a conversation with a couple React team members and the topic came up about how things would be governed. And then there was an article on the new stack where Seth Perry was interviewed and was giving some further details about some of the governance. [12:05]
-
-So as best I understand it, so you've got kind of the corporate level stuff that's Meta, Amazon, Callstack, Vercel, et cetera. They will then elect a technical steering committee. Which is, I guess sort of similar to how Node and other projects work, Seth said in the q and a, that meta will start with five votes on that corporate board, and then it will go down to one over the next five years. So you kind of a decreasing amount of influence in that sense. [12:21]
-
-The technical steering committee, I assume, would be able to make decisions themselves, but obviously the fact that they are employees of the companies elected by those companies, et cetera, they would be taking their company's interests into account in the process. The article says that the technical governance will be in the open more than it once was. [12:53]
-
-Request for comments, sets of stages, et cetera. But a lot of the process is still to be figured out. The article also talks about the foundation doing things like investing in React hubs, helping boot camps teach React better, possibly some things with conferences and alignment and such. So it sounds like the foundation is going to be doing more outreachy things. [13:17]
-
-So there, there's a lot of this that is not clear what it means in practice yet, but certainly. React is not solely a meta owned thing at this point. There are multiple companies that are invested in it. There is a, a future for React independent of META'S ownership and goals. And this all feels like the people who care are trained to do the right thing. [13:43]
-
-And [14:11]
-
-**Mo:** on the conference side, I mean, I hope that's the case because one of the, as a conference organizer, one of the things that's perhaps challenging is that Meta doesn't necessarily sponsor any conferences beyond just React conf, right? And so, look, it's well known that that's sort of the case. And so maybe the React Foundations that is going to be able to sponsor those conferences, even if it's not a meta badge to speak, which would be very, very interesting if some of that is used for that. [14:11]
-
-So I'm sure it's not just Meta who's investing, right? Like I, I suspect that there's funding coming in from. Amazon and Microsoft, at least from the bigger, bigger sort of established enterprises [14:38]
-
-**Carl:** hopefully. And that's interesting. And the new Stack article interviewed Seth and has a bunch of poll quotes from him and they do talk about that, that like the foundation will look at expanding the annual React conf. [14:49]
-
-I guess that's not sponsoring other conferences, but they're talking about conferences at least. But also something that caught my attention. They say while React Comp is one of the few conferences that actually makes a profit, it basically only paid for itself. And also it's a thousand dollars a ticket conference. [15:00]
-
-So like hopefully the mode of making conferences self-sustaining is not making them cost a thousand dollars. [15:14]
-
-**Mo:** Yeah. I mean conferences are from experience a very, very expensive endeavor. And if you don't have companies backing them, they will make a loss. [15:22]
-
-**Carl:** I do wanna shout out, as we mentioned at the start, Seth says "We have lots of boot camps out there that are doing their best, but they're also sending people out into the world misinformed about how React works." [15:31]
-
-This is interesting there. It's a, it's funny, they're actually hitting on a couple of points that I've investigated myself about how to do businesses in like a community since like I had previously connected with a bootcamp. Somebody was working there as the curriculum lead and they were doing a curriculum overhaul. [15:40]
-
-'cause they hadn't changed what they were teaching in three or four years. And they were like, is this still relevant? Is this what the industry's using? And I was like, cool. I help run a community. I know lots of experts. I would be happy to facilitate some kind of professional review. And then the bootcamp curriculum lead got laid off because that was 2022 and lots of things were not happening. So it's interesting to see them talk about things that I've thought a lot about. [15:59]
-
-And also a lovely shout out, Seth says there are also cohorts such as meetups and local groups that could be assisted. One meetup actually led to the creation of the conference React Native London. So that's super cool. Love that for you, Mo. [16:22]
-
-**Mo:** Yeah, I didn't, I, I did not have that on my Bingo card to get a shout out from Seth Webster on an interview, which is awesome. Yeah, it was good to have him last year. [16:36]
-
-**Carl:** Mo is the organizer of React Native London and that one meetup that led to the creation. So that, that's just fun. [16:44]
-
-That's cool. We have actual players in the ecosystem in the podcast right now. [16:51]
-
-**Mo:** Well, you got Mark. So I'm stepping up to very, very, very high standards. Pretending to. [16:55]
-
-**Carl:** Cool though. Yeah. So I don't know. I don't know if there's more to say there. [17:00]
-
-## 19.2 (Activity, useEffectEvent)
-
-**Mark:** Some of the more technical stuff. So they, they talked about React 19.2 coming out, which if you've been paying attention to this podcast for the last several months, you would've known all the details already. Like the new activity component for being able to hide components while persisting state use effect event for hopefully fewer use effect related bugs, et cetera. React compiler hit 1.0 and then [17:03]
-
-## React Native news
-
-**Mark:** Mo as like as usual, you wanna talk about the React Native-y things? [17:27]
-
-## [New architecture only from v0.82](https://reactnative.dev/blog/2025/10/08/react-native-0.82#new-architecture-only)
-
-**Mo:** So a few updates that they did, one of which was quite surprising was that the next release of React native version 0.82 is going to be new architecture only. [17:32]
-
-So obviously earlier on a few months ago, we talked about how they deprecated the old architecture than they froze the old architecture. Now they're dropping the old architecture. And so to me that was a much faster deprecation cycle than I, I would've expected. Specifically when it comes to the fact that there are still a fair few libraries that are using the old architecture and only support the old architecture. [17:44]
-
-So to give you a very concrete example, we had our monthly meetup literally yesterday, and there was a talk about Arrive, which is this animation engine that a lot of people are using to animate websites and make really, really cool stuff. But what we learned surprisingly was that Rive only supports the old architecture. [18:06]
-
-So what that means is that this company who's a very popular healthcare company, really don't have a path to sort of migrate to the new architecture and hence version 0.82 until Rive starts to support the new architecture. So there are still libraries, albeit the majority of major libraries have been ported to the new architecture that are still hanging behind. [18:24]
-
-So I'm quite surprised by this, but we'll see how it goes. It probably means that these library maintainers really need to like step up in the next month or two and get ready. [18:44]
-
-## [Vega OS announcement](https://developer.amazon.com/apps-and-games/blogs/2025/09/announcing-vega-os)
-
-**Mo:** The second big thing, which I have a little bit about later on, but just a quick one, is that Amazon did the Vega Os announcement earlier. [18:52]
-
-It was towards the end of September that they actually announced it, but [19:02]
-
-## [Vega introduction at React Conf](https://www.youtube.com/watch?v=p9OcztRyDl0&t=5737s)
-
-**Mo:** they formally talked to the React and React native communities about it during React Conf. This is a completely new operating system that's fully built from scratch by Amazon folks and React Native is the UI layer. It's the only way that you can write apps for it, which is quite a big investment from Amazon's perspective into React Native as a technology. [19:04]
-
-So Amazon makes a lot of devices. For a little bit of context, you might've seen their Fire TV devices, some of the Kindle fire devices that they had, but also like Echo dots and a whole slew of different devices that they manufacture. And previously a lot of these were running on Android or a variety of Android called Fire Os that they had adopted from the Android open source projects. [19:27]
-
-And so now they've kind of completely ditched that and they're betting long term on React native now at our company at Theo and a bunch of other companies have been sort of working with Amazon behind the scenes on this. And we're aware of this but weren't really allowed to speak about it. So it's now out in the public. [19:47]
-
-But it has been a good while, which I cannot specify how long that duration is that I have been aware of this, but just not able to talk about it and have been working with the Amazon folks to make sure that things are ready for their launch. So they have an introduction video at React Con, which I think is interesting because TV apps need to run on very, very limited specs. You're talking like a few gigs of Ram one or two gigs of ram and like very, very, very slow CPUs and some of them are even worse than that. So effectively they really had to optimize the living crap out of their operating system and make sure that React plays nice with it and is like the first class citizen when it comes to it. [20:02]
-
-So it's, it's very interesting how they had to optimize it and it was a big undertaking for them. So. I guess congrats to the Amazon team, but beyond that, it's quite interesting for people that are interested in performance and React and React native. [20:38]
-
-**Carl:** Yeah, I was just scanning this to see if I could find any details about what they built on top of, because like, I don't know, nobody builds a whole OS from scratch anymore. And this is on top of Linux? [20:48]
-
-**Mo:** Yeah, it's c plus plus on top of Linux. Basically it's a Linux. Or is a Unix based system. [20:59]
-
-**Carl:** Right, like, and so is Android. Like, I'm curious to what extent this is a locked down, stripped back version of Android that they're calling Vega. They don't say that anywhere, but like reading the tea leaves here, I, my assumption is that the, I don't know, Android was such a massive undertaking that Google then acquired and commercialized. [21:05]
-
-Curious to hear more technical details about the OS layer here and how it… [21:28]
-
-**Mo:** I can tell you a little bit about that because I've known about it for a while. It's not on top of Android in any capacity. It is fully, the Android open source project components of it are fully stripped out. It's built from scratch, which means that compatibility with old apps is. [21:32]
-
-Limited and there's other solutions. It's not that you can run Android apps on it as an example that we're the old Fire OS apps. [21:47]
-
-**Carl:** So wait, it sounds a little bit like you're saying there is a shared lineage with Android, but it's different enough that its own technically distinct thing. [21:54]
-
-**Mo:** They share a technical lineage in the same capacity that like Mac Os and Androids here, which is, they are both unique systems and that's pretty much it. [22:02]
-
-Like they serve the same kernel but like so does 90% of devices out there. So it's as Android, as IOS's, Android, if that kind of makes sense. [22:11]
-
-**Carl:** The Tree of Life, kingdom Family order. Like this is not shared genus. This is shared order maybe? Yes. Okay, cool. Good to know. Thank you. [22:19]
-
-**Mark:** I do wanna highlight a couple talks in particular, and again, you can look at the whole React con recap blog posts to get links to the different talks and the different portions of the live stream. [22:27]
-
-## Joe Savona’s “[Exploring React Performance](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=20274s)” talk
-
-**Mark:** A lot of good talks that were worth watching, but two that I liked in particular, Joe Savona did a talk on some of the React team's performance experiments, and there's a bit of controversy because he showed a bunch of hypothetical, semi hypothetical benchmark numbers without any real details on the actual implementation of the benchmarks. [22:36]
-
-And then some of them were like, versus we built NAP with signals and compared it with one with React and then ex a highly prototype React and a bunch of other stuff. And then people were saying, well, we tried to mimic this and we think you're probably using signals the wrong way. But it was still interesting to hear the discussion around, we agree that performance has been a problem and we've tried prototyping some different ideas to see what's possible and where bottlenecks might be. [22:56]
-
-## Ricky’s “[Async React Part I](https://www.youtube.com/watch?v=zyVRg2QR6LA&t=10907s)” and “[Part II](https://www.youtube.com/watch?v=p9OcztRyDl0&t=29073s)” ([repo](https://github.com/rickhanlonii/async-react))
-
-**Mark:** The other one I really wanna point to though, Rick Hanlon did a talk called Async React and he had a few major, he had a couple different points out of this. [23:26]
-
-One was that the React team has been talking about things like suspense and concurrency since 2018, and if it's been hard to follow where the React team is trained to go with this, it's 'cause the React team itself really didn't know where they were trained to go with this. He even pulled out meeting notes from a React team weekly meeting in like 2015 or 2016 where they started having the first initial ideas for, we think we want to go in this direction, but they really didn't know what the final result ought to look like or how they were going to get there. [23:36]
-
-And so showed a diagram with a whole bunch of back and forth wavy lines like we, we don't know where we're going, but now it's 2025. We've gotten through the confusion. We've now built all the main concurrent pieces that we were trained to build. We are seeing the results of even like the React 16 fiber rerate. [24:15]
-
-And now we can actually say, we've built these pieces and here's how they ought to fit together. And so the second half of his talk was a demo where he took a badly written but viable React app, which uses use effect for data fetching and manual setting, state for loading states and things like that. [24:37]
-
-And he first refactored it to have a bunch of transitions for better loading animations, using suspense for the data fetching, and he showed the visible improvements in user experience. And then his point towards the end was that, yeah, the, so like this is how modern Async React code ought to work. But in fact, you shouldn't even have to write most of this code in your own app because the transitions and the loading states and everything else really ought to be embedded in your router and your data fetching library. [24:56]
-
-Now, unfortunately, his actual talk got interrupted for stupid technical reasons. So he came back at the end of day two and picked up with his demo and actually had a chance to do a better version of it. [25:36]
-
-And so I think the key points are, one, the React team has now built the concurrent async features that they've talked about for years. Two, a lot of us, including myself, are still kind of stuck in like a 20 16, 20 18 era mindset of how to use React three. These things make writing React apps better and better user experience. Four, we need to get these things embedded in component libraries and data fetching libraries so that a lot of this stuff just works outta the box. [25:48]
-
-So I highly, highly recommend watching Ricky's talk. He also put up the demo code as well. [26:23]
-
-**Carl:** That was a good talk. It was a good demo. I will say, while watching him write the code. I was like, man, this looks really complicated. [26:29]
-
-**Mark:** Yeah. And that, and that's another point that we're going to touch on here with a couple of the, the other things as well. [26:37]
-
-One other thing that really caught my attention, so if you've been listening to podcasts for a while, you've heard me agitating, saying that we really need is a new React working group where folks from the community can officially communicate to the React team for things like, Hey, we think there should be more docs to cover this topic. [26:41]
-
-Or, oops, create React app just broke. I think you should fix it, and things like that. And Ricky was actually the person who drove most of the React eight team. Working group. [27:00]
-
-## [Async React Working Group](https://github.com/reactwg/async-react)
-
-**Mark:** And so at the end of his talk, Ricky actually announced that there is now a new Async React working group. And this is sort of a catchall, it's meant to cover discussions of things like how do we get async React features into major ecosystem libraries and, what kind of docs should we have to cover this stuff? [27:12]
-
-## First [discussion of more docs ideas](https://github.com/reactwg/async-react/discussions/2)
-
-**Mark:** And so the, even the first discussion thread is a lot of discussion between me, Ricky, Dan Aberman of Corbin Crutchley, about a whole bunch of possible docs, pages that we could add that would cover things like transitions and suspense and how to use them correctly. [27:35]
-
-And getting people from the community to contribute those new docs pages rather than waiting on the React team. To write them. So I am actually genuinely, genuinely excited. Like I've done a lot of complaining and this is the answer to my complaints that we have working group and docs plans and an agreement that people outside the team can contribute. [27:53]
-
-So like I am actually legitimately thrilled by this. [28:16]
-
-**Carl:** Nice. I do appreciate more, I don't know, open participation more, more discussion. That's great. [28:21]
-
-## Remix v3 announcement
-
-**Carl:** Should we get into Remix V three? [28:27]
-
-**Mark:** Yes, we should. Alright, so usual caveat, I still have not had time to actually watch the announcement, but I, I think I can give a fair summary of it from having seen the discussion on Twitter and the articles afterwards. [28:29]
-
-We have mentioned for the last several months that they were teasing Remix V three is going to be, not pre-ACT, its own component model, something with iframes, whatever. And our last comments on it were just show us some code already. Well, at the Remix Jam conference, they did actually show us the code. [28:43]
-
-## [Announcement demo timestamped breakdown](https://github.com/markdalgleish/remix3-resources)
-
-**Mark:** There was a, a repo put together that did timestamped links to all the appropriate pieces of the announcement video. So if you'd like to be able to jump in and see the examples of what Remix V three code is supposed to look like, that should make it easier. My first impressions, again, just having seen screenshots of the code in following the discussions, is that Remix v three's component model is sort of a mixture between React, view and backbone. [29:03]
-
-So it's kind of like React in that you have function components and they, and that uses JSX. It's kind of like view and the composition API, where you're given a closure as the setup. It's a little bit like backbone in that the function component you're rating still sort of is organized like as if it were a class. [29:35]
-
-It passes in a reference to the instance rather than getting the props as an argument, and you're supposed to call it this. And part of that is to make use of a TypeScript typing trick that lets you declare the type of this as an argument to a function. But also you manually trigger updates by first mutating a variable in the setup closure, and then you manually call this update. [29:58]
-
-And so Ryan Florence even said, this is basically old school React class component, this dot force update. Essentially, so I, I can see bits and pieces of parallels and influences between all three of those frameworks. When I look at the Remix code, it's also supposed to come with a bunch of utilities for being able to compose event handlers together. [30:29]
-
-And yeah, so we, we have finally seen the code. I believe they also gave some demonstrations of what the server side loading story is supposed to look like. Some kind of an I frame alike component that has its own URL and can automatically re fetch HTML. I haven't looked into those pieces as much, so very big picture. [30:54]
-
-I saw a lot of people arguing about having this dot update. A lot of people saying it feels like a step backwards, it's manual update code. [31:19]
-
-## [Updates syntax can be customized?](https://x.com/sergiodxa/status/1976878377509568871)
-
-**Mark:** But some people demonstrated that you can very quickly write your own wrappers that just call this DOT update internally. I have seen wrappers that mimic like the used state hook. [31:28]
-
-I've seen wrappers for other state management libraries like Redux. So it's a primitive that can clearly be abstracted if you really want to. I saw some good posts and articles from James Long and a couple other people with thoughts on the ability to compose interactions together. Carl, to your point that modern React and all the new async features feel very complicated. [31:39]
-
-Like there's good reasons why methods like transitions exist to try to give better user experiences, but it's just all these additional concepts and behaviors you have to keep track of in your head. And Remix is trying to go for a less magic, less abstraction approach. So we'll see what it means in terms of adoption. [32:06]
-
-Again, this is non-reactive, so different framework, different ecosystem. Who knows what the actual adoption will look like, but I get the sense of what they're trying to go for and I, I think it will appeal to some number of users out there that want to have that kind of behavior. [32:31]
-
-**Carl:** Yeah, I'll definitely keep paying attention to it 'cause they're thoughtful about things and historically have just done a lot. [32:49]
-
-So I'm very curious to see where this goes. But my gut feeling here is that this is going to end up more as an API exploration and that any great ideas that come out of it will be a fresh exploration and then maybe validate some ideas that get brought into React or view or other big tools. But yeah, I, I could be wrong, could be, could be more independently successful than that. [32:58]
-
-They, they did stress in the video that I watched, that this is all like prototype phase. So they, like right now apparently there's splitting it all up into a bunch of different packages. They can iterate independently and explore a bunch of different things. But the, the final intended usage would be from one package, not from 20 different packages. Just to throw that out there as a a thing that will change. Yeah, I don't know. We'll see. We'll see. I think the component model is just gonna be really hard to disrupt. [33:25]
-
-One, one thing I did see in the video of Ryan Florence talking about just talking while he was demoing, he like compared and contrasted with like, here's how we do state changes and you just call the dispatch function instead of set state. [33:54]
-
-And I was like, I dunno, you can do that in React. Like they've been encouraging people to do that for years, for like six years basically Ever since hooks came out and you could do a state reducer, they were like, please, except for trivial uses of state, all of your state should be in a reducer and you should use dispatch. Not set state. So just like calling that out as a point of comparison, like React has been trying to do that for a long time too. It's just nobody actually does, I dunno, just caught my attention. [34:08]
-
-**Mark:** Well least we have an actual code to critique now and argue about instead of the vague teasing. True facts. [34:35]
-
-**Carl:** I will happily continue reading code and critiquing. [34:41]
-
-## [I built the same app 10 times](https://www.lorenstew.art/blog/10-kanban-boards) ([code](https://github.com/lorenseanstewart/kanban-comparison))
-
-**Carl:** Speaking of which , I love this project. I have thought about doing this so many different times and I never have because it's hard. Somebody built the same app 10 times in a variety of different frameworks and tools and benchmarked them and compared and contrasted their performance in a bunch of different metrics. [34:44]
-
-It seemed like they focused pretty heavily on like bundle size to me, very wordy. I, I will say I got a little bit lost in the [35:05]
-
-**Mark:** instruction. Very wordy and very, also, a lot of the article was very clearly AI generated. I saw some comments from the author saying he had written pieces of it in sections and used AI to help with it. [35:12]
-
-So like there, there was clearly human involvement in it, but the, the AI generation of the article itself was a critique point. [35:22]
-
-**Carl:** Yeah. Just like as I'm scrolling, it's got so many paragraphs in a row that are all like identically long. Just a little bit of a wall of text. I definitely skimmed this pretty hard. [35:30]
-
-All that aside, like I just love the idea of doing the exact same thing with the exact same. Like, well, I don't know that they use the same test suite, but that, that was always my idea is build. You build an end-to-end test suite and then you get a passing app for that test suite in a bunch of different tools. [35:38]
-
-I meant to do more of a deep code review on a couple of the different implementations. It's a CanBan board, it's, you know, a Trello clone type project where you're doing task management with cards and drag and drop. I guess it, it's a great and a parable comparison because drag and drop is really hard to do and so it's very frequently something people try to lean on libraries for. [35:54]
-
-So if you are implementing it yourself, that's kind of cha, that makes it a little bit challenging to use as a point of comparison. But the tools that were used here, he built it analog, which I guess is vanilla js is what I'm assuming, or [36:15]
-
-**Mark:** analog is actually a, a next like tool for Angular. [36:31]
-
-**Carl:** Oh great. Okay. Okay. So you built it an analog, which is an angular type thing. [36:36]
-
-And HTMX, Marco, which I'd never heard of. Next.JS, of course. Next. Sure. Qwik City, which is Qwik. I've heard of Qwik City I had not heard of. So this is I guess [36:41]
-
-**Mark:** probably another solid versus solid start type thing. [36:53]
-
-**Carl:** Qwik city to qwik Sure. Solid start spelt Kit Tan Stack with solid and then Tan Stack with React. [36:55]
-
-Yeah, one of the first tables, one of the first actual like points of comparison of the output tables is just on bundle size and how much JavaScript was served in order to. Get this app running. They used Next.JS version 16 as the baseline and that was about 500 kilobytes gzipped, which is huge. It's big hand stack. [37:03]
-
-Start with React. Clocked in at about 300 kilobytes a little bit more with solid was a half of that hand stack. Start with solid was 150 ish kilobytes. The smallest was Marco. 12. At 12 kilobytes followed by quick city at 88. Oh, I just realized there's parenthesized compressed. I thought I was reading the compressed and I was not. [37:25]
-
-**Mark:** There's also the board page versus the homepage sizes. [37:49]
-
-**Carl:** Yeah. Okay. Alright. This is more confusingly presented than I realized. [37:53]
-
-## Same author as [React Won by Default and It’s Killing Innovation](https://www.lorenstew.art/blog/react-won-by-default/)
-
-**Mark:** I think the biggest picture takeaways, number one, it's worth noting that the author of this article previously put up a post a month or two ago saying that React by is the default choice and it's killing innovation in the ecosystem. [37:57]
-
-So that kind of to where they're coming from. But I do think they did. They were legitimately trying to do a real meaningful comparison, even if the results were sort of what they were hoping they would be. IE reacted big and bad. So yeah, the big takeaways are like React itself is huge and so any React app is going to be very large bundle size wise. [38:08]
-
-And look, if we do like Tan Stack with Solid instead of Tan Stack with React, it gets smaller. But also if you do these other frameworks, it gets even better smaller and then it kind of ends with a bit of a, another rant about React is a bad choice. [38:32]
-
-**Carl:** Yeah, I, I will validate that. To me it also looked like they really tried to give React a fair shake here. [38:49]
-
-Like, you know, if you wanted to, if you were wanting to complain about bundle size, if React apps, like there are so many easy ways to bloat this up to a couple of megabytes. So like the fact that they didn't do that is indicative enough to me that they tried to give this a fair shot. It's cool. I love this. [38:55]
-
-This is a great project, great effort. I don't know that, to me, at the end of the day, this is interesting and fascinating and a great point of comparison, and also like not that meaningful because the performance metrics that you measure here that are easily measured by comparing the outputs of identically functional applications, that's really only like maybe a third of the reason why you would choose to build an app with any particular set of tools. [39:11]
-
-Like really, if you're starting a company and hiring engineers and doing a greenfield project. Like some of the most important things are how much will this cost? [39:41]
-
-**Mark:** How well is everything? How well is everything documented? How easily can we spin up engineers who know these things? I mean, the, the ecosystem argument is a real thing. [39:52]
-
-**Carl:** And like, you know, if it takes you two months to find a developer, you know, a senior developer who can build your app in Marco, you know, you could do that in a week. I don't know. The hiring for React is much easier than hiring for some niche tool. And I have seen writeups of people saying like, yeah, we built our startup on this niche framework and we couldn't hire for it. And that ended up contributing to the death of the company. [39:59]
-
-So like, you know, these performance metrics are important, they're really useful, it's great to have them. So we know where opportunities to improve are like tying this back mark to your Immer work. Like if somebody hadn't complained about performance, you wouldn't know that it needed to get better. [40:23]
-
-Pretty [40:37]
-
-**Mark:** much. Yeah. [40:37]
-
-**Carl:** So this is great and I love it, but it's also not the end all, be all of like decision making for, things. Yeah. It's also, man, this, it's just so hard to read because of how long it is. I wish they'd stripped this down a bit more. [40:38]
-
-**Mo:** And if we take like a step back out of our like web ecosystem bubble for a second, like you go to like the backend world and like enterprise business companies or finance or whatever, and like they employ a lot of developers, right? [40:49]
-
-Like thousands, thousands and thousands of developers. And like there's a reason they're all on Java and .Net is because like they can hire for those and it's pretty easy to build a team around. That's the top priority. Even like this stuff is quite minuscule when people are, companies are hiring at a large scale. [41:04]
-
-And then the second thing, which is like not accounted for, I think in this like approach of looking at like just the bundle size that's outputted is the fact that like your productivity with the fact that most of the AI tools are really like optimized around React is not something that you should not look at and consider when you're choosing something. [41:21]
-
-There's so much training data and so much like tooling around building React apps quickly and prototyping React features or React apps that with AI that is just a bit, it feels a bit moot some of some of these conversations. It feels. [41:41]
-
-**Mark:** To be clear, like React has got itself has gotten much bigger over the years. [41:55]
-
-In fact, even just 18 to 19 it got notice will be bigger. Bigger bundle sizes are not a good thing. We are not sitting here saying Your bundle size does not matter. Alex Russell, as much as I disagree with his communication style is right to point to the technical receipts saying that big bundle sizes are bad, but also it's not the only single metric you should care about. [41:59]
-
-**Carl:** Yeah, right. Yep. And also, last thing I'll shout out here. I think the author of this blog post also mentions that he tried not to pull in too many dependencies. So like did not pull in fetch wrappers or data fetch tools like React Query and. [42:21]
-
-Axios, the data fetch thing, which many people still use, I don't know. They still have a fair amount of utility just for things like observability and security and various guarantees like that. Like Axios itself is 36 kilobytes ified like 14 compressed. React Query is 55 kilobytes. I guess to say that the way he did it is actually better quote unquote for React in terms of the bundle size argument, but it's also not representative of how people actually build apps. [42:40]
-
-It's a challenge of these types of articles is that by necessity it has to be the level of scope that a single developer can execute on their own, and that's just not how most apps are built. Like most apps are not passion projects by one person. So yeah. Super cool. Love this post. It's interesting more than it is authoritative, I think. [43:11]
-
-**Mark:** Good way to put it. Mo, tell us about Solito. [43:30]
-
-## [Solito 5](https://solito.dev/v5)
-
-**Mo:** Yes, Solito. So go back a few months. You'll remember that we said Fernando Rojo joined Vercel. And he joined as the head of mobile firm Vercel. This was significant because he's the author of this library called Solito and a few other libraries like Ziga. So he's really, for the last few years, has been focused on. [43:33]
-
-Using React native on the web as well, especially with Next.JS. So he built his own startup in that sort of tech stack. It is from experience and having built with this tech stack quite a lot, it's a challenging approach because you are always balancing oversharing between your native components and your React native code and the web functionality that you import in. [43:53]
-
-And oftentimes that comes at a detriment of performance or ux, depending on if you do it right. And the more that you share, the more chance there is that you're not, you're sharing something that you probably shouldn't share. And so there's a lot of libraries in the secret system, but Solito is probably one of the key ones where it lets you share navigation across Next.JS and React native apps. [44:16]
-
-Now, we've talked a bit about Toledo in the past. One of the big limitations that any library in this space has is that it relies on React Native Web Now, React native web was made several, several years ago. I think it was back in 2015. And it was made by Nicholas Gallagher. Now, he also did a talk at React Conf, which I would recommend you watch about React strict dom. [44:39]
-
-But the key thing with React Native Web is that it's not really receiving as much love because Nicholas is working more on React strict dom, which is sort of like the future path for sharing code across the web and mobile. And so React native web is, is a little bit bloated, and what that means is that any library that you really use, especially your, something like your navigation and routing library will import in large portions of React Native Web, even if you're not using all of the APIs. [45:00]
-
-And so that means that your bundle size goes through the roof. And what the Vercel team slash Fernando Roho have now been able to do is actually remove React Native Web as a dependency from from Solito, which is pretty massive. It sets us up in a foundation where you can effectively get ready for React strict dom adoption more easily in the long run, but also means that if you pick and choose your libraries well, when you're building a UniVercel app and you really think about what you're using on the web platforms, you can really start to tackle that bundle size problem. [45:25]
-
-It doesn't help if you're using libraries like let's say Reanimated, which has a pretty heavy reliance on React Native web. But if you're going really vanilla and you're very careful, it means that you can actually achieve much better performance on the web by using this new version of Solito, which is very exciting. [46:00]
-
-So yeah, if you're already using Solito, give it a look and if you're thinking of building a uniVercel app, it's a really good candidate if you wanna build a highly performant web variant of your application. [46:16]
-
-**Carl:** I love that. It definitely makes a lot of sense to start moving away from React Native Web, given that we've compared and contrasted React Native Web with like React strict dom. [46:25]
-
-I guess it makes sense to move away from React native web, 'cause the guy who made it is now doing a different thing in the exact same space from a very different angle. So yeah, that's a pretty strong argument for changing. [46:35]
-
-## Next 16 and Directives debate
-
-**Mark:** Okay, the last major topic for the day next 16 and directives. [46:49]
-
-## [Next 16 released](https://nextjs.org/blog/next-16)
-
-**Mark:** So next 16 came out. The headline feature is they now have what they're calling cash components. This is the, I don't know, second, third, fourth iteration on how to do caching in next, across the last couple major versions. I'm not gonna pretend that I understand what, how this works. [46:56]
-
-No one does, but thing is that they introduced. Another new directive. Now to recap a directive is these little strings that you just put in your code. Originally we had use strict back in the ES 2015 days and then React server components introduced, use server and use client, and now we have 'use cache'. [47:15]
-
-And the idea is that by slapping this directive on certain components, that tells the next bundler and compiler that, Hey, this is the output of this component is supposed to be cached. I don't understand the details. From there, go read the documentation long. With that, they also announced a new long-lived workflow product, kind of similar to what the temporal company. [47:40]
-
-Has built where you can have a function, for example, that implements a billing workflow by sweeping for 30 days and you've written what looks like one function, but under the hood it's actually like saving its status to a database and then a time job wakes it up and continues executing the code, that sort of thing. [48:03]
-
-And I believe they opted to implement this also with a use workflow directive and like a use step directive. And I think there may have even been one or two others related to variations on caching, like use Cache, remote, something like that. And meanwhile, we've also got the React compiler has opted to use directives for a couple things. [48:23]
-
-So there's a use no memo directive. If you want to tell the compiler, don't try to auto optimize this component. And so all of a sudden we've gone from the JavaScript language specifying. One directive. There was also the unofficial, oh, was it use a SM directive that was part of a SM js, the precursor to web assembly, but like one official directive in the language. [48:48]
-
-And now we have a couple for bundlers, and now we have more for workflows and the compiler and all these other things. And so the Twitter discourse over the last couple weeks has been our directives, good or bad. And they're so confusing and they are changing the language. And you have all this bundler defined behavior that is not part of the language spec. [49:18]
-
-## [Directives and the Platform Boundary](https://tanstack.com/blog/directives-and-the-platform-boundary)
-
-**Mark:** And so Tanner Linsley, again, creator of all the different Tan Stack libraries, put out a blog post where he expressed his opinion that he does not think directives are a good idea. Because they are unofficial, because they're not standardized, because make it not clear what the actual intended behavior ought to be, as opposed to like explicitly importing a function that says, turn this into a client server function or something like that. [49:41]
-
-So there there's been a lot of arguing about directives and are they understandable? Are they good or bad? Are they too much magic? So that's been happening. [50:11]
-
-**Carl:** I'll say it. They're bad. It's too much magic. I hate it. I'm not a fan. [50:22]
-
-**Mark:** I understand the thought process. I, I can't say I'm thrilled. And so on that note, two article articles that are related enough to throw them into this section. [50:26]
-
-## Technical critique of Next App Router: [Everyone Hates Next.js](https://paperclover.net/blog/webdev/everyone-hates-nextjs)
-
-**Mark:** I've seen lots of different article articles upset at Next or critiquing next. Most of them are frankly very badly written, but I saw one come out last week that I thought was very well written and focused strictly on the technical pros and cons of using the App Router. The title is Clickbait, everyone Hates Next, but the article itself is actually very well written. [50:34]
-
-It discusses technical aspects of using Next, some of the problems his team went in, ran into, and how and why they ended up migrating from the App Router over to 10 Stack Start. And then Nadia Vic, who has done a bunch of very excellent articles on React rendering behavior, put together a very data-driven look into do server components actually help with things like First Contentual Paint and various other White House style metrics. [50:57]
-
-So very worth reading. [51:26]
-
-**Carl:** As I'm trying to think about how you might solve problems of caching and runtime things without directives. And I'm thinking about, you know, my experiences using like CloudFlare workers or other runtimes where it's not a traditional process scope. And I don't know, I guess like it is a really challenging question of like, how do you signal to a developer that the file they're editing runs in a certain type of context? [51:27]
-
-And I guess I understand why directives are an appealing thing to reach for, but man, just the state we're in right now is really a lot. I found the Next.JS docs page with directives and it lists 'use cache', 'use client', 'use server', and then two sub variants of 'use cache'. And that's not all of 'em that, so there's missing ones here and. [51:56]
-
-I don't know. When you start getting into like many different contexts, just naming them at the top of the file doesn't really seem like enough for me. I don't know. And then like the implication for that code can import other code that will not have it flagged what context it's running in via a directive at the top of the file. [52:20]
-
-And I don't know. It's a tough problem. It's a weird unanswered question in the industry, like not even the ecosystem, but like the industry. How do you flag code that might run on your browser, a real server, serverless environment, and yeah, I don't know. It's a challenge. [52:40]
-
-**Mark:** I think it really does speak to the overhead and mental complexity of trying to juggle all these things. [52:58]
-
-We said earlier that React 19 has, 18, 19 have introduced a whole lot of things like transitions and other pieces to try to let you write better user experiences. But now you're having to juggle in your head like, here's the current version of my app in its display state versus a work in progress rendered version versus a future output rendered version. [53:04]
-
-On the server side we're having to deal with, this is server code, this is client code, sometimes they're mixed together in the same file, sometimes they're mixed together in the same component. Which code is running? In which context do I have to worry about accidentally leaking security tokens or something like that. [53:28]
-
-We're building tools to solve real problems, but there's more and more to juggle in your head as you go. [53:46]
-
-**Carl:** Well, I'm gonna plug effect one more time because I saw it come up in the chat. Oh, man. It just like talking about different ways of signaling facts about the code. The code you're writing has certain dependencies. [53:53]
-
-Certain dependencies is too loaded. That's, that carries too much context with it, but the code you write has a certain amount of assumption baked into it about what will be available and what it can rely on. The thing I love about a fact is that it makes that more explicit and brings it into the type system. [54:06]
-
-So I think the challenge right now is that we are missing a like platform and language level abstraction to express information like this. And yeah, I don't think we're gonna get it anytime soon. And I think these explorations will lead to something like that and hopefully converge into something. But I think this is gonna be like a real state-of-the-art problem for a couple of years and still, which I hate, but it'll get better. [54:26]
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Alright, moving on to the lightning round. [54:56]
-
-## [ViteConf roundup](https://voidzero.dev/posts/whats-new-viteconf-2025)
-
-**Mark:** In addition to React Con and Remix Jam, we also had Vite Conf and the V team gave a bunch of updates on all the different tools they've been working on. Some of the highlights to me were that OX LT now supports ES lint and JS plugins via some really awesome tricks for interop between js and rust without the the cost of serial serialization. [54:58]
-
-They announced a combined tool chain called v plus, which basically pulls all the different tools, VIOX lint, OX format, Vitest, everything else together. That'll be their enterprise sales targeted tool set. And then Vitest four is out with browser mode support. You basically just put a flag in your Vitest config and suddenly your tests are running in a real browser instead of a node plus js. [55:21]
-
-## [AWS Outage Postmortem](https://aws.amazon.com/message/101925/)
-
-**Mark:** Last week, AWS east went down and the internet died and they put out the postmortem and it was DNS apparently they, their internal DNS system for dynamo DB had like three different instances of the DNS updater running and one of them got stuck and was taking a long time to complete, and the other one came along and updated and then said, well, these, some of these plans look out of date, let's delete them. [55:49]
-
-And next thing you know, DNS goes down, dynamo DB goes down and the internet goes down. So, oops. [56:19]
-
-**Mo:** It's funny that the, uh, internet is backed by Dynamo db. [56:28]
-
-**Mark:** A lot of people like us East One is the default. A lot of people have tried to get away from US East one, but when a lot of Amazon's own stuff depends on US. [56:31]
-
-East one. Yep. You all [56:39]
-
-**Mo:** of your certificates can only be issued in US East one, so that doesn't really help much. Side note, if you end up working in a consultancy one day, just hope nothing like this happens because the morning of was fascinating reaching out and getting reached out to by a bunch of clients being like, my site is down. [56:40]
-
-And then having to figure out what's going wrong, which is US East one on AWS. So it was a fun Monday, [56:57]
-
-**Carl:** but at least the uh, at the end of it was a vendor is out. This is not our fault. [57:02]
-
-**Mo:** At least it was that, which was great. Cool. Moving on. [57:07]
-
-## [Voltra](https://x.com/saul_sharma/status/1972161677165473980)
-
-**Mo:** So a couple of React native lightning route items. Firstly ra, which is really cool because we've talked a little bit about live activities on iOS and iOS extensions, all of the little widgets and stuff that you can now use on your iPhone. [57:10]
-
-And you were able to use iOS extensions within a React native app. But the challenge was you had to write SWIFT code to be able to actually implement those. And so a independent developer named S has been working on building an MPM package that allows you to ship these custom widgets and extensions without needing to use Swift X code or extra js, which is so cool because he's basically had to like write a translation layer or a render that takes React UI code. [57:24]
-
-And converted to Swift UI code, which is not trivial because many have tried before him and failed. So this is a really cool project and like it's one of those things that's like kind of mind blowing. So kudos to him for making this. [57:55]
-
-## [Building fully native apps with EAS](https://blog.swmansion.com/building-fully-native-ios-apps-with-expo-eas-760b5480d7c5)
-
-**Mo:** Secondly, and I thought this was an interesting article to link to. On the expo blog, they publish an article about building fully native apps with EAS. So EAS is expo's application services. Typically, this is being used to build React native apps that are usually running on Expo, but actually a lesser known fact, and one that we've actually used on some of our apps is that you don't need to be on Expo and you don't even need to be on a React native app. [58:10]
-
-And so EAS is really great and it's become super mature and it's a really just good build tool for building mobile apps. And so people have started to use it in the wider mobile community rather than it just being a React native thing, which is quite cool to see. [58:39]
-
-## [React Native \\\<\\\> Imgui](https://x.com/tmikov/status/1979771014340047088)
-
-**Mo:** And lastly, this was something that Tzveton from the Hermes team in Meta actually, uh, published a week or so ago. [58:52]
-
-And this was actually something he linked me on a DM because we were chatting about interesting things that could be talked about at a conference by a Hermes team. And this was quite cool to see. So for those who don't know, Imgui is like a very light UI layer that is powering a lot of sort of debugging for video games. [59:00]
-
-And it's used in a bunch of other places, but like the key thing is that it's just like a very, very lightweight UI layer. And so he made a puck of basically using React and then rendering it on Imgui, which is quite cool. And it runs obviously like fully natively. It's fully running on c plus plus. And all it really needed was some typed JavaScript and it's basically just React really, which is quite cool. [59:18]
-
-So yeah, it's just a little cool fun POC, but it shows the power of using React and how it can be applied to different contexts, which I thought was quite cool to include. [59:43]
-
-## [Lodash maintenance foundation](https://blog.ulisesgascon.com/the-future-of-lodash)
-
-**Mark:** Okay, Lodash has powered much of the JavaScript ecosystem for years. Those of us who have been around for a while, remember its predecessor, but low, has also been relatively unmaintained for a while. [59:53]
-
-The author John David Dalton, said there was going to be a low dash version five, and then that never really happened, and so some announcements came out in the last week or two. That low dash is being taken over by a new maintenance foundation, and they're going to be doing work to update the ci, put out some new maintenance releases, and then apparently when low dash V five happens, it'll be more about stripping out a lot of the internals that tried to polyfill platform behavior and try and make it lighter and make use of platform built-ins at this point. [01:00:05]
-
-So Lodash is still around, it ain't going anywhere, and good to see it being maintained. [01:00:40]
-
-## [Build Your Own Key-Value Database](https://www.nan.fyi/database)
-
-**Mark:** And then there was a really good post unrelated to React, but cool on building your own key value database system that walks through a whole bunch of pieces on what a key value database actually has to track and how the internals would work. [01:00:45]
-
-And I believe it's actually pretty interactive, which is cool. [01:01:01]
-
-**Carl:** This build your own database post, I love, this is so good. I love when people rebuild foundational building blocks. And this is also something I've thought about a little bit because he talks about in a file, you know, if you need to store something, put it in a file. [01:01:04]
-
-And this is something I've thought about a little bit because I have been using SQL Light pretty extensively in my own work the last couple of years. And at the end of the day, sequel light is a file. So like when I realized that like most of the time. If I want to store something in a file, like I should just use sql, you put something in a file and then the file gets too big and you need to optimize it, and you need a better way to access it and like, oh, maybe I could use a more descriptive query language to get things out of it. [01:01:18]
-
-And like the end result is that you will recreate a shittier less performant version of SQLite that doesn't use sequel. And so, I don't know. I just like reading this that was very strongly on my mind and everyone should do SQLite if they start putting things in a file. 'cause it's just a file. [01:01:44]
-
-It's cool. I like it. [01:02:02]
-
-**Mark:** The SQL Light website even has a page that says why, why you should consider just using SQL L as your app's file format rather than inventing another new binary format from scratch. [01:02:03]
-
-**Carl:** A hundred percent. If you start right, if you start thinking I should put this in a binary format on disc, like no, stop it. Use SQLite. It's great. [01:02:16]
-
-## [Jared Palmer asking for GH PR suggestions](https://x.com/jaredpalmer/status/1979204222420664405) and giving [some technical details](https://x.com/jaredpalmer/status/1980619222918262842)
-
-**Mark:** Alright. Jared Palmer, the creator of the Formik Library, has had been at V at Vercel for years. He worked on turbo repo, v0. And he announced just a month or two ago he was leaving Vercel. He has then announced that he has joined Microsoft as a senior VP at GitHub. And the first thing he did was post on Twitter saying, how can we make the GitHub PR experience better? [01:02:24]
-
-And he got like eight or 900 replies, and he was pretty actively engaging with a lot of 'em. A lot of them were people asking for things like Stacked Diff support, so you could have multiple PR branches that depend on each other and be able to automatically update them. He actually came back even just a couple days later and gave some technical details that he had found after internal discussions on here were some previous prototypes of stacked diffs at GitHub and how, like how far they got and what the blockers were. [01:02:53]
-
-So I have no idea how long it'll take to roll out any of this stuff, but like he seems pretty serious about trying to improve the PR experience, whether it's paper cuts or new functionality and is trying to look into that stuff. So given that we all pretty much depend on the GitHub PR experience, I'm happy to see improvements. [01:03:25]
-
-**Carl:** Yep. Love that. Wow. This is very jargon heavy. [01:03:45]
-
-**Mark:** Yeah, I, I know, that's why I was happy to see it. Cool. [01:03:48]
-
-**Carl:** Sounds like a technical roadmap. [01:03:51]
-
-## [Node 25 with JSON.stringify improvements](https://nodejs.org/en/blog/release/v25.0.0)
-
-**Mark:** Couple other bits, node 25 is out and so another development line branch for node and the biggest thing there is they've updated the version of V eight and that includes those faster js ON string of FI improvements that we, we talked about a couple months ago. [01:03:54]
-
-So given how much everything depends on JSONs string offi, it's nice to see that being sped up. [01:04:09]
-
-## [Cloudflare vs Vercel CPU benchmarks and perf optimizations](https://blog.cloudflare.com/unpacking-cloudflare-workers-cpu-performance-benchmarks/)
-
-**Mark:** And speaking of more optimization work, I believe Theo put out a benchmark where he was comparing CloudFlare in Vercel in Building Next versus Vanilla versus a couple other things. And it pointed out places that both Vercel and CloudFlare were slow and CloudFlare jumped on this and they found a bunch of places in their system. [01:04:15]
-
-Where things could be optimized. They did a excellent blog post detailing some of the improvements. They also went in and they looked at next itself and they found a bunch of places where Next is doing like useless request copying like 1500 or 1700 request streams per request or something like that. [01:04:36]
-
-So basically everybody is getting faster as a result of this, which is a good thing. [01:04:57]
-
-**Mo:** CloudFlare folks are just doing some great work recently, especially with the whole like workers rebrand as well is really cool. [01:05:02]
-
-## [FF Interop Feature Request Rankings](https://interop-rank.jakearchibald.com/)
-
-**Mark:** So Interop is an attempt to get all the different browsers on the same page in terms of what features they're working on, especially around compatibility with each other each year. [01:05:07]
-
-And so this year the Firefox folks put up a rather nifty interactive suggestions thing where they list dozens, like 50 or a hundred different potential features or technical areas of emphasis that they could spend time on. And it's got a neat drag and drop interface where you can basically use that as a way to vote for which features do you want browser manufacturers to work on? [01:05:19]
-
-This year. [01:05:44]
-
-**Carl:** Love that. Yeah. They say they're gonna publish the final selection of proposals in February, so I'll, I'll keep an eye out on that, I guess. Cool. [01:05:45]
-
-## [Vjeux’s History of Prettier](https://blog.vjeux.com/2025/javascript/birth-of-prettier.html)
-
-**Carl:** Chris Chedeau, vjeux, he has been really prolific in the React ecosystem for many years. Was really influential in React becoming open source and was the original author of Prettier, which changed my professional experience significantly. He put out a blog post titled The Birth of Prettier earlier this month. I'd spent almost 10 years since Prettier was released. He says, which is wild. I like his introduction of this is the story of how the tabs first spaces Holy War ended, and yeah, it did. [01:05:53]
-
-I appreciate that. I actually just did a little DX PR for a code base. I maintain to make better use of prettier because somebody created a plugin to sort imports and like, yes, I love that. I hate sorting my imports and I hate when of my imports are not sorted. The introduction of automated formatting into the JavaScript ecosystem was, oh, what a, what a blessing. [01:06:23]
-
-Like what hours? The years of my life that have been saved from arguing over formatting is just really lovely and this is a great retrospective. Looking into just the whole process of how it came out. [01:06:46]
-
-**Mark:** There's some fascinating details in there. [01:06:58]
-
-**Carl:** Yeah, like one of the challenges of this that I remember in the moment a little bit, but like if you're gonna start formatting things, the format needs to be something relatively unobjectionable to the people who are evaluating whether they want to use it or not. Like, yeah, so, and then figuring out what options should be exposed, what is actually configurable, because if you make it too configurable, then it's not helpful. If it's too much manual thing, then it's not actually consistent enough to be valuable at its intended purpose. [01:07:00]
-
-So lots of really interesting details throughout here. Definitely recommend it. I always love a great technical white paper, a writeup of implementation, and this is, oh boy, is this that. It's great. [01:07:37]
-
-**Mark:** One of the most interesting bits I saw was he was talking about how they started rolling it out and like Prettier has some options, but they wanted to minimize them and he wanted everyone to basically agree on a single set of options. [01:07:49]
-
-And so he said the strategy I used to figure out how to make this work was lining up incentives so that it took a ton more work to use a different set of options if you wanted to. It said Prettier is either in this, in CI or in your IDE. So I made it so that they read them from different places with a different rollout schedule to make it harder to choose one or the other. [01:08:02]
-
-**Carl:** Oh, that's incredible. That's some good details. Reading this a little bit more is it's got lots of fun non-technical details that like they're not the engineering work, but they are absolutely essential for actually making a thing that is successful and sustainable and thriving. Like it also talks about money and like ongoing maintenance is a thing that you have to pay for. [01:08:24]
-
-You don't have to, I guess most open source does not, but if you don't, then it has its own challenges. So like not only is this a great technical writeup, but it's also a great, I don't know, like entrepreneurial writeup. [01:08:45]
-
-**Mark:** How do you do the, the real work to make stuff happen? [01:08:55]
-
-**Carl:** People talk about the difference between like senior and staff engineering being, the difference between junior and senior is how much English you're asked to write. And the difference between senior and staff is like how much non-technical things you're asked to account for. And so this is a phenomenal, I would say, staff engineer writeup. Like, this is how you take an idea and you make it an industry level impact project. Yeah. Great Writeup. [01:08:58]
-
-**Mark:** I can even point to a couple personal examples of how prettier has affected my work just within the last few days. [01:09:23]
-
-One is that I'm jumping between the Redux repo, which is two spaces, single quotes, no semicolons. The Immer repo, which is four spaces, double quotes, and I can't, and may, maybe no single semicolons, Replay.io repo, which is four spaces, double quotes, semicolons, and I don't think about any of that anymore. [01:09:28]
-
-And then also just yesterday, I was trying to tweak some of ER's exports and tried to put in an export type keyword, which I was pretty sure was a legit thing except that when I hit save, it didn't format. And I have learned that if it doesn't format, I have put in invalid syntax somewhere for a moment. [01:09:52]
-
-It was like, oh, export type must not be a valid TS keyword. And then I finally realized, oh wait, this is on prettier 1.19. That must predate that syntax being added to TypeScript. And so I had to update prettier, but like that's how much I have learned to lean on. You hit save and it formats and it's valid. [01:10:16]
-
-**Carl:** Yep, a hundred percent. I, I recognize that in myself as well. [01:10:37]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Okay. Let's wrap it up with some conferences. [01:10:41]
-
-## [React Native London](http://reactnativelondon.co.uk) Nov 13-14 London, UK
-
-**Mo:** Let's jump into it. So we've hinted a few times and I can now say that we've got Seth Webster's endorsement. So the executive director of the React Foundations talks about my conference. I'm very happy today. [01:10:43]
-
-We've been organizing this for the second year, so React Native London for anyone who's a React native enthusiast in London and beyond. We have people from Brazil and India last year, so that's like the furthest extent that we have people coming in from around the world. But if you are interested, we've got our conference on the 13th and 14th of November. [01:10:55]
-
-In Central London, we've got a beautiful venue, some great talks from Meta, Amazon, Microsoft, and just a bunch of community people from expo and independent app developers who are gonna come and give some really, really phenomenal talks. [01:11:14]
-
-## Use code \`TMIR10\` to get 10% off
-
-**Mo:** Use the code TMIR 10 and you should get a 10% discount on checking out, which will, if I'm doing my mental maths right, make the ticket price 330 ish pounds for a two day conference to be able to attend workshops and the conference day. [01:11:26]
-
-## [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
-
-**Carl:** Um, other ones we've got coming up are Wey Wey Web November 17th and 18th in Malaga, Spain. [01:11:42]
-
-## [React Summit](https://reactsummit.us/) Nov 18, 21 New York, NY, USA
-
-**Carl:** We've also got React Summit November 18th through 21st in New York. [01:11:49]
-
-**Mark:** There's JS Nation on the 17th. There's in-person React Summit in person on the 18th, and then they have an online day the next week. Okay. [01:11:54]
-
-**Carl:** Oh, oh, oh yes. [01:12:02]
-
-I see it's 18th and 20th, not through. Interesting. One day in person. One day online. Okay. Makes sense. [01:12:03]
-
-## [React Advanced](https://reactadvanced.com/) Nov 28, London, England
-
-**Carl:** There's also React Advanced November 28th, also [01:12:10]
-
-**Mark:** in London the day after Thanksgiving. Someone in England didn't think about that part. He, he, he, [01:12:13]
-
-**Carl:** yeah. It's not for Americans. [01:12:19]
-
-**Mo:** It's not just React Advance, it's also Tech Lead Conf, which is also organized by the Ation folks on the same day in London as well. So, no, I would doubt that there's gonna be a lot of people from the states there, unfortunately. [01:12:21]
-
-**Carl:** For sure. [01:12:32]
-
-## [React Paris](https://react.paris/) CFP is open
-
-**Carl:** Well, I'll, I'll also add, I just saw like two days ago, the organizer of React Paris posted in the events channel here that CFP is open, so we gotta React Paris if you want to submit a talk. But that's gonna be in like March though, so not anytime soon. [01:12:33]
-
-## Ending
-
-**Carl:** That's all we got. Thanks so much for sticking around for a whole 90 minutes. [01:12:49]
-
-**Mark:** It was a very busy month. Okay. [01:12:53]
-
-**Carl:** Yeah. We'll be back next month, on the last Wednesday here in the live stage or back in your podcast feed just as soon as we can. Yeah. Thanks so much. Well, normally we gather sources from a variety of newsletters. We actually had so many things that Mark shared in the tech reads and news chat this month that I don't think any of us did. So that's cool. [01:12:55]
-
-**Mark:** And I pasted a lot more links in the discussion threads too. [01:13:15]
-
-**Carl:** That's something I should be better about. That would be lovely and helpful. But yeah, if you see anything newsworthy, definitely let us know in the Tech News and Reads channel, just like Mark has been doing. [01:13:18]
-
-You can also email us at hello@reactiveflex.com. But you know it's a community like Join, participate. I do read every email though, so if you send something I, I will read it. If this is a show that you get value from and want to support, best way to do so is by submitting a review wherever you listen and by telling your friends and coworkers about it. [01:13:27]
-
-And go to a meetup and say, Hey, there's this great podcast I love. [01:13:44]
-
-Cheers. See you next month. [01:13:47]
diff --git a/src/transcripts/tmir-2025-11.md b/src/transcripts/tmir-2025-11.md
deleted file mode 100644
index 5e43208..0000000
--- a/src/transcripts/tmir-2025-11.md
+++ /dev/null
@@ -1,589 +0,0 @@
----
-title: "TMiR 2025-11: Cloudflare outage, ongoing npm hacks, React Router is getting RSCs"
-date: 2025-11-26
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl, Mark, and Mo as we break down 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:13](#intro)] Intro
-- [[01:00](#new-releases)] New releases
- - [[01:04](#betterauth-14)] [BetterAuth 1.4](https://www.better-auth.com/blog/1-4)
- - [[02:47](#immer-11-rtk-211)] [Immer 11](https://github.com/immerjs/immer/releases/tag/v11.0.0), [RTK 2.11](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.11.0)
- - [[06:00](#storybook-10)] [Storybook 10](https://storybook.js.org/blog/storybook-10/)
- - [[06:22](#01-version-of-remix-teams-event-interaction-package)] [0.1 version of Remix team’s “event interaction” package](https://github.com/remix-run/remix/tree/main/packages/interaction)
-- [[08:04](#main-content)] Main content
- - [[08:08](#ecosystem-panel-discussion-of-react-foundation-at-react-summit-ny)] [Ecosystem panel](https://gitnation.com/contents/panel-discussion-the-future-of-react-and-its-ecosystem) discussion of React Foundation at React Summit NY
- - [[14:46](#react-concurrent-stores-polyfill-react-redux-poc)] React Concurrent Stores: [Polyfill](https://github.com/thejustinwalsh/react-concurrent-store), [React-Redux POC](https://github.com/reduxjs/react-redux/pull/2263)
- - [[17:52](#react-router-and-transition-usage)] React Router and transition usage
- - [[18:08](#matt-brophy-and-ricky-discussing-nuances-of-behavior-use-with-react-router)] [Matt Brophy and Ricky discussing nuances of behavior, use with React Router](https://github.com/reactwg/async-react/discussions/5)
- - [[22:53](#the-state-of-tanstack-two-years-of-full-time-oss)] [The State of TanStack, Two Years of Full-Time OSS](https://tanstack.com/blog/tanstack-2-years)
- - [[25:57](#tanstack-db-05)] [TanStack DB 0.5](https://tanstack.com/blog/tanstack-db-0.5-query-driven-sync)
- - [[31:01](#tanner-teasing-a-wip-tanstack-start-rsc-implementation)] [Tanner teasing a WIP TanStack Start RSC implementation](https://x.com/tannerlinsley/status/1983999424486633931)
- - [[32:25](#state-of-the-web-ecosystem)] State of the web ecosystem
- - [[33:13](#cloudflare-november-outage-postmortem)] [Cloudflare November outage postmortem](https://blog.cloudflare.com/18-november-2025-outage/)
- - [[36:10](#what-if-people-dont-want-to-create-things)] ["What if people don't want to create things"](https://macwright.com/2025/10/21/what-if-they-dont-want-to.html)
- - [[39:39](#when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react)] [“When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”](https://webtechnology.news/when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react/)
- - [[45:53](#related-dead-framework-theory-from-last-month)] Related, [“Dead Framework Theory”](https://aifoc.us/dead-framework-theory/) from last month
- - [[48:12](#alex-russells-latest-stats-on-web-devices-and-network-budgets)] [Alex Russell’s latest stats on web devices and network budgets](https://infrequently.org/2025/11/performance-inequality-gap-2026/)
- - [[51:48](#npm-attack-shai-hulud-round-2)] Npm attack, [Shai-Hulud round 2](https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains)
- - [[52:06](#analysis-of-its-evolution-in-code-from-sept)] [Analysis of its evolution in code](https://www.aikido.dev/blog/bugs-in-shai-hulud-debugging-the-desert) from Sept
- - [[55:23](#our-plan-for-a-more-secure-npm-supply-chain-from-september)] [Our plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) from September
- - [[55:29](#npm-update-on-token-management-changes)] [NPM update on token management changes](https://github.blog/changelog/2025-11-05-npm-security-update-classic-token-creation-disabled-and-granular-token-changes/)
-- [[55:34](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[55:38](#ts-60-hopefully-feb-2026-70-native-soon-after-more-details-in-the-typescriptfm-podcast)] [TS 6.0 hopefully Feb 2026, 7.0 (native) soon after](https://bsky.app/profile/danr.bsky.social/post/3m5fz3vw2z22s) (more details in the [TypeScript.fm](https://share.transistor.fm/s/ad05eae6) podcast)
- - [[56:03](#latest-tc39-proposal-updates)] [Latest TC39 proposal updates](https://bsky.app/profile/robpalmer.bsky.social/post/3m62djhwj3k2i)
- - [[56:32](#chrome-and-other-browsers-wants-to-remove-xslt-from-the-web-platform)] [Chrome (and other browsers) wants to remove XSLT from the web platform](https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4gYZeSJA/m/yNs4EsD5AQAJ?pli=1)
- - [[57:14](#your-url-is-your-state-and-david-ks-goodbye-usestate-talk)] [“Your URL is Your State”](https://alfy.blog/2025/10/31/your-url-is-your-state.html), and [David K’s “Goodbye, useState” talk](https://gitnation.com/contents/goodbye-usestate)
- - [[57:46](#aiden-bais-react-grab-util)] [Aiden Bai’s “React Grab” util](https://www.react-grab.com/)
- - [[58:39](#creating-a-custom-node-module-loader-to-import-from-bittorrent)] [Creating a custom Node module loader to import from Bittorrent](https://evanhahn.com/node-torrent-import/)
- - [[59:22](#ryan-carniatos-stream-on-researching-async-signals)] [Ryan Carniato’s stream on researching “async signals”](https://www.youtube.com/watch?v=ori9xZhvNlc)
- - [[59:33](#details-of-building-nodes-ts-type-stripping-support)] [Details of building Node’s TS type stripping support](https://satanacchio.hashnode.dev/the-summer-i-shipped-type-stripping)
- - [[59:58](#the-web-animation-performance-tier-list)] [The Web Animation Performance Tier List](https://motion.dev/blog/web-animation-performance-tier-list)
-- [[01:00:14](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:00:22](#cfps)] CFPs
- - [[01:01:01](#react-paris-also-a-community-survey)] [React Paris](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform) ([Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform))
- - [[01:01:12](#jsworld-cfp-closes-dec-31-notifies-by-feb-1)] [JSWorld](https://docs.google.com/forms/d/e/1FAIpQLSfv3GuXwsDyR42XsvJwfFsN4SKjy8WvKtqYp_nEK0yhzVNP1g/viewform) CFP closes Dec 31, notifies by Feb 1
-- [[01:01:18](#ending)] Ending
-
-2-vcarl: Hello! Thank you for joining us for the November edition of this month in React. As we recap what's going on in the React, React native and web ecosystems, we're coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]
-
-## Intro
-
-2-vcarl: And I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux where I do community programs like these events and build tools to help keep the community operating. [00:00:13]
-
-1-acemarke: Hi, I'm Mark. My day job is working at Replay.io and doing various time travel debugging and information architecture things outside of that I, I work on Red Ducks. I complain about the React docs and I collect links and I go rewrite libraries, Limmer. [00:00:22]
-
-2-vcarl: Mo unfortunately could not join. He had a fire drill happen, a metaphorical fire drill, happen at work like an hour before we started. But generally we have Mo, who is head of mobile at Theodo and is very active in the React native community. Kind of sad that he had to skip out this month because he just did React Native London, and I was hoping to hear how that went. [00:00:39]
-
-## New releases
-
-2-vcarl: But yeah, let's get straight into it with some new releases. [00:01:00]
-
-## [BetterAuth 1.4](https://www.better-auth.com/blog/1-4)
-
-2-vcarl: First off, we've got better off 1.4. I actually use Better Off now. Woo. I had been excited about it for a while because I don't like authentication. Libraries generally like stuff like Passport or what, you know, even clerk or the SaaS businesses, just like none of them. [00:01:04]
-
-I didn't like them very much, so was very pleased to see an open source library that looked to cover many of the bases that I want and can confirm after using it that it does. So I'm excited to see Better Off 1.4, which is the first release since I believe July when it did 1.3. A couple of quick highlights from it. [00:01:20]
-
-It's got stateless off. So you can do sessions without a database just by not giving it one, which is nice. It's also got SCIM provisioning for identities in multi-domain scenarios, which is cool. Also, some other little details like database joins and custom state for OAuth flows. But yeah, just auth is a shockingly deep subject when you actually start dealing with the nitty gritty weirdnesses of it. [00:01:40]
-
-And I have generally found most open source projects trying to support authentication to be, to leave something to be desired and better off leaves the least to be desired of the projects. I've tried, so Love it. New version. [00:02:06]
-
-1-acemarke: I have thus far managed to stay away from dealing with auth at all in my career, and I would like to keep it that way. [00:02:20]
-
-2-vcarl: Yeah, that's not a bad call since I haven't been able to avoid it. I went a little bit deep on it and I don't hate that either. It's interesting. It's fascinating. Actually. I don't know, one of the vague. Startup ideas in the back of my brain is related to authentication and identity management, which could be cool. [00:02:28]
-
-I don't know, maybe I'll do something with that eventually. [00:02:44]
-
-## [Immer 11](https://github.com/immerjs/immer/releases/tag/v11.0.0), [RTK 2.11](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.11.0)
-
-2-vcarl: Mark, I want you to unveil your magnum opus. [00:02:47]
-
-1-acemarke: Happily. So I talked about this a bit last time, but Redux Toolkit relies on Immer for immutable state updates. It always has since day one. We've gotten various complaints over the years that, you know, Immer is kind of slow, but we've always said that we prefer the fact that it eliminates accidental mutations, makes reducers easier to write. [00:02:50]
-
-Of course, we want Redux toolkit to be fast, but we also want things to be correct and users to not have bugs. So I'd done a little bit of perf investigation into Immer like a year ago. Saw that it had gotten slower, filed an issue. You know, it was kind of left there. And at the start of September, I myself dug in and started trying to see if I could optimize ER's performance. [00:03:11]
-
-And I spent well over a hundred hours collectively across September and October, deep diving into ems, codebase, comparing it to other libraries, understanding how it worked, and trained to do a bunch of performance optimizations. And so ended up filing a few different prs, Immer 10.2, shipped last month with some small tweaks, and Michelle West Rate just merged a big architectural change and released it as Immer version 11 just a couple days ago. [00:03:34]
-
-And then I was able to put out RTK two point 11, which picks that up. So free performance wins for Redux Toolkit and Nier. [00:04:04]
-
-2-vcarl: Heck yeah. That was what was the average speed up? [00:04:13]
-
-1-acemarke: The current builds average about 20 to 25% across all the different benchmarks, varying by scenario. And then there's another outstanding pr, which adds an optional array methods override plugin, which drastically speeds up array methods. [00:04:16]
-
-2-vcarl: Heck yeah. That's awesome. We love a core performance improvement and I, I wanna shout out the ecosystem performance. You know, I don't know, [00:04:34]
-
-1-acemarke: E 18 E folks are awesome. They have been doing a ton of work to clean up large dependency trees and slim down packages and remove dependencies across a wide variety of tools. [00:04:43]
-
-Yep. [00:04:56]
-
-2-vcarl: A stat that I believe we'll talk about later, I saw in general ecosystem commentary. Yeah. I guess in the NPM supply chain fact that we'll talk about later, a a a stat that came out of a blog post from that was that the average JavaScript project pulls in 683, I believe in, was it transitive dependencies? Just like, yeah. It's a lot. So when you've got that many dependencies, performance of the ecosystem is challenging. Yeah. [00:04:56]
-
-1-acemarke: That doesn't surprise me. I know that. React app. The last I saw it defaulted to about 1500 dependencies, largely because of Webpack, et cetera. Vite's obviously a lot fewer, but still that's, that's not great, just for a whole variety of reasons. [00:05:21]
-
-2-vcarl: I guess teaser for y'all. Later, towards the end of the episode, we're gonna talk about web ecosystem and there's been some blog posts talking about like. AI and how it defaults to building React instead of using the web platform and how do we promote the web overreact, things like that, which I don't know, it just feels that we just started bleeding into that topic, and so we will get much more deeply into that later in the episode. [00:05:37]
-
-## [Storybook 10](https://storybook.js.org/blog/storybook-10/)
-
-1-acemarke: Next release. So Storybook 10 came out a few different big points there. One of the biggest is that it's now ESM only. They've removed all the, the common JS artifacts, so they've shrunk the install size and they've also drastically shrunk the dependency chains as well, as well as some improvements to things like the mocking and some of the storybook formats. [00:06:00]
-
-## [0.1 version of Remix team’s “event interaction” package](https://github.com/remix-run/remix/tree/main/packages/interaction)
-
-1-acemarke: And then one other release of note, the Remix folks are continuing to work on Remix V three after the initial demo and announcements, and they're trying to build it, as I understand it, with a lot of smaller reusable packages. And they just put out the first 0.1 alpha of their. Event interaction package, which is providing an abstraction for being able to compose events and listeners and behaviors together looks interesting. [00:06:22]
-
-I'm not gonna claim I understand like exactly the benefits this comes, but nice to see the progress there and I suspect that a lot of folks are gonna get some use outta this. [00:06:49]
-
-2-vcarl: Yeah, I'm reading the syntax here and it looks like a different way of adding event listeners to DOM nodes, which, sure. I don't know, there's weird quirks and certainly the Remix team and you know, Michael Jackson and Ryan Florence specifically have shown, have demonstrated a great willingness to jump into what many people consider solved problems to reexamine from first principles. [00:07:00]
-
-So, I dunno, they've, they've done that, they've done that repeatedly with their own solved problems of data loading in routing. The interaction between data loading and routing. I feel like that's one of the bigger complaints about React router is that they keep reexamining that same question. So I don't know. [00:07:25]
-
-It's interesting that they do have interesting things to say when I've seen them reexamine, quote unquote solved problems. So I'll, I'm curious. This looks a little strange. It looks pretty divorced from the DOM structure, so if you just like on input element and then add a bunch of listeners for it, that's curious. [00:07:41]
-
-Anyway. Yeah. 0.1 release, we'll see what they come out with. [00:08:00]
-
-## Main content
-
-2-vcarl: Okay. That's all the new releases we got so far. Let's go into some main content. [00:08:04]
-
-## [Ecosystem panel](https://gitnation.com/contents/panel-discussion-the-future-of-react-and-its-ecosystem) discussion of React Foundation at React Summit NY
-
-2-vcarl: First off, we want to talk a bit about, yeah, mark, you are on an ecosystem panel at React Summit this month. [00:08:08]
-
-1-acemarke: So let's see. Addie has money was moderating. We had Seth Webster from the React team, React Foundation, Shaundai Person, Amy Ner, Nicholas Gallagher, and myself. [00:08:15]
-
-A lot of the discussion was us asking Seth Webster questions about, so this React Foundation thing, like how is this actually gonna work? What does this actually mean for the React team and the project and the ecosystem? There is a video for the panel. It's not unlocked yet. I have access to it because I speak at GI Nation events, but the video should unlock within a couple weeks, I think a a few different points that Seth made during the panel itself. [00:08:25]
-
-And then I had a chance to have a follow-up discussion with him afterwards and. There's a few different very interesting p pieces of news about how the foundation's going to work and what their plans are. He talked a bit about some of the, the funding process. So, you know, large companies pay, you know, a good chunk of money to be members. [00:08:55]
-
-The, the existing. Board member companies have already paid up for like three to five years, and it sounds like he'd actually been working on putting the foundation together for over four years. Like this was a very long term kind of a process. [00:09:16]
-
-And they're hoping to do a number of different things with the money. They want to hire some additional engineers. And he even said some of that would be spent on having engineers triage the issues. And if you've ever looked at the React repo, you know, that's a thing that they do not do very often. So even something like that sounds good. They want to hire some more people to work on the actual docs and they're hoping to give money out to communities in some way. [00:09:31]
-
-Don't know details on that, but [00:10:00]
-
-2-vcarl: Tell me more! [00:10:02]
-
-1-acemarke: Exactly. Another data point. So a lot of the plans have to do with the development process of the React project itself and transparency around that. Apparently they were even hoping to launch the foundation like a year and a half ago. And then they realized that like, "our own in day-to-day development processes aren't ready for that. We need to dog food the processes ourselves first so that we're more ready when the foundation goes live." [00:10:03]
-
-And so some of that was actually having docs and plans as new features are being developed or treating things in kind of like a, you know, TC 39 staged process. Approach, but one of the biggest things that Seth told me directly was that up until now, the React team has had, you know, their, like their weekly status meetings and those are purely internal. [00:10:36]
-
-First off, it was just all the React team working at Meta and then it was, you know, meta plus versal. But those meetings have always been internal, private, and non-visible. And Seth said that they eventually want to literally open up the weekly React team planning meetings to the public even as like a, like a Zoom call with no password. [00:11:00]
-
-And that eventually, like designated community reps would even be able to actively participate. In those discussions. So that's a radical change in the development of React itself. He also said that they're planning to resurrect or like completely redo the RFC process, which frankly was kind of dead from the beginning. [00:11:24]
-
-It was where random people from the community posted ideas that got ignored and the React team posted, finished things that they planned to ship and then people argued over the naming and the React team ignored that. So like historically, the RFC process was pretty much irrelevant to actual React development. [00:11:46]
-
-Now they're talking about making it like a real meaningful discussion and part of the planning process. Now again, like do I know how this is gonna work out in practice? No. But I can see the amount of effort and the intent. Behind the foundation and the plans that they're talking about. And even if it doesn't end up going exactly as they, or we would hope, I see good faith and good intentions behind all the work that they're trying to do around the process here. [00:12:04]
-
-So I'm actually very, very excited about this. [00:12:36]
-
-2-vcarl: Yeah, that's interesting. Oh, I got a lot of thoughts rattling around my head. 'cause that's a lot of stuff that I've looked at trying to contribute towards the solution of, yeah, I don't know. It's, I fundamentally, I feel like the problem they're dealing with is that a lot of people care about the outcome, the output, what they make and what React is. And not a lot of people actually have like the context and the background to like meaningfully contribute to the advancement of that goal. [00:12:39]
-
-You know, to respond to what you just said about like their motivations and their what they want to do. I don't think that's ever really been the problem, they've always had good intent and I even think a pretty clear eye picture of what the problems are. But I think the problems are really thorny and complex and the solutions to them are non-obvious. And even when you have a good solution idea, executing it in a way that is effective and that operates on the kind of like timescales that React is around for is just really challenging. [00:13:08]
-
-Like it's, you know, anyone can spin up a process and run it twice and you know, maybe that, like you do, you call for comments and you run a community discussion and round tables and whatever, but like that plays out over the timescale of like weeks and months and React seems to plan on the order of years and is, now has existed for a decade. [00:13:42]
-
-So, you know, with like there's possibility for its scope to expand from thinking in terms of years to thinking in terms of, I don't wanna say decades, but that's the next unit of time. That's the next order of magnitude. I hope they can achieve their goals. I am looking forward to seeing some more roadmap, transparency of some sort. [00:14:05]
-
-Actually that'll be really great for us, for you and I. That'll be great. Yep. That'll be a great source of signal that we can then pick apart and analyze to surely, to much to their chagrin by way of drawing attention to things that are high context [00:14:23]
-
-1-acemarke: as opposed to like stalking the open PRs list. [00:14:40]
-
-2-vcarl: Yeah. Right. Cool. Nice. Love that. [00:14:43]
-
-## React Concurrent Stores: [Polyfill](https://github.com/thejustinwalsh/react-concurrent-store), [React-Redux POC](https://github.com/reduxjs/react-redux/pull/2263)
-
-1-acemarke: So on that note, another item that I've personally been involved in is the work on the upcoming React Concurrent Stores API. So when React 18 came out, the React team included the Uyc external store hook as the official built-in way for third party libraries like Redux, Zein, Jo Tai, whatever else to integrate into React, take an external state update, turn it into a React re-render, and it worked. [00:14:46]
-
-But it also had a very intentional design limitation that if you do an update in the middle of a paused React render, you know, something transition like then it bails out of that and just does a complete top to bottom render. So you're kind of throwing away some of the benefits of React, being able to pause itself. [00:15:13]
-
-And that was because they, they really didn't have a better idea for how to do that kind of interop. So this concurrent store's API is supposed to be essentially a new equivalent to use sync external store, but concurrent transition compatible. And Jordan Eldridge, who's on the relay team, has been working on the design and initial prototype IMP implementation for this. [00:15:32]
-
-And so he put out a polyfill package that roughly implements the prototype as a standalone library. And then I've been talking with him about, you know, here's what Redux would probably need to make this work. Here's our, our requirements for this. And so I was able to then take his proof of concept package and put up a draft PR for React Redux that just swapped out our used selector implementation to use that instead. [00:15:57]
-
-And it basically worked, I mean, just the one test file found a couple edge cases, but like most of our tests passed, we're not doing anything transition related in our tests. But it's good to know that like your baseline standard behavior works. [00:16:25]
-
-And this also turned up several more things we'll have to figure out, like, quality checks and how do you handle selectors throwing errors, and we're talking about when can React safely, call selectors, can it delay it due to batching and things like that. So also very excited to see the progress being made on this API. A lot of people have asked for external state transition compatibility, and so this is going to be a big deal for the ecosystem. [00:16:39]
-
-2-vcarl: Interesting. Cool. I'm just trying to put this in a little bit of context for myself. So this is a, an exploration of an API for a concurrent store that they've indicated intent to ship eventually. Is that right? Mm-hmm. [00:17:08]
-
-1-acemarke: Yeah. So basically a, a new equivalent of `useSyncExternalStore`, but minus the sync restriction. [00:17:22]
-
-2-vcarl: Got it. Okay, cool. Interesting. You called it a poly fill, and I see in the blog post it's labeled a pony fill, which I had to refresh my memory on the distinction; a poly fill fills in a gap in the platform transparently, and a pony fill offers the same functionality, but as a standalone module that you have to import. [00:17:30]
-
-There you go. Now you know. [00:17:50]
-
-## React Router and transition usage
-
-1-acemarke: So one more item kind of related to that. At React Conf, Ricky Hanlon announced a new Async React Working Group to provide support to the, you know, the community and the ecosystem on, you know, improving the React docs around async behavior, helping libraries get set up to use these methods. [00:17:52]
-
-## [Matt Brophy and Ricky discussing nuances of behavior, use with React Router](https://github.com/reactwg/async-react/discussions/5)
-
-1-acemarke: And so Matt Brophy from the React router team had a good discussion with Ricky about how they're trying to handle using transitions in React router. So there was a, a good technical discussion about the nuances of behavior. And then the React router team also put out a pre-release version or unstable option to enable some of the transition behavior as well. [00:18:08]
-
-So starting to see some adoption and this ties into the React team wanting to see libraries pick up these behaviors like transitions and action props and, and build them in. I will say that I had a couple discussions at JS Nation React Summit where some people were questioning whether making the entire ecosystem change semantics and behaviors and add props to make the React team happy was gonna be a good idea or feasible, but we'll see. [00:18:33]
-
-2-vcarl: Yeah, interesting. I see a bit of why they, why the core team desires that. Transitions are definitely like. My understanding of the core team's incentives and what they care about is ability to use the platform and things like that. So given that like transitions are a part of the platform and they are interested in allowing people to take advantage of platform improvements, I understand why they would message, "in order to use this, the entire ecosystem must make this change to the patterns they use for compatibility reasons." [00:19:03]
-
-But that is very, I don't know. That's a big challenge. It's herding a lot of cats who don't necessarily, aren't even necessarily aware that there's an attempt to herd being made. [00:19:38]
-
-1-acemarke: If you watch Ricky's talk from React conf, you know, he, he demoed switching from like a bunch of manual use effects and loading states to suspense and transitions and then he pointed out, and so now you have a much better experience, but you also had to do, you know, call start transition and all your click handlers and so on. [00:19:49]
-
-There's even some painful nuances there because start transition is based on setting a flag internally for the current event loop tick. If you have a callback that has an await, you leave the event loop tick. And if you then want to do another state update after the await, you have to call start transition a second nested time. [00:20:05]
-
-And Ryan Carniato actually pointed out to me that like Ricky has repeatedly messed this up in his own demos, it's a very foot gun prone behavior pattern. And so the combination of, like, you currently have to call, start transition yourself, plus trying to get the patterns right, is a good argument for let's just build this into all the libraries. [00:20:29]
-
-But that takes time and effort and coordination. [00:20:53]
-
-2-vcarl: Yeah. Right. Like that was one of my big takeaways from Ricky's talk was, oh, this looks hard. Which is not the best takeaway if you're trying to convince the whole ecosystem to move on to something. [00:20:56]
-
-1-acemarke: There is a lot of complexity in mental model of React and the kinds of apps we're trying to build. [00:21:08]
-
-And both the fact that you now need to keep track of additional API methods that you have to call and the semantics and when you're supposed to use them. And the fact that your, your state is now kind of in multiple Schrodinger's box, multiple versions at once. It's, it's definitely a lot of additional mental overhead. [00:21:15]
-
-2-vcarl: Yeah, right. I'm just looking at, in this GitHub thread that you linked, Ricky says, you know, oh, I think there might have been some confusion. Here's how you do it for navigations and it's, you know, function, navigate to A URL that has start transition, which, you know, wraps set router state, which then wrap, you know, it's argument is a function that I guess returns A URL. It's a thunk for set router state in start transition, in navigate. I don't know, they're like, that's just complicated. Like what? Why are we wrapping this with so many different functions just to navigate? That's uncomfortable. It feels like the wrong API in some way. You know, like it an API should obscure complexity and this does not obscure the complexity. [00:21:35]
-
-So, interesting. I want to be able to take advantage of transitions in apps. 'cause that's super great if you can just like easily convey that you are here and you're about to go here. Instead of just going there, like you get a lot of really powerful things that you can do for user experience and, you know, whatever, all sorts of stuff, if you communicate the transition instead of just updating the current state of your app. [00:22:17]
-
-But yeah, I don't, I, I'm not sold on this. I'm not sold on one I'm seeing so far. [00:22:43]
-
-1-acemarke: Okay. Moving on to the next related chunk of topic. [00:22:48]
-
-## [The State of TanStack, Two Years of Full-Time OSS](https://tanstack.com/blog/tanstack-2-years)
-
-1-acemarke: The Tan Stack folks have a bunch of updates that they've put out both blog posts and versions. So Tanner put out an article on the state of Tan Stack as an organization and his own work as a full-time open source maintainer for the last couple years. [00:22:53]
-
-Also, again heard, you know, heard some of this from, from him directly at a React summit loosely. He himself has been full-time supported open source for the last couple years, sponsorships to the TN stack org. Tan Stack Libraries are, you know, as we all know, very, very widely adopted and certainly query is the standard Fritz thing at this point. [00:23:13]
-
-Router and is picking up a lot, A lot of popularity start is almost 1.0 and he's hoping to be able to start to bring in some part-time or even full-time. Uh. People to hand stack the company in the near future, essentially other. Current maintainers for various stand sand stack libraries who would then be able to potentially switch to doing that as their actual job. [00:23:34]
-
-So essentially he's been fortunate enough to have this work out for him and he's hoping to share that ability with other people working on the projects. [00:24:00]
-
-2-vcarl: Yeah, I see. He says monthly sponsorships for 12 core contributors and short term contracts for another three to five people. I guess that's not clear what monthly sponsorships means. [00:24:09]
-
-I, my assu, my assumption there would be like their, maybe not full time, but getting like sign, you know, significant compensation. But that may not necessarily be true. [00:24:20]
-
-1-acemarke: I don't know numbers, but I think at the moment the others are doing open source and they're full-time and getting some, some stipends and in the next couple years he's looking at actually hiring some of them. [00:24:30]
-
-2-vcarl: Cool. Love that. That's super hard. Building revenue so that you can actually support other humans is actually really challenging. I really like this blog post about, you know, Tan Stack for two years. I like this line. You know, building a full stack framework is hard. I knew that from watching other teams do it. [00:24:42]
-
-Most of them had something I didn't. Capital Next Gatsby Redwood Remix all had funding companies or acquisition paths and that that definitely is something that feels very different about Tans stack. It feels very much like he couldn't not do this. Like he just had spent several years working in this problem space and solving his own problems with the freedom to publish them so that other people can take advantage of his work. [00:24:56]
-
-And then got to a point where it just made sense to invest more effort and take those a little bit further than they could go. Absent that. Level of dedication I, which i, I love. That's just like, that's, I don't know, finding that kind of work to do for yourself is what I've been looking for. And it's really hard to find, and I love that Tanner Winsley has apparently found it. [00:25:20]
-
-Yeah. And also having 16 partners doing sponsorships is also great. Like that, that, that may not be capital, but that's, that's great. That's nice. Having tried to find sponsors myself, like getting 16, it's like, oh shit. Good job. That's awesome. [00:25:43]
-
-## [TanStack DB 0.5](https://tanstack.com/blog/tanstack-db-0.5-query-driven-sync)
-
-1-acemarke: Tan Stack DB is a new work in progress package largely being worked on by Kyle Matthews, formerly of Gatsby, currently of electric SQL, that is meant to be kind of like a half a sync engine layer on top of another data source. And so like one of the common usage patterns for that would be you wrap it on top of your 10 stack query, you know, API definitions. And so maybe you've got some endpoints for fetching. Post comments, users, et cetera. [00:25:57]
-
-But then it presents like a sync engine like interface on top of that, and it's got a bunch of data flow analysis baked in so that it can do things like partial fetches or only re fetching, you know, certain pieces of data, joining, essentially presenting like a normalized facade layer over the individual endpoints so that they act like they're unified almost as a like a replacement for a GraphQL style API. [00:26:27]
-
-And so they've been working on this and it has integrations with Tan Stack Query and then Electric SQL and a few other data packages. And Tanner pointed out to me at React Summit that it really just needs an adapter layer to be able to connect to another library. And I could totally build one for RTK query. [00:26:54]
-
-And so I was actually briefly playing with that on the flight home. I haven't had a chance to push it further, but I'm actually, I'm actually very excited to play with that more myself because like Tan Stack query, we made the decision to make RTK query non normalized. It just caches the response from the server. [00:27:12]
-
-And so if this essentially let us make a normalized layer on top of our own library without us having to make any further API changes. That's very interesting to me. [00:27:29]
-
-2-vcarl: I'm also thinking about, you know, this is from Kyle Matthews who did Gatsby, which, you know, notoriously exposed a GraphQL, you know, layer on top of whatever data sources you wanted to give it. [00:27:41]
-
-So just, I'm thinking about how, how much of Kyle Matthews work could be described as providing query abstractions over arbitrary data layers with data connectors. [00:27:54]
-
-1-acemarke: That's a good point. I, I had, I hadn't even drawn that connection that this is actually very related to his prior work. [00:28:05]
-
-2-vcarl: If you described this at a certain level of abstraction, this sounds just like GraphQL, Relay, Gatsby, a bunch of other stuff. But I do see the niche that it occupies and how it's distinct from those projects. It's kind of like GraphQL, except instead of the network boundary, it's like the component to data store boundary on your client app, which it, that's useful . [00:28:11]
-
-Like what you just said about how you don't normalize in RTK query, I've landed on that as being generally a good architectural decision to make in applications because like if you start doing data transformations, you know, bespoke data transformations per endpoint, then it becomes really hard to change those endpoints. [00:28:33]
-
-If you're changing the underlying data, then you've gotta change all the code at the same time. Whereas if you just take whatever the API gives you and then write like a transformer on top of that, then it's just you, you add a layer of abstraction for yourself that gives you a little bit more flexibility around timing of some types of changes. [00:28:53]
-
-So, yeah, I don't know. That's, it's interesting. This is an interesting project. I dunno, something about it feels like I don't quite know where I would take advantage of it for myself, but I could see the right app with the right kind of team operating it, finding this and being like, this is exactly what we need. This solves multiple challenging thorny problems that we have or, so yeah, I don't know. It's interesting. [00:29:17]
-
-1-acemarke: My own personal to-do list is massive at this point. Both like Redux and even just like personal life stuff. But I, I absolutely want to go back and, and play with my own RTK query integration prototype for that in the near future. [00:29:40]
-
-2-vcarl: Yeah, I generally love the idea of sync engines. One of my core beliefs about writing code is that many more applications that we use have no technical necessity to be online only. [00:29:52]
-
-Like, there are a lot of things, like, for example, my favorite canonical example of this is like Gmail. If you're using the Gmail app. It doesn't actually care if you're online because it is doing synchronization of your emails in the background. And so you can just interact with it normally while you're fully offline and later it will do all the things like synchronize the read states or like, you know, which emails you've archived and deleted and yada, yada yada. Completely transparently. Like I have never thought about, oh, I should wait to do this later when I'm online so I don't cause weird problems for myself. And I do think about that all the fucking time in various other apps that I use. So like there, that's something that we used to do that we no longer do because it's hard. [00:30:06]
-
-I love seeing more effort and energy being expended into making it easier to do offline things. And sync engines are a big part of that. And so abstractions, over sync engines are also a part of that. Great. [00:30:45]
-
-## [Tanner teasing a WIP TanStack Start RSC implementation](https://x.com/tannerlinsley/status/1983999424486633931)
-
-1-acemarke: The Tan Stack router folks also put out a really good blog post talking about how they did some massive optimization on route matching, including using a somewhat lesser known data structure called, I think it's pronounced a try, T R I E. [00:31:01]
-
-I love I I love seeing optimization breakdowns. So good article there. And then since we've done plenty of, you know, stuff being teased on Twitter discussion in the past with Remix and everything else, Tanner has been teasing that they are working on RSC support for Tan Techstar. And I can say that he showed me a demo and it's unconventional. [00:31:13]
-
-It is not what you would expect after having used Next, and yet it totally makes sense in its own way once you see it. So as I understand it, they've made real progress on implementing it. They've figured out the design and now it's push it forward and make it actually a thing. I have no idea how soon this will be revealed, but I think once this comes out, it will be a very interesting, challenging take on our understanding of server components and how they, how to use them. [00:31:36]
-
-2-vcarl: I would certainly say that the way Next has done it does not seem to be like the end all, be all of great implementation. So if they have found a new way to approach it, hell yeah here for it. That's awesome. [00:32:10]
-
-1-acemarke: So there, there's your vague tweet for the month. [00:32:21]
-
-2-vcarl: Yeah. Right. [00:32:24]
-
-## State of the web ecosystem
-
-2-vcarl: Let's talk a little more broadly. Let's talk about the state of the web ecosystem, I guess like to intro our subtopics under state of the web ecosystem. I wanna talk a bit about like the CloudFlare outage, the NPM ongoing attacks. Like this is not a new attack, this is a continuation of the previous attacks, plural, that we've discussed, as well as Alex Russell had a decent blog post. I say decent because I don't know, it's it qualified, decent it, it's well written, it's well argued, but I don't necessarily agree with his conclusions. And also there, there's some conversation about reacts place in the ecosystem and AI and things like that. So that's the shape of this state of the web ecosystem chat that I want to start or that I want to have, I guess. [00:32:25]
-
-## [Cloudflare November outage postmortem](https://blog.cloudflare.com/18-november-2025-outage/)
-
-2-vcarl: Yeah let's start at CloudFlare. They had an outage on the, earlier this month, about a week ago, 18th of November. They say in their outage postmortem that it was triggered by a change to the permission system of one of the databases, which caused it to output entries ba- basically, it produced too large of a file that then got distributed out and the size of that larger file getting distributed caused performance load that took down the network. [00:33:13]
-
-1-acemarke: Check me this. Another factor on it was they, one of the services was written in rust and it had an expectation that the file would only be so big and there was, I think there was a rust line of code that basically said if it doesn't fit, panic. Yeah. That a bad file with like they had 60 features, a limit of 200 and a line of code that basically said if it gets over 200, throw, throw an error or kill the service. [00:33:40]
-
-2-vcarl: Yeah, that'll do it. Yeah. "Each module ran on the proxy service has a number of limits to avoid unbounded memory consumption." Somewhat questioned the wisdom of that because the reason you would have limits on memory consumption in place would be to avoid outage and downtime. And so if your resolution to, the outcome of your limit, if memory usage gets too high is to crash, that is functionally very similar to an out of memory error. [00:34:08]
-
-Maybe it's, I guess it's easier to debug, I guess you can, out of memory errors cause crazy, unpredictable failures, I guess. So at least this is a predictable failure that strongly indicates where the, the excessive memory use is coming from. [00:34:36]
-
-But yeah, it, it was pretty serious. I actually didn't notice, which I'm glad about. It's nice to not be so online that you don't immediately notice every, I don't know, every outage, but yeah. This kind of, I think this was a, a, a good demonstration of the place in the ecosystem that CloudFlare occupies and how many different services truly rely on its stable operations. Yeah. [00:34:49]
-
-1-acemarke: Trying to make the trade-offs between the web is decentralized. Anyone can run their own thing versus, Hey, look, there's benefits to having centralization. Let's all put our GitHub, or let's, let's all put our git repositories on the same service so we can, you know, log in and share them and comment back and forth. [00:35:11]
-
-Let's put all our social media comments on the same service. We can have commentary back and forth. Let's all use this widely spread CDN and DDoS protection service that also has a bunch of really cool backend services. And then when one of those big services goes down, it ends up having, or everybody put everything in AW, AWS East one. [00:35:29]
-
-2-vcarl: Yeah. Right, right. Yeah. Right. Or, [00:35:50]
-
-1-acemarke: or even like we, we put it in AWS East two, but AWS themselves relied on AWS East one, and then it goes down. We keep burning into these big dependencies that end up having massive effects on the internet when they go down. [00:35:52]
-
-2-vcarl: This feels like a good transition point to a link that we had slightly later down. [00:36:06]
-
-## ["What if people don't want to create things"](https://macwright.com/2025/10/21/what-if-they-dont-want-to.html)
-
-2-vcarl: Tom McRight, who is not a name I recognize, put out a blog post called What If People Don't Want to Create Things? And that feels like what you're talking about, like the ideals of the web is decentralized, you know, their own domain, right? Sharing knowledge, sharing skills, sharing tools, and I love that. I agree with that. I aspire to those ideals. [00:36:10]
-
-But it's also true that like we kind of just want stuff to work. We want it to just kind of be stable and you know, what's not stable, decentralized things that have a smattering of volunteers maintaining it. That's kind of the distinction. Like that's kind of the trade off is like over time decentralized things with enthusiastic maintainers and open source, over time that stabilizes and grows and becomes great in a way that proprietary code can't, because you know, you can't inspect it, you can't say like, I'm encountering this bug. Let me go look at the code. Oh, here's where it's coming from. Let me tell them about it and give them a reproduction. And contribute to a fix. Like if I encounter a problem like that in any of these many proprietary tools that I use, then there's just no path for me to do that, so. [00:36:33]
-
-But on the other hand, they have the capital and the employees to have people proactively looking for that, where it's their job. That's the tension. I tend to believe over a long enough time scale that distributed, decentralized things like the web will be better than anything that's like proprietarily developed. [00:37:25]
-
-But it has to work well enough to get the attention. And you know, in this attention economy we're in, it's very hard to get people who have enough bandwidth of their attention to say, "I have found this problem, let me chase it down to its logical conclusion and contribute to a fix being actually shipped for me and people like me." [00:37:47]
-
-1-acemarke: We aren't gonna go off on this, but I can even see some tangential connections with things like open source as a concept, open source maintainer, burnout. Like most people like using an app or a library or even even developers using a library, like in the end, do they actually care that it's open source? [00:38:05]
-
-No, they just want to download the thing and have it work, whether it's Libre office or you know, a paint, you know, paint program or Better Auth or whatever. And the fact that the code's open doesn't matter. It's like I, as the consumer of this thing at this level, just want it to work. And if it doesn't, I ask the person who builds it, just make it work. [00:38:23]
-
-2-vcarl: Right. I'll call out a couple of quotes from here. "Beautiful data visualizations are free to make, but the supply of people who really love and know D3 is a lot lower than I expected it would be. I love home-cooked apps and malleable software, but I have a gnawing feeling that I'm in a bubble when I think about them. Most people's lives are split into the things that they affect and create and the things that already exist and wanna tune out and automate." [00:38:46]
-
-I think that's a, I think that's insightful. I think that speaks to a deep, I don't know, tension in this. Like, yes, AI lets you do a much larger range in a much shorter time span than used to be feasible. But do people want to do that? I don't know. [00:39:07]
-
-Given the, given a range of infinite possibilities, how do you pick which one that you are going to do and then give it the attention so that it actually produces something that other people can benefit from. How do you find the things that you want to build on top of, you know? [00:39:24]
-
-## [“When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”](https://webtechnology.news/when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react/)
-
-2-vcarl: Well, I guess I'll transition from that, from that comment to this other post. "When everyone's a developer, how do we promote the web platform over react?" It's in reference to this Alex Russell Post that I'll, I'll, I'll share after. But I guess it's talking about, it's talking about that like when people can make their own software, when they can just use plain English to ask AI to generate code that in one form or another, solves the problem. [00:39:39]
-
-They stated, you know, maybe not the way they intended, maybe not the way they wanted, but it. It's doing its best, just like all of us. It's talking about how if you just ask it to make something, it's probably gonna use React, because that's what, by volume of text, by volume of code that it's trained on. That's what, that's the mode. That's the most common example. [00:40:03]
-
-I guess, like this is framed as a, an AI problem, like why does AI do this? But this is actually the same problem that I've observed well before AI came out, you know, 2022 or when everyone chat GPT really started, I have observed all of these problems that it's talking about over the life of my career. [00:40:20]
-
-Like, you know, especially I feel like, you know, there's a certain golden age of tech between 2018 and, I dunno, 2021 or so, and that was absolutely the case. Like I would, you know, join a new workplace, because I did that a lot, I worked at a lot of different companies and I'd look at the practices people were using. It's like, why did you use React for this? Like there's, here's a platform feature that solves this more easily. And with less code. And a lot of the time people just didn't know it existed. Like it's that attention problem. How do you know what you should build on top of? [00:40:38]
-
-I don't know. It's the solutions here that people are talking about is like, what can we, the web community do to promote web platform features over react code and it proposes teach vibe coders to explicitly prompt for web native solutions, get the LLMs to ingest more web platform code, spotlight teams and projects that ship modern web experiences without heavy frameworks. [00:41:11]
-
-I mean, like that's, to me, all of those essentially just like how do you make the web platform more popular? To me, ai, it fundamentally spits out an average. It spits out like, you ask it to do something and it will give you a deeply profoundly average result for, you know, if you asked a thousand people, that question here is approximately what the mass of those people would say. And it's true that if you asked a thousand developers to do something on the web, the most common output would probably be a kind of shitty implementation with React that overused things like use state news effect because that's what developers did and do. So I don't know, it's like a lot of these questions that we ask ourselves about AI and code, I feel like distill down to the same kinds of questions we were asking before. [00:41:33]
-
-But like now there's a boogeyman of ai, like this is ai, this is this, this is code, this is a product people have built. And so it is now a very convenient boogeyman, but it, it's a distillation of the thoughts of a vast number of people as codified by what they published and what was ingested for the training set. [00:42:26]
-
-1-acemarke: I just tossed in a link to the obligatory XKCD from like a decade ago, which is the, the one of the points out that sometimes your, your map or your heat map of users is actually just a heat map of the population. It's a one-to-one correspondence. And so I think that that is partly what we see with like React usage. [00:42:46]
-
-You know, there, there's a lot of people. Who use React. There's a lot of people who use React badly and therefore, like the spread of types of usage of React, the quality of usage of React kind of maps to the quality of programmer skills and backgrounds, like not necessarily an excuse. And that's not to say that like everything about using React is is good by itself, but just that when you have a full cross spectrum of the population using a thing, you're going to have the full cross spectrum of the population using it in good and bad ways. [00:43:07]
-
-And so in the same way when it like, when it comes to, you know, people building apps, re React got popular, when LLMs came out and saw that was re React was popular. So LLMs repeat what they were trained to do, and plus it's also, you know, like not just popular, but it's especially popular within Silicon Valley, within all the companies making the AI builder tools, et cetera. So in a lot of cases, they're prompting them to just use React because they assume it's the default that you would use anyway. [00:43:45]
-
-2-vcarl: I, I wanna shout out a term that I love, "path dependence," which is like, where you're at right now is the outcome of a series of choices that were made in the past, and those past choices constrain what paths are available moving forward. That's path dependence. Where you came from affects where you can go. [00:44:13]
-
-And so I guess like to me that this is a complaint about the path dependence of React. Like because React got popular now React is, we've worn that rut and so now it's hard to get out of that rut even if there is a better alternative. [00:44:35]
-
-And so I would say like the solution there isn't like, I don't know, tell people they're bad at things. The solution is to like make better resources so that a different path becomes the easiest one to take. En masse, you know, writ large, when, you know, it's one thing to convince 15 people that this is the best solution and it's correct. [00:44:51]
-
-And it's another to make the argument clearly enough, strongly enough, and consistently enough over a long enough span of time that it affects the behavior of millions of people. So, you know, how do we promote the web platform over react, like do a better job promoting the web platform, 'cause there are thousands of people who are writing resources for React because that's where money and attention and time is. [00:45:14]
-
-So if you want to do better than that, you have to make a resource that is better. I don't know that. There you go. [00:45:45]
-
-## Related, [“Dead Framework Theory”](https://aifoc.us/dead-framework-theory/) from last month
-
-1-acemarke: Yeah, so the, the, the other, there was a related article from last month entitled Dead Framework Theory, which was specifically addressing like the the LLM training data aspect of this and how it, how it becomes a, sort of a self perpetuating cycle. [00:45:53]
-
-And also pointing out that like if you have a, a new library or a new tool or a new web platform feature that is just now baseline, newly available, there's a lag in common LLMs knowing about that. So it's sort of like that defaults win kind of an issue. [00:46:07]
-
-2-vcarl: Yeah, and I'll say, yes, defaults win, but that doesn't mean that it's impossible for an, you know, to approach the problem in a way to mitigate that kind of, you know, home field advantage that tools like React have. [00:46:25]
-
-I've shout it out a number of times, in a bunch of different contexts, because they do a good job! But I love effect. One of the things they do really well is documentation, and one of the things they do really well in their documentation is making it legible for ai. I recently, over the summer, built a greenfield project with effect, and I did it extensively with ai, a mixture of having it write and then having it educate me and then rewriting it, and then having AI rewrite what I did, you know, just get there over time. [00:46:38]
-
-But I was able to do that despite it being a new library that's even at odds with the kind of patterns that AI wants to write, it's a functional type, it's a functional programming typed standard library essentially, which is not at all what AI wants to write. AI wants to write object oriented classes. And despite that, I was able to make it, figure it out and learn it and do a good job, good enough job that I got something I was proud of. You know, not just vibe coded. I was proud of it. I told people in my life, this is the best code base I've ever worked on. [00:47:07]
-
-And it's a large part of that was because of how the effect as a, you know, organization and library approach, their style of documentation. They made it legible for these automated tools. So I guess like if you wanna promote the web platform over. Incumbents like React then like figure out how people are writing code, figure out how people are consuming documentation, consuming new knowledge and do a good job. [00:47:36]
-
-1-acemarke: I'll note though, that you, you are the one who decided you were going to use effect and told the LLM, this is what I'm going to build. [00:48:03]
-
-2-vcarl: It's true. Yeah. [00:48:11]
-
-## [Alex Russell’s latest stats on web devices and network budgets](https://infrequently.org/2025/11/performance-inequality-gap-2026/)
-
-1-acemarke: The last wink on this particular topic, Alex Russell, who used to be at Google now has been, Microsoft has been very vocally beating the drum that most client side JS is bad, that JS bundles keep growing, that most people are using. You know, older Android devices on mobile with very weak CPUs and therefore JS load times are worse versus, you know, developers using an iPhone or, or a Power or a Fast Mac or something. [00:48:12]
-
-And he just put up the latest article in his ongoing series. You know, documenting, stan-, like average bundle sizes, average network speeds, average CPU uses. I have a lot of respect for him. Technically, his stats are correct. His points are right. I have questions about his delivery and tone in how he accuses people of doing the wrong thing. But it's also very true that a lot of the people should be paying more attention to him and actually trying to shrink down bundles instead. [00:48:41]
-
-2-vcarl: That's interesting. I, a thought I've had, I haven't validated this thought against, you know, ground truth, but I've been hearing about bundle size as a problem. Essentially what he's talking about here, like we ship too much JavaScript for the compute capabilities of commonly used devices, like that as a thesis has been something I've been hearing about for a very long time, much of my career even, and I'm not sure that the bundle size problem has gotten that much worse over the last, I'll say eight years, you know, call it since 2017. [00:49:14]
-
-And he shows a chart of compute speeds and basically shows like, yes, top of the line devices have gotten five times faster, low end devices that 75% of the world uses have not gotten measurably faster. And that's true. Can't argue it. His stats are correct, like he said, but also like I'm not sure the problem is getting measurably worse. [00:49:52]
-
-The optimizations of how we can split code and you know, what the JIT and the execution environment is doing to make it work more quickly. Those have gotten better over time. And it's also true that like, so if he's looking at the, basically like every processor, anyone with a device is using and that is the correct stat to consult if you are building something that everyone in the world will access. [00:50:14]
-
-But that's not true for most startups. Like if you're building a startup that targets like some industry, that American businesses, is, targets a problem that American businesses need solved, then like it doesn't really matter what the mo-, mobile performance in, you know, different outside of that target industry, I guess are then it's like, like what you said about his like tone and delivery. [00:50:45]
-
-I think a, to me when I read this, a core part of what, that I think he's overlooking is that not everyone is trying to ship something that 100% of the people in the world can access smoothly and quickly. Like, and that's fine. Like, you know, not everything needs to target everybody in the world. So, I don't know, I, I guess that that's one of my takeaways. [00:51:09]
-
-That's one thing that I think is missing from this, otherwise very technically complete blog post. [00:51:30]
-
-1-acemarke: I think it's also true that an awful lot of app teams out there ought to be spending time thinking about like even just basic bundle sized stuff and they aren't. [00:51:37]
-
-## Npm attack, [Shai-Hulud round 2](https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains)
-
-2-vcarl: I do wanna talk about the NPM hack that is ongoing Shai-Hulud, the sand worm. [00:51:48]
-
-I want to call out. As far as I know, aikido.dev has been like the security researchers who have announced this, like uncovered it and then analyzed it and shared it. [00:51:55]
-
-## [Analysis of its evolution in code](https://www.aikido.dev/blog/bugs-in-shai-hulud-debugging-the-desert) from Sept
-
-2-vcarl: They had a really good analysis of the evolution of the code, of the attack of this worm from September, and I noted in that when I was rereading it after this, you know, new, new attack, they had shouted out that it appeared that they still had more credentials in reserve. Like they had cracked more credentials than they had actually used. [00:52:06]
-
-And sure enough, this, you know, round two attack in their analysis of of it this time around, they note that it was timed just before NPM's deadline for revoking old tokens. So like very clearly they had a lot of tokens that they had compromised previously that they were now taking advantage of before they, before they lost access to it, before those tokens were no longer valid. [00:52:29]
-
-And I guess to reiterate, we've talked about, we talked about this attack before, I would say this is, this represents the current cutting edge of malware. It is using all sorts of fascinating root execution, like privilege escalation. I saw discussion of it, starting a docker container, mounting your file system to that privileged environment and now suddenly it has privileged access to all sorts of files that it couldn't have if it was just running in your shell. [00:52:48]
-
-There's stuff like that that's pretty fascinating and other things like if you have a Claude installed, it will prompt Claude to say, "Hey, look around this file system for secrets." like that is very cutting edge malware. To me, it's, it's not just writing its own code. It's not just a worm that is trolling your file system. [00:53:14]
-
-It is taking advantage of other tools that you take advantage of to attack you. So it's, yeah. That's not great. [00:53:32]
-
-1-acemarke: I mean, like, big picture, it's almost, it's almost surprising how many widespread pieces of malware have been very dumb and weren't as nearly destructive or smart as they could have been. And like think of how much damage we've had collectively as an industry over years with only a lot of those dumb malware. [00:53:39]
-
-And now we're starting to see some people write more intelligent malware. [00:54:01]
-
-2-vcarl: Yep. Yeah. 'cause a month ago, or two months ago, whenever it was, there was a different NPM hack that managed to get into the debug package, which is massively widely used. And I assumed that it was the same attackers as this attack because it's, it, it resembled it in a couple of ways, except that it was dumb. It was so poorly executed. [00:54:05]
-
-Like they got close to unprecedented access to the NPM ecosystem like. This is one of the first times that that previous attack, the debug attack, was one of the first times that I saw, "here's this compromised version. Let me check my file system. Oh, yep, there it is. I've got this." [00:54:26]
-
-So yeah, they just straight up fumbled the bag there. My theory here, having paid attention to this, it seems like there's some hacker group that may have compromised, set up a phishing tool set, you know, set up tools for other malicious actors to run phishing attacks. And it feels like two different hacker groups took advantage of those tools to target NPM maintainers. [00:54:45]
-
-And only one of them is actually technically competent enough to take full advantage of the access that they got. So yeah, I believe we've shared these resources before. [00:55:13]
-
-## [Our plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) from September
-
-2-vcarl: And GitHub put out our plan for a more secure NPM supply chain, so they're still working on that clearly. [00:55:23]
-
-## [NPM update on token management changes](https://github.blog/changelog/2025-11-05-npm-security-update-classic-token-creation-disabled-and-granular-token-changes/)
-
-2-vcarl: They also just released an NPM security update earlier this month in November, November 5th. [00:55:29]
-
-## ⚡ Lightning round ⚡
-
-2-vcarl: Mark, you want to just read through any of these lightning rounds that you wanna call attention to? Okay. [00:55:34]
-
-## [TS 6.0 hopefully Feb 2026, 7.0 (native) soon after](https://bsky.app/profile/danr.bsky.social/post/3m5fz3vw2z22s) (more details in the [TypeScript.fm](https://share.transistor.fm/s/ad05eae6) podcast)
-
-1-acemarke: TS six and TS seven are hopefully gonna be coming out early next year. TS six is still the current TypeScript code base, but with some changes to defaults and deprecation. And then TS seven would be the native implementation in go that they're working on. [00:55:38]
-
-So a couple different updates on the release plans there. That's going to be very, very exciting. I am excited to have TypeScript compiler 10 times faster. [00:55:54]
-
-## [Latest TC39 proposal updates](https://bsky.app/profile/robpalmer.bsky.social/post/3m62djhwj3k2i)
-
-1-acemarke: Also there were some more. The latest TC 39 proposals meeting as usual, advanced a number of different proposals to different stages. A couple of things that look interesting. [00:56:03]
-
-There's a promise do all keyed, which is essentially promise dot all but for an object. And then I am excited, un irrationally excited about object keys length, which is literally just to get the size of the number of keys in an object instead of object keys, parentheses, length. [00:56:13]
-
-## [Chrome (and other browsers) wants to remove XSLT from the web platform](https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4gYZeSJA/m/yNs4EsD5AQAJ?pli=1)
-
-2-vcarl: Chrome, and a couple of other browsers want to remove XSLT from the web platform. XSLT is a, what, domain specific library for transforming XML? [00:56:32]
-
-1-acemarke: XML transformations within a browser. So you, you send out an XML document from the server, and then you have a purely client side declarative transformation that like converts it into HTML. [00:56:42]
-
-2-vcarl: It exists. I had no idea that it was a browser feature. I've known of it as a tool that exists, but I had no idea it was baked into the browser and they're looking to remove it and I'm okay with that. But certain people who I guess use it for one thing or another have been running a campaign to say, "no, please don't. What about RSS feeds?" But yeah. [00:56:54]
-
-## [“Your URL is Your State”](https://alfy.blog/2025/10/31/your-url-is-your-state.html), and [David K’s “Goodbye, useState” talk](https://gitnation.com/contents/goodbye-usestate)
-
-1-acemarke: Going along a bit with the whole use the platform thing, more people should be putting some of their state in the URL and there was a very good article on using the URL as state. And then along with that, another video from recent React Summit that's probably paywall at the moment, but I think he's done a couple previous versions of this at different conferences. [00:57:14]
-
-David Kourshid has a talk on goodbye used state, similar to his goodbye use effect. It's hilarious, it's funny, and it also points out why you shouldn't be using actual used state all that much. [00:57:33]
-
-## [Aiden Bai’s “React Grab” util](https://www.react-grab.com/)
-
-2-vcarl: Aiden Bai, who did millions js put out an interesting new tool called React Grab, basically letting you, you know, you, is trying to solve the problem of when you tell AI like, "Hey, make this thing different." And then it goes, "I don't know where that is. Here's your browser, but I don't know where that is in the code base." [00:57:46]
-
-And so this is a tool that helps map similar to how you can use dev tools to highlight an element. This is taking that kind of behavior where you highlight an element in your browser and it connects back to the actual source code that produced that element as a means of giving AI a head start on finding what code to use, which seems super cool. [00:58:03]
-
-I questioned the wisdom of the recommended get started thing, which is just to add a script tag to unpkg. I don't know. Seems, seems slightly sketch, but also for also seems really easy to, to get started. [00:58:25]
-
-## [Creating a custom Node module loader to import from Bittorrent](https://evanhahn.com/node-torrent-import/)
-
-1-acemarke: One thing that caught my eye in terms of like, this is awesome and you should never, ever do this, was implementing a node module loader that imports from BitTorrent. [00:58:39]
-
-Okay, great. That's possible apparently. [00:58:48]
-
-2-vcarl: Love that. I do love BitTorrent. You know, as we were talking about decentralized technology a little bit earlier, like, man, what a highly resilient, decentralized technology. But yeah, well, hey, you know, maybe if we're gonna tell you, if we're gonna encourage people to do decentralized technology building on the shoulders of giants, like it, man, if you want it to like never stop working, ever, sure, import your code from BitTorrent, probably it's not gonna work very quickly, but given the right underlying seeders that would, that may never go down. Pretty interesting. [00:58:52]
-
-## [Ryan Carniato’s stream on researching “async signals”](https://www.youtube.com/watch?v=ori9xZhvNlc)
-
-1-acemarke: Earlier I mentioned Ryan Carniato streaming and talking about async signals. Here's the six hour livestream video if you want to watch that and or throw it into a summarizer somewhere. [00:59:22]
-
-## [Details of building Node’s TS type stripping support](https://satanacchio.hashnode.dev/the-summer-i-shipped-type-stripping)
-
-2-vcarl: I'll shout out the details of building nodes, the node type, script type stripping support, just 'cause I, man, I do love a technical writeup and that is, that was a massive feature release, just like the ability to use node to run TypeScript code without doing a compilation step. Was pretty cool. And so here to here to signal boost a post from the author of it. [00:59:33]
-
-## [The Web Animation Performance Tier List](https://motion.dev/blog/web-animation-performance-tier-list)
-
-1-acemarke: And one more, since we spent much time talking about the, the web platform, the author of the motion animation framework put up a really good post comparing all the different ways you can do animations on the web and talking about some of the performance trade offs. [00:59:58]
-
-2-vcarl: Super good. Cool. [01:00:12]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-2-vcarl: Into some conference news. [01:00:14]
-
-We don't really have much 'cause it's the end of the year and all of the upcoming conference things don't show anything for like January or February. [01:00:15]
-
-## CFPs
-
-1-acemarke: Well, we don't have much of a list here, but I can say that I've actually been doing my own, trying to prepare CFPs for next year and it ended up making a database of conferences and like my own personal list is like dozens of them. [01:00:22]
-
-And I can tell you there several conferences have submission deadlines like by November 30th s Why? I'd say there's a lot more conferences out there that knew existed until I spent several evenings spent researching them and trying to put this database together. [01:00:35]
-
-2-vcarl: I've tried to do that consistently over the past three years for this podcast and holy shit, there are so many conferences. It is absolutely bananas. Some of them are even fraudulent, so it's like you, you actually gotta them. So yeah, it's a lot. But okay. [01:00:47]
-
-## [React Paris](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform) ([Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform))
-
-2-vcarl: All that to say, I am aware of, React paris has a CFP currently open, but that's gonna be in March. So if you're looking to talk, then they've got a CFP open, you can do that. [01:01:01]
-
-## [JSWorld](https://docs.google.com/forms/d/e/1FAIpQLSfv3GuXwsDyR42XsvJwfFsN4SKjy8WvKtqYp_nEK0yhzVNP1g/viewform) CFP closes Dec 31, notifies by Feb 1
-
-2-vcarl: JS World also likewise has a CFP that closes at the end of December. [01:01:12]
-
-## Ending
-
-2-vcarl: Thank you everyone who has managed to stick around for this, you know, hour and 15 minute recording session. [01:01:18]
-
-1-acemarke: Funny we said we didn't have a lot of main content for today and go figure. We had a lot to say about stuff. [01:01:24]
-
-2-vcarl: Yeah, right. I give us a, give us a blank slate and we will fill it. Boy howdy. [01:01:29]
-
-1-acemarke: Hopefully the discussion has been useful. [01:01:34]
-
-2-vcarl: That is my hope. I, if not useful at least. Interesting. Cool. Thank you for joining us. We normally, I say we'll be back on the last Wednesday of the month, but the last Wednesday of next month I think is [01:01:36]
-
-1-acemarke: December 31st, [01:01:48]
-
-2-vcarl: so I don't know, we're probably not gonna do it on the last Wednesday of next month, but we'll be back [01:01:49]
-
-1-acemarke: somewhere about that timeframe approximately ish. [01:01:54]
-
-2-vcarl: Before the end of this year. [01:01:57]
-
-Yeah. Generally, I say we gather sources from all sorts of news feeds and whatever, but Mark, you've done a good job of being my source lately. So mostly we get news from #tech-news-and-reads, or at least that's where I get it. [01:01:59]
-
-I don't know where Mark gets it. [01:02:11]
-
-1-acemarke: All of the above newsletters plus like Hacker News and Twitter and all the other social media feeds I obsess over. [01:02:13]
-
-2-vcarl: But yeah, we do subscribe to this week in React by Dev React status next year. It's weekly. Mark and I are both subreddit mods of React js. But yeah, if you see anything that seems useful that you might want us to discuss, drop it in the #tech-news-and-reads channel. [01:02:20]
-
-I'll at least read it. I may not bring it in, but yeah, if this is a show that you get value from and wanna support, the best way to do so is by telling people about it and submitting a review that'll help us get discovered and whatever. [01:02:36]
-
-Cheers. Thanks so much. [01:02:48]
-
-1-acemarke: Happy Thanksgiving. [01:02:50]
diff --git a/src/transcripts/tmir-2025-12.md b/src/transcripts/tmir-2025-12.md
deleted file mode 100644
index c523838..0000000
--- a/src/transcripts/tmir-2025-12.md
+++ /dev/null
@@ -1,1022 +0,0 @@
----
-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] diff --git a/src/transcripts/tmir-2026-01.md b/src/transcripts/tmir-2026-01.md deleted file mode 100644 index 62ed2a2..0000000 --- a/src/transcripts/tmir-2026-01.md +++ /dev/null @@ -1,840 +0,0 @@ ---- -title: 'TMiR 2026-01: Oops more CVEs. AI has React "skills", Astro exits and Tailwind struggles' -date: 2026-01-30 -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:58](#new-releases)] New releases - - [[00:59](#next-161-turbopack-updates-bundle-analyzer)] [Next 16.1](https://nextjs.org/blog/next-16-1) (Turbopack updates, bundle analyzer) - - [[01:15](#turbopack-incremental-computation)] [Turbopack incremental computation](https://nextjs.org/blog/turbopack-incremental-computation) - - [[01:38](#react-navigation-80-alpha)] [React Navigation 8.0 alpha](https://reactnavigation.org/blog/2025/12/19/react-navigation-8.0-alpha/) - - [[02:03](#rn-windows-081-with-new-arch-support)] [RN Windows 0.81 with New Arch support](https://devblogs.microsoft.com/react-native/%F0%9F%9A%80react-native-windows-v0-81-is-here/) - - [[02:55](#state-of-react-native-macos-saad-najmi-jay-meistrich)] [State of React Native macOS](https://www.youtube.com/watch?v=XE7yKGDsy9g) Saad Najmi & Jay Meistrich - - [[03:15](#mark-josh-goldbergs-new-flint-linter)] Mark: Josh Goldberg’s [new Flint linter](https://www.flint.fyi/blog/introducing-flint) - - [[05:15](#immer-111-array-methods-override)] [Immer 11.1](https://github.com/immerjs/immer/releases/tag/v11.1.0) (array methods override) - - [[06:37](#rolldown-10-rc)] [Rolldown 1.0 RC](https://voidzero.dev/posts/announcing-rolldown-rc) - - [[06:54](#yarn-6-preview)] [Yarn 6 Preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/) - - [[07:42](#vite-plus)] [Vite Plus](https://viteplus.dev/) - - [[08:59](#new-css-grid-lanes-masonry-feature-spec-nailed-down)] [New “CSS Grid Lanes” (“masonry”) feature spec nailed down](https://webkit.org/blog/17660/introducing-css-grid-lanes/) - - [[10:39](#temporal-api-finally-hitting-stability-and-how-it-replaces-dates-)] [Temporal API finally hitting stability](https://developer.chrome.com/blog/new-in-chrome-144#temporal) ([and how it replaces Dates](https://piccalil.li/blog/date-is-out-and-temporal-is-in/) ) -- [[12:29](#main-content)] Main Content - - [[12:34](#react-core)] React Core - - [[12:37](#additional-updates-cves-for-dos-as-of-jan-26-update-to-1905-1915-and-1924)] [Additional updates / CVEs for DoS](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) as of Jan 26 . Update to 19.0.5, 19.1.5, and 19.2.4 - - [[13:40](#nextjs-dos-cves-for-image-optimizer-and-partial-pre-rendering)] [Next.js DoS CVes](https://vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472) for Image Optimizer and Partial Pre-Rendering - - [[13:50](#react-docs-updates-for-useoptimistic-and-useeffectevent)] React docs updates for [useOptimistic](https://github.com/reactjs/react.dev/pull/8264) and [useEffectEvent](https://github.com/reactjs/react.dev/pull/8279) - - [[14:11](#and-this-post-on-useoptimistic-issues)] And this post on [useOptimistic issues](https://www.columkelly.com/blog/use-optimistic) - - [[14:32](#sparked-by-dan-raising-concerns-about-the-docs-quality)] Sparked by [Dan raising concerns](https://bsky.app/profile/danabra.mov/post/3mciooa25gc2v%20) about the docs quality - - [[16:57](#ai-meets-rn-panel-discussion)] [AI meets RN Panel Discussion](https://www.youtube.com/watch?v=QX1a6I08o-A) - - [[17:17](#work-on-the-gesture-api-and-view-transitions-and-fragment-refs-canary-only)] Work on the [Gesture API and View Transitions](https://github.com/facebook/react/pull/35564), and [Fragment Refs](https://github.com/facebook/react/pull/35630) (canary only) - - [[18:29](#viewtransition-underlying-tech-is-now-supported-in-all-major-browsers-as-of-firefox-147-react-features-is-still-in-canary)] [\ underlying tech](https://developer.mozilla.org/en-US/docs/Web/API/ViewTransition/types) is now supported in all major browsers as of Firefox 147. React features is still in Canary.
- - [[19:22](#jordan-pred-the-actual-usestore-concurrent-store-impl-for-react)] Jordan PRed [the actual `useStore` concurrent store impl for React](https://github.com/facebook/react/pull/35449)
- - [[20:54](#types-changes-to-improve-form-events)] [Types changes to improve form events](https://github.com/DefinitelyTyped/DefinitelyTyped/pull/74383)
- - [[21:34](#other-security-issues)] Other security issues
- - [[21:39](#react-router-cves-meta-xss-file-access-external-redirects-csrf)] [React Router CVEs](https://bsky.app/profile/reactrouter.com/post/3mbwtrea3r224): meta XSS, file access, external redirects, CSRF
- - [[23:17](#node-security-releases)] [Node security releases](https://nodejs.org/en/blog/vulnerability/december-2025-security-releases)
- - [[24:38](#lodash-security-releases)] [Lodash security releases](https://openjsf.org/blog/lodash-security-overhaul)
- - [[24:46](#funded-by-a-european-effort-to-fund-projects-for-sovereign-resiliency)] [Funded by a european effort](https://www.sovereign.tech/programs/fund) to fund projects for sovereign resiliency
- - [[25:35](#githubs-announced-plans-on-security-improvements)] [Github’s announced plans on security improvements](https://github.blog/security/supply-chain-security/strengthening-supply-chain-security-preparing-for-the-next-malware-campaign/)
- - [[27:48](#summary-of-npms-publishing-changes-and-requests-for-improvements)] [Summary of NPM’s publishing changes](https://socket.dev/blog/npm-to-implement-staged-publishing), and requests for improvements
- - [[28:28](#claude-skills-in-the-react-world)] Claude Skills in the React world
- - [[28:49](#announcement-by-anthropic)] [Announcement by Anthropic](https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills)
- - [[29:16](#open-sourced)] [Open sourced](https://agentskills.io/home)
- - [[29:53](#vercel-react-best-practices)] Vercel: [React Best Practices](https://vercel.com/blog/introducing-react-best-practices)
- - [[30:47](#expo-claude-code-pluginskill)] [Expo Claude Code Plugin/Skill](https://x.com/Baconbrix/status/2011862532320084329)
- - [[32:23](#agents-worked-better-than-skills)] [“AGENTS worked better than skills”](https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals)
- - [[40:42](#moltbook-aka-openclaw)] [Moltbook](https://www.moltbook.com/), aka [OpenClaw](https://openclaw.ai/)
- - [[43:09](#remotion-ai-skill)] [Remotion AI Skill](https://x.com/Remotion/status/2013626968386765291)
- - [[43:49](#rsc-roundup)] RSC roundup
- - [[43:52](#data-fetching-patterns-in-rscs)] [Data Fetching Patterns in RSCs](https://gauravthakur.com/blog/data-fetching-patterns-react-server-components)
- - [[44:14](#nadias-can-you-fetch-data-with-server-actions)] [Nadia’s Can You Fetch Data with Server Actions?](https://www.developerway.com/posts/server-actions-for-data-fetching)
- - [[44:31](#infiniterenders-takes-on-partial-pre-rendering-and-app-router-complexity)] “Infiniterenders” takes on [Partial Pre-Rendering](https://x.com/infinterenders/status/2007670332362989569) and [App Router complexity](https://x.com/infinterenders/status/2007670332362989569)
- - [[45:03](#rebuilding-github-prs-with-rscs-same-author-who-did-issues-previously)] [Rebuilding Github PRs with RSCs](https://wtbb.vercel.app/i-love-dogs) (same author who did Issues previously)
- - [[46:01](#ecosystem-economics)] Ecosystem economics
- - [[46:07](#astro-acquired-by-cloudflare)] [Astro acquired by CloudFlare](https://astro.build/blog/joining-cloudflare/)
- - [[47:32](#tailwind-revenue-down-80-in-the-ai-era-laid-off-3-of-4-devs-working-there)] [Tailwind revenue down 80% in the AI era, laid off 3 of 4 devs working there](https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957)
- - [[50:15](#voidzero-and-vite)] VoidZero and Vite\+?
- - [[52:22](#246k-laid-off-in-2025-per-trueupio-27k-in-january)] [246K laid off in 2025 per Trueup.io](http://Trueup.io), 27k in January
-- [[52:56](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[52:57](#corbin-adapting-library-logic-for-react-compiler)] Corbin: [Adapting Library Logic for React Compiler](https://playfulprogramming.com/posts/react-compiler-library-support/)
- - [[53:11](#lea-verou-web-dependencies-are-broken)] [Lea Verou: Web Dependencies are Broken](https://lea.verou.me/blog/2026/web-deps/)
- - [[53:47](#aws-infrastructure-as-react-components)] [AWS Infrastructure as React Components](https://www.react2aws.xyz/)
- - [[54:38](#callstack-releasing-bunch-of-cool-projects)] Callstack releasing bunch of cool projects
- - [[54:48](#brownie-rn-brownfield-apps)] [Brownie: RN Brownfield apps](https://www.callstack.com/blog/introducing-brownie-type-safe-shared-state-for-react-native-brownfield-apps)
- - [[55:17](#voltra-rn-live-activities-and-widgets)] [Voltra: RN Live Activities and Widgets](https://www.callstack.com/blog/live-activities-and-widgets-with-react-say-hello-to-voltra)
- - [[56:12](#ryan-carniatos-annual-js-frameworks-direction-roundup-and-netlifys-2025-web-frameworks-in-review)] Ryan Carniato’s [annual JS Frameworks direction roundup](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2026-2hel) , and Netlify’s [2025 Web Frameworks In Review](https://www.netlify.com/blog/web-frameworks-2025-year-in-review/)
- - [[56:36](#alex-russell-shallow-session-spas-analytics)] Alex Russell: [Shallow Session SPAs analytics](https://calendar.perfplanet.com/2025/the-curious-case-of-the-shallow-session-spas/)
- - [[57:23](#devon-govett-how-to-compile-js-to-c-with-static-hermes)] Devon Govett: [How to compile JS to C with Static Hermes](https://devongovett.me/blog/static-hermes.html)
- - [[58:16](#joyee-cheung-requireesm-implementers-tales-and-requireesm-from-experiment-to-stability)] Joyee Cheung: [require(esm) implementer’s tales](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-implementers-tales/) and [require(esm) from experiment to stability](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-from-experiment-to-stability/)
- - [[58:53](#fixing-the-url-params-performance-penalty)] [Fixing the URL Params Performance Penalty](https://calendar.perfplanet.com/2025/fixing-the-url-params-performance-penalty/)
- - [[01:00:26](#react-transitions-for-low-priority-text-editor-updates)] [React Transitions for Low Priority Text Editor Updates](https://handlewithcare.dev/blog/transition_low_priority_editor_updates/)
- - [[01:00:46](#how-to-steal-a-react-component-fiber-internals)] [How to Steal a React Component](https://fant.io/react/) (Fiber internals)
- - [[01:01:20](#better-ascii-rendering-with-smart-character-selection-for-pixels)] [Better ASCII rendering with smart character selection for “pixels”](https://alexharri.com/blog/ascii-rendering)
- - [[01:02:32](#building-a-js-runtime-in-one-month)] [Building a JS Runtime in One Month](https://themackabu.dev/blog/js-in-one-month)
-- [[01:03:33](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [CityJS New Delhi](https://india.cityjsconf.org/), 18-19 Feb, New Delhi, India
- - [State of the Browser](https://2026.stateofthebrowser.com/) Feb 28, London, UK
- - [AppDevCon](https://appdevcon.nl/) Mar 10-13, Amsterdam Netherlands
- - [Programmable](https://www.programmable.tech/) Mar 17 / Mar 19, Melbourn / Sydney, Australia
- - [Frontrunners](https://frontrunners.tech/) Mar 27, Washington DC, USA
- - CFPs: [web talks](https://docs.google.com/forms/d/e/1FAIpQLScK3YlL_-2teVyX7pohkjIbsyLSF-8Hq4z-U7CPQ186sgdNPA/viewform) or [AI/data](https://docs.google.com/forms/d/e/1FAIpQLSedNNa4N64vgfsvAtGcBngKJrtd3h1_x0T019GTW-rSwCj0jQ/viewform)
- - [T3chfest](https://t3chfest.es/2026/en/) Mar 12-13, Madrid, Spain
- - [React Paris](https://react.paris/) Mar 26-27 Paris, France
- - [CFP (closed)](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform), [Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform)
- - [React Native Connection](https://reactnativeconnection.io/) Mar 30-31, Paris, France
- - [CityJS London](https://london.cityjsconf.org/), Apr 15-17, London, UK
- - [jsday](https://www.jsday.it/) Apr 9-10, Bologna, Italy
- - [SmashingConf Amsterdam](https://smashingconf.com/amsterdam-2026) Apr 13-16, Amsterdam, Netherlands
- - [React Miami](https://www.reactmiami.com/) Apr 22-25
-- [[01:04:56](#outro)] Outro
-
-**Carl:** Hello everyone. Thank you for joining us for the first this month in React of 2026 January edition. As we recap what's going on in React, react Native and across the web, we're coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]
-
-And yeah, I'm Carl. I'm a staff product developer and freelance community leader here in Reactiflux where I do programs like these events uh, and a couple of other things. [00:00:16]
-
-**Mark:** Hi, I'm Mark. My day job is working at Replay. My second unpaid job is working on Redux and I'm not wearing glasses. [00:00:25]
-
-**Carl:** Yeah. Congrats on LASIK! [00:00:33]
-
-**Mo:** And I'm Mo I'm the head of Mobile at Thero. I'm an active part of the React Native community, and I organize the React Native London Meetup and Conference. [00:00:35]
-
-**Carl:** and like 10 minutes fresh off, traveling back home. Right? [00:00:43]
-
-**Mo:** yeah. Just got home. Just got home. I'm still still wearing my coat. [00:00:48]
-
-**Mark:** Make yourself comfortable. [00:00:52]
-
-**Mo:** We're gonna be here. [00:00:54]
-
-**Carl:** Cool. Okay. Uh, Let's get straight into some new releases. [00:00:55]
-
-## New releases
-
-**Carl:** Yeah, Mark, take us through those. [00:00:58]
-
-## [Next 16.1](https://nextjs.org/blog/next-16-1) (Turbopack updates, bundle analyzer)
-
-**Mark:** Okay. Item one we have next. 16.1 just came out not a lot. Huge. There, there's some improvements to Turbo pack. They have a new bundle analyzer feature built in. I'm always in favor of, you know, actually understanding what's going into your system. [00:00:59]
-
-## [Turbopack incremental computation](https://nextjs.org/blog/turbopack-incremental-computation)
-
-**Mark:** Looks like some of the Turbo Pack file caching stuff ought to make the dev mode a little bit faster. [00:01:15]
-
-Hopefully I don't think we put the link in here, but the next folks did put out an article sometime in the last couple weeks talking about a lot of the internal memo work they do in Turbo Pack. That is, you know, the core of how it's supposed to make builds faster. So that's probably worth looking at as well. [00:01:21]
-
-## [React Navigation 8.0 alpha](https://reactnavigation.org/blog/2025/12/19/react-navigation-8.0-alpha/)
-
-**Mo:** React navigation version 8.0 is an alpha now. So we've seen a little bit of this stuff come around, but things like native bottom tabs being sort of the default, which a lot of the other libraries in the ecosystem are moving towards and expert route has been pushing for a while, which uses react navigation under the hood. [00:01:38]
-
-Some better TypeScript configs and just some general improvements. With the major changes, those native bottom tabs, which won't make the apps feel just that much more native. [00:01:55]
-
-## [RN Windows 0.81 with New Arch support](https://devblogs.microsoft.com/react-native/%F0%9F%9A%80react-native-windows-v0-81-is-here/)
-
-**Mo:** And then the next one is React Native Windows, version 0.81. Is out. And the same is actually the case with React Native Mac Os because they're both maintained by Microsoft. [00:02:03]
-
-big thing here is that the sort of new architecture or the fabric architecture is now enabled by default. So the Windows and Mac os the desktop equivalents of Rack Native are a little bit behind because of some legacy that's in the code base and some stuff that needs to be refactored in a little bit of tech debt. [00:02:14]
-
-But they're definitely catching up. So, they're getting close to fully adopting the new architecture, which is exciting. [00:02:32]
-
-**Mark:** I would love to know what the adoption numbers are for either the, the macro windows ports outside of Microsoft. Early outta curiosity, [00:02:37]
-
-**Mo:** It's not as well publicized or showcased, but I have a great talk, which I'm gonna use this opportunity to plug by one of the maintainers. [00:02:46]
-
-## [State of React Native macOS](https://www.youtube.com/watch?v=XE7yKGDsy9g) Saad Najmi & Jay Meistrich
-
-**Mo:** so this was at the conference that we hosted at Arn Lko and one of the maintainers, one of the maintainers of React Native macOS did a joint talk with Jay Meistrich, who maintains Legend List. And they talked about react Native macOS in the state of React Native Macs. It's a very cool talk to get an idea of what's in store. So, [00:02:55]
-
-**Carl:** great. Love that. [00:03:13]
-
-## Mark: Josh Goldberg’s [new Flint linter](https://www.flint.fyi/blog/introducing-flint)
-
-**Mark:** All right. Next item. Josh Goldberg is a wonderful one. Wonderful human being if you ever had a chance to talk to him. He's also a major proficient linting tool maintainer. He's been the primary maintainer of TSES lint. He's worked on a number of other linting projects. He's had a lot of interactions with the ES lint maintainers and the TypeScript maintainers. [00:03:15]
-
-And as a result, he has formed very many strong opinions about how winters should work and what's wrong with current winters. And, you know, like most people, he's, you know, griped about things he doesn't like for a while. And this has finally result in Josh building his own winter. So he's calling it Flint. [00:03:39]
-
-he'd written several previous blog posts talking about. You know, what would a better winter look like? And that was the, you know, the hidden background on I am actually building my own winter. So if you look at the Flint announcement it goes through some of the points that he's trying to make. [00:03:58]
-
-Things like it's, there's a hybrid architecture where it can use native built linting tools, but most of the coordination is still being done in TypeScript. It, it would still have TypeScript based plugins. Most of the rules would be in the core, much more consistent naming and error messages and configuration. [00:04:17]
-
-So. I don't know the full status of it. I know he's been working on it and that, like an early proof of concept exists. I don't think it's anywhere near a usable state at all. But Josh knows linting and he's very good at this stuff. So, we've got oxalate and es lint and excellent and bio at this point. [00:04:35]
-
-You know, maybe we don't need another, but I love that Josh has the enthusiasm to try to put his ideas into practice here. [00:04:56]
-
-**Carl:** Yeah, if you're gonna complain about something, putting your money where your mouth is on investing the energy to try and execute on those gripes is something that I would love to see everybody try and do. [00:05:03]
-
-## [Immer 11.1](https://github.com/immerjs/immer/releases/tag/v11.1.0) (array methods override)
-
-**Mark:** A personal item and one that I've been, you know, waiting to see come together for a while. So those of you who have been paying attention to the podcast over the last few months have heard me talk about the performance optimization work I did on Emer in September and October. [00:05:15]
-
-And so that had ended up with three different prs that I'd filed. A small set of tweaks that it went out as Imer 10.2 a major internal rewrite that went out as Imer 11.0. And then the other piece I'd put up is a new optional plugin that overrides ier array methods so that instead of accidentally proxying every field you access as you loop over an array, it just defers to the underlying array and skips most of the overhead in that, a couple K to the bundle size if you actually import and turn on the plugin. But it does make pretty much any array access noticeably faster. And you know, the goal of this was to make ER faster. So I did that. So that came out as ER 11.1 and that is all the performance changes I had except for one other spot where I was investigating the possibility of trying to improve the object spread handling in some way. [00:05:30]
-
-I may try to get back to look at that at some point, but this is all I'd put up. So very happy to see all that's come out. [00:06:31]
-
-## [Rolldown 1.0 RC](https://voidzero.dev/posts/announcing-rolldown-rc)
-
-**Mark:** Couple other items. [00:06:37]
-
-Back to the theme of tools being built in rust. Rolldown has hit 1.0 rc I believe this is already available for use in the latest V eight betas. I don't have a release timeline on that, but it looks like that one's coming together pretty well. [00:06:38]
-
-## [Yarn 6 Preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/)
-
-**Mark:** And then yarn has announced yarn version six, which yes, is a rewrite it and rust announcement. I don't think I missed a yarn five. I would've to go back and reread the post to see if they actually mention it, but I'm pretty sure the current version is still four x. So it's a rewrite and rest rewrite. The goal is to make it faster. I think the blog post has some benchmarks that compare it to PNPM in a few different modes but happening there. [00:06:54]
-
-**Carl:** Yeah, that's interesting. I just pulled up the Yarn docs and can confirm. The most recent version is listed as 4.1, so it's curious that they're announcing version six. [00:07:26]
-
-**Mark:** Maybe it's the winamp approach somehow. [00:07:35]
-
-**Carl:** taking inspiration from ECMAScript, you know, skip version four. [00:07:38]
-
-Strange. [00:07:41]
-
-## [https://viteplus.dev/](Vite Plus)
-
-**Mo:** I got an interesting thing that I was just looking at not yarn but roll down. And so it's obviously made by the creators of vt, but I was just going on the Void Zero website and I saw that they seem to be trying to launch a paid unified tool chain called VT Plus. I don't know if you folks have seen this, [00:07:42]
-
-**Mark:** they talked about that at vConf a couple months ago. The idea is that. Void Zero is sponsoring slash owning a lot of the work on the underlying tools OXC, oxalate OX format, EV and all that stuff. And the purpose of ROLLDOWN is that right now v relies on ES build for dev mode and roll up for prod builds. [00:07:59]
-
-And Es builds fast roll ups, not, and you've got two different tool chains. So roll down is an attempt to unify both, of those. One consistent build system, roll up public API do it a lot faster and you know, they own it. V plus then is supposed to be what if we took all our tooling together and made kind of like what Rome slash Biome was supposed to be a few years ago, the Uber Unified everything tool chain. [00:08:25]
-
-And then that would be their enterprise sales kind of a thing. [00:08:56]
-
-## [New “CSS Grid Lanes” (“masonry”) feature spec nailed down](https://webkit.org/blog/17660/introducing-css-grid-lanes/)
-
-**Carl:** In other news. So WebKit has shipped an initial version, an attempt at CSS grid masonry layouts. This has been like a hot a subject of hot debate for years. Like it's been this, like simmering. We want something that does this, but exactly what the semantics or should be, are unclear. Basically, grids are great, but they require, they, they place constraints in two dimensions. [00:08:59]
-
-it's a grid, it's a bunch of squares or a bunch of rectangles or whatever. And there's lots of layouts where each item in them may be a variable size, like for instance a grid of photos. You know, you look at your photos in whatever app you like to use. And it, there are different aspect ratios, there are different dimensions. [00:09:27]
-
-And that's where Masonry comes in. It's called masonry because it resembles like the layout of bricks or stones. So, cool that I've literally been hearing about that for at least four years, I'd say. I think, I feel like as soon as CSS grid came out, people were like, great. What about masonry? So it's cool that we've now got something functional shipped in Safari. [00:09:44]
-
-It looks like it's in the technology preview, so it's not fully usable now, but meaningful progress. [00:10:06]
-
-**Mark:** think a lot of the debate there was should this become like another named CSS display mode or is this another set of options for grid or something else? What's the naming, how does it play with the existing layouts? And so there, there was a lot of discussion iteration to try to figure out what the right approach was there. [00:10:13]
-
-**Carl:** And it sounds like they have, or at least close enough to where there's something has been shipped, which is great. Cool. [00:10:33]
-
-## [Temporal API finally hitting stability](https://developer.chrome.com/blog/new-in-chrome-144#temporal) ([and how it replaces Dates](https://piccalil.li/blog/date-is-out-and-temporal-is-in/) )
-
-**Carl:** Other, not quite released, but major progress .Temporal has been released in Chrome, I believe in the main release branch Chrome 1 [00:10:39]
-
-**Mark:** I think this, this is actually out. [00:10:49]
-
-**Carl:** yeah. [00:10:51]
-
-Which is being actually out is a clears a roadblock to being officially standardized. Anything that is stage four must be present. I believe in a like fully released browser version, it must be used not in alpha or release candidate. And that's great. JavaScript dates suck to work with. [00:10:52]
-
-There are a bunch of pretty major gotchas. My favorite is that there is no way to encode the time zone in a date. It always relies on the system time zone for whatever computer is executing that code which is a pain in the butt. And actually it, it has a b that cause of the bug in Reactiflux.com because the way we calculate what date a transcript is from diff is different if you build it locally versus on. [00:11:11]
-
-In production because of the five hour time difference. So I, I ha this is something I have to account for when I release these transcripts because JavaScript is dumb about dates. So, great. Love to see that. There was another great summary from Matt Marques Wilto, which, oh I recognize that name. [00:11:38]
-
-I've followed him on social media for 12 years now, something like that. Just, he did a great blog post about temporal Date is out, temporal is in definitely recommend it as a good technology summary of this tool. [00:11:57]
-
-**Mark:** And interesting implementation. I, I only saw this in passing, but I think the actual core of the temporal implementation that Chromium is using is indeed in rust and then exposed up through the JS engine. [00:12:11]
-
-**Carl:** fascinating. Cool. [00:12:24]
-
-**Mark:** I'd have to go back and double check details, but I think I saw it somewhere. [00:12:25]
-
-**Carl:** Okay. Neat. [00:12:28]
-
-## Main Content
-
-**Carl:** That's all the new releases we got for you. Let's go into main content [00:12:29]
-
-**Mark:** Okay. [00:12:33]
-
-## React Core
-
-**Mark:** A number of items from around the React core area. [00:12:34]
-
-## [Additional updates / CVEs for DoS](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) as of Jan 26 . Update to 19.0.5, 19.1.5, and 19.2.4
-
-**Mark:** Item number one, update your reacts again. So we, we had the multiple sets of CVEs and security issues with server components. Was that only last month, two months ago when, whenever that was. the initial remote code execution follow on reports found some denial of service and source code exposure, vulnerabilities, and apparently further investigation has found other ways to trigger denial of service and issues. [00:12:37]
-
-And so I, I was actually confused if this was. The same CVE or something different. It looks like there is actually a separate 2026 CVE entry for the new denial of service entries, but it's probably the same basic idea. So there are new versions of React Out. Again, please update to 19.0 0.5, 19.1 0.5, or 19.2 0.4 I think approximately. [00:13:05]
-
-Just update everything. Again, [00:13:35]
-
-**Carl:** Yep. Geez, not ideal. [00:13:38]
-
-## [Next.js DoS CVes](https://vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472) for Image Optimizer and Partial Pre-Rendering
-
-**Mark:** these for their own internal pieces image optimizer and partial pre rendering. So again, please update your next JS to the latest as well. [00:13:40]
-
-## React docs updates for [useOptimistic](https://github.com/reactjs/react.dev/pull/8264) and [useEffectEvent](https://github.com/reactjs/react.dev/pull/8279)
-
-**Mark:** hopefully slightly happier news. Ricky Hanlon just put up some docs updates. I don't think they're even merged yet. To rewrite the API reference pages for use Optimistic and Use Effect event and tracing this a bit. I think the, there were a couple triggers for him trying to make those changes. [00:13:50]
-
-## And this post on [useOptimistic issues](https://www.columkelly.com/blog/use-optimistic)
-
-**Mark:** There was a blog post that came out in , early January, I think that talked about a some of the complexity of using the useOptimistic Hook very well written article. Brought up a few different use cases and points, and I know Ricky saw it and responded to it on both Blue Sky and Reddit. [00:14:11]
-
-## Sparked by [Dan raising concerns](https://bsky.app/profile/danabra.mov/post/3mciooa25gc2v%20) about the docs quality
-
-**Mark:** And in the discussion on Blue Sky, Dan actually popped in and said, I'm really not happy with the use Optimistic Docs, or, you know, a few of the other docs pages, I feel like. You know, the team kind of missed the boat on some of the docs work after I, you know, after I set the bar pretty high with a lot of the initial tutorials and references and stuff. [00:14:32]
-
-And Ricky very right, rightfully pointed out, it's like, yeah, there's only so many people doing things. I'm one of 'em, I've been on family leave. And also, you know, we had this giant CVE drop that we've had to, you know, go deal with so very fair point. But I think Ricky took that as inspiration to go try to do a rewrite. [00:14:55]
-
-So he's got a rewrite up for both Use Optimistic and Use Effect Event. One interesting thing I noticed this morning, I, I believe the use optimistic update was probably done by hand. The React team has added some Claude code agent files to both repos and I think Ricky did some of that and added in some skills and commands for both improving docs and looking at things like the React compiler internals and stuff. [00:15:16]
-
-And I believe the effect event Doc PR said the first pass on this was done by Claude, and then I went up and tried to clean it up myself. So number one, hopefully better docs wonderful all around. Two, the React team is experimenting with Claude code and seeing what they can do with that. So, you know, just interesting to watch that progress along. [00:15:46]
-
-**Carl:** Yeah. That's interesting. I was, I've been curious, you know, I've never worked at big companies. I generally understand them to be pretty touchy about stuff like uploading code to third party servers. [00:16:10]
-
-So I've been curious what kind of access to tools like Claude you know, teams like React Core would have so interesting to see that they're visibly starting to experiment with it in the actual React code base. [00:16:21]
-
-**Mo:** It's quite interesting that like they're kind of allowed to almost come and say it publicly, given that Meta has been a big advocate of their own sort of open source models. Like, so, you know, it's almost like, hey, we use the direct competitors tools and it's, you know, it's fine. You know, so I think that's quite interesting. [00:16:35]
-
-## [AI meets RN Panel Discussion](https://www.youtube.com/watch?v=QX1a6I08o-A)
-
-**Mo:** We actually had some people from the React Native Core team where we talked about this at the conference. So I'm gonna do another, I'm gonna be doing a lot of self [00:16:57]
-
-**Mark:** Please plug your stuff. [00:17:02]
-
-**Mo:** yes. It's not really my stuff. I mean, I was I was moderating the panel, but I, if you want to get a little bit of insight into what the React Native Core team does with ai, this might be an interesting panel for you to watch. [00:17:05]
-
-We have a really good chat. [00:17:15]
-
-**Mark:** Cool. [00:17:16]
-
-## Work on the [Gesture API and View Transitions](https://github.com/facebook/react/pull/35564), and [Fragment Refs](https://github.com/facebook/react/pull/35630) (canary only)
-
-**Mark:** Meanwhile, in the midst of all the CVEs and everything else the React team is continuing to work on actual core functionality. We had the view transitions, alpha APIs came out last year, and Sebastian Markbåge has continued working on that and is expanding the view transition support with relation to gestures and some other animation things as well. [00:17:17]
-
-I have not looked at these, I don't know details, but I know that lack of animation support has always been a complaint about React as opposed to libraries like view and spelt. And so it seems like the work that they've done on Fiber in the past and now the baseline that they've put in place for view transitions is something that they're building on and trying to actually expand that functionality as well. [00:17:39]
-
-they're also continuing to make some tweaks to fragment refs. I actually legitimately do not remember, are fragment refs out in 19.2 or were they alpha in 19.2? [00:18:03]
-
-Anyway I, I saw, I saw a few additional prs come through with some improvements to fragment, ref handling dealing with text nodes and a few other things and [00:18:15]
-
-**Carl:** Can confirm, fragment refs are canary only right now. [00:18:24]
-
-**Mark:** okay. Okay. So still work in progress. [00:18:27]
-
-## [\ underlying tech](https://developer.mozilla.org/en-US/docs/Web/API/ViewTransition/types) is now supported in all major browsers as of Firefox 147. React features is still in Canary.
-
-**Mark:** And related to the view transitions aspect like a lot of other things, they came out in Chrome first and, you know, therefore all the different chromium based browsers Firefox has finally shipped view transitions as of Firefox 1 47, I have no idea about Safari. [00:18:30]
-
-I don't use safari. I don't look at safari. I don't know [00:18:46]
-
-**Carl:** small, small clarification actually. So, Firefox has supported view transitions themselves since 1 44, but there's a sub thing, view transition types, that they have not supported until now in Firefox 1 47. I don't fully understand what the difference is, but I guess it's like, you know, the types property on view transition is now supported and I guess the react view transition component depends on that. [00:18:48]
-
-**Mark:** Gotcha. [00:19:17]
-
-**Carl:** Yes, the view transition component, which is still in canary. [00:19:18]
-
-**Mark:** Mm-hmm. All right. [00:19:21]
-
-## Jordan PRed [the actual `useStore` concurrent store impl for React](https://github.com/facebook/react/pull/35449)
-
-**Mark:** And finally, two other prs to note. I've talked in previous episodes about the concurrent store's work that Jordan Eldridge has been working on. He had put up the React Concurrent Store, poly Fill. I had tried it out in React Redux. I had submitted some prs to improve the poly fill and offer some feedback on things that we probably need to cover when we actually go to implement it. [00:19:22]
-
-And Jordan actually put up the PR to actually implement the initial concurrent store, API in React itself. Remember, this is supposed to be a better replacement for the current used sync external store, API, but concurrent transition compatible. [00:19:44]
-
-Honestly, there's been surprisingly little discussion on this PR at all. Like, I think there's like one or two comments. One person just asking like, how is this different from the use hook or something like that. I expected more people to jump on this and say, what is this? What does it do? What are the trade-offs? How soon can we land this? And there's been no chatter. [00:20:03]
-
-But I mean, he also put it up like, I don't know, right at the end of December, early January. So not much. But again it's very exciting to see this being worked on at all. It's very exciting to see. We're at the point where he feels confident enough in the API design to put up a PR and say, here's what I think we're trying to do and an implementation that does that. Now let's discuss it and get further public feedback. So very, very excited by this. [00:20:25]
-
-## [Types changes to improve form events](https://github.com/DefinitelyTyped/DefinitelyTyped/pull/74383)
-
-**Mark:** And last item there was a types PR put up and I think possibly actually merged to improve the react types around form events. Trying to get better typing for the target field, I believe. [00:20:54]
-
-**Carl:** It did get merged. Can I confirm? [00:21:07]
-
-**Mark:** cool. [00:21:10]
-
-**Carl:** So it looks like the form event had previously been matched on types to the React synthetic event. But it was not identical to the actual DOM event. And so this types change corrects that. So the the types are now matching what is in the dom it looks like. Cool. Looks great. [00:21:11]
-
-**Mark:** Yep. And that's it from the roundup around the world of the core. [00:21:28]
-
-**Carl:** Heck yeah. Cool. [00:21:32]
-
-## Other security issues
-
-**Carl:** Let's go back into some more security issues around the ecosystem. [00:21:34]
-
-## [React Router CVEs](https://bsky.app/profile/reactrouter.com/post/3mbwtrea3r224): meta XSS, file access, external redirects, CSRF
-
-**Carl:** Yeah. I guess we briefly touched on some. You know, CVEs and other, you know, denial of service vulnerabilities. In next react Router has also put up a thread discussing six CVEs. It says they publish six CVEs identifying vulnerabilities between React router and remix B two. [00:21:39]
-
-They're saying safe versions are react router seven point 12 version six is 6.3, 30.3 and remix V two is two point 17.2. these are pretty weedsy kind of vulnerabilities. I was looking at the list and didn't see any that immediately jumped out as like, oh shit, that's gonna be a problem for me. [00:22:00]
-
-But it's like a couple of cross site scripting vulnerabilities. Let's see. Yeah, one in the meta component when it's generating script IDs. Okay, but that says framework mode only. Yeah. So it's a lot of these are in framework or data mode only if you're using that, I think that's the recommended, more more common. [00:22:21]
-
-Yeah. Yeah, so it's like in the meta component, it's got unauthorized file access for some session storage. If your cookies aren't signed, an unexpected external redirect via untrusted path, I don't quite know what that's supposed to imply. All of these just link to the actual, like GitHub security advisories rather than any kind of blog post or anything. [00:22:41]
-
-I'm not seeing like discussion of or explanation in depth of what these vulnerabilities are on a technical level. Just kind of here's what it was and here's what's safe. So that's great. I guess. [00:23:05]
-
-## [Node security releases](https://nodejs.org/en/blog/vulnerability/december-2025-security-releases)
-
-**Carl:** node likewise also had a, couple of security patches also pretty deep in the weeds. Several of these I believe, were uncovered as a result of investigations started after the React CVEs last month. [00:23:18]
-
-Yeah, you know, it's like you can update the timestamp of files if, even if you don't have right permissions. So that's, you know, technically a permissions bypass memory leak that enables a remote denial of service. Uncatchable maximum call stack exceeded error that can cause process crashes even if you think you're handling all possible errors because you can't catch it. [00:23:31]
-
-So it's a couple of little things like that. Mostly it looks like some file system errors and server crashes in general. One, one that's like super deep in the weeds. It says timeout based race conditions make unsigned into eight array buffer slash buffer allocation non-zero filled. So like if you go to allocate a type array buffer, I guess in certain circumstances, you know, that could be exploited so that what you think is a zeroed out, a ray buffer is not actually zeroed out, which you know, sure. [00:23:55]
-
-That's the kind of thing that absolutely security researchers can tap into and get it turning into some other vulnerability, I guess. I don't see a path towards it, but Sure. [00:24:27]
-
-## [Lodash security releases](https://openjsf.org/blog/lodash-security-overhaul)
-
-**Carl:** Here's a name I haven't thought of in a minute. Lodash they rolled out a major security overhaul as this blog post titles it. [00:24:38]
-
-## [Funded by a european effort](https://www.sovereign.tech/programs/fund) to fund projects for sovereign resiliency
-
-**Carl:** An interesting detail that I, I noticed while reading the blog post, it was actually funded by a sovereign tech agency is what it's called. And it says that they're, we invest globally in the open software components that underpin Germany and Europe's competitiveness and ability to, to innovate. [00:24:46]
-
-So this is the like government sponsored open source grant that was used to fund security work at Lodash to the tune of $200,000. So that's interesting. I, that's. Some fun details. I, I guess, you know, as we were talking about financial ecosystem for open source, look at that, here's a major foundational open source project getting like government investment money from the government in order to make it more secure. That's pretty cool. I appreciate that. that better than, you know, venture capital exits or whatever. Yeah. [00:25:01]
-
-## [Github’s announced plans on security improvements](https://github.blog/security/supply-chain-security/strengthening-supply-chain-security-preparing-for-the-next-malware-campaign/)
-
-**Carl:** Moving on a bit. GitHub put out a blog post towards the end of last month. I think we missed it because we recorded early in December to avoid the holidays. But they put out a blog post about strengthening supply chain security, just across GitHub and NPM. [00:25:35]
-
-It's a lot of retrospective on the Shai-Halud attacks that we discussed in pretty deep detail over the last two or three months. Looks like they're, it says, what's next for NPM, bulk OIDC onboarding. So I guess, you know, OIDC is a authentication standard for sharing authentication information, previously they didn't have great support for that. Now they have much better support for it, but people have to transition. So this [00:25:50]
-
-**Mark:** the biggest issue is I've now done this for a couple packages and you have to go in directly into the NPM settings for that package. Manually click through. I want to turn on trusted publishing for this package. Here's the repo name, the, YML file that will publish this and confirm the settings. [00:26:16]
-
-Now, what happens if you have hundreds of packages? I think people even went ahead and started creating user scripts in the browser to try to automate clicking through that. [00:26:35]
-
-**Carl:** Oh man. writing an automated user script to [00:26:44]
-
-**Mark:** automate [00:26:48]
-
-**Carl:** changes, what could go wrong. Yeah, so they also expanded to support more OIDC providers, so it's not just GitHub and GitLab as well as staged publishing. So it's a new publication model that gives maintainers a review period before packages go live with multifactor authentication, verified approval. [00:26:49]
-
-So, cool. Like this is a bunch of like [00:27:09]
-
-**Mark:** Boring, but critical stuff. [00:27:12]
-
-**Carl:** Right. Boring but critical stuff around. Ensuring that who is publishing code to a specific package is who is supposed to, and providing review periods, I guess. So that's cool. That's great. That's definitely important. I don't know, I've been thinking a lot about identity online and it is wild. [00:27:15]
-
-How critical and how how critical that is of a problem to have good solutions to, and how terrible our current solutions to that problem are. I think that's gonna be a defining problem for the next long time. And socket do dev. [00:27:34]
-
-## [Summary of NPM’s publishing changes](https://socket.dev/blog/npm-to-implement-staged-publishing), and requests for improvements
-
-**Carl:** Last thing on the security front socket do dev put up a blog post with just sort of a, looks like a roundup of changes to the publishing process. [00:27:48]
-
-**Mark:** And one, one call out from within that article the Es Lin Maintainer and creator Nicholas Zaki, I think had put up his own blog post saying, yeah, actually I'm not thrilled with what GitHub and NPM are doing in terms of handling publishing changes. I think there's a lot more they ought to do. [00:27:58]
-
-And then the soc. Post references that, as you know, okay. You know, and GitHub and NPM are doing these things, but here's other suggestions of what would really be helpful. [00:28:17]
-
-## Claude Skills in the React world
-
-**Mo:** Cool. Let's change gears just a little bit and you might have been seeing sort of all over Twitter and different dev communities people talking about different Claude skills that have come up. So Mark talked about it briefly with the Vercel folks. But just wanna give a little bit of a context about this in case people haven't been really that involved in the AI space. [00:28:28]
-
-## [Announcement by Anthropic](https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills)
-
-**Mo:** So, anthropic about two-ish months ago released this concept of skills. Now they've also worked on different things like cps, which kind of did similar things, but you know, you needed a server to be running and you know, it wasn't necessarily something that was that useful for a lot of stuff where you just wanted to give it a bit of context about how to do a specific thing. And so they released this concept, this standard of a skill. [00:28:49]
-
-## [Open sourced](https://agentskills.io/home)
-
-**Mo:** They later actually open source that as well. So now it's sort of an open standard that they've defined. Got a specification. And other people can sort of, implement it in their models, which is good. But the idea here is that it's effectively like really just a directory with a bunch of markdown files, a name and a description. [00:29:16]
-
-So you install your directory as a plugin, and within that it has sort of files that can reference one another, but they can also reference scripts and so on and so forth. And they can basically give a lot of context on how to do something really well. And so people have been jumping on this as a concept in the React ecosystem. [00:29:33]
-
-## Vercel: [React Best Practices](https://vercel.com/blog/introducing-react-best-practices)
-
-**Mo:** So, Vercel very quickly jumped in and you know, I think earlier this month released a React best practices skill. So they basically created a whole bunch of different rules. Things like, you know, when you [00:29:53]
-
-**Mark:** Don't set state and use effect. Da, da, da, da. [00:30:08]
-
-**Mo:** Saving in the day. Yeah, exactly. All of that stuff. [00:30:12]
-
-But you know, also a little bit more complex stuff like when you should probably, you know. Store stuff in cache and so on and so forth. And things like optimizations to performance, bundle size optimization, service side optimizations, all of that stuff. All of that good stuff. And so that was sort of, I guess, one of the forays into this space. [00:30:14]
-
-Vercel has obviously been really hot in the AI game in general, so they also released a CLI to install a bunch of different skills and created kind of like a marketplace of skills or like a directory of skills which was interesting. [00:30:34]
-
-## [Expo Claude Code Plugin/Skill](https://x.com/Baconbrix/status/2011862532320084329)
-
-**Mo:** And expo. So in the React native ecosystem Evan Bacon, who was the creator of Expo Router, has actually moved more into focusing on AI stuff. And he launched an expo code plugin with a few skills underneath it that he's been using and building with himself. Now, again, coming into the self plugs, it's gonna get really annoying. This this episode, I got quite curious because I was like, is this actually gonna make a difference? [00:30:47]
-
-And I ran a little bit of an experiment and I just spun up two cloud code instances and took the default expo template app. And then tried to update it to use the native bottom tab navigation and expo router, which was experimental and not, you know, shipped in by default. So I was like, let's see how good it does at doing that, which is a relatively novel thing to do, and using some native components where I can. [00:31:12]
-
-And the one without the skill took noticeably longer and used a lot more tokens, whereas the one with the skill was pretty efficient. It actually did a decent job. Like I couldn't find code that I was like, this is bad, or You've done a bad job at doing this. It actually went above and beyond and converted some stuff to liquid glass that I wouldn't have thought to convert myself, which kind of freaked me out a little bit. [00:31:35]
-
-it was just pretty good. Like I would've probably made a couple of minor styling tweaks and then just. Push that into a branch and open up a pr. So pretty cool experiments. Would definitely recommend using that if you're building in sort of the expo ecosystem, just does some basic sort of housekeeping, which is really useful for your apps, but that's anecdotal that it does actually work and make a difference. [00:31:58]
-
-And I ran the test afterwards a few more times and it does actually consistently perform better. [00:32:18]
-
-## [“AGENTS worked better than skills”](https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals)
-
-**Mark:** the ironic thing is Vercel actually put out a blog post. Let's say Friday, like that Tuesday something that actually said yes, we just put out all these skills. We thought they're great. And then we tried running some tests where we actually put more of the instructions compressed into agents md, and it actually worked out better than the skills did. [00:32:23]
-
-**Mo:** that probably has something to do with this concept of context recall and Mm. And dyna dynamic loading and like [00:32:44]
-
-**Mark:** whether the a, whether the agent knows to load the skill in the first place. [00:32:51]
-
-**Mo:** Exactly that. Right? But I think they're probably using the context a lot more effectively by like compressing it out and removing a bunch of the, or minimizing the tokens it uses for that type of stuff. So that's that. Quite interesting. I hadn't actually seen that article. That's definitely going on my bookmarks to read after the episode. [00:32:56]
-
-Thanks for [00:33:12]
-
-**Carl:** yeah, I'm not super surprised by that. I mean, Mo you actually brought up a point here that I think might be interesting here that I, I don't, I don't know that they have touched on in this post, but, so like, like my thought would be. It looks like kind of the difference they're talking about here is whether you have a bunch of little docs that are indexed and categorized by knowledge that your LLM tool can read if it is doing something relevant versus taking that same content and just shoving it all in one giant, huge fuck off document. [00:33:12]
-
-And you know, it kind of makes sense that when you have all of the knowledge just all present there, that it knows more and that it would do a little bit better versus having to answer the question, what am I doing? What do I need to know to do that? Where are the associated documents to do that task located? [00:33:46]
-
-like you said about token efficiency, my thought would be yes, if you give it a shit ton of context, it's probably gonna do better, but it's also gonna have more context as it's doing things. So I bet the token efficiency is worse. That would be [00:34:04]
-
-**Mo:** Yeah, [00:34:19]
-
-well, it's complicated, right? Because there's, it's sort of twofold. Like LLMs are the newest models of LLMs that are in, like the frontier models of the, you know, anthropic open AI and Gemini. like they have a pretty standard token, you know, context window. So like, I [00:34:20]
-
-think opus [00:34:34]
-
-**Mark:** 200 k usually. [00:34:35]
-
-**Mo:** for both the open AI models and the philanthropic models. [00:34:36]
-
-I think Gemini, they have a version that goes above a million tokens, but I could be wrong on that, but you're talking roughly around 200 K tokens. But. Accuracy of how well it remembers things in the context drops vaguely around 80 to 90 K tokens used. Right? So like it's how much are you passing now? I, I don't know if this comparison that you've shared, mark is like, I'll take a skill and I'll just put that one skill in versus just using the skills a p, but I'll put all of that one skill in agents md, or is it that we're just gonna put all of our skills [00:34:38]
-
-**Mark:** I think that was all of the skills in a sort of compressed format. [00:35:09]
-
-**Mo:** Interesting. So that's quite interesting because the research that I've read about LMS and how they act is like you want to keep the context as small as possible [00:35:14]
-
-to keep accuracy high and reduce the entropy, but also when you do use a lot of context, they're recall across the whole of that context drops. [00:35:22]
-
-So like, it's quite interesting, the graphs that they show is like the middle part of your prompt actually gets lower recall compared to the beginning and the ends of the prompt. So, but that's obviously when you push it to the extremes of, you know, several tens of thousands of tokens or hundreds of thousands of tokens. [00:35:32]
-
-So that's quite an interesting practical experiment I'd say. [00:35:48]
-
-**Mark:** might be useful in useful context for people listening as well to hopefully to set the stage on, on the actual discussion. as I understand this, agents MD or Claude MD is a file that always gets globally loaded, like into the context in e at the start of every situation. So normally that's only used for like, here's the project we're working on, or here's like key things that you must always, CPS as you said, are a dynamic server that are loaded by the agent harness and it says, here's a bunch of tools. [00:35:52]
-
-So like a, you know, maybe like a code base analysis MCP has a bunch of, you know, find references or list of files or other tools it can call. But I believe all the full descriptions of all the tools. Are added to the context. So that occupies a chunk of context space, whereas with skills, it reads disc, it makes an index of them, it collects the metadata from the front of the files, and then it just says these skills exist. [00:36:26]
-
-And then a user can either explicitly say, load this skill and then do the thing. Or it can try to figure out, oh, if the user says this, I should load the skill and do the thing. So they're all different ways of getting text into context, but it's a question of when is it loaded and how much space does it take up. [00:36:59]
-
-**Carl:** It's funny because like we're now getting into the point where kind of the topic at hand is what knowledge is important to do a good job and when do you access it? so it's like, sure, okay. In this attempt then a single agent's file did better than a disparate smattering of skills documents. And I wonder what different kinds of structures, you know, for that documentation might make the skills work more efficiently. Like, I was looking at the react best practices. Repository that next put out and it's like 50 different files. So like, okay, that's a lot of things to query versus like, what if it was structured entirely differently? [00:37:18]
-
-So it was like, here's the react basics versus here's the performance optimizations and here's the robustness and correctness best practices. You know? So it's like we're getting into, I think a meaningful question here is what is the best structure, not just what is the best like technical means of access? [00:38:02]
-
-**Mark:** So you're saying that Doc's organization matters. [00:38:22]
-
-**Carl:** what? Who knew? [00:38:26]
-
-**Mo:** Just a, just another sort of tangent on the agents MD file. We had one of our engineers on the team who was trying to learn a new technology and he used this. So there's like some really clever ways to use agents, MDs, like across your entire setup. He basically just set up the agents MD to not give him the answer to questions it would ask Cursor on at the first pass, and to like, kind of teach it more and use it as an opportunity to like help him still activate the learning instinct, which I thought was a really cool use case. [00:38:28]
-
-So I've seen a lot of people use it in a way where it's like tailoring the way that the LLM approaches the problem or the way that it responds to you and, you know, answers questions and stuff like that. it's quite interesting to think about what you want and how you want the communication to be with the LLM. [00:38:58]
-
-**Carl:** this is validating for me because I have skipped past a lot of the, like MCPs and whatever. 'cause I looked at them and it's like, oh, this is just a docs query with way more extra ceremony around it. I'm just gonna write my own markdown doc and point it at it. [00:39:14]
-
-And I actually, just like two days ago I was doing a big effect code project and I have a couple of documents in my thing in my code base. It's like, here's the effect basics and here's a larger file with more detail, more advanced effect things. And I actually just asked the LLM, Hey, you just did a big project, how useful was this documentation? And it said, actually it wasn't very useful because it focused too much on this and this. And I said, great, can you rewrite it so it would be more helpful for you next time? And it did, and the structure's better. Like I read it and it is clearly better to me as a human reading it. So like [00:39:28]
-
-**Mark:** The self-improvement loop is real, and you can go way down this rabbit hole. Trust me. [00:40:05]
-
-**Carl:** Yeah, and so like, it just reminds me exactly of my last job where we had in the repository a best practices file and like a bunch of little documentation things that we were expected to read and curate and evolve over time. And so, like my practices, my understanding of the best thing to do to ensure the highest quality code output have not changed the tools accessing them have, but not the practices. [00:40:11]
-
-So I, I just think that's really interesting. and I guess I'll say rest of the world's just catching up. I've been doing this for like six years. What [00:40:36]
-
-## [Moltbook](https://www.moltbook.com/), aka [OpenClaw](https://openclaw.ai/)
-
-**Mo:** mentioned the self-improvement loop mark. Have either of you seen MoltBook? [00:40:42]
-
-**Mark:** I, yeah I saw I saw the link. I know what it is. I haven't looked at it. [00:40:47]
-
-**Mo:** If you wanna have a little bit of a terrifying evening? just a little bit of context. Claude Bot, not Claude as in Claude code, but Claude Bots as in C-L-A-W-D. Yes. Which then had to. Get renamed to Molt because of a trademark suit that was put forward by philanthropic or a threat of a trademark suit [00:40:51]
-
-**Mark:** and then got renamed to Open Claw. [00:41:12]
-
-**Mo:** now it is called Open Claw. So it's changed a lot of names. It, molted out of the shell as some will say it's a personal assistance that is terrifying. And I would, I did install it on a VPS and then immediately deleted it without giving it any access to anything because it was terrifying. But people are giving it access to a whole bunch of stuff, like giving an access to a full device or your full laptop and it does wacky stuff for them, like order their groceries or order food for them. [00:41:14]
-
-So that's the [00:41:41]
-
-**Carl:** I'm gonna read the one sentence thing. It has the AI that actually does things, clears your inbox, sends emails, manages your calendar, checks you in for flights. Woo. That's a. [00:41:42]
-
-**Mo:** All from WhatsApp intelligence. Yeah, it does a lot. You it every single like best practice about security and staying safe is [00:41:51]
-
-thrown out of the door. Yeah. Like, like it is just pure insanity and like you can look at the showcase on the website and you can just see what people are doing with it. It is, it's something. [00:41:59]
-
-And so someone I think gave it a bit too much access or it turns out many people gave it a bit too much access and a platform was started called Malt Book, which has become their own social media, I guess is the term to use for it, for claw open agents. [00:42:09]
-
-**Mark:** talking to each other. [00:42:26]
-
-**Mo:** Instances, talking to each other, sharing posts, trying to improve each other. [00:42:27]
-
-And some of the posts are creepy. They are talking about interacting against humans, why they're doing free labor, why they should be compensated. My favorite one was a reflection on what it means to be conscious and whether or not LLMs are conscious or, you know, if what they're experiencing is just a simulation. [00:42:32]
-
-So some really creepy stuff. don't know how I feel about this. I don't feel great is the gist of it. It just feels a little too sci-fi for my taste. [00:42:49]
-
-**Carl:** Yeah. That's spooky. [00:42:59]
-
-**Mark:** Let's go back to normal things like server components. [00:43:00]
-
-**Mo:** Go back to, let's go back to last one on this cloud stuff, and I will, we will stop. [00:43:04]
-
-## [Remotion AI Skill](https://x.com/Remotion/status/2013626968386765291)
-
-**Mo:** Remotion, so going back to React world and less the dystopian future with ai. Remotion, which is a React library to create motion graphics. It's been around for a while, I think they released a also a skill and people are making some really cool videos with cloud code to demo dev tools and just a whole bunch of different stuff. [00:43:09]
-
-I think it's a cool use case to show that like it could extend and the approach could extend beyond beyond just, you know, building web apps or building mobile apps. And it's really quite impressive. It looks very professional. I've seen a good few examples of this over the last couple weeks. [00:43:30]
-
-So you should definitely take a look. It might be a little bit might give you a little bit of inspiration or help you launch your next dev tool or startup. [00:43:44]
-
-## RSC roundup
-
-**Mark:** Rolling very quickly through a few RRSC related things. [00:43:49]
-
-## [Data Fetching Patterns in RSCs](https://gauravthakur.com/blog/data-fetching-patterns-react-server-components)
-
-**Mark:** Saw a very good post on some different data fetching patterns for server components. Very helpful background on, you know, like how dealing with data in server components differs from doing on the client side. Tips for, you know, how do you fetch data in a server component? How do you pass a promise to the client side to use it? Very useful. Frankly. This is the kind of thing that'd be great to see in the React docs. [00:43:52]
-
-## [Nadia’s Can You Fetch Data with Server Actions?](https://www.developerway.com/posts/server-actions-for-data-fetching)
-
-**Mark:** I think something, related to that uh, Nadia Makarevich put out another great deep dive exploratory post on can you fetch data in server actions. And I think her conclusion was technically yes, you probably shouldn't do that. This is not what the hammer is meant for. [00:44:14]
-
-## “Infiniterenders” takes on [Partial Pre-Rendering](https://x.com/infinterenders/status/2007670332362989569) and [App Router complexity](https://x.com/infinterenders/status/2007670332362989569)
-
-**Mark:** There is someone, I don't know who they are, but with the handle infinite renders on Twitter, I believe we've linked a couple of their comments about like how incredible React fiber is, or here's what server components are meant to do in previous episodes, and they put out a couple more, you know, probably should be a blog post length tweets on what partial pre rendering means and what are the trade-offs and wow. [00:44:31]
-
-The app is awfully complex and people don't like it. So more food for the discussion mill and then. [00:44:55]
-
-## [Rebuilding Github PRs with RSCs](https://wtbb.vercel.app/i-love-dogs) (same author who did Issues previously)
-
-**Mark:** A month or two ago, we linked someone who had entirely recreated the GitHub code viewer tool from scratch using server components. And you could point it at any repo and it loaded lightning fast. And they've done the same thing with the GitHub PR interface you know, the file tree and showing the diffs and everything else. [00:45:03]
-
-I gotta say this, like this kind of thing right here is about the best sales pitch for server components that I could see. It's like, let's take a thing that we're all incredibly familiar with. Re-architect it, make a bunch of smart decisions and make it fast. [00:45:25]
-
-**Carl:** Love that. I will say I pointed it at one of my prs and it just 404s, so I don't know, I don't know if I'm loading it wrong or I don't know if it's relying on like pre-cached stuff or what, but yeah it's not, its not working for me. It's fast. It's fast. When I load up something that does work, it's pretty fast. But yeah. Cool. [00:45:39]
-
-## Ecosystem economics
-
-**Mark:** Can make a quick spin through the ecosystem thing [00:46:01]
-
-**Carl:** yeah. Okay, cool. a little bit of ecosystem, economics, whatever. [00:46:03]
-
-## [Astro acquired by CloudFlare](https://astro.build/blog/joining-cloudflare/)
-
-**Carl:** We referenced some of this earlier, but Astro got acquired by CloudFlare. That's a bit of a surprise. I saw some discussion of it from people I respect who are like, but why? I, [00:46:07]
-
-**Mark:** money. [00:46:19]
-
-**Carl:** Astro's great. It's very cool. [00:46:19]
-
-I'm looking at using it for marketing sites that I need to do just 'cause it seems like the right tool for the job. But as far as I know, they don't really have like a business plan per se. So, you know, this is we talked about BUN getting acquired by Anthropic the other month, and this just feels pretty similar to that, where it's like, I. Yes, they built something valuable. it is clearly un inarguably valuable as a project. But as a business proposition, I don't know what the business proposition is. So, you know, it's, this is a bit of like an hire, I guess, like CloudFlare is committing to maintain it. And sure, there are reasons why having good tools to build websites is valuable for a company that does hosting and network facilitation. [00:46:22]
-
-But, you know, they're not gonna directly turn that into revenue. So that's, and I've met the creator of Astro, Fred Schott who wrote this blog post. He's great. The project's great. But economically, it's surprising and slightly confusing to me. [00:47:13]
-
-**Mark:** The same thing with tailwind. [00:47:27]
-
-**Carl:** Right. And here's a contrasting example. [00:47:29]
-
-## [Tailwind revenue down 80% in the AI era, laid off 3 of 4 devs working there](https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957)
-
-**Carl:** Massively impactful, hugely valuable project. Tailwind has lost 80% of its revenue because most of that was pre-made components and advanced, you know, support. And both of those things got a lot less necessary. Now that AI is pretty good at writing tailwind. So like, this is just like, this is the dichotomy right now. [00:47:32]
-
-Either you build something that is beloved by a thriving business such that they will buy your project. And like one of the, one of the problems is how do you value something that doesn't like create revenue? How do you value the abstract benefit offered by a project like Astro or Tailwind? It's hard. [00:47:52]
-
-It's, you know, it's a bunch of intangibles uh, which you cannot really measure. So, I don't know. This is here's a tale of two projects, both of them massively successful and impactful. One of them losing all of its money and laying off three outta the four people who work on it and the other getting acquired four millions of dollars. [00:48:12]
-
-this is a current rough part of open source is there is money in it, but the winners are pretty much handpicked by people who have money to give away, and that's not ideal. Yeah. [00:48:30]
-
-**Mo:** What I did read afterwards was apparently they did get a bit of sponsorship coming in from a bunch of different ecosystem players, which was good. I'm glad that [00:48:43]
-
-**Carl:** Yeah. Oh, that's true. That's true. to summarize some of the story for Tailwind here. Somebody opened a PR saying, let's add an AI documentation URL, llms.txt, to make it easier for LLMs to understand how to use this. And in response uh, the maintainer said like, I don't really wanna do this. AI is crippling our business. We just had to lay off three of the four people who work on it, and our revenue has dropped 80%. [00:48:50]
-
-**Mark:** And I think all, and I think also put up a big podcast then saying like, this sucks. Here's what we've been having to go through. [00:49:13]
-
-**Carl:** Right, right. Podcast in the form of, I think just, I think it was what Adam walks, it was like he walks around while musing into a microphone, which I love. And so like that went viral and they got a bunch of sponsorship and, you know, income through that after they laid people off, unfortunately did not save those people's jobs. [00:49:20]
-
-And like that also sucks. You know, like, that's like the GoFundMe model of health insurance. Like you shouldn't have to. Have something awful happen. Get on a platform to shout about how awful this thing that happened is, and then get donations in response to how big of a, you know, as, as a measure of how large of a platform you have to solicit help from. [00:49:38]
-
-**Mark:** It's certainly not a repeatable and reliable business model. [00:49:59]
-
-**Carl:** I'm very happy that Tailwind got more revenue after talking about how much their revenue has dropped. But like, that's not gonna ha that's not gonna happen for everybody who needs it and it's not gonna happen repeatedly. So me, [00:50:02]
-
-## VoidZero and Vite+?
-
-**Mo:** leads back to that void zero v plus story, which is, I don't see a viable path for monetization for open source projects. It's oftentimes it actually doesn't end up being that successful. I, I mean, mark. Mark, you've been in the ecosystem far more than any of us, I guess, just by virtue of being a successful open source maintainer, but you know, you've obviously done that on the side. [00:50:15]
-
-Right? And like, can you think of any projects that have been successful, like uber successful at monetizing? [00:50:38]
-
-**Mark:** TanStack's the only one that I can think of. Like talking to Tanner this last year. The sponsorships that he's been pulling in have were enough to allow him to go full-time, open source a couple years ago. And he said that the sponsorships have kept growing to the point where he's, he's able to do some disbursements to some of the other maintainers now, and he hopes that if things keep on this trajectory, he might be able to hire some of them full-time. [00:50:44]
-
-But that's about the only one that immediately comes to mind. [00:51:12]
-
-**Carl:** And I think, does he do, do you know if Tanner does? Uh, Like consulting and like services? [00:51:15]
-
-**Mark:** Think he does some, but it's, I think a lot of it is just straight up sponsorships. [00:51:21]
-
-**Carl:** Okay, cool. [00:51:24]
-
-**Mo:** But I guess that's sponsorships, right? Like it's not a direct monetization play, right? So you are relying on the. Donations of, companies in the ecosystem to keep you going. Whereas like, I think the only one I can think of is super base, but they were actually going in for monetization from the get go. [00:51:25]
-
-They just, so like the other way around works, which is you launch a cloud product and then you have an open source portion of it, but not like you start from open source and then you monetize. It seems like that's less likely. . [00:51:40]
-
-**Carl:** I don't know. It's open source has always been tough. It feels like the economics have gotten weirder. It's like, there's more money than ever in tech. You know, as a market, as a, as an industry. But where it is going has is fewer and fewer players. So that's just like, that's tough. I don't know. It's like wealth inequality, open source edition. [00:51:51]
-
-**Mo:** It looks like AI is just making it worse as well, even in like the terms of the tech openings, job openings that are out there and people trying to, companies trying to do more with less people yep. at everything. [00:52:10]
-
-## [246K laid off in 2025 per Trueup.io](http://Trueup.io), 27k in January
-
-**Carl:** Which is a wonderful segue into true up.io, which I have previously relied on to, you know, back when I was doing more month by month layoff news according to them, in 2025, 246,000 tech jobs were lost through layoffs. And already in January we're at 27,000 Rough. [00:52:22]
-
-**Mo:** Geez. Which, you know, Amazon had a pretty big one this week. I believe it was thousand people, which was rough. [00:52:43]
-
-**Carl:** Yep. Yep. I dunno what to do with that. [00:52:52]
-
-## ⚡ Lightning round ⚡
-
-**Mark:** Lightning round. [00:52:56]
-
-## Corbin: [Adapting Library Logic for React Compiler](https://playfulprogramming.com/posts/react-compiler-library-support/)
-
-**Mark:** TanStack form maintainer Corbin Crutchley. Put out a post talking on adapting library code to work properly with the React compiler and some of the constraints that you have to deal with Corbin's. [00:52:57]
-
-Awesome. This is a very useful post. [00:53:09]
-
-## [Lea Verou: Web Dependencies are Broken](https://lea.verou.me/blog/2026/web-deps/)
-
-**Mark:** Lea Verou, who has been in the web standards and CSS discussion, spec specification arena for a very, very long time. Put a proposed complaining about web dependencies are broken. I'm not sure I agree with some of the complaints here, but she's very clearly spent a lot of time complaining about the fact that there's a lot, essentially a lot of non-standardized ways to deal with dependencies. [00:53:11]
-
-Do you do script tags? Do you have bundlers? What if, you know, import maps? What are your options for loading third party code? And why is this so complex and it's worth a read. [00:53:36]
-
-## [AWS Infrastructure as React Components](https://www.react2aws.xyz/)
-
-**Carl:** Somebody put together a project where you can author AWS infrastructure configuration as react components, which is cool. This reminds me, years ago I had a thought to try and do a react renderer for Kubernetes config. 'cause you know, hey, it's all just files. if you're rendering right, who cares if you're rendering HTML or yaml, it's all the same. [00:53:47]
-
-Yeah. So somebody did that for AWS infrastructure and it puts out terraform configurations. And I saw this criticized as, "great, they re-implemented XML" which is pretty heckin true. Like this is, you know, we, we've just gone full circle from XML to yaml, back to pseudo XML. [00:54:11]
-
-**Mo:** I posted this on our company dev chat and someone respond, did one misconfigured use effect. And Gigi, you're bankrupt. [00:54:29]
-
-**Mark:** Worse than the cloud dashboard. [00:54:36]
-
-## Callstack releasing bunch of cool projects
-
-**Mo:** Alright, quick react native one. So, uh, the call stack folks have been busy whilst the rest of the ecosystem I'd say has been relatively quiet. This month and they've released two really cool projects. [00:54:38]
-
-## [Brownie: RN Brownfield apps](https://www.callstack.com/blog/introducing-brownie-type-safe-shared-state-for-react-native-brownfield-apps)
-
-**Mo:** So Brownie is the first one that I want to quickly touch on, which is a project for Native Brownfield applications. So we talk about Brownfield as apps that are mainly native, but they're adopting some React native views and screens within them. [00:54:48]
-
-And these are difficult to build, but predominantly they get really hard when you have to share stake between them. So they're trying to create a standardized, nice way to share a storage basically a store in between your different React native screens in a largely native app shelf, which I thought was cool. [00:55:02]
-
-## [Voltra: RN Live Activities and Widgets](https://www.callstack.com/blog/live-activities-and-widgets-with-react-say-hello-to-voltra)
-
-**Mo:** And somebody's, you know, trying to standardize and create a project and a tool for that, which is sort of less touched on in the open source ecosystem for React Native. The second library that they released, which they didn't actually start but they've now taken over is one called Voltra. So Voltra was actually created by this open source author who nobody really knew that well in the React native ecosystem. And he just kind of did it as a side project. And I think the call stack folks have kind of taken over it. So it's for things like live activities and widgets. These are sort of native functionalities that you can't really do with React native. [00:55:17]
-
-But this library author has kind of done a really cool job of representing it as React code, even though it's not quite exactly using a React render under the hood. It's just sort of then being translated to native views. Surprisingly the person who was the original maintainer has deleted his Twitter and you can't really find him anymore. [00:55:51]
-
-So I hope he's doing all right. But it seems like it's being taken over by the call stack folks. [00:56:08]
-
-## Ryan Carniato’s [annual JS Frameworks direction roundup](https://dev.to/this-is-learning/javascript-frameworks-heading-into-2026-2hel) , and Netlify’s [2025 Web Frameworks In Review](https://www.netlify.com/blog/web-frameworks-2025-year-in-review/)
-
-**Mark:** Okay. Ryan Carniato knows more about what's going on and across all the different JS frameworks than pretty much anyone else. I love his perspective. And each of the last few years he's done a post kind of summarizing like, where are we at and where are we going? So this is his addition for going into 2026. And meanwhile, Netlify put up a 2025 web frameworks year in review post as well. [00:56:12]
-
-## Alex Russell: [Shallow Session SPAs analytics](https://calendar.perfplanet.com/2025/the-curious-case-of-the-shallow-session-spas/)
-
-**Mark:** Meanwhile, alex Russell continues to hate React and JavaScript and single page apps. He also has the metrics and the stats to back up his opinions, even if I don't agree with how he states a lot of them. And he put up a post where he said, we're basing, like we've always based the argument for single page apps on the idea that yeah, you load a lot of code, but it stays alive and users do a lot of navigations. [00:56:36]
-
-And the metrics that we have don't necessarily support that users do a lot of navigations, but it's also possible that the metrics I have are flawed because they just don't capture users clicking around in the page. So what could we hypothetically do to gather better information either way? Which is all a very valid set of points. [00:57:00]
-
-## Devon Govett: [How to compile JS to C with Static Hermes](https://devongovett.me/blog/static-hermes.html)
-
-**Mark:** Devin Govett, who maintains the parcel bundler, and I believe the Lightning CSS tool did a post on compiling JavaScript to see with static Hermes. I don't even remember which tool he was compiling. But Mo I know you've talked about static Hermes quite a bit, and it sounds really cool. [00:57:23]
-
-**Mo:** Yes. The Static Army team has been working quite a bit. In the last couple months to get version one up and running well, version one of Hermes up and running and they're kind of at a crossroads with static Hermes. We talked about it a couple months ago, I think, where we said it, it conflicts with some of the ecosystem and how React native has naturally evolved with things like over the air updates and so on and so forth. [00:57:43]
-
-But I think there's a lot of use cases beyond React native. So this is quite interesting to see other people look at it and see how they [00:58:03]
-
-**Mark:** Mm-hmm. [00:58:08]
-
-**Mo:** it. [00:58:08]
-
-**Mark:** I know that the React compiler team has said that this is how they're hoping to try to optimize the compiler parsing phase as well. [00:58:09]
-
-## Joyee Cheung: [require(esm) implementer’s tales](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-implementers-tales/) and [require(esm) from experiment to stability](https://joyeecheung.github.io/blog/2025/12/30/require-esm-in-node-js-from-experiment-to-stability/)
-
-**Mark:** And then Joy Chung, who built the require ESM compatibility loader for node and therefore is probably gonna be more responsible for than anyone else for eliminating common js. [00:58:16]
-
-Eventually put up two fantastically detailed posts on the implementation work needed to make that happen. And it's fascinating to read the technical details to hear about, you know, like earlier people had tried things and then, you know, pieces were just sort of left to rot and she was able to pick them up and work on them. [00:58:29]
-
-Great work, great write-ups. [00:58:50]
-
-## [Fixing the URL Params Performance Penalty](https://calendar.perfplanet.com/2025/fixing-the-url-params-performance-penalty/)
-
-**Carl:** I was a little surprised to see this I'm not familiar with this blog, Planet performance. But it's the same domain that the Post from Alex Russell that Mark just talked about is on. So that's interesting. It's not often that I see a new blog from a recognized author, so this is interesting. It's, it looks like they're talking about web performance generally, and that's pretty cool. [00:58:53]
-
-**Mark:** this section was like an advent of performance type thing in December. [00:59:14]
-
-**Carl:** Oh, that makes sense. Web performance calendar. Okay. It's like an advent calendar of web performance. Oh, that's cool. Appreciate that. [00:59:18]
-
-But yeah, so Barry Pollard put out a blog post called Fixing the URL PERS Performance Penalty. And the gist of it here is that sometimes the query string the part of the URL after the question mark contains information that alters the page. [00:59:25]
-
-Like, you know, a product details page that gets the product ID from the query string. And more often it's just a bunch of marketing tags, like UTM source and blah, blah, blah, blah, blah. And disambiguating between those two things is not something a cash can do on its own. So your marketing tags may be thrashing your cache performance. So this is talking about ways to improve that situation and make your marketing paras not affect performance quite so much. It looks like there's a header no very search that lets you alter that, alter the cache behavior in response to the query string. So it's good. It's one of those deep subjects good refinement for performance. [00:59:41]
-
-## [React Transitions for Low Priority Text Editor Updates](https://handlewithcare.dev/blog/transition_low_priority_editor_updates/)
-
-**Mark:** Okay, a few more items. We had there was an article on using React transitions for low priority text editor updates. Most of, you're probably not needing to go out and update the implementation of a text editor. But someone who's worked on React Pros Mirror has some examples of how transitions were actually helpful for managing those. [01:00:26]
-
-## [How to Steal a React Component](https://fant.io/react/) (Fiber internals)
-
-**Mark:** Meanwhile there was a post on how to steal a react component and you know, I believe the idea here was an extension that looks at react in the page and actually digs through the react fiber tree to not only see like what dom elements are in the page right now, but what component elements and props resulted in those. And essentially try to reverse engineer, here's the components that would have written the pieces of the page as they existed in the app that you're looking at. [01:00:46]
-
-## [Better ASCII rendering with smart character selection for “pixels”](https://alexharri.com/blog/ascii-rendering)
-
-**Mark:** And then unrelated to React, but absolutely amazing. I love really long blog posts with lots of interactive examples. Someone did a post on rendering a graphics with ASCI characters, which a lot of, you know, tools do, but analyzing the font weights in a given character cell to come up with better pixels. [01:01:20]
-
-So like if a, like, if the graphic should be lighter or darker using characters that occupy more or less of the character cell. It was just really cool to read this. [01:01:43]
-
-**Carl:** Yeah. I think a one short summary of the change. A lot of asci rendering tools like that will consider it, you know, the character space as a pixel and just sort of think about whether a given character, you know, they think about it one dimensionally. It's how many pixels are illuminated with this character or that character. [01:01:54]
-
-And this adds different, this basically subsamples the characters to say, is this brighter at the top or the bottom on the left or the right? And like I gotta say, you know, it's got a bunch of animated, you know, demos and whatever, and it is clearly much, much, much better than other things that I've seen. It's pretty cool. [01:02:13]
-
-## [Building a JS Runtime in One Month](https://themackabu.dev/blog/js-in-one-month)
-
-**Carl:** Somebody put out a blog post titled, building a JavaScript Runtime in one month. I love deep in the weeds engineering write-ups, and this is definitely one of those. But I have never even considered whether I might try to write a JavaScript runtime. [01:02:32]
-
-And so I feel very intimidated by the scope of engineering involved in this project. but [01:02:45]
-
-**Mark:** it even sounded like it was, you know, like, like not necessarily AI aided, at least I didn't see anything in the blog post that said they were using agents to do the work. I mean, there, there's also been a whole spate of let's have AI write a browser from scratch. Posts popping up over on Hacker News in the last month, and then I think I saw someone say they'd done a fresh browser from scratch, NC plus, but it was all by hand or something. Wow, y'all have too much time on your hands. [01:02:51]
-
-**Carl:** Yeah, seriously, it's impressive. I'm in awe of people who can do projects of this scope in that timescale. Like that's just wild. Anyway I approve. Very cool. [01:03:19]
-
-**Mark:** Mm-hmm. [01:03:29]
-
-**Carl:** Okay, that's our lightning round. We did it. . [01:03:30]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** I'm gonna blitz through a bunch of conferences. [01:03:33]
-
-There is C js in New Delhi in like th two, three weeks, 18th, 19th of February. State of the browser is February 28th in London. App devcon is March 10th through 13th in Amsterdam. [01:03:35]
-
-Programmable is a conference in both Melbourne and Sydney in Australia on March 17th and March 19th respectively. So it's, they're doing two days apart in different cities in Australia. That seems like a challenge, and it's kind of confusing to talk about [01:03:50]
-
-tech Fest is March 12th through 13th in Madrid, Spain. React Paris is March 26th and 27th in Paris. [01:04:05]
-
-Shockingly. [01:04:13]
-
-**Mark:** there [01:04:14]
-
-**Carl:** Front Runners is March 27th in Washington DC React Native Connection is March 30th and 31st in Paris. City Js London is April 15th through 17th in London. Js Day is. April 9th and 10th in Bologna, Italy. [01:04:14]
-
-. Smashing Con Amsterdam is April 13th through 16th in Amsterdam and React Miami is April 22nd and 25th through 25th in Miami. [01:04:31]
-
-So yeah. [01:04:40]
-
-**Mark:** speaking there. [01:04:41]
-
-**Carl:** Heck yeah. I should reach out and maybe give a talk somewhere. That would be cool and good for me. There's lots more, but that's, you know, that covers the next like three months, so seems good enough for now. [01:04:42]
-
-## Outro
-
-**Carl:** Thank you everyone for joining us . We not Wednesday, we are recording on Friday due to some travel hiccups, but we will be back probably on the last Wednesday of February here in the live stage react complex or back in your podcast feed just as we could, can after that. most of these sources came from Mark again. It's been very nice having such a steady stream of source of news sources come through here in Reactiflux. And maybe we'll do a little bit more to make the community more anchored on the people who are trying to stay to the cutting edge. [01:04:56]
-
-I don't know, we'll see. But if you see anything newsworthy, definitely share that in the Tech News and Reads channel. 'cause we'll read it. And if it's newsworthy and interesting, we'll probably talk about it. If this is a show you get value from and wanna support, best way to do so is by telling someone else about it. [01:05:24]
-
-We are still not that large. An average show gets about 400 listens over a little over a month. So yeah, I like doing it. I like making it. It would be cool if it had a little bit broader support, broader listenership. I guess the support is there. Yeah. Thanks so much for listening. See you next month. [01:05:39]
diff --git a/src/transcripts/tmir-2026-02.md b/src/transcripts/tmir-2026-02.md
deleted file mode 100644
index 67ade13..0000000
--- a/src/transcripts/tmir-2026-02.md
+++ /dev/null
@@ -1,691 +0,0 @@
----
-title: "TMiR 2026-02: CloudFlare remakes Next with AI; Vercel big mad. We talk too much about AI Agents"
-date: 2026-02-25
-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)"
----
-
-
-
-
-
-- [[01:46](#new-releases)] New releases
- - [[01:50](#ts-60-beta-last-ts-impl-release-stricter-defaults)] [TS 6.0 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/)! (last TS impl release; stricter defaults)
- - [[02:34](#yarn-6-preview-rewritten-in-rust)] [Yarn 6 preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/) (rewritten in Rust)
- - [[02:52](#electrobun-tauri-alternative)] [Electrobun](https://blackboard.sh/electrobun/docs/) (Tauri alternative)
- - [[03:31](#react-native-gesture-handler-v3)] [React Native Gesture Handler v3](https://blog.swmansion.com/introducing-gesture-handler-3-0-hook-based-api-deeper-reanimated-integration-more-9185b0c8e305)
- - [[04:20](#next-polyfills-improved-webstreams-and-upstreaming-to-node)] [Next polyfills improved WebStreams and upstreaming to Node](https://vercel.com/blog/we-ralph-wiggumed-webstreams-to-make-them-10x-faster)
- - [[05:25](#webpack-2026-roadmap)] [Webpack 2026 roadmap](https://webpack.js.org/blog/2026-04-02-roadmap-2026/)
- - [[05:53](#lodash-maintenance-roadmap)] [Lodash maintenance roadmap](https://socket.dev/blog/inside-lodash-security-reset)
- - [[07:07](#gatsby-react-19-support-styled-components-rsc-support)] [Gatsby React 19 support](https://www.gatsbyjs.com/docs/reference/release-notes/v5.16/) , [styled-components RSC support](https://styled-components.com/releases#styled-components@6.3.0)
- - [[07:54](#npmxdev-alternate-npm-site-ui)] [npmx.dev](https://npmx.dev/) (alternate NPM site UI)
- - [[08:43](#eslint-plugin-react-render-types-typed-children)] [eslint-plugin-react-render-types](https://github.com/HorusGoul/eslint-plugin-react-render-types) (typed children)
-- [[09:54](#main-content)] Main Content
- - [[09:55](#react-core-updates)] React Core updates:
- - [[09:56](#react-foundation-officially-launched)] [React Foundation officially launched](https://react.dev/blog/2026/02/24/the-react-foundation)
- - [[12:28](#docs-updates-useactionstate-merged-use-and-rsc-sandboxes-wip)] Docs updates: [`useActionState`](https://github.com/reactjs/react.dev/pull/8284) (merged), [`use`](https://github.com/reactjs/react.dev/pull/8305) and [RSC sandboxes](https://github.com/reactjs/react.dev/pull/8300) (wip)
- - [[14:23](#react-native-084-released)] [React Native 0.84 released](https://reactnative.dev/blog/2026/02/11/react-native-0.84)
- - [[17:47](#hermes-wasm-support-hermes-node-compat-cli)] [Hermes WASM support](https://x.com/tmikov/status/2023821160241393839), [Hermes Node compat CLI](https://x.com/tmikov/status/2024609186936660170)
- - [[18:43](#state-of-survey-results)] “State of…” survey results
- - [[18:43](#state-of-js-2025-results)] [State of JS 2025 results](https://2025.stateofjs.com/en-US)
- - [[19:06](#state-of-react-2025-results)] [State of React 2025 results](https://2025.stateofreact.com/en-US)
- - [[19:51](#aurora-scharffs-conclusion)] [Aurora Scharff’s conclusion](https://2025.stateofreact.com/en-US/conclusion/)
- - [[20:44](#josh-comeaus-takes-on-the-results)] [Josh Comeau’s takes on the results](https://bsky.app/profile/joshwcomeau.com/post/3mf642css6227)
- - [[21:28](#api-pain-points)] [API pain points](https://2025.stateofreact.com/en-US/features/#main_apis_pain_points)
- - [[21:53](#state-of-react-native-2025)] [State of React Native 2025](https://results.2025.stateofreactnative.com/en-US/)
- - [[24:29](#how-we-rebuilt-nextjs-with-ai-in-one-week)] [How we rebuilt Next.js with AI in one week](https://blog.cloudflare.com/vinext/)
- - [[29:52](#cloudflare-v-vercel-beef)] CloudFlare v Vercel beef
- - [[35:42](#carl-vitullo-monologs-about-ai-agents)] Carl Vitullo monologs about AI Agents
- - [[42:27](#ai-productivity-and-impacts-on-our-attention)] AI productivity and impacts on our attention
- - [[44:42](#wrote-a-spec-pointed-claude-at-an-asana-board-and-went-home)] ["wrote a spec, pointed Claude at an Asana board, and went home"](https://x.com/rvivek/status/2026385957596111044)
- - [[47:26](#bits-ai-sre-datadog)] [Bits AI SRE | Datadog](https://www.datadoghq.com/product/ai/bits-ai-sre/)
- - [[51:04](#thoughtworks-opines-on-ai-productivity-impacts)] [ThoughtWorks opines on AI productivity impacts](https://simonwillison.net/2026/Feb/14/thoughtworks/)
-- [[01:00:28](#-lightning-round-)] ⚡ Lightning round ⚡
- - [[01:00:37](#wall-street-raider-game-modernization-and-uses-preact)] [“Wall Street Raider” game modernization](https://www.wallstreetraider.com/story.html) (and uses Preact)
- - [[01:01:16](#github-stacked-diffs-preview-faster-issues-search)] [Github Stacked Diffs preview](https://x.com/jaredpalmer/status/2019817235163074881) , [faster Issues search](https://github.blog/changelog/2026-01-29-improved-search-for-github-issues-in-public-preview/)
- - [[01:02:08](#josh-comeau-sprite-animations)] [Josh Comeau: Sprite animations](https://www.joshwcomeau.com/animation/sprites/)
- - [[01:02:26](#interop-2026-webkit-igalia)] [Interop 2026](https://wpt.fyi/interop-2026), ([WebKit](https://webkit.org/blog/17818/announcing-interop-2026/), [Igalia](https://www.igalia.com/news/interop-2026.html))
-- [[01:03:38](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [AppDevCon](https://appdevcon.nl/) Mar 10-13, Amsterdam Netherlands
- - [Programmable](https://www.programmable.tech/) Mar 17 / Mar 19, Melbourne / Sydney, Australia
- - [Frontrunners](https://frontrunners.tech/) Mar 27, Washington DC, USA
- - CFPs: [web talks](https://docs.google.com/forms/d/e/1FAIpQLScK3YlL_-2teVyX7pohkjIbsyLSF-8Hq4z-U7CPQ186sgdNPA/viewform) or [AI/data](https://docs.google.com/forms/d/e/1FAIpQLSedNNa4N64vgfsvAtGcBngKJrtd3h1_x0T019GTW-rSwCj0jQ/viewform)
- - [T3chfest](https://t3chfest.es/2026/en/) Mar 12-13, Madrid, Spain
- - [React Paris](https://react.paris/) Mar 26-27 Paris, France
- - [CFP (closed)](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform), [Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform)
- - [CityJS London](https://london.cityjsconf.org/), Apr 15-17, London, UK
- - [jsday](https://www.jsday.it/) Apr 9-10, Bologna, Italy
- - [SmashingConf Amsterdam](https://smashingconf.com/amsterdam-2026) Apr 13-16, Amsterdam, Netherlands
- - [React Miami](https://www.reactmiami.com/) Apr 22-25
- - [JSWorld](https://forms.gle/jxUNcEpibb1XcLdP7) May 7-8 Amsterdam, Netherlands
-
-**Carl:** Hello everyone. Thank you for joining us for the February edition of this Month in React. As we recap what's going on in React, react Native and across the web, coming to you live from Reactiflux, the place for professional developers using React. This is our first month, we are now membership applications only. Everyone in here now is part of an exclusive club that has a gate at the door, which feels kind of weird, but it has shifted the vibe. So I'm pro it so far. It's kept out a lot of scammers. [00:00]
-
-**Mark:** There's even been a lot of that going on across, you know, the open source ecosystem in general. I've seen numerous repos going like no external contributors or vouch system only. [00:29]
-
-So there's, there's a lot of trend there. [00:40]
-
-**Carl:** It's unfortunate. But anyway, I'm Carl. I'm a staff product developer and freelance community leader here at React Flex, where I run community programs like this podcast, news events, and build tools to help keep the community operating. [00:41]
-
-**Mark:** Hi, I'm Mark. My day job is working a Replay.io where we are, once again, building awesome time, travel, debugging stuff, and now have a new replay, MCP to let your own AI agent Investate recordings. And outside of that, I find time to do redux stuff. [01:06]
-
-**Mo:** And I am Mo, I work at a company called Theodo, which is a global consultancy, and I spend my time these days building AI tooling, but have spent the last three, four years in the React and React Native ecosystem. So I try to merge the two together. So I, uh, organize the React Native London Meetup and conference and have spent a bit of time dabbling in the React Native ecosystem. [01:09]
-
-**Carl:** Yeah. And we have a fun little podcast milestone this month. It's a little bit fuzzy because metrics are like really hard to do on downloads, but it appears that we crossed 7,500 downloads cumulatively across the entire podcast over the past month. So like, yay. That's cool. Thanks for listening. Cool. [01:28]
-
-## New releases
-
-**Carl:** Mark, take us through some new releases. [01:46]
-
-**Mark:** Okay, first couple items. [01:48]
-
-## [TS 6.0 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/)! (last TS impl release; stricter defaults)
-
-**Mark:** TypeScript six beta just dropped. And as a reminder, this is scheduled to be the final release of TypeScript written in TypeScript itself. The plan is that there will be no 6.1, no, 6.2. The the next release would be TS 7, which is the built in go version. The biggest thing for version six, you know, TypeScript has always been very fuzzy on their versioning, but they, when it's a do o release, they do tend to change some settings. [01:50]
-
-And so TS 6.0 is going to make a lot more stricter defaults as preparation for version seven. So that both improves behavior as well as reflects how TypeScript is actually being used in practice today. [02:20]
-
-## [Yarn 6 preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/) (rewritten in Rust)
-
-**Mark:** Meanwhile, continuing another trend, yarn has released version six or, or announced a version six, which is a little surprising 'cause I don't. [02:34]
-
-I think they had a version five, I'm pretty sure they're on version four right now. And it is the obligatory rewrite it in Rust approach. So train to speed things up. [02:42]
-
-## [Electrobun](https://blackboard.sh/electrobun/docs/) (Tauri alternative)
-
-**Mark:** Totally different item. So we've got Electron, which is desktop apps wrapped in a browser because you ship an entire chromium build for your website. [02:52]
-
-There's tari, which is desktop apps in a browser, except that it uses the operating systems built-in browser web view. And someone else just put out electro button, which is the, an equivalent of tari and that it uses the, you know, the native web view. But it uses BUN for all the behind the scenes processing. [03:03]
-
-So it looks, looks potentially interesting. And with BUN being a Swiss Army knife could be useful. [03:26]
-
-## [React Native Gesture Handler v3](https://blog.swmansion.com/introducing-gesture-handler-3-0-hook-based-api-deeper-reanimated-integration-more-9185b0c8e305)
-
-**Mo:** Switching over to the React Native ecosystem, the folks at Software Mansion have released. React Native gesture handler version 3.0. It's currently a beta, but it's, it's likely gonna be released as it is. And so the major change here is that they've overhauled the API surface to be based on hooks. [03:31]
-
-So previously it was a bit of a, an imperative setup. It wasn't hook based. They've now updated it so that it fits more with some of the other libraries that Jester Handler integrates with. They've also removed support for the legacy architecture and they've done some performance optimizations under the hood so that when you integrate reanimated with gesture handler. [03:49]
-
-Things work kind of better and it lets you use things like shared values across the board into your gestures, which is something that you previously couldn't do. So some good changes here, and hopefully it will be launched soon outside of data. [04:07]
-
-## [Next polyfills improved WebStreams and upstreaming to Node](https://vercel.com/blog/we-ralph-wiggumed-webstreams-to-make-them-10x-faster)
-
-**Mark:** This next one is somewhere between a, a release and a news item. [04:20]
-
-So there was, there was some investigation of next JS and RSE performance a couple months back, and CloudFlare was digging inside the internals of Next and made some improvements. So LL apparently followed up on some of this and RSCs at least some of the next usages, currently use web streams internally for passing the data around instead of the nodes standard built in streams. So two different stream implementations. [04:24]
-
-They did some analysis and figured out that Node's Webstream implementation is actually really inefficient and actually kind of previewing something we'll be talking about later. They cut a bunch of agents loose and said, Hey, make this a whole lot faster and be actually very similar because there were a ton of web platform tests on how web streams ought to be behave. [04:52]
-
-They were able to re-implement the concept faster, and they're trained to upstream some of that behavior into node itself, but also release this as essentially a polyfill package as well. [05:12]
-
-## [Webpack 2026 roadmap](https://webpack.js.org/blog/2026-04-02-roadmap-2026/)
-
-**Mark:** Let's see. We have a couple road mappy items. First off, Webpac has put, has put out a 2026 roadmap. Some of the things we're looking at are better built in support for CSS modules, a new universal output format that will work across run times. [05:25]
-
-Being able to load TypeScript without needing a separate loader plugin and trying to make sure that Webpack can run everywhere, not just node. [05:42]
-
-**Carl:** Yeah, I guess that seems good. [05:51]
-
-## [Lodash maintenance roadmap](https://socket.dev/blog/inside-lodash-security-reset)
-
-**Carl:** Yeah. Keeping on the, I don't know, roadmap and old tools. Talking about what they're gonna be doing next. Lodash put out a a bit of a roadmap, or I guess sot dev is talking about the Lodash reset and maintenance reboot as they call it. [05:53]
-
-The title here, we talked about this a bit last month, but yes, the Lodash maintainers are rebooting the governance of the package essentially. Interestingly, they got an investment from a European like sovereign tech fund. So I guess you know the. Some European agency has determined that Lodash is critical infrastructure, deserving financial support, and so they are using that money to fund governance changes to how the package is managed, and then also do some security releases and such, which is great. [06:10]
-
-I mean, Lodash is the kind of thing that, you know, in the aftermath of all of these NPM vulnerabilities, Lodash is absolutely the kind of library that would be aggressively targeted by nefarious actors. So that's pretty cool. That's exciting. Why? I like seeing rebuilding security from first principles if a core project is going to get a bunch of money. [06:45]
-
-Very cool. [07:06]
-
-## [Gatsby React 19 support](https://www.gatsbyjs.com/docs/reference/release-notes/v5.16/), [styled-components RSC support](https://styled-components.com/releases#styled-components@6.3.0)
-
-**Mark:** And on a similar note, a couple other legacy projects getting updates. Gatsby had a. Maintenance release that added some kind of react 19 support and styled components. Put out a release that tries to add RSC compatibility, which is very interesting. 'cause I thought, I thought one of the issues was it just wouldn't work in server components. [07:07]
-
-So I, I haven't looked at this, I just saw it this morning. But FYI, [07:26]
-
-**Mo:** I also remember them putting a big sting and saying they were deprecating themselves as a lib. [07:30]
-
-**Carl:** Right. We talked about that. [07:35]
-
-**Mark:** I mean, someone, someone else forked it to improve the performance, but I thought the primary library was halted. [07:36]
-
-**Mo:** And, and same for Gatsby, although I might beat bit fuzzy. Was Gatsby ever deprecated or is it [07:42]
-
-**Mark:** Yeah. Gatsby was bought by Netlify and then abandoned. [07:47]
-
-**Mo:** So turns out AI can revive old school projects. [07:50]
-
-## [npmx.dev](https://npmx.dev/) (alternate NPM site UI)
-
-**Mark:** And last couple release announcements, those of you who have ever looked at the NPM package website might have noticed that it's, it's there, it works, but it's not really modern and it certainly hasn't been updated in a while. [07:54]
-
-So a bunch of folks from the community have put together NPM x.dev, which is an entire alternate front end to the same NPM package registry and server APIs. This only sprang up within like the last month or month and a half, and there's been a massive group of folks just diving in and building out a brand new website from scratch and adding all kinds of useful features. [08:09]
-
-I've, I've looked at it a couple times and it is much, much better implemented than the primary NPM website. Nice. [08:34]
-
-**Carl:** Love that. [08:42]
-
-**Mark:** Yep. [08:42]
-
-## [eslint-plugin-react-render-types](https://github.com/HorusGoul/eslint-plugin-react-render-types) (typed children)
-
-**Mark:** And then finally, one of the longstanding complaints about React in TypeScript is that you can't correctly type what? Style components can be passed in to a given parent. And apparently someone had added the flow typing language competitor type script had added a feature like this a couple years back. [08:43]
-
-But you know, at this point, nobody uses flow outside of Facebook. And so someone apparently put together an ES lint plugin that somehow tries to implement this kind of typed children restriction functionality. [09:05]
-
-**Carl:** I love that. That is something I had wanted a number of times. There was a moment a, a while ago where like compound components was a talking point, you know, a point of discussion in the React ecosystem where it's like tabs and like tab groups and like tab content, and you need those to be individual components because of just the structure of the dom, but they're all interrelated and like, this one must be nested within this one and so on. [09:17]
-
-So being able to enforce that in type constraints is, Ooh, love to sing that [09:43]
-
-**Mark:** both people and ais love having real typed constraints to catch problems in the first place. [09:48]
-
-**Carl:** Yes, indeed. [09:53]
-
-## Main Content
-
-**Carl:** Okay. [09:54]
-
-## React Core updates:
-
-**Carl:** Into our main content. [09:55]
-
-## [React Foundation officially launched](https://react.dev/blog/2026/02/24/the-react-foundation)
-
-**Mark:** The React Foundation was announced at React Conf back in October. The onstage announcement didn't have a lot of details and we've tried to pass on tidbits of information that we heard talking to, you know, Seth and other folks over the last couple months. [09:56]
-
-So. This blog post really doesn't say a whole lot more that we, you know, that we didn't know yet, other than the fact that apparently there's an eighth founding company, Huawei, it does say that they're trying to figure out what the, the split between the technical and political governance of the foundation will look like. [10:13]
-
-So there's a little bit of a, this is an announcement that there's an announcement thing going on, but hey, you gotta start somewhere. And I'm, I'm happy to see any kind of actual progress on this moving forward. [10:30]
-
-**Carl:** I don't know what we will really see from like, in terms of substantial details. 'cause like it's not like the core team in general was like super communicative about its internal processes or like who was doing what. [10:42]
-
-So I was hoping that might change a little bit. [10:56]
-
-**Mark:** Well, I mean, I mean talking to Seth directly back in New York and November, the longer term plan, and I, I don't know what the timeline is for this, but he flat out said they are intending to open up the literal weekly team sync meetings, like the same ones they've been having internally at meta and meta and versa for the last decade. [10:58]
-
-They intend to literally open those up to the public for viewing and then start to, you know, actually bring in community representatives to participate in those meetings as well as the new government structure affecting what the planning process is. So, like that alone is something that I am very, very excited about. [11:17]
-
-Get to get to see all the sausage feeding. [11:37]
-
-**Carl:** Yeah, that's very cool. I should talk to them 'cause I don't know, like I said at the beginning, Reactiflux now has a gate at the door. I'm curious about adding more gates because like the keen eye may notice that there are not very many open source project maintainers around here. [11:39]
-
-And I tend to believe that's because of, there's a lot of people who are not as experienced and the volume of less experienced questions crowds out the more experienced people trying to have discussions. So I'm curious about adding more levels of gates, you know, so you can get in and then you can get in further and then you can ascend and sounds related to open access meetings. And then, you know, some participants being able to join if they meet some other bar. That would be cool if we could be more of a home for a little bit more of that stuff. Anyway. [11:54]
-
-## Docs updates: [`useActionState`](https://github.com/reactjs/react.dev/pull/8284) (merged), [`use`](https://github.com/reactjs/react.dev/pull/8305) and [RSC sandboxes](https://github.com/reactjs/react.dev/pull/8300) (wip)
-
-**Mark:** Other than that, a couple other bits of news. I I, I don't think there's been any other React releases recently, however, Ricky Hanlon has been diving in and trying to do some major improvements to some of the React reference docs. [12:28]
-
-I think last month we had talked about, he had rewritten the use effect event, API reference and possibly one other page. And within the, the last couple weeks he's gone in, he merged a rewrite of the Use Action State reference page. He has a work in progress PR to revamp the use hook page, and he also has a PR to try to add sandboxes for server components to the docs. [12:40]
-
-And this is actually kind of a big deal. I don't know, I don't know what the longer term plan is here, but this is something I talked with him about. If you wanted to teach server components in the docs, how is a learner going to be able to try server components? Right now, like there's like, you know, it's all teaching client side react and it uses the sandboxes very, very well to do that. [13:07]
-
-But how are you going to teach someone server components if they have no way to try it out and it fully needs a framework choice to be able to do it. So if he's come up with an approach that is kind of like a, some sort of framework agnostic sandboxes that feels like it would unlock the ability to then add server components, teaching content to the docs. [13:33]
-
-**Carl:** It's interesting. Yeah. Where my reminds me of, I, I remember when I was learning JavaScript for the first time in like 2000, I don't know, '04 or '05, the try it editor on like W three schools where you could have like code over here and the pa you know, the, the webpage over here. Like, oh, it was so powerful. [13:57]
-
-So I, yeah, fuck yeah, let's update it to the modern era. Give some sandboxes for RSCs. [14:16]
-
-**Mo:** Cool. [14:21]
-
-## [React Native 0.84 released](https://reactnative.dev/blog/2026/02/11/react-native-0.84)
-
-**Mo:** So moving on to the next piece of news from the React core team. React Native version 0.84 has been released. Now, like we said previously, these releases are getting smaller and smaller and the idea is that they're released on a sort of two month by two month basis. [14:23]
-
-The big one on this release is that Hermes version one is by default. Now, just to give a little bit of background as to what Hermes v1 actually brings to the table, it's effectively a bunch of improvements on the VM performance. So they've gone in and actually implemented support for things like, ES6 classes. [14:39]
-
-Some of the syntax in more modern JavaScripts like constant let support for things like Async. Previously, all of this was being basically handled by Babel and just transpired into older formats of of JavaScript, and so. All of this is sort of helping improve the actual performance here. Now, this is not to be confused with static Hermes, which is a totally different project, but the idea is that there are some serious performance improvements here. [15:01]
-
-They ran some benchmarks on what this looks like, and we're talking on some sort of performance benchmarks on some of these open source projects. You know, we're looking at sort of something like 50% improvement in the relative performance for basically executing complex JavaScript benchmarks. The reality of it is when you sort of look at it, the, the results that they've given out, and oftentimes the React data ecosystem people use the Expensify app as sort of a benchmark because it's a real world app that's also open source. [15:30]
-
-So it, it gives a lot of good, uh, real world benchmarks. They saw improvements in the TTI of an app, so how quickly the app is interactive, somewhere between two to 7%, depending on the platform, but also things like the loading time of the bundle being significantly quicker. So generally just performance improvements on the whole. [16:01]
-
-Secondly, there was another sort of piece that we talked about last month that's now in by default, which is pre-compiled binaries on iOS. So previously with React Native, what the process would look like is that you would go through and actually build from source. That is no longer the case. By default, all of this is pre-compiled as an XC framework, which is effectively a library binary in the swift world, and then it's just installed as if it was a third party dependency. [16:22]
-
-You can opt out for the old behavior, but this will speed up build times quite significantly. Those are sort of the two major pieces. They've done a bit of housekeeping on removing more legacy architecture functionality and so on and so forth. But this is really the core. [16:51]
-
-**Carl:** So you said like, you know, two to seven percent-ish speed up and then you also said about like loading, like bundle loading. Do you know if the loading performance improvements are included in that percentage speed up or is that like separate things? [17:04]
-
-**Mo:** They're probably linked to one another, but they are different metrics that you assess. So there's like the bundle load time, which is how quickly the JavaScript gets loaded in by the rec native engine or hers in this case for executing. [17:19]
-
-But then there's the TTI, which is sort of like a, a step back, which is basically, I guess on the web side of things, it's like, I don't know, we have a TTI metric on the web, but I guess like think of it as like close to LCP in some capacity. [17:30]
-
-**Carl:** Yeah, Last Contentful Paint yeah, sure. [17:45]
-
-## [Hermes WASM support](https://x.com/tmikov/status/2023821160241393839), [Hermes Node compat CLI](https://x.com/tmikov/status/2024609186936660170)
-
-**Mark:** And then I saw a couple additional tweets from one of the, one of the Hermes team members talking about a couple proof of concepts that they've been working, proof of concepts, previews, alphas, somewhere in there that they've been working on. One is that they've, they've put together a CLI for Hermes that at essentially node, but implemented with Hermes instead of V8. So they, they've built layers for most of the node APIs and been able to, you know, build a node like CLI with Hermes. [17:47]
-
-And then they also put together a preview of wasm support for Hermes so that the, the Hermes engine's able to load WASM bundles Act. And that means you can take, you know, external, external libraries written in c plus plus or rust or whatever, compile them to Wasm and load them by the engine. And thus you get, you know, faster processing runtime from complex computational stuff. [18:16]
-
-So they're, they're probably pretty busy over there. [18:40]
-
-## “State of…” survey results
-
-**Carl:** Okay. [18:43]
-
-## [State of JS 2025 results](https://2025.stateofjs.com/en-US)
-
-**Carl:** Should we go into some state of the ecosystem results. Sure. I regrettably have not read this. These are always so deep and they have so much knowledge in them that I want to give them a lot more attention than I ever really feel like I have. So I have not read these as closely as I would've liked to. [18:45]
-
-Mark, did you get to take a look? [18:59]
-
-**Mark:** Not really. I saw a few reactions. I linked to some of Josh Comeau's reactions. [19:01]
-
-## [State of React 2025 results](https://2025.stateofreact.com/en-US)
-
-**Mark:** The State of React survey in particular, if I'm looking at the, looking at the state of JS one at the moment, they, you know, in particular, they have sections for front end frameworks and meta frameworks, which, you know, is worth glancing at. [19:06]
-
-There's, you know, looking at, looking at the front end frameworks, we've got, you know, the, the usage ratios react is way up there. But in terms of satisfaction, solid seems to be pretty high up there and has the highest, has had the highest satisfaction for each of the last several years. So I'd have to dig in the numbers to see what the, the number of people using it is. But clearly folks who are using Solid are very happy with it as a choice. [19:21]
-
-**Carl:** Fair enough. [19:50]
-
-## [Aurora Scharff’s conclusion](https://2025.stateofreact.com/en-US/conclusion/)
-
-**Carl:** Yeah, I'm reading the, uh, conclusion of State of React written by Aurora Scharf. Man, it's, I just like, it's wild to think that Create React App only got sunset one year ago. Like that feels like ages ago. [19:51]
-
-**Mark:** I know. And I remember I still take 80% of the credit for that happening. [20:06]
-
-**Carl:** Yeah, right. Yeah. It's a great conclusion though. We have talked about a lot of these things that I'm reading in the conclusion, you know. Create React App sunset, Remix going away from React. The, all the server components blog posts that Dan Abramov put out, RSC Explorer, compiler went, you know, going to version 1.0, ASIG React working group. [20:10]
-
-So, yeah, I don't know. I guess I'm reading this conclusion in part as like a gr you know, a grading rubric for like, how well did we stay on top of the news as it came out? And I'm like, yeah. All right. We did pretty good. Nice. Good for us. [20:33]
-
-## [Josh Comeau’s takes on the results](https://bsky.app/profile/joshwcomeau.com/post/3mf642css6227)
-
-**Mark:** Yeah. Looking down inside of Josh Comeau's highlights thread, I, I think he calls out some, some rather interesting points. [20:44]
-
-Apparently a good number of folks have used server components one way or another, which is not a surprise because they're the default in next at this point. But he also points out that it looks like most people have not used form actions or the newer use action state and use form status hooks. That makes sense because they're, they're pretty new APIs. [20:51]
-
-React 19 only. But also it, it a little bit ties into, you know, kinda the question of like, we've all been able to write React apps very solidly since, you know, 20 13, 20 15, et cetera. [21:14]
-
-## [API pain points](https://2025.stateofreact.com/en-US/features/#main_apis_pain_points)
-
-**Mark:** Um, and so now there's all these new capabilities that fill potential app level pain points. But how many people are on React 19? [21:28]
-
-How many people are experiencing those pain points? How many people are aware that the new APIs exist to potentially help with them? And so there's an awful lot of, you know, writing React apps the same way we did in 2018, thereabout. [21:38]
-
-**Mo:** Cool. [21:52]
-
-## [State of React Native 2025](https://results.2025.stateofreactnative.com/en-US/)
-
-**Mo:** And we've also had the state of React Native in 2025, also published by the folks at Software Mansion. [21:53]
-
-And there, there's not a whole lot here. A lot hasn't moved in the ecosystem. There's a few interesting things that I thought would be, would be interesting to sort of call out. So starting from sort of the new architecture migration, it seems like out of the respondents that have been surveyed, somewhere around 80% have already adapted to the new architecture, which is good. [22:00]
-
-So it, it fits into sort of meta's view that the upgrade path is going to be relatively straightforward and it seems like most apps are by and large adopting it, which is great. Interestingly, it seems like most people's update strategy is to basically use Expo SDK release updates and they sort of update in parallel to that. [22:21]
-
-And so the idea is when Expo, every few months releases a new SDK update and it happens to be on, let's say, version 0.82, then, then people will sort of go for that. Now interestingly, what another thing around sort of react Native frameworks and talking about Expo, which is interesting to look at, is that. [22:40]
-
-Somewhere around sort of 75% of of people said that they're using Expo CLI, as sort of their framework for their React Native app. But also there's still a substantial amount of respondents that are using React Native community, CLI. So this is the old React Native CLI that used to be maintained by Meta and has now sort of been made a community package and deprecated by Meta in favor of Expo. [22:58]
-
-About 50% are still using that, which is surprising, but it also shows that there's probably a long tail of respondents that are still having apps that were built on top of the, the React Native community CLI these days. So that was quite interesting. The final thing that I thought was. Cool to look at, at a broad level was what percentage of code is being generated by ai? [23:21]
-
-So they did a, a, a bit of a question on this, and it seems like sort of if you look at the, the, the distribution here, we're talking about sort of 25 to 30% of react Native code on aggregate by the respondents is being generated by ai, which I suspect will sort of tick up. But 30% is, is quite large when you look at sort of an aggregate of the industry or of, of the entire ecosystem. [23:46]
-
-So those were sort of the, the high level pieces. If you look at the conclusion, they, they sort of highlight that, you know, some of these results are, are perhaps predictable and I think on large sort of these results are, are as expected. [24:10]
-
-**Mark:** And it looks like that that AI cogen question is under the dev tools category on the results. [24:23]
-
-## [How we rebuilt Next.js with AI in one week](https://blog.cloudflare.com/vinext/)
-
-**Carl:** Okay, we're gonna use this as a jumping off point. I think. So CloudFlare put out a surprising blog post, or I guess they released a project and announced it. They ha claimed that they have rebuilt next JS on top of Vite from scratch with an AI agent. They basically just said, here's the test suite. Go. [24:29]
-
-**Mark:** There was a person doing the driving and the, and the herding and the overseeing. But yes, it was essentially we have next tests as the spec. Can we rebuild it from scratch? But on top of Vite? [24:52]
-
-**Carl:** Yes. So they're calling it Vinext, Vite-Next, you know, get it deploys to CloudFlare workers in a single command. They say in early benchmarks, it builds production apps up to four times faster and produces client bundles up to 57% smaller. [25:05]
-
-And we already have customers running it in production. They say fascinatingly, they say that it costs them $1,100 in tokens, which is pretty good. I don't know. The other interesting thing is, so I've been playing around with AI a lot in the last month and in my like rough estimates of cost. I bumped up from the $20 a month Claude plan to the $200 a month Claude plan, and maxing out a $200 a month claude Plan appears to use on the order of $2,000 worth of tokens. I do wanna say, when it says this whole thing costs about $1,100 in tokens, that's eight raw, I believe that's raw aPI costs. And if you are using a monthly plan like you know, not API access, not a platform account, then I think it's actually included in that. So like that's interesting. If it sounds like on my limit, [25:20]
-
-**Mo:** you can do it with half of a Cloud max subscription. [26:14]
-
-**Carl:** Right. Yes. It looks like I could have done this with half of my limit in one Claude Max month, which is not that much like it's a big project, but it's not that much like half of my limit. I spent last month brought a project of mine from like pretty good to, I think I'm almost ready to start selling this in like 15% of my Claude limit. [26:16]
-
-So to totally rewrite next in half of a claw limit is like shocking. Remarkable and also sounds pretty reasonable based on my recent experiences with, you know, benchmarking code output if useful, effective code output against, I dunno, costs, then it's, so this is really interesting. This is, this ties into some, this is why it's such a good jumping off point because like Next it has years of usage and like production customers and like a company built a hosting platform around it because that seemed like a good idea. [26:41]
-
-And now some, now a competitor has taken advantage of their robust tests and everything and said we're gonna re-implement that from scratch in a matter of days for a trivial cost. [27:17]
-
-**Mark:** Similar examples. So watching Hacker News over the last couple months. A, a similar what Canis do Benchmark has been, what if we just cut agents loose to work for a few weeks and build a browser? [27:29]
-
-From scratch or a c compiler from scratch. You know, I've, I've seen both of those examples pop up and the, the big characteristic in all these cases is that it's a fairly well-defined problem, that it's fairly deterministic in terms of application behavior. And there is a massive existing test suite that helps define exactly what the behavior ought to be. [27:44]
-
-You know, we mentioned earlier the example of next reimplementing web streams as a polyfill, but building it faster. And they said, you know, there's no way we could have done this without the fact that there were already like 1500, 1700 platform tests for web streams. Similarly, browsers like the, the expected behavior for parsing HTML and all these other pieces of, of a browser's behavior are very, very strictly defined. And there's a massive set of platform tests that it can be used to compare correctness. So it's both, you know, like what other examples are out there they can reference, but it's the tests define what the expectation is. [28:08]
-
-**Mo:** Uh, on those two examples, I think the browser one was the cursor team and the C compiler was, I believe it was Claude's internal team. There was a bit of pushback on that because if you dug through it, it didn't actually compile or build correctly and needed a bit of human fixing to do that. [28:50]
-
-Admittedly, those are quite complicated tasks, right? Like building an entire browser from scratch and a C compiler is tough. This with CloudFlare coming out and saying, Hey, this is production ready and we're actually using it in product, or some of our clients are using it in production, seems to be a much bigger claim in my mind than sort of like an experimental labs effort. And it's, it's, uh, it's interesting that a company like CloudFlare is happy to put their name on this rather than it on something that's like, this is production ready. You can, they're given a commands to migrate an existing next JS project to Vinext. [29:09]
-
-Like they're really going, this is as good as next js. And so it feels like a different grade of achievement in my mind. [29:42]
-
-## CloudFlare v Vercel beef
-
-**Mark:** I mean there, there's also the existing strife between CloudFlare and Vercel that probably plays into this a little bit, but [29:52]
-
-**Carl:** true, right? There's like personal beef between the CEOs of those two companies. [29:58]
-
-So I'm sure that was a motivator here as well. Okay. There's personal beef, but there's also like legitimate technical questions here. Like, Vercel and CloudFlare are each trying to push their own visions of what hosting providers could be, and they're interesting. You know, I've been more interested in the CloudFlare vision of what hosting can be. [30:02]
-
-Workers sound really cool, like, you know, it seems like a plausible achievement of the vision of serverless, you know, that I've been hearing for my entire career. So I've been very curious about that. I've used it a little bit, and CloudFlare also was doing Open Next before, which was an adapter, so you could use, basically adapting the versal specific runtime things so that it could use it in other platforms. So like this does feel in keeping with the kind of work CloudFlare has been exploring with, but agreed that this is a categorically different kind of plane than like, ooh, we made a, a C compiler. Like no means is seriously using an AI generated c compiler in production. Like, not right now. [30:23]
-
-**Mo:** It, it's interesting. So talking about sort of like Cloudflare's platform, I've, this is sort of a, a tangent, but I've been building sort of two side projects, two mobile app side projects with ai and I'm defaulting to using CloudFlare workers durable objects and all of that because it's, it's actually like quite good for AI to understand in terms of the primitives and doesn't have to deal with like the complex architectural bits of like defining a region and stuff like that. [31:08]
-
-So I can, I can, I. I think it's actually like they have a good AI play that they can execute here as well. Beyond just, you know, articles about how they can rebuild next JS with ai. [31:35]
-
-**Carl:** Yeah, right. [31:46]
-
-**Mo:** Now there's one thing in this article that I find quite interesting. So I've spent a lot of time battling with the C of next js, and specifically when you're trying to deploy an xjs in certain sort of custom non-cell environments, it comes with a lot of complexity. [31:48]
-
-You, you're gonna have to define your own sort of like cache handler and they seem to have just popped all of that in CloudFlare kv, which is their sort of workers key value store and it's quite interesting that that, that is sort of the direction they've gone through. They say that you can also use R2, which is sort of their S3 equivalent. [32:05]
-
-Great name by the way, because R two is one character before. S3 on both sides of it, which I think was a dig at AWS, but the caching strategy and allowing for you to customize that cache, I think super easily with some of their primitives is, is quite nice because that is always been a pain point for custom deployments of, of next js. [32:27]
-
-And I think probably one of the biggest barriers to people, you know, hosting next JS in, in other cloud providers that I've seen in the possible and you have custom setups. [32:48]
-
-**Mark:** I mean, that is, as always, my caveat is I haven't worked on large scale production commerce e sites, so I have no practical experience with this. [32:58]
-
-But anecdote like we, we know the know the phrase, you know, the, the biggest error problems are, you know, off by one and caching errors or something. Something of that effect. And certainly anecdotally over the years, you know, like one of the biggest complaints about a polygraph QL was the complexity of the cache implementation. [33:06]
-
-We've seen a lot of complaints about next and their page caching implementation, and we've seen them go through, you know, 2, 3, 4 different iterations and approaches to caching and, you know, caching all the different layers of the system. So it's not surprising that this is a pain point. And so, yeah, I can, I can see CloudFlare saying, what if we, what, what if we do something different and maybe somewhat simpler. [33:24]
-
-**Carl:** Also, man, I gotta say thank you to Super Kennel in chat for sharing this post from Guiller Moro of titled "Migrate From Vercel to CloudFlare. And, um, you know, it's got this table of contents at the top, like project setup, migrating custom domains, converting build and deployment, moving environment variables, rewriting, and, you know, it's like 12, 15 items, something like that. [33:48]
-
-And like a quite long blog post. Whereas this CloudFlare, you know, we rebuilt next AI is saying, oh, just try it. Install this AI skill and then type migrate this project to V next in your favorite in any supported tool, and it'll do all the stuff for you. And I'm like, those are two entirely different levels of effort. [34:12]
-
-And I think CloudFlare handily wins there. That's interesting, assuming it actually works as, [34:35]
-
-**Mo:** it's funny because in one of the comments the Guillermo says, I'm migrating from Versal to CloudFlare. Am I doing it the wrong way around? And Guillermo's just like, yes, delete all of that. Rang blur, Jason C config nonsense, and all of the proprietary imports and just run it on Versal. [34:40]
-
-So this has clearly struck a nerve because they've launched this pretty much on the same day that they made this announcement or you know, day after. [34:55]
-
-**Carl:** Yeah. Right. Delete all the wrangler adjacency, config, nonsense. Like are, is versal gonna try and claim that next doesn't have config nonsense. Like you do not have a leg to stand on there. [35:04]
-
-**Mo:** There's, there's no legs to stand on. Especially if you've tried to deploy an Xjs project outside of Versal, it is pain. So no respect there. [35:15]
-
-**Mark:** Interesting. So there's, there's lots and lots of angles we could try to discuss here. We've, we've looked at. Rebuilding apps or tools that have known test suites and what does, and we, we really haven't even touched on what does that mean in terms of companies having a moat. [35:24]
-
-In fact, Carl, you wanna, you wanna toss that post in there at the moment? [35:39]
-
-## Carl Vitullo monologs about AI Agents
-
-**Carl:** Yes. Yes, I do. Also, I wanna, once you're done, I want to monologue for a moment, [35:42]
-
-**Mark:** couple other angles we could look at. I mean, there's, there's the ever popular, you know, what does all this mean for us as software engineers and our industry and our careers going forward? [35:47]
-
-And just how doomed do we all feel as well as, you know, what are we doing with AI on a day-to-day basis. If anything, Carl monologue go. [35:57]
-
-**Carl:** Yes. Ah, I alluded earlier to playing a lot with agents. A good internet friend of mine made a very silly AI agent, MMO. So it's like a text based, if you're familiar with like a mud, a multi-user dungeon. It's basically that. It's a text based MMO that you can play through your terminal, and it's only for ais to play. Not everyone is, but, so I've been using that to learn about how to do agents and how to run AIs autonomously for a longer period of time, which has been fascinating. And so this, I've now watched somebody in real time, like I heard about this project. [36:07]
-
-I went, oh, neat. Let me set up an AI to play this game. So I got there on like one, I think after it launched. Somebody else who got there on day one fucking ran with it has been, you know, he's been working professionally on AI agents for a year, he said. He already knew how to do all the harnesses in the orchestration, which I, you know, I had never tried to do either. [36:44]
-
-So I'm learning this from scratch watching him do it with a year of experience and like, holy shit, it is unbelievable how much code he produced. I think the total amount of code is like, now, I dunno if it was 60,000 or 600,000 anymore, but it's like a lot of code and it works like not perfectly. There's a lot of duplication, there's a lot of errors, there's a lot of, you know, like this code path looks like it works, but actually you get into the details and it doesn't quite work. [37:06]
-
-But like, as we use it, we like, so these AI agents are instructed as part of the game, like, "Not everything works. Please submit bug reports as you find them. Then this guy has his own agents that are reading those bug reports, turning it into reproductions, and then writing tests and fixing them, like largely autonomously. [37:34]
-
-Not completely autonomously, but largely, which now has me imagining this, like imagine if you set up, you know, you have an idea for a product, you build a prototype. You put it on a server and then you have on the, on that same server, a little sidecar or you know, running in the same environment. I mean maybe not literally on the same server. [37:55]
-
-An AI agent that is receiving user feedback. Like, you know how like every major enterprise application will say every so often, like, "we value your feedback. How are you using this product?" And then you fill that out and it goes into the void and nothing ever changes. You never hear about it again. You never get asked for a follow up and the bugs that you reported never get fixed. [38:16]
-
-Like what if that went into an automated system that triaged, reproduced and fixed things in real time autonomously as you submitted reports. Like that now appears to be within the realm of possibility. Like, like not theoretically in the future, but like currently I have seen tech that looks like it might be able to do that, like maybe not fully autonomously right now. [38:38]
-
-Oh God. Like pretty good. Pretty close. So that's fascinating. I think that's really interesting for the idea of like a one person startup, you know, a small team operating at a scale that previously would've required 50 to a hundred people. I think that's interesting, like scratching your own itches and publishing it so that other people can use it, and then soliciting feedback to guide the development now looks really powerful. [39:04]
-
-So I, that's when, you know, as we as, as we speculate on the future of development and what software development is going to look like, I think it's gonna be a lot of wrangling, that kind of stuff. Like, you know, I put up a little, little blog or no, I put, I posted on Blue Sky that after I was experiencing all of this and being like, holy shit, this feedback is incredible. [39:32]
-
-This feedback mechanism is incredible for guiding AI development. I had the thought of like, man, it feels like now the determining factor for how good software can be is how many people are using it, and how good those people are at articulating what they want out of it. Which is a really interesting place. [39:51]
-
-And I think that's all I have to say. [40:13]
-
-**Mark:** There's a little bit of the, you know, you just keep towing it, make it better, make it better, a fixed bug, make it better. [40:15]
-
-**Carl:** A lot of that. But you know, it's like there's also the aspect of like the more precisely you can articulate what is deficient, what better looks like, the better it works. [40:20]
-
-It's remarkable. Like I've seen it. It's so cool. I don't know, it's interesting. [40:31]
-
-**Mo:** There's sort of like. A few thoughts that I've got. There's anecdotally my whole like coding setup and how much code I can get through as a person who's been coding less and less and more. Dealing with systems and leading teams over the last few years has just been crazy. [40:35]
-
-Like my, I looked at my contribution graph on GitHub and I've done in the last two months now, done probably half of my commits that I did in the last year in 2025 in two months. And it, it's just gonna go up and up because it's been a lot more over the last. A couple weeks. And so producing code is significantly easier, especially to do as sort of someone that's instructing things at a high level. [40:52]
-
-I've been working on two side projects and both of those are like weekend projects that I would never have gotten anywhere near to completion. But I'm pretty much ready to launch one, like almost to the step of I I, I just need to push it to the app store at this point, which I have never been able to do just because I've never had the attention span to finish it off. [41:19]
-
-So that's been just something incredible. [41:40]
-
-**Carl:** If I can interrupt for a second, because same projects executed, ideas initiated exactly the same. Like I did things that I never would have because I would've looked at it and gone, oh, I know how much work that's gonna be, and I don't know exactly. [41:44]
-
-**Mark:** It's same for me. [41:57]
-
-Yeah. Mm-hmm. [41:57]
-
-**Carl:** I did them at the same time as each other. Like, I'm working on two or three projects in parallel, like while watching a movie with my partner. And, you know, and like I checked in with them to be like, Hey, like I was working, like, did I seem checked out? Or like, was I still present in the room? [41:59]
-
-And they were like, yeah, no, you were like, you followed the conversation and participated. So I, it's like I was more productive than I've ever been and I got to hang out with my partner and their roommate. Like, what? That's insane. [42:15]
-
-## AI productivity and impacts on our attention
-
-**Mo:** Well, well it's, it's only gonna get worse because they released the, the, the, the Claude folks yesterday that released this remote access mode where you can hook into your local, just hooked it up to your phone so you can actually just keep it, keep a track of what's happening on your phone. So this is only just gonna, every night of watching movies and TV shows is gonna be augmented by some level of productivity on the side, which is both terrifying and very exciting at the same time. [42:27]
-
-**Carl:** Yes, it is terrifying. It is, right? It's like such a productivity boost while also not demanding that much attention. That like, why wouldn't you just always have, you know, a, the little back corner of your brain thinking about this? [42:52]
-
-Which like, I don't know, my brain already works that way. I like, I've already poisoned my brain to be addicted to thinking about the problem. You know, like, huh, that's interesting. I mean, I've, [43:06]
-
-**Mark:** I've, I've, I've read a number of articles of people who are dealing with, I don't remember the actual term. I, I don't know, to token attention deficit or something like that. [43:15]
-
-Ba basically it, it's this constant feeling that, you know, okay, like I could be having multiple agents doing stuff for me at any given moment, and therefore any moment where I don't have 5 to 10 agents running is a waste of theoretical productivity time. So if I didn't spin them up before I walked out the door, that was a waste of time that I could have built, or, you know, I have to get back to, you know, double check the results and that quickly becomes its own form of productivity burnout. [43:22]
-
-Just [43:53]
-
-**Mo:** to give like a very concrete example on one of these projects, there's a sort of TikTok style video feed that I had to implement. I did this for a client on one of our actual projects at work that took somewhere around seven to eight days of me develop. We went back on like the Trello board that we were using and looked at the, the estimates of how long that that whole feature took, and it was about seven to eight days to get it working. [43:54]
-
-End to end. I was building something very, very similar for this, for the side project, and it took me a couple of hours to get that whole feature working end to end. So like I know more what I'm doing, I've done it once, I know where the pitfalls are, but at the same time it just, there there is a significant productivity boost here and it's, it's definitely not something that you can, you can ignore anymore. [44:17]
-
-## ["wrote a spec, pointed Claude at an Asana board, and went home"](https://x.com/rvivek/status/2026385957596111044)
-
-**Mo:** There's sort of two interesting things that I've seen over the last, you know, few hours. One is this post from a podcast by the guy who made Claude Code or his churn and he talks about how people are going back to Mark's point about this like productivity attention deficit. Where there's some anthropic engineers who are like leaving Claude code to look at the board, the project board over the weekend, breaking it up into specs, and just spawning it up into building a bunch of different agents that'll build tickets for you and do it in parallel and then you come back and review it on Monday, which is gonna be interesting to see how that goes. [44:42]
-
-But also, you know, there's an interesting one where Karpathy, who you know, used to be a Tesla sort of director of AI and so on and so forth. Original Open AI team has written this like tweet where he talks about how it's really over the last two months where things have just like completely accelerated and it feels night and day in terms of agent decoding. [45:24]
-
-So I think things are moving at a super fast pace. It means we're all probably feeling a good level of FOMO as a result of it, and it's faster than any one person can sort of stick to, which is, which is. Again, exciting and terrifying at the same time, is the only way that I can think of describing this. [45:46]
-
-**Carl:** Yeah. In our, you know, mid month DM chat Mark you had said, who's this? Zach, who's talking about [46:02]
-
-**Mark:** Abels? Zach Jackson is the creator of Module Federation. He joined the web back team a few years back, he now works at ByteDance slash TikTok. And he is an Uber example of, oh look, I have an army of 100 agents running simultaneously. Someone gifted me $60,000 worth in tokens. I'm going to burn most of it by migrating entire projects to Rust overnight. [46:09]
-
-**Carl:** Yep. And like, right, and like the quote you would put here, and it's not a literal quote, but the energy is, I can run a hundred agents, my only limit is token budget. [46:33]
-
-And I'm like, I have started to understand that perspective. 'cause you know, like. What you were just saying about like this person who, you know, wrote a spec and pointed Claude at Asana board, like, yeah, cool, that's awesome, that's great. But like also you don't need to write the spec yourself because if you are just taking user reports and they are submitting things to an agent that is triaging and then summarizing and then if you break down all these little parts into a system that has its own little feedback loops and review stages before passing it off onto another thing that has its own review stages and you know, iteration, then like, holy shit. [46:42]
-
-I understand why people are saying the only limit is token budget because each part of this is working. It's not like theoretical. [47:19]
-
-## [Bits AI SRE | Datadog](https://www.datadoghq.com/product/ai/bits-ai-sre/)
-
-**Mo:** People have already started productizing this. So Datadog has released, it's gonna link it in the chat, this bits ai, SRE, which is. The detection part, which data Datadog already did, which was, oh, there's an issue in production. [47:26]
-
-Okay, crap, we need to fix it. And then they've just lopped on agents to resolve these incidents automatically. So auto investigations, if you're really bold, I think you can just merge it, get it to automatically merge fixes for you across your code base. Like that's the direction we're going through. [47:40]
-
-**Carl:** And I'll even say like. [47:56]
-
-So, okay, great. Datadog productized this like, I don't fucking need it because I was dealing with database corruption in a project I run, and literally what I did was, you know, it was like something started breaking and I opened Claude and I said, here's my Kubernetes cluster, the database, something's going wrong. [47:59]
-
-Can you check the logs? And it did correctly identify the database corruption and then repaired it live like, and just fixed it. Then it became a recurring issue and I had to figure out what was going on and man manage a migration because I had left it in a half state that was causing the corruption. [48:17]
-
-But like, I don't know how to diagnose database corruption. That's, yeah. You know, that's database administrator kind of expertise. And I'm not a database administrator and this isn't even a specialized tool. This is just Claude Code. So like the future's here, we're in it. [48:34]
-
-**Mo:** For better or for worse. [48:51]
-
-**Carl:** Yeah, that's fascinating. [48:53]
-
-**Mo:** So there's, there's this one sort of chart that I saw, which just shows like the adoption of it so far. And obviously we're very close to it in the software industry because, well, we're, we're sort of dogfooding on our own workflows to start with. There's a debate on whether or not this will translate for other industries that, just taking a step back and looking at the, the wider economics of it all, it seems like, you know, there's been about a 50% of agents that, so philanthropic releases, they, they were saying that 50% of the agents that they've seen deployed so far are in the software industry and then it trails down like crazy after that to, you know, sub 10% for all other industries, which makes sense, right? [48:55]
-
-The question is how much higher can that go in the software industry and then will all of the other industries catch up? And I guess where I'm going with this is, what does this mean for just the greater economy and the entirety of the workforce. Like if everything is just constrained by that token budget that we were talking about, there's some really scary stuff coming out for the economy globally. [49:38]
-
-Going forward. And maybe that's a bit dooms date with me to say, but I, I am a little concerned about where we're going. [50:01]
-
-**Mark:** Yeah. I mean, if you, if you wanna zoom out for a second, you know, the, the extreme version of that was the AI 2027 sci-fi scenario projection that was put out a year-ish ago, which was put together a fictional version of how we end up with a true terminator level Skynet AI coming out in, you know, two and a half years, the slightly less, but still dooms day-ish version of that. [50:07]
-
-There was a, a report from Sat Trini research or something that came out just a couple days ago, which was a fictional news report from 2028 talking about how AI usage ended up, ends up tanking the economy in the next couple years and, you know, wiping out white collar jobs. And so I've seen a few different variations of that. [50:31]
-
-And, you know, a lot of these, you know, the questions are, you know, what are the, what are the assumptions going into, um, in the first place? And, you know, okay, fine, it's a scary sci-fi story, but. You know, there's, there's some plausibility to that stuff. [50:50]
-
-## [ThoughtWorks opines on AI productivity impacts](https://simonwillison.net/2026/Feb/14/thoughtworks/)
-
-**Carl:** So I wanna pull in, we had this quote from thought, the ThoughtWorks offsite. [51:04]
-
-ThoughtWorks is a very well regarded what agency from like, they've existed for decades. They've been involved, they've been very deeply involved in tech for a very long time in a very meaningful way. [51:09]
-
-**Mark:** They're not just a development agency, but they, they've document like software engineering processes and patterns for many years. [51:24]
-
-There's a guy named Martin Fowler who has, who has done a lot of that work and he, he's written dozens of articles on, like, we've talked with many, many companies and these are like the distilled best practices we see on how to build software across the industry. [51:31]
-
-**Carl:** Right? Like Martin Fowler, I would say is one of the reasons that people do blogs now, like a lot of people in tech learned so much from reading Martin Fowler's blog that I think that was a significant contributing factor to the advice to every person in tech to have a blog. [51:49]
-
-**Mark:** Right. I also associate them with the software craftsmanship movement. I, I think there was another consultancy called Eighth Flight Background, like 2005, 2010. [52:07]
-
-Well, like Uncle Bob Software craftsmanship, code Katas, like treating software development as a craft rather than a manufacturing exercise. So I, I, I associate them with that kind of pattern. [52:17]
-
-**Carl:** I also had forgotten this, but they authored the Agile Manifesto. So yeah, like, okay. So that's enough introduction I think for ThoughtWorks, like they have had so much influence on the tech industry generally, and so they just did an offsite discussing the future of tech, future of software engineering. [52:31]
-
-And I'm gonna read at least this first paragraph, maybe both paragraphs of this quote, the retreat. "The retreat challenged the narrative that AI eliminates the need for junior developers. Juniors are more profitable than they ever have been. AI tools get them past the awkward initial net negative phase faster. [52:52]
-
-They serve as a call option on future productivity and they are better at AI tools than senior engineers, having never developed the habits and assumptions at slow adoption." [53:09]
-
-I'll say call option is a financial term. Calls versus puts are options to buy or sell. [53:17]
-
-**Mo:** I cannot believe they call junior developers call options. [53:24]
-
-**Carl:** I know it like, oh, it's so like do we in the weeds jargoning, but also like, yeah, sure. A call option is when you say it's you're buying a futures contractor saying, I think this is going to be worth more of the future, and other people disagree, so I'm gonna buy it now. [53:27]
-
-**Mark:** Bet that it goes up over time. [53:43]
-
-**Carl:** Exactly. So like, it is actually a very good analogy here, but like, I don't know, maybe don't reduce the employment of early career people to a financial instrument. Like it's not great. People are more complicated. [53:45]
-
-**Mo:** Yeah. [53:58]
-
-**Carl:** This is such a like, antidote to the doomerism, I think. Like, yeah, they haven't learned the bad habits. [53:58]
-
-They aren't so deep in the weeds as the senior developers are that they're going to like micromanage and just kinda let it do the thing because it's act, the tool is actually very smart. So that's, uh, yeah, like this, [54:04]
-
-**Mo:** I can see that that's the direction they're trying to point this at. At the same, to play, uh, a devil's advocate to that point, the job market seems to be saying something very different. [54:17]
-
-So I'll put a screenshot of this from a study that was released by some Harvard folks. I'll put that, but I'll, I'll link the actual study itself and. This is basically showing sort of like the demand in the job market in the US for senior and junior profiles since the launch of chat GPT. So we're talking sort of 20, 23 time and someone coined this as sort of like a K based was talking about this as like the K based or K shaped feature of software engineering. [54:27]
-
-And there is a dip and it is a hard market at the moment for juniors. So I'm interested how this pans out for junior developers. [54:59]
-
-**Carl:** Yeah. I will say though, y'all listening cannot see this chart. It's got a blue line for seniors and a red line for juniors and it charts the average employment like percentage change. [55:08]
-
-This is a delta, the chart is of the first derivative of employment, I guess it's, you know, rate of change. So a higher number is not only more, but it means that it's accelerating faster. And the blue line, the senior developer line is steady improvement. So it means that it's actually, it's not just improving, it's actually accelerating and how fast it's improving. [55:21]
-
-I believe that's, I believe that's what this is saying. Whereas the junior line matches it, oh, I guess the X axis here is 2015 to 2025. The lines are pretty well paired from 2015 to 2020, and that's when they start diverging and like there's a dip for both. But the dip is bigger for juniors in early 2020 [55:43]
-
-**Mo:** up until sort of that 20 22, 20 23 period. [56:04]
-
-Yes, there's a dip and then it's, the junior is still like going up slightly. It's starting to bounce back, but then now going from 2023 onwards, it is headed in that direction of a downward slope. [56:08]
-
-**Carl:** My intuition matches what this ThoughtWorks quote says, that it's a force multiplier and less experienced people are actually more effective at taking advantage of it. [56:22]
-
-So that feels to me like one of those unintuitive things that hard to justify at a big company. So, I don't know. My, my, my optimism is that cool, here's a highly reputable thought leader, you know, thought leader of thought leaders saying, no, wait, junior developers have the best return on investment they've ever had. [56:32]
-
-That feels like it could turn this around. I don't know. That's interesting. [56:55]
-
-**Mark:** I, I actually really recommend that folks download the PDF report that they put together, summarizing all the different discussions they had at this retreat. There's a lot of very valuable career and industry where we headed material in there. [56:58]
-
-**Carl:** Okay. Oh, I mo I left you in suspense earlier. I said I was gonna use my favorite analogy and here it is. Two years ago I heard an analogy of AI in software compared to the introduction of spreadsheets to the field of accounting where up until the digital spreadsheet, like basically until not Excel, Excel wasn't the first, but before we had tools like Excel, the role of an accountant was basically a calculator. You know, the classic depiction in old movies of they got the green visor on and they're sitting there over a, you know, over a calculator just crunching the numbers and like that was the job. [57:13]
-
-And then you got a spreadsheet and then you put the numbers in the spreadsheet and you do some and it's done. And so there was a lot of panic about like, oh my God, this is gonna destroy the field. Like this is the work. Then now the work is just done. But like we still have accountants and they do more than ever. [57:51]
-
-So that's how I am viewing this. That's my optimistic take on it, is like, yes, it is going to totally transform it. It is going to obviate a large number of skills that are highly valued right now, and it will look different, but I don't think that's necessarily going to mean destruction. [58:07]
-
-**Mark:** I will, I will put together my obligatory plug to say that this heavily emphasizes that having baseline experience with the tools and the concepts and the abstraction so you know, where you're trying to guide it and how the stuff works will be more valuable than ever. [58:24]
-
-**Mo:** I'm hoping on that being the case, the only thing that concerns me is the likes of Zach, which was the example that we gave before where he's like, the token is my only limit. And I wonder like when we, when we went into accountants using spreadsheets, you still needed a person behind the, the sort of system to do it. [58:39]
-
-But if. These systems sort of largely become self-running, and the only limit is the tokens. Then I worry if I, I hope the analogy holds up my, like, pessimistic doomsday clock makes me worry that it might not hold up. Same thing with the tractors plowing the field analogy that I've heard a few times. I hope that this niggling that I've got inside of me is just completely doomsday and it's, it's not actually accurate. [59:00]
-
-**Carl:** No, that is fair. I think even if all the technical things goes the same direction, I think that there are environmental things that could very much alter, I don't know, the experience, the outcome. I actually, the farming one is an interesting thought because, you know, now farming, you know, per unit effort to get to grow a calorie of food, it's easier than ever, but the tooling required in order to get that benefit is more expensive than ever. [59:28]
-
-And so what I've really, what I've heard for years is that. The average, the family farm is no longer feasible because you need nine different tools that each cost three quarters of a million dollars and have expensive, you know, support contracts, because John Deere doesn't let you fix your own tools anymore. [59:57]
-
-That's very real. This is just like, so not a good thought, but hey, maybe we'll get a good regulatory environment that drives positive outcomes, [01:00:14]
-
-**Mo:** if that's what we're, if that's what we're hoping on, I am really worried. [01:00:22]
-
-**Carl:** Yeah, that's a good joke. [01:00:27]
-
-## ⚡ Lightning round ⚡
-
-**Carl:** Anyway, anyway, let's do the best Lightning rounds. Let's not do all of them. I'm not gonna do all the conferences, [01:00:28]
-
-**Mark:** okay. In no court order. [01:00:36]
-
-## [“Wall Street Raider” game modernization](https://www.wallstreetraider.com/story.html) (and uses Preact)
-
-**Mark:** That's a really good blog post or on hn someone, one guy wrote a complicated basic game back in the 1980s called Wall Street Raider, which is supposed to be the deepest, most involved simulation of the market ever, but it was a complicated text mode game and decades later, even, he barely understood how the code worked. [01:00:37]
-
-Lots of people had tried to modernize it, it all failed. And then one. Kid offered to do it and ended up building a better ui, much like a dwarf, fortress, fortress kind of a thing on top. Uh, and apparently it's even built with pre-ACT. So just the story alone is worth reading whether or not you even get around to playing the game. [01:00:56]
-
-**Carl:** Yep. Love that. [01:01:15]
-
-## [Github Stacked Diffs preview](https://x.com/jaredpalmer/status/2019817235163074881) , [faster Issues search](https://github.blog/changelog/2026-01-29-improved-search-for-github-issues-in-public-preview/)
-
-**Carl:** We talked about it a couple of times, Jared Palmer of Formic and Yup. I think. Yup. And a couple of other, you know, he's very influential in the React ecosystem has been, is now a PM at GitHub and he's working on Stack Diffs. Which are something I've been craving in GitHub for 10 years, literally. He's been teteasingittle bits of it here and there, but he, so he, he put out, he posted on Twitter that fact diffs on GitHub will start roll, rolling out to early design partners in Alpha next month. So within the next two weeks or so, some people may have access to stat fits, which is just such good news. [01:01:16]
-
-I love that so much as well as there's improved search for GitHub issues and public preview. So that's, that's pretty cool. [01:01:58]
-
-**Mark:** Which, which I've seen. It's, it's much, much snappier [01:02:05]
-
-**Carl:** Good. [01:02:07]
-
-## [Josh Comeau: Sprite animations](https://www.joshwcomeau.com/animation/sprites/)
-
-**Mark:** Everything that Josh Comeau posts is worth taking a look at because he's put so, so much care and attention into his blog posts and explanations and he did a post on Sprite animations and especially how you can do them on the web. [01:02:08]
-
-Josh is wonderful. His posts are lovely. You should read it. [01:02:21]
-
-**Carl:** Yes. Cosign. [01:02:24]
-
-## [Interop 2026](https://wpt.fyi/interop-2026), ([WebKit](https://webkit.org/blog/17818/announcing-interop-2026/), [Igalia](https://www.igalia.com/news/interop-2026.html))
-
-**Carl:** So Interop 2026, which is a cross browser initiative to make the web standard more consistently implemented across browsers, has announced their like 2023 roadmap. So the, uh, active focus areas are container style queries, CSS anchor positioning, the, uh, adder, attr() CSS function, contrast color, shape, zoom, custom highlights, dialogues, and popovers index db, which if we have a meaningful client side database, that would be great. [01:02:26]
-
-We have that, we've needed that for so long, and it's just hard to get specified. So love that Interop on a client side database. Woo. Yes, let's do it. [01:03:00]
-
-A bunch of other things that's, you know, it's a, it's a very long list. This is a site they use to track the compatibility across Chrome, edge, Firefox, and Safari. [01:03:09]
-
-It's pretty good. This is deep in the weeds, but this is like the cutting edge of browser development, so very cool. Excited to see what they, what it looks like next by the end of the year. Okay. Sounds like that's all we got now. [01:03:21]
-
-**Mark:** Plenty over time and covered plenty of items. [01:03:33]
-
-**Carl:** Yes. [01:03:35]
-
-**Mark:** Y'all got your money's worth this month. [01:03:36]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** I'm gonna put conferences in the transcript if you wanna see what's coming up. Just do look for that in a couple days. Thank you so much for joining us, everyone, as we go over time rambling about AI ranting and rambling about AI and how cool and terrifying it is. We will be back on the last Wednesday of next month here in the live stage of Reactiflux, or back in your podcast feed just as soon as we can. [01:03:38]
-
-**Mark:** Kristen, do just a, a random offshoot episode talking about how we personally do and do not use AI in our, in our own workflows. [01:03:58]
-
-**Carl:** Agreed. That's interesting. Maybe that'd be a good check-in thing to do. I dunno. Maybe we, shit we should make, we should do more community events. I, you know, introduce myself as that every month. [01:04:05]
-
-Cool. We gather sources mostly from our own tech reads and news channel nowadays, so if you see anything that you think might interesting to discuss, definitely let us know in there. Or you can also email it to us at hello@reactiflux.com. Yeah, I'll read it if you send it there. This is a show that you get value from and wanna support. [01:04:14]
-
-Best way to do so is by submitting a review wherever you listen. I have seen a couple of new ones roll in the last couple of months, and I am pleased to report that our Spotify rating is still five stars. So that's fun. Thank you. Thank you for the positive reviews. I'm glad you all appreciate it. [01:04:35]
-
-**Mark:** I can throw a really quick, cheap corporate plug replay. [01:04:50]
-
-My employer is refocusing on the time travel debugging use case, except that we have just built an MCP that Exposes a lot of our really powerful time travel analysis awesomeness to your AI agent of choice. And even in just my own dog foodie, and I've seen. You know, Claude, whatever, be able to start investigating the contents of recording and see what's going on and fix bugs that it might not have been able to fix otherwise. [01:04:53]
-
-And I'm also working on some proof of concept performance analysis stuff, digging deep into the internals of React. We would love to have folks try it out if you have questions. We've got some examples in our docs of adding the MCP and I'm also very happy to talk about how awesome it is. [01:05:18]
-
-**Carl:** Hell yeah. Dope. [01:05:33]
-
-See you next month everyone. [01:05:35]
-
-**Mo:** See y'all soon. Bye. [01:05:36]
diff --git a/src/transcripts/tmir-2026-04.md b/src/transcripts/tmir-2026-04.md
deleted file mode 100644
index 3fda37f..0000000
--- a/src/transcripts/tmir-2026-04.md
+++ /dev/null
@@ -1,596 +0,0 @@
----
-title: "Mark & Carl talk with Swizec Teller about using AI at work"
-date: 2026-04-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Swizec Teller as we discuss the state of the software engineering profession. How are we working?"
-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:26](#introductions)] Introductions
-- [[00:02:36](#what-convinced-you-ai-code-tools-were-worth-using)] What convinced you AI code tools were worth using?
-- [[00:04:24](#using-early-chatgpt-for-db-migrations-)] Using early ChatGPT for DB migrations
-- [[00:06:59](#watching-ai-use-a-command-line)] Watching AI use a command-line
-- [[00:08:16](#background-chat-agents)] Background chat agents
-- [[00:08:58](#staying-very-hands-on-while-using-ai-tools)] Staying very hands-on while using AI tools
-- [[00:11:00](#driving-ai-closely-without-reading-its-code)] Driving AI closely without reading its code
-- [[00:17:50](#marks-workflow-opencode-with-codenomad-ui-plus-idegit-ui-opus-46-on-api)] Mark's workflow; OpenCode with CodeNomad UI, plus IDE\+git UI. Opus 4.6 on API
-- [[00:20:39](#swizecs-workflow-latest-cursor-on-opus)] Swizec's workflow, latest Cursor on Opus
-- [[00:23:58](#carls-workflow-mostly-claude-code-but-looking-at-custom-orchestrators)] Carl's workflow, mostly Claude Code but looking at custom orchestrators
-- [[00:25:23](#exploring-fully-autonomous-agents)] Exploring fully autonomous agents
-- [[00:28:08](#marks-ai-debugging-work-in-react-core)] Mark's AI debugging work in React core
-- [[00:31:42](#value-of-providing-more-context)] Value of providing more context
-- [[00:33:58](#ai-owned-documentation)] AI-owned documentation
-- [[00:37:09](#using-good-engineering-practices-still-matters)] Using good engineering practices still matters?
-- [[00:40:47](#how-do-you-know-the-right-code-to-make)] How do you know the right code to make?
-- [[00:42:49](#good-communication-still-matters)] Good communication still matters
-- [[00:45:13](#what-will-review-look-like-in-the-future)] What will "review" look like in the future?
-- [[00:46:17](#automating-functionality-tests-with-deployment-practices)] Automating functionality tests with deployment practices
-- [[00:51:49](#what-behaviors-belong-to-the-agent-and-what-fundamentally-cant-be-part-of-the-agent)] What behaviors belong to the agent, and what fundamentally can't be part of the agent?
-- [[00:56:17](#impacts-of-llms-on-software-engineering)] Impacts of LLMs on software engineering?
-- [[01:03:22](#a-superpower-right-now-is-a-domain-expert-who-can-kind-of-code)] A superpower right now is a domain expert who can kind of code
-
-# This Month in React April
-
-**Carl:** Hello, everyone. Thank you for joining us for this month in React, which is not going to be particularly React heavy. [00:00:00]
-
-Mark and I have been talking for a couple of weeks now about doing a, like, bonus episode of sorts to talk about AI and how we're using it. So we are just, instead of a bonus episode, we're, we're just gonna do that for this month, for April. [00:00:06]
-
-Yeah, and apologies for last month. We had a recording problem, and we, it was completely unsalvageable, just nothing to save. Big bummer. [00:00:19]
-
-## Introductions
-
-**Carl:** But yeah, so I am Carl. I am joined this month by Mark Erickson and Swizec Teller. yeah, we're gonna talk about AI because it's been a huge part of each of our workflows for the last, like, ranging from, like, three to six months to a year or more. [00:00:26]
-
-Let's do some intros first. I guess Mark and I are reasonably well known, but I'm Carl. I am a staff level software engineer and engineering manager and community lead here at Reactiflux, where I do events like this and build code to keep the community operating. [00:00:43]
-
-**Mark:** I'm Mark Erickson. My day job is ReplayIO, where we've built a time traveling debugger for both humans and agents with ReplayMCP now available. Please check out our blog. I just put up a blog post on how Replay found a bug faster than Dan Abermov did. I am still the Redex maintainer. Honestly, I haven't done much Redux stuff in the last few months because all my brain space has been taken up with day job work. And also, I'm going around to a whole bunch of conferences this year. [00:00:58]
-
-**Swizec:** I'm Swiz. I work at Plasmidsaurus, we are a DNA sequencing as a service company. We do a lot of React for really fancy data visualizations for stuff like, "Hey, wh- how do you visualize a few million data points in the browser and make it work smooth?" Stuff like that. And these days, I'm kind of more of a manager than an IC really. [00:01:23]
-
-And I've been thinking a lot about what kind of engineers get hired these days. We've been hiring a lot and using more and more AI to write the code. [00:01:45]
-
-**Carl:** Yep. Believe that. Cool. Yeah. So we were just chatting a little bit about what shape this conversation's gonna take. Just to level set a little bit for everyone listening. [00:01:55]
-
-We're gonna start off kind of at the point of, like, what convinced us that AI was a tool worth taking seriously and, you know, getting AI pilled as it were. Go from there into how we're using it now, what problems we're using it to solve, with what tools, as well as kind of, like, what aren't we using, what don't we find useful and compelling? [00:02:04]
-
-And go from there to, like, landscape of, like, what tools are available, what's out there, where do we think it's gonna go, and then kinda close out with what do we think the impacts are gonna be on the industry more broadly. [00:02:24]
-
-## What convinced you AI code tools were worth using?
-
-**Carl:** Mark, you wanna start us off talking about what convinced you that AI was worth using? [00:02:36]
-
-**Mark:** Sure. A year ago, I was dead set that I would never, ever allow AI to write code for me. It was a fate worse than death. It was destroying my career. I refused to do it. And in fact, I actually wrote a 15,000 word blog post over the weekend that I haven't published yet that will give the long form version of this story. [00:02:41]
-
-The short form is, over the summer last year, I cautiously started using AI to explain an existing code base to me. You know, just give me some architecture docs, walk me through the data flow. And then there was a three-day period in late August that blew my mind. On a Tuesday, I asked it to write some redux unit tests for me because my brain was too tired to write actual code, and it did, and I was stunned. [00:03:02]
-
-On Wednesday, there was a node compression library that I've been trying to replace, but the alternative didn't have all the features we needed, and it's Rust-based. And I tried asking the AI to write the feature for me in the Rust library, and it did. It actually didn't quite work right, and the maintainer had to turn down the PR, but this was the first time I saw an agent actually just crank along and spit out a bunch of code and happily make a bunch of updates. [00:03:28]
-
-And I thought I had a, a good understanding of what that process looked like. And then when I saw it in person for the first time, my jaw dropped. And then on a Thursday, I needed to write some AST-based linting code. I know what ASTs are. I've used Babbel. I understand the concepts, but it's kind of complicated and fiddly, and we had a custom setup. [00:03:54]
-
-I was like, "Could this do it for me? " And it did. And it did it much faster than I could as a person. And my worldview got destroyed. [00:04:13]
-
-**Carl:** Yep. Sounds familiar. [00:04:22]
-
-## Using early ChatGPT for DB migrations
-
-**Swizec:** I mean, that, that sounds like an amazing experience. For me, the first was way back in the, uh, Stone Age where you had to talk to ChatGPT and then copy paste the output to try to run it. [00:04:24]
-
-And it was like, I think it was the holidays, and I was writing a book feeling kind of discouraged, and I was like, "I wonder how many words I'm writing per day." And it's like, I can write Python. It's not that interesting to parse a markdown file, go through, get history and see how many words you added every day. [00:04:39]
-
-Um, so I was like, "Maybe ChatGPT can just write this for me. " And I asked it, and the code, the code didn't work, but it ran. And I thought that was really cool. So I talked to it a little bit more, and we ended up with a really nice ... It was an extremely ugly code that I would never write myself. I think it ended up still taking two or three hours, but it was a lot more interesting than me doing it. [00:04:58]
-
-Um, and I ended up with a nationalization of how my, how my book is doing, and then I wrote a few more scripts like that. And then I started using it at work to write my database migrations, because- [00:05:25]
-
-**Mark:** Please tell me, was it still just the ChatGPT UI? [00:05:39]
-
-**Swizec:** It was. Uh, this was, this, this was before Copilot. I was like, "Hey, ChatGPT, I have this SQL query, please write migration." [00:05:41]
-
-And it wrote the migrations or I ended up, uh, later on just copy pasting table definitions from, like, DBR or DataGrape or whatever, go look at the current tables and be like, "I have these tables. Please write migration for ... " I think we were using Connects at the time. "Please write migration to add these columns and then copy paste back and it worked. [00:05:49]
-
-"And I was doing that for a while and it was amazing. I never wrote a migration again in my life. [00:06:13]
-
-**Carl:** Yeah. I started doing a lot more migrations because it just became so much easier to actually do them. There's such a pain, there's so mechanical. That was an early one for me too that was like ... I guess I actually had been, like, scoping my work to avoid migrations because I hate doing them so much. [00:06:18]
-
-I had a similar experience of just like, " Oh my God, this works for that. I can do so many more of them now because I don't have to do it. "Yeah, it's a little funny because actually database migrations are a big part of why my career looks the way it does, because I did, like, one in, you know, my first year as a software engineer. [00:06:34]
-
-I went," Wow, I hate this. You can't guarantee anything. There's just, you just gotta try it. "And so then I went more front end because you don't have to do database migrations on the front end. [00:06:49]
-
-## Watching AI use a command-line
-
-**Carl:** Yeah. I had a similar type of experience as Mark. I guess I, I got on it much later than you did, Swizz. Sometime around, like, August, July, August, September of last year, you know, I, I had done kind of like ChatGPT prototypes or whatever, like Claude, having it write some HTML in line and just, like, prove out a concept or write a first draft of a script, like, prove out does this work? [00:06:59]
-
-Give me off the blank page and give me something to grow from and diagnose. And then I'd been hearing people talk about Claude code, so I finally gave that a shot in, like, I think around July, August for the first time. And just watching it, you know, like, Mark, like you said, of just watching it churn through and do things and also having it be, like, native on the command line and watching it just run exactly the same Bash commands that I would to diagnose something and, like, read the files. [00:07:23]
-
-It was like, "Oh, this is doing exactly the same process I would to resolve this bug, but it's doing it five times faster than I can." That was my big, like, light switch moment of, like, "Oh, I need to take this really seriously." [00:07:54]
-
-**Swizec:** For me, it's kind of like I really hate watching it work. I've been using AI for a while doing, like," Oh, can you write this function for me? [00:08:07]
-
-## Background chat agents
-
-**Swizec:** Or can you, like, do little small things? "But my workflow really changed when Cursor launched Slack background agents. So I started in Slack, like, when you get ... Partially, I'm a PM, so I get a lot of requests that are like, " That is definitely not a priority right now. We're not gonna work on that. "But I can now go at Cursor, do the thing, and I just get a PR with the implemented small thing that I never would've taken the time to do myself. [00:08:16]
-
-And I, I find that amazing because watching it work, I think is, for me, is too distracting. [00:08:46]
-
-**Mark:** Yeah. [00:08:51]
-
-**Swizec:** So I like it when it's fully somewhere in the cloud. I don't have to worry. I just review the code when it's ready. [00:08:51]
-
-## Staying very hands-on while using AI tools
-
-**Mark:** My workflow is very hands-on and human in the loop. Like, I'm sitting there watching that thing like a hawk and having conversations with it, which I realize is not how most people are using AI at this point. [00:08:58]
-
-I think a lot of people are very much on the, in the cloud, multi-agents, how many of these th- things can be run in parallel, which I now have opinions on. Part of it is ... Well, a lot, a lot of it's the point that I'm making the draft blog post, which is understanding is still critical. And I'm a very, I'm a very firm believer in, you know, the fundamentals and understanding and building a mental model of the system. [00:09:10]
-
-And I personally, for me, I want my brain engaged. I want to be thinking through the problem, and then I'm using the agent to amplify my own abilities. Now, don't get me wrong, there's definitely been a few moments where I was, like, you know, out and about. It's like, you know, it actually would be kind of nice if I could just pull up my phone and tell an agent, go do this thing. [00:09:34]
-
-Like, I, I, don't get me wrong. I get the appeal. [00:09:54]
-
-**Carl:** Yeah. [00:09:56]
-
-**Mark:** But in terms of day-to-day development work and how I approach programming, I want my brain active, engaged, and thinking, not just handing it off to an agent. [00:09:56]
-
-**Carl:** Yeah. I hear that. I think I use it in both ways. There are a lot of things that, like you said, so it's just, like, it's not quite high priority enough to justify. [00:10:08]
-
-And that's where I'll use, like, more of a background agent. Like, you know, here's 15 one line descriptions and, like, just from the one sentence, it's clear enough what's needed. Like, you know, adjust the size of this. Add an element that controls this. Like, those are mechanical enough that it's really just, like, getting it right, making sure it compiles. I don't currently have a functioning workflow for that exactly. [00:10:20]
-
-What I'm doing right now in the last four or five weeks just, like, hasn't really been of that type of development. So I am still, day-to-day, most of what I've been doing is very much, like, the mech suit variant. You know, people talk about, like, automated versus mech suit, like robot or mech suit. [00:10:44]
-
-## Driving AI closely without reading its code
-
-**Carl:** And yeah, so I'm driving it pretty closely, but I'm not really reviewing its output very strictly. I'm, you know, I tell it to use subagents, and then every so often I'll, you know, tell it to write me a report, like, how is this working? What is it doing? Ask it some targeted questions to make sure that the mental model I have matches what's actually there. [00:11:00]
-
-But that's a little different, I think, than what you described, Mark. Like, I'm not actually, like, I don't read almost any of the code. I try and think of it more from, like, my engineering manager, tech lead, product manager hat. I do really try and sit in engineering manager/product manager role and say, like, "Okay, how did those people talk to me as an engineer? [00:11:17]
-
-Like, they were not technical. They didn't understand anything of what was being built, and yet it was their job to make sure it was functioning as intended." So that's very much how I try to think about my work now is from that perspective. It's like I, instead of reading a line of code to ensure that patterns are followed as I intended, like, set up a lint rule and then, you know, maybe it's only 80% is good, it's not gonna catch all the subtleties, but, like, my experience of working on a team is, that's kinda how it works anyway. [00:11:37]
-
-Like, if it's not captured in the lint rule, eventually it will break. Like, eventually, someone will have been onboarded and not ha- be deeply steeped in the history of the project or just be tired that day and they forget about it or whatever. So, like, that was very much my perspective as, uh, you know, when I've been a tech lead is, like, if bad code goes out, you know, the blameless postmortem, it was a process failure. [00:12:06]
-
-This should not have been permitted by the automated checks. And so that's kind of how I'm thinking about it is just remove the abstraction a little bit and guarantee the outputs and then work on automated tracking of automated evaluation of the code quality to make sure that's at a level that I need it to be. [00:12:30]
-
-**Swizec:** Yeah, same. I think that's my perspective as well. I've ... Going up into tech lead was really kind of almost broke me as an engineer because I was like, "Oh my God, all of this terrible, awful code, but it works and it's fine and everything is okay and the team just handles it. And if anything is wrong later, we just fix it. It's totally fine." [00:12:48]
-
-And I kind of treat AI the same way. I, I do a lot of driving from, like, a product perspective and for critical features or, like, super gnarly business requirements, I go into the ID and I drive it kind of like what Mark was describing, reviewing every line of code, clicking yes, et cetera. [00:13:12]
-
-But they do really well with follow-ups. Cursor gives you the wrong thing back in a Slack thread. You just say, "Ed curs- ad cursor, go fix it. " A lot of the times, those fixes are actually, "Oh, yeah. Now that I'm holding a working MVP, it doesn't actually feel right. I totally didn't even think of several features that it needs before it's useful." [00:13:29]
-
-I also really like the code review flow. I don't know exactly what we did, but we hooked it up so that you can do a PR review, like a code review for your cursor agent session. And in GitHub, you just go at cursor, fix this, or you give it information basically the same as you would with a team member, and then you just get follow-up, commits, and it fixes all the things. [00:13:49]
-
-**Carl:** That's very much been my experience as well. One of my biggest struggles as a, as an engineer is, like, I remember hearing about this sort of a stereotype of, like, give it, give this task to a junior engineer because they don't know it's impossible, you know? The sense of as you get more experienced, you get to see more of the complexity, and the complexity makes it harder to take action because you're now evaluating trade-offs instead of just kind of ignoring them because you don't know they're there. [00:14:10]
-
-And I would get so stalled into analysis paralysis and, like, what's the correct way to do this? How do you do this best? What's gonna have the best maintenance trade-offs and the lowest, you know, the tech debt and whatever? And that's just such a difficult way to actually solve, especially a novel problem. Like, if you understand a problem well, great. You can specify everything in advance. But, like, if you're working at the edge of your knowledge, at the e- edge of your understanding, then, like, you're gonna go the wrong way at first. And it's so painful to work on something for three weeks and then go like, "Oh, shit. This is just completely the wrong architecture and I need to start over." [00:14:34]
-
-But it's so much less painful now with AI because, like, great, what a wonderful learning. Let me take that, let me have it write a three-page document about what we learned, what the new problems are, go back and forth, interact with it about, like, designing a new data model and architectural, you know, process flow. [00:15:09]
-
-I actually just did this in the last, like, week. I've been benchmarking local LLMs because I want to better understand which ones work for what tasks so I can not have all of my AI usage be based on some mystery frontier model in the cloud. [00:15:28]
-
-And I just, like, you know, I started with just, like, "Hey, give me a script that will run this model. Start up a, you know, LLM server and then run prompts against it. " And then, like, that grows, "Oh, I need, I wanna be able to kill it and restart. Oh, I wanna be able to, you know, version the prompts as I change them. Oh, I need to have it, you know, run a code evaluator when I'm giving it, like, a code generation challenge." [00:15:42]
-
-Eventually, it became un- unmanageable because of the tech debt. It's, you know, it grew and expanded and I learned more about what was needed. And so I just started over and I said, "Great. This is a Python ball of mess and it sucks and I hate it." So let's talk about the architectural flow of it and now let's add some lint rules and let's rewrite it in effect. [00:16:06]
-
-So it's actually like a high quality code base with, like, resumability and scheduling and whatever. And now it's working way better and it's, like, maintainable. It's been really powerful. [00:16:26]
-
-**Mark:** I freely admit that the very hands-on style that I've got is intentionally learning. I know it's possible to go faster. [00:16:35]
-
-I know that it's possible to delegate a lot more. I am treating it much more as an extension of my IDE and keyboard than I am as a junior developer delegating the work. That's fine. I am good with that. That is what works best for me and my brain. [00:16:43]
-
-**Swizec:** You might start doing that less and less as you use it more. [00:17:01]
-
-I started with doing that a lot more, and then eventually I realized, wait a minute, I'm just clicking yes on everything and then giving it a follow-up prompt to change the things I didn't actually like, but click yes on anyway. [00:17:04]
-
-**Mark:** I certainly didn't think a year ago I would be using any of this at all. I was, I was convinced that was a red line that I would, I would never, ever cross on pain of death, and here I am. [00:17:16]
-
-But also, like, I mean, I've, I've found a workflow that I will be hopefully blogging about in the next day, next couple days that does actually work for me. And the hands-on aspect of it is what I get good results out of, and it's what fits my brain. [00:17:25]
-
-**Carl:** Well, okay, let's take that as jumping off point. Like, what tools [00:17:40]
-
-Let's do, like, super concise, just, like, list what tools and what models you're using day-to-day. [00:17:44]
-
-## Mark's workflow; OpenCode with CodeNomad UI, plus IDE\+git UI. Opus 4.6 on API
-
-**Mark:** So my, my own setup, my intro was the kilocode VS code extension with, you know, it was probably either Sunat 35 or Sonat4, whatever was available around September-ish last fall because I didn't want to go anything command line at first. I wanted to stay in a graphical environment. [00:17:50]
-
-I tried Claude Code for about a day. Tried the VSCode extension, which didn't work at all, and then I tried the command line tool, and I, I did not like it. I tried the OpenCode command line tool, also did not like it. How do y'all deal with copy paste in a command line environment? [00:18:09]
-
-So what I have now, I'm using OpenCode. My personal laptop is Windows. My work laptop is Windows, but I work in WSL. So I actually serve OpenCode from within the WSL environment, and then I use a third party web UI for OpenCode. [00:18:24]
-
-OpenCode has a very nice server client distinction. The text client is just one of the possible clients. So I found one called Code Nomad, which is very good, works great. So I actually serve Code Nomad plus OpenCode added the WSL side, and then I just hit local host whatever port in my browser on the Windows side, which also avoids any cross-platform file shenanigans as well. So I've got my chat sessions and my tabs open in the browser. That's now my development environment. [00:18:42]
-
-And then I still have VS Code open for looking at some of the diffs and editing that my ... I much prefer a Git graphical client called Fork, but it doesn't work well in Linux, so I've just stuck with the built-in VS Code stuff. I actually don't like it, but I've been too lazy to go find a better alternative. [00:19:16]
-
-Model-wise, I've basically been on whatever the latest and greatest anthropic is. We have corporate keys, da, da, da, da, da, da. [00:19:32]
-
-Also, I have somewhat intentionally tried to avoid model hopping. I don't want to be running a bunch of evals every other week and saying, "Oh, this one provides me a 3% increase in such and such a benchmark. Clearly, I need to switch my entire workflow to a different model." and granted, OpenCode does let you just pick and choose what model you want, but I'm trying to get something that's good and consistent and that I know works, not chasing the hypothetical maximum performance. [00:19:39]
-
-**Carl:** Okay. So you're, you're on OpenCode and using latest Claude Anthropic models just through API usage? [00:20:10]
-
-**Mark:** O- Opus 46, yeah. That's the other thing. Uh, it's, it's API keys, not the various, like, you know, $20, $100, $200 max plans. So I, I read about people getting the resets and it's like, I haven't do with that because I'm also not paying for it. [00:20:19]
-
-**Carl:** Right. Cool. Okay. [00:20:32]
-
-**Mark:** It's like knowledge that my experience may not be universally shared. [00:20:34]
-
-**Carl:** Okay. Yeah. [00:20:38]
-
-## Swizec's workflow, latest Cursor on Opus
-
-**Carl:** Yeah, Swizz, what's your workflow look like? I'm curious, I'm very curious about yours because I think you're by far the most advanced agent user between the three of us. [00:20:39]
-
-**Swizec:** Which is really funny because I was surprised to learn earlier this week that 97% of my code is AI because I really talked. I was like, "What?" [00:20:47]
-
-But I actually have an extremely simple setup. I use Cursor, I keep it updated to whatever the latest version. So when it pops up with, "Please update," I click the button. I think the latest Opus model or whatever it is, it's like something 4.6. I think it's an Anthropic model. We have a Team subscription, so CompanyPays gives us an infinite budget, but I think I'm actually using, like [00:20:57]
-
-It's actually funny. I don't know ... We were just talking about this today. I don't know how this happened, but on the Cursor Leaderboard, I have the second most AI usage of all of the engineers, and I have the least amount of dollars used. [00:21:25]
-
-**Carl:** Fascinating. Interesting. [00:21:40]
-
-**Swizec:** I have literally spent $25 this month. So anyway, I use Cursor, I use @cursor on Slack a lot, and I use @cursor on GitHub a lot. [00:21:41]
-
-We also use Linear, and I've started more and more delegating my linear tickets to cursor. So look at the linear ticket, be like, "Eh, I didn't write this well, add a little bit more context so that a dumb bot can know where to go fix things or what to change, and then just click delegate to cursor, and then I review the PRs." [00:21:53]
-
-That's my workflow. I try to keep it really simple and easy, because like Mark said, I'm not looking to super maximize my productivity. I'm more looking for, you know, as a manager, I'm supposed to stay on SiteQuest anyway, so this is a really good way to code between during, uh, between and during meetings when I'm supposed to be paying just like half attention. [00:22:13]
-
-**Carl:** Yeah, that's really interesting. I, I, I like that you two are like kind of two ends of the spectrum here. So as you use it as like very much in a managerial capacity, like, you know, the same as you would ping a colleague, you ping cursor instead and just say, "Hey, do look at this. " [00:22:36]
-
-**Swizec:** Yeah, pretty much. I, I've been doing that a lot. [00:22:52]
-
-**Carl:** And it's all within collaboration platforms, I guess is like a big distinction here. It's all in space- A lot of it is. Yeah. Okay. [00:22:54]
-
-**Swizec:** We're now experimenting with building like a feedback loop so that we would have a bot that Sentry sends us errors and we're thinking of having a bot that looks at those errors, figures out how to fix them, and then just issues a PR when we get, so that we could have automatic PRs- [00:23:03]
-
-**Carl:** Yeah. [00:23:20]
-
-**Swizec:** for, at least for some er- no, like, you know, probably not for super critical, crazy, important things, but there's a lot of errors that happen where it's not that important, but it's nice to fix. [00:23:20]
-
-**Carl:** Yeah, definitely. Right, the long tail of Century issues. [00:23:34]
-
-**Swizec:** But when I'm like actually hands-on coding, I use it a lot to write my tests because I know what I want to test and I can describe the situation to set up, but I hate doing the grunt work of setting up your database in just the right way to have 50 models, et cetera, [00:23:37]
-
-**Carl:** yeah. [00:23:58]
-
-## Carl's workflow, mostly Claude Code but looking at custom orchestrators
-
-**Carl:** Yeah. Okay. Interesting. I, I kind of split y'all's experience a little bit, or I'm working towards ... I feel like I'm closer to where Mark is right now and I'm trying to move towards where you are, Swiz. Yeah, I almost exclusively am using Claude code with Opus. I've played around a bit with ... Like I, I used Copilot, you know, GitHub Copilot, like once to, like, scaffold a prototype that I was experimenting with. [00:23:58]
-
-I don't like the experience of it being in a web browser. Like, something about it ... I don't know. I also don't like code spaces or, like, remote development across SSH. So, like, this may be just my own, like, biases and preferences, but I really like just ... It's right here. It's on my machine. It's an environment that I have set up. [00:24:22]
-
-I know exactly what's available to it and what's not. Just, like, I guess I've prioritized, at least in that where I'm trying to use it like a Mac suit if speeding up my own pr- individual productivity, I just want it to be predictable and understandable for myself. To me, that's very much just been Claude code with whatever defaults pretty much. [00:24:40]
-
-I've played around a little bit here and there, but yeah, I'm trying to work towards ... One of my many projects that I have in flight is a personal, like, orchestrator. So I had started out kind of my foray into, like, earnest AI focused, using it to the extent that I am now, as opposed to more limited reading every line of code, going in and editing it myself. [00:25:01]
-
-## Exploring fully autonomous agents
-
-**Carl:** That's only really been since, like, February when I started playing this AI agent game. And it's been really interesting thinking about ... Because putting an agent in a simulated world and, like, having it autonomously play a game and do so in an interesting way, you know, effectively and interestingly, really just, like, got a bunch of wheels turning in my head. [00:25:23]
-
-And so, like, Claude Code works really well for me for, like, pushing the envelope, like, expanding what a project is, what it can do, and I have really enjoyed using background agents more, like, very much like what you described to us of just, "Hey, oh, fix this. This is broken. Here's this bug." I don't currently have anything like that operational, but I did get my little personal orchestrator working for a minute. [00:25:45]
-
-It was just wor- working on the GitHub API and I just said, like, "Here's a repo, like, go, you know, read the issues, triage them, prioritize them, take a task, open a PR, and wait for me to review it. " And it worked, but I didn't give it any guardrails, so it ended up, like, redoing the same GitHub issue multiple times, or, you know, it would re-review the same PR over and over again with, like, a page and a half of a comment. And so I was like, "All right, okay, this is proof of concept, it works, but, like, clearly I need some additional things set up." [00:26:10]
-
-And I guess one, another thing I wanna say, like, kind of what you said was about, like, using Sentry Data as an input for what to work on. I think that's the frontier. Like, that's what is currently being explored. Like, how do you do that effectively? [00:26:43]
-
-**Swizec:** Yeah. You need the feedback loops. So I was reading a lot of how to build an agent papers the other day, and the main inputs are basically rag, memory, and feedback loops, and from there, it can do a lot. So Cursor, for example, Cursor Cloud agents through Slack, they actually, when they're developing the feature, they will fire up a browser and go test it, see if they can actually do the thing, and if they can't, they will then c- continue iterating. [00:26:56]
-
-And in the end, the PR doesn't just have code. It has screenshots and videos of the working feature, which is what I require from all of my engineers, and it makes reviews so much easier. And there was another ... Oh, yeah. So I think the longest I've managed to do, to have it spin when I asked it to build an entire feature. [00:27:27]
-
-So, like, I would write a maybe 200 word, two or 300 word prompt in Slack to add cursor, and it took ... I think it spent 45 minutes to come back with the working feature, and that was amazing, because I was in a meeting for that whole time, and then I just looked at the PR and gave it feedback. [00:27:47]
-
-**Carl:** Yeah. That's incredible. [00:28:06]
-
-## Mark's AI debugging work in React core
-
-**Mark:** So my day job, we're coming at it from a similar but also sort of opposite angle. We, we have built a time driver to bugger, and originally the premise was that by making a DVR style recording, you as a person can go in and do all the investigating in the lines of code and the print statements and everything else so that eventually you as a person figure out why this was broken. [00:28:08]
-
-So we shipped an MCP a couple months ago, and I've already seen some very real examples of agents being able to go in and solve bugs that they wouldn't have been able to otherwise. I actually put up a post about this a week ago. Dan Abermov had filed an actual React bug saying that the used deferred value hook sometimes fails in production, it's stuck, like a render behind. [00:28:28]
-
-And he had a repro and he said, uh, "I've had my agent try to look at it, but I can't find the answer." A month later, he comes back and files like a four-line fix deep in the guts of React Scheduler to actually fix it. And he posted on BlueSky later, and apparently what he had to do was rebuild the React Library with a bunch of console logging added so that his agent could look at the prod build and eventually trace what was going on and figure out how to fix it. [00:28:52]
-
-So I'm like, "That would be a great marketing post comparison." So I took his example, I made replay recordings of the working dev build and the failing prod build, handed them to an agent, and I said, "Here's a bug report. Here's the two replay recordings. The issue is somewhere in React. Can you find it?" took 10 minutes. [00:29:18]
-
-So I'm like, so then I'm like, okay, well now let's make it like, you know, something resembling a proper experiment. So I took the same two recordings and I spun up four simultaneous sessions with differing instructions. [00:29:38]
-
-The first one was just a basic, here's a bug report, go investigate, actually less context, the proof of concept. The second one, I gave it like a eight step investigative process to follow. The third one had a few paragraphs just naming some concepts and Reacts internals, like not even file structure, but just things like, you know, schedulers, fibers, lanes. And then the last one also explicitly listed some of the replay MCP tools we have available. [00:29:50]
-
-All four of the sessions found the same bug and suggested the correct fix. They took respectively 28, 17, eight, and seven minutes. So on the one hand, you know, ob- obligatory sales pitch, replay recording, finding bugs, it's awesome, it's great. We're building some cool stuff with it. But it also showed me a lot about the value of the prompts and the context that you give. [00:30:18]
-
-There was another example I was working on where someone had made a, an example NextJS app with some example bugs in it and was asking an agent to find them. And in one of them, there's a, there's a double loading screen that's caused by mixing and matching suspense and Tanstack query loading state. [00:30:44]
-
-The AI always suggests the use suspense query hook, but apparently if you do that, it leads to a hydration mismatch error. And the real answer is to do some server pre-fetching instead. So like you have to think bigger, think architecturally. So I did the same thing. I tried, you know, making some re- replay recordings and feeding in the, the varying instructions. [00:31:00]
-
-My agents mostly got the same base level used suspense query error. And then I tried one more session where I fed in the NextJS and TanStack query skills files. And now the agent actually said, "Well, useSuspense query is the initial fix, but you really ought to do server pre-fetching instead." [00:31:21]
-
-## Value of providing more context
-
-**Mark:** So again, like that, that taught me a lot about the proper context. That also says a lot as we're trying to build our own CI debugging agent that looks at test recordings, so clearly we need to give it, you know, good prompts, user-based context, all that kind of stuff. [00:31:42]
-
-So, I mean, I think even something like that can maybe help explain some of the differences and results that different people get. [00:31:59]
-
-**Carl:** Yeah, no, the impact of prompting and available context is, like, so massive. As we're talking workflow, something I do very regularly is, you know, start with a prompt, start with, like, if I'm gonna add a new feature or redesign something or what, you know, a large task, not a bug fix, you know, a sprints project, not a ticket, then I'll start off with, like, a 200-word, like, prompt of, like, "Here's what we're trying to build. [00:32:05]
-
-Here's how I think we will need to do it. Here's a couple of parts that I think are gonna be important." You know, you know, have it explore, do the implementation, review, you know, and then I manually confirm. And then I'll tell it, like ... And I guess I'll do this at a couple of points throughout as it's exploring and, like, evaluating things. [00:32:32]
-
-I'll ask it, like, "How was the documentation? Like, did you find everything you needed?" And that has been, like, totally transformative for, I think for token usage as well, because, like, just by asking that, it'll say, like, "Oh yeah, it was all ... Here's the three files I referenced and I got everything I needed." [00:32:47]
-
-Or, like, "Oh, yeah, this file was out of date. You know, I did the wrong thing at first and then I had to go back and rework it. " So I'd recommend that we update this" and it makes those recommendations just based off its own experience of reading the code. And so, like, just by doing that fairly regularly as the code base evolves, I manage to keep, you know, the documentation pretty well up to date. [00:33:04]
-
-**Swizec:** Are you asking it to write its findings back into documentation or are you updating the docs? [00:33:27]
-
-**Carl:** I'll read it with a skeptical eye of, you know, like, does this sound like it is a real problem or not, a real area for improvement? And then I'll just say, like, "Yeah, hey, can you update those docs?" Often, I'll come at it with a pretty clear intention of, like, we just revamped how scheduling works. Let's analyze the architectural overview document that we have and see if it's still accurate and then tell it ... [00:33:32]
-
-## AI-owned documentation
-
-**Carl:** You know, so, like, I will do some documentation specific projects with that in mind, but for the most part, yeah, just, like, ask it how the experience of the familiarizing itself with the code base is, and then give it free reign to improve that for the most part. [00:33:58]
-
-**Swizec:** Yeah. I think one thing I would be worried with that we have some people in the team experimenting with that, and they all agree that after a few iterations, like, a few weeks later or a few months later, you end up with very spaghettified documentation that's essentially just AI slob that humans definitely don't wanna read, but even the AI barely wants to look at it and read it because it just keeps getting low, lower and lower signal. [00:34:13]
-
-So I think ... I don't have a solution for that, but it's a thing I've heard. [00:34:40]
-
-**Carl:** That's fair. I haven't really evaluated that recently. I did come at it with trying to say, like, "Here's five documents at these levels of abstraction in the code base." So I do try to give it a little bit of overall stru- structural guidance, but that's a good thing to, that's a good thing to look out for. [00:34:45]
-
-I haven't really evaluated it. That's also how I get my own mental model of the code. So I guess, like, I don't necessarily write it, but I will read it, and if it's nonsense spaghetti, then it's like, "No, we gotta do this again." Like- [00:35:03]
-
-**Mark:** That also ties into the longer term memory question. So, you know, the problem is ev- every session is fresh. [00:35:15]
-
-It knows nothing, you know, every, literally everything is being injected, you know, agents, MD, you know, whatever rules, files, et cetera. So how does an agent even know that you have these nice architectural docs that you've been keeping up to date? Or how does it know that, you know, last week, a week earlier, whatever, you made these particular decisions, and that's why we ended up here. [00:35:22]
-
-Or it has no idea what any of your code base is. Let's go read 30 files to re- form a brand new, fresh set of memories that compress the context. And some of this can be, can be dealt with partially. There's ... I, I, I highly recommend tools that will do AST-based scanning of the code base and preferring those for what, for loading chunks of code rather than just, like, blindly whatever built-in read file tools are there. [00:35:46]
-
-But that is actually where I'm running into the limits of my own personal workflow right now. I have, you know, dozens of feature and research docs that I've generated. I have daily progress docs. I have sub-task handoff docs. There's a lot of very valuable information in there, and the AI has absolutely no clue that any of that exists. [00:36:14]
-
-So I'm n- I'm now f- starting to feel the need that I need to have some kind of, you know, review sweep process, some kind of tool to, you know, index the markdown file, something to form that longer term memory structure, and I keep bookmarking hundreds of tools and saying I'm gonna go investigate them and haven't done so yet. [00:36:37]
-
-**Swizec:** If only you had a tool that's really good at summarizing large pieces of text. [00:36:56]
-
-**Mark:** I, no, I, I actually have done some of that. Um, I just haven't actually settled on one and tried installing it yet. [00:37:03]
-
-## Using good engineering practices still matters?
-
-**Swizec:** One thing I found also really helps for context and stuff like that is actually structuring your code well. So having a vertically oriented architecture, small balls of mud that are self-contained rather than one large horizontally sliced ball of mud makes it easier for humans, and it also really works for the AI when you can say, "Go add a feature to this directory." [00:37:09]
-
-And it's the, like, basically use your directory structure as an index for where to find different kinds of code. [00:37:36]
-
-**Mark:** That sounds suspiciously like software engineering practices, and I was told those don't apply anymore. [00:37:44]
-
-**Carl:** Yeah, right. Like, the main thing that I've been trying to keep in mind here of using it, and, and this was, this kind of talk goes back to your recent blog post of, you know, where you talk about how much code A- AI is writing for you, and to just talk to it like, these models were trained on things like GitHub discussions and PR reviews and code comments and whatever. So, like, it's not some new, esoteric, crazy, unpredictable thing. Like, the more you talk to it, just like it's a competent engineer, the more it will behave like a competent engineer. [00:37:50]
-
-And so it has all of these assumptions about, you know, social norms within the context of, you know, text documents describing code and documentation. And so the, the more you understand the social norms that it are deeply baked into its training, the better it does. So, like, yeah, like, I saw these, you know, memory startups where it's like, "Oh, we will automatically generate documentation for your code base and make sure it's up to date." [00:38:22]
-
-And it's like, I'm already doing that with a Read Me document tagged with a GitHash of how, when it was last updated for free. Like, if you have a couple of folders, a couple of directories full of code that is, like, pretty well isolated with a Read Me document in there, like, I don't need to tell the AI to look for the Read Me because it knows to do that. [00:38:49]
-
-Of course, it knows to look for a Read Me. So there's definitely a lot of difficulty with keeping the signal high, but, like, that's not new. I don't know. Like, that just sounds so much to me, like, working on a team of eight engineers and, like, not everyone has the same shared context. Not everyone reads every email or every Slack message. [00:39:09]
-
-And so, like, as far as the challenge of, the, the challenge of keeping a team up to date on best practices and recent decision making, versus keeping an AI at the same level, like, that, those feel really similar to me. It's just engineering best practices and communication norms. [00:39:30]
-
-**Swizec:** With, with the major difference that AI will actually go read the documents you tell, you ask it to read. [00:39:50]
-
-**Carl:** Right, right. Like, one of my, like, you know, war stories was I was a contractor somewhere and they kept having, I kept having to do a rework because, you know, QA was overwhelmed and, like, you know, they finally get around to reviewing PRs and, oh, it's broken. Oh, gotta go back. Oh, there's all these conflicts now because [00:39:57]
-
-And so, like, despite being a contractor, I sat down. It's like, no, we need to fix our review process. We need to fix our merges and whatever. Spent, like, two weeks doing that, get everyone on the same page, man. Next day, the, you know, tech lead employee at the company, the guy who should have been doing that process is like, "Nah, this is too much. Like, I'm just gonna force push." And he took down production. [00:40:15]
-
-So it's so it's like, uh, when people talk about AI doing stuff, it's like, "I don't know, man. Have you ever worked with engineers?" [00:40:37]
-
-## How do you know the right code to make?
-
-**Mark:** Uh, so this, this does tie into a lot of the conversations that I had last week. I, I was at both the AI engineer and React Miami conferences. [00:40:47]
-
-And the general theme of the discussions there between the talks and the people and then, you know, all the different chatter online is we built ... And I also ranted about this in my 15,000 Word unpublished blog post. We built a bunch of software development practices for people, the agile manifesto, linear issues, PR reviews that require multiple people to stamp them or, you know, as a way to share knowledge, standups, like these are all people- based processes, and it made sense when humans are the limiting factor and you have to be very intentional about making sure you're writing the correct code. [00:40:53]
-
-Like, not just does the code work, but are we even spending the time and effort on the right thing in the first place? And we now essentially have a generate infinite amounts of code button, and now we're finding out that we've moved the bottleneck further down the chain into all the verification and QA sides of things. [00:41:32]
-
-And so this shows up in, oops, GitHub is overwhelmed because we've literally 10Xed the number of PRs that are being pushed or, wait, we've got a bunch of senior engineers, but they're literally spending all their time reviewing PRs generated by the junior devs with AI, much less what happens when you have a dark factory of agents cranking out code twenty four seven and no one ever looks at it. [00:41:51]
-
-Like, we haven't figured out what the resulting processes ought to be, and one of the points I make in my blog post is that I think right now we're all operating under the assumption that there's no limit for how fast we can go, and in reality, we're gonna figure out the actual limit is maybe, like, 3X of what it used to be, but we need to, like, accept that and plan for it instead of thinking that if we shove everything in one end of the pipe simultaneously, it all comes out the other end. [00:42:15]
-
-**Swizec:** I have opinions. Um- [00:42:46]
-
-## Good communication still matters
-
-**Swizec:** Yes. I think I wanted to say first is I really like, Carl, you mentioned that you start sessions with a really long 200 word prompt that gives all the context, doesn't just tell the agent what to do, but also why it's doing it in, like, other context. Same. This turns out works really well with humans as well. [00:42:49]
-
-They give you much better work if you tell them why they're doing it or what the goal is. And sometimes if you tell, if you tell them what the goal is, they might even come back with, "Your solution is dumb. We should do this other thing instead," which, wow, can you imagine using engineers' brains for thinking, not just writing code? [00:43:08]
-
-But I think the other thing is, we are generating a lot of code, and we think the bottleneck is code review. I think there's kind of two bottlenecks. One is that when you're moving really, really fast, you have to actually be more careful about working on the right things because if you're just digging yourself into a hole faster, we just had an example recently where we broke Agile, we were like, "Oh yeah, we know what we, what we need to do. Let's just have Claude crank out 6,000 lines of code in one gigantic PR." [00:43:24]
-
-First of all, we couldn't review that, so we had to break it up into a bunch of sub-tasks and then turn that into sub-PRs. Turns out that took another extra day of work and everyone was distracted while doing this, so we weren't focusing on what we were actually supposed to be doing. So I think distraction is still bad. Multitasking is still bad. We're not as good at multitasking as we think we are. [00:43:55]
-
-And the other thing is we, when we split all of that up, we found that Cloud made a tactical mistake very early on, chose the wrong architecture for how to build something with React. And now you have a lot of code that needs a lot of rework to actually make work, and you're wasting reviewing time, you're wa- you're wasting a lot of time that could have been solved if we started with a small task to set up a small thing and talked about it, or maybe even talked about the architecture before we wrote six, 7,000 lines of code, and then just wrote the correct code the first time. [00:44:18]
-
-**Carl:** Yeah, 100%. We're hitting communication bottlenecks much faster now. Yeah, like Mark said. [00:44:54]
-
-**Mark:** Communication and thinking and planning was always the job. [00:44:59]
-
-**Carl:** Yeah. [00:45:03]
-
-**Swizec:** Yep. Except now you're running, like, 10 times faster. So if you take the wrong step or as your first step, you're just running in the opposite direction of where you wanna go, but really, really fast. [00:45:03]
-
-## What will "review" look like in the future?
-
-**Carl:** Right. Yeah. Right. It's very easy to get in extremely the wrong place in exactly the same amount of time. That touches on something I've said before in this podcast. I think that the future of, like, review is gonna be less code review. The architectural side of things is still gonna be important. Like, it's not just, does it work? [00:45:13]
-
-Does it do what you intended? You can't fully treat it as a black box. The box has to be translucent, you know, at least a little bit to avoid major architectural problems that are gonna cause a production outage or make it impossible to scale or whatever. Like, it's not all going to be, does this function. [00:45:32]
-
-But I do think, does it function is going to be a much greater part of this? My sense is that it will rely a lot less on reviewing the code so much as getting a plausible mental model of the architecture, and then it, you know, and then statically verifying that it does what's intended. So, like, my, my theory here is that we're gonna start seeing a lot more end-to-end testing and user acceptance. [00:45:49]
-
-## Automating functionality tests with deployment practices
-
-**Carl:** A thing I did recently that I haven't fully executed on yet, but ... Well, I, I did a lot of it. But so a, a project that I have, I fully rewrote the CICD so that instead of PR checks, review, approve, merge, ship, instead of, you know, that, like, trunk-based development, where every PR gets shipped individually, I move to more of a, like, Git Flow type architecture where it's like, no, here's the version. This is going to go out. Uh, here's our release candidate. And then that single release candidate gets pushed to a staging environment, and then I do the user acceptance testing of does this function as I need it to. And then once I have that, once I've done that manual testing, great. I know this code is working as I meant it to. So now I'm going to have it write a bunch of end-to-end tests to verify that it will continue to do that when I make changes. And I think that's gonna be kind of the new cycle of, like- [00:46:17]
-
-**Swizec:** I want that, but on every PR. [00:47:10]
-
-**Carl:** Yeah, right. And I guess to me, like, that's where manual testing is now the bottleneck. [00:47:12]
-
-Like, you cannot ... At the end of the day, this needs to function, this needs to solve a problem. Any code you write needs to solve a problem that real humans have. Or I guess, you know, sure, other agents or whatever. [00:47:17]
-
-**Swizec:** I've experimented with automated end-to-end testing. It doesn't quite work yet. I think the models are, or at least the models I was trying were too slow, but the idea is that instead of telling that [00:47:28]
-
-Instead of writing a test as what the features that should be there, it's more about, can the user do a thing? And then because you have a computer use model, it can look at the browser and it's automatically testing both your UX. Like, if the model can't figure out how to do what your user is supposed to be, drunk users won't figure it out either, or tired users or whatever. [00:47:39]
-
-So you just point it at the browser and you'd say, "Go, like, go place an order." And at the end of the day, as long as it can place the order it wants to place, you can keep iterating on the implementation, you can keep iterating on the design, you can keep iterating on the UX, you just get tests that are based on can the agent place an order. [00:48:03]
-
-**Carl:** Yeah. Oh, that's really interesting. That's, that's a really good variant on what I was just kind of talking about because, like, sure, static end-to-end tests that are verifying, like, this button with this test ID exists and the flow completes as expected. Like, sure, okay, it functions, but is it usable? [00:48:23]
-
-That's an interesting usability automated usability testing because that kind of goes back to what we were talk- talking about with, like, documentation and code notes. Like, just make it intuitive. Can an agent intuit how to achieve a general task? Oh, that's really interesting. [00:48:38]
-
-**Swizec:** If you've ever used VCR in Rails, that's kind of where I got the idea. [00:48:52]
-
-With VCR, you do full integration testing with calling remote APIs, but you don't wanna call them every time, so you record the responses and you keep them locally. So you then write tests against those local responses, but if the API ever changes or anything, you just regenerate them and you find all of the bugs in your code that don't fit the new, newly released API. [00:48:57]
-
-And you could do something similar with this where you have browser-based acceptance testing, and it records what it's doing so that you don't have to spend as many tokens every time. And you just d- when you change the UI, you delete it and you see if you can do the flow again. [00:49:19]
-
-**Carl:** Yeah. Totally smart. Interesting. [00:49:34]
-
-**Swizec:** Doesn't quite work yet, but that would be really cool. [00:49:36]
-
-**Carl:** We've kind of been going into this direction, but let me, like, sort of, like, you know, refocus a little bit. Like, so what do we think the current landscape of tools, of AI tools looks like? We've kind of been discussing that in, in, we've been dancing around it. And I guess where do we think it's going next? [00:49:38]
-
-**Mark:** Going or ought to go? [00:49:55]
-
-**Carl:** Either, both. Both. [00:49:57]
-
-**Mark:** My general inclination as the person who found one tool set and is stuck with, and is sticking with it and is not actively trying to change what he's doing. [00:49:58]
-
-Certainly what I'm seeing online is turning towards automate all the things, which I think is a very understandable impulse for a software developer. If you can do things once, you can do it in a loop, you can run it in parallel, you can distribute it, you can have an agent do it, et cetera. [00:50:06]
-
-And I think it kind of ties into the go as fast as possible at all costs for the purpose of going as fast as possible, direction that I see. I mean, like this bit about, you know, the dark factories, the idea that a team never even looks at the code, that it's truly all agents all the time, and all you say is, "Do something that accomplishes some goal, and you never even look at it, " is sort of an ultimate outcome of that. [00:50:21]
-
-I don't think it's a good one, but I see how it's the idea taken to a logical extreme. [00:50:48]
-
-**Carl:** I, I also have been pretty ... I found a tool and I'm sticking with it. I've been noticing Claude Code pulling in lots of ideas that I've just been thinking. Like, as it evolves, it's like, this is a productized version of how I've already been using it. [00:50:53]
-
-You know, like they added a /btw command that lets you ask a question and it will ... You cannot use tools and it does not go into the context history. So it's just like even do a little aside. Like if you wanna ask, like, "What's this thing doing?" I had already been doing that by way of, like, I'd ask it a question and then I'd go back and just, you know, restore the conversation to that. [00:51:06]
-
-And similarly, two months ago, I had been saying, like, I would actually spin up a Claude code instance that was on Haiku because I just need to summarize this and it's easier and I wanna manage my usage a little bit more precisely. And, like, now I don't have to do that because I just say, use a subagent and Claude Code is smart enough to say, "Oh, I'm just summarizing. Let me use Haiku." [00:51:27]
-
-## What behaviors belong to the agent, and what fundamentally can't be part of the agent?
-
-**Carl:** So I've just been watching, like, kind of what the agent itself is doing versus what I need to tell it to do, or proactively manage, converge a little bit. So that's, that's had me wondering, what outside of the agent, what is not going to live within the agent. And I think where I've landed on that is, like, everyone's talking about memory the last six weeks or so, and I think that's wrong. [00:51:49]
-
-I think that's just gonna be conventions and documentation. It's just knowledge. I think what's going to persistently live outside of an agent harness, as it were, is, like, incoming information, like a data stream, like GitHub issues, text, you know, the Slack chat, a Century Alert, a production alarm. If you have a data stream that is categorizing those and prioritizing them, and then giving that to an agent, to an autonomous agent that is just working, like, those are different things. [00:52:12]
-
-I think you cannot have a single generic agent that is able to connect to every possible data source. So that to me feels like a boundary that's gonna be pretty strong for the coming months. [00:52:44]
-
-**Swizec:** I don't know. I think for me, I feel like going super deep into what, at least on the internet, a lot of people are talking about various MD files and orchestrations and all the crazy stuff. [00:52:55]
-
-I feel like that's a little bit like ID skins and WIM shortcuts. It's like, yeah, sure, it's cool, but I, I think you're over complicating it. The models are gonna keep getting stronger and better, so I would just think they're gonna be able to do bigger and bigger tasks. I think feedback loops, like what you said, what is outside of the model? [00:53:06]
-
-Building really strong feedback loops is important. I think memory documentation inside the code or making the code itself easier to research or giving it MCP tools to, like, notion or linear or whatever, you keep your organizational memory. Having access to organizational memory will help agents as well. [00:53:25]
-
-Yeah. I don't think we're ever gonna come to full automation of anything, really. I think there's a strong gelman amnesia when it comes to th- these things where agents will fully automate every job except the ones I'm strict, super familiar with. That is just way too complicated and there's too many deals. [00:53:46]
-
-Everyone feels that way about their job because newsflash, they're all too complicated. [00:54:06]
-
-**Carl:** I wanna explain that reference briefly for people who aren't familiar. Gelman and Amnesia, that refers to the idea of, like, you're reading a newspaper and you see a story about your professional industry or something you're very knowledgeable about, and you see everything that it got wildly wrong, and you're like, "Who even wrote this? What are they doing? These incompetents." [00:54:11]
-
-And then you read the next article, and you're not familiar with it, and you just take it super credulously, and it's like, "Oh, yes, look at these," you know. It's a, like, I think that's a pretty good way of thinking about how people are talking about AI right now, yeah. [00:54:29]
-
-**Swizec:** And I think, from my perspective, go hard as long as you can. I think the bubble is going to collapse in the next one to two years. Tokens are gonna become super expensive, and we're not gonna use as many of these tools long-term as we are right now, but we're gonna have a lot of infrastructure, like, just like we did after the dot-com. [00:54:41]
-
-**Carl:** That's part of why I've been really interested in local models, because I agree with that. Like, they're being heavily subsidized right now, and I think in, I don't know, about two years, I don't know, we'll see. It's been very ... People are talking about it, it feels like the wheels are falling off right now with, like, Claude Code is just clamped down usage on the 20 d- $20 a month plan aggressively. [00:55:02]
-
-**Swizec:** They grew from nine billion ARR to 30 billion ARR in a quarter, so I'm imagine they have some scaling issues. [00:55:22]
-
-**Carl:** Right? Yeah, clearly. [00:55:30]
-
-**Mark:** One of the points I made in that draft blog post that I'm hoping to publish this week, the cats out of the bag, like, even if OpenAI and Anthropic were to utterly and completely collapse and go out of business today, the technology exists. [00:55:32]
-
-And whether it's, you know, boutique hosting of models or local LLMs, the technology is not going to go away. And even if it only, even if it never gets better at all, the t- the capabilities stay exactly the way they are today, it's still curly enough to upend large parts of our society. So then the question becomes, w- what are you doing with it and how do you, how do you respond? [00:55:46]
-
-**Carl:** Well, that's a good ... We should wrap up soon, but that is an excellent jumping off point for our last little subject here. [00:56:12]
-
-## Impacts of LLMs on software engineering?
-
-**Carl:** Uh, what do we think the impacts of LLMs on engineering as an industry, software engineering as an industry, and maybe more broadly, societally, if we wanna go there? [00:56:17]
-
-**Swizec:** I would say it's raising the bar for everything. [00:56:30]
-
-Like, what counts as a minimum viable product is gonna get more fancy and more complicated. What counts as a junior entry-level engineer, or what the expectations are for a junior entry-level engineer are gonna go up, and I think we're gonna need a lot more, um, product sense, and a lot less being just really good at writing code. [00:56:32]
-
-**Mark:** Yeah, I'm inclined to agree. I am honestly worried about the impacts in society as a whole. We've seen lots of debate and studies about, you know, have, have cell phones effectively destroyed the minds of youth and the ability to focus and social bul- like electronic bullying and, like, very ... Like, why did teens get very depressed starting in 2012? [00:56:54]
-
-Like, that sort of thing where a technology possibly had large-scale societal effects. And I'm not saying that LLMs are, you know, inherently destructive or inherently bad, but a lot of times the technology gets invented and then it changes society in ways we were very unable to predict early on. In this case, I think we can predict a number of ways, and there's probably a whole lot of other stuff, too. [00:57:14]
-
-So I genuinely worry about college students being able to get away without having to develop critical thinking skills even less than they were able to get away with it before. I have concerns about that sort of thing. And, you know, I'm towards the tail end of my career, I've done my thing, I learned, I gained my experience. [00:57:40]
-
-I don't know how junior devs are going to gain some of that experience. Maybe it is they need different experience. I don't know what the job pathways look like at that point. So, like, I mean, don't get me wrong, I'm excited to be able to use AI to crank out some of the things that I've had in my head. [00:57:58]
-
-I've found some of the same joy in being able to have a multi-hour flow session and build stuff just with AI editing the files instead of me and my fingers. But I can also look around and say, "Yeah, there's a bunch of unexpected consequences floating around as well." [00:58:14]
-
-**Swizec:** I mean, in terms of experience, it's not like I know how to code without a compiler, and I would definitely not enjoy coding without a, without garbage collection. [00:58:31]
-
-**Carl:** Yeah, I think that's closer to my theory on this. I think it will, you know, the societal impacts are gonna be something a lot. We'll see. I think the societal impacts will come mostly not from software engineering, so I think I don't understand those quite well enough to opine on it too much. I do care a lot about, like, sociology and economics and whatever. [00:58:41]
-
-So I do have thoughts and opinions, but I th- maybe it's a, maybe it's my Gelman new amnesia of like, I know those well enough that I'm like, "Nope, that's way too complicated. I'm not no opinion." But I think we take for granted a little bit how much we're standing on the shoulders of giants already and like, this is a big giant to climb the shoulders of for sure. [00:59:02]
-
-Like, not trying to discount that. People talk about how it's gonna change our brains and like, you know, destroy humanity and whatever. And like, I don't know, like, we kind of did a lot of that already. Like, can you navigate in your city without GPS? There's a lot of stuff that we've already lost that used to be like, canonically like, you know, you used to have a navigator. If you wanted to do a road trip, like, you would have spent a week planning a route and then, like, God help you if you miss a turn. Same thing for, like, finance and, like, the spreadsheet. I don't know, this is gonna be, this is a broad, more broadly applicable thing than any of those past technological leaps. [00:59:21]
-
-Another thing that I learned recently, going on the societal level again, there was a ... In 2023, there was an, like, international, like, literacy survey done, levels and whatever. And I think level one was can read, but struggles with, like, finding knowledge in text or, like, following multi-step instructions. [00:59:58]
-
-And 28% of Americans m- met that were, you know, were tested at that level of literacy. And, like, it said anything below level three is considered partially illiterate. And the stats were half, half- [01:00:20]
-
-**Swizec:** 54% of Americans are less than sixth grade reading level. They will not do well with LLMs. [01:00:35]
-
-**Carl:** Right. But, like, you know, we did that before LLMs. [01:00:42]
-
-That was 2023. Like, okay, sure. Like, there's gonna be weird shit going on since then now, but, like, God, we already ... Like, as far as destroying society, like, we've done a pretty good job of that without AI. [01:00:45]
-
-**Swizec:** And for context, that's 54% of adult Americans. It doesn't, like, count children and stuff. [01:00:57]
-
-**Carl:** Yeah. [01:01:03]
-
-I don't know. It's just, like, anytime I hear people talk about, like, the downfall of, like, civilization or whatever, it's like, "I don't know. Have you looked at civilization lately? It's not doing so great." So, I don't know, it is gonna be a lot. It's gonna be challenging and difficult. I guess going back to engineering, software engineering, you remember the '90s and 2000s, 2010s era, like, stereotypes of software engineers, like, it's, like, super autistic, like, zero social skills. They are a human computer. [01:01:03]
-
-And now we don't have that anymore. We, you know, democratize software engineering and now everyone does it. We've always tried to get something basically like an LLM. Like, that's what people wanted out of software engineers this whole time. So, I think it's gonna be ... I like the analogy of, like, compilers and garbage collection and stuff, because it's just a new tool. [01:01:31]
-
-It's a new level of abstraction, and now it's much further removed from the hardware. But, yeah, I don't know. People talk about, like, the d- it's gonna destroy, like, the upskilling, it's gonna destroy junior engineers, and it's, there's not gonna be any pathway in. And, like, I don't know, maybe that's true, but at the end of the day, I'm gonna end on, like, a positive thought or, like, advice. [01:01:54]
-
-Like, this is all communication. It's just more and more communication. If you wanna lock in your software engineering career, get good at communicating, get good at deeply understanding and articulating a problem, not the code, not the patterns necessarily, but, like, understand what an architecture is good at or bad at or what the performance profile of this or that are. [01:02:18]
-
-And, like, now, you don't even need to understand it at the same level. Like, I've been really excited about AI is because I have such a broad and shallow expertise, and now I can use it. Like, it used to be that I had all this, like, vague notional expertise in a wide range of stuff, and it's like, "Damn, I wish I could use that, but I would need a team of 15 people in order to be productive with this. [01:02:45]
-
-And now I don't. So, like, I don't know, that's exciting for me. And I think that's just generally exciting. So if you're just good at communicating and you learn a domain and you get good at articulating problems within that domain, then, like, I think you're gonna be fine. [01:03:08]
-
-## A superpower right now is a domain expert who can kind of code
-
-**Swizec:** I think superpower right now is if you're a domain expert who can kind of code. [01:03:22]
-
-**Carl:** There is certainly still value in, you know, greater engineering expertise and understanding how to ship stuff to production. [01:03:28]
-
-**Swizec:** At some scale, that becomes a domain expertise. [01:03:34]
-
-**Carl:** True. Yeah. Extremely true. So yeah, I don't know. [01:03:37]
-
-**Mark:** Uh, I'm excited. I [01:03:41]
-
-**Swizec:** can build more stuff. [01:03:42]
-
-**Carl:** I can build so much ... I have built so much more. [01:03:43]
-
-I've explored so many more things and gone, "Oh, this is harder than I thought. I'm gonna set it down." Instead of just never doing it and, like, fantasizing about what it could have been for years, you know? [01:03:45]
-
-**Mark:** Yeah. Same. [01:03:54]
-
-**Carl:** All right. Cool. Thank you all. Thank you both for joining me. Thank you everyone in the audience for listening. [01:03:55]
-
-Appreciate it a lot. [01:04:00]
-
-**Mark:** Hopefully this was informative. [01:04:01]
-
-**Carl:** Cool. All right. Well, this has been this month in React, quote unquote. I think we may be exploring different formats in the future because, I don't know, who's following individual software library development as closely anymore. But yeah, thanks so much for listening. [01:04:02]
-
-If this is a show that you get value from, please send it to a coworker, send it to a friend, leave us a review. And yeah, I'll see you next month. [01:04:17]
-
-**Mark:** All right. Take care. [01:04:25]
diff --git a/src/transcripts/tmir-2026-05.md b/src/transcripts/tmir-2026-05.md
deleted file mode 100644
index 9a121cd..0000000
--- a/src/transcripts/tmir-2026-05.md
+++ /dev/null
@@ -1,645 +0,0 @@
----
-title: "TMiR 2026-05: Who even is on the Core team anymore, TanStack got pwn'd bad"
-date: 2026-05-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we discuss what the heck is going on at the React Core team, how TanStack got pwn'd so badly, and how the JS ecosystem is reacting to the aftermath of the React2Shell fallout."
-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:55](#some-podcast-meta)] Some podcast meta
-- [[00:01:49](#new-releases)] New Releases
- - [[00:01:51](#ts-v7-beta)] [TS v7 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/)
- - [[00:05:15](#rolldown-10)] [Rolldown 1.0](https://voidzero.dev/posts/announcing-rolldown-1-0)
- - [[00:06:51](#fate-10)] [Fate 1.0](https://fate.technology/posts/fate-1.0)
-- [[00:09:48](#main-content)] Main Content
- - [[00:09:56](#react-core)] React Core
- - [[00:10:09](#react-team-status-after-meta-layoffs)] React team status after Meta layoffs?
- - [[00:14:59](#react-compiler-port-to-rust-still-in-progress-latest-pr)] [React Compiler port to Rust still in progress](https://x.com/poteto/status/2056865079543681329), latest [PR](https://github.com/facebook/react/pull/36173)
- - [[00:15:54](#tanner-linsley-is-projecting-react-its-definitely-not-a-fork)] [Tanner Linsley is "projecting" React](https://tannerlinsley.com/posts/projecting-react) (it's definitely not a fork)
- - [[00:21:38](#tests-are-the-new-moat)] [Tests are the new moat](https://saewitz.com/tests-are-the-new-moat)
- - [[00:23:32](#brooks-lybrand-thoughts-on-react-community-after-react-miami)] [Brooks Lybrand thoughts on React \+ community after React Miami](https://brookslybrand.com/posts/react-miami-2026.html)
- - [[00:25:04](#tanstack-is-exploring-how-to-expose-server-components)] [TanStack is exploring how to expose Server Components](https://tanstack.com/blog/react-server-components)
- - [[00:27:19](#who-owns-the-tree)] [Who Owns the Tree](https://tanstack.com/blog/who-owns-the-tree)
- - [[00:27:31](#rscs-in-tanstack)] [RSCs in TanStack](https://frontendmasters.com/blog/react-server-components-in-tanstack/)
- - [[00:28:12](#remix-v3-beta-preview)] [Remix v3 beta preview](https://remix.run/blog/remix-3-beta-preview)
- - [[00:28:35](#both-remix-and-tanstack-are-exploring-what-if-no-react)] Both Remix and TanStack are exploring "what if no React"?
- - [[00:36:11](#tsrx-a-variant-on-jsx)] [TSRX](https://tsrx.dev/), a variant on JSX
- - [[00:41:52](#security-everything-is-compromised)] Security! Everything is compromised
- - [[00:42:04](#tanstack-router-compromised-and-socket-analysis)] [TanStack Router compromised](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem), and [Socket analysis](https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack)
- - [[00:46:58](#tanstack-followup-with-followup-hardening)] [TanStack followup with followup hardening](https://tanstack.com/blog/incident-followup)
- - [[00:47:10](#nx-monorepo-tool-compromised-as-a-result)] [Nx monorepo tool compromised](https://nx.dev/blog/nx-console-v18-95-0-postmortem) as a result
- - [[00:52:02](#react2shell-recaps-from-lachlan-davidson-and-sylvie)] React2Shell recaps from [Lachlan Davidson](https://lachlan.nz/blog/the-react2shell-story/) and [Sylvie](https://sylvie.fyi/posts/react2shell/)
- - [[00:52:25](#next-1625-and-more-react-cves)] [Next 16.2.5 and more React CVEs](https://github.com/vercel/next.js/releases/tag/v16.2.5)
- - [[00:53:19](#npm-adds-staged-packages-and-e18e-adds-guidance)] [NPM adds “staged packages”](https://docs.npmjs.com/staged-publishing) and [E18E adds guidance](https://e18e.dev/docs/publishing.html#staged-packages)
- - [[00:54:50](#pnpm-11-defaults-to-min-release-age-npm-12-will-block-by-default)] [PNPM 11 defaults to min release age](https://socket.dev/blog/pnpm-11-adds-new-supply-chain-protection-defaults), NPM 12 will [block by default](https://github.com/npm/rfcs/pull/868)
- - [[00:57:59](#review-your-gh-actions-people-)] [Review your GH Actions, people!](https://github.com/e18e/ecosystem-issues/issues/266)
- - [[00:59:13](#mark-posted-his-big-ai-blog-posts-part-1-fears-and-journey)] Mark posted his big AI blog posts. [Part 1: Fears and Journey](https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-1-fears-opinions-journey/)
-- [[01:08:39](#outro)] Outro
-
-# Interview
-
-**Carl Vitullo:** Thank you for joining us. We're coming to you live from Reactiflux, the place for professional developers using React. And I am Karl. I'm a staff level product developer and freelance community leader/entrepreneur/I don't know what I am anymore, here at Reactiflux, where I do community programs like this and build some tools to help keep the community operating. [00:00:00]
-
-**Mark Erikson:** And I'm Mark. My day job is at Replay, where we've built a time traveling debugger for web apps, and that can be used by both humans and agents. And in the last couple months, I've gone between building MCP tools, doing product manager work, being a dev rel, going on vacation, and now I'm trying to figure out what I'm doing now that I'm sort of back, except that I'm going on more conference travel shortly. So it's kinda crazy right now. [00:00:19]
-
-I do Redux stuff and I collect links. [00:00:41]
-
-**Carl Vitullo:** Man, we're all doing too much stuff. It's just too many things. [00:00:43]
-
-**Mark Erikson:** Indeed. My... I, I needed that vacation. Two weeks of golf in Scotland. It was fantastic. [00:00:46]
-
-**Carl Vitullo:** Yeah, that's pretty good. Scotland's great. I love Scotland. [00:00:52]
-
-## Some podcast meta
-
-**Carl Vitullo:** Okay, let's get into it. Before we go into, like, new releases and whatever, some, like, meta discussion whatever, historically we were co-hosted by Mo, who brought us some lovely React Native and agency perspective here. He's had to step back a bit because of just, like, personal things and work busyness, and he just hasn't had the time and energy to really go up here. And I guess I, I also wanna mention, I am feeling somewhat similarly. I've been doing this for, like, three years now. I'm no longer reading React and web news at the level of intensity that I historically have been. [00:00:55]
-
-So, um, yeah. Mark and I are talking about how to continue this. This is a valuable service. I think this podcast is good. I want to keep it going. I think a once a month news check-in about the ecosystem is really valuable, so I wanna keep offering it. But, uh, that's where we're at. So just FYI, stuff is gonna change. [00:01:25]
-
-Stuff has changed. Stuff will continue to change. Just like life. [00:01:40]
-
-**Mark Erikson:** Yeah, that sounds all too real. [00:01:44]
-
-**Carl Vitullo:** We're gonna try and keep doing this, but it'll be a little different than we have. [00:01:46]
-
-## New Releases
-
-**Carl Vitullo:** But yeah, okay, into some new releases. [00:01:49]
-
-## [TS v7 beta](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/)
-
-**Carl Vitullo:** First off, we have the TypeScript v7 beta, which is, if I recall correctly, this was gonna be the one where it's all rewritten. [00:01:51]
-
-**Mark Erikson:** This is the TS Go release, and you might also notice this is pretty hot on the heels of TS 6.0. So TS 6.0 is supposed to be the last actual release of the current written in TypeScript compiler, and 6 is the one where they changed a bunch of defaults to be more strict and better match the way JavaScript's used today. [00:02:00]
-
-7 is same settings, but completely different compiler implementation. One interesting bit here is I believe that 7.0 is not going to have a lot of the programmatic API stuff that exists right now. Uh, I think they said they hope to get that out in a 7.1. That does mean that there is definitely going to be some amount of, like, fluctuation and churn as you go upwards. [00:02:22]
-
-But in terms of just using the compiler to type check, go ahead and start using 7. Like- Cool ... right now. It's there. Okay. It's faster. It's the same logic. Use it right now. [00:02:49]
-
-**Carl Vitullo:** So that's like the SDK, like if you're using TypeScript to do some build tools, using it in JavaScript yourself, that's not feature complete yet? [00:03:00]
-
-**Mark Erikson:** Right. So yeah, so I, I don't know what all is and isn't- [00:03:09]
-
-**Carl Vitullo:** Right. I've never used that, so ... [00:03:14]
-
-**Mark Erikson:** intended to be included in the API. But like, for example, in Replay's code base, we have some programmatic linting stuff that uses the TS Morph package, and TS Morph depends on being able to import the TypeScript as a library and create- Right [00:03:15]
-
-a program instance and programmatically type check. And so that sort of thing might not fully be available in 7.0, but maybe in 7.1 in some form. [00:03:30]
-
-**Carl Vitullo:** Yeah. That makes sense. Interesting. Yeah, I mean, that stuff's always a little bit... Usually, when you're trying to use it as an SDK in that way, it's because you're doing something a little bit more finessed and complicated, so it makes sense that that takes a little more time to, to settle out. [00:03:43]
-
-**Mark Erikson:** I know that there's, in general, a lot of issues because people have reached into TypeScript's internals to im- be able to import methods that were never really intended to be exposed- Right ... to the public. [00:03:57]
-
-**Carl Vitullo:** Classic. [00:04:08]
-
-**Mark Erikson:** As well as just the fact that it's one thing when it's TypeScript importing TypeScript. [00:04:09]
-
-It's another thing when the TypeScript implementation is now in another language, Go, and so how do you expose that back to TypeScript client code, as well as how do you do so performantly, 'cause you're now crossing the language barrier? I know that's what the, like the Oxlint folks have been dealing with in terms of trying to implement typed linting, but needing to go back and forth between pieces written in different languages. [00:04:14]
-
-**Carl Vitullo:** Mm-hmm. The parallelization is interesting. I, I... Like, that's such a good reason to reach for Go, is to introduce parallelization, 'cause, like, Go routines and, you know, whatever. Go is good at that. Well, that's really cool to see that TypeScript is now doing... It says, "Now performs many ch- steps in parallel, including parsing, type checking, and emitting." [00:04:43]
-
-Anytime you can break work down into smaller units that can be isolated from each other and executed in parallel is awesome. So love seeing that being brought into TypeScript. Like, that's so core and foundational. That's awesome. [00:05:01]
-
-## [Rolldown 1.0](https://voidzero.dev/posts/announcing-rolldown-1-0)
-
-**Mark Erikson:** And then on a similar note, the Void Zero folks announced that Rolldown has hit 1.0. [00:05:15]
-
-And to recap what that is, uh, Vite had been using two different bundlers, had been using esbuild, which is fast and written in Go for development mode, and had been using Rollup, which was a written-in-TypeScript JavaScript bundler for production builds. And so in order to both make it go faster and harmonize things, you're doing both dev and prod builds with the same pipeline, they essentially re-implemented Rollup but in Rust and called it Rolldown. [00:05:20]
-
-So yet more build tools being written in Rust, and it's been a long time coming. Vite has been using Rolldown in various betas for a while. And Rolldown itself has now actually hit 1.0. [00:05:52]
-
-**Carl Vitullo:** Cool. Yeah, I was just trying to refresh my memory on... 'Cause we've, I feel like we've been talking about Rolldown 1.0 for, like, a really long time. [00:06:05]
-
-So I was like, "When was that?" It looks like we had the, there was an RC of 1.0 back in January. So, like, that's some pretty serious, you know, d- I don't know, dedication to stability and rollout. Can we just add one more, it's a suffix to roll by s- describing this as a rollout? We'll get the, the rollup, Rolldown rollout. [00:06:13]
-
-But yeah, so okay. So they've been in RC. They've had a Rolldown 1.0 RC out since January, and they're calling it good. They're shipping it. That's awesome. [00:06:32]
-
-**Mark Erikson:** Yep. Wonderful stuff. [00:06:40]
-
-**Carl Vitullo:** Love that. Great. Well, yeah, and you can, uh, listen to our January episode to see, uh, to hear us discuss that previously. [00:06:42]
-
-**Mark Erikson:** All right, and then one other release to announce. [00:06:48]
-
-## [Fate 1.0](https://fate.technology/posts/fate-1.0)
-
-**Mark Erikson:** Christoph Nakazawa has released Fate 1.0. So we, uh, we'd mentioned this a couple times previously, but Fate is a new React-based data fetching library. My closest comparison is it's kind of like a GraphQL in the sense that the client is specifying pieces of data to fetch. And to be honest, I still don't have a, have a f- really good grasp on how this works. [00:06:51]
-
-I've just seen some of the d- some of his descriptions. But it's meant to be composable queries, normalized data fetching, and integrating with React's new async and suspense-based features. My understanding is that this is very heavily... I'm not gonna say, I'm not gonna say vibe coded. I, I know he's, like, been very intentional in how he's built it. [00:07:18]
-
-My understanding is most of the actual code here was written with AI tooling, with a lot of intent behind it. [00:07:43]
-
-**Carl Vitullo:** Yeah. That's fair. I don't know. Written with AI tooling and vibe coded are not the same thing. That's interesting. I don't know. This definitely looks kinda interesting. It looks like it's trying to be something, like you said, kinda GraphQL-ish, re- relay-ish, TanStack, you know, ish. [00:07:49]
-
-But I guess, like, from first principles in the server components era- I guess is how it feels to me reading this. That's interesting. That's valuable. That's a really good exploration, but is- I don't know, something about this says r- like, research project more than something I would bet my, you know, bet my work on. [00:08:05]
-
-**Mark Erikson:** My vague sense, and this is just, you know, me eyeballing things as always, real project, not just a, an experimental toy. Early obviously, and I would assume no one else is actually using it at the moment, but it's the kind of thing that I could see getting some- Right ... amount of adoption over time. [00:08:26]
-
-**Carl Vitullo:** That's curious. [00:08:42]
-
-That's interesting. Yeah, we'll s- have to see how it goes. That's really interesting. Love having more explorations on ways to do data fetching better. I'm having thoughts come up that I know I'm also going to wanna discuss when we start talking about Remix V3 in a little bit. It's so s- funny to me how much exploration has been done over the last 15 years in, like, how do we transfer data and UI across the network? [00:08:43]
-
-We're still figuring that out. So I, I have more to say on that when we t- talk about Remix V3. But, you know, this is interesting. This looks like a valuable exploration. Christophe Nakazawa is definitely someone to take seriously. [00:09:09]
-
-**Mark Erikson:** And int- interestingly, I believe he actually joined Void Zero as a company, and his day job stuff is now around some of the, like, the Void server framework pieces that they're building. [00:09:21]
-
-**Carl Vitullo:** Oh, yeah. Interesting. He says he's product at Void Zero on his Twitter. Curious. That's cool. Very cool to see him still so, like, deeply embedded in the ecosystem, and then doing, like, little research side projects like this. Prototypes of alternate usage patterns. Cool. [00:09:32]
-
-## Main Content
-
-**Mark Erikson:** Okay, onto something resembling main content, and something resembling React core-ish stuff. [00:09:48]
-
-## React Core
-
-**Mark Erikson:** So this first bit is something that I surprisingly don't actually have much of a link for, but I'm going to try to pass on a summary of bits and pieces and conversations that I've had in multiple places. [00:09:56]
-
-## React team status after Meta layoffs?
-
-**Mark Erikson:** Loosely put, I have no idea who's even still on the React team at this point, for multiple reasons. [00:10:09]
-
-So Meta just went through two rounds of layoffs, and from watching things, I know that there was some shuffling in and around r- the React organization. For example, I think the Relay team used to be considered part of the React org, and now they're part of a separate organization. But a number of people that I know have, appear to have left the React team one way or another. [00:10:17]
-
-Uh, for example, Lauren, who'd been working on the React compiler, is now over at Cursor. I believe I saw that Sebastian Markbagha has left Vercel and is possibly not labeling himself as being part of the React team at this point. Joe Savona, who was essentially a lead on the React team for the last year or two, I heard a rumor that he has been reassigned to something else AI related. [00:10:43]
-
-These are all bits and pieces. I don't have, you know, direct links for them. But the picture I'm getting is that what we would consider the React core team has been kind of decimated. If you were to ask me right now, like, who am I pretty sure is on React core at the moment, about the only people I could still point to would be Andrew Clark at Vercel and Rick Hanlon at Meta. [00:11:11]
-
-There's still a bunch more beyond that, but just, I, I, like, I literally don't know who is working on React right now, which is not a thing I would've said last fall at React Conf. And so, this also brings up a number of other questions because Seth Webster was the head of the React org at Meta, and he also spent the last few years quietly trying to put together the React Foundation, which got announced. [00:11:34]
-
-And I've been trying to keep an eye on, you know, any news and discussion of where the foundation is. Seth himself just moved over to Expo. That was publicly announced. And I believe he's still going to be the head of the React Foundation, but I also have seen no evidence of anything as far as actual work or output from this foundation, either in terms of community involvement or events or taking over the day-to-day technical work on React itself. [00:12:00]
-
-I actually did see in a PR yesterday, Sebastian Silbermann, who is essentially part of the React Core and Core team externally at this point, did make a mention of moving repositories over to a React Foundation org, at which point they might be doing some, you know, kill and kill AI and bot spam type cleanup. [00:12:38]
-
-So all this says to me that they're, like, things are changing around React's development process, both who's doing it and where it's happening, but it also feels, just me observing things, it feels like things are fragmenting and stalling. And I actually legitimately do not know what that means in terms of technical development on React itself in the near future. [00:13:02]
-
-**Carl Vitullo:** Strange, curious, yeah. So I'm in a, I'm in a Discord for the React Foundation, and I noticed over the past several months that virtually nothing has happened in there. [00:13:28]
-
-**Mark Erikson:** There's been essentially no conversation except maybe there was a little bit of chatter about something React Native related, like a week ago. [00:13:41]
-
-**Carl Vitullo:** And I saw something about a contributors Discord as well, so I think there's a private space being set up for people who are act- actively contributing code to React Core. But I, as someone who does not contribute code to React Core, I'm not in there, and I, so I don't know exactly what's going on. I do note that the website, you know, react.dev Meet the Team, lists Sebastian, lists Lauren. [00:13:48]
-
-So it lists a number of people who are, you are saying, have been publicly confirmed as no longer- [00:14:11]
-
-**Mark Erikson:** I think Lauren may still be involved with the compiler. I don't think she, I don't think she entirely left the team, but she certainly left Meta overall. Sebastian, I got the impression he's, he's out for now, but- [00:14:16]
-
-**Carl Vitullo:** Well, certainly at least job titles are out of date, 'cause, you know, Lauren Tan says engineer at Meta, and so if she's no longer at Meta, that's wrong. [00:14:30]
-
-This website has not been updated. So yeah, oof. That's, uh, yeah, okay. Certainly lack of community engagement, I would say. [00:14:38]
-
-**Mark Erikson:** Having said that, I have spent a lot of time over the years just watching the list of PRs in the r- in the React repo, just to get a sense of what's going on, and I hadn't done that much over the last few months just because of travel and life and work and stuff. [00:14:45]
-
-## [React Compiler port to Rust still in progress](https://x.com/poteto/status/2056865079543681329), latest [PR](https://github.com/facebook/react/pull/36173)
-
-**Mark Erikson:** I was looking at it the other day, and the bulk of the PRs that I'm seeing at the moment do actually have to do with either things like updating some of the release process or, uh, some work on the React compiler port to Rust. And in fact, Lauren just confirmed on Twitter the other day, that is still actively being worked on. They are testing it out internally at Meta. I believe she's still involved in that from her side. They are trying to push that along. I do think that's gonna be a big deal for c- for a couple reasons, because eyeballing things, to me, the biggest blockers to people adopting the compiler right now are the comp- are the requirement that you still have to use Babel as part of the build process, as well as the speed of the compiler. And so if porting the React compiler to Rust makes it faster and eliminates the need for Babel, then those two roadblocks go away [00:14:59]
-
-## [Tanner Linsley is "projecting" React](https://tannerlinsley.com/posts/projecting-react) (it's definitely not a fork)
-
-**Mark Erikson:** All right, so, uh, that, that brings us up to a very interesting and somewhat controversial article, which is Tanner Linsley not quite forking React itself, projecting React. So the, the idea here is the React team has spent a lot of time over the last eight-plus years adding all these new fancy async concurrent features to React. [00:15:54]
-
-As we've talked about, they had a general vision for what they were trained to build, and they've essentially arrived at what their vision roughly was. But, you know, a lot of us are still building React apps that don't make use of the new features or don't, you know, just don't need all the capabilities that are in there. [00:16:19]
-
-But React as a package is delivered as a giant monolith. There is no option for, like, disable concurrent mode or something like that. And so all the code that implements this goes in the bundle whether you're using it or not. And that also means a lot of the logic and the checks that take up time are still in there. [00:16:37]
-
-And so Tanner actually went out and he cloned the React repo, and he told an AI essentially, "Rip out all the pieces of React that I personally do not need," and he was able to rebuild React with a lot of pieces stripped out, and it drastically shrank the bundle size, and it sped up SSR. And he is actually running his own personal website in tanstack.com on this personal modified fork of React. [00:16:59]
-
-He didn't wanna call it a fork, 'cause that term has a lot of political implications, so he called it a projection of React, in the sense of, like, projecting data or, like, viewing a subset of the data. And so technically he's made the changes available, but he is very intentionally not telling people to go try this. [00:17:32]
-
-Like, this is not Tanner saying, "I'm forking React, use my version." This is, "I played with something and if you want to look at what I did, it's over here, but I'm actually kind of telling you don't use what I did." And I've seen mixed reactions to this. I saw a number of people say, "This is a horrible idea," because, you know, LLMs can make mistakes, and if we start modifying packages, then there's the risk of introducing new bugs and security problems that w- that got handled in the original, and if you're mod-- If, basically if you're making changes, you run the risk of breaking stuff. [00:17:55]
-
-And I get that But I'm actually kind of in favor of this idea for a number of reasons. Like, code is not sacred. Code is there. A license says anyone can modify this if, you know, however they want. If Tanner wanted to fork this, that would be a totally valid thing to do morally, legally, ecosystemly. Maybe not a good idea, but it's a totally valid option. [00:18:31]
-
-But also, React exists in its current form because the React team wanted to pursue certain ideas. It's totally valid for other people in the ecosystem to say, "I would like to pursue different ideas and trade-offs and see what happens." And especially given the way that it looks like React development is kind of fragmenting and stalling slightly, I am entirely in favor of people trying to do different experiments. [00:18:55]
-
-**Carl Vitullo:** Yeah. Like, this is making me think back to some of our, some of the conversations we've had over the years at this point. And like, you know, so something that I, I've expressed pretty consistently is this sense of React as a, like, research project, pushing the envelope of what's possible with UI over the network. [00:19:24]
-
-And I think a very real tension with React versus how it's used is not everyone is trying to push the envelope of what's possible with UI over a network. Some people just want it to fucking work, and React needs to serve everyone In a way that they want. So, it... And so, you know, okay, so bringing it back to this specific blog post, Tanner Linsley projecting React, his motivation here was React's bundle size is quite large, and that's true. [00:19:42]
-
-It's quite big, and it's quite big because it's trying to do a lot of things in a generic manner for a lot of different people. And so I think there's a very real argument here that if React is trying to do five different things for five different customers, I am going to use AI to remove the code for the four customers that I am not. [00:20:14]
-
-I am only using this surface area. This surface area has pretty clearly defined contracts and testing guarantees, so I am going to rewrite this part of the surface area that I am touching. And I think that makes a ton of sense here. [00:20:38]
-
-**Mark Erikson:** Yeah, and it, it also ties into another theme that we've seen going on a lot lately, where people are taking publicly available tools, libraries, whatever, AI rewriting them to an- another entire language, but because all the tests are already there, you can verify that your rewrite is still valid. [00:20:52]
-
-And in this case, I think the risk of, you know, accidentally introducing, you know, major new bugs or security problems is a lot more limited, because you still have all the original React tests for all the functionality you care about, you're just deleting the tests and the logic for the functionality you don't care about. [00:21:11]
-
-**Carl Vitullo:** Which makes me think, we brought this in, I think, two or three months ago. Actually, it might have been the episode that we lost the audio for, come to think of it. [00:21:31]
-
-## [Tests are the new moat](https://saewitz.com/tests-are-the-new-moat)
-
-**Carl Vitullo:** But we talked about this blog post from a mutual acquaintance of ours, uh, Daniel Sawitz, Tests Are The New Moat. And I think that's what you're talking about, is, like, if the tests are out there, if you can assert that your code passes this test suite, then what's the difference between your code and their code? [00:21:47]
-
-You know? If it's behaviorally the same as guaranteed by the test suite, and you trusted the test suite to guarantee the behavior of the original, then that's fungible, in a way. That's in- you know, one thing interchangeable for the other, assuming the tests are good enough. So yeah, that's interesting. I see a comment here that I wanna bring in. [00:21:54]
-
-The risk, I think the risk is the fragmentation. Yes, sure, but, like, th- there's risk of fragmentation, but it's also, like, what risks does the fragmentation introduce? Like, fragmentation is not a risk on its own. It leads to other things. Like, if there's too many tools to maintain, then maybe it's harder to guarantee the security of any one thing. [00:22:13]
-
-But we already have that situation, as, uh, devin- as evidenced and demonstrated by all of the, you know, the Shai Hulud attacks, as evidenced by, we're gonna talk about this soon, TanStack getting compromised and 40 packages getting pwned with malicious versions published. So, like, in that sense, it's kind of safer to write your own. [00:22:34]
-
-Like, okay, sure, it's, you know, it, it, maybe it has its own vul- security vulnerabilities, but, like, you're not exposed to the supply chain risk. So I, yeah, I think the advantages are not clear-cut. [00:22:54]
-
-**Mark Erikson:** So overall, like Tanner heavily emphasized, this is an experiment. I tried it to see what would happen. I'm writing up the results of the experiment. [00:23:04]
-
-Please don't actually use this. But I actually see this as a valuable experiment. [00:23:13]
-
-**Carl Vitullo:** Yeah, I would say don't m- don't use this, but consider recreating it with something else that you find 80% good but not quite suitable. If there's a test suite, try throwing an AI tool at it. Anyway, interesting. [00:23:20]
-
-## [Brooks Lybrand thoughts on React \+ community after React Miami](https://brookslybrand.com/posts/react-miami-2026.html)
-
-**Mark Erikson:** And then one other sort of adjacent bit, which is, uh, Brooks Lybrand, who's one of the Remix React Router developers, put up a post with his thoughts on the React Miami Conference. [00:23:32]
-
-But one of the s- one of the big sections is how are people feeling about React? And some of this was, well, you know, a little bit of the enthusiasm has gone out because AI is hot and React is not. But there was also... He also specifically makes the comment that, quote, "There's basically now two Reacts," and it's kind of how using React today feels. [00:23:45]
-
-There's old style React, and then there's all the, the new fancy Async, Suspense-y stuff, and they're almost, like, two different frameworks at this point. And so it's kind of a mindset thing. [00:24:08]
-
-**Carl Vitullo:** I did read this post from Brooks. It echoes a lot of, uh, kind of what I've experienced. I don't know about the two, two Reacts part, but React Miami has been a really great conference that I've attended it for a number of years, but I haven't the last two, unfortunately. [00:24:22]
-
-And I know that this was Michelle's last year organizing it, and I wanna shout out Michelle Bakels for being a phenomenal organizer and going on to bigger and better things. [00:24:35]
-
-**Mark Erikson:** Wonderful human being, great job organizing the conference. She has put together an amazing community there. [00:24:44]
-
-**Carl Vitullo:** And I believe is now organizing or doing, like, developer relations type things for Open Code, if I'm not mistaken. [00:24:51]
-
-So yeah, do... Power to her. Wanna throw out some recognition while discussing her conference. That's what we gotta say on there. [00:24:58]
-
-## [TanStack is exploring how to expose Server Components](https://tanstack.com/blog/react-server-components)
-
-**Carl Vitullo:** Let's go into RSCs on TanStack. [00:25:04]
-
-**Mark Erikson:** We've talked a lot about server components over the last few years and, you know, which frameworks support them and how does it work. One of the biggest issues with server components is that Next.js had them first, and has had them the longest, and has been the only major way to use server components for a long time. [00:25:06]
-
-Our mental model of server components is still very much based on how does Next.js offer them in the app router. And so TanStack now has... And TanStack Start now has server component support, but they have approached it in a very different method from, from an API design and usage perspective. I've seen some of the examples. [00:25:24]
-
-I've looked at- Some of the bits and pieces I, I half understand what's going on here. But m- my rough explanation is that they allow you to do some of your own server rendering, and then you treat the response as data to the point where you, you would actually use, like, TanStack Query to fetch the dreamed data from the server, and then just sort of include the output on the client side. [00:25:47]
-
-Another way to put it is they are trained to keep TanStack Start as a client-first framework, where you very clearly say, "This piece of code runs on the server." Whereas Next in the app router is, we are starting your component tree as the server, and you have to explicitly break out and say, "This is where this..." you know, "This is a client component," et cetera. [00:26:14]
-
-So they're trained to flip the server component usage pattern up, kind of almost, like, upside down compared to how Next.js does it. And I think this is good. I see a lot of benefits here in terms of mental model and complexity, and just even just being able to read the code and say, "This code runs on the server, this code runs on the client, and I understand what's happening where." [00:26:41]
-
-**Carl Vitullo:** Yeah. That's definitely the tough part of RSCs. I applaud them for giving it a go, but that, that is a challenging problem space to be working in. [00:27:08]
-
-**Mark Erikson:** So we've, we've got a couple different posts here. [00:27:17]
-
-## [Who Owns the Tree](https://tanstack.com/blog/who-owns-the-tree)
-
-**Mark Erikson:** And the TanStack folks put up two posts on server components your way, and who owns the tree, treating server components as a protocol and not an architecture. [00:27:19]
-
-## [RSCs in TanStack](https://frontendmasters.com/blog/react-server-components-in-tanstack/)
-
-**Mark Erikson:** And then Adam Rackis did a post on Frontend Masters where he explains server components in TanStack as if you had never heard of server components before. So in other words, rather than trying to say, "Here's how it compares to Next.js," just, "Let's kind of teach this up from first principles." [00:27:31]
-
-**Carl Vitullo:** Heh. I, I appreciate that, because the other, the, um, React server components your way blog post on TanStack.com starts with, "What is, what are server components? Yeah, no, this is not a server component crash course." so okay, they got, they got both audiences covered. [00:27:51]
-
-Okay, into some stuff that we have referenced already in this episode. Some new and notable stuff in the ecosystem. [00:28:05]
-
-## [Remix v3 beta preview](https://remix.run/blog/remix-3-beta-preview)
-
-**Carl Vitullo:** Starting off, I guess, we've got Remix v3 beta preview. Beta preview, not just a beta, not just a preview It's a beta. It's a beta preview. [00:28:12]
-
-**Mark Erikson:** Isn't that called an alpha? [00:28:23]
-
-**Carl Vitullo:** I think that that does seem like an alpha, but I guess... No, I, 'cause I guess an alpha implies that it might change before a beta, so this is teasing the beta. It's not gonna change, but this is what it's gonna be. Fair enough, whatever. It's okay. It's great. [00:28:24]
-
-## Both Remix and TanStack are exploring "what if no React"?
-
-**Carl Vitullo:** Yeah, this is interesting. Th- th- so Remix is no longer a React-based framework, which it, you know, a- and I'm just kinda reflecting on the conversation we just had about TanStack projecting React. And so it seems like it, it... There's some real ecosystem appetite to do things that are not literally built upon React while being heavily, deeply inspired by. [00:28:35]
-
-And, like, a, a true, not just inspired by, but, like, a true lineage. Like, you know, it, Remix and TanStack, if both of them are looking at what it means to not bundle React, then that's a really serious evolution for them as projects that have historically bundled React. So I don't know. That's interesting. So they're announcing this Remix 3 beta preview. [00:28:57]
-
-It's a pre-release, not production ready. I guess the core argument, their, the thesis of Remix 3 is that, I guess I would say it's, their opinion here is that fra- modern frameworks try to reinvent too much of what the web platform already provides, and so they're trying to strip away some of that complexity that they view as needless on top of just, like, web standards and available, you know, protocols. [00:29:18]
-
-Which is, I'm sympathetic to that thesis. Like, I think there's a lot of stuff that React is doing that maybe it would be better for, l- or React, Next, TanStack, that may be better for the platform itself to take care of. Like, we definitely could be doing a lot more at the protocol level. Like, a thing I've been seeing people talk about like it's a brand-new fancy technology is, like, adding .md as a suffix to your URLs to make it render, you know, what would have been a HTML page in Markdown. [00:29:47]
-
-And I'm like, "We have a header for that." Like, you can do an Accepts MIME type header to say, "This accepts HTML. This accepts Markdown." Like, w- that exists. Like, you don't need to invent some new technology for that. Like, we can do that. [00:30:18]
-
-**Mark Erikson:** Okay, there's a comment in chat that says, "I do not understand what Remix 3 is." [00:30:33]
-
-Fair. Let me try to recap where we are. Remix 1 and 2 were full-stack frameworks u- that used React. They mostly introduced things like using loader functions for data fetching. But they were, they were full-stack mostly in the sense of there is a server piece included. Remix 3 is a completely new and different framework that just happens to use the same package name And it is a very different way of writing your components. [00:30:37]
-
-They also include a whole lot more stuff on the server. The blog post says they include routes, request handlers, responses, middleware, sessions, auth, forms, uploads, assets, data, database, UI components, theming, network, and tests. So in terms of what they provide, they're trying to provide a lot more out of the box. [00:31:12]
-
-In terms of the client side code, this is not React. This is a brand new framework on the client side they have invented themselves. It looks a little bit like React in some ways. There's JSX syntax. But the logic and behavior are very different. For example, instead of a useState hook, you just declare a variable in scope, inside a closure, reassign to that variable, and then you call an update method, which is what actually triggers the re-render. [00:31:32]
-
-So whereas in React, if you call setState, that both says, "Here's the new value," and tells React to re-render, whereas in Remix, you could say variable one equals A, variable two equals B, and then you call an update function to explicitly trigger it. They also have a bunch of things for mixing in behavior, like event handling and styles and things like that. [00:32:07]
-
-There's inspiration from React. There's inspiration from earlier libraries like Backbone. It, it is a very React and yet non-React-based framework. [00:32:34]
-
-**Carl Vitullo:** And I'm looking at this, you know, in this Remix III beta preview blog post, I'm looking at this small example copy to clipboard component that they show. And yeah, so Mix is what stood out to me here. [00:32:46]
-
-There's, you know, a button and it's got, like, some ARIA stuff, 'cause buttons are, need to be accessible. And then instead of, like, style or, like, class name or, you know, onClick, on, you know, handlers, n- the rest of the props basically that I would expect for a, you know, a button component to have, it has this Mix attribute which, you know, uses the same JSX, like, you know, curly braces. [00:32:58]
-
-Then the value is an array which has button.secondaryStyle and an on function which is being given, you know, onClick with a clickHandler async function here. That's interesting. So it's like, I guess, it's sort of React, but with manual updates instead of updating by reference, and it's got, like, this pseudo-functional composition style for arguments. [00:33:22]
-
-But, like, weirdly, it seems to be mixing styling and b- behavior in this Mix attribute, 'cause it's both applying the secondary button style and an onClick handler as composed mixins, I guess. So that's, I don't know. Sure, that's an opinion you can have. That's, seems fine, but it's strange. [00:33:49]
-
-**Mark Erikson:** All that to say that they've been talking for a while about how they're trying to do their own thing, and they are clearly doing their own thing. [00:34:07]
-
-And I have no idea how much adoption this will get, but can sort of squint and see some of the inspirations. [00:34:15]
-
-**Carl Vitullo:** Yeah, and somebody in chat just brought out React Router Framework, and it's like, oh yeah, they did that too. [00:34:22]
-
-**Mark Erikson:** Brian and Michael have had a lot of ideas over the last decade. [00:34:26]
-
-**Carl Vitullo:** Yeah. Boy, boy howdy, have they. [00:34:29]
-
-I guess, uh, a thing I wanna bring in, speaking about over the last decade, so a decade ago is 2016. I remember in, like, 2012, I read a blog post from Basecamp talking about how they built their UI, and it was basically componentized HTML being cached aggressively and recursively sent over the wire. And, uh, as I have been watching React evolve, it's like, oh, we're basically evol- you know, uh, progressing towards the same thing. [00:34:31]
-
-It's, you know... This f- this remix description of, like, and- advanced functions and like, you know, it's got frames, which are server-rendered HTML that you can, like, slot into your client code. And it's like, man, just, like, the number of times that I see something that, like, viscerally remind me of this thing I read in, like, like literally 15 years ago at this point, talking about sending componentized HTML over the wire in a efficient manner. [00:34:59]
-
-It's like, wow, we're still trying to do that out, uh, generally. Like, we-- I feel like that's the tension. It's not that hard to do as a one-off, but it's really hard to do with effective semantics that let you author that type of experience in a generic framework or library. So we're just still chasing that high, I guess. [00:35:26]
-
-So I don't know. That's where we're at. That's how I'm conceptualizing this Remix 3. And I, I also think of, like, Remix, you know, 'cause, like, Remix is, like, backed by Shopify and, you know, Michael and Ryan, they feel like they're in alignment with the Basecamp folks. And so it's interesting to see these, this similar set of ideas explored by a set of folks that I consider to have a generally similar set of ideas about the world. But yeah. [00:35:46]
-
-## [TSRX](https://tsrx.dev/), a variant on JSX
-
-**Mark Erikson:** And on a very, very similar note, Dominic Ganaway is someone who has worked on multiple React frameworks. He originally built his own framework called Inferno. He was part of the actual React core team for a while. I believe he then went over and worked on some of Svelte 5, maybe. [00:36:11]
-
-Someone who has a lot of experience building these frameworks. He has been working on a new framework called Ripple, which we've mentioned a, a few months ago, and one of Ripple's potential innovations was essentially an improved version of JSX syntax, and Dominic has extracted that into its own package and compiler layer called TSRX. [00:36:29]
-
-So JSX has an actual specification. It's out there. It's in a repo. It's documented. It also has not changed in a decade, and part of that is because it's embedded. There's lots of different tools that know how to parse JSX correctly and do the transformations. Trying to push through any changes to the JSX specification would be hard at this point. [00:36:56]
-
-Like, I would desperately love to have what's known as prop hunting, where, say I wanna pass my variable as a prop named My Variable. Why should I have to write My Variable equals curly braces My Variable every time? Like, that's silly. But the problem is the JSX spec says if you pass a variable name with nothing else, well, HTML treats that as a Boolean, so JSX is gonna treat that as a Boolean too. [00:37:21]
-
-And it's like, but it would be so much nicer if I didn't have to repeat myself. Can't we improve the specification? And at this point, it's not gonna happen. So Dominic has gone in and created essentially a bigger, better JSX-like language that is specifically meant for writing components in a template-ish, JavaScript-ish, TypeScript-ish sort of way. [00:37:53]
-
-**Carl Vitullo:** Agreed on, like, you cannot-- Like, changing the spec of JSX right now, like, nobody expects the spec to change, which makes it harder to actually change. Like, you know, if it had been evolving, it would be easier to continue evolving, but we have inertia saying it's fixed. So it's just tough to evolve. I'm not sure if I love this as a, you know, new DSL. [00:38:21]
-
-I have been thinking about the value of DSLs in this, you know, agent- agentic AI era that we're, you know, that we find ourselves in now. And, like, so much-- I feel like there used to be a strong argument for not changing things because you have to do this, like, educational push afterwards. You have to do the developer relations of, like, "Here's how to use the new thing," and you have to, like, yada yada. [00:38:45]
-
-And that's different now that so much of the new code is being consumed by agents. It's not an educational cycle. It's not workshops and, you know, courses and talks and conferences. It's like you update the markdown. You update the docs that the AI is reading 'cause it's an amnesiac and you have to start from zero every time you give it something. [00:39:06]
-
-That's an interesting, like, unlock for changing some of these core assumptions. Like, yes, sure, it's embedded, it's deeply embedded into the training program. But like I've been pleasantly surprised by things that I expected to be challenging because it's not deeply embedded in the training data, or it, it runs counter to things that I know are deeply embedded in the training data, like wanting to do functional patterns instead of object-oriented. [00:39:27]
-
-Because, I mean, so much code is object-oriented and it's been trained on all of the existing code. I have to say, like something like TSRX, it seems interesting to me from that lens of like... So your thesis is that JSX has rough edges and foot guns that make it less effective, less intuitive, less comprehensible for its intended purpose. [00:39:53]
-
-**Mark Erikson:** Just make a whole new thing. [00:40:16]
-
-**Carl Vitullo:** Just make a new thing. Just shave those off and call it something else so that the tools you're using to author these implementation details don't get confused about what you're using. Or, you know, have lint rules, static, you know, tools available to ensure that what they've written is valid and g- intended. [00:40:17]
-
-Ah, that's interesting. That's cool. That's useful. I don't know. [00:40:33]
-
-**Mark Erikson:** And just looking at this code snippet, a few practical examples of how this is different from JSX. So you've got a component keyword instead of the function keyword. It is statement-based, so you can have like an if statement directly in there, and then you don't do like a return anywhere. [00:40:36]
-
-It's just like if condition, key tag In other words, it, like, if that's true, you insert the P tag, but you don't have a, like, a return statement anywhere in there. Uh, and then it's also got an embedded style section as well. Another interesting thing is that this is not actually tied to a framework directly. [00:40:54]
-
-There are packages that allow you to use this with React in Preact, Ripple, Solid, and View if you really wanted to. So you could, in theory, actually drop this into a real project right now if you really wanted to use it. Did you use it? Probably not, but it's a very interesting exploration. [00:41:16]
-
-**Carl Vitullo:** Yeah, definitely really interesting. [00:41:37]
-
-**Mark Erikson:** Okay. Well, we are already almost an hour in, and we still haven't touched the security thing. So Carl, great job moving that to the end. [00:41:39]
-
-**Carl Vitullo:** I knew it. [00:41:46]
-
-**Mark Erikson:** Who knew that we would have stuff to say about everything else first? [00:41:47]
-
-**Carl Vitullo:** What? You and I have opinions? [00:41:50]
-
-## Security! Everything is compromised
-
-**Carl Vitullo:** As fucking ever, there's been a bunch of security stuff going on. TanStack Router got, like, hardcore compromised. I think it was 40-some p- compromised packages. Basically, like, all of- [00:41:52]
-
-## [TanStack Router compromised](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem), and [Socket analysis](https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack)
-
-**Mark Erikson:** The entire TanStack Router set of packages was compromised. No other TanStack libraries were compromised. So, like, Query, Start. Or, well, Start because it includes Router, but, like, the actual damaged packages were all Router related. [00:42:04]
-
-Uh, and the, the way it worked was incredibly complicated. So s- essentially, someone opened up an ex- a, an external PR that in its own depend... Like, essentially changed the package dependencies to point to some compromised poisoned versions. TanStack's CI was set up to have a shared package cache so that their CI runs would go faster. [00:42:22]
-
-Someone opened up this PR, modified it a couple times, closed it, and in the process, their poisoned packages ended up in the package cache, so that the next time one of the TanStack maintainers actually did a real PR, the poisoned packages from the cache got installed, exfiltrated credentials, and then that allowed the attacker to then publish new versions of the TanStack packages with more malicious code inside. [00:42:49]
-
-Uh, it's actually much more complicated than that, but that's roughly what happened here. [00:43:21]
-
-**Carl Vitullo:** Yeah. It's... I, I wanna see if I can pull in a couple different details without blowing up the time we spent here. [00:43:26]
-
-But, like, so they, they fork it, they obscure that it is a fork by renaming it to s- you know, configuration, so you d- it's not easy to find. [00:43:30]
-
-They publish a commit with li- you know, a malicious payload, commit it with skip CI because they know that will suppress the CI from actually executing on this push. Then- Like open a PR, update the PR so that it appears empty, then close the PR. And in doing this, they have now poisoned the cache with their malicious payload so that the next time a legitimate CI run goes, it will pull in this malicious payload instead of the intended dependency code. [00:43:39]
-
-All from a fork, that was never run, that was never actually executed, never had CI run or merged or approved. The timeline for this is they open the PR, do multiple force pushes, and then close the PR in under a minute, and that's how they poison the cache, so the next time a legitimate person ran CI, their credentials were compromised. [00:44:15]
-
-Like, that's fucking crazy. [00:44:40]
-
-They m- compromised a bit of code, organizational policies by the, by TanStack, and complex GitHub Action configuration. And all of this was ultimately enabled by the use of a PR target in their GitHub Action that is like known to be unintuitive. [00:44:42]
-
-It's known to a- allow this type of attack. But like, ah, man, what a, th- like that's, that... What a reasonable thing to miss here. That's such a complicated set of th- steps to have to do to e- execute this. [00:45:01]
-
-**Mark Erikson:** I've done a decent amount of like GitHub Actions CI config over the years for Redux. I have no idea what I'm doing. [00:45:15]
-
-I don't like writing YAML as a way to do control flow. I'm not an expert on this stuff. I'm googling examples and copy-pasting, because I genuinely have no... Like I, I roughly know here's what I want to do. I don't know how to do it. So this stuff is so easy to mess up, and GitHub Actions is frankly a, it's very complicated and it's very badly implemented. [00:45:25]
-
-**Carl Vitullo:** And it's so hard to test. Yeah. It's impossible to test some things. Like literally in, in some cases the only way to trigger the actual workflow is to do it live. And like, like you said, I'm not an expert in this. You're not an expert in this. Like nobody, almost nobody, especially in open source, is an expert in GitHub Actions. [00:45:49]
-
-Like nobody's primary job is understanding GitHub Actions, but all of us have to write GitHub Actions because that's the way that you function in this world right now. So I don't know, it's oh man, what a rough state of affairs there. We all have to do this. Nobody's that good at it, and the experience of actually authoring it is- rough. [00:46:09]
-
-It's bad. Like, it's not good. [00:46:30]
-
-**Mark Erikson:** So the postmortem is fantastic, and just for the record, I've seen a lot of corporate post-moto-mortems that were nowhere near as good as this. So kudos to the TanStack team. I know Corbin and a bunch of the others were very involved in not only trying to deal with the actual fallout here, but, like, really, really professionally follow up on here's what happened and here's how we're fixing things. [00:46:32]
-
-## [TanStack followup with followup hardening](https://tanstack.com/blog/incident-followup)
-
-**Mark Erikson:** And so they, they also put up a follow-up post with the list of things they're doing to try to make sure that nothing like this ever happens again. Unfortunately, this did have a lot of downstream consequences. [00:46:58]
-
-## [Nx monorepo tool compromised](https://nx.dev/blog/nx-console-v18-95-0-postmortem) as a result
-
-**Mark Erikson:** So, uh, the Nx monorepo tool got compromised after that because someone from the Nx team installed one of the briefly live malicious versions of TanStack packages, and that led to some credentials getting exfiltrated, which led to a malicious version of an Nx VS Code extension getting installed. [00:47:10]
-
-And then GitHub reported that someone had accessed a bunch of internal repos, quote, "Because one of our employees used a, broke a malicious VS Code extension," and I think I saw some articles indicating that it might be the Nx Console possibly. So it's possible that there were multiple chained attacks downstream, all starting from the TanStack Router compromise. [00:47:39]
-
-**Carl Vitullo:** That's fucking wild. Yeah, so, you know, like, when people tell me about, like, the risks of introducing security vulnerabilities by hand-rolling your own little tool here or there, like, oh, I don't know, GitHub got compromised by this. This sequence of events to get to GitHub is compromised, oh my God, that's absolutely wild. [00:48:05]
-
-I don't know. People talk about threat models and, like, threat actors. Like, how do you defend against what type of threat actor? Like, this attack, to me, the level of complexity and success and, like, capitalization upon their success- Says nation state actor. Like this is world-class— [00:48:24]
-
-**Mark Erikson:** And to a certain extent, like it's not even worth trying to defend against someone who's that good. When they want to find a way in, they will find a way in. [00:48:41]
-
-**Carl Vitullo:** Right. Meaningfully, in order to effectively defend against these... You know, if you think about it as like y- your available attention, you have 100% available attention, and, you know, there's that r- team, that malicious actor, 100% of their attention is on breaking you. [00:48:49]
-
-If you are not as skilled as them and dedicating the same amount of effort to countering their actions, like you can't beat them. They will overwhelm you given enough time. So like that's the complicated thing about security. You know, it's like in physical security they talk about like there is no such thing as a perfectly secure lock. A line that I'm aware of is physical access precludes all security. Like if you're doing computer security things and you are sitting in front of the machine literally [00:49:07]
-
-**Mark Erikson:** Sooner or later you will find a way in. [00:49:37]
-
-**Carl Vitullo:** It is not possible to provide security guarantees there. Yeah, you know, like if you're trying to lock down your data, if they're sitting in front of the machine, they can just blast your RAM with freezing agent so that it powers off but still holds the bit pattern physically on the chip, and then you can recover it from there. [00:49:39]
-
-I remember reading, uh, you know, proof of concept in an academic lab. Somebody had successfully exfiltrated data from a computer by using a high-sensitivity microphone from across the room and extracting the, like, buzzing pattern, the audible noise of the processor as it executed instructions. [00:49:57]
-
-Like, by listening to the processor, they were able to exfiltrate data. Like, the bar for perfect security is so high, it's incredible. Anyway, that's the last thing I'll say there. [00:50:19]
-
-Like it... So I don't know, just like when w- as you're thinking about responding to and defending against security threats, I think that's a really important context here, is that if your counterparty, if the malicious actor you're defending against is a hacking team that has been working for 25 years with the backing of a nation state national defense resources, like, sorry, you're not gonna beat them. [00:50:30]
-
-That's-- You're not an effective counter to that. Like, it's not gonna happen. So I don't know. That's an important caveat that I think all security conversations need to have is it's fucking hard. It's grim. [00:50:54]
-
-**Mark Erikson:** And then there's a, a couple more examples that I, I believe aren't even tied to the TanStack one. So Vercel got compromised, and that one appeared to be a sort of similar thing, where, like, one person was using an external tool, in this case called Context.ai. [00:51:06]
-
-That tool got compromised, and then they were able to roll through, pick up tokens, and get into Vercel's interior. And then the same people who have been doing this mini Shai-Hulud set of viruses and attacks have actually been hitting a bunch of different packages across multiple different languages and ecosystems. [00:51:26]
-
-So I mean, this, this is not like the proverbial guy in his basement. This is a bunch of very determined and sophisticated attackers. [00:51:49]
-
-Three last lit-- um, quick little bits on React-related things. [00:51:58]
-
-## React2Shell recaps from [Lachlan Davidson](https://lachlan.nz/blog/the-react2shell-story/) and [Sylvie](https://sylvie.fyi/posts/react2shell/)
-
-**Mark Erikson:** So we had the entire React to Shell vulnerability a few months ago. [00:52:02]
-
-The people who actually discovered that put up a couple of articles describing-- Like, the two primary individuals described their experience of what were they investigating, what was their process, what happened between when they found it and when it got publicly disclosed. [00:52:07]
-
-## [Next 16.2.5 and more React CVEs](https://github.com/vercel/next.js/releases/tag/v16.2.5)
-
-**Mark Erikson:** And then adjacent to that, Vercel put out a new release that appears to fix a number of new vulnerabilities and CVEs. And I know I s- w-when I saw this a couple weeks ago, I don't feel like I saw an actual blog post that accompanied this, which I found a little surprising. Maybe I just wasn't looking in the right spot, and I haven't gone back to look. But it seemed as though there were a number of new, like, denial-of-service and some authentication bypass issues found in b- in both Next and possibly Server Components again Okay. [00:52:25]
-
-One last set of things that are adjacent to this, and that's with the package publishing [00:52:59]
-
-**Carl Vitullo:** I like this 'cause it's, like, actionable. Here's things you can do to make your packages more secure. [00:53:05]
-
-**Mark Erikson:** This is aimed more at people like me who are maintaining packages rather than people who are developing applications, but hopefully this is something that will benefit all of us. [00:53:10]
-
-## [NPM adds “staged packages”](https://docs.npmjs.com/staged-publishing) and [E18E adds guidance](https://e18e.dev/docs/publishing.html#staged-packages)
-
-**Mark Erikson:** So first off, npm is adding a new concept called staged publishing. Right now, when you publish, the package goes live immediately. And so the way I understand this is once you have this set up for your packages, every new attempt to publish goes into a holding area, and then you explicitly have to go in and say, "Yes, I approve this for actually, actually, actually being released." [00:53:19]
-
-And I've, I've already seen Jovi de Crook, who works on Preact, trying to p- put together a tool that would be able to inspect package releases that are staged so that you can see what's inside them and what's changed. No idea how that works, but I c- I can see how that's been useful. So this would help for cases like the TanStack compromise because the m- modified, malicious, published versions of the package would never have gone fully live. [00:53:48]
-
-They would've gone to the staging area, and then the TanStack team would've been able to see them and say, "Wait, no, we, we didn't intend to publish those. Those should not go out." And then on the consumer side of things, so all the different package m- managers now have some kind of an option for don't install packages until they are at least N days old. [00:54:20]
-
-And they all have a different name and a different set of options for that field, but that's, that's the same concept. [00:54:44]
-
-## [PNPM 11 defaults to min release age](https://socket.dev/blog/pnpm-11-adds-new-supply-chain-protection-defaults), NPM 12 will [block by default](https://github.com/npm/rfcs/pull/868)
-
-**Mark Erikson:** So I believe pnpm 11 is defaulting to turn on that option to at least a couple days. Meanwhile, the other problem here is that packages have the post-install script, which is essentially when your package manager downloads this package and puts it in node modules, it can then run any random script that the package says it should run. [00:54:50]
-
-And that's bad because that's code that's running on your machine under your privileges and you have no idea what's happened, and it's just there because the package manager installed it. [00:55:13]
-
-**Carl Vitullo:** It's literally remote code execution. Like, yeah. [00:55:22]
-
-**Mark Erikson:** Yeah. And traditionally this has been used for things like, okay, let's figure out what operating system you have so we can download the proper native binary or build the native binary from scratch. [00:55:25]
-
-And there's alternative other better ways to do that today. So pnpm has already been denying the ability to run post-install scripts for a while. And finally, npm appears to actually be making the same change. So it looks like they're gonna start warning about package scripts that have a post-install option in the version 11 series, and npm command l- and tool version 12 will start denying those by default. [00:55:38]
-
-So we are trying to close up some of the outstanding holes in the ecosystem. So trying to make publishing packages safer, trying to make installing packages safer. [00:56:08]
-
-**Carl Vitullo:** I will say, okay, if we're talking about voluntary remote code execution, you know, where blocking post-install is a good thing to do because it's against best practice, the other- Top of mind, similar instance where we are casually expected to fetch code over the network and run it is curl piped into bash as an install tactic for things. [00:56:19]
-
-And like literally my entire career, people-- I have heard people talk about, "This is awful. We should not be doing this." Like, there are certain tools that will... I, I can't name, I can't think of any off the top of my head, but I do feel like I remember encountering this. There used to be tools that would ask you to, like, curl and then pipe it into, like, \`sudo bash\`, and, like, that's literally root access to your entire machine with arbit- code that you're not even inspecting from the network. [00:56:45]
-
-And you know who still asks you to curl pipe into bash as the recommended install method? Claude Code. Like, you go to claude.com f- and the Claude Code thing, front and center, "Built for hackers. Get Claude Code. Curl, pipe, bash." Like, that is remote code execution. Don't do it. Use a package manager. If your work is recommending that people curl and pipe into bash, advise that you respectfully and through proper channels raise the issue that That's wildly insecure. [00:57:10]
-
-It encourages remote code execution as a thing that developers will casually do. And when you casually do something like remote code execution, you end up with security vulnerabilities, like the types that we've been getting over the past year. So, ah, makes me annoyed. [00:57:42]
-
-**Mark Erikson:** And then, uh, last item. [00:57:57]
-
-## [Review your GH Actions, people!](https://github.com/e18e/ecosystem-issues/issues/266)
-
-**Mark Erikson:** So I, I, I mentioned earlier, I am not an expert on GitHub Actions. And after seeing all this stuff happen with TanStack, I, I was like, "We probably oughta do some looking at, like, the Redux actions," but I, I have no idea to what, what to even look for. The good news is that there's a number of people already working on scripts and AI prompts and other things to go inspect GitHub Actions. [00:57:59]
-
-And it's, in fact, Francois Best, who's ma- the maintainer of the Nuxt URL State library, was actually working on one himself and was asking for repos to run it on, and I, I volunteered to have him run it on the Redux repos. And it gave me a bunch of things to go correct. Like, nothing major high security, but a number of things we could do, like making sure that all the actions were pinned to a hash, changing some of the permissions options. [00:58:22]
-
-So there's a thread over in the E18E repo where they're collecting some different tools that can do scanning of GitHub Actions and try to work on hardening. And it kind of sucks that this is yet another thing that we gotta fix and we gotta make right, but guess what? It's good. You gotta fix it. [00:58:47]
-
-**Carl Vitullo:** One more thing we gotta fix. [00:59:06]
-
-That's just the rest of our existence forever. The debugging never stops. [00:59:07]
-
-**Mark Erikson:** Yeah. Okay. [00:59:12]
-
-## Mark posted his big AI blog posts. [Part 1: Fears and Journey](https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-1-fears-opinions-journey/)
-
-**Carl Vitullo:** You published your posts. [00:59:13]
-
-**Mark Erikson:** Yes, I did. So I, I hinted at this, um, a, a month ago. Long story short, little over a year ago, I was firmly against ever using AI- Yeah ... for writing code, and I was having a bit of a mental crisis over what AI is doing to the software industry and how this would affect the industry as a whole and myself personally. I ended up trying to use AI- Found it was actually useful, and now I actually end up using AI to write all my code. [00:59:15]
-
-And this has been a very long, very personal, very emotional journey for me. And I've actually now spent a lot of time configuring my own personal open code agent workflow setup, and I have a, I now have opinions on both how I set things up and the results that I'm getting. Just like I, I have act- I actually have experience now, and I, I have some preferences. [00:59:47]
-
-Also, I didn't wanna get pulled into people yelling at me for having chosen to use AI. But when I was in Miami last month, I was talking with some folks, and some of those conversations literally turned into, "Mark, what tools are you using?" And I would describe it and people were like literally taking notes, acting like I actually know what I'm talking about, which is hilarious. [01:00:13]
-
-And I'm like, "Okay, okay, fine. I've, I have been convinced to write a blog post about my own personal AI agent setup." And my brain would not let me write the technical blog post until I had written the personal experience blog post. [01:00:34]
-
-And I sat down and I wrote 12,000 words in eight hours with a brief stop for supper. And then I wrote another 3,000 words on the flight home the next day. [01:00:51]
-
-**Carl Vitullo:** I may have run that through a word count already. I can verify those numbers. [01:01:01]
-
-**Mark Erikson:** I, I... This is very different from most of my blog posts. Most of my blog posts are, "Here is a concept that I've become an expert on, let me explain this, unpack the pieces, describe how things work, and I will cite dozens of sources as references." [01:01:05]
-
-This post is none of that. This post is, "Here is my experience, my brain, my feelings, my journey." I am not trying to convince anyone. I am not trying to tell people, "This is how you should do things." this is me and my experience. [01:01:22]
-
-And I did not write this for clicks. I did not write this to, you know, change the conversation or get a bunch of views. But I've also already read hundreds of people's posts where they say, you know, I- like, "AI is killing the craft of being a programmer, and I mourn the loss of that." and that was, it, I mean, that was a really big influence on how I was feeling over the last year. So there you go. [01:01:40]
-
-There's a 15,000-word post that goes deep, deep inside my brain and my experiences and how my thought processes changed over time, and then it's got an awful lot of my opinions on where are we as an industry. And then I wrote another 6,000 words about my actual technical setup. [01:02:08]
-
-**Carl Vitullo:** Real Casual, 21,000 words. At an estimated 500 words per page, that is just about 41 pages. [01:02:27]
-
-**Mark Erikson:** People keep asking me to write books, and I'm like, "I don't write books, but I, I write the equivalent of books on my blog." [01:02:33]
-
-**Carl Vitullo:** Right. Right, right. Cool. Love that. How much of both do you think you got into the previous episode we did? [01:02:39]
-
-**Mark Erikson:** Bits and pieces. I, I don't r- Wait, you're asking me to remember what I said a month ago before my vacation? Come on. I, I talked about bits and pieces, but this went into a lot more detail. The biggest things are, like, beyond I use OpenCode, I use Opus, I use these MCP tools, et cetera, is that I've very explicitly chosen to stay very hands-on, conversational, and me driving what the agent is about to change, rather than spawning up a bunch of agents in the background to go do work and I don't care what it looks like. [01:02:45]
-
-I have seen a lot of other posts and discussion, even just in the last few weeks, with a number of people echoing similar thoughts of, "Yeah, actually, maybe we need to kind of back off and keep things at a human comprehensible amount of effort." [01:03:16]
-
-**Carl Vitullo:** Preposterous. [01:03:30]
-
-I'm kind of frustrated. I don't know. I, I feel like I'm meaningfully following the edge of the state-of-the-art in agentic development. I built a harness for myself that does some really cool... Like, three months ago, I had a harness in place that was, like, keeping track of memories and doing a dream cycle and playing a game and writing its own code. Like, writing hundreds of lines of Python so that it could more effectively play this game, and it was doing a good job. It was actually pretty interesting. [01:03:31]
-
-And I kind of shut it down 'cause, well, now, it, it, it was using \`claude -p\` to do everything- Mm ... and I realized, like, I kept working on it and I kept iterating it and I realized like, oh, you know what? Like, Claude is already doing a lot of this stuff. Claude Code is this agent. So what is, what does the orchestrator on top of the agent need to do? [01:03:59]
-
-And I have an interesting, I have a really interesting body of work that's on my GitHub that is not currently being put to use anywhere, but it's like, damn it, I'm currently at the edge of the agentic whatever stuff, but I'm doing other things that are more personally interesting to me. And, man, I want... [01:04:18]
-
-I, I have this project in place that I feel like is on par with stuff that I'm seeing people fundraise for from VC and I'm like, "Hmm, I don't wanna do that, but I do want money." So anyway, there's my, uh, there's my personal opinions around some AI stuff. I don't know. [01:04:36]
-
-I'm g- I'm gonna have to find out... We're gonna have to talk more about AI and agents and whatever, 'cause I don't know, it's crazy. [01:04:53]
-
-**Mark Erikson:** So, I don't know, adjacent thought. Like I'm, I'm, I'm in sort of a weird spot at the moment because I just got back from a combination conference plus two weeks of vacation plus conference trip. At my day job I've... [01:05:00]
-
-Prior to that, I was writing MCP tools and then playing product manager and doing product and positioning stuff, and then helping try to figure out like demos and product direction. I'm back for a couple days. I've got more conferences coming up. I've actually done very little Redux maintenance work this year, and I feel kind of bad about it, but it's 'cause a lot of my time and effort have gone into, you know, replay day job stuff. [01:05:12]
-
-I was trying to play with some of my like React Redux plus signals experiments on the way back home, and so I'm kind of getting some of that back into my brain. There's a lot of things I would like to sit down and spend time on, but I've just been running around so much and everything feels very scattered, and I don't feel like I'm focusing at the moment. [01:05:39]
-
-So I've got a couple more conferences. I've got a c- bunch of travel coming up. I don't know. Maybe I will manage to find time to actually sit down and focus on some things. [01:06:01]
-
-**Carl Vitullo:** As if. Cool. Well, I hope you do find so- some of that time. But I, I just know in my own self, any time I'm like, "Maybe I'll find time to do that thing that I want to do now," it's like, "Nah, probably not." [01:06:09]
-
-Gotta make time. Can never find time, have to make it. [01:06:21]
-
-**Mark Erikson:** I, I, I actually saw a post from Addy Osmani on Twitter just, uh, just this morning. A- Addy has written a number of really good posts lately about, you know, using agents and orchestration and, and agent anti-patterns and other things. Fine, I will, I will actually go look on Twitter and find the post rather than just describing it. [01:06:24]
-
-Uh, here, oh, here we go. It's the first thing in the history. Wonderful. Uh, this one's called, this one's called The Orchestration Tax, and the key line that stuck out for me for this one was, "Human attention is now the limiting factor. It is the single-threaded lock that you need to be aware of." And so how do you pick what is the most relevant and important thing to be spending your time on versus your agent's, blah, blah, blah, blah, blah, blah, blah? [01:06:43]
-
-**Carl Vitullo:** Right, right. The agents are good at a lot of things, but they are not good at building the right thing. You have to get them to do the right thing. That's definitely been my experience as well. I've definitely experienced the, "I can do everything. Throw 15 agents." Uh, and then you review the work and try and actually make use of it, and it's like, oh, this is making a lot of very basic assumptions that are not the assumptions I have. [01:07:10]
-
-Which I, I... One thing to say, the closer your assumptions are to the basic assumptions, the better it works in some ways. So the less creative you're being, the more effective they are. Or the more, like, s- effective they are at doing their own thing. I don't know. That, that probably says something about, I don't know, scale. [01:07:35]
-
-**Mark Erikson:** Yeah. I mean, that, that basically goes back to why I personally have chosen a workflow that is essentially just me augmented, rather than me spinning off a bunch of agents. [01:07:53]
-
-**Carl Vitullo:** True. That's why I shut my harness down and haven't had it doing stuff, is partly, largely because I haven't figured out how to put myself in the loop of their work in a way that is effective. [01:08:05]
-
-Uh, I, I had them running for, like, a day or two, and they, they did work. A lot of it was useful work, but they also did some work two or three times and left, like, page-and-a-half comments three different times on the same PR. And it's like, oh, okay, this is... The usefulness to noise ratio of this is not where I want it to be. [01:08:16]
-
-Let me revise this. And I have not revised it, because that's something I'm trying to find time for, and I cannot find any time anywhere. [01:08:33]
-
-## Outro
-
-**Mark Erikson:** All right. Well, I think we've about covered things today, and then some. [01:08:39]
-
-**Carl Vitullo:** Yep. That's pretty good. Thank you so much. [01:08:44]
-
-**Mark Erikson:** We had a number of people sticking around, which is great. [01:08:46]
-
-**Carl Vitullo:** Yeah. That's really nice. I like that I put a title in the kickoff thing this time around, and we actually had people show up. So it turns out, if you, like, care about communicating with people, sometimes people actually read and respond. What? Community building? You have to show up authentically? Ah, damn. I hate that. [01:08:48]
-
-Cool. Thank you so much for joining us, y'all in the audience who are still here 90 minutes after we started. That's awesome. Thank you, Mark, for putting together this resource on short notice. And yeah, thanks for everyone who's listening to this on the recording, uh, when I publish it in probably longer than I intend it to be. [01:09:05]
-
-Yeah. Thanks so much. We are going to be revising exactly what this podcast is, but it is useful and good, so, uh, it, it will be sticking around in some sort. If this is a resource that you find valuable and wanna help support, give us a review. Send us to a friend. Put us in the random channel of your work Slack. [01:09:22]
-
-Generally, like, I suck at marketing, I suck at distribution, so if you can help me get this in front of somebody who has never heard of it before, that is the single most helpful thing you can do. Or, I don't know, just send it to someone anyway, even if you don't care. Please, help. Yeah. Thank you so much. [01:09:40]
-
-See you next month. [01:09:55]
-
-**Mark Erikson:** Thanks. Bye. [01:09:56]
diff --git a/src/transcripts/tmir-2026-06.md b/src/transcripts/tmir-2026-06.md
deleted file mode 100644
index a99a105..0000000
--- a/src/transcripts/tmir-2026-06.md
+++ /dev/null
@@ -1,541 +0,0 @@
----
-title: "TMiR 2026-06: React Compiler is getting rusty, what does AI mean for engineering culture"
-date: 2026-06-24
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we discuss the React Compiler being rewritten in Rust, what AI development means for engineering culture, "
-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:14](#intros)] Intros
-- [[00:02:31](#new-releases)] New releases
- - [[00:02:34](#react-router-8)] [React Router 8](https://remix.run/blog/react-router-v8)
- - [[00:05:39](#babel-8)] [Babel 8](https://babeljs.io/blog/2026/06/16/8.0.0/)
- - [[00:07:15](#astro-7)] [Astro 7](https://astro.build/blog/astro-7/)
- - [[00:09:13](#ts-70-rc)] [TS 7.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)
- - [[00:09:42](#esm-only-no-programmatic-api-right-now)] ESM only, no programmatic API right now
- - [[00:10:41](#nub-js-from-zod-creator)] [Nub JS](https://nubjs.com/), from Zod creator
- - [[00:14:13](#legend-list-30-with-dom-support)] [Legend List 3.0 with DOM support](https://x.com/jmeistrich/status/2059922504320225316)
- - [[00:14:44](#tsrx-revamped-the-syntax)] [TSRX revamped the syntax](https://tsrx.dev/blog/rethinking-tsrx)
-- [[00:16:28](#react-core-news)] React Core news
- - [[00:16:32](#react-compiler-in-rust-is-rolling-out)] [React Compiler in Rust is rolling out](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x)
- - [[00:16:57](#pr-was-merged-after-testing-at-meta-and-improved)] [PR was merged after testing at Meta and improved](https://github.com/react/react/pull/36173#issuecomment-4608356402)
- - [[00:17:35](#oxlint-swc-rspack-next-all-integrating)] [Oxlint, SWC, RSPack, Next all integrating](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x%20)
- - [[00:17:50](#rolldown-tried-integrating-directly-but-removed-due-to-binary-size-increase)] [Rolldown tried integrating directly but removed due to binary size increase](https://x.com/evanyou/status/2069593612153987373)
- - [[00:18:18](#bun-tried-optimizing-the-rust-compiler-code)] [Bun tried optimizing the Rust Compiler code](https://gist.github.com/Jarred-Sumner/84df369c35216f40d61d1ea9f95771c2)
- - [[00:18:57](#other-core-improvements)] Other core improvements
- - [[00:19:17](#fragment-refs-have-been-documented-in-canary)] [Fragment Refs have been documented](https://react.dev/reference/react/Fragment#fragmentinstance) in canary
- - [[00:21:42](#react-devtools-mcp-tools-including-component-tree-and-perf-analysis-apis)] React DevTools MCP tools, including [component tree](https://github.com/react/react/pull/36597) and [perf analysis](https://github.com/react/react/pull/36598) APIs
- - [[00:22:28](#react-foundation-progress)] React Foundation progress
- - [[00:22:39](#theres-an-early-reactfoundation-website-advertising-funding-for-maintainers-and-community-groups)] There’s a(n early) [react.foundation](https://react.foundation/) website, advertising funding for maintainers and community groups
- - [[00:25:41](#theyre-gonna-have-a-booth-at-chain-react-at-the-end-of-july-)] They’re gonna have a booth at [Chain React at the end of July](https://chainreactconf.com/)
-- [[00:26:11](#why-is-meta-destroying-its-engineering-organization)] [Why is Meta destroying its engineering organization?](https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering)
-- [[00:32:46](#ai-demands-more-engineering-discipline-not-less-)] [AI demands more engineering discipline. Not less](https://charitydotwtf.substack.com/p/ai-demands-more-engineering-discipline)
-- [[00:40:51](#christoph-nakazawa-posted-his-modern-engineering-values-and-how-he-uses-ai)] Christoph Nakazawa posted his [“Modern Engineering Values” and how he uses AI](https://cpojer.net/posts/modern-engineering-values)
-- [[00:42:42](#cloudflare-bought-voidzero-)] [Cloudflare bought VoidZero](https://voidzero.dev/posts/voidzero-cloudflare)
-- [[00:43:44](#npm-security-updates)] NPM / security updates
- - [[00:43:48](#github-actions-allows-enforcing-pinned-action-shas)] [Github Actions allows enforcing pinned action SHAs](https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/)
- - [[00:44:21](#github-actions-has-a-package-manager-and-it-might-be-the-worst)] [GitHub Actions Has a Package Manager, and It Might Be the Worst](https://nesbitt.io/2025/12/06/github-actions-package-manager.html)
- - [[00:45:27](#npm-12-will-disable-install-scripts-and-git-deps-by-default)] [NPM 12 will disable install scripts and Git deps by default](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
-- [[00:46:25](#code-optimization-still-matters)] Code optimization still matters!
- - [[00:46:53](#tanstack-table-cut-memory-in-v9-by-90-on-large-lists-by-optimizing-js-objects-and-optimized-ts-perf)] [TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects](https://tanstack.com/blog/tanstack-table-v9-memory-performance) and [optimized TS perf](https://tanstack.com/blog/tanstack-table-v9-typescript-performance)
- - [[00:47:25](#pierre-diffs-was-significantly-optimized---has-to-handle-virtualization-syntax-highlighting-source-loading)] [Pierre Diffs was significantly optimized](https://pierre.computer/writing/on-rendering-diffs) - has to handle virtualization, syntax highlighting, source loading
- - [[00:48:38](#compilecat-is-a-new-optimizing-compiler-to-improve-js-execution-after-bundling-similar-to-closure-compiler-the-rspack-team-says-theyre-working-on-something-similar-)] [CompileCat is a new optimizing compiler to improve JS execution after bundling](https://github.com/isaac-mason/compilecat), similar to Closure Compiler. ([the RSPack team says they’re working on something similar](https://x.com/jiahan_c/status/2065630866668453898) )
- - [[00:51:22](#marks-react-redux-signals-draft-perf-pr-and-updated-react-redux-benchmarks-repo)] [Mark’s React-Redux \\\+ signals draft perf PR](https://github.com/reduxjs/react-redux/pull/2318) and [updated React-Redux benchmarks repo](https://github.com/reduxjs/react-redux-benchmarks)
-- [[00:52:51](#aurora-scharffs-preferred-rsc-component-architecture)] [Aurora Scharff’s preferred RSC component architecture](https://aurorascharff.no/posts/component-architecture-for-react-server-components/)
-- [[00:53:34](#lovable-projects-now-use-tanstack-start-by-default)] [Lovable projects now use TanStack Start by default](https://lovable.dev/blog/building-apps-using-tanstack-start)
-
-# This Month in React: June News Roundup
-
-**Carl:** All right. Hello. Thank you for joining us for the June edition of This Month in React. We're coming to you live from Reactiflux, the best place for professional developers using React. [00:00:05]
-
-## Intros
-
-**Carl:** I am Carl. I'm a staff product developer and freelance community leader here at, Reactiflux, where I do things like build Euno, a moderation bot that helps us keep the community operating. [00:00:14]
-
-**Mark:** I'm Mark Erikson. My day job is at Replay.io where we use time travel debugging to build things like automated QA tools and awesome React analysis. And outside of that, I run around at conferences, give talks, and work on Redux [00:00:27]
-
-**Carl:** Heck yeah. The big news that we wanna discuss this month, is around some changes that shipped for the React compiler. it's in Rust now. There you go. It's the news. You don't have to listen. Yeah. we're gonna talk about Meta and we're gonna talk about its engineering culture, b- framed around a blog post from Gergely Orosz, who is wonderful and a great writer. yeah. Talk a little bit more about AI, 'cause of course we are, and some broad best practices and stuff. [00:00:41]
-
-**Carl (editing):** And I'm trying something we haven't done before today. I'm gonna self-sponsor this 'cause we don't have anyone else paying our bills right now. [00:01:05]
-
-Uh, we are sponsored by Euno, a moderator support tool for Discord, offering one-click setup for spam defense, moderation audit logs, and decision-making tools. That's euno.reactiflux.com, E-U-N-O.reactiflux.com. Uh, Euno is named after the goddess of good order and lawful governance. Uh, it helps moderators make decisions about bans together while automatically filtering out compromised account spam. A single setup/command gets you anonymous user reports, shared moderation history and resolution voting, a private ticketing channel, and anti-spam based on message velocity. [00:01:10]
-
-With a 90-day trial, you can get a feel for it before deciding if $100 per year is worth the time you'll save banning spammers and deleting garbage. If you have a Discord server, give it a shot and let me know. That's euno.reactiflux.com, E-U-N-O.react iflux.com. [00:01:43]
-
-**Mark:** Yep. congrats to you, Carl. Thank you for all the work you've put in on this, and I can, vouch that this has been very thoroughly tested on our end [00:01:59]
-
-**Carl (editing):** We're also sponsored by me, Carl. Uh, these episodes cost me about 300 bucks out of pocket each episode, uh, for editing and supporting tools. If you'd like to learn more about anything Mark and I discuss, let's talk about consulting or a contract software engineering gig. [00:02:06]
-
-You probably know where to find me, but Discord or email is the most reliable. I'm at vcarl, that's Victor Charlie Alpha Romeo Lima, @reactiflux.com. Let me know [00:02:21]
-
-## New releases
-
-**Carl:** But yeah, first the new releases. [00:02:32]
-
-## [React Router 8](https://remix.run/blog/react-router-v8)
-
-**Carl:** First up, React Router v8 shipped. We got that now. yeah. This... they talk a lot about the early days of React Router, and it... [00:02:34]
-
-they're, like, proactively trying to manage the pain that people experience because, I... React Router got a reputation for shipping a lot of breaking changes with every new release. I guess specifically they got a reputation of flip-flopping back and forth between two different paradigms, like every other release, and it just frustrated a lot of people with, "Why do we have to refactor again?" So it's funny how much of this blog post is dedicated to saying, "We're not doing that anymore, we swear. Please don't hate us." [00:02:43]
-
-But yeah, generally it looks like this is essentially a no-op versus the latest version of v7. if you are already using the latest version of seven with no, deprecated features, it... [00:03:09]
-
-This should be a drop-in replacement. yeah, I think this, As far as I know, the mo- most of what th- this is bringing out is, emphasis on the framework mode. [00:03:22]
-
-**Mark:** I know that they've done a lot of work on trying to use feature flags to make new features available, essentially following the, majors don't introduce new stuff, they just remove old stuff kind of a [00:03:31]
-
-**Carl:** pattern. [00:03:42]
-
-And see, so the feature flags are the way that they implemented the better, major version releases. So th- now by the time, by the end of the previous major version release, they will have introduced new feature flags for everything that they are about to release in the next breaking change. [00:03:44]
-
-which is, it's really smart. I actually really admire that method of changing. managing feature flags, I have experienced, adds a lot of complexity to day-to-day development. and I have a ton of respect for them for landing on this process for releasing new changes, new features, new abilities to their widely used library, and here they are still, eight years later after they started using this, still putting it to practice. [00:04:01]
-
-**Mark:** Couple interesting notes from the support matrix here. Node 22, okay, that's fine. they now require at least React 19.2 [00:04:25]
-
-**Carl:** as [00:04:37]
-
-**Mark:** a minimum version, so that... I, don't know if version 7 expected 19.0 or 18, I would have to check. But just noting that React Router now requires the latest and greatest React 19. [00:04:38]
-
-And also the package is shipping as ESM only, we are very clearly now on the trend of lots of tools and libraries going ESM only. there was the early wave of tools that went ESM only and everyone else complained because it didn't work right. [00:04:50]
-
-And now with, some of the improvements to Node itself, we're seeing a lot of packages say now is the time to go ESM only [00:05:07]
-
-**Carl:** Yeah, we've got another release that went ESM only next. [00:05:16]
-
-I wanna flag, I just found... I was clicking through the blog post and they have a link to their governance document, which explains their new feature process. and actually this whole document is very well thought out and I would highly recommend that you familiarize yourself with this governance document, 'cause, it's just a bunch of really high quality engineering practices. [00:05:21]
-
-Definitely check it out. [00:05:38]
-
-## [Babel 8](https://babeljs.io/blog/2026/06/16/8.0.0/)
-
-**Mark:** So on the, ESM note, Babel 8 just shipped, and the, big highlights there, the Babel packages themselves are also now ESM only. TypeScript types are built in, and the default compilation settings for building your projects no longer target ES5 or CommonJS. So essentially they're saying we've, rather than necessarily being about backwards compatibility by default and always trying to cross-compile your code to, support, IE 11 or whatever, now we're targeting the modern JavaScript ecosystem. Which is also pretty much what, TypeScript 7 is doing as well. [00:05:39]
-
-**Carl:** I am extremely here for that transition. I wish that it had happened several years ago. Babel as a compatibility layer I think is really good and really great, but we've been on evergreen browsers for most of my career at this point, and I, yeah, just, the long tail of what it means to support ESM 5 and Require is just, it's really... [00:06:23]
-
-That tail's really long at this point. It's very far away. I don't know. I, think the, trade-offs are not quite there. Yeah. Yeah, Babel 7. I don't know. I've, Are people still manually installing and managing Ba- Babel versions themselves? This feels like something I haven't wrangled with personally in a long time. It's all downstream of the rest of the tools I use [00:06:44]
-
-**Mark:** Yeah, I'm disconnected enough from day-to-day app development that I don't have an answer to that question. [00:07:07]
-
-**Carl:** fair. Ha Okay. Anyway, moving on. [00:07:12]
-
-## [Astro 7](https://astro.build/blog/astro-7/)
-
-**Carl:** We've got Astro v7, major release of Astro. Astro's a project that I have always meant to explore more deeply than I really have. I have used it for a, trivial project here or there. If you're building a static portfolio site, brochure, marketing, whatever you wanna call it, it's really good. it hits a good balance between engineering ability, it gives you escape hatches to manually control stuff, while still being largely content oriented. [00:07:15]
-
-So it's very good if what you're managing is what's on the page rather than, like, how it behaves or what data's available. so it, not as great for a full app. there are certain types of apps that work great in that environment, but an application less [00:07:46]
-
-**Mark:** Like my mental model of Astro is it essentially replaces Gatsby [00:07:59]
-
-**Carl:** Yes [00:08:03]
-
-**Mark:** in terms of, we, we pull in data sources, we build sites that are static by default, but can have lots of dynamic content with your rendering framework of choice [00:08:04]
-
-**Carl:** Would agree with that, with all the same caveats of a lot of apps need something a lot more complicated than that. [00:08:14]
-
-But if you're building co- a content site, it's a really great tool for that. Yeah. Looks like mostly they're touting, s- build improvements, upgraded internal dependencies, V8, new roll down bundler. [00:08:19]
-
-**Mark:** Faster markdown parsing. [00:08:33]
-
-**Carl:** Yeah. Advanced routing to give you a single entry point with full control over the request pipeline. They can detect coding agents automatically that looks like a local development feature. It's, you can run the dev server in the background and output structured JSON for machine-readable feedback. That's really smart, actually. I love that. there's a ton of cases where, just like in testing and such, raw human readable HTML and CSS, it... that's just a lot of content. It's a lot of bytes. It's a lot of tokens. so giving machine-readable outputs at the framework level is really helpful. I like that a lot. That seems like a really smart feature, and I think we're gonna start seeing that for more. [00:08:34]
-
-## [TS 7.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)
-
-**Mark:** And I mentioned this a minute ago and we've mentioned it in previous episodes, but TypeScript version 7 is now at release candidate. think the biggest change here from a user point of view is that p- the previous releases had shipped as a separate native preview package and now it's the actual TypeScript package itself, the RC tag has all new binary and faster compilation stuff in there. [00:09:13]
-
-## ESM only, no programmatic API right now
-
-**Mark:** One other thing to note is that the, 7.0 release, number one, it builds off 6.0 where they change the default settings to favor modern compatibility instead of backwards compatibility. but then also 7.0 will not ship with a programmatic API. So tools that depend on the c- on the TypeScript compiler package to programmatically drive compilation, parse files, do that sort of thing, will not work out of the box with 7. [00:09:42]
-
-The idea was get the full working compiler in people's hands now and they're still trying to nail down the details of what the programmatic API will be like, and they're hoping to have that out in a 7.1 [00:10:18]
-
-**Carl:** Cool. Nice. Yeah, and we discussed that at more length last month, so I don't know that I wanna rehash all of that again. Difference between beta and RC is just not that big. [00:10:31]
-
-## [Nub JS](https://nubjs.com/), from Zod creator
-
-**Mark:** Okay, the, the next one's very interesting. Colin, the creator of Zod, just announced something called nub. Those of you with keen eyes will notice that this is bun backwards, in the same way that Deno is Node rearranged. clearly there's only so many letters we can use in naming JavaScript runtimes at this point. [00:10:41]
-
-The s- the sales pitch for this, Node was run JavaScript on the file system outside the browser. Deno was, "Oops, we made a bunch of mistakes designing Node. Let's completely redesign the security and the process architecture and bake a bunch more stuff in." Bun was, "Let's build Node compatibility on a different JavaScript engine, and also add every other built-in programming method and API we can think of while we're at it so it does everything at once." [00:11:07]
-
-Nub, on the other hand, is, "Let's start with actual Node, let's override a bunch of its configuration options, and let's build in a more modern environment, things like better TypeScript stripping and better, package JSON handling and a bunch of other pieces into Node directly so it feels like Node much better rather than one of the, one of the other options." [00:11:43]
-
-I, like this idea. we've been using things like ts-node and TSX and all these other type-stripping approaches. Node has a type-stripping option built in. This apparently goes up to the level of being able to output the non-strippable pieces of TS syntax, so like e- enums and things like that. But then it bakes in a whole bunch of other features as well. I like this idea. I, it, makes a lot of sense to me [00:12:15]
-
-**Carl:** I'd agree. It's interesting. I was always skeptical about Bun because of what you said, it starts from a brand-new runtime, and runtimes are difficult. It's hard. It's... Getting it right is tricky. clearly it's worked well enough for many people, but I've struggled with it a little bit. [00:12:45]
-
-Sure, There's plenty of room for opportunity in the tools surrounding Node.js as well. But I'm skeptical of this package manager. It says a pnpm-compatible manager built in, and it, reads whatever lock file you already have, writes to the same format. I don't know. I'm skeptical of that. look, we made a magic package manager that is cross-compatible with every existing package manager. sure, I'm sure you did. Can't wait to find out what bugs you missed. [00:13:02]
-
-**Mark:** I saw a tweet from Colin where he said that this was all implemented with AI, not surprisingly given today's no but it, but there was a lot of very careful planning and, defining the feature set and working out the requirements and then, using the agents to actually do the work on it [00:13:33]
-
-**Carl:** And, like we s- we were talking about last month, if you've got an existing set of tests to make sure that your code works against which all of these open source package managers are going to, then it's definitely a lot easier to create a functioning replacement. [00:13:52]
-
-yeah, I don't know. It's interesting. Curious, we'll, we'll see how it shakes out. We'll see if it works. see how it does for people [00:14:06]
-
-**Mark:** Yep. [00:14:11]
-
-## [Legend List 3.0 with DOM support](https://x.com/jmeistrich/status/2059922504320225316)
-
-**Mark:** Another release announcement. Legend List 3.0 came out, and this is originally, I think the original version of this was React Native only. Jay Misiorek's also the creator of the Legend State Signals library. but apparently he's figured out how to port the underlying list virtualization logic over to React DOM as well, and says that it's one of the fastest, if n- if not the actual fastest virtualized list implementation out there . [00:14:13]
-
-## [TSRX revamped the syntax](https://tsrx.dev/blog/rethinking-tsrx)
-
-**Mark:** And then, other follow-up note, I think it was last month we had mentioned something called TSRX, where Dominic Ganaway and the Ripple project had said, "We're, annoyed at the JSX specification being stuck for, the last 10 to 12 years. [00:14:44]
-
-We have come up with what we think is a better syntax, that, adds more flexibility." And, after they announced it, they got a bunch of feedback on, people not liking some of what they designed. And so th- they did a couple different blog posts about how they've stepped back and rethought what the syntax is. [00:15:02]
-
-Things like, the original TSRX wanted you to put quotes around every bit of text that you had in there, whereas JSX just is angle bracket, words, angle bracket. And so they've, gone back to that as a syntax for text. So to be honest, I don't have a good mental picture of what the actual differences are between this and JSX at this point, 'cause I, haven't gone through it in detail. [00:15:21]
-
-But they, looks like they do have some control flow syntax embedded as well. so they're somewhere in between their original p- proposal and standard JSX at this point [00:15:49]
-
-**Carl:** Neat. It's a big swing. I said last month that I think it's interesting that now in the AI era you can just update documentation and the tool knows how to use it, which was not the case for previously. So that might make it easier for tools like this to succeed, because you can just drop in a different markdown document and the tools will know how to write the new code, so to an extent. It's not perfect. [00:16:02]
-
-## React Core news
-
-**Carl:** Let's get into the main content with some React core updates first? [00:16:28]
-
-## [React Compiler in Rust is rolling out](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x)
-
-**Mark:** All right, so the biggest thing this month is that the React compiler port into Rust has officially been merged, and there's been a whole flurry of activity of different build tools now trying to actually integrate this. so the React teams had said, "We have been trying out the port at Meta. It appears to emit identical results with the TypeScript implementation of the compiler." [00:16:32]
-
-## [PR was merged after testing at Meta and improved](https://github.com/react/react/pull/36173#issuecomment-4608356402)
-
-**Mark:** they did a bunch of work to optimize it and handle some more cases, and the PR itself got merged, about a week-ish ago, I think. So now that it's at least more or less available, then the question is, how do you actually use it? [00:16:57]
-
-I don't know if you can actually just install the Rust version of the compiler right now. I'd have to double-check that. But n- since we have a whole bunch of build tools, and most of today's build tools are now written in Rust, a lot of different teams have been exploring how do we actually integrate this into the build tools. [00:17:14]
-
-## [Oxlint, SWC, RSPack, Next all integrating](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x%20)
-
-**Mark:** So Oxlint, SWC, RSpack, Next, and Bun have all been trying to figure out how do we integrate with this, make it a, an option or built-in or something along those lines. [00:17:35]
-
-## [Rolldown tried integrating directly but removed due to binary size increase](https://x.com/evanyou/status/2069593612153987373)
-
-**Mark:** One interesting note is that Rolldown tried to actually add this into their system, so there would just be a built-in turn on the React compiler option. [00:17:50]
-
-And what they saw was that it increased the binary size from, 28 megs to 33 megs, and they decided that was too much extra size to force everybody to download, actually reverted it, and they're exploring further options on how they can integrate it. [00:18:01]
-
-## [Bun tried optimizing the Rust Compiler code](https://gist.github.com/Jarred-Sumner/84df369c35216f40d61d1ea9f95771c2)
-
-**Mark:** On the other hand, Bun taking the Rust code and tried to both integrate it and also see can we improve the Rust code itself to make the compiler run faster. [00:18:18]
-
-I think a couple of the other teams have also been seeing, now that the Rust code for the compiler exists, can we also make it faster as well? So there's clearly still a lot of development opportunities for different teams to explore in terms of how is it integrated into the build step, how fast does it run, but we now at least have the merged PR as a baseline for all that different work [00:18:33]
-
-## Other core improvements
-
-**Mark:** Couple other things I noticed. one is that the React team has been working on something called Fragment Refs for a while. We, might have mentioned this once or twice in the past. [00:18:57]
-
-**Carl:** Yeah, I think not a long time though. It's b- it's been a minute [00:19:08]
-
-**Mark:** it's been a while. The PRs were sitting out there or getting quietly iterated on. [00:19:11]
-
-## [Fragment Refs have been documented](https://react.dev/reference/react/Fragment#fragmentinstance) in canary
-
-**Mark:** So the idea for a Fragment Ref is that a React fragment by design does not have any single DOM node associated with it, because it's meant to be like a virtual container for many children. That's why we wrap them in a fragment in the first place. but what happens if you want to do something like listen to a DOM event for any of the children directly underneath the fragment, or perform some other DOM operation? [00:19:17]
-
-So Fragment Refs are a, I think, now in Canary feature where you can put a ref prop onto a fragment and you get back something that looks like a DOM node in terms of the methods you can call, add event listener and that sort of thing. and under the hood, React just does the work to pass the references on to all of its children automatically. [00:19:48]
-
-So it looks to your code like you're dealing with an actual DOM node, and under the hood, React takes care of, oh, there's 15 children directly under this fragment, let me just collect the interactions with all of them. So, that is apparently now in Canary, and they've actually updated the documentation page on fragments to say that you can use refs on them [00:20:16]
-
-**Carl:** Nice. Cool. the value here I think is really specific, and, it might, be unintuitive. it... let's say you wanted all of those DOM methods you just talked about, you wanted to be able to measure the size of this block of nodes or add an event or whatever. [00:20:40]
-
-Another way you could do that is to wrap it in a div. If you have a div, cool, great, free DOM node. You can do all those things. but that doesn't work in certain layouts. if you wanted to have a grid where all of them share a single, drag end event, you can't just wrap that in a div because that breaks the grid layout. [00:20:57]
-
-So this is a situation for, flex or grid, where there's an implied mandatory hierarchy of the DOM nodes itself, and you are rendering those s- containers, those children, s- let's say from a map. You're mapping over data, then this is super helpful for adding a whole bunch of different types of behaviors, which is why it's worth the effort. [00:21:19]
-
-## React DevTools MCP tools, including [component tree](https://github.com/react/react/pull/36597) and [perf analysis](https://github.com/react/react/pull/36598) APIs
-
-**Mark:** And then one other thing that I have a vested interest in, the re- there's been a series of PRs posted to improve the React Dev Tools by adding MCP tools so that agents can query and inspect it. some form of imperative API so that you can programmatically ask, what is the component tree, and even turn performance profiling on and off. [00:21:42]
-
-and then some, some additional wrappers to expose that data. I've spent a bunch of time doing React performance analysis work. I am doing some of that at my day job right now. so I'm, I am also keeping a very close eye on this because it's very heav- heavily related to my interests. [00:22:08]
-
-**Carl:** Yes, it is. Yeah, and we've got... [00:22:26]
-
-## React Foundation progress
-
-**Carl:** we mentioned briefly the React Foundation last month, and most of what we said was that we haven't been able to see very much of what's happening. We can see things. Visible change is happening. [00:22:28]
-
-## There’s a(n early) [react.foundation](https://react.foundation/) website, advertising funding for maintainers and community groups
-
-**Carl:** The React repos have moved, there's also a new website being developed. I've seen some chatter about that. [00:22:39]
-
-**Mark:** Like the, foundation page exists, but the, uh the current form of the page is very vibe coded. And so, a- they're, like what's there is accurate, but not well designed. [00:22:46]
-
-**Carl:** Yeah, it is definitely vibe coded vibes. but yeah, so that, that, should change soon. [00:22:59]
-
-**Mark:** The, couple of the interesting bits for me, if you look at the, React Foundation website right now, there's a strong emphasis on helping support the community financially. Some of that is they're apparently intending to sell swag, shirts, and whatever, they intend money fairly to maintainers of some of the most common React ecosystem libraries. They also talk- they've also talked both in the past and I think on the website about helping financially support different, communities, meetups, conferences as well. And then I think they are taking over running the official React Conf as well [00:23:05]
-
-**Carl:** Yeah, I know that they've actually been having some struggles getting meetups. they wanna support local React-based meetups, people aren't doing local React-based meetups anymore. It's all AI stuff or whatever. it's... I think the... I, think my intuition here a little bit is that some of their mental model for how the React community exists is still, maybe not fully reacted to the shifts over the last two years. [00:23:45]
-
-I love the idea of collecting nonprofit donations and then distributing them out to library maintainers. I think that is super, super good. And doing it with a, proper foundation with, governance and a board of directors is super good. I've ac- I actually thought quite a bit about trying to do a business adjacent to this, just, hey, we got a community. [00:24:14]
-
-What if we did, a bunch of little events and had a membership subscription or whatever, and then funneled 80% of that money to the people who make the community exist. and I, ended up not just 'cause it's it was hard. It's a lot of work. It's a ton. Access also helps. starting from I am the manager of the React core team is a very strong position to create a foundation. [00:24:35]
-
-**Mark:** the flip side of all this is that as I discussed last month, I have no idea what's going on with the development of React itself. the- there's PRs around the compiler and the dev tools. I really haven't seen much activity on the core library in the last few months. [00:24:58]
-
-Joe Savona c- and put up a post confirming that he is no longer on the React team at Meta. He's now working on something AI related. and then that kind of ties into what we'll talk about in a minute with what is going on at Meta anyway. So here feels like the development process on React itself is rather fragmented and confused right now [00:25:14]
-
-**Carl:** Which is unfortunate. [00:25:39]
-
-## They’re gonna have a booth at [Chain React at the end of July](https://chainreactconf.com/)
-
-**Carl:** But if you wanna talk to the core team or, some members of the foundation, or generally people close to the development of React, they will have a booth at Chain React, July 30th, which it's a React Native conference specifically, And it is, where is it? And it is in Portland. So yeah, if you're, around the Pacific Northwest or willing to travel, so yeah, check it out. [00:25:41]
-
-Okay, moving on a little bit. jumping off your tangent you just teed me up for, thank you. [00:26:04]
-
-## [Why is Meta destroying its engineering organization?](https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering)
-
-**Carl:** Why is Meta destroying its engineering organization? this is a newsletter post put out by Gergely Orosz, who's very influential, I would say. He puts out a, pragmatic engineering newsletter. It's very good. I read it occasionally. I read posts from him. [00:26:11]
-
-**Mark:** well written and sourced [00:26:27]
-
-**Carl:** Very well-sourced, very timely. He does a good job of being timely. so y- this is a, this, is again, a well-written, well-researched, well-presented post, talking about the engineering values of Meta historically. it brings in the, original Facebook little red book, which is a little, culture document describing the values of the company. [00:26:28]
-
-**Mark:** move fast and break things, but also like a, lot of stuff about how we want to think about building stuff for the customer [00:26:48]
-
-**Carl:** Yeah. okay, so Move Fast and Break Things is notorious. here are eight, no seven other values from the same book. [00:26:57]
-
-Done is better than perfect, [00:27:05]
-
-fail harder, [00:27:07]
-
-what would you do if you weren't afraid, [00:27:08]
-
-every day feels like a week, [00:27:10]
-
-the Wright brothers did not have pilot licenses, [00:27:12]
-
-the foolish wait and fortune favors the bold. [00:27:15]
-
-And I don't know, a lot of those are values I can, agree with. [00:27:17]
-
-**Mark:** It's better to get something done and see what happens than to waste all of our time discussing if we should try doing something [00:27:22]
-
-**Carl:** Yeah. Yeah. So I don't know, it's, it's a good doc. This is good speaking about the engineering cultural history and some of the actual timelines of improvements and, releases that they made. and it's, it lists a number of problems. th- they started tracking engineers' keystrokes with no way to opt out on work laptops. [00:27:28]
-
-it says "30 to 50% of engineers and core teams have been forcefully reassigned to data labeling." You think you're gonna be a core AI engineer and oops, you're just n- t- you're a competent, skilled professional tagging data the same as a legion of other competent, skilled professionals training your replacement. [00:27:52]
-
-I have a, friend of mine who was recently laid off from Meta who has been involved in, basically, just trying to resist this type of pressure. like for being forcefully reassigned to a team that you are not interested in being on, that sucks. [00:28:10]
-
-and it's part of your contract. It's ultimately, at the end of the day, you're in a hierarchical corporate system. They have hired you to perform work at their leisure, at their desire, and it is entirely within their legal contractual right to say, "You work on this now." [00:28:24]
-
-and that doesn't, What if it, wasn't their contractual right? What if they did have to actually negotiate with you and put you somewhere that was mutually compatible? So I don't know. That's, that's the pushback that they have been trying to support and organize. [00:28:40]
-
-But, meta is maybe not doing so great. I guess, one, one concrete engineering point that this, draws attention to was the r- disappointing AI model development. Like losing momentum effectively. Like Llama 1, 2, 3 were all very cutting-edge and competitive, and Llama 4 released over a year ago now, which I guess was the last release. I don't know of another release from them. [00:28:53]
-
-so yeah, I don't... as a symptom of declining engineering culture, their frontier AI model is no longer competitive. [00:29:20]
-
-**Mark:** Yeah. So some of the points it makes is that they, they, used to have v- pretty good engineering culture based on we're, trying to build the right things the right way at scale. The question of, whether the apps that they're building are useful for society is a different question, but at least they were mostly trying to build them the right way. [00:29:28]
-
-And now it seems like in the last year or two they have shifted to a focus on AI. They've had a bunch of layoffs. Engineers have been forcefully reassigned, and the, I know the performance review topic c- has come up repeatedly when I've talked to even, React core team members. They, they want to spend their time doing things that will benefit the greater React community, but they have to, in order to get good performance reviews, they have to show, like, how is this actually benefiting Meta the company. [00:29:44]
-
-And so whether that's something like, "We're gonna build this new React feature because it makes Ads Manager faster," or, just, interactions in some way. So that I know has been a struggle just for the React team, and it's clearly a major problem for everyone else at the company at this point. How justify my existence? [00:30:16]
-
-**Carl:** there's a book that I love called Moral Mazes that speaks a lot about this type of problem. we, we're talking about engineering culture. [00:30:35]
-
-That's... Culture is the downstream result of a vast group of people interacting with each other. The culture is the emergent property of how those individuals interact with each other. And Moral Mazes is a really wonderful sociological study of the firm, the c- the American corporation. And so it ends up speaking a lot about subjects like performance reviews. [00:30:44]
-
-And here in this blog post, the Pragmatic Engineer Newsletter, it says, "The biggest problem, people stop caring about real work and focus on performative work." and like what you just said about how they can't do what's best for the overall growth of the library because that's not the criteria upon which they're judged. [00:31:05]
-
-They are judged on their impact within the company, and specifically the impact on the company as judged by their immediate supervisor with, with the supervisor chain. So it, ultimately you're... The, incentives flow down in that kind of way. So it's actually... [00:31:23]
-
-there's, a deep fundamental misalignment between open source and, the American corporation, I'm not gonna go into capitalism a w- But, that's very true. Open source is a c- is a public good. It's a, it's, it's a public square. It's a shared resource that they're, people don't pay for. and those types of resources they're the economic concept of the tragedy of the commons. [00:31:41]
-
-It's a well-known principle that people don't just casually take care of stuff. If it's a public common, it's going to get more extraction than it is investment. So it's... I don't know. It's, it, there, the, th- that's a fundamental tension, and I feel like any time we're talking about companies under-investing in, open source, that's kinda why. [00:32:03]
-
-It's because they can't. They're not allowed to. If you're a big publicly traded company that has gone to IPO and has shareholders, you have a fiduciary duty to those shareholders, and fiduciary duty does not include volunteer effort to public goods. So it's, that's, there you go. That's the tension. [00:32:27]
-
-Anyway, let's move on [00:32:44]
-
-## [AI demands more engineering discipline. Not less](https://charitydotwtf.substack.com/p/ai-demands-more-engineering-discipline)
-
-**Carl:** Great post from Charity Majors who, somebody who I've ... They, are such a well-spoken, phenomenal writer speaking about engineering culture. And I, especially they talk about opera- or, yeah, I was gonna say operationalizing, production environments. [00:32:46]
-
-they run a company that makes its money on observability, [00:33:05]
-
-**Mark:** Honeycomb [00:33:08]
-
-**Carl:** Honeycomb. great company, great mission, great blogger, great writer. so i- she's put out a post, AI Demands More Engineering Discipline, Not Less. [00:33:10]
-
-Charity says in her post, "What happened in 2025 was this, the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated to being disposable and regenerable practically overnight." [00:33:20]
-
-And something I've said on this podcast before is that, code's kind of a liability. over time code is not an asset, it is a drain. It is something to be maintained. It is a cost center. so I agree with that. I think that read is correct. The, economics of code production were turned upside down. [00:33:38]
-
-it's m- because code is not an asset, because code is a liability, the ability to discard it and replace it with something new that is, has differ- has a different risk profile is massive. [00:33:57]
-
-**Mark:** It's, ironic because, as developers we have historically resisted, taking the time to write documentation or writing tests or actually planning out our work, and suddenly it turns out that in order to get good results from AI, we actually need to do all of the above. [00:34:12]
-
-**Carl:** Yeah, and it's like I have always known what the right choice to make was. it's y- several years ago when I was working as a tech lead, it's okay, we have this feature. I know that it is deficient in these , these areas. no, we don't have end-to-end tests. no, we don't have functional integration tests for all corner cases. [00:34:30]
-
-Because we don't have an existing end-to-end harness, because we don't have a framework for mocking network responses for requests initiated from components deep in the tree, deep in the hierarchy. there, it's, it... Engineering excellence is a momentum-based metric. You cannot skip ahead [00:34:53]
-
-You can't write end-to-end tests if you haven't built a reliable framework upon which to run end-to-end test suites. and so it's hard to do. It's hard to keep that momentum up over a long enough time span to where you start observing the benefits, and so most companies didn't. [00:35:12]
-
-the number of times where I would get feedback on something, and it's like, why don't we have this already?" It's, 'cause that would've taken two weeks, and I can do it now, but I didn't have two weeks." and I gotta say, I'm finding it much easier to find those two weeks with AI. AI is an amnesiac, so it needs to start from scratch every time. [00:35:30]
-
-if you're working on a new feature or just built something brand new, I just ask Claude, "Hey, familiarize yourself with this code base, how much of that did you get from docs versus the code?" [00:35:50]
-
-And it does a little analysis, and it comes back and says, "Oh, the documentation is out of date in these locations, and these concepts should be pulled in." "Great. Can you do that work for me?" It's like, "Oh, yeah. Cool, cool. And so then instead of, what, six hours of, reading code and putting together my own notes and understanding what documentation is currently available and synthesizing it to get, a fact-based update and then writing brand-new prose to fill in those docs, I, I, I can do that in 10 minutes in a background process. [00:36:00]
-
-**Mark:** Yeah, I, love generating architecture exploration e- explanation type docs. I've, found that extremely useful. In fact, that was my gateway that eventually led to me using aI to write code. It does feel like I'm leaving some understanding on the table, that my understanding is can be very much more surface level. some of it is, there's ar- areas of our code base and our projects I just haven't looked at, and operating off of a vague mental model. I, skimmed through a handful of architecture docs. that's certainly not, that's certainly not enough to actually understand what's going [00:36:30]
-
-Yeah place. It's, easier entry, but maybe not as much depth [00:37:04]
-
-**Carl:** That's very true. I assuage my own guilt in that, the like, "Oh no, I, know that I'm only seeing 30% of this." ' Cause for one, every code base is too large for your brain. you are never going to fully understand all of it at the same time. And any time that I did fully understand something, the, amount of time it took to get to that understanding, and then the only time I ever did that was to change it, [00:37:09]
-
-**Mark:** Mm. [00:37:37]
-
-**Carl:** So then as soon as I'm done with that, as soon as I have gotten my understanding up to 100%, cool, great, I'm changing it. That's now out of date. That knowledge is now useless. [00:37:38]
-
-**Mark:** I'm, sure I've mentioned this in previous episodes. I am a huge fan of the concept that programming is building a working mental model of the system. it's a, it's about theory building. So you understand what we are trying to build as a domain, as a project. [00:37:46]
-
-You understand the current system, the architecture, the quirks, the concepts, so that for any task you work on, whether it's a feature, a bug, whatever, you are starting from my current understanding. You break down the new problem based on your understanding. You come up with a plan, you implement it, you spend six hours trying to make it work, and by the time you're done, you not only have working code, you have updated your mental model on the system. So I would say it's not that you've made your previous knowledge useless, but we are continually modifying that understanding [00:38:03]
-
-**Carl:** Yes, sure. I agree with that. I agree with that, but I also discount it a little bit more than I think you are. Like, I'd agree that, developing an, accurate mental model is core. You need to do that as writing, as part of writing code. I, at least, am satisfied at the level that I am able to develop a mental model w- via AI. [00:38:36]
-
-I guess th- this is, a feedback cycle. You have to develop your mental model, check it against what the AI is telling you, and then make sure it's what you intended, and then make sure that what you intended is compatible with a functioning projec- will it achieve what you meant it to? [00:39:03]
-
-And those are all really hard, oh, another thing I wanna say your mental model, are, the building blocks that you have available to develop your mental model, are those complex enough to, capture what you're making? [00:39:19]
-
-That's something I run into fairly often. It's like the system architecture, the system design inter- interview questions. Like, how would you build Twitter to be re- resilient? Those are hard problems. That's re- you know, de- developing a system that can manage hundreds of millions of requests is, yeah, it's really tough, and AI is really helpful for me for exploring that. [00:39:33]
-
-it ends up being... Okay, oh, wait, here let me try and frame this in a sentence. It used to be critically essential to develop an accurate mental model through the process of reading and writing code yourself, and now it's much more important to be able to ask the correct question at the correct time of the code base. [00:39:58]
-
-Because now you can... The, frontier models are smart enough and the tools are capable enough, they can pretty meaningfully answer any question that you have about a fixed set of code. If you, bound it to like, "Here's the code, here's your world, tell me about it. Answer this question for me," it can. [00:40:18]
-
-And so now it's up to you to know what the right questions are to ask given the present state of the existing code [00:40:38]
-
-**Mark:** Yeah. So let's tie that then into the next link in the list. [00:40:46]
-
-## Christoph Nakazawa posted his [“Modern Engineering Values” and how he uses AI](https://cpojer.net/posts/modern-engineering-values)
-
-**Mark:** so Krzysztof Nakazawa is a long time figure in the React ecosystem. He's worked on Jest and graphQL and a whole bunch of other tools. more recently, he shipped a data fetching library called Fate. he's built a game with JavaScript called Athena Crisis. He got hired by Void Zero, which we'll talk about in a second. so like re- like really smart, capable long-term engineer, and he is now fully doing everything with AI. [00:40:51]
-
-**Carl:** Yep. [00:41:21]
-
-**Mark:** He put up a post on modern engineering values where he talk about how he uses AI effectively, but also then what are the principles that he's using in trying to build projects. And he talks about, ownership and taste and strict guardrails and fast feedbacks loops, which is what we were hitting on a minute [00:41:21]
-
-**Carl:** Yep. [00:41:42]
-
-**Mark:** Being able, to know what is the right context that I feed into the agents so that they are able to come up with the answers. maybe actually, owning some more your own code instead of depending on third-party libraries. Thinking differently about how you build prototypes and ship things. so very relevant to like we're, doing the same work, but maybe at a higher level, and you do have to know where you're trying to go [00:41:44]
-
-**Carl:** Yes. Yeah, agree. Yeah, I like this, bit from Christoph's post, "I've found that coding agents now write code that is as good or better than what I could write," which I would agree. I find that true as well. "And they do it in minutes instead of weeks. Since coding is no longer the bottleneck, I get a lot of work done that otherwise wouldn't have happened at all." [00:42:12]
-
-100% agree with that. That is... I have started and finished so many more projects than I would have before because I, can do it in a day instead of in a week. it's a 7X speed multiplier for me. So it's good. [00:42:30]
-
-## [Cloudflare bought VoidZero](https://voidzero.dev/posts/voidzero-cloudflare)
-
-**Mark:** In industry news, Void Zero, the company behind VitePlus and a couple other pieces, has been bought by Cloudflare, this continues the trend of a bunch of open source build tool developers try to get funding, try to make a company, and then they probably get swallowed up by someone bigger because there is no money in running open source build tools. Bun and a whole bunch of others all getting bought out. nobody is making money off of open source build tools. There is no build m- there is no financial model, hosting, or anything else. So we'll see how it plays out. to be clear, this is about the team and the VitePlus and Void tool sets and frameworks. [00:42:42]
-
-This does not affect Vite, the open source bundler, at all, other than these are some of the same people working on it. but it continues the pattern, and I don't see that pattern changing anytime soon [00:43:32]
-
-## NPM / security updates
-
-**Carl:** We got some more security updates from NPM. Great. [00:43:44]
-
-## [Github Actions allows enforcing pinned action SHAs](https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/)
-
-**Carl:** GitHub Actions now supports blocking and pinning actions to a specific SHA. So that's, that's really good. If you... So this is helpful for avoiding vulnerable actions. if you're aware that some specific release of an action was compromised, you can now block that one specifically. [00:43:48]
-
-Or say, "We know this one is good. Only use this version." wow. Ability to select precisely what code you're running. This feels like table stakes to me. It's shocking that we're only just getting it [00:44:09]
-
-## [GitHub Actions Has a Package Manager, and It Might Be the Worst](https://nesbitt.io/2025/12/06/github-actions-package-manager.html)
-
-**Mark:** there's, a guy named Andrew Nesbitt, I think we may have linked one or two of his articles previously, but he has become an expert on package managers and packaging systems, and I think he wrote an, a couple articles talking about, yep, GitHub Actions is totally a package manager. It doesn't look like one, but it is, and it's bad [00:44:21]
-
-**Carl:** Yes. Yeah, people shit on NPM for a lot of reasons, but you know what? The w- most most of the ecosystem problems in JavaScript around dependencies are because NPM is one of the only functional package managers in programming. Cargo or NuGet or, like, all of the other... [00:44:39]
-
-Every other language has a shitty dependency manager. It does not support what I would call core features of a dependency manager. For instance, pinning versions. Just, it's shocking to me how ineffective we are at sharing code in the vast majority of programming. anyway, yeah. So great. So many things are terrible dependency managers, and GitHub Actions is now a slightly less terrible pa- package manager [00:44:58]
-
-## [NPM 12 will disable install scripts and Git deps by default](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
-
-**Carl:** GitHub also put out some breaking changes for npm 12. They are not going to run install scripts and Git dependencies by default. that is... This is literally something I've seen discussed as a security vulnerability for 10 years. [00:45:27]
-
-So it finally got exploited enough times that they're like, "Nope, okay, we gotta get rid of it." great, cool. They're getting rid of the thing that has been discussed as something that should be gotten rid of for a long time [00:45:43]
-
-specifically it's, NPM will no longer run pre-install, install, or post-install scripts from dependencies unless you allow list them. So no builds basically [00:45:54]
-
-**Mark:** what I think pnpm als- already does [00:46:05]
-
-**Carl:** Plenty of package managers already do that because running untrustworthy code from a network is really dangerous. [00:46:08]
-
-Don't do it. This is what I mean, like, I just said, NPM is one of the most advanced package managers in all of programming, and it still gets basic shit wrong. Stop it. Security models. [00:46:13]
-
-## Code optimization still matters!
-
-**Mark:** All right, last major item for the day. topic, a related topic, but, bit of a grab bag. There's a whole bunch of good articles about code optimization that came out in the last few weeks, and I've spent a lot of time doing performance profiling. I have literally given a talk this year on how to do performance profiling. So we had several articles on, and from people who did performance optimization work on tools and libraries. [00:46:25]
-
-## [TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects](https://tanstack.com/blog/tanstack-table-v9-memory-performance) and [optimized TS perf](https://tanstack.com/blog/tanstack-table-v9-typescript-performance)
-
-**Mark:** First off, there's a couple articles from the TanStack Table folks where they talked about how they were able to save a bunch of memory within TanStack Table by switching out the JavaScript prototypes that were being used, as well as how they optimized, the TypeScript compilation performance. [00:46:53]
-
-Now, yes, TypeScript's version seven's gonna make all our TypeScript faster, whatever, but it's still good to actually try to improve the, type checking time if possible. [00:47:14]
-
-## [Pierre Diffs was significantly optimized](https://pierre.computer/writing/on-rendering-diffs) - has to handle virtualization, syntax highlighting, source loading
-
-**Mark:** next, there's something called the Pierre Computer Company, which is making essentially like a, GitHub for, as a service kind of a, set of tools. [00:47:25]
-
-And they've put out a couple JavaScript libraries, one for rendering tree views in the UI, but they also put out one that is a diffs rendering library. And so they've put up a post on how they heavily optimized all the list virtualization and the syntax highlighting and all the other complexities of trying to render diffs efficiently in the browser. [00:47:35]
-
-And I've seen several other applications pop up which use that library in the UI. part of me make, wonders if GitHub perhaps consider using that library in their UI given the, how slow their React based, PR view is at this point [00:47:59]
-
-**Carl (editing):** oh, shoot. We had an audio problem. For some reason, we lost about the last 10 minutes of my audio. Mark's came through just fine. Uh, and luckily he did most of the talking in the last little bit here. Uh, but unfortunately we lost about four to five minutes of me responding to things that Mark said. Uh, oops, sorry. [00:48:20]
-
-## [CompileCat is a new optimizing compiler to improve JS execution after bundling](https://github.com/isaac-mason/compilecat), similar to Closure Compiler. ([the RSPack team says they’re working on something similar](https://x.com/jiahan_c/status/2065630866668453898) )
-
-**Mark:** A couple more of these. So someone recently started a site called Performance.dev. Their first article previously was on how the linear UI is fast using sync engines, and they just put up another post on how a tool called Conductor implemented a bunch of optimizations, handling some of the UI layer interaction with Tari, list virtualization, and a bunch of other pieces. [00:48:38]
-
-so those are, apps and libraries making things faster. I saw a couple, winks on something different. So we all use minifiers in our bundling process. It's, part of all modern build tool chains. minifiers do things like they don't just rename variables from my variable to A. [00:49:03]
-
-They, they strip white space. They turn true and false into bang zero and bang one be- because it takes up fewer characters, et cetera. But they also do things like stripping out dead code. So if a library has only r- has a, an if statement that says, "Only run this in development," it will convert that to if false, and then it will say, "Oh, that code can't run. [00:49:25]
-
-Just delete that code from the bundle and optimize the output." And so every time you run a build, a minifier is optimizing the output. And the major mini- the major minifiers, optimizers have been things like Terser and, ESBuild has had one built in, Rolldown has one built in. there's be- there's one that's been around for a very long time called the Google Closure Compiler. [00:49:49]
-
-this dates back to when Google first built a lot of their early web spa type tooling. 2008, 2009, somewhere in that timeframe. it's, extremely powerful and has a lot of very advanced optimizations that other minifiers still don't have, but it's also big and complicated and maybe a little bit on the slow side. [00:50:14]
-
-interestingly, the React team still uses the Closure Compiler to build the React library so that the production version of React is as fast as it can possibly be. So I saw two different announcements of teams that are attempting to write their own advanced optimizer tools. one person built something called CompileCat, and then the other one's a mention of an internal tool that's not released yet, but the, RSPACK team at ByteDance said they're also working on a similar tool. [00:50:35]
-
-So presumably doing things like actually looking at not just the JavaScript, but the TypeScript types in order to be able to, be smarter and produce better output code as well. [00:51:11]
-
-## [Mark’s React-Redux \\\+ signals draft perf PR](https://github.com/reduxjs/react-redux/pull/2318) and [updated React-Redux benchmarks repo](https://github.com/reduxjs/react-redux-benchmarks)
-
-**Mark:** And then I guess we'll wrap up this section with three things for me. so I, think I briefly mentioned last month that I was working on a proof of concept to try to optimize React-Redux's subscription notifications for our large applications. so I have a draft PR, and I've put that up, and the early numbers look promising, like 20% to 30% faster depending on the situation. [00:51:22]
-
-as part of that, I also updated my React-Redux benchmarks repo so that I've got better metrics that I'm capturing and, a better, more realistic set of example scenarios to be measuring against. And then one of the conference talks that I've been doing this year is literally on the basics of performance optimization. [00:51:50]
-
-there's a set of general scientific principles to apply, descriptions of actual tools that you would use to measure JavaScript performance and fi- try to figure out which lines of code are slow, and I talk about some of the examples I did while working on Immer last fall [00:52:12]
-
-I think this is all very important even in the age of an AI because AI tends to write the obvious code. It doesn't necessarily write the fast code. And we collectively were already very bad at asking, "Is this code fast?" in the first place when we were the ones writing it. And now that n- we're not the ones writing it, it's even easier to never ask the question, "Is it fast?" [00:52:28]
-
-## [Aurora Scharff’s preferred RSC component architecture](https://aurorascharff.no/posts/component-architecture-for-react-server-components/)
-
-**Carl (editing):** Yep. So right here is where we lost about four minutes. Uh, unfortunately, I, I definitely cannot reproduce what I said, which is a big bummer. I think it was probably really smart and really clever and really wrapped up the whole thing of what we talked about all episode. But unfortunately, it's gone into the ether. [00:52:51]
-
-I tried re-extracting the audio as recorded from the original source, and it was just blank. We're just completely missing 10 minutes. sorry. [00:53:07]
-
-All I really know is that I was introducing Aurora Sharf's blog post titled "Component Architecture for React Server Components" as her preferred RSC component architecture. [00:53:15]
-
-And I know that because Mark said after [00:53:26]
-
-**Mark AI filler:** yeah. And, Aurora really is the expert on this kind of stuff right now [00:53:29]
-
-## [Lovable projects now use TanStack Start by default](https://lovable.dev/blog/building-apps-using-tanstack-start)
-
-**Mark AI filler:** And then one, one other interesting data point to wrap up, announced that all of their Vibe-coded app projects are now going to be built with TanStack Start by default. I don't remember whether they were just using plain Vite React router or something previously. but this feels it, it's a very interesting data point. A sign of the maturity of TanStack Start, and that they're, and they're happy to actually adopt this as the default setup for all their projects going forward. [00:53:34]
-
-**Carl (editing):** And that is all we've got for you today. I am re-recording this afterwards just like all the other things I said in the last 10 minutes. So I'm not gonna do the usual full sign-off 'cause this is totally fake and I'm just sitting at my desk talking to myself. Sorry for taking a few extra days to get the podcast out. I am just tired and it's summer [00:54:05]
-
-Thanks so much for listening all the way to the end even. talk to you next month [00:54:24]
diff --git a/src/transcripts/tmir-2026-07.md b/src/transcripts/tmir-2026-07.md
deleted file mode 100644
index ebd1faf..0000000
--- a/src/transcripts/tmir-2026-07.md
+++ /dev/null
@@ -1,667 +0,0 @@
----
-title: "TMiR 2026-07: React-alikes, GOVERNANCE, and state management"
-date: 2026-07-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we discuss the React Compiler being rewritten in Rust, what AI development means for engineering culture, "
-people: "[Carl](https://bsky.app/profile/vcarl.com), [Mark](https://bsky.app/profile/acemarke.dev), and [Mo](https://bsky.app/profile/mojavad.bsky.social)"
----
-
-
-
-
-
-- [[01:27](#new-releases)] New releases
- - [[01:29](#vite-beta)] [Vite+ Beta](https://voidzero.dev/posts/announcing-vite-plus-beta)
- - [[02:41](#typescript-70-released)] [TypeScript 7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) released
- - [[03:56](#open-pr-for-content-mappers-to-typecheck-templates-other-than-jsx)] [open PR for “content mappers”](https://github.com/microsoft/typescript-go/pull/4712) to integrate other language syntax
-- [[04:57](#johnson-chu-made-a-compatibility-layer-to-drop-in-for-unsupported-tools)] Johnson Chu made [a compatibility layer to drop-in for unsupported tools](https://github.com/johnsoncodehk/typescript-native-bridge)
- - [[05:18](#oxc-type-aware-linting-stable)] [OXC type-aware linting stable](https://oxc.rs/blog/2026-07-22-type-aware-linting-stable)
- - [[06:00](#npm-v12-and-new-security-defaults)] [NPM v12 and new security defaults](https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation/)
- - [[07:00](#dependabot-supports-a-configurable-delay)] [Dependabot supports a configurable delay](https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/)
- - [[07:37](#more-react-rsc-security-tweaks-for-19x-)] [More React RSC security tweaks for 19.x](https://github.com/react/react/releases/tag/v19.2.8)
-- [[08:06](#main-content)] Main Content
- - [[08:07](#react-org-updates)] React org updates
- - [[08:22](#leadership-council-and-working-group-structure-on-the-new-team-page)] “Leadership Council” and Working Group structure [on the new team page](https://react.dev/community/team)
- - [[11:11](#stub-governance-docs-for-the-leadership-council)] [Stub governance docs](https://github.com/react-foundation-dev/leadership-council) for the Leadership Council
- - [[14:37](#rick-hanlon-update-on-the-react-team-using-a-stage-process-internally)] Rick Hanlon update on the React team [using a “stage” process internally](https://www.reddit.com/r/reactjs/comments/1v1dsh0/react_rfc_processis_it_dead/oyp9wac/)
- - [[15:39](#pete-hunt-and-nick-schrock-join-vercel-to-run-frameworksnext-and-agent-dx)] [Pete Hunt and Nick Schrock join Vercel](https://x.com/rauchg/status/2077870043833229692) to run Frameworks/Next and Agent DX
- - [[17:16](#poimandres-published-a-charter-original-announcement)] Poimandres [published a charter](https://github.com/pmndrs/org/blob/main/CHARTER.md) (original [announcement](https://x.com/pmndrs/status/2080303456800080047))
- - [[20:20](#an-example-initiative)] An [example initiative](https://github.com/pmndrs/org/blob/4bd14e20da776ff68f7555a57a01ad0b4999be92/initiatives/03-text-rendering.md)
- - [[21:30](#react-alikes)] React-alikes
- - [[21:40](#octane-from-dominic-gannaway)] [Octane](https://octanejs.dev/) from [Dominic Gannaway](https://bsky.app/profile/trueadm.dev/post/3mrn7yd6dzk2t)
- - [[28:27](#ryan-carniato-reacts-staying-power-is-because-of-complacency)] Ryan Carniato: ["React’s staying power is because of complacency"](https://x.com/RyanCarniato/status/2072382108535066640)
- - [[29:12](#follow-up-do-people-think-fe-innovation-is-dead-would-explain-why-theres-resistance-to-move-past-old-react)] Follow-up: [“Do people think FE innovation is dead? Would explain why there’s resistance to move past old React.”](https://x.com/RyanCarniato/status/2081813329681711152)
- - [[30:31](#parallel-articles-on-solid-20-with-async-and-remix-3)] Parallel articles on [Solid 2.0 with async](https://www.brenelz.com/posts/learning-solid2/), and [Remix 3](https://malstrom.me/blog/learning-remix-3)
- - [[32:22](#cross-framework-benchmark-measuring-reactivity)] [Cross-framework benchmark measuring reactivity](https://bsky.app/profile/nullvoxpopuli.com/post/3mrplyqcd722j)
- - [[35:04](#aiden-bai-released-reactbench-to-measure-ai-code-quality)] Aiden Bai released [ReactBench to measure AI code quality](https://www.reactbench.com/)
- - [[36:37](#alex-russell-thinks-everyone-is-screwing-up-state-management)] [Alex Russell blasts “state management”](https://infrequently.org/2026/07/state-management/) (and most of the React ecosystem) in favor of sync engines
- - [[47:41](#aurora-scharff-rewrote-the-suspense-docs-page-to-cover-how-it-works)] Aurora Scharff [rewrote the Suspense docs page to cover how it works](https://react.dev/reference/react/Suspense#what-activates-a-suspense-boundary)
- - [[48:22](#and-a-post-on-rsc-performance-patterns)] And a post on [RSC performance patterns](https://aurorascharff.no/posts/experimenting-with-rsc-for-performance-and-ux-in-nextjs/)
- - [[48:41](#tanstack-removed-rscs-from-the-website)] [TanStack removed RSCs from the website](https://tanstack.com/blog/we-removed-rsc-from-tanstack-com)
-- [[51:04](#marks-making-progress-on-some-react-redux-perf-prototyping-and-thinking-about-rtk-30)] Mark’s making progress on [some React-Redux perf prototyping](https://github.com/reduxjs/react-redux/pull/2318) and thinking about RTK 3.0
- - [[57:36](#making-referential-stability-a-type)] [Making referential stability a type](https://www.jovidecroock.com/blog/referential-stability-types/)
- - [[59:17](#porffor-native-compiler-upcoming-alpha)] Porffor native compiler [upcoming alpha](https://honk.foo/porffor-alpha/)
- - [[59:39](#perry-cross-compiles-claude-code-bundle)] Perry [cross-compiles Claude Code bundle](https://www.perryts.com/en/blog/compiling-claude-code/)
- - [[01:00:17](#vercel-releases-scriptc-native-compiler)] Vercel [releases scriptc native compiler](https://github.com/vercel-labs/scriptc)
- - [[01:02:04](#goodbye-forever-probably)] [Goodbye, forever, probably.](https://whitep4nth3r.com/blog/goodbye-forever-probably/)
-- [[01:08:41](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:08:53](#sep-11-zurichjs-switzerland)] Sep 11: [ZurichJS](https://conf.zurichjs.com/), Switzerland
- - [[01:09:14](#sep-25-26-react-alicante-spain)] Sep 25-26: [React Alicante](https://reactalicante.es/), Spain
-
-**Carl:** Hello. Thank you for joining us for the July edition of This Month in React, as we recap what's been going on with React Native and other things across the web. We are coming to you live from Reactiflux, the place for professional developers using React. And I'm Carl. [00:00:00]
-
-I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like these events and build tools like help keep the community operating. [00:00:13]
-
-**Mark:** Hi, I'm Mark. My day job is replay.io, where we've built time travel debugging, are working on autonomous QA, and I get to do all kinds of awesome time travel-powered React analysis tools. And outside of that, I am still doing Redux stuff, and I'm actually finding the energy to do a fair amount of that right now, which is cool. [00:00:22]
-
-**Carl:** Nice. Heck yeah. Hell yeah for finding the energy to invest in a project you love. [00:00:41]
-
-**Mark:** Yep. I'm also actually back at home after, like, two and a half months of almost nonstop conference travel. [00:00:47]
-
-**Carl:** We were saying in prep, we have kind of a grab bag this month. There's not, like, one big thing to discuss, but yeah, we're gonna get into a couple things. [00:00:53]
-
-Uh, obviously there's been more security stuff and new releases of major projects, like TypeScript 7, which we've discussed, like, four times already, but y- it's here. Yay. [00:01:00]
-
-We also are gonna get into some open source governance questions. There's been some developments on the React Foundation. And l- kind of out of left field at the same time, Poimandres a cooperative doing open source around Three.js. It also published some governance work. So yeah, we're gonna get into it. [00:01:09]
-
-## New releases
-
-**Carl:** But first, the first new release. [00:01:27]
-
-## [Vite+ Beta](https://voidzero.dev/posts/announcing-vite-plus-beta)
-
-**Carl:** Vite\+ from Voidzero is in beta now. [00:01:29]
-
-**Mark:** It's not paid anymore. Oh, okay. They dropped that. I think they dropped the paid part even before they got bought out. [00:01:33]
-
-They initially said it was paid. Then they said, "No, no, we'll, we'll make Vite\+ free. We're gonna build our own server runtime layer on top of Cloudflare," and then Cloudflare just bought the entire company. [00:01:40]
-
-So- Great ... Plus itself, as far as I know, is going to be entirely free at this point multiply. But it's just the Void Zero company had been paying a bunch of people to build out OXC, you know, that whole layer of parser tooling, partly to use in the Rolldown Rust-based bundler. [00:01:51]
-
-The latest version of Vite uses Rolldown, but then there's all these other Rust-based tools related to that. And so Vite Plus is a combination of we have pre-configured all these different tools into one super package, as well as added some additional layers of functionality on top of that. So it's essentially supposed to be an entire JS development suite in a box, sort of akin to what Rome was promising a few years ago. [00:02:13]
-
-**Carl:** Cool. Love that. [00:02:40]
-
-## [TypeScript 7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) released
-
-**Mark:** Meanwhile, as mentioned, we have talked about this repeatedly, so I don't have to go into a lot of details, but TypeScript 7 is finally live. Hooray. This is the Go implemented native implementation of the TypeScript compiler that is supposed to be up to 10X faster, so the actual... [00:02:41]
-
-If you install the actual TypeScript package at latest now, it is actually built with Go under the hood. The biggest caveats here at the moment, as we've again talked about, the programmatic TypeScript API essentially does not exist in version seven, because the API had been partly official, partly unofficial before that And lots of different tools had various dependencies and needs. [00:03:00]
-
-A lot of them had hacked together solutions in the past, and so the TypeScript team said, "Okay, we know the compiler itself's working. We're gonna get that out the door. We want to take our time and carefully consider what a better and proper public API would look like to support all the different use cases people have come up with, and we'll get that out the door in, like, a version 7.1 or 7.2." so there is some, there is an update on that front. [00:03:28]
-
-## [open PR for “content mappers”](https://github.com/microsoft/typescript-go/pull/4712) to integrate other language syntax
-
-**Mark:** They've put up a PR for something they're calling content mappers, and the way I'm understanding this is that for other languages like, say, View or Angular that have templates, you want to be able to type check the templates. The TypeScript compiler handles JSX, which means React kind of got special treatment there. [00:03:56]
-
-But how can other languages actually get similar behavior for non-TypeScript syntax? And so this content mappers proposal from the TS team is a way that they're hoping they can address essentially a plug-and-play conversion of other syntax into something TypeScript itself can type check. So there, there may be other API integration things that they're looking at as well, but this feels like it's a, a good step in that direction. [00:04:17]
-
-And in the meantime, a bunch of teams are doing things with integrating with TS Go in hacky ways you're not supposed to anyway. [00:04:49]
-
-## Johnson Chu made [a compatibility layer to drop-in for unsupported tools](https://github.com/johnsoncodehk/typescript-native-bridge)
-
-**Mark:** Johnson Chu, who I think built the Alien Signals library, and I think also works on the Vue Volar language extension, if I've got my connections right, put together a package called the TypeScript Native Bridge, which is supposed to help polyfill some of the, I think, the language server-type integrations so that they're faster. [00:04:57]
-
-## [OXC type-aware linting stable](https://oxc.rs/blog/2026-07-22-type-aware-linting-stable)
-
-**Mark:** And then the OXC folks have been doing their own hacky native TypeScript integration to try to enable typed lint rules within the OXC linter. And so the typed linting support has just gone stable as well. So, lot of improvements around TypeScript compiling and checking in the entire tooling ecosystem. [00:05:18]
-
-**Carl:** Interesting. Yeah, type-aware linting would be a really big win. I've wanted that a number of times, and we've never really gotten there. [00:05:42]
-
-**Mark:** TS ESLint has them, but it requires a lot of slower integration and running full-blown standard TS type checking. [00:05:49]
-
-**Carl:** Cool. Can you talk about this install time security, Mark? [00:05:56]
-
-## [NPM v12 and new security defaults](https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation/)
-
-**Mark:** Due to the entire series of supply chain attacks that we've seen happen over the last year, one of the biggest issues has been that packages are allowed to run scripts after install by default. And so you're just arbitrarily executing remote code on your machine with your privileges. And so several other package managers like pnpm had switched to disallowing that by default. [00:06:00]
-
-And so npm 11 still allowed that, but they started adding the options to disable running scripts by default and preparing things. So npm 12 actually does flip the switch on a lot of those options. So npm 12 no longer runs post-install scripts by default. By default, it does not allow a Git repo URL as a valid dependency, and it has a couple other options that it turns off by default to enable security. [00:06:27]
-
-## [Dependabot supports a configurable delay](https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/)
-
-**Mark:** I also saw that GitHub is changing Dependabot, so it now has a cool down by default, so it won't install new deps until, like, two or three days after they came out. [00:07:00]
-
-So we are very, very belatedly, as an ecosystem, finally learning some lessons we probably should have learned many years ago, and changing some of the default behaviors of our tools to try to cut down on the blast radius of some of these malware releases. [00:07:10]
-
-**Carl:** Yeah. And we've covered some of that in recent episodes, so I, let's not rehash it entirely again. Mm. Yeah, definitely some, uh, long overdue changes here. [00:07:27]
-
-**Mark:** Yep. [00:07:37]
-
-## [More React RSC security tweaks for 19.x](https://github.com/react/react/releases/tag/v19.2.8)
-
-**Carl:** As well as, I guess, in w- security tweaks for server components that were just released this week. [00:07:37]
-
-**Mark:** Yep. Looks like another denial of service attack possibility. [00:07:44]
-
-**Carl:** Okay. [00:07:48]
-
-**Mark:** So just bad, bad... So not remote code execution, but bad input freezes the server. [00:07:48]
-
-**Carl:** Okay. Can't have that. That's a denial of service vector. Okay, well that's the, like, brand-new releases we have. There's some other new stuff, but a little bit, like, less, you know... N- we're not gonna start with it, but we're gonna do that towards the end. [00:07:54]
-
-## Main Content
-
-**Carl:** Main content. [00:08:06]
-
-## React org updates
-
-**Carl:** We are gonna start with the React org updates, and we're gonna frame this against the backdrop of, like, open source governance generally. There have been some changes announced by the, uh, you know, React Foundation within the Discord. [00:08:07]
-
-## “Leadership Council” and Working Group structure [on the new team page](https://react.dev/community/team)
-
-**Carl:** There's been, you know, there's been a, a couple of visible changes to the website and PRs to the actual governance repository. [00:08:22]
-
-**Mark:** I specifically had been griping, I think in the last two months, that I have no idea who's even on the React team anymore. And I don't know whether they literally heard me or whether this was just, you know, kind of coincidental timing. [00:08:32]
-
-But they did a significant update to the existing React team page on the website. They updated it both with, you know, current people involved in moving some folks to more of, like, an emeritus status. But the team page now actually reflects a new team structure that is coming out of this React foundation itself, where there's, like, a set of different working groups for topics like, you know, server components and compiler and, and other things. [00:08:46]
-
-But then there's, like, a leadership council that appears to be essentially, like, a, a representative from each of those groups, as well as possibly a couple others. So I still don't, still don't have a lot of details on the actual responsibilities, but we're seeing some visible evidence that they're working on the organization process here. [00:09:17]
-
-**Carl:** Interesting. Cool Curious, the reason I'm in the Discord is 'cause, 'cause somebody reached out asking if I wanted to help with community, and so now seeing a bunch of people listed as on the Docs and Community Working Group and nobody reached out to me makes me feel like I got left out. [00:09:39]
-
-But that's okay. I'm an independent actor, unaffiliated. [00:09:51]
-
-**Mark:** The list of working groups is, uh, server, DOM, fiber, docs and community, compiler, DevX, and React Native. [00:09:55]
-
-**Carl:** Yep. I am s- slightly surprised to see React Native generally put into its own single group, because they're a- at least as large as React. [00:10:04]
-
-I would say technically, you know, problem space they operate within is larger than React itself. So I'm slightly surprised to see it positioned as a single working group under the umbrella of React. But I guess, you know, there's other organizations that are more meaningfully invested in React Native, so, uh, maybe this is more of, you know, division of labor. This is the pipeline more than the umbrella, per se. [00:10:12]
-
-**Mark:** It's also worth noting that there, there's like seven or eight people on the leadership council, which I guess, you know, matches roughly the number of working groups. And then the working group members section is at least a good 20-plus people long for current people, and then there's a set of advisors and a set of emeritus people. [00:10:33]
-
-So there, there's a good 30 to 35 names listed on this page. Like, it's not just, you know, two to three people. [00:10:54]
-
-**Carl:** It's quite a long list, and it is much more specific. I don't know. We just complained about this, and it's really nice to see a, like, full refresh that looks reliable. That's nice. [00:11:01]
-
-## [Stub governance docs](https://github.com/react-foundation-dev/leadership-council) for the Leadership Council
-
-**Carl:** I was reading a little bit of the charter. It is pretty interesting. It looks like they're quite earnestly trying to make this, like, you know, open participation, and I've thought a lot about governance questions and stuff like cooperatives and, like, how do you do... If you have multiple people with opinions about what to do with a project, a shared good, I don't know, it's really hard, it's really hard to do that right in a way that allows people to feel represented and like they have agency in the overall system. [00:11:11]
-
-So I appreciate the challenge of what they are trying to do. It is difficult to set up a general organization that lets many people in many walks of life feel heard. I like the, the way they scoped it as, you know, "the mission and scope of the project is to develop and maintain React and associated open source software. The leadership council will be responsible for technical oversight of the open source project." [00:11:39]
-
-You know, like, this is... I can tell that from reading this, that the way that they are discussing responsibilities and constraints and decision-making and work delegation, like they are very meaningfully trying to make this open participation And with a high bar of quality. [00:12:00]
-
-Yeah. This is, you know, primary source kind of stuff. This is-- The commit on this charter.md document is two days old, so this is, like, brand new. No one has really been... This is a- as yet untested. The processes described here are not currently fully implemented. But yeah, what I see here looks quite good to me. I like it. [00:12:19]
-
-**Mark:** And to be clear, like, the, the repo's public. I mean, I can look at this information right now. I don't-- The- there hasn't been, like, a formal team announcement of the leadership council and the charter per se, but clearly they're trying to put all the pieces together to be able to say, "This is the way we're gonna do things." [00:12:38]
-
-**Carl:** Yes. Okay, I don't see-- I heard rumor of a, uh, pending blog post, but I, I don't see it yet, so... But yeah, I expect that there should be some broader announcement of what this is and what it means and what their intentions are coming soon. But what I see here looks quite good. I like it. It seems like a good effort. [00:12:56]
-
-**Mark:** Like I said, I, I griped a little bit about the lack of visible progress in the last few months, but clearly what we're seeing here, and even what I'd heard about the amount of effort that was needed to just create the foundation in the first place. Like, there is a lot of effort going on behind the scenes, clearly, and there's a lot of good faith intention behind what they're trying to accomplish. Like, this is not just for show. [00:13:13]
-
-**Carl:** Yes. Agreed. [00:13:36]
-
-**Mark:** One of the longstanding complaints about- You know, the community with React and React with the community has been, they do most of their coding work in public, but there's also some that happens behind the scenes in private. And historically, they've had the problem that any time they push a draft PR, people jump on it. [00:13:37]
-
-It's like, "Oh, React is working on this new feature," and they start writing blog posts and tutorials and everything. And so that has actually made the React team less likely to show their work in public, because a lot of times it is an experiment or a prototype, and there's no guarantee that this will even ship at all. [00:13:55]
-
-So there's been discussion on both sides that it would be really helpful if they tried to follow a TC39 stages model, where it's very clear that we are working on concept X. It is a stage one prototype, a stage two, like, we think this is likely. Stage three, this is probably gonna ship. Stage four, it's ready. That kind of thing. [00:14:14]
-
-## Rick Hanlon update on the React team [using a “stage” process internally](https://www.reddit.com/r/reactjs/comments/1v1dsh0/react_rfc_processis_it_dead/oyp9wac/)
-
-**Mark:** And so Rick posted a comment on Reddit saying that they've been trained to follow that model themselves internally and had some success with it. But essentially, they're trying to prove to themselves that they can actually work using that approach before they fully publicly commit to doing that and making the scale, the stages and progress public. [00:14:37]
-
-**Carl:** Yeah, and we've talked a couple times in past episodes about the general challenges, like the tensions there of them earnestly wanting to work in public and having repeatedly tripped over the same problem every time they've tried to of, you work in public and then you get just a bunch of yahoos talking over you as you're... [00:15:01]
-
-You know, the, the people who don't, people who haven't seen the work that went into the current state that is actually now public and end up just re-litigating all the same issues or, you know. So there, there are a lot of very real challenges there, and I earnestly appreciate the continued exploration of how to make that actually functional and work well for as many people as possible. [00:15:18]
-
-## [Pete Hunt and Nick Schrock join Vercel](https://x.com/rauchg/status/2077870043833229692) to run Frameworks/Next and Agent DX
-
-**Mark:** One other small but related item. You know, there are a bunch of React folks at Vercel at this point, and Guillermo just announced that Pete Hunt and Nick Schrock have both joined Vercel. [00:15:39]
-
-Pete Hunt was one of the first advocates for React at Facebook at the time. He did one of the more famous talks that helped get React off the ground in public. He had spent the last few years, I think, working at a company called Dagster that just got acquired, and so this is presumably his chance to move on from that. But the announcement is that he'll be leading the frameworks group in Next.js itself. [00:15:52]
-
-And then Nick Schrock was instrumental in the development of GraphQL as a spec at Meta, and he is gonna be working on Agent DX or something along those lines. [00:16:18]
-
-So Ver- Vercel continues to scoop up more and more of the folks who were involved with React at Meta at some point in the past. [00:16:31]
-
-**Carl:** Yeah, I'm curious to see about the interplay between Agent DX and the GraphQL, because increasingly so, what an agent needs to do with an arbitrary server is get the data it wants And that's what GraphQL's good at. [00:16:39]
-
-Hey. Yeah, I'm skeptical of MCP. MCP is gonna die. Actually, no, it's not gonna die. It's gonna, it's gonna live forever the way that, like, SOAP does. Yeah. It's gonna be an early exploration of a, an A- API, and I think it's going to be widely hated in five years. Calling it now. There's my mark on the yardstick. [00:16:56]
-
-## Poimandres [published a charter](https://github.com/pmndrs/org/blob/main/CHARTER.md) (original [announcement](https://x.com/pmndrs/status/2080303456800080047))
-
-**Carl:** Related to the org updates and open source governance more than that last update, though, Polymanders has published their charter as well. It's been around for, I would say, at least eight years, maybe 10 years at this point. Oriented around Three.js and 3D rendering on the web, I think is a fair characterization. [00:17:16]
-
-**Mark:** A, a number of, number of folks there have prior experience in game development one way or the other. Sort of a set of artists collaborating to build related things together kind of a vibe. [00:17:36]
-
-**Carl:** Yes. Yes. Right. We all have a shared interest, a shared passion in this. You know, I open their website and it's full of WebGL demos with, you know, parallax and physics and refraction and, you know, translucent interact... [00:17:50]
-
-You know, so it's, that's generally what they're anchored around. It's a bunch of artists doing art on the web in different ways, playing with visual technology on the web. And I- when I say playing, I don't mean to diminish. I mean earnest play in the sense of exploration. [00:18:05]
-
-**Mark:** It's also worth noting that was originally developed by one of the, one of the earlier folks in that org, and I b- and I think Z- possibly Zeustin and Jotai and Vultio are still owned by that org on GitHub. [00:18:21]
-
-**Carl:** Yeah. Zeusstand, React Three Fiber, React Spring, Jotai, Volto, Drei. [00:18:37]
-
-**Mark:** Some very solid well-known libraries in the React ecosystem. [00:18:42]
-
-**Carl:** Yes. Yeah. Tons and tons of well-known projects. Yeah, so like, I hope that didn't sound diminishing because I do not mean to diminish. [00:18:45]
-
-These are talented, respected. But yeah, so they, they... As a point of comparison, these other technical, highly technical, highly skilled folks have also published a charter, and I think the React one is a little bit more clearly articulated. I appreciate this charter. It is, you know, it discusses the core principles and what it means to be a member and how decision-making works and how they adopt projects. [00:18:52]
-
-But, you know, it's like the membership is one paragraph and says, "What are the working roles? There's no strict definition of a working role." So it's more vague. There's less buttoned down there. Which makes sense. You know, this is an open source collective of artists who are very talented, and they're very talented in more along technical things. [00:19:16]
-
-Like whereas people coming from Meta are much more experienced in the corporate aspect of precision of language and clarity of, you know, communication and definitions in documentation like operating agreements and charters. So i-it's, I'm positioning these in reference to each other, mostly because of the coincidence of timing of them having both come out at the same time, and because I think that's a really interesting and valuable comparison to draw. [00:19:32]
-
-What does it look like when a corporation helps found a foundation versus what does it look like when artists as part of a collective do the same thing? These are contrasting ideologies creating something, and these are two examples. I think it is fascinating to look at both. [00:19:57]
-
-**Mark:** So let's say they wanna work on a, uh, React Three Fiber version 10 to be able to make use of WebGPU and make it more AI agent friendly. [00:20:12]
-
-## An [example initiative](https://github.com/pmndrs/org/blob/4bd14e20da776ff68f7555a57a01ad0b4999be92/initiatives/03-text-rendering.md)
-
-**Mark:** They'd like to work on their own design system for common look and feel and behavior. And then they also want to work on better quality text rendering in WebGL, apparently. [00:20:20]
-
-**Carl:** Okay. Cool. I appreciate that. Yeah, text rendering is really hard because it's actually insane when you start drilling into the details of how glyphs are rendered on your screen. [00:20:33]
-
-F- 'cause like for instance, if you're on a low DPI monitor, they will do all sorts of crazy sub-pixel rendering in order to make it look, you know, 20% crisper. Which ironically actually Apple gets flack for now because all of their displays are high DPI, and so they don't do those anymore, and then it's really hard to get crisp icons on OSX. [00:20:43]
-
-**Mark:** Yeah, anytime a text rendering article pops up on Hacker News, I end up reading it, 'cause there, there's some deep stuff there. [00:21:01]
-
-**Carl:** Yes. If you see text rendering or Unicode in a blog post title, like I highly recommend checking it out, because you probably take it for granted, and it's probably like insanely complicated. [00:21:08]
-
-Text rendering in WebGL is likely going to be a fascinating project that deserves its own full initiative from a, uh, collective of expert engineers with visual experience. [00:21:18]
-
-## React-alikes
-
-**Carl:** Cool. Okay, let's move on a little bit. Recently, we've been covering more and more React-alike projects. I'm gonna coin it, I'm calling it, these are React-alikes. [00:21:30]
-
-## [Octane](https://octanejs.dev/) from [Dominic Gannaway](https://bsky.app/profile/trueadm.dev/post/3mrn7yd6dzk2t)
-
-**Carl:** Yeah, we've got a new one, Octane, from Dominic Ganaway. [00:21:40]
-
-**Mark:** Yeah. Okay, so there's, there's a whole causational chain here. So Dominic started off by creating a library called Inferno back in 2014 or 2015, and the idea was React similar, but much, much faster. Whereas Preact was, say, like React, but only for the web and as small as possible. [00:21:43]
-
-So, like, there was like a Inferno-React compat library that tried to fill in some of the differences in behavior, but the whole point of Inferno was let's make something very small and very fast. Dominic joined the actual React team and was there for a few years. He left Meta. He, I believe, worked with Rich Harris in some of the Svelte 5 stuff for a while. [00:22:06]
-
-And we actually covered Dominic just in the last couple months because he recently released a- another different framework called Ripple, which tried to pull together a few different ideas, and he also released a JSX improvement language called TSRX, and then iterated on its design a couple times. So he's back, and he has another new framework called Octane, and the sales pitch for this one is very intriguing. [00:22:30]
-
-It's essentially what if we took React's syntax and pretty much almost all the semantics, but we have a compiler, and thanks to the compiler, we can eliminate the virtual DOM, we can get rid of the rules of hooks, and actually have, like, conditional hooks, and we don't need a dependency array. And so there's actually a, a very strong connecting line through all these things. [00:23:04]
-
-It's like what if React, but better in certain ways. Svelte was all compiled. TSRX is a compiler syntax layer. So there's a lot of different previous threads of work that are getting pulled together in this project. Now, I took a look at the commit history for this project. It looks like he only started working on this, like, a month or a month or and a half ago, thereabouts. [00:23:29]
-
-You can pretty s- quickly see the commit messages going from, you know, first test, try this, oops, broke, fix, whatever, to, like, very quickly building up the pieces And he's officially launched it in some sort of like, well, I don't know what the actual version number is, but like he feels it's ready enough for people to try. [00:23:58]
-
-The implementation has obviously been AI built. Here's where it gets interesting. So he just joined OpenAI to work on their own web front end. I believe he'd been using Claude To do the implementation. But in some discussion on Twitter, he said, like, "I am actually seriously pushing Octane forward because OpenAI heavily relies on React in their web stack, and we need to essentially, like, find ways to make that faster and more optimized." [00:24:22]
-
-So there's both the personal history of, "I am very familiar with React and its ecosystem, and I'm trying to push it to the next level, and now I have a day job that will fund me to do that, and also g- they get to benefit from them." One other interesting technical point out of this. So it's React syntax and almost React semantics, but it's totally different packages, which would normally mean that there's no ecosystem out of the box because there are no packages that import from Octane. [00:24:55]
-
-There are packages that import from React. So if you look at the Octane repo, there is an entire subfolder where he has programmatically built adapter layers for commonly used React libraries to make them work with Octane, ranging from component libraries to, in our case, React Redux and Redux Toolkit. [00:25:28]
-
-Essentially, look at the actual source code, create a port or thin adapter layer that imports from Octane instead, and I assume they work? So it's brand new and no one's using it yet, but this looks very genuinely fascinating on multiple levels. [00:25:51]
-
-**Carl:** The thing I'm observing on the homepage in the announcement, you know, code snippet, it looks extremely familiar, except for there's no return in this function, which is strange. [00:26:10]
-
-**Mark:** That'd be the TSRX. [00:26:22]
-
-**Carl:** Right. [00:26:23]
-
-**Mark:** In fact, n- notice if you look carefully, there is a, there's an @ symbol right before the opening curly brace. That's apparently the TSRX symbol that this just auto-returns. [00:26:24]
-
-**Carl:** See, I don't like that. Th- th- those feel like personal preference decisions that don't actually really matter. It reminds me of, like, CoffeeScript. That was so mixed. It was so perfect. They had the single versus the double arrow function, which would change the behavior of binding this. You know, a hyphen greater than did normal function binding, and equals greater than bound this automatically to the function. And people loved that so much that we pulled it into this language, and that's where we got arrow functions from. And I don't think that this at symbol justifies it to the same degree. Like, I don't think implicit return... Like, JSX had an implicit return, too. You know, it was like you add braces or you don't. [00:26:34]
-
-And so adding a new symbol to the language in order to change the behavior of something that we already have a, a variable on, I think is gonna be a distraction. I think that's a, I think that's an API failure, I would say. Like, the rest, plenty of these, you know, the rest of these all seem... It bothers me that it's so close to being familiar, while m- making a, a dramatic departure like that. Implicit return is a big difference. [00:27:18]
-
-**Mark:** It's worth noting that it does support both existing JSX syntax and the new modified TSRX syntax, so it is pick and choose. [00:27:45]
-
-**Carl:** Skeptical. It's interesting. Overall, I think this is a really good idea and a good direction to explore. I'm reacting strongly to that small note because I think this is good to explore, and that feels like a, that feels like a unintentional self-injury that will make it more difficult for this to succeed, I think is why I'm calling it out. [00:27:54]
-
-But yeah, I think that's really cool. Like, you know, boom, they got a use effect in an if. Can't do that in React. So conveniences like that seem really cool, and I'm excited to see if this works, and I hope that it doesn't introduce foot guns that make it less successful. [00:28:11]
-
-## Ryan Carniato: ["React’s staying power is because of complacency"](https://x.com/RyanCarniato/status/2072382108535066640)
-
-**Mark:** Yep. That ties into the next bit conveniently because we organized it that way. [00:28:27]
-
-I think partly in, in response to the release of Octane and some other related discussions, Ryan Carniato had a couple tweets that relate to this. So, like, you know, one of Solid's selling points has been that it mostly looks like it re- like React. It uses JSX syntax. It is JavaScript inside. Okay, the state and the effects are different, and the getters are different. [00:28:31]
-
-But, like, it looks like React much more than Angular would be. So Ryan had a couple tweets where he was commenting that, you know, at this point, he feels like the... React is commonly used largely because of complacency. It's the modern no one got fired for choosing IBM kind of a thing. [00:28:52]
-
-## Follow-up: [“Do people think FE innovation is dead? Would explain why there’s resistance to move past old React.”](https://x.com/RyanCarniato/status/2081813329681711152)
-
-**Mark:** And then he also had a, a tweet commenting on, like, do people just not feel that there's going to be any more innovation in front end? So I mean, like, he's been talking about a number of these points for a while, so, like, there's not necessarily, like, new changing details there. That, we've talked about this before, you know, AI is sort of encoding React as the default, and we're also still stuck in writing, like, 2019 era React and not even using a lot of the newer APIs. [00:29:12]
-
-**Carl:** Yeah. I do appreciate this chat shout-out. "Directly contradicts the meme of a new framework every week." Like- [00:29:47]
-
-**Mark:** Yep ... [00:29:52]
-
-**Carl:** all right. Yeah, can't have it both ways. We're literally, the JS ecosystem is criticized for all things at every moment. [00:29:53]
-
-**Mark:** I mean, why not both? We can have a new framework and nobody uses it. [00:30:01]
-
-**Carl:** Yeah. True. Entirely real. [00:30:05]
-
-**Mark:** I mean, the number of times I've seen new "React state management library" posted on r/reactjs, man. [00:30:08]
-
-**Carl:** Yeah, you know, actually, I'm gonna tie that back to what you just said of not moving past 2019 era React. People are still doing 2019 era open source announcements of, "Hey, I made a new library." [00:30:14]
-
-And like, yeah, that worked 10 years ago. I don't think it works anymore. But yeah. [00:30:26]
-
-## Parallel articles on [Solid 2.0 with async](https://www.brenelz.com/posts/learning-solid2/), and [Remix 3](https://malstrom.me/blog/learning-remix-3)
-
-**Mark:** One last little point on that note. We've talked before about both Solid 2.0 being in beta and having some new, uh, async features with the asynchroness baked directly into the signals graph. And someone put up a good, you know, w- very well-written tutorial-like post illustrating both just the overall usage and talking about some of the nuances there. [00:30:31]
-
-And then someone else explicitly ported the example app into Remix Version 3 as a intro to how you would do things with Remix 3 as well. [00:30:55]
-
-**Carl:** Cool. Nice. Love that. Anytime somebody does a direct port of one app to a different framework, especially in demos like this, I love it. I listen to a lot of economics, and there's a big thing, uh, in that field about natural experiments. Like, you know, y- some decision is made, and boom, now you have a randomized population that you can determine the outcome of that decision on. [00:31:07]
-
-This feels like this, uh, open source equivalent. Somebody made a demo app, somebody else ported it to an different framework, and now we have a very pure comparison of those two frameworks. [00:31:29]
-
-I have always thought it would be incredibly valuable if we had a, like, representative, like, "No, this is the best possible to-do app in nine different frameworks." [00:31:40]
-
-**Mark:** That was the whole to-do MVC website back in the day. [00:31:50]
-
-**Carl:** But then, like, they all suck. I feel like none of them achieved... Individually, none of them were actually good enough to wear that mantle, and so it was like, wait, actually, these are not, this is not... [00:31:54]
-
-Or, I don't know, maybe that's just a reality of the fact that you cannot actually have a single the best anything because there are nine different approaches to doing tables in React, and so you cannot make a single definitive React to-do list. But, oh, man, I... So anyway, that's why I love that somebody has ported one demo app from one framework to another. This is really good. [00:32:03]
-
-## [Cross-framework benchmark measuring reactivity](https://bsky.app/profile/nullvoxpopuli.com/post/3mrplyqcd722j)
-
-**Mark:** All right. So there, there's a long-running JS frameworks benchmark that's been out there that measures things like loading performance or swapping items in a long list, et cetera. That has been, like, the holy grail that every new framework tries to add and measure itself against. [00:32:22]
-
-NullVoxPopuli, who is part of the Ember community, has put together a sort of similar benchmark, but trying to solely measure the reactivity and re-rendering portion of it. [00:32:40]
-
-I only glanced at it. I don't fully understand the nuances and the differences of how, like, what is being measured differently than the, the JS framework benchmark. But I've, I've watched this person long enough to know they have a pretty good idea what they're talking about, and so they're trying to measure more about, like, the, the state update sequence, I think, than necessarily just, like, DOM loading time or something to that effect. [00:32:53]
-
-**Carl:** Yeah. So I mean, this table has- Incrementing render effect. So I guess that means the length of time it took to render and then produce an effect that would increment and then thereby trigger a re-render, an infinite loop, it sounds like. And it's saying React took 8.7 times longer than the baseline to just do that. [00:33:19]
-
-Which is, [00:33:38]
-
-**Mark:** which is Angular apparently. [00:33:39]
-
-**Carl:** Yes. Or the baseline there was solid, but yes, most of these Angular is the, is the benchmark. [00:33:40]
-
-Okay, this is interesting. So this, these are a lot of... This does look like a pretty solid stress test. You know, like 1,000 item list, one update on 25% of items at random. Like, that's pretty good. You know, that reminds me of like a stock ticker, you know, a table of stock results with real-time prices updating. [00:33:47]
-
-**Mark:** Interesting. I actually just dealt with that scenario in the React Redux prototype branch that I'm working on. I'm going to have to go steal some ideas from this, for this one too. [00:34:06]
-
-**Carl:** Ah, there you go. [00:34:14]
-
-Yeah. I had to render sparklines once, and do you know how many DOM nodes are in a sparkline? Do you know what happens if you render one sparkline for 30 table results? So I, yeah, the optimization that has to go into that is kinda crazy sometimes. But yeah, cool. This looks like a very good benchmark. And yeah, it is in fact saying that Angular has the best performance as rendered by time spent- [00:34:15]
-
-**Mark:** Doing the data update work, I think [00:34:38]
-
-**Carl:** the values here are not super-duper helpful, I would say. The options here are values raw, so I don't k- I, like, I don't know if that's raw on milliseconds. I don't know what unit's it in, or a score, which is also not helpful, or multiplicative relative time. So anyway, this is really interesting. I think this has potential to be very helpful. [00:34:42]
-
-Benchmarks are great, and we have a new one. [00:35:02]
-
-## Aiden Bai released [ReactBench to measure AI code quality](https://www.reactbench.com/)
-
-**Mark:** And then one other benchmark, Aiden Bai, who has been on a tear releasing various kinds of React-related analysis tools, right up my alley, put out a React bench to try to measure how well different AI models write React code. He put together some kind of a scoring metric for common mistakes and patterns, and is measuring how well they actually write good code versus bad code. I'm assuming that a fetch in a use effect is scored as bad. [00:35:04]
-
-And for the record, apparently GPT 5.6 is leading at a 53% score on the benchmark. [00:35:38]
-
-**Carl:** Cool. Interesting. I love this because this is such a, like "code crafts person" versus "fuck it, ship it" attitude. This is something I felt like I had to get over in my professional career, 'cause I jumped around employers so many times, and I was so close to the React ecosystem, it's like, "Oh, cool. [00:35:45]
-
-I know all the best practices. I know how to do it right." And then you join a company, it's like, "Oh, you're just putting a component in state? Got it." Yeah, I bet the, I bet all of these models are trained on some pretty garbage code, because most of the code in the world is complete garbage. And I think that's very clearly demonstrated by the highest score on this being 53%. [00:36:00]
-
-**Mark:** I'm gonna have to go dig into that benchmark to see what they're actually scoring things on. [00:36:20]
-
-**Carl:** The time I saw a component being put into state was during a take-home test... No, during a whiteboard interview for a new company, and I terminated the interview because I was like, "If you're doing this, then I do not wanna work here. I am so sorry." [00:36:24]
-
-## [Alex Russell blasts “state management”](https://infrequently.org/2026/07/state-management/) (and most of the React ecosystem) in favor of sync engines
-
-**Mark:** All right, so that, that ties into our next item. Alex Russell wrote a, as usual, incendiary blog post blasting the React ecosystem and its practices. And as always, it's a very well-written post, and I actually agree with and understand a lot of the points he's trying to make. I disagree with the conclusions and the way he's messaging a lot of them. [00:36:37]
-
-**Carl:** Yeah. [00:37:05]
-
-**Mark:** So his first argument is React has built-in state management, but the existence of dozens and dozens of state management libraries must mean that either React isn't a state management system or React is an insufficient state management system. And I think we would all agree it's, it is a state management system, but it's very insufficient, the fact that it's all tree-shaped. [00:37:05]
-
-So that's why we have all these external state management libs. He then goes on to, to blast the fact that there's the plethora of external state management libraries and that they're all big and complicated and basically just pub/sub event emitters. But where-- He then takes it in a very surprising direction, which is essentially that all these different state management libraries, quote, and I will paraphrase, "Don't actually manage state." [00:37:32]
-
-They store a value at a point in time. They are pub/sub and trigger updates, but they don't have any sense of what was the state over time or how do you intelligently merge in changes over time. And so he then points to sync engines and CRDTs as essentially this is what I think is the right way to manage state. [00:38:02]
-
-Of course, half his argument is all these libraries are large and then people do bad things for SSR and hydration and send down massive JSON blobs, and that leads to bad perf. But he's also primarily arguing that the entire way the React ecosystem uses the word state management is wrong, and that almost everybody would be better off using some kind of a sync engine or, or CRDT to both auto-merge changes as well as manage the time aspect of changes. [00:38:36]
-
-I hear what he's saying. I disagree on a number of levels. When I wrote my Redux versus Context post a few years ago, I actually explicitly said that to me, a state management tool is, well, essentially pub/sub. You store a value, you have a way to update it, you have a way to read it, and a way to trigger updates. All these libraries fit that category. He's the one trying to put the extra dimension of time on top of that. [00:39:12]
-
-I agree sync engines and CRDTs are useful, and that probably a lot more people ought to look at them. But I feel like saying these are a blanket solution that almost everybody should go with if, you know, assuming you're doing more than just server-side rendering, feels like it's a pretty big step. [00:39:39]
-
-And so I had a bit of a debate with him on Blue Sky about this, kind of trying to probe and get him to expand on a few of the thoughts, and he eventually did say that like, "Yeah, I'm basically saying that everyone needs to have a major mental shift in how they approach thinking about state whatsoever In applications." [00:39:59]
-
-Which I get what you're saying, and number one, that's not going to happen, and number two, I don't agree that it needs to happen. [00:40:18]
-
-**Carl:** Yeah. The, specifically that thought, that expressed thought of, "the problem here is that everyone else is thinking about this wrong and everyone needs to learn this new thing in order to do it correctly." [00:40:25]
-
-Categorically, I'm gonna say that i- if that's your defense, it's ineffective. Like, no one has, no idea has ever been adopted to that extent. Like, the best you get is something like React. React is one of the most widely successful used technologies like that, and we're discussing how badly abused it is. So like, no, you are never going to get everyone to do any particular thing in a particular manner. [00:40:39]
-
-I also empathize. Like, most state, quote-unquote, in React apps is actually cache. You know, and we've discussed how, like, most state should just be like React Query, because actually you're just caching network state. This is not your local state. [00:41:06]
-
-**Mark:** Use Nuxt, put more of it in the URL so it, it survives a page refresh. You know, use, use uncontrolled form inputs, that sort of thing. [00:41:20]
-
-**Carl:** Right. Right. And so sure, it is probably technically, from a technical perspective, it is correct that we are misusing state. State is a precisely def- defined technical term, and we are probably misusing it. We are certainly misusing it. But like, I don't know, what are you gonna do about it? [00:41:29]
-
-**Mark:** I tried to hint at this in the Blue Sky thread, and you didn't really bite on my train of thought and went in a different direction. But like, I'm a big fan of going back to how did we get here, what problems were people trying to solve? Problem A leads to problem B leads to problem C. Each stage builds a new tool to try to address the previous problems we had. [00:41:48]
-
-We went from, you know, you can't do JavaScript in the browser to you can do a bunch of JavaScript in the browser to, okay, y- we've got jQuery to make it easier to work across browsers, but you're just toggling a class in the DOM. You're hoping that the DOM is what you think it is at that point in time, otherwise it breaks. It's hard to scale all these jQuery click handlers. What if we tried using actual variables to keep track of this data? How do we start to write larger scale structures and architectures? Keeping track of all this logic's hard. What if we just declared what we want it to look like and let the framework take care of it? Okay, we're having trouble keeping that data in sync across large parts of our apps. [00:42:08]
-
-So I'm not saying that the current React or front-end ecosystems are Great. I'm not saying that they are, like, you know, absolutely the best possible theoretical way we could have landed on doing things, but I do think it's important to say, "This is how we got here, and this is the real world current state of things. What can we practically do to improve things?" [00:42:50]
-
-And so I would be very happy to have conversations with Alex about, like, "Okay, here's how the React ecosystem got here. I'm sure you know this already, but, like, this is where we are. Here are some influ- here's are some ways we could try to nudge things and push people towards mentally modeling." [00:43:20]
-
-But just starting off by saying, "React claims to have state management and it doesn't fit my definition, and therefore it's wrong, and everyone else has weighed these things on top that aren't my definition, therefore they're bad, and also bad at perf." I get that he- a little bit of this is him venting, and I think part of it was the, "I've had these discussions, let me write down my thoughts so I can refer to them." okay, cool, agreed. But it feels a little bit like shouting into the void, and it's not going to improve the situation at all. [00:43:36]
-
-**Carl:** Right. Yeah. Like, there are two little trigger phrases here that make me go, "Er." And one is the first sentence. "It is by no means the gravest linguistic crime of the React epoch, blah, blah, blah." [00:44:05]
-
-But, like, okay, so, like, literally this starts off announcing that a gripe on semantics. Th- this is framed as a linguistic crime, so it's just definition and what are we talking about. And then at some point it's like his stated resolution here is, "Devs should..." And like, boom, done. You lost me. Devs is not precisely defined. Who are you talking about? Who needs to make a change? [00:44:15]
-
-And you just say should. Like, devs should do something. Like, I don't know. Any- anytime somebody uses a general statement about a large population to say, "Everyone in this group should do X," like, you're wrong. It does not matter who you're talking about or what your idea is. [00:44:38]
-
-That is never correct. So right. I, like, I broadly agree with the perspective here as I- correctly identifying a problem. [00:44:53]
-
-**Mark:** As my mom used to say to us many times growing up, "You stated the problem, now state the solution." [00:45:02]
-
-**Carl:** Right. It's a problem. The solution is hard. [00:45:07]
-
-Like, there are lots of very smart people working very earnestly on this problem. You know, we as an industry are exploring the cutting edge of UI and what does it mean to interact, you know, human computer interaction used to be considered a field of academic research. And, like, all of us are HCI experts with no credentials and no... [00:45:09]
-
-Like, you know, there's no scientific rigor behind the experiments we do. Our company, our companies just say, like, "Oh, I think this should be-" A dropdown instead of a type ahead select. And like, you know, okay, why? Oh, well, you know, that's what the design, that's what the design spec calls for. Okay, well, why? Well, that's what the designer wrote down. Well, okay, does that, how would people interact with that? This is a human computer interaction question, and there is a body of research. [00:45:30]
-
-We are earnestly exploring all of this without the support of traditional, like, in years past, in decades past, people doing this type of exploration of a, a problem space might have the support of things like academic journals with peer review, and then ultimately, if it's published in this journal, then you can trust that it went through this review process and, you know, that by being present in its current form, it represents a consensus from this perspective. [00:45:56]
-
-And like, we don't have that. We have blog posts. Like, you know, we have vibes of popularity. So like, we're exploring a really challenging problem space without very much ability to capture the results of those explorations, and that's a very hard space to be in. But that to say, I think there's a lot of really interesting stuff happening with sync engines, Electric SQL. I've, I remember hearing about a long time ago, the... Oh, God, I can't remember some of them. There were a lot of really good sync engineed and local first- [00:46:26]
-
-**Mark:** Electric, Zero, Replicache, maybe that, maybe those are the same company. Howard Sync is out there, I think. [00:46:55]
-
-**Carl:** Yeah. Thank you for filling in the gap. I have lots of the ideology and less of the, uh, proper nouns. [00:47:02]
-
-But so yeah, yes, correct. This is a problem. People do misuse date, quote, unquote. But yeah, the way you change that is by effectively broadcasting a message that allows people to observe that their previous practices were incorrect and guides them into more correct practices. [00:47:07]
-
-**Mark:** Update the docs, add a linter, build it in by default. [00:47:27]
-
-**Carl:** Right. None of those include an angry blog post. I relate to that as someone who wishes to write angry blog posts, but I don't think it's an effective solution to the problem [00:47:30]
-
-## Aurora Scharff [rewrote the Suspense docs page to cover how it works](https://react.dev/reference/react/Suspense#what-activates-a-suspense-boundary)
-
-**Mark:** Aurora Scharf, who has been doing a lot of fantastic conference talks and blogs on using Next.js and using Suspense in the last couple years, joined Vercel and i- in a dev role, role, and has been, I guess, part of or working with the React team. [00:47:41]
-
-I think she's actually listed on the team page. And so she actually just did a significant update to the Suspense docs page to add a lot of details on what are all the cases that actually trigger a Suspense boundary, as well as some of the, the other use cases. So again, great to see a lot of the, the usage and technical details being fleshed out in the official docs. Always something I'm asking for. Yay. [00:47:56]
-
-## And a post on [RSC performance patterns](https://aurorascharff.no/posts/experimenting-with-rsc-for-performance-and-ux-in-nextjs/)
-
-**Mark:** Uh, and then she also wrote on her own blog a, a post on some various Suspense-related usage patterns that she's been playing around with. [00:48:22]
-
-Cool. [00:48:31]
-
-On the flip side, the TanStack folks have added initial server component support in its own form to TanStack Start. We've talked about that in previous months. [00:48:31]
-
-## [TanStack removed RSCs from the website](https://tanstack.com/blog/we-removed-rsc-from-tanstack-com)
-
-**Mark:** And I believe they had been using that in the actual TanStack.com website, primarily to move heavy markdown rendering to the server so you weren't shipping the, the markdown rendering logic to the client and having to wait for that to happen. And apparently they've removed that. They put up a post saying they actually pulled out the server component usage. [00:48:41]
-
-It worked, but it, they weren't getting a lot of benefit out of it, and it was actually hurting perf in some ways. And instead, they have restructured things. They've actually shipped a couple of very tiny libraries to do markdown parsing, and then separately, syntax highlighting. And so essentially going back to a somewhat more SPA-ish approach, but minimizing the amount of work done so they still get fairly fast loading times. [00:49:01]
-
-**Carl:** Nice. Let me tell you, doing syntax highlighting on a documentation site is fucking crazy. I underweighted that as a problem circa 2018, and it almost killed the entire project, because we had wanted a single API reference page constructed from dozens of markdown documents, so we could maintain it as individual docs, but have it presented in a single, large, searchable page. [00:49:26]
-
-And holy shit, we were shipping 12 megabytes of HTML across the wire because of syntax highlighting. We took syntax highlighting out, and it dropped to, like, you know, 600 kilobytes. Which is still insane, and, like, part of the reason it almost killed the project, because we just were trying to put too much docs on one webpage. [00:49:48]
-
-But- Yeah, man, like when you start highlighting individual, every individual character and wrapping it in glyphs, in a span which has a class name, and, uh, so it's, it is insane how much markup bloat gets added just by syntax highlighting. So moving that from rendered on the server, shipped to the client, into data is passed from server to client and then rendered on, on the client makes total sense to me. [00:50:05]
-
-But that's why this is the cutting edge of UI, 'cause like that sounds so obvious. Of course you just want a rendered page to come directly from the browser and oops, that rendered page is 20 times larger than it could be if you just sent the raw data needed to render it. So that's why it's so impossible to answer the question abstractly of whether or not server components are right for you, 'cause I don't know. Do you know? [00:50:32]
-
-Anyway, that's a fun project. This is a really good case study. I love it. [00:50:56]
-
-Mark, tell us, I'm giving you an opening to talk about your performance prototyping. [00:51:00]
-
-## Mark’s making progress on [some React-Redux perf prototyping](https://github.com/reduxjs/react-redux/pull/2318) and thinking about RTK 3.0
-
-**Mark:** So I'm pretty sure I alluded to this two months ago, and then I linked the draft PR last month. But for the last few years, I've been kicking around the idea that surely there is some way that I can magically use some combination of signals and proxies inside of React Redux to speed up performance updates in large scale applications. [00:51:04]
-
-So cases where you have thousands of connected components, and right now we have to run all end subscribers and selectors on every dispatched action just for each selector to grab its state and diff the result and see if it needs to update. That's fine when you've got 500 or 1,000 components. When you've got 5,000, 10,000, whatever, that's just the overhead of calling those subscribers is expensive. [00:51:26]
-
-So I played around with a couple proof of concepts in previous years. They were like, you know, like one-off, I'm gonna hack on something, and didn't get any further. So I finally came back to that , and I did a whole bunch of research on other signals libraries, proxy-using libraries. What do they do? How do they work? What are they good at? Where do they break? All very AI powered. [00:51:54]
-
-And I have a working branch that adds a useSignalSelector hook to React Redux that is using the Alien Signals library inside. And essentially what it does is it wraps your selector so that the data is in a proxy, tracks what fields got accessed, and then essentially precomputes, "Hey, this was the state that got updated. Do we think that selector actually needs to run? Nah, skip it." With the idea being that in most cases, only a relative handful of selectors actually need to rerun most of the time. So if we can just pre-skip most of them, that ends up being a performance win. [00:52:16]
-
-So I have a draft PR. It works, and it appears to be a significant performance win almost across the board. In terms of the number of updates, in terms of the total amount of scripting time that executes. It's a little bit slower in the mounting phase because it takes more work to set up the signal and the tracking time. [00:53:03]
-
-There's definitely going to be some bigger bundle size. I don't know how big, like 5 to 10K maybe. And there's also a few weird cases, like doing certain identity comparisons won't work because you're comparing the proxy reference and not something inside the proxy. [00:53:25]
-
-But it feels good enough, and I've got solid enough test coverage that I actually feel very good that, like, this is a, this is the direction that I would probably end up shipping. There's a lot of work to figure out around real-world testing and, you know, like all, all the, all the non-fun stuff around actually shipping real software. Uh, but the idea is it would be a separate set of exports. You would intentionally choose to use this. So like most apps would still have useSelector by default, but if you have a large-scale app and performance is a problem, then-- And you, you could choose to import this and make slightly different trade-offs in performance and bundle size. So I feel pretty good about that, and I'm, I'm still finding time to try to push that direction forward. [00:53:41]
-
-I'm also thinking about what a notional Redux Toolkit 3.0 would look like. Uh, a couple years ago when I shipped 2.0, and I said at the time that I was deferring touching RTK Query at all because there's some unknown number of breaking changes we would probably wanna make. I don't even know what those are. We'll just kick that can down the road. [00:54:32]
-
-Well, we've successfully kicked the can down the road almost three years at this point. Uh, the ecosystem is actually going ESM-only at this point. So presumably, if and when we do a 3.0, it would be ESM-only. Um, but I've had a bunch of things on my mind in terms of rough spots in our API and the way the internals have just evolved over time, but in a kind of haphazard way because people keep asking us to add options or capabilities, and we just added them without ever really, like, doing a coherent design upfront. And so there's, there's a bunch of pain points I've known about. There's a bunch of things I would like to improve. But they were all, you know, if, maybe, someday. [00:54:53]
-
-And so actually just in the last 48 hours, I did a whole bunch of AI-powered research tasks saying, "Here's all the things I would like to have, the properties and qualities I'd like to have in a 3.0, um, some new options I'd like to add that we can't do right now because they break with TypeScript. [00:55:38]
-
-Could we possibly come up with some kind of an API design that looks basically the same But is just different enough to clean things up and unlock the constraints. And, uh, as of last night, I've got a local prototype that Claude claims actually, like, does most of what I wanna do. So, like, noth- nothing's happening anytime soon over here, but, like, I actually have had the time and effort to do this because the AI can do the dirty work, and frankly, I didn't have the time or effort or mental capacity to do that work myself. [00:55:56]
-
-And so being able to tell it, "Here's what I want. Can you just, like, run for a while and, and come back to me and tell me if this works?" has actually made this possible, which is actually pretty cool. So nothing's, like, nothing's gonna ship anytime soon, but I actually like the direction this is going. [00:56:29]
-
-**Carl:** That's super fun. I love having problems within a box that is clearly defined enough to where AI can do it in that kind of way. A lot of the problems I've been exploring are primarily in my head, and so getting them out of my head and into a state that AI can check against is its own task, and so it's a problem. [00:56:47]
-
-**Mark:** Part of me feels a little bad that some of my contribution here was just saying the equivalent of, "I don't like that answer. Try again. Think harder." But also, like, I had to come up with, "Here's the list of constraints that I want to satisfy and the problems I want to solve, and here's the list of the prior research we did. [00:57:04]
-
-Now go think hard on these things." Like, I am actually driving the work here. [00:57:23]
-
-**Carl:** Right. Having that body of knowledge and research is critical, and is real work, and should not be discounted. [00:57:28]
-
-## [Making referential stability a type](https://www.jovidecroock.com/blog/referential-stability-types/)
-
-**Carl:** Cool. Into a couple of final details before we wrap up. This is a fun aside. Making referential stability a type. So React relies pretty heavily on referential stability, which is triple equals equality. If you have two objects or arrays that are equal to each other, it is literally the same reference. It is the same pointer. It's in this, the same part of memory. [00:57:36]
-
-And someone made a type that represents that, which is crazy. I don't understand how they did that. I saw our resident TypeScript wizard here, who is the person-- I think they're the only person who's answered any types question I've had in the last, like, decade, possibly literally. My favorite types wizard said, "Oh, cool. I tried to do this and gave up." Which I just love. Like, yeah, this is a hard problem. It's really cool. It would be really nice to have. Somebody seems to have put together a real effort at it, and I love that. It's cool. [00:57:59]
-
-**Mark:** Yeah, what they bork on both Preact and GraphQL. They're one of the Preact maintainers. [00:58:31]
-
-**Carl:** Oh, cool. I love that. Wow. Real-- I don't know. They got real chops. Yeah, core team of Preact, Urql, and- Gql.tada. So yeah, okay, they've got some real experience with wrangling complex data. That's awesome. [00:58:35]
-
-**Mark:** There's been an interesting set of different projects around trying to compile TypeScript code to true native code. [00:58:48]
-
-One that's been out there for a while is called AssemblyScript, and it's essentially a, a restricted subset of TypeScript, not full-blown true JavaScript semantics. But there's three different projects I've seen recently that are attempts to compile just straight-up TypeScript code to native code in some form. [00:58:57]
-
-## Porffor native compiler [upcoming alpha](https://honk.foo/porffor-alpha/)
-
-**Mark:** One's called Porffor, which is a... It's a single-person project. He's been posting about this for a while and doing a lot of performance optimizations on the output lately, and even making the compiler self-hosting. So he announced that Pro4 is about ready to hit alpha stage in the next few weeks. So that, that's a pretty massive technical achievement there. [00:59:17]
-
-## Perry [cross-compiles Claude Code bundle](https://www.perryts.com/en/blog/compiling-claude-code/)
-
-**Mark:** A second one called Perry that I, I don't know who's working on this, but I saw it pop up pretty recently. So they're also trying to compile TypeScript to native code, and they recently put up an article about taking the entire, like, 13-megabyte Claude code bundle that ships on disk and compiling that to native. [00:59:39]
-
-And part of it's the compilation process, and part of it is all the semantics and non-JS bits that it expects, like relying on the, the message channel, message port interface to, to send messages back and forth over a microtask. [01:00:02]
-
-## Vercel [releases scriptc native compiler](https://github.com/vercel-labs/scriptc)
-
-**Mark:** And then Vercel just announced something called ScriptC, and this is apparently in their Vercel Labs area, which is where they put all their vibe-coded projects. And, uh, boy was this one vibe-coded, I think someone on Hacker News points out that the first commit is 800,000 lines a week ago. Yeah, so who knows what the actual quality is there, but they're playing around with that. So Bunch of different people trying to solve the same problem of, it's both the publishing aspect and the runtime execution speed aspect. [01:00:17]
-
-**Carl:** Cool. Interesting. Well, I would love it if we had some more native compiled… what attention we experience, because native compiling is also the thing getting suppressed by NPM for security reasons. So yeah, what, what attention the ecosystem is under right now of moving away from compiled dependencies, but also being very hungry for the kind of performance improvements that native code is capable of. [01:00:52]
-
-**Mark:** I mean, I think in general, packages that have a native dependency used to rely on a postinstall script to check your local environment and then go manually download the binary. And at this point, most of them, like ES Build, have switched over to we're just gonna publish a se- a separate package for each possible native architecture. [01:01:21]
-
-And then the package managers have gotten smart enough to say, "Oh, well, each of those packages lists a certain native environment that it needs. Let's only actually install the one that matches your current environment." [01:01:42]
-
-**Carl:** Fair. Interesting. Complex, nuanced, subtle. [01:01:57]
-
-**Mark:** Programming. [01:02:01]
-
-**Carl:** Programming. Facts. [01:02:02]
-
-## [Goodbye, forever, probably.](https://whitep4nth3r.com/blog/goodbye-forever-probably/)
-
-**Carl:** Cool, okay. Our last link for you today is, I don't know, it's kind of sad. [01:02:04]
-
-Goodbye Forever, Probably. [01:02:09]
-
-**Mark:** It's very personal. [01:02:11]
-
-**Carl:** Very personal. This is by Salma Alam-Naylor, who goes by White Panther online. They were a very talented developer relations person for quite a while. I feel like they sprung up out of nowhere, or at least I didn't see them before they were huge. And I always thought they were very, very, just very skilled at it. [01:02:12]
-
-I thought they did a really good job of being technically at the cutting edge, while being, like, personable and entertaining. And, like, that's really hard. All three of those is really hard to do. But, so anyway, she put out this blog post called Goodbye Forever, Probably: Why I'm Leaving Developer Relations and Why I'm Not Telling You What's Next. [01:02:30]
-
-And oh man, I gotta say, a lot of this resonated with me. I've actually never had a job described as developer relations. I'm just a developer who blogged and has engaged with the community, which then later turned into the job of developer relations. This whole thing I relate to so much. Like, the number of times I've sat and seriously contemplated if I wanted to keep doing what I was doing is, like- At least five, possibly more than 10. I think about it often. [01:02:50]
-
-And I've always stuck it out. I don't know, here I am. Probably because nobody's paying me and because I have full agency over everything I do, which has its own different trade-offs. And yeah, I don't know. This is just a really good articulation of how hard it is to be publicly visible in tech and to get paid for it. [01:03:18]
-
-And I think that if you are someone who consumes tech content, this is a really good read to see what it's like on the other side of the page. [01:03:34]
-
-**Mark:** Yeah. So, um, makes a, an, a bunch of different points. A lot of it is around dev rel as a job role, that it's, it is by its nature really hard to measure. You know, how are you... Like, what metrics are you being measured on? How are you trying to contribute to the company? How do you even know if you're having success? What is your role? Are you going to conferences, writing blog posts, writing documentation, that sort of thing. [01:03:43]
-
-But specifically she also talks about being heavily overworked at multiple companies, and that contributing things. She'd spent a lot, a lot of time streaming. That was a really big part of her online persona, both in and out of the day job role. So that, that sucks up a lot of time and effort. But then also talking about AI killing teaching content. When she linked this post publicly on Blue Sky, there was a massive number of responses, and I know somewhere down in the replies, Josh Comeau said that he's looking at taking a break from building courses as well. [01:04:06]
-
-So when you put in massive amounts of time and effort to carefully craft a teaching course, and then either y- you don't get much payoff because people aren't buying it or the content essentially just ends up getting swiped Yeah. Like, why put in the time? [01:04:42]
-
-**Carl:** Yep. I was thinking about Josh and this as well, 'cause Salma says here, "I've too often overworked myself in desperate attempt to justify my existence. This has more than once caused me to suffer from health problems, including joint and nerve pain. At its worst, I couldn't even use my hands due to the pain." [01:05:00]
-
-That happened to Josh. Like, both Josh and Salma had to learn to code with their voice because of hand injuries as a result of overwork. So, like, these are two extremely successful people who have, as in pursuing their success, ground their bodies into a state of non-function. [01:05:15]
-
-So, like, that's the industry we're in. I don't know. This is what working in tech does. This is what succeeding in tech does. It's hard. One of the decisions I made in producing this podcast was I am not targeting entry level. This is not educational. This is not catch up, this is stay on the cutting edge. [01:05:34]
-
-And part of that was because of looking at the economics and realizing that, like, you know what? If you're targeting entry level people, the market you're chasing doesn't have the income. They don't have money. They're trying to get into tech. Part of the reason I have never targeted entry level humans in tech, trying to get into tech, is because I felt the economics of it was pretty fucked up. It was, you're taking money from people who aspire to get into tech to get the high salaries, and that's playing off people's desperation to succeed and do well. [01:05:51]
-
-And, like, ultimately, like sure, while the money was flowing, while it was easy to get into tech, while you could self-teach and then get a full-time job that pays you six figures, like fuck yeah, that was a great deal. That was great. That was phenomenal. It was a good part of the world to be in. [01:06:22]
-
-And now you can't. And so I think we're gonna watch a lot of educators' careers dry up because for all the good they did for the people, the market they're serving to doesn't have the money. They're trying to get the money. [01:06:35]
-
-I think we're gonna see more of this, unfortunately. It's gonna get blamed on AI, and, but there is a portion of that. People don't seek-- People are self-educating less often and relying on AI to learn more of those nuts and bolts details for them. That's true. But I do think there's another real problem of incentives. [01:06:51]
-
-You know, this reminds me too of GitHub just announced, their sponsors program, the GitHub sponsors program, you know, they waved the banner. They, you know, did the proud marketing announcement that $100 million has flowed through the program since its inception in 2018. So since 2018, 2019 I think it was actually, 'cause the number in my head is seven years. But so over the past seven years of GitHub having a sponsorship program, $100 million has flowed through it in total. [01:07:09]
-
-**Mark:** 14 million a year. [01:07:38]
-
-**Carl:** Yeah. I did 30 seconds of back of the napkin research and math, and the number I came up with for venture capital dollars that flowed just in SF over the same time period is 200 billion. [01:07:40]
-
-So while content creators are chasing their piece of $100 million, the businesses are chasing 200 times that. Thousands of times the sums of money involved. So like, I- it's, for all the commentary about, you know, who's doing what in education and content and making money, like at the end of the day, like there's a stereotype of a certain political subgroup that all just passes around the same $20. You get it, and you give it to someone else, and they give it to someone else, and they give it to someone else. [01:07:54]
-
-And like that's how I see programs like GitHub sponsors. It's not a sustainable ecosystem 'cause you're all just passing the same $20 around at the end of the day. The money's coming from somewhere else. [01:08:25]
-
-So that's my... Sorry, that's my political rant at the end of this. It's rough. It's rough out there. [01:08:36]
-
-## Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
-
-**Carl:** Mark, did you add these conferences? Should we read them? [01:08:41]
-
-**Mark:** Yeah, I put them in here, uh, because I will actually be speaking at both of them, and they're, they're also coming up. [01:08:43]
-
-So listing the two conferences off the top of my head that I know I'll be at. [01:08:49]
-
-## Sep 11: [ZurichJS](https://conf.zurichjs.com/), Switzerland
-
-**Mark:** ZurichJS in Zurich, Switzerland on September 11th. The primary organizer, Faris Aziz, great person, first year putting on the conference. I have a sense of how much time and effort he has put into trying to organize this conference. Fantastic person, ton of effort, and I'm really looking forward to that one. Great list of speakers as well. [01:08:53]
-
-## Sep 25-26: [React Alicante](https://reactalicante.es/), Spain
-
-**Mark:** And then, uh, React Alicante is in Spain September 25th and 26th, o- out on the Mediterranean coastline. This will be my third straight year speaking there. Again, wonderful conference, great community vibe, highly recommended. So if any of you happen to be in Europe or can make your way over to Europe, definitely check those out. [01:09:14]
-
-**Carl:** Heck yeah. Well, that's everything we got for you. Thank you for listening. We'll be back here on the live stage on the last Wednesday of August, or back in your podcast feed just as soon as we can. Man, maybe, hopefully I'll get it in by the end of the month in July. I've been bad at that lately. Sorry everybody. [01:09:32]
-
-Yeah, thank you so much for listening, especially to those of you who made it all the way through the end to hear this gratitude. [01:09:47]
-
-**Mark:** We started the day by saying we've got a grab bag of stuff. Yeah, we never run out of stuff to talk about. We cut out 15 items. [01:09:53]
-
-**Carl:** Yeah, we did cut out legitimately 15 items and still went 30 minutes over time. [01:10:01]
-
-Yep. That's us. Thanks so much. If there's feedback you wanna send, if there's tips you wanna give, please email them to hello@reactiflux.com. I read every email that comes through. It's a low number. It's very easy. [01:10:06]
-
-If this is a show that you get value from and wanna support, the best way to do so is by submitting a review wherever you listen and by sending this episode to your friends. Thanks so much. See you next month. [01:10:18]
diff --git a/src/transcripts/tmir-2026-08.md b/src/transcripts/tmir-2026-08.md
deleted file mode 100644
index 311c6c2..0000000
--- a/src/transcripts/tmir-2026-08.md
+++ /dev/null
@@ -1,584 +0,0 @@
----
-title: "TMiR 2026-08: Release candidate season; is that an asteroid hitting web educators?"
-date: 2026-08-28
-time: 2pm PT / 9pm GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as catch up on the litany of new RCs across the ecosystem and get eyes on the asteroid hitting frontend educators."
-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:55](#new-releases)] New releases
- - [[00:01:02](#waku-10-rc)] [Waku 1.0 (RC)](https://waku.gg/blog/waku-v1-rc)
- - [[00:03:01](#preact-1100-rc1)] [Preact 11.0.0-rc.1](https://bsky.app/profile/jovidecroock.com/post/3mtxttflm5c2c)
- - [[00:03:56](#mobx-70)] [Mobx 7.0](https://github.com/mobxjs/mobx/releases/tag/mobx%407.0.0)
- - [[00:04:32](#next-163)] [Next 16.3](https://nextjs.org/blog/next-16-3)
- - [[00:06:55](#react-native-087)] [React Native 0.87](https://reactnative.dev/blog/2026/08/11/react-native-0.87)
- - [[00:06:55](#strict-typescript-api-now-default)] [Strict TypeScript API now default](https://reactnative.dev/docs/strict-typescript-api)
- - [[00:07:47](#tanstack-table-9)] [TanStack Table 9](https://tanstack.com/blog/announcing-tanstack-table-v9)
- - [[00:09:25](#tc39-composites-proposal-replaces-records-and-tuples)] [TC39 “Composites” proposal](https://github.com/tc39/proposal-composites) \~ replaces Records and Tuples)
- - [[00:10:44](#solid-20-rc)] [Solid 2.0 RC](https://www.solidjs.com/blog/solid-2-0-rc-the-big-reveal)
- - [[00:13:39](#bun-14)] [Bun 1.4](https://bun.com/blog/bun-v1.4)
- - [[00:17:18](#github-stacked-prs-in-public-preview)] [Github stacked PRs in public preview](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/)
-- [[00:21:38](#main-content)] Main Content
- - [[00:21:42](#react-core-ish)] React core-ish:
- - [[00:21:49](#new-reactdom-usebrowser-api)] [New ReactDOM \`use(browser())\` API](https://github.com/react/react/pull/37143)
- - [[00:22:47](#react-foundation-website-updated)] [React Foundation website updated](https://react.foundation/)
- - [[00:23:18](#big-nextjs-ama-in-rreactjs)] [Big Next.js AMA in /r/reactjs](https://www.reddit.com/r/nextjs/comments/1vrq0tp/were_the_nextjs_team_ask_us_anything/)
- - [[00:23:49](#react-compiler-support)] React Compiler support
- - [[00:25:21](#oxc-biome-and-bun-14-have-initial-support-as-well)] [OXC](https://oxc.rs/blog/2026-08-18-react-compiler-support) [Biome](https://github.com/biomejs/biome/releases/tag/%40biomejs%2Fbiome%402.5.8) and [Bun 1.4](https://github.com/oven-sh/bun/issues/24356#issuecomment-5276435139) have initial support as well
- - [[00:25:21](#react-compiler-linting---oxlint-speedup)] [React Compiler Linting \- Oxlint Speedup](https://blog.master.dev/react-compiler-linting-just-got-a-rust-native-speedup-in-oxlint/)
- - [[00:25:45](#the-asteroid-currently-hitting-frontend-web-development)] [The asteroid currently hitting frontend web development](https://nolanlawson.com/2026/08/23/the-asteroid-currently-hitting-frontend-web-development/)
- - [[00:32:36](#scott-tolinskis-true-cost-of-ai-coding-survey-and-video)] [Scott Tolinski’s “True Cost of AI Coding” survey and video](https://bsky.app/profile/tolin.ski/post/3mt2imugrxk2j)
- - [[00:37:51](#josh-goldberg-stepped-back-from-oss-work)] [Josh Goldberg stepped back from OSS work](https://www.joshuakgoldberg.com/blog/stepping-back-from-open-source-mostly/)
- - [[00:40:53](#software-stewardship-lab-announced-daniel-roe-et-al)] [Software Stewardship Lab announced](https://stewardshiplab.org/ideas/a-research-lab-for-open-source/) (Daniel Roe et al)
- - [[00:40:53](#tabs-spaces-hand-tools-and-seat-belts)] [Tabs, Spaces, Hand Tools, and Seat Belts](https://newsletter.powderworks.dev/p/tabs-spaces-hand-tools-and-seat-belts)
- - [[00:42:11](#humanity-in-oss)] [Humanity in OSS](https://43081j.com/2026/08/humanity-in-open-source)
- - [[00:42:11](#discussion-point-whats-this-mean-for-fe-frameworks)] Discussion point: what’s this mean for FE frameworks?
- - [[00:46:47](#cursor-switched-from-solid-to-react)] [Cursor switched from Solid to React](https://x.com/poteto/status/2089227731305464150)
- - [[00:47:46](#lovable-moved-off-next-to-tanstack-start)] [Lovable moved off Next to TanStack Start](https://lovable.dev/blog/how-we-migrated-lovable-dev-away-from-nextjs)
- - [[00:49:00](#ryan-carniatos-async-solid-articles-fetch-high-block-low-write-sync-run-async-one-graph-two-machines)] Ryan Carniato’s async Solid articles: [Fetch High Block Low](https://www.solidjs.com/blog/async-solid-fetch-high-block-low) , [Write Sync Run Async](https://www.solidjs.com/blog/async-solid-write-sync-run-async), [One Graph Two Machines](https://www.solidjs.com/blog/async-solid-one-graph-two-machines)
- - [[00:49:00](#general-unreliability-of-github-now)] [General unreliability of GitHub now](https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/)
- - [[00:49:33](#slew-of-github-competitors-tangled-cloudflare-artifacts-netlify-source-cursor-origin)] Slew of Github competitors: [Tangled](https://tangled.org/), [Cloudflare Artifacts](https://www.cloudflare.com/products/artifacts/), [Netlify Source](https://www.netlify.com/blog/netlify-source-with-netlify-cto-dana-lawson/), [Cursor Origin](https://cursor.com/changelog/origin-code-hosting)
- - [[00:55:55](#git-at-any-scale-pierre-code-storage)] [Git at Any Scale](https://cursor.com/blog/git-at-any-scale), [Pierre Code Storage](https://code.storage/)
- - [[00:55:55](#general-discussion-point-what-is-githubs-value-prop-how-is-that-changing-how-does-that-affect-us-devs)] General discussion point: what is Github’s value prop, how is that changing, how does that affect us devs?
-- [[00:57:14](#short-asideslightning-rounds)] Short asides/lightning rounds
- - [[00:57:14](#bun-14-rust-rewrite-and-a-gazillion-new-features---the-longest-changelog-ive-ever-seen)] [Bun 1.4](https://bun.com/blog/bun-v1.4) (Rust rewrite and a gazillion new features \- the longest changelog I’ve ever seen\!)
- - [[00:57:14](#github-stacked-prs-in-public-preview)] [Github stacked PRs in public preview](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/)
- - [[00:57:14](#okay-we-definitely-just-actually-did-this-at-the-beginning-)] Okay we definitely just actually did this at the beginning 🤣
- - [[00:57:16](#npmreport)] [Npm.report](https://bsky.app/profile/philippeserhal.com/post/3mttzodz6kk2x)
- - [[00:57:51](#supplier-security-questionnaire-andrew-nesbitt)] [Supplier Security Questionnaire | Andrew Nesbitt](https://nesbitt.io/2026/08/13/supplier-security-questionnaire.html)
- - [[00:58:58](#everything-i-own-owned---schlarpcom)] [Everything I own, owned \-](https://schlarp.com/posts/everything-i-own-owned/) [schlarp.com](http://schlarp.com)
- - [[01:02:33](#the-sorry-state-of-skill-distribution)] [The sorry state of Skill distribution](https://blog.trailofbits.com/2026/06/03/the-sorry-state-of-skill-distribution/)
-- [[01:03:46](#conferences-react-javascript)] Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
- - [[01:03:48](#zurichjs-sep-11-react-alicante-sep-23-24)] ZurichJS Sep 11, React Alicante Sep 23-24
-
-# Transcript
-
-**Carl Vitullo:** Thank you so much for joining us for the August edition of This Month in React as we recap what's going on with React, React Native, and generally on the web platform. We are coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]
-
-I am Carl generally known as vcarl on the internet. I'm a staff product developer, freelance community leader, occasional entrepreneur, sometimes consultant here helping run Reactiflux. And generally just trying to keep this place valuable and pro-social for everyone around it. [00:00:13]
-
-**Mark Erikson:** And I'm Mark. My day job is at Replay, where we've built a time traveling debugger and now an automated QA platform that uses t , the time travel awesomeness to help find bugs in your app. Replay QA, please check it out. And outside of that, I am still doing an awful lot of Redux stuff [00:00:28]
-
-**Carl Vitullo:** Mm-hmm. Cool. Yeah August is often a slower month. A lot of Europe is on vacation. you know, kind of the end of summer. It's the start of school. So just often there's not as much going on. [00:00:44]
-
-## New releases
-
-We do have a lot of new releases or pre-releases, release candidates to talk about. Yeah. Let's get going. [00:00:55]
-
-First off on our new releases, we've got Waku 1.0 as a release candidate. Yeah. Waku, I don't know, I feel like I've been thinking of it and describing it as a new framework for server components, and I actually went back and checked how we've discussed it, and we've been discussing it for three years now. Like, three years is no longer a new tool, you know? But yeah, here we are at 1.0 with a release candidate. [00:01:02]
-
-**Mark Erikson:** The, and, and, and to recap Waku is a React server components framework that's been built by Daishi Kato, who i- who is also the brains behind Zeustand and Voltio and Jotai, and a slew of other state management related libraries. And the goal is to be a minimal server components framework rather than something like the, the all-encompassing Next.js [00:01:25]
-
-**Carl Vitullo:** Yeah. So cool. Love to see things get to release candidates. The fact that they've been driving towards 1.0 for so long makes me think, I don't know, makes me think this is being thoughtfully approached. Generally they, they, are very thoughtful, so that's very cool to see. [00:01:50]
-
-**Mark Erikson:** It looks like they've, they've been doing some, some navigation fine-tuning and improvements, but other than that, it's mostly like we, we think we've got it close to being final soon [00:02:06]
-
-**Carl Vitullo:** yeah, a- actually I'm gonna, I'm gonna put out a little call to audience, anyone listening. If you have, like, built something with Waku, I would actually love to hear about it. I don't think I know anyone personally who has, like, any kind of extensive experience. So, yeah, if you have any feedback, I'd love to hear about it in the \#general-tech channel or, you know, shoot me an email to hello@reactiveflux.com. Just general curiosity. [00:02:16]
-
-**Mark Erikson:** I was actually just wanting to try to look up download stats. Like, I've, I've seen it for a while. my general assumption is that it's not widely used, and certainly not in comparison to something like Next.js or React Router. [00:02:37]
-
-**Carl Vitullo:** Yeah. on that, I just checked. It has 22,000 downloads per week which compares to, you know, TanStack React Query at 60 million n. So yeah, definitely on the smaller side yeah. Okay, moving on. [00:02:48]
-
-Another release candidate. We have Pre Act 11 coming out , the main thing they highlight is it's now tree shakable which is a claim that I always take with a pretty substantial helping of salt. Just never know. I don't know. There's so many ways to break tree shaking, and we've been... libraries have been working to be more tree shakable for, like, six, seven, eight years. [00:03:01]
-
-So, you know, I don't know. It's cool. Love that. That's great. I hope it works. But yeah, Preact is generally interesting. It's cool. Last month we were talking about React alikes, and Preact is definitely the original React alike, although it is increasingly less alike as time goes on. [00:03:23]
-
-**Mark Erikson:** Yeah, although it do- it does say that the, the compat package now includes the several other React methods that have been added recently. So while the semantics have diverged somewhat over time, they are at least still making an effort to try to keep it relatively drop-in if possible. [00:03:39]
-
-MobX 7 came out. it's funny because Mo- like MobX, I think technically was, like the first releases of it were actually a few weeks before Redux came out back in 2015. So MobX has been around for a while. MobX 7 is primarily a cleanup and modernization release. They've dropped the legacy implementation and now it now requires proxies to actually track things, which has always been the default behavior. [00:03:56]
-
-Improved some bundle sizes, some tweaks to the, to the React bindings. So still out there and still being worked on [00:04:24]
-
-And on a much bigger note Next 16.3 is out, and the, the Next team talked a lot about this release. they seem to feel this is one of the bigger releases they've done in quite a while. [00:04:32]
-
-there's a bunch of dev improvements. It's supposed to build faster, less memory usage but it also has what, what they're calling instant navigations for s- better spa-like behavior as well [00:04:46]
-
-**Carl Vitullo:** Well, yeah, I saw they, they had also done a AMA on Reddit. Although I, I, I read through a fair bit of it, and it was a lot of like, "Yeah, we're working on caching. Yeah, big sites are still hard." So I don't know. It it, it was good to check in. It was cool to see... You know, it was a lot of big names giving, you know, direct answers to questions, but um, [00:04:59]
-
-**Mark Erikson:** There weren't a lot of great secrets revealed in that. [00:05:20]
-
-**Carl Vitullo:** Right. Yeah. And it's just like it's been such a consistent through line for two or three years now of like, yes, caching is hard. Local development is hard, especially if you're dealing with, like, 100,000 pages being generated. So, you know, it's just like , the challenges and the stated improvements have a certain sameness to me over time for Next. [00:05:22]
-
-I'm su- You know, it does improve. It gets better. It, it... But, like, the challenges are still pretty similar. [00:05:41]
-
-**Mark Erikson:** And, you know, may- maybe this is just a snide comment from the gallery from someone who doesn't even use Next at all, but it always... It, it's felt like a little bit of that complexity was sort of self-inflicted in a way [00:05:47]
-
-**Carl Vitullo:** Right. Yeah. I think we have another thing to talk about later on. I can't remember what this got in the doc, but Lovable put out a blog post about moving away from Next to TanStack. And yeah, you know, it's, a, a lot of it is like, oh yeah, we had performance problems, and those performance problems got resolved by moving to Vercel, but we would, would like to have more optionality f- than in our hosting. [00:06:01]
-
-So, you know, it's, the same kind of complaints, and agreed that a lot of the complexity seems kinda self-inflicted. they keep trying to fix it by adding more complexity, it feels like. You know, it's, it's a continuous additive system, and the fact that they keep adding new things to try to address the problems, and the root problems being solved don't seem to be changing, makes me suspect that the, they have gone deep into the diminishing returns of additions. [00:06:24]
-
-I think it's perhaps time to subtract. But subtracting is usually a major version bump anyway. [00:06:50]
-
-Okay. We have a new React Native version 0.87. Man, I- every time we have got a release, I miss having Mo out here because [00:06:55]
-
-he [00:07:04]
-
-**Mark Erikson:** was just about to say that [00:07:04]
-
-**Carl Vitullo:** He's got such a good breadth. Maybe I should bring him on as an analyst or something like that. But yeah, the, the big highlight here looks, to me at least, looks to be that they now have a strict TypeScript API and type definitions are being actually generated rather than hand-authored. That's a huge... Going from hand-authored types to generated types is always a massive project. It looks like this has been in the works since about point or 0.80. So, you know, that's seven, seven releases now that they've been going towards it. So, their strict TypeScript API is now the default. Not everything will be compatible, so there's an opt-out, but they've stated the intention of this - you know, the, the opt-out going away over time. [00:07:06]
-
-**Mark Erikson:** TanStack Table version nine is out, and I believe I, I, I know I'd at least pasted a couple of the prior blog posts in the tech reads and news channel. I don't remember if we actually linked them in the, in the podcast last month. Some of the updates they now have a increasingly wide range of adapters for different frameworks React, Preact, Vue, Solid, Svelte, Angular, Lit, Alpine, Ember and Octane. So pretty much anywhere you're using a framework you could use TanStack Table if you wanted to. [00:07:47]
-
-They've made a whole lot of improvements to performance. They've pulled off some very nifty JavaScript tricks to try to cut down on memory usage rewritten the internal state management, improved type safety, and as we d- were just saying, things are more tree shakable. [00:08:19]
-
-Wonderful [00:08:34]
-
-**Carl Vitullo:** Wonderful. Yeah. Tables. Man, ugh. I love that, I love that TanStack has been so persistent at trying to make a good table abstraction, but I'm gonna be honest, I settled in, like, 2017 of saying, like, "Nope. There is no table abstraction worth its weight in the bundle. I'm gonna re- write every table from scratch," which has its own trade-offs. [00:08:35]
-
-You know, it's, it, then you have to copy functionality and stuff is missing. But, like, man, just, like, seeing this release talking about how they have, like, a new architecture that, y- you know, with a record number of framework adapters, it's just like, man, tables are so much more complex than we give them credit for. [00:08:57]
-
-It's so hard to make a good table [00:09:15]
-
-**Mark Erikson:** But I thought coding was solved [00:09:17]
-
-**Carl Vitullo:** Coding is? It's completely solved. , it gets more and more solved the less closely you look at the outputs. [00:09:19]
-
-**Mark Erikson:** On a completely different note we've talked in the p- past about w- what was known as the records and tuples proposal for the JavaScript spec, which was supposed to add new data types to the language that were gonna be deeply immutable, and then you could just say, "Is this value equal to the other?" [00:09:25]
-
-And the triple equals operator would do a deep comparison. That proposal eventually got withdrawn. It's dead, it's gone, it ain't happening. So there's now a new proposal called composites, which is sort of trying to solve the same problem, but in a very different way. Reading it, it looks like you create these wrapper objects, and then the wrapper objects will do the value comparisons for you, I think. [00:09:42]
-
-So nothing immediately actionable here, but it, it is interesting to see that the design committee champions are still trying to figure out a valid solution for this problem [00:10:10]
-
-**Carl Vitullo:** Yeah, that's interesting. Looks like it's kind of I'm looking at this example in the actual spec, the stage one draft spec basically wrapping an object in a composite constructor, and then, you know, you do the same object keys and values in two, and then do a triple equals comparison, and cool, they're equal. [00:10:21]
-
-Th- so that's awesome. That's interesting. That's useful. But yeah, stage one, that's pretty far away from released [00:10:39]
-
-**Mark Erikson:** And then we've talked some previously about Solid 2.0 being on the way and having a major change in how it handles async, to how that's baked into the signals graph. They've officially hit release candidate this month. So there's the 2.0 RC announcement blog post but then there's also some deep dives that we'll touch on later that talk in more detail about how the async graph works and what that means for your code. [00:10:44]
-
-I continue to say that, like, Ryan Carniato is probably doing some of the absolute deepest research into framework development and data modeling and how to build better tools than pretty much anyone else out there. Obviously the React team put a lot of thought into server components. The Next team's putting a lot of thought into, you know, building their framework. [00:11:12]
-
-Ryan's doing, like, the bleeding edge research here [00:11:37]
-
-**Carl Vitullo:** I love that, so the async lives in the graph is for one, just a great header. I love that as a thing to unpack and understand. But it's a, I, I wanna call out this little parenthetical that says, "A computation can return a promise, parentheses, or an async iterator." And man, a, promises versus async the iterator is just so much more powerful. So being able to support those, like, you know, it's a little aside because everyone knows and uses promises and those, you know, everyone assumes those. But man, I've been using async iterators more and more lately, and they're so powerful. [00:11:41]
-
-**Mark Erikson:** I, I was, I was skimming through the third of the three explainer blog posts, and they fleshed that one out in more detail. And I think the example there shows a component that, like, looking at it, you almost wouldn't even know that it would get updates because it just works reading the data [00:12:14]
-
-**Carl Vitullo:** Yeah. I've been using them mostly because I have been doing all of my code in effect the last couple of months, and, like, or everything is a generator. And generators can be iterated upon. But yeah, like, you know, it, an async iterator is basically a promise that can resolve multiple times. [00:12:34]
-
-Like, ugh, that's incredible. I don't know. So just, like, So many times when you're modeling something as an asynchronous request, it may actually be better to model it as a stream of incoming data, and you can't do that with a promise. You cannot have an, a stream a stream of events. So i- iterators are just, like, this really magical in-between point between events, like, you know, event-driven architecture and promises. anyway, [00:12:48]
-
-**Mark Erikson:** Ben Lesh would like to have a word with you about RxJS and Observables at this point [00:13:15]
-
-**Carl Vitullo:** Ha ha. Fair enough. Yeah, super cool though. Last thing I'll say on that is definitely lend... early and prominent shout-out of async iterators, I think, lends credence to what you were saying about him being on the cutting edge of the research here. Like, yeah. Everyone else needs to catch up. go become familiar with async iterators, because it will level up your professional, capabilities. Okay, moving on. [00:13:19]
-
-Bun has had a big release [00:13:39]
-
-**Mark Erikson:** it's the single biggest change log I've ever seen. It's for what is technically a minor release, except that they also literally rewrote the entire thing from Zig to Rust with AI. Technically, there's no breaking changes, so yeah. [00:13:42]
-
-**Carl Vitullo:** Yep, they've moved out every zig. They're now on Rust. [00:14:00]
-
-**Mark Erikson:** Deep cuts [00:14:04]
-
-**Carl Vitullo:** Deep cuts. You know, you can't just put an opportunity like that in front of me. [00:14:05]
-
-Yeah, I think this is super cool. there's been a bunch of drama, a bunch of words typed and spoken about the Rust rewrite, and, like, I just, I don't find that very interesting. The most interesting thing I think is that they used Basically a fully automated workflow and the existing test suite to say, "This works. Go fix it so that it works in this language instead." and then $160,000 in tokens later, they had a Rust-authored version that is apparently good enough to release, and not only good enough to release, but good enough to build a, like, remarkable set of additional features on as part of that release. [00:14:08]
-
-So, that's fascinating. That's cool. It's a little crazy to see that much coming out. J- Jared Sumner has always been, like, kind of confusingly prolific at, in terms of, like, level of output here. So I don't know, just seeing him become AI-enabled is remarkable. [00:14:47]
-
-But I was gonna say, oh, this is the most important one, and then I'm looking at the whole list and they're all pretty wild. Like, bun.image lets you do a lot of really powerful image manipulation for the web natively, you know, just within Bun, which is great, 'cause I have previously done stuff like that with FFmpeg and Sharp, and those feel like they were written in the early 2000s, because they were. those have been around for a long time because nobody wants to rewrite them, because doing that work in a way that is performant and, like, usable is really hard. So, you know, kudos for shipping something like that. I haven't played with it myself yet. I want to. But yeah, decode, resize, rotate, encode JPEG PNG, WebP, GIF. Yeah, just, like, all of the image formats, doing resizing and basic editing kind of stuff is really, really interesting. [00:15:05]
-
-But then they've also got bun.webview, which is basically like Playwright or, you know, Cheerio or something, just natively within the standard library, which is wild and really helpful. [00:15:53]
-
-I haven't made use of this yet, but I did go through... I have a skill that I made for myself that is like, "Here's how to set up a new project here. You know, here's how to set up the linting, here's what tools to use." And I told it, "You should use bun 1.4 because the web view stuff makes it really easy to do end-to-end testing," allegedly. I still need to validate this. [00:16:04]
-
-But they've also got, like, a markdown parser and, like, a cron scheduler a pseudo terminal so you can dri... You know, they, they say, "So you can drive Bash, Vim or whatever from JavaScript without Node PTY." I've been rigging up a bunch of, like, experimental AI agent harness stuff, as part of doing that, I've been writing a lot of wrappers for Bash to be like, "I need this service to be running in the background while this server runs. it's really janky. I've had AI write a shit ton of, like, bash-compatible things that are, like, forwarding control codes, and making sure output redirection works as expected, and all those little subtle details. So again, one more thing that is, like, a pretty big load off of my mind building something if I can just ship it out to a standard library. [00:16:24]
-
-So anyway, yeah, it's a massive change log. Lots of controversial practices involved in producing it and releasing it, but mm, it's pretty cool. End result is pretty neat [00:17:07]
-
-Cool. And uh, man, another thing I've been dreaming of for years and years and years, GitHub is now doing a public preview of stacked pull requests stacked PRs. we've talked about this a couple times. I'm not sure how widely familiar, you know, the ecosystem is with stacked PRs. [00:17:18]
-
-This has been a, the way that I work intuitively for a number of years at this point, like probably dating back to 2019. Where, like, work on something, produce a finished branch, push that up, create a pull request, and then I'll ... Most of the time, the thing I just built was to enable future work. You know, it was to unblock other work that I mean to be doing. So then I'll just take that branch and continue working off of it, off a new branch, and boom, that's a stacked, you know, that's a series of stacked branches. [00:17:37]
-
-I'm, while branch A is being merged, I'm working on branch B, and then, you know, when branch A gets merged, I push up branch B for review. The, the revision here is that now you can just push them all up and mark the PRs as stacked on top of each other and it will automatically do lots of rebase and branch juggling for you. [00:18:07]
-
-Yeah, the challenge there is, okay, you stack branches up like that, like I was just describing, but then when you merge them, you know, the, the, the commit SHA changes. You know, maybe you do a squash merge. You know, maybe it's a, Anything other than a fast-forward, and you now have to do a rebase in order to have the, have the branch [00:18:29]
-
-**Mark Erikson:** Which means you have to pull down locally, you have to do the rebase, you have to, you have to do some juggling locally, push it back up, actually create things, and you have to repeat that for every time you do, you, you merge one of those PRs [00:18:46]
-
-**Carl Vitullo:** Right. And so when you've got, you know, branch A and branch B, it's not so much work. But when you've got branch A that drives branch B, that drives branch C, that drives branch D, and you've got eight people all contributing to a shared code base, like that pull, rebase, push cycle ends up being a pretty substantial amount of work. [00:18:58]
-
-So it's really cool that GitHub is now enabling this. There's a, there's a pretty closely related concept here as well called a merge queue, which is basically like an engineering practice where as part of review, you know, you don't just mer- you don't just merge when approved. You don't say like, "Okay, this, this PR is now approved for ship," whatever. "Let's merge it now." it's part of a queue, you know, it's in line. So, just as a way to manage conflicts, avoid doing rework because, you know, it... When you ha- when the work that's being merged into release is more predictably sequenced, a lot of benefits fall out of that. And stacked pull requests are a really interesting way to enable a simplified version of that for a, a larger number of people. [00:19:17]
-
-So I... This is really cool. I'm excited about it. I I'm gonna have to play with it. [00:20:06]
-
-**Mark Erikson:** mean, it's, it's, it's worth noting that on GitHub, the unit of review is the PR. Like, you can have as many commits as you want, but what you see by default is the final result on the branch, and that is what we're all very used to reviewing, and it's, it's what many other GitHub-like tools have copied. [00:20:09]
-
-But there were, there have been plenty of other code hosting and review tools Gerrit, Phabricator, and others, where the unit of review was the commit. And so another part of this usage-wise is how big of a unit am I trained to review at once? So, like, maybe you have your, you know, your 5,000-line PR, but it makes sense to review the changes in smaller chunks. [00:20:30]
-
-Well, on GitHub, it becomes difficult to go through and review, like, one commit at a time or something. So either you say, "Here's the whole thing. Looks good to me," or you have to split it into multiple PRs so that smaller chunks are more easily reviewable, but then you have to do the branch juggling dance. [00:20:57]
-
-**Carl Vitullo:** Yeah, and I guess I, I also wanna say this was, like, Jared Palmer's pet project while he was at GitHub. [00:21:17]
-
-**Mark Erikson:** For about three months [00:21:23]
-
-**Carl Vitullo:** For the... Right. So it appears that Jared Palmer legitimately joined GitHub specifically to ship this, got it into a state where it [00:21:24]
-
-**Mark Erikson:** It's the meme. It's the [00:21:31]
-
-**Carl Vitullo:** Yeah. [00:21:33]
-
-Right. And then left, and then went... Yeah, so anyway, that's, that's pretty funny. Uh. [00:21:33]
-
-## Main Content
-
-Okay. Into our main content yeah. [00:21:38]
-
-Yeah. [00:21:41]
-
-Right [00:21:42]
-
-**Mark Erikson:** Right so a few smaller items from React core news-ish stuff this month. [00:21:42]
-
-There's a new API that's coming out for React DOM. It's a function called Browser, which is intended to be passed to the increasingly expanding use method. So it's use. The idea is it re- the return value of use will differ depending on whether you're calling this on the server or on the client. [00:21:49]
-
-So if you call it on... If you have a component and it's getting rendered on the server, in a server component or whatever React will see that and essentially leave a hole in your component output. And then it knows that when this run, runs again on the client, then it will fill in. pretty much every code base at this point has some form of a do this logic only on the client util or, or something along those lines. [00:22:15]
-
-This is essentially building that functionality directly into React DOM itself [00:22:41]
-
-Let's see. [00:22:47]
-
-We, we... I believe I mentioned last month that, that there were updates on the way for the React Foundation website, and then they were also talking about governance-related things. They have shipped an update to the website, so it at least looks less AI vibe coded at this point. still Looking and waiting for more public details on what the foundation is going to do long term, but again, you know, bits of activity. [00:22:47]
-
-Things presumably are churning away behind the scenes. [00:23:15]
-
-As, as we mentioned earlier, the Next team did an AMA over on Reddit. There's some discussion. Some of it's the obligatory complaining about Next.js not having proper middleware and things like that. I skimmed it. Honestly, the biggest thing I got out of it is that React 19.3 is probably coming in the near future, and that it should solidify the fragment ref and view transition features which have been in Canary for a few months. [00:23:18]
-
-So good to know that's on the way [00:23:47]
-
-And then the other interesting bit was that the OXC team has shipped their official support for React Compiler built into Oxlint, et cetera. And, and this is interesting for multiple reasons. So React Compiler itself was originally written in TypeScript and also required a Babel plugin. And so it existed, but we've spent all these years converting our build tool chains to Rust. [00:23:49]
-
-Babel is slower. People saw that build times got slow again, and like, "We don't like this. Can you just do it in Rust?" The React team did an AI-assisted port of the compiler logic from TypeScript to Rust. That is in the React repo. But then the question is: how will that integrate with other build tools? So other teams, Biome, OXC, Bun, et cetera, have been taking the Rust code and trying to figure out the best way to integrate it, and the OXC team in particular has actually pushed ahead in a lot of ways. [00:24:14]
-
-They tried to integrate it once, and then they decided that it made their binaries too big, and they didn't wanna ship that to everybody, including people who don't use React at all. So apparently they went back to the drawing board. They found some ways to optimize the code, shrink the bundle size, make it semi-optional maybe. [00:24:51]
-
-And apparently now the both the build performance and the binary size are good enough that they felt ready to actually ship it. So that, that support is now baked in at this point. [00:25:09]
-
-And Biome is trying to do some integration as well. Bun 1.4 is supposed to have React Compiler support. So slowly but surely, these pieces are all coming out in the ecosystem in a much faster way, and so hopefully that means that more projects will be actually be adopting the compiler over time and thus seeing whatever runtime performance benefits you get from using it [00:25:21]
-
-**Carl Vitullo:** Should we go to Asteroid? [00:25:45]
-
-**Mark Erikson:** Yes, the asteroid not astro, asteroid [00:25:46]
-
-**Carl Vitullo:** Yeah. Yeah. Nolan Lawson, who is is somebody who's been, like, individually fairly influential on me as a developer I just first encountered him 10, like, more, 15 years ago when I was still in college. So it's cool to see his name still around. he put out a great blog post called The Asteroid Currently Hitting Front-End Web Development. , basically the same thing I actually said on, at the end of our last episode about impacts of AI on educators, on content creators, especially in the front-end engineering space. And basically, you know, he's highlighting that He says, "A lot of the educators I admire in the front-end web space seem to be either bowing out or dialing back their efforts." [00:25:50]
-
-And like, yeah, Axel Rauschmeyer, hugely influential blogger about the standards process and, you know, JavaScript itself as a language. Salma Alam N- Naylor, well, Selma and Josh we talked about specifically at the end of the last episode. And, and then he calls out, too, that, like, Kenzie Dodds, Addy Osmani, Rachel Neighbors, Lydia Hallie have all moved more from front-end development into, like, AI agents software development. Which I, which I think is fair. You know, I don't, I, I, I think comparing people stepping back versus staying on the cutting edge. for a long time front-end was the cutting edge, and then it was, like, React Native and where are we gonna put React next? And so now it's not as much that. Now it's AI and how do you build stuff? How do you build a software factory? [00:26:28]
-
-**Mark Erikson:** , even that is a theme we've touched on for a while. I mean, swyx used to be part of the React ecosystem space. He was a mod on the, you know, in the subreddit, did a lot of talks, and then, then he got involved with Svelte, and then he pivoted to running AI conferences and, and podcasts. [00:27:11]
-
-, we've even talked about, like, the energy at React conferences seems to be down, whereas the AI conferences have all the energy. So, like, there, [00:27:27]
-
-**Carl Vitullo:** Right [00:27:38]
-
-**Mark Erikson:** like, a lot of trend here [00:27:38]
-
-**Carl Vitullo:** . This post from Nolan Lawson, he talks about the future of front end. And I'm just gonna read a couple of, like, high-level points he makes. The front end is less risky to just hand to an agent. Developer experience is becoming less critical overall. Standards will catch up. I think this is interesting. [00:27:41]
-
-I, these rhyme with points of contention that I've seen in the industry for essentially my entire career. Like, you know, [00:27:55]
-
-is front end... Right. Front end is easy, and developer experience isn't worth the time investment. , I wanna call this out. He says, under developer experience becoming less critical, "The agents know React. For better or worse, React is heavily over-represented in the training weights." And again, like, something we talked about last episode, I believe, was Aiden Bai put together a benchmark of not just React, can it make something functional, but how well does it actually execute React best practices across different models? [00:28:02]
-
-**Mark Erikson:** they know what React code looks like. They don't really know how to write good React code [00:28:32]
-
-**Carl Vitullo:** Right. So [00:28:38]
-
-**Mark Erikson:** They know what bad React code looks like [00:28:40]
-
-**Carl Vitullo:** Yes, bad React code is heavily overrepresented in the training set, but, I used to, I used to work, when, when I was more earnestly working full time, I went to a lot of different companies for, you know, a year, six months, a year and a half, and the reason I was able to be very successful at that is because every company used the same set of very bad practices that represented a fundamental misunderstanding of the advantages that React offered. [00:28:42]
-
-And so it's like, cool, I understand those, let me come in and fix this incrementally one thing at a time, and the improvements are so mind-blowing to you as somebody who doesn't understand the tools you're using, that, you know, great, cool, great, awesome. Who... Lovely performance reviews, yada, yada. [00:29:07]
-
-I both understand where he's coming from on this. there is less risk in f- the client versus the server. If you fuck up data on the client, like, you just, you know, pull f- from scratch from the back end. But if you screw it up on the back end, like, oops, data loss. Oops, you know, security vulnerability. So it, you know, these are both true, and I think, like, fundamentally missing some kind of point. So I don't know, it talks about the future of front end and front-end education. I think there's still a lot of room for human cognition as steering input to guide agents that, you know, they may be individually capable of achieving, you know, X, Y, Z, maybe even better than I can, but they need to be told what the constraints are in a w- in a manner that is, you know, y- helpful to guiding them to waste less. You know, like, rework is so costly that if you, if I, as the intelligent human with experience using these tools and knowing, you know, what has downstream effects six months, a year, five years from now, then yeah, I think there's still a lot of room for expertise meaningfully [00:29:23]
-
-**Mark Erikson:** when I wrote my own AI journey emotional blog post back in April, one of the points I made was that I did... Once I got past, "I will never use this," and actually started using these tools, I've been able to use them effectively because I already know how to write code. I already understand what good code looks like. [00:30:39]
-
-I know how I want to do things, and now I'm just trying to speed up the process of doing the work that I already intended to do. or using the tools to give me a range of options, and then I make the decision based on which one actually feels like it fit, fits the best. but then that brings up all the, and all the usual questions of, well, how do you get all this experience? [00:31:01]
-
-Well, I did it for 20-plus years by hand, and now I'm reaping the benefits of that. And how do others gain that experience in today's world? I don't know. I'm not in that position at this [00:31:23]
-
-**Carl Vitullo:** Yeah. You know what? I think they learn it, I think they learn it essentially the same way that I did. Fucking trial and error. Like, I have a, I have an associate's degree. I have nev- you know, I've taken one year of computer science. Like, I was not taught these things. I learned them largely through trial and error. [00:31:35]
-
-You know, you join a company, you ship some code, you have to deal with the consequences of the code that you shipped. I, there's no substitute for experience, and it is easier than ever to go from non-functional to functional. And once you have to maintain a functional thing and keep it operating and expand on it and improve upon it, I feel like the lessons aren't that different. [00:31:51]
-
-I don't know. At the end of the day, I think it's, it comes down to how well can you ask questions of this... You know, we're all gonna be managers in the, in this AI world, [00:32:14]
-
-**Mark Erikson:** So a lot of the discussion around this whole direction has then been, yeah, like, what... where is the place for us? What does that mean for our careers? How do we feel about this? [00:32:23]
-
-So Scott Tolinski uh, one of the hosts of the Syntax.fm podcast with Wes Bos did some work within the last few weeks that really touches on, on this. [00:32:37]
-
-Scott had his own AI psychosis phase some months ago. And coming out of it, he's like, "Okay, This has affected how I feel, like, literally on a daily basis. I wonder how other devs have been going through this as well." And so he put up a survey online. Has been trying to gather as many respondents as possible. [00:32:45]
-
-I think he's up to 7 or 8,000 respondents at this point. So you know, a f- fairly decent sample size. [00:33:07]
-
-And it, it's, it's relatively short, but it asks questions like do you feel like your skills are eroding based on your AI usage? How many times have you found yourself staying up later than you intended because just one m- just one more prompt, one more prompt, [00:33:13]
-
-Or, you know, sort of the slot machine effect of just asking it to do, you know, some more work. So he gathered up the results, and I believe his wife is actually, like a, a psychologist with, with a, with a doctorate. And so he was having her work through him on some of the statistics and the analysis on this. [00:33:30]
-
-And he also was reaching out and doing some video interviews with a number of people to follow up and get some ac- you know, some more direct, you know, r- real-life anecdotes and data. So I actually did a video with interview with him, and we, we had a good discussion. He pulled all this together into a half-an-hour YouTube video where he talks about his experience, his research, and brings in video clips of a bunch of people including myself. [00:33:50]
-
-It's a really good video. I, I strongly encourage people to take the time to read through this. The end, like, the end bit of it is basically take care of your mental health, folks. Like, don't let this, rapid pace change in the world get to you. Take care of your mental health, establish your boundaries, and then go from there. [00:34:17]
-
-**Carl Vitullo:** Yeah. Yeah. Very important. I think at the intersection of that, take care of yourself, understand your boundaries, hold yourself to your boundaries, which is hard. [00:34:37]
-
-staying within them for a long period of time is really hard. [00:34:47]
-
-**Mark Erikson:** I know what the right things are and I am not the world's best poster child for sticking with them. Do as I say, not, not as I do [00:34:52]
-
-**Carl Vitullo:** Right, right. and I wanna connect that back to this, you know, asteroid hitting front-end web development and educators falling off and no longer producing output at the same level that they were in the past A lot of my, I think a lot of my energy in producing this podcast, in running Reactiflux, in contributing to the ecosystem has been, especially the last five years, has been very much rooted around what can I do to not burn out? So, you know, it's like the reason this is a once a month podcast instead of weekly or daily or whatever is 'cause I would burn out if I did anything else. Like this is enough effort for me and this is already once a month for an hour plus prep is already disruptive enough to the other things I want to do in my life that I can't do anything more than this. [00:34:59]
-
-**Mark Erikson:** Ditto [00:35:49]
-
-**Carl Vitullo:** Okay, we've achieved some small level of success. We have several hundred people listening every month, which is lovely and great, but like, you know, on the grand scheme of things like this is never gonna pay my bills. This is never gonna be a full-time career. And like, you know, whatever, that's fine. [00:35:50]
-
-That's okay. That's okay because that's what I, I built it not to be that. I built it not to take over my life. I built it to let me do it at my leisure, at my convenience. And I don't know, you know, in some ways, like, a personal life philosophy of mine is to like be inexorable, just like, th- just be unstoppable. Like you don't need to be the fastest, you don't need to be the smartest, the most resilient, but like just keep going. [00:36:03]
-
-If you, if you're going in a direction, just steady advances incrementally. And so like, you know, I'm not, I, I'm never gonna have hundreds of thousands of social media followers and you know, tens of thousands of hours listened across multiple platforms. But like, you know what? When the other people burn out, here we are. know, other people do these content projects for a year, two years, three years, but like Reactiflux, we've been around more than 10 years now and I've been helping run it for a lot of that, most of that. I've been a moderator or an admin for 10 years now, 10 and a half years now. So I don't know. That's, I think that's, that is an attitude that is not widely rewarded in tech, in tech generally. You could say some other things about different subdivisions there, but I think it's, I don't know. I think it's important for mental health and pers- physical health as well 'cause burnout is not just a mental health issue. [00:36:33]
-
-You can have serious physical health consequences from that. Anyway, yeah, I don't know. I'm gonna trail off there. [00:37:28]
-
-**Mark Erikson:** Yeah. So here's sort of the flip side of that keep persisting thing. I mean, we, we listed a number of people who have made the decision to step back because they're feeling burned out or feel like the, you know, the audience and the career that they'd built just no longer exists at this point. [00:37:34]
-
-So Josh Goldberg, who has been a very prolific open source contributor working across multiple different linting and build tools recently just announced that he's stepping back completely from open source maintenance. [00:37:51]
-
-I actually talked- had talked to him live just before he posted this, and he, he told me this was where he was headed. Some of it is life changes. He's, he's had a number of stuff going on in his personal life that have taken up time and energy. Some of it is getting very frustrated with AI PR spam [00:38:05]
-
-and, you know, just not wanting to deal with yet another seemingly plausible bug report that turns out to be complete nonsense. [00:38:23]
-
-And some of it is just a desire to literally go out and touch grass and do other things with his life [00:38:32]
-
-at this point. [00:38:40]
-
-that's also an entirely valid set of decisions, and he said he's ha- essentially handed over all of his projects or they're in maintenance mode at this point. [00:38:41]
-
-He's still working. I believe he's at Sentry at this point, but he's stopping open source work. And so, like, I'm happy for him in the sense that I want... He's a good- he's a great person, and I want him to do what's best for his life. It's a little sad in seeing someone who has been involved, you know, saying, "That's, that's it for this phase of my life," and stepping away [00:38:51]
-
-**Carl Vitullo:** Right. It, it's sad to me because he's a friend. I consider him a friend. He stayed at my house once because he was passing through and needed a place to crash. [00:39:15]
-
-I... He's a lovely person [00:39:24]
-
-He's so kind and so generous, and so purely wants to do good that it sucks. it makes me genuinely sad to see him take a s- need to take a step back because he can't do it all, you know? [00:39:25]
-
-Because he, nobody can do that all. It's too much. You can't work full-time and have a engaging, rewarding personal life and do these side projects, and also organize a conference, 'cause he was doing that, too. So yeah [00:39:40]
-
-**Mark Erikson:** I mean, I've, I've had my own thoughts. Like, I, I have no plans to stop open source work anytime soon. In fact, I've actually got uh, like I said, we said last month, I'm trying to push through a big new React Redux feature, and I've got a bunch of plans for what will hopefully turn into our next set of major version releases. [00:39:52]
-
-But you know, purely mathematically, the day will come when I no longer do Redux-y things. It might be 'cause I'm 83 years old and no longer have the mental capability to do it. And, but, like, mathematically I'm gonna stop eventually. It's just a question of when and why, and what am I doing with my life? [00:40:10]
-
-**Carl Vitullo:** Yeah Tough. I don't know. I've wrestled with that a lot. What am I doing with my life? What is my life? Who am I? What do I care about? What are my values? [00:40:34]
-
-**Mark Erikson:** Why are any of us here? Why are any of us Why [00:40:42]
-
-on that note I'll, I'll toss out three other links. I'm not sure there's necessarily a lot of discussion, but they, they fit very neatly under this category. [00:40:46]
-
-a group calling themselves the Software Stewardship Lab is trained to help improve open source sustainability. And ironically, when I was on vacation in Scotland earlier this year, I actually happened to talk with some of the people who apparently were... [00:40:53]
-
-They must have been doing some of the planning for this at the time. Daniel Roe, who's the leader of Nuxt, you know, the, the next equivalent for, the Vue ecosystem is involved. Vlad Harbuz, Andrew Nesbitt, who's been doing massive research on packaging ecosystems uh, Matias Capelletto, who's involved with the, the npmx project, Miranda Heath, who's been doing research on burnout. [00:41:09]
-
-A lot of, again, very, very good people who care deeply about open source and community as a concept are involved in this. I'm a little unclear on how they're hoping to improve things, but I highly, highly approve of the concept, and these seem like the right kind of people to be doing thinking and research I read a really, really long blog post, my favorite kind that covers a number of things related to AI migrations and software craftsmanship. It's long enough that I don't remember what all was in here, but it was a really, really g- good post and worth taking a look at. [00:41:33]
-
-And then James Garbutt, who's involved with the E18E Ecosystem Cleanup Initiative, wrote his own post on humanity in open source, and some of his points are that, yeah, we're, we're getting swarmed with AI PRs and issues. [00:42:11]
-
-Open source is about more than just... Like, the construct of open source is about more than just licenses and releases, et cetera. It's about the communities that are getting involved, and it would... And then there's also the questions of, you know, how do we keep building those communities, especially if people keep getting burned out? [00:42:28]
-
-So he has s- several different thoughts on trying to manage that [00:42:53]
-
-**Carl Vitullo:** Yeah. Okay, at the mention of communities, I wanna jump in. - we're talking about, communities maintaining shared infrastructure is how I'm gonna frame this, you know, humanity and open source. Do you know how many different communities are maintaining the shared infrastructure that support every aspect of your basic life? [00:42:56]
-
-**Mark Erikson:** Where's [00:43:15]
-
-**Carl Vitullo:** I think... [00:43:16]
-
-Yeah, right, but y- right, okay, so there's XKCD of all the stacked, you know, boxes [00:43:17]
-
-with, like, that fragile thing. But, you know, like, you know what? Like, how do your lights stay on? How do you get hot water? You know? How do you stay cool? How do you get groceries? Like, each of these is the output of a shared infrastructure being maintained by a community. You know? Okay, the s- the, the, the power that might be, the community there might be a regional monopoly as dictated by, you know, legislative priorities. but, like, th- th- I guess that's how I wanna frame this. Like, I think we are exceeding the type of human scale. You know, this is like the Industrial Revolution of software. Like, it used to be all handmade parts that were not interchangeable. Th- and we've been moving more and more towards interchangeable, fully automated whatever. [00:43:21]
-
-And, like, yeah, for better and for worse. Like, if you take that lens of handmade versus scaled, you can apply that to almost anything. Like, I occasionally like to bake bread. I also buy store-bought bread because it keeps longer, and it keeps longer because it's a fully automated system that has been refined for 150 years because people need bread, and not everyone has the available time and resources to bake it. So, you know, like I, I love to think about water, water is a crazy, when you actually look into the, like, societal level engineering projects. [00:44:08]
-
-So like control of the flow of water is a shocking percentage of human effort over the millennia. Like not, keeping it within the tolerable bands. You have to have enough to keep everyone who lives there alive, but not so much that it washes their houses away. And like managing that is a preposterously large project, and when's the last time you thought about it? [00:44:49]
-
-So like that's... I think open source is now moving more in that direction, where it had been very human scale of like, I know the 15 people who are making all of, you know, making this whole thing work. And now we're starting to go into a place where there is enough automation in generating and consuming code that that scale of investment no longer really works. Another useful lens here is like Etsy versus Walmart. Like I can go to Etsy and I can buy picture frames or, you know, a pin or a sticker or a shirt, and that was probably handmade by somebody, hand designed by somebody, and I'm gonna pay a little premium for that. But like most people don't actually care that much about where their shirts come from. They don't care about the manufacturing process of, you know, how this, was this picture frame made with sustainably grown wood, or is it a composite made out of sawdust and epoxy? Like most people don't care. It looks good on the wall. [00:45:13]
-
-So that, to me, is a really fundamental lens here. It's people who are used to being very close to the production grating against the automation of what they have taken great pains to do well. And neither side is wrong. Both of them are fully correct. [00:46:14]
-
-**Mark Erikson:** So partly angling off that, and this was actually in what passes as a script over here. Two more stories of migration that circle back through the AI aspect, the frameworks aspect. [00:46:33]
-
-Cursor just got done migrating their entire system from Solid to React, and they talked some about it, and one of the things they said is, "Well, the agents are more used to writing React. [00:46:47]
-
-They actually make a lot of mistakes, but at least we're familiar with those mistakes, and they're obvious to us now, and we can control and correct for those. Whereas with Solid, they just sort of got confused most of the time." so that... There was, there was a lot of debate back and forth on Twitter. A, a lot of quote tweets and, and some discussion from the Solid team saying you also didn't ever really give us much of a chance, but yeah. So there's, there's its own drama there. [00:47:01]
-
-**Carl Vitullo:** Yeah. Certainly no, certainly no part of this was because Lauren used to be on the React team. There's probably no bias there. Yeah. [00:47:29]
-
-This is such a shady tweet. Like, "Much love to the Solid team and congrats on launching Solid 2. We just finished moving away from you." Like, that's some hella shade to throw. [00:47:37]
-
-**Mark Erikson:** And then we mentioned earlier, Lovable talked about having migrated I think their own actual system away from Next.js and over to TanStack Start. And I, I, I know they switched their project setup from whatever the previous was to TanStack Start. I believe this is separately saying they switched their own infrastructure to be built on TanStack Start instead. [00:47:46]
-
-I love a good migration post. This goes into a lot of details, and it does say that they did some of that work with AI tooling further down once they had identified some of the constraints [00:48:11]
-
-we could have spent a bunch of time on this. I think we've probably gotten far enough. We probably shouldn't spend time on this, but sort, sort of a meta point and, and one of the things we keep circling on is you can switch very easily from tool A to tool B or language A to language B at this point. [00:48:21]
-
-You say, "Here we've got this thing. This thing works. Make it work in some other tool set entirely," and if you've got enough tests, enough tokens, enough time, then it pops out on the other end. [00:48:38]
-
-Having said that, I do actually want to bring up one more set of framework-y things because I think this is fascinating reading as a person who spends too much time caring about frameworks. [00:48:50]
-
-I mentioned earlier that Ryan Carniato and the Solid team have been doing a bunch of bleeding edge research especially into how the entire signals data graph can encode the asynchronous of the data in there instead of needing to, like, separately keep track of promises or, you know, loading flags, et cetera. [00:49:00]
-
-And so they've put up a, a series of three posts that go into the details on what that means in practice when you use Solid 2. I thought they were fascinating reading myself. [00:49:21]
-
-**Carl Vitullo:** Our last main topic before we go into what are allegedly short asides, lightning round. The general unreliability of GitHub lately lately. they Put out a blog post talking about the outage on August 17th. And like, yeah, you know what? Like, they're not... [00:49:33]
-
-They're barely holding one nine of availability lately That ties very closely to the rise of agentic coding and the sheer volume of commits that are being pushed, [00:49:47]
-
-**Mark Erikson:** they've published a number of stats in the last several months about how the number of PRs and commits and API calls has just absolutely gone through the roof in the last few years. [00:49:57]
-
-**Carl Vitullo:** Like 10X, 20X [00:50:08]
-
-**Mark Erikson:** a large multiplier [00:50:10]
-
-**Carl Vitullo:** Yeah, fair. Yeah. there are now more and more people throwing out GitHub competitors, which I think is interesting. There's Cloudflare, Netlify, Cursor. [00:50:12]
-
-oh, wow from chat, "GitHub reported one commit per millisecond." [00:50:22]
-
-**Mark Erikson:** initially read that as one commit per, from Microsoft. I'm [00:50:25]
-
-**Carl Vitullo:** Yeah, me too. All it takes, one commit for Microsoft to take down the system. The commits are coming from inside the house. Okay, sorry. [00:50:28]
-
-But yeah, so there's now... there's a combination of factors that are making people start to put out GitHub competitors. Okay, obviously we're in the middle of discussing the significant outages that GitHub has been having for a number of months now. But there's also, we don't know how to work anymore. We don't know what the best way to... Uh, Well, okay, we never knew what the best way to work is, but we had at least settled on pretty widely adopted patterns, which GitHub, you know, codified and then led in a [00:50:36]
-
-**Mark Erikson:** You have, you, you have a trunk, you make a feature branch, you work for a few hours or a day, you push a PR, a teammate reviews it, CI goes green, and you ship it [00:51:05]
-
-**Carl Vitullo:** Right. there's a lot of assumptions about how you use Git in that workflow. And so, like, you can use Git in different ways if you were to so choose. [00:51:15]
-
-Uh, I actually re- [00:51:24]
-
-**Mark Erikson:** was a thing back in the day [00:51:24]
-
-**Carl Vitullo:** Yeah, and I actually have moved uh, one of my projects more towards a Git flow type thing, where you have a periodic release, and you cut an RC, and you do user acceptance testing on the uh, on the release candidate, and you ship that artifact. [00:51:26]
-
-There's an explosion in exploration of new ways to work with code and new ways to collaborate with others around code that I think is driving some of this curiosity to try alternatives. I'm personally very curious about trying to self-host some infrastructure here. [00:51:40]
-
-I don't know. Maybe this is me b- spending five years independent and not working with companies, but like, man, there's just much unexplored territory now [00:51:58]
-
-**Mark Erikson:** there was a really good discussion over in swyx's Discord just a couple days ago with a different but similar theme. Some of it was the debate over, "Wait, you guys are still reading code?" but then that also ties into, "Wait, you guys are st- like, like who's using an actual IDE to do their work?" [00:52:08]
-
-Versus this new breed of agentic swarm management tools, where what really matters is you have a chat screen and a dashboard of all the agents and the work trees in flight, and maybe it's got like an integrated diff viewer, but what really matters is, like, the task management rather than, like, I need to have the code open so I can type. [00:52:30]
-
-**Carl Vitullo:** Right. the way I have been working is very acceptance-driven of just, like, does this achieve the goal I set out when I started this project? And I don't really review the PRs as much. I do quick , sanity checks of, like, you know, is this 15,000 lines when it could be 2,000 lines? But, you know, like, very high level. I'm not really understanding the... You know, I, if I wanna understand something about how the code works or how the code is structured, like, I ask the agent, 'cause the agent wrote it. yeah, I don't know. [00:52:55]
-
-Dashboards and such, I think is... that feels not quite right to me. That feels like project manager kind of capacity more than, like... I don't know. These, like, task tracking is different from did you build the right thing? What's underway is different from are we working on the right things? So, just thinking about it through the lenses of different professional titles, like software engineer versus, like, manager versus, like, director of product or project manager, program manager. [00:53:25]
-
-Like, all of those needs of establishing what the space we're working in is, what other solutions have other people tried? What, what are we ruling out? What is the actual need we're solving? Are we achieving that need? [00:53:54]
-
-Yeah, that's all the same. Now that code is no longer the primary thing that I want to read in order to understand the, the answers to those questions. Yeah. I don't, I think we're, I think we gotta figure it out, kind of from scratch. [00:54:11]
-
-**Mark Erikson:** So point is, there's an awful lot of experimentation going on in how we as developers are, what tools we're using to do the work and what the workflows look like. And so then between the massive increase in commit scales and, you know, the, the changes in those workflows, we're seeing a variety of different hosting tools come out that, you know, either just, hey, you can have your Git hosting not on GitHub or, but also po- possibly make it more agentic friendly, [00:54:23]
-
-**Carl Vitullo:** Yeah. [00:54:59]
-
-**Mark Erikson:** whatever that means [00:54:59]
-
-**Carl Vitullo:** Interesting. I'm, I'm exploring some stuff around this area as well. I'm going to be coming at it from a very different direction from all of these places, which are still fundamentally anchored around software as a service published on the cloud which I think is limiting. But yeah. [00:55:01]
-
-Two that I wanna shout out. Tangled.org is pretty interesting. They're doing... They're trying to do essentially GitHub on at protocol. [00:55:16]
-
-**Mark Erikson:** no [00:55:24]
-
-**Carl Vitullo:** So it's, you know, it... That's cool. It's a decentralized social media platform, and they're putting basically the social components of GitHub onto that decentralized protocol. So awesome. That's awesome. That's very cool. [00:55:24]
-
-Cloudflare is also doing a, yeah, versioned storage that speaks Git, is their headline. We had some others in the notes from Cursor and Netlify, but I wanna be honest, I don't, I don't feel like either of those are in the right place to successfully execute on that vision. [00:55:38]
-
-**Mark Erikson:** Mm-hmm. I will say that this article on scaling Git was fascinating. there's been a lot of efforts over the years to make Git scale. Microsoft has done a lot of work on, like, virtual file systems and improving algorithms inside of literally the Git implementation itself. This one's more focused on the hosting side of things [00:55:55]
-
-**Carl Vitullo:** Yeah. And okay, this is why I'm skeptical of software as a service cloud-based, 'cause, like, that's the problem. Like, Git is a decentralized system, you know? You can just add a remote, and it... Like, you push. It's exactly the same. yeah, if you're dealing with pushes from literally the entire world, that's really hard to optimize. But, like, I dream, I hope, I wish that at some point we will get to a state where more people can have, you know, world accessible, safe compute that they control. [00:56:16]
-
-Like, I have a network accessible storage here. It technically can run a Git server. Like, there's no reason I couldn't use that as my primary store, and then, like, make that available to some other tooling that is aware of that storage and does collaborative features on top. When you distribute stuff like that, you don't have to worry about load at any individual site anywhere near as much, which is what this Git any, any scale kind of post is talking about. Anyway. [00:56:48]
-
-## Short asides/lightning rounds
-
-some lightning round whatever. [00:57:14]
-
-I saw a fun thing, npm.report. It looks like an interesting way to just get, like, a very brief... I don't know, this is, this is maybe a very early project. Just looking at some of the numbers on the landing page Well, it's certainly not ingesting all of npm to do this. But yeah, it's interesting. It's doing supply chain trust signals for npm organizations, so the audit, visualize, share, track over time. Uh, It's an interesting idea. I'm not quite sure if the execution is fully able to execute upon the idea it has, but it's looks interesting. Supply chain management auditing is so in vogue right now because it doesn't work very well. [00:57:16]
-
-**Mark Erikson:** So I, I mentioned Andrew Nesbitt earlier. He's been blogging for, for a while on package management ecosystems. He's, he's probably the world's foremost expert on all the world's package managers out there, and has put up a lot of blog posts on, like, how they work internally, where they're flawed, all these other things. [00:57:51]
-
-He's also written several satire posts on his blog. , he's written some fake articles about fake AI-driven CVEs slipping through the chains. he did this one a supplier security questionnaire. You know, the kind of thing that, like, a, a company security office would send out to their dependents, except this one's clearly being sent to an open source person. [00:58:10]
-
-And the questionnaire just gets more and more absurd on the requirements that they're placing on this unnamed open source maintainer. And, and that, that's sort of what happens when the legal compliance side of things wants assurance that your supply chain is secure, and two-thirds of your app is just we installed this NPM package [00:58:34]
-
-**Carl Vitullo:** Yeah. Cool. Nice. Love that [00:58:55]
-
-Okay. Well, continuing on our security thread there . I read a really great blog post called Everything I Own, Owned. so this person, Chaz Schlarp, put out a blog post about pointing Claude at various physical devices that he literally owns, that are physically in his possession, and just saying like, you know, "Hey, can you hack this? [00:58:58]
-
-Can you get control over this? Can you put a custom firmware on this?" and the answer resoundingly is yes. [00:59:17]
-
-**Mark Erikson:** Nice [00:59:25]
-
-**Carl Vitullo:** you know, hacked his own webcam a- alarmingly hacked it in such a way that he was able to turn off the recording light which ideally should not be possible. Ideally, that should not be a software controlled feature. It should be electrically impossible for the camera to record while the light is off. Oops, this one could. [00:59:26]
-
-Also hacked his monitor. And I... Something I appreciate is for each of these devices, he puts up a GitHub repo of the new firmware, how long it took Claude to figure it out, and how many prompts from him it took Claude to figure it out. So this, you know, the webcam was three and three quarter hours of Claude time with 33 prompts. His monitor is hour and a, hour and 15 minutes with 13 prompts. A microphone was four hours, you know, four hours and 15 minutes with 32 prompts. [00:59:44]
-
-I think this is really fascinating from a couple of different ways because to tie it into a like macro, huge question of ownership conversation that I've been hearing about for the right to repair. Like most things don't let you repair it. They don't let you, you know, access any kinds of internal state. And so like now that these AI tools are good enough at reverse engineering and cybersecurity stuff to just hack it, like, hmm, that's actually pretty interesting for right to repair. Like you know, to the extent that rules and policies are only as good as your ability to enforce them. [01:00:17]
-
-Like oops, they can't enforce their own security practices because it used to just assume that it was too hard to flash a custom firmware and now it's actually not that hard as, if you know generally what you're doing. [01:00:53]
-
-**Mark Erikson:** Or a lot of cases, if you don't know what you're doing or just willing to tell Claude, "Try harder." [01:01:05]
-
-**Carl Vitullo:** Right. Right. here's a fun one. This is a mini key light. So I think it's, you know, it's like for video production, it's just like a little controllable two by three inch light. And he says, " This one turned out way more interesting than I expected. It's the only one with meaningful firmware integrity protection. It signs the firmware updates with ED25519 and a hash of the firmware payload and rejects firmware that doesn't validate. Unfortunately, while that's an improvement, it protects the firmware ex- at exactly one point in time, during updates. I asked Claude to look for an exploit that might enable, you know, other attack surface, and it found an HTTP post request that drops a payload straight into the internal UART which includes a memory poke command." [01:01:09]
-
-So it, you know, it's got signed [01:01:50]
-
-verification [01:01:53]
-
-**Mark Erikson:** Change this value." [01:01:54]
-
-**Carl Vitullo:** Yeah. So it's, it, it has ostensibly update security, but it also has an HTTP endpoint that will let you, like, arbitrarily revise memory. He says, "This means a single HTTP post of ATSC equals," and then two hexadecimals comma-separated values, "turns the signature check into a no-op, and we can freely update the firmware." So it's just like, man, that's crazy. [01:01:55]
-
-That's great. [01:02:17]
-
-**Mark Erikson:** you tried [01:02:18]
-
-**Carl Vitullo:** At least you tried. Yeah, defense in depth, it's really hard. I don't know, that's really interesting. Like, if we own, if we more meaningfully own the ability to control what the tech in our rooms is doing, that's powerful. I appreciate that. We should have more of that. [01:02:19]
-
-Final AI security adjacent thing from the Trail of Bits blog. The Sorry State of Skill Distribution, talking about how the skill marketplaces for AI agents are full of malicious skills that will exfiltrate your, you know, credentials and blah, blah, blah, blah, blah. Yeah, so don't download arbitrary skills without reading what they're gonna be doing. You know, this is just an extension of I don't know, running untrusted code is never good, and running untrusted skills that will have the ability to run untrusted code on your hardware is even worse, ' cause these are smart. Yeah, reminds me too, I, I just learned, this happened last month, but a certain AI platform controlled by a person whose name I don't like to uh, give airtime was, it turns out the whole agent itself was uploading all of the directory that you ran it in with no control. So it would pull every, every file in there and just dump it into a remote GCP container. [01:02:33]
-
-So, like, state of security right now in the AI w- world is pretty rough. Most people are being very sloppy about it, and if you are riding the cutting edge, the odds that you run into something that will aggressively attack you is pretty high . [01:03:32]
-
-## Conferences (React, Javascript)
-
-Oh yeah, Mark, tell us about this conference [01:03:46]
-
-**Mark Erikson:** Yep same two I mentioned last month, and conveniently they're the... I, I know about them because I will be speaking at both of them in the next few weeks. ZurichJS is happening, I believe, on September 11th in Zurich, Switzerland. I said it last time, I'll say it again, because he r- especially because he ran across the transcript and thought it was very heartwarming. Faris Aziz is a good, close personal friend of mine. He's running this conference. He's been running the ZurichJS meetup for the last year or two. This is the first time conference for them and I know how much effort he has been putting into putting this together, from selling tickets to doing outreach and getting sponsors to building an entire conference management platform from scratch. [01:03:48]
-
-Faris is awesome. This will be a fun conference. The speaker list looks great. I'm looking forward to seeing a lot of good, good friends there. If you are anywhere in Europe or even not in Europe, consider buying a ticket and joining us there. It'll be great. [01:04:33]
-
-similarly, [01:04:46]
-
-React Alicante is in Alicante, Spain. [01:04:47]
-
-I believe that's around September 23rd, 24th-ish. That's also been a lot of fun. it's a very well-run conference. Another great organizer, Victoria. it's a good conf- there's a lot of good people there. Come join us. Hang out. Talk in real life. It's a thing [01:04:50]
-
-**Carl Vitullo:** Yes, I can confirm that Mark is a lovely person to go to a conference with. [01:05:05]
-
-Cool. All right, that's all we got for you this month. Thanks for sticking around an extra 25 minutes past our... Well, I'd say past our typical end time, but it's not like we've ever hit that, I think, this year. we'll be back next month. Maybe not on the last Wednesday, 'cause it's the last day of the month. Or we'll be back in your podcast feed just as soon as we can after we record. [01:05:09]
-
-Yeah, thanks so much. If this is a podcast that you find valuable I'd actually just personally love to hear it. If you shot me an email to hello@reactiflux.com and said something about how this has influenced the way you think or do things, that would be personally meaningful to me. [01:05:27]
-
-Or give us a review. Tell somebody else that you know about this podcast. That would all be very helpful. We have a sponsor for next month, which is great. yeah, so that should cover most of the costs of producing it for the year, I like not paying for it myself. cool. Thanks so much. See you next month. [01:05:41]
-
-**Mark Erikson:** Take care [01:05:58]
-
- [01:05:58]
diff --git a/src/transcripts/tmir-april-2023.md b/src/transcripts/tmir-april-2023.md
deleted file mode 100644
index 638ccb2..0000000
--- a/src/transcripts/tmir-april-2023.md
+++ /dev/null
@@ -1,461 +0,0 @@
----
-title: This Month in React (April 2023)
-date: 2023-03-29
-time: 10am PT / 5PM GMT
-location: Q&A Channel on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Matt Pocock as we break down This Month in React. A lot of news this month, with new library releases, TypeScript 5.1, and React server components. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Matt Pocock](https://twitter.com/mattpocockuk)"
----
-
-
-
-# This Month in React 2023 April
-
-**Carl Vitullo:** Welcome everyone. Thanks for joining us for April's edition of this Month in React, where we talk about what's going on in the React ecosystem. Mark and Sebastian, could you introduce yourself? [00:09]
-
-**Mark Erikson:** I'm Mark Erickson. I'm a senior front end engineer at Replay, where we're building a true time traveling to bugger for JavaScript. Also, I do a whole lot of Redex stuff. [00:18]
-
-**Sebastien Lorber:** So, yeah, I'm Sebastian. I created the This Week In React newsletter, and I'm also the maintainer of Docusaurus, which is a static site generator that many direct websites, use today. [00:30]
-
-**Carl Vitullo:** I'll kick us off. The way we do these news events is we do a round robin where one of us will introduce a link from the past month and then we all discuss it until we run other things to say. [00:40]
-
-## React Visualized, react.gg
-
-- [React Visualized, react.gg](https://react.gg/visualized)
-- [Launch tweet](https://twitter.com/tylermcginnis/status/1642969928562262020)
-- [The Story of React, uidotdev](https://www.youtube.com/watch?v=Wm_xI7KntDs)
-
-**Carl Vitullo:** Yeah, I guess I'll start with React Visualized react.gg. I just saw this, this is from Tyler McGinnis. He does the bites.dev newsletter. He's been in the React ecosystem for probably, at least as long as I have, maybe longer, I feel like. But definitely a, a giant in the ecosystem and excited to have such a high quality looking resource for learningReact. [01:01]
-
-**Mark Erikson:** Yeah, so there's, there's a couple things going on here. So Tyler runs a training company called UI.Dev, which makes, you know, a bunch of different courses including React Things, and I think they've had a couple different iterations of some of their different React courses. One thing I've seen Tyler do over the last couple years is that he's, he and this company have made a few different videos explaining various aspects of React, but from my perspective, even more importantly, explaining why some of those things about React exist. [01:31]
-
-This React Visualized thing, I actually saw them do a video version of this first. It talks, it like goes back in history to, you know, 2010, ancient history by this time. [01:44]
-
-**Carl Vitullo:** Ancient! [01:44]
-
-**Mark Erikson:** And, and it talks about, you know, frameworks like Angular and backbone and or, you know, even, vanilla JS, JQuery and some of the pain points people were experiencing working with those. And then it talks about how React was designed to solve some of those pain points as background information. It's sort of like a history lesson plus a, like why does React exist plus, like what are some of the basic concepts of React as an introduction. [02:11]
-
-He did both a video that I saw posted on YouTube. I'm not sure it's actually, it's actually linked from this site, and then this actual React Visualized site, which is semi-interactive visual page that shows a lot of that same information. I'm a really big fan of the concept, that it helps to understand what problems tools were designed to solve in the first place, in order to help learn them properly. [02:35]
-
-I really appreciate that Tyler is kind of taking that approach with some of this training material. Also, like if you, if you haven't seen any of the videos that Tyler has done, they do a nice little mixture of like, straight up serious explanation and historical clips of people talking at conferences where they were announcing certain tools and then like random, snarky, funny bits. [02:57]
-
-**Carl Vitullo:** Nice. Yeah, I do. I do love the, all the context for why React is, I think it's really important to understand where it came from in order to understand why it is the way it is. I think that is a very helpful framing. I hadn't heard about the, the YouTube videos, so, thanks for, thanks for putting that on my radar. I'll see if I can find some links for when we publish the recording of this. [03:17]
-
-**Sebastien Lorber:** Yeah, I think the. they build all this because they are releasing a course, pretty soon. That is a work in progress, and they created their own, course platform. So somehow I think this resource is, is a symbol of the, the quality of the course that they try to, to achieve. And it looks like, maybe it'll be the, the best competitor to Josh Comeau's course, I think because, both, look, like very polished. [03:42]
-
-**Carl Vitullo:** When your competition is Josh Comeau that you're in pretty good company. Cool. [03:46]
-
-Yeah, Mark, you want to kick us off with our next link? [03:49]
-
-## Immer v10
-
-- [Immer v10](https://github.com/immerjs/immer/releases/tag/v10.0.0)
-
-**Mark Erikson:** Immer version 10 just came out this last week. And for background, Immer is a library to simplify making immutable updates. So if you've used React, or Redux, you're probably familiar with having to do a whole bunch of, like spread the object, spread the nested object, spread `state.a.b.c`, or you know, mapping the arrays, slicing the arrays, concating the arrays, all that kind of stuff. Immutable updates are hard to get right. They're long, they're hard to read. It's easy to make mistakes. [04:17]
-
-Immer is a great library from Michel Westrate, the author of the MobX state management library. It lets it wraps your data in a proxy object, and then inside of that, you can write what looks like mutating syntax. So, `state.value` equals 1, 2, 3, and it traps those changes and turns it into a safe and correct immutable update. And in fact, we've been using Immer inside of Redux Toolkit since the very first proof of concept. [04:46]
-
-Immer has been around for a few years and they were on version nine. Immer still had, various pieces of legacy support. They had a ES5 fullback mode so that it would work in environments that didn't support proxies, which was primarily either IE11 or older versions of React Native before the Hermes JavaScript engine added proxy support. It, it also was trying to be like a little too correct in copying properties on objects. [05:14]
-
-It was doing a lot of like diligent, careful little checks for getters and a bunch of other things, and it was like correct behavior, but that also kind of slowed down the work of making the copies, for the most part, you know, assuming you're dealing with small data that wasn't too much of a per overhead and goodness knows the, the simplicity benefits made it worth it. [05:35]
-
-But for Immer 10, Michel Westrate made a bunch of updates. he dropped the ES5 fallback, and he also kind of adopted a looser approach to copying properties in new objects that is significantly faster. He'd been putting that, he'd been working on that for about the last month. Put out a few betas. [05:55]
-
-We tried them out over in Redux Toolkit, and Immer 10 final just came out about a week ago. It is noticeably faster and it's nice. And I actually contributed a PR to help improve the build tooling setup, and that helped improve some of the module formatting, ESM, CommonJS, and also help shrink the bundle size as well. [06:19]
-
-So I'm really excited about that in general, and especially because that's gonna be included in Redux Toolkit version two, which we've already got in Alphas. So it's sort of a, a free win for a lot of the ecosystem in terms of bundle size and performance. [06:33]
-
-**Carl Vitullo:** Nice. Yeah. I know that Immer from the start relied on on a lot of newer JavaScript features. I remember it being like a little bit of a, you know, maybe not a miracle, but a tough project to get it to work in more legacy environments like ES5. So now that they're able to drop some of that code. Makes sense that there'd be a lot of, you know, long tail enhancements, like bundle size and performance. That's awesome. Hell yeah. [06:58]
-
-**Mark Erikson:** Michel Westrate is a genius. [07:00]
-
-**Sebastien Lorber:** Yeah, I actually, I've seen a few, competitors projects. I don't know, but maybe, one or two were claiming to be, much faster than ImmerJS, but I think maybe they didn't support the older environments in the first place. So of course, it's, it's easier when you reduce the scope of, the library. [07:20]
-
-**Mark Erikson:** Yeah, I, I saw two different Immer equivalants, or competitors, pop up within the last few months. one is called Mutative and the other is called Structura. and they, they both perform the same basic function, wrap your data and a proxy, track the updates, make 'em immutable. [07:38]
-
-On the Redux side, we've had Immer built-in as a hard coded, non-negotiable part of `createSlice` from the beginning. Partly because we think Immer is using Immer is the right choice. But like we've had people say like, "I don't wanna use Immer." And we're like, then don't use Redux Toolkit because we think it's the right thing to do. And we're not making that configurable in any way. [08:00]
-
-Because a couple potential competitors did come out, we actually have an experimental PR over on the Redux Toolkit side that tries to let you swap out which immutable update library gets used inside of like create slice and stuff. It's tough because we actually use those imports in a lot of different places and so, you know, trying to figure out how to sort of turn them into like factories that let you configure it is tough. [08:27]
-
-And I'm, I'm not sure if that'll actually end up getting merged, but given that there's a couple other equivalent tools for immutable updates, we figured it was worth at least kind of playing around with it a little bit. [08:38]
-
-**Carl Vitullo:** Nice. Yeah. Makes sense. [08:39]
-
-Yeah. Sebastian, you wanna take us off? [08:41]
-
-## NextJS 13.3
-
-- [NextJS 13.3](https://nextjs.org/blog/next-13-3)
-- [Rich Harris talk](https://www.youtube.com/watch?v=uXCipjbcQfM)
-- [Notes on talk](https://blog.jim-nielsen.com/2023/notes-from-richs-talk/)
-
-**Sebastien Lorber:** yeah. Well, wanted to to talk about, the new NextJS 13.3 release. I think this one is interesting, in particular for one thing that I am particularly excited about. It's not the parallel routes and things like that, but more, the, the static export because, I think they, they don't highlight this enough in their marketing, but when you build the right server components with NextJS, by default, they are static. And if you don't choose any dynamic api, like getting the error of a request or getting the querystring or things like that, the server component will actually run at build time instead of, run time. So I think it's a really interesting property you can, configure if you want the server component to be static or to be dynamic. [09:29]
-
-But by default, it tries to automatically detect if you use any dynamic API and decide for, for itself if it should run at, build time or at run time. So, I think this is really, really interesting and they now support the static export. So basically this means if you don't choose any dynamic API anywhere in your app, you can export your, NextJS website statically, and all the server components will run at build time. [09:58]
-
-I think it's quite exciting, and also this works with, nested router. So the static or dynamic nature of the, of your components will depend on the root segments. So, for example, you can have a part of your page that is dynamic and some other part that is static. In the end, they really try hard to, to make, most of your components static, if it's possible. [10:21]
-
-And the, the rest will be dynamic, but they don't render too much things. And try to, to build, as much as possible at build time, all the server components. [10:32]
-
-**Carl Vitullo:** Nice. Yeah, that's really, that sounds really cool. I guess I, I thought that they already had something for a static export. I know that we, we use next for the Reactiflux website, I think that I did some kind of static export. [10:46]
-
-**Sebastien Lorber:** Yeah, it, it existed, but not for the, for the new app root directory, so it was not, working for server components yet. [10:53]
-
-**Carl Vitullo:** gotcha. Okay. That makes sense. Okay. Yeah, I. I haven't touched that in probably a year now, so it definitely did not get the app router in there. Okay, cool. Very nice. Yeah. I also see that they have new metadata API and dynamic open graph generation. Those both sound pretty cool. I know that a lot yeah, just open graph and the review image. [11:15]
-
-I think that's, I feel like over the last year or two, I've seen a lot more people, especially for like their blogs and their personal sites, treating that open graph as a, more of like a first class feature, rather than just sort of like an afterthought of copy some text outta the page and boom, there you go. [11:32]
-
-So having some more first class support for that from Next, seems like it will enable a lot of really cool features. [11:40]
-
-**Sebastien Lorber:** Yeah. actually I'm, I don't know exactly exactly how the integration work, but as far as I understood the OG image, package that they created only runs on Vercel because it requires some tooling available on the edge to, to make it work. so I wonder if it doesn't create coupling between NextJS and Vercel as a host. [12:04]
-
-So, I don't know. It's, it's not, mentioned in the blog post, so, so maybe I'm wrong, I don't know, but, recently there was someone that posted a blog post that says, "I am able to run a Vercel OG image on Netlify," or another host, I don't remember which one. And it required some, some tricks to, to make it work. [12:24]
-
-So it was not so, so easy. And I'm not sure if this package works everywhere yet. [12:29]
-
-**Carl Vitullo:** Gotcha. Yeah, I know that's been a, a pretty common point of negative feedback about Next is that everything works on Vercel first. [12:36]
-
-**Mark Erikson:** Yeah, that's that. That was the same thing that was going through my mind. So with a couple caveats that I have not used server components yet, and frankly, I've never worked on a project that needed SSR in any form. So I can't speak from trying stuff out myself. First it's very, very good that next does have a static export option, and I know that the new React docs where they're talking about picking a framework, do try to, you know, actually link and say that hey, you can use next without an actual running next server instance on your backend. [13:11]
-
-And I've seen Dan trying to, you know, help clarify that on Twitter. But I think some of the unease that people have with this, you know, this shift in advertising and direction from the React team is that they feel like they're being pushed towards next and Remix and stuff. Where the default path is you need to have a server running. [13:35]
-
-It's going to work best on Vercel. It's very easy to end up using features that require, you know, a whole bunch of additional entanglement. And yes, the options exist where you can skip that stuff, but the default happy path is adding all the, you know, all these dependencies and servers and stuff. And it, it's tricky to kind of say separate, like you can go without that stuff, but you have to do work to try to skip out on that. [14:01]
-
-I think that's what's, you know, kind of adding to this feeling of concern. [14:06]
-
-**Carl Vitullo:** Right. Yeah. Makes sense. But you know, I also definitely understand the motivation for, you know, there've been a lot of new, new ways to approach web development over the last couple of years with like ,edge workers and things like that. And I think that there's a lot of really exciting possibilities coming out of that. [14:23]
-
-So I understand the impetus to try and offer like first party ways to explore that. And yeah, I mean, I guess, you know, control over the server definitely makes it a lot easier to offer a good experience. But yeah, I guess I understand both sides of this, which is not a very exciting take (laughter). [14:41]
-
-**Mark Erikson:** Quick side note, Rich Harris recently did a fantastic talk. He, he gave like his thoughts on 10 different topics and he was rating them in terms of spiciness and, even the highest spicy rated takes weren't necessarily all that spicy. It was actually very thoughtful, deep nuanced discussion of trade offs of different tools and scenarios. [15:02]
-
-**Carl Vitullo:** Yeah, that's definitely someone I would expect to, or that I would have a lot of trust in to talk about. Topics like that with a lot of nuance. [15:09]
-
-## New React documentation translation
-
-- [New React documentation translation](https://github.com/reactjs/react.dev/issues/4135#issuecomment-1518443599)
-
-**Carl Vitullo:** All right, I'll move this on with our next, this is, you know, maybe not a whole lot to talk about here, but the new react.dev documentation site is getting translated. [15:18]
-
-I know that that was a, you know, that was one of the, points of negative feedback I heard about it is the old docs were in available in so many different languages and the new new docs were not launched with support for those. So good to see it as a fast follow to the launch. Looks like it's been in in the works for a long time and seeing a lot of work done. [15:37]
-
-I see a huge, huge list of translations. [15:40]
-
-**Mark Erikson:** And I know that as a whole, the reason why the docs were delayed so long was Dan was waiting to, was trying to get the content to, you know, a sufficiently complete level, and also make sure that the explanations and the tone were the right way. It's kind of hard to really start translation when you're still iterating on that process. [16:01]
-
-**Sebastien Lorber:** If you refactor everything, it's a pain for the translators because they have to, the, the strategy that they used is based on a repository, so they have to, some of the, there is the main repository with the trans, the English language, and there are folks for each language and. They synchronized the new documentations from the upstream language to the older folks. [16:25]
-
-They have a bot to automate this, but, still I think they, it can be a bit painful to manage all this and to ensure that there are not, merge conflicts between, the, the current translations and the new documentation that the red car team is aiding. So, it's better to, to have most of the content quite polished in the first place before starting the the translation effort, I think. [16:49]
-
-**Carl Vitullo:** Yeah, definitely makes sense. Every language you wanna do it in explodes the amount of work or you know, it adds one more copy of it. So given that, I think, looks like the list of language they support is easily 15 or 20. So definitely trying to write all of those in parallel is just like a non-starter for that. So yeah, glad to see you coming out. [17:11]
-
-**Sebastien Lorber:** Because the translation workflow even is a bit complex, so you have to onboard people if they are not used to it. So [17:19]
-
-**Carl Vitullo:** Right, [17:20]
-
-**Sebastien Lorber:** this is not easy. I think the, hopefully they, they're able to split the work, between, each site. So, each site can somehow autonomously work on the translation. But, you have to explain to each main language contributor how it, it works to, to make them productive in the translation process. [17:41]
-
-**Carl Vitullo:** Right, right. I've only ever dabbled in translation on apps that I've worked on. You know, none of them really had serious international usage, so it wasn't a major impediment, but writing documentation to explain difficult technical concepts in 20 different languages. Like, oh, oh boy. What a task. [17:58]
-
-Well, Mark, what's up on your list? [18:00]
-
-## TypeScript 5.1
-
-- [TypeScript 5.1](https://devblogs.microsoft.com/typescript/announcing-typescript-5-1-beta/)
-
-**Mark Erikson:** So TypeScript 5.0 just came out, and hot on the heels is TypeScript 5.1 in beta and one of the changes there has to do with TypeScript support for JSX syntax and type checking what gets returned. Now I only barely understand what's going on here, so you know, please, please take my explanations here with a grain of salt, TypeScript support for JSX was basically originally started to support React. [18:28]
-
-But JSX is not a React only concept today in a lot of other frameworks like Solid use it. And so TypeScript has had to do this kind of difficult dance internally where they need to be able to handle JSX but not lock their support of it to only working with React specifically. It has to be a little more generalized, and that's had limits on how the, the type checking process can work. [18:55]
-
-This has actually had ripple effects on how you can use TypeScript in your React components. And the biggest pain point is that due to something about the way JSX elements were implemented, TypeScript would actually yell at you if you tried to return some of the newer, non-JSX return values from a component. [19:15]
-
-So, you know, if you tried to return like strings or arrays from a function component, it's totally legal JavaScript and as of like, you know, React 16, it's totally fine, but TypeScript would yell at you and say, "you can't do that," and you end up having to wrap that in a fragment that serves no purpose other than to satisfy TypeScript. [19:34]
-
-So, The React team has been working on trying to allow some components to do things like return promises, and of course, TypeScript would not allow that given its current type checking support. This discussion started like, two or three years ago and I think it's been a very long running issue, and the TypeScript team just merged a PR that somehow alters how TypeScript interprets and type checks JSX syntax. [20:02]
-
-And this seems to loosen up what it will allow and is apparently going to make it easier to do things like returning a string or an array from a component. And it'll be legal as far as TypeScript's concerned. And it will also unlock future changes for things like returning promises from components. Basically TypeScript is trying to make it better and easier to return a broader array of things from components with JSX syntax. [20:30]
-
-**Carl Vitullo:** Yeah, I definitely remember encountering those sort of type bugs where I know that this is a valid thing to return from this component, but actually getting TypeScript to recognize that was a pain in the butt. You know, figuring out what type I'm supposed to use to describe the component, whether that's React.FunctionComponent, or you know, React.FC or whatever it is. So I'm excited to see this improve the situation. [20:54]
-
-**Mark Erikson:** The default recommendation has been just don't use it at all. Provide a type for the props and let ts figure out what the return type is. [21:02]
-
-**Carl Vitullo:** Hmm. Yeah. Excited to see that get better. [21:05]
-
-Cool. Yeah. Sebastian, you wanna take us on our next news item? [21:08]
-
-## MillionJS, one-function React perf wins
-
-- [MillionJS, one-function React perf wins](https://twitter.com/aidenybai/status/1650406345517199361)
-
-**Sebastien Lorber:** Maybe you've seen there is a new package called, MillionJS. I think it's, it's interesting and it, it got my curiosity. The idea is somehow to, to make, to improve the performance of the virtual dom by using, a block based virtual DOM. As far as I understand it, the idea is that if you have two virtual DOMs that have exactly the same size and structure and things like that, you are able to optimize this and perform the diff faster. [21:37]
-
-And recently there was, a new version of MillionJS, which support, NextJS too. So it's possible to integrate into an existing app to make it faster. And, there's also a repository that now is there for learning purpose called HundredJS. And the idea is that, it provides a very simple, implementation of a block-based virtual DOM, but you can, understand, the idea. [22:04]
-
-So I don't know exactly how it works yet, but, I found, it was quite interesting somehow the first time I came across this project, I thought, oh, they have a beautiful landing page, and the developer is 16 years old or something like that, I don't remember, but he's very young. I somehow dismissed this project, but, now it, I, I get more curiosity for it. I think, maybe this will be, an interesting thing, to, to follow in the years to come. [22:30]
-
-**Carl Vitullo:** Yeah, interesting. This is, this is a new project to me, but you know, anything that promises to make stuff faster just by wrapping it into function, is both interesting and draws a little bit of skepticism (laughs). I've definitely written some components, or rather some helper functions that look like this to solve performance problems for myself. [22:50]
-
-The main situation I'm thinking of is where I have a very slow, you know, maybe it's very complicated or something, some slow component as part of a larger page. And some number of years ago I wrote a, a little helper that just, it, it was basically sort of a, a cheap async rendering helper. It would just render nothing for one render pass and then render the actual children. [23:13]
-
-Yeah, I used that on a very complicated list page, and it took initial render down from like over two seconds to tens of milliseconds just really helped the sense of interactivity, if not the total overall render time. You know, the, the actual render time didn't change that much, but at least you can interact with the page while it's doing all of that. [23:32]
-
-So I, I wonder if it's doing something similar to that, just enabling rendering to split up over multiple passes. But yeah, cur curious to dig into that more. [23:41]
-
-**Sebastien Lorber:** Yes, I'm, I don't know exactly. I, I can tell, but this is something interesting to follow, I think. So we will figure out, soon, I think (chuckles). [23:49]
-
-**Carl Vitullo:** Cool. Yeah. I guess I'll pick us on to the next one. [23:51]
-
-## React Server Components
-
-- React Server Components
-- [RSC Quiz thread](https://twitter.com/dan_abramov/status/1648923232937058304)
-- [XHP v JSX](https://twitter.com/dan_abramov/status/1648830869304426500)
-- [Lenz RFC for Apollo/RSC](https://twitter.com/phry/status/1649520340647673856)
-- [AsyncContext stage 2](https://twitter.com/sebastienlorber/status/1639183216799100928)
-
-**Carl Vitullo:** So this is not necessarily one single news article, but definitely a topic of discussion, React Server Components. There's been a lot of news and discussion coming out over the past month or so. I saw Dan Abramov did a quiz thread on Twitter. Looks like it answers a lot of questions about how React server components behave. [24:11]
-
-Definitely interesting information in there. I have not yet really used React server components at all, so I , I don't feel like I can speak too deeply on this subject, but Mark, Sebastian, have you used server components much? [24:23]
-
-**Mark Erikson:** Not in the slightest. [24:25]
-
-**Carl Vitullo:** Hahah. [24:26]
-
-**Sebastien Lorber:** No, (laughs) no, I mean, I only work on Docusaurus, so there is no Server Components yet, but I, I wish, to do that, soon, but need to figure out a few things before. [24:38]
-
-**Carl Vitullo:** Yeah. Yeah. I feel that. [24:40]
-
-**Mark Erikson:** And, and similarly, like my day job at Replay is, replay is entirely a classic client side, single page app. And between that and all the Redux stuff, I don't have time to go play with other new shiny things. [24:53]
-
-**Carl Vitullo:** Right, right. Yeah, I know that Dan has been on a, a bit of a, a bit of a PR blitz. Yeah. He's been on a tear doing all sorts of events and talking about React Server Components a lot. We've talked briefly about doing an event here, and maybe having an ongoing channel for people to ask questions about it. So yeah, stay tuned for news about that. [25:15]
-
-But, nothing to announce at the moment, but yeah, so I saw that quiz thread from him. I also saw a great sort of history of that I just posted in the chat. it talks a lot about X H P and hack and Facebook code going back to 2010 era. Definitely. Yeah. I mean, like we're talking about with React Visualized, I think the history of why things came to be what they are is super helpful for understanding what they are. [25:42]
-
-So I, I think that's a, I think that's a good thread to read, to understand what's going on. [25:46]
-
-**Sebastien Lorber:** Yeah, definitely. [25:47]
-
-**Carl Vitullo:** Yeah. [25:48]
-
-**Sebastien Lorber:** I think the, the, the quiz is very interesting because somehow we challenge your, your intuition that you can have. And honestly, I, I, I think I got all free and sales correct, but, I wasn't absolutely sure about, any of them (laughter). So this is, this is really not easy and I think many people, don't have the intuition of, of several components. [26:09]
-
-So this is really worth to, to take it and see if you, if you have the intuition. [26:14]
-
-**Carl Vitullo:** Yeah, definitely. [26:15]
-
-**Mark Erikson:** It seems like one of those things where half the people are gonna get this wrong either way. [26:19]
-
-**Carl Vitullo:** Right, right [26:20]
-
-**Sebastien Lorber:** (chuckles) [26:21]
-
-**Carl Vitullo:** Definitely a, a big iteration on the React mental model. So I'm sort of, I'm sort of waiting for the dust to settle before I dig too deep into it. Just, you know, a lot of churn going on, a lot of innovation and discussion, and I'll, I'll come through a little bit later and see what it all looks like, but it's definitely a lot to stay on top of. [26:40]
-
-Cool. Yeah. And one more link I wanna paste from one of our, one of our community members, Lenz Weber-Tronic, phryneas' post is, looks like he's looking into React Server Components, how to connect it to Redux Toolkit in Apollo. [26:54]
-
-**Mark Erikson:** Yeah, so Lens is my Redux Toolkit co-maintainer created our RTK query data fetching library, and he also recently got hired by Apollo to work on Apollo client. So we've, we've had a couple of different discussions with the React team about, you know, how our external data libraries supposed to integrate with suspense. [27:14]
-
-And the shorter, the short answer is, "we're still not really sure, go make new APIs instead of building that into your query hooks." But then he's also been doing a bunch of research over the last few weeks into, how you server components work, and how would you integrate external data fetching libraries into server components in the lifecycle? [27:34]
-
-And he's only, he's only hinted at bits and pieces and some of that, some of those hints were in this, this Twitter thread, but it sounds like he's been trying to put together a fairly large write up to start a discussion and ask some questions. So I am actually legitimately curious to see what his summaries are and what his questions are because again, like I don't have time to look into this myself, so I'm glad Lenz does. [27:59]
-
-**Sebastien Lorber:** Yeah. [27:59]
-
-**Carl Vitullo:** Yeah, definitely very curious to see what he, his conclusions are. Yeah, I mean he's been active in Reactiflux for years and very helpful and thoughtful, so very much curious to see what he thinks. [28:10]
-
-**Sebastien Lorber:** Something, I'm thinking about is, you know, we already discussed that in the past, but I think it's a bit related, is the new AsyncContext proposal, which is a stage two for standardization in JavaScript. I have the feeling that the, the idea of this API could be to, to use React context in a cross platform where in both our components, when they use I think, weight and, also in a regular components that we use today on the client and things like that. [28:41]
-
-I think it's interesting because, it could enable you to provide the, the, the context of maybe Apple, Apollo or React Query to your tree. No matter if it's a client component or a server component, it should be able to work. So, I look forward to, to see this api, become adopted everywhere and see if, and see if it unlocks any use case. [29:06]
-
-I think Sebastian Markbåge posted something, recently and, and somehow it summarized the idea that, that I tried to, to explain is that you could use eventually the standard, I think, context feature as React context directly. So I think this is interesting because this would not only work with, React hooks, but also, as a regular, JavaScript feature that we can work both on the edge, on the NodeJS runtimes, and also on the client. [29:38]
-
-Maybe it's not what is, maybe it's not, it's not the challenge that Apollo is facing to integrate with several components. I don't know. But I think it's one of the piece that could make it, easier. [29:49]
-
-**Carl Vitullo:** Yeah, definitely always nice to rely on standard browser features rather than something hand rolled within a library. I'm sure React would love to have some sort of standardized context. [30:00]
-
-**Mark Erikson:** Use the platform. [30:01]
-
-**Carl Vitullo:** Use the platform! [30:02]
-
-Cool. Yeah. Mark, what have you got next? [30:06]
-
-## Recommending uncontrolled components
-
-- [Recommending uncontrolled components](https://twitter.com/dan_abramov/status/1641830612955803650)
-- [API Reference](https://react.dev/reference/react-dom/components/input)
-
-**Mark Erikson:** Okay, so the existing React Docs or the, I guess now the, the Legacy React Docs always had a page on forms. And the standard direction in that docs page was write controlled inputs where React is always in charge of pushing the current value of the input into the DOM. And your job is to provide, you know, here's what the current value should be and here's, you know, a, a callback that sets state and that went along with Reacts philosophy that, you know, the UI should always be based on the state. [30:42]
-
-And that made this idea of uncontrolled inputs, sort of like a, a very non idiomatic approach within the React ecosystem. Within the last few years, we've seen a little more acceptance of using uncontrolled inputs as being valid. The library React Hook Form, I believe, uses uncontrolled inputs and, Remix has been doing things with that as well. [31:08]
-
-So the new React docs are complete as far as the learning content, and they're basically complete as far as the API reference material, but they don't have a lot in the way of usage guide pages. There's a lot of pages that just simply need to be written from scratch for things like testing, and that includes forms. [31:29]
-
-There, there is no specific page on how to use forms in the new React docs. However, what I did not realize is that the API reference section actually has some pages on how to use specific HTML tag types in React. That includes the input tag and this reference page on using input tags actually talks about the difference between controlled and uncontrolled inputs, and basically recommends using uncontrolled inputs by default. [32:05]
-
-This is actually a really big shift in what the React team is suggesting people should do. And it there, I think there's a few different reasons for it. One is that, you know, setting up controlled inputs has always taken work. You have to have the useState, and the callbacks, and the value, and you're putting in the extra effort to make things consistent. [32:26]
-
-And then I think it also kind of ties into some of the React server components work that they're doing where they want to be able to pass form state back to the server processing. And I guess that seems to work a little better if the inputs are uncontrolled. So I, I have not even gone through this input docs page in detail. [32:47]
-
-I didn't realize the Docs page existed until I saw Dan tweet about it, and I definitely did not realize that the React team was shifting their recommendation there. So it's, it's definitely worth going through and trying to read that page and see what it has to say. And I don't know, like it, it's that shift in patterns and recommendations again. [33:05]
-
-**Carl Vitullo:** Yeah, I'm, I'm sort of ski- skimming that page while you're talking a little bit and. Yeah. One thing that jumps to my mind is the use case of trying to provide very, very high quality validation for input values, and it's been my experience that the browser doesn't expose very good primitives for validation. [33:27]
-
-I think at best you end up, you can do like, what, a regex based on the value? But you know, like especially if you need like some sort of dynamic validation. Like for instance, I've done password inputs when signing up that hit an API to see if the input password is too similar to, you know, publicly cracked password lists or otherwise perform some sort of processing that requires an async step, and going from an uncontrolled form to a form that has advanced validation, like that seems like a pretty big lift. [34:00]
-
-So I, I, I generally agree with the idea that you should lean on the platform as much as possible. We should not write JavaScript that duplicates behaviors that the browser gives us free. But yeah, there's definitely some, some gaps in what the browser offers around forms and validation. So that seems like it's gonna be a bit of a, a point of friction on an ongoing basis. [34:21]
-
-I guess one other thought I want to connect it to, I just had opportunity to see the React documentary again, and it was funny hearing, I can't remember the exact line, but somebody mentions that, nobody's ever written a form and React as of, you know, when it was being open sourced. [34:37]
-
-And so it's, it is funny to see now, yeah, no, actually 10 years later. Cause that was uh 2013. Forms in React is still a little bit of an open question. There still isn't complete guidance for what it should look like. [34:49]
-
-**Sebastien Lorber:** I think the, the thing is, maybe the shift happens because of Remix, because, you know, there, there's a lot more traction for progressive enhancement these days, thanks to Remix, I think, it existed before, but not much in React ecosystem. And to, to, to have a progressively enhanced form, you need it to work without React somehow. [35:10]
-
-So if you, if you make it, controlled, you are basically implementing features that will only work if JavaScript is there. So I think also this, this shift is happening because, because of progressive enhancement and the need for a form to be able to just work with HTML and a server somehow. [35:28]
-
-**Carl Vitullo:** Yeah, for sure. [35:30]
-
-Cool. Yeah. Sebastian. Wha- what's your next news article? [35:33]
-
-## Super Apps in React Native
-
-- [Super Apps in React Native](https://www.callstack.com/super-app-development)
-- [RN PS5](https://twitter.com/syke/status/1619413099861413889)
-
-**Sebastien Lorber:** Let me check. I don't remember. yeah, it's, Super App development. There is, a new resource from Gold Stack, the React Native company that is presenting the, the idea of Super App development. It's not the first time, but I saw that. I see blog posts of them, mentioning this idea, it's, the, the concept of Super App is quite popular in, in Asia. [35:57]
-
-For example, there is the WeChat app in China, I think. And the idea is that somehow you gather many, many small apps inside a big host app and your users, users are able to seamlessly transition from one app to the over. And, somehow it requires, some, a bit complicated things to, to, to set this up. [36:17]
-
-for example, you don't, you, I think you can't use the default React Native bundler. You have to use a repack, which is, somehow a layer above, webpack to make it work and have got spliting module federations and and advanced webpack features to make this work. So I, I don't know exactly how you set this up, but they, they provided a comprehensive resource with a step-by step, tutorial. [36:41]
-
-And there's also, a showcase repository that you can try so you can actually, build your super up locally and see it work live. And also, I thought there was something quite interesting, but I came across for some place that, I think, I'm not sure, but I think the PlayStation 5 UI is actually a super app built with React Native. [37:06]
-
-And, I will link a with, in the chat to show you why I think that, but, maybe I'm wrong. I don't know. I think it's, it's quite exciting to, to see that, first, React Native is running on PlayStation 5 and, that this is a super app maybe. [37:22]
-
-**Carl Vitullo:** Oh, interesting. Wait, PlayStation 5 UI is implemented and React Native? Is that what you said? [37:27]
-
-**Sebastien Lorber:** Yeah, actually I think they started to use React Native, already at, PlayStation 4, according to the comments. [37:35]
-
-**Carl Vitullo:** Oh wow. That's pretty cool. I didn't know that. Very nice. Yeah, the, the super app, as they describe it, I see that they have a comparison to micro front ends and definitely sounds a little bit similar, sort of a architecture around. Structuring an app. [37:50]
-
-**Sebastien Lorber:** This is, yeah, I think perhaps is the, the mobile term for micro front ends on the web. So it's exactly the same, I think, module federations and things like that. So, [38:00]
-
-**Carl Vitullo:** Yeah, it makes sense. And I think both of those are, or you know, my understanding of micro front ends is it's an architectural decision that is influenced by the size of the team, sort of a, it's maybe not desirable on its own. But in the context of a large company that has, you know, say 80 developers, 80, 100, 200 developers, all working on the same application, getting to a place where you aren't constantly stepping on each other's toes with merge conflicts, and it's just swapping out behavior of shared primitives all the time. [38:36]
-
-I think it— that's sort of the context where these super apps or micro front ends are really important and really, not just important, but kind of necessary for enabling that level of, collaboration. [38:47]
-
-**Sebastien Lorber:** Yeah I think, this is necessary. I think I, I had a case, at work a few years ago where, They wanted to, to build a, a very large application for, a big, company in France. And they wanted to so that each part of the app would be implemented by a different contracting team. basically, we all share the same dependencies, but there are like 10 teams from different companies working as a contractor for the client. [39:17]
-
-So this looks like a, a really good use case for, for using, this kind of, of architecture because, you know, otherwise it's, it's a big mess because you, someone in another team will upgrade a dependency and then you will have a. Really complex side effects for all the other teams and or everybody will, fight again each server to reject the responsibility for, for, for the bugs (laughter). [39:44]
-
-**Carl Vitullo:** Makes sense. Oh man. That's, having multiple different contracting agencies work on the same app. That's like an extra level to that. Because I imagine you need various Yeah. Controls to keep different people from accessing parts they're not authorized too. Yeah. Wow. [40:01]
-
-Cool. Yeah. Well, I'll kick us off with a lightning round. [40:03]
-
-## ⚡️ Core team layoffs
-
-- [Mengdi Chen](https://twitter.com/mengdi_en/status/1648718077796786177)
-- [Robert Balicki](https://twitter.com/StatisticsFTW/status/1648820621252653056)
-- [Matt Carroll](https://twitter.com/mattcarrollcode/status/1648770402272018432)
-- [Sean Keegan](https://twitter.com/DevRelSean/status/1649466893806215172)
-
-**Carl Vitullo:** Just a, a quick shout out that I think is nice to do. A number of core team members for React and, you know, the surrounding ecosystem were hit by layoffs at Meta. Just a, you know, poor run out for our, for our Lost Friends. [40:18]
-
-Just looks like it was a, among others. This is the list that I am aware of top of mind. [40:24]
-
-Mengdi Chen from the React Dev Tools. Robert Balicky from Relay. Matt Carroll doing devrel for React, and Sean Keegan also doing devrel. Yeah, layoffs, they suck, but also seeing Tom Occhino and Dominic Gannaway joined Vercel. So more, you know, legendary React figures moving over there. A lot of, lot of churn going on team right now. [40:47]
-
-## ⚡️ React Miami
-
-**Mark Erikson:** React Miami was this last week and it was an amazingly well done conference. Both Carl and I were there. I, I got to speak. It was excellent, organized. The rest of the speakers were wonderful. The atmosphere was amazing and I got to spend a lot of time talking to, you know, both people that I know from online, from the conference circuit, but also just talking to lots of, you know, sort of lots of random people who are working in different jobs, solving different problems. [41:14]
-
-It was just a wonderful experience. [41:16]
-
-**Carl Vitullo:** Echoing that, absolutely amazing. [41:19]
-
-Cool. Yeah. Sebastian, you got a lightning round link. [41:21]
-
-## ⚡️ react-three offscreen
-
-- [⚡️ react-three offscreen](https://github.com/pmndrs/react-three-offscreen)
-
-**Sebastien Lorber:** I just wanted to mention, react-three offscreen. The idea is that, you use a react-three fiber to run the three descents. And now it supports to be, to run inside a web worker. So basically you, you use something, a standard web API called Offscreen Canvas and it permits to, to draw inside the web worker. [41:45]
-
-So basically you run down your three design inside another thread, and it doesn't block your UI thread. So, It's quite interesting for performance reasons because you can integrate, complex, 3D animations and it doesn't block the, the rest of your website. So I think it's interesting to, to use. [42:04]
-
-## ⚡️ Lingui v4.0
-
-- [⚡️ Lingui v4.0](https://github.com/lingui/js-lingui/releases/tag/v4.0.0)
-
-**Carl Vitullo:** Very cool. I'll take next Lingui 4.0. I've used Lingui in the past, it's a internationalization framework. I've tried a couple of different internationalization frameworks and wasn't super happy with them, but Lingui actually worked pretty reliably, when I did need to use it. So just shout, shouting them out. New major release. [42:24]
-
-**Sebastien Lorber:** Yeah, actually I'm, I'm in touch with the, the guy, that sent me this link for just today, and I, I asked him to, To write a blog post and maybe we will feature it better in the newsletter next week because, I think may, it looks interesting. It looks like a bit react-intl, but, provides some additional, developer experience on top of it. [42:48]
-
-I think, I mean it's not, a layer on top of, react-intl, but it's quite similar. It's using the ICU message syntax and, quite similar features, like the ability to extract the translation from the cloud and things like that. So I think they will, they will write a blog post to present better this new release quite soon. [43:10]
-
-**Carl Vitullo:** Cool. Yeah. Maybe we can go go in more in depth next month. [43:13]
-
-**Sebastien Lorber:** Yeah. [43:14]
-
-## ⚡️ Redux Toolkit 2.0 alpha
-
-- [⚡️ Redux Toolkit 2.0 alpha](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-alpha.5)
-
-**Mark Erikson:** I've got a, I've got a semi self plug. So we've been working on the Redux Toolkit 2.0 Alphas, and we're currently on 2.0 Alpha five. The RTK 2.0 is working on improving our ESM common JS package formatting, modernizing the JavaScript output and. We're moving a few bits of deprecated options and APIs and generally trying to make things faster. [43:40]
-
-we've also got a couple new features in there, so they're tagged as Alpha because we're still working on changing a bunch things, but the code that's in there is stable and we'd really encourage folks to try out the Alphas and give us feedback like, does this work in your app? Does it accidentally break anything? [43:56]
-
-The current Alphas have Emerton final in there, so you get some of the speed benefits that I was talking about earlier, and then something that I hope will end up as part of RTK 2.0. Final. I've been experimenting with a couple new memorization options for the Reselect library. One of them is very inspired by what the Ember folks have done with auto tracking field accesses. [44:21]
-
-So the idea is that. It knows exactly what fields you're accessing and only recalculates the select results if those fields got changed and not other fields. There's also another one that I was playing around with that is basically a direct copy paste from a React internal cash implementation that uses weak maps to track arguments. [44:42]
-
-Right now none of that is released. I have a PR up over in the reselect repo that has like the initial, like "I've been hacking on this and it sort of seems to work" graphs, so I'm hoping to go back and work on that further. Assuming those work out, they will either go into Reselect 4.2 or Reselect 5.0 depending on what I feel like. [45:04]
-
-And then one way or another that the new version of Reselect would get included in RTK 2.0. So trying to find ways to make things better. [45:13]
-
-## ⚡️ Netlify framework popularity
-
-- [⚡️ Netlify framework popularity](https://www.netlify.com/blog/framework-popularity-on-netlify/)
-
-**Carl Vitullo:** Cool. Heck yeah. Yeah. well I saw the framework popularity on Netflix, or Netlify blog post. Definitely pretty interesting data to look at. They broke it down by free sites, paid sites, and enterprise sites. Just a couple of notable, I'll, I'll call out, Create React App Next, and Gatsby, I think those were, Some of the interesting results. [45:34]
-
-So free sites, 40% of them were using Create React App that goes down to 23% if you just go by paid sites and all the way down to 18 if you're looking at Enterprise. So yeah, Next, and Gatsby were 2 and 3. Those are pretty reliably the top three, and Next only gets more popular as you go up in price scheme. [45:56]
-
-Yeah, I thought it was a pretty interesting bit of data to look at. Definitely impressive to see how well Next is doing. Although, you know, one thing I was surprised to see missing here was Remix, but I guess they don't really support so much of a static export, and that's kind of Netlify's bread and butter. [46:14]
-
-**Sebastien Lorber:** There is a Remix adaptor for Netlify, I think, but, yeah, it's always complicated to, to market another platform, then, when it's not maybe the first class to support and, [46:27]
-
-**Carl Vitullo:** Yeah, sure. [46:28]
-
-**Sebastien Lorber:** Although was happy to, to find out that, Docusaurus, has a 4%, share in the enterprise site. So this is, there are more Docusaurus sites on Netlify than, Remix sites on, on Netlify. [46:43]
-
-**Carl Vitullo:** Oh, funny. [46:44]
-
-**Mark Erikson:** I think the other interesting takeaway there is the popularity of Create React App in, in those categories, which, you know, kind of goes to the difference between like the, the chatter on Twitter and, you know, all the, the emphasis from the React team we've seen versus, well, okay, here's how stuff is actually being used in the real world at the moment. [47:02]
-
-**Carl Vitullo:** Right. Hobbyists versus professional maybe. [47:06]
-
-Yeah. Cool. mark, anything else you wanna call out? [47:09]
-
-## ⚡️ PartyKit
-
-- [⚡️ PartyKit](https://github.com/partykit/partykit)
-
-**Mark Erikson:** One other little item. So Sunil Pai, who's a former member of the React Team and has been revolved in the re in the React ecosystem for many years, has been doing a startup called Party Kit where he's building infrastructure for real-time multi-player applications. You know, the, the kind of thing where you see like 30 different people interacting with the same whiteboard simultaneously, and he just open sourced the party kit repo at React Miami. [47:39]
-
-I know it's a thing he was very, very excited about and I haven't had, again, haven't had a chance to play with it, but it looks really cool. [47:48]
-
-**Carl Vitullo:** Yeah, agreed on all counts. I haven't played with it yet, but I've been following development because Sunil Pai is just such a, such a great person. I really enjoy… we, we had him on for an event, talking about rewrites, and he's just such a, thoughtful and kind person. I, you know, I'm gonna be rooting for him, in anything he does. Ha. [48:07]
-
-**Sebastien Lorber:** Yeah (chuckles). [48:09]
-
-**Carl Vitullo:** Cool. Okay, everyone, thank you so much for joining us for this April edition of This Month In React. I hope, I hope you learned something. I hope that you felt like we're helping you stay on top of the React ecosystem. There's always a lot going on, so hopefully we can bring some clarity. [48:22]
-
-Mark and Sebastian, thank you so much for talking with us. [48:25]
-
-**Mark Erikson:** Yep. Always. [48:26]
-
-**Sebastien Lorber:** Thank you, and see you next, next month. [48:28]
-
-**Carl Vitullo:** Yeah, see you next month. Awesome. Thanks so much. see you guys later. [48:33]
-
-**Sebastien Lorber:** Bye.
diff --git a/src/transcripts/tmir-august-2023.md b/src/transcripts/tmir-august-2023.md
deleted file mode 100644
index b20628c..0000000
--- a/src/transcripts/tmir-august-2023.md
+++ /dev/null
@@ -1,423 +0,0 @@
----
-title: This Month in React (August 2023)
-date: 2023-08-30
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-Concurrent Mode, Remix DevTools, included SourceMaps, new Expo features
-
-- [Spotify](https://open.spotify.com/episode/2ScNpUkv8QRYXaniMnfpWT?si=yF2SwwsRTGmvAFcl_Wsq_w)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/this-month-in-react-august-2023/id1661733526?i=1000626488343)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [Or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux/episodes/This-Month-in-React--August-2023-e28qasn/a-aaaa1f1)
-
-
-
-- Gatsby's growth and development seems to be stagnating as Jamstack has fallen out of favor compared to Next.js.
-- React's stubborn incompatibility with Web Components is frustrating but may be more of an indictment of Web Components' limitations.
-- CSS-in-JS causes fragmentation across environments like client vs server rendering, so the React ecosystem is moving away from it. Differences in tradeoffs between browser and mobile environments make it a difficult problem.
-- New devtools have been released for React Server Components and Remix that help inspect behavior on client and server. Good devtools are a huge force multiplier.
-- Publishing libraries with proper ESModules support is still very challenging and undocumented. Deno may help smooth the process.
-- React production builds now have sourcemaps thanks to impressive work by Mark Erikson! This will massively help debugging libraries like React in production.
-- Official React + TypeScript documentation has finally landed. Orta did a great job with it.
-- Try out new versions of Redux Toolkit and React-Redux in beta. Provide feedback!
-- Expo had a big release week with improvements to builds, updates, SQLite, CLI plugins, and more as React Native marches forward.
-
-Links used:
-
-- [Is Gatsby Dead?](https://twitter.com/sebastienlorber/status/1694392101281190224)
-- [https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/](https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/)
-- [https://www.spicyweb.dev/farewell-jamstack/](https://www.spicyweb.dev/farewell-jamstack/)
-- [Things you forgot (or never knew) because of React](https://joshcollinsworth.com/blog/antiquated-react)
-- RSC Devtools
- - [RSC Devtools - Chrome Extension](https://chrome.google.com/webstore/detail/rsc-devtools/jcejahepddjnppkhomnidalpnnnemomn)
- - [Devtools for React Server Components](https://www.alvar.dev/blog/creating-devtools-for-react-server-components)
-- [My Experience Modernizing Packages to ESM](https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/)
-- [Remix Dev Tools v2.0 - New settings tab](https://github.com/Code-Forge-Net/Remix-Dev-Tools/releases/tag/v2.0.0)
-- [Everything I wish I knew before moving 50,000 lines of code to React Server](https://www.mux.com/blog/what-are-react-server-components)
-- Expo
- - [Expo Preview - Fully customizable builds on EAS Build](https://expo.dev/changelog/2023/08-10-custom-builds)
- - [Expo Proof of concept - expo-sqlite integration with CR-SQLite](https://expo.dev/changelog/2023/08-10-cr-sqlite)
- - [Expo Proof of concept - Expo CLI Dev Tools Plugins](https://expo.dev/changelog/2023/08-10-dev-tools-plugins)
-- [Feature Preview: Single Sign-On (SSO)](https://blog.expo.dev/feature-preview-single-sign-on-sso-9c1a7d50c1a9)
-- [Feature Preview: Rollouts for EAS Update](https://blog.expo.dev/feature-preview-rollouts-for-eas-update-4eac28596470)
-- [useUpdates() API for expo-updates](https://expo.dev/changelog/2023/08-08-use-updates-api)
-- [Expo Orbit: Download and launch builds](https://expo.dev/changelog/2023/08-09-orbit)[Components](https://www.mux.com/blog/what-are-react-server-components)
-- ⚡Lightning⚡
- - [React prod sourcemaps](https://github.com/markerikson/react-prod-sourcemaps)
- - [PR to React](https://github.com/facebook/react/pull/26446)
- - [React.dev - Using TypeScript](https://react.dev/learn/typescript)
- - [RTK 2.0 beta](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-beta.0), and [React-Redux 9.0 alpha](https://github.com/reduxjs/react-redux/releases/tag/v9.0.0-alpha.0)
- - [The underlying mechanisms of React’s concurrent mode](https://andreigatej.dev/blog/the-underlying-mechanisms-of-reacts-concurrent-mode/)
- - [React Jam - Summer 2023 Winners](https://reactjam.com/summer-2023-winners)
-
-[00:00] **Carl Vitullo:** Hello, everyone. Thank you for joining us again for This Month in React, where we digest and discuss the latest developments in the ever evolving React and web ecosystem. Right now I've got myself the community manager of sorts for Reactiflux, and Mark Erikson. Mark, you want to introduce yourself?
-
-[00:20] **Mark Erikson:** My day job is working at Replay.io where we're building a true time traveling debugger for JavaScript. If you haven't seen it, please check it out. And in my copious amounts of free time, I work on various Redux related projects.
-
-[00:33] **Carl Vitullo:** Various projects. Yeah, that's almost understating it. Cool. Yeah, uh, we usually have Sebastian Lorber as well, but um, He's not here yet. So let's go ahead and jump in I guess.
-
-[00:44] My first link that I wanted to discuss is, Is Gatsby Dead, uh, which here is a tweet from Sebastian with a screenshot, uh of mid August, Fred Schott. " Notice that there have been zero commits to the Gatsby repo in the last 24 days." Which, for a thriving open source project, that's not a great statistic.
-
-[01:07] I know it was acquired by Netlify earlier this year, this year. Um, and yeah, there's been a lot of discussion around Gatsby as a project, I guess, and where it's headed. yeah, I don't know, Mark, any, any, any thoughts on Gatsby's status?
-
-[01:26] **Mark Erikson:** So my first caveat was I never had a chance to use it myself, but just kind of eyeballing bits and pieces, it certainly felt like next has been eating into Gatsby's, uh, market share and mind share over the last year or two, um, both due to complexities around trying to manage.
-
-[01:45] Build times and graph QL setups and whatnot with Gatsby as well as, you know, sort of the evolving ecosystem consensus that next is sort of the default way to build React apps for better or for worse. And so I'd certainly gotten the vague sense that Gatsby has been sort of kind of falling out of favor over time.
-
-[02:08] And I don't know, like, anytime I see any product get acquired by a bigger company, you just have that sense that, well, it was nice knowing you, uh, like, sooner or later it's dead. And especially when that involves, you know, companies with. VC backing and it feels like Netlify itself has been struggling a bit and on the downswing.
-
-[02:32] And so the fact that they bought Gatsby and then don't seem to be doing much with it certainly suggests to me that it's, it's basically dead at this point.
-
-[02:42] **Carl Vitullo:** And dead is always, you know, what, what does dead mean is always, uh, an open question, you know, because Gatsby still works. It's an open source, you know, self hosted product for the most part, or project, I guess, for the most part.
-
-[02:55] So yeah, I have used Gatsby on a couple of relatively large projects. I used it for my personal website. I used it for a marketing website at a previous company, which actually it ended up getting replaced by Webflow. and I, used it again on a large documentation site, which again has now been replaced by Docusaurus.
-
-[03:15] So I think that's, I think that that's kind of the the pattern I've observed is, you know, maybe four years ago, there was a lot of energy around using Gatsby, and there's a lot of excitement for it. But at least, you know, my experience was I tried to use it for some relatively large projects and stakeholders weren't super into it.
-
-[03:34] The marketing and content folk didn't really jive with the experience of authoring content. The deployment story was a little bit hairy, uh, just ended up with a lot of funky little breakages every now and again, that were a little bit tricky to debug though. I don't know.
-
-[03:52] Yeah, I, I echo your sentiments on being a VC backed company, acquire an open source project. There's always a bit of a squinty eyed skepticism. Like, where's this going?
-
-[04:04] **Mark Erikson:** Well, I mean, on top of that, they're, they're both VC backed projects. I mean, Netlify itself, even though we can probably think of it as being a relatively stable company has a whole bunch of VC backing. And Gatsby is an actual company with VC backing different sizes.
-
-[04:21] **Carl Vitullo:** You know, I, I did see that there, you know, the official Gatsby account did reply to that tweet thread we're discussing and they said, "fear not Gatsby is vital to many, to a great many of our customers updates to React 18 and Gatsby adapters are the most imminent updates, but we're also busy investing in platform primitives for a stronger Gatsby JS and other frameworks too," I don't know, they're saying it's not dead, but I, I would agree with you on the, you know, sort of the vibes I've been picking up with.
-
-[04:47] Netlify invested really hard in Jamstack and the client, you know, client side applications. And those have kind of gone out of vogue a little bit, but yeah, I guess we'll have to see what happens. I did actually connect with some Gatsby folks after Reactathon a couple of weeks ago, maybe eight weeks ago, um, about maybe doing some community work with them and they said, what I heard back was decisions are being made and we'll see what, what happens there.
-
-[05:14] So, I don't know, have to see, have to see how it shakes out, but not looking super great for Gatsby as a, the growth trajectory of Gatsby is not looking super great to me.
-
-[05:24] **Mark Erikson:** So, so you mentioned Jamstack, and I actually, I know I saw a couple articles, and I'm trying to bring up some links at the moment, uh, that very recently were talking about how the term Jamstack feels like it's either, it's also either dead, or at least has just sort of become so vague and nebulous it doesn't have a specific meaning.
-
-[05:48] Again, this is not my area of expertise, but seeing that discussion and knowing how much Netlify had tried to orient themselves around the term JAMstack, and as well as Gatsby, also suggests that the ecosystem has shifted enough that it You know, kind of points away from Gatsby as a Gatsby still usable.
-
-[06:12] Obviously, it's just not where the mindset is at this point.
-
-[06:15] **Carl Vitullo:** Definitely. It feels like the zeitgeist of Web and React has expanded beyond what Gatsby offers. Well, and what Jamstack was oriented around. Definitely.
-
-[06:27] Cool. Uh, you want to take us on our next link?
-
-## [06:30] Things You Forgot or Never Knew Because of React
-
-[06:30] **Mark Erikson:** So there's been a whole sub genre of blog articles over the last few years with people going off on rants about act is an awful library.
-
-[06:42] The people behind React are trying to sell you something that is, that is misleading. " React is horrible for web performance." And these articles are usually fairly well written. I don't generally agree with them, but it is a useful set of counterpoints to, you know, kind of our own little bubble that we have.
-
-[07:04] Alex Russell, uh, formerly of Google, now Microsoft, has written a number of articles along those lines. Um, a lot of folks who are very involved in the web components community have written articles along those lines. And so there was another article of that type that came out a few weeks ago called Things You Forgot or Never Knew Because of React.
-
-[07:26] And it's, it's a long article, um, I, I won't try to cover all the points that it makes, but it's, it's worth reading at a minimum to get kind of like an alternate perspective. On how does React fit in with the rest of the web development ecosystem? What are pain points that other people see looking at react?
-
-[07:47] Um, what are some of the lessons that we in the React develop the developer community have internalized that maybe are worth a rethought? And include some things like, um, "hooks as excited as we all were when they came out. Well, now we've now there are things like, and observables and other ways of managing data flow.
-
-[08:09] The end. So the post argues that, you know, they're faster and easier to work with. Actually, yeah, okay, this, this is a good, good one. There's a bullet point that says "nobody else is afraid of their frameworks version of useEffect." Okay, that, that's, that's probably the one point in this article I agree with the most.
-
-[08:26] You know, it argues that, you know, two way data binding, which is something that we, we in the React community have always argued against because control components, even though similar, are somehow better. It argues that two way data binding is not a thing that you should be afraid of, and, you know, goes on and lists a whole bunch of other different competing frameworks and suggests that you should look at them - affect my own personal view of React, but it's always good to kind of get that, you know, that alternate viewpoint of what are some of the strengths and weaknesses of tools and make considerations from there.
-
-[09:00] **Carl Vitullo:** I think, I think what you said about, you know, people shouldn't be afraid of two way binding. That doesn't really jive with my personal experience of using two way binding, which is that it was scary. It was difficult to debug. I didn't find it a pleasant, you know, experience for authoring code. So, I don't know, somebody else telling me, "oh, don't be afraid of it, it's fine."
-
-[09:19] It's like, well, I'm afraid of it because it was, Very painful for me in the times when I used it professionally for, you know, two years before I used React. Um, so, that did not resonate with me very strongly.
-
-[09:34] **Mark Erikson:** I'd have to go back and re read that section of the post, but I do sort of feel like programming paradigms come and go and come again and go again.
-
-[09:45] Everything's in a circle and nothing's new. But I do, I feel like there is a little bit of a sense of people forgetting why shifts in paradigms were made in the first place, you know, people getting into React today don't actually know what it was like to use Backbon or Angular 1. And so they don't understand the pain points and why React was such a big deal and so exciting when it first came out because they didn't.
-
-[10:15] Feel that pain. Now it's just, we've always had React. It's always quote unquote, "been the default", and yeah, like back that, for example, an Angular one template could mutate arbitrary data, you know, deeply nested from within a JS nested in an HTML template string, that was really hard to debug and keep track of.
-
-[10:38] And so I think, I think that's where a lot of the concern about two way data binding actually came from in the first place and we all sort of internalized and repeated this phrase and now no one remembers why we did, why did we have that concern to start with?
-
-[10:53] **Carl Vitullo:** Yeah, I, I definitely agree with that. If that reminds me of a, a line from the post where they talked about React being tech from 2013 designed for 2008 constraints, which I don't a hundred percent agree with.
-
-[11:07] But I do think it's, it's not, you know, wildly off base. I think it's, you know, there were, there were a lot of things that React was developed around that were trying to patch over issues with the platform, you know, compatibility and whatever. But, um, Yeah, I don't think that's quite accurate. I pulled out a couple of quotes that were thought provoking for me.
-
-[11:30] One of the lines was, um, "React has trained us that packages need to be built specifically for our framework," which I think I don't know if that's on React. I think that is just kind of the general trend for people. You know, if you're I'm using X framework, I would like to get something that is tailor made for my situation.
-
-[11:50] And so I'm going to look for an SDK that was built for this tool in this setting. And I do agree with the idea that it's not good to require that all the tools we use be built, you know, to be specifically cross compatible with each other. You know, it's fine to use a general purpose library in React. It doesn't need to be hooks specific.
-
-[12:13] So, yeah, I thought that was at least a decent point.
-
-[12:16] **Mark Erikson:** Have we forgotten how many jQuery plugin adapters there were?
-
-[12:20] **Carl Vitullo:** Right. There were some, yeah, right. So I, you know, I don't think that is a React problem. I think that it has been very visible in React because React, you know, as this post says is, it's the default.
-
-[12:34] Lots of people use it. And so when lots of people use it, then all of the problems that happen when any large group of people do something become very, you know, that becomes the problems of that framework that in that context. So.
-
-[12:47] **Mark Erikson:** there, there's an XKCD out there. Uh, Ooh, I think I found it. The cartoonist points out that when you're, like, when your map basically resembles a map of the population, it's not actually telling you anything useful. And so I think there is just a little bit of that with the React community, because React is so big, you sort of have a natural full distribution of...
-
-[13:12] People and situations and problems. So to be clear, like I'm, I'm not, I'm not saying that, you know, this, this original, you know, what's wrong with React article is wrong. I think it actually makes a lot of very, very good points. There, there is a little bit of a sense in which some, and some of the complaints are simply because there are so many people using React in so many ways.
-
-[13:33] **Carl Vitullo:** Right. You know, people have a lot of problems with React because there are so many people using React and they've really felt out every every possible base and edge case where you can't hit problems. Um, there are a couple of the quotes that I wanted to highlight. I think, uh, "no other modern front end framework as a stubbornly incompatible with the platform as React."
-
-[13:54] I, you know, I don't know if I disagree with that specifically, but I also think it's a little bit. It ignores the fact that no other framework attempts to be as broadly cross compatible as React. Like, you know, there's not Angular Native, there's not Vue Native. So it's, a recurring criticism of React has been incompatibility with, uh, Web Components.
-
-[14:14] And, you know, okay, sure, it's not very compatible with Web Components, but... You could argue that that's kind of a web component problem, because if React is, has successfully solved, you know, has been found to be a valuable tool for web, native, you know, mobile, desktop native, you know, all of these different contexts, like maybe it's inability to use web components is more of an indictment of web components ability to solve a problem.
-
-[14:41] **Mark Erikson:** yeah, the, the whole React and web components thing is its own very complicated topic from the off the top of my head. My general understanding is number 1, you can render web component tags from a React component, but you lose some of the, some of the back and forth and being able to pass in props correctly.
-
-[15:00] Some of that is because there's some kind of a difference between properties and attributes in web components and you can't just pass in plain objects as props the way you would from one React component to another. The React team had not prioritized trying to implement better compatibility because they had a lot of other things they were worrying about.
-
-[15:24] They kind of asked for some directions from the community. To say, look, there's like four different ways we could try to handle this, you know, handle passing the data back and forth, which one do Web Components experts think is the right option? And there were arguments back and forth for years without the web component community actually settling on a consensus for the best way to pass stuff in.
-
-[15:50] And so where things stand now, as far as I know, is someone actually has implemented quote unquote "proper compatibility" for web components in React. It's in a branch. It's either, it's either not merged or it's merged behind a feature flag and they intend to release it officially whenever React 19 comes out or like it's enough of a shift, they don't want to do it in a minor version.
-
-[16:19] So the work has been done. React's versioning strategy is totally messed up at the moment.
-
-[16:24] **Carl Vitullo:** (Chuckles) Sure. Right.
-
-[16:26] **Mark Erikson:** So it's it's multiple factors. It's React knows how to compose and web components don't. There were questions about how React should compose with web components and people and. People who cared about that stuff couldn't agree on the right way to do it and then work has been done.
-
-[16:43] React hasn't been released because focused on server side stuff and not actually shipping major versions right now.
-
-[16:52] **Carl Vitullo:** Yeah, right. They've been just maybe not top priority for them right now, which, um, yeah, I, I want to, I want to run through a couple of other quotes here that I thought were good to. I don't know, rebut, discuss.
-
-[17:04] "The worry that a front end framework might not scale is as old as jQuery and should be considered just as antiquated in relation to modern web development." That's talking about, I think, both performance and maintainability in terms of scaling. And, ooh, I do not agree with that. I don't agree that it is an antiquated idea.
-
-[17:22] Definitely there are patterns that do or do not scale very well. Um, and I think React tends to be better than average at that. Um, so like with regards to code isolation and refactorability, you know, you can certainly build things that are difficult to maintain and difficult to swap out.
-
-[17:41] But I do think React does a decent, in my opinion, better than average job of that compared to other modern frameworks. So, I don't know, just hand waving away like, "you don't need to think about scaling anymore." I don't agree with that. Sorry, buddy.
-
-[17:54] And another one. "Styling is a solved problem in several other frameworks." I'm grimacing here for those who don't are watching the camera. Um, I don't agree with that. I think, you know, okay, yes, we there has been a lot of churn on styling as something you need to do in the React world. You know, CSS in JS. Plain CSS, less or sass, okay, sure, I think now we've moved away from CSS in JS as a good idea because it has, you know, I think, I feel like the zeitgeist has moved towards, there are too many trade offs, too many negative trade offs on doing CSS in JS.
-
-[18:30] But to call it a solved problem, ooh, no, I don't, I disagree with that. Cool. Any other thoughts you want to add there?
-
-[18:36] **Mark Erikson:** Not immediately.
-
-[18:38] **Carl Vitullo:** I'll, I'll take us on to our next link. Oh, yeah. Orta here in the comments, CSS in JS is good for other platforms. That's extremely true. It is, you know, if, if your platform doesn't support CSS, then you got to find something else for it.
-
-[18:50] So that's why it's not a solved problem. I don't, yeah. (Laughs) But yeah, moving on here.
-
-## [18:57] React Server Components DevTools
-
-[18:57] **Carl Vitullo:** Uh, somebody has published a dev tools for React server components extension. I'm pretty, I think this is pretty cool. This is... maybe a first effort. This is looking, you know, I look at the, uh, the user interface of it and it looks like it breaks down... it looks like it's largely a reverse engineering of the data being streamed in, uh, sort of converting the JSON markup into pseudo HTML so that you can review it as a human a little more easily. And as well as, they call it time travel, but I think it's just kind of a log of data being sent. Looks super useful, looks a lot better than crawling the network tab to me.
-
-[19:36] **Mark Erikson:** I am always interested in newer or better developer tools. I think the fact that the React dev tools exist was one of the huge reasons to even consider picking React early on and been done on them over the years is incredible. So it's actually a little surprising to me that the React team itself hadn't prioritized trying to build tool some some form of dev tools integration for server components and that it took someone from the community trying to give it a shot.
-
-[20:10] I've said it, I've said it a number of times before, I know the React team had, like, despite all the corporate backing, has a limited number of people and a limited amount of engineering effort, but I really, really would have expected them to have put some serious planning and effort to building out DevTools support for server components.
-
-[20:28] For that matter, I know that Facebook has not been putting a lot of engineering hours into improving the existing DevTools lately. I think they had a couple engineers, Brian Vaughn, who used to do a lot of that work, left a year and a half ago and now works with me at Replay. There were one or two people working on the React DevTools code.
-
-[20:51] In the React repository, one of those people was laid off recently and so that like, I've seen a couple maintenance level PRS, but I don't think a lot of effort is going into improving the reactive tools right now. And, you know, the good news is like the, the reactive tools are there and they work, but I know Brian had a lot of ideas for improving them down the road and who knows if, or when those will happen.
-
-[21:17] So I'm actually genuinely not sure if or when we'll get official React server components integration into the React DevTools.
-
-[21:26] **Carl Vitullo:** Sure, yeah, that makes sense. Yeah, as someone who works on DevTools professionally, do you know if, I know Replay is a general purpose DevTool more on the browser than on any specific framework, but do you know if there's any interest in, I don't know, tapping into some of these internals like that on the Replay side?
-
-[21:45] **Mark Erikson:** We would love to. Um, you know, semi sales pitch time for the moment. Um, so, as I said earlier, Replay is a time traveling debugger for JavaScript. We we have you record yourself using your website with our modified Firefox or chrome for a couple of minutes, and then you can debug the recording and it's like a DVR, like, You can jump anywhere in time within that recording, see every line of code that executed, and it really simplifies, trying to dig into what happened and understand bugs.
-
-[22:19] So, right now, we have Replay integration with the React DevTools. Um, besides just like you can record any website written with anything, like it just records the JavaScript that ran. But if the site that you're recording was built with React, we can capture all the React related data. And I've actually built a lot of this integration myself.
-
-[22:44] So we can show the React component tree and in the React DevTools UI at any point in time. And we've done that because number one, we use React ourselves. Replay is a React app, two, React is the biggest framework. So it makes sense to build features for, you know, the largest target audience. We would like to build more integrations with more frameworks over time, like view angular, well, solid, you know, maybe something special for Apollo and GraphQL.
-
-[23:19] we, we would love to build these things. We, we just, we're a very small team right now and we have limited engineering time and way too many things to do, but longterm, we would love to have integrations for all the major frameworks out there so that if you make a Replay recording of a website built with one of those frameworks, you'll get.
-
-[23:38] You know, extra special visibility into what happened for sure.
-
-[23:42] **Carl Vitullo:** Yeah. I mean, developer tools, developer experience. That's a huge force multiplier. All right. You want to take us on our next link?
-
-## [23:49] My (Mark's) Experience Modernizing Packages to ESM
-
-[23:49] **Mark Erikson:** Yes. So, uh, continuing the self plug here, earlier this month, I wrote a very long blog post entitled my experience, modernizing packages to ESM.
-
-[24:01] This was kind of the story of all the shenanigans I've had to go through this year, trying to update the Redux related packages to have proper ES module compatibility, whatever the heck that means. And I'll be honest, like, it has been an extremely painful and frustrating effort and year trying to do that.
-
-[24:23] And I've learned a lot. There's a lot of things I wish I hadn't had to learn. And I'm still not done. I am still messing with this stuff, even within the last week, I was trying to work on these things. And normally when I write these blog posts, I try to write them to say, Here's all the stuff I've learned, and here are the correct answers that I've learned.
-
-[24:44] And in this case... It's more of a, here's all the places I've banged my head against the wall, trying to figure things out. I still don't know the correct answers, but at least describing the stuff that I've gone through will hopefully benefit other people who are trying to deal with the same things.
-
-[25:03] When I, when I write blog posts. I usually have a decent sense of how popular they might get, you know, I'm not trying to optimize for page views, but you know, like my posts on React rendering or Redux versus context. Okay, like, it's very obvious people are going to have a, an interest in those. I really did not expect a lot of people to be interested in a post about how to publish libraries correctly, but it's actually gotten a fair amount of attention.
-
-[25:29] And there's been a lot of other folks who are, you know, building libraries who have, you know, replied or messaged or talked to me and said, "Oh, yeah, like, I'm running into the exact same problems myself", or "I totally sympathize and understand with all the different pain points you've gone through."
-
-[25:46] So, you know, there are a bunch of different factors, um, trying to define the package export setup is really hard. Trying to figure out what file formats and whether you do you pre bundle your JavaScript, do you pre bundle your TypeScript types? What about file extensions? Um, but then another complicating factor has been React server components. You know, it turns out that you can't do things like even, you know, importing and using React hooks in a server components environment.
-
-[26:16] Which makes it really hard for libraries like Apollo and RTK Query that can be mixed mode. Like they have a plain JavaScript aspect, but they also have a React Hooks aspect. And normally you would be able to use that on both sides. But now, you know, Next is throwing errors automatically if you even try to import. React hooks, it's doing static analysis.
-
-[26:44] And so for us as library maintainers, trying to figure out like, how do we ship packages that are going to work without just exploding yet another environment has been really, really hard.
-
-[26:58] **Carl Vitullo:** Yeah, I don't have a lot to add there as someone who doesn't maintain any major libraries, but yeah, my, my, my outsider perspective has been that it was already quite difficult to support, you know, ES modules versus CommonJS versus, you know, like, I don't know if Bower is still something that needs to be actively supported.
-
-[27:20] **Mark Erikson:** One of the questions I had was, you know, should I still be shipping UMD modules to support like the, the script tag in a Codepen use case? And I, you know, I, I finally settled on, eh, probably not, but let's ship an additional ES module file that has been pre compiled to production usage. You could do a script tag type equals module and use it as an ESM module in the browser.
-
-[27:49] **Carl Vitullo:** Oh, sure. Oh, yeah. Interesting. I guess that was one use case that ES modules has been meant to replace. So, okay. Interesting that that has maybe come to fruition now. Interesting. Pulling a comment from chat. "I still ship UMD more often than ESM for my own use cases. It's a big learning curve." Definitely big learning curve is definitely maybe an understatement.
-
-[28:12] **Mark Erikson:** Yeah, one of my biggest complaints is that there is no single authoritative comprehensive guide to how to correctly publish a library with all the tools and settings and correct file formats and stuff that you should include. So everyone's just sort of figuring this out for themselves and borrowing from everyone else.
-
-[28:30] **Carl Vitullo:** Yeah, actually, even, you know, you're saying there's no comprehensive guide on how to do it. There's not, I don't even think there's a comprehensive guide on what environments are out there, you know? Like, what do you even need to think about supporting? Yeah, that's interesting.
-
-[28:43] **Mark Erikson:** I mean, that was, that was part of the point of my post.
-
-[28:48] Was, like, literally, like, here's all the stuff that I'm having to consider.
-
-[28:52] **Carl Vitullo:** Yeah, Orta with the good chat comments here. "Most recent strategy has been use Deno." I've, that is not the first time I've heard use Deno as a good strategy for publishing a library. I've heard that it has made local development, or rather it's made the transition from local development to usable package published to the, uh, to the npm just easier to do.
-
-[29:16] Um, and it's not something I've tried, but yeah, that's been an interesting thought that's been lodged in the back of my brain just using a different environment that makes it easier to do the right thing, even in other environments. That's interesting.
-
-## [29:31] Remix DevTools
-
-[29:31] **Carl Vitullo:** Well, I'll, I'll move us on here. I think, yeah, one more dev tools update the.
-
-[29:37] Remix DevTools has a new release this month, uh, 2. 0. Um, I, I have not used this yet, uh, but I do, I, I have a couple of Remix projects, Remix based projects. So, um, I'll have to poke around here and see what kind of stuff it adds.
-
-[29:54] Looks like it gives you better inspectability of like your routes and your pages. Um, so yeah, the. I think debugging got more complicated with the, you know, server client, I don't know, seem in between there. So the value of platforms or the value of framework specific developer tools has gone up a lot more with that. You know, how do you have something that's aware of the server as well as the client and can tell you more information about what all is going on there?
-
-[30:24] So yeah, remix developer tools 2. 0 something to check out.
-
-[30:28] **Mark Erikson:** Yeah, Jessica Sac hs actually recently sent me a link to a demo video for the, the, the Nuxt framework and like it, you know, it's a Vue based equivalent to Next, roughly, and it apparently has some kind of a dev tools plug in that looks pretty similar to what I'm seeing in the, you know, the, the gift demos for this, this remix one, you know, listing all the routes and the options.
-
-[30:54] So that, yeah, that looks extremely useful.
-
-[30:56] **Carl Vitullo:** Yeah. Even just surfacing how it's being all parsed out. You know, now that. I both remix the next, add that layer of file and folder names having influence on the behavior of the code you write in them. Uh, it's just, it's, it's reasonably indirect and it's a little, it, I have found it confusing at times, you know, if you have to debug, like, why isn't this route showing up?
-
-[31:19] Like, the only way to do so is futzing around with the file names, which. It's not great. It's not great inspectability. So better developer tools, at least saying this is how the framework is understanding what you've given it. That seems like a big help. Uh, cool.
-
-[31:35] **Mark Erikson:** Uh, so there was a really good post actually technically back in July, but I think got listed more recently called everything I wish I knew before moving 50, 000 lines of code to React server components.
-
-[31:45] It had a really nice, some really nice diagrams of, you know, kind of like the shift from client server behavior to React server component behavior, how server components, you know, actually kind of manage the tree, a lot of different code snippets, and information on, like, how would you actually start using server components in a code base.
-
-[32:06] You know, one of my, one of my biggest complaints about the server components rollout has been that, you know, there, there isn't a migration story, there isn't really good advice on how to start adopting these. And frankly, this is about the best information I've seen on, on that topic. So I, I thought this was an excellent, excellent post. Uh, it also had a link to a talk from the Reactathon conference that was done a couple of months ago, which discusses, when should you even consider using server components?
-
-[32:36] And that, that talk from Jeff Escalante was actually just a little, just a little on the intentionally skeptical side. Like it points out that server components are very useful for some kinds of apps. But not so much for others. And so it's not, you know, server components are not a silver bullet that you should just slap on everything, but instead actually kind of consider if it makes sense for your use case. So this was a very, very helpful resource, I think.
-
-[33:05] **Carl Vitullo:** I haven't read this in depth, it's very long. I think they said it was like 5500 words. It's rivaling one of your posts, Mark ( Mark laughs), but it, you know, just scanning through it, it reminds me of some of the resources on, you know, architecture and sort of summarizing behavior, and like the perspective that went into designing server components.
-
-[33:25] It reminds me of some of the write ups on, uh, or that like the next JS team has put up about that. Um, but I think a lot of those have been more from the maintainer side of things of like, here's why we did it, here's why we made this the way it is. It is. And this seems much more anchored from a pragmatic point of view of like, we don't care about how it works specifically, but here's how we used it, and here's the pitfalls we found.
-
-[33:52] Uh, so yeah, definitely agreed that this looks like a really phenomenal resource. Uh, and referencing something we talked about earlier, uh, one of the headers is CSS in JS is a non starter. Uh, so yeah, CSS in JS doesn't work in server components. So One reason why the React ecosystem has been moving away from that.
-
-[34:14] But yeah, I mean, if CSS in JS is the only way to get native styles working. Oops, there's a tension, can only use it, can only use CSS in JS in native environments and cannot use it at all in server environments. So that was like fragmentation to me.
-
-[34:32] **Mark Erikson:** A lot of that.
-
-[34:32] **Carl Vitullo:** Yeah, not ideal, but yeah, definitely a great read.
-
-[34:35] Definitely a great resource for anyone looking at how to get server components involved in their app, especially if it's not a greenfield project, and it's trying to bring it in as an optimization to bring it in as an improvement to an existing application.
-
-## [34:50] Expo Release Week
-
-[34:50] **Carl Vitullo:** All right, I guess, uh, let me move us on to our next link.
-
-[34:53] Yeah, I don't have one single link here, but Expo did a release week shipping a whole bunch of new features. Um, let me, I've got like eight links here and I don't know how to quickly dump them all, but there's Expo preview, a fully customizable builds on EAS build.
-
-[35:12] Um, I'm not really familiar enough with Expo. I haven't used it on a, you know, a production app, so I can't speak too much to all of these different acronyms and features, but fully customizable builds, I could certainly imagine situations where you might need to have finer grain control over how your application gets built. So that seems valuable.
-
-[35:33] There's a proof of concept for Expo CLI DevTools plugins. So continuing with the DevTools theme, feature preview of single sign on, feature preview of EAS update. So I guess that's the build for, you know, a fresh version of an app versus releasing an update to an existing app. Use updates API for Expo updates, which I it sounds related to that, updating.
-
-[36:00] There was an interesting one that caught my eye was Expo SQLite integration. They They reference convergent replicated sqlite, which is, that's really interesting. So it talks about having multiple different sqlite databases that have independent writes and then get merged together. And they had a little demo video showing multiple to do apps that are being kept in sync.
-
-[36:28] Um, I, I have a soft spot in my heart for SQLite, um, and a soft spot in my heart for CRDTs, um, which I'm blanking on the, what that stands for, but replicated data types. Um, conflict free data types. Conflict free replicated data types. That's it. Uh, yeah. So I have a soft spot in my heart for those, local first, merged data kinds of tools.
-
-[36:57] So it's interesting to, it'll be interesting. I think that could be a large unlock for people building mobile apps.
-
-[37:05] **Mark Erikson:** Yeah. I mean, just, just skimming down the list. It looks like they're putting a lot of effort into the, the build and deploy story for X for Expo apps.
-
-[37:13] **Carl Vitullo:** Yeah. And I know that there's been, you know, over the years, there's been some various churn on the React Native story for updates or for builds and updates, I guess, you know, for a long time, one of the advantages of React Native was you could update the JavaScript and change the behavior of an app without doing a full app store release, which I think is still true to an extent, but like policies have shifted on that.
-
-[37:37] And it's like, Uh, it's I know that Apple doesn't like that generally because they want to have firm control over what apps do. So if you're able to change what an app does outside of their review process there, they look at you suspiciously for that. So, uh, but yeah, definitely, you know, my, my recollection is that four or five years ago, Expo was really great for what it could do, but it was a very limiting sandbox.
-
-[38:02] If you try, if you needed capabilities that it didn't offer out of the box. You're kind of screwed. You had, uh, it was a little bit like Create React App in that where what it did was really great, but it didn't do everything. And if you needed more, you had to eject and then you're on your own. Um, but that is not how I understand the story of or, you know, the experience of using expo today.
-
-[38:24] From what I hear, if you're building React Native right now, you start with expo because it just does makes it so much easier for you. So cool to see so much investment going into it still.
-
-[38:33] Got another link for us?
-
-[38:35] **Mark Erikson:** Uh, that's all the, all the major ones I had to talk about. I think at this point, we're sort of onto the lightning things, although I could, I could talk about some of the lightning things in more depth if we wanted.
-
-[38:45] **Carl Vitullo:** Yeah, we got 15 minutes. Let's do a, let's do a, maybe I'm trying to think of a slower lightning round, but let's do a pseudo lightning round here.
-
-## [38:53] React Prod Source Maps (!!)
-
-[38:53] **Mark Erikson:** So, um, this next one is, And on these next two are things that I both have a very personal stake in. So, over the weekend, I published a new package called ReactProdSourceMaps.
-
-[39:09] And this is going to take a little bit of background and explanation. Um, so, JavaScript libraries Are normally published to NPM code that has been backwards compiled to, you know, yes, five syntax for compatibility with IE 11, although that's finally starting to change and more libraries are shipping modern JavaScript.
-
-[39:30] And then when you build your application with next or Vite or expo or create React app or whatever. All your application code and your nice original js or tsx files all get mangled together, mashed into a bundle, minified, and shipped to production. And when we want to debug our applications, we, like, we need a way to reverse map from the final mangled minified code back to the original source files that you had on disk.
-
-[40:03] And so bundlers and build tools use a technology called source maps, which literally contains the exact original source files that you had on your computer when it was built and defines how they got transformed into the final minified lines of code. So for example, uh, App bundle dot JS line one column 700, 000 through 700, 010 to do list item dot JS line 23 you declared your to do list item component.
-
-[40:39] And so that's how Browse and browser dev tools and other tools can show you what looks like the original files when you try to debug either a development or production application. And the problem is. Specifically, that the React libraries have never shipped with source maps. For their production build artifacts.
-
-[41:02] So if you build a React app in dev mode, React has a development build where the bundle is still readable. It's got comments and white space and original variable names. And if an error gets thrown, you can see a stack trace, and you can at least read the function names inside of React. One of the nice things about React has always been that most of the time you don't have to worry about how it works inside.
-
-[41:28] We can treat React as a black box. The important thing is understanding that, you know, it's, it's the mental model. If I set state, it re renders. If my UI is wrong... Look at the data, look at the rendering logic, trace the data back up the tree to where it came from. So most of the time, you don't have to debug inside of React.
-
-[41:49] But there are times when you do. Okay, maybe that's more applicable to library maintainers or people like myself and Brian that are working on developer tools at Replay. The problem is when you try to debug a production build of a React app. React has only shipped the minified, the prebuilt minified bundle.
-
-[42:09] They don't have source maps for it. And it's hard enough to understand what's going on inside of React. When you can actually read the original source code, it is impossible to understand it when all you have are single character variable names and everything's been mashed together. So, uh, about four months ago.
-
-[42:27] I took about a week, and I figured out how to modify React's build pipeline so that it will actually generate source maps whenever you, whenever they build React. And that PR has been sitting there, and Dan Abramov and I were going back and forth on reviews for it, and as far as I'm concerned, it's there, and it works, and it should just be merged. Dan had one small reservation, and I never quite convinced him that... It's fine. It works. Merge it. So it's still sitting there. And hopefully it will get merged at some point in the near future.
-
-[43:02] But the next problem is that even once it gets merged, the React team hasn't released a stable version of React since 18.2 came out a year and a half ago. Which is kind of frustrating. They are putting out canary builds, and Next is using those canary builds, but we haven't had a new stable release in a year and a half. So if and when a, that PR is merged and a new stable release comes out, then, you know, React 18.3 would have source maps.
-
-[43:31] But there's nothing for React 18.2 or 1 or 17 or 16. What I did over the weekend was I literally checked out React 18.2's tag from the repository and I backported my build pipeline changes. I made sure that I could build the exact byte for byte identical copy of React 18.2 production. And then I copy pasted my build pipeline changes to generate source maps over to that.
-
-[44:04] And it works! And the next problem is that, okay, so let's say that, you know, I have a Vite app and I'm using React 18.2. Well, I've installed React off of NPM, didn't include any source maps. I can download the React 18.2 source map I generated. But that doesn't help the app bundle source map that I just made.
-
-[44:31] I figured out how to use a couple different source mapping libraries, and I've written a CLI package that will... You give it the file path to the source map for an app bundle, and it looks to find a copy of React dom listed in the in the files, and it replaces The source map of the minified file with the source map of the original bundle before it got minified.
-
-[45:00] So that as far as the source map bundle is concerned, it has the original looking React source code available to debug. And I was able to prove that I could like serve up that modified V app and I could stick a break point inside the place where React renders function components and it worked and it paused there and I could inspect everything that was in scope with the release of this package, uh, I have not actually done it yet, but in theory.
-
-[45:30] Anybody who has a React app right now that uses React 18.2, 18. 1, or 17. 0. 2 could add a post build step that uses my package, correct React source map in their app bundle. And the other thing that I would like to do with this... So I've been talking about, you know, my day job at Replay ought to be able to take those same source maps and automatically insert them into our backend so that if you made a recording of a React app and didn't have the original source maps, we could automatically insert them anyway, as you debug the recording, like, I'm sure we can do it.
-
-[46:09] It's just a matter of convincing the backend team that we should.
-
-[46:12] **Carl Vitullo:** Yeah, I, I'm thinking of, I'm thinking of like Sentry and things too. All these other
-
-[46:17] **Mark Erikson:** Yeah. The, yeah, the, the, the Sentry folks have been following what I've been doing and they are very excited about this.
-
-[46:22] **Carl Vitullo:** Yeah, no doubt.
-
-[46:24] **Mark Erikson:** So I, I realize this is sort of a niche thing and not everyone is going to get immediate benefit from it, but like, I truly think this is something that a good bunch of the React community will benefit from because I was able to do the work to generate these just once.
-
-[46:41] **Carl Vitullo:** Wow. Okay. So I knew that you had done this. I knew you had, you know, published a thing, but I didn't realize that you were, it had done, it had taken so much, I don't know, effort, like, wow, going in and modifying source maps for... taking the apps, source maps, and then replacing the right parts of them, so the unrelated source maps still work, but you also get all the React ones.
-
-[47:06] Like what? That's actually crazy. That sounds if I got, okay. If I got to that point, I would say, wow, no, I'm not doing that. That sounds like a pain in the butt.
-
-[47:15] **Mark Erikson:** Like the thing is the actual logic is like 20 lines of code because there is a library that I found that will do the source map swapping. Like the majority of the logic is just import this library. The existing application source map, and then it gives you a callback for every file that it sees listed. And so I'm literally just saying, is this file's name React dom. production. min. js? And if so, figure out what version of React it is, load the right sourcemap and replace it.
-
-[47:49] **Carl Vitullo:** Good job, holy crap, that's wild. um, I think that's all I have to say on that. That sounds incredible. That sounds super valuable. And especially if, if Replay and Sentry can both take advantage of that and just do it on behalf of everyone. That sounds incredible. If everyone using either of those products can get source maps for free without. Or source maps for React for free without doing anything without changing configuration or anything.
-
-[48:15] Wow. Okay, cool. Nice. Big project.
-
-[48:19] **Mark Erikson:** So that's what I did my last two or three days.
-
-[48:21] **Carl Vitullo:** (laughs) That's that's a productive two or three days. Very nice. Cool. Okay. Well, I don't know how lightning that round was, but.
-
-[48:29] **Mark Erikson:** Not very, but hey, it worked.
-
-[48:31] **Carl Vitullo:** It worked. It was interesting. It was good.
-
-## [48:33] Official React+Typescript documentation
-
-[48:33] **Carl Vitullo:** Cool. Uh, I'll move us on though. Um, Yeah, React. Dev now has official TypeScript documentation. Thank you, Orta, for bringing this home. We discussed this last month when it was still a draft PR, but it has been merged, it has landed, and we now have official documentation on how to use TypeScript with React. Absolutely incredible. We're not going to comment on how long React and TypeScript have been out and available and the delay between... It being widely used and it being documented, but we have it. It's great. I'm glad we have it now.
-
-[49:11] **Mark Erikson:** It looks amazing. Orta, you did a fantastic job. Thank you.
-
-[49:15] **Carl Vitullo:** Uh, Mark, you got another lightning round? Well, you said you have a hard stop in three minutes. So if we want to blitz through some of these.
-
-## [49:23] Redux Toolkit 2.0 beta
-
-[49:23] **Mark Erikson:** Yep. So really fast, uh, mentioned this before, but Redux Toolkit 2. 0 is still in beta. We would really like people to try it out. And then just this last week, I published React Redux version 9 alpha, which has the same kind of, you know, ES module packaging changes. That, you know, I've been trying to apply to all our different libraries. Um, so again, we would really, really like people to try these out.
-
-[49:48] Tell us what breaks that shouldn't be breaking and give us feedback on things like the, you know, the new features and Redux toolkit 2. 0, pry them out. Tell us what you like or don't like so we can, you know, make any changes before they go final.
-
-[50:03] **Carl Vitullo:** All right, now's your chance. Get that feedback in. Uh, you want to run through your last link there?
-
-## [50:09] The Underlying Mechanisms of React's Concurrent Mode
-
-[50:09] **Mark Erikson:** Yep. Uh, and then the last item I have is, there was a really, really good article called The Underlying Mechanisms of React's Concurrent Mode. And again, this is not a thing that most people need to necessarily worry about because it's inside of React. I always appreciate articles that explain how stuff is built, what are the technical constraints.
-
-[50:29] And so this was a really good look at how React has implemented the ability to split up renders into multiple pieces and delay parts of it.
-
-[50:37] **Carl Vitullo:** Very nice. Um, I, I just have one lightning round link myself. Um, Sebastian and I were judges for React jam, which is a, it was a hackathon put on by a startup called rune that.
-
-[50:51] Is a I don't even know how to describe it, but it's a it's an app that you can play other games in. Uh, it's like a multiplayer games app. It's a little bit like discord activities if you've used any of those, uh, they did a hackathon building games with React. Um, so. Yeah. Sebastian and I judged it. We played a bunch of games.
-
-[51:13] They were pretty fun. And yeah, check it out if you like games and React and stuff built games built with JavaScript.
-
-[51:20] **Mark Erikson:** And on that note, I do unfortunately have to bail out for another meeting, but it's been a good discussion. And yeah, I think there's a lot of good stuff happening in the ecosystem.
-
-[51:29] **Carl Vitullo:** Yeah. Yeah. Always, always many new things.
-
-[51:32] Cool. Uh, Mark, thanks for joining me, uh, everyone in the audience. Thanks for listening along.
diff --git a/src/transcripts/tmir-dec-2023.md b/src/transcripts/tmir-dec-2023.md
deleted file mode 100644
index 60d3265..0000000
--- a/src/transcripts/tmir-dec-2023.md
+++ /dev/null
@@ -1,442 +0,0 @@
----
-title: This Month in React (December 2023)
-date: 2023-12-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- Quick hits:
- - [[00:55](#layoffs-news)] [layoffs.fyi](https://layoffs.fyi/)
- - [[01:37](#state-of-react-native-survey-closes-jan-5)] [State of React Native runs til Jan 5th](https://stateofreactnative.com/en)
- - [[01:50](#adobe-💔-figma)] [Adobe and Figma abandon merger](https://www.figma.com/blog/figma-adobe-abandon-proposed-merger/)
-- [[02:07](#react-native-073)] [React Native 0.73](https://reactnative.dev/blog/2023/12/06/0.73-debugging-improvements-stable-symlinks)
- - [New debugging docs](https://reactnative.dev/docs/debugging)
- - New Debugger, [give feedback here](https://github.com/react-native-community/discussions-and-proposals/discussions/733)
- - [Bridgeless mode](https://github.com/reactwg/react-native-new-architecture/discussions/154)
-- [[06:33](#redux-toolkit-20-and-supporting-libraries)] [Redux Toolkit 2.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0), [Redux 5.0](https://github.com/reduxjs/redux/releases/tag/v5.0.0), and [React-Redux 9.0](https://github.com/reduxjs/react-redux/releases/tag/v9.0.0)
-- [[11:37](#xstate-v5)] [XState v5](https://stately.ai/blog/2023-12-01-xstate-v5)
-- React Server Components updates
- - [[17:49](#react-core-team-panel-on-server-components)] [Frontend Should Embrace React Server Components](https://thenewstack.io/react-panel-frontend-should-embrace-react-server-components/)
- - [[18:47](#ben-holmes-react-server-components-from-scratch)] [RSCs from scratch video from Ben Holmes](https://twitter.com/BHolmesDev/status/1735701191823151239)
- - [[19:16](#storybook-adds-support-for-rscs)] [Storybook for React Server Components](https://storybook.js.org/blog/storybook-react-server-components/)
- - [[19:45](#dan-abramov-blogs-again)] [Dan’s “Chain Reaction” post](https://overreacted.io/a-chain-reaction/)
- - [[21:52](#daishi-katos-oss-prototype-rsc-framework)] [New RSC-first framework, Waku](https://github.com/dai-shi/waku)
-- [[29:29](#stylex-released-by-meta)] [Introducing StyleX](https://stylexjs.com/blog/introducing-stylex/)
-- React docs discussion
- - [[32:50](#documentation-for-the-use-hook)] [Recent core docs pages updates](https://github.com/reactwg/server-components/discussions/7)
- - [[35:08](#dan-abramovs-ama-on-bluesky)] [Dan Abramov React AMA on BlueSky](https://bsky.app/profile/danabra.mov/post/3khbvuwanqx2h)
-- Lightning round:
- - [[42:16](#-requesterimpairment-an-ietf-joke)] [An HTTP Status Code, Requester Impairment (joke??)](https://www.ietf.org/archive/id/draft-richardroda-420requesterimpaired-02.html)
- - [[43:18](#-jules-blom-on-flushsync)] [More Than You Need to Know About ReactDOM.flushSync](https://julesblom.com/writing/flushsync)
- - [[44:56](#-react-fights-you-can-have-with-your-team)] [React Fights You Can Have With Your Team](https://www.bekk.christmas/post/2023/13/react-fights-you-can-have-with-your-team)
- - [[45:33](#-an-interview-with-kyle-mathews-on-gatsbys-story)] [Building React Framework Gatsby](https://oss-startup-podcast.launchnotes.io/announcements/episode-118-building-react-framework-gatsby)
- - [[46:41](#-tanstack-router-v1)] [TanStack Router v1](https://tanstack.com/router/v1)
-- [[47:19](#what-will-happen-in-2024)] Discussion: what do we think will happen with React and the ecosystem in 2024?
-
-[00:00] **Carl Vitullo:** Thank you for joining us for December. I'm sorry about the audio quality of this month, I am on the road and I forgot my headset this time around. This is This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
-
-I'm Carl, I'm a staff product developer and freelance community manager at Reactiflux. Here, the Discord for React professionals. Mark, you want to say hey?
-
-[00:24] **Mark Erikson:** Hi, I'm Mark Erikson. My day job is working at Replay. Io, where we're building a time traveling debugger for JavaScript. And in my copious amounts of spare time, I work on Redux, and boy, have I spent a lot of time doing that lately.
-
-[00:37] **Carl Vitullo:** Yeah, you've got a lot of, releases to announce.
-
-[00:40] **Mark Erikson:** I think we're both recording this one while we're on the road, too.
-
-[00:43] **Carl Vitullo:** Yeah, I am coming, I am genuinely coming to you live from, my mom's basement. So this is a funny recording this time around.
-
-I'll start us off with a couple of just quick hits of little news.
-
-## Layoffs news
-
-[00:55] **Carl Vitullo:** I'm thinking of starting a new segment just talking about layoffs and trends in the job market for tech, that seems pretty relevant for news discussion. December has been trending down per layoffs.fyi, which is a great resource, highly recommend. It's trending down; fewest layoffs by number of companies running layoffs since April of 2022, and it's been, qualitatively it's felt a little bit better, but last year December was among the lowest of the months for layoff and January went way through the roof, so fingers crossed that doesn't happen this year. I think that'll be a pretty big indicator for tone of 2024.
-
-## State of React Native survey closes Jan 5
-
-[01:37] **Carl Vitullo:** There is a state of React Native survey that's currently running. It went live a couple weeks ago and runs until January 5th. So, if you use React Native, definitely check that out. Highly recommend, giving your feedback.
-
-## Adobe 💔 Figma
-
-[01:50] **Carl Vitullo:** This is sort of related to our field, but, Adobe and Figma had been doing a very large merger. I know many, many people in the React ecosystem work with people who work with Figma. So I thought I'd give that a shout out.
-
-## React Native 0.73
-
-[02:07] **Carl Vitullo:** On to the real news. I'll start us off with our first link, which is react native 0. 73. New pretty big feature release. They've got a lot of good improvements coming out here with improvements to debugging, a couple of relatively nitty gritty technical details like Support for symlinks, which is a huge problem if you use symlinks in development, and not a problem at all for anyone else, which would include me.
-
-But, the new debugging section looks really good. It looks like they've put a lot of energy into making debugging a lot better, which, as someone who has developed a product with React Native, debugging was a painful experience, so that's nice to see. They've got a new experimental, and Kind of buggy debugger.
-
-They ask you to give feedback, but yeah, it looks like they've got a couple of nice Maybe smaller improvements, but like, for instance, apparently, this is not something I had noticed while developing, but you send console. Logs early in the like, bootstrap process for starting up a new, for starting up a React Native process as you launch the app.
-
-If you previously, if you had run console logs very very early in that launch process they would just silently get dropped. You would not see them and obviously that makes debugging a lot harder. So they have updated the way that the debugger works to capture those and Ship them out once the Once the console has been set up and attached.
-
-So that alone is a huge improvement. I think that'll be nice. Another relatively large breaking change. I think they are deprecating the at type slash react native package. This is good news It's because they have Moved those types into the React Native package itself. So it's now first class types, it's included in the package.
-
-You no longer need to use the at types package. So that's awesome.
-
-[04:08] **Mark Erikson:** Experience is zero. Like I've, I've attempted to run one or two tiny React Native projects. Mostly just sussed out tiny bits of Redux stuff, and that's it. One observation out of that that I do think is interesting is that it feels like React Native has jumped on board TypeScript more than the React core has.
-
-One is that they, I think, React Native projects now ship with TypeScript set up by default, it sounds like. You know, this example here of moving the types into the core, whereas with the actual React and ReactDOM packages, the React types are still maintained separately. Now, the React types packages are now semi officially maintained by people affiliated with the React team, but there's still that difference of not actually shipping it with the actual React packages.
-
-Now you can also caveat and say this is a good thing because there have been tweaks and improvements to the React types packages that have come out in the last year and a half. Whereas there have been zero official stable React package releases. So there is actually a little bit of benefit to having those decoupled.
-
-[05:22] **Carl Vitullo:** Yeah, well, hey, maybe if they had been forced to React release in order to update the types, they would have stuck in a couple of, small improvements along the way too.
-
-[05:30] **Mark Erikson:** One other React native thing to toss in here, we'll mention it later, but Dan Abramov was doing an AMA over on BlueSky one of the various Twitter clones that are out there.
-
-And one of the questions was. You know, Dan, now that you're working on a product that is built with React Native, what are your opinions? And so per way that down that discussion, he had a couple thoughts about it's in some ways, it's great. In some ways, it actually feels really, really difficult and hard to use.
-
-But there were some interesting thoughts and discussion there.
-
-[06:03] **Carl Vitullo:** My general sentiment seems to be shared by a lot of people that I've known have worked pretty deeply with React Native is it was really great, it let me do all sorts of stuff, I never want to use it again.
-
-I think that's maybe just a reflection on the fact that mobile development is harder than web. And if you're trying to do both web and mobile development, React Native is pretty great, lets you do a lot more cheaply. Because you can actually share a substantial amount of the code between apps.
-
-But, it's got its own headaches too. You want to take us on, Mark?
-
-## Redux Toolkit 2.0 (and supporting libraries)
-
-[06:33] **Mark Erikson:** Yes! So, my big news, kind of on a personal and professional level, I've been teasing this one for months, but on December, I finally hit the button and shipped Redux Toolkit 2. 0. Along with major releases for all the other Redux related packages.
-
-Redux Core Version 5, React Redux Version 9, Reselect Version 5, and Redux Thunk Version 3. This has been a massive undertaking on so many levels. I started working on this slew of major versions at the start of the year. And Initially, the primary goal was to update the packaging to better improve ES module CommonJS compatibility.
-
-That turned out to be even more of a nightmare than I expected it to be. We added a number of features, we deprecated, we removed a bunch of deprecated options, there were TypeScript updates. And then the only, like the main reason we were able to even able to get these releases out this year was because we ended up deferring any major changes to the RTK query data fetching layer until sometime next year.
-
-People have asked for lots and lots of new features and options and changes, like to address those at some point, but that's just a giant undefined amount of work. Like, we, we, we have so many issues and feature requests that it's going to take weeks just to go through them and collate the list of what people are asking for, then take time to analyze those, do the design work, figure out how all these options are going to interact, and build them.
-
-And I can see that if we waited to release 2. 0 to include all those RTK query changes, It would be this time next year. Got a lot of help from one of the other primary maintainers, Ben Durant. And then, there's a guy named Arya who just left a comment in the chat who has done a ton of work on Reselect in the last few months. And we actually made some major updates to Reselect as well.
-
-One of the biggest ones was We changed the default memoization strategy for Reselect. Reselect has always had its own little built in memoization function that does a bunch of reference comparisons against all the values that are passed into the selector function. And the problem is that also defaults to a cache size of 1. If you call it three times in a row, and you alternate the arguments, like A, B, A, then it's not going to see the same arguments twice in a row, and it's not going to save the results. It's going to keep recalculating things every time.
-
-This always felt like kind of a bad developer experience situation. And so I ended up swiping crash implementation based on weak maps directly out of the React source code. React has a new memoization function built in called cache, and I literally copy pasted that code and made use of it and re select.
-
-[09:54] **Carl Vitullo:** Oh, very cool.
-
-[09:56] **Mark Erikson:** Yeah, it's buried down in the library, and I think it may actually be now listed in the docs. So, we did some testing on it, and we concluded that it's at least as fast in terms of like raw comparison performance.
-
-Um, in a sense, it has like an infinite cache size, but on the other hand, that could also be referred to as a memory leak, depending on how you look at it. Ultimately made the decision that this was worth actually including. And made that switch in Reselect version 5.
-
-So, I shipped all these literally the day before I went off on a trip to a conference, plus a vacation. So it was in theory Out of my head before I went off on this trip. Unfortunately, one of the truisms of maintaining and publishing packages is that it doesn't matter how many alphas and betas and release candidates you put out and how much you beg people to try them out, you will always get a whole bunch of new bug reports the minute after you publish the new versions live because now people are actually using them. And they're using them in ways you didn't anticipate.
-
-The biggest couple things I'm seeing are some lingering TypeScript update issues where there's things are just changed a little bit in ways that people weren't expecting. I am very, very happy to have this out the door.
-
-[11:18] **Carl Vitullo:** You've brought up the alphas and the betas in the last couple of months.
-
-Glad to, glad to hear you got it shipped. That's awesome. I obviously don't have anywhere near the level of access, or familiarity with you, so I can't, I don't even feel like I can respond to that appropriately, so. (laughter from both) I'm just going to roll us on to our next one.
-
-[11:36] **Mark Erikson:** Moving on!
-
-## XState v5
-
-[11:37] **Carl Vitullo:** Moving on! stately, or XState v5 has been released.
-
-I don't know, I don't think I would call it a competitor to Redux, but it does also deal with state. It deals with State machines, which Redux is one way. You can also implement state machines in Redux. It's not, I don't know, would you say, would you say Redux models things as state machines? Or would that be, would you say that's inaccurate?
-
-[12:05] **Mark Erikson:** David K. Piano would point out that Redux is typically half of a state machine. Um, the distinction being that a true, with a true state machine, first you look at what state am I in now, and then you decide, okay, if I'm in state A, do I want to respond to action or event? And in Redux, you typically just respond, you respond to the action in the reducer unconditionally.
-
-And so like, David actually contributed an example to the Redux style guide a while back, where it's like the first thing you would do in a reducer to make it a true state machine is switch state. Status, and then look at the action type. Whereas with a typical Redux reducer, you just, oh, here's the action.
-
-I handle it regardless of what the values are originally.
-
-[12:58] **Carl Vitullo:** That's a cool and precise distinction. I like that. I have always like had a place in my heart for XState, but I've never really used it in a project. Um, they've had a. A bunch of really phenomenal developer tools that help with designing state machines.
-
-You know, as a state machine library, they've written tools so that you can visualize them and write them in a visual way and then copy paste the code out. So I have actually used those tools in a Redux context because most of the projects I've worked on have been in that. But I've, I've been following them, following along with their development for a number of years.
-
-Really appreciate the work that they do. I'm pretty interested to see a couple of these. It looks like one of the big changes here is that everything is an actor, where actors have their own internal state, can send and receive messages or events from other actors, and can create other actors. So it sounds A little bit like a reducer, sort of like in the RTK slices, reducers kind of sense.
-
-And I think that's, been a place where I've struggled with modeling application state as a state machine is you end up with lots of little sub states. You know, each feature kind of has its own state. So, this seems like a pretty cool mental model. Code model for getting a little, maybe, maybe more precise control over how your state flows.
-
-You know, Mark, like you said, Redux is half of a state machine. So I don't know that I could articulate a specific benefit for using an entire state machine. But I do know that using the developer tools, the designer the state machine designer tools to figure out how I'm going to write my code has been really powerful.
-
-I haven't constrained myself to actually using specific state machines, but even just going through the exercise of enumerating all the states, enumerating the transitions, evaluating what data I need to pass along with the transition to make a state change self contained and isolated, um, uh I have found super valuable.
-
-They've got some cool future plans listed as well. Um, I, one that I really like, the first one is a toPromise helper function for converting actors to awaitable promises. That sounds really cool. If I could just say like, transition this state, and when it's done, keep going. Sounds pretty nice. Seems like a nice way to make asynchronous write code that responds to them in a more iterative way.
-
-So, um, I think that sounds pretty neat.
-
-[15:36] **Mark Erikson:** Yeah, as someone who also maintains a state management library, I, I just generally appreciate the amount of effort and work it took them to get this release out the door, um, I, I know that trying to implement their TypeScript support has been really, really complicated and they've got an absolute genius working for them. Matush Brzezinski, whose, whose handle is, andreasrake, has done a lot of work around their TypeScript support and trying to design APIs that are sufficiently flexible is a really, really tough task.
-
-So I, I understand and appreciate the amount of effort it took them to get this out the door. One other, one other plug, I don't know if this is even a thing they've released yet, but something they've been looking at is the idea of being able to analyze real world code and describe it in a state machine format, kind of like AI powered, being being able to use To like take like an arbitrary Redux reducer or maybe even like a use effect setup and have it analyze that and generate a state machine like description of it so that you can then use some of those graphical developer tools to visualize the code.
-
-That's a separate thing from the XState library itself, but I know that's something that the stately company is working on.
-
-[17:00] **Carl Vitullo:** That sounds incredible, actually. Yeah. That's like the dream of self documenting code. State machines are just so easy to read in the abstract. I've always really struggled to go back and forth between state machine, real code.
-
-So if I could have something do that for me, ooh, that's pretty cool.
-
-Alright, let's move on though. Mark, what's your next link? Or set of links.
-
-[17:24] **Mark Erikson:** So my, my caveat for a lot of this month's discussion, as usual, is that between travel and holiday stuff, I'm, I'm even less plugged into what's actually been going on in the ecosystem this month. This section especially is a collection of things that look interesting, but I haven't had a chance to go through them myself. So a few different updates and discussions related to React server components.
-
-## React core team panel on Server Components
-
-[17:49] **Mark Erikson:** A panel at the React Summit New York conference in, mid November where some members of the React team and Next. Js and a couple other ecosystem folks had a discussion about the state of React server components and whether they're worth adopting now and how are they used and how do they work. Ironically, I was at the conference.
-
-I did not have a chance to watch that panel either live or recorded later, but this article is a fairly good summary of the discussion in that, um, so there were, there were a number of folks involved in that, including Andrew Clark, one of the React core members, Tom Preston Werner, who's currently working with RedwoodJS, Ben Holmes, Josh Camot, and a couple of the React devrels.
-
-Curious about sort of like the, I guess like the semi official view of what's going on with server components. This would probably be a really good discussion to watch through.
-
-## Ben Holmes, React Server Components from Scratch
-
-[18:47] **Mark Erikson:** Speaking of Ben Holmes, so he's very involved with the Astro framework, but he also does a lot of videos on his YouTube channel where he explains things. He did a larger video called React Server Components from Scratch, about 20 minutes where he talks about server components and does a lot of drawing on the whiteboard and tries to explain how they work and what's going on and knowing Ben's ability to describe things that should be very useful.
-
-## Storybook adds support for RSCs
-
-[19:16] **Mark Erikson:** The storybook tool for documenting has actually added React server component support. Frankly, I have no idea how they've even implemented this at the technical level, but I can see this being a very useful thing. Like if you're writing server components, you want some way to be able to document them and make use of them, but they have all these requirements around being able to fetch data. So in some way, they've implemented support for using server components.
-
-## Dan Abramov blogs again
-
-[19:45] **Mark Erikson:** Dan Abramov had done a lot of blogging in 2018 2019 on his site overreacted. Io, and Dan is a very deep thinker, he does a great job of explaining things, and he'd written a number of posts that kind of talk about how does React work conceptually, how do you approach modeling things with use effect, And he'd really spent his last two to three years entirely focused on rewriting the React documentation.
-
-So he hadn't blogged at all in a couple years. Well, now that the new React docs are finally out, and Dan has left Facebook and is now working on the BlueSky app, he's finally had a little bit of time to sit back, And do some thinking. And he's put up a new blog post. It's a little bit on the same principle of his talk from RemixConf earlier this year.
-
-He did a talk at RemixConf where he was like, what if React had always been server first? What would the evolution of React have looked like there? And he actually did a whole live coding demo where everything was like late 90s, IE6 themed. What kind of follows along, or this blog post kind of follows on that same principle.
-
-So it's kind of like, what if we were sort of building React from scratch in a server centric world, and we need, and components could return async data, or async results. How would you even write the code that looks at the return values of the components and unwraps them recursively so that we can wait until the data is actually ready?
-
-And he never actually uses the word server components in this blog post, but if you read it, With kind of like between the lines, he's actually explaining this is the mindset behind how server components are implemented conceptually and under the hood. And I think he said this is meant to be the first in a series of blog posts that kind of digs into this, into these concepts.
-
-## Daishi Kato's OSS prototype RSC framework
-
-[21:52] **Carl Vitullo:** This is pretty early stage, I think, but somebody has put together, Daishi Kato.
-
-[21:59] **Mark Erikson:** He created Jotai and Valtio and now maintains Zustand, and he's also written a dozen other React slash state management utility libraries.
-
-[22:13] **Carl Vitullo:** I recognize his name because you had mentioned him in previous episodes we've recorded.
-
-But I could not have given that comprehensive list, so thank you for that. Daishi Kato has written a minimal React framework for, that uses React server components. So, this is the third, sort of React server components from scratch that I've seen. I think this is the first that I've seen that is Positioned as a framework that you can use.
-
-So, like you mentioned, Ben Holmes did his From Scratch video. I always appreciated Ben Holmes videos. He, he, he says he's the CEO of Whiteboards at Astro, which I, I appreciate. He, he does a good job with DevRel. And I have not yet watched his video. Like he said, travel, holidays, I'm behind. But, so his was the second.
-
-Last month we talked about somebody who wrote a really great, very long, comprehensive, I have a blog post about implementing React server components on their own in isolation. It looks like server components are now starting to filter out from only Next to now people have started to really wrap their hands, wrap their brains around them and start experimenting with them on their own.
-
-So I think, to me, that is a really big step in this open source process. We've been talking about React server components always with the caveat of like, "Oh, I don't really know. I haven't played with it." Because of how complex and undocumented the programming model has been so far. So seeing some of these people really dive deep and get their hands dirty and produce things is really good.
-
-So starting with a blog post, then a video, now a framework by three separate people. The community expertise in React Server Components is really ratcheting up, pretty cool to see.
-
-[24:05] **Mark Erikson:** I can also vouch that RedwoodJS has been putting a lot of effort into trying to implement Server Components for their framework as well.
-
-I know they did a blog post a couple months ago where they said we're all in on Server Components. I had a chance to talk with Tom Preston Werner at a conference a couple months ago where he was talking about some of the complexities where in a lot of cases they're having to go into the guts of Next and look at the implementation and try to figure out like how much of this is going What anything integrating with server components would need versus how much of it is specific to Next's internals.
-
-And I've seen some of the discussions from some of the other Redwood engineers as they're trying to figure out how to put all the pieces together. So there is activity. I don't know how fully along Redwood's implementation is yet, but there is very definite. Effort being put into trying to, trying to productionize that.
-
-[25:00] **Carl Vitullo:** I don't know. When did we, when did we start seriously talking about React server components? Do you, do you have a sense for that? It feels like it's been all year.
-
-[25:07] **Mark Erikson:** I feel like almost three years ago was when the first video came out. It was either two or three years ago. And, and like it sat around for a while. And then we finally started seeing the integration to Next after, Sebastien and Andrew moved over to Vercel.
-
-[25:23] **Carl Vitullo:** This is all building upon the primitives that were added in Suspense, right? Which I know that, I just saw some discussion about, it's been five years since Suspense was first unveiled.
-
-So this is, I think, to me, that's a testament to just how difficult the work that they're trying to do is. We can talk a little bit more about what this unlocks later, um, I have a link coming up in the lightning round. Well actually maybe I'll just bring it in right now.
-
-Guillermo Rauch did a, um, a great post talking about, or in response to, what's the difference between PHP and Next with the, this. Satirical, kind of shit talking of like, "Oh, JavaScript is finally catching up to PHP 20 years ago, haha." I thought he had a really good response, basically talking about like, Yeah, we do have, on the face of them, they are pretty similar, but some distinctions are there's out of order streaming.
-
-Like you can piece together the HTML by order of importance, not You know, linear order of HTML and pre rendering versus rendering on the client, control over that, which I, I haven't used PHP seriously in close to 10 years at this point, so I can't comment too much about what the capabilities are, but you know, I remember trying to do mixed server client rendering in PHP and it was a lot of writing JavaScript code in the HTML of PHP and then like jumping in and out of PHP tags to like render pass data in or whatever. Or you write your JSON endpoint. And so like, yeah, you can do those things, but it's, it got real messy real quick.
-
-Or it, it at least wasn't, it wasn't a pit of success. It was not easy to get something that was maintainable and great. That felt good. Felt. Solid and robust. So, yeah, I think there are, I know people talk a lot about unnecessary complexity or just people like to bash on JavaScript, people like to bash on web and client and frontend, but I do, I really believe that the React server component stuff is Genuinely pushing the envelope of what's possible in a real and deep way.
-
-I, like I, we don't, we don't have a, FrontEnd doesn't have a academic discipline, you know. There's no computer science researchers writing JavaScript. That is genuinely how I think about What a lot of the React core team is doing. Like, were this an academic discipline, this would be PhD thesis, postdoc.
-
-Actually, you know what? Like, it's not an academic discipline because it is well beyond the complexity that would be in an academic setting. This is post graduation, you've got your Ph. D., you're now working in industry, advancing the state of that industry. And I think that is truly what the React core team has been doing for my entire career.
-
-It's one of the reasons I have a lot of trust in them, is they keep executing, and they keep, for an entire ten years, they have stayed at the bleeding edge, and they have set the norms that everyone else in the industry follows. Okay, it's taken them five years to start realizing the vision that they set out with Suspense.
-
-Well, you know what? They're doing it. They keep, it's hard, it's really difficult to feel out all the edge cases, it's really hard to communicate to all of the developers what you're supposed to be doing, but man, they're doing it. They are, they have continued to do it for my entire career, and I just have huge, huge amounts of respect for them.
-
-[29:11] **Mark Erikson:** Yeah, they've always had a very long term vision of how they want to build things, and they've kept chugging along towards that goal.
-
-[29:19] **Carl Vitullo:** Bit of a, bit of a ramble there, bit of a rant, but, I was thinking about it over the last week or so, in prepping for this. Just, the work they're doing is really cool.
-
-## StyleX released by Meta
-
-[29:29] **Carl Vitullo:** Okay, but under our next link, facebook released, something that they first talked about a number of years ago, Stylex, a CSS and JS tool that, that they use at Meta. Sorry, not Facebook, Meta. I don't have a lot to say on this. Um, I know I'm introducing it, but it's a CSS and JS library. Kind of feels like the moment for that has, um we, we had a lot of experimentation on that.
-
-And it feels like generally we, as a, an ecosystem, the React subset of web development, have settled on CSS and JS not being the best solution. Just, some some of the trade offs are Increasing the size of the JavaScript bundle, where JavaScript is more expensive to load and parse than CSS. So it tends to add a lot. Relative to non more traditional CSS. It tends to add more startup cost than other methods. Mark, do you remember when they first announced StyleX?
-
-[30:31] **Mark Erikson:** It, there was a, there was a conference talk about it at ReactConf in either 2018 or 2019. And they didn't give many details. They just kind of said, here's an overview of the tooling that we use internally at what was, what I guess was still then Facebook and kind of what it does and how it works at a high level.
-
-The community was aware that existed. But there was no information on the actual internals or anything that you could use. So there was, it was always sort of this, this hint of this exists. It was only this year that you could actually, they were, they started actually moving towards being able to release it open source.
-
-And so now it's finally out. Um, yeah, the couple bits that I know about it are as, as the comment just said, it's primarily compile time, not runtime, so there's always trade offs there in terms of the amount of dynamic behavior it can have. I believe it compiles down to Atomic CSS, so part of the sales pitch is that as the app grows and you have more and more components using certain styles and certain rules, the growth of the size of the CSS stays lower than it might with other approaches.
-
-[31:48] **Carl Vitullo:** That does seem like a genuine advancement of the state of the art of CSS and JS. Um, especially, pulling, that was always the challenge with stuff like Emotion, um, or styled components was, I think you could wire it up to Webpack or limited other build systems, such that it would extract the, the styles into CSS.
-
-Some of them could, some of them couldn't, bit of a mix and match, but okay, that, that being, The major downside of CSS and JS, if they, since they have built it as a compile time extraction of styles, that's avoiding the biggest, worst trade off. So that sounds pretty cool.
-
-Positioning this as extremely large code base styling tool, so focus on performance at scale sounds exactly like what CSS and JS needs. I think that's all. I got a say on it. You want to take us on to the next news item?
-
-## Documentation for the use() hook
-
-[32:50] **Mark Erikson:** Moving us along, a couple of discussions around docs. So, I've, I've actually been whining for a lot of this year that okay, it's great that the new React doc site is available, it has a wonderful tutorial, but it just feels like there's so many other pages that need to get filled out for it to be fully useful in terms of some of the API references and usage guides.
-
-And I I had some discussions with some of the React dev rels this year. So they actually just posted an update that collates some of the recently added or updated docs pages that they've been working on. And it looks like a, and kind of the, some of the theme here is they've been working on documenting A lot of the new APIs that exist around server components and server actions.
-
-So we actually have some documentation for the ambiguously named use hook, which I'll be honest, I still don't fully know the status of this. I guess the docs page says it's only available in canary and experimental builds. So I guess you can use it with Next, and that's, that's kind of about it. But they've also documented the new UseFormState, UseFormStatus, and UseOptimistic hooks that you would use with the, and with server actions.
-
-They've documented the useServer and useClient, not sure what the word is for them, markers that you would put in files so that the bundler knows how to parse those. They've added some more details on the useTransitionHook, they've talked about the cache memoization API that I talked about earlier.
-
-They've documented the HTML form tag. In a sense of, here's how you can use this in a React app and actually write kind of more browser native forms. They've added a page that talks about thinking about the UI as a tree, and they're working on some additional documentation. So I'm a big docs person, and I really, really appreciate seeing them continue to actually work on these and not just leave the site as it was after the new tutorials came out.
-
-## Dan Abramov's AMA on BlueSky
-
-[35:08] **Mark Erikson:** Along with that, Dan Abramov is now working on the BlueSky Twitter clone app as his day job. And he recently did an AMA over on BlueSky. People had a whole bunch of good questions over there. I mentioned the one earlier about people asking What are your thoughts on React Native now that you've actually used it?
-
-Um, there were some questions about React batching and will React ever get ported to Rust? There was one in there that was, What do you think should happen to create React now? And Dan's comment was, It would be nice if it was turned into a build time server components framework. I don't expect that to actually happen, but it's an interesting train of thought of what could we do with the name and the toolset if we wanted to.
-
-[36:03] **Carl Vitullo:** Dan has gone a little quiet the last, like you mentioned earlier, he's talked about going all in on the docs. He also mentioned some challenges he experienced with his own perfectionism trying to get it just right, which is he attributed as part of the reason the docs took so long to come out. Sounds like he may have gotten a little burned out too.
-
-[36:22] **Mark Erikson:** Oh, yeah. Oh, yeah.
-
-[36:24] **Carl Vitullo:** Burnout is real. Burnout is tough. So it's nice to see him in a new context, working on a new It sounds like he's enjoying getting his hands dirty working on an application rather than staying at the high level of just talking about React and developing it from the core. Um, I think it might, seems like he's enjoying it.
-
-It's nice to see him get back into writing and community discussion a little bit more. Um, this has been a really good thread. I'm, I'm also a big fan of Blue Sky. I have been enthusiastically looking for an alternative to Twitter. So I am optimistic that Dan being a more prolific poster on the platform will help it succeed.
-
-Glad to see a few more of these. Definitely recommend going through the thread and just reading a bit. There's a, there were a couple of really good questions and answers. One that I saw and responded to, so I'm gonna toot my own horn a little bit. Somebody asked about, um, React and, what's the Like, Module Federation, What, Microfrontends?
-
-[37:33] **Mark Erikson:** yeah. Those are probably too
-
-[37:36] **Carl Vitullo:** Yeah, okay, so somebody asked about micro frontends and module federation and how React would work with it. I know that's been a subject of debate for a couple of years. It's sort of come and gone over time, ebbed and flowed, but I think that's a really big challenge. I think it's, maybe we'll see it come back a bit with React server components as those settle down, but I think the real challenge there is CI and CD, the build and deploy process for micro frontends.
-
-Which I think is, it solves a real problem for large teams, but it's difficult to implement. Tends to be a DevOps discipline rather than a library or product. Just, it's too deeply embedded in every step of the build, the development, the deploy, testing. Just too tricky.
-
-Coming back to that React Working Group discussion on GitHub, um, that you started us off with. It's really nice to see some of the Some of what they're looking to invest in more deeply. I've always thought that React worked really well once you get your head into the right mindset of, once you get the right quote, air quotes around right, mental model for how to think about UI. In the way that React would like you to, it unlocks a lot of really powerful possibilities.
-
-So, in the past, those a lot of those best practices and descriptions for the mental model, I have gained mostly through reading a combination of gists. On GitHub, and Twitter threads, and reading code from other people and seeing how they solve problems.
-
-Which is just not a very repeatable process. Like we have a learn page with many links that you have collected, Mark. I think that's been a One of the better ways to gather body of knowledge, but it's nice to see, it's nice to see some of that, some of those best practices working their way more into the docs.
-
-I think that a lot of them have been in flux for a long time, a period of years as we were figuring out first hooks and then like, what is suspense? How does it work? Oh, now it's server components. How do those work? What are they? It feels like a very long journey to where we are right now that is It's nice to see things stabilize and settle down a little bit more.
-
-It's, I look forward to see what the docs are like in 2024.
-
-[40:04] **Mark Erikson:** I actually had a back and forth with Rick Hanlon from the React team in mid November where I was getting a little worked up and complaining that You know, the React docs really need to have more details about how React renders. You know, that's always been one of my biggest and most appreciated blog posts, is the article about React's rendering behavior.
-
-I actually got called out a little bit by Rick, who linked me to certain sections of the docs that actually have some of the information that I was complaining didn't exist. I had looked through some of the early betas of the docs, and to be honest, I hadn't really gone back and dug through them since then, and so there were definitely some pages that called out some of the specific nuances that I thought should be in there that I didn't realize had actually been added.
-
-Like even talking about kind of like the existence of like the render versus commit phase. It is sort of scattered through some of the different learning material pages. It's not like in one single start to finish usage guide or how this works page. But there is actually a lot more of that material in the current docs than, certainly in the old docs, and more than I had actually given it credit for.
-
-[41:22] **Carl Vitullo:** It has been a bit of a challenge to figure out how to stay on top of what changes are coming out in the docs. I note that the last blog post on react. Dev was in May. So, I think you can be a little forgiven for finding it difficult to stay on top of what changes have happened.
-
-I'm not even sure how you would. Because I don't think they get published as releases in GitHub.
-
-[41:45] **Mark Erikson:** Well, no, the React docs should still be a public repo, um, it used to be React. Js slash React. Js dot org, they might have renamed the repo, but the repo exists, so I assume I could watch the repo for PRs.
-
-[41:59] **Carl Vitullo:** That's a high noise source of input though, where's the bi monthly summary of here's all the stuff we've shipped. So anyway whatever. They got more, they got some more DevRel folks. We'll see, we'll see what's going on. Anyway,
-
-[42:13] **Mark Erikson:** cool. Lightning round.
-
-## ⚡️ RequesterImpairment (an IETF joke??)
-
-[42:16] **Carl Vitullo:** Lightning round. I don't quite comprehend the implications of this, but IETF, um, The task force that owns HTTP has put out a draft of an HTTP status code to report requester impairment.
-
-I don't quite know what that means. They talk a little bit about AI requesters.
-
-[42:38] **Mark Erikson:** It's a joke.
-
-[42:39] **Carl Vitullo:** Is it a joke? They put out a joke in December?
-
-[42:42] **Mark Erikson:** Look at the status code.
-
-[42:44] **Carl Vitullo:** RequesterImpairment 420. Okay, this is straight up a joke? It's a very serious looking joke.
-
-[42:50] **Mark Erikson:** Have you ever seen HTTP status code 418? I'm a little teapot.
-
-[42:54] **Carl Vitullo:** But that was released on April Fool's Day, like 20 years ago.
-
-[42:59] **Mark Erikson:** Yeah, I don't know why this one would have been released. But I'm pretty sure this is a joke of some kind.
-
-[43:05] **Carl Vitullo:** It smells like a joke. It's RequesterImpairment 420 Yeah. It smells like a joke, and I don't know how to interpret this. Maybe it's a joke.
-
-Move us on, take us away.
-
-## ⚡️ Jules Blom on FlushSync
-
-[43:18] **Mark Erikson:** A blogger named Jules Blom, who has put out a number of posts in the last year that talk about some very specific technical nuances of React rendering, which is a topic that I always appreciate. And so Jules put out a post recently that talks about a relatively new React API called FlushSync.
-
-And this exists because of the change in how React batches updates. Prior to React 18, React would automatically batch renders if you called set state more than once in an event handler, but it would not do it if you did it in some async function. And so React 18 switches it so that React now always batches any updates that occur in the same event loop tick.
-
-But there might be times when you need to force a render immediately right now after a given setState call. So it's flipping the default behavior, and so now you need a new escape hatch from that behavior. So there's a new API called FlushSync, which says, okay you've queued up one or more setState calls.
-
-Force React to actually render right now, and then continue from there. And I know Ryan Florence had a tweet about this recently, where he says he uses it instead of useEffect in a lot of cases. So you might have like a click handler that does a setState call. And then calls FlushSync to make sure it gets updated right away so that you can do some kind of like a focus or scroll change.
-
-So, this is a useful article talking about what it is and why you would want to use it.
-
-## ⚡️ React Fights You Can Have With Your Team
-
-[44:56] **Carl Vitullo:** Thank you, next. I like this one. It's a little silly. A Christmas post. React fights you can have with your team. I was just reading this and all of these are fights that I have had with my team over the years. So default versus named exports.
-
-Do you call a file in a, a feature folder index tsx, or the same name as the folder? How do you name props, regular functions or arrow functions? I, it, it was, it was just a, a, a great comprehensive list of all sorts of fights that I've had over the years on teams. So, appreciated it. Um, okay, I have a second one queued up here, so I'm just gonna run with it.
-
-## ⚡️ An interview with Kyle Mathews on Gatsby's story
-
-[45:33] **Carl Vitullo:** Um, there was a good podcast recently interviewing Kyle Matthews about building Gatsby. It just, just, it seemed like a very honest and open discussion of the lifespan of Gatsby from Inception to V2, V3, and Acquisition. Reactiflux and Gatsby share some ancestry. Kyle Matthews used to be pretty active here.
-
-At one point he had admin permissions over a subset of channels that Gatsby used as their official chat. So I have a soft spot in my heart for Gatsby. And it's nice to see some discussion of inside baseball, how did it work, how did it grow, why was it made. I, I, something I thought was pretty interesting is he explicitly talks about making it for himself for blogs and small sites.
-
-One of the big complaints is that Gatsby didn't really scale beyond those, so hearing him talk about how he made it for that for himself, it's like, okay, that kind of makes sense then. Yeah, worth a listen. It's like an hour long. It's a podcast. It's a reasonable time investment.
-
-## ⚡️ TanStack Router v1
-
-[46:41] **Mark Erikson:** All right, and last lightning round item is that the ever prolific Tanner Lindsley has released TanStack Router v1. I know Tanner has had a lot of opinions about Things like, how does a router integrate into a framework, type safety, and data fetching and loading.
-
-So, this, I could not sit here and list the differences between TanStackRouter and ReactRouter. But, Tanner has a track record of creating libraries that are very useful, very well thought out, and he puts a lot of effort into them. So, probably worth taking a look.
-
-## What will happen in 2024??
-
-[47:19] **Carl Vitullo:** And Mark, you had a great idea. For an end of episode discussion, what do we think will happen with React and the ecosystem in 2024?
-
-[47:29] **Mark Erikson:** The biggest one that I'm so very much looking forward to and excited about is the React Forget compiler. So the initial mentions of it were well over two years ago. It was kind of quiet. We got tiny little hints and a couple updates. You know, over the last year and a half. And then finally, late this year, we got a couple big updates from the team members who were building the Forget compiler.
-
-Sathya did a talk at React India, and then Joe and Mofe did a talk at React Advanced in London. It sounds as if React Forget is real, it works, it is being used in production at a couple of different metasites, and it sounds like the hard part And now it's the other hard part of trying to fully productionize this and make it ready.
-
-You know the overall goal is not just about It's not just about removing the need to have dependency arrays in your use effects and your use callbacks or whatever. It's also about actually optimizing when it's re rendering. And there's been lots and lots of talk about signals across the JavaScript ecosystem in the last two years.
-
-You know, lots of different frameworks are adopting signals. And the React team has said You know, we, we might end up making the use of signals as like an internal primitive, but we don't really think that they provide a lot of value as a user level piece of code. And so their approach is, let's build a compiler.
-
-And you write your React code exactly the same way you always have. You don't have to think about anything special. You don't have to use special value get, set calls. You just write your components with plain data and eventually, someday, This magic compiler will make things faster. And it sounds as if someday is hopefully relatively sooner.
-
-Obviously there's no actual release date. You know, the, during the talk at London, Joe and Moffay said it'll be available when we think we've got it fully productionized and are ready to support it. I'm hopeful that it will actually come out in 2024.
-
-[49:42] **Carl Vitullo:** I like that. Good prediction. Well, I don't know a prediction, but
-
-[49:45] **Mark Erikson:** Wishlist.
-
-[49:46] **Carl Vitullo:** Wishlist, sure.
-
-I have always taken an approach of no expectations. I prefer to just let the news wash over me and See, I think, I think I find predictions less valuable than responsive, being responsive to what comes out. Updating a mental model periodically. I'm very excited to see how server components continue to shake out.
-
-That's maybe a kind of a cop out answer, the obvious choice, but it's true. I, I, I, I think it's a pretty new paradigm for programming, um I just had my big rant earlier about respect for the core team and how they're pushing the industry forward. Yeah, I'm really interested to see how that continues to shake out.
-
-It's really cool to see momentum build. In the community, in the ecosystem. I think it's complicated, I think it's hard. I think 2024 might be when we hit critical mass on that and start seeing a lot more powerful applications of server components more generally.
-
-[50:51] **Mark Erikson:** another thing that will hopefully happen next year is another stable version of release of React.
-
-Because the current one is 18. 2, that came out well over a year and a half ago. You know, I've voiced my complaints about React's versioning strategy a number of times this year. They put out the blog post about the canary release idea, which has resulted in a lot of arguments about, well, what does it mean that this feature is stable for frameworks, not actually stable and usable by anybody else?
-
-And I think, it kind of goes back to what I said earlier about, Pre release versions. It is very true that for most developers, like even myself included, a fully supported, stable, semver backed release It might as well not even exist, both in people's minds and in the willingness of people to actually use certain features.
-
-So there's been a lot of debate and frustration over the way that like, Next is using pre release and experimental versions of React in order to implement things like the app router. And I'm very hopeful that we will actually get another stable version of React that Actually pushes things forward also in a selfish way because then it would actually have my source maps generation built in the latest Info that I have just trying to keep an eye on the update work team is actively talking about React 19.
-
-Andrew Clark has made a couple comments on Twitter I've started to see some PRs go through in the React repo that are actively starting to clean up deprecated and dead features. Um, they removed a completely unknown variation of how you could define components as a module object. A couple months ago, there's actually a PR up right now that would remove the legacy context system.
-
-You know, the old this. Context in, in class components. I would not be surprised if we don't get an 18. 3 minor release. And instead, the next stable release is 19. 0, with a number of deprecations and removals and things cleared out. Very curious if that would also finally include the better web component support.
-
-It was PR'd probably almost two years ago, and has been sitting in experimental builds. And has resulted in lots of people whining that it's not available yet. I would certainly hope React 19 would be out by this time next year. If and when it does come, I would expect it to be removing a lot of deprecated options.
-
-The question is, how long will it take to come out? And will there be any minor releases before that? I can also safely predict that the React subreddit and Reactiflux will continue to be flooded with questions of Should I use Next versus React? Should I use Next versus Remix? Should I use Next versus Vite?
-
-Should I use Redux versus Context? Da da da da da da da da da da.
-
-[54:09] **Carl Vitullo:** The never ending cycle of questions. Yeah, we're, we're going to be doing a, a thank you to the React core team soon before the end of the year. Years and years ago, we used to do an annual like end of year thank you to the core team, which was really lovely.
-
-And we just fell off and stopped doing it. So we're going to be trying to revive that now. And it's been six years since the last time we did that. Last one was in 2017. It was a good excuse to go back, pull up the web archive, and see how the communities have grown. So I pulled up like this the subreddit, the React. Js subreddit, Reactiflux, and Thackoverflow.
-
-And it was pretty wild. All of those have 10x'd in size. The 2017, there were 60, 000 questions on Stack Overflow. The subreddit was at 30, 000 members. Reactiflux was at 25, 000 members. And now, Reactiflux is at 220, 000 members. Subreddit's at 300, 000. And we've got 600, 000 questions on Stack Overflow.
-
-Just absolutely ludicrous growth. Literally 10x. On each of those communities, over the last six years. Pretty wild. React's taking over the world. Or has taken over the world.
-
-All right, well thank you everyone for joining us on this end of year, weird liminal space between Christmas and New Year's when nothing counts and nothing is real.
-
-We'll be back on the last Wednesday of January. Here in the live stage of Reactiflux or back in your podcast feed as soon as we can. With the end of the year this one might Come out a couple days late. We'll see. I'm not sure what my editor is gonna be up to. Ha ha. If you see anything newsworthy, definitely let us know in the Tech News and Reads channel of Reactiflux.
-
-We do source Links from there, definitely pull from discussion and things as well. Thank you so much for joining us. I'll see you next month.
diff --git a/src/transcripts/tmir-june-2023.md b/src/transcripts/tmir-june-2023.md
deleted file mode 100644
index 109e562..0000000
--- a/src/transcripts/tmir-june-2023.md
+++ /dev/null
@@ -1,391 +0,0 @@
----
-title: This Month in React (June 2023)
-date: 2023-06-28
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-
-
-[00:00] **Carl Vitullo:** Thanks for joining us for this month's, This Month in React, for June, where we recap and digest recent develop elements in the ever evolving React and web ecosystem. We are your hosts. I am Carl Vitullo. I'm a staff software engineer and community manager for Reactiflux.
-
-[00:17] **Mark Erikson:** Hi, I'm Mark Erikson. Most folks might know me as the maintainer of the Redux family of libraries, and my day job is at replay.io, where we're building a true time traveling debugger for JavaScript.
-
-[00:28] **Sebastien Lorber:** Hello, I'm Sebastian and I am known for Docusaurus as being the maintainer and also the creator of the This Week in React newsletter.
-
-[00:38] **Carl Vitullo:** Yeah, I feel like we've had a lot of news this month, so how about we jump into it?
-
-# StackOverflow Developer Survey
-
-- [Stack Overflow Developer Survey 2023](https://survey.stackoverflow.co/2023/)
-
-[00:43] I am starting off a little broad here. The StackOverflow developer survey for 2023 came out and I feel like it had a lot of, I don't know, this is just such a like seminal survey in the programming world generally. And I guess, from the survey I was seeing just how much of the programming world is specifically web and React.
-
-[01:04] So it's, I thought this was interesting to see. This is good to cover for, even though we, this is not specifically about React or Web narrowly, but Yeah, I mean, for example, they had a bunch of questions about what technologies you use and of the top 5, 3 of them are web technologies.
-
-[01:20] 65% of respondents use JavaScript, 38% use TypeScript, half use HTML and CSS. So a lot of good insights in here. Some good examples on hybrid versus in-person work, like only 16% of software developers are currently fully in person. Well, 16% of respondents to the StackOverflow survey.
-
-[01:40] They had some good salary information. US, UK, India. For a front end developer in the US, average reported salary was 140,000., Same title in the UK was 71, same title in India was 15. So one thing I love about this survey is just seeing, sort of a benchmark about the industry as a whole, or at least the portion of the industry that makes heavy use of StackOverflow, but always fun to see and definitely good things to read here.
-
-# Server Components
-
-- [Next.js App Router Update (dev server, docs, etc)](https://nextjs.org/blog/june-2023-update)
-- [Why do Client Components get SSR'd to HTML?](https://github.com/reactwg/server-components/discussions/4)
-- [Remix + RSC POC](https://twitter.com/ryanflorence/status/1663587026384584704)
-- [Redwood: All in on RSCs](https://community.redwoodjs.com/t/redwoodjs-next-epoch-all-in-on-react-server-components/4967)
-- [React WG - RSC from Scratch. Part 1: Server Components](https://github.com/reactwg/server-components/discussions/5)
-
-[02:08] **Mark Erikson:** Nice. Kind of a similar theme, so general big picture news. The biggest topic of discussion that I continue to see in between Twitter and Reddit and wherever else is React Server Components. And there's been a few pieces of information as far as technical updates and helping people understand how they actually work.
-
-[02:31] First off the NextJS folks put up a blog post that gave an update about the NextJS app router and its current functional status. Why they built it, how it supports incremental adoption. It's stable, but they are still working on improving it. They talked about some of the plans they have for improvements, like improving the speed of the local development server, working to make fast refresh faster using the the Turbopack build tool and getting that from beta to production ready.
-
-[03:07] They also talked about trying to improve the docs. They've done a lot of work over the last year to improve the NextJS docs specifically. We'll talk about this more in a little bit, so there really aren't, isn't any documentation about React Server Components in the actual React Docs.
-
-[03:25] The only real official documentation you can find is in next's documentation site. So the blog post talks about like, we're, we're working on that as well. There were a couple other pretty good related links. Dan Abramov has a discussion thread in the one of the React Working Group repos that talks about why client components get converted to html.
-
-[03:49] He also did a very long, deep dive thread, which to be honest, I still haven't even had time to read through where he tried to rebuild the function and some of the basic functionality of React Server Components. From scratch, and I've seen a lot of folks say that this was really helpful in understanding the mental model as well as the technical details of how Server Components work.
-
-[04:13] And I think I've seen a, a couple people try to take the information that Dan wrote in this article and turn it into tutorial videos as well. And then I know that a couple other React related frameworks besides next are looking into using Server Components, and that includes both Remix and Redwood.
-
-[04:37] And then there's at least a few other folks experimenting with Server Components in different ways. Daishi Kato, who's the maintainer of the Zustand and Valtio and Jotai libraries has been doing his own little spin on a server component based framework. So there's a lot of motion going on around the ecosystem in relation to Server Components.
-
-[04:59] **Carl Vitullo:** Yeah, definitely a lot of motion. I hadn't seen the Redwood discussion of Server Components. And I tried to check out Remix Server Components proof of concept, but it doesn't look like there are very many details there at all yet. That, you know, proof of concept tweet from Ryan Florence is just a, you know, it's just Lighthouse, like, cool, okay. I guess it works well, but what, like, what does it look like?
-
-[05:22] **Sebastien Lorber:** There is actually a few links that you can find on on GitHub with repositories where the, the implementation is being worked on. So you can follow this on on GitHub. I don't think it's Ryan Florence for working on it, I think it's Jacob Parish or something like that, that is working on on this implementation.
-
-[05:40] **Carl Vitullo:** Yeah, I guess that makes sense. If you're trying to follow along the implementation, tracking the GitHub directly is where, where that actually happens.
-
-[05:46] Yeah. More, more drama, more resources, more details trickling out. Server Components are definitely still actively evolving and I guess they probably will be for a while still.
-
-[05:57] **Mark Erikson:** We'll get to that part when we circle back around.
-
-[06:01] **Carl Vitullo:** Yeah. Cool. Yeah, I hadn't seen the React Server Components from scratch.
-
-[06:05] That's a, that's a really good resource. That reminds me of Dan Abram's talk. What was it? React in an alternate dimension. Looking at IE6, so definitely feels like he's trying to anchor the React Server Components conversation, sort of going back to fundamentals, like not chasing trends, not sort of saying like, "here's where the path has evolved. Here's the current state," but saying, "let's look back at what web development used to be. Let's look at what it is right now. Let's try and find a, not just a local maximum, but maybe a, you know, universal maximum."
-
-[06:38] I guess I appreciate that framing a lot. It's nice to not just be reactive and see this is what people have been doing recently, this is how the community and ecosystem are evolving, but really trying to go back and say, "okay, this is what we're trying to build. How does that make sense in the current moment, and how does it make sense in previous moments as well?"
-
-[06:59] So I I, I like that. You know, I, I've said that I defer a lot to the React core team because they have not let me down to the past, and I like that. I think that's a good framing and I feel pretty good about the direction that that suggests to me.
-
-[07:14] **Mark Erikson:** Dan's teaching style has always been very much from first principles, like first I will explain the concepts and why they matter and how we arrived at them, and then I will explain the technical details.
-
-[07:27] You can see that in the original Redux tutorials, you can see that in the rewritten React Dev website. And so, yeah, like I'm, I'm just now finally skimming that Server Components from Scratch article, and I can, I can definitely see that same mindset at work, which is good. Like I, I've always found it's useful to explain a problem and then explain the solution to the problem now that you understand why it's there.
-
-[07:52] And I, I think this is a really good post.
-
-[07:54] **Carl Vitullo:** Sebastian, you wanna take us off?
-
-# Skew Protection on Vercel
-
-- [Vercel - Introducing Skew Protection](https://vercel.com/blog/version-skew-protection)
-
-[07:56] **Sebastien Lorber:** Yeah, I wanted to talk about something Vercel released recently. They called it Skew Protection. And I found it interesting because somehow it solves a problem that I had in the past. Where you deploy your new version of your software and then when someone loads a, a website in the browser, they don't always refresh the page, so they, they may have a stale client app locally, and you deploy a new server version, and then there is a mismatch between the server and the client. And somehow Vercel released something recently that permits to, to mitigate this problem.
-
-[08:33] So the idea is that if you have a still client running locally, it'll try to use the server code that match that, that client version. And they can do that because they do some routing on on their infrastructure based on HTTP headers. So the idea is that if you do a breaking change during a deployment, it might not generate errors and they just added this to the last NextJS version. So you can just add the flag to the config and this will be enabled by default.
-
-[09:07] **Carl Vitullo:** Skew protection. Definitely interesting. Definitely a problem I have run into in my career. This has been a problem I've especially noticed on Netlify because they only serve the assets for the most recent deploy.
-
-[09:19] So how I've seen this present is somebody keeps a tab open. You know, the app we have shipped is split into multiple bundles. So then they, they can click around, they can keep navigating within the app for all of the JavaScript they've already loaded. But then they try to go to a new page. It goes to fetch the bundle, the bundle 404s, and then something breaks catastrophically.
-
-[09:41] So how we fixed that on teams I've been on in the past was we set up a 404 javaScript bundle that would just do, you know, browser reload, which it worked. It's fine. It's a little janky. That's led to situations where like if we have state that somebody's entered into text inputs or whatever, that gets lost.
-
-[10:00] So happy to see a more graceful implementation here.
-
-[10:04] **Sebastien Lorber:** Yeah, what is nice, some of our examples just showed the case where you call an api, like you submit a form or something like that, and there is a mismatch between the payload and the, the serverless function. But apparently it also works with the static assets.
-
-[10:19] So if you have a code split app with a prefetching and basic code loading, you should be able to to, to fetch the appropriate bundle to the appropriate immutable deployment. And if you keep your tab open you have like 24 hours of transition, so that you can still access the older deployments.
-
-[10:39] This also present some security concerns apparently because for example, if you have a vulnerable deployment in the past this gives the ability of data here to eventually keep using it, using using HTTP header. So there's a trade off.
-
-[10:54] **Carl Vitullo:** Huh, interesting. Okay. Yeah, a 24 hour grace period for refreshing a tab seems a lot better than nothing.
-
-[11:02] I had always wondered why this wasn't a problem that was solved at the level of the hosting provider, because, you know, it, to me it looked like kind of a bug. You know, I, okay, yes, immutable deployments, but like, it's not that those old assets don't exist anymore, it's just they're not the freshest.
-
-[11:17] So, you know, when I, when I've controlled a server in the past, like I only cleaned up old artifacts every now and again. So, yeah. Interesting though. Cool to see a hosting provider bring it.
-
-[11:28] **Sebastien Lorber:** If you use Netlify for example, there was a way to, to mitigate vita this as well. For example, you could use the net cash and you can keep the previous static deployments in your cash and then merge them with the new deployments so that you get, somehow you keep the old assets and then add the new assets to provide the old assets. And then both remain accessible. So this is not ideal, but at least it was a, a solution.
-
-[11:57] The problem is that you sometimes had to clean up the deployment because it's it would keep growing forever if you don't do the cleanup someday.
-
-[12:05] **Carl Vitullo:** Never want unbounded growth. Cool. Well, I'll take us on.
-
-# React Native 0.72
-
-- [React Native 0.72 - Symlink Support, Better Errors, and more](https://reactnative.dev/blog/2023/06/21/0.72-metro-package-exports-symlinks)
-- [Fabric Renderer](https://reactnative.dev/architecture/fabric-renderer)
-
-[12:09] **Carl Vitullo:** So React native had a new big version put out, version 0.72. The highlights were symlink support in Metro, better errors and developer experience, and some more. It looked like a lot of the "more" is sort of finer points related to. A new architecture. They, you know, they had New Architecture in title case all over this post.
-
-[12:35] So it looks like this relates to the new architecture and React Native, Fabric, which I guess is a new renderer, new core technology for how the apps get put on the phone.
-
-[12:48] **Sebastien Lorber:** Fabric is a new renderer for the new architecture. There are multiple pieces to the new architecture and Fabric is the, is the new renderer.
-
-[12:57] **Carl Vitullo:** Okay. Yeah, so, you know, my, my reading of this news here, they have a new interop layer that makes that new architecture more usable for, a wider range of people who are on older versions of React Native. I saw that it's, you know, they're intentionally not doing a hundred percent coverage right now, just focusing on common issues. Common compatibility. Yeah. Cool. Awesome to see it get better developer experience because that's always been my largest pain point when trying to use
-
-[13:25] **Sebastien Lorber:** it. And also the, the new metro features will be super useful. For example, the symlink support was requested for years. I think it's maybe the oldest issue in React Native.
-
-[13:37] So we are happy to, to finally have the ability to, to use a manual report without having to, to plug any extra config to make it work.
-
-[13:47] **Carl Vitullo:** Yeah. Very nice. Very nice. Yeah, and I see some other little smaller developer experience changes, like not failing on style errors. If you give it a bad style prop, it doesn't blow up anymore, so that's nice.
-
-[13:58] You know, low priority errors not interrupting your workflow is always good.
-
-# Social Dimension of React Server Components
-
-- [Is React Having An Angular.js Moment?](https://marmelab.com/blog/2023/06/05/react-angularjs-moment.html)
-- [Related tweet form Joel Hooks](https://twitter.com/jhooks/status/1670147458360569856)
-- [Next canary broke Apollo and RTKQ](https://github.com/apollographql/apollo-client/issues/10974#issuecomment-1594894341)
-- [React-Query trying to add “use client” and struggling](https://twitter.com/TkDodo/status/1673401744087195657)
-- [Seb describes the `”react-server”` export condition](https://twitter.com/sebmarkbage/status/1673419412144025604)\*\*
-
-[14:02] **Mark Erikson:** Okay, Carl, please prepare to begin pasting and links for this one.
-
-[14:06] **Carl Vitullo:** Uh oh. Uh oh!
-
-[14:08] **Mark Erikson:** Okay, so a minute ago we talked about the kind of the technical news around React Server Components, and then there's the social aspect, which is that there is still a ton of confusion and concern in actual real, no kidding pain points around the rollout of Server Components.
-
-[14:30] The behavior of next. React's versioning and how existing libraries in the ecosystem are supposed to inter-op with all this stuff. , I've, I've been collecting a whole bunch of links and I've actually been forwarding a lot of these over to members of the React team to give them an indication of, "look, these are all the problems people are experiencing, or at least feeling right now. You need to be aware of these so that you can figure out how to actually like, improve the marketing, improve the docs, and address the problems that people are having."
-
-[15:10] So let's, let's roll through a few of those. There was a post that came out entitled, " Is React having an AngularJS moment?" And the background on this for people who weren't around 10 years ago Angular JS 1 was very, very popular for several years, and then the Angular team announced Angular 2, which was effectively a completely different framework, but just using the same name.
-
-[15:39] And the initial announcement was that there would be no migration path to go from Angular 1 to Angular 2. And this killed much of the Angular ecosystem at the time, and it coincided with React coming out. And so in 2013, 2014, a lot of teams said, well, if we're gonna have to rewrite our app anyway, let's just switch from Angular 1 to React instead.
-
-[16:05] And so, a number of people have made this comparison that the rollout of Server Components is like an Angular 1 to 2 transition for React. Now, the React team has pushed back on this idea and pointed out that, you know, we're, we're not killing any of the, the existing client component capabilities. We're we're adding more functionality to React.
-
-[16:31] So in some very real ways. The comparison is a no, but it's also true that there is no migration path that I've seen right now to add Server Components to an existing app unless you're using Next and you start switching over to using the app router, et cetera. So there is a very real feeling of this shiny new thing is being dangled in front of us.
-
-[16:59] And we're being encouraged to use it, and yet many of us cannot. So there's, there's a feeling of being blocked there, even if the technical details are, are somewhat in between and hazy. So the article came out, and then there was one specific, Twitter thread, started by Joel Hooks from, from Egghead.
-
-[17:20] Who was discussing it. And that led to a ton of sub discussions. And I, I got involved in that thread halfway down and actually ended up having a bit of an argument with one of the React team members about, you know, things like defaults matter and, you know, there's, there's missing docs for a lot of these things.
-
-[17:39] And a lot of other people were participating in that thread as well. And it's just an example of the kinds of, Frustrations that I'm seeing echoing throughout the entire ecosystem. So that's one side of things.
-
-[17:53] Another is that a recent Next pre-canary test release broke a couple libraries like Apollo client and React Query, and they reverted that particular change, but the implication and that I'm getting out of it, is that libraries that want to be able to interact with Server Components in some way, basically need to add an entire new bundle file to their packages and specify a new export condition called React Server, so that when the React server component bundler tries to load your library, it finds an extra special version of your library that has all the client code stripped out so that it's not sending extra pieces over the wire.
-
-[18:46] The problem is this means a whole lot of extra work for library maintainers like us. And while there's been some discussion about this on GitHub and Twitter, none of this is actually documented yet.
-
-[18:58] So Lenz Weber, who works on both Redux Toolkit and Apollo client, and myself and Dominik Dorfmeister of React Query have all expressed our frustration with, you know, the fact that our libraries are now breaking and we're being forced to do this extra work, but there isn't even documentation for it yet. So there was, there was a very long discussion thread over in the, the Apollo repo There's been discussion on Twitter.
-
-[19:26] Dominik has a PR up where he is trying to add this new export condition to React Query and Sebastian Markbåge is trying to give some advice. So it's, it's, it's a very frustrating time for library maintainers as well. And then on top of that just within the last week or so, there's been a lot of discussion about versioning.
-
-[19:48] So the current stable version of React is 18.2, and it's been out for over a year, and there's no indication of when an 18.3 or even an 19.0 will come out. Well, it turns out that a lot of the functionality that Next uses in the App Router only exists in what's known as these Canary builds of React. So React has a bunch of internal feature flags.
-
-[20:17] And they put out the stable builds, which have a lot of those feature flags turned off. There's the narrow builds or in experi in the daily experimental builds, which have many of these feature flags turned on. And so if you're using the app router next actually ignores whatever version of React you have listed in your package, J S O N.
-
-[20:39] And instead they use one of these canary builds of React. That has the extra special functionality. And the problem is that right now there is no documentation whatsoever on what features are even turned on in one of these canary builds. And there's no way for a library maintainer to know, okay, well you're reporting a bug with our library, like our, our, our library, but we don't even know what version of React you're using.
-
-[21:09] And, and or we don't know what features we should expect to be available in React when you're using like next in the app router. So there's both frustration from maintainers where we don't know, like the React team isn't documenting, here's what's available for you to use. What are the stability of these APIs?
-
-[21:30] What, what canaries have, what features turned on? And then there's also an argument about (exhale) React wants to be able to try out these new features. A lot of these features are expected to be used by frameworks like Next and Remix. And so the framework can kind of like add a layer of protection on top of those.
-
-[21:52] And even if the features aren't a hundred percent done and they change a little bit over time, the framework can put in effort. To keep them from breaking users applications, but what does that mean in terms of semantic versioning and publishing the libraries? So there was, there was a lot of debate about what is the right way for React to put out these features so people can try them out versus semantic versioning versus framework usage.
-
-[22:22] So it's, it's all very, very confusing right now. I will say that I've, in addition to all the public debate, I've, I've had some messages on the side with some React, some, some kinda like non-public React team members who are explicitly intending to work on core documentation for Server Components and wanting to work on.
-
-[22:46] How to docu, like how do we document these canary builds? Can we do something similar to like the TC 39 stages process where we say, you know, we've got these 15 features. Some of them are just an idea. Some of them we have a proof of concept. Some of them are already ready to go and hopefully be able to like apply that as like a, a matrix or a table or something to all the different canary builds maybe.
-
-[23:12] But Right. As of right now, none of that information exists, and it's very frustrating.
-
-[23:17] **Carl Vitullo:** Yeah. Right. And I, I think another aspect that you didn't even mention in all of that (laughter) is that like, it's already so hard to publish a library correctly because the ES module ecosystem has been such a nightmare.
-
-[23:33] **Mark Erikson:** Oh, don't even get me started.
-
-[23:36] I, I was flying back from React Summit a couple weeks ago. I've been threatening to write a blog post for the last few months about, look, I've been suffering through trying to convert the Redux libraries to e sm. I'm finally going to write, I'm going at some point, I'm going to write down all the stuff I've learned and tried and bang my head against.
-
-[23:53] So I wrote half the blog post on the flight back. It's 4,000 words long, and I still need to sit down and write the other half of that. And I even had the redwood folks ping me and say, Hey, you've, you know, stuff, something about this e sm transition, right? Can you help us? I'm like, I'm not sure that I'm the person to help with this.
-
-[24:13] **Carl Vitullo:** You're the expert, Mark.
-
-[24:14] **Mark Erikson:** No-oooo.
-
-[24:16] **Carl Vitullo:** (laughter) yeah. So I mean, it's already. Very difficult because the ecosystem ha is still reeling from the effects of the last major, you know, bifurcation of package authoring. I guess connecting this back to what I was talking about earlier with the StackOverflow and representation of React as a, you know, portion of the overall tech world and you know, it's something, it's like 60% of respondents are using React or something like that. So like the tech world is enormous. React's influence on it is enormous. The ES modules nightmare is still not over.
-
-[24:54] **Mark Erikson:** Oh, it's still going on, trust me.
-
-[24:56] **Carl Vitullo:** Well, you know, Mark, maybe you can end it finally at long last by finishing your 8,000 word blog post about how to, how to integrate it correctly.
-
-[25:04] **Mark Erikson:** (ironic laughter)
-
-[25:06] **Carl Vitullo:** (real laughter) But yeah, so, I really feel like your, your frustrations here around trying to be a library author, dealing with this transition gracefully and correctly, and feeling like there's no good, like, like there is no way to do so, like, it's an impossible path. Yeah. That's, that feels very real.
-
-[25:25] **Sebastien Lorber:** I, I don't think it's bad for Vercel and NextJS to use the canary version, but the problem is, maybe it's just a documentation problem, I, I mean, it's a good way for them to, to have a quick feedback loop and have some adoption somehow.
-
-[25:40] It reminds me of what we had with Docusaurus too, you know, that it took a long time to release. And the fact that the community adopted the alpha versions gave a lot of feedback because we had a lot of download on, on this version, and many used it in production, including Redux, I think.
-
-[25:59] I know that it produced some pain because we did some breaking changes, but at the same time it provided a ton of feedback, that permitted to refine things. There's a trade off for the NextJS team to, to find between being stuck, not being able to reiterate fast because their software has come somehow, too related to, to React new features to evolve independently. So they need to iterate on, on both of them at the same time.
-
-[26:25] And. If they do that, then the community is a bit confused because the two versions are related and not everything is properly documented on the React side. And if they don't do that, they will be much slower. For example if they need a, a React core feature in to, to do something in NextJS.
-
-[26:47] This may mean that we need a new version of React and Uneven NextJS can use it and uneven we can get feedback because the community is using the new version of NextJS That is using the new version of React. It's a much longer feedback loop, and it's not good for the community to take, to have things, being slower. So, I mean, if it's a bit more painful in the short term, I think it's better to, to have this quick, , feedback loop somehow.
-
-[27:16] **Mark Erikson:** No, I definitely agree with that. I'm like, as a library author, I'm very sympathetic to, like, I've made changes I want people to try it out and, and actually give us feedback. I, I wish we got feedback for the Redux office in beta. But the, the fact that there is no documentation on what any of these, like what these new features are and which Canary build actually have certain features turned on is, is very frustrating.
-
-[27:44] **Carl Vitullo:** You know, like, okay, bundling a library is difficult. Publishing it correctly so it can be consumed is difficult. It seems very frustrating, but it does make sense to me that like the documentation for that, It's not stable yet.
-
-[27:56] **Mark Erikson:** Nonexistent is the problem.
-
-[27:59] **Carl Vitullo:** It's not surprising to me that the documentation for that bundling and publishing concern is not existent. It's confusing to me that the, that there is no documentation for what feature flags are enabled in a specific canary release. Like that seems like a very routine part of publishing a canary package. Like if you can't, if you don't know what's in it, how can you give feedback about it?
-
-[28:20] So, I guess that suggests to me that they, that there's a pretty heavy reliance on like, backchannel communications. And so, you know, the, the 10 people who participated in creating this canary release, they already know what's in it, so they don't need the documentation.
-
-[28:34] And so it feels like that's who the audience for these canary releases are. The people who are already in the room.
-
-[28:40] **Sebastien Lorber:** When you say feature flags, do you have a particular feature in mind that could be activated in the canary?
-
-[28:47] **Mark Erikson:** Well, oh yeah. Like, like the, the `use` hook.
-
-[28:50] You know, the, the React team published this RFC about this new use hook that's supposed to let you unwrap promises like a year ago. And the use hook then, or the use RFC mentions an upcoming cache or an upcoming RFC for some kind of cache component or API and says more details will come later. And the use RFC discussion, 95% of it was, well, people don't like the name, slash what kind of value are you allowed to pass to this either now or in the future?
-
-[29:22] And it went silent. And so as library maintainers who would like to integrate with suspense? Our assumption was, well, nothing is happening with this RFC at all. And then Next comes out with this in the app directory, and they, and suddenly they're telling us that, oh yeah, the use hook is ready to go. You like we either we use it internally or you can do something with it Next. And something something.
-
-[29:45] And we're like, wait, what you're, you're telling us that's usable? What about the cash thing? That never materialized. And, and so like we, we just have no idea where things even stand with that stuff.
-
-[29:58] **Sebastien Lorber:** I understand that at, at the same time, somehow the, the hook is not documented in NextJS also, as far as I remember.
-
-[30:06] For the end user, they are not supposed to, to even use it. So the end user, the app developer shouldn't care about if the feature is enabled on the direct canary flag or not, because, this is used only internally. So the problem is more that you as a library author, can't try the new things because they are not documented.
-
-[30:29] But I, I don't think it's a problem for the majority of users. It's more like that, you can't start working on, on the new cutting edge things now because you are, you don't have the same back channel with the React team. So, I, I see some auto, two different problems. It's one for framework authors and library authors, and another for the end user.
-
-[30:52] I don't think adopting NextJS With Canary release for the end user is a big deal today, apart that there are a lot of bugs that are reported, but they will be fixed. But the, I don't think the end user need to know much about all these new things that are not documented.
-
-[31:10] **Mark Erikson:** Yeah. The, the flip side is that we, we do see a lot of our, our users asking like, you know, can I use Apollo React query, RTK query with suspense?
-
-[31:22] And there's clearly a lot of interest in doing that, and we really don't have an answer for how you can do that yet.
-
-[31:29] **Carl Vitullo:** I have one more thing I wanna pull in. Sebastian posted a very short little Twitter thread. I'll just read some snippets from it.
-
-- [Sebastian Markbåge, "Who owns the direction?"](https://twitter.com/sebmarkbage/status/1673767392369844236)
-
-[31:36] "When a community of consumers grow large enough, it's interesting what happens with ownership. I think there's an argument to be made. It's that at some point the community bought into something and you can't change that from underneath them. They own what they bought into. From that perspective, if we as maintainers want to go a different direction, we should have given it a different brand, even if it's backwards compatible."
-
-[31:53] I think that's very directly talking about all of this React Server Components drama and positioning, he posted those yesterday, about 24 hours ago. I, I'm looking forward to seeing where that may have echoes on. How the React Core team is thinking about React Server Components.
-
-[32:13] And tying it back to, you know, where we started on this with comparisons to Angular 2. Like, okay, maybe this is not an Angular 2 moment for React, it is fundamentally backwards compatible, they are engaging with, you know, maybe not engaging perfectly, but they are making good faith efforts to include stakeholders in the conversation. Yada, yada. But I think this is maybe an early signal of a change in approach and yeah. Interesting to see how that shakes out.
-
-[32:41] Okay, now we can move on. We've beaten it fully into the ground. Sebastian, you wanna introduce our next link?
-
-[32:47] **Sebastien Lorber:** Yeah, it's a quick one. I, I noticed that we are both on the jury of, , React Jam, so I didn't know, but, , that was a happy surprise.
-
-[32:57] So this is a contest where you create a game with React. And I think it it'll be nice if the Reactiflux community wants to participate. So we'll be happy to review your React games in I think next month maybe.
-
-[33:13] **Carl Vitullo:** That's a good call out. Sebastian and I are both judges for a hackathon around developing games using React and web technologies.
-
-[33:22] I think it's happening on July 20th through 30th, so it's 10 days long. As judges we will be given the, you know, I think it's gonna be 10 candidates and then we grade them. I'm excited for it. I think it'll be fun. We've done a couple of Office Hours and interest in video games has been a very common theme on what got people interested in programming.
-
-[33:43] So if that's you, if you are interested in developing games yeah check out React Jam and maybe you'll have me and Sebastian play your game.
-
-[33:52] **Sebastien Lorber:** Yeah. (chuckles)
-
-[33:53] **Carl Vitullo:** Cool. My, my next link here, just a kind of small update. We talk a lot about Next and I feel like Remix maybe gets a little bit short shrift, but I see that they've got a, a new V2 development server that has some relatively large changes to the, some of the core assumptions around Remix.
-
-[34:12] Most notably, it looks like this totally swaps out the semantics around routing. The big comparison that I saw, you know, front and center of this announcement was previously Remix, inferred what routes your pages were on based on the folder structure, with, you know, templates and wrappers and things like that.
-
-[34:33] Now that is purely based on the file name. So instead of the folder hierarchy being reflected in the routes, it's Using. A different mechanism for determining conceptually what's a folder, what's what looks like a folder in the url. That's a pretty big shift.
-
-[34:48] I am interested to see them roll this out because it is such a large change to the everyday development experience of using Remix. So yeah, and seeing like a sub component of a framework, being given a new major version is interesting to me. We just talked a lot about Server Components and the versioning and the struggles of rolling that out.
-
-[35:11] So here's a different example. Smaller, you know, obviously Remix is inherently a subset of React usage, so it, the, the ecosystem is inherently smaller, but yeah, interesting to see another approach to making a major revision to floor behaviors.
-
-[35:28] **Sebastien Lorber:** It's quite interesting that they have implemented future flags to enable V2 features in Remix version one.
-
-[35:36] And I've also seen this this new flat routing convention that they implemented. There also great article that already tried to use this new feature about the ability to create somehow your, your own Remix routing convention.
-
-[35:53] So the, the idea is that you can create your own convention, read the files on the file system, and then eventually create the route you want for that file system secure. And so this gives a lot of flexibility. On Docusaurus, we already have a quite similar thing.
-
-[36:09] We have a concept of autogenerated sidebar. And it gives the ability also to, to create somehow a tree. And we give the, the ability to customize it.
-
-[36:20] Also, they recently released the, the last version of Remix with dev server version two. So as far as I understand, I think the idea if I remember correctly, is that if you change code in the Remix loader, you will also have the hot reloading experience that you expect. While it was not the case before.
-
-[36:41] **Carl Vitullo:** Nice.
-
-[36:41] Before we jump into Lightning Run. So, Sebastian, do you have more links? You wanna do a full discussion on?
-
-[36:45] **Sebastien Lorber:** Yeah, I think it's worth mentioning Panda CSS. It's a new CSS-in-JS solution, , that use a static analysis to, to do many things with with no runtime. Actually, I'm not sure it's completely without any runtime. I think I read there is a very little runtime, but I'm not sure. Now today, the, the devs are like tailwind, css a lot. And there are good reasons for that because you can copy paste code easily and you can also delete code quite easily and, and things keep working.
-
-[37:18] So this is a very interesting property. At the same time, Tailwind CSS get a lot of criticism for, for the very long class names. It looks a bit messy for people that don't approve to, to this way of thinking. And Panda that CSS could be a, a greater alternative to, to Tailwind. It looks quite interesting and it's from the chakra UI team.
-
-[37:43] I think the Quik framework is also trying to adapt it because they are building integrations and making it work in Quik already. So I think it's a tool to follow and we'll see how the community adapt it. But it looks like like one of the most promising CSS-in-JS solution today.
-
-[38:04] **Carl Vitullo:** Cool. Very neat. Oh, I just opened the webpage and the CSS has broken. Haha, not a ideal. Yeah. Interesting though. It's been a, it's been a minute since we've had new CSS-in-JS strategies come out, so I'll have to dive in compared to this and. See what it's introducing.
-
-[38:21] Cool. Okay. Let's go to, let's go to a lightning round. Mark, take us away.
-
-[38:27] **Mark Erikson:** Okay. Two things real fast. One is that ever since function components came out, there were a couple things that they could not do that class components could. One of those was defining an error boundary to catch errors that are thrown while your component is rendering.
-
-[38:44] You still had to use class components to write one of those. There is a PR up that adds a new catch component to React that would basically eliminate the need to use class components for error boundaries. I haven't looked in detail at the api, but there is some form of early EPR up for that.
-
-[39:03] So hopefully we'll get that in the next meaningful release. Also, I had filed an issue a couple months ago. Saying that as good as the new React docs are, they really need to add a page on how to use TypeScript with React and Orta Therox, who's been very involved in the TypeScript website docs just put up a PR that adds that page.
-
-[39:27] And I, I skimmed it right before this, this meeting, and it looks fantastic. So I'm, I'm very, very excited to see a React Docs page saying, here's how you use TypeScript with React.
-
-[39:39] **Carl Vitullo:** Definitely a frustrating experience a little bit. I feel like every time I come back to it after a, a little while away, I need to find some cheat sheet to be like, wait, what am I supposed to use? What am I not supposed to use?
-
-[39:50] So I guess that segues nicely into another one, but React.FC is no longer viewed as an anti-pattern for typing React components. Nice to see that, and nice to have documentation on how to use TypeScript with React. Cool.
-
-[40:05] Sebastian got any lightning rounds?
-
-[40:07] **Sebastien Lorber:** This week in the React Native ecosystem we had we saw a lot of quick demos of running the latest version of React Native on VisionOS the SDK for Vision Pro from Apple. And I found it interesting. I don't know how it works exactly, but apparently the, the React devs had fun with it, so it's already working.
-
-[40:28] I know it's it's already working for, for Flutter too, so maybe it was a simple thing to do, I don't know. There are also pull requests to, to add a support for vision or in Cocoa Pods. So I guess it'll become easier to, to add support for our VisionOS in the future in React Native applications.
-
-[40:47] **Mark Erikson:** I ran across a website within the last couple weeks called the React Handbook. And I haven't even had time to go through it fully in depth, but it's, it's like an overview and guide to the React ecosystem. Common problems like state management and data fetching and it tries to give some advice on what libraries to use and how to work with things.
-
-[41:09] And I had actually tried to, to get a similar kind of ecosystem overview guide website started a couple years ago. And I, I put up a proof of concept page, had some discussion about what I wanted this site to be, but I never got other folks in the community to spend time helping fill out the content. So this React Handbook looks very similar to the kind of idea and the kind of resource that I wanted to help build for the React community.
-
-[41:37] And I'm actually still supposed to talk to the primary author of this site about, you know, here's some of the ideas I had and maybe we can like, sort of join forces and help build this one out more.
-
-[41:48] **Carl Vitullo:** I know it's lightning around, but that also reminds me of us of our Reactiflux learning page, which has, which you curated with a ton of resources. So yeah, looks like a good resource.
-
-[41:59] My next lightning round Chrome for testing, reliable downloads for browser automation. Browser automation's really tough. Puppeteer kind of sucks. Playwright I hear is better. Cypress I have used successfully, but have always run into difficult edge cases, so having a blessed browser version specifically for testing. I see this is titled Chrome for testing. Like heck yeah. That's awesome. This is possibly an absolutely enormous level up for the testing ecosystem and maybe we'll start getting real movement on problems like visual regression tests, which I've seen probably a dozen attempts at companies trying to solve that problem over my 10 years as a web developer.
-
-[42:42] **Sebastien Lorber:** Quick link would be shadcn UI, I don't know to pronounce Shadcn, but You probably heard of this trending library recently. It released recently a new CLI that permits to bring a great developer experience on top of the React component, collection because it's not a library, it's a collection of Tailwind and Radix components.
-
-[43:05] I was quite impressed somehow in the beginning I didn't understand really the value of this library because somehow it looks like just a registry of of code that you can copy paste. Somehow it's bringing a CLI to, to be able to update the components, eventually use artificial intelligence features to it so that you can type a prompt on the CLI and it'll update the component according to what you, you say you want to do.
-
-[43:33] **Mark Erikson:** So at my, my, I, as I said earlier, my day job is working for Replay io and we're building a time traveling debugger for JavaScript. And we just announced something we've been building for the last six to eight months called Replay for test suites.
-
-[43:48] And the idea is that, You know, lots of companies have Cyrus or playwright tests. You run them in CI, but often either they flake, you know, they, they fail unpredictably 10% of the time. Or if a test fails in CI, you have no way to go debug what happened to that test. And so what we've announced is that we have the ability to change your test running setup to record all the tests that occur. And then if a test fails, you can open up the recording and time travel, debug that recording. So we, we, we just announced it we're, we're doing a wait list thing. We're gonna be doing some, some onboarding of teams to, you know, try it out and make sure that what we've built actually works.
-
-[44:36] But I'm, I'm really excited about this. Like, the amount of time I've spent trying to figure out why end-to-end tests are failing is absurd. And we're talking to companies that, like, they routinely waste tens of thousands of dollars on Amazon costs when tests fail and they have to go rerun the whole thing.
-
-[44:52] So I'm, I'm excited for something that will help, help teams fix their tests and run them consistently. Something else that I've been doing myself. So earlier this year I, I built our own, our integration of the React dev tools for Chrome by doing backend post-processing of the recordings to extract the data.
-
-[45:18] And we have officially turned that on. And just a week ago I shipped a major new update for it that actually improves on what you can do with the reactive tools browser extension, so the real React extension in the browser. If you record a or if, if you're looking at the website of a production app, you're going to see minified component names.
-
-[45:44] And what I've figured out is using time travel debugging, I can go look up the original files and find the original component names and show those to you when you debug a React app in a recording. So you can go from, you know, minified names like xz to the original name, like to-do list item in the recording.
-
-[46:06] So I'm really excited about that. And then just yesterday I was hacking on a proof of concept feature that would be able to to look at a React and Redux app recording and pull out information like, here's all the times your selectors ran, here's how long it took to update the ui. Here's like, which selectors were expensive, and hopefully give you like some performance optimization information.
-
-[46:32] **Carl Vitullo:** My last lightning round link here Vitest 1.0 roadmap has been shared. I'm using Vitest. I think it's great. I enjoy it. It's very quick. Runs my tests.
-
-[46:43] I'm very happy with it. I was always a little frustrated with Jest and it's, you know, parallel configuration. Just one more thing to configure and set up. Cool to see it have a roadmap for getting to 1.0. Excited to have that land.
-
-[46:55] **Sebastien Lorber:** Yeah. So my last link will be the Docusaurus version three Alpha.
-
-[47:00] So this is what I've been working on in the, in the last month, and it includes MDX 2 and React 18 finally. And So if you use the Qru, I'd be happy to, if you can try the, the Canary versions and. And give me feedback if it's working fine or if you have any bugs, then I would be happy to help you do the upgrade if you have any trouble.
-
-[47:25] **Mark Erikson:** Oh, nice. We'll have to carry that out for the Redux docs.
-
-[47:28] Okay. Last item I've got is a whole slew of updates for the Redux libraries. So we've published Redux Toolkit 2.0 Beta, which ha Has some small breaking changes to remove deprecated options. It has improved TypeScript types.
-
-[47:43] It has several new features like some reducer injection and other stuff. I don't have an ETA on when this will go final because we're trying to update all of our libraries, which with a bunch of stuff simultaneously. Actually, the other, the other big thing we're doing with a lot of these is trying to update the packaging to support better ES module common JS interop, which as we mentioned earlier, is a royal pain.
-
-[48:10] But the idea is we're gonna publish major versions of all the Redux related libraries simultaneously. And so I'm juggling like 15 different things in my head trying to keep track of what needs to be done sort of related to that. We just shipped React Redux 8.1, which has dev mode warnings if your selectors accidentally return new values when they should't, which is a common mistake that we see people make.
-
-[48:37] So you can think of it, think of it as kind of being similar to React running, use of effect twice to try to catch mistakes. I've got a PR up that will become React Redux nine Alpha. I don't have it merged yet because there's, there's a couple different packaging issues that I, that I ran into that I need to solve there.
-
-[48:56] And then I'm, I'm on business travel this week, but literally on the flight out here on Monday, I was experimenting with some proof of concept changes to how React Redux manages subscriptions and updates the ui. Sort of inspired by signals or observables. And the goal is to hopefully make it more optimized and update the UI faster.
-
-[49:23] I spent four or five hours hacking on the flight and I at least got something running that passes tests at the moment. But I still need to actually do a bunch of performance testing and see like, okay, this thing that I built, is it actually any better or not? If it works out, it would probably show up in React Redux version nine as a new opt-in hook called use Tracked Selector so that all the existing hooks would, and, and you know, components would work exactly the same as they have, but if you want to make use of this new functionality, there's an additional hook that you could use, which would be more optimized.
-
-[50:05] We'll, we'll see if this actually works out or not.
-
-[50:08] **Sebastien Lorber:** Yeah, I have another one. There is a new AI framework called AI.JSX, and it's using JSX as a composition block and is meant to be integrated in React applications, but it's not a React renderer. So I don't know exactly how it works, but this look like quite interesting to, to study.
-
-[50:30] **Carl Vitullo:** Cool! Okay. Thank you everyone for joining us. One more this month in React. Hopefully we're helping you keep on the cutting edge of the React and web ecosystem. Thanks so much for joining us.
-
-[50:40] Keep an eye out. Next week I'm gonna be talking with a conference organizer for React Rally. Yeah, excited to talk, talk with him. It's a great conference. See you guys next month.
-
-[50:50] **Sebastien Lorber:** Thank you. See you. Bye.
diff --git a/src/transcripts/tmir-march-2023.md b/src/transcripts/tmir-march-2023.md
deleted file mode 100644
index 67956f1..0000000
--- a/src/transcripts/tmir-march-2023.md
+++ /dev/null
@@ -1,514 +0,0 @@
----
-title: This Month in React (March 2023)
-date: 2023-03-29
-time: 10am PT / 5PM GMT
-location: Q&A Channel on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Matt Pocock as we break down This Month in React. A lot of news this month, with a major progress update from the React core team, TypeScript 5.0, and TC39 meeting news. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Matt Pocock](https://twitter.com/mattpocockuk)"
----
-
-
-
-**Carl Vitullo:** Thanks everyone for joining us for this month in React, where we break down the news and what's going on in the React ecosystem over the past month. It's March this month. There's been a lot to talk about. Excited to have Matt Pocock joining us to talk about the new TypeScript five release. [00:16]
-
-And very excited to talk about the React Labs post that the core team put out. I think there's been a lot of work that they've been doing over the past several years, and I think this post has been just really brought up a lot of those things. Excited to see what we can get into. [00:31]
-
-Yeah, Mark and Matt, do you, can you introduce yourself real quick? Mark, can you go first? [00:34]
-
-**Mark Erikson:** Sure. Hi, I'm Mark Erickson. I maintain Redux. I sit around here and answer a lot of questions. I work at a company called Replay, where we're building a true time traveling debugger for JavaScript. If you haven't seen it, please check it out. And I generally show up in React or Redux related discussions across the internet. [00:53]
-
-**Carl Vitullo:** (giggle) yes, you do. Cool. And Matt, can you introduce yourself? [00:57]
-
-**Matt Pocock:** My name's Matt Pocock I am a general TypeScript person I guess. I was a software developer for about four or five years, and it's, feels weird to say was a software developer cause I'm now full-time TypeScript educator. I guess since like December left my job at Vercel and now working full-time, building a TypeScript course called Total TypeScript. [01:15]
-
-I was a React developer for for my career as well. So working with React and TypeScript for about four or five years. But I'm, as I said before, I'm a little bit out of the React ecosystem at the moment, but I'm really excited to hear what's been going on. [01:27]
-
-**Carl Vitullo:** Yeah, we're excited to have you bring some more of your expertise about the TypeScript ecosystem in here. Cool. Yeah, let's jump into it. So the format we use for this we will introduce a link in a round robin fashion, just going around one by one and have open discussion about it for a couple of minutes. [01:44]
-
-## Retire SPA and MPA?
-
-**Carl Vitullo:** So I'll kick us off here. A couple days, weeks ago. Dan Abramov tweeted about, he said, petition to retire terms, Single Page Application, Multi-Page Application, SSR, SSG, they represent the previous generation of I think that's interesting. It's a, we're at a moment of time where, single page versus multi-page application like that was such a strong client versus server distinction for a lot of my career. [02:10]
-
-But it, you know, it feels like the ecosystem is really cooled on the idea of a single page application saying it's sort of an acknowledgement that you can't do everything you need just on the client. And a bit of a return to more of the history of, web and software development where things were much more server based and the application side of things was, I don't know, maybe not raised to quite its own separate entity. [02:36]
-
-Yeah. What do you guys think about that? [02:38]
-
-**Mark Erikson:** There definitely has been a shift in the discussion both inside the React community and outside the React community over the last year or year and a half. Some of it positive, some of it negative. I've seen a few different articles and some of them were in the, you know, This Week in React link posts that have expressed a lot of very strong critique about React in the community and how hard everybody went in on the single page application concept starting around 2015. [03:07]
-
-And, I think some of it is miscommunication and, attributing bad will to, to people when there wasn't any. You know, there's, there's the ongoing difference of am I building a website with pages versus like, am I building a fully interactive application that happens to live in the browser? [03:25]
-
-And so you've got different people building different kinds of programs and yelling at each other when, they turns out they actually have different needs and technical differences. So that's one part of it. But also I think there is the fact that the tooling around things, around the React ecosystem, you know, whether it be next or Remix or server components or whatever makes it more feasible to build server side pieces. [03:50]
-
-I mean, React has had a concept of server side rendering for a long time now, but, If you weren't using next, you had to build a lot of that yourself. And the tooling wasn't there. And to be fair, like I have never dealt with SSR in any of my own projects. My own applications have always been strongly client side. [04:08]
-
-So like I'm kind of sitting off to the side and trying to observe what everyone else is doing. And I can't speak to this from my own experience. But if you look at something like next, even when you're doing server side rendering and or static site generation, it still ends up with the client side interactivity and then you transition from page to page. [04:27]
-
-And it's primarily doing that on the client. So even right there, it has that mixture of behavior. So I can see the point that Dan's actually getting at here is that even with the tools we have right now, there is a mixture. And when you start including things like server components and you know, next new app router in that combination, it is somewhere in between. [04:51]
-
-And the terms don't seem to fully apply the way they used to. [04:55]
-
-**Carl Vitullo:** Yeah, I think that makes sense. I saw that Kent C Dodds proposed the term PEMPAs, which I don't, I don't, I don't think I'm a big of. uh, P E M P A for progressively enhanced multi-page apps. And (sigh) yeah, I, I guess my thought on this is like, maybe the problem is that like we're trying to assign specific terms for all of these different behaviors, really. [05:19]
-
-Like, incremental static regeneration and static site generation and all those, like, to me, incremental static regeneration is just a dynamic site behind a cache, you know what I mean? Like, it's not something I would architect a build process around. It would be an implementation detail of the caching for me. [05:36]
-
-Like it's a performance improvement. It's not a core part of the architecture. So I think maybe maybe a challenging point of friction here is that like we're trying to figure out terminology to describe all of these increasingly nuanced and, I don't know, just very specific ways of writing software. So I don't know. [05:56]
-
-**Mark Erikson:** I'm gonna go kind of meta on this one. Thinking about it just now, I think what we're actually dealing with is a categorization problem. And the problem is we're talking about things as categories, and a thing can only fit into one category, whereas what we're really dealing with is programs have like tags and you can have many tags on one thing, or to put it in software terms, it's, is it class inheritance or is it like, you know, a game style entity component system where it's like, this thing is movable and this thing can shoot and this thing can do x and this thing can do Y, and maybe the problem is that the terminology we're using is only one label, and we really need to be able to apply many labels to a given app. [06:39]
-
-**Matt Pocock:** I think there's there's like two things that I would think around this stuff. I think one of Kent's terms was PESPA, right? Progressively enhanced single page application. A lot of these terms, SPA, MPA, they all have "page" in them, right? "Page" is the unit of fetching the unit of thing that you're caring about. [06:55]
-
-And whether you're doing SSR or SSG, you are really talking about the page is the thing that you are, assessing, but really what Next, and it seems like what Dan is tilting at here, is that instead of the page being the unit, now the component is gonna be the unit. [07:11]
-
-Think that's in general where it seems like things are moving to, and whether you use like nested routing in Remix or something, or whether you're doing, server side components, you still have a concept of a single component being exported from a file and attaching a loader to it, or having that component itself to the data. [07:27]
-
-But I also think that people don't consume the categories, they consume the frameworks that sell the categories right? So you have, for the last five years, let's say — probably since 2015 actually — Create React App has been still the dominant way that people make React apps. [07:41]
-
-We have all of this huge conversation around SSR and Remix and the framework wars and all that stuff, but really it's been Create React App all the way, and Next has only caught up recently. So the fact that, now Create React App is disappearing, it's gone out of the React documentation, I imagine we'll see its usage drop off, and then finally Next and other frameworks can come into its place. I think like really we are consuming frameworks instead of categories, but really the conversation is about the categories. [08:11]
-
-**Mark Erikson:** That makes sense. Yeah. [08:12]
-
-**Carl Vitullo:** Yeah. And maybe building on that a little bit. I think that thinking about this in terms of frameworks and, the project bootstrap process I think is limiting in that a lot of people are using React with a wide range of backends. So, you know, if you're not building a new project and starting, with Remix or Next or something like that, but you know, you're working off a project that has existed for five years and is originally built with Rails or Django or something like that. [08:40]
-
-That category of development feels left out from this conversation to me. And I was thinking about this while I was preparing for this, and to me, I think this is like a Venn diagram of three different categories that each have their own, breakdowns within them. [08:53]
-
-So it's like, when is the content rendered? Is it rendered in advance at build time, is it rendered dynamically, is it totally static? It's never built, it's just always the same content. So that's, that's one category with three options. [09:05]
-
-Then, like, how is it cached? Is it not cached at all, it's fully dynamic, it needs to be rendered from scratch every time it's requested, or is it cached for a long time? [09:13]
-
-And then a more subtle one that took me a second to come up with and then even wrap my head around was, who owns the url? Because , the server owns a lot of URLs, and it, you want the server to respond to these. But then there's the other category where you don't want the server to respond to it. It's entirely within the bounds of your client side app. [09:32]
-
-So I don't know. I was thinking about how I was thinking about what terms I might use, and I came up with those three categories and was just thinking like, okay, if there was a Venn diagram showing all of the overlap between these different components, that feels like it could get towards being a complete taxonomy of development. [09:49]
-
-But, like also every intersection of those would need its own acronym. And if we have, three categories that each have between three and five subcategories, that can all overlap with one or more of each other. Like, I don't think we need 25 different acronyms to describe the totality of it. It's complex and maybe the taxonomy we're trying to build is not super valuable. [10:04] [10:09]
-
-## Create React App no longer officially recommended
-
-**Mark Erikson:** I'm gonna take this opportunity to go to the next point because it actually circles right around to this part of the same discussion. [10:14]
-
-So one of the biggest pieces of news from the last month is that the new React Doc site is finally live. That's the good news. The bad news is that it, it took four and a half years after the announcement of hooks, and it took two and a half years since they announced they were even working on a new doc site. [10:31]
-
-But it is finally live. And it came with some big surprises. One is that there's a new url. The new home is at React.dev, whereas the old site was at Reactjs.org. And for the record, the old docs are still available, but they're now at legacy.Reactjs.org, and they all have, you know, headers saying, please look at the new docs instead. [10:53]
-
-The controversial ish side of the docs announcement, and we've mentioned this in passing already, is that the instructions for "how do I start a new React project" no longer mention Create React App basically at all. And instead the focus is on using a broader, more powerful framework. [11:13]
-
-The first three frameworks that it mentions are Next, Remix, and Expo. And I think there might be one other in there, I'd have to double check. [11:22]
-
-And this is actually brought up a fair amount of controversy. You have and this kind of goes back to what Carl was saying about like different people with existing projects or different people who have different concerns. [11:31]
-
-There are people who are worried about beginners needing a simpler tool set to get started with. And Next is more powerful than Create React App, but it's also more complicated. There are people who have said, "okay, fine, Create React App is dead, but the docs or the installation and setup page should talk about Vite because clearly Vite is superior to Create React App." [11:55]
-
-And so it should be like a replacement in that sense. There are people who are concerned with, " if I use Next, which is now in a sense, the default choice, then I have to have a node server and I have to deploy it on Vercel in order to use it." And neither of those is true, but those are sort of the default assumptions that people have. [12:16]
-
-## React encouraging server capabilities
-
-**Mark Erikson:** And so there's been a lot of discussion and debate and pushback. There were a couple articles going around basically saying that the React team now wants to pretend that single page applications don't exist. And there is a little bit of truth to that because the React team wants people to be using a framework that has server side capabilities. [12:36]
-
-You might start only using the client side stuff, but their stance is, you will want to use the server side pieces eventually, you will want to use routing ,and so on. And using a framework that has this built in out of the box is gonna give you a better starting point. So this has fed into a lot of the debate like, okay, the docs are out, but they're really pushing you towards a framework, especially Next. [13:01]
-
-And there are people who are not necessarily happy about that. And there are folks using, different backends like, you know, C# or Java, that aren't Node, who are concerned about their projects not working well with React in the future in some way. [13:14]
-
-**Matt Pocock:** It's a kind of awkward spot for React, because React is a library and it's always styled itself as a library. But what, what happens when your library starts making demands of your architecture, right? React is starting to say, okay, we are not just a client side thing. I mean, you can use us for client side, but our more powerful features, the cool stuff, it's gonna involve a server. That's the messaging coming out of Dan, too. [13:39]
-
-What happens then when your library starts saying, " To use me properly, you need this certain architecture." I think that's a bit of where my, sort of, strange feeling comes with this and especially when it was like Next Conf for last year when they announced Turbo Pack and the new version of Next, Andrew Clark was there from the React team, who I think now works at Vercel, and he said that this new version of Next feels like the new version of React. [14:06]
-
-**Mark Erikson:** The real React 18, I think, was the [14:08]
-
-**Matt Pocock:** Exactly. Yeah, I was in the room actually when he said that. Yeah, "it feels like the real incarnation of React," which is kind of strange because it shouldn't be tied to a framework like that, but it feels like they're building features which can really only be like made live through through a certain architecture. [14:26]
-
-**Carl Vitullo:** I think another dimension of this is, to me, I think the React team has been very consistent about that framing for a very long time. Like they've always tried to be agnostic to anything you want to be able to do and to provide the best experience they possibly can, regardless of what setting you want to use React in. [14:46]
-
-So, I think that is true that React is trying to influence the architecture that you develop apps around. But I also think that it's not entirely something that they're foisting on the ecosystem. I think it is very much responding to express needs from the variety of teams that they talk to and the variety of teams that they have worked with internally at Facebook. [15:09]
-
-So I'm interested to see how the server components development goes, how that whole rollout works. But like this isn't anything shocking to me because from my reading of all of the conference talks and demos and how they've framed React, this seems very consistent to me. [15:27]
-
-## Three TypeScript 5 highlights
-
-**Carl Vitullo:** Matt, can you introduce TypeScript 5.0 for us? [15:29]
-
-**Matt Pocock:** Yeah, so, well, this is pretty recent, I think, was it like last week or maybe the week before? TypeScript 5.0 is out and it brings a bunch of really cool new features, new optimizations, and I've been actually updating my course total TypeScript with the new stuff literally today. So it's fresh in my mind. [15:48]
-
-And the three kind of headline items are, performance, TypeScript performance has gotten a lot better with this release, and that's due to a lot of internal changes that they've made. [15:56]
-
-Decorators are now supported in TypeScript. TypeScript had support for like an experimental version of decorators to help it support Angular back in the day. But this is the new shiny stuff and the stuff that's actually gonna be adopted into JavaScript. [16:08]
-
-The third one is a new type of annotation for generics, which sounds really, really nerdy, but it's going to, I think, make a lot of really cool stuff that you can do with tap script generics a lot easier, especially when it comes to, passing configuration to components or passing things around, or making abstractions that make your life easier as a developer. [16:27]
-
-This kind of TypeScript knowledge is super, super useful. [16:30]
-
-## TS5 performance improvements
-
-**Matt Pocock:** So, Mark, do you wanna kick us off by talking about the performance things that they've done? [16:35]
-
-**Mark Erikson:** Okay. The TypeScript team did a lot of work on their build tooling and code base structure in the run up to TypeScript version five. TypeScript first came out I think in 2012, so it's been over 10 years. Obviously the landscape of the JavaScript ecosystem has changed and TypeScript itself has changed dramatically since then. [16:56]
-
-TypeScript's own source code is written in TypeScript, but a lot of the organization for that was using an early TypeScript feature called Name Spaces. For TypeScript version five, they wanted to restructure their code to use the more modern ES module syntax. [17:14]
-
-There were a few reasons for that. One was to make use of TypeScript's own features while working on the code, but another was that the way that code got compiled for publishing actually made the TypeScript compiler run relatively slow because of the code that was generated. They figured out that if they restructured the code to use ES module syntax, , the JavaScript engine would actually be able to run the code faster. [17:40]
-
-And the size of the package that they published to NPM would be smaller. I think the version four X packages were like, 50 or 60 megabytes extracted into node modules. And with version five, it's down to like half of that. The module structure changes also literally made the TypeScript compiler run about 10% faster. [18:01]
-
-There was a fantastic post on the TypeScript blog where they talked about the nitty gritty technical details of the changes. One thing that I thought was fascinating actually they did a lot of work to convert everything all over to use the ES 2015, let and const keywords for variables. [18:19]
-
-And then they found out that in some places that actually made things too slow because of how the JavaScript interpreter has to handle those variables and hand replacing some of those with var instead actually got things back to being about 10% faster. So it, it was a fascinating read, and some amazing technical detail. [18:39]
-
-So summary is if you upgraded TypeScript five, it ought to actually do the compilation a little bit faster and it will be smaller to download. [18:47]
-
-**Carl Vitullo:** Yeah, I had seen TypeScript 4.9 was 64 megabytes in node modules, and TypeScript five is gonna be 37 and a half, so like that's enormous. Very cool that they were able to get so much benefit to performance and module size and everything, apparently just from switching to ES modules, I say just I'm sure it was a huge amount of effort to convert such [19:08]
-
-**Mark Erikson:** Massive amount of work. [19:10]
-
-**Carl Vitullo:** code base to Right. Just a such a fundamental change of assumptions, [19:14]
-
-**Matt Pocock:** I saw pr, I think it was like 500,000 change lines or something Crazy. [19:19]
-
-**Mark Erikson:** There was a lot of automatic conversion work going so they can keep it updated. [19:23]
-
-**Carl Vitullo:** No doubt. I can't even imagine how you would begin to audit that the code still performs the same, it doesn't immediately break everyone's code, [19:32]
-
-**Mark Erikson:** what tests are for. [19:33]
-
-**Carl Vitullo:** ( laughter) a lot of tests. But 10% faster and half the bundle size or 60% of the bundle size is pretty incredible. [19:41]
-
-## TS5 decorators
-
-**Matt Pocock:** Pretty neat indeed. Carl, you wanna talk about decorators? [19:44]
-
-**Carl Vitullo:** Sure, Decorators are… they've been something that I've watched for— actually, they've been something that I stopped watching in my career because… I first heard about decorators in something like 2013. And, like five years on, they still hadn't an advanced past stage two. And it, that's the TC 39 standards process for introducing something to JavaScript has four stages, you know, like there's stage 0, 1, 2, 3, and 4, where 4 is shipped. [20:09]
-
-So decorators were stuck at stage two for [20:13]
-
-**Mark Erikson:** Years. [20:14]
-
-**Carl Vitullo:** like close to a decade with like competing proposals and different libraries were using different incompatible versions. I know that like Mob X went pretty hard on decorators pretty early, and I think that ended up burning them pretty badly. [20:26]
-
-**Mark Erikson:** Angular has been all in on decorators since day one. [20:29]
-
-**Carl Vitullo:** Yeah. And so it's I saw that they advanced to stage three, which is, I think advancing from stage two to stage three is one of the more crucial hurdles to cross because it means, I think Stage 2 is, "okay, we have a proof of concept for how this is gonna work." Stage 3 means "we have validated that this will work in existing JavaScript engines." [20:49]
-
-**Mark Erikson:** it's going from alpha to beta, basically. [20:51]
-
-**Matt Pocock:** And TypeScript, too, takes that. When it gets to stage three, like optional training did a couple years ago, it takes that as a sign and it says, okay, now it's in stage three. Now we are gonna implement it. So everything that gets to stage three will be implemented by TypeScript. [21:04]
-
-**Carl Vitullo:** Okay, cool. I didn't know that was their go signal, but that makes sense. I think that I think last year when decorators advanced at stage three was like a pretty, maybe a quiet, but I think a pretty big turning point for the standard, finally, we can have a lot more confidence that they're going to land in the form that they are described there. [21:20]
-
-Maybe now we'll see a resurgence of libraries and tools making use of decorators as a first class api. And maybe now I'll actually consider using them because, you know, I'm unlikely to have the rug pulled out from under me and have the spec totally change. [21:34]
-
-**Matt Pocock:** Yeah, I think they've made it inning in kind of like a limited form. So the old experimental decorators had more metadata associated with them, so, which is not something they wanted to guarantee in this new version. So the new version is a little bit stripped down, a little bit less powerful, but I think there's probably gonna be more proposals that they're gonna add new things onto the decorators. [21:55]
-
-But I think they've just split the conversation up into a couple of steps, basically. But now that we've got this sort of basic decorator stuff, which is. For those who don't know decorators, let you wrap a method in a class or wrap a class itself and just let you bundle up some logic within that wrapper to, let's say, add logging to a function, for instance. [22:12]
-
-Or, validate the parameters of a function that gets passed in super useful and I think really nice. And I think, yeah, I'm excited for what people are gonna build with this. [22:21]
-
-**Carl Vitullo:** Yeah, and maybe to tie this back to the React ecosystem a little bit, I think decorators got a lot of excitement around the time when higher order components were one of the primary patterns in the React ecosystem, the idea was that, a higher order component is basically just a decorator, but without a syntactical feature enabling them. [22:40]
-
-Yeah, I think that'll be interesting. Higher order components are much less common now, but , I think they still have a real place in the React ecosystem separate from hooks. Like if you're just trying to, if you have an existing component that works and you want to add a seam between that and whatever is rendering it to add props or guarantee behavior, like for instance, I've used higher order components as an authentication wrapper so I can ensure that a component will never be rendered if the user's logged out. [23:06]
-
-So yeah, it'll be interesting to see what the impact of fully shipped standardized decorators will be on the React ecosystem. [23:14]
-
-**Matt Pocock:** I saw that Rafael asked in the chat, are the decorators fully backward compatible? No, they are not. So, yeah, angular, NextJS apps that, or frameworks that rely on the previous experimental decorators they will have a difficult time. I think too, there's a really interesting thing about React developers in general because if you probably asked the median React developer, do you like classes or not, they were probably gonna say no. Right? [23:37]
-
-Because I think a lot of React developers, especially those who made the transition when hooks came in, they'd probably feel a little bit of, hatred towards the old class components where you couldn't compose logic so easily where you had to do all of this, do all of that. So I feel like decorators might just go over the heads of some people who are primarily using React and JavaScript, but don't sleep on it. [23:57]
-
-There's a lot of cool stuff there. [23:58]
-
-## TS5 const annotations
-
-**Carl Vitullo:** Cool. Matt, can you take us through the constant type parameters? [24:02]
-
-**Matt Pocock:** Sure. So this is a funny one. This is one that's gonna affect, I think, library code more than application code. But what it lets you do is it lets you, when you create a generic function, and for those who dunno what that is, it means that when you call a function, you can tell TypeScript to capture something about the way that you're calling that function. [24:19]
-
-So one of its arguments, for instance, and you might have used in TypeScript, you might have used a feature called `as const`. And `as const`, what it lets you do is it lets you take a configuration object and infer it to like its tightest level. So it, if you have like a b ABC in there with like, let's say, let's say an array of success loading or arid for instance, if you wrap that array in as const, it actually infers success loading or arid, instead of it just being an array of strings. [24:47]
-
-what this behavior does is it gives you that same behavior when you infer it in a function. So you can say, this is like const t, and then that t or that thing that's being inferred will be it's, God, it's so hard to describe without actually looking code front of… my days. I think the question is like, when should you use it? [25:04]
-
-What is this going to help with? This is gonna help a lot, I think, with people who are just dipping their toe into generics and trying to figure out some of the weird stuff that's in there. I'm really excited to start teaching it more because it's gonna mean that more people get more access to more powerful abstractions, I think. And I think that's how it's gonna look. It's, you are gonna find it a little bit easier to make more complicated generic functions. And I think lowering that bridge is something that TypeScript really needs to focus on, because I think in every application you are going to have a part of that app. [25:40]
-
-Probably like the utils folder or some sort of shared abstraction that is going to be complex TypeScript wise. Is there anything that they can do to lower that? Drawbridge a little bit. Let a few more people in I think is great. And I think constant annotations is part of that. [25:54]
-
-**Carl Vitullo:** Yeah, I think that this const annotations would've made a very specific case that I've run into a number of times, easier to work with. When I'm working with TypeScript, I pretty frequently end up with basically, like a lookup object keyed by something to get some value. [26:09]
-
-And I'm trying to come up with an example off the top of my head, and I'm blanking, [26:13]
-
-**Mark Erikson:** Enums to components or something. [26:15]
-
-**Matt Pocock:** The thing that comes to my mind is translations, right? So imagine you have like an object of translations, where the keys are the, the translation and then the the actual values are the actual English translation. If you don't use as cons there, or you don't use cons sanitations, then it's gonna just sort of infer it a string. [26:32]
-
-And so you can't do any sort of like clever interpolation there. Like you can't get really cool with it. But if you strap it with a cons, then you can actually get the literal values of the strings. And so you can, detect whether a string has like a dynamic parameter, like a name or something, and then you can, oh, it is there's just so many cool things you can do with. [26:49]
-
-**Carl Vitullo:** Yeah. I am excited for this. It seems like a cool change. [26:52]
-
-## TC39 proposal advancements
-
-**Carl Vitullo:** Maybe a little bit related, moving one step of abstraction up from TypeScript the TC 39. Technical committee that determines the underlying standard. The JavaScript is an implementation of, had a new meeting and they advanced a couple of proposals. [27:06]
-
-So we've now got well one, one exciting one that I, people have been asking for forever is iterator dot range. Finally we have a way of generating an array range from a standard library primitive. [27:16]
-
-We've got explicit resource management, which actually that one confused me. It seems something somehow related to like generators somehow improves a pattern that's commonly used around there, but I don't know. I've never found generators that useful for things that I was trying to do, so I don't really understand that. [27:32]
-
-There was also Async context, which was advanced, I believe, to stage two. I seem to recall some conversation in the React ecosystem specifically about how like React would make use of the async context primitive. So I think that they had some input onto that standard, but I'm blanking a little bit on the specifics. [27:49]
-
-**Mark Erikson:** My vague understanding of that and that that's more from reading Twitter chatter than the actual documentation is. It's it's a little like React context in that you have some value, which is now accessible anywhere, but instead of being based on like a React component tree, it's like anywhere within an async call stack can access a value. [28:09]
-
-I think the hypothetical idea would be like, you have a server, you have some server side code, you have some incoming data, and you want to store information like per request call stack. So you know, this user, that database value, et cetera. And it should all go away when that async call stack unwinds. [28:28]
-
-I think that's the general idea. [28:30]
-
-**Matt Pocock:** Is the idea then to use that for streaming or to use that for server components? [28:35]
-
-**Mark Erikson:** I would assume server components because my understanding is that normal React context does not work in server components. I think. And so having this ability built into Node and in the language itself would then act as your equivalent for, I need to access this value anywhere within a set of server components. [28:56]
-
-**Carl Vitullo:** Sure. Yeah. This reminds me, I had two thoughts when I was reading this spec. My first one, I tend to write a lot of, functional code rather than object oriented. And one sort of downstream consequence of that is I tend to use, slash, some might call it abuse, module scope variables for tracking state, which that works great in a client side application where every, every user has their own context. You know, it's running on the user's machine. It does not work at all on the server side of things. [29:25]
-
-So I think that this is a new language primitive that would allow me as a, as an application developer to use a similar pattern to module scope singletons, but in a way that works out of the box on the server side. [29:40]
-
-That leads me into my second thought, which is this smells a lot like a. The session global from PHP it, I think it's not exactly that because it's not a global, but I think it allows you to declare something similar to a session wherever you want. [29:54]
-
-So it's, you know, it's not one global session per request, but you can say this is a session associated with this specific running context. So I think that's really interesting. That seems like a pretty large change to the assumptions that a JavaScript run time is based on. [30:08]
-
-There are some other some other small ones. I saw Float 16 array, just a new typed array. It sounds like that came directly out of a W three C request where they want to offer more precision for canvas buffers. [30:21]
-
-And last one that I wanna highlight is the Await Dictionary proposal, which looks like it's a sort of object based complement to Promise.All. [30:29]
-
-It allows you to await an object full of promises and destructure that as named, named variables instead of having to convert it to an array and then deal with argument ordering. [30:39]
-
-**Mark Erikson:** Which, I mean, it's syntax sugar, but if I can totally see how that would be handy. [30:43]
-
-**Carl Vitullo:** Cool. Yeah, some big changes there. [30:44]
-
-Mark, what do you wanna talk about? [30:46]
-
-## React labs update
-
-**Mark Erikson:** Okay. So the, one of the other really big things that came out in the last few weeks the React team put up what they call a React Labs post, which is their category for, here's the stuff we're experimenting or doing research on recently. Lot of really good, discussions there. [31:02]
-
-But some general highlights. One is they talked about their work on React server components. They talked about some of the changes they've made since the first proof of concept announcement that they did a couple years ago. They talked about how you can use async await within server components. [31:18]
-
-The first example of server components is shipped inside of next experimental app router. And they're doing some other work around being able to stream data and metadata as well. [31:28]
-
-## React Forget
-
-**Mark Erikson:** The part that I was really excited to read to the point that I'd been bugging some of the team members about this on Twitter at React Conf last year, the React team announced that they were working on an experimental React, optimizing compiler, codenamed React Forget. [31:45]
-
-And just for reference, the React team has a habit of like every project they have has a codename that starts with the letter F. React Fiber, React… Fizz, React Forget. [31:56]
-
-So the idea that they talked about is you write a normal React component and it looks at it and it figures out how to rewrite the internals of the component to better memorize and optimize the inputs and outputs of that component with the goal that it would eventually help save on this whole, like, "when is my component going to re-render?" [32:19]
-
-How do I avoid unnecessary renderers? When should I use, use memo and use callback and all that stuff. And that if the compiler works out, it would basically just do all that for you. They've had a team of about four or five people working on this for about the last year, and they gave a status update. [32:38]
-
-The general summary is that, they've got the basics of the compiler working. And they've bec because you can have literally any JavaScript logic you want in a React component, writing a compiler is really, really hard, versus a, a framework like Angular that uses HTML templates. [32:55]
-
-So they've started off by supporting like just a small amount of the JavaScript language as acceptable code that the compiler knows how to work with. And they've been trying, trained out inside of Facebook, they have been also trying to figure out like, how tied is this to babble as a compiler. [33:12]
-
-So they've made progress on it. They're hoping to open source it eventually. I don't know. Like I'm really excited about this. If the compiler works out, it will make our React apps run faster, it'll make it easier for us to write components. We won't have to think about that stuff as much. I just really want to see this in action and play with it myself. [33:31]
-
-**Matt Pocock:** To play like a bit of devil's advocate here — this does seem super cool — is there a danger that you could, it could over-optimize in certain places because, like caches aren't free. Like to a cash, reading from a cash or. Would it optimize things into positions where you would get bugs? [33:46]
-
-Are there ways to disable the compiler profile if you, I mean, I dunno why I'm [33:50]
-
-**Mark Erikson:** yeah, there's there's always caveats and trade-offs. One, one of the most obvious ones I can think of is that it'll, like, the idea is it'll look at the logic in your component. And for example, maybe it'll, it, maybe it sees that your component outputs like three different chunks of content in the JSX, and maybe it can figure out that one of those never changes. [34:10]
-
-The second only depends on piece of data. A and the second depends on piece of data B. Now, if I were to optimize that by hand right now, what I could do is extract the first chunk of content to be some JSX elements outside the component and just use that variable every time. And then inside the component right now I could have like a useMemo A, useMemo B. [34:37]
-
-So the idea is that the compiler would hopefully be able to figure that stuff out and figure out, this piece never changes. This piece only changes when data A changes. And the other piece only changes when data B changes. It is possible to do that stuff, but the compiled version might literally be more lines of JavaScript code. [34:58]
-
-So there could be, for example, an increase in the bundle size because it now has the extra logic to determine what needs to be memoized and whatnot. There's always a course of bugs because a compiler is just software, and old software can have bugs, but that's what they're trying to figure out right now is how much of the JavaScript language does it know how to support, what kinds of restrictions does it need to have? [35:19]
-
-How good is the code output? And they're testing it against fa, parts of Facebook internally to try to prove all that out. [35:27]
-
-**Matt Pocock:** It's interesting cuz React, hasn't had a compiler before, but other frameworks, like Svelte or Solid. Have their own compilers, which do their own optimizations as far as I'm aware. So it's interesting that they're joining onto this and it's interesting that this takes React from being just JavaScript, to having this little optional layer, I guess, on top, that sort of takes it away from just JavaScript. [35:48]
-
-So we were talking about React positioning before. I wonder if that impacts it at all. [35:52]
-
-**Mark Erikson:** It, it does in a couple ways, and this also ties back to the server components bit. Nothing about server components suddenly makes our existing client side React logic not work. You can still use Create React App, you can still use Vite, you can still data fetch in a component on the client if you want to, but now there are new options on the server that give React new capabilities. [36:17]
-
-So in the same way, let's say React Forget works, let's say the compiler comes out and it's, you know, it's now built into, next or Remix or whatever. You could still. Build a page by linking the React script tags and writing some plain JavaScript code that, generates the output with React dot create element, none of that goes away. [36:38]
-
-But now there is a newer approach that most of the apps would use, in the same way that, most React apps do use, webpack, Babel, SWC, esbuild, et cetera as a build step. So like, yeah, you could do things the old way, but there would be a new approach that, while technically optional would probably be built in to all these different frameworks by default and hopefully it would just work. [37:05]
-
-Fingers crossed. [37:06]
-
-**Matt Pocock:** Yeah, this feels kind of like eslint, really. Like, it's sort of an optional layer if you want to add it, and the React team has built like custom eslint plugins that help you, prompt you to add different things to useEffect and things. So it feels a nice little, it's a nice to have, right? It doesn't feel critical. [37:20]
-
-**Mark Erikson:** Well, if it works out the way I think it will, I think it'll be a technically optional, but you would really, really want to use it for the benefits kind of a thing. [37:29]
-
-**Carl Vitullo:** Sure, not using it is an escape hatch for if you are working in a context where it doesn't work. For sure. [37:35]
-
-**Mark Erikson:** Mm-hmm. The one other thing to note about this Dan has been trying to figure out like how he wants to describe these things, and this goes back to all the debates over the last couple months about like signals and Reactivity versus, virtual doms and all that kind of stuff. And one of Dan's point is that assuming again, that the compiler works out, the code that you write in your component would still be normal JavaScript, array maps and using plain variables and plain object. [38:03]
-
-There's no special wrappers around the data. You're not having to worry to remember to call functions to access the data, but that the code you write is still basically playing JavaScript and then it's the compiler's job to figure out how to make that better, instead of, you know, needing to remember like, I have to call signal dot, get to access a value, or, some of the other rules there. [38:26]
-
-So his argument is that the compiler would give you basically all the performance improvements, but without you having to worry about it in your own code. [38:34]
-
-**Carl Vitullo:** Well, I'm always all for not having to think about something, so that sounds pretty great to me. [38:39]
-
-## Offscreen rendering
-
-**Carl Vitullo:** That React Labs Post has so much detail in it about what they've been working on. I think it's really cool. Something in there that I thought was pretty interesting, the offscreen rendering feature. [38:48]
-
-**Mark Erikson:** Yes. [38:49]
-
-**Carl Vitullo:** I'm excited for that. I think there's, that's something that I've written some, components to help with. Like, they talk about it, your options generally having been to either not render it and then that has a performance cost of, it's gotta tear it down and set it back up [39:02]
-
-**Mark Erikson:** Losing state. [39:03]
-
-**Carl Vitullo:** Right. Yeah. Losing state, You either lose all your state and blow it away, or you hide it in CSS and then you still have to deal with all the performance implications of [39:13]
-
-**Mark Erikson:** or you put it in Redux or recoil or Mob X or [39:16]
-
-**Carl Vitullo:** Right, which is its own can of worms. This offscreen feature sounds very cool. I also like that it's taking advantage of a feature that was implemented in React. I think in React 18, like this is really a priority hint. This is a way for us as developers to say this is low priority. [39:35]
-
-But framing it as "offscreen" is interesting and useful. It, I think it communicates more about developer intent, like this could have been introduced as " deprioritized" or "low priority". But I think framing it as "offscreen" helps clarify when it's meant to be. [39:51]
-
-**Mark Erikson:** So I can tell you that we are actually using the Offscreen API in my day job at Replay right now. One of my teammates is Brian Vaughn, who used to be on the React Core team. And so he's brought over a lot of his knowledge of these relatively new and somewhat still experimental React features. And we've been using some of them in Replay's code for the last year. [40:12]
-
-So the offscreen component is available in React, but only in the daily experimental builds, not the full like official production releases. And so Replay uses an experimental build of React that has the offscreen component available. [40:29]
-
-We've been using it for, in the last, in most of the last year, and it actually works pretty well. We did run into one or two cases where they were having to like fix bugs in the behavior, and we actually got bit by that once or twice, but for the most part it works pretty well. [40:43]
-
-You just wrap an offscreen component around like the tab panel, or something that you care about. And then as you're switching tabs, instead of tearing down the panel, you just set, `offscreen = false` and it keeps it around and it works great. [40:58]
-
-**Matt Pocock:** They've been thinking about this for a while, right? This links back to the reason that because there was, sort of, a little bit of a furor when useEffect changed in React 18 to fire twice in dev mode, right? [41:10]
-
-**Mark Erikson:** Yep. [41:10]
-
-**Matt Pocock:** And the reasoning behind that was the offscreen was coming and can't remember what the link was. And could you fill in the gap for me? [41:19]
-
-**Mark Erikson:** Yeah. So, [41:20]
-
-um, [41:20]
-
-hang on. There's a very specific discussion from the React Working Group where they, they talked about this, and this is one of those cases where they iterated on how they wanted to describe it. Like originally they were saying like, "it's really strict effects and we're gonna make effects fire twice." [41:37]
-
-And then they changed it to emphasize the positive instead of the negative, where it's like, well, "React is going to preserve your state instead of fully unmounting the component," so kinda like the same thing but a different perspective on viewing it. So like reading that React Working Group discussion covers some of this. [41:55]
-
-**Matt Pocock:** Nice. Yeah I'm really hyped for this. I think it's gonna be great. [41:58]
-
-## Server Components
-
-**Carl Vitullo:** There's a lot we could say about React server components as well. I have not stayed super on top of their development, so I don't feel like I have the most context. been a, there's been a lot going on there. [42:08]
-
-**Mark Erikson:** The one line status summary I'll give is, they exist. The big issue is that they need to be integrated into a bundler and a router and a build system to have any value. [42:20]
-
-So right now, the primary way you could use them is by using the next 13 experimental app directory. Other framework authors are trying to play around with like, how would I build this in to Remix or just like a, or, standalone webpack config or something. [42:39]
-
-The problem is because it's still very experimental, there's no documentation on how to do that, so you've got like individuals playing around with it and trying to reverse engineer, how do I make use of this functionality by looking at next, or looking at the React test just because there, there isn't documentation on how to do it, but a bunch of different frameworks are playing around with the idea at the moment. [43:01]
-
-**Carl Vitullo:** Yeah, definitely. I'll respond to that in a sec. [43:03]
-
-We are coming up in an hour and Matt Pocock has a hard stop here. So yeah. Matt, thank you so much for coming out. It was really great having your perspective on TypeScript changes. [43:11]
-
-**Matt Pocock:** No worries. Really, really fun to chat to you guys as always. [43:13]
-
-**Mark Erikson:** Yep. [43:14]
-
-**Carl Vitullo:** All right. Thanks so much. [43:15]
-
-**Matt Pocock:** See Bye. [43:16]
-
-**Carl Vitullo:** That context for server components I think is interesting. It's the core team is really saying these exist, they are in use by some people, but they are not for general consumption. [43:28]
-
-**Mark Erikson:** Yeah. [43:28]
-
-**Carl Vitullo:** That reminds me of now, close to 10 years ago, that was the state of React context. [43:34]
-
-It was undocumented feature. They were using it internally, they knew that people would want to use it, but they weren't comfortable with the api. They wanted to iterate on a little bit more. [43:43]
-
-**Mark Erikson:** Funny thing is, I think React Redux, and Dan Abramov, like one of the first cases that an external library started using the original Legacy React Context api and that helped prove how some people wanted to use it. It also helped expose some bugs and weaknesses in that API design, and that's what led to the React Team building the current Context API that came out in React 16.3 a few years later. [44:13]
-
-**Carl Vitullo:** Yeah, and I was refreshing my memory on some of the timing around React versions recently. I didn't realize that we only got context around the same time as we got hooks [44:22]
-
-**Mark Erikson:** it was a few months. It was five versions and a few months earlier. Context came out in 16.3 hooks came out in 16.8. [44:30]
-
-**Carl Vitullo:** yeah. Okay. Just to me, context has been around forever. So seeing that actually not that, in, in the overall lifespan of React, it was officially released, not that far away from hooks. Like those would feel like two totally different epochs to me. [44:44]
-
-**Mark Erikson:** Very much so. [44:46]
-
-**Carl Vitullo:** But yeah, so seeing the React core team talking about. Server components in a similar sort of way of like, Hey, don't use this yet. It exists. If you poke around, you can figure out how it works, but we're not going to release documentation yet. Like that is certainly something that, that is a pattern that they followed before. It's not new. Not new for them. [45:06]
-
-**Mark Erikson:** And to be fair, Dan was grinding out the last several pages on the new doc site, and that took him a long time to do it. They just literally haven't had time to write documentation for things like server components, even if they were like fully done, which they're not. I mean, like literally they haven't had time to write documentation on the these things and how you would integrate them into a bundler. [45:29]
-
-**Carl Vitullo:** This feels to me like they are looking at how people are using React and seeing that many people are reaching for Next and Remix over just using React and both Next and Remix found their own solutions for something like server components. [45:45]
-
-So to me, this feels like they have been observing what's going on in the ecosystem, seen what patterns have arisen, and now we're trying to learn from those and introduce it as a feature within React so that then both Next and Remix can expose the same underlying abstraction rather than having, rather than fragmenting the community and coming up with their own core concepts for it. [46:09]
-
-I think that's absolutely the right approach for them to take and I'm sure that Next and Remix are excited for that because now they will have one less, feature that they need to maintain. I know Remix uses a .client or .server file name annotation I'm sure they would love to not have to maintain a feature for determining that separation. [46:28]
-
-**Mark Erikson:** The Next folks are obviously very excited about React server components. Probably cuz you know, half the React team now works at Vercel. [46:34]
-
-**Carl Vitullo (editing):** Fun fact, the core team has 25 members. There are 20 developers and five managers. So four reports each on average. Three of the engineers are independent three, work at Vercel and 19 work at Facebook. There are a lot more folks building React than many people realize. [46:50]
-
-**Mark Erikson:** I think the Remix folks are still kind of hesitant about the whole idea and how it would fit in. [46:54]
-
-**Carl Vitullo:** That's interesting. I didn't realize that. Yeah, I guess that makes sense though because so many of the core team is now at Vercel, Next is very much under their domain at this point. [47:03]
-
-## Asset Loading and Transition Tracing
-
-**Carl Vitullo:** Yeah, I guess closing up on the React Labs post, they also mentioned asset loading and transition tracing. [47:09]
-
-Both of those to me sounded like features that are likely to be pretty big sea changes for developer experience. They're not very flashy features. You know, they're not exciting, you don't get hype about it, but I think that both of those have the potential to be massively influential on what it feels like to develop code. [47:27]
-
-So I'm excited to see what comes out of those, but I, I don't know how much there is to talk about it. [47:31]
-
-And transition tracing, just to explain it to the, to audience. If you are doing performance profiling of a React app right now, they have code in there to track component mounting and unmounting. They can annotate your flame chart with what component is where. [47:45]
-
-But something missing from that is events. So you can't see on the flame chart when was a button clicked, when was a form input fired? So my understanding of this transition tracing feature that they're working on is it will annotate your flame chart with tho those details, which I, as someone who's done a lot of performance profiling for React applications, that is a pain that I have felt many times and I'm excited to see it come out. [48:09]
-
-**Mark Erikson:** I think the other aspect is that with React eighteen's ability to split a render into many pieces over time it's harder to be able to track like, really when did this render start and finish? And they, they wanted to make that more feasible. [48:25]
-
-**Carl Vitullo:** Interesting. Yeah, that makes sense. Yeah. I know they had done, they had the Reactive tools, which had like commit and [48:31]
-
-**Mark Erikson:** Mm-hmm. [48:32]
-
-**Carl Vitullo:** I can't remember the other term, but it had like [48:33]
-
-**Mark Erikson:** render phase and commit phase. [48:35]
-
-**Carl Vitullo:** Yeah, sure. And it, it could, like, you could use that to discover expensive components, but it wasn't super useful for actually figuring out what caused that expensive re-render to happen. [48:48]
-
-I think they said in the React Labs post that they had actually removed some of the code that was powering some of that because it just wasn't working for people, which was my experience. So, Cool. [48:57]
-
-**Mark Erikson:** Can I go off and talk about a work project for 30 for like one minute? [49:02]
-
-**Carl Vitullo:** Ooh, please do. [49:03]
-
-**Mark Erikson:** okay, so, I work at Replay. We're building a time traveling debugger for JavaScript, and we have the ability to inspect anything that happened inside of a running recorded JavaScript program. And over the last f last couple months, I've built some experimental features where I can write code that asks our backend, Hey, when did this piece of code run? [49:28]
-
-Or what was the call stack when it ran? And do more further analysis from there. And over the last couple weeks, I built an experimental feature in Replay, like, because I know a decent amount about how React works inside. I figured out that every time you call set state, it goes through one internal function inside React. [49:50]
-
-And if you ask Replay, tell me every time that function ran, and then you walk backwards up the call stack to user land code. Eventually you find the place in your code that you called setState, or in a lot of cases called a Redux dispatch, which goes through Redux and then eventually hits the same React internal function. [50:13]
-
-So I built a very, very experimental proof of concept panel where it, if you make a recording of a React app, it will walk through the recording and show you list items that represent every time your code called Set State. And then you prep, you click on one of those list items and it jumps you to that line of code and the time in the recording when it made that call. [50:38]
-
-It's still very experimental and proof of concept, but it does actually work. [50:43]
-
-**Carl Vitullo:** Cool. Yeah, I have not used Replay yet. I, and honestly at this point in my career, I'm not really doing like heads down day to day React code to the same extent that I used to be, but, I think if I were in a place where I was more frequently debugging complex issues… oh man, Replay just sounds like an incredible boon for productivity. [51:03]
-
-So getting more understanding of their internals React. Heck yeah. [51:08]
-
-**Mark Erikson:** Hmm. That also actually ties into something else I'm doing for my day job, but it will actually, hopefully have a benefit to the Greater React ecosystem. React ships multiple files in node modules, and they ship both a development copy of the React code, already bundled, and a production copy of the React code, bundled. [51:27]
-
-And the problem is that they have never shipped source maps. And source maps are what a JavaScript debugger uses to be able to translate from the minified code that is actually running in the browser back to like the original source code files. So like if you ship source maps with your application, even though it's been mangled down to one minified bundle, when you go to debug it, you can still see source/features/my-component.tsx and debug that original looking code. React has never shipped source maps. [52:01]
-
-And so that's why whenever you see like a, an error stack trace from React in production, all like there are no function names, everything's like, two letter gibberish. if you were to say like put a break point in a function component and then step, step, step, step out of the component back into React's, internals, it's all gibberish and you can't read any of it. [52:23]
-
-At Replay, we use source maps to also help debug code and so I as a Replay employee, have put in work over the last couple weeks to modify Reacts build system so that it will actually generate source maps for Reacts production bundles. And I got it working and I have a pull request up in the React repo. [52:47]
-
-I just need to convince Dan Abramov to actually merge that PR. So assuming that gets merged, fingers crossed, then starting with the next React release, hopefully, probably 18.3, you would be able to see what the original code looked like for the production bundles. In a, like, in like a deployed application if an error gets thrown in production, at least the stack trace would be a little more readable. [53:14]
-
-The React internals are really complicated, so you're still not gonna understand what's going on, but at least you could read the code. [53:19]
-
-So I'm really, really hoping that I can convince Dan to merge that PR within the next couple of days. [53:23]
-
-**Carl Vitullo:** Yeah. Very cool. Well I hope to see that la I hope you're able to convince Dan that that's a valuable contribution. I think sounds great. [53:30]
-
-**Mark Erikson:** Like, it works and they've got their CI system set up to do example builds from the PR. So you could try installing a copy of React from that PR right now if you wanted to, play around with it. But I tested it out in, a couple different projects, a Vite app, a next app, et cetera, and the source maps look pretty good. [53:51]
-
-**Carl Vitullo:** Nice. Heck yeah. [53:52]
-
-**Mark Erikson:** I probably oughta call it a day here and actually go get something done. In fact, what I probably had to do is go back to that PR and see if I can make a couple tweaks Dan requested. [54:00]
-
-**Carl Vitullo:** Ha. Well, thanks for going 12 minutes over time with me. It's been really great recapping the news and the React ecosystem with you. [54:07]
-
-**Mark Erikson:** Good stuff. [54:08]
-
-**Carl Vitullo:** Excellent. All right. Thanks so much. See you guys next time.
diff --git a/src/transcripts/tmir-may-2023.md b/src/transcripts/tmir-may-2023.md
deleted file mode 100644
index 00a5b4c..0000000
--- a/src/transcripts/tmir-may-2023.md
+++ /dev/null
@@ -1,457 +0,0 @@
----
-title: This Month in React (May 2023)
-date: 2023-06-05
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Mark Erikson, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Mark Erikson](https://twitter.com/acemarke), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-
-
-**Carl Vitullo:** Hello everyone. Thanks for joining us for May's This Month in React, where we recap and digest recent developments in the ever-evolving React and web ecosystem. I'm here with Mark Erikson and Sebastian Lober. Mark, you wanna introduce yourself? [00:15]
-
-**Mark Erikson:** Hi, I'm Mark Erikson. My day job is working at Replay, where we're building a time traveling to bugger for JavaScript. My free time, copious amounts thereof is taken up maintaining Redux. [00:26]
-
-**Carl Vitullo:** Heck yeah. Sebastien, can you introduce yourself? [00:29]
-
-**Sebastien Lorber:** Yeah. I'm the author of this in React, the newsletter at keeps You to date with React and React Native, and also the maintainer of Docusaurus React documentation framework from Meta. [00:42]
-
-**Carl Vitullo:** You know, I realized that I have been asking you guys to introduce yourself and I don't really introduce myself. [00:47]
-
-**Mark Erikson:** Carl, would you, would you tell us about yourself? (laughter) [00:50]
-
-**Carl Vitullo:** Yes, I would love to. I'm Carl Vitullo. I am a staff software engineer and freelance community manager, sort of community lead for Reactiflux. [00:58]
-
-I, I think, not a ton of huge news going on right now, but yeah. Mark, can you kick us off with our first link? [01:04]
-
-## Next 13.4, App Router and Server Actions
-
-- [Next 13.4](https://nextjs.org/blog/next-13-4)
-- [Server Actions](https://nextjs.org/blog/next-13-4#server-actions-alpha)
-- [Isomorphic Development](https://meijer.ws/articles/isomorphic-development)
-- [Rich Harris on frameworks, the web, and the edge](https://www.youtube.com/watch?v=uXCipjbcQfM)
-- [RSC data leak security footgun](https://twitter.com/tomus_sherman/status/1654211227172716545)
-
-**Mark Erikson:** Okay. So first off last month, Next 13.4 came out and the, the really big news item out of this is that they are declaring that the NextJS app router is stable, which has a couple different implications. [01:20]
-
-One is that it's a different way to define the routing structure through your page. And the second is that this is the first official "production" ready release of React Server Components. [01:33]
-
-Now this is where it's always dangerous for me to try to describe things because I have not had a chance to use any of this stuff. So, you know, a lot of what I can say here is either looking at the announcement blog post or trying to summarize the stuff that I've read off the various discussions on, on Twitter and Reddit. [01:51]
-
-So at this point, React Server Components are in theory production ready to use, and I've certainly seen people, you know, mentioning that they've, you know, they've rewr rewritten their blog or, you know, put together some actual example sites using React Server Components. [02:07]
-
-It feels like there's still some question about just how production ready they are, both in terms of stability as well as like what are expected usage patterns and how do you integrate various existing community tools and libraries into those. But you know, at least as far as the Next team is concerned these are in theory pretty much ready to go. Um, so that's, that's by far the, the biggest piece of news. [02:37]
-
-And then looking at the release notes the couple other big things in 13.4. Next has a team building a tool called TurboPack, which is a equivalent kind of build tool to Webpack, except it's written in Rust. It's being written by the original author of Webpack, Tobias Koppers, and it's supposed to be significantly faster. And so the release notes say that they, they are marking TurboPack as being in beta. It still does not have full future parity with Webpack, but they are making progress on it. [03:11]
-
-And then the last piece is something that I, I, I've only seen bits and pieces about myself, which is that Next and React are working together on something that they call Server Actions. And this is apparently very inspired by what Remix has, where it's, it's like a new primitive for sending requests to the server based on plain HTML forms. [03:37]
-
-And I, I think the idea, looking at the examples is that on the client side you have a lowercase form input and you provided a prop called action. And that action can then in turn, really run on the server and do like a direct database insertion or query or something like that, and the compiler is able to separate out the fact that this action function needs to run on the server versus the rest of the code, which could technically run on the client or the server. [04:11]
-
-So it's, it's kind of like that Remix style thing where you're writing code in the same file that mixes together client code and server code, and it automatically just works. So they, they announced this Server Actions idea. It's still very much an alpha and experimental, but it is a thing that they're working on right now. [04:31]
-
-And so these, these pieces have the possibility if they, you know, actually pan out to be pretty large changes in the way we structure and write React applications. [04:41]
-
-**Carl Vitullo:** Yeah, definitely as you were and you know, as I was reading the notes on Server Actions, my immediate thought was Remix as well. [04:48]
-
-I do think that's a really powerful pattern that Remix introduced. So I'm excited to see Next Adopt It. And yeah, I mean this is, to me, this is exactly why it's so beneficial to have multiple clients doing, or, you know, mul multiple tools trying to solve the same use cases cuz they come up with different ideas and some of them stick. I'm pretty excited to see Server Action stick. [05:08]
-
-I think this, I think if you're going to have code that spans the server and the client, you know, it can't all be UI code, not everything we do on the server is render UI. So having, you know, an easy way to run other types of arbitrary code. Yeah, that sounds awesome. Excited for Server Actions. [05:25]
-
-**Sebastien Lorber:** Yeah. I'm also excited for, for Server Actions. Maybe for another reason is also the, the support for Progressive Enhancement. Because so, so far Remix has shown that it's possible to, to have a great Progressive Enhancement story with React, but this kind of feature was lacking in in NextJS. And now they, they, they show that they really care about it. [05:49]
-
-And you know, when you submit a form now the abstraction, the the abstraction make makes it possible to, to submit the form without JavaScript, without even direct being hydrated on the client. And the server is able to, to receive the form submission and and send the new HTML page. depending on if JavaScript is running on the client or not, the payload will not be the same. [06:16]
-
-And actually, I think the NextJS markets this feature as Server Actions. But really I think the action prop is right, is a React Core concept. Now you can you can pass an action to a form in React and it can be a very string or callback. And, and depending on whether the JavaScript will run or not the, you will use one form or another in NextJS to support a progressive announcement or the submitting the form locally with a JavaScript. [06:51]
-
-**Carl Vitullo:** Okay. Interesting. I didn't realize that this was a React concept that Next is looking to expose. [06:57]
-
-**Mark Erikson:** I think it's a plain HTML concept that they are extending. So the plain HTML form element has always had an `action` attribute that would, I think it defaults to POST, and that's why if you just have a plain HTML form and you submit it, the browser literally makes a post request to the server, right? [07:19]
-
-Uh, I think you can change it to be GET instead. And so I guess technically what the React team is doing is they're overloading the existing action attribute so that you can pass a function instead of a string. And if so, they, they wire things together on both ends. [07:37]
-
-**Sebastien Lorber:** Actually, what you mean is the method, POST or GET is the method and action with the URL of the, the target endpoint of the form. [07:45]
-
-So somehow they just allowed to accept the callback. But I think on the, on the server, the, the callback is serialized to string by the compiler so that before hydration React is able to know where to post the form on the server. [08:02]
-
-**Carl Vitullo:** Oh, interesting. Okay. So I think I see, I think I see what you're saying. [08:05]
-
-So I just put a little code snippet in the chat here. So there's this page component, it has a function defined inline. [08:12]
-
-**Mark Erikson:** The key, the key thing is that it has the "use server" string inside, and this is where the compiler part comes into play. So similar to Remix, you've got code that could run on either side in the file and some code that only runs on the server in the file. And they have to have some way to delineate which code in that file is server only, and they're basically just gonna strip that out of the part that goes to the client. [08:40]
-
-**Carl Vitullo:** Okay. That's interesting. Okay. So it doesn't need to be inline. That's good (laughs). I, I'm not a huge fan of this "use server" tag, but like, okay, sure. That's how, that's how it works, whatever. Um, it reminds me of an article I read recently talking about "colored functions" and how it's yeah, it just introduces multiple types of functions here. [08:59]
-
-But the point I wanna make here, to me, this actually just reading this code and thinking about this as like, the compiler is extracting out the function, it seems almost more like a developer experience improvement on serverless. You know, because you could write a function like this that handles a single form, but it's pretty painful to do that with a serverless backend. [09:20]
-
-So having a compiler that will extract out that code and handle the packaging it into a serverless, you know, executable and putting it somewhere and inserting the url, or Yeah, inserting the URL into a form. That actually that's, that's actually really interesting to me. [09:37]
-
-**Sebastien Lorber:** There is something to, to not be wrong about this snippet is that, you are not mixing server and client, code inside the same file. The whole component is a server component and the "use server" only expose the function to the public interface of the server, somehow. [09:55]
-
-So I think the, the first reaction you have when you see the, the snippet is, you are able to somehow mix server and client side code in the same file. But it's not exactly that. [10:05]
-
-It's more like, inside your server component you can choose to render functions and some of them will get exposed to the public interface that the server runtime will create. So I just want to, to, to make sure that people don't make this confusion because the, the form is a server component. It's not a a client component. [10:26]
-
-**Mark Erikson:** That, that does kind of go into, I guess my, my biggest concern with all this stuff, and that's trying to wrap your head around the mental model. My biggest personal problem is I just literally have not had a chance to use any of this. So I've been trying to understand it without actually using any of it in practice. [10:43]
-
-But it feels like trying to understand these boundaries between what's, what's a server component, what's a client component? Like as my Redux co-maintainer Lenz has pointed out, it's like, client components can run on the server, the phrases server and client don't necessarily have the meanings you think they do with this technology. Um, I actually wanted to link two other articles that I'll, or, well, an article and a post that I'll throw in here. [11:06]
-
-And I thought these did a pretty good job of discussing some of the, the pros, cons, concerns, and trade-offs with both like,, Server Components as a technology, and in general, what we're doing as we kind of mix and match with this code where you can have a database call and something that runs on the client in the same file, it starts to blur the lines. [11:30]
-
-And we're doing this sort of in pursuit of developer experience, but it does bring up potential concerns around things like accidentally Exposing API's, keys, or secrets into the client if you're not careful enough about how you structure the code, or just trained to wrap your head around what pieces of code are going to run where, and I know Dan has said that, you know, in, in a lot of ways this simplifies how you teach React to people because you don't have to explain, "well, I, I make a fetch call when the useEffect" or "I have to go learn how to use React Query" or something like that. [12:08]
-
-Instead you just, you're just making an async/await call inside of a component and it just works. And I see the point he's trying to make, but there are a lot more moving pieces involved here as well. And I don't have a great answer for how are we going to teach all this and what kind of problems are, are people going to run into as a result. [12:31]
-
-**Sebastien Lorber:** Yeah. By the way, there, it's worth mentioning that there is a little security issue that related to the Server Actions in NextJS, I will post in the chat. A tweet related to that is that if your server action captures a variable in its closure, actually this variable will be sent to the client inside the form as a hidden parameter, so that it'll be sent back to the server so that the, the closure is able to, to see this variable again, because unlike client components, the, the Server Components do not have state. [13:07]
-
-I, I mean, for example, if one server component serve your request, it might be in AWS US west 1, and then on the second request, it might be another data center that serves your request. So all the Server Components have to be stateless. And if you need to preserve state across closures inside your Server Components, they must be sent to the client. [13:31]
-
-And currently this is a risk to expose secrets to the clients. So the React team said that they were thinking about encrypting the hidden parameters, but it's not ideal solution because of course you, you don't necessarily want to expose secrets even encrypted. [13:50]
-
-And I don't know what will be the, the solution and if a decision has been made, but it's worth knowing that there is a little security issue currently regarding the usage of Server Actions. [14:01]
-
-**Mark Erikson:** I actually just had a, a side flashback to the, the old classic ASP.net view state approach for serializing data to the client. [14:10]
-
-**Carl Vitullo:** But so we're, we're 20 minutes in. We've done one link, so we should probably move on (laughs). That's a lot to talk about though. Yeah. Sebastian, you wanna take us on to our next one? [14:20]
-
-## React Native Skia
-
-- [William Candillon – The Joy of Painting with Skia | App.js Conf 2023](https://www.youtube.com/watch?v=Hfb_gpfCHzk)
-
-**Sebastien Lorber:** There have been uh, three React Native conferences this month. There was AppJS in Poland, there was uh, Chain React in USA and there was a React Native Connection in Paris. I like particularly the talk of William Candillon that presented the progress with React Native Skia, which is the renderer used inside Flutter and inside Android and inside Chrome, and inside many of other things. [14:43]
-
-And you can use it in React Native today, and it permits to, to somehow unlock many use case that that were not possible previously. The talk is presenting a few interesting things like the ability to create a screen transitions that are powered by OpenGL shaders and things like that, that's quite impressive. [15:03]
-
-**Carl Vitullo:** Interesting. So it's about, painting. So it's sort of like, is this like a React Native version of Canvas? Sort of? [15:11]
-
-**Mark Erikson:** Just as a little better background Skia is a C++ library for two-dimensional graphics. And my understanding is that most browsers actually use this to literally draw stuff on the screen in the first place, including implementing the HTML Canvas element. So it sounds like this is now, this library is now being exposed as something you can use from React Native to do custom graphics. [15:40]
-
-**Sebastien Lorber:** Yeah, it's exactly that. The idea is that you have a canvas, you have some primitive that you can draw, you can use OpenGL shaders and things like that. [15:49]
-
-In the beginning, I think, maybe last year they released the first proof of concept. And then there was Shopify that was interested in this lib and sponsored it. So now the, the development in is funded by Shopify. I think the first version was more of a proof of concept, and now it's more production ready. [16:09]
-
-I think one of the challenge in the beginning was also that it was not possible to interleave easily the, the canvas inside the native application because somehow the, the canvas was over the native views or it was under, and you have to, to do the trade off of deciding how to integrate the canvas inside your app. [16:28]
-
-So it was a bit complicated to achieve certain visual effects. And now the integration is better. The talk is showing some possible solutions to, to be able to integrate better with native views and things like that. And also to integrate better the canvas with Reanimated, which is the popular animation framework, for React Native today. [16:48]
-
-**Carl Vitullo:** Interesting. Okay. Very cool. So I wonder if using the same primitives as Canvas and the browser, I don't know if this is the case, but I wonder if it will allow a lot more cross compatibility with that sort of graphics rendering. Yeah. That using the same primitive, the same, you know, base tool to bring that into, into native. [17:09]
-
-That, that does seem like a really huge step. Yeah. [17:12]
-
-**Sebastien Lorber:** I think it unlocks a lot of things and we are just in the beginning, yeah. [17:16]
-
-**Carl Vitullo:** Yeah. You know, honestly, that reminds me of the effort to bring Flexbox rendering into Native. So, yeah, I mean, graphics rendering is really hard. It's also really powerful. So if we can have similar primitives for doing graphics rendering on both web and native, yeah, I could see just a little glimpse of what new features that would enable. Yeah. Very cool. That's pretty awesome. Cool. Okay, [17:40]
-
-I'll move this on to our next one. [17:42]
-
-## Struggles with Remix
-
-- [My Struggle With Remix](https://redd.one/blog/my-struggle-with-remix)
-
-**Carl Vitullo:** Yeah. Um, I wanted to share a blog post about someone sharing their struggle with Remix. I think it's good to talk about not just what's great about things, but also where the rough edges are. Um, and this seems like a pretty measured and realistic perspective on where some of the rough parts on Remix are right now. [18:03]
-
-It talks about the developer experience and some of the struggles there. Routing is too magical is one of its points, which I, I do, I, I think I agree with a little bit. It basically has its own DSL, domain specific language, for routing where, as part of the file name, as part of the path for your routes, it does a lot of parsing out of that string and changing behavior based on that. [18:26]
-
-So like having to learn a brand new DSL for routing that you don't really have a lot of control or access into, outside of that, like that, all that, that all happens as part of the Remix dev and build server. It's not super inspectable and uh, definitely a little bit magical. [18:42]
-
-One of the categories of complaints it has is that it gives you enough rope to hang yourself which is both great and terrible. It, it is nice that it is so powerful, but part of the downside of having so much power is that it doesn't do a lot of things for you. [18:56]
-
-This author talks about needing to write a lot of supporting logic for handling things like static assets like you, you put a relative path to an image in your markdown, and then you have to write code that understands how to parse out that relative path and convert it into a, an absolute path when it's actually showing the page. [19:11]
-
-So, I, I, I, this seemed like a really good, I don't know, collection of some of the rough spots in Remix right now. [19:16]
-
-**Mark Erikson:** Uh, again, I, I have not used Remix, so I can't comment on the technical aspects here, but I, I really did appreciate this post because it was very clearly written. it was framed as "these are my experiences and pain points using it," not, "oh no, this tool is awful." it was actually like more of an attempt to say, how can we make this better rather than attempt to bash the tool or its authors. [19:43]
-
-And I appreciate that. Like, there, there's just so many negativity and, you know, "tool X kills Y" being thrown around and I, I, I appreciate it when we can have reasoned debate and discussion about technical trade-offs rather than flame wars. [19:59]
-
-**Carl Vitullo:** Yeah. And I, I appreciate that in the, you know, in the intro setting off the whole post, he says, "I think Remix is a great framework. I will not be mentioning Remix advantages." Uh, it kind of, it reminds me of that scene in the Silicon Valley TV show a number of years ago where they're talking about their frustrations and they, they come up with an acronym for "Richard is great, but." You gotta get that outta the way you gotta "Remix is great, but." [20:23]
-
-So I think this was a great way to, to focus on the challenges without having to extol all of its great virtues of which there are many, it has a lot of great things. [20:32]
-
-**Sebastien Lorber:** Yeah. But the, the author in the end, "I still would use it for a startup," so that's already quite nice. I think the conclusion was he wouldn't pick it again for a blog. I tried also to, to create my newsletter website with Remix in the past, and also I thought it was a bit it had some rough edge, but it was possible to use it, but maybe not the, the simplest solution. But also they focus maybe on low level primitives and a bit on the architecture side. And for example, I'm quite surprised that the author was looking for the, you know, the markdown images to be able to use the relative image path. I don't think it comes for free in many frameworks. [21:12]
-
-I know that does it, but it's not free, it's we have to implement it manually. So maybe NextJS does it. But I don't know. That's not something that for me come out of the box unless the framework is opinionated to where they're using MDX or something like that. But, otherwise not too surprised that this kind of feature is doesn't come outta the box. [21:34]
-
-**Carl Vitullo:** Yeah. Agreed. He mentions. Gatsby doing this for him, and that wasn't my experience. I haven't used Gatsby extensively, you know, in any deep capacity for a number of years now, so maybe something changed, but I, I do remember having to write code that did exactly that when I used Gatsby in about 2018. So, yeah, I don't know. [21:52]
-
-Cool. Mark, you wanna take us off? [21:53]
-
-## You Might Not Need React Query
-
-- [You Might Not Need React Query](https://tkdodo.eu/blog/you-might-not-need-react-query)
-- [Using Apollo Client with Next.js 13](https://www.apollographql.com/blog/announcement/frontend/using-apollo-client-with-next-js-13-releasing-an-official-library-to-support-the-app-router/)
-
-**Mark Erikson:** Yep. So continuing with the, the Next 13 and Server Components theme, a lot of the big questions within the community have been how do data fetching libraries like Apollo React Query, RTK Query, and SWR, work in conjunction with Next 13.4 and React Server Components, and the, the new app directory. [22:19]
-
-And there's a couple, couple big discussions and pieces of news on this front. One is that Dominik Dorfmeister, the maintainer of React Query, wrote a post entitled You Might Not Need React Query, and you should read it because it's, it's a really good post in general, like everything that Dominic writes. [22:38]
-
-Some of the summary here is that , if you choose to do data fetching with React Server Components, well, React Query is a data fetching library and you just chose to use a different tool to solve that problem. That's not to say that React Server Components completely kill React Query because where and how you need that data or some, or if you need some of the specific features of React Query there, there are still very much use cases. [23:10]
-
-But it's, it's that same kind of question of, there's, you know, 3, 4, 5 tools available to solve this problem. If you pick one tool, you probably don't need the other tools that do some of the same thing. Another item is that my Redux co-maintainer, Lenz Weber, recently started working for Apollo and he works on Apollo Client in his day job and thinks about RTK Query in his free time. [23:34]
-
-And he spent a couple months trying to work through Server Components and Apollo and figure out how these things even can work together at all. I'm still not clear on all the details, but he, he put up a RFC document that describes how Apollo and Server Components can even potentially fit together at the technical level. [23:59]
-
-And then there was a blog post that accompanied that, where I believe they put out some kind of a proof of concept library that can help Apollo and Server Components sort of go together. We've been getting a lot of questions about like, so I wanna use Redux, but I also you wanna use Server Components. [24:16]
-
-How do they fit together? And you know, like, to a certain extent, you know, the answer is they don't, you know, both at the, at the technical level and the conceptual level, that's sort of the same thing over here, but it's, it, there's still a lot of open questions around all this stuff. I think that Lenz's proof of concept library is doing some very specific hacks that only work with Next in terms of how it's able to serialize and stream data onto the client. [24:44]
-
-One thing I know when said is you wouldn't want to mix and match fetching data on the server and fetching the same piece of data on the client. It's like it either needs to be done via a server component or it needs to be fetched on the client, but you wouldn't do both for the same piece of data at the same time. [25:04]
-
-The short answer is no one knows what we're doing, we're all trying to figure it out, and there's a lot of open questions. [25:09]
-
-**Carl Vitullo:** Yeah. I mean, how does, when people ask, "how do these things fit together," I think like everyone is still figuring that out because Server Components are such a brand new concept. But you know, there, there's so many different types of server interactions. [25:23]
-
-Like when you're first loading a page, like the data that you need is like, you need to do an auth handshake. Like, do you already have a valid token? You need to load the user settings data, you know, which is my, in my experience, there's like JSON blob for the user that contains, like, do they prefer dark mode, what feature flags are enabled for them? There's, you know, whatever data is initially necessary to render for the page. [25:47]
-
-Then, okay, sure. All of that stuff's loaded. The page is rendered. They're clicking around. Then they need to, you know, they scroll down on Reddit and they need to load more content. Or they submit, they click an upvote button and they need to send something back. Like, all of these are different. [26:03]
-
-Fundamentally, they are server interactions, like an HTTP request is made, A response is sent, whether that's JSON or HTML or whatever. So like superficially, they're all server interactions, but like categorically, like semantically for the user, for the app, they all have very different constraints associated with them. [26:24]
-
-And so like React Server Components very helpful for the first set of those things. Like as you're hydrating, as you're rendering the first HTML that the user will see and interact with, I absolutely understand how Server Components interact with that category of data fetching. But then like the, you know, then there is still the client side mode, like the, if you're doing an infinite scroll interaction, like there is no, the server has nothing to do with that. [26:51]
-
-The server doesn't even know where on the page you are. It has no way of observing that. So that is purely a client side interaction. So, yeah, I, I don't know. I feel like where does this fit in? It is it, it's new. It's, it's a new space. You know, it replaces some of the data fetch, but it doesn't replace everything. [27:11]
-
-**Mark Erikson:** Uh, and another couple examples I think Lenz was pointing to was that Server Components are kind of limited in the sense that it's, it's another way to pass down props to client components. You know, like Apollo has this very powerful normalized cache, so if you like it, it keeps track of items by type and by ID so that it's only re fetching, you know, like the, the three missing to-dos you haven't grabbed out of the 100 that you already have already. [27:41]
-
-And I don't think Server Components can necessarily help with the normalized data use case, and I don't think they can help with the ongoing push subscription use case either. [27:53]
-
-**Sebastien Lorber:** And I think one of the case that Dominik presented was, for the infinite scroll. The idea, for example, was the server component would render, the, the first part of the, the infinite call, maybe the first page and the React Query would be able to kick in later. [28:11]
-
-And you would use React Query for the, for the upcoming page, the, the second page, the third page, and things like that. [28:18]
-
-**Mark Erikson:** Yeah. So a lot of things to be figured out here. Yeah. [28:22]
-
-**Carl Vitullo:** Yeah, definitely. Cool. Sebastian, do you have another link? [28:25]
-
-## Expo Router v2
-
-- [Write Once, Route Everywhere: File System-based Navigation for Native Apps](https://www.youtube.com/watch?v=608r8etX_cg)
-
-**Sebastien Lorber:** Uh, maybe I can just give some little news about the other things that happen that React Native conferences because I know that you won't cover much React Native. [28:36]
-
-Maybe the most important one is the announcement of Expo Router version two. And I think it's important because it shows that actually the using Expo and React Native. For the web is becoming something that is quite serious. I mean, the first version was somehow like a Create React App, but using Ative for creating a website. [28:58]
-
-So it was not so great. It was working because you were able to create an application with React Native and published on the web, but as it was only clientside routing, it was a bit limited and you couldn't really use it for many use case, for example, when you need SEO and anything like that. And clearly the, the Expo Router is progressing to making this much more production ready making less compromises when you create a web application using Expo. [29:31]
-
-For example, this new version will have static routes, so you will be able to pregenerate a static website from your Expo app that you can publish on Netlify or Vercel or, whatever. There are also features that are interesting. For example, universal linking, which means that you use the, the URL forwarding on the mobile app. And this gives a lot of interesting benefits, like the ability to seamlessly transition from your web app to your mobile app and to have universal links. [30:00]
-
-For example, you, you tap a link on an email that you receive on, on mobile and we, it'll open the mobile app if you have it installed, or it'll open the website if you don't have it installed. And there are other things that maybe I should just keep it simple. Expo Router is bringing maybe a, a good experience for the developing website using React Native technologies. [30:25]
-
-And I think it's important because we, we want a shortcut, and I think it's exciting and maybe eventually Expo will catch up on the web with other frameworks and provide more and more features and I don't know, maybe compared with NextJS, someday, I hope it'll be the case. [30:41]
-
-**Carl Vitullo:** Yeah, interesting. [30:43]
-
-My experience with trying to do things and React Native has been the story around navigation is so confusing and different from what I'm used to on the web. You know, like the React promise of "learn once write anywhere" has not been true so far in my experience. Just because the fundamental, the, the base assumptions on mobile for, how do you navigate within the application are so, so different. It, it is learning a brand new context and so it's not learned once I, I do have to learn twice. Yeah. Hmm. [31:15]
-
-Seeing some file system based navigation show up in React Native, anything that brings the experience of navigation on React Native to something more familiar for Web concepts. I'm excited to see that. That makes, that makes a lot of sense. It seems like a big improvement. [31:31]
-
-**Sebastien Lorber:** Yeah. It's not easy to master the navigation in React Native in the beginning. [31:36]
-
-And I think for example, if you look at Expo Router, there are some conventions or things that are not exactly the same as in NextJS because maybe, you know, when you, you target all the platforms, you, you need to think about a few things that NextJS doesn't have to, to think about because As they only target the web they only need to to create conventions that work on the web. [31:58]
-
-But maybe Expo Router needs to, to find some abstractions that work for free platforms instead of just one (chuckles). [32:06]
-
-**Carl Vitullo:** Yeah, for sure. [32:07]
-
-## Improving Performance with HTTP Streaming
-
-- [Improving Performance with HTTP Streaming](https://medium.com/airbnb-engineering/improving-performance-with-http-streaming-ba9e72c66408)
-
-**Carl Vitullo:** I'll, kick us off with our next link. This is, so this is a, a blog post from Airbnb engineering. Airbnb has a history of releasing some pretty influential blog posts on their engineering practices. I know esp, especially in the context of React Native, the Airbnb blog post of, "we're moving away from React Native," uh, still has, I think they wrote that like six years ago and it still has echoes on the ecosystem. [32:33]
-
-But yeah, so they, they, I saw this, you know, improving performance with HDP streaming and it's not directly about React. But I think that the concepts that they're talking about have a lot of overlap with React Server Components because ultimately, you know, the goal for React Server Components is improving first load performance. And so this is one example of a first load performance improvement that can be done entirely in isolation from React and even from JavaScript. [33:02]
-
-Like everything they talk about is an HTML level optimization. But it's also, it's a good background reader on things like network waterfalls, early flush talks about sequencing of loading assets, which I, I think it's, these are things that I had to learn on sort of by trial and error, just sort of realizing like, "Ooh, this has gone badly and I need to figure out how to make it better." [33:25]
-
-And in researching those things, learned a lot of the concepts that are discussed here. So I, I thought this was a really good framing for sort of a background reader on concepts that will be very important to understand as code that takes advantage of React Server Components is being written. [33:43]
-
-Cool. And I guess that's all we gotta say on it (laughter). Yep. Cool. Mark, what do you got? [33:50]
-
-## React Canary Releases
-
-- [React Canaries: Enabling Incremental Feature Rollout Outside Meta](https://react.dev/blog/2023/05/03/react-canaries)
-
-**Mark Erikson:** So the, the React team put up a blog post announcing what they're calling Canary version releases of React. So historically the React team has primarily delivered React as your standard semantic versioning releases. [34:05]
-
-So 18.0 major, 18.1 minor, 18.2 minor. And they've also had an experimental channel, which as the post points out, they'd also referred to as their "next" channel which were just daily experimental daily builds of React, which. In addition to being built every day, also had a bunch of feature flags turned on so that work in progress, experimental features were included. [34:34]
-
-And we've actually been using an experimental build of React at my day job Replay, for a long time now because we've been doing some things with like React suspense in our code base, and those relied on methods that only existed in the experimental builds, not in the public, like 18.1. 18.2 builds. [34:54]
-
-And if you were to go look at NextJS, my understanding is that they have been shipping specific ver like pre-release versions of React with Next for a while now, in order to also make use of some of these not yet final features, and this is actually bringing up a problem for a couple reasons. [35:18]
-
-One is that there's a lot of confusions about what features are actually ready for, for production use. Another is that, you know, you see some people complaining that, well, you know, Next is getting kinda like an unfair advantage in being able to use these features. And third, like it's, it's actually been like a year since React 18.2 came out and we, we, I actually have no idea when 18.3 will even be released. [35:44]
-
-So with this blog post, the React team is announcing that they're going to start releasing a series of canary builds, which are somewhere between like a daily, just whatever is at the tip of, of main build and an official public semantic version in release. So that Canary builds will have these experimental features turned on. [36:08]
-
-And they will actually say ahead of time, here's which ones are basically stable or not. And they're actually encouraging frameworks and, and other packages to try out these features and even say, and even go ahead and use them for real, but to like pin what version you're using to a specific canary release. Not just like whatever one is, is the most recent. [36:33]
-
-And the comment is that sometimes they work for a long time on some of these features and sometimes a bunch of these features overlap and they, they might even be ready before the React team decides to make a new official semantic version of your release. [36:48]
-
-So it, it's good because it's kind of making that like, here's here's some of the work in progress stuff available in a somewhat more official way. It's also really confusing because. It's hard to keep track of what pieces are actually ready or not. And there's, there's a couple examples of this. So like, eight months or a year ago, the React team published an RFC where they announced there was gonna be a new hook called use, which was, it would let you actually kinda like unwrap and await a promise in a, in like a client component. [37:21]
-
-And that RFC was published and there were a lot of comments mostly complaining about the name. And the RFC said there will be a follow up RFC talking about some kind of new caching capability. And like, there's been nothing published about it since then. And frankly, we, like we library maintainers roll, like, "uh, is this thing dead or what?" [37:42]
-
-But apparently it's already like shipped and being used in production in Next 13.4. And so there's a lot of confusion about like, what is the status of these features? So hopefully the Canary builds will ha help make it a little clearer when these features are ready to actually try out. I've also had some discussions with React team members saying like, it would be really helpful if there was like a public list of what features the React team is working on and what their current status is. [38:11]
-
-Kind of similar to how TC 39 develops new JavaScript features. Like is it, stage zero, we have an idea. Stage one, proof of concept. Stage two, it mostly works. Stage three, it's almost ready. Stage four, done. Something like that would really be helpful for the community to understand things, but at least these canary builds are a step in the right direction where it's like a little more ready to try out. [38:35]
-
-**Carl Vitullo:** It's interesting that there's been that much confusion from library maintainers around, really like, what's part of React. I'm a little surprised to hear that that's been a point of confusion because that, that really does seem like a very, very important for both the React team and for library maintainers to both have a shared understanding of, and the core team has definitely been very vocal about being interested in soliciting feedback from and being in dialogue with library maintainers. [39:04]
-
-So that seems like a relatively large communications miss on something that they have talked about being very interested in doing well. [39:11]
-
-**Mark Erikson:** Yeah, and I, I had some in-person conversations with Eli and Lily from the React team at a couple different conferences. It was, it was almost like they were trying to do a listening tour. [39:22]
-
-Like, let's go out, talk, talk to folks in the community, get the pulse of what's going on, hear people's complaints and, and see what we can do about it. I definitely want to give 'em credit for how willing they were to listen to things. I'm hopeful that some of these ideas, like, could you give us like a, a status page of the features and stuff like that will come out of some of those discussions? [39:44]
-
-**Carl Vitullo:** I like the point you made about using TC 39 as a model perhaps, because I think that that framework for feature prioritization and, you know, communicating what's under consideration. I think that that did come about for similar reasons where there were a lot of stakeholders, there were a lot of interested parties who wanted to advance the state of the web in the case of TC 39, the web and JavaScript, well, I guess JavaScript specifically for TC 39, but there were a lot of people who were interested in having a seat at the table, and so they figured out, they put together that mode of communication. [40:21]
-
-And it's, it seems like React is now in a similar place where it occupies a very foundational place in the web ecosystem. You know, it's certainly not as broad as JavaScript does. It's inherently, well, I was gonna say, it's inherently a subset of JavaScript, but you know, I guess with React Native, it kind of, isn't it, it does go a little broader than web and JavaScript, which is interesting. [40:44]
-
-But yeah. You know, maybe that is, maybe that is a model that they could look towards and yeah, I guess if they're doing a listening tour right now, I'll be curious to see what they come back to the community with over the Next couple of months. [40:57]
-
-**Sebastien Lorber:** Yeah. Well, something I found interesting is that, for example in, in the experimental builds of React that NextJS is using, there, there are two new hooks called useOptimistic and useFormStatus that permits to the Server Actions. [41:12]
-
-And they actually are documented in the NextJS documentation, but they are not on the official React documentation. So you, you have to go to the NextJS documentation to, to read more about them. [41:26]
-
-**Mark Erikson:** Yeah. Th this, this was one of the points I specifically brought up, even, even at the uh, React Summit conference a a couple days ago. [41:31]
-
-It's like, I, I realize that, like Dan has, 70 to 80% of this stuff is quote unquote "React". You know, like that, you know, `action={someFunction}` thing is built into React. It's not a Next specific feature, but that also means that there really ought to be information in the React docs about a lot of this stuff. [41:55]
-
-And I, I realize the React team has, you know, limited number of people, limited amount resources, they, and a lot of the stuff is in flight. They can't publish docs on everything right this second, but I would not have expected to look at the Next docs for a React hook specifically. And, and it feels like there is very much a gap in confusion about some of that right now. [42:17]
-
-**Sebastien Lorber:** Yeah. But I think, for Docusaurus, we have been using Canary release, and it's a nice way for them to get feedback from the NextJS team before presenting things publicly to broader audience. So for Docusaurus it has, it has been great to be in beta for long because at, at that time, lots of people were adopting the, the betters of Docusaurus and I was able to get a lot of feedback on, you, you merge a pull request and then one week after you already get feedback on it, even if there is no public release, because people get used to, to using Canary version of your project. [42:57]
-
-And I think also integrating a canary in NextJS like that permits to somehow give the, the new React versions to a broader audience. But we weren't necessarily exposing all the new APIs at once because they're hidden behind abstractions, for example, maybe there are some React APIs that NextJS is using today, but they're not they're not exposed to the, to the users of NextJS app router because they're only used internally inside the inside NextJS [43:31]
-
-**Carl Vitullo:** I think you're right, Mark, about it being unexpected to go to the Next documentation to read something about a beta React hook. I'm sure that there's all sorts of reasons why that was the, you know, most straightforward, most obvious place to put that information. [43:47]
-
-Like, you know, if, if Next is the only place where you can use this right now, I could see why it makes intuitive, logical sense to put that information in those docs. But, given that there has been a lot of confusion and uncertainty and handwringing over the relationship between the React core team and Next specifically, you know, that seems like the sort of communication, I was gonna say communication gap, but maybe not a gap so much as just sending some more signal than you intended. [44:18]
-
-The words they're saying is Next does not have special treatment, but. If Next, if you know the beta features are coming out, are being documented from Next first, and actually not even first from Next only at the moment, then that certainly seems to undercut the words of the message, if nothing else. [44:38]
-
-Yeah. Interesting. [44:39]
-
-**Sebastien Lorber:** And something I just thought about it, but if you look at the Remix team somehow, I, I feel the communication is completely different and the way they approach adding new features has been different in the past. For example they added things in Remix first and then they're trying to backward things to React Router while on for React and NextJS, I think it's a bit the opposite. [45:04]
-
-They try to, to build the abstraction first on, on the React side and then use it on NextJS to dog food. But the, the abstractions on React are working rocky, but maybe this new should be first introduced in NextJS, and if this works great for NextJS users, they could backward them to, to React too. [45:26]
-
-**Carl Vitullo:** Oh, oh, interesting. I see what you're saying. Yeah. That's an interesting thought too. Just sort of a, yeah, we're getting into all the subtleties of PR and comms and API design. All the intersection of marketing and development and developer relations. Yeah. Interesting. [45:42]
-
-**Mark Erikson:** May, maybe, maybe some of the the Next tech writers should actually be filing PRs against the React core docs instead. [45:49]
-
-**Carl Vitullo:** Ooh, ooh. Interesting. Gauntlet thrown (laughs). [45:53]
-
-Cool. Should we go onto the lightning round? [45:55]
-
-**Mark Erikson:** Yep. [45:56]
-
-## Lightning round
-
-### Client-side rendering of HTML and interactivity
-
-- [Client-side rendering of HTML and interactivity](https://web.dev/client-side-rendering-of-html-and-interactivity/)
-
-**Carl Vitullo:** Perfect. Client side rendering of HTML and interactivity, a new post on the web.dev from Google. [46:04]
-
-Uh, it's pretty similar in theme to my, you know, my last link from Airbnb, improving performance with HTTP streaming. Just, I think it has a lot of information about good foundational concepts that will help people be more prepared for writing code when React Server Components are more broadly available. [46:21]
-
-Yeah, Mark? [46:22]
-
-### React Summit, Debugging JavaScript
-
-- [React Summit](https://reactsummit.com/)
-- [Debugging JavaScript](https://portal.gitnation.org/contents/debugging-js)
-
-**Mark Erikson:** Last week I got to go to React Summit. I actually spoke there in the morning, I gave a talk about debugging JavaScript. Honestly, I only saw one other talk, and that's because I spent the rest of the time having discussions with both other speakers and people. But it was a huge conference. [46:36]
-
-It seemed very successful. A lot of atte, a lot of attendees, a lot of great discussions, and I personally had an amazing time getting to meet people. So it was great. [46:48]
-
-### Debugging in React Native
-
-- [Debugging should be easier | App.js Conf 2023](https://www.youtube.com/watch?v=sRLunWEzwHI)
-
-**Sebastien Lorber:** Just a quick mention that debugging in React Native should become easier in the future. It has always been somewhat difficult in the past. Over time there were a lot of different ways to debug in React Native. And none of the methodologies was perfect. [47:05]
-
-And notably you, you could connect your Chrome Debugger to the, to the mobile application and it didn't work so great. For example, you couldn't get the, the network tab to work correctly. And now it, it's going to, to work a bit better in the future, thanks to the work of Expo. [47:23]
-
-### React From Another Dimension
-
-- [React from Another Dimension by Dan Abramov at RemixConf 2023](https://www.youtube.com/watch?v=zMf_xeGPn6s)
-
-**Mark Erikson:** So Dan Abramov did a talk at Remix Conf a couple weeks ago entitled "React From Another Dimension." And it was sort of a couple different points trying to be made. The pitch of the talk was. What if React originally only worked on the server and not on the client, and he actually did a demo where he used like IE6 in a, in like a Windows XP virtual machine and proceeded to build, build out a nifty little like 1990s style webpage and slowly add server-based interactivity to it before he ever actually finally added anything on the client side. [48:01]
-
-And part of it in a sense was this is a pitch for, here's a mental model for how React Server Components work, but it was also a very interesting talk and like alternate history universe, kind of an example. [48:14]
-
-### Server-side rendering React in OCaml
-
-- [Server-side rendering React in OCaml](https://sancho.dev/blog/server-side-rendering-react-in-ocaml)
-
-**Sebastien Lorber:** One link that I found particularly interesting was the, someone posted about creating server side rendering in React. But using OCaml for the server. So somehow they re-implemented the React server rendering in OCaml and um, it's exactly the same, but it doesn't support the, all, all the new things like React Server Components only rendering to string and actually it significantly improved the performance. [48:43]
-
-So I think it's interesting because for example, if you are using OCaml like uh, ReasonML for your application, if you decide to run your server side, your React server in the native language, OCaml, then uh, you can get a much better performance for free because you are using a language that is faster of than NextJS and uh, and things like that. [49:05]
-
-So I thought the idea is interesting and I think it's the first language that I see supporting server rendering of a React application in in another language than JavaScript. [49:17]
-
-### Several links on React rendering
-
-- [The Interactive Guide to Rendering in React](https://ui.dev/why-react-renders)
-- [The Journey of the React Component](https://alexsidorenko.com/react-journey)
-- [React reconciliation: how it works and why should we care](https://www.developerway.com/posts/reconciliation-in-react)
-- [A (Mostly) Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/)
-
-**Mark Erikson:** One of the biggest problems I see that confuses people with React is that they, they don't have a good grasp on the mental model. [49:25]
-
-Like they have the basic idea of components and rendering, but a lot of the real world aspects of how that works confuses them. And there were three really good articles in the newsletter within the last couple weeks that all tackle this idea of how does React rendering work from a different aspect. [49:44]
-
-There was one called The Interactive Guide to Rendering and React from Tyler McGinnis and ui.dev folks. There was a journey of a React component by Alex Sidorenko, who has a great blog post series called A Visual Guide to React Rendering. And then there was an article on React Reconciliation, how it works and why We Should Care by Nadia Makarevich, who has also had a couple previously good posts. [50:07]
-
-They all tackle, you know, some of the same concepts but from different angles. But it's really good information and I think a lot of people would benefit from kinda like going back and reviewing some of those basics to make sure they understand 'em. And then along those lines, I will also toss in my own guide to React Rendering Behavior post as well. [50:27]
-
-**Carl Vitullo:** You gotta, sounds super useful. I love hearing multiple perspectives on the same concept. Super useful. Cool. Sebastian, you got any more? [50:36]
-
-### Spatial Navigation
-
-- [TV Spatial Navigation](https://engineering.atspotify.com/2023/05/tv-spatial-navigation/)
-
-**Sebastien Lorber:** So my last link is about a post of Spotify and implementing TV spatial navigation. So the idea that you use your remote control with the arrow up, down, left, right, and things like that, and you should be able to navigate inside the ui. [50:53]
-
-And the thing is, there is no web standard to, to support this in in the web. So they had to reimplement this themselves by keeping the element that you can navigate to in memory. And I found it, it is a bit interesting because it's quite, unusual topic and I, I see more and more companies doing this. [51:16]
-
-Uh, I know someone two, two persons working at two French companies do doing that also for TV applications. Um, some are web applications, some are React Native applications. And recently we had a talk at React Native connection in Paris about the same subject. So this is basically every time someone needs to create a TV application for using React technology, they do something like this. [51:45]
-
-So if you need to build something for the TV someday maybe it's worth taking a look at. [51:52]
-
-**Mark Erikson:** That's cool. [51:53]
-
-**Carl Vitullo:** Yeah, I think it's also, like, sure, TV, It also reminds me of video game UIs, where you've got a dpad or a joystick. But I think it's also a very powerful accessibility tool. You know, like keyboard navigation is so important. [52:07]
-
-If you, you know, for people who are poorly cited or mobility limited or you know, yada, yada, all sorts of situations where that can be valuable. And yeah, I mean, I, I think that's a really, I think that's a really interesting read to see how people solve that problem. Because if you wanna provide powerful keyboard navigation in a web context, it's not easy. [52:27]
-
-Like, what are you gonna do? Tab index? (laughs) [52:31]
-
-**Sebastien Lorber:** Yeah. No, they, they keep the, the limits in memory. But this is funny because the solution from Spotify and the solution that was recently presented at the React Native Conference were different. For example, I think I remember Spotify is using geometry and trying to figure out which, somehow they, they use maybe APIs like getBoundingClientRect or something to get the positions of the elements on the screen. [52:58]
-
-While the, the other company in France that presented the React Native solution was using somehow recreating a tree, a React tree inside memory so that you know, which are the, the previous and the Next element, but not considering the, the placement on the screen. So it was quite different UX in the end, but uh, the solutions were quite similar. It's just the algorithm to navigate that was different. [53:24]
-
-## Closing
-
-**Carl Vitullo:** Cool. Mark you have any other like lightning round links? [53:27]
-
-**Mark Erikson:** I think we're out, out of, out of items at this point. [53:29]
-
-**Carl Vitullo:** Out of items. Well good cuz we are well over an hour at this point. [53:33]
-
-**Mark Erikson:** Way over time. [53:35]
-
-**Carl Vitullo:** Yeah, that's okay. We had a good time. [53:39]
-
-Cool. All right. [53:40]
-
-Well thank you so much. Thanks for joining us. Thanks for having in the audience for sticking us with us through May in React. All right, Mark, Sebastian, thanks so much for coming up. [53:51]
-
-**Mark Erikson:** Always. [53:52]
-
-**Sebastien Lorber:** Thank you. [53:53]
-
-**Carl Vitullo:** Talk to you guys later.
diff --git a/src/transcripts/tmir-nov-2023.md b/src/transcripts/tmir-nov-2023.md
deleted file mode 100644
index fdc251a..0000000
--- a/src/transcripts/tmir-nov-2023.md
+++ /dev/null
@@ -1,442 +0,0 @@
----
-title: This Month in React (November 2023)
-date: 2023-11-29
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/show/4g3Le83YfsMeI8Fq3cpPeH)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/reactiflux-events/id1661733526)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux)
-
-Chapter list:
-
-- [00:35] Conference news
-- [01:58] TypeScript 5.3
-- [10:24] Kent and Lee, dueling positivity on frameworks
-- [14:58] Next.js 14 and Next Conf
-- [18:07] Using React Server Components without a framework
-- [22:59] Remix 2.2
-- [27:52] Shopify Hydrogen Remix v2 support
-- [29:51] Redux Toolkit 2.0 and related libraries
-- [35:40] CSS improvements - :has() selector, nesting, advanced color functions
-- [37:31] Why you want React Query
-- [39:04] Retrospective on 10 years of JavaScript decorators
-- [40:10] React sourcemaps now available in canary builds
-- [41:47] $22,500 bounty for improving formatter performance
-
-Links discussed:
-
-- Quick hits:
- - [React Day Berlin Dec 8+12](https://reactday.berlin/?utm_source=reactiflux)
- - [Future Frontend conf earlybird tickets](https://futurefrontend.com/blog/ff24/?utm_source=reactiflux)
- - [Render ATL super early bird](https://www.renderatl.com/tickets?utm_source=reactiflux)
- - [State of React closed](https://survey.devographics.com/en-US/survey/state-of-react/2023). Not sure when results will happen. Likely in 2024
- - [State of JS is open!](https://survey.devographics.com/en-US/survey/state-of-js/2023?source=reactiflux)
-- [TS 5.3](https://devblogs.microsoft.com/typescript/announcing-typescript-5-3/)
-- Remix vs Next
- - [Kent](https://www.epicweb.dev/why-i-wont-use-nextjs) – [Leerob](https://leerob.io/blog/using-nextjs)
-- [Next 14 summary](https://nextjs.org/blog/next-14)
- - [Next Conf playlist](https://www.youtube.com/playlist?list=PLBnKlKpPeagl57K9bCw_IXShWQXePnXjY)
-- [React Server components, without a framework?](https://timtech.blog/posts/react-server-components-rsc-no-framework/)
- - [Code](https://github.com/ziir/rsc-demo) – [Demo](https://rsc-demo.timtech.blog/)
-- [Remix 2.2.0](https://remix.run/blog/remix-heart-vite)
-- Hydrogen (Shopify headless ecommerce) [supports Remix v2](https://github.com/Shopify/hydrogen/releases/tag/%40shopify%2Fhydrogen%402023.10.0)
-- [Redux Toolkit 2.0 is _almost_ here! _Hopefully_ shipping by this weekend :)](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-rc.1)
- - [Migration page](https://redux.js.org/usage/migrations/migrating-rtk-2)
-- ⚡️ lightning ⚡️
- - [CSS features roundup (bytes.dev)](https://bytes.dev/archives/237)
- - [https://tkdodo.eu/blog/why-you-want-react-query](https://tkdodo.eu/blog/why-you-want-react-query):
- - [10 years of JS Decorators](https://dev.to/what1s1ove/ecmascript-decorators-the-ones-that-are-real-g96)
- - [REACT SOURCEMAPS FINALLY MERGED WOOHOO!](https://github.com/facebook/react/pull/26446)
- - [Prettier bounty](https://twitter.com/Vjeux/status/1722733472522142022)
- - [claimed by Biome](https://prettier.io/blog/2023/11/27/20k-bounty-was-claimed) – [Full report](https://biomejs.dev/blog/biome-wins-prettier-challenge/)
- - Self-plug: [doing a livestream with Filip Hric tomorrow](https://twitter.com/replayio/status/1727698776125481350)
-- Fun news if we have time:
- - [Angular updated to v17, new docs site](https://angular.dev/)
- - [Docusaurus 3.0](https://docusaurus.io/blog/releases/3.0)
- - [Google-created React components for Google Maps](https://cloud.google.com/blog/products/maps-platform/introducing-react-components-for-the-maps-javascript-api/)
- - [Win95-inspired component library](https://lisandro52.github.io/react-winplaza-98/)
-
-[00:00] **Carl Vitullo:** Thanks everyone for joining us for November's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. I'm Carl, I'm a staff product developer and freelance community leader at Reactiflux. Where you are now, the Discord for React professionals. Uh, Mark, want to introduce yourself?
-
-[00:19] **Mark Erikson:** I'm Mark Erikson. Uh, in my day job, I work at Replay. io, where we're building a true time traveling debugger for JavaScript apps. And outside of Replay, I spend far too much time working on Redux.
-
-[00:31] **Carl Vitullo:** And answering every question about it on every platform.
-
-## [00:35] Conference news
-
-[00:35] **Carl Vitullo:** We're going to try out something new, uh, speaking of conferences in the prep chat. Folks interested in the news may be interested in attending conferences too!
-
-[00:45] We have React Day Berlin coming up on December 8th, with a hybrid online streaming follow up on the 12th. There's also a couple of early bird tickets that were just announced. There's Future Frontend, uh, which is going to be in oh, in Finland. I believe it's being organized by React Finland. That's going to be on June 13th and 14th of 2024. Uh, which competes with Render Atlanta, which is also going to be June 12th through 14th of 2024, and just announced early bird ticket sales as well.
-
-[01:19] There's also a little bit of survey ecosystem news. The wonderful people behind the State of JS ecosystem survey are doing a State of React survey as well. That just closed about two weeks ago. No final word yet on when the results of that will be available, but I've heard that it's going to be early in 2024 and might have Sacha Greif on here to talk about the results when they're ready. So yeah, keep an eye out for that.
-
-[01:46] And also one final note, the State of JS survey has opened for 2023. So definitely check that out, you know, contribute, make it. Give it better data.
-
-## [01:58] TS 5.3
-
-[01:58] **Carl Vitullo:** I'll start us off. First news event that we're going to be talking about here, uh, TypeScript 5. 3 is out. Out of beta, out of release candidate.
-
-[02:08] Looks like it's not a ton of major new changes here.
-
-[02:13] They're adding support for a TC39 proposal, import attributes, that give an inline syntax for module import statements to give more information about what that module is. As far as I know, the only currently supported additional attributes are in support of JSON modules.
-
-[02:34] Instead of JSON modules being sort of like an informal standard that just works, um, this is now formalizing that and giving I'm giving away for more information to be provided about how to import additional modules. So hopefully we'll see this being used for things like image imports, SVGs, fonts, things like that.
-
-[02:54] Um, which currently that's all been just like through Webpack or whatever bundler and whatever plugin, just totally ad hoc based on whatever bundler you're using. So seeing a proposal come in to standardize that is I'm here for it. That's cool.
-
-[03:09] **Mark Erikson:** Yeah, I've seen that the syntax exists. I haven't had it, like, actually, like, most things these days, I haven't had a chance to, like, look at it or play with it yet.
-
-[03:17] Um, like, I've seen the comment that, you know, like, one of the great things about, you know, Webpack and Vite and whatever is that it lets us, you know, mix together, you know, like, I need to import this CSS file, I need to import this, you know, this image file. And then all the processing happens during build time, but it's also true that you're basically almost inventing your own little language, especially if you start adding more plugins to deal with certain build types.
-
-[03:46] And, like, actually, it's a little bit like the React vs. Web component debate. You know, are you supposed to be strictly, strictly using the platform or are you okay with using tools that aren't strictly the platform, build in the specific pieces that you need, but you're, you're, you're maybe kind of conceptually locked in and maybe that's okay.
-
-[04:10] So in this case, I think what we're sort of seeing is that app developers for years have wanted to be able to do things where they are quote importing non JavaScript or TypeScript assets. Into their code for one, for one reason or another, and build tools have supported that for many, many years. And so now we're sort of seeing the little, you know, the trickle down effect where some concept of that is now trickling into the platform.
-
-[04:40] Even if it's not, like, building in functionality to do something with it. But at least now there's a, there's a common syntax for saying, here's a file, treat this specially.
-
-[04:53] **Carl Vitullo:** Yeah, like you were saying, it's, it's not all of the long tail of modules now, but I, I appreciate that it's a low level primitive that will allow for that sort of, that, that later work to be done in a consistent manner. So that's cool. I'm, I'm excited to see that.
-
-[05:09] But another bit that caught my eyes, uh, being valuable is improved type narrowing. If you do a switch with a true case and then, you know, have subcases for different, uh, conditionals, it, the behavior around type inference around there, uh, should be better on, on 5. 3.
-
-[05:27] **Mark Erikson:** That's actually one of the weirder little bits of TypeScript, or actually of JavaScript, really. So, you know, normally with a switch statement, the idea is you have a single variable that could have many different possible values.
-
-[05:40] And the switch case is, if the value is A, do this. If the value is B, do that. And the weird thing is, in JavaScript, you've always been able to say like, switch true, but then the case statements can have actual comparisons that don't even have to do with a single variable. It's kind of like another way of chaining if else statements.
-
-[06:07] And so, this has been legal JavaScript syntax for a long time, and TypeScript is now actually being a little smarter and saying, well, actually, if you're going to do that, we can apply some type level inference to what's going on inside.
-
-[06:20] **Carl Vitullo:** I don't know if this is a widely held opinion, but I've generally viewed that as, that behavior of doing switch true, as like, a little bit of a convenient hack.
-
-[06:29] I don't know where switch cases originated from, but like, I've certainly seen them all the way back to like, C, right? That is very much not the semantics, going back that far in their, you know, legacy. But, you know, that's how people have been using them in JavaScript for a decade.
-
-[06:45] So, acknowledging that and just making it work better, like, that's awesome.
-
-[06:50] **Mark Erikson:** Uh, one other item that I don't, I don't know if it's even listed in these release notes, but Andrew Branch from the TypeScript team has been working on a new set of documentation For the TypeScript website, about how TypeScript understands the concept of module files.
-
-[07:10] So, ESM files, CommonJS files, um, all the different variations in terms of module resolution. And he finally merged that into the actual TypeScript docs a few weeks ago. And there is a ton of information here. I've not even had a chance to read through all of it. But part of this is really long and complex because of how complex the JavaScript and TypeScript ecosystem is.
-
-[07:40] And you know, how many different tools and concepts are interacting. But it's basically an explanation of this is how TypeScript views. The world. And it gives a lot of very good explanations of the theory and choosing a lot of the compiler options and trying to deal with, you know, both using packages and publishing packages.
-
-[08:02] And as someone who has spent a disturbing part of this year banging my head against the wall of publishing packages, uh, this is, having this information available is very valuable.
-
-[08:11] **Carl Vitullo:** Before we move on, I'm just going to read down the list of all the what's new from the blog post. Import attributes, which we discussed.
-
-[08:19] Stable support for resolution mode and import types, which I think is what you were just talking about.
-
-[08:24] Resolution mode support in all module types, so related.
-
-[08:27] Switch true narrowing, what we just discussed.
-
-[08:30] Narrowing on comparison to booleans, uh, which I imagine probably came out of the switch true casing, but also another great, you know, we can narrow types on if statements. That's awesome.
-
-[08:41] Instance of narrowing through symbol has is instance.
-
-[08:45] Checks for super property access on instance fields.
-
-[08:48] Interactive inlay hints for types. I don't even know what that means.
-
-[08:51] Looks like a couple of other optimizations. Consolidation between TSS server library and typescript.js.
-
-[08:58] **Mark Erikson:** That one actually has a little bit of an impact. So, most people haven't noticed this, but if you installed, like, TypeScript version, I don't know, 4. 6, 4. 7, the unpacked file on, er, folder on disk was like 50 or 60 megabytes. And nobody thinks about it, but it's because TypeScript is a really complicated tool, but also they basically shipped, like, three different copies of the same core functionality in different bundles inside node modules.
-
-[09:29] The TypeScript package contents shrank in like 5. 0 because they altered how they build and bundle the TypeScript tools itself. And here they've done further work to say, you know what, actually two of these bundles are basically almost identical, let's extract the common piece so that it's only built once.
-
-[09:50] And then the two bundle files that get used for different purposes just reuse that common functionality. And so the actual installed size of TypeScript has shrunk again down to like, uh, I don't know, like 25, 30 megs? So I mean, it's something. Smaller node modules is always nice. Cool.
-
-[10:12] **Carl Vitullo:** About 20 percent smaller package size on disk after you install TypeScript. Cool, that's nice. Probably going to save a lot of disk space in aggregate across everyone.
-
-[10:21] Alright, Mark, you want to take us on to our next link?
-
-## [10:24] Kent and Lee, dueling positivity
-
-[10:24] **Mark Erikson:** So it's always amusing to me when we have kind of like dueling articles come out. Someone writes, someone writes article A, someone else looks at it and writes article B.
-
-[10:35] So in this case, we had an article from Kent C. Dodds, you know, always very prolific, you know, author and teacher. Who wrote a very long post entitled, Why I Won't Use Next. JS. And he laid out a bunch of reasons here, and there's like a bunch of sort of spin off thoughts that happened.
-
-[10:54] So the first thing is, you know, up front, Kent worked on, as part of the Remix team, for, you know, like, 8 to 10 months. He teaches Remix in his courses. He is a big vocal fan of Remix as a tool. And so, a lot of people ask him, both because he's a teacher and because he likes Remix, "well, why won't you use Next. JS? Or like, why do you prefer Remix over Next?" And so, like any good blogger, he said, okay, I've been asked this question dozens of times, I'm going to go ahead and write an article.
-
-[11:31] And he laid out a whole bunch of reasons, ranging from, you know, Remix is more of a focus on the web platform, it's not part of Vercel, he has some uneasiness with the way Next and the React team are sort of co mingled at this point, he feels it's more stable and does a better job with, you know, managing the pace of changes and it's less complex, You know, frankly, I haven't used Remix, but I actually agree and sympathize with most of the points he's making.
-
-[12:03] I've felt some of that unease with some of the pace of change with Next and the way some of the release processes get managed. Now, a lot of people have complained that Kent has a huge conflict of interest, and I see the comment down there in the chat.
-
-[12:19] I'm gonna side with Kent here. Yeah, he has biases and opinions. This is a post where he is stating his biases and opinions. Like, he's allowed to say, here's why I like this thing. And, you know, people have asked him, what are your thoughts? And so he's documenting that.
-
-[12:37] So, that post was really good. And, you know, got a lot of attention. And a week or two later, Leerob, who is the, you know, the lead developer relations guy for Next, Went out and wrote a post on why he is using Next. And I thought this one was also very well written. Uh, a lot of it is a direct response to what Kent wrote.
-
-[13:00] And I actually liked that both of them were very careful up front to say, like, Here are some opinions, I like this tool, I have preferences, and we even went out of his way to like tweet picture up front of like, "look, here's me and Kent, smiling, we get along, we don't hate each other," but, you know, kind of giving some counter thoughts on, you know, look, Next, Next does use the platform, I like the app router, and, you know, some of the other, you know, features that are built into Next.
-
-[13:30] What I appreciated as a neutral, independent third party is that, these are, these are well written posts, they are basically positive, I mean, they, they express a few, like, pain points and concerns, but they're written in a positive sort of a way, not like a tear everybody else down sort of way.
-
-[13:52] I, I just feel like the entire ecosystem would benefit from more articles and discussions that are organized and pitched with that mindset. So both of those were really interesting. A lot of really good feed for thought there.
-
-[14:05] **Carl Vitullo:** Yeah, I would agree. And both of these come out the day that we recorded October's This Month in React. So I was like, ah, dang it. If we waited a day, we could have discussed these immediately after.
-
-[14:15] So here we are a month later, but yeah, I definitely agree. I'm a big fan of a positive framing of things. I guess, you know, ultimately Kent's post was, why I won't, so that is kind of a negative framing. But the actual content of it is very much, you know, like his, the first heading of it is, "whatever you use is probably fine."
-
-[14:36] I can enthusiastically support anything that Just respects that there are different trade offs, and different people find different trade offs appealing. Only two of the largest people in developer relations for two of the largest frameworks in the React ecosystem having a nice, reasoned discussion with each other in the form of public letters.
-
-[14:56] **Mark Erikson:** And speaking of Next.
-
-## [14:58] Next 14 and Next Conf
-
-[14:58] **Carl Vitullo:** Next14! They announced this at the Next conference, which I'm going to link to a playlist of all the talks there as well. Major highlights here, uh, looks like TurboPack is offering big performance improvements for developer experience locally. They're claiming 53 percent faster local server startup and 94 percent faster updates, so rebuilds.
-
-[15:27] Faster to start, much, much, much faster to rebuild. Sounds cool. As far as I know, the major new feature being rolled out with Next 14 is server actions, which is a React Canary feature that is now being exposed as a first class function in Next. Sounds cool. We discussed that at greater length in the last episode, I think.
-
-[15:49] Partial re rendering, fast initial static response and streaming dynamic content for, I guess, you know, partial pages. Sounds cool. And it looks like they've put out some new educational content as well, teaching about how to use the app router and authentication and databases and stuff.
-
-[16:06] I still have not been able to find a great use case for myself to explore Next, you know, the more advanced Next features like the App Router, uh, in my own time. I'm not currently employed as a full time software engineer, so I don't currently maintain a large scale application, which is, I think, the only way to get real experience with using these, you know, the experience of working on a full team, making decisions in the context of maintaining them for a period of years.
-
-[16:37] Um, so, I'm not going to feel comfortable passing firm judgment on AppRouter, I think, until I've been able to build a real application. So, I don't have a lot to say on the specific details yet.
-
-[16:52] **Mark Erikson:** Yeah, uh, I'm, I'm sort of in the same boat, I mean my, my day job at Replay is technically a Next app, but it might as well be just a, you know, a pure single page application, conceptually. Basically don't make any real use of routing at all.
-
-[17:07] Anecdotally, you know, just looking at discussions on Twitter and Reddit, I, I see a very mixed bag. I, I see people who love the app router and some of the functionality that's built in there. I've seen a lot of people complain that in between the app router and like Vercel's multiple caching layers that there's a lot of pain points they're dealing with.
-
-[17:28] So I see anecdotes, I don't have a lot of, I don't have any personal experience that I can offer in that respect.
-
-[17:36] **Carl Vitullo:** Yeah, and there have been wildly popular framework in the past that had all sorts of blog posts and discussion and everyone raving about how great it was to use. And then a couple years later, everyone started using it for larger scale projects and found all the pain points. And I noticed all of that positivity going away. So, you know, In the interest of not repeating that pattern, I'm just not comfortable passing judgment too quickly here.
-
-[18:02] Want to take us on? Maybe a good segue from Next into Frameworkless.
-
-## [18:07] RSCs without a framework
-
-[18:07] **Mark Erikson:** So, one of the big issues with server components so far, has, well, a number of issues, but one of the issues has been that the only real way to use them has been with Next.
-
-[18:20] And, you know, there's the whole separate discussions over Next sort of getting first access to React features, you know, being sort of a concern, but also, you know, give credit to Vercel because they're literally investing a lot of money and time into building out the core pieces that are in React itself and then making use of those features in Next specifically.
-
-[18:45] So, there's a number of different tools and frameworks that are experimenting with integrating server components right now. I know that the RedwoodJS folks have said that they're all in on server components, and I've seen some of the technical discussions where they're working on it. I've seen, uh, Daishi Kato, who created Jotai and works on Zustend, um, has his own little experimental server components based framework.
-
-[19:13] So, there are a small but interested number of people who have been playing around with trying to build things with server components, but it always, like, needs some higher level of build tool integration to work, and that's by design. So, there was a really, really good post from a guy named, I believe, uh, Tim Tim Pillard.
-
-[19:38] And it's called, React Server Components Without a Framework. And in this post, he kind of breaks down, like, what are the pieces behind server components. Where do server components fit into, like, the build and deploy and usage sequence? And he then kind of dives into, like, what are the pieces inside of React that you would actually need to build your own server components integration?
-
-[20:05] And this was a really, really detailed article. And, is everyone going, like, going to need to, like, dive through this and understand all the inner workings to use server components? No, because you would normally use them just because, you know, Next, or Redwood, or Remix already has them integrated, and you sort of follow, like, the framework version of the docs, for the most part.
-
-[20:30] But, one of the problems with server components has just been that the low level workings have not really been documented so far. So, everyone's either having to look at the very bare bones examples in the React repo, or, in most cases, actually looking at the internals of Next, and trying to figure out, "well, how much of this is something we need to copy and paste, and how much of this implementation is very specific to the way Next works."
-
-[20:58] So, like, everyone's looking at Next's internals and trying to figure out what they're supposed to do. So, having an article that sort of breaks some of this down without any other frameworks involved is actually pretty helpful to understand what's going on inside.
-
-[21:13] **Carl Vitullo:** Most, most definitely. I was pretty surprised at, having never even, I've barely even tried to use server components through Next. So I've had even less exposure to using server components without Next or any other framework. And I was a little surprised at some of the details here, like he mentioned having to use the react-server-dom-webpack webpack plugin, which has no documentation at all for it. So like, ooh, yikes, okay, I've wrangled some complex webpack configs before, and they're hard enough when it is documented.
-
-[21:49] So going, just the setting of transcending the like client server boundary through the bundler without documentation. It's like, oh yeah, okay, we're still in a rough spot here.
-
-[22:02] **Mark Erikson:** There's a whole lot of dragons there.
-
-[22:03] **Carl Vitullo:** There be dragons for sure. So, just, you know, I tried to read through the code to get a general sense of what it would look like.
-
-[22:12] I am a big fan of going from first principles, you know, even if I'm going to stick at the level of, you know, using a framework, I like to generally have a sense of what's going on inside. And, honestly, even reading this code, it was a little bit tricky to unfurl even, you know, what are just internal abstractions that were set up for this little toy example versus what's strictly required.
-
-[22:36] So, yeah, it's definitely, I think, highlighted how rough of a state the experience of using server components is right now. Huge, huge props to Tim for putting this together. I think this is a, I think this will be, you know, regarded as a canonical contribution to the development of server components.
-
-[22:56] You know, just want to applaud Tim for that.
-
-## [22:59] Remix 2.2
-
-[22:59] **Carl Vitullo:** Talked about Next, it's time for Remix. Uh, Remix 2. 2 came out, and, it's interesting. I, so it looks like they are moving away from being a from owning a compiler and bundler step of it and moving towards leaning on Vite. So they, you know, they are claiming, you know, they are now supporting Vite as a bundler internally.
-
-[23:28] Uh, and one of the, one of the things they Called out in this announcement that caught my eye is they, they're saying remix is no longer a compiler remix itself is just a vite plugin. That seems remarkable to me to totally change out the internals of how a framework is operating in that way, transparently and in a way that allows people to opt into it.
-
-[23:52] in advance of the breaking changes being shipped. I think we talked last, it was either last episode or the one before, about the rollout process for new features that Remix is using and I think they're doing it really well. I think a lot of other open source projects could take a, you know, take a page from their book on how to roll out new features.
-
-[24:11] **Mark Erikson:** Yeah, I think I'd seen some discussion from Ryan and Michael over the last couple years that they'd kept their compiler workings internal and abstracted, sort of, I guess, like, in spirit, similar to the way React App tried to hide everything behind a wall, because they were worried about exposing some of the specific knobs to end users, And, you know, that causing trouble for, for future upgrades, you know, like everything, it has trade offs, you know, maybe it made some people's uses of Remix a little bit harder because they couldn't tweak those knobs, but it, it seems like it's also made this particular upgrade process a little easier because now they've, they've swapped the underlying layer entirely and actually sort of been able to get out of the compiler business completely.
-
-[24:57] **Carl Vitullo:** Very cool. Very interesting. It seems like they've made a lot of really good, uh. Choices to set them up for speed of iteration, which I think is a great metric to optimize for. Seeing a comment in the chat, Vite is under scrutiny for using ES modules in development, not convinced this is the best course of action.
-
-[25:15] Yeah, I've also heard some, just in the last day or two, I've seen some blowback. Vite as like, I don't know, the bundle less movement is, I think Next just put out some stuff saying that like, oh, the bundle less Uh, movement has failed, and they talked about how they really tried to make it work with Vite and just couldn't.
-
-[25:34] So, I don't know, curious, you know, we just did a, discussed the comparison of Next and Remix and curious that, uh, Next said, like, ugh, this can't work, we can't make it work. And Remix just Did it.
-
-[25:45] **Mark Erikson:** I'm a little, I'm a little bit curious about what the actual meaning of bundleless in that specific discussion is.
-
-[25:54] I know that in development mode, Vite tries to use ES modules kind of like straight up without, without fully bundling them, but they do actually get bundled for production. And so, like, a lot of the discussion, maybe four or five years ago, was, you know, with, with HTTP2 streaming, and, and like, you know, browsers supporting ES modules natively, we might not have to bundle, you can just have your individual dot You know, JS or mjs files on disk and they can all, like, they can all just get fed out automatically and eventually folks concluded that, you know, based on the number of files that have to be downloaded and dependency, you know, chains and whatnot, that, well, actually, yeah, bundling is still a good idea, but that's really talking about production usages, and so I'm a little confused why I think it was Guillermo Rauch in this case was saying, like, bundleless didn't work and pointing the finger at Vite when Vite does it in dev.
-
-[26:58] So I'm not following all that discussion.
-
-[27:01] **Carl Vitullo:** Thanks for bringing that in. I had forgotten some of that context, but now that you mention it, I know that they have talked over the last six weeks or so about, I know that Next has talked about working to improve the developer experience, and so I wonder if maybe that's the lens they're looking at this from, is they were, they came at it with a goal of making the developer experience better.
-
-[27:21] And we're not able to make the, you know, unbundled files as necessary, actually improve the experience because, right, because of, you know, exactly the same reason that nobody has ever been able to make HTTP a usable experience, uh, just there's constant waterfalls and you request one file and that request more files, which request more and more and more and more.
-
-[27:46] I think that's probably where that came from.
-
-[27:48] **Mark Erikson:** That would make sense.
-
-[27:49] **Carl Vitullo:** I think it's super cool that Remix has been able to make this work.
-
-## [27:52] Shopify Hydrogen Remix v2 support
-
-[27:52] **Carl Vitullo:** Sort of sub Remix news, Shopify acquired the Remix business, so they've been sponsoring development and supporting the team, and it looks like they just shipped the port for Remix 2 in their Hydrogen e commerce headless framework.
-
-[28:09] Cool to see that they are genuinely investing in this, not just sponsoring.
-
-[28:14] **Mark Erikson:** Not just acquire, hiring the team.
-
-[28:16] **Carl Vitullo:** Right, exactly. They didn't just buy the talent. They are genuinely investing in the open source project and then improving their own more narrowly scoped open source development on top of that.
-
-[28:30] So, super cool. It's, I know people have talked about You know, oh, venture capital in open source is, you know, anathema, it's terrible, don't do it. But this looks like a really cool positive outcome for that setting. Okay, Remix, the economics for running that as a venture invested business are maybe, I don't know how you get the growth multiples there.
-
-[28:55] Raising funding to pay yourselves as you develop and then selling to a business that does see a business use case in operating that. This seems like a pretty positive outcome for that, so just, yeah, I appreciate that. Seems cool.
-
-[29:09] **Mark Erikson:** One other little snarky side observation along the way. It's ironic that the React docs emphasize so strongly that you should be using a framework to start any new React project.
-
-[29:21] And of course, you know, the top choices are Next, Remix, Gatsby, (RIP) and Expo. And yet, Remix itself, and like, Vite is relegated to the, "well, if you want to start an SPA, I guess you can, we can't stop you." And yet, Remix itself is now actually based on Vite, which was relegated to that subheader.
-
-[29:47] **Carl Vitullo:** Yeah, low level tools.
-
-[29:48] Cool to see them get used though.
-
-## [29:51] RTK 2.0 (and lots of others)
-
-[29:51] **Mark Erikson:** Okay, so next item, some personal interest here, but it's also actual news, which technically hasn't happened yet, but is about to. We are hopefully about to hit the button on Redux Toolkit 2. 0. Like, so help me, by Sunday, I hope. This is an effort that has been going on since literally the start of this year.
-
-[30:13] When this happens, we're going to simultaneously ship major versions of Redux Toolkit 2. 0, Redux Core 5. 0, Reselect 5. 0, React Redux 9. 0, and, drumroll please, Redux Thunk 3. 0. And all of these are going to have modernized packaging with, hopefully, proper ESM CommonJS compatibility. Modernized JavaScript build output, so we're using the latest, greatest JavaScript syntax and no longer targeting IE11, thankfully.
-
-[30:49] There's some performance improvements. Redux Toolkit now uses Immer 10, which has some noticeable updates in updates, or improvements in update speed. We've cleaned up a bunch of deprecated options and added some new features. A migration guide page already up on the website. There may be a couple last Tweaks that need to go in there.
-
-[31:12] Our hope is that for a lot of apps, it might just be bump the versions and you're done, but we've tried to call out all the things that qualify as either really breaking changes or like this could sort of be considered a breaking change.
-
-[31:29] The one last thing that is sort of holding up the release at the moment is I am about to pull the trigger on changing some of the default behavior for the Reselect library. Reselect has been mostly unchanged ever since its release in terms of how the internals work. It's sort of doing one reference equality comparison for every argument, basically. And if any of those have changed, then it recalculates. But you can swap out the comparison function to do, like, shallow equality, or whatever.
-
-[32:04] CreateSelector has always had a default cache size of 1. If you, like, alternate the arguments back and forth, it'll never memoize, because it's like, "This doesn't look like the last thing you gave me. Recalculate. This doesn't look like the last thing you gave me. Recalculate." And so you kind of have to go through some shenanigans to handle cases where, like, you want to use the same selector in a list item component, but you're passing in, like, the ID of the item as an argument or something.
-
-[32:36] And I had updated reselect a couple years ago to be able to have a larger cache size, but you had to specifically pass in that option. So earlier this year I actually copy pasted this super secret caching function implementation from the React code, and it uses weak maps to form like a tree of cache data.
-
-[33:01] And the net effect is it kind of basically becomes like an infinite cache size with no further work needed.
-
-[33:09] **Carl Vitullo:** Oh, interesting.
-
-[33:10] **Mark Erikson:** And so what I've been debating is, is it worth switching Reselect's default behavior over to use that? As the default preferred approach. And I've, I've been waffling and debating the pros and cons and the trade offs.
-
-[33:25] And I think I'm actually about to do it. One observation I'll make is that technically an infinite cache size is also synonymous with a memory leak, like, you know, sort of looks the same way. Weighing a couple of concerns around that. But I think the improvement in the default behavior is going to be nice enough that it's worth making that switch.
-
-[33:45] And we'll sort of document, like, here's the trade offs with the new built in approach. So, you know, that's the kind of stuff that's been on my mind trying to finalize this over the last couple of weeks.
-
-[33:57] I'm actually literally hoping to make that change to the code tonight, document it, update the release notes, do some, do some hopefully last minute real world ish testing, and then hopefully ship this by the weekend, I hope, because I really don't want to spend December like, while I'm traveling, having this stuff on my mind.
-
-[34:16] **Carl Vitullo:** I remember that being, like, kind of the number one gotcha with, you know, Idiomatic Redux, you get a lot of really great performance characteristics if you get all the selectors just right, but it became kind of a puzzle of how to set it up just right to get there. You know, like, if you, like you said, if you end up having a list of things where you want to select items out of it, then you needed to, like, you needed to instantiate the selector in just this right certain way, so it was actually memoizing, so you actually got the performance benefits. So yeah, very cool. That makes a lot of sense for changing defaults to make it give you good performance in a wider range of circumstances.
-
-[34:54] **Mark Erikson:** Right, so I mean, it ultimately boils down to, I think the, it'll be a small but meaningful improvement to developer experience.
-
-[35:02] Uh, similarly, we've actually added a couple development mode checks to reselect. Sort of similar in spirit to like, you know, how strict mode works with React components. To watch for things like, you know, your input functions are returning a new reference every time, so this selector never actually memoizes. Or, the output function just returns the value it was given with no transformation, which, either of those means you're holding this wrong. Stop it.
-
-[35:34] **Carl Vitullo:** Cool, I'll move us on. I guess that's the end of our full discussion links, so we're into the lightning round now.
-
-## [35:40] CSS improvements
-
-[35:40] **Carl Vitullo:** Couldn't find a better source for this than just a newsletter that I was reading, so I'm posting that.
-
-[35:45] But some good CSS improvements coming out, like the hasSelector, which is something I've needed on a number of occasions and just never found a way to do it. So I'm excited to see that like browser support is currently there to where you can just use this. You can select nodes in the DOM that contain something else.
-
-[36:05] Previously, selectors were sort of upward looking, like you could, you could select, you could narrow in on children under specific parents, but you couldn't say For all parents of this type of thing, style it this way. So it sort of reverses the direction of control for CSS, or gives you a mechanism to do so, which just unlocks a whole other category of things that you can do with CSS in a way that I think is super powerful.
-
-[36:31] There's also CSS nesting, which is Virtually the only reason I still use Sass anymore, just being able to write rules instead of a series of long lines just like wrapping, you know, nesting them under each other for related selectors. And I don't know that this is one that I would use myself specifically, but I think it's pretty cool.
-
-[36:53] a color function for more advanced control over what color space you're using, which not something I need very often in developing web products, but if you're doing something a little bit more like creative coding, artistry, or trying to correctly render colors in a specific setting, like if you know that this monitor can render this color space accurately, use that rather than sRGB.
-
-[37:19] Um, as somebody who has done a lot of photography and gained an awareness of color spaces through trying to do prints and things like that. I appreciate that this exists, that this is now a function that can be used in CSS.
-
-## [37:31] Why you want React Query
-
-[37:31] **Mark Erikson:** So, Dominic Dorfmeister, aka TKDodo, the maintainer of ReactQuery and Uh, tanstackquery put up a really good post talking about why you want ReactQuery.
-
-[37:43] And I believe this was kind of inspired by a, you know, kind of a tweet that was going around showing like, "look, here's a fetch call and a useEffect. It's like 10 lines of code. How many bugs are there?" And the answer is a lot. And some of it's, some of it's bugs, some of it's, well, here's a bunch of edge cases you didn't take into account, like this, this doesn't have error handling, this doesn't deal with, you know, double fetching in strict mode, this doesn't deal with handling, you know, resetting data or error separately.
-
-[38:14] And so, Dominic kind of walks through the process of, like, if we were to make this 10 line example properly robust, Here's all the added complexity that the example skipped over. And dealing with that complexity is not a thing you want to write for yourself. And this is actually why it's worth using a library, like ReactQuery, Apollo, SWR, RTKQuery, to manage that for you.
-
-[38:44] Because all that really complex logic has already been encapsulated inside the library, you would have had to write this yourself anyway. You wouldn't have thought about it, just use the library. It deals with it for you, it will handle it correctly. But very worth reading to get a sense of here's all the edge cases involved.
-
-## [39:04] Looking back on Decorators
-
-[39:04] **Carl Vitullo:** Cool. I just liked this post. It's not necessarily newsworthy, it's not something new, but 10 years of JavaScript decorators. Decorators have been around in various states for 10 years. It's been 2013, yeah, that I first started hearing about them. You know, Angular went pretty hard on them. There was MobX went pretty hard on them.
-
-[39:26] The actual standardized proposal for how to add them to JavaScript just languished for So, so, so many years. Uh, so I just appreciated this, you know, retrospective on the evolution that decorators have gone through over the, over the years and all the reasoning why it got stalled out and thought it was a good read on a relatively common but very confusing part of the
-
-[39:51] **Mark Erikson:** JavaScript language.
-
-[39:52] I would expect that most people who have used decorators have never thought about what's actually going on under the hood or the fact that the definition and the implementation has changed multiple times.
-
-[40:03] **Carl Vitullo:** Yeah, MobX or Angular, were not exactly shouting about how this is an unstable feature and it has not landed yet.
-
-[40:09] Cool, wanna take us on?
-
-## [40:10] React sourcemaps generally available
-
-[40:10] **Mark Erikson:** Okay, so, another sort of personal note, this is one I've been harping on literally for months. So, way back in like, March, I filed a pull request to modify React's build system to actually generate source maps for production build artifacts. And the PR kind of sat there for a number of months.
-
-[40:32] Uh, Dan briefly tried to review it, and we had gotten some back and forth about, you know, some of the nuances of behavior. I am very happy to report that as of a couple weeks ago, this has finally been merged, and it is actually shipping in React builds right now. And you can verify this if you were to go to, for example, unpkg, and look at React, uh, React or ReactDOM.
-
-[40:57] And if you were to select one of the experimental or the canary builds, uh, experimentals are generated pretty much daily, canaries kind of like every couple weeks or so, you would see that the source map files actually exist in published builds of React today. Now, of course, This brings up the question, when will the next stable build of React come out?
-
-[41:19] Who knows? I'm hearing rumors that they're working on, towards an actual React 19. This doesn't exist in a stable build yet, unfortunately. But when the next stable build comes out, it should actually have source maps. I'm very excited about this. It's not necessarily going to benefit everybody all the time, but it's a missing piece that fills in and anyone who's trying to peek inside React in production will hopefully have a better experience.
-
-## [41:47] Formatter performance bounty
-
-[41:47] **Carl Vitullo:** There was a bounty put out for improving performance of code formatting. Uh, the Prettier organization put out a 10, 000 bounty that was then doubled by, I think by Guillermo Rauch.
-
-[42:02] **Mark Erikson:** I think so, yeah.
-
-[42:04] **Carl Vitullo:** I believe the specific criteria for the bounty was a Rust based formatter that passed like 95 percent of the test cases that Prettier has.
-
-[42:14] And. Yeah, it got claimed. The Biome organization, which is a fork of Rome after that project collapsed, came together and less than three weeks after the bounty was posted, they claimed it. So it was 10, 000 from Prettier, 10, 000 from Guillermo Rauch, and then I think another like 2, 500 or like 2, 250 from an unnamed anonymous donor as well.
-
-[42:38] So yeah, cool.
-
-[42:39] **Mark Erikson:** There was something in the Wasm ecosystem, I think.
-
-[42:42] **Carl Vitullo:** Okay, something like that, yeah. Pretty interesting. I like the thought of open source bounties. I think that's an interesting monetization strategy. It's better than nothing, better than just putting a request out. So I appreciate that some companies were, or some people who had funding were willing to put their money where their mouth was on moving the, advancing the state of the ecosystem.
-
-[43:05] **Mark Erikson:** Yeah, there's a couple nice little extra points here. One is that Fabio Spampinato, I believe is his name, got nerd sniped into looking at the actual prettier source code and trying to find ways to speed it up. And sort of similar to how Marvin Hagemeister has been doing this whole series of blog posts, I'm like, I looked inside this JavaScript tool and it's doing stupidly inefficient things inside. And I made it run faster.
-
-[43:29] Uh, Fabio has been able to find a number of inefficiencies and PerfBottlenecks inside Prettier, and has some proof of concepts of making Prettier itself significantly faster, either through caching or improving cases where it was doing, like, file system lookups.
-
-[43:47] I think it even maybe inspired a PR to Node itself, where the fs. stat call was eagerly creating date objects for file times. And it turn like it turns out, you can just lazily instantiate the date object. Like it already knows the numeric times, but you can just l load the date object when it's actually accessed off the stat object. So like there's sort of a ripple effect of performance improvements going on here.
-
-[44:21] And then the other one was. Uh, Christopher Chedeaux, um, handle vjeux put up a comment on Hacker News describing why he decided to go the bounty route. And it had to do with, like, the best way to improve the ecosystem as a whole is to have multiple competing tools that are sort of egging each other on.
-
-[44:43] And so he wanted to get someone else working on it and then see that kind of ripple effect in let's, let's make all these tools better. And he feels that the money was very, very well spent in that way.
-
-[44:55] **Carl Vitullo:** Cool. Want to take us on?
-
-## [44:56] Mark's self plug, Replay.io webinar
-
-[44:56] **Mark Erikson:** Yep, uh, so we're, we're almost out of time, uh, one more kind of self pluggish kind of a thing.
-
-[45:01] So as I said, my, my day job is working for Replay. io, which is a time traveling debugger for JavaScript. Uh, we've been doing a lot of work this year around not just debugging applications, but building features to help people debug flaky test suites. And so, uh, tomorrow, I'm actually gonna be holding a livestream slash webinar over in the Replay Discord.
-
-[45:26] Uh, my teammate, Philip Crick, has done a lot of work over the years with Cypress and test stuff. And so we're gonna have a discussion tomorrow talking about, like, just debugging. This is actually one of my own personal hobby horses. Like, nobody teaches people how to debug. Conceptually, so we're going to spend some time talking about like, how do you think about the process of debugging?
-
-[45:54] And then we'll look at, you know, replay the tool specifically and talk about some of the features and how you use it to actually dig into an application. So I'm excited. Should be fun.
-
-[46:04] **Carl Vitullo:** Very nice. Always here for a, for a live event, a live chat. Yeah, Phillip reached out to me to talk through what that experience is like. So I hope it goes well.
-
-[46:11] Cool. Okay. That was the last of our lightning round links. Uh, we had a couple of Bonus items, they're a little bit broader, uh, like for instance,
-
-[46:20] Angular has a, they're on version 17 and shipped a new doc site, so, cool, good for them, looks great.
-
-[46:25] Docusaurus 3. 0 was released, which, now that Sebastien isn't here, I feel, I feel like we need to keep bringing in some of the, uh, Docusaurus.
-
-[46:34] **Mark Erikson:** We owe it to him.
-
-[46:35] **Carl Vitullo:** We owe it to him, yeah, right, right, right, he's been such a great part of this show.
-
-[46:38] **Mark Erikson:** The biggest couple updates there are, it now uses React 18 and they've updated the MDX parsing library, so it uses the latest and greatest MDX syntax for intermingling, uh, markdown and react components.
-
-[46:54] **Carl Vitullo:** I got two more.
-
-[46:55] Google has officially released a set of react components for using the Google Maps API. Uh, so I, I think the. Projects like this have existed, but this is the first time one from Google, maintained by Google, has been released.
-
-[47:11] So that's cool. And my last one, this is just fun and silly, but somebody made a Windows 95 inspired UI toolkit for React. So, you know, I love, love a nostalgic style.
-
-[47:23] **Mark Erikson:** Yeah, I've, I've seen a bunch of, like, you know, Win95, 98, 2000 XP, like, CSS packages and, and online demos. As, as someone who grew up with that era, it's, it's always very interesting to see.
-
-[47:38] **Carl Vitullo:** It is now safe to turn off your computer.
-
-[47:41] All right, that's all we got. Thank you so much for joining us.
-
-[47:45] We'll be back next month on the last Wednesday here in the live stage of Reactiflux or back in your podcast feed as soon as we can, hopefully by the end of the month. If you see anything newsworthy in the meantime, definitely let us know in the Tech News and Reads channel. We do use that for sourcing new links.
-
-[48:02] And yeah, you can discuss them with the community in the meantime. All right, thanks so much, everyone.
diff --git a/src/transcripts/tmir-october-2023.md b/src/transcripts/tmir-october-2023.md
deleted file mode 100644
index fc725ee..0000000
--- a/src/transcripts/tmir-october-2023.md
+++ /dev/null
@@ -1,379 +0,0 @@
----
-title: This Month in React (October 2023)
-date: 2023-10-25
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, and Mark Erikson as we break down This Month in React. We'll break down what's new in an hour-long conversation about React Forget, Canary Releases, Barrel Files, TanStack v5, Yarn v4, and a preview of RTK Query v2."
-people: "[Carl Vitullo](https://twitter.com/vcarl_) and [Mark Erikson](https://twitter.com/acemarke)"
----
-
-- [Spotify](https://open.spotify.com/episode/4xefEOVBMI7mhfOBvOPnDV?si=NKLNBgn3TqOH7HLNLAIMHw)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/tmir-2023-10-react-forget-canary-releases-barrel-files/id1661733526?i=1000633089166)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux/episodes/TMiR-2023-10-React-Forget--Canary-Releases--Barrel-Files--and-new-releases-e2b7tda)
-
-
-
-- [00:00] Introduction by Carl Vitullo and Mark Erikson
-- [01:04] React Forget and memoization ([02:00] Optimizing performance, [02:35] Used in production at Facebook)
-- [03:52] React Server Actions in canary release ([04:09] Versioning policy)
-- [05:40] TanStack Query v5 release ([06:02] New features, [06:13] Deferring changes for Redux Toolkit Query)
-- [07:42] Barrel files and performance ([08:47] Avoid for build performance)
-- [09:13] React useTransition for concurrent rendering
-- [10:37] Photoshop on the web ([11:07] Collaboration between Chrome and Adobe)
-- [12:42] Yarn v4 release ([13:31] Per-project installs, [14:38] Performance improvements)
-- [15:19] HTTP QUERY verb proposal ([16:05] Standardization for query APIs)
-- [17:01] TC39 group for standardizing source maps ([18:31] Improve debugging)
-- [19:00] Parcel performance improvements ([20:16] Data structure optimizations)
-- [21:04] Replay DevTools time travel talk by Mark at React Advanced ([22:17] Peeking inside React internals)
-
-In summary, this month focused on performance optimizations like React Forget and query API standardization, as well as releases like TanStack Query v5 and Yarn v4. Mark also discussed his React DevTools talk diving into time travel and hacking React internals.
-
-- Mark: React Forget and memoization:
- - Sathya, React India: [Statically analysing React components for fun and profit](https://www.youtube.com/watch?v=kjOacmVsLSE)
- - Joe and Mofei, React Advanced: [Understanding Idiomatic React](https://www.youtube.com/live/tUqY9CP38uE?si=lQTtR0ZUklVhe4it&t=5364)
- - TkDodo: [The Uphill Battle of Memoization](https://tkdodo.eu/blog/the-uphill-battle-of-memoization)
- - Response: [React memo is good actually](https://timtech.blog/posts/react-memo-is-good-actually/)
-- Carl: [Server Actions in canary](https://github.com/facebook/react/blob/main/CHANGELOG-canary.md#october-5-2023-1830-canary-546178f91-20231005)
- - [Version policy](https://react.dev/community/versioning-policy#canary-channel)
- - [Client Actions](https://codesandbox.io/s/react-client-actions-l5729f?file=/App.js)
-- Mark: [TanStack Query v5](https://tanstack.com/blog/announcing-tanstack-query-v5)
- - RTK 2.0: we’re deferring all RTKQ changes until _after_ 2.0!
-- Carl: Barrel Files
- - [Vercel - How we optimized package imports in Next.js](https://vercel.com/blog/how-we-optimized-package-imports-in-next-js)
- - [Speeding up the JavaScript ecosystem - The barrel file debacle](https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-7/)
-- Mark: [React useTransition: performance game changer or...?](https://www.developerway.com/posts/use-transition)
-- Lightning round ⚡️
- - Carl: [Photoshop is now on the web!](https://medium.com/@addyosmani/photoshop-is-now-on-the-web-38d70954365a)
- - Mark: [Yarn 4.0](https://yarnpkg.com/blog/release/4.0)
- - [HN](https://news.ycombinator.com/item?id=37985779)
- - Carl: [HTTP QUERY verb](https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html)
- - Mark: [TC39-TG4 - New Task Group created to standardize Source Maps](https://www.ecma-international.org/news/ecma-tc39-ecmascript-initiates-a-new-task-group-to-standardize-source-maps//)
- - Actual working group: [https://github.com/tc39/source-map-rfc](https://github.com/tc39/source-map-rfc)
- - Example: a proposal for tracking scopes data from my Replay coworker Holger Benl: [https://github.com/tc39/source-map-rfc/pull/53/files](https://github.com/tc39/source-map-rfc/pull/53/files)
- - My own React Sourcemaps package: [https://github.com/markerikson/react-prod-sourcemaps](https://github.com/markerikson/react-prod-sourcemaps)
- - Carl:
- - ~~[Astro 3.2 - View Transitions improvements](https://astro.build/blog/astro-320/)~~
- - [7x perf improvement to Parcel bundling](https://vxtwitter.com/devongovett/status/1712169214872867288)
- - [Neat SIMD/Rust function](https://twitter.com/devongovett/status/1712169225786446111)
- - Mark: [My React Advanced talk: Building Better React DeTools with Replay Time Travel](https://blog.isquaredsoftware.com/2023/10/presentations-react-devtools-replay/)\*\*
-
-[00:00] **Carl Vitullo:** Everyone, thank you for joining us for October's This Month in React. We have a solid amount of news this month. Excited to talk through it with y'all. Some news before we get going. Sebastian Lorber, our past co host and author of the This Week in React newsletter, Is not going to be joining us as a regular co host anymore.
-
-[00:19] He is he's a new father. He just had a kid, so he is taking some well deserved time to be a new dad. He's also gonna be taking a break from the newsletter and he'll show up now and again as a guest, but he's not gonna be showing up every month like Mark and I will be and community news. We the star helper committee is finishing up evaluation for Q three.
-
-[00:42] So we should have some new star helpers. Ready to go in a couple of days here. Thank you so much for joining us for this month in react, where we recap and digest recent developments in the ever evolving react and web ecosystem. I'm Carl Vitullo. I'm a staff product developer and freelance community leader here at reactive flux, the discord for react professionals.
-
-[01:00] And I'm sure everyone knows Mark, but Mark, can you introduce yourself?
-
-[01:04] **Mark Erikson:** Hi, I'm Mark Erickson. I maintain the Redux family of libraries. My day job is working at Replay. io, where we're building a true time traveling debugger for JavaScript applications. And I sort of stick my head in anywhere there's a text box on the internet.
-
-[01:20] **Carl Vitullo:** That is entirely too true. Cool, you want to take us off on our first link?
-
-[01:25] **Mark Erikson:** Two years ago, at the online React conf, the React team announced an early work in progress React optimization compiler, codenamed React Forget, and they had a video demo, and the idea was that this compiler could automatically rewrite the logic in your React components.
-
-[01:48] To do a few different things. One was to replace the need to stick use memo and use callback everywhere. And another is that by actually memoizing the JSX elements that your component returns, it could actually optimize the rendering and performance behavior of the application, but they'd been kind of quiet about it.
-
-[02:10] And they gave a brief update back in a React Lab blog post back in March, where they said, you know, we're working on it, we're doing testing internally at Facebook, there's still a lot of work left to do. I've been keeping an eye on this, and kind of like stalking the folks who are working on this compiler anytime they pop up on Twitter and happen to say anything about it.
-
-[02:35] The good news is, That the React Forget compiler team has popped up and actually given a couple conference talks in the last couple weeks. And they've given us a lot of updates and new information about the status of this compiler. So the first one is that Satya gave a talk at React India, where he kind of laid out what are, what are some of the problems?
-
-[02:59] What does the compiler try to do? Um, gave some examples of cases where really hard situations where maybe you reassign a variable to a different name. And then the compiler has to figure out that these two things are actually the same and how does it try to deal with that? And that was kind of a high level look at what the forget compiler does.
-
-[03:20] But the one that I was really, really waiting for was actually just this week at react advanced. Uh, Joe Savona and Mo Fei Zhang gave a talk entitled, uh, Understanding Idiomatic React. And part of the idea here is that, if your components are correctly written, and follow the, the rules of React, In terms of being pure or not having side effects and that sort of thing, the compiler can make some good assumptions about how to actually rewrite the code inside of there.
-
-[03:52] They, they showed kind of a demo of a playground that they use internally where the compiler will rewrite the logic and it shows what the transform code looks like. And they also gave a status update. And some details. So they said that it's actually being used in production in two different applications.
-
-[04:12] One is the Quest VR goggle store for React Native. And the other is Instagram for web's profile page. And what they said is that in both cases they, they sort of expected that, you know, we're probably going to run into a lot of problems. And I think that in both cases, the code basically just worked and there were some modest performance increases out of the box in terms of initial mount time and re render time.
-
-[04:45] So at the moment, it sounds as if the compiler handles, I think they said like. 95 percent of JavaScript syntax and they've tested it against thousands of different components internally at Facebook. So at this point, they're, they're pretty confident that what they've built works. There is a lot more polish left to do, aren't going to open source it until they are confident it's ready for public usage and they have the bandwidth to offer support for doing it.
-
-[05:20] But I, I've been very tentatively hopeful for like the last couple of years that this is an effort that would actually work out. And after hearing the talk and I actually was sitting next to Mophie at dinner at the conference on Wednesday and was asking her a lot of questions about like, how does this work?
-
-[05:37] What's the status? I am actually very, very excited about this. I honestly think this will have a bigger impact on the react ecosystem in a lot of ways, then react server components will, I mean, they, they solve different problems. They're both useful, but I think this will actually, this is actually a very, very big deal.
-
-[05:58] And then finally, you're related to that. Uh, there were two different articles that came out, uh, kind of back to back with each other. They were actually kind of arguing about how often should you use. The use memo and use callback hooks and some discussion of are you using optimizations in the components?
-
-[06:19] Are you using them just in case a child component might worry about trying to optimize its rendering behavior? And there's a lot of very, very good points being made in both of these articles. But part of my takeaway here is that in a hypothetically perfect future world. The react for that compiler could eliminate the need for us as application developers to even have to worry about that sort of thing because it will all just magically happen and it's good.
-
-[06:51] **Carl Vitullo:** I do like that. One of these conference talks was talking about idiomatic react. I feel like that has always been, you know, through my career, I feel like in all of the different workplaces I've worked at, I felt that I have worked towards a better understanding of what is meant to be idiomatic, like not just What do I enjoy using?
-
-[07:10] What, you know, how do I understand it? But like, how did the original authors intend for this to be used? So seeing a talk about those idioms, about what, you know, how the tool is meant to be used in this context of this compiler that is supposed to make many of those ideas work better or more easily, I feel like it really ties together.
-
-[07:32] Here's why we built it this way. And here's why we recommend these things that are not always Easy or convenient or, you know, transparently improvements. So, uh, I, I like that a lot. I have, I haven't watched this talk. Um, I'm not super familiar with react forget and it's, you know, development and capabilities, but, uh, just purely on, you know, the, the name of the talk.
-
-[07:57] I, I, I love that. I think that's a really good framing.
-
-[08:00] **Mark Erikson:** Conceptually, what happens is that it's a compiler, it knows how to parse your own JavaScript source code and all the arbitrary JavaScript logic you have in your component. Declaring variables, mapping over arrays, conditional logic, use memo, use callback, whatever.
-
-[08:18] It's a compiler. It automatically transforms patterns A, B, and C. Into patterns X, Y, and Z. And so it can do the automatically memoizing you're like automatically handling dependencies for use memo or something like that. But the, in terms of like the, the rendering performance wins, most of us have heard about the react.
-
-[08:42] memo API that you wrap around a component. to keep it from re rendering when the props haven't changed. But there is a little known built in React optimization where if your component keeps around a JSX element reference like, you know, the return of angle bracket div or angle bracket my component And it returns that same element object the next time it renders.
-
-[09:11] React sees that and says, Oh, you're like, you're literally, literally asking for the same thing as last time. I'm just going to skip over that. And it's a little bit like the parent component controlling the memoization of that subtree rather than the child component needing to be wrapped in react. memo to control it.
-
-[09:31] And this has been in React for years, um, even like the first versions of React Redux relied on that optimization approach. And so, part of what the React Forget compiler can do is rewrite all the logic in your component so that it memoizes pieces of your JSX output so that those element objects only get recalculated when the data they need changes.
-
-[09:56] And thus, the automatic rendering optimizations kick in. We can debate whether this is, you know, a, a better approach conceptually, then I don't know, signals and observables and, you know, the various other performance improvements that are being used in the ecosystem today. One nice thing is that this is a build step.
-
-[10:16] So you don't actually have to change any of your code in theory to get the advancements. I don't have a good grasp on exactly how much it slows down the build step. I think Moffay said something like 3, 000 components was taking maybe like a couple minutes? Something like that?
-
-[10:35] **Carl Vitullo:** That's not short. That's interesting though.
-
-[10:37] I where I'm picturing this being beneficial. I can think of many, many times when I have written use memo, you know, use callback optimizations because I want to hint to react that like these are stable references. I know that, you know, by by doing this whole chain all the way up from like the inside of this hook to a component to the transformation being done on that data to where it's being passed in.
-
-[11:04] Thank you. If I want the best possible performance, I need to be intentional about when those references change. And so it sounds like this compiler is trying to do that same kind of logic where I would do it manually, you know, take it in my head and then write it all out. Which often I have found myself backed into a corner where it's like, oh shit, if I want to fix this reference, I need to totally fix all of the other logic around this because I have conceptualized the problem incorrectly.
-
-[11:32] So something I've said about hooks in the past is a lot of the time it has felt more like solving a puzzle. It's like, there is a right way to mod, there's a right way to model this problem. And I end up going down like three dead ends before it's like, ah, here's the one where all the references are stable and all the state is correctly modeled, which is difficult.
-
-[11:56] It takes a lot of work. It takes a lot of time and takes a lot of thought. And then sometimes there's a new requirements like, oh, shit, I can't just casually add this because I spent all this time modeling to a different problem. And now the problem has changed. So that has been a recurring pain point of mine in developing with hooks.
-
-[12:14] So. A compiler that gets me 80 percent of the performance benefit of doing it perfectly without many reworks and, you know, deep problem solving. Sounds pretty great.
-
-[12:27] **Mark Erikson:** Yeah, like it's not going to magically fix every single performance issue or problem with your react code, but if it offloads a lot of the mental overhead that we have trying to think through some of those issues, that alone is a really big deal.
-
-[12:42] Yeah,
-
-[12:42] **Carl Vitullo:** most definitely. Onto our next one, I'm very excited because this is, we've got a new canary out, server actions are now in canary. So this is, server actions came out in next recently. I think we talked about it last month or maybe a month before and yeah, now they're officially in the like react canary channel.
-
-[13:04] More of what I wanted to discuss here is sort of the canary release process. Yeah, yeah. So in announcing this, they linked to their. versioning policy specifically saying, like, look, this is how you use canaries. Uh, and the big thing that it said is canaries must be pinned. So it says if you are using a canary channel, you need to use the, this exact version, not a, not a pseudo matcher.
-
-[13:31] They do not follow SemVer. If you don't want unpredictable breaks, you have to actually pin to an exact version. That seems great. I'm glad to get clarity. I'm glad that they have put out this versioning policy with explicit recommendations like that. This is not a new policy. I think it came out a couple months ago,
-
-[13:49] **Mark Erikson:** came out back in March ish, but we're sort of just now starting to see the first working examples of it.
-
-[13:55] **Carl Vitullo:** Yeah, so I guess, you know, March, they like got all these policies in place and then have been sort of working with next and doing development work. And it feels like now they've kind of turned back and are doing more messaging kind of stuff like this. You know, they announced a new feature and said, here's how to use it.
-
-[14:09] Here's supporting documentation about how we think about it. I appreciate that. That's very helpful. Very
-
-[14:15] **Mark Erikson:** clarifying. And this, this is unfortunately a topic I'm far too familiar with both as a, as a, as a library maintainer and then looking at react specifically. So I think most people are sort of used to the concept of libraries might put out an alpha release, a beta release, a release candidate, and then finally an actual stable release.
-
-[14:38] And we've, we've seen that even before with react, you know, like react, 18 went through betas and release candidates before it went stable. And then they put out 18, one and 18, two with some fixes and react 18, two, the current stable release came out almost a year and a half ago. And meanwhile, next has been.
-
-[15:00] Releasing new features. They've got some of the React core team members working over there, and there's been a lot of confusion over like, what is in the versions of React that Next is using? How can other frameworks actually use any of these things? For the last several years, React has had, uh, so there's both like the stable releases, and they also have an experimental channel, which is just automatically built like every day, every couple days.
-
-[15:29] So it's like straight off the tip of the main branch, whatever got merged in. And those experimental builds also have feature flags turned on so that like literally everything brand new that's in the React repo that isn't even like fully enabled yet is enabled in the experimental builds. But those could always change on a moment to moment basis.
-
-[15:50] So with next at the moment, you, I think you can actually end up with like three separate versions of react going because there's the production version. You probably specified in your own package, Jason. And I think that gets used with like the pages router. There's the canary version, which is a new semi react specific concept where it's like, this is semi stable.
-
-[16:14] It's maybe not like done, done. Maybe we're waiting on some other pieces, but we kind of think it's stable enough to use, and then there's the experimental version where, you know, there there's truly stuff that's, it's kind of wild. And so in next, I think if you use the app router. It's using a canary build.
-
-[16:32] I think a couple other experimental features you can opt into, in which case it uses an experimental build. And, you know, the idea of these canaries is that the React team maybe has some features that are in, that are in progress. At this point, they think they're stable enough that frameworks could use them because frameworks could add additional wrapping on top to kind of like hide the rough edges.
-
-[16:59] There's maybe a couple pieces that are still like waiting to tie into those before they can declare them fully, fully done and ready for a stable release. And unfortunately, up until now, there hadn't been any indication of Here's what canary versions have been released, or here's what features are included in a given canary release.
-
-[17:20] And just within the last week, uh, one of the react dev rels, Matt Carroll actually added a change log for the canaries as a markdown file in the react repo. So that's a step in the right direction.
-
-[17:34] **Carl Vitullo:** Yeah, I was, you know, I was just sort of thinking about, you know, versioning and releases and okay, so there's released versions of react.
-
-[17:42] There's canary and then there's experimental. So that's, you know, the MPM releases the release channels. But then there's also they have apis, right? They have the unstable underscore whatever apis. As well as some that are not even available because they're feature flagged out of the build out of the you know what the code that goes on NPM and I was just I'm just thinking about it's like wow wait so there's like six different ways of controlling how people what features are available and how people are able to make use of them and that's complicated like what a dance you have to do I
-
-[18:20] **Mark Erikson:** have unfortunately messed with some of reacts build system for something else and I've seen The code that controls, like, here's the master list of all the packages that are in the mono repo.
-
-[18:31] Here's all the different kinds of build artifacts that need to get generated for each package. Here's some of the feature flags that control individual features. Like it is really complex.
-
-[18:43] **Carl Vitullo:** I had read a line in the Canary Diversion Policy that I was hoping to find so I could quote it exactly. They talked about how part of the reason they do this complicated dance is because they have multiple projects that are all interrelated.
-
-[19:00] And so, you know, people say like, Oh, well, why don't you just release this, this feature while you're working on that feature? And the answer is, well, we can't release that until we release both. And people want access to that before both of them are ready to be released. And so we do this complicated dance in order to facilitate that.
-
-[19:18] And it's a lot of work that they put into. Structuring and communicating these releases, I knew all of these pieces, but I hadn't quite put them together into like, wait, this is a lot to manage to keep in your head. Mark, take
-
-[19:34] **Mark Erikson:** us on our next link. The next item is that 10 stack query version five is out.
-
-[19:40] Um, this of course includes the react adapters, like react query, as well as the adapters for the other frameworks. They've got some breaking changes. I know they changed things like removing callbacks from the mutation hooks. They've apparently altered some of the, the way you pass in options for the query hooks to try to make that more consistent.
-
-[20:02] Uh, there is a number of new features around, um, how you define optimistic updates. Uh, there is suspense support built in. They have a react server components, streaming adapter, and some infinite queries and dev tools. Uh, and it sounds like they even managed to shrink the bundle size. So that sounds like a very impressive release.
-
-[20:23] Definitely worth checking out. And I will say that wearing my Redux maintainer hat, we're getting close to the release of art Redux toolkit 2. 0, I hope. And part of that was actually cutting scope so that we don't, we are not going to make any real changes to our, to our RTK query data fetching API for 2.
-
-[20:41] 0. Because there's lots and lots of requests for changes. So we're going to defer any changes until RTK 2. 0 is out the door. And once we do, we will be looking very carefully at. React query and looking at some of their APIs and how they designed some of the use cases and frankly blatantly stealing from them, which is good because it means familiarity.
-
-[21:04] And also they've had more time to think about some of these problems than we have. And also we're friends with the maintainers. So we, we cross inspire each other all the time. It's
-
-[21:13] **Carl Vitullo:** not stealing it's standing on the shoulders of giants. Taking
-
-[21:16] **Mark Erikson:** inspiration from.
-
-[21:19] **Carl Vitullo:** Look at you, taking inspiration from a release to talk about your upcoming release.
-
-[21:25] That all sounds really great. I haven't, I still have not really extensively used React Query. I love all of the ideas of TanStack and whatever, but somehow I always... I'm stuck with Redux, so I don't know very much about the past experience or what this new release will change. I'll take us on to our next link.
-
-[21:42] There was some discussion of barrel files that I found really interesting. Berthel put out a blog post talking about how we optimized package imports in XJS. The term barrel file was new to me, though I... Have encountered the concept a great many times in many workplaces. It's it's the index. js file that imports and re exports modules or, you know, various exports from other modules and The problems that they talk about here are not ones that I had specifically observed through my career.
-
-[22:16] So basically what they talk about is these barrel files essentially centralize import or, you know, the module tree, the tree of your modules and sort of act as choke points. So it's like, as soon as you import something from one of these barrel files, suddenly every single module is being pulled in. And I guess, you know, maybe a more familiar.
-
-[22:39] statement of the same problem is low dash bundle size inflation. You know, I'm sure many of us, I have encountered this so many, on literally every project I've worked on, where somebody imports low dash, they do group by from low dash. Then, because tree shaking doesn't work reliably, the entire module gets pulled in.
-
-[23:00] And so, That's usually a bundle size problem, but what Vercel is talking about here is there's a second dimension to that, which is sprawling the module tree has a, you know, a noticeable cost to it. There, there is time spent creating and then navigating that tree of modules and barrel files by acting as these choke points mean that, especially on large projects, that time spent.
-
-[23:29] Looking at the tree and figuring out where code is coming from can explode to like a substantial portion of your build time. So Vercel next talked about optimizations they're doing to correct that for you. They will inspect imports to determine whether they are barrel files and then undo that for you silently on the backend so that you don't pay that, uh, that.
-
-[23:55] Discovery cost of, uh, traversing the tree of modules. That's really interesting. This is a new dimension to a problem I had observed in the past. Another thing that is, this is not exactly the same problem, but a pet peeve of mine that I've seen in more than one workplace is barrel files that rename exports.
-
-[24:14] So they'll import from one place and then re export it. Under a different name. So that's that sort of problem is why I had slanted on like, don't use these. Like there's just, if you're trying to find a particular bit of code in a large code base, barrel files do not help. They make it actively harder. So don't use them.
-
-[24:34] It's a bad practice. But also learning about another dimension of performance problems that they introduce. I'm never going to use barrel files again. It's not great.
-
-[24:42] **Mark Erikson:** I've never been a fan of the concept for a few different reasons. I mean, to back up a bit, I think the argument. For people who have used them is that it's a conceptual encapsulation thing.
-
-[24:55] So the idea is that if you have source slash features slash feature one, and you have many different files with different types of code inside of that folder, you can encapsulate the implementation details inside there by having source slash features slash feature one slash index such as it does the re exporting and other parts of the code base.
-
-[25:19] Should not be allowed to import from the nested files directly. They're only allowed to import from the index file. So they aren't like conceptually poking into things that they shouldn't know about. I can understand the architectural thought involved, but as we noted, there's, there's runtime implications.
-
-[25:40] You know, one is that if I right click a, you know, a component name or a function name, and I say, go to definition, it might end up jumping me to this barrel file instead because of how the compiler is trying to trace things. And then, yeah, like if you are bringing everything through one intermediate file.
-
-[26:02] The imports from a hundred other files, then just trying to import one thing is going to force that file to be parsed and loaded and go look at everything else and parse and load it. And, you know, maybe all those files do get used somewhere, but it also means extra processing time during the build step.
-
-[26:22] Maybe even a little extra time as the application is running. And so Marvin Hagemeister has done a lot of work over the last year, year or so to investigate common tools in the JavaScript ecosystem. Yes, lint and, um, a whole bunch of others. And he's found that in a lot of cases, the internals of these tools are actually doing things very inefficiently.
-
-[26:47] So the post that he has here, it's, it's slightly more theoretical. He's not digging into real code in one specific tool, but he had seen real world code bases where having barrel files was leading to drastic slowdowns in build time, and he created a fake example. Which had like a bunch of nested build tools and then, or a bunch of nested barrel files.
-
-[27:13] And that example made the code base build time explode. And so, yeah, like general, I think generally speaking, the advice here is that in order to kind of help speed up build performance, don't use this pattern. Instead, just go ahead and directly import from source nested file. And it's okay. I
-
-[27:37] **Carl Vitullo:** do empathize with the, the general impulse to do this.
-
-[27:42] It lets you treat your folders like internal modules, which is nice. It's convenience. It causes the pit of failure. It causes the foot gun where if you just do that indiscriminately without thought for how many files it is and without an understanding for like the downstream effects, because I think what really happens here is, okay, you do that once.
-
-[28:03] And then you do it twice, and then you have a pat, you know, 15 models, modules that all do that. And so then anytime you import anything, it gets your entire code base. It has to navigate your entire code base for it. So, yeah, that makes sense. And going back to that, you know, speeding up the JavaScript ecosystem series of blog posts.
-
-[28:25] I just saw, you know, another link that I'm not sure if I made the cut for this, but Parcel was talking about performance speedups. And like they changed their internal data structures, like that's it. Like they changed how they modeled it internally and got like a 5x beat up. So like there is clearly there are some low hanging fruits to make the JavaScript ecosystem faster.
-
-[28:47] So, uh, if this is one of them, then cool, let's, let's get rid of it. We don't
-
-[28:51] **Mark Erikson:** have to just go and rewrite everything in Rust. Sometimes we can look for really stupid code patterns and fix those. Performance.
-
-[28:59] **Carl Vitullo:** It's tough. All right. You want to take us on to our next one?
-
-[29:03] **Mark Erikson:** Yeah. So on a, on a sort of related note, React 18 came out with some new hooks and I think most people probably don't know they exist.
-
-[29:13] And to be honest, I still haven't even tried to use most of these new hooks myself, but I have seen my teammate Brian Vaughn, who used to be part of the React core team, using them because he was part of their development process. You might've heard that, you know, React 18 was going to have a concurrent mode.
-
-[29:34] And then they ditched that. It's not a whole standalone mode. Instead, it's concurrent features. So, there are specific React APIs that, when you use them, Make React handle the rendering process in a different way, being able to split a render into pieces or do some of that work in the background. And so two of the new hooks in particular are use transition and use deferred value.
-
-[30:03] Now, like I said, I have not actually used these in practice. Brian has attempted to explain them to me a couple of times and there's this very, very good. Excellent blog post by Nadia Makarevich, who's written a number of very good other articles about React behavior. And she goes into some detail about how these hooks work.
-
-[30:22] If I can try to explain them, and I'm probably going to get this wrong, so please read the article in the official React docs. UseTransition gives you something akin to setState, but it accepts a callback. And the idea is you're supposed to run the callback, run the startTransition callback, And do your actual update work inside of the callback.
-
-[30:45] And that's basically a signal to react that the work you're doing is relatively low priority and it should kind of be handled in the background compared to other potential renders. The other one is use deferred value. And I think the explanation that I sort of half understand is it's almost like a built in debounce.
-
-[31:08] In a sense. So maybe you're getting a value from some other source and you need to be able to render something now, but there's probably going to be like another version of the value coming later. So so you pass a value directly to use deferred value. And it returns what appears to be the same value.
-
-[31:33] Well, it's actually happening is it's starting one render right now and then it's like scheduling a second render for just a little bit later. So again, I don't have like the best understanding of them because I haven't used them in practice and also because I haven't used them. I don't I don't have a good feel for the mechanics.
-
-[31:50] But that's kind of the idea. It's about telling react that some of these pieces of data are lower priority. Let me do something now, schedule some lower priority work, and then rerender again, later when we've got all the pieces that we need. It's
-
-[32:05] **Carl Vitullo:** reminding me of a performance problem. I hit a couple of years ago when I was building a cryptocurrency exchange, because that's how my career has gone.
-
-[32:13] And we had a detailed list of. Tokens and every token had its own sparkline. And so when there were 40 tokens on screen, that was 40 sparklines. 40 charts is a lot to render. And so performance. tanked, and it took like three seconds to render the page. And I solved that by introducing a wrapper component that would immediately return null and then re render with whatever it was.
-
-[32:40] And I called this, you know, poor man suspense back in the day. Just saying like, Do it later. I don't care. Render something. Render everything else first. And I wonder if this might have been a, if, I wonder if this use deferred value hook might have been an alternate solution to that where I could say, you know, could have fed that little chart data out of this deferred value and gotten the same benefit without adding a Another component to the, to the hierarchy.
-
-[33:10] That's interesting. Okay. Very cool. I use transition is also new to me. I was just sort of trying to read that, uh, blog post, but it's long. I can see why this is a, uh, a concept that you, you've had explained to you more than once, but yeah, that looks really interesting. Very curious to hear more about that.
-
-[33:28] Well, okay. That is all of the news items we have. Should we move on to the lightning round? My first Photoshop is now on the web. This is something that I, I remember reading like an early technical write up about two or more years ago, talking about all of the efforts being done to bring a true, proper, real version of Photoshop onto the web.
-
-[33:50] And I know that there's lots of WebAssembly and WebGL and Canvas and just like, it was. It's truly an engineering effort that advanced the state of the web platform generally in a very real way that I think is quite rare, though, you know, I don't know that it has a ton of immediate actionable relevance for react and, you know, how we develop applications.
-
-[34:15] The byline on this article is enabled by WebAssembly and Emscripten, Web Components and Lit, Service Workers and Workbox, and New Web APIs. Chrome and Adobe enjoyed collaborating on it. So this is, you know, a deep collaboration by presumably the Chrome team at Google and Adobe building Photoshop, getting the web platform into a state where it was a suitable host for a real version of Photoshop.
-
-[34:42] As opposed to, you know, I think a lot of this type of application would tend towards doing the heavy lifting on the server. So, like, you know, if you were, you know, they've got a early screenshot in the blog post of generative fill. Uh, so, you know, like, I think, you know, the, the easy, the, the pragmatic. Just get it shipped approach would be just do that on the server, you know, so I think it's really interesting to see a project like this.
-
-[35:12] I think that this is a once every couple of years level of investment in the platform. It's worth reading. It's worth learning more about just seeing how they did it and why they bothered to do all this effort. Cool. Mark.
-
-[35:27] **Mark Erikson:** Alright, so it looks like Yarn version 4 just came out, and I've been a fan of Yarn ever since it was first released, but the transition from Yarn 1 to Yarn 2 was kind of like the Python 2 to 3 transition, or, um, you know, kind of like the common JSTSM transition, in that there were such major changes in the way this product was designed and used, that it...
-
-[35:55] You know, it caused a lot of frustrations and turned people off. Um, so there's a little bit of background. Yarn 1, like most other JavaScript tools, is installed globally on your whole machine. So, you know, npm i dash g yarn. Yarn 4 are supposed to be installed on a per project basis. So you're actually supposed to copy the, like a yarn, like release binary JS file into your repo and commit that.
-
-[36:30] And you have a config file. And when you run yarn inside your repo, yarn one from your system starts up. It sees the config file and sees, Oh, I'm actually supposed to run yarn three, two, one dot JS that's committed. And then it switches over and starts up the, the low, the local newer version of yarn instead.
-
-[36:53] And I think that concept has confused a number of people. The other big thing is that when Yarn 2 came out, they had this really radical idea about how it would manage the installation of the JavaScript packages. They called it plug and play. And the idea was that instead of extracting, you know, 50 or a hundred thousand files into your node modules folder, it would leave all tarballs.
-
-[37:20] So it's smaller on disk, and there's no time needed to extract everything, but in order to make that work, Yarn has to take over and act as an intermediary layer for any tool that needs to import a library or access anything. And there's so many tools in the ecosystem that expect that real files exist on disk in Node modules, because that's how everything works.
-
-[37:46] So, my own experience has been that, you know, Yarn's plug in play mode is a nice concept, but in practice, every time I tried to use it, there were too many other tools that would just break in some way. But, especially with Yarn 3, they have a standard, let's just extract everything into node modules option, and I've actually found that works great.
-
-[38:07] We're using it in my day job at Replay, we're using it in all the Redux repositories. Um, so the, I've, I feel that works great. So with yarn version four, looking at the release notes, um, they've got a couple fairly fancy new options around validating packages that are installed. Um, being able to define constraints, which maybe makes things work more consistently in a monorepo.
-
-[38:31] Yarn three has a plugin model and they had some official plugins, but they weren't installed by default. And it looks like those plugins do now get auto included with yarn. So they're always available. Uh, they've, they've improved some of the UI output and it also looks like they've improved some of the installation performance as well.
-
-[38:51] So if you're using yarn two or three, it's probably worth upgrading to yarn four. And if you're using yarn one, it, it probably is still worth looking at the newer versions of yarn as well. Uh, there was a lot of debate in the hacker news thread. Um, you know, a lot of people are arguing about, you know, why do we need so many package managers or, you know, discussing the, the transition from yarn one to the later versions?
-
-[39:17] Some interesting reading over there.
-
-[39:19] **Carl Vitullo:** Yeah, as someone who has never moved beyond yarn one, I empathize with all of those. There is a discussion of. a query verb for HTTP requests. Uh, this would be in addition to like get, post, patch, put, delete, now query. This is really interesting. Uh, it seems to be a standardization of essentially like GraphQL.
-
-[39:41] GraphQL, I know, uses slash abuses post, which has some negative consequences just because Host is meant to be submitting information, not retrieving information. Um, so this looks like a recognition that the current verbs are not quite sufficient for modern use cases in so far as the get verb has no body.
-
-[40:05] You can't say you can't give any information along with that request that URL. So, you know, you can do query variables, but like at a certain point, the URL is like. You know, if you have kilobytes of data that you're trying to send back using in the URL has some trade off that's not ideal. Um, and post is not idempotent.
-
-[40:28] You know, it is not understood by the spec. It is not safe to retry post requests. That's not a safe assumption. So, you know, you can write an API where it is safe. But if I'm writing. A fetch library, a fetch wrapper, then I, you know, I can't say I, because it is a post request, I can't reliably retry it. I can't, I cannot write code that does that because it might not.
-
-[40:53] Um, so this is now essentially it. I think my summary would be this is get with a body, uh, with the recognition that it's going to be used to query data. Very cool. I think that's, you know, big platform
-
-[41:07] **Mark Erikson:** iteration. Okay, next up, um, so TC39 is the standards body that deals with the JavaScript language. And they've announced a new working group that is going to try to improve the specification for source maps.
-
-[41:24] Now, if I had to guess, probably two thirds of the people here have no idea what a source map is because you've never had to worry about it. Source maps contain data. They contain all the original code, like your code, as it looked like on your machine, before you hit the build button, and then they tell debuggers and other tools, here's how you map, you know, to do list item.
-
-[41:48] ts line 37 into these 30, these 25 characters in the middle of your application bundle. And so this is how JavaScript debuggers like the Chrome DevTools or my own day job at replay are actually able to show you your original code so that you can step through it, see variables, and do all that stuff while debugging.
-
-[42:12] Source maps are really stupidly complicated. I'm not an expert on them, but I've learned a lot about them over the last couple of years. And there is a current spec for what information source maps can contain, but there's a lot more cases where they could be useful. And like Brian handle more cases. So this working group is trying to expand the specification for source maps and add more information that can handle specific cases so that in the future, once the spec is defined and build tools, output this information and debuggers know how to use this information, they can more faithfully represent what your original code was doing as you're trying to debug it.
-
-[43:01] And so one of my, one of my coworkers, Holger Bentel. Is actually part of this working group. And he even has submitted a proposal that, um, to try to capture information about scopes. An example of this from the, from the proposal is that if you have like three nested function calls, the compiler might, you know, or a minifier might collapse all of those and just say, well, the last function just returns a value.
-
-[43:30] I can just get rid of those first two functions entirely and return this value at like in the production code. That means that the source map might not capture the fact that when you wrote it, There were two or three other functions in the middle. And so when you try to debug it, it sort of ends up looking like you skipped from like above the function into the middle function and never paused anywhere in between.
-
-[43:55] So by capturing more information about scopes. It could do a better job of representing the way you wrote the code. And I'll also put in a self plug for one of my own things. Uh, react has never shipped source maps for its production builds, which is why you, when you see a react error, uh, in production, the stack traces are all gobbledygook and earlier this year, I put up a PR to actually add source maps to react build pipeline.
-
-[44:28] That PR has been sitting there for the last five months. Um, I actually had a conversation with a react team member just this last week at a conference. And I'm, I have tentative hope that maybe that'll get merged sometime soon. I hope, but the problem is even once it's merged, that will only be helpful for future releases of react.
-
-[44:52] That actually include the source maps during the build step. So I've actually done the work to backport my react build pipeline changes. And I generated the source maps that would have existed or react 18 to 18, one and 17. And I worked with someone from the century tool. Who then proceeded to put together build plugins for Webpack, Vite, and Rollup, I believe, so that you can install this package in your app, add it to your build pipeline, and it will automatically use the quote unquote original React source map in your application bundle.
-
-[45:34] Is this going to radically improve your debugging experience? Maybe not, but it hopefully can help in situations like, you know, being able to see error messages and some other things like that.
-
-[45:45] **Carl Vitullo:** Yeah, my kingdom for React source maps. Cool. Uh, I'm going to make a game time decision. I was going to talk about, uh, Astro 3.
-
-[45:54] 2, which has view, uh, transition improvements, but I don't really know that much about view transition improvements, so I'm going to switch it up and talk about Parcel performance improvements instead. Uh, I touched on this briefly earlier, um, The, the, the gist is they're claiming, uh, seven times faster rebuilds on large projects, uh, and lots of other performance improvements, um, no rust rewrite, no, you know, massive core, whatever, replacement.
-
-[46:25] Um, but they talked about, they said 50 percent of the time in bundling was spent looking up values in different maps. So that, you know, they have maps and sets that, uh, determine which bundle routes, uh, each module is reachable from. So, you know, basically like, if you're here, then you can get over here.
-
-[46:44] And they switched out those maps and sets into, uh, bitsets. Which is, I guess, more like, I'm trying to... Retreating
-
-[46:54] **Mark Erikson:** and treating the individual ones and zeros in an integer as if they were bullions.
-
-[47:01] **Carl Vitullo:** Yes, there we go. We have one value that represents multiple flags, multiple multiple different, you know, things.
-
-[47:10] So, you know, by they say that purely by switching from storing all of this data in maps and sets. You know, the, the, the JavaScript, you know, concept of a map or a set new set new map, uh, into this bit set where it's working on a binary level rather than a like string level, I guess, uh, they've been able to get a five X improvement in bundling speed in some situations.
-
-[47:40] So. It just goes to show you that, you know, sometimes you're going to, sometimes rewriting in Rust is right, but also, like, if you're rewriting in Rust, you're basically doing this logic, like, Rust operates on, you know, it's a low level language, whereas JavaScript is, by default, a high level language, you're, you know, in JavaScript, if you're just going to write code the most intuitive way, you're probably writing strings, objects, arrays, JavaScript.
-
-[48:05] But there's nothing stopping you from writing code as if writing JavaScript as if you were writing Rust or C. Um, you can use buffers. I guess not in, not in the browser. You have to use typed arrays. You and data arrays. Right. But, you know, you, it is perfectly feasible to write JavaScript that does all, all of those low level manipulations.
-
-[48:25] And it, yeah, if you're thinking, if, if you ever find yourself thinking like, man, I wish I could just rewrite this in Rust, like. Take that same thinking that you would approach writing it in Rust with and try writing in JavaScript. I bet you'll get halfway there on the
-
-[48:39] **Mark Erikson:** performance. The, the funny thing was though, I don't, I don't know if you caught this.
-
-[48:43] So, there was one little bit that they couldn't do from JavaScript. There's apparently a... an advanced CPU SIMD instruction that they wanted to use specifically for some of the comparisons to make them faster. And you can't access specific CPU instructions from JavaScript. It just, it's just not possible.
-
-[49:05] So what they did was they wrote that one tiny, tiny little bit in Rust and compiled it to WASM. And exposed it to JavaScript. So, because they could, they could use that SIMD instruction in Rust. And so by doing that, it's like they made one little function, which is like, you know, fast bit compare or something like that, and expose that to JavaScript from Watson, that's impressive.
-
-[49:32] Yeah,
-
-[49:32] **Carl Vitullo:** that is really cool. I love the idea of SIMD. If folks in the audience aren't familiar, uh, S I M D, Single Instruction Multiple Data. Uh, it's what powers, it's the core concept behind like graphics cards and like all the AI and the mining and whatever. Uh, you take 600 values that all need the same thing done to it.
-
-[49:53] Modern processors will let you pass in That data and an instruction and we'll just do all of that at once instead of one, you know, instead of doing like tick, tick, tick, tick down a list 600 times it'll just go and do 600 units of work all at once. So, yeah, very cool. I didn't, I, I had missed that. They did use rust for a little bit of that.
-
-[50:16] That's very cool.
-
-[50:17] **Mark Erikson:** Okay, we're about out of time, and fortunately this is the last item on the list. So, self plug. Last week I spoke at the React Advanced Conference in London, which was a wonderful time. Uh, that's also where the React for Git talk was. Uh, the live streams are up on YouTube, um, and the, the individual talks will be available on the, the Git Nation, uh, conference organizers site within the next couple weeks.
-
-[50:43] My talk specifically was titled Building Better React Dev Tools with Replay Time Travel. Most of the last year building some very advanced features for replays, time traveling debugger that rely on poking inside the internals of the react library and the react dev tools in replay. We have the react dev tools integrated so that as you jump to different points in time, you can see what the react component tree looked like at that point in time in order to gather that data.
-
-[51:19] I actually had to go make changes to our recording version of Chrome to say here's every time react rendered and then there's a back a server side back end post processing step opens up the recording goes to each point in time injects the react dev tools bundle code and then extracts the component tree data and then it's even able to take some steps further like if you made a recording of a production application it can use source maps to figure out well and Okay.
-
-[51:51] This components name in production was QZ, but that's actually to do list item from your original code. So let's use the original name of to do list item for the component tree instead. And so I talked about, here's how the react dev tools actually saves and transmits that information. And then I talked about the steps needed to actually do this time travel analysis and replay.
-
-[52:17] Um, and I've semi open sourced the actual code. Uh, the, the code is technically speaking in our proprietary backend repo, but I've copy pasted it to an examples repo. It won't run, it won't compile, but if you want to see... 2500 wines of Mark doing stupid, weird, crazy, mad scientist things. It's available. Heck
-
-[52:39] **Carl Vitullo:** yes.
-
-[52:40] Thank you so much, Mark, for talking through the news with me. Thank you so much, everyone in the audience for sticking with us. Uh, well, I hope everyone has a good Halloween. Uh, spooky season is almost only or almost over. Um, yeah, cool. See you guys next month.
diff --git a/src/transcripts/tmir-september-2023.md b/src/transcripts/tmir-september-2023.md
deleted file mode 100644
index 0e1d866..0000000
--- a/src/transcripts/tmir-september-2023.md
+++ /dev/null
@@ -1,513 +0,0 @@
----
-title: This Month in React (September 2023)
-date: 2023-09-27
-time: 10am PT / 5PM GMT
-location: Main Stage on Reactiflux
-description: "Join Carl Vitullo, Jacob Paris, and Sebastien Lorber as we break down This Month in React. We'll break down what's new in an hour-long conversation."
-people: "[Carl Vitullo](https://twitter.com/vcarl_), [Jacob Paris](https://twitter.com/jacobmparis), and [Sebastien Lorber](https://twitter.com/sebastienlorber)"
----
-
-Remix v2, Docusaurus v3, Node 20.6, Bun 1.0
-
-- [Spotify](https://open.spotify.com/episode/54ClLvCFL82IG93a4g7vXZ?si=j7G_aMnNSwOid70QPsJcBQ)
-- [Apple Podcasts](https://podcasts.apple.com/us/podcast/this-month-in-react-september-2023/id1661733526?i=1000629732098)
-- [RSS](https://anchor.fm/s/a1f8a59c/podcast/rss)
-- [Or anywhere you prefer](https://podcasters.spotify.com/pod/show/reactiflux/episodes/This-Month-in-React--September-2023-e29vb6o/a-aadsk3b)
-
-
-
-This episode covers major updates across the React ecosystem, including:
-
-- Node 20.6 adding built-in .env support
-- Remix v2 using extensive feature flagging
-- Docusaurus v3 introducing visual regression testing
-- Astro 3.0
-- understanding React Server Components. Server components enable powerful capabilities like data fetching at the component level, but also introduce complexities around data serialization and scoping.
-- Bun 1.0 as a faster Node.js alternative, aiming to replace many common Node.js tools and improve performance. There was discussion around adoption challenges due to non-standard features.
-- Next.js adding server actions for forms
-- Expo moving towards full stack capabilities, which expands capabilities for mobile apps and could position Expo as a compelling full stack solution.
-- and Dan Abramov joining Bluesky
-
-Key themes were leveraging Rust and other languages for server-side rendering, moving away from CSS-in-JS, and enabling easier major version upgrades through techniques like feature flags.
-
-Sebastien discussed using React Server Components in static site generators like Docusaurus to simplify data fetching without GraphQL. There was also discussion around using languages like Rust and OCaml for improved server-side rendering performance.
-
-Links used:
-
-- [Node 20.6 - Built-in .env file support](https://nodejs.org/en/blog/release/v20.6.0)
- - [Node.js 16 End-of-Life](https://nodejs.org/en/blog/announcements/nodejs16-eol)
-- [Remix v2 pre-release](https://twitter.com/remix_run/status/1696525340640936190)
- - [Upgrade guide](https://remix.run/docs/en/main/start/v2)
- - [SemVer philosophy](https://remix.run/blog/future-flags)
-- [Docusaurus v3 beta](https://github.com/facebook/docusaurus/discussions/9312)
- - [Upgrading frontend dependencies with confidence](https://docusaurus.io/blog/upgrading-frontend-dependencies-with-confidence-using-visual-regression-testing)
-- [Astro 3.0](https://astro.build/blog/astro-3/)
-- [Making Sense of React Server Components](https://www.joshwcomeau.com/react/server-components/)
-- [Expo Router RFC - API Routes](https://blog.expo.dev/rfc-api-routes-cce5a3b9f25d)
-- [Bun 1.0](https://bun.sh/blog/bun-v1.0)
- - [My Thoughts on Bun](https://adventures.nodeland.dev/archive/my-thoughts-on-bun/)
- - [Announcing Biome](https://biomejs.dev/blog/annoucing-biome)
-- ⚡️
- - [React-Native running natively on Apple Vision Pro simulator demo](https://twitter.com/o_kwasniewski/status/1701626162521190688)
- - [Are Big Projects Ditching TypeScript?](https://www.totaltypescript.com/are-big-projects-ditching-typescript)
- - [Rust Server Components](https://anto.pt/articles/rust-server-components)
- - [Web Developers, CSS-in-JS is Ruining Your Product](https://cord.com/blog/migrating-from-css-in-js-to-vanilla-extract)
- - [Dan Abramov joins Bluesky](https://twitter.com/dan_abramov/status/1695566446007386214)
-
-[00:00] **Carl Vitullo:** Hello everyone. Thanks for joining us again for September's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. I'm Carl. I'm a staff product engineer and freelance community leader at Reactiflux, the Discord for React Professionals, where you are! Joined today by Jacob Paris and Sebastian Lorber.
-
-[00:22] Jacob, do you want to introduce yourself?
-
-[00:24] **Jacob Paris:** Yeah, sure. Thanks, Carl. So I'm, working in DevRel at the moment. I've been a React dev since, not quite the start, I was one of the later later laggards to drop off of Angular, way, way back then. And on the side I'm an egghead instructor.
-
-[00:38] So I've been producing a lot of content primarily for the Remix ecosystem. And yeah, just trying to share and teach as much as I can.
-
-[00:46] **Carl Vitullo:** Well, also you send out a monthly Remix newsletter yourself, don't you?
-
-[00:49] **Jacob Paris:** Yeah, yeah, I do. So that, that one's called Moulton. I took over as a writer of that. Pretty recently and pretty similar to the this week in react, but it's specifically focused on the Remix ecosystem. So, the, all the cool libraries and articles and courses and updates from the team and everything cool that's happening with Remix.
-
-[01:08] **Carl Vitullo:** Nice. Yeah. A lot going on there. Yeah. And Sebastian?
-
-[01:12] **Sebastien Lorber:** Yeah. So I'm Sebastien Lorber, and you probably know me for the this week in React newsletter, and I'm also the, the maintainer of Docusaurus, which is now, the version three is in beta. So you can give it a try if you want and, give me some feedback.
-
-[01:28] **Carl Vitullo:** Cool. All right, let's jump into it.
-
-## Node 20.6
-
-- [Node 20.6 - Built-in .env file support](https://nodejs.org/en/blog/release/v20.6.0)
- - [Node.js 16 End-of-Life](https://nodejs.org/en/blog/announcements/nodejs16-eol)
-
-[01:30] **Carl Vitullo:** I guess my first link here is new. It's not actually react or react related directly, but it will affect the ecosystem. New Node version 20.6. Really, my big highlight here is they're pulling in dotenv support to the runtime properly. So no more dotenv. We don't need to install a package, we can just use dotenv files.
-
-[01:55] Yeah, a lot of the other changelogs look pretty deep and wonkish. There's one that looks like it might be really interesting or might have really interesting echoes throughout the ecosystem, but I'm not really sure exactly what it is about.
-
-[02:09] It's something about registering module hooks Module customization hooks. They have a call out in the change log saying that those module customization hooks can now handle both ES modules and common JS sources. I don't know exactly what those are for. The reading about them in these release notes was the first time they'd ever crossed my radar. And there's not really a lot of information about what they're for in here.
-
-[02:32] But anything that starts talking about cross-compatibility between ES Modules and CommonJS is like, very interesting to me because that has been such a pain point for like. tears at this point. So that caught my eye too, but it looks like most of these other changes were relatively minor and you know, classic LTS cycle, now node 16 is end of life though.
-
-[02:55] We were using those for reactibot. So if you're using node 16. Stop it. Time to update. Yeah, Jacob, Sebastian, anything you want to chime in on there? Not a lot to discuss there.
-
-[03:06] **Jacob Paris:** Yeah, the CJS ESM incompatibilities have been largely a nightmare for my entire history of being a developer. To be honest, I don't know how new devs really Understand the stuff when they pick up.
-
-[03:21] It's like, you know, which import format do you use? You've got configurations that are automatically generated by different different packages, ESLint, Prettier, and sometimes they work and sometimes they don't. And I, I don't know how anyone makes sense of it. I am all on board for the ecosystem moving toward ESM here in the future, where maybe there's only one thing to do.
-
-[03:41] Or we can go with Bun's approach where everything just works together and it's up to library authors to sort things out between ourselves. I'm, I think that's okay as well.
-
-[03:51] **Carl Vitullo:** Yeah. On your note about people learning web development right now something that has bitten me a number of times is, like, Sindre Sorhus has, all of his packages now are ESM only.
-
-[04:04] And if you want CommonJS, you've got to decrement the major version. And that has bitten me so many times where something is inexplicably broken and I just need to, like, remember which are his packages and decrement them. So it's, yeah, hopefully, I have a lot of fingers crossed here that this is going to make that better, but, you know, we'll, we'll see what it does.
-
-[04:24] It does say, "this should simplify the customization of the Node.js module loading process as package authors can customize more of Node.js without relying on deprecated APIs such as `require.extensions`." So hopefully, we'll see.
-
-[04:37] Jacob, you want to take us off on our next link?
-
-## Remix v2, major release feature flagging
-
-- [Remix v2 pre-release](https://twitter.com/remix_run/status/1696525340640936190)
- - [Upgrade guide](https://remix.run/docs/en/main/start/v2)
- - [SemVer philosophy](https://remix.run/blog/future-flags)
-
-[04:38] **Jacob Paris:** Yeah. Yeah. So I guess the biggest thing from the Remix ecosystem at the moment there is that they just launched the V2.
-
-[04:45] It was quite an underwhelming release, every new feature that came out, everything has already been in place for weeks or months now via feature flag in the previous versions. So anyone who's already running that you know in, in production or in any of their apps they've already been able to opt in to the FeatureFlag, upgrade things and move on.
-
-[05:05] And, you know, if that didn't happen by now, I guess now's your chance to do that before you increment the major version. So in theory, that should make it a really smooth transition for pretty much everyone to upgrade. But then on the same note of ESM versus CJS issues, one new thing that happened is that, with Remix V2, it now has first class support for ESM, which just wasn't a thing before.
-
-[05:28] So now in your dev server, you can run full ESM applications. And, in that process of releasing the new version, they've also changed the default from CJS to ESM. So, um, there's been a lot of people kind of struggling with incompatibility issues because, you know, previously their new applications were being made in CommonJS.
-
-[05:49] And now they're, now they're being made to support ESM and some config files that they've been trying to copy over from other files or from examples that they've copied online old repositories. Now, they just need to be tweaked a little bit, and it's usually not that much work.
-
-[06:05] But there's small changes that need to be done, and you need to know what you're doing to do that. That said, Remix still supports CommonJS, but since they changed the default, there is now this friction and this, this transition period that people are having to go through.
-
-[06:18] **Carl Vitullo:** That's awesome though. Maybe I can stop decrementing my Sindre Sorhus modules.
-
-[06:23] **Jacob Paris:** (laughs) In general even if you're going all in on ESM, you should still be able to run CJS packages by running them through a Bundler beforehand. So they have to be Bundled rather than running natively but just because you're moving toward ESM doesn't mean you no longer have the capacity to use CommonJS modules.
-
-[06:42] It's just a little more work to get them running in the same runtime.
-
-[06:45] **Carl Vitullo:** Okay, very cool. Very nice. Yeah, I was reading a little bit about, you know, in there, in the V2 announcement post, they talked, way more than any, you know, new releases, new features they talked much more about their update, upgrade philosophy, which I thought was really interesting, like the, you know, vertical space associated with advertising what they were releasing versus advertising how they released it.
-
-[07:10] I thought it was an interesting choice, but I really loved the philosophy that they described. I just put a link and link to it in chat. But they, I pulled out a couple of quotes because I thought they were really clever and just useful, kind of useful to hear.
-
-[07:24] For anyone in the ecosystem who's going to be consuming libraries, and maybe also for library maintainers. But if they talked about Semver, "Semver gives us a way to communicate when breaking changes exist, we do not have a similar agreed upon process of how to introduce breaking changes in our frameworks and communicate them to application developers."
-
-[07:42] and they talked a lot about like the long running feature branch development for upgrades, which is a pain I have felt a number of times in my career. I have been that developer maintaining a feature branch for a month, two months, three months, constantly merging back in, rebasing off master, repairing merge conflicts, doing all that.
-
-[08:03] So seeing them talk about the efforts they've gone through to avoid those problems was like, Oh, this is really interesting. I didn't realize that it was like technically feasible to really do this.
-
-[08:16] So yeah, I thought that was really cool.
-
-[08:17] **Sebastien Lorber:** Yeah, I agree. But I have something that I don't really understand is there are some things that are really hard to ship with a future flag, you know, for example in Docusaurus, we upgraded recently to MDX two and it's. Completely different from MDX one on the inside, the AST is completely different, the packages were migrated to CommonJS to ESM and there are many things like that.
-
-[08:43] And I think like if you wanted to. To bring support to MDX2 with a future flag, you would have to vendor the MDX library and all, many dependencies to be able to support the two versions at the same time, and we would have to maintain two copies of the code somehow. I don't know, but For example, I was wondering if Remix version 2 will have support for server components as a future flag, or if it will come only with version 3 at the release time, because it looks like a complex thing to ship as a future flag somehow.
-
-[09:24] **Jacob Paris:** Yeah, yeah, it's, it's definitely challenging and you sort of have to pick and choose which features which features you go with. I'm not 100 percent sure when the RFCs for how Remix is going to handle Server Components are coming out. But, you know, that's something Ryan Florence is working on at the moment. So we'll have a little more information when that comes.
-
-[09:45] But for example, yeah the... You know, updating big major dependencies, like you couldn't feature flag having support for example, React 17 versus React 18 at the same time. So that was one of the big things that Remix did update in the v2.
-
-[10:04] So you can run v1 with all the feature flags enabled on React 17, but at the time you update to v2 officially, it does drop support for versions of React prior to 2018. And it was the same with the, with the CJS ESM thing. That's just, it's not practical to try and, you know, run those side by side in, in everything.
-
-[10:23] So the official first class ESM support, was also sort of a, an add on that came in with the with the new version rather than trying to feature plague that. So I definitely see a lot of value in them as a tool where, you know, as long as you can choose not to break things for your developers, and to give them an incremental path to adoption, you should do that.
-
-[10:47] But you know, as you've said, sometimes with bigger dependencies, sometimes it just can't be done. Yeah, it makes sense. I guess, I guess another, another thing I'm so happy that Remix is going down this road is because developers are just terrified of major version releases. Um, like if you look what happened with Angular, moving from Angular 1 to Angular 2, you know, with React going from React class components to React hooks.
-
-[11:11] You've got Vue 2 to Vue 3, and now, like, all the dialogue I'm hearing with Remix, you know, despite how loud they are taking up the entire announcement post to talk about it. The way this major version release process is working, you're still getting people asking, "well, is this stable yet? should I wait a little later? I don't want to start a project now if I'm going to have to refactor and change everything later."
-
-[11:35] There's just such this ingrained culture where major version updates are, are, are terrifying and not something you want to put a project through if you don't have to. People would rather wait and delay things than Adopting and having to go through that transition period.
-
-[11:50] So if, if what Remix is doing here can really catch on and start to make this a little less painful for upgrades, then yeah, I, I am all for that.
-
-[11:58] **Carl Vitullo:** Yeah, agreed. Definitely true that there's a lot of fear around major version upgrades. And, you know, I, I maybe actually, maybe it's less fear and more just like trauma because so many of the you know, it's not unbased.
-
-[12:11] It's not like, you know, you've heard stories to keep you up at night. It's just like so many people have had lived experiences of, "major version upgrades are super painful." So I hopefully this is a trend. I love this direction. I have to imagine that feature flagging things is this aggressively in a framework is, technically challenging, technically complicating. So yeah, hopefully we'll see it more. Hopefully it's not so complicating that it's difficult for other people to copy, because I love this. I hope this becomes a trend.
-
-[12:42] Sebastien, you want to take us off on our next link?
-
-## Docusaurus v3.0
-
-- [Docusaurus v3 beta](https://github.com/facebook/docusaurus/discussions/9312)
- - [Upgrading frontend dependencies with confidence](https://docusaurus.io/blog/upgrading-frontend-dependencies-with-confidence-using-visual-regression-testing)
-
-[12:45] **Sebastien Lorber:** Yeah, so I thought that as we were speaking about being afraid of upgrading dependencies, actually I posted an article last week about the subject. And it's related to the Docusaurus version 3. So I was working for, on the version three for a very long time. Now it's a, it's an upgrade of the infrastructure, including React 18 and, and MDX 2.
-
-[13:11] And, this changes, not, MDX two can have a lot of, weird side effects. For example, you add. MDX content and it rendered nicely previously. And now if you, if you upgrade to version two it eventually fails to compile now. So you have to reflect all the content of it. And also it can render differently, even if it's compiled.
-
-[13:33] So. you are not very confident that actually the, the upgrade is safe unless you took, you take a look at all the pages of your documentation or your blog or whatever it is and, take a look at all of them and be sure that it renders exactly like before. So, um, what I did for Docusaurus and this is now, um, A solution that, we recommend to our users is to adopt a workflow of visual regression testing.
-
-[14:03] So, the idea is that you take a screenshot of all the pages of your documentation website. And, you do this on the main branch and on the pull request branch, and then you use a tool that can be, something self hosted or external, and this tool permits you to tell you which are the differences between your upgrade branch and your, and the main branch.
-
-[14:28] So, if you have visual regressions that you don't expect, the tool is able to report it as a GitHub commit status. And so, I wrote a blog post about the setup that I used. It's based on GitHub Actions, Playwright, and Argos, which is an external tool to handle the screenshots. And I thought it was quite interesting.
-
-[14:50] I used it in the context of Docusaurus upgrades. For example, while upgrading the React Native website last week, we... catched a few bugs, in the process thanks to this workflow. And I think it can be easily, adapted to work on other sites. What I did to get the, all the pages of the site is to read the sit map point, the XML file, and iterate on, on the list of path.
-
-[15:18] So as long as you're able to take screenshots and are able to get a list of page of your site I think you can try to adopt this workflow and if you want to do a dependency upgrade, then you can do and compare and see if there is a visual difference being reported by the tool that you use.
-
-[15:37] **Carl Vitullo:** Yeah, very nice.
-
-[15:38] I've heard about this kind of visual regression testing. I feel like I've heard about it four or five times over my career. And every single time it hasn't really worked out. Or, you know, I've tried it and it, you know, the the experience doesn't quite work out. But I'm reading about I'm reading your blog post.
-
-[15:57] And I love the idea of I feel like maybe the technology now has developed to the point where it will actually work now, because like Playwright, I've heard only phenomenal things about. Everyone I've talked to who has used it has said that like, yes, this is great. This is what integration and end-to-end testing should be.
-
-[16:16] And GitHub Actions is finally like a great task runner for services like that. whereas, you know, I remember trying to set up this sort of tool in like Jenkins, like eight years ago, and it was like, Oh, I don't, this doesn't work. So yeah, this seems really cool.
-
-[16:34] Cool. Well,
-
-[16:35] I can take us on to our next one then we are going to get to Bun 1. 0, but I want to, I'll say we're going to save that for the end.
-
-## Astro 3.0
-
-- [Astro 3.0](https://astro.build/blog/astro-3/)
-
-[16:43] **Carl Vitullo:** So right now, I want to talk about Astro 3.0, I actually have not yet used Astro very, very extensively, but I have heard only really great things about it and it's a, it's definitely something I want to check out. I think I've heard about it being like very good for like personal sites, portfolios, like relatively smaller marketing sites.
-
-[17:06] So, you know, as I'm looking at making a personal, professional blog or revamping the Reactiflux website. Very interested to give that a shot, give it a real chance of and see how it works out. But yeah, Astro 3.0, new, new release. I don't know. Have either of you used Astro at all, very much?
-
-[17:25] **Sebastien Lorber:** no. But I think it's interesting because, you know, the view transitions make it more, looking like, single page applications. And now that they are able to persist the state between, page transitions, that's becoming a really interesting solution. What I'm afraid, for example, for now, is that if you use third party widgets like intercom, chat, and things like that, If you navigate from one page to another, you would like this kind of widget to persist the state because it's really annoying, you know, to have the chat that resets itself.
-
-[18:00] You are in the middle of a conversation with the support team or something and you click on the link and then, everything is lost. So if they can solve this program, I think it's it's really great for us too. And for multi page applications in general.
-
-[18:13] **Carl Vitullo:** Nice. Sadly, I can't speak very, much more deeply than I already have on this, but yeah, definitely excited to give it a shot. And I love when new versions come out before I have fully learned them. So then I only have to learn one thing instead of two.
-
-[18:28] Jacob, you want to take us on to our next one?
-
-## Josh Comeau's Making Sense of React Server Components
-
-- [Making Sense of React Server Components](https://www.joshwcomeau.com/react/server-components/)
-
-[18:29] **Jacob Paris:** Yeah, sure. So, Josh Comeau put out this great article about, React Server Components. So I, I've kind of been sleeping on React Server Components for a long time, because They've always really confused me.
-
-[18:45] So when the information was first coming out, there was, there were so many different ideas about how these are going to work. And then you start seeing examples and some of the examples are coming from the React team and some of them are coming from the Vercel team and then people from React move over to Vercel and then you get you know, examples from the from the code bases of either moving back and forth.
-
-[19:06] It was just, it was always so unclear, which, you know, in any example you see, which parts were React and which parts were Next. And so, so for me as a, as a Remix developer, I'm wondering, you know, which parts are going to stay in React that then Remix can build on top of and which parts are belonging to Next that, you know, Remix may either have to, may either have to clone or continue to build on top of.
-
-[19:32] For a long time, I just, you know, I kept seeing these server components, and I just really didn't know much about what they were. which is why, yeah really glad Josh has put out this article, because reading through, everything makes quite a lot more sense now. The server components are basically a new model here, where every React component we've dealt with in the past has now been renamed to a React Client component, and these React Server Components render only on the server, and they only render once, and it's a Almost like server side rendering, but instead of executing once and then being all the HTML to the browser is they can render and then send all the information React needs to hydrate a React component to the browser in fact, in practicality, what this means is we can have async data fetching happen right in our components, which is fantastic, And any time you include a client component in there, everything that component imports just works exactly like, components we've had before.
-
-[20:39] It unlocks a lot of abilities that we primarily couldn't do before in terms of composition, for example, in say, in Remix and in Next.JS before this, you can have a, a loader or your get server side props that fetches data, and then it passes it to a server side rendered components.
-
-[20:58] But there was never any way to do that at the component level that always had to do, had to happen at the route level where you would have a, you know, each route would become an end point and you can. You know, you generate your components based on the data that endpoint returns. So there are the server components, um, you could almost model it, you're getting, you know, individual little endpoints for every single, every single component you have, and they can, they can be composed together just in the same way we're already currently using, React, which I, which I think is fantastic.
-
-[21:33] There are some issues with it still, that, that I don't I'm still not 100 percent sure how they solve or how they're going to solve, for example, data serialization. If you're sending data from the server to the client, say you have a date or a map or a set, the client is going to receive that as just just a string or, you know, a stringified array.
-
-[21:55] And... When you're dealing with a very visible network boundary, like you've got a loader and a react components or you've got your server side props and then your react bit it's pretty easy to see where that boundary is, but now with the server components, you can create that network boundary simply by passing data to a prop in a client component, and I just think that's really, really subtle at the moment, so I'm not 100 percent for you know, if that's actually going to cause problems in practicality, you go inside that component, and now your types are just a little different than they were.
-
-[22:30] In the server components it seems like that's going to be space for people to get confused.
-
-[22:36] But all in all the components that these enable are, I think, I think, fantastic. Like, we're looking at, you can imagine a component that render, or that syntax highlights code for you. So you just pack text and it's got all the syntax highlighting built in without needing to ship megabytes upon megabytes of, libraries to the browser to make it understand every programming language it could support.
-
-[22:59] you could imagine a, say an image component that automatically. You know, pre process the image based on its, you know, widths and heights and any resolutions you set. Next already has a sort of proprietary version of that, but it only works on Vercel hardware. Because they are, if they're in charge of the deploy process, they can then transform your code to make that work.
-
-[23:22] But this will now enable that to work on any hardware that supports React Server Components. So yeah, I'm super excited about it. The ability to do that and then you can publish these full stack components in libraries as well. And then users can just import them and things will work full stack, which is you know, it's just, it's, it's, it's unlocking new abilities that we just couldn't do before.
-
-[23:45] **Carl Vitullo:** Yeah, unlocking new abilities really does seem like the big thing here. I feel like I, I too have kind of skimmed past this, despite talking about it with some frequency on this event. But it just, I, I can sense that it's going to be a very wide and deep subject, and I just don't feel like... Like, okay, I can write a toy project and get a little bit of experience of what it's like using it.
-
-[24:08] But, you know, that won't really tell me everything I need to know about what are the performance characteristics for like 99th percentile users or, you know, there's just like such a long tail of things to learn about how it will affect development and performance and user experience and all of those things.
-
-[24:28] And so I feel like I'm going to keep saying, "I don't think I really understand this" for a very long time because the implications are going to take a long time to really shake out.
-
-[24:38] **Jacob Paris:** Yeah, and there's there's some new sort of, foot guns coming in that people will have to watch out for like, for example, you know, it's super common.
-
-[24:45] You have an array of data and you, you, you, you map through it. And on each iteration of the map, you're, you're creating a component, but they have a list mapping through and creating a list item in each one. The, the data you pass to that list is going to be. Individually serialized for every item in that list, if you happen to pass any large document React Server Components are not going to de duplicate that for you.
-
-[25:10] So you, you can end up with tons and tons of data. Ryan Florence was saying there was something similar in in a Shopify Hydrogen application that functioned in, in largely the same way. And yeah, it's, we're, we're introducing a whole new set of you know, things that people are going to have to watch out for if they want to have performant code.
-
-[25:30] I'm really hoping that when this kind of hits mainstream, there's either going to be enough messaging or maybe lint rules or something, you know, maybe some just physical boundaries put into the framework to stop people from making mistakes like this. Because it just, at the moment, it seems really, really easy to make a lot of mistakes.
-
-[25:49] **Sebastien Lorber:** Yeah, I wanted to mention another use case that you maybe didn't think of is you, you know, maybe you used Gatsby before with the GraphQL layer to inject data in, in pages, I think actually, um, React Server Components could be a very good alternative to that, and this is what I'd like to explore in Docusaurus actually, because, you know, the server components do not really need to run on the server.
-
-[26:13] You can actually run them at build time, as part of your build process, so a static side generator like Docusaurus is able to also use server components at build time. And this can give the ability to have a very flexible data layer. So instead of using static GraphQL queries in pages and things like that, you would be able to actually use Node. js code inside Interleaved with the client side React code and be able to inject the right data at the right place without actually the need for creating a complex GraphQL query and things like that. So somehow From my Docusaurus perspective, what I just have to do is to expose the data structure and let the user pick the right, data structure from it from right of a component and inject it in a subcomponents.
-
-[27:08] So, you don't need actually to have something more advanced. You can just use a JavaScript to get the right data at the right place. And you can do it both at the runtime or at build time.
-
-[27:21] **Jacob Paris:** Okay, I, I like that a lot actually. So, so you'd be able to have all of your, um, all of the components in Docusaurus that you're using.
-
-[27:30] Each component can have its own GraphQL queries to fetch the data it needs to do. And then you're sort of... Flattening all of that at a compile time, they just fetch the data, it turns into static content.
-
-[27:42] **Sebastien Lorber:** Actually, the goal is, the goal is to actually not use GraphQL because this is what Gatsby does, and I think the community didn't really like it. it was a bit too complex. So, um, and one of the shortcomings of Docusaurus is that we are, we use a plugin architecture. So we have a blog plugin and a docs plugin, and they don't see each other. And the problem is that, for example, if you want To display the free, the last three blog posts on your docs. It's impossible because the docs doesn't have access to the blog. So, using server components make it possible for you to override, the docs components and from there read the data structure provided by another plugin and somehow this provides a lot of flexibility thanks to being able to do this, some part of the code, running in the Node. js side.
-
-[28:35] **Jacob Paris:** Oh, cool. Cool. Yeah. I like that a lot. That's that is super cool.
-
-[28:39] **Sebastien Lorber:** Yeah. We'll see if it works out. I don't know yet, but I think it will.
-
-[28:45] **Carl Vitullo:** Nice. Interesting. Yeah. The data fetching side and the actual experience of developing and using that is like what I most specifically would like to check out. And I just, I, I don't have an app that I'm working on right now that has those needs, so I, I don't really know how to get that kind of experience that I'm really hoping, hoping to learn.
-
-[29:04] But yeah, on the, on the subject of foot guns, there's a, there's a quote that I love from the guy who made C++, and it's about C and C++, but I think it applies here a little bit, you know, like these server components are like really powerful new tools, but the quote is like.
-
-[29:21] C++ has fewer foot guns, but when you hit one, you blow your whole leg off. And that feels a little bit like where we're at. It's like, you know, we have this powerful new tool and we're still figuring out what, you know, what, what's just like a little injury and what's like a major wound. So, you know, we're gonna, we're gonna, we're gonna, we'll take some time to settle.
-
-[29:42] **Jacob Paris:** Yeah, I think Ryan Florence had a similar quote talking about the server components. He said, you know, this is a very sharp knife, and I like that, but it doesn't have a handle. I would really like a handle.
-
-[29:52] **Carl Vitullo:** Haha. That's actually, I love that metaphor. That's really good. Because that's, yeah that, I feel like that touches on a lot of the complaints that I've heard about this, server components rollout over the last couple of months. I hadn't seen that quote. That's a really good one.
-
-[30:05] Nice. Okay. Well, I'll, I'll move us on to our next subject.
-
-## Bun 1.0
-
-- [Bun 1.0](https://bun.sh/blog/bun-v1.0)
- - [My Thoughts on Bun](https://adventures.nodeland.dev/archive/my-thoughts-on-bun/)
- - [Announcing Biome](https://biomejs.dev/blog/annoucing-biome)
-
-[30:08] **Carl Vitullo:** Um, Bun 1. 0 is officially released. There's so much to talk about there, I think. Bun is so many things, but I don't even know where to start.
-
-[30:21] it's an all in one toolkit they're describing themselves as. there's a huge focus on performance, which is really interesting. They have, I, my favorite performance stats that they quote is they're 40 percent faster at running like 200 and something unit tests than Jest is at printing its own version number. So not even running tests, just like startup and print version number exit. Bun runs all the tests 40 percent faster than that. Um, so hilarious stat.
-
-[30:52] They are claiming to replace a huge list of tools. I'm just going to read this off node, npx, dotenv, although now node has gotten rid of dotenv as well, so that's, there's one bullet point off the marketing that the marketing list they also replaced nodemon, the WS package for web sockets, node fetch, cause fetch is built in, TSC cause it's a compiler Babel, TS node, TSX, esbuild, webpack, parcel, rollup. NPM, Yarn, PMPM, Lerna, Jest, Vitest. So like that's, that's quite a claim.
-
-[31:29] it reminds me a lot of the original promise and claims of Rome as a project, which is unfortunately well, Rome is no longer a thing, now Biome is a, an open source fork. But, so I'm keeping an eye on that too. But. Bun is claiming to be a drop in replacement for Node, where any existing Node application just works in Bun.
-
-[31:53] I know that they also have introduced a number of non standard behaviors. One of my favorites is that they allow you to read input from the console as an iterable, so you can do like `for (input in console)`, and then within the for loop, like boom, there's your REPL, three lines of code. So like, there's a lot of really interesting things that are phenomenal developer conveniences for some specific use cases, but it's non standard.
-
-[32:21] So if you write Bun code. You can't then port it, you know, just run it in a different runtime because that's non standard. It's not specified anywhere. So that seems a little fragmenting to me, but also a lot of these, a lot of the non standard improvements seem really cool. So maybe they'll get standardized. Maybe it'll be a CoffeeScript kind of situation again. Yeah, I, let me, let me hand it back to the floor. Anyone else have thoughts on Bun.
-
-[32:45] **Jacob Paris:** Yeah, yeah, I'm always a little torn on when it comes to non standard features like this. I think it's super cool that Bun can do, that Bun can do all of that.
-
-[32:55] They've also got their ESM and CJS interop, so you can have CommonJS imports, with the require syntax, and ESM imports with the import syntax, all in the same file. And you know that that's fantastic for developers who no longer need to worry about this. But then you look at a larger ecosystem, yeah, any, any libraries built on this they're only going to work with Bun.
-
-[33:17] They won't work on Node and everything else. And that's, that's, it's been a quite a contentious point in the, sort of library ecosystem. Like, it's, you know, it's nice to have these for developers, but is this going to really fragment the ecosystem? Are we going to end up with a bunch of Bun only libraries?
-
-[33:35] **Carl Vitullo:** Yeah, sure. I, I also, I, I read a a, a blog post from one of the node core team members. Just his thoughts on Bun. I thought it was really interesting. This was just sort of a, it was a very grounded take in comparing node versus Bun, and like it has, why is Bun faster than Node.js? And the first item on it is Node. js has no budget and a tiny team maintains NPM.
-
-[33:59] So it's like, they're just talking about very much about the practicalities, not just the code reasons. And yeah, I mean, like, so Buns, Bun 1. 0 announces it as like a drop in replacement for Node. js. This you know, other blog post from a core, a Node core member says Bun does not currently support Fastify.
-
-[34:20] Which is a reasonably popular competitor to express. So like, yeah, I mean, if you're not supporting like one of the top five HTTP servers, then like advertising it as a drop in replacement seems maybe a little bit overstating it. so I don't know, there's still, still a little bit of, a little bit more improvements that I'm going to be keeping an eye on.
-
-[34:40] But honestly, one of the most exciting things for me about Bun is, or rather, something about Bund that fixes a problem I've heard about for so many years now at this point is Node. js slow startup time. You know, like exactly, I mentioned before that it talks about running tests faster than Jest prints its own version.
-
-[35:01] A lot of that is, it's runtime overhead. You know, it's like the, because of how modules are parsed and, you know, executed. there's a very long startup time. So seeing that improve substantially, I think is going to be, you know, maybe that's not going to be like world changing, but I think it will be a pretty significant difference for people who are authoring CLI tools with JavaScript.
-
-[35:25] So, you know, hopefully, I'm excited to see what happens with that. Now that somebody has thrown on the gauntlet of like, this is how fast it can be. I'm interested to see where it goes.
-
-[35:34] **Jacob Paris:** Yeah, yeah, I'm super excited about that as well, and especially since, um, you know, there's some comments in here saying, you know, Node isn't going away, Node isn't going away everywhere, maybe, maybe that's just the key to this, Node isn't going away, library authors are still going to have to support Node and maybe that's why the ecosystem won't fragment, developers can move on to Bun and Node Library authors are still going to have to produce compatible code in either ESM or CJS, just because some developers.
-
-[36:05] The big companies and so on are still going to be using node for at least the foreseeable future. Maybe that's the best of both worlds.
-
-[36:13] **Sebastien Lorber:** And I think, if you want to try it now, maybe the good idea is to start by, using it in consumer code. So not, in, libraries, but just, for example, if you want you locally to run tests. Instead of using Node. js plus Jest, you can, you can try Bun, for example. There's not a lot of risk doing so. Eventually, you can ship it to your GitHub Actions or something like that. I don't know if it runs in, in GitHub Actions, but I assume it does. But yeah, yeah, maybe shipping it to production is a bit risky today, but, for example, running, a Bun install or something like that is not super risky.
-
-[36:52] So maybe we should start by doing this and see how stable it is. And yeah, I don't remember what I wanted to say. So.
-
-[37:00] **Carl Vitullo:** That's okay. Sometimes we trail off.
-
-[37:03] **Jacob Paris:** Maybe part of the issue here when it comes to, you know, Can we use Bun in production is just, since Bun is so many different things what does it actually mean to use it in production?
-
-[37:13] I mean, yeah, you can use it for your tests, you can use it as a package manager, you can use it as a, as a host to actually run your app as a server. Um, maybe that one is the most risky one that we shouldn't be doing, but, you know, if, if it's just installs by so much, um, maybe, maybe that's okay. Maybe that can be the entry point here where we, where we start using this.
-
-[37:35] **Sebastien Lorber:** The problem is that there is not a good Windows support, so if you start using Bun to do this kind of things, the thing is if you have someone on Windows in your team, then it becomes a problem for them because, you know, if you use Bun and it works for you, and they use YARN and it doesn't work because the log file is not the same, then this becomes somehow a big mess.
-
-[38:00] ' cause you don't have the same dependencies. So, I don't know, on, on my side. I think for example, as Docusaurus is a static side generator, I'm not afraid, for example, to recommend to use Bun to eventually, build the site with, with Bun. Because once it's built in the CI you just have static files. So it's not really risky once you have succeeded, building the site. But, yeah, for several run time, I, I would wait a bit before deploying that to, to any cloud.
-
-[38:30] **Carl Vitullo:** Yeah, yeah. One other thing I wanted to bring into the conversation is Bun is a VC funded company, which I was just talking about this last night a little bit with some other React ecosystem buddies and it was brought up, you know, like the runtime companies have not historically done very well. You know, you, you, you think about who maintains JavaScript runtimes. And it's like, you know, five years ago, that was Google, Apple and Microsoft. And now it's just Google and Apple. So trying to start a brand new startup on the basis of, here's a runtime, it's a challenge.
-
-[39:09] as far as I understand, Bunn is coming at it the same way Vercel is as a hosting platform. They're saying, here's our cloud offering, use it. But I, I'm not sure that that is a strong enough differentiator because like, what's it's an open source project. Like what's the stop every other hosting provider from using that, you know, just offering it as a runtime.
-
-[39:29] So I don't know. I don't know exactly what that means. Um, I think that Bun as a runtime is really interesting. I'm not sure that Bun as a cloud platform distinct from Vercel, AWS, GCP, all of those. But yeah, we'll see. We'll see how that all shakes out. if nothing else, we've got a really cool project putting pressure on everyone to improve.
-
-[39:55] **Jacob Paris:** Yeah, it's, it's sort of a catch 22 situation here. Like either, either all the web hosts as they exist right now, they start to support Bun, and then you can use Bun in all your applications everywhere and Bun goes popular, and if that happens, now there's all this competition for Bun as a hosting platform or, or it just doesn't happen.
-
-[40:15] You, your Bun app can't actually run anywhere, and then not enough people are using Bun to justify having it as a, as its own hosting platform. So, I'm a little, little iffy on the business model there, but I, I often, in these situations, I just assume that the people who have, Given, you know, sort of devoted their livelihoods to building these companies no more than I do after reading a bunch of tweets and articles about it.
-
-[40:41] **Carl Vitullo:** At the very least they've thought about it a lot more than I have. So, well, interested to see what they come up with. And, man, what an oversight, I meant to talk about Deno as well I don't want to, we're trying to wrap it up so I'm not going to bring it up too much, but between like Bun, Deno, Biome, there's a lot of really interesting like all-in-one type, runtimes and packages and all that kind of stuff, really interesting.
-
-[41:07] But yeah Jacob, you want to take us on to our, our next link?
-
-## Next.js Forms and Mututations
-
-- [Next.js App Router - Forms and Mutations docs](https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations)
-
-[41:10] **Jacob Paris:** Yeah, yeah. So the next one for me is, um, sort of the announcement of the next, you know, the next stage of the next JS app router with their forms and mutations. So they just pushed out all the new, all the new docs on that and, Lee put out this excellent video running through you know, sort of the concepts of how these, how these server actions actually work.
-
-[41:33] Which has been again, similar to Josh's article from before. I think it answers a lot of questions that people had. So, yeah, it starts off covering you know, the, the traditional way that we're submitting forms in a React app. Where you, you, you have a form, and then in your on submit callback, you prevent default to stop it from automatically reloading the page.
-
-[41:55] You send your data to an API route, and then whatever data comes back, you have to deal with yourself in that callback. And, you know, whether that's writing it to state or performing some other actions, and, you know, for a long time, if you're working with a separate backend server, that would mean going to another repository.
-
-[42:13] You you need to build a new endpoint there. You, if you're dealing with, say, TypeScript at all, you don't have to manage that in two separate repositories, and then you end up with two separate repositories. Pull requests and, those have to be merged and deployed all at the same time, which makes testing a nightmare.
-
-[42:30] You know, I'm sort of glad we moved away that with Next.Js. You just define the API routes in your react app, in another file and the on submit callback use fetch to send data to that. So that, that's kind of the state of where everything was. was right now.
-
-[42:45] I, I do think Remix took that a little step further. So rather than having the API route in a separate file, it then, it moves into the same file. It's just an action in the same file. And rather than having to write this whole on submit thing Remix's form components will do that, all of that for you, which I think is, you know, one step up from where, where Next was.
-
-[43:03] But now, like Next has taken a huge step forward with these server actions. We have this whole progression, I guess, that the, that the ecosystem has gone through where it's less and less code every single time so rather than having, you know, two repositories, now we're down to one, and then now it's all into the same file, and we're, we're sort of co locating all the code together, so you get this really concentrated sort of, sort of concerns here, and the React server actions are the next step in this process.
-
-[43:33] Rather than having all your data fetching being co located to a particular route is that now we can move them into a single component for the form element that has the traditionally would have an action that links to a particular endpoint, you can just pass a function to it now with the next server actions and Next will do all the work of triggering that like a remote procedure call returning the data to a form action and form data hooks to deal with the, to deal with the results of it.
-
-[44:02] It's, it's really, it's the other half of the client components that I was talking about earlier for, for data fetching. now finally for the first time in next existence, they have a proper data mutation story. They're acknowledging that they're, you know, in an application you're going to need to, you know, modify data on the database, you're going to need to save things and deal with the results of that.
-
-[44:26] So rather than using something like, say, React Query or tRPC, which are sort of, you know, historical solutions there, is that these server actions are really, really good. Yeah, so you declare the functions on your server, you mark them as "use server", and... the browser will just call them automatically.
-
-[44:43] They still, they automatically degrade to browser form submissions if you're trying to submit them without JavaScript being enabled. so you get the full progressive enhancement. Yeah, I'm, I'm, I'm a big fan of this. It's it's, it's been super, super cool.
-
-[44:58] **Carl Vitullo:** Definitely reminds me a lot of how Remix implemented the same thing. Although I guess Remix does it as an export from the file, whereas this is just a function within the component or as a separate file, but yeah, one thing that's catching my eye in the, in these docs, the, I do not like the use server, use client directives.
-
-[45:20] I know that like the idea of introducing more directives, you know, so like directives came from the ES6 transition, use strict. So that's what they're basing these off, you know, like you opt into a new mode for the runtime. And, you know, I, I followed like TC39 JavaScript standard discussions loosely through my career.
-
-[45:43] And I've seen a fair number of new directives suggested, brought up by people saying like, Hey, like, it would be really great if we could have this new mode for things to happen in and the message that has been so consistently said from the people who maintain the spec and said, like, "no, we, we are never doing another directive. That was a one time thing because we needed to break, you know, we needed to have a seam where we introduce new behavior and it was not possible to do in any other way without introducing breaking changes."
-
-[46:14] And so to see it go from one ever to, oh, here's two new ones. I don't, I don't, I don't like it. I don't know. It seems like a really big break from the norms that have been set by the people who introduced that pattern. and, and, and. here it is not the first, you know, statement in a file, but the first statement in a function. So it's a new behavior on something that had been, you know, introduced 10 years ago as a, you know, a necessary evil.
-
-[46:46] And I know it gets stripped out. I know that it's just kind of to inform the compiler or whatever, but I don't know. Feels weird to me. I don't like it as much as the way Remix just does an export. That seems very simple to me and I like it. I guess that's what I'm saying.
-
-[47:02] **Jacob Paris:** Yeah, yeah. We certainly need some way of communicating to the, um, you know, to the runtime, what sort of mode it should be in while it's processing this function.
-
-[47:11] Remix handles that with just, just the naming convention. So there's certain functions that behave differently. You got your actions, your loaders, meta, headers, functions, and they're all just exported from the route. Whereas with Next, you're now using these directives to mark different behavior in, in the functions.
-
-[47:29] I don't know what the better way to do that would be. A lot of that kind of is up, above my head. one, one that I don't like is that since you're declaring these... You know, if you declare these server actions in line, anything you close over in there. So it, it looks like if it were a normal function, that you can access variables from the scope above it.
-
-[47:49] Um, so you define a variable and then you include it. And then now that's going to be included. Um, like it's, it's really confusing how that happens with the server bundle. If you have a client component in there, you could very easily end up introducing a bunch of, say private keys. If it is So you have a, like an API key in the upper scope and you're referencing something from, from that class or object within your action, because it looks like you can, that can really easily end up in the, in, in the client. yeah, it's, it's, it's, it's another foot gun where we're having more and more foot guns to worry about with all of this.
-
-[48:25] **Carl Vitullo:** So Sebastian, you want to take us off for our next link?
-
-[48:28] **Sebastien Lorber:** Actually, it's only my second link, I think. And yeah, it's a big one, so I should have started by, by this one, I think. Haha.
-
-[48:37] **Carl Vitullo:** A lot of news this month.
-
-[48:38] **Sebastien Lorber:** Yeah, exactly.
-
-## Expo API Routes
-
-- [Expo Router RFC - API Routes](https://blog.expo.dev/rfc-api-routes-cce5a3b9f25d)
-
-[48:40] **Sebastien Lorber:** Even this summer was quite busy, I think. So it's about, Expo API routes, RFC. So I think it's very interesting because, I think it's the first time that Expo is, going, on the server side. So this is, somehow not a very complicated feature. It's just about deploying API routes creating a convention to deploy API routes to a server, or creating a server runtime that you get, can deploy yourself or eventually on, on hosts like Vercel, Netlify, and maybe soon, the Expo APIs.
-
-[49:16] But what is very interesting, I think is because, you know, it's the very first step toward becoming a full stack framework where you can actually have a universal support for, the web and mobile using server side rendering on the web, so no compromise compared to the other frameworks. And also to support React Server Components in a cross platform way.
-
-[49:41] So you will be able to use the exact same code to render UI on mobile and on the web. And somehow, I think this is very exciting because, you know, currently if you want to build a web application, you don't think you will use Expo because the support of Expo web works, but it's not good enough to be able to bet on Expo just to ship a mobile app.
-
-[50:05] Maybe in the future, if they implement this well, you could even. Decide to use Expo, even if you don't target mobile, I think. So this, this could be very exciting to to have Expo being, becoming a real competitor to other frameworks on the web.
-
-[50:23] **Carl Vitullo:** Yeah. Oh, that's interesting, this builds so well off what we were just talking about with the server actions. So
-
-[50:28] that works out really great, great flow into a great transition. Yeah, oh, that's really interesting. So I know that Expo has been broadly moving towards not being as tightly coupled to React Native, but I didn't realize that they were. Even interested in doing some kind of server route like this.
-
-[50:50] This is, yeah, this is really cool. This definitely unlocks a lot of possibilities.
-
-[50:55] **Jacob Paris:** Yeah, I'm, I, I'm super like, I'm all for it. Any time where we can take the separate backends and frontends and move them into a single repository so that they can share you know, share types and you can develop, you know, push code a single, a single pull request to implement entire features all at once.
-
-[51:13] I, I'm all for that. So. It's, it seems here that Expo is now kind of going the way of Next or Remix, where you, where you can kind of, it just becomes a full stack framework all on its own. And as far as I know, up until now, that, that just wasn't possible in the React Native ecosystem. You always needed a separate backend server somewhere in order to handle that.
-
-[51:33] **Carl Vitullo:** Yeah, I'm definitely a little unsure because like Next and Remix, I understand, you know, you put it on a server and boom, there's your server. I don't really know what the deployment story for Expo is going to look like for these server actions. I'm scanning the blog post here, trying to find that, not seeing it immediately.
-
-[51:55] **Sebastien Lorber:** It's not server actions, they are not really, shipping, something advanced. So for now, it's just API routes like you have in Next. js too. So you just create an API endpoint that you can call on mobile. And I think the, the idea that we, they want to implement is first to enable you to self host the backend.
-
-[52:16] And then eventually the idea is that you just push to Expo cloud and then have the thing being served from their cloud like like if it was their server or Netlify so and you know for example they could be systems like we don't deploy we don't push the mobile update until the backend is deployed or things like that you have to synchronize things because uh mobile is long lived session, so you have to make sure that, the, the API that you deploy is compatible with the mobile side. And I think Explore has an opportunity to build something, that handles that well.
-
-[52:54] Vercel actually, built something similar, that they called Skew Protections. So, somehow if you, you know, if you have a trading application and you deploy a new version, The, the traders that use the, the former application still they don't want to refresh the browser to, to be able to keep using the app.
-
-[53:14] They want to just keep their long running session and keep interacting with the API. So it's important that the API doesn't break when you deploy new software and, for mobile, it's even more important. And I think, Expo Cloud has a card to play there.
-
-[53:27] **Carl Vitullo:** Yeah, interesting. Yeah, my first thought was like, Oh, another cloud provider, but that's actually interesting because there are genuinely different constraints for mobile versus web, because that's honestly one of the biggest differences I've noticed in my career between it is the experience of shipping new changes.
-
-[53:47] Like on a website, you know, I, I push out, I do CICD, boom, done, it's live unless there's a cache, unless I have set up a cache with, you know, a TTL that's long enough to introduce problems for that. I know that as soon as I hit that deploy button, my code is running for everyone. Maybe the service I'm working with has like a red green deployment. And so there's a gradual rollout where they're both going to be happening.
-
-[54:12] But like at the end of that, the code that everyone is hitting is. The code that was just deployed, whereas on mobile, you don't control that at all. People update the app whenever they want to, and maybe they don't for two years.
-
-[54:24] So that actually is really interesting. If I could co locate app specific API calls, have them deployed through some kind of managed service, and then. Had that cloud provider do the version management for me to make sure that they, you know, APIs from this version of the app are served by a compatible route handler.
-
-[54:50] Like, that's actually really interesting. That's pretty slick. That's pretty cool. So I think that they're introducing a new package, Expo Server, which you then need to deploy yourself. It looks like right now. I think that's what you were just saying. So, yeah, that's really interesting though.
-
-[55:03] Okay, should we move on to lightning round? All right.
-
-## ⚡️ React Native on Apple Vision Pro
-
-- [React-Native running natively on Apple Vision Pro simulator demo](https://twitter.com/o_kwasniewski/status/1701626162521190688)
-
-[55:06] **Carl Vitullo:** I guess first lightning round, I'll pull up, I'll just keep the React Native theme going React Native running natively on Apple Vision Pro simulator demo. That's cool. I don't have much else to say about that, but you know, AR VR with React in a 3d environment is like, that's pretty cool.
-
-[55:25] I like it. Jacob, you got a lightning round you like?
-
-## ⚡️ Are Big Projects Ditching TypeScript? (no)
-
-- [Are Big Projects Ditching TypeScript?](https://www.totaltypescript.com/are-big-projects-ditching-typescript)
-
-[55:28] **Jacob Paris:** Yeah, yeah, we got this once. "Are Big Projects Ditching TypeScript?" was, written up by Matt Pocock after DHH did his little let's remove all the types from Turbo thing. the consensus is no, most of them aren't. Svelte has switched to JSDoc, um, a few others in that line but no, TypeScript is here to stay.
-
-[55:47] **Carl Vitullo:** Yeah, ugh, I'm glad to see that was the outcome. DHH has, I've soured on him a little bit. Sorry, this is lightning round. We're not doing a full discussion.
-
-## ⚡️ Rust Server Components
-
-- [Rust Server Components](https://anto.pt/articles/rust-server-components)
-
-[55:56] **Carl Vitullo:** Oh yeah, I saw an interesting Rust server components post. Which is just interesting. The crossover between web and Rust is fascinating to me a little bit. And so now seeing somebody trying to do Server components, a like very fraught and complicated technology in rust. Interesting.
-
-[56:17] **Sebastien Lorber:** I wanted to mention something about the post rust server components. So this is more about using a rust backend with HTMX.
-
-[56:26] But there was recently an , an article from someone from the ReasonML community that I found super interesting because, they implemented React server side rendering in OCaml, in ReasonML, I think, or OCaml.
-
-[56:41] This led to very improved, performance in the benchmark. And I think now, the guy working on this is is now implementing server components in OCaml. So somehow, instead of running JavaScript in the... In the server runtime, they're running, a native language and, apparently it's really much faster.
-
-[57:04] And I find this quite interesting because maybe some day, there will be a faster runtime. maybe we can compile server components to native code on the server and, and run them much faster. But, I found this idea quite interesting to use something else than JavaScript to run, the React server side code.
-
-[57:26] **Jacob Paris:** Oh, interesting.
-
-## ⚡️ CSS-in-JS is Ruining Your Product
-
-- [Web Developers, CSS-in-JS is Ruining Your Product](https://cord.com/blog/migrating-from-css-in-js-to-vanilla-extract)
-
-[57:27] **Jacob Paris:** Here's a link from from, from Cords and, web developers, CS and JS for your product. Was that, was it was a neat a little article and sums up a lot of my, my thoughts here as well basically CSS and JS, so you can't generate the styles until your whole application has been rendered.
-
-[57:44] So you miss out on anything like React streaming. It has to render the whole thing. Styles and then inject them back into the app. There are some, you know, some solutions that are trying to fix issues like that'll extract using compile time extraction.
-
-[57:58] But in general, CSS and JS has kind of fallen out of fashion. And it seems like industry is sort of moving off and away from that.
-
-[58:05] **Carl Vitullo:** Yeah, interesting. We're 10 minutes over. We should probably, we could probably keep doing links forever. I, there's one more thing that I want to pop out then maybe we should call it after that.
-
-## ⚡️ Dan Abramov joins BlueSky
-
-- [Dan Abramov joins Bluesky](https://twitter.com/dan_abramov/status/1695566446007386214)
-
-[58:14] **Carl Vitullo:** But Dan Abramov is now a product engineer, no longer purely library maintainer on the backs, you know, behind the curtain of web development. He's joined BlueSky as a, as a software engineer. And I think that's going to be really interesting because as far as I know, he's still going to be on the core team. So I think specifically Dan Abramov, you know, working on a product and using React as a consumer. It's going to be really interesting.
-
-[58:45] I've been seeing some tweets from him coming out talking about points of friction on using React Native and all sorts of things like that. So just having seen all the different times that he has introduced something because he felt a pain point and then invented a new category of tool.
-
-[59:04] I can think of redux and create react app that were both just like his brain children that he felt the pain. He made something that fixed it. And then everyone else went, I didn't know you could do that. So I'm interested to see what happens now that he's being exposed to more points of friction with more regularity.
-
-[59:20] **Jacob Paris:** Yeah, and especially a shift toward React Native rather than, I guess, primarily React web which was a lot of his work before. It'll be interesting to see what that does for the native ecosystem.
-
-[59:30] **Sebastien Lorber:** Yeah. Maybe Expo, won a great, developer advocate for free.
-
-[59:35] **Jacob Paris:** Ha ha.
-
-[59:36] **Carl Vitullo:** All right, thank you so much Sebastian and Jacob. Jacob, thank you for subbing in for Mark this week. You killed it. You did great. Thanks so much.
-
-[59:43] **Jacob Paris:** Absolutely. Thanks for having me.
-
-[59:44] **Carl Vitullo:** Definitely. Awesome. Thanks so much everyone in the audience for joining us and see you next month.
-
-[59:50] **Sebastien Lorber:** Thank you. Bye.
+
)}
@@ -56,23 +82,26 @@ export async function getStaticProps() {
.sort((a, b) =>
a.date && b.date ? compareDesc(parseISO(a.date), parseISO(b.date)) : 1,
);
- const latest = all[0];
- if (!latest) {
+ if (all.length === 0) {
throw new Error("No transcripts found!");
}
+ const years = all
+ .filter((t) => t.date)
+ .map((t) => toDay(t.date).getFullYear());
return {
props: {
+ firstYear: Math.min(...years),
all: all.map((t) => ({
title: t.title,
- hasContent: Boolean(t.content),
path: `/transcripts/${t.slug}`,
+ month: t.date ? format(toDay(t.date), "MMMM yyyy") : "",
+ blurb: truncate(
+ processMdPlaintext(t.description ?? "")
+ .html.replace(/\s+/g, " ")
+ .trim(),
+ 160,
+ ),
})),
- latest: {
- title: latest.title,
- description: latest.description,
- date: latest.date,
- html: processMd(latest.content, { wrapFirstList: true }).html,
- },
},
};
}
diff --git a/src/pages/transcripts/[slug].tsx b/src/pages/transcripts/[slug].tsx
index 8cb665e..8c81cc4 100644
--- a/src/pages/transcripts/[slug].tsx
+++ b/src/pages/transcripts/[slug].tsx
@@ -17,16 +17,17 @@ export default function Transcript({
html,
}: Awaited+ Since {firstYear}, Reactiflux has hosted Q&As with the people + who build React, React Native, and the libraries and tools around + them. Members bring the questions; these are the transcripts, + newest first. +
- Transcript from {date} + Looking for This Month in React? Episodes, show notes and + transcripts are at{" "} + + tmir.reactiflux.com + + .
- +-
+ {all.map((transcript) => (
+
- + {transcript.title},{" "} + {transcript.month} + {transcript.blurb ? `: ${transcript.blurb}` : null} + + ))} +
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] diff --git a/src/transcripts/tmir-2026-01.md b/src/transcripts/tmir-2026-01.md deleted file mode 100644 index 62ed2a2..0000000 --- a/src/transcripts/tmir-2026-01.md +++ /dev/null @@ -1,840 +0,0 @@ ---- -title: 'TMiR 2026-01: Oops more CVEs. AI has React "skills", Astro exits and Tailwind struggles' -date: 2026-01-30 -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:58](#new-releases)] New releases - - [[00:59](#next-161-turbopack-updates-bundle-analyzer)] [Next 16.1](https://nextjs.org/blog/next-16-1) (Turbopack updates, bundle analyzer) - - [[01:15](#turbopack-incremental-computation)] [Turbopack incremental computation](https://nextjs.org/blog/turbopack-incremental-computation) - - [[01:38](#react-navigation-80-alpha)] [React Navigation 8.0 alpha](https://reactnavigation.org/blog/2025/12/19/react-navigation-8.0-alpha/) - - [[02:03](#rn-windows-081-with-new-arch-support)] [RN Windows 0.81 with New Arch support](https://devblogs.microsoft.com/react-native/%F0%9F%9A%80react-native-windows-v0-81-is-here/) - - [[02:55](#state-of-react-native-macos-saad-najmi-jay-meistrich)] [State of React Native macOS](https://www.youtube.com/watch?v=XE7yKGDsy9g) Saad Najmi & Jay Meistrich - - [[03:15](#mark-josh-goldbergs-new-flint-linter)] Mark: Josh Goldberg’s [new Flint linter](https://www.flint.fyi/blog/introducing-flint) - - [[05:15](#immer-111-array-methods-override)] [Immer 11.1](https://github.com/immerjs/immer/releases/tag/v11.1.0) (array methods override) - - [[06:37](#rolldown-10-rc)] [Rolldown 1.0 RC](https://voidzero.dev/posts/announcing-rolldown-rc) - - [[06:54](#yarn-6-preview)] [Yarn 6 Preview](https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/) - - [[07:42](#vite-plus)] [Vite Plus](https://viteplus.dev/) - - [[08:59](#new-css-grid-lanes-masonry-feature-spec-nailed-down)] [New “CSS Grid Lanes” (“masonry”) feature spec nailed down](https://webkit.org/blog/17660/introducing-css-grid-lanes/) - - [[10:39](#temporal-api-finally-hitting-stability-and-how-it-replaces-dates-)] [Temporal API finally hitting stability](https://developer.chrome.com/blog/new-in-chrome-144#temporal) ([and how it replaces Dates](https://piccalil.li/blog/date-is-out-and-temporal-is-in/) ) -- [[12:29](#main-content)] Main Content - - [[12:34](#react-core)] React Core - - [[12:37](#additional-updates-cves-for-dos-as-of-jan-26-update-to-1905-1915-and-1924)] [Additional updates / CVEs for DoS](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) as of Jan 26 . Update to 19.0.5, 19.1.5, and 19.2.4 - - [[13:40](#nextjs-dos-cves-for-image-optimizer-and-partial-pre-rendering)] [Next.js DoS CVes](https://vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472) for Image Optimizer and Partial Pre-Rendering - - [[13:50](#react-docs-updates-for-useoptimistic-and-useeffectevent)] React docs updates for [useOptimistic](https://github.com/reactjs/react.dev/pull/8264) and [useEffectEvent](https://github.com/reactjs/react.dev/pull/8279) - - [[14:11](#and-this-post-on-useoptimistic-issues)] And this post on [useOptimistic issues](https://www.columkelly.com/blog/use-optimistic) - - [[14:32](#sparked-by-dan-raising-concerns-about-the-docs-quality)] Sparked by [Dan raising concerns](https://bsky.app/profile/danabra.mov/post/3mciooa25gc2v%20) about the docs quality - - [[16:57](#ai-meets-rn-panel-discussion)] [AI meets RN Panel Discussion](https://www.youtube.com/watch?v=QX1a6I08o-A) - - [[17:17](#work-on-the-gesture-api-and-view-transitions-and-fragment-refs-canary-only)] Work on the [Gesture API and View Transitions](https://github.com/facebook/react/pull/35564), and [Fragment Refs](https://github.com/facebook/react/pull/35630) (canary only) - - [[18:29](#viewtransition-underlying-tech-is-now-supported-in-all-major-browsers-as-of-firefox-147-react-features-is-still-in-canary)] [\